Re: Plan to fix icons [was: Re: breakage caused by removed icons from gnome-icon-theme]
Il giorno lun, 06/02/2006 alle 21.57 -0500, Matthias Clasen ha scritto: On 2/6/06, Jeff Waugh [EMAIL PROTECTED] wrote: Look at the conversation about making g-i-t a 'platform API' - now how major do you think this change is? :-) If we are talking about making g-i-t part of the platform, it should also be pointed out that the latest releases of g-i-t have added animations in the form of stuff-all-frames-in-a-png. While I think that adding support for animations in icon themes might be valuable, I think a) this needs to be discussed as an addition to the icon theme spec on [EMAIL PROTECTED], which I have not seen happening so far b) I believe we should pick a file format that did not already look antiquated when it was first employed in wanda the fish 5 years ago. Even gif animations look modern and featureful compared to this. I suspect you have in mind bug #319607 (Add a spinner widget to GTK) :-) http://bugzilla.gnome.org/show_bug.cgi?id=319607 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: breakage caused by removed icons from gnome-icon-theme
Il giorno lun, 06/02/2006 alle 13.09 -0500, Rodney Dawes ha scritto: On Mon, 2006-02-06 at 11:15 -0600, Federico Mena Quintero wrote: On Sun, 2006-02-05 at 11:00 -0500, Rodney Dawes wrote: snip for, although it is not yet complete. However, by GNOME 2.16, I hope to be able to call the base spec complete and 1.0, and guarantee API/ABI stability with it. Don't forget that a11y icon themes should be ported too. I just updated bug #319041: now the SVG BW theme is based on icon naming standard and it's using the build framework from tango. The current situation is not an API. It is a clusterbomb of random icons that were named a certain way, because a developer wrote a feature, and decided it needed an icon, and picked a name at random, or used an icon already in the set, that doesn't really make sense for the item they associated with it. However, all the work I've been doing with the spec and cleaning up gnome-icon-theme is to get all this fixed, so we can actually do things The Right Way. Issue: How to add an icon for Podcasts Details: Jimmac has a cool podcast icon here[1], designed for banshee (I don't know if it's yet used and/or installed by banshee). This icon is really useful for Rhythmbox. Let's me assume that a valid name for icon naming standard is remote-podcast under Places categories. Let's me also assume that this icon is not well fitted in base icon theme, so it should be provided by applications. Moreover a KDE app could like to use/provide/install the same icon. My Questions: 1. who should install the icon? Rhythmbox? Banshee? Both? An external *-icon-theme-extra package? 2. where this extra-but-common[2] icon should be installed? In hicolor? In gnome icon theme for GNOME apps and kde for KDE apps? [1] http://jimmac.musichall.cz/i.php?i=banshee [2] note there are also extra-but-unique icons. For example the banshee logo, installed under hicolor. This it right. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome-utils branched to gnome-2-14
Il giorno lun, 06/02/2006 alle 10.26 +0100, Emmanuele Bassi ha scritto: On Mon, 2006-02-06 at 08:50 +0100, Vincent Untz wrote: Le lundi 06 février 2006 à 00:26 +0100, Emmanuele Bassi a écrit : Hi all, I've branched gnome-utils for GNOME 2.14. 2.14 will use the gnome-2-14 branch; this branch is anchored to the GNOME_2_14_BRANCHPOINT tag. Development will go on on HEAD, as usual. Any plans for HEAD you'd like to share with us? :-) Screenshot * heavy bugzilla love * remove the file name entry and use a filechooser button * rework the UI and use a vertical layout I'll open relevant bug later, but what about a button to a new shot? [Help][New Shot...] [Cancel] [Save] Clicking it you could provide a dialog with some options, like Target (*) Grab entire screen (*) Grab only a window Options Wait |3 | secs before shoot [x] Add a drop shadow [Cancel] [Shot] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: breakage caused by removed icons from gnome-icon-theme
On Tue, 2006-02-07 at 09:43 +0100, Luca Ferretti wrote: Issue: How to add an icon for Podcasts Details: Jimmac has a cool podcast icon here[1], designed for banshee (I don't know if it's yet used and/or installed by banshee). This icon is really useful for Rhythmbox. Let's me assume that a valid name for icon naming standard is remote-podcast under Places categories. Let's me also assume that this icon is not well fitted in base icon theme, so it should be provided by applications. Moreover a KDE app could like to use/provide/install the same icon. My Questions: 1. who should install the icon? Rhythmbox? Banshee? Both? An external *-icon-theme-extra package? 2. where this extra-but-common[2] icon should be installed? In hicolor? In gnome icon theme for GNOME apps and kde for KDE apps? On a related note: A while back, several Rhythmbox icons got added to g-i-t because it was thought that they would be useful to other applications, e.g. the static-playlist smart-playlist and music-library icons. Are these the kind of things that would stay in g-i-t or not? They aren't useful to a great many applications, and I don't think the ones they would be useful for (e.g. Banshee) use them. If not, we come to the issue of theming application icons. There was some debate about six months ago on rhythmbox-devel about whether to use the new Bluecurve-ish icons someone had created for us (when we weren't using the g-i-t icons). Quite a few people were of the opinion that they didn't fit well with the standard gnome theme, so we ended up not having them in RB, and so they should have gone in the Bluecurve icon theme. If icon theme authors want to create their own icons for these, they will probably have to make a heap of symlinks, i.e. rb-static-playlist, banshee-static-playlist etc. Any other applications they don't know about, won't get their icons. I'm sure a lot of other things will run into this, e.g. OpenOffice and AbiWord/Gnumeric. Do we have clear guidelines on which kinds of icons should be included in g-i-t, and what application/icon authors are supposed to do if they are not? Cheers, James Doc Livingston -- Any sufficiently advanced technology is indistinguishable from a perl script. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
NLD10 and GNOME
Hi all, Just a quick question to anyone who may be in the know. After seeing the NLD10 videos, it seems the GNOME in there is rather similar to the mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/ I made a comparison in a blog post at http://www.jonobacon.org/viewcomments.php?id=637 to outline the point. Do we know if these radical changes to GNOME have been implemented, and if so, are the changes coming back to the community? Cheers, Jono ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: esd patch for control center
Rodrigo Moya wrote: Hi One of the things GNOME is doing on log in is to execute a couple times (one in gnome-session and one in gnome-settings-daemon) esound daemon. There is one related bug: unable to unset Enable software sound mixing (ESD) and set Sound for events http://bugzilla.gnome.org/show_bug.cgi?id=160335 But much better would be: Patch for moving libgnomeui to GStreamer http://bugzilla.gnome.org/show_bug.cgi?id=82340 Related: http://bugzilla.gnome.org/show_bug.cgi?id=94615 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
On Tue, 2006-02-07 at 10:43 +, Jono Bacon wrote: Hi all, Just a quick question to anyone who may be in the know. After seeing the NLD10 videos, it seems the GNOME in there is rather similar to the mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/ Indeed, these mockups were made internally at Novell by the UI team (same guys that brought you betterdesktop). I made a comparison in a blog post at http://www.jonobacon.org/viewcomments.php?id=637 to outline the point. Do we know if these radical changes to GNOME have been implemented, and if so, are the changes coming back to the community? The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. -JP -- JP Rosevear [EMAIL PROTECTED] Novell, Inc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Hi JP, Indeed, these mockups were made internally at Novell by the UI team (same guys that brought you betterdesktop). Awesome. Good work. They seem to be going down rather well, from speaking to other people. The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. Thanks. :) Jono ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
On 2/7/06, JP Rosevear [EMAIL PROTECTED] wrote: On Tue, 2006-02-07 at 10:43 +, Jono Bacon wrote: Hi all, Just a quick question to anyone who may be in the know. After seeing the NLD10 videos, it seems the GNOME in there is rather similar to the mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/ Indeed, these mockups were made internally at Novell by the UI team (same guys that brought you betterdesktop). I made a comparison in a blog post at http://www.jonobacon.org/viewcomments.php?id=637 to outline the point. Do we know if these radical changes to GNOME have been implemented, and if so, are the changes coming back to the community? The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. To ask the obvious question, why not now, and why not discussed publicly earlier? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver
Hello Davyd, Davyd Madeley wrote: I see that both Ubuntu Dapper and Fedora Core 5 test 2 are shipping with gnome-screensaver now. Having now used both of them, does it seem slow for anyone else? It seems that something has gone astray once or twice and forced me to have to change vt and kill the process to get my session back. I suspect that you may be running into: http://bugzilla.gnome.org/show_bug.cgi?id=328441 If you think it is something else feel free to open a new bug and we can try to track it down. Also, if you are on a system with a large number of users (500) you may experience problems when running with user switching enabled. This is one reason why it is off by default. It can be enabled or disabled using gconf. I didn't manage to get anything useful debugging-wise from it, does anyone know the story here? You can get debugging information from g-s by running it like so: gnome-screensaver --no-daemon --debug If we have a screensaver that you can't get away from, we should consider not including this module during this release cycle. I haven't experienced anything like this but that would indeed be a serious problem. I strongly encourage anyone experiencing such a thing to create a bug for it and work with me to solve the problem. Thanks, Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Hi, While it would be good to get fixes and improvements right away I do think its to hard to criticize anyone for holding back a bit on things they are doing. Being able to ship something first is an important marketing tool and this has happened before. In most cases where it has happened the distribution makers have been good at working with the community afterwards to get their changes merged upstream. Remember getting those changes merged in is in their interest too as keeping a larger and larger diff maintained is very costly and time consuming, so I am sure nobody wants to keep the changes any longer than necessary. Sincerely, Christian On Tue, 2006-02-07 at 14:41 +, Jamie McCracken wrote: Luis Villa wrote: On 2/7/06, JP Rosevear [EMAIL PROTECTED] wrote: On Tue, 2006-02-07 at 10:43 +, Jono Bacon wrote: Hi all, Just a quick question to anyone who may be in the know. After seeing the NLD10 videos, it seems the GNOME in there is rather similar to the mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/ Indeed, these mockups were made internally at Novell by the UI team (same guys that brought you betterdesktop). I made a comparison in a blog post at http://www.jonobacon.org/viewcomments.php?id=637 to outline the point. Do we know if these radical changes to GNOME have been implemented, and if so, are the changes coming back to the community? The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. To ask the obvious question, why not now, and why not discussed publicly earlier? Ditto + do i take it the changes amount to a fork? (I assume as its internal it does not have maintainer approval nor consensus?) To also be so blunt, is this a new strategy by Novell to keep new things like these under wraps in order to steal a march on your competitors? (if so I would be worried by this as it goes against the spirit of open source where open is the definitive word - I would hate to see this become common practice as if every gnome based organisation did this we would end up in a mess as well as in the dark) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver
On Tue, Feb 07, 2006 at 09:48:25AM -0500, William Jon McCann wrote: Hello Davyd, Davyd Madeley wrote: I see that both Ubuntu Dapper and Fedora Core 5 test 2 are shipping with gnome-screensaver now. Having now used both of them, does it seem slow for anyone else? It seems that something has gone astray once or twice and forced me to have to change vt and kill the process to get my session back. I suspect that you may be running into: http://bugzilla.gnome.org/show_bug.cgi?id=328441 This is the fontconfig bug that Kjartan alluded to I assume. I didn't manage to get anything useful debugging-wise from it, does anyone know the story here? You can get debugging information from g-s by running it like so: gnome-screensaver --no-daemon --debug Ok. I'll look into this more. If we have a screensaver that you can't get away from, we should consider not including this module during this release cycle. I haven't experienced anything like this but that would indeed be a serious problem. I strongly encourage anyone experiencing such a thing to create a bug for it and work with me to solve the problem. Will look into it. This module has been a long time coming, but we must be sure that we will not suffer any serious regressions. One thing that Xscreensaver had going for it was that it was really very well tested. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Christian Fredrik Kalager Schaller wrote: Hi, While it would be good to get fixes and improvements right away I do think its to hard to criticize anyone for holding back a bit on things they are doing. Being able to ship something first is an important marketing tool and this has happened before. In most cases where it has happened the distribution makers have been good at working with the community afterwards to get their changes merged upstream. Remember getting those changes merged in is in their interest too as keeping a larger and larger diff maintained is very costly and time consuming, so I am sure nobody wants to keep the changes any longer than necessary. I agree and im not judging Novell here but merely being blunt in asking a direct question (and hopefully I will get a direct answer) My concern is that if this becomes the rule rather than the exception and if say Red Hat follows suit then it would make gnome development effectively untenable and increase the risk of forking. That said Novell is certainly due all the praise and credit they will no doubt get when things are released and no one wants to take that away from them. Perhaps we can find some middle ground here that keeps everyone happy? -- Mr Jamie McCracken http://www.advogato.org/person/jamiemcc/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
UI Review
I'll probably regret asking this, but since we didn't do one for 2.12, does anyone think it would be worthwhile doing one for 2.14? Or is the HIG so ingrained in everyone's minds now that we don't need to bother? :) Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On Tue, 2006-02-07 at 15:17 +, Calum Benson wrote: I'll probably regret asking this, but since we didn't do one for 2.12, does anyone think it would be worthwhile doing one for 2.14? Or is the HIG so ingrained in everyone's minds now that we don't need to bother? :) I'd appreciate raving hordes of UI-zealots attacking Sound Juicer with its new (well, from 2.12) playback mode, if only so that I can ignore most of the feedback. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
Hey, On Tue, February 7, 2006 16:17, Calum Benson wrote: I'll probably regret asking this, but since we didn't do one for 2.12, does anyone think it would be worthwhile doing one for 2.14? Or is the HIG so ingrained in everyone's minds now that we don't need to bother? :) A UI review will of course be welcome :-) We're nearing UI freeze, though, but it might be a good idea to work do it soon so we can fix things for 2.16 ;-) Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Alt Mouse Modifier (Was: Adaptive mode)
Shaun McCance wrote: On Tue, 2006-02-07 at 10:36 +1300, Matthew Paul Thomas wrote: On 7 Feb, 2006, at 5:10 AM, karderio wrote: On Tue, 2005-12-27 at 21:42 +0100, Reinout van Schouwen wrote: If it is possible what you suggest, then that would make it easier to rubberband-select items in the list view, like you can in the icon view. Dragging the mouse over columns other than icon/filename would not affect the item under the mouse cursor directly, but rather affect the selection. Rubberbanding in the list view would be handy, how about activating rubberbanding if the shift key is held down (presuming that key is not in use) ? ... As you can see by trying it, Shift is already used for contiguous selection, Ctrl is used for non-contiguous selection, and Alt is (unfortunately) used to move the window. But a modifier key wouldn't be necessary if the behavior described above was implemented. Just a me-too on how unfortunate the Alt modifier thing for window moving is. I know of at least one major piece of third-party software that uses Alt as a modifier for certain mouse operations, and it's been doing so since long before Gnome stole it for window movement. I always switch it to Super, but I never use it. There doesn't seem to be a just turn this off, please check box. I always switch to Super, too, and use it very frequently. And I, too, use Alt-clicking in some applications. The problem is that some keyboards have no Super, or its equivalent. Concerning files selection and activating - personally, I think that activation by clicking on the name, and selection by clicking somewhere else would be quite convenient. Using another modifier to switch to selection pseudo-mode looks by no means obvious to an end user. -- Alexey Ktirf Rusakov ___ 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
Federico Mena Quintero wrote: - how long does nautilus take to pick up the pixmap and repaint its desktop window. That takes about 1 second for me, due to XRENDER bugs. This last one should be better on Radeon cards if you cvs update your GTK+. I put a workaround for the relevant Cairo/XRENDER bugs. I applied the patch (gtk2-117163-cairo-repeat-pattern-workaround.diff), to Gentoo's gtk+-2.8.11 and it makes Gnome much smoother and snappier, even running at 600MHz off of battery. I feel that combined with the removal of the 300ms delay, the problem is solved. Now, if only to get the useful icons back... sigh... --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Science/Engineering Menus.
Hello, While I'm bug-mongering gnome-icon-theme, could someone look at: http://bugzilla.gnome.org/show_bug.cgi?id=140900 I've been trying to get attention with it, as it's a minute change that would make a fair bit of difference to a lot of third-party applications. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On 2/7/06, Calum Benson [EMAIL PROTECTED] wrote: I'll probably regret asking this, but since we didn't do one for 2.12, does anyone think it would be worthwhile doing one for 2.14? Or is the HIG so ingrained in everyone's minds now that we don't need to bother? :) I'd appreciate usability feedback in response to http://bugzilla.gnome.org/show_bug.cgi?id=321905#c50 (which happened to be in response to earlier feedback -- thanks!) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver
On 2/7/06, William Jon McCann [EMAIL PROTECTED] wrote: Hello Davyd, Davyd Madeley wrote: I see that both Ubuntu Dapper and Fedora Core 5 test 2 are shipping with gnome-screensaver now. Having now used both of them, does it seem slow for anyone else? It seems that something has gone astray once or twice and forced me to have to change vt and kill the process to get my session back. I suspect that you may be running into: http://bugzilla.gnome.org/show_bug.cgi?id=328441 If you think it is something else feel free to open a new bug and we can try to track it down. I also think that a large part of the slowness may be explained by fontconfig brokenness until recently. If it is still too slow, we might consider starting it ahead of time. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On 2/7/06, Vincent Untz [EMAIL PROTECTED] wrote: Hey, On Tue, February 7, 2006 16:17, Calum Benson wrote: I'll probably regret asking this, but since we didn't do one for 2.12, does anyone think it would be worthwhile doing one for 2.14? Or is the HIG so ingrained in everyone's minds now that we don't need to bother? :) A UI review will of course be welcome :-) We're nearing UI freeze, though, but it might be a good idea to work do it soon so we can fix things for 2.16 ;-) Uh, we're just over a week *past* UI freeze. ;-) So yeah, most stuff would probably have to wait for 2.16 (though there might be things from usability feedback that wouldn't cause problems to documentation or release notes writers and wouldn't likely to destabilize things, which might be able to make it in 2.14...) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On Tue, 2006-02-07 at 09:44 -0700, Elijah Newren wrote: On 2/7/06, Vincent Untz [EMAIL PROTECTED] wrote: Hey, On Tue, February 7, 2006 16:17, Calum Benson wrote: I'll probably regret asking this, but since we didn't do one for 2.12, does anyone think it would be worthwhile doing one for 2.14? Or is the HIG so ingrained in everyone's minds now that we don't need to bother? :) A UI review will of course be welcome :-) We're nearing UI freeze, though, but it might be a good idea to work do it soon so we can fix things for 2.16 ;-) Uh, we're just over a week *past* UI freeze. ;-) I know, but didn't we always do UI reviews after the freeze, with maintainers having special release team dispensation to change stuff after that that the UI review recommended? Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Group http://ie.sun.com +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Alt Mouse Modifier (Was: Adaptive mode)
On 2/7/06, Alexey Rusakov [EMAIL PROTECTED] wrote: Shaun McCance wrote: On Tue, 2006-02-07 at 10:36 +1300, Matthew Paul Thomas wrote: As you can see by trying it, Shift is already used for contiguous selection, Ctrl is used for non-contiguous selection, and Alt is (unfortunately) used to move the window. But a modifier key wouldn't be necessary if the behavior described above was implemented. Just a me-too on how unfortunate the Alt modifier thing for window moving is. I know of at least one major piece of third-party software that uses Alt as a modifier for certain mouse operations, and it's been doing so since long before Gnome stole it for window movement. Maya? Or is there another? I always switch it to Super, but I never use it. There doesn't seem to be a just turn this off, please check box. I always switch to Super, too, and use it very frequently. And I, too, use Alt-clicking in some applications. The problem is that some keyboards have no Super, or its equivalent. Yes, but is that such a big problem? Few users even know that it exists (and, in fact, it affects usability decisions because we can't depend on users knowing about it) so why is it considered essential enough that it has to be Alt? I personally think that Super should have remained as the default, but given how long it has been Alt, changing (again) would probably do more harm than good. Anyway, for historical reference, see: - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80918 - http://bugzilla.gnome.org/show_bug.cgi?id=101151 - http://bugzilla.gnome.org/show_bug.cgi?id=79315#c10 Especially important for understanding my comment about changing again being bad would be http://bugzilla.gnome.org/show_bug.cgi?id=79315#c10. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Plan to fix icons [was: Re: breakage caused by removed icons from gnome-icon-theme]
On Mon, 2006-02-06 at 18:09 -0700, Elijah Newren wrote: On 2/6/06, Jeff Waugh [EMAIL PROTECTED] wrote: quote who=Federico Mena Quintero On Mon, 2006-02-06 at 13:36 -0600, Federico Mena Quintero wrote: 6. Create a subpackage of symlinks from the missing icons (the old icon names) to the new icons. If you don't have a new icon that matches, find the closest generic one, or simply put in the old icon image with a marker to indicate that it needs to be replaced. See this nice technique: http://blogs.msdn.com/jensenh/archive/2006/01/10/511202.aspx To clarify this: the point above is to make it easy to find cases where we *do* have an old-style icon name and image, *and* a way to map it to a new-style name, but we *don't* have a Tango-ified image to go with the name. Dude, why are we supporting this *wholly inappropriate* late breakage? This is not the kind of change that we should meekly accept at this stage of the release process. We don't *have* to do this, and we *shouldn't* do it. This is a choice between release discipline and riding a train wreck. I don't believe this is a fair representation. Rodney made the change mid-January, and released it in the gnome-icon-themes-2.13.5 tarball. He also notified desktop-devel-list, at http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00302.html. But not the documentation team, as far as I remember. For the first time in ages, we actually have talented folks actively working on the User Guide and the rest of our stack of documentation. These intrepid writers have taken charge and gotten stuff done, despite not getting the sort of lead we should be providing new contributors. Let's not screw them over with a blatant disregard for the schedule. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On 2/7/06, Calum Benson [EMAIL PROTECTED] wrote: Uh, we're just over a week *past* UI freeze. ;-) I know, but didn't we always do UI reviews after the freeze, with s/the freeze/a freeze/ maintainers having special release team dispensation to change stuff after that that the UI review recommended? Yes, but didn't we used to have a soft UI freeze + a hard UI freeze, with the UI review coming in between? (e.g. see http://www.gnome.org/start/2.5/). We're almost to the time of what would have been the hard UI freeze in such a schedule. Anyway, I think it'd make sense to probably approve stuff that was changed in response to UI review recommendation, if done soon, but given that it is later in the release cycle we do need to weigh it against possible work caused to the documentation or release notes writers as well as possibility for instability if the changes are not small. So, I'd probably lean towards approving such stuff, but I think it's too late to give blanket approval to changes made in response to UI review at this point. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Luis Villa wrote: On 2/7/06, JP Rosevear [EMAIL PROTECTED] wrote: The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. To ask the obvious question, why not now, and why not discussed publicly earlier? So here's my (ie, not Novell's) answer. Two words: bike shed[1]. Or actually, stop energy[2] works too. Your pick. Although the changes aren't nearly as radical as the original mockups, they are a big change from the current GNOME panel menu. If we had proposed the changes on the mailing lists, it would have started a huge discussion about what people hated about the design (you can't make the panel menu depend on beagle!!!) and how it should be different. And then we could have either (a) completely ignored everyone and done it ourselves anyway, or (b) had a long conversation about the merits of the design and then not actually finished the code in time for NLD10. So we did it ourselves, and now either GNOME will like what we did, in which case, yay, free code for GNOME, or GNOME won't like what we did, in which case, no harm no foul for GNOME, and yay, brand differentiation for Novell. (And anyone who yells fork deserves to get one stuck in them.) An equivalent answer to the question is because you can't do design by committee. Everything good in GNOME is good because one person or a small number of people working closely together made it good. Much of what is bad in GNOME is bad because lots of people have contributed without having a single vision of what the end result is supposed to be. I mean, look at the stuff John Williams has been blogging about the last week[3]: * Evolution's UI blocking on I/O SUCKS. Due to lack of design in the early stages of development * Evolution's integration with gaim and tomboy RULES. Both of these happened because specific people (ChipX86, orph) made them happen. * Multimedia integration SUCKS. No one has ever sat down and tried to fix the big picture. (Although I think the gstreamer team is in the process of doing this now?) * Apps not remembering their window size and position SUCKS. Again, needs someone to take this problem and make it their own. I remember xkahn was trying to fix this a few years ago, but never finished. * Bug-buddy SUCKS. Jacob's original UI was simple and brilliant. But as more and more people added more and more features without looking at the big picture, it got unwieldy. (But now a small team is putting the simplicity back in again.) * Deskbar applet RULES (kikidonk), dashboard RULES (Nat), and beagle RULES (trow and joe). None of these was done *exclusively* by those people, but each of them reflects one person's (or a few people's) vision, as opposed to the current state of bug buddy, which just sort of happened. This is just another aspect of the UI simplicity thing. We like UIs that try to do the right thing (metacity, epiphany/firefox, evince) rather than UIs that try to make every possible user happy (enlightenment, mozilla, gpdf/acroread). If you try to design something by committee, you either have to end up with the latter sort of messy does-everything UI, or you ignore and hence piss off a large chunk of the committee. And that's where we are with NLD. There is no way that everyone in the GNOME community is going to like the changes we wanted to make. But we did the user testing, and we believe in it, and we want to make the changes anyway. So we're doing it. Maybe it will turn out good, and maybe it will turn out bad. Either way, the GNOME community learns from it. Think of it like this: wouldn't it have been cool if we could have tried out spatialus on our users, found out that they hated it, and then reverted back to browserlus, without ever having to actually piss off our users? This is essentially what is going to happen with NLD10. If Novell's customers like the NLD changes, then GNOME can adopt them. If Novell's customers don't like the changes, then GNOME can stand off to the side and say yeah well, we never liked that UI anyway. Not at all like how we would have done it. :-) But some people will still say But couldn't you have discussed it with the community before doing it? No, we couldn't. If we had, it would either not have happened, or it would have sucked. It's inevitable. It's not a problem with the GNOME community, it's a problem with communities in general. The wisdom of crowds[4] only works in situations where there are clear right and wrong answers. If you try to apply it to a design problem, where there are many entirely different right answers, then you end up with a wrong answer. Always[5]. So to sum up: design by committee is bad, endless debates that result in code not actually being written are bad, design by very small teams is good, software with a
Re: Gnome-utils branched to gnome-2-14
On Tue, 2006-02-07 at 00:11 +0100, Emmanuele Bassi wrote: Hi Shaun, On Mon, 2006-02-06 at 11:41 -0600, Shaun McCance wrote: The Master Plan is: Screenshot * heavy bugzilla love * remove the file name entry and use a filechooser button In cases 1 and 2, I typically save directly to my public_html folder on master.gnome.org. (I love the GnomeVFS integration we've got in the GTK+ file choosers these days.) In 2 and 3, I'm often taking a series of screenshots, and I love the fact that the Screenshot tool remembers my last folder. This won't change at all. The machinery that saves the last folder will always be there, since I agree with you that's it's a (or even the most) useful feature of the screen shooter. With a file chooser button, to rename the file, I always have to click the button and type in a new name. I also can't see at a glance which folder I'm saving into. I can add a label with the save location under the preview image, for faster look up, but it must be understood that the file name entry is demonstrably broken, as it doesn't do what it seems to be doing. For instance, the entry doesn't really control the file name up until the very end: it won't work if you are going to save by drag and drop, for instance. I don't have a whole lot more to add. I've provided my point of view, and I can see merits in what you're saying as well. End of the day, you're the maintainer, and it's your call. But regarding this last paragraph, would a full file chooser button solve this drag and drop case? Wouldn't it be the exact same situation? Also, I'm not sure I understand why the dragged file can't use the file name provided. But then, I don't know how the drag and drop is being done. Are you creating a temp file and putting a URI in the drag data? It also strikes me as the only UI of the overall desktop that uses a separation of the file name and the location, which makes it inconsistent. That's true, I suppose. Although I do have this graphical checksum program I've been working on, which has never yet seen the light of a public release. It does use separate controls for file name and location, for pretty much the reasons I've outlined. I find that I almost never want to change the location, but I change the file name maybe half the time. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome-utils branched to gnome-2-14
On Tue, 2006-02-07 at 10:20 +0100, Luca Ferretti wrote: Il giorno lun, 06/02/2006 alle 10.26 +0100, Emmanuele Bassi ha scritto: On Mon, 2006-02-06 at 08:50 +0100, Vincent Untz wrote: Le lundi 06 février 2006 à 00:26 +0100, Emmanuele Bassi a écrit : Hi all, I've branched gnome-utils for GNOME 2.14. 2.14 will use the gnome-2-14 branch; this branch is anchored to the GNOME_2_14_BRANCHPOINT tag. Development will go on on HEAD, as usual. Any plans for HEAD you'd like to share with us? :-) Screenshot * heavy bugzilla love * remove the file name entry and use a filechooser button * rework the UI and use a vertical layout I'll open relevant bug later, but what about a button to a new shot? [Help][New Shot...] [Cancel] [Save] Clicking it you could provide a dialog with some options, like Target (*) Grab entire screen (*) Grab only a window Options Wait |3 | secs before shoot [x] Add a drop shadow [Cancel] [Shot] As I've mentioned elsewhere before, I think we should get a dialog like this when opening the Screenshot tool from the menus. I absolutely do not want to mess with the perfection we have now with PrtScrn and Alt+PrtScrn, but we should have the what would you like to do? dialog from the menus. Why: 1) It's less startling the first time you do it. It can guide users on what to do. 2) It would allow me to use our Screenshot tool to take screenshots of single windows in XNest. 3) It could provide access to a timeout for single-window screenshots, letting me open menus. 4) Bonus points: It could have helpful text right in the dialog telling you about the PrtScrn action, like: Target (*) Grab entire screen iOr use PrtScrn!!!/i ( ) Grab only a window iOr use Alt+PrtScrn111/i Then normal users might actually learn about our wonderful do-what-I-mean screenshot key bindings without having to go read the documentation cover-to-cover. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
On 2/7/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: On 2/7/06, JP Rosevear [EMAIL PROTECTED] wrote: The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. To ask the obvious question, why not now, and why not discussed publicly earlier? So here's my (ie, not Novell's) answer. Two words: bike shed[1]. Here's a heart felt thank you from one person for avoiding this. :) However, that seems to apply more to e.g. the panel changes. I'm curious about the joint window-manager/compositing manager (compiz) you were working on as it sounds like duplication of Soeren's work and something that largely wouldn't be affected by the bike shed stuff, at least not if the work discussion were restricted to the core gl part excluding plugins. I'm not trying to come across as accusing, I'm just wondering whether there was duplicated effort and if so whether there's a possibility of merging now or if we have a real fork for this particular part of the desktop. Thanks, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Dan, I agree on 99.9% of your mail, seriously, except one little line: dashboard RULES (Nat) IIRC Dashboard didn't compile some time ago (was some discussion on it on dashboard-list), afaik no (stock) apps work with it,... Or have you guys been fixing that too recently? :D I can't wait to get all great stuff Novell got out there on my desktop... There should be some good way to say Thank you. Kind regards, Ikke http://www.eikke.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Hey, Here's a heart felt thank you from one person for avoiding this. :) However, that seems to apply more to e.g. the panel changes. I'm curious about the joint window-manager/compositing manager (compiz) you were working on as it sounds like duplication of Soeren's work and something that largely wouldn't be affected by the bike shed stuff, at least not if the work discussion were restricted to the core gl part excluding plugins. My understanding while talking to David Reveman this past week was that the complexity of keeping a compositing manager as a separate process from the window manager was too high (too much bookkeeping that made it error prone, and there were some fundamental problems that he could not solve). So some time ago he abandoned his effort to patch Metacity and have a separate composition manager, reduced the complexity and eliminated a lot of bugs and the source of these bugs. That is what David explained to me, but I can only understand about 50% of the technical stuff that he talks about, so keep that in mind. Miguel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
On 2/7/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: On 2/7/06, JP Rosevear [EMAIL PROTECTED] wrote: The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. To ask the obvious question, why not now, and why not discussed publicly earlier? I should have been not quite so hasty and added 'and if the answers are real problems (which I think they probably are) any suggestions on how to solve them?' I'm swamped at work, so I can't go into much detail ATM, but it seems like these are very real issues we need to solve... Luis So here's my (ie, not Novell's) answer. Two words: bike shed[1]. Or actually, stop energy[2] works too. Your pick. Although the changes aren't nearly as radical as the original mockups, they are a big change from the current GNOME panel menu. If we had proposed the changes on the mailing lists, it would have started a huge discussion about what people hated about the design (you can't make the panel menu depend on beagle!!!) and how it should be different. And then we could have either (a) completely ignored everyone and done it ourselves anyway, or (b) had a long conversation about the merits of the design and then not actually finished the code in time for NLD10. So we did it ourselves, and now either GNOME will like what we did, in which case, yay, free code for GNOME, or GNOME won't like what we did, in which case, no harm no foul for GNOME, and yay, brand differentiation for Novell. (And anyone who yells fork deserves to get one stuck in them.) An equivalent answer to the question is because you can't do design by committee. Everything good in GNOME is good because one person or a small number of people working closely together made it good. Much of what is bad in GNOME is bad because lots of people have contributed without having a single vision of what the end result is supposed to be. I mean, look at the stuff John Williams has been blogging about the last week[3]: * Evolution's UI blocking on I/O SUCKS. Due to lack of design in the early stages of development * Evolution's integration with gaim and tomboy RULES. Both of these happened because specific people (ChipX86, orph) made them happen. * Multimedia integration SUCKS. No one has ever sat down and tried to fix the big picture. (Although I think the gstreamer team is in the process of doing this now?) * Apps not remembering their window size and position SUCKS. Again, needs someone to take this problem and make it their own. I remember xkahn was trying to fix this a few years ago, but never finished. * Bug-buddy SUCKS. Jacob's original UI was simple and brilliant. But as more and more people added more and more features without looking at the big picture, it got unwieldy. (But now a small team is putting the simplicity back in again.) * Deskbar applet RULES (kikidonk), dashboard RULES (Nat), and beagle RULES (trow and joe). None of these was done *exclusively* by those people, but each of them reflects one person's (or a few people's) vision, as opposed to the current state of bug buddy, which just sort of happened. This is just another aspect of the UI simplicity thing. We like UIs that try to do the right thing (metacity, epiphany/firefox, evince) rather than UIs that try to make every possible user happy (enlightenment, mozilla, gpdf/acroread). If you try to design something by committee, you either have to end up with the latter sort of messy does-everything UI, or you ignore and hence piss off a large chunk of the committee. And that's where we are with NLD. There is no way that everyone in the GNOME community is going to like the changes we wanted to make. But we did the user testing, and we believe in it, and we want to make the changes anyway. So we're doing it. Maybe it will turn out good, and maybe it will turn out bad. Either way, the GNOME community learns from it. Think of it like this: wouldn't it have been cool if we could have tried out spatialus on our users, found out that they hated it, and then reverted back to browserlus, without ever having to actually piss off our users? This is essentially what is going to happen with NLD10. If Novell's customers like the NLD changes, then GNOME can adopt them. If Novell's customers don't like the changes, then GNOME can stand off to the side and say yeah well, we never liked that UI anyway. Not at all like how we would have done it. :-) But some people will still say But couldn't you have discussed it with the community before doing it? No, we couldn't. If we had, it would either not have happened, or it would have sucked. It's inevitable. It's not a problem with the GNOME community, it's a problem with communities in general. The
Re: NLD10 and GNOME
On 2/7/06, Miguel de Icaza [EMAIL PROTECTED] wrote: Hey, Here's a heart felt thank you from one person for avoiding this. :) However, that seems to apply more to e.g. the panel changes. I'm curious about the joint window-manager/compositing manager (compiz) you were working on as it sounds like duplication of Soeren's work and something that largely wouldn't be affected by the bike shed stuff, at least not if the work discussion were restricted to the core gl part excluding plugins. My understanding while talking to David Reveman this past week was that the complexity of keeping a compositing manager as a separate process from the window manager was too high (too much bookkeeping that made it error prone, and there were some fundamental problems that he could not solve). So some time ago he abandoned his effort to patch Metacity and have a separate composition manager, reduced the complexity and eliminated a lot of bugs and the source of these bugs. Right, but this sounds similar to what Soeren did/is doing -- he's building a compositing manager inside metacity, and has merged many of the changes into head now (this is disabled by default, though). So, we have two merged window manager + compositing manager codebases now. My question is whether and how we can merge these. That is what David explained to me, but I can only understand about 50% of the technical stuff that he talks about, so keep that in mind. Yeah, I don't know the technical details of the compositing side either (I've been meaning to help out with it at some point, but there's so many other bugs to fix...). I guess we just need Soeren and David to get together and figure it out. :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Alt Mouse Modifier (Was: Adaptive mode)
Elijah Newren wrote: Just a me-too on how unfortunate the Alt modifier thing for window moving is. I know of at least one major piece of third-party software that uses Alt as a modifier for certain mouse operations, and it's been doing so since long before Gnome stole it for window movement. Maya? Or is there another? Meld, the diff tool for GNOME. Don't know about GIMP, btw. Yes, but is that such a big problem? Few users even know that it exists (and, in fact, it affects usability decisions because we can't depend on users knowing about it) so why is it considered essential enough that it has to be Alt? Well, not really. I personally think that Super should have remained as the default, but given how long it has been Alt, changing (again) would probably do more harm than good. Certainly. -- Alexey Ktirf Rusakov ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Alt Mouse Modifier (from digest)
Hi, Alexey Rusakov wrote: Elijah Newren wrote: Just a me-too on how unfortunate the Alt modifier thing for window moving is. I know of at least one major piece of third-party software that uses Alt as a modifier for certain mouse operations, and it's been doing so since long before Gnome stole it for window movement. Maya? Or is there another? Meld, the diff tool for GNOME. Don't know about GIMP, btw. Yes, the GIMP does this too, for (among other things) moving selection boundaries without moving their contents. And yes, we've worked around it (Ctrl-Alt does the same thing). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Alt Mouse Modifier (Was: Adaptive mode)
On Tue, 2006-02-07 at 00:48 -0500, Shaun McCance wrote: Just a me-too on how unfortunate the Alt modifier thing for window moving is. I know of at least one major piece of third-party software that uses Alt as a modifier for certain mouse operations, and it's been doing so since long before Gnome stole it for window movement. WTF? That wonderful feature worked on some window managers even before there was as Super Windows key on keyboards. Before there was GNOME, even... Rui signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-screensaver
tir, 07,.02.2006 kl. 14.55 +0800, skrev Davyd Madeley: On Tue, Feb 07, 2006 at 07:53:15AM +0100, Kjartan Maraas wrote: tir, 07,.02.2006 kl. 12.10 +0800, skrev Davyd Madeley: I see that both Ubuntu Dapper and Fedora Core 5 test 2 are shipping with gnome-screensaver now. Having now used both of them, does it seem slow for anyone else? It seems that something has gone astray once or twice and forced me to have to change vt and kill the process to get my session back. I've seen the lock screen dialog taking 20-30 seconds to give me a username entry and ended up disabling locking. That is certainly unacceptable I think. I tested again now and the bug is gone here at least. I didn't manage to get anything useful debugging-wise from it, does anyone know the story here? If we have a screensaver that you can't get away from, we should consider not including this module during this release cycle. I think there were some problems with fontconfig recently that caused slowness in many apps, could this be one of them maybe? AFAIK it has been fixed in the latest updates. Don't seem to be having problems with other applications (in fact many things are quite snappy, large Cairo-exposes excluded of course). I've also noticed this on Dapper, which did not have fontconfig issues that I noticed. These issues should be addressed before we consider including this as a blessed Desktop module. Do you have the latest fontconfig stuff for Ubuntu? I think they have updates there that should fix it *if* it is the same problem I was seeing. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Alt Mouse Modifier (Was: Adaptive mode)
On Tue, 2006-02-07 at 21:17 +, Rui Miguel Silva Seabra wrote: On Tue, 2006-02-07 at 00:48 -0500, Shaun McCance wrote: Just a me-too on how unfortunate the Alt modifier thing for window moving is. I know of at least one major piece of third-party software that uses Alt as a modifier for certain mouse operations, and it's been doing so since long before Gnome stole it for window movement. WTF? That wonderful feature worked on some window managers even before there was as Super Windows key on keyboards. Before there was GNOME, even... You mean back when there was a Meta key on Sun keyboards? All the window managers and desktops and toolkits steal keys, and they don't all steal the same ones. The fact is, ISDs have a hell of a time dealing with modifier keys in applications that are supposed to run on five different desktops over seven different operating systems using four different keyboard layouts in the US alone. I know at least one major piece of third-party software that actually ends up using NumLock to modify certain behaviors. Not because some usability group sat down and decided Hey, NumLock would be cool! But just because NumLock happens to get mapped to Mod2. If you need anything more than Ctrl+letter in your application, you're pretty much screwed. I envy Apple. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
quote who=John Williams I take Jeff's point as well, although personally I would not have put it in such emotive terms. I put it in emotive terms because *someone* has to offset all the hugging and back-slapping about Dan's mail. All this positivity about a mail that basically says this community shit is too hard! fuck it!, and just puts that meme right back in centre square. Nat and Miguel blogging about it as if it were an epiphany. Those two form some kind of leadership perspective in GNOME, and look at what they're cheering about... Deeply unimpressed. - Jeff -- FOSDEM 2006: Brussels, Belgiumhttp://www.fosdem.org/2006 From my observation, when it comes to porting Linux to a particular device, a point doesn't appear to be necessary. - mpt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Alt Mouse Modifier (Was: Adaptive mode)
On 8 Feb, 2006, at 11:39 AM, Rui Miguel Silva Seabra wrote: On Tue, 2006-02-07 at 16:34 -0600, Shaun McCance wrote: ... If you need anything more than Ctrl+letter in your application, you're pretty much screwed. ? I fail to see the relevance, this is window level, not application level, feature. ... Taking it for a window-level feature prevents it from being used for any application-level feature. For example, in a Web browser there are all sorts of things you can do with a link: open it in a new window, open it in a new background window, open it in a new tab, open it in a new background tab, or download the linked item. In Epiphany we would like to be able to use (Shift+)Alt+click for one or two of those things, like popular Web browsers on other platforms do. But we can't, because Metacity has taken it. I would much prefer that the easy way of moving a window was drag any part of the window that isn't for something else, with no modifier key necessary. Drag a window's title bar, status bar, an empty part of a toolbar, an empty space between controls, and so on. That would provide less target area than Alt+drag did (though still *much* more target area than on Windows or the Mac), but (1) it would be more obvious, (2) it wouldn't need two hands, and (3) it would remove the need for the clutter of a title bar and the rest of the window being visually distinct elements. -- Matthew Paul Thomas http://mpt.net.nz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
I put it in emotive terms because *someone* has to offset all the hugging and back-slapping about Dan's mail. Er. Yeah well. Anyway, I just reread Jono's original message and corresponding blog post again, and it still seems to me that he was talking solely about the GNOME- UI-related stuff in NLD10 (ie, the new panel menu replacement), and that's what I assumed we were all talking about when I replied. But it seems to me now that everyone other than me (and possibly Jono) is actually talking about Xgl, and I have no comment on that. (OTOH, if you really were saying that Novell's writing a replacement for the panel menu was commons-sapping, community-tearing, morally and intellectually lazy, then by all means, let me know so I can write a suitably rude reply. :) -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
quote who=Dan Winship But it seems to me now that everyone other than me (and possibly Jono) is actually talking about Xgl, and I have no comment on that. (OTOH, if you really were saying that Novell's writing a replacement for the panel menu was commons-sapping, community-tearing, morally and intellectually lazy, then by all means, let me know so I can write a suitably rude reply. :) I was not talking exclusively about Novell, Xgl, or the new panel applet. I was talking about a serious problem in our community, and the destructive ideas, memes and role models that support it. - Jeff -- FISL 7.0: Porto Alegre, Brazilhttp://fisl.softwarelivre.org/7.0/www/ Oh my god, if I get killed, Meryl Streep will get an award playing my life and I would be really pissed off. - Susan Sarandon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
On Wed, Feb 08, 2006 at 12:53:52PM +1100, Jeff Waugh wrote: quote who=John Williams I take Jeff's point as well, although personally I would not have put it in such emotive terms. I put it in emotive terms because *someone* has to offset all the hugging and back-slapping about Dan's mail. All this positivity about a mail that basically says this community shit is too hard! fuck it!, and just puts that meme right back in centre square. Nat and Miguel blogging about it as if it were an epiphany. Those two form some kind of leadership perspective in GNOME, and look at what they're cheering about... You've nailed the issue here, Jeff. What I don't understand is that even if Novell want to develop new ideas in house, why does this work take so long to bubble to the surface? This is the same as Novell's netapplet: people saw hints that this piece of software existed in screenshots of desktops c, but software was still not released. You can talk about stop energy, but nothing is stopping you doing the work. What I don't understand (and this doesn't just apply to Novell) is why that patch couldn't have appeared in the open when it was written: here is an idea we've been tossing around at Novell for a new panel menu, rather than only finding out through leaks and screenshots. For the sake of the community; share, and share alike. Otherwise, one day there will be no community, there will be only corporates in competition for mind-share, you will have lost the unified product, the unified experience and no longer benefit from each other's successes. This course of action will create a time when GNOME goes the way of propriortary UNIX: Tru64, Solaris, AIX, HP-UX, IRIX... imagine a world with Novell Desktop, Topaz, Java Desktop, the Hatrack Environment: all competing products... where is GNOME? --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sorry State [Was: NLD10 and GNOME]
Em Qua, 2006-02-08 às 12:16 +1100, Jeff Waugh escreveu: quote who=Dan Winship Two words: bike shed[1]. Or actually, stop energy[2] works too. Your pick. This is a very sorry state of affairs for GNOME. But it is not only Novell and its employees who have adopted this commons-sapping, community-tearing, morally and intellectually lazy approach to open design and development in GNOME. In contributing organisations, it is rationalised as a faster approach, a way to avoid massive discussions about inanities, and top of the list in these modern times, a way to avoid design by committee or stop energy. How on Earth *do* we manage design out in the open? It is easier to avoid that question, in the name of getting things done. Outside the contributing organisations, it's appeased as something we have to accept to get the cool stuff, and a side-effect of our ability to involve contributing organisations, who have their own priorities. It sounds a lot like, don't bite the hand that feeds you, whether that hand is delivering cool drops of code, or your pay packet. But ultimately, this is *killing our community*. And it must be fought. - Jeff I think the process used by Novell is very common in the GNOME community (and Free Software in general). For example take metacity. Sawfish was the default window manager, so Havoc could have started a discussion should-our-window-manager-be-like-this-instead. But he didn't; what he did was write metacity following the design he had in mind in a window manager. Metacity was included in GNOME because most people adopted it and agreed that Havoc's design was better for the default window manager. The menu layout we use today is another example. If people had gone on discussions about which is better - the foot or the menu panel - perhaps things would have gone nowhere. But someone wrote the menu panel and eventually it became the GNOME default. Ubuntu has also done some changes in the panel, like the 'Add to Panel' dialog. From what I remember this was first done in Ubuntu and after a release using that configuration discussion started on the usability list. Another example is the log out dialog on the right top corner of the screen in Dapper, which wasn't proposed for discussion on mail.gnome.org, it was just implemented there when GNOME uses the window selector for the top right corner. There are some people posting mockups of GNOME 3 and to be honest I see very little discussion about them. People know (or learn) that unless they code these mockups or convince someone to do it then most likely nothing will happen. But if someone comes up with a different concept for the panel and translates that into code then the community will review and pick it up or reject it. Spending time discussing the design first would IMO be a waste of time if the person has it clear in their head what they want from this hypothetical new panel. The review process will still happen, just not before the design. The design might even have small changes after suggestions from the community, but the basic idea of the original author is what makes this good or bad design. I'm not sure I agree that you can't do design by comittee but I would agree that a lot of the good design decisions we see in GNOME today came from only a few coders doing their vision. I'd love to play with the code as soon as possible but maybe there are other reasons for it not being released yet. What GNOME can do is encourage the companies making changes in their development branches to at least commit the patches in a CVS branch. There's also the issue of who you target with the changes. Novell might find in a usability test that the menu they designed is a lot better for their target audience but most people in the GNOME community would reject it in favor of the current panel layout (I'm one for example). Should that stop Novell from doing what's best for their customers (people used to Windows but now using GNOME because their company went with NLD)? My 2c. Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
