Re: Module Proposal: GNOME Shell
On Sat, 2010-04-03 at 13:57 +0200, Frederic Peters wrote: Is Gnome dropping support for these operating systems ? I am sorry my only answer at the moment is I wish not, but I am not familiar enough with the state of graphic drivers, not even on Linux, to know how wishful thinking it is. For a modern computing environment, access to hardware graphics acceleration is a must-have requirement. OS X and Windows 7 both require hardware graphics acceleration to enable their full user experience. Where they have the option (and I think only Windows 7 does this), they degrade to what is essentially a legacy mode. We've seen with the Compiz project how lower level support can be improved once a requirement is made. The chicken and egg situation has to be broken at some point and I think GNOME 3 gives a good opportunity to do that. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: A different point of vision (was: Appearance capplet)
On Wed, 2009-11-11 at 17:05 -0500, William Jon McCann wrote: So, the needs-to-be-written Universal Access panel would likely have some overlap here. I was under the impression that such an applet was frowned upon by the accessibility folks, as it may lead to a ghetto-izing of accessibility options? Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
On Tue, 2009-11-10 at 10:18 +0100, Xavier Claessens wrote: So if you agree/disagree with those changes, please tell your opinion! I would like to know if I'm the only one to be worried. Well, I'll repeat what I said on the bug: I agree with McCann, if someone wants to tweak their settings in such a way, then it should be done through an appropriate tweaks application. The interface tab does not contain options that are of interest to the majority of users. Please don't revert the status of bugs to unconfirmed. The bug status is fixed since the issue reported in the bug has been fixed. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RE: Appearance properties
On Tue, 2009-11-10 at 11:14 +0100, Olivier Le Thanh Duong wrote: I agree with Xavier. In the bug report they say this should be moved to a tweak application but isn't this capplet already a tweak application? A tweak application is would be one that changes little-used and low importance preferences. The Appearance capplet includes three sections. Background is probably most used, Font is of high importance (for accessibility) and Theme is probably a medium priority preference. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
On Tue, 2009-11-10 at 08:01 -0500, Jud Craft wrote: I actually enjoy most of the new changes (I like the simpler menus), but I miss being able to change the toolbar style. The 2.28 text-beside is nice, but I prefer the old text-under. Is that really such a forbidden use case? It's not forbidden and in fact, in 2.28, you can still change this option through the appearance capplet. In 2.30, if you still want to change this option, you can open gconf-editor, navigate to the /desktop/gnome/interface/toolbar_style key and set it to the value you want (both). Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Trying a new toolbar style
Hi folks, We've had a discussion on gnomecc list about removing the Interface tab from the appearance capplet (see discussion¹ in the archive for reasoning). However, before we do so, we would like to ensure the the defaults are correct. The main reason for the tab being there at all is because people felt the defaults are probably incorrect. The main default we would like to change is the toolbar style settings. I have suggested¹ that there is broad support for the text beside icons style, however there have been concerns that not all applications implement it properly. It is important to note that in this mode, only the most important toolbar items get text labels. PLEASE TRY THIS OPTION BEFORE YOU COMMENT - A LOT OF PEOPLE DO NOT REALISE THAT ONLY SOME TOOLBAR BUTTONS GET LABELS IN THIS MODE. Therefore, I would like to propose a trial period with this setting set to the new value, to give a chance for maintainers to ensure their applications work correctly. I have (regrettably rather hastily) already made the change to libgnome and I have opened a bug 590143 to discuss any issues. Regards, Thomas ¹ http://mail.gnome.org/archives/gnomecc-list/2009-July/msg00015.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Trying a new toolbar style
On Wed, 2009-07-29 at 15:51 +0200, Johannes Schmid wrote: PLEASE TRY THIS OPTION BEFORE YOU COMMENT - A LOT OF PEOPLE DO NOT REALISE THAT ONLY SOME TOOLBAR BUTTONS GET LABELS IN THIS MODE. Hmm, yes that definitely looks different than I expected. And just to help anyone who doesn't have the chance to try out the changes, I've put up some screenshot comparisons here: http://blogs.gnome.org/thos/2009/07/29/toolbar-styles/ Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Trying a new toolbar style
On Wed, 2009-07-29 at 10:41 -0400, Matthias Clasen wrote: While I am all for dropping the interface tab, I think it is silly to ignore the results of distros which have already tried this change and found it to not work. The problem was that several apps did not implement it properly. This is why I suggest a trial period where we can file bugs/fix those apps that do not work correctly. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Trying a new toolbar style
On Wed, 2009-07-29 at 15:06 +, Stef Walter wrote: Thomas Wood wrote: We've had a discussion on gnomecc list about removing the Interface tab from the appearance capplet (see discussion¹ in the archive for reasoning). How will we enable 'Editable menu shortcut keys'? Hopefully you won't, since this option is totally broken due to the lack of any universal way to revert changes made to shortcut keys. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] Mousetweaks usability discussion
On 31 Oct 2007, at 13:54, Denis Washington wrote: On Wed, 2007-10-31 at 13:44 +0100, Rodrigo Moya wrote: On Tue, 2007-10-30 at 19:20 +0100, Vincent Untz wrote: Le samedi 13 octobre 2007, à 14:25 +0200, Francesco Fumanti a écrit : Hello, [...] I have made a mockup that integrates Mousetweaks settings into the mouse capplet: http://ultimum-projekt.de/mockups/mouse.html I hope I haven't forgotten everything. Comments? Did we discuss combining acceleration and sensitivity at one point? I've never really understood the difference between the two (or rather, I've never decided how each one affects my own usage). Would it be possible to just have one slider that adjusts the two values in a sane way? Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Getting the Current Theme's Colors
On Fri, Sep 21, 2007 at 11:09:18AM +1000, Matthew Allen wrote: Hi, I'm integrating Lgi, a xlib based application framework, with the Gnome desktop. And I want to be able to make an Lgi application sensitive to the current theme's fonts and colors so that is blends in with the Gnome desktop. I've worked out how to query for the right system font to use. But I'm having a lot of trouble getting information about how to retrieve the theme's color scheme. I think I need to use gtk_style_lookup_color or maybe the color-hash property of the GtkStyle object. But I can't find any example code and the documentation is too brief. For instance gtk_style_lookup_color has a string parameter color_name, but absolutely no description of what possible values you might be able to pass into it. The sorts of colors I need are the selection bg/fg color, text fg/bg, application workspace etc. If you have access to the GtkStyle object, you might as well use the GdkColor arrays in the struct directly. For example, style-base[GTK_STATE_SELECTED] will give you the background colour for selected text in an entry widget. Symbolic colour schemes are a relatively new addition to GTK+, so I would avoid using them directly. It is much safer to use the bg/fg and base/text arrays to get colour information from the theme. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On GNOME 2.22: the rise of a revamped platform and desktop
On Sun, 1 Jul 2007 01:57:03 +0300 Lucas Rocha [EMAIL PROTECTED] wrote: Hi all, I've blogged this but I thought it would be good to send to d-d-l for further discussions. http://blogs.gnome.org/lucasr/2007/07/01/on-gnome-222-the-rise-of-a-revamped-platform-and-desktop/ [...] A small point, but you may wish to run a spell checker over that. oportunity = opportunity interation = iteration There are some other grammar issues, but I know you're not a native English speaker. ;-) Otherwise, it makes for positive reading. After a bit of a lull it seems there is some real new development and drive in core GNOME technologies, which can only be a good thing. Perhaps also mentioning some of the current activity around GTK+ with regards to formalising and driving the development process would be good? All in all, it would make a good GNOME Journal article. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Background gradient not being applied until I run preferences dialog
On 11/04/07 14:07, Jonathan Kamens wrote: Greetings, Some time while I was mucking with my settings to try to switch window managers to see if that would fix the problem I was having with Xaw button translations, my desktop background gradient stopped being applied when I log in. My background remains completely black until I run the desktop background preferences dialog; when the dialog starts up, the background is updated to the correct gradient and I just close it without changing any settings. Sounds like whatever alternative session you're using is not starting gnome-settings-daemon, as this is what applies the background settings (amongst other things). When you open a preference window, it will automatically start gnome-settings-daemon if it is not already running. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sticky Windows
On 08/04/07 21:16, adel wrote: On 4/8/07, Thomas Wood [EMAIL PROTECTED] wrote: On 08/04/07 21:02, adel wrote: GNOME desktop needs something like this http://www.donelleschi.com/stickywindows/ We look forward to your implementation then. -Thomas using Java? You can write it in whatever language you want! Whether it will be accepted into GNOME is an entirely different matter. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sticky Windows
On 08/04/07 21:02, adel wrote: GNOME desktop needs something like this http://www.donelleschi.com/stickywindows/ We look forward to your implementation then. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dropping bug-buddy reports for old version of gnome automatically
On 07/04/07 16:13, Paolo Borelli wrote: Hi, [...] Personally I am not able anymore to handle my bugmail anymore and even useful bugreports get lost in the noise. I usually mark any Crash: ... bugmail as read without even looking at it nowadays. As a first step, what do you think of just dropping silently at least crash reports from older versions of gnome? All bugs coming from there are either already fixed or will be reported anyway if still present in newer versions. Is there any way to do it non-silently? There needs to be something to at least inform the user they have an ancient version of GNOME and should consider upgrading. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Do you use multiple gnome-keyring keyrings?
Nope, never used the multiple keyrings. It never occurred to me that I would ever want more than one keyring either. -Thomas On 06/04/07 17:57, Nate Nielsen wrote: Do you or anyone you know use multiple password keyrings [1] in gnome-keyring? That is do they store their passwords in anything but the default keyring? I'm taking a good hard look at gnome-keyring and how to fit in a certificate store, and perhaps other technologies in the future. The multiple keyring support seriously complicates any design [2]. I'm interested in neutering functionality. If you have a use case, or actual use for multiple keyrings I'd love to hear from you. Disclaimers: * Obviously I'm not looking into removing the 'session' keyring [3]. * Any changes would happen in a ABI compatible manner. Cheers, Nate Nielsen [1] gnome-keyring-daemon supports having multiple keyrings. Each of these store a set of passwords/secrets. Each is encrypted on disk with its own 'master' password. One of these is the 'default' keyring. The 'default' flag can currently be switched on the fly. [2] http://live.gnome.org/GnomeKeyring/Cryptoki [3] The 'session' keyring stores passwords/secrets for the duration of the user's login session. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: doesn't the session splash disappear too soon?
On 04/04/07 07:36, Elijah Newren wrote: On 4/4/07, David Prieto [EMAIL PROTECTED] wrote: Hi, I've noticed that when I power on my laptop the session splash after the GDM lasts only some 3 or 4 seconds, but even after that the desktop background takes another 3 or 4 to appear, them 5 to get the panel and another 5 or so to get the panel applets and be able to actually use the computer. I've talked to other users and they find the issue annoying too. Shouldn't the session splash last almost until you have an usable desktop? http://bugzilla.gnome.org/show_bug.cgi?id=74508 Ugh, can't we get rid of the splash screen yet? -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: doesn't the session splash disappear too soon?
On 04/04/07 09:59, Frederic Crozat wrote: Le mercredi 04 avril 2007 à 09:31 +0100, Thomas Wood a écrit : [...] Ugh, can't we get rid of the splash screen yet? I don't think it is a good idea : a lot of people don't have fast as light systems which give you a working desktop 2s after typing your password. Splash is still a way to tell those people (me included) that their system is working ;) Well, I usually don't give up on my system unless I've been waiting for 10 seconds or more. I can't actually find any example of another desktop system (other than KDE) that has a splash screen between login and presenting the desktop. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-theme-manager and gnome-background-properties
The correct mailing list to discuss Control Center issues is [EMAIL PROTECTED] Please direct your suggestions there. Regards, Thomas David Prieto wrote: Hi, As I see it, the wallpaper is a part of the desktop theme. Is there a good reason not to have the background manager integrated into the theme manager, as just one more tab? I'm attaching two mockups of how the thing should ideally look like. The desktop colour chooser is moved from the background tab to the colours tab, wich A) makes more sense IMO, and B) saves space in the wallpaper tab and makes it less cluttered, while takes some space in the almost empty colours tab. I have created a bug about the issue: http://bugzilla.gnome.org/show_bug.cgi?id=423314 Please comment. Regards, David. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Desktop sounds in Gnome
Richard Hughes wrote: On 19/03/07, Étienne Bersac [EMAIL PROTECTED] wrote: So, will gnome 2.20 play nice sound when disk is burn, sound volume increased, mail received/sent, new RSS item available, etc. ? Would the system sounds be themable like icons are ? It would be great to theme these like we can icons. gnome-power-manager just needs to play a battery low chime, and linking to gstreamer seems very heavyweight. I love the fact that OS X has just one system beep sound. It makes things super simple from a user perspective. Do we really need, and do users really care about, different sounds for questions, information, battery low, etc. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
Behdad Esfahbod wrote: On Tue, 2007-03-06 at 22:31 +0100, Vincent Untz wrote: Hi, [...] It would be really great if all maintainers could take 10 minutes and check that all of their main contributors are listed in there. To do so, open this URL and look for the name of your contributors: http://svn.gnome.org/viewcvs/gnome-desktop/trunk/gnome-about/contributors.h?view=markup If there are some missing contributors, send me a private reply with the names of those contributors. I'll make sure to add them before 2.18.0. If we really must have a gnome-about dialog, shouldn't the contributors list be kept up to date automatically? If it has to be updated manually then it's only going to go out of date again for the next release. Perhaps all svn account holders and foundation members (past and present?) should be automatically added to the list? This would also encourage people to become foundation members. It also has the benefit that each of the names would have been verified as having made a significant contribution. On Tue, 2007-03-06 at 17:01 -0500, Luis Villa wrote: And I'll buy a $BEVERAGE_OF_CHOICE for anyone who makes the dang thing sexy and less slow in 2.19.0. This is 2007; if our about box doesn't optionally utilize GL, surely we've failed. :) I suggest we give MacSlow (CC'ed) till the end of the week to come up with something uber sexy. I'll give it a lame try if he doesn't. I thought this was GNOME we're talking about. We do professional software, not pointless eye-candy, right? I'm not saying professional looking software has to be boring, but there seems to be a tendency to go over the top with GL effects on the desktop at the moment. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: http://www.gnome.org mentioning FOSDEM in Germany
Damien Sandras wrote: Hello, http://www.gnome.org has a mention about FOSDEM (great), happening in Brussels. However, it mentions Brussels is in Germany. Just for information, Brussels is located in Belgium. See http://en.wikipedia.org/wiki/Brussels Thanks to fix it :-) Well spotted! At least we know someone reads the front page now and again. Should be fixed in a few minutes. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Suggestion: New Control Centre disabled by default in GNOME 2.18 (was: New Control Centre)
Alex Jones wrote: Hi list I'd like to suggest that the new Control Center be disabled by default in GNOME 2.18, but that it be enabled by GConf option and refined a bit more before it's pushed onto the mainstream user. Thank you for your suggestion. We are already discussing this on the gnomecc-list. Regards, Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: some more questions on the control center shell, etc
Calum Benson wrote: On Wed, 2007-01-24 at 17:43 +, Thomas Wood wrote: Calum Benson wrote: Of course if we'd tackled that problem first, we might not have needed to switch back to a shell at all :/ Change back? I thought people had agreed that in the long run the menus were not a good idea, and that a usable shell was much nicer? There didn't appear to me to be any overwhelming consensus in the recent desktop-devel discussion, but admittedly I was probably reading it through menu-tinted spectacles :) Ok, put another way, there weren't any massive objections :-) The current shell is not perfect and it still has issues that need to be ironed out, but I don't think that any blocker issues cannot be resolved before release. Are we suggesting that even if we had a perfect shell, it would still not be more usable and accessible as using a menu? [...] As I've said before, I always use the menus rather than the shell on both OS X and Windows when I'm using those, so yes, I'm biased in that sense. All I can say is that I did audibly mutter an expletive when I had to open the control center shell on Ubuntu for the third time in two minutes the other night, rather than pick straight off the menu, and it's a very long time since a GNOME UI feature made me do that :) If people really believe that the menu options are still the most user-friendly way of getting to the preference capplets, then we should enable that by default. I hope that the control center shell will be easily accessible to those people who prefer it (where as it was not in the past). I am reluctant to say make it an option, because it is so obvious we are creating an option due to lack of effective decision making and design direction. This really brings me on to another point Sri made when I was speaking to him on IRC. He used the term interface churn when I happened to ask his opinion on the new control center shell. He made the point that every time we change something in our UI, businesses and users will have to spend time and money retraining. Not to mention any books or guides that give examples about our desktop go instantly out of date. The change to the control center interface will mean that every single distribution that carries user documentation will have to be updated. We seem to have a really difficult time deciding on changes to our user interface (gnome-main-menu discussion for example). How do we move forward with UI improvements when we face these problems? Do we need a group of trusted and motivated people to approve design changes? -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Theme package mime type in 2.18
One of the new features in GNOME 2.18 is that the theme manager will be associated with a specific mime type for theme packages (application/x-gnome-theme-package, file suffix .gtp). There is nothing new here, as it uses exactly the same gzipped tarball format and directory layout as we have been using in the past, but now we can specifically open and install themes with the theme manager. If anyone has any final comments on the chosen mime-type and extension, now would be a good time to make them. Please note that an extension such as .theme was not chosen because it is already in use elsewhere on the desktop, and is also too generic to specify what the file actually is. See these bugs for more information: * http://bugzilla.gnome.org/show_bug.cgi?id=393697 * http://bugzilla.gnome.org/show_bug.cgi?id=149346 -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Theme package mime type in 2.18
Bastien Nocera wrote: On Fri, 2007-01-26 at 17:29 +, Thomas Wood wrote: One of the new features in GNOME 2.18 is that the theme manager will be associated with a specific mime type for theme packages (application/x-gnome-theme-package, file suffix .gtp). Fine with me. Do you install a .xml file with the mime-type definition yourselves? If not, you should :) Yessir, we do :-) -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Recolorable themes
Bouncing my original e-mail (below) to desktop-devel, as I didn't have any replies on gnome-themes-list. Basically, I think I am now going to have to take the saving custom colour schemes feature out of the theme manager capplet, since there has been no decision on the best place to save this information (one name field, and six key/value pairs). I can see three options at the moment: 1) save the information in gconf somewhere 2) Save in a custom xml format file in ~/.gnome2/color_schemes.xml (similar to the way the gnome background manager saves the current background settings) 3) Save a ini format file in ~/.gnome2/color_schemes.ini (in a similar was to index.theme) I think it would also be nice to be able to read a set of alternative schemes from the index.theme file, which has the added bonus of allowing the scheme names to be translated. If we can reach a consensus on this, then I'd be happy to finish the implementation before next weekend. I'd also like (if possible) someone to do a UI review on the new Colors tab before next weekend. There is a bug open http://bugzilla.gnome.org/show_bug.cgi?id=382517 for HIG fixes, but it hasn't had any comments for some time. -Thomas Thomas Wood wrote: On 9 Dec 2006, at 05:13, Matthias Clasen wrote: [...] Would it be possible for themes to be able to suggest alternate named schemes? Thats probably something to be solved between the yet-to-be written color capplet and the meta-theme file. I'm still trying to think about how to solve this one. Would adding an xml file to the gtk+-2.0 directory have any adverse ramifications? Not as far as GTK+ is concerned. How will these xml files relate to the existing metatheme desktop files ? Would it be easier to just add the colors to these files instead ? This had been my first thought as well. However, I wanted to associate colour schemes to a particular GTK+ theme, rather than to the metatheme. For GNOME 2.18 however, the only feature that will be available to the user is saving their local custom colour schemes. At the moment, there are several ways this could be implemented. We can save the schemes to keys in gconf or we can save the schemes to a file. For saving to a file, it could be an xml or .desktop format file in $HOME/.gnome2/colour_schemes. I think there are advantages and disadvantages to both methods, so I would like to know if anyone has any strong opinions either way. -Thomas ___ gnome-themes-list mailing list gnome-themes-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-themes-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing control center menus
Ross Burton wrote: On Tue, 2006-12-12 at 11:18 +, Thomas Wood wrote: The gnome-control-center hackers have been hard at work integrating the work done at Novell into making a nice shiny new shell for the control center. This time it is very much more usable, and we would like to propose that we replace the Preferences and Administration menus in the System menu with a single link to the new control center shell. There is always the possibility of adding a gconf key that will allow users to revert back to the old behaviour. Of course, we wouldn't like to do this without the full support of the GNOME community, so we invite all your comments and thoughts. Some screenshots of the new system would be good for people like me who are not running a full GNOME 2.17 desktop. I didn't include screenshots because there is still work to be done in terms of making it more acceptable to GNOME users (for example, we have patches pending to making it more compliant with the current theme). However, if you search for SLED control center or application browser you will get some idea of how it is going to look. The main purpose of my e-mail was to gauge the reaction to removing the menus and replacing them with a link to a shell window. If the reaction is mainly positive it will give us the motivation to polish off the new shell, and make sure the appropriate accessibility and usability audits are completed before switching over. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing control center menus
David Bolter wrote: If it is indeed very much more usable, then you have my vote as long usable includes accessible. http://developer.gnome.org/projects/gap/ By usable I nearly meant has enough features to be useful. Accessibility and usability audits would, of course, be a prerequisite to making any changes at all. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing control center menus
Gustavo J. A. M. Carneiro wrote: On Ter, 2006-12-12 at 11:51 -0500, Jonathan Blandford wrote: On Tue, 2006-12-12 at 15:26 +0100, Étienne Bersac wrote: A menu longer that 10 entry is very painful. Often, Gnome properties menu is about 20 entry when you install some additionnal softwares. Gnome is the only desktop which keep using this outdated control-center. A control center is far more usable and accessible (especially if it provide search). This also could mean that we have too many capplets. Agreed. But even if we can't get away from a multitude of capplets, there's an alternative solution: add an extra level of preferences categories, as we do for the applications menu. Four clicks to get to a preference window? Sounds a bit excessive. We had the discussion about the number of capplets already on the control center list. It was generally agreed that it would be nice to merge some of them, but (as far as I know) all except one of the suggestions had problems. And after that, the biggest issue is finding some developers with enough time to actually do the work. I do think using a shell window is easier than a menu, especially when it has search and filter features. It is also likely to be more familiar to users coming from other desktops. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gtk-engines has been branched
The gtk-engines modules has been branched. The stable branch is now gtk-engines-2-8 and jhbuild module sets have been updated. Development will now start in head, and will require gtk+ 2.10. The targets for the gtk-engines 2.10 release are to add gtk+ colour scheme support to all the themes, and to polish the appearance of some of the engines. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Notifications for build release issues: gnome-control-center
Elijah Newren wrote: On 10/20/06, Davyd Madeley [EMAIL PROTECTED] wrote: In many respects, jhbuild _is_ the dependency tree for building GNOME. A mode like `jhbuild list` will give you a list of packages you need to build. It would be easily possible to put the output of this command on a webpage if people thought they needed that. Also worth noting is that you can get the exact list of modules tarball version number for a given tarball release (in addition to getting a valid build order), if you have jhbuild installed, via the command jhbuild -m http://download.gnome.org/teams/releng/2.16.1/gnome-2.16.1.modules list -r (replacing both instances of '2.16.1' with the appropriate gnome version you are interested in). Of course there are a couple 'virtual' modules in the list, but they all begin with 'meta-' and thus can easily be removed. If there are people that would find this information useful, it shouldn't be hard to put up on a page somewhere. Is there anything other than build order, module list, and version numbers that are needed for ISVs/ISDs wanting to build GNOME? I think information about which dependencies are mandatory and which are optional would be very helpful. Optional dependencies are probably even more important, as they are the hardest to discover. There's a lot of good information in the releng directory, but I doubt people know about it. We need a system to generate some nice html pages for each release detailing all of the above information in a nice readable format. Did anyone ever have anything to do something like this? -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity Compositor
Havoc Pennington wrote: BJörn Lindqvist wrote: On 10/4/06, Rob Adams [EMAIL PROTECTED] wrote: The effort required to add eye candy effects to metacity is much smaller, in my opinion, than the effort required to make compiz a good, usable window manager. Most of the effects code is likely to be reusable in metacity and KWin; compiz makes for a good experimental Are you sure? Compositing in Metacity has been in progress at least since August 2004. It doesnt seem like a small effort. I don't think in progress is very accurate, at least I have not seen a lot of code going in, granted I haven't been paying huge amounts of attention. I don't understand why it would be a huge effort for 2D stuff like minimize animations, drop shadows, etc. Think xrender rather than opengl. But, I have not really been involved in the conversations about it and can't say I have a deep understanding. Ditto, which is why I haven't mentioned this, but I have been wondering why people are equating compositing with 2D OpenGL effects. I really want to have a composite manager so I don't have to shudder each time I move a window and watch it redraw. Would it not be possible to have a really simple compositing manager in Metacity? This seems much more in tune with Metacity's remit than anything else (perhaps drop shadows and a nice minimise animation are the only two things I would improve). -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clarius
Shaun McCance wrote: On Tue, 2006-08-29 at 10:01 +1200, Glynn Foster wrote: Hey, Shaun McCance wrote: I'm going to coin a new term: key churn. This is when people make frivolous and unnecessary changes to GConf keys or their default values. It sucks for large deployments. Gnome is bigger than your personal desktop. I don't really care too much about the name change, but what I do care about is the migration story between themes as new engines/icons/whatever are dropped in and out. This stuff isn't as smooth as it should be - hopefully Calum can provide details of what currently happens [we documented this for an ARC case recently]. I don't care about the name change out of some phonetophilic adoration of the word Clearlooks. I care because of the problems it introduces. Scenario 1) I have, at some point, explicitly set my theme to Clearlooks, rather than getting Clearlooks from the GConf default value. I upgrade to Gnome 2.16. What happens? You get the Clearlooks theme, that is installed by gtk-engines. Interim 1) I utter some choice words about the ugly boxiness of the default GTK+ rendering. But I'm pretty clever, so I go to the theme manager, find Clarius, and switch. Clarius is now explicitly set as my theme in GConf. You don't get the ugly default GTK+ rendering, because you already have Clearlooks installed. Scenario 2) I go to use another machine that's mounting the same NFS home directory, or is otherwise getting the same GConf values. This machine is running Gnome 2.14, which doesn't include Clarius. The same thing would happen if you went to a machine running a Gnome version prior to that which Clearlooks was available in. Or if you selected a theme that you have installed locally, or any other combination of possibilities. I think it is slightly unreasonable to assume we can never add new themes. Interim 2) I utter some choice words and post a flame to Slashdot and/or OSNews. I go to the theme manager and change my theme back to Clearlooks. Scenario 3) I go back to do some work on the machine that's running Gnome 2.16. See scenario 1. It's running Clearlooks, but with a slightly updated appearance. Friends don't let friends churn keys. I know several people have already pointed out the relevant points about the change, but I just want to reassure you I did consider these scenarios before I made the changes. There were several reasons for the change. Firstly, I wanted to make sure we didn't go through appearance churn. The new cairo based clearlooks engine provides several changes to the UI. I wanted to make the 2.16 appearance more consistent with the 2.14 appearance. I also had several people mention to me that they did not want Gnome to go down the glossy appearance route. It was therefore critical that the glossy scrollbars were toned down before the release. Unfortunately I was under the impression that I made this change before the UI freeze, which I now realise was incorrect. Secondly, the change did not affect any translatable strings, so I assumed it did not affect the string freeze. The reason I felt it necessary to make our own gtk+ theme (in gnome-themes, rather than relying on the one provided by gtk-engines), is that we probably will want to make more conservative changes in the future than the author of Clearlooks wants to make. Having spoken to Richard about this problem (unfortunately he has been very busy and we didn't get a chance to discuss it before), he seems willing to keep the Clearlooks gtkrc as conservative as Gnome wants it, and put more exciting changes into a separate gtkrc. With the permission of the release team, I would be happy to revert the changes, and change the one line that makes the scrollbars blue in the Clearlooks gtkrc. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-themes and licensing
Josselin Mouette wrote: Le samedi 15 avril 2006 à 13:16 +0100, Thomas Wood a écrit : Personally, I think it's understandable that artists may choose not to distribute their work under the (L)GPL, which is primarily a license for software. As long as the license they choose upholds the values of Free Software, I don't see it as a problem. However, I know there have been various lengthy discussions elsewhere about the status of the Creative Commons licenses, so I would like to have some advice before continuing. I think I would ask those people to wait for the 3.0 version of the Creative Commons licenses, which promise to solve a number of small issues[1] that were raised with 2.0 and which are still present in 2.5. Do you happen to know if there is any time scale for 3.0? I'd really like to get started on revamping gnome-themes, but I can't do it unless I can distribute the themes under a more appropriate license. If it's likely that a 3.0 CC license is not going to be available before 2.16, are there any other licenses that might be suitable to meet the needs of artists and distributors such as Debian? -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK+ 2.10 on track for GNOME 2.16?
Jeff Waugh wrote: quote who=Matthias Clasen I am still trying to get 2.9 releases out before the end of April, although it is looking a bit tight. Need to get the async filechooser branch merged first. As soon as that has happened, I'll go into release mode... Does it feel/look like you'll meet the May target mentioned in the 2.10 plan page? I'd start feeling uncomfortable if it slipped much beyond May or June, from our previous experiences with synching GTK+ and GNOME releases. There's great stuff in 2.10 that would be disappointing to miss out on. :-) I'd like to start implementing a UI for setting colour schemes in the theme capplet, but I obviously don't want to introduce a GTK+ 2.10 dependency to control-center, and then have to roll it back later. It'd be nice if we could have a firm commitment on this sooner rather than later. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-themes and licensing
With 2.16 now underway, I thought it was about time to give the gnome-themes module a bit of a revamp. However, many of todays artists want to use licenses other than the GPL to distribute their work (for example, the Creative Commons By Attribution license[1], or the Free Art license[2]). This would mean that parts of the gnome-themes module would no longer be GPL or LGPL. What I need to know is what impact this would have on distributors, and on the module's status in GNOME. Personally, I think it's understandable that artists may choose not to distribute their work under the (L)GPL, which is primarily a license for software. As long as the license they choose upholds the values of Free Software, I don't see it as a problem. However, I know there have been various lengthy discussions elsewhere about the status of the Creative Commons licenses, so I would like to have some advice before continuing. -Thomas [1] http://creativecommons.org/licenses/by-sa/2.0/ [2] http://artlibre.org/licence/lal/en/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-themes and licensing
Alan Cox wrote: On Sad, 2006-04-15 at 13:16 +0100, Thomas Wood wrote: With 2.16 now underway, I thought it was about time to give the gnome-themes module a bit of a revamp. However, many of todays artists want to use licenses other than the GPL to distribute their work (for example, the Creative Commons By Attribution license[1], or the Free Art license[2]). This would mean that parts of the gnome-themes module would no longer be GPL or LGPL. This would only matter if the license was not GPL or LGPL compatible. Freer than LGPL ought to be fine. The Free Art license allows restriction of modification rights, which appears to make it non-free if used (like the GNU document license mess), and cannot be combined with non-free programs using the desktop, so would create the ludicrous situation of the theme manager forcing the user to change theme when they ran say realplayer, or they installed the mp3 plugin It is also subject to French law alone and from the translation looks like it would have serious problems in any other jurisdiction - for example most countries would not recognize the french law requirement, and since there is no legal statement about how the license fails if a clause is invalid the entire license probably goes with it. A second consideration is that themes also contain code so the GPL or LGPL boundary there must be respected whether it applies to artwork that depends upon the code or not. Actually, gnome-themes itself no longer contains any source code. The engines where separated out into gtk-engines some while back. The only type of files found in gtk-engines should now be images and text files. The only binary data installed by gnome-themes would be any PNG images. The FSF keeps some good information on licenses and compatibility - eg creative commons. The FSF recommends[1] not to use any Creative Commons licenses, but to use the Free Art license as an alternative. It then states the the Free Art license is incompatible with the GNU GPL and GNU FDL, and advices not to use it. It seems the only license they recommend is one of their own as they state that all the licenses are incompatible. So the problem still is that many artists no longer want to use the GPL, and the FDL isn't ideal for artwork either. So are we stuck with using the GPL for artwork to avoid any problems? If it was clear what license each theme or file in the gnome-themes module was under, would this prevent any problems distributors might have? -Thomas [1] http://www.fsf.org/licensing/licenses/index_html#OtherLicenses ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Overall State of Documentation [was Re: Gnome is a problem for OEMs]
Jeff Waugh wrote: [...] I wouldn't mind writing the first level specs as a SoC project, in fact. - Jeff Wasn't library.gnome.org a SoC project last year, and no one picked it up? -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: requesting official list of modules and versions for GNOME 2.14
Matthias Clasen wrote: On 2/9/06, Shaun McCance [EMAIL PROTECTED] wrote: On Thu, 2006-02-09 at 10:58 +0100, Vincent Untz wrote: On Thu, February 9, 2006 10:41, Davyd Madeley wrote: On Thu, Feb 09, 2006 at 09:10:55AM +0100, Vincent Untz wrote: + gtk-engines: I quickly looked at the archives and couldn't find a mail related to it (ie there's no mail with engines in the subject ;-)). Is the issue a possible slowdown caused by the use of cairo? We have two issues here: (a) speed issues caused by Cairo; and (b) changes in the default theme (which while may be popular are also unpopular with others) Isn't be an issue in the theme (and not the engine)? Well, the new Clearlooks entails both the Cairo-enabled Clearlooks engine in gtk-engines and the Clearlooks theme data in gnome-themes. Both the engine and the theme data have changed. The theme data is probably setting a few things that are new to the engine, but most notably, it's using a brigher and more saturated set of colors. Both the engine and the theme data are responsible for point (b). The engine is responsible for point (a). Until somebody sits down and does measurements to show that use of cairo in theme engines is responsible for measurable slowdowns, this is just guesswork. Is there any way of reliably profiling gtk engines? As far as I am aware there is no way (short of actually placing hooks in the engine) of knowing when the engine has finished painting a widget or window. If anyone can think of a good way of profiling the speed of a theme, I would be very interested to know. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
Davyd Madeley wrote: On Wed, Feb 08, 2006 at 02:41:16PM +, Calum Benson wrote: On Wed, 2006-02-08 at 08:56 -0500, Luis Villa wrote: Just wanted to say, Calum (and perhaps others listening in) that I firmly believe that, done right, the UI reviews can be very, very useful. It is clear that we're not doing it very well, though- perhaps it needs to be more proactive, and earlier in the cycle? If we're going with the new Clearlooks, does that need any sort of UI or a11y review? I know that there have been sweeping changes. There is a lot more blue. Looking at what appears to be the default new-Clearlooks: there are some highly visual changes that perhaps we should reconsider (I feel that sweeping change from release to a release is a bad thing). I have not talked to any of the Clearlooks guys yet, but was it planned to make the theme looks more like it did last release (with nice gradients) or to keep it the way it is? There has been a general objection to the new 'glossy' look, and it would be possible to revert it. However, I haven't done so since I thought we were in the UI freeze, and changes to the default theme would probably not be welcome unless they where major usability issues or such like. I would really welcome more input from people on this subject - but please, on the correct list! If you'd like to discuss theme issues, please do so on gnome-themes-list. I would be glad if we had a few usability people on the list too. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
Pat Suwalski wrote: Thomas Wood wrote: I was thinking of doing some work on the theme manager UI for 2.16. Should the theme manager be switched to explicit apply too? It often takes more than a second to apply a theme. The best way to see what your desktop will look like is to click one of the themes and see what your desktop looks like! There's a handy revert button, and it should be quite discoverable to click back on the theme that was previously selected. Is this not the case? This isn't really the issue. The problem is that the apply procedure takes more than a second to complete, thus violating the previously mentioned section of the HIG about instant apply. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Performance (was Re: control-center 2.13.90 released)
Christian Fredrik Kalager Schaller wrote: Hi, Do we have a general performance problem currently? My Fedora Rawhide (FC5) desktop is slow as hell atm. I thought at first it was a distribution/development edition issue, but talking to people running Dapper at the office they are experiencing the same. One example, starting Totem for the first time takes about 30 seconds on my system now. Stopping and restarting totem multiple times lets me get that down to around 8-10 seconds. Christian It'd be interesting if you could try changing your theme (I assume you are using Clearlooks) to Glider and seeing what difference that makes. The Glider theme uses the Smooth engine, which is not currently using cairo. Clearlooks on the other hand, is now using cairo almost exclusively. If there is a significant difference in speed then we may need to look at holding back cairo enabled gtk-engines in GNOME, at least until significant speed improvements are made to cairo. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: control-center 2.13.90 released
James Livingston wrote: On Tue, 2006-01-31 at 14:38 +, Thomas Wood wrote: This isn't really the issue. The problem is that the apply procedure takes more than a second to complete, thus violating the previously mentioned section of the HIG about instant apply. I saw a figure quoted that the average time to apply was 1.4 seconds. How did that get evaluated? The machine I'm on at the moment isn't old, but it definitely isn't that new either, and it takes under half a second to change the background. I was talking about the theme manager, and asking whether it should also be switched to explicit apply. If you could time how long it takes to apply a theme on your machine, that would be a useful figure to have. One thing I noticed is that the time is greatly affected by whether Nautilus is drawing the desktop or not. I normally don't, but when turned on the time was up to around a second. Drawing the icons and text might take extra time, but is there something Nautilus is doing that causes it to go that much slower? Cheers, James Doc Livingston ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Performance (was Re: control-center 2.13.90 released)
Jan de Groot wrote: On Tue, 2006-01-31 at 15:31 +, Thomas Wood wrote: It'd be interesting if you could try changing your theme (I assume you are using Clearlooks) to Glider and seeing what difference that makes. The Glider theme uses the Smooth engine, which is not currently using cairo. Clearlooks on the other hand, is now using cairo almost exclusively. If there is a significant difference in speed then we may need to look at holding back cairo enabled gtk-engines in GNOME, at least until significant speed improvements are made to cairo. -Thomas I switched back from Clearlooks cairo version to the Mist theme: everything is nice and fast now. With cairo-clearlooks, clicking a cleared number in gnome-mines, I could follow the bombsquad clearing the field of known not-mine squares. With Mist, these fields get uncovered instantly. Actually, Mist is already using cairo, so your test only shows that Mist is a faster theme than Clearlooks. This was hopefully already known, since Mist is a lot simpler than Clearlooks. One of the biggest problems for Clearlooks in terms of speed, is it's use of gradients, and that has always been an issue whether it has used GDK or cairo. To get a definitive answer, we need people to test is the difference between using Clearlooks with cairo (gtk-engines 2.7.x) and with GDK (gtk-engines 2.6.x). -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-backgrounds has been branched
The gnome-backgrounds modules has been branched. Bug fixes and translations for the 2.12.x releases should now be committed to the gnome-background-2-12 branch. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
High Contrast Icons
There has been a discussion on gnome-themes-list about how we can improve the coverage of the high contrast icon theme. It was generally agreed that it was unrealistic to try and maintain icons for every application within GNOME in the high-contrast-theme itself. The alternative is that individual applications should be responsible for installing a high contrast icon into the high contrast theme. If an application calls itself accessible, having high contrast icons should be one of the requirements. Applications are allowed to install icons into the hicolor theme; if we're really taking accessibility seriously, then high contrast themes should have a similar status to hicolor. The work for individual application maintainers is minimal. Most icons can simple be removed from the high contrast theme and added to their respective modules. Does anyone have any comments on this idea, and how we can encourage maintainers to include high contrast icons? Accessibility is one of the cornerstones of GNOME, so it would be a shame to let it slip on this issue. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gtk-engines branched
The gtk-engines module has been branched for 2.6 to allow exciting new Cairo based work to begin in HEAD. However, we do not yet anticipate a 2.8 release in time for GNOME 2.12, so users and developers building GNOME 2.11/2.12 from CVS should use the gtk-engines-2-6 branch. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up themes
On 30 Jul 2005, at 5:18 am, Davyd Madeley wrote: I'm sure I've brought this up before, but I think we should clean up the list of themes we ship for G2.12. Looking at the default list, we appear to have: Clearlooks, Glider, Mist, and Simple which are all pretty good themes, and should stay in by default. Then we have Crux, Default (which is not), Grand Canyon, Ocean Dream, Traditional, and Smokey Blue Perhaps we should consider moving these into the -extras package. What I think would be really cool is having a level of integration that allows you to install themes right off art.gnome.org from your favourite web browser. That way we could ship our 4 very nice themes, and everyone can install whatever else they want with ease. Very rapidly integrated with web backgrounds, and one day web-shipped applets. gtk-engines has had a number of bugs filed for both Crux and Ocean Dream (lighthouseblue) recently, so it's possible quite a few people still use these themes. There was also talk of including Industrial in gnome-themes at some point, since it no longer has a permanent home. It is already possibly to install themes straight from art.gnome.org by dragging and dropping the links into gnome-theme-manager. What would be ideal would be a new mime-type for gnome themes, and a proper file format for themes too. Then we could do the install (and possibly apply) straight form clicking on a link. I made several suggestions on a file format and mime-type for gnome themes a while ago, but it didn't get much further than a few ideas on paper. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up themes
Owen Taylor wrote: On Sat, 2005-07-30 at 16:58 +0200, uws wrote: På Sat, Jul 30, 2005 at 02:52:30PM +0200, Murray Cumming skrev: On Sat, 2005-07-30 at 12:18 +0800, Davyd Madeley wrote: I'm sure I've brought this up before, but I think we should clean up the list of themes we ship for G2.12. Maybe for 2.14/2.14, but I'm not personally going to approve this feature-freeze break. It's bad enough that the change of the default theme has taken this long. Well, maybe it'd be ok to remove the non- default default. If the default is just the built-in theme in GTK+ (no way to check now, no X over here), I think a rename to Built-in is the best. The Red Hat packages have renamed this theme to Raleigh for a long time to avoid having a non-default Default. (It is derived from the Raleigh theme we did for GTK+-1.2) Regards, Owen Here are two patches to rename the Default theme to Raleigh. One patch alters GTK+ to install the default gtkrc into the Raleigh directory, and the other one patches gnome-themes so that the Traditional metatheme uses Raleigh rather than Default. Changing the name of the default gtk themes may break existing configs and uses. However, GTK+ will always fall back to the default theme if Default is not found, so this would not cause any problems. -Thomas Index: desktop-themes/Traditional/index.theme.in === RCS file: /cvs/gnome/gnome-themes/desktop-themes/Traditional/index.theme.in,v retrieving revision 1.1 diff -u -p -r1.1 index.theme.in --- desktop-themes/Traditional/index.theme.in 30 Jan 2003 22:42:25 - 1.1 +++ desktop-themes/Traditional/index.theme.in 30 Jul 2005 21:28:48 - @@ -5,6 +5,6 @@ _Comment=Traditional hard-edged 3D appea Encoding=UTF-8 [X-GNOME-Metatheme] -GtkTheme=Default +GtkTheme=Raleigh MetacityTheme=Atlanta IconTheme=gnome Index: gtk/Makefile.am === RCS file: /cvs/gnome/gtk+/gtk/Makefile.am,v retrieving revision 1.275 diff -u -p -r1.275 Makefile.am --- gtk/Makefile.am 29 Jul 2005 14:06:02 - 1.275 +++ gtk/Makefile.am 30 Jul 2005 21:29:20 - @@ -688,16 +688,16 @@ endif # Install a RC file for the default GTK+ theme, and key themes install-data-local: install-ms-lib install-def-file - $(mkinstalldirs) $(DESTDIR)$(datadir)/themes/Default/gtk-2.0 - $(INSTALL_DATA) $(srcdir)/gtkrc.default $(DESTDIR)$(datadir)/themes/Default/gtk-2.0/gtkrc - $(mkinstalldirs) $(DESTDIR)$(datadir)/themes/Default/gtk-2.0-key - $(INSTALL_DATA) $(srcdir)/gtkrc.key.default $(DESTDIR)$(datadir)/themes/Default/gtk-2.0-key/gtkrc + $(mkinstalldirs) $(DESTDIR)$(datadir)/themes/Raleigh/gtk-2.0 + $(INSTALL_DATA) $(srcdir)/gtkrc.default $(DESTDIR)$(datadir)/themes/Raleigh/gtk-2.0/gtkrc + $(mkinstalldirs) $(DESTDIR)$(datadir)/themes/Raleigh/gtk-2.0-key + $(INSTALL_DATA) $(srcdir)/gtkrc.key.default $(DESTDIR)$(datadir)/themes/Raleigh/gtk-2.0-key/gtkrc $(mkinstalldirs) $(DESTDIR)$(datadir)/themes/Emacs/gtk-2.0-key $(INSTALL_DATA) $(srcdir)/gtkrc.key.emacs $(DESTDIR)$(datadir)/themes/Emacs/gtk-2.0-key/gtkrc uninstall-local: uninstall-ms-lib uninstall-def-file - rm -f $(DESTDIR)$(datadir)/themes/Default/gtk-2.0/gtkrc - rm -f $(DESTDIR)$(datadir)/themes/Default/gtk-2.0-key/gtkrc + rm -f $(DESTDIR)$(datadir)/themes/Raleigh/gtk-2.0/gtkrc + rm -f $(DESTDIR)$(datadir)/themes/Raleigh/gtk-2.0-key/gtkrc rm -f $(DESTDIR)$(datadir)/themes/Emacs/gtk-2.0-key/gtkrc # if srcdir!=builddir, clean out maintainer-clean files from builddir ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clearlooks and GNOME 2.12
On 20 Jul 2005, at 11:38 pm, James Henstridge wrote: On 20/07/05 19:17, Thomas Wood wrote: On 19 Jul 2005, at 10:26 pm, Danilo Šegan wrote: Today at 22:42, Richard Stellingwerff wrote: Personally, I'd really prefer to keep distributing standalone packages, since it allows me to do more frequent releases. Nobody would object if gtk-engines got more frequent releases. :) In fact, I'm planning a release soon, since I've just closed quite a number of outstanding bugs. Incidentally, this will be the 5th gtk-engines release in 7 months, compared to no releases in the 2 years previously. Why are you including modules that are maintained externally anyway? I think the original plan was to eventually maintain clearlooks in gtk-engines. Clearlooks was still quite experimental at the time, so the idea was to have a stable version in gtk-engines, and allow the developers to continue experimenting elsewhere. Now that clearlooks is more stable, perhaps it would be possible for the developers to have cvs access to gtk-engines. If you find bugs in clearlooks, are you fixing them in gtk-engines or are you feeding them to the official maintainers? If you are fixing them locally, how are you resolving conflicts when merging later on? It seems like it would remove all these synchronisation problems if gtk-engines only contained engines that were maintained within gtk-engines. Including a theme whose engine is not in gtk-engines isn't really a bad thing. gtk-engines is already required by gnome-themes, so rather than adding yet another dependancy, I think including Clearlooks in gtk-engines saves hassle for both users, developers and distributors. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clearlooks and GNOME 2.12
On 19 Jul 2005, at 10:26 pm, Danilo Šegan wrote: Today at 22:42, Richard Stellingwerff wrote: Personally, I'd really prefer to keep distributing standalone packages, since it allows me to do more frequent releases. Nobody would object if gtk-engines got more frequent releases. :) In fact, I'm planning a release soon, since I've just closed quite a number of outstanding bugs. Incidentally, this will be the 5th gtk-engines release in 7 months, compared to no releases in the 2 years previously. I.e. this should not impact a decision, since if clearlooks is included and maintained inside gtk-engines, you could ask for releases as often as you wish, or even more likely, do them yourself. I can't imagine anyone complaining about someone else doing the work :) Not at all, I would be more than happy for you to maintain clearlooks in gtk-engines. If there have been any updates since the last time gtk-engines was updated with your development version of clearlooks, let me know and we can go about updating it before the next release. I'm not terribly aware of the release schedules and procedures of GNOME. As I understand, a few weeks before the new release there will be a feature freeze. How would this apply to Clearlooks? You'd switch to bug fixing mode for around two months. New development might happen on another branch (HEAD), while this one is stabilised. Though, I'm not sure if gtk-engines follows Gnome or Gtk+ schedule (they're different). We're sort of following the Gtk+ schedule in that we're currently using our major/minor version number to indicate which version of Gtk+ we require (i.e. 2.6 at the moment). However, we're releasing a micro version every time there have been a number of bugs fixed, rather than sticking to any timed schedule. -Thomas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
