Re: [Sugar-devel] [DESIGN] New share button style
On Thu, Jun 17, 2010 at 05:56:30AM +, Aleksey Lim wrote: On Thu, Jun 17, 2010 at 01:42:58AM -0400, Frederick Grose wrote: On Thu, Jun 17, 2010 at 1:07 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Jun 17, 2010 at 04:47:30AM +, Aleksey Lim wrote: What about just making ShareButton inactive while changing status? http://people.sugarlabs.org/~alsroot/tmp/share-meornu-sensitive.ogvhttp://people.sugarlabs.org/~alsroot/tmp/share-menu-sensitive.ogv That would work in the successful or quick failure cases, but if there was a failure, and the process was stuck retrying, the static signal would not provide the information about process state. See http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Controls/Indicators for some other ideas on how to badge the icon with process state information. To be honest I was planing to use alerts to notify about sharing errors with message like Cannot make it Public, fallback to Offline, imho this kind of fails is critical enough to use alserts. I mean, in case of ShareButton, where is a timeout and if something is wrong, error will be raised in any case. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] New share button style
On 17 Jun 2010, at 06:56, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Jun 17, 2010 at 01:42:58AM -0400, Frederick Grose wrote: On Thu, Jun 17, 2010 at 1:07 AM, Aleksey Lim alsr...@member.fsf.org wrote: On Thu, Jun 17, 2010 at 04:47:30AM +, Aleksey Lim wrote: On Thu, Jun 17, 2010 at 12:09:24AM -0400, Frederick Grose wrote: On Wed, Jun 16, 2010 at 11:41 PM, Aleksey Lim alsr...@member.fsf.org wrote: ... This enlivens the interface, and should only be a compliment to the more standard 'busy' cursor because the gray-scale tone changes of the pulsing can be missed in suboptimal viewing conditions. There are several situations where a busy cursor is needed. Among them are these: http://bugs.sugarlabs.org/ticket/405 http://bugs.sugarlabs.org/ticket/851 or http://dev.laptop.org/ticket/3617 Not trying to argue but for me busy cursor means that the whole application is in suspended (more or less) state, but in case of share button, activity could be used as usual. There is also another reason against setting cursor. ShareButton is only low level widget which is not aware of high level use cases where global setting like changing cursor is unaccessible (or sounds overkill). +1, and also in a touch based UI there is no cursor ;) Yes, those are good reasons not to modify the cursor in the Activity sharing case. For the general case that you suggested, the throbbing icon is a nice feature, but to serve those with low vision or in a difficult viewing environment, a small, high-contrast element or badge (perhaps a small stop sign, or just a small x as a badge on the icon) should be added. Hmmm. A stop sign or small x icon badge icon would be confusing I think, as you can currently neither stop or cancel via the toolbar button. The pulsing provides vastly more status information from where we are right now, which is zero feedback. Adjusting the pulse frequency and pulse contrast range could give some scope for improvement. If we need additional new high-contrast elements for the visually impaired, we should tackle that as a separate design task so as not to block on current progress. I'm sure there are more pressing features we need for that group (global font size controls, screen zoom shortcuts, screen colour reverse, audio feedback, global text to speech, etc). What about just making ShareButton inactive while changing status? http://people.sugarlabs.org/~alsroot/tmp/share-meornu-sensitive.ogvhttp://people.sugarlabs.org/~alsroot/tmp/share-menu-sensitive.ogv That would work in the successful or quick failure cases, but if there was a failure, and the process was stuck retrying, the static signal would not provide the information about process state. See http://wiki.sugarlabs.org/go/Human_Interface_Guidelines/The_Sugar_Interface/Controls/Indicators for some other ideas on how to badge the icon with process state information. To be honest I was planing to use alerts to notify about sharing errors with message like Cannot make it Public, fallback to Offline, imho this kind of fails is critical enough to use alserts. +1 Regards, --Gary Thanks again!--Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ 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] [DESIGN] Displaying the current status of system resources (such as memory, cpu)
On Wed, Jun 16, 2010 at 09:17:37AM +1000, fors...@ozonline.com.au wrote: Furthermore, what all system parameters should be made available through such a means (such as free memory, and cpu load)? Suggestions and opinions welcome! Time and date would be good. We've been there: http://wiki.laptop.org/go/User:MartinDengler#Add_a_clock_.28to_the_frame.29 http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014270.html Tony Martin pgpw0jR0ZLRtm.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar with a virtual (onscreen) keyboard
[Apologies for the cross-posting] Hello, Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. A problem with the current FVKBD is that it supports only one base layout. Even variants of that layout (eg: CapsLock enabled, Symbols, etc) are treated as temporary, which means that you press the Caps key, enter a capital letter, and immediately after that, it gets reset back to the base layout (lower case qwerty). I wanted something which would be similar to the existing physical keyboards that we ship with the XO machines - with a dedicated key to switch between different scripts in the same keyboard. I had to extend the code of FVKBD to implement that, and with the modified FVKBD, I have spun a live-cd ISO (based on the current SOAS). You can download it from http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.iso Apart from the modified FVKBD, I have added a default keyboard definition file which is for English + Bengali, and I've also included a sugar device-icon on the frame to control the appearance of the keyboard. I realize that more needs to be done to support non Latin scripts, and here are some of the issues I faced while converting the existing XKB Bengali layout: * Many scripts do not have a concept of upper case/lower case - so we need some other script specific way to divide the characters * In the current XKB configurations, non-symbol characters from other scripts are often placed in the position of what normally is symbols for QWERTY keyboards * Numerals pose an interesting problem, since in some places, native numerals/digits are quickly being obsoleted, and latin numerals (1,2,3..) are becoming the de-facto standard. In these cases, it may make sense to provide only _one_ layout/state for numerals, and allow users to input native numerals by hovering (touch + hold) on the virtual key for the latin digit. Among the general issues, I'm not sure how to deal with the keyboard taking up half of the screen real estate - it may be worthwhile to see if we can have a split screen sort of configuration while the keyboard is active. Thoughts, feedback, etc would be appreciated :-). Thanks, Sayamindu [1] http://git.moblin.org/cgit.cgi/fvkbd/ -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
On Thu, Jun 17, 2010 at 5:46 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: [Apologies for the cross-posting] Hello, Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. A problem with the current FVKBD is that it supports only one base layout. Even variants of that layout (eg: CapsLock enabled, Symbols, etc) are treated as temporary, which means that you press the Caps key, enter a capital letter, and immediately after that, it gets reset back to the base layout (lower case qwerty). I wanted something which would be similar to the existing physical keyboards that we ship with the XO machines - with a dedicated key to switch between different scripts in the same keyboard. I had to extend the code of FVKBD to implement that, and with the modified FVKBD, I have spun a live-cd ISO (based on the current SOAS). You can download it from http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.iso For those who do not want to download the ISO, there's a screencast at http://dev.laptop.org/~sayamindu/sugar_vkbd_multi.ogv Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
Hi, FVKBD support spanish keyboard? Could be added an system scanning buttons to write. for example: https://desarrollo.ceibal.edu.uy/projects/tecladoenpantalla/files http://wiki.sugarlabs.org/go/Features/Accessibility_virtualkeyboard http://bugs.sugarlabs.org/ticket/1686 2010/6/17 Sayamindu Dasgupta sayami...@gmail.com On Thu, Jun 17, 2010 at 5:46 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: [Apologies for the cross-posting] Hello, Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. A problem with the current FVKBD is that it supports only one base layout. Even variants of that layout (eg: CapsLock enabled, Symbols, etc) are treated as temporary, which means that you press the Caps key, enter a capital letter, and immediately after that, it gets reset back to the base layout (lower case qwerty). I wanted something which would be similar to the existing physical keyboards that we ship with the XO machines - with a dedicated key to switch between different scripts in the same keyboard. I had to extend the code of FVKBD to implement that, and with the modified FVKBD, I have spun a live-cd ISO (based on the current SOAS). You can download it from http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.isohttp://dev.laptop.org/%7Esayamindu/sugar-vkbd-test/sugar-vkbd-test.iso For those who do not want to download the ISO, there's a screencast at http://dev.laptop.org/~sayamindu/sugar_vkbd_multi.ogvhttp://dev.laptop.org/%7Esayamindu/sugar_vkbd_multi.ogv Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Esteban Arias Plan Ceibal - Área Técnica Avda. Italia 6201 Montevideo - Uruguay. Tel.: 601.57.73 Interno 2228 E-mail : ear...@plan.ceibal.edu.uy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Help Needed - Convert python code into Sugar
John, We have a manual which should help you figure out what you're doing wrong: http://en.flossmanuals.net/ActivitiesGuideSugar/Introduction James Simmons Date: Thu, 17 Jun 2010 03:28:52 -0700 (PDT) From: John Samuel johnsamuel...@yahoo.com Subject: [Sugar-devel] Help Needed - Convert python code into Sugar To: Sugar Devel sugar-devel@lists.sugarlabs.org Message-ID: 350718.92048...@web45305.mail.sp1.yahoo.com Content-Type: text/plain; charset=us-ascii Hi, this is John Samuel here.I am new to Sugar. I've made a small program in python for the viewing of images.It runs perfectly as a standalone program, but when I convert it into Sugar, it runs in a different window coz of which it cannot be stopped.I have to close Xephyr and run it again.I use Sugar .88 on Ubuntu 9.10 KarmicCould anyone please help me? I've attached my code along with this mail. John Samuel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] New share button style
... For the general case that you suggested, the throbbing icon is a nice feature, but and to serve those with low vision or in a difficult viewing environment, a small, high-contrast element or badge (perhaps a small stop sign, or just a small x as a badge on the icon) should be added. The busy emblem, http://git.sugarlabs.org/projects/sugar-artwork/repos/mainline/blobs/master/icons/scalable/emblems/emblem-busy.svg, applied to the lower right corner of the icon, is available for this purpose. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Read PATCH v2] don't break if HAL is not available
HAL is only used for displaying the current battery status, so it's
entirely optional.
---
readtopbar.py | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
v1-v2: log warning when HAL is unavailable
diff --git a/readtopbar.py b/readtopbar.py
index 3f338f5..cca68e2 100644
--- a/readtopbar.py
+++ b/readtopbar.py
@@ -134,17 +134,22 @@ class _TopBar(gtk.HBox):
self._completion_level = 0
self._progressbar = None
-bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM)
-proxy = bus.get_object('org.freedesktop.Hal',
-'/org/freedesktop/Hal/Manager')
-hal_manager = dbus.Interface(proxy, 'org.freedesktop.Hal.Manager')
-udis = hal_manager.FindDeviceByCapability('battery')
-if len(udis) 0:
-self._battery = BattMan(udis[0]) # TODO: Support more than one
battery
-self._battery.connect('notify::level', \
-self._battery_level_changed_cb)
-else:
-self._battery = None
+
+self._battery = None
+try:
+bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM)
+proxy = bus.get_object('org.freedesktop.Hal',
+'/org/freedesktop/Hal/Manager')
+hal_manager = dbus.Interface(proxy, 'org.freedesktop.Hal.Manager')
+udis = hal_manager.FindDeviceByCapability('battery')
+if len(udis) 0:
+self._battery = BattMan(udis[0]) # TODO: Support more than one
battery
+self._battery.connect('notify::level', \
+self._battery_level_changed_cb)
+
+except dbus.DBusException:
+logging.warning('HAL not found. Will not be able to display'
+' battery charge level.')
self._icon = None
--
1.6.5
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Read PATCH] don't break if HAL is not available
Excerpts from Benjamin M. Schwartz's message of Thu Jun 17 00:31:06 + 2010: It might be worth logging an explanation like NOTICE: Battery tray icon not displayed because HAL is not available. Fair point. In the long run Read should switch to upower, but I'll wait with that until it works again at all (#1900, [1]). Sascha [1] https://bugs.sugarlabs.org/ticket/1900 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] RD vs Product Support
El Wed, 16-06-2010 a las 18:27 +0200, Simon Schampijer escribió: I saw the talk from Mark Shuttleworth at Linuxtag and he said a few words on Releases, and why is makes sense to bundle forces. Basically, bundling forces is a powerful idea behind open source. We are a small project, if we keep being aligned with all the bigger projects especially gnome we will profit from this joined efforts a lot. I couldn't agree more. At the same time, I'm seeing a number of very skilled Sugar hackers who would be more inclined to work on complex innovative projects and would therefore prefer a less structured approach. Long term, both approaches are essential to the evolution of a project. Some large hi-tech companies I worked for in my previous life solved the conflict of approaches by splitting their engineering staff into two departments: RD lab and Design/Engineering office. RD creates prototypes and then hands them off to the other department which turns them into an industrialized product. Needless to say, many projects die during the transition. Not everything that is technically possible can become a finished, marketable product. It may seem that RD is doing all the hard work while engineering just adds the finishing touches,but Brooks claims that there's a x3 factor in effort between a working program and a finished product that could be commercialized to paying customers. I believe that Brooks' law holds also for a FLOSS project like ours. Despite being used in production for ~2 years, Sugar still has many traits of a half-finished prototype: it can backup but not yet restore... Stuff that RD people wouldn't normally do, but still takes many years of organized engineering work to get right. Moreover, some of these missing features are urgently needed. A simple pragmatic solution often serves our users better than a theoretically perfect one which would require redesigning a large subsystem. Every time I see a hypothetical design blocking the delivery of a quick effective solution available today, I think that we should rethink our project structure to minimize this tension. Ensuring that the proper design will eventually be implemented is as important as delivering a sufficiently polished product to our current user base. It seems that the two approaches should proceed in parallel. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar with a virtual (onscreen) keyboard
Hi Sayamindu, On 17 Jun 2010, at 13:16, Sayamindu Dasgupta wrote: [Apologies for the cross-posting] Hello, Thanks to the pointers provided by Peter Robinson, I got the Meego FVKBD (Free Virtual Keyboard)¹ running along with Sugar. A problem with the current FVKBD is that it supports only one base layout. Even variants of that layout (eg: CapsLock enabled, Symbols, etc) are treated as temporary, which means that you press the Caps key, enter a capital letter, and immediately after that, it gets reset back to the base layout (lower case qwerty). I wanted something which would be similar to the existing physical keyboards that we ship with the XO machines - with a dedicated key to switch between different scripts in the same keyboard. I had to extend the code of FVKBD to implement that, and with the modified FVKBD, I have spun a live-cd ISO (based on the current SOAS). You can download it from http://dev.laptop.org/~sayamindu/sugar-vkbd-test/sugar-vkbd-test.iso Wow, big thanks for launching into this. For anyone not sure how to try the iso, I'm on a Mac and just used Virtual Box to create a new empty Fedora VM, no HD, and just point to the iso as the boot CD. Started up just fine, keyboard is already open to type in your user name (of course this is all read only, any changes you make will be gone after a reboot). I'll try and spend some time in the next few days using it via iPad HW and send some feedback, just been playing via mouse so far today. Apart from the modified FVKBD, I have added a default keyboard definition file which is for English + Bengali, and I've also included a sugar device-icon on the frame to control the appearance of the keyboard. I realize that more needs to be done to support non Latin scripts, and here are some of the issues I faced while converting the existing XKB Bengali layout: * Many scripts do not have a concept of upper case/lower case - so we need some other script specific way to divide the characters * In the current XKB configurations, non-symbol characters from other scripts are often placed in the position of what normally is symbols for QWERTY keyboards * Numerals pose an interesting problem, since in some places, native numerals/digits are quickly being obsoleted, and latin numerals (1,2,3..) are becoming the de-facto standard. In these cases, it may make sense to provide only _one_ layout/state for numerals, and allow users to input native numerals by hovering (touch + hold) on the virtual key for the latin digit. Among the general issues, I'm not sure how to deal with the keyboard taking up half of the screen real estate - it may be worthwhile to see if we can have a split screen sort of configuration while the keyboard is active. It didn't bother me too much, and this was in an 800x600 session, though ideally we would want the text insertion point to be visible above the keyboard (FWIW various iPad apps have different success in dealing with this, all of Apple's are fine, but it seems 3rd parties do need to do some work on the app side to keep this behaviour working at all times). Thoughts, feedback, etc would be appreciated :-). Yes, lot's of interesting items to cover :-) I'll try to start to put together a list. Some quick item that struck me right away: - the Meego keyboard design is clearly for casual typing/text entry, no way of typing commands or many symbols needed for basic programming work – diving into terminal to use vi, or worse emacs, is pretty much a dead end (unless ctrl and alt keys are hidden somewhere I couldn't find). Is it flexible enough to allow different activities to trigger different keyboards (or an extra row of custom keys)? Something like Pippy, or Terminal would need that kind of extra flexibility. - z layering issues with frame, should it be over, under, part of? Currently it can be a mix depending on the sequence things are triggered. - Ideally something (Gnome I assume?) should trigger the keyboard overlay when you focus on a text field, perhaps with some hints about what the 'return' key behaviour should do (or expose a tab key as that is usually the other common text field navigation method). Dismissing the keyboard overlay when a text field is defocused would also be ideal. - The 'grapes' icon particularly (and some others) could do with with some sugar-love ;) Do you think those should be upstreamed? Or do we have many other unique requirements (enough to fork) that the Meego platform isn't looking to support? OT: one thing I really miss on the iPad even after a few weeks solid use, is the omission of cursor keys for small adjustments in text cursor positions or text selections. Text editing, even on an iPad with its auto correction, and realtime frame redraw perfect tap and hold magnifying glass effect can be frustrating. I think cursors are still important keys to have if we expect children to write more than minimal text in this
