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 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 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 on the list, but nobody >>>> implemented >>>> them, so this one still stands. >>>> >>>> >>>> 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 >>>> while ago. I've merged it to observe user reactions, so >>>> hopefully we can have a polite discussion based on some real data. >>> >>> I would go with whatever deployers decide. >>> >>>> sugar/backup-0003-Journal-documents-volume-button.patch >>>> >>>> We no longer need this feature since we decided to disable Gnome, but other >>>> deployments may find it useful. (but journal crashes when you drop files on >>>> the icon) >>>> >>>> >>>> == Patches with outstanding issues == >>>> >>>> sugar-datastore/0001-Add-ctime-and-timestamp-properties-to-the-index.patch >>>> >>>> sugar-datastore/0002-Add-migration-from-DS-v0-code-for-the-new-properties.patch >>>> >>>> sugar-datastore/0003-increment-CURRENT_LAYOUT_VERSION-to-trigger-an-index-rebuild.patch >>>> sugar/sizelist-0000-cover-letter.patch >>>> sugar/sizelist-0001-Journal-Retrieve-filesize-from-the-datastore.patch >>>> sugar/sizelist-0002-Add-a-filesize-column-to-the-journal-list-model.patch >>>> >>>> sugar/sizelist-0003-Journaltoolbox-Add-add_separator-method-for-convenie.patch >>>> >>>> sugar/sizelist-0004-Add-a-ListViewButton-to-the-journal-search-toolbar.patch >>>> sugar/sizelist-0005-Rename-the-date-column-to-sort_column.patch >>>> sugar/sizelist-0006-Display-the-sorting-property-in-the-last-column.patch >>>> sugar/sizelist-0007-Expandedentry-Try-to-use-the-filesize-property.patch >>>> sugar/sizelist-0008-Implement-sorting-for-removable-devices.patch >>>> >>>> sugar/sizelist-0009-Add-sort-by-creation-time-option-to-the-ListViewButt.patch >>>> sugar/sizelist-0010-Add-ctime-property-to-the-journal-model.patch >>>> >>>> Andres' series for sorting the journal by size. There's an outstanding >>>> problem with ctime being an integer rather than a string, as expected >>>> by Etoys. Andres is working on a fix. >>> >>> Is Aleksey ok with merging this? >>> >>> Regards, >>> >>> Tomeu >>> >>>> sugar-toolkit/sugar-toolkit-dont-configure-fonts.patch >>>> sugar/sugar-enable-settings-manager.patch >>>> >>>> We had to temporarily exclude these because sugar-settings-manager does >>>> not yet work well on F11-0.88. >>>> >>>> >>>> == Obsolete patches == >>>> >>>> sugar/pe558-add-option-to-mount-any-user-directory-to-journal.patch >>>> sugar/pe558-backup-restore-front-end-for-control-panel.patch >>>> sugar/pe558-journal-management-control-panel-feature.patch >>>> sugar/pe558-modify-volumnestoolbar-to-mount-a-directory.patch >>>> >>>> This patch set has been replaced by Tincho's Journal-based backup/restore >>>> functionality. Keeping these patches around in case someone else prefers >>>> the control panel UI. >>>> >>>> -- >>>> // 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 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 >> _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
