>> 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... > >
Nice! >> > 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? Its fine by me. I'll release the patch later today (NotifyAlert, 20 sec timeout, without an icon). This would be a minimum fix done with the premise that there will be a more detailed discussion on this (and the general sugar notification scheme) in the future.. -- Anish On Fri, Jul 2, 2010 at 10:35 AM, Bernie Innocenti <ber...@codewiz.org> wrote: > 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 >> > 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. > > I received no comments so far. I'll ask my testers to give an opinion > whether they like it more this way after a few days of adjustment. > > They also did not say anything about the hot-borders for the frame being > disabled by default. > > >> > 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? > > If I interpreted correctly, he was reluctant to put more work into the > current Journal UI because it must be rewritten from scratch to solve > some fundamental performance and extensibility issues. > > However, it doesn't seem like this will happen in time for 0.90... so > perhaps it won't hurt? > > NOTE: the current implementation conflicts with etoys' usage of ctime > and fails to upgrade the index format from version 4 (what 0.88 uses). > Andres is working on fixing both these issues. > > -- > // 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
