12:05 a.m.
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/