Re: Control Center Shell and libslab



Scott Reeves wrote:
Denis Washington wrote:
Hi everyone,

Thomas Wood and I wrote a few patches for the new control center shell(see http://mail.gnome.org/archives/gnomecc-list/2006-November/msg00002.html). Because 90% of the shell's internals are in libslab, the patches mainly or only involve changes in that library. My question now is: should we do this forking of SLAB (i guess at least my patch especially is one ...

Thomas Wood <thos gnome org> 11/28/2006 5:36 AM >>>
I spoke to Rodrigo and Seb about this briefly on IRC. Rodrigo also
suggested forking SLAB, but I would still like some feed back from the
current authors about their opinion. Seb is in favour of just going
ahead and making changes, since the code is now in GNOME cvs.

Thanks for your patches and input on these issues. I am certainly open to forking if we have to but I would prefer not to and I think our end look is close enough we should not need to. Lets hit the issues.

Context menu – there are two problems with the context menu that need to be solved. First most of the menu entries (and some other functionality like closing behavior and common tasks) require a gconf key to work properly. A lot of these gconf keys are being installed by the gnome-main-menu module not the libslab subset.  Since SLED installed the entire module (and a couple others) not just the libslab subset that g-c-c now installs, this was unfortunately not addressed until just recently. We had just finished isolating the set of gconf keys that need to be installed by libslab and are moving them over.  Second, the code needs to have sane fall back behavior for all the keys if they are not set. Some of them work correctly now – like the upgrade and uninstall context menu options that you don't see in your menu because those keys don't exist so the option does not show in the menu. The rest need to be fixed.  Hopefully we can get all that committed here shortly and you could look at it then and see what you think.

Search watermark – I agree a clear button would be useful and the watermark is not recognizable to stock gnome users.  See final comment

Color and bolding – no issue to go with common gnome look for bold. And we definitely want to follow the users current theme. I thought we were actually. I will bounce this off the design team and get back with a response quickly.



Thank you for your will to give us a chance to "GNOMEify" libslab. It certainly would be the best if there is no need for any forking.

One thing about the color: it follows the theme in some kind of way, but doesn't use the theme's default background color. This is fine for the SLED theme, but for instance with the Ubuntu Human theme the sidebar's color is a not very nice grey (see attachment in http://mail.gnome.org/archives/gnomecc-list/2006-November/msg00002.html). But maybe this is also a theme issue.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]