Re: Hard code freeze break for gnome-panel for centered clock

[Lucas Rocha <lucasr gnome org>]

Hi,

2011/3/31 Matthias Clasen <matthias clasen gmail com>:
> On Thu, Mar 31, 2011 at 3:16 AM, Vincent Untz <vuntz gnome org> wrote:
>> Hi,
>>
>> I've pushed a branch to make it possible to have the clock centered by
>> default:
>>  http://git.gnome.org/browse/gnome-panel/log/?h=wip/packed-objects
>>  (starts at "panel: When creating an object, explicitly specify how
>>   it's packed")
>> This is for https://bugzilla.gnome.org/show_bug.cgi?id=631553 (minimize
>> differences between shell & fallback), which is marked as important.
>>
>> This actually changes a few things to make this possible:
>>  - change the way applets are positioned: instead of having an absolute
>>    position for each of them, we now simply pack them at the
>>    start/center/end of a panel. (Ryan wanted this, and he got it)
>>  - change the schema, since the old keys were actually not good for
>>    that. This change means that a user who used gnome-panel 2.91.93
>>    will have all panel layout broken on update; but it's rather easy to
>>    fix by just moving the applets again.
>>  - center the clock by default.
>>
>> In my tests, it work quite well, and it's actually useful to help the
>> users keep a clean panel. It also fixes a bunch of bugs where the
>> applets were not at the right place after a screen resize, or after
>> moving a panel.
>>
>> There are some unrelated fixes in the branch, though. They'd be nice to
>> have, but not strictly necessary:
>>
>>  - Apply delayed GSettings before unref'ing it to not lose change:
>>    http://git.gnome.org/browse/gnome-panel/commit/?h=wip/packed-objects&id=75fe30f62bb06c4afda64857207710dd88483224
>>
>>  - Add ranges to schemas to avoid invalid settings:
>>    http://git.gnome.org/browse/gnome-panel/commit/?h=wip/packed-objects&id=ea08f1b0dcdd77c209150871ad2e957b06c3531e
>>
>> Overall, this makes the fallback mode look much closer to gnome-shell,
>> which is quite nice.
>>
>> FWIW, doc team was fine with a change like this, and there's no string
>> change involved.
>>
>> Opinions?
>
> Obviously risky to continue taking this amount of change a few days
> away from the release.
> I hope that you and Ryan are careful about testing things.  I'll try
> to find some time to read through the changes later.
>
> Here is my proposal: Land these changes now, do a release that we can
> push out into distros to get at least some exposure. Then, if you get
> the user menu done, we can repeat that procedure tomorrow...

I agree with Matthias' suggestion.

--lucasr