[Sugar-devel] F11-0.88 unmerged patches summary

[Anish Mangal]

>> 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 <bernie at 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 at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>