8,288
edits
Changes
mLine 5:
Line 5: − + − + − +
typos
== Sugar Digest ==
== Sugar Digest ==
1. It has been crazy busy. With the upcoming XO4 launch, Sugar with touch support will be making its début. The developer team has done a great job but we are lagging behind a bit on the activity level: Activities that use keyboard input need to be modified to use the on-screen keyboard; and now that tablet mode will be used more often, we need to better attend to the issue of screen rotation.
1. It has been crazy busy. With the upcoming XO-4 launch, Sugar with touch support will be making its début. The developer team has done a great job but we are lagging behind a bit on the activity level: Activities that use keyboard input need to be modified to use the on-screen keyboard; and now that tablet mode will be used more often, we need to better attend to the issue of screen rotation.
In order to adapt to the on-screen keyboard, there are two adjustments that need to be made: (1) use either a GTK Entry or TextView instead of directly querying the keyboard; and (2) make sure that the Entry is visible when the keyboard is visible. To address both issues, I have been mostly using GTK Fixed in order to reposition the Entry appropriately. But also, I have been using a strategy of moving the Entry to the top of the activity.
In order to adapt to the on-screen keyboard, there are two adjustments that need to be made: (1) use either a GTK Entry or TextView instead of directly querying the keyboard; and (2) make sure that the Entry is visible when the keyboard is visible. To address both issues, I have been mostly using GTK Fixed in order to reposition the Entry appropriately. But also, I have been using a strategy of moving the Entry to the top of the activity.
There are two issues with dealing with landscape vs portrait mode. One is to make sure that the work area of an activity accommodates the change in size and aspect ration. Perhaps the easiest way to do this is simply to define a square work are inside of a scrolling window. There are times when this strategy won't work, such as with Paint, but for the most part, it is a simple solution.
There are two issues with dealing with landscape vs portrait mode. One is to make sure that the work area of an activity accommodates the change in size and aspect ration. Perhaps the easiest way to do this is simply to define a square work area inside of a scrolling window. There are times when this strategy won't work, such as with Paint, but for the most part, it is a simple solution.
The toolbars are another matter. It is often the case that not all of the elements fit when in portrait mode. The default behavior of Sugar, to make a list on a palette that displays on the edge of the screen is somewhat lacking, both in that many toolbar items are either not shown or inoperable in that form. And aesthetically, it is not very Sugar-like. I've been experimenting with some different approaches to generating palettes, and also moving some toolbar elements around (e.g., moving some buttons to secondary toolbars). Alas, none of these solutions are idea or completely generalizable. But I think there are harbingers of a solution.
The toolbars are another matter. It is often the case that not all of the elements fit when in portrait mode. The default behavior of Sugar, to make a list on a palette that displays on the edge of the screen is somewhat lacking, both in that many toolbar items are either not shown or inoperable in that form. And aesthetically, it is not very Sugar-like. I've been experimenting with some different approaches to generating palettes, and also moving some toolbar elements around (e.g., moving some buttons to secondary toolbars). Alas, none of these solutions are ideal or completely generalizable. But I think there are harbingers of a solution.
Another issue with touch is that Gtk2 ComboBoxes don't work. The problem has been fixed in the Gtk3 version of the Sugar tool-kit, but, not being a fan of Combo Boxes to begin with, I see it as an opportunity to minimize their use. For example, using bigger/smaller buttons is arguably an easier way to adjust font size using touch.
Another issue with touch is that Gtk2 ComboBoxes don't work. The problem has been fixed in the Gtk3 version of the Sugar tool-kit, but, not being a fan of Combo Boxes to begin with, I see it as an opportunity to minimize their use. For example, using bigger/smaller buttons is arguably an easier way to adjust font size using touch.