[Sugar-devel] [DESIGN] Fwd: #2063 UNSP: Sugar should bring up an alert when an unhandled Python exception occurs
Any ideas about how it would look like? Regards, Tomeu -- Forwarded message -- From: Sugar Labs Bugs bugtracker-nore...@sugarlabs.org Date: Sun, Jun 27, 2010 at 20:20 Subject: #2063 UNSP: Sugar should bring up an alert when an unhandled Python exception occurs To: Cc: b...@lists.sugarlabs.org #2063: Sugar should bring up an alert when an unhandled Python exception occurs --+- Reporter: bernie | Owner: tomeu Type: defect | Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: sugar | Version: Git as of bugdate Severity: Unspecified | Keywords: Distribution: Unspecified | Status_field: Unconfirmed --+- Many UX designers abhor the idea that the computer would scare off users with incomprehensible error messages. Ideally, we would have a 100% bug free system in which this never happens, but current today's is very different. Currently, users and are left wondering why some operation isn't doing anything and have no way to tell that their log is full of tracebacks. To keep things simple, I would suggest to print the exception message in a notification alert, and suggest users to open the Log activity for further details. -- Ticket URL: http://bugs.sugarlabs.org/ticket/2063 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Caacupé war bullettin -- day 1
Today we started testing of F11-0.88 with one 6th grade classroom in Caacupé. Within a couple of hours from updating the laptops, an overwhelmed amount of new bugs popped up: * Restore from XS does not make system reboot. tch sent a fix today, I need to build new Sugar packages. * Journal does not reindex after restore Silbe and aa helped me diagnose this. aa is working on a fix. Meanwhile, I temporarily dropped the sort-by-size patch series. * Touchpad control panel does not show up with new kernel Dsd filed dlo#10191, pgf figured out why. we need to issue a new olpc-utils package * Missing spanish translation of backup strings tch updated the po files, but there is plenty of line numbers noise in the diffs. How do we usually handle po updates? * Icon of backup is a laptop, should be a school garymartin made a bunch of icons, need to select one ASAP * Date not being updated One laptop booted with clock set to the Epoch. Oddly, the lease was accepted anyway. We need to figure out why the clock is not being updated from the network. Why aren't we using ntp? * When registration to XS fails, you get no error messages Ditto. I'm not sure it happens in all cases, though... (someone wants to pick this up?) * Can't register to XS just after connecting to the AP for the first time. Works after restarting Sugar. This may not be the same issue of Python's urllib permanently caching the DNS lookup failure. * Missing icons for the datastore sort feature aa sent them later today, I need to integrate them * New kernel still has one-dot boot hang bug Did not see this yet, but we need to remember to apply the fixes from dlo#10193 * Missing spanish translation for the datastore sort feature (Who could do this? aa?) * When we uninstall an activity, we should remove its data dir as well. This may sound controversial (think data loss), but if we don't laptops become unusable after the user has tried out too many activities. In one case, a user had 200MB of invisible junk in ~/.sugar/default/org.winehq.Wine. * Another typical offender of free space is Browse, with 50MB of junk in its data dir. We should consider reducing the cache to 5-10MB. * Volumes don't disappear from journal volumes toolbar. (tch fixed it today, need to rebuild Sugar packages). * Plenty of datastore corruption issues. These have been observed with journals created by 0.84, but the bugs are probably still there in 0.88. == Reflections == * We need to dedicate more resources to testing. Many of the above bugs could have been avoided with better testing in the lab. * The current test plan sucks (contains only trivial tests, it is not representative of real-world usage) * Many of these bugs are not regressions (i.e.: Sugar 0.84 and 0.82 were also affected). * We need a public test schoolserver. We could provide a VM on treehouse and Carlos could install it, but schoolserver security is inadequate for public Internet access. Ideas? * Even if we could find and fix all bugs leading to datastore corruption, we must deal with upgrades. The datastore need to become more robust when dealing with various cases of corrupted entries and index. * I have a macabre collection of datastores mangled in various ways. Since they potentially contain privacy-sensitive data, I can't publish this horror show. Contact me if you would like to analyze them. * Datastore corruption is still the #1 cause of user and teacher dissatisfaction with Sugar. WE MUST ABSOLUTELY PUT MORE RESOURCES ON THIS PROBLEM. It makes Sugar look worse than Vista. After an initial round of discussion, I'll transcribe the remaining bugs in the F11-0.88 page so we don't forget. Anyone is also welcome to file them as tickets in the OLPC/SL trackers. Much more importantly, anyone is *very* welcome to work on a fix for one of these, but hurry up: we have only one month before general availability. -- // 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] [PATCH] Browse: Add support for creating multiple tabs
El Wed, 30-06-2010 a las 11:13 +0200, Benjamin Otte escribió: I believe this is a Mozilla bug, to be exact: https://bugzilla.mozilla.org/show_bug.cgi?id=522635 Thanks! I asked if someone could point me at the patch, so I can apply it to the F11 version of xulrunner. (damn, I wish we did not have to fork xulrunner too) -- // 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] F11-0.88 unmerged patches summary
On Wed, Jun 30, 2010 at 03:57, Bernie Innocenti ber...@codewiz.org wrote: Here's an executive summary of all outstanding patches in my queue: http://people.sugarlabs.org/bernie/sugar/sugar-0.88-patches/ Most of these have already been submitted to sugar-devel@ or attached to tickets in bugs.sugarlabs.org. Some of these patches have outstanding quality issues, but all of them have been integrated and tested for a while in F11-0.88 and together contribute to a better Sugar experience. == Bugfixes == sugar-toolkit/use-set_toolbar_box-in-example-code.patch sugar-toolkit/set-default-accelerators-for-Copy-and-Paste-buttons.patch These have been ack'd by Alsroot. Do we also need Erikos' approval? No, as per http://wiki.sugarlabs.org/go/Development_Team/Code_Review#Discussion . sugar-toolkit/sl1842-notify-red-alert.patch Correct me if I'm wrong, but I think both Gary and James agreed? I wonder about performance, as fills on the XO-1 are very slow and if the fading was very smooth it could have a negative impact on the UX. sugar/sl1842-journal-error-messates.patch The review has been swamped by a design discussion. It's not clear what Anish should do to pass review. Do you have a link to the controversy? sugar-toolkit/sl1948-Race-condition-with-name-widget-in-the-activ.patch This patch has a corner case in which it fails to update the activity name, but I think it's still a little better than the current behavior. See ticket for details. I guess you and Simon need to agree on which bad is better. sugar/add-font-dpi-schema.patch This is a companion patch of a fix sugar-settings-manager which has already landed in git. It's needed by xulrunner (Browse). Would be good if the commit message said why is that needed, or at least have a link to the ticket. sugar/avoid-popping-an-empty-list-in-the-software-updater.patch Works, but James Cameron's posted a better counter-patch. Merge that one. sugar/click-on-journal-icons-with-a-exclusive-time-frame.patch Requested by the Waveplace folks. Please merge. What happened to the check for activity_id? We have it in other places in the UI with the similar issue. sugar/dynamically-set-number-of-control-panel-columns.patch The approach to comoute the column width is wrong, but it produces better results than the current fixed number of columns. So, for now, I'm keeping it around. Anish has a better one already. sugar/fix-duplication-of-OLPC-mesh-icons.patch sugar/fix-for-file-list-sorting-for-FAT32-formatted-flash-drives-in-journal.patch All the above have no issues to my knowledge and should be merged. sugar/use-the-spanish-verb-quitar-for-unmounting-devices.patch Better-than-nothing patch, but the real fix would require a gettext kludge in the code (see http://bugs.python.org/issue2504 ) Shouldn't we make the change in Pootle? Or it will be synced automatically? Or maybe we should go with the kludge as the real fix is most likely to not land in 2.x. == Minor bugfixes == sugar-toolkit/fix-two-trivial-shell-log-warnings.patch Reviewed on sugar-devel, should be merged. sugar-toolkit/sl1876.patch Patch is in comment 2 of the ticket. It has been overlooked becuase the ticket had also an attachment. sugar/fix-name-clash-set_state.patch Should be merged. == New Features == sugar/backup-0001-Volumes-Backup-and-Restore.patch sugar/backup-0002-Journal-XS-backup-and-restore.patch There are concerns about restore deleting new entries since the last backup. I agree, but since nobody seems to have the time to implement and test a more sophisticated procedure, at this time this is the best restore feature we have for Sugar. Do we know any other deployment willing to deploy this? If we decide to merge it, I think it should be disabled by default and have a gconf setting, because knowingly shipping a feature that causes data loss may not be a good idea. == Cleanups == sugar/simplify-the-definition-of-UpdateModel._bundles_to_check..patch Merge. sugar-toolkit/remove-incomplete-MANIFEST-support.patch The incomplete design and implementation of MANIFEST files has been laying around for 3 years. We can choose to clean it up now, or let it bitrot for another 3 years. == Experimental patches == sugar/set-default-scaling-to-100.patch This is only required on the XO. We should really autodetect this. sugar/cpu-and-memory-resource-indicator.patch Not yet reviewed on sugar-de...@. Not even tested by us yet. sugar-artwork/sl2006-icons-for-touchpad-panel.patch sugar/sl2006-touchpad-section-for-control-panel.patch sugar/sl2006-file-exists-check.patch Walter's XO-1 touchpad control panel. For me, it could already go in, but it would be nice to add a global shortcut such as alt-shift-t, and maybe move the functionality to a frame icon, for fast switching. sugar-toolkit/change-keep-string-to-keep-a-copy.patch Several alternatives have been suggested
Re: [Sugar-devel] sugar-artwork 0.84 and 0.86 apparently out of sync
On Thu, Jul 01, 2010 at 03:14:38PM +0200, Tomeu Vizoso wrote: On Fri, Jun 25, 2010 at 16:49, Jonas Smedegaard d...@jones.dk wrote: Hi, It seems that sugar-artwork Git is tagged as at version 0.84.2, but the corresponding tarball is missing from http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/ . Also, I suspect (based on Sascha Silbe reporting[1]) that the GTK_WIDGET_HAS_FOCUS bugfix applied in 0.88 branch should be backported to both 0.86 and 0.84. Thanks for the heads up, I'm adding it to my list in case nobody does it before. I tried backporting, and noone complained so far: http://git.debian.org/?p=collab-maint/sugar-artwork.git;a=blob;f=debian/patches/1001_avoid_deprecated_GTK_API.patch;hb=7f7a47 http://git.debian.org/?p=collab-maint/sugar-artwork.git;a=blob;f=debian/patches/1001_avoid_deprecated_GTK_API.patch;hb=05cf34 - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-artwork 0.84 and 0.86 apparently out of sync
On Thu, Jul 01, 2010 at 05:15:31PM +0200, Jonas Smedegaard wrote: On Thu, Jul 01, 2010 at 03:14:38PM +0200, Tomeu Vizoso wrote: On Fri, Jun 25, 2010 at 16:49, Jonas Smedegaard d...@jones.dk wrote: Hi, It seems that sugar-artwork Git is tagged as at version 0.84.2, but the corresponding tarball is missing from http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/ . Also, I suspect (based on Sascha Silbe reporting[1]) that the GTK_WIDGET_HAS_FOCUS bugfix applied in 0.88 branch should be backported to both 0.86 and 0.84. Thanks for the heads up, I'm adding it to my list in case nobody does it before. I tried backporting, and noone complained so far: http://git.debian.org/?p=collab-maint/sugar-artwork.git;a=blob;f=debian/patches/1001_avoid_deprecated_GTK_API.patch;hb=7f7a47 http://git.debian.org/?p=collab-maint/sugar-artwork.git;a=blob;f=debian/patches/1001_avoid_deprecated_GTK_API.patch;hb=05cf34 ...and 5 days from now, if still noone finds bugs in the latest packaging release, the patches will appear at these nicer URLs: http://patch-tracker.debian.org/package/sugar-artwork-0.86 http://patch-tracker.debian.org/package/sugar-artwork-0.84 ...similarly all other Debian packages has such URLs for easy lifting patches :-) - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [GSoC] [Patch] Sugar Smolt Control Panel Integration
Sorry that it took me a bit to reply. Catching up on email backlog once again. I dropped a couple of replies inline. :) On Mon, Jun 28, 2010 at 11:57 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Excerpts from Sebastian Dziallas's message of Sun Jun 27 21:07:11 +0200 2010: I've been working on an integration of Smolt (https://fedorahosted.org/smolt/) into Sugar as part of my GSoC. The Nice! The repository lives here (http://git.sugarlabs.org/projects/sugar/repos/sugar-smolt) and A quick look doesn't show any major mistakes (take that as praise ;) ). There are a few minor style issues; pylint + pep8 might catch some of the easy ones (like EOL spaces and naming conventions for constants). Oh, okay! I'll run that... Some questions I had: - Why do you recommend to delete the profile (including UUID) after submission? Isn't one of the purposes of smolt support to be able to help individual users with hardware trouble (which would require knowing the UUID of the user)? It's not the we actually *recommend* to the user to delete the profile afterwards. It's just that they should have the option to delete it, if they want to. But yes, indeed: We'd need to know the URL to read the profile. - Is the privacy policy really large enough that we need to destroy the widget even while the section view is active? (If section views are kept in memory even after they got closed, that should be fixed rather than worked around). Uh, I looked at how the GPL was read in the about-my-computer screen and that's how they did it there. The privacy policy might be a little shorter, though. Suggestions: - Only show the section if smolt is actually installed (not all distros have it). Might need support on the Sugar side as this check is currently hardcoded for the keyboard and power sections. The latter one even checks for /ofw, but that's stuff for the OHM support thread, not this one. I put that in the __init__.py file: the control panel section only shows up when the smolt file executing the submission is present. - Don't store the handler ids of the GTK callbacks if you don't use them. We don't need to keep a reference in our code to protect them from garbage collection. - Maybe deactivate the Delete button if no profile is present? (Submitting a second time can be useful so that button should always be active). That should be doable, yeah. :) - Assuming smoltSendProfile is synchronous (i.e. doesn't finish until sending the profile has either been finished successfully or failed), you should run it in the background. The Sugar shell is currently a single process, so running synchronously will block everything. Yup yup, I'll look into that! - Check for smolt errors (rc, stderr) and relay them to the user. I marked the ticket as r?, so a review would be appreciated, too. Sending the patch to the mailing list makes it easier to review, so you'll get more feedback that way. My config is rather complicated because of the email address scheme I use, but maybe it shows you how to automate everything so sending the patch to the ML is as simple as typing a single git command. For patches that might need to be revised before they can be committed I use TopGit. git rebase -i is nice as well, but only works if you don't publish your repository. Thanks for all the feedback and hints, it's really appreciated! :) --Sebastian This is my ~/.gitconfig : [user] email = sascha-...@silbe.org name = Sascha Silbe [url gitori...@git.sugarlabs.org:] pushInsteadOf = git://git.sugarlabs.org/ [alias] send-to-ml-multi = !git send-email -s --annotate --summary --cover-letter --add-header=\Reply-To: Sascha Silbe sascha-ml-reply-to-$(python -c 'import time; t=time.gmtime(); print \%d-%d\ % (t.tm_year, t.tm_mon//4+1)')@silbe.org\ send-to-ml-single = !git send-email -s -p --stat --add-header=\Reply-To: Sascha Silbe sascha-ml-reply-to-$(python -c 'import time; t=time.gmtime(); print \%d-%d\ % (t.tm_year, t.tm_mon//4+1)')@silbe.org\ tg-send-to-ml-single = !tg mail -s \-p --stat --add-header=\\\Reply-To: Sascha Silbe sascha-ml-reply-to-$(python -c 'import time; t=time.gmtime(); print \%d-%d\ % (t.tm_year, t.tm_mon//4+1)')@silbe.org [sendemail] from = Sascha Silbe sascha-...@silbe.org chainreplyto = false signedoffcc = false suppressfrom = true confirm = always [color] diff = auto And this is (part of) my .git/config for sugar: [format] headers = Mail-Followup-To: sugar-devel@lists.sugarlabs.org [sendemail] to = sugar-devel sugar-devel@lists.sugarlabs.org envelopesender = sascha-ml-ui-sugar-de...@silbe.org Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org
Re: [Sugar-devel] [DESIGN] Fwd: #2063 UNSP: Sugar should bring up an alert when an unhandled Python exception occurs
Oh my this would need to be one subtle alert... It's one thing for testers/developers (I.e. fantastic) but quite another for spamming our target age range users! It would definitely need to be a control panel so folks can switch it on/off. Question: is this for Activities, Sugar, or both? 'Simple' proposal (from the UI side), how about an insect bug shaped icon notification that pulses for a few cycles in a corner (activity corner?) when a traceback hits. That could be enough so interested parties can go use Log, and the other 99.99% of users to at least recognised 'something just went wrong'. Regards, --Gary On 1 Jul 2010, at 10:52, Tomeu Vizoso to...@sugarlabs.org wrote: Any ideas about how it would look like? Regards, Tomeu -- Forwarded message -- From: Sugar Labs Bugs bugtracker-nore...@sugarlabs.org Date: Sun, Jun 27, 2010 at 20:20 Subject: #2063 UNSP: Sugar should bring up an alert when an unhandled Python exception occurs To: Cc: b...@lists.sugarlabs.org #2063: Sugar should bring up an alert when an unhandled Python exception occurs --+- Reporter: bernie | Owner: tomeu Type: defect | Status: new Priority: Unspecified by Maintainer | Milestone: Unspecified by Release Team Component: sugar |Version: Git as of bugdate Severity: Unspecified| Keywords: Distribution: Unspecified| Status_field: Unconfirmed --+- Many UX designers abhor the idea that the computer would scare off users with incomprehensible error messages. Ideally, we would have a 100% bug free system in which this never happens, but current today's is very different. Currently, users and are left wondering why some operation isn't doing anything and have no way to tell that their log is full of tracebacks. To keep things simple, I would suggest to print the exception message in a notification alert, and suggest users to open the Log activity for further details. -- Ticket URL: http://bugs.sugarlabs.org/ticket/2063 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Patches to mail list, or patches to trac?
Hi folks, Just wanted to ask the obvious question. Patches to mail list, or patches to trac? Patches to mail-list seem great for quick random 'easy' feedback from and for any one who cares to give it, and I really like seeing little code snippets go past. However it seems vital that with the current process we at least make a final closing stage (currently tickets in trac) where the hard final call can be made and the loop closed. Personally I read mail in a bunch of different places/devices and there's no way I can currently (and sanely) keep track of all the list activity and know who suggested what, what was actually agreed, and what is still outstanding. I've had a few patches and reviews now from kind folk posting to the mail-list, but for me, I've ended up having to ask folks to create git clones so I can pull in patches in a maintainable work flow. I dread to think what it must be like trying to look after several large core modules! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11-0.88 unmerged patches summary
On 1 Jul 2010, at 14:02, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Jun 30, 2010 at 03:57, Bernie Innocenti ber...@codewiz.org wrote: Here's an executive summary of all outstanding patches in my queue: http://people.sugarlabs.org/bernie/sugar/sugar-0.88-patches/ Most of these have already been submitted to sugar-devel@ or attached to tickets in bugs.sugarlabs.org. Some of these patches have outstanding quality issues, but all of them have been integrated and tested for a while in F11-0.88 and together contribute to a better Sugar experience. == Bugfixes == sugar-toolkit/use-set_toolbar_box-in-example-code.patch sugar-toolkit/set-default-accelerators-for-Copy-and-Paste-buttons.patch These have been ack'd by Alsroot. Do we also need Erikos' approval? No, as per http://wiki.sugarlabs.org/go/Development_Team/Code_Review#Discussion . sugar-toolkit/sl1842-notify-red-alert.patch Correct me if I'm wrong, but I think both Gary and James agreed? I wonder about performance, as fills on the XO-1 are very slow and if the fading was very smooth it could have a negative impact on the UX. Yes, I was half way through an email suggesting we drop the NotifyRedAlert and use the NotifyAlert in the original Journal write error patch. Avoid the controversy and still get the main patch fix in. We can always revisit the Notifications as a separate design cycle, but I don't think it's a critical feature for the needed fix. sugar/sl1842-journal-error-messates.patch The review has been swamped by a design discussion. It's not clear what Anish should do to pass review. Do you have a link to the controversy? sugar-toolkit/sl1948-Race-condition-with-name-widget-in-the-activ.patch This patch has a corner case in which it fails to update the activity name, but I think it's still a little better than the current behavior. See ticket for details. I guess you and Simon need to agree on which bad is better. sugar/add-font-dpi-schema.patch This is a companion patch of a fix sugar-settings-manager which has already landed in git. It's needed by xulrunner (Browse). Would be good if the commit message said why is that needed, or at least have a link to the ticket. sugar/avoid-popping-an-empty-list-in-the-software-updater.patch Works, but James Cameron's posted a better counter-patch. Merge that one. sugar/click-on-journal-icons-with-a-exclusive-time-frame.patch Requested by the Waveplace folks. Please merge. What happened to the check for activity_id? We have it in other places in the UI with the similar issue. sugar/dynamically-set-number-of-control-panel-columns.patch The approach to comoute the column width is wrong, but it produces better results than the current fixed number of columns. So, for now, I'm keeping it around. Anish has a better one already. sugar/fix-duplication-of-OLPC-mesh-icons.patch sugar/fix-for-file-list-sorting-for-FAT32-formatted-flash-drives-in-journal.patch All the above have no issues to my knowledge and should be merged. sugar/use-the-spanish-verb-quitar-for-unmounting-devices.patch Better-than-nothing patch, but the real fix would require a gettext kludge in the code (see http://bugs.python.org/issue2504 ) Shouldn't we make the change in Pootle? Or it will be synced automatically? Or maybe we should go with the kludge as the real fix is most likely to not land in 2.x. == Minor bugfixes == sugar-toolkit/fix-two-trivial-shell-log-warnings.patch Reviewed on sugar-devel, should be merged. sugar-toolkit/sl1876.patch Patch is in comment 2 of the ticket. It has been overlooked becuase the ticket had also an attachment. sugar/fix-name-clash-set_state.patch Should be merged. == New Features == sugar/backup-0001-Volumes-Backup-and-Restore.patch sugar/backup-0002-Journal-XS-backup-and-restore.patch There are concerns about restore deleting new entries since the last backup. I agree, but since nobody seems to have the time to implement and test a more sophisticated procedure, at this time this is the best restore feature we have for Sugar. Do we know any other deployment willing to deploy this? If we decide to merge it, I think it should be disabled by default and have a gconf setting, because knowingly shipping a feature that causes data loss may not be a good idea. Sounds fair. I was going to suggest making sure there was at least a second user action needed after hitting a backup or restore button (I skimmed through the patch code but couldn't see a conformation warning step). A warning notification with Cancel/Backup, and Cancel/Restore could help avoid some accidents. Regards, --Gary == Cleanups == sugar/simplify-the-definition-of-UpdateModel._bundles_to_check..patch Merge. sugar-toolkit/remove-incomplete-MANIFEST-support.patch The incomplete design and implementation of MANIFEST files has been
Re: [Sugar-devel] [DESIGN] Fwd: [PATCH] Browse: Add support for creating multiple tabs
On 1 Jul 2010, at 14:12, Tomeu Vizoso to...@sugarlabs.org wrote:
Any comments from the UX people? I hope the commit description is
enough for imagining how it looks like (and if Anish had a link to a
screenshot it would be great).
Yes a screen grab would be useful, but just wanted to say that there is already
an add tab toolbar icon already used in Terminal. Suggest we reuse it if
possible to keep UI consistency.
Regards,
--Gary
Regards,
Tomeu
-- Forwarded message --
From: anishmangal2002 anishmangal2...@gmail.com
Date: Tue, Jun 29, 2010 at 22:58
Subject: [PATCH] Browse: Add support for creating multiple tabs
To: lucian.brane...@gmail.com
Cc: to...@sugarlabs.org, sugar-devel@lists.sugarlabs.org,
anishmangal2002 anishmangal2...@gmail.com
This patch adds support to create multiple tabbed windows
in Browse. A tab may be added by either clicking the add tab
('+') icon in the activity toolbar or by pressing 'ctrl+t'.
Signed-off-by: anishmangal2002 anishmangal2...@gmail.com
---
icons/add-tab.svg | 86
+
webactivity.py| 11 +++
webtoolbar.py | 21 +
3 files changed, 118 insertions(+), 0 deletions(-)
create mode 100644 icons/add-tab.svg
diff --git a/icons/add-tab.svg b/icons/add-tab.svg
new file mode 100644
index 000..0220993
--- /dev/null
+++ b/icons/add-tab.svg
@@ -0,0 +1,86 @@
+?xml version=1.0 encoding=UTF-8 standalone=no?
+!-- Created with Inkscape (http://www.inkscape.org/) --
+
+svg
+ xmlns:dc=http://purl.org/dc/elements/1.1/;
+ xmlns:cc=http://creativecommons.org/ns#;
+ xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#;
+ xmlns:svg=http://www.w3.org/2000/svg;
+ xmlns=http://www.w3.org/2000/svg;
+ xmlns:sodipodi=http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd;
+ xmlns:inkscape=http://www.inkscape.org/namespaces/inkscape;
+ version=1.1
+ width=55
+ height=55
+ id=svg2
+ inkscape:version=0.47 r22583
+ sodipodi:docname=add-tab.svg
+ metadata
+ id=metadata10
+rdf:RDF
+ cc:Work
+ rdf:about=
+dc:formatimage/svg+xml/dc:format
+dc:type
+ rdf:resource=http://purl.org/dc/dcmitype/StillImage; /
+ /cc:Work
+/rdf:RDF
+ /metadata
+ sodipodi:namedview
+ pagecolor=#ff
+ bordercolor=#66
+ borderopacity=1
+ objecttolerance=10
+ gridtolerance=10
+ guidetolerance=10
+ inkscape:pageopacity=0
+ inkscape:pageshadow=2
+ inkscape:window-width=1280
+ inkscape:window-height=721
+ id=namedview8
+ showgrid=false
+ inkscape:zoom=4.2909091
+ inkscape:cx=27.5
+ inkscape:cy=27.033898
+ inkscape:window-x=0
+ inkscape:window-y=27
+ inkscape:window-maximized=1
+ inkscape:current-layer=layer1 /
+ defs
+ id=defs4
+inkscape:perspective
+ sodipodi:type=inkscape:persp3d
+ inkscape:vp_x=0 : 27.5 : 1
+ inkscape:vp_y=0 : 1000 : 0
+ inkscape:vp_z=55 : 27.5 : 1
+ inkscape:persp3d-origin=27.5 : 18.33 : 1
+ id=perspective12 /
+ /defs
+ g
+ transform=translate(0,-997.36218)
+ id=layer1
+rect
+ width=55
+ height=55
+ x=0
+ y=0
+ transform=translate(0,997.36218)
+ id=rect2818
+ style=fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none /
+rect
+ width=9
+ height=38
+ x=23
+ y=1005.8622
+ id=rect3599
+ style=fill:#ff;fill-opacity:1;stroke:none /
+rect
+ width=8.94349
+ height=37.99044
+ x=1020.3485
+ y=-47.595592
+ transform=matrix(-0.00107369,0.9942,-0.9889,-0.00148761,0,0)
+ id=rect3599-4
+ style=fill:#ff;fill-opacity:1;stroke:none /
+ /g
+/svg
diff --git a/webactivity.py b/webactivity.py
index 4be551e..5f4f917 100644
--- a/webactivity.py
+++ b/webactivity.py
@@ -152,6 +152,7 @@ def _set_accept_languages():
logging.debug('LANG set')
from browser import TabbedView
+from browser import Browser
from webtoolbar import PrimaryToolbar
from edittoolbar import EditToolbar
from viewtoolbar import ViewToolbar
@@ -443,6 +444,16 @@ class WebActivity(activity.Activity):
_logger.debug('keyboard: Zoom in')
self._tabbed_view.props.current_browser.zoom_in()
return True
+elif gtk.gdk.keyval_name(event.keyval) == t:
+browser = Browser()
+self._tabbed_view._append_tab(browser)
+if os.path.isfile(_LIBRARY_PATH):
+browser.load_uri('file://' + _LIBRARY_PATH)
+else:
+default_page = os.path.join(activity.get_bundle_path(),
+data/index.html)
+browser.load_uri(default_page)
+
return False
def
Re: [Sugar-devel] [PATCH] Journal Volumes Backup and Restore
On 29 Jun 2010, at 19:56, Martin Abente mabe...@paraguayeduca.org wrote: Martin and James, In case you haven't noticed, we know how it could be better and we know how the high level pseudo code would look like. We just can't do it, because we have no more time to spend on this. The backup and restore script are just a little part of this whole patch, and it would be _very_ helpful if someone could actually test it and review the code. Thanks for your comments, hopefully we or someone else will have the time to improve it, in the near future. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel On Thu, 1 Jul 2010 19:50:02 +0100, Gary Martin garycmar...@googlemail.com wrote: On 1 Jul 2010, at 14:02, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Jun 30, 2010 at 03:57, Bernie Innocenti ber...@codewiz.org wrote: == New Features == sugar/backup-0001-Volumes-Backup-and-Restore.patch sugar/backup-0002-Journal-XS-backup-and-restore.patch There are concerns about restore deleting new entries since the last backup. I agree, but since nobody seems to have the time to implement and test a more sophisticated procedure, at this time this is the best restore feature we have for Sugar. Do we know any other deployment willing to deploy this? If we decide to merge it, I think it should be disabled by default and have a gconf setting, because knowingly shipping a feature that causes data loss may not be a good idea. Sounds fair. I was going to suggest making sure there was at least a second user action needed after hitting a backup or restore button (I skimmed through the patch code but couldn't see a conformation warning step). A warning notification with Cancel/Backup, and Cancel/Restore could help avoid some accidents. Just posting on this email thread as well. Not being sarcastic here :-p genuine question, is there a trac ticket for this one? Some patches do, some patches don't. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] F11-0.88 unmerged patches summary
sugar-toolkit/sl1842-notify-red-alert.patch Correct me if I'm wrong, but I think both Gary and James agreed? I wonder about performance, as fills on the XO-1 are very slow and if the fading was very smooth it could have a negative impact on the UX. Yes, I was half way through an email suggesting we drop the NotifyRedAlert and use the NotifyAlert in the original Journal write error patch. Avoid the controversy and still get the main patch fix in. We can always revisit the Notifications as a separate design cycle, but I don't think it's a critical feature for the needed fix. Ok, how about a normal alert (no fancy colors), that doesn't get timed out, and displays an error icon beside the text. If that works for everyone, I'll send forth the patch. Currently there is no Alert class which doesn't timeout and has only one 'Ok' button. The closest is ConfirmationAlert (screenshot attached) http://people.sugarlabs.org/anish/sl1842.png -- Anish On Fri, Jul 2, 2010 at 12:20 AM, Gary Martin garycmar...@googlemail.com wrote: On 1 Jul 2010, at 14:02, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Jun 30, 2010 at 03:57, Bernie Innocenti ber...@codewiz.org wrote: Here's an executive summary of all outstanding patches in my queue: http://people.sugarlabs.org/bernie/sugar/sugar-0.88-patches/ Most of these have already been submitted to sugar-devel@ or attached to tickets in bugs.sugarlabs.org. Some of these patches have outstanding quality issues, but all of them have been integrated and tested for a while in F11-0.88 and together contribute to a better Sugar experience. == Bugfixes == sugar-toolkit/use-set_toolbar_box-in-example-code.patch sugar-toolkit/set-default-accelerators-for-Copy-and-Paste-buttons.patch These have been ack'd by Alsroot. Do we also need Erikos' approval? No, as per http://wiki.sugarlabs.org/go/Development_Team/Code_Review#Discussion . sugar-toolkit/sl1842-notify-red-alert.patch Correct me if I'm wrong, but I think both Gary and James agreed? I wonder about performance, as fills on the XO-1 are very slow and if the fading was very smooth it could have a negative impact on the UX. Yes, I was half way through an email suggesting we drop the NotifyRedAlert and use the NotifyAlert in the original Journal write error patch. Avoid the controversy and still get the main patch fix in. We can always revisit the Notifications as a separate design cycle, but I don't think it's a critical feature for the needed fix. sugar/sl1842-journal-error-messates.patch The review has been swamped by a design discussion. It's not clear what Anish should do to pass review. Do you have a link to the controversy? sugar-toolkit/sl1948-Race-condition-with-name-widget-in-the-activ.patch This patch has a corner case in which it fails to update the activity name, but I think it's still a little better than the current behavior. See ticket for details. I guess you and Simon need to agree on which bad is better. sugar/add-font-dpi-schema.patch This is a companion patch of a fix sugar-settings-manager which has already landed in git. It's needed by xulrunner (Browse). Would be good if the commit message said why is that needed, or at least have a link to the ticket. sugar/avoid-popping-an-empty-list-in-the-software-updater.patch Works, but James Cameron's posted a better counter-patch. Merge that one. sugar/click-on-journal-icons-with-a-exclusive-time-frame.patch Requested by the Waveplace folks. Please merge. What happened to the check for activity_id? We have it in other places in the UI with the similar issue. sugar/dynamically-set-number-of-control-panel-columns.patch The approach to comoute the column width is wrong, but it produces better results than the current fixed number of columns. So, for now, I'm keeping it around. Anish has a better one already. sugar/fix-duplication-of-OLPC-mesh-icons.patch sugar/fix-for-file-list-sorting-for-FAT32-formatted-flash-drives-in-journal.patch All the above have no issues to my knowledge and should be merged. sugar/use-the-spanish-verb-quitar-for-unmounting-devices.patch Better-than-nothing patch, but the real fix would require a gettext kludge in the code (see http://bugs.python.org/issue2504 ) Shouldn't we make the change in Pootle? Or it will be synced automatically? Or maybe we should go with the kludge as the real fix is most likely to not land in 2.x. == Minor bugfixes == sugar-toolkit/fix-two-trivial-shell-log-warnings.patch Reviewed on sugar-devel, should be merged. sugar-toolkit/sl1876.patch Patch is in comment 2 of the ticket. It has been overlooked becuase the ticket had also an attachment. sugar/fix-name-clash-set_state.patch Should be merged. == New Features == sugar/backup-0001-Volumes-Backup-and-Restore.patch sugar/backup-0002-Journal-XS-backup-and-restore.patch There are concerns about restore deleting new
Re: [Sugar-devel] F11-0.88 unmerged patches summary
On 1 Jul 2010, at 22:01, Anish Mangal anishmangal2...@gmail.com wrote: sugar-toolkit/sl1842-notify-red-alert.patch Correct me if I'm wrong, but I think both Gary and James agreed? I wonder about performance, as fills on the XO-1 are very slow and if the fading was very smooth it could have a negative impact on the UX. Yes, I was half way through an email suggesting we drop the NotifyRedAlert and use the NotifyAlert in the original Journal write error patch. Avoid the controversy and still get the main patch fix in. We can always revisit the Notifications as a separate design cycle, but I don't think it's a critical feature for the needed fix. Ok, how about a normal alert (no fancy colors), that doesn't get timed out, and displays an error icon beside the text. Hmm I don't think we have an official sugar error icon designed that I can remember... If we add an error icon it should be something we can use as standard else where where as needed. In my draft post, that never made it out as I replied to the related email from Tomeu instead, I was trying to flesh out what the distinction may be between various alert levels. Seems a foggy area right now, e.g. the discussions on backup/restore wipe all your work if you make a mistake type case is even more critical (in my mind at least) than a single Journal failed to write a file to USB case. Once we start adding levels of alertness - custom icons, colour, border thickness, strobe lighting, electric shock via touch pad ;) we seem fall into a trap of ongoing classification. If that works for everyone, I'll send forth the patch. Normal alert would work for me, way better than where we are now. I genuinely think we need the design team to chew over and detail sugar notifications/alerts needs again, work has been done, some implemented, some not, but it needs clarification, some goals set for implementing missing parts, and a nice wiki page with pretty pictures showing example use cases ;) BTW, what happens if a user tries a second time when an alert is already displayed? Not that this is anything to do with your patch, just wondering how it's currently handled in Sugar (the four possibilities; stacked alerts; 2nd alert appears after first is dismissed; 2nd alert is just ignored; something terrible involving virtual smoke and a reboot). Currently there is no Alert class which doesn't timeout and has only one 'Ok' button. The closest is ConfirmationAlert (screenshot attached) Could you use a longer timeout if you think the message is more critical? The Cancel/OK suggests it makes a difference what you click, and that you need to make a specific decision. FWIW: The timeout sugar style is so that folks that can't necessarily read text yet (or well enough) are not stuck with dialogue messages that are of no use to them anyway. Regards, --Gary http://people.sugarlabs.org/anish/sl1842.png -- Anish On Fri, Jul 2, 2010 at 12:20 AM, Gary Martin garycmar...@googlemail.com wrote: On 1 Jul 2010, at 14:02, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Jun 30, 2010 at 03:57, Bernie Innocenti ber...@codewiz.org wrote: Here's an executive summary of all outstanding patches in my queue: http://people.sugarlabs.org/bernie/sugar/sugar-0.88-patches/ Most of these have already been submitted to sugar-devel@ or attached to tickets in bugs.sugarlabs.org. Some of these patches have outstanding quality issues, but all of them have been integrated and tested for a while in F11-0.88 and together contribute to a better Sugar experience. == Bugfixes == sugar-toolkit/use-set_toolbar_box-in-example-code.patch sugar-toolkit/set-default-accelerators-for-Copy-and-Paste-buttons.patch These have been ack'd by Alsroot. Do we also need Erikos' approval? No, as per http://wiki.sugarlabs.org/go/Development_Team/Code_Review#Discussion . sugar-toolkit/sl1842-notify-red-alert.patch Correct me if I'm wrong, but I think both Gary and James agreed? I wonder about performance, as fills on the XO-1 are very slow and if the fading was very smooth it could have a negative impact on the UX. Yes, I was half way through an email suggesting we drop the NotifyRedAlert and use the NotifyAlert in the original Journal write error patch. Avoid the controversy and still get the main patch fix in. We can always revisit the Notifications as a separate design cycle, but I don't think it's a critical feature for the needed fix. sugar/sl1842-journal-error-messates.patch The review has been swamped by a design discussion. It's not clear what Anish should do to pass review. Do you have a link to the controversy? sugar-toolkit/sl1948-Race-condition-with-name-widget-in-the-activ.patch This patch has a corner case in which it fails to update the activity name, but I think it's still a little better than the current behavior. See ticket for details. I guess you and Simon need
Re: [Sugar-devel] Async schoolserver registration for F11-0.88
On 1 July 2010 18:00, Bernie Innocenti ber...@codewiz.org wrote: Martin, while you're working on adding the Re-register button in the Network control panel, would you have time to work on updating, integrating and testing the auto-registration patch attached to this ticket? http://bugs.sugarlabs.org/ticket/1152 Not sure if this is what you are suggesting, but it's not so clear cut if this should be applied to mainline sugar. It opens up a security hole where the entire contents of someones journal can be stolen. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OLPC/Open Video Chat Boston Hackfest
I would like to participate in the event. Name: Hernan Pachas City: Lima-PERU --hernan 2010/7/1 Taylor Rose (RIT Student) tjr1...@rit.edu *What* Open Video Chat will be returning to Boston July 8th for a HackFest at OLPC headquarters. If you'd like to come, contact us on the Open Video Chat mailing list (o...@lists.fedorahosted.org). We will be tackling farsight and telepathy-farsight to pave the way for cross platform communication. *When* July 8th @ 10am *Where* OLPC Headquarters 1 Cambridge Center Cambridge, Massachusetts *How* Come hack with us or participate remotely through our IRC channel (#rit-innovation on freenode.net ). Please send us an email to our mailing list with your full name by *Wednesday July 7th at midnight* so we can compile a guest list for the security desk Thursday morning. Facebook Event: http://www.facebook.com/?ref=logo#!/event.php?eid=13920529 9429364ref=tshttp://www.facebook.com/event.php?eid=139205299429364ref=ts Official Event Page: http://foss.rit.edu/events/ovchackfest http://foss.rit.edu/events/ovchackfest-Taylor Rose OVC Devel Team ___ 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] [Tecnologia] Async schoolserver registration for F11-0.88
El Thu, 01-07-2010 a las 18:53 -0600, Daniel Drake escribió: http://bugs.sugarlabs.org/ticket/1152 Not sure if this is what you are suggesting, but it's not so clear cut if this should be applied to mainline sugar. It opens up a security hole where the entire contents of someones journal can be stolen. What's the attack vector you're thinking about? Playing dirty tricks with DHCP and DNS on the LAN? Sadly true for many clients in many LANs... Wouldn't this also affect the manual registration case? How could we fix this without distributing keys to schoolservers? Given the current security model of the XS-XO interaction, which appears to be far from being secure in several ways, I would be inclined to add this one new flaw for the sake of convenience. Don't get me wrong, I *do* care much about security, but in order to achieve it we would need to rethink the entire network security model, not simply by bothering the users with a manual registration step which does not authenticate the schoolserver anyway. Would you agree? -- // 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
[Sugar-devel] [PATCH] fixes sl#2062
Hi all
ref http://bugs.sugarlabs.org/ticket/2062
Simple fix, have captured the exception that's raised and have told user to
connect to the nework:
This commit fixes sl#2062. This bug causes XS registrations
to fail silently when the XO is offline. The fix is to
catch the TypeError provide an alert to the user upon
failure.
---
src/jarabe/desktop/favoritesview.py |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/jarabe/desktop/favoritesview.py
b/src/jarabe/desktop/favoritesview.py
index aca945a..45fa305 100644
a b 323323except RegisterError, e: 324324
alert.props.title = _('Registration Failed') 325325
alert.props.msg = _('%s') % e326except TypeError: 327
# raised by xmlrpclib.py when XO attempts to 328# register
itelf while offline: sl#2062 329alert.props.title =
_('Registration Failed') 330alert.props.msg = _('Please try
connecting to '\ 331 'the network.') 326
332else: 327333alert.props.title = _('Registration
Successful') 328334alert.props.msg = _('You are now registered
' \
Index: src/jarabe/desktop/favoritesview.py
===
--- a/src/jarabe/desktop/favoritesview.py
+++ b/src/jarabe/desktop/favoritesview.py
@@ -323,6 +323,12 @@
except RegisterError, e:
alert.props.title = _('Registration Failed')
alert.props.msg = _('%s') % e
+except TypeError:
+# raised by xmlrpclib.py when XO attempts to
+# register itelf while offline: sl#2062
+alert.props.title = _('Registration Failed')
+alert.props.msg = _('Please try connecting to '\
+ 'the network.')
else:
alert.props.title = _('Registration Successful')
alert.props.msg = _('You are now registered ' \
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Tecnologia] Async schoolserver registration for F11-0.88
On 1 July 2010 20:07, Bernie Innocenti ber...@codewiz.org wrote: What's the attack vector you're thinking about? Playing dirty tricks with DHCP and DNS on the LAN? Sadly true for many clients in many LANs... Child connects to a network, perhaps just to go online outside of school. The network has an XS. The laptop registers. The journal is backed up to the server. Wouldn't this also affect the manual registration case? That's true but it's unlikely that the child would try to register outside of school. I think the current XO-XS communication is secure enough in the places where it needs to be. But registration indeed is a big problem and it could do with a rethink which would probably involve some kind of key-based auth to achieve the best results in terms of user experience. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] fixes sl#2062
On Fri, Jul 02, 2010 at 02:09:17PM +1200, Tim McNamara wrote: This commit fixes sl#2062. This bug causes XS registrations to fail silently when the XO is offline. The fix is to catch the TypeError provide an alert to the user upon failure. Trivial typo in second line of comment. s/itelf/itself Otherwise fine. Reviewed-by: James Cameron qu...@laptop.org -- 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] F11-0.88 unmerged patches summary
El Thu, 01-07-2010 a las 15:02 +0200, Tomeu Vizoso escribió: sugar-toolkit/sl1842-notify-red-alert.patch Correct me if I'm wrong, but I think both Gary and James agreed? I wonder about performance, as fills on the XO-1 are very slow and if the fading was very smooth it could have a negative impact on the UX. Looks smooth even on my XO-1... sugar/sl1842-journal-error-messates.patch The review has been swamped by a design discussion. It's not clear what Anish should do to pass review. Do you have a link to the controversy? I agree with Gary's proposal of using only NotifyAlert for the time being. Anish, what do you think? sugar-toolkit/sl1948-Race-condition-with-name-widget-in-the-activ.patch This patch has a corner case in which it fails to update the activity name, but I think it's still a little better than the current behavior. See ticket for details. I guess you and Simon need to agree on which bad is better. It's hard to dedice which one is less incorrect. I tried to come up with a perfect fix by checking for a title change one more time from the Stop button, which sounds like a straightforward approach. However, I quickly got to a difficulty that I couldn't solve without breaking encapsulation or subverting the design: the Stop button and the TitleEntry widgets don't know about each other, but StopButton would have to peek into TitleEntry to find what the current title is. Because many activities build the activity toolbar manually, one widget at a time, there's no way to ensure that the StopButton instance will have a reference to TitleEntry instance. Perhaps Gtk offers an easy way to find other widgets by name in the widget tree of a window, but it smells like a horrible kludge. Eventually, I gave up on this approach because it seemed overly complicated for fixing this bug. You know Gtk much better than me: is it possible that there's no sure way to get notified when the user has finished editing a gtk.Entry? The editing-done signal implemented by the GtkCellEditable sounds perfect, but it only fires when the user presses enter in the widget so it's useless for us. sugar/add-font-dpi-schema.patch This is a companion patch of a fix sugar-settings-manager which has already landed in git. It's needed by xulrunner (Browse). Would be good if the commit message said why is that needed, or at least have a link to the ticket. sugar/avoid-popping-an-empty-list-in-the-software-updater.patch Works, but James Cameron's posted a better counter-patch. Merge that one. sugar/click-on-journal-icons-with-a-exclusive-time-frame.patch Requested by the Waveplace folks. Please merge. What happened to the check for activity_id? We have it in other places in the UI with the similar issue. You mean in the Activity() class of jarabe? It seems that activity_id gets initialized after the activity brings up its window, which leaves several seconds of time for a user to open two instances with a double-click. (I'm not very familiar with this code, excuse me if I'm misunderstanding the context) sugar/use-the-spanish-verb-quitar-for-unmounting-devices.patch Better-than-nothing patch, but the real fix would require a gettext kludge in the code (see http://bugs.python.org/issue2504 ) Shouldn't we make the change in Pootle? Or it will be synced automatically? Good question, I don't know if Pootle syncs bidirectionally. I would expect it to, but better ask Sayamindu. Or maybe we should go with the kludge as the real fix is most likely to not land in 2.x. Indeed. (though the bug has been moving forward a little) sugar/backup-0001-Volumes-Backup-and-Restore.patch sugar/backup-0002-Journal-XS-backup-and-restore.patch There are concerns about restore deleting new entries since the last backup. I agree, but since nobody seems to have the time to implement and test a more sophisticated procedure, at this time this is the best restore feature we have for Sugar. Do we know any other deployment willing to deploy this? The original code was contributed by Uruguay, so I guess they would like to use it. sugar/use-the-spanish-verb-quitar-for-unmounting-devices.patch Better-than-nothing patch, but the real fix would require a gettext kludge in the code (see http://bugs.python.org/issue2504 ) If we decide to merge it, I think it should be disabled by default and have a gconf setting, because knowingly shipping a feature that causes data loss may not be a good idea. Sounds like a good compromise. The backup/restore strategies are decoupled from the dialogs. Having the infrastructure in git might motivate others to come up with improved approaches. (though I suspect that any non-destructive approaches will likely be complicated or break in several common scenarios) sugar-toolkit/kill-the-delayed-menus-for-good.patch This change has been at the center of a huge design / UX / testing flame war a
[Sugar-devel] Question about slider key codes
I was modifying Paint to change the tool size using the slider keys. I used the the keys to change the size in a relative form. The first key reduce the size by 5, the second reduce by 1, the third enlarge by 1 and the fourth enlarge by 5. Then I talked with Walter, he told me, you can use the slider with seven values. Pressing the key 1, 1 and 2, 2, 2 and 3,3,3 and 4, etc. Also the original plan was use the Fn key with the slider. I thought use the slide without Fn to set absolut sizes, and with Fn to modify relatively the sizes. (I don't know if is a good idea). But I have two problems: * I don't have key events when I press two slider keys simultaneously. * I don't have key events when I press the Fn key and the slider keys. Anybody knows what can I do? Where is the definition of the codes for the OLPC keyboard? (for example we have PgUp and PgDown in the arrows using Fn) It's posible to have a event when you press two slider keys? (In a PC keyboard are F5 to F8) Thanks Gonzalo Links http://wiki.laptop.org/go/Keyboard_definitions http://wiki.laptop.org/go/OLPC_Spanish_Keyboard http://www.linuxquestions.org/questions/linux-software-2/creating-custom-keyboard-definition-file-649255/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Question about slider key codes
G'day, That's a good question, I confirm your observations, and I agree that it will be something between the keyboard and the kernel if you want fn to work. I've tested just now, with os205 on XO-1.5. The slider keys individually provide Pygame key events for key down and key up. Pressing slider key 1 and 4 at the same time results in four events; two for each key. This is expected. Pressing any combination of a slider key and the immediately adjacent slider key generates only two events for one key. This is odd. There is an area between key 1 and key 2 where you can press down with normal force and no events are generated. Also, pressing fn with any slider key gives no event at all. For Pygame. Also, in text console, running showkey shows events for slider keys, but no events for fn key. Slider key events stop if fn is pressed. So I guess that it isn't possible to capture events in the way Walter suggested. This is also verified using test /keyboard at the ok prompt. fn works fine, but repeated presses on the slider at various points shows the isolation behaviour; you can't press two at once easily. If you press very hard, you can get two at once. Placing an XO-1 C2 on scales, it takes 75g of downward pressure to activate single slider keys, and 850g to 1.3kg of downward pressure to activate two slider keys at once. This is an adult smallest finger. I don't think pressing two keys with one finger is practical. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
