Re: [Sugar-devel] Is there a way to purposefully do synchronous GUI updates?
On Tue, Aug 21, 2012 at 12:18:43PM +0530, Ajay Garg wrote: > James, > > Yes. Only one thread ACTUALLY executes on at any time on a > uniprocessor system. That is logical. > > But the thing is.. I am not at all wanting to speed up anything > .. :P :P I think you are wanting to speed up yourself, and that is a reasonable goal. > I am wanting to solve an issue, which in the present case seems > possible ONLY by using two threads. > > My intention is to somehow have GUI updates in a synchronous manner, > and not rely upon "gobject.idle_add", which would have to have > dividing a long workflow into many sub-parts, and chaining these > sub-parts through "gobject.idle_add". This is EXTREMELY painful, > especially when one needs to do it on an already existing codebase. Can you factor this in some python way so that you don't have to worry about the implementation detail of calling idle_add? How about a list of lambda functions, or a list of method calls? Can you be more specific about what code is afflicted by this problem? > So, the two-thread workflow would make that easier. And yes, only > one thread will execute any time; in fact, my suggested workflow > takes advantage of this only-one-thread-running fact :D > > At the same time, I also think that there is no easy way to do what > I want. At least not without hacking onto the python-core code > (event loop implementation). I agree, you might need to work to make the python core and GTK+ handle threads as well. I don't know the size of that work. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is there a way to purposefully do synchronous GUI updates?
James, Yes. Only one thread ACTUALLY executes on at any time on a uniprocessor system. That is logical. But the thing is.. I am not at all wanting to speed up anything .. :P :P I am wanting to solve an issue, which in the present case seems possible ONLY by using two threads. My intention is to somehow have GUI updates in a synchronous manner, and not rely upon "gobject.idle_add", which would have to have dividing a long workflow into many sub-parts, and chaining these sub-parts through "gobject.idle_add". This is EXTREMELY painful, especially when one needs to do it on an already existing codebase. So, the two-thread workflow would make that easier. And yes, only one thread will execute any time; in fact, my suggested workflow takes advantage of this only-one-thread-running fact :D At the same time, I also think that there is no easy way to do what I want. At least not without hacking onto the python-core code (event loop implementation). Thanks and Regards, Ajay On Tue, Aug 21, 2012 at 12:02 PM, James Cameron wrote: > First, learn that on a single processor system, only one thread > actually executes at a given time, so if you think you have more than > one thread of execution, you're wrong and you really only have one. > > As soon as you expand the time for sampling, yes, more than one > thread, or process, may execute. > > In this situation, threads are an abstraction which distorts reality. > > On Tue, Aug 21, 2012 at 11:33:55AM +0530, Ajay Garg wrote: > > Thanks James for the reply. > > > > > > On Tue, Aug 21, 2012 at 3:47 AM, James Cameron wrote: > > > > On Tue, Aug 21, 2012 at 12:11:13AM +0530, Ajay Garg wrote: > > > So, is there a way to have the code always in-order; in other > words, > > > have the GUI updates absolutely synchronous? > > > > No, not without waiting for the update to complete, and if you do > > this, the code runs very slowly. > > > > (When there is only one CPU, only one process can execute on it at a > > time. The updates are placed in a pipeline to the display, and the > > display process runs them as soon as it is practical to do so. If > > your process does not release the CPU, then your process will likely > > continue executing until it hits something that will cause it to > > release. It is better to be specific and use idle_add to release.) > > > > > > Right. > > > > Now, from what I believe, that there is just one "main" thread, that is > > responsible for running the "normal, backend" code, and the same "main" > thread > > does the GUI updates (of the events present in the display pipeline), > when it > > has nothing more to do with the "normal, backend" code. > > > > This also means, that doing something like > > > > main_thread.wait() > > > > would be idiotic, as that would stall the GUI updates as well. > > I don't understand what you would hope to achieve by calling .wait(). > > > So, does there exist a method, that could cause doing the GUI updates in > a > > different (other than the "main" thread) ? > > If yes, that would solve the issue, as the following would then be > feasible :: > > > > logic statement 1 > > spawn a new thread, and pass the GUI-update event to > > it | > > "joins" on the new > > thread | > > > > | anywhere in this interval, the new thread performs the GUI update > > > > | > > > > | > > > > new thread terminates > > logic statement 2 > > > > > > > > At first, it seems that the " spawn a new thread, and pass > the > > GUI-update event to it" step is trivial. > > However, the thing to note that in a default python configuration, all > GUI > > update events are scheduled in the context of the main thread. > > > > So, only if the GUI update events could be scheduled to be processed in a > > custom thread - that would be awesome !!! > > > > > > Please let me know if any such method exists :) > > No, I don't think so. It is an event loop implementation only. > > For more information, google "Threads Considered Harmful", and check > out John Ousterhout's paper "Why Threads Are A Bad Idea (for most > purposes)." > > -- > James Cameron > http://quozl.linux.org.au/ > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is there a way to purposefully do synchronous GUI updates?
First, learn that on a single processor system, only one thread actually executes at a given time, so if you think you have more than one thread of execution, you're wrong and you really only have one. As soon as you expand the time for sampling, yes, more than one thread, or process, may execute. In this situation, threads are an abstraction which distorts reality. On Tue, Aug 21, 2012 at 11:33:55AM +0530, Ajay Garg wrote: > Thanks James for the reply. > > > On Tue, Aug 21, 2012 at 3:47 AM, James Cameron wrote: > > On Tue, Aug 21, 2012 at 12:11:13AM +0530, Ajay Garg wrote: > > So, is there a way to have the code always in-order; in other words, > > have the GUI updates absolutely synchronous? > > No, not without waiting for the update to complete, and if you do > this, the code runs very slowly. > > (When there is only one CPU, only one process can execute on it at a > time. The updates are placed in a pipeline to the display, and the > display process runs them as soon as it is practical to do so. If > your process does not release the CPU, then your process will likely > continue executing until it hits something that will cause it to > release. It is better to be specific and use idle_add to release.) > > > Right. > > Now, from what I believe, that there is just one "main" thread, that is > responsible for running the "normal, backend" code, and the same "main" thread > does the GUI updates (of the events present in the display pipeline), when it > has nothing more to do with the "normal, backend" code. > > This also means, that doing something like > > main_thread.wait() > > would be idiotic, as that would stall the GUI updates as well. I don't understand what you would hope to achieve by calling .wait(). > So, does there exist a method, that could cause doing the GUI updates in a > different (other than the "main" thread) ? > If yes, that would solve the issue, as the following would then be feasible :: > > logic statement 1 > spawn a new thread, and pass the GUI-update event to > it | > "joins" on the new > thread | > > > | anywhere in this interval, the new thread performs the GUI update > > > | > > > | > > > new thread terminates > logic statement 2 > > > > At first, it seems that the " spawn a new thread, and pass the > GUI-update event to it" step is trivial. > However, the thing to note that in a default python configuration, all GUI > update events are scheduled in the context of the main thread. > > So, only if the GUI update events could be scheduled to be processed in a > custom thread - that would be awesome !!! > > > Please let me know if any such method exists :) No, I don't think so. It is an event loop implementation only. For more information, google "Threads Considered Harmful", and check out John Ousterhout's paper "Why Threads Are A Bad Idea (for most purposes)." -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is there a way to purposefully do synchronous GUI updates?
Thanks James for the reply. On Tue, Aug 21, 2012 at 3:47 AM, James Cameron wrote: > On Tue, Aug 21, 2012 at 12:11:13AM +0530, Ajay Garg wrote: > > So, is there a way to have the code always in-order; in other words, > > have the GUI updates absolutely synchronous? > > No, not without waiting for the update to complete, and if you do > this, the code runs very slowly. > > (When there is only one CPU, only one process can execute on it at a > time. The updates are placed in a pipeline to the display, and the > display process runs them as soon as it is practical to do so. If > your process does not release the CPU, then your process will likely > continue executing until it hits something that will cause it to > release. It is better to be specific and use idle_add to release.) > Right. Now, from what I believe, that there is just one "main" thread, that is responsible for running the "normal, backend" code, and the same "main" thread does the GUI updates (of the events present in the display pipeline), when it has nothing more to do with the "normal, backend" code. This also means, that doing something like main_thread.wait() would be idiotic, as that would stall the GUI updates as well. So, does there exist a method, that could cause doing the GUI updates in a different (other than the "main" thread) ? If yes, that would solve the issue, as the following would then be feasible :: logic statement 1 spawn a new thread, and pass the GUI-update event to it | "joins" on the new thread | | anywhere in this interval, the new thread performs the GUI update | | new thread terminates logic statement 2 At first, it seems that the "* spawn a new thread, and pass the GUI-update event to it*" step is trivial. However, the thing to note that in a default python configuration, all GUI update events are scheduled in the context of the main thread. So, only if the GUI update events could be scheduled to be processed in a custom thread - that would be awesome !!! Please let me know if any such method exists :) Thanks and Regards, Ajay > -- > James Cameron > http://quozl.linux.org.au/ > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Fix drag and drop to the clipboard - SL #3811
2012/8/21 Manuel Quiñones : > gtk.gdk.DragContext.get_source_widget returns None if the drag is not > made within the same application. pygtk documentation for reference: http://www.pygtk.org/docs/pygtk/class-gdkdragcontext.html#method-gdkdragcontext--get-source-widget This is enough test to say that > it's not an internal drag. The gtk.Viewport comparison is left as > fallback. > > Signed-off-by: Manuel Quiñones > --- > src/jarabe/frame/clipboardtray.py | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/src/jarabe/frame/clipboardtray.py > b/src/jarabe/frame/clipboardtray.py > index 37d5e1a..779ffed 100644 > --- a/src/jarabe/frame/clipboardtray.py > +++ b/src/jarabe/frame/clipboardtray.py > @@ -216,7 +216,10 @@ class ClipboardTray(tray.VTray): > context.drop_finish(True, gtk.get_current_event_time()) > > def _internal_drag(self, context): > -view_ancestor = > context.get_source_widget().get_ancestor(gtk.Viewport) > +source_widget = context.get_source_widget() > +if source_widget is None: > +return False > +view_ancestor = source_widget.get_ancestor(gtk.Viewport) > if view_ancestor is self._viewport: > return True > else: > -- > 1.7.11.2 > -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar] Fix drag and drop to the clipboard - SL #3811
gtk.gdk.DragContext.get_source_widget returns None if the drag is not made within the same application. This is enough test to say that it's not an internal drag. The gtk.Viewport comparison is left as fallback. Signed-off-by: Manuel Quiñones --- src/jarabe/frame/clipboardtray.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/jarabe/frame/clipboardtray.py b/src/jarabe/frame/clipboardtray.py index 37d5e1a..779ffed 100644 --- a/src/jarabe/frame/clipboardtray.py +++ b/src/jarabe/frame/clipboardtray.py @@ -216,7 +216,10 @@ class ClipboardTray(tray.VTray): context.drop_finish(True, gtk.get_current_event_time()) def _internal_drag(self, context): -view_ancestor = context.get_source_widget().get_ancestor(gtk.Viewport) +source_widget = context.get_source_widget() +if source_widget is None: +return False +view_ancestor = source_widget.get_ancestor(gtk.Viewport) if view_ancestor is self._viewport: return True else: -- 1.7.11.2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Journal: confirmation before erasing/duplicating an entry
On 08/20/2012 11:21 PM, Manuel Quiñones wrote: 2012/8/19 Simon Schampijer : Hi, I have been working on the confirmation alert for the Journal, submitted a patch [1]. "Erasing an entry in the Journal does not ask for confirmation before doing the erase. This patch adds an alert to the ListView and the DetailView that asks for confirmation before doing the erase. This is part of the touch interaction work [2]". I think the need is clear, I just want to confirm the wording of the message and title. "This will erase the object..." can also work, but I think "This will erase the entry..." works better. About the alert for the duplication. I am not 100% convinced it is needed. +1 to not add an alert in duplication too. There is not much harm in duplicating an entry (unless it is really big). I try to avoid confirmation alerts when possible. I think the only thing which is critical is feedback in that case. In the ListView the feedback is given. Duplicating an entry in the DetailView lacks a bit the feedback what has happened. Long term an animation would be nice here. Short term options that would help giving feedback here (please not an alert:)? What about a message "duplicating entry..." that dissapears in a few seconds? Yes, is an alert :) but without Accept/Cancel buttons. Yes, I thought about that as well, actually. In the ListView I think feedback is great, in the DetailView not so much, so the alert would be only in the DetailView? Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse
On 08/20/2012 05:06 PM, Manuel Quiñones wrote: 2012/8/20 Simon Schampijer : On 08/20/2012 04:44 PM, Manuel Quiñones wrote: 2012/8/17 Simon Schampijer : On 08/17/2012 12:48 AM, Manuel Quiñones wrote: I've tested an earlier patch for this and now I reviewed it. This is a much more solid interaction with the frame, and less error prone. All looks good. Please commit. Thanks Manuel for testing and the review. I have fixed the 'cycling through activities' in v2 of the patch. Something we have to look at as a follow-up would be the Frame 'animation'. When you switch between the Home View and the Neighborhood View for example you see the Frame disappear and then the toolbar is drawn. And in general the Frame animation should really be smoother... Yes, and that makes me think, why not leave the frame open while switching zoom views? I think that would be better. The idea is to have the upper Frame section (Views and Activities) behave the same. The primary action for those should be switching between them. But after I switched the Frame should be away so I can interact with the new Zoom level/Activity I am in. I understand. So yes, for consistency's sake is ok. We should fix the toolbar appearence then. Thanks for all the feedback on this one Manuel, pushed this one as 238338d4b5d6a065eb81bd118a8c0b7ca83717bf About the Frame behavior in regards to the CP, I remember we had some discussions on that already, maybe Gary can chime in. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Neighborhood View: reveal Palette on left click/touch instead of a primary action
On 08/16/2012 02:10 PM, Manuel Quiñones wrote: 2012/8/15 Simon Schampijer : Having a primary action for the icons in the Neighborhood View like the AP icon, the Ad-hoc, the Mesh network icon and the icon for a shared activity has never been a fully working UI design because the result you get by clicking on the icon was not fully clear to the user (e.g. I clicked on the AP icon to connect to it, when I click again will it deconnect?). With the mouse you have a way of discovering secondary information by hovering over the icon, this is not as elegant with touch. You would need to use touch&hold for that but the 'failure' rate of undesired actions is much higher. In long discussions with Gary we agreed on always revealing the Palette on left-click/touch and giving the learner the information to make his choice. We think this is the best behavior for both worlds. For the SugarAdhoc Palette we make sure it has the connect option in the Palette. Until now, the Palette did only have the connect option shown when the device state had changed once. This patch applies on top of "Making the buddy icons in the Views reveal the Palette on left click or touch" Signed-off-by: Simon Schampijer Acked-by: Manuel Quiñones Thanks for the review, pushed as 682c6c2fdebb8dcc2ee16ece2330c4d840806273 Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Making the buddy icons in the Views reveal the Palette on left click or touch
On 08/16/2012 02:07 PM, Manuel Quiñones wrote: Very good Simon, 2012/8/15 Simon Schampijer : The owner icon (in the Home, Group and Neighborhood View) has no primary action. On left click we agreed to always reveal the Palette. This will give a better experience for users with a mouse/trackpad and for those with a touchscreen. This patch also changes the behavior of the buddy icons that represent other learners which appear in the Neighborhood and Group View. Here as well we do not have currently a primary action. Left click does currently not do anything. We change this to revealing the Palette on left click now as well. Nice description. I think this changes improve the mouse interaction in addition to prepare Sugar for touch. They are welcome. I'm testing them on the XO too. Signed-off-by: Simon Schampijer Acked-by: Manuel Quiñones Thanks Manuel for the review and testing, I pushed it as 071e534d44a2294ca8e27fe854a16644fc8e35d7 Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal
> > >> - the entry contains a hint (e.g. "Search in your Journal..."), adding > a placeholder text is available in GTK+3.2 [2] > > > > Nice find. The place holder text would need to vary from place to place > e.g. "Search journal", "Search neighbourhood", "Search group" [1], "Search > favourite activities", "Search all activities". > > On one hand it provides context, agreed. On the other, it adds text > in the Sugar views. I thought the magnifying glass icon was enough > metaphor. Specially in the home spiral, which is the face of Sugar, > this placeholder would be the only text in it. Not saying I'm not > open to change, just pointing this out. > > But we have a lot of reports of people confusing the activity list view in the home with the journal, may be this change helps to avoid this issue. +1 from my part. Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Frame: reveal Palette on left click for device, friends and clipboard items v2
Have to say this again: interaction with the frame elemenst is much
better and less error prone with this patch.
2012/8/19 Simon Schampijer :
> In previous design discussions we agreed on making the Palette appear
> immediately on left click. Actually some device icons like Speech or
> Speaker have been already doing this.
>
> The device icons that change to that behavior with this patch
> are: all the network items and the battery item. For the volume
> item I opened a design discussion, it can be merged into that patch
> after agreement. All the items are listening to the 'button-release-event'
> and do not propagate the event further after revealing the Palette.
>
> The Friends items behave the same as the device icons technically
> (both are TrayIcons) and UI-wise.
>
> We could think about handling the left click directly in the TrayIcon
> there are a few exceptions like the touchpad device icon and the volume
> icons which do have a primary action on left click.
>
> As well the clipboard icons will reveal now the Palette on left
> click. This is also true when selecting a clipboard item. Technically we
> have to listen to the 'button-release-event' of the child widget
> as the RadioToolButton does only emit a clicked signal. Using this
> would colide with the state changes of the clipboard items as those
> emit a signal [1]. We do let the event propagate further
> (return False) so that the state change when selecting another
> item is picked up.
>
> Signed-off-by: Simon Schampijer
Acked-by: Manuel Quiñones
> [1]
> http://developer.gnome.org/gtk3/3.4/GtkToggleToolButton.html#gtk-toggle-tool-button-set-active
>
> ---v2---
> Add bhavior for the Frame Device icon Volumes like discussed in:
Just note "bhavior" misspelling.
> http://lists.sugarlabs.org/archive/sugar-devel/2012-August/thread.html#39074
> ---
> extensions/deviceicon/battery.py | 5 +
> extensions/deviceicon/network.py | 20
> extensions/deviceicon/volume.py | 28
> src/jarabe/frame/clipboardicon.py | 7 +++
> src/jarabe/frame/friendstray.py | 5 +
> 5 files changed, 61 insertions(+), 4 deletions(-)
>
> diff --git a/extensions/deviceicon/battery.py
> b/extensions/deviceicon/battery.py
> index a70458a..5a6d99a 100644
> --- a/extensions/deviceicon/battery.py
> +++ b/extensions/deviceicon/battery.py
> @@ -70,10 +70,15 @@ class DeviceView(TrayIcon):
> self._model = DeviceModel(battery)
> self.palette = BatteryPalette(glib.markup_escape_text(_('My
> Battery')))
> self.palette.set_group_id('frame')
> +self.connect('button-release-event', self.__button_release_event_cb)
> self._model.connect('updated',
> self.__battery_status_changed_cb)
> self._update_info()
>
> +def __button_release_event_cb(self, widget, event):
> +self.palette_invoker.notify_right_click()
> +return True
> +
> def _update_info(self):
> name = _ICON_NAME
> current_level = self._model.props.level
> diff --git a/extensions/deviceicon/network.py
> b/extensions/deviceicon/network.py
> index 96713fb..ff451f4 100644
> --- a/extensions/deviceicon/network.py
> +++ b/extensions/deviceicon/network.py
> @@ -400,6 +400,7 @@ class WirelessDeviceView(ToolButton):
>self.__deactivate_connection_cb)
> self.set_palette(self._palette)
> self._palette.set_group_id('frame')
> +self.connect('clicked', self.__toolbutton_clicked_cb)
>
> self._device_props = dbus.Interface(self._device,
> dbus.PROPERTIES_IFACE)
> @@ -569,6 +570,10 @@ class WirelessDeviceView(ToolButton):
> def __activate_error_cb(self, err):
> logging.debug('Failed to create network: %s', err)
>
> +def __toolbutton_clicked_cb(self, button):
> +self.palette_invoker.notify_right_click()
> +return True
> +
>
> class OlpcMeshDeviceView(ToolButton):
> _ICON_NAME = 'network-mesh'
> @@ -600,6 +605,7 @@ class OlpcMeshDeviceView(ToolButton):
>self.__deactivate_connection)
> self.set_palette(self._palette)
> self._palette.set_group_id('frame')
> +self.connect('clicked', self.__toolbutton_clicked_cb)
>
> self.update_state(state)
>
> @@ -684,6 +690,10 @@ class OlpcMeshDeviceView(ToolButton):
> except dbus.exceptions.DBusException:
> pass
>
> +def __toolbutton_clicked_cb(self, button):
> +self.palette_invoker.notify_right_click()
> +return True
> +
>
> class WiredDeviceView(TrayIcon):
>
> @@ -701,6 +711,11 @@ class WiredDeviceView(TrayIcon):
> self.set_palette(self._palette)
> self._palette.set_group_id('frame')
> self._palette.set_connected(speed, address)
> +self.connect('button-release-event', self.__button_release_event_cb)
> +
> +def __but
Re: [Sugar-devel] [PATCH sugar] Journal: add alert to confirm before erasing an entry
2012/8/19 Simon Schampijer :
> Erasing an entry in the Journal does not ask for confirmation
> before doing the erase. This patch adds an alert to the ListView
> and the DetailView that asks for confirmation before doing the
> erase. This is part of the touch interaction work [1].
>
> Signed-off-by: Simon Schampijer
Acked-by: Manuel Quiñones
> [1] http://wiki.sugarlabs.org/go/Features/Touch/Development#Journal
> ---
> src/jarabe/journal/journaltoolbox.py | 26 --
> src/jarabe/journal/palettes.py | 17 -
> 2 files changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/src/jarabe/journal/journaltoolbox.py
> b/src/jarabe/journal/journaltoolbox.py
> index 2aa4153..5572668 100644
> --- a/src/jarabe/journal/journaltoolbox.py
> +++ b/src/jarabe/journal/journaltoolbox.py
> @@ -36,6 +36,7 @@ from sugar.graphics.combobox import ComboBox
> from sugar.graphics.menuitem import MenuItem
> from sugar.graphics.icon import Icon
> from sugar.graphics.xocolor import XoColor
> +from sugar.graphics.alert import ConfirmationAlert
> from sugar.graphics import iconentry
> from sugar.graphics import style
> from sugar import mime
> @@ -45,6 +46,7 @@ from jarabe.journal import misc
> from jarabe.journal import model
> from jarabe.journal.palettes import ClipboardMenu
> from jarabe.journal.palettes import VolumeMenu
> +from jarabe.journal import journalwindow
>
>
> _AUTOSEARCH_TIMEOUT = 1000
> @@ -438,12 +440,24 @@ class EntryToolbar(gtk.Toolbar):
>_('Error'))
>
> def _erase_button_clicked_cb(self, button):
> -registry = bundleregistry.get_registry()
> -
> -bundle = misc.get_bundle(self._metadata)
> -if bundle is not None and registry.is_installed(bundle):
> -registry.uninstall(bundle)
> -model.delete(self._metadata['uid'])
> +alert = ConfirmationAlert()
> +alert.props.title = _('Erase \"%s\"') % self._metadata['title']
> +alert.props.msg = _('This will erase the entry \"%s\"
> perminantely.') \
> +% self._metadata['title']
> +alert.connect('response', self.__erase_alert_response_cb)
> +journalwindow.get_journal_window().add_alert(alert)
> +alert.show()
> +
> +def __erase_alert_response_cb(self, alert, response_id):
> +if response_id is gtk.RESPONSE_OK:
> +journalwindow.get_journal_window().remove_alert(alert)
> +registry = bundleregistry.get_registry()
> +bundle = misc.get_bundle(self._metadata)
> +if bundle is not None and registry.is_installed(bundle):
> +registry.uninstall(bundle)
> +model.delete(self._metadata['uid'])
> +elif response_id is gtk.RESPONSE_CANCEL:
> +journalwindow.get_journal_window().remove_alert(alert)
This remove_alert() call can be moved out of the if clause, and the
elif can be removed to avoid duplication.
> def _resume_menu_item_activate_cb(self, menu_item, service_name):
> misc.resume(self._metadata, service_name)
> diff --git a/src/jarabe/journal/palettes.py b/src/jarabe/journal/palettes.py
> index 8fc1e5d..90f5dee 100644
> --- a/src/jarabe/journal/palettes.py
> +++ b/src/jarabe/journal/palettes.py
> @@ -29,6 +29,7 @@ from sugar.graphics.palette import Palette
> from sugar.graphics.menuitem import MenuItem
> from sugar.graphics.icon import Icon
> from sugar.graphics.xocolor import XoColor
> +from sugar.graphics.alert import ConfirmationAlert
> from sugar import mime
>
> from jarabe.model import friends
> @@ -36,6 +37,7 @@ from jarabe.model import filetransfer
> from jarabe.model import mimeregistry
> from jarabe.journal import misc
> from jarabe.journal import model
> +from jarabe.journal import journalwindow
>
>
> class ObjectPalette(Palette):
> @@ -142,7 +144,20 @@ class ObjectPalette(Palette):
>_('Error'))
>
> def __erase_activate_cb(self, menu_item):
> -model.delete(self._metadata['uid'])
> +alert = ConfirmationAlert()
> +alert.props.title = _('Erase \"%s\"') % self._metadata['title']
> +alert.props.msg = _('This will erase the entry \"%s\"
> perminantely.') \
> +% self._metadata['title']
> +alert.connect('response', self.__erase_alert_response_cb)
> +journalwindow.get_journal_window().add_alert(alert)
> +alert.show()
> +
> +def __erase_alert_response_cb(self, alert, response_id):
> +if response_id is gtk.RESPONSE_OK:
> +journalwindow.get_journal_window().remove_alert(alert)
> +model.delete(self._metadata['uid'])
> +elif response_id is gtk.RESPONSE_CANCEL:
> +journalwindow.get_journal_window().remove_alert(alert)
Same here. This is just styling so you can choose to push as-is, all
looks good.
> def __detail_activate_cb(self, menu_item):
> self.emit('detail-clicked', self._metadata['uid'])
> --
> 1.7.11.4
>
Re: [Sugar-devel] gst-plugins-espeak port to gstreamer 1.0
A very nice feature provided by the gstreamer espeak plugin is the signals
at the begining of the words,
useful to highlight every spoken word.
Also, is true we can use espeak with the command line, but if we can avoid
calling another process,
I think is better.
Gonzalo
On Mon, Aug 20, 2012 at 5:28 PM, Flavio Danesse <
fdane...@activitycentral.com> wrote:
> Hello, on this subject, I think it is not necessary to create a special
> plugin for sugar, you can do the same in this way:
> Check it out at: http://git.sugarlabs.org/speak/mainline
>
> class BaseAudioGrab(GObject.GObject):
> __gsignals__ = {
> 'new-buffer': (GObject.SIGNAL_RUN_FIRST,
> None, [GObject.TYPE_PYOBJECT])}
>
> def __init__(self):
> GObject.GObject.__init__(self)
> self.pipeline = None
> self._was_message = False
>
> def speak(self, status, text):
> # 175 is default value, min is 80
> rate = 60 + int(((175 - 80) * 2) * status.rate / RATE_MAX)
> wavpath = "/tmp/speak.wav"
>
> subprocess.call(["espeak", "-w", wavpath, "-p", str(status.pitch),
> "-s", str(rate), "-v", status.voice.name, text],
> stdout=subprocess.PIPE)
>
> self.stop_sound_device()
>
> self.make_pipeline(wavpath)
>
> def restart_sound_device(self):
> try:
> self.pipeline.set_state(Gst.State.NULL)
> self.pipeline.set_state(Gst.State.READY)
> self.pipeline.set_state(Gst.State.PLAYING)
> except:
> pass
>
> def stop_sound_device(self):
> if self.pipeline is None:
> return
> try:
> self.pipeline.set_state(Gst.State.NULL)
> self.pipeline.set_state(Gst.State.READY)
> self._new_buffer('')
> except:
> pass
>
> def make_pipeline(self, wavpath):
> if self.pipeline is not None:
> self.pipeline.set_state(Gst.State.NULL)
> del(self.pipeline)
>
> self.pipeline = Gst.Pipeline()
>
> file = Gst.ElementFactory.make("filesrc", "espeak")
> wavparse = Gst.ElementFactory.make("wavparse", "wavparse")
> audioconvert = Gst.ElementFactory.make("audioconvert",
> "audioconvert")
> tee = Gst.ElementFactory.make('tee', "tee")
> # FIXME: alsasink no more, pulseaudio causes:
> # gst_object_unref: assertion `((GObject *) object)->ref_count >
> 0' failed
> playsink = Gst.ElementFactory.make("playsink", "playsink")
> queue1 = Gst.ElementFactory.make("queue", "queue1")
> fakesink = Gst.ElementFactory.make("fakesink", "fakesink")
> queue2 = Gst.ElementFactory.make("queue", "queue2")
>
> self.pipeline.add(file)
> self.pipeline.add(wavparse)
> self.pipeline.add(audioconvert)
> self.pipeline.add(tee)
> self.pipeline.add(queue1)
> self.pipeline.add(playsink)
> self.pipeline.add(queue2)
> self.pipeline.add(fakesink)
>
> file.link(wavparse)
> wavparse.link(tee)
>
> tee.link(queue1)
> queue1.link(audioconvert)
> audioconvert.link(playsink)
>
> tee.link(queue2)
> queue2.link(fakesink)
>
> file.set_property("location", wavpath)
>
> fakesink.set_property('signal-handoffs', True)
> fakesink.set_property('dump', True)
> fakesink.connect('handoff', self.on_buffer)
>
> self._was_message = False
> bus = self.pipeline.get_bus()
> bus.add_signal_watch()
> bus.connect('message', self.gstmessage_cb)
>
> self.pipeline.set_state(Gst.State.PLAYING)
>
> def gstmessage_cb(self, bus, message):
> self._was_message = True
>
> if message.type == Gst.MessageType.WARNING:
> def check_after_warnings():
> if not self._was_message:
> self.stop_sound_device()
> return True
>
> logger.debug(message.type)
> self._was_message = False
> GObject.timeout_add(500, self._new_buffer, str(buffer))
>
> elif message.type == Gst.MessageType.EOS:
> self.pipeline.set_state(Gst.State.NULL)
>
> elif message.type == Gst.MessageType.ERROR:
> err, debug = message.parse_error()
> logger.debug(err)
> self.stop_sound_device()
>
> def on_buffer(self, element, buffer, pad):
> GObject.timeout_add(100, self._new_buffer, str(buffer))
> return True
>
> def _new_buffer(self, buf):
> self.emit("new-buffer", buf)
> return False
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] gst-plugins-espeak port to gstreamer 1.0
On Mon, Aug 20, 2012 at 05:28:04PM -0300, Flavio Danesse wrote: > Hello, on this subject, I think it is not necessary to create a special > plugin for sugar, Sorry, what kind of plugins you mean? > you can do the same in this way: > Check it out at: http://git.sugarlabs.org/speak/mainline There are also gst-plugins-espeak examples on wiki, http://wiki.sugarlabs.org/go/Activity_Team/gst-plugins-espeak#Python_examples -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is there a way to purposefully do synchronous GUI updates?
On Tue, Aug 21, 2012 at 12:11:13AM +0530, Ajay Garg wrote: > So, is there a way to have the code always in-order; in other words, > have the GUI updates absolutely synchronous? No, not without waiting for the update to complete, and if you do this, the code runs very slowly. (When there is only one CPU, only one process can execute on it at a time. The updates are placed in a pipeline to the display, and the display process runs them as soon as it is practical to do so. If your process does not release the CPU, then your process will likely continue executing until it hits something that will cause it to release. It is better to be specific and use idle_add to release.) -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Journal: confirmation before erasing/duplicating an entry
2012/8/19 Simon Schampijer : > Hi, > > I have been working on the confirmation alert for the Journal, submitted a > patch [1]. > > "Erasing an entry in the Journal does not ask for confirmation > before doing the erase. This patch adds an alert to the ListView > and the DetailView that asks for confirmation before doing the > erase. This is part of the touch interaction work [2]". > > I think the need is clear, I just want to confirm the wording of the message > and title. "This will erase the object..." can also work, but I think "This will erase the entry..." works better. > About the alert for the duplication. I am not 100% convinced it is needed. +1 to not add an alert in duplication too. > There is not much harm in duplicating an entry (unless it is really big). I > try to avoid confirmation alerts when possible. I think the only thing which > is critical is feedback in that case. In the ListView the feedback is given. > Duplicating an entry in the DetailView lacks a bit the feedback what has > happened. Long term an animation would be nice here. Short term options that > would help giving feedback here (please not an alert:)? What about a message "duplicating entry..." that dissapears in a few seconds? Yes, is an alert :) but without Accept/Cancel buttons. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal
2012/8/20 Gary Martin : > Hi Simon, > > On 20 Aug 2012, at 12:56, Simon Schampijer wrote: > >> Hi, >> >> I have been thinking a bit about how we can enhance the interaction with the >> search entries in the Shell so they will work well in touch as well [1]. >> >> When you have a touchscreen device focusing an entry will automatically >> bring up the onscreen keyboard (OSK). We are currently doing this in the >> Home View/Neighborhood View and in the Journal. For keyboard devices this >> makes absolute sense, having first to move the pointer towards the entry, >> click on it before you can type in the search is a too long interaction. >> With a touch interface however it is ok to touch the search field to bring >> up the OSK in most of the cases. Otherwise the OSK might cover parts of the >> screen without need. >> >> I would suggest the following new behavior: >> >> - the entry is unfocused by default, the canvas is focused > > +1 > >> - the entry contains a hint (e.g. "Search in your Journal..."), adding a >> placeholder text is available in GTK+3.2 [2] > > Nice find. The place holder text would need to vary from place to place e.g. > "Search journal", "Search neighbourhood", "Search group" [1], "Search > favourite activities", "Search all activities". On one hand it provides context, agreed. On the other, it adds text in the Sugar views. I thought the magnifying glass icon was enough metaphor. Specially in the home spiral, which is the face of Sugar, this placeholder would be the only text in it. Not saying I'm not open to change, just pointing this out. >> - when the user starts typing the entry is focused automatically (listening >> on the canvas and switching focus) > > +1 +1 this is indeed a better behaviour. Testing the OSK it becomes obvious that autofocus the entry should not be the default for touch mode. > >> I think this will give a good behavior for both worlds. > > Yes, agreed. The search placeholder text also provides additional context > indicating which view you might be in. At one point we discussed the > possibility of adding each zoom view icon to each view's toolbar to improve > context, but that design wasn't complete, the search placeholder text would > be a step in that direction. > > Regards, > --Gary > > [1] The Group view still doesn't have a minimal toolbar or search facilities > ;) > >> I have attached as well a GTK+ 3 example. Let me know what you think. >> >> Regards, >> Simon >> >> [1] >> http://wiki.sugarlabs.org/go/Features/Touch/Development#Reveal_on_text_input_focus.2C_auto_.2A.2Adismiss.2A.2A_on_loss_of_focus >> [2] >> http://developer.gnome.org/gtk3/3.4/GtkEntry.html#gtk-entry-set-placeholder-text >> >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] gst-plugins-espeak port to gstreamer 1.0
Hello, on this subject, I think it is not necessary to create a special
plugin for sugar, you can do the same in this way:
Check it out at: http://git.sugarlabs.org/speak/mainline
class BaseAudioGrab(GObject.GObject):
__gsignals__ = {
'new-buffer': (GObject.SIGNAL_RUN_FIRST,
None, [GObject.TYPE_PYOBJECT])}
def __init__(self):
GObject.GObject.__init__(self)
self.pipeline = None
self._was_message = False
def speak(self, status, text):
# 175 is default value, min is 80
rate = 60 + int(((175 - 80) * 2) * status.rate / RATE_MAX)
wavpath = "/tmp/speak.wav"
subprocess.call(["espeak", "-w", wavpath, "-p", str(status.pitch),
"-s", str(rate), "-v", status.voice.name, text],
stdout=subprocess.PIPE)
self.stop_sound_device()
self.make_pipeline(wavpath)
def restart_sound_device(self):
try:
self.pipeline.set_state(Gst.State.NULL)
self.pipeline.set_state(Gst.State.READY)
self.pipeline.set_state(Gst.State.PLAYING)
except:
pass
def stop_sound_device(self):
if self.pipeline is None:
return
try:
self.pipeline.set_state(Gst.State.NULL)
self.pipeline.set_state(Gst.State.READY)
self._new_buffer('')
except:
pass
def make_pipeline(self, wavpath):
if self.pipeline is not None:
self.pipeline.set_state(Gst.State.NULL)
del(self.pipeline)
self.pipeline = Gst.Pipeline()
file = Gst.ElementFactory.make("filesrc", "espeak")
wavparse = Gst.ElementFactory.make("wavparse", "wavparse")
audioconvert = Gst.ElementFactory.make("audioconvert",
"audioconvert")
tee = Gst.ElementFactory.make('tee', "tee")
# FIXME: alsasink no more, pulseaudio causes:
# gst_object_unref: assertion `((GObject *) object)->ref_count > 0'
failed
playsink = Gst.ElementFactory.make("playsink", "playsink")
queue1 = Gst.ElementFactory.make("queue", "queue1")
fakesink = Gst.ElementFactory.make("fakesink", "fakesink")
queue2 = Gst.ElementFactory.make("queue", "queue2")
self.pipeline.add(file)
self.pipeline.add(wavparse)
self.pipeline.add(audioconvert)
self.pipeline.add(tee)
self.pipeline.add(queue1)
self.pipeline.add(playsink)
self.pipeline.add(queue2)
self.pipeline.add(fakesink)
file.link(wavparse)
wavparse.link(tee)
tee.link(queue1)
queue1.link(audioconvert)
audioconvert.link(playsink)
tee.link(queue2)
queue2.link(fakesink)
file.set_property("location", wavpath)
fakesink.set_property('signal-handoffs', True)
fakesink.set_property('dump', True)
fakesink.connect('handoff', self.on_buffer)
self._was_message = False
bus = self.pipeline.get_bus()
bus.add_signal_watch()
bus.connect('message', self.gstmessage_cb)
self.pipeline.set_state(Gst.State.PLAYING)
def gstmessage_cb(self, bus, message):
self._was_message = True
if message.type == Gst.MessageType.WARNING:
def check_after_warnings():
if not self._was_message:
self.stop_sound_device()
return True
logger.debug(message.type)
self._was_message = False
GObject.timeout_add(500, self._new_buffer, str(buffer))
elif message.type == Gst.MessageType.EOS:
self.pipeline.set_state(Gst.State.NULL)
elif message.type == Gst.MessageType.ERROR:
err, debug = message.parse_error()
logger.debug(err)
self.stop_sound_device()
def on_buffer(self, element, buffer, pad):
GObject.timeout_add(100, self._new_buffer, str(buffer))
return True
def _new_buffer(self, buf):
self.emit("new-buffer", buf)
return False
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] conversations about sugar ui design
"We have an opportunity in Peru to do some experiments." - WB Hi David, As a member of the Somos Azucar research & development team and direct responsible for the software distribution prototypes to be piloted in Peru, I warmly welcome your constructive offer of help. We (Laura and I) are responsible for the Sugar Network sketches presented to you by Aleksey, who is doing the back-end implementation to support specific functionality. It is important to underline that the Sugar Network client (webui) is an experimental intervention that hopes to facilitate knowledge exchange within an initial environment (Sugar and Sugar Activities in Perú). Of course, there are a wide set of constraints (**). You can find more information about the Sugar Network project as it is being implemented for Perú at: http://pe.sugarlabs.org/go/Red_Az%C3%BAcar Specific goals of the system are: to provide a de-centralized network for feedback, support and learning resources exchange and distribution. The current UI implementation is expected to evolve quickly and our goal is to have a 1.0 release by December 2012 with main functionality. The UI dev strategy has been to rely on standard HTML+CSS+JS in order to facilitate rapid UI experimentation by the widest possible group of people including ourselves. So far we've sought to directly expose functionality, trying to follow Sugar's UI style and paradigms of simplicity, reflection and collaboration. However we are at a stage of reflection into how to better expose functionality to reflect the system's stated goals to the local community. As for a design forum, Sugar Network is hoped to become such a forum where feedback can be collected with the purpose of improving specific system components (for example, Sugar itself). Your feedback / proposals for improving the Sugar Network experience are welcome and will be taken into consideration. I recommend installing Sugar Network locally from the sweets-desktop packages for you to be able to explore functionality specific to Sugar. Regards, Sebastian (**) most notable constraints in no particular order: - (almost) no connectivity - slow hardware / crappy touchpads - language/cultural barrier - remote locations - not skilled deployment personnel - disreputed laptop project - conflicted national education system On Mon, 20 Aug 2012 13:56:39 +1000 David Brown wrote: > this note embraces several different emails from >Aleksey and > > > What you see on http://network-testing.sugarlabs.org > > is a first rough and implementation for webui, > > you have put quite some effort into presenting your sketches, Aleksey: > whilst that is in itself impressive, i'm not keen on the sketches > themselves: using icons instead of words is presumably an attempt to > make the ui accessible to the illiterate, but in my view it only > complicates matters. icons would be effective if they were > universally obvious a priori, but that is not possible - icons have to > be learned just as do the symbols of any alphabet. mother tongue is > preferable, as it contributes to the learning of literacy useful in > the broader context of the language world within which they live. a > single release of a ui could have a feature that allows the ui to be > displayed in any of the languages that have been implemented. > > the choices of names are developer-oriented rather than user-oriented: > for example, the name "turtle-art" makes sense only to people who are > already familiar with Logo. Whereas, "draw a picture" (or its > translation) would make sense to any kid who can read her mother > tongue. for those who can't read, a thumbnail of a half-finished > painting and a brush might work - it would take up more pixels than an > icon, but i don't think there should be many app-triggers on view at > the same time. > > with 69 apps already mooted (and presumably a thousand more waiting to > be added), that creates a navigation issue which needs to be > addressed. i feel that it could be done by creating categories of > activity (such as "learn", "play" and "meet") and subcategories etc, > making a simple tree structure (or maybe a network with cross-links). > the one thing i am sure of is that trying to put buttons for > everything on one screen creates information overload. > -- Sebastian Silva ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Is there a way to purposefully do synchronous GUI updates?
Hi all. I frequently happen to encounter cases, where GUI updates do not happen in the in-order manner. For eg, if the code is on the lines :: logic statement 1 update GUI logic statement 2 the actual procedure that happens is :: logic statement 1 logic statement 2 update GUI However, if I do something like logic statement 1 update GUI gobject.idle_add(logic statement 2) the procedure now runs in in-order. The above is not a problem for such trivial cases, but it IS a problem, when we want to have seemingly in-order GUI updates, when the code runs deep. So, is there a way to have the code always in-order; in other words, have the GUI updates absolutely synchronous? WIll be grateful for a reply. Thanks and Regards, Ajay ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] SpreadLayout: do not remove items from the grid if there is none yet, SL #3814
On 08/20/2012 05:45 PM, Manuel Quiñones wrote: Good fix. I was seeing this issue of not initialized grid in the shell port too. 2012/8/19 Simon Schampijer : A grid is added to the ViewContainer when the children are allocated, we can not do it earlier because we need to pass the allocation details. The allocation happens when the children needs to be shown. Therefore if the container and it's children have not been shown yet, removing the child from the grid would fail. This patch does check if a grid exists already before trying to remove items from it. Signed-off-by: Simon Schampijer Acked-by: Manuel Quiñones Thanks for the quick review. Pushed, is part of the 'no-hippo' release 0.97.1. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-0.97.1
The 'no-hippo' release. == Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.97.1.tar.bz2 == News == * Release 0.97.1 (Simon Schampijer) * SpreadLayout: do not remove items from the grid if there is none yet, SL #3814 (Simon Schampijer) * Use the gdk window to get the depth of the preview pixmap - SL#3804 (Manuel Quiñones) * Debug log before and after running ssh-keygen (Daniel Narvaez) * Journal, no-hippo: set white background for no-matching-entry message, SL #3808 (Simon Schampijer) * Update Sucrose version for upcoming 0.97.1 (Simon Schampijer) * Drop unused intro.py (Daniel Narvaez) * Remove hippo mentions (Daniel Narvaez) * Views: Replace the hippo based layout with one using GTK+ containers (Simon Schampijer, Manuel Quiñones, Daniel Drake, Walter Bender, Raul Gutierrez Segales) * ControlPanel AboutMe section: use the EventIcon from the shell (Simon Schampijer) * SugarEventIcon: Add a hippo-free implementation of the CanvasIcon (Simon Schampijer) * Allow to build outside the source directory (Daniel Narvaez) * Commit from Sugar Labs: Translation System by user cjl.: 5 of 387 messages translated (33 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 358 of 387 messages translated (14 fuzzy). (Pootle daemon) * Drop obsolete and non-functional sugar-ui-check script (Daniel Narvaez) * Enable gnome-keyring-daemon to start inside emulated session (Daniel Narvaez) * Commit from Sugar Labs: Translation System by user cjl.: 285 of 387 messages translated (14 fuzzy). (Pootle daemon) * post-branch catch up, Pushing many PO files (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 93 of 387 messages translated (5 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 50 of 387 messages translated (19 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 152 of 387 messages translated (9 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 188 of 387 messages translated (46 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 0 of 387 messages translated (43 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 258 of 387 messages translated (9 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 260 of 389 messages translated (9 fuzzy). (Pootle daemon) * sugar-session: disable Metacity mouse button modifiers, OLPC #11781 (Daniel Drake) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 212 of 389 messages translated (4 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 183 of 387 messages translated (4 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages translated (0 fuzzy). (Pootle daemon) * Push many PO files (Pootle daemon) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing Rotate in sugar-jhbuild
On Mon, Aug 20, 2012 at 12:25 PM, Gary Martin wrote: > Hi Walter, > > On 20 Aug 2012, at 00:57, Walter Bender wrote: > >> On Thu, Aug 16, 2012 at 5:27 PM, Gary Martin >> wrote: >>> Hi Walter, >>> >>> >>> On 16 Aug 2012, at 16:53, Walter Bender wrote: >>> >>> On Thu, Aug 16, 2012 at 11:36 AM, Gonzalo Odiard wrote: >>> >>> In anybody want test how activities work with the screen rotated in >>> >>> sugar-jhbuid, >>> >>> can do in the terminal: >>> >>> >>> xrandr -o left >>> >>> >>> when your neck hurts, or you have finished... >>> >>> >>> xrandr -o normal >>> >>> >>> Gonzalo >>> >>> >>> ___ >>> >>> Sugar-devel mailing list >>> >>> Sugar-devel@lists.sugarlabs.org >>> >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >>> >>> >>> Works great. Check out >>> http://wiki.sugarlabs.org/images/c/cb/Portfolio-27.xo which support >>> rotation. But I am curious why the stop button runs off the edge... it >>> would appear there is plenty of room for it. >>> >>> >>> Not sure if this is your issue (my land line has been down most of the day >>> and am on GSM network), but invisible separators still take space unless you >>> explicitly tell them not to: >>> >>>separator.set_size_request(0, -1) >>> >>> So your separator factory might need a tweak. See Physics activity.py line >>> 103 for a working example. >>> >>> Regards, >>> --Gary >>> >>> >>> -walter >>> >>> -- >>> Walter Bender >>> Sugar Labs >>> http://www.sugarlabs.org >>> ___ >>> Sugar-devel mailing list >>> Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> I've been thinking for quite some time that we need a new approach to >> the problem of toolbar items following off the end of the toolbar This >> problem will be greatly exacerbated by the more frequent use of screen >> rotate one would expect with more use of tablet mode on XO 4.0 Touch. >> Most activities have not taken into account the potential squeezing of >> the toolbar by 25% even of they take into consideration general >> resizing of the screen due to rotation. > > I know this is a tough line to take, but we should file tickets against > activities that overflow in portrait orientation – that includes Physics and > Calculate ;) > > It is quite an effort making a complicated multi-function Activity appear > simple, but letting activity developers off the hook to pile on features > without keeping their UI under control seems like a loosing direction to > take. Max ten icons in the toolbar (that includes the Activity toolbar icon > and the Stop toolbar icon). We've had decent sub-toolbar support in Sugar for > a long time now, lets make sure we prioritising that primary tool bar space > and putting the less used features into secondary toolbars. > > Regards, > --Gary > >> A simple solution would be to double the vertical size of the toolbar >> and wrap the icons onto a second row. >> >> comments? >> >> -walter >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org > OK. I can accept that decision, but I expect that many many activities will have to change (including all the Turtle Art variants). -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing Rotate in sugar-jhbuild
Hi Walter, On 20 Aug 2012, at 00:57, Walter Bender wrote: > On Thu, Aug 16, 2012 at 5:27 PM, Gary Martin > wrote: >> Hi Walter, >> >> >> On 16 Aug 2012, at 16:53, Walter Bender wrote: >> >> On Thu, Aug 16, 2012 at 11:36 AM, Gonzalo Odiard wrote: >> >> In anybody want test how activities work with the screen rotated in >> >> sugar-jhbuid, >> >> can do in the terminal: >> >> >> xrandr -o left >> >> >> when your neck hurts, or you have finished... >> >> >> xrandr -o normal >> >> >> Gonzalo >> >> >> ___ >> >> Sugar-devel mailing list >> >> Sugar-devel@lists.sugarlabs.org >> >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> >> >> Works great. Check out >> http://wiki.sugarlabs.org/images/c/cb/Portfolio-27.xo which support >> rotation. But I am curious why the stop button runs off the edge... it >> would appear there is plenty of room for it. >> >> >> Not sure if this is your issue (my land line has been down most of the day >> and am on GSM network), but invisible separators still take space unless you >> explicitly tell them not to: >> >>separator.set_size_request(0, -1) >> >> So your separator factory might need a tweak. See Physics activity.py line >> 103 for a working example. >> >> Regards, >> --Gary >> >> >> -walter >> >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > I've been thinking for quite some time that we need a new approach to > the problem of toolbar items following off the end of the toolbar This > problem will be greatly exacerbated by the more frequent use of screen > rotate one would expect with more use of tablet mode on XO 4.0 Touch. > Most activities have not taken into account the potential squeezing of > the toolbar by 25% even of they take into consideration general > resizing of the screen due to rotation. I know this is a tough line to take, but we should file tickets against activities that overflow in portrait orientation – that includes Physics and Calculate ;) It is quite an effort making a complicated multi-function Activity appear simple, but letting activity developers off the hook to pile on features without keeping their UI under control seems like a loosing direction to take. Max ten icons in the toolbar (that includes the Activity toolbar icon and the Stop toolbar icon). We've had decent sub-toolbar support in Sugar for a long time now, lets make sure we prioritising that primary tool bar space and putting the less used features into secondary toolbars. Regards, --Gary > A simple solution would be to double the vertical size of the toolbar > and wrap the icons onto a second row. > > comments? > > -walter > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] SpreadLayout: do not remove items from the grid if there is none yet, SL #3814
Good fix. I was seeing this issue of not initialized grid in the shell port too. 2012/8/19 Simon Schampijer : > A grid is added to the ViewContainer when the children > are allocated, we can not do it earlier because we need to > pass the allocation details. The allocation happens when > the children needs to be shown. Therefore if the container > and it's children have not been shown yet, removing the > child from the grid would fail. > > This patch does check if a grid exists already before trying > to remove items from it. > > Signed-off-by: Simon Schampijer Acked-by: Manuel Quiñones > --- > src/jarabe/desktop/favoriteslayout.py | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/src/jarabe/desktop/favoriteslayout.py > b/src/jarabe/desktop/favoriteslayout.py > index 0f63f95..e0ee80e 100644 > --- a/src/jarabe/desktop/favoriteslayout.py > +++ b/src/jarabe/desktop/favoriteslayout.py > @@ -150,6 +150,11 @@ class SpreadLayout(ViewLayout): > ViewLayout.__init__(self) > > def remove(self, child): > +if self._grid is None: > +# the Grid is created during allocation time, so it might not > +# exist yet when this method is called, SL #3814 > +return > + > if self._grid.is_in_grid(child): > self._grid.remove(child) > > -- > 1.7.11.4 > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Call For Proposals: OLPC SF Community Summit 2012
OLPC-SF has opened proposal submission for the 2012 Community Summit held in San Francisco, California during the weekend of October 19th-21st. Submission form here: http://olpcsf.org/submit-proposal-2012 Workshops range from topics in Technology to Education to Outreach and are generally in the range of 60-75 minutes. Group organized workshops are also encouraged. You can read more about proposal submission on our blog: http://olpcsf.org/node/66 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing Rotate in sugar-jhbuild
2012/8/19 Gonzalo Odiard : >> >> I've been thinking for quite some time that we need a new approach to >> the problem of toolbar items following off the end of the toolbar This >> problem will be greatly exacerbated by the more frequent use of screen >> rotate one would expect with more use of tablet mode on XO 4.0 Touch. >> Most activities have not taken into account the potential squeezing of >> the toolbar by 25% even of they take into consideration general >> resizing of the screen due to rotation. >> >> A simple solution would be to double the vertical size of the toolbar >> and wrap the icons onto a second row. >> >> comments? > > > It's a really good question. > I am thinking another: We really need rotate the toolbar? > May be had more sense when the old toolbar had text in the tabs... > Is very difficult design a interface making good use of the toolbar size, > and have a option were the toolbar have half the size. > Not all the activities have this problem, but if have more than six buttons, > probably yes. > > Maybe we can use the toolbar vertical, in the long side of the screen, > and rotate the icons and the palettes. > The problem with this approach are the activities with wide widgets in the > toolbars. I don't think this is an option as we have text entries. For example always for the title, in the main toolbar or in the activity sobtoolbar. I've seen that rotate icons toolbars for example in the android while taking photos, but that's a icons-only toolbar. > Another option is have the option of inhibit rotate in a activity, > but is not so easy, what happen when the user switch activities? -1 to inhibit rotate, this is an overall feature.of Sugar. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal
Hi Simon, On 20 Aug 2012, at 12:56, Simon Schampijer wrote: > Hi, > > I have been thinking a bit about how we can enhance the interaction with the > search entries in the Shell so they will work well in touch as well [1]. > > When you have a touchscreen device focusing an entry will automatically bring > up the onscreen keyboard (OSK). We are currently doing this in the Home > View/Neighborhood View and in the Journal. For keyboard devices this makes > absolute sense, having first to move the pointer towards the entry, click on > it before you can type in the search is a too long interaction. With a touch > interface however it is ok to touch the search field to bring up the OSK in > most of the cases. Otherwise the OSK might cover parts of the screen without > need. > > I would suggest the following new behavior: > > - the entry is unfocused by default, the canvas is focused +1 > - the entry contains a hint (e.g. "Search in your Journal..."), adding a > placeholder text is available in GTK+3.2 [2] Nice find. The place holder text would need to vary from place to place e.g. "Search journal", "Search neighbourhood", "Search group" [1], "Search favourite activities", "Search all activities". > - when the user starts typing the entry is focused automatically (listening > on the canvas and switching focus) +1 > I think this will give a good behavior for both worlds. Yes, agreed. The search placeholder text also provides additional context indicating which view you might be in. At one point we discussed the possibility of adding each zoom view icon to each view's toolbar to improve context, but that design wasn't complete, the search placeholder text would be a step in that direction. Regards, --Gary [1] The Group view still doesn't have a minimal toolbar or search facilities ;) > I have attached as well a GTK+ 3 example. Let me know what you think. > > Regards, > Simon > > [1] > http://wiki.sugarlabs.org/go/Features/Touch/Development#Reveal_on_text_input_focus.2C_auto_.2A.2Adismiss.2A.2A_on_loss_of_focus > [2] > http://developer.gnome.org/gtk3/3.4/GtkEntry.html#gtk-entry-set-placeholder-text > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Testing Rotate in sugar-jhbuild
2012/8/19 Walter Bender : > On Thu, Aug 16, 2012 at 5:27 PM, Gary Martin > wrote: >> Hi Walter, >> >> >> On 16 Aug 2012, at 16:53, Walter Bender wrote: >> >> On Thu, Aug 16, 2012 at 11:36 AM, Gonzalo Odiard wrote: >> >> In anybody want test how activities work with the screen rotated in >> >> sugar-jhbuid, >> >> can do in the terminal: >> >> >> xrandr -o left >> >> >> when your neck hurts, or you have finished... >> >> >> xrandr -o normal >> >> >> Gonzalo >> >> >> ___ >> >> Sugar-devel mailing list >> >> Sugar-devel@lists.sugarlabs.org >> >> http://lists.sugarlabs.org/listinfo/sugar-devel >> >> >> >> Works great. Check out >> http://wiki.sugarlabs.org/images/c/cb/Portfolio-27.xo which support >> rotation. But I am curious why the stop button runs off the edge... it >> would appear there is plenty of room for it. >> >> >> Not sure if this is your issue (my land line has been down most of the day >> and am on GSM network), but invisible separators still take space unless you >> explicitly tell them not to: >> >> separator.set_size_request(0, -1) >> >> So your separator factory might need a tweak. See Physics activity.py line >> 103 for a working example. >> >> Regards, >> --Gary >> >> >> -walter >> >> -- >> Walter Bender >> Sugar Labs >> http://www.sugarlabs.org >> ___ >> Sugar-devel mailing list >> Sugar-devel@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > I've been thinking for quite some time that we need a new approach to > the problem of toolbar items following off the end of the toolbar This > problem will be greatly exacerbated by the more frequent use of screen > rotate one would expect with more use of tablet mode on XO 4.0 Touch. > Most activities have not taken into account the potential squeezing of > the toolbar by 25% even of they take into consideration general > resizing of the screen due to rotation. +1 I think this should be solved somehow, is not easy. > A simple solution would be to double the vertical size of the toolbar > and wrap the icons onto a second row. Yeah but how the subtoolbars and the icons that toggles them would look in this case? -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse
2012/8/20 Simon Schampijer : > On 08/20/2012 04:44 PM, Manuel Quiñones wrote: >> >> 2012/8/17 Simon Schampijer : >>> >>> On 08/17/2012 12:48 AM, Manuel Quiñones wrote: I've tested an earlier patch for this and now I reviewed it. This is a much more solid interaction with the frame, and less error prone. All looks good. Please commit. >>> >>> >>> >>> Thanks Manuel for testing and the review. I have fixed the 'cycling >>> through >>> activities' in v2 of the patch. >>> >>> Something we have to look at as a follow-up would be the Frame >>> 'animation'. >>> When you switch between the Home View and the Neighborhood View for >>> example >>> you see the Frame disappear and then the toolbar is drawn. And in general >>> the Frame animation should really be smoother... >> >> >> Yes, and that makes me think, why not leave the frame open while >> switching zoom views? I think that would be better. >> > > The idea is to have the upper Frame section (Views and Activities) behave > the same. The primary action for those should be switching between them. But > after I switched the Frame should be away so I can interact with the new > Zoom level/Activity I am in. I understand. So yes, for consistency's sake is ok. We should fix the toolbar appearence then. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Port the gstreamer code to pygi
2012/8/18 Daniel Narvaez : > Feel free to ignore this, I pushed it on the manuqs-erikos-shell-port > branch. I think the idea everything will be posted for review here as > soon as the port is in good shape. Yes, thanks for pushing it and help with the shell port :) Added your name to http://wiki.sugarlabs.org/go/Features/GTK3/Shell#Done -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse
On 08/20/2012 04:44 PM, Manuel Quiñones wrote: 2012/8/17 Simon Schampijer : On 08/17/2012 12:48 AM, Manuel Quiñones wrote: I've tested an earlier patch for this and now I reviewed it. This is a much more solid interaction with the frame, and less error prone. All looks good. Please commit. Thanks Manuel for testing and the review. I have fixed the 'cycling through activities' in v2 of the patch. Something we have to look at as a follow-up would be the Frame 'animation'. When you switch between the Home View and the Neighborhood View for example you see the Frame disappear and then the toolbar is drawn. And in general the Frame animation should really be smoother... Yes, and that makes me think, why not leave the frame open while switching zoom views? I think that would be better. The idea is to have the upper Frame section (Views and Activities) behave the same. The primary action for those should be switching between them. But after I switched the Frame should be away so I can interact with the new Zoom level/Activity I am in. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Gio.VolumeMonitor.get() crash
2012/8/18 Daniel Narvaez : > As mentioned on the wiki shell port page, calling > Gio.VolumeMonitor.get() inside sugar was causing a segfault. > > I found this was due to the fact that we was mixing statinc and > dynamic bindings by importing gst. Now I added the gstreamer 1.0 port > of gst-plugins-espeak to sugar-build and posted a patch to port sugar > to use pygi for gstreamer. With these changes journal_gtk3-2.patch > doesn't crash anymore. Daniel, thank you very much! I was looking for the faulty import, grepping the code, but couldn't find it. Thanks! -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse
2012/8/17 Simon Schampijer
>
> After discussing with Gary I prepared this patch to change the
> interaction with the Frame in the following manner:
>
> - you can reveal the Frame by going with the cursor in one of the
> hot corners
>
> - you can hide the Frame by going with the cursor in one of the
> hot corners (and the Frame is visible)
>
> - the Frame is not hidden on mouse out (leaving the Frame)
>
> - (as before) you can hide/reveal the Frame with the designated keys
>
> - the Frame is hidden when you switch between activities
> (todo: hide as well when resume in the Palette is clicked)
>
> - the Frame is hidden when a zoom level is selected
As I suggested, maybe leave the frame open whle switching zoom views?
> - (as before) you can use 'alt-tab' to cycle through the
> running activities
>
> - drag & drop is currently not working, SL #3811
>
> v2: fixed cycling through running activities
Tested, works as expected.
Another thing to think is the frame in relation with the Control
Panel. I think the frame should be hidden when the control panel is
opened.
> Signed-off-by: Simon Schampijer
> ---
> src/jarabe/frame/activitiestray.py | 2 ++
> src/jarabe/frame/frame.py | 53
> ++
> src/jarabe/frame/zoomtoolbar.py| 6 +
> src/jarabe/view/tabbinghandler.py | 2 +-
> 4 files changed, 22 insertions(+), 41 deletions(-)
>
> diff --git a/src/jarabe/frame/activitiestray.py
> b/src/jarabe/frame/activitiestray.py
> index 9590bce..d386b3b 100644
> --- a/src/jarabe/frame/activitiestray.py
> +++ b/src/jarabe/frame/activitiestray.py
> @@ -287,6 +287,8 @@ class ActivitiesTray(HTray):
> window = home_activity.get_window()
> if window:
> window.activate(gtk.get_current_event_time())
> +frame = jarabe.frame.get_view()
> +frame.hide()
>
> def __remove_invite_cb(self, icon, invite):
> self._invites.remove_invite(invite)
> diff --git a/src/jarabe/frame/frame.py b/src/jarabe/frame/frame.py
> index 7407e18..ee112a1 100644
> --- a/src/jarabe/frame/frame.py
> +++ b/src/jarabe/frame/frame.py
> @@ -57,29 +57,12 @@ class _Animation(animator.Animation):
> class _MouseListener(object):
> def __init__(self, frame):
> self._frame = frame
> -self._hide_sid = 0
>
> def mouse_enter(self):
> -self._show_frame()
> -
> -def mouse_leave(self):
> -if self._frame.mode == Frame.MODE_MOUSE:
> -self._hide_frame()
> -
> -def _show_frame(self):
> -if self._hide_sid != 0:
> -gobject.source_remove(self._hide_sid)
> -self._frame.show(Frame.MODE_MOUSE)
> -
> -def _hide_frame_timeout_cb(self):
> -self._frame.hide()
> -return False
> -
> -def _hide_frame(self):
> -if self._hide_sid != 0:
> -gobject.source_remove(self._hide_sid)
> -self._hide_sid = gobject.timeout_add(
> - _FRAME_HIDING_DELAY, self._hide_frame_timeout_cb)
> +if self._frame.visible:
> +self._frame.hide()
> +else:
> +self._frame.show()
>
>
> class _KeyListener(object):
> @@ -88,23 +71,16 @@ class _KeyListener(object):
>
> def key_press(self):
> if self._frame.visible:
> -if self._frame.mode == Frame.MODE_KEYBOARD:
> -self._frame.hide()
> +self._frame.hide()
> else:
> -self._frame.show(Frame.MODE_KEYBOARD)
> +self._frame.show()
>
>
> class Frame(object):
> -MODE_MOUSE = 0
> -MODE_KEYBOARD = 1
> -MODE_NON_INTERACTIVE = 2
> -
> def __init__(self):
> logging.debug('STARTUP: Loading the frame')
> -self.mode = None
>
> self._palette_group = palettegroup.get_group('frame')
> -self._palette_group.connect('popdown',
> self._palette_group_popdown_cb)
>
> self._left_panel = None
> self._right_panel = None
> @@ -143,6 +119,9 @@ class Frame(object):
> visible = property(is_visible, None)
>
> def hide(self):
> +if not self.visible:
> +return
> +
> if self._animator:
> self._animator.stop()
>
> @@ -150,16 +129,12 @@ class Frame(object):
> self._animator.add(_Animation(self, 0.0))
> self._animator.start()
>
> -self.mode = None
> -
> -def show(self, mode):
> +def show(self):
> if self.visible:
> return
> if self._animator:
> self._animator.stop()
>
> -self.mode = mode
> -
> self._animator = animator.Animator(0.5)
> self._animator.add(_Animation(self, 1.0))
> self._animator.start()
> @@ -180,6 +155,7 @@ class Frame(object):
> zoom_toolbar = ZoomToolbar()
> panel.append(zoom_toolbar, expand=False)
> zoom_toolbar.show()
> +zoom_toolbar.connect('level-clicked', self._level_clicked_cb)
>
> activit
Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse
2012/8/17 Simon Schampijer : > On 08/17/2012 12:48 AM, Manuel Quiñones wrote: >> >> I've tested an earlier patch for this and now I reviewed it. This is >> a much more solid interaction with the frame, and less error prone. >> >> All looks good. Please commit. > > > Thanks Manuel for testing and the review. I have fixed the 'cycling through > activities' in v2 of the patch. > > Something we have to look at as a follow-up would be the Frame 'animation'. > When you switch between the Home View and the Neighborhood View for example > you see the Frame disappear and then the toolbar is drawn. And in general > the Frame animation should really be smoother... Yes, and that makes me think, why not leave the frame open while switching zoom views? I think that would be better. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] conversations about sugar ui design
On Sun, Aug 19, 2012 at 11:56 PM, David Brown wrote: > this note embraces several different emails from >Aleksey and > >> What you see on http://network-testing.sugarlabs.org >> is a first rough and implementation for webui, > > you have put quite some effort into presenting your sketches, Aleksey: > whilst that is in itself impressive, i'm not keen on the sketches > themselves: using icons instead of words is presumably an attempt to > make the ui accessible to the illiterate, but in my view it only > complicates matters. icons would be effective if they were > universally obvious a priori, but that is not possible - icons have to > be learned just as do the symbols of any alphabet. mother tongue is > preferable, as it contributes to the learning of literacy useful in > the broader context of the language world within which they live. a > single release of a ui could have a feature that allows the ui to be > displayed in any of the languages that have been implemented. > > the choices of names are developer-oriented rather than user-oriented: > for example, the name "turtle-art" makes sense only to people who are > already familiar with Logo. Whereas, "draw a picture" (or its > translation) would make sense to any kid who can read her mother > tongue. for those who can't read, a thumbnail of a half-finished > painting and a brush might work - it would take up more pixels than an > icon, but i don't think there should be many app-triggers on view at > the same time. > > with 69 apps already mooted (and presumably a thousand more waiting to > be added), that creates a navigation issue which needs to be > addressed. i feel that it could be done by creating categories of > activity (such as "learn", "play" and "meet") and subcategories etc, > making a simple tree structure (or maybe a network with cross-links). > the one thing i am sure of is that trying to put buttons for > everything on one screen creates information overload. As regard the activity icons on the home page (as several people have responded already) we haven't observed this as being a major problem with Sugar in the field. Also, at least in the beginning, we were disciplined about naming activities as actions, e.g., Paint, Browse, etc. Turtle Art was a bit of an exception and probably could have been named Program. It has been oft observed that children will push buttons in order to find out what they do, as oppose to adults, who like to know what buttons do before they push them. In general, there are roll-over text hints for every icon in Sugar. We've had a long (4+ years) argument about the length of the delay in revealing those texts and in the most recent Sugar, all secondary palettes will appear immediately. > > the problem of toolbar items following off the end of the toolbar > .A simple solution would be to double the vertical size of the > toolbar and wrap the icons onto a second row.> > > perhaps there are too many tool buttons on screen at the same > time! - but in general, one way to display long lists of items is > to use scrolling, whether by mouse or finger slide - if the scrolled > list were an imaginary wheel viewed edge-on with, say, half a dozen > items in view at any one time, you wouldnt need a scrollbar, just a > single button to rotate it (or a wheel mouse, which i find quite handy > for scanning up and down lines of text). We had extensive use of scrolling in earlier versions of Sugar and found that it was not readily discoverable, even by curious kids. Maybe it was simply a matter of poor design and it certainly could be revisited. Another argument against scrolling is that it requires you to remember where things are. Not sure that is necessary. > > > > "critique and reflect".> > > sounds good but these are things that a kid would do within an > activity (aka app) - getting to that activity should not require > detective work. Agreed. But as per above, kids seem to engage in such detective work anyway. In a recent study in Ethiopia, it was reported that kids explored thousands of activities per month. This was all done through clicking on icons (Android in this case) to see what they do. > > > > activities by using the Sugar tools as individual building blocks,> > > ah if the objective were to produce sugar-literacy, that would > make sense, but if sugar were merely a tool to facilitate learning of > things that are going to be of use to the kid in the outside world, > then every effort should be made to make sugar itself as transparent > as possible, rather like google chrome tries to get out of the way > just as internet explorer tries to get in the way with thousands of > toolbars Apparently I was not clear. Let me explain by example. Sugar has a Record activity used to record still images, sound, and video. Sugar also has a Write activity, used to write texts. When you use Record, your recordings are saved to the Journal. When you use Write, you can import recording from the Jou
[Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal
Hi,
I have been thinking a bit about how we can enhance the interaction with
the search entries in the Shell so they will work well in touch as well [1].
When you have a touchscreen device focusing an entry will automatically
bring up the onscreen keyboard (OSK). We are currently doing this in the
Home View/Neighborhood View and in the Journal. For keyboard devices
this makes absolute sense, having first to move the pointer towards the
entry, click on it before you can type in the search is a too long
interaction. With a touch interface however it is ok to touch the search
field to bring up the OSK in most of the cases. Otherwise the OSK might
cover parts of the screen without need.
I would suggest the following new behavior:
- the entry is unfocused by default, the canvas is focused
- the entry contains a hint (e.g. "Search in your Journal..."), adding a
placeholder text is available in GTK+3.2 [2]
- when the user starts typing the entry is focused automatically
(listening on the canvas and switching focus)
I think this will give a good behavior for both worlds. I have attached
as well a GTK+ 3 example. Let me know what you think.
Regards,
Simon
[1]
http://wiki.sugarlabs.org/go/Features/Touch/Development#Reveal_on_text_input_focus.2C_auto_.2A.2Adismiss.2A.2A_on_loss_of_focus
[2]
http://developer.gnome.org/gtk3/3.4/GtkEntry.html#gtk-entry-set-placeholder-text
from gi.repository import Gtk
def _destroy_cb(widget, data=None):
Gtk.main_quit()
def _key_press_cb(widget, event, entry):
if entry.has_focus():
print 'has focus'
else:
print 'grab focus'
entry.grab_focus()
return False
window = Gtk.Window()
window.connect("destroy", _destroy_cb)
box = Gtk.VBox()
window.add(box)
box.show()
b = Gtk.Button('touch1')
box.pack_start(b, False, False, 0)
b.show()
entry = Gtk.Entry()
entry.set_placeholder_text('Type to search...')
box.pack_start(entry, False, False, 0)
entry.show()
b2 = Gtk.Button('touch2')
box.pack_start(b2, False, False, 0)
b2.show()
window.connect('key-press-event', _key_press_cb, entry)
window.show()
Gtk.main()
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] conversations about sugar ui design
On Mon, Aug 20, 2012 at 01:56:39PM +1000, David Brown wrote: > this note embraces several different emails from >Aleksey and > > > I've CCed people who are working on current webui implementation (that > > is intended to be piloted in several Peruvian schools). If you are have > > time, you can help to make UI more useful. > > i'd like to try to assist/participate. my first suggestion would be > to create a design forum so design discussions can flow and be > retained. there is a design team meeting sometime soon, but i feel > that the design process should be basically asynchronous and ongoing - > one can't schedule one's brainwaves at just the right time during a > brainstrorming session (most of my better ideas occur to me when i am > on the toilet or thinking about something else or asleep...) More practical thoughts. Unfortunately, Sugar Labs community is not overcrowded by designers and usability specialists (though, some people think that such overcrowding is not good for Gnome:). And, not all projects started within the Sugar Labs (Sugar Network is a recent effort) have rapt attention from UI and edu people. Laura and Sebastian (people who work on Sugar Network webui) do some efforts to involve people from Peruvian community, but afaik, there are no more people who can work on webui on regular basis. You posted some UI notes, if you want, we can work on Sugar Network UI in more practical way. (/me is waiting a response from Laura and Sebastian here). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] conversations about sugar ui design
On Mon, Aug 20, 2012 at 01:56:39PM +1000, David Brown wrote: > this note embraces several different emails from >Aleksey and > > activities by using the Sugar tools as individual building blocks,> > > ah if the objective were to produce sugar-literacy, that would > make sense, but if sugar were merely a tool to facilitate learning of > things that are going to be of use to the kid in the outside world, > then every effort should be made to make sugar itself as transparent > as possible, rather like google chrome tries to get out of the way > just as internet explorer tries to get in the way with thousands of > toolbars A couple of general thoughts. My own background, when I started contributing to Sugar Labs, was that I didn't see how Sugar Shell might be particular useful in educational process (but I saw technical potency of having community of "doers" targeted to learning platform, whatever it might be at the end). At the same time, Sugar Shell has OLPC roots when OLPC needed, in my mind, "desktop" environment for XO laptops. And, Sugar Shell is much better, imho, option than regular desktops existed in the past and present right now. I mean, attempt to create entire desktop environment should not be dominant effort on Sugar Labs level when there is no urgent need in having desktop environment (different to "office" desktops) to install on particular hardware. Obviously, high aged students, most likely, will prefer not Sugar Shell as a regular desktop environment. Low aged students, at least in my mind, don't exactly need desktop environment, but rather some environment (maybe pretty isolated from the rest of current desktop) that will be useful for them from teacher's pov. In other words, it will be useful if software, created within the Sugar Labs, will run on regular desktops to give more flexibility for people in the field. For example, particular school/region might decide to spread tablets on Android among students. The "lets port Sugar [as a desktop environment] on Android" sounds scary for me. Much better if there will be a way to launch some Sugar activities as a regular Android apps and having a kind of shell (most likely created from scratch to make it more Android) for cases when students [low aged] need limited/restricted environment. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Frame Device icon Volumes
On 08/19/2012 08:04 PM, Gary Martin wrote: On 19 Aug 2012, at 15:54, Simon Schampijer wrote: On 08/19/2012 03:45 PM, Gonzalo Odiard wrote: There are a convention about the position of the primary action? Should be the closest to the button or the first at top of the palette? The palettes reflow based on how close to a screen edge it is, so in some cases it might not be easily to know which end of the palette is closest to the button. I'd also call out that reordering a palettes content is a worse UI crime for consistency. At Sugar Camp Paris 2, Simon and I did mock-up a range of 'put the primary action by the button' type designs, until we realised the issues with reflow when near screen edges. So that's a +1 for top of the palette. I've always assumed this was the convention and implicit in the current implementation, but perhaps it's not explicitly documented (seemingly like so many other items). I think is important have this defined, and may be show it in a special way. In this particular case, the option is between the label, another action and the widget showing the size, and is not obvious. Gonzalo So, in this particular case, there is no primary action anymore. Left click will always bring up the Palette, then it is up to the user to decide. +1 Let's look at another case: the Activity Palettes in the Frame (see activity_palette_1.png). The primary action there is to resume the Activity. When you click on the button that activity is resumed. The action is drawn right below the label. That is where I would put it as well. But in this case, I think the separator should then be drawn below the primary option (see activity_palette_2.png). Yes, for this case I think that's a reasonable amendment. The only other variation for this that came to mind would be to make the primary action text bold (as adding/moving separators might not always be the right treatment). Attached is an example with the text being bold for the primary action. Is subtle. Not sure it will make clear what it is about. Simon <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
