Re: NLD10 and GNOME
On 2/7/06, Dan Winship [EMAIL PROTECTED] wrote: 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 unified vision is good, trying out cool new UI ideas is good, free code at least doesn't suck, and of course, for Novell, not shipping NLD10 is bad. Totally agree, all those guys whining about developing out of alpha stage behind closed doors are just jealous about others doing cool stuff ;) Many projects could be more stable if only they hadn't been torn to pieces by indecision in the community. Or left rotting because talk of changes lead nowhere. Talk is cheap but if nobody codes, nothing happens. This has been discussed many times recently, but discussions that start with hey, I wrote a patch to... instead of with hey, I just thought that... will have a significantly better chance to actually have an effect. This is very visible in the usability list for example, since discussions there involve more non-coders than here for example. There's loads and loads of suggestions which might be good but nobody knows because nobody implemented it. Which is a shame. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Be nice to the contributors (was Re: NLD10 and GNOME)
Le mardi 07 février 2006 à 15:55 +0100, Christian Fredrik Kalager Schaller a écrit : 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. (this is no way specific to Novell or to the panel change in NLD10, which just seems to be a new menu applet) Let's put it another way: I'm a maintainer of some modules, working on my free time on GNOME. I'm trying to fix bugs, and if I find time, implement cool new features (most often small new features :/). Now, something with a lot of changes comes out. It looks really great. As a user, I'm pleased. As a contributor, I'm sad. While I'm struggling in day-to-day not-so-funny things, I'll probably have to review a big patch without having the fun of developing it. I'd have loved to give some input on the idea, and on the implementation. Maybe I would have said no way, but no way means I don't want this, but feel free to patch your version if you really want. I'm not saying it's bad to code some stuff in your corner. But please, please, please be nice to contributors: tell the people who work on some stuff what you might be doing, talk to them, ask them what they think. You don't need to mail d-d-l to get input on some change. Someone on irc wrote something like GNOME is first a software writing project, and then love. This is so wrong. Don't ignore the community. 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: Sorry State [Was: NLD10 and GNOME]
Le mercredi 08 février 2006 à 04:49 -0200, Evandro Fernandes Giovanini a écrit : 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. AFAIK, Havoc used CVS for metacity. Everybody could look at it. 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. There were discussions about the new layout, but they were not on d-d-l ;-) It was also done in CVS, by one of the maintainer. 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. The Ubuntu Add to Panel dialog was developed with input from a gnome-panel maintainer (who wondered what result it would give). Discussion on usability list occurred because the maintainer was not sure the result was okay. (maintainer being me, in that case) 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. AFAIK, the log out thing in dapper is just a simple applet. The real change is in the gnome-session dialog. I'm not sure the gnome-session maintainers were aware of this change, but I believe that at least Mark wanted to move this functionality to the panel, so... [...] I'm not saying design by community works. But people working on the modules that will be changed should have the possibility to know about the change. Don't ignore them. Be nice. Another solution is to just proclaim we don't need maintainers any more, everyone can do anything. Less work for me ;-) (but I'm not sure this is a good solution). 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: Sorry State
El mi, 08--2006 a las 10:10 +0100, Manu Cornet escribi:
I'm not saying taking our time to discuss changes is wrong (of course
not). But sometimes I just need to try something out. If there's a new
feature proposal, and some developers find it is a bad idea, but it
basically looks like a nice thing to try, then just let the guy code it,
make it better, and then let everyone actually try it.
I totally agree with you. I'm not contributing to Gnome but i am on other open source projects where lots of code goes to CVS repository. If you have a 'big idea' then sometimes you *can't* put it on CVS cause you will surely interrupt the roadmap for the next release, you would surely need to have the consensus from a lot of people, and you would surely put your efforts on that task: convincing people. If instead of that, you go your way and develop a new feature you can always share your feature in a near future, perhaps in a next stage. So the problem here seems to be that was Novell Inc. who take this approach, and it wasn't the less important guy in this world who did it. Let's suppose that these changes were all done by somebody totally unknown. Surely he would become the next most loved Gnome hacker ey look that guy!. My opinion is that community developers should wait for Novell proposal to include it on Gnome 2.xx, or to make his own fork to discuss about this new ('nice') injection of creativity on Gnome. And of course, it must be discussed, but ... now come back to your seat! :-).
--
Arturo Gonzlez,
CEVUG, University of Granada
http://www.ugr.es/~arturogf
___
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, 2006-02-08 at 15:36 +1100, Jeff Waugh wrote: 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. Isn't what we got here exactly what has been asked for? That 'big' changes to GNOME needs to come from 'outside' projects? Havoc for instance was advocating that in his blog entries. So if people are unhappy about XYZ in GNOME, for instance the current panel. Due to it being so business critical we can't have experimentation going on in the gnome-panel CVS head, so 'radical' changes would need to be done as a separate project, and if it turns out good then it will at some point replace the current module. There is also a lot that gets thrown away, and I guess people don't want to spend time discussing UI and so on about something which might not ever get used outside their own machine, for instance someone mentioned the Novell Network applet, which afaik ended up in the dustbin and Novell started contributing to NetworkManager instead. That said I think the 'problem' of endless debates on desktop-devel in regards to actual development is overstated. 90% of endless debates on this list is not about module xyz, but about general policy issues like this one. If we want to get (back) to a situation where more gung-ho stuff happens in our core modules I think we need to do a couple of things. Like increase module maintainers freedom again (at the cost of the release team for instance) and accept that if radical changes happens to module XYZ the maintainer of that module is more free to ignore any criticism no matter who is giving it. So if the Nautilus maintainers decide that file manager windows should be circle shaped and not square for instance the rest of us have to accept that. Christian ___ 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=Christian Fredrik Kalager Schaller 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. Isn't what we got here exactly what has been asked for? That 'big' changes to GNOME needs to come from 'outside' projects? Havoc for instance was advocating that in his blog entries. Sure, but do we all agree with that? Is that the best way forward for GNOME? If we want to get (back) to a situation where more gung-ho stuff happens in our core modules I think we need to do a couple of things. Like increase module maintainers freedom again (at the cost of the release team for instance) There is very little cost of maintainer freedom associated with the release team. The whole process is seriously optimised for maintaining that freedom *and* making sure their work gets into the hands of users. That said, where improvements could be made, r-t has always been open to them. Let them know what sucks! - Jeff -- FOSDEM 2006: Brussels, Belgiumhttp://www.fosdem.org/2006 You know the end is nigh when modern art is relegated to the status of meme. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Need for lead (Re: NLD10 and GNOME)
On Tue, 2006-02-07 at 19:53, Elijah Newren wrote: So, we have two merged window manager + compositing manager codebases now. My question is whether and how we can merge these. I think that's precisely the heart of the problem: decisions in the GNOME project are made not to hurt community developpers. Sometimes I'm sure the core isn't even looked at and is accepted as a whole. Code needs to be accepted on it merit, not only feature-wise but wrt its quality, integration with the rest of the desktop and testability (i.e. no too big changes in the code at once). Look at Xorg, they asked David to integrate Xgl piece by piece, rejecting unwanted changes. Look at the linux kernel, they often reject ideas without code, and often reject code because it's not good or because it's too big. But they never decide to merge two pieces of code just to please both developpers. ___ 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, 2006-02-08 at 11:01 +0100, Christian Fredrik Kalager Schaller wrote: On Wed, 2006-02-08 at 15:36 +1100, Jeff Waugh wrote: 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. Isn't what we got here exactly what has been asked for? That 'big' changes to GNOME needs to come from 'outside' projects? Havoc for instance was advocating that in his blog entries. So if people are unhappy about XYZ in GNOME, for instance the current panel. Due to it being so business critical we can't have experimentation going on in the gnome-panel CVS head, so 'radical' changes would need to be done as a separate project, and if it turns out good then it will at some point replace the current module. this is exactly what I was going to say :) It is indeed what some big GNOME names have been advocating for. And I agree with it. At novell, and I guess at other GNOME-related companies, we try to put as much fixes as possible upstream, but for radical changes, it makes sense to do them separately and merge them upstream if/when maintainers are ready to accept it. Also, current 6 months schedules make it difficult, at least from my experience, to introduce big changes. For big things, you usually need a couple of releases. Maybe we could improve this a little bit by forcing people to branch as soon as we hit the freezes, so that big changes can start immediately, instead of 2/3 months later (which is mostly what happens now, that most people start branching a few weeks after the final *.*.0 release). Also, Federico suggested some time ago, IIRC, keeping the old stable branches more alive than what they are right now. For instance, NLD10 is based on GNOME 2.12, so it makes it impossible to introduce radical changes in the upstream GNOME version, which is frozen. Of course, I'm not saying we should allow companies to put whatever they want in old stable releases, but maybe following Federico's suggestions would make companies contribute better to upstream GNOME. There is also a lot that gets thrown away, and I guess people don't want to spend time discussing UI and so on about something which might not ever get used outside their own machine, for instance someone mentioned the Novell Network applet, which afaik ended up in the dustbin and Novell started contributing to NetworkManager instead. That said I think the 'problem' of endless debates on desktop-devel in regards to actual development is overstated. 90% of endless debates on this list is not about module xyz, but about general policy issues like this one. If we want to get (back) to a situation where more gung-ho stuff happens in our core modules I think we need to do a couple of things. Like increase module maintainers freedom again (at the cost of the release team for instance) and accept that if radical changes happens to module XYZ the maintainer of that module is more free to ignore any criticism no matter who is giving it. So if the Nautilus maintainers decide that file manager windows should be circle shaped and not square for instance the rest of us have to accept that. that's basically how it works already :) Maintainers do changes, and when those changes upset people, they complain (ie, see background capplet instant-apply removal). So, except during freeze times, maintainers have freedom to do what they want in their modules. The problem with big changes is on modules the person doing the big change doesn't maintain. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by community
Hi, Evandro Fernandes Giovanini said: I think the process used by Novell is very common in the GNOME community (and Free Software in general). Compare contrast with Spatial nautilus and the GTK+ file selector. It's also funny that you should pick Metacity - Havoc wrote a document on his theory of simple interface, then wrote metacity released an early version. Design integrity, right. But RERO as well. Nautilus and the file selector were both designed by a small number of people, and implemented in the open by a wider community. 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 a question of principle at work here - does having an announcement effect (like a cool demo in Solutions Linux, or giving nice 770 devices to GNOME developers) justify the secrecy of developing a free software product/feature to a point where it's usable offset the damage of developing in a cathedral, while participating in a bazaar? You can have both design integrity and open development. We've proven it several times. You just need a pig-headed designer with a couple of dedicated disciples (both those qualifications are intended as compliments). Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ 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, 2006-02-08 at 12:57 +0800, Davyd Madeley wrote: 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? not if the changes are not kept proprietary and sent upstream sooner or later. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
Jeff said (after 'Sorry State') ... .. 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. ... Deeply unimpressed. My €0.02: 1) stuff should have gone into cvs right away, in branches (honestly, nobody has a strong reason to fight 'experimental' branches) 2) projects and progress should have been announced to d-d-l and g-h. 3) then the issue of merging to HEAD (or not) could be raised in a more objective, matter-of-fact manner in the community. Of course people would have complained, and made comments varying from pure noise to helpful insights and everything in between, but I think it would have been less divisive than the way it went down. Bill - Jeff ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
Rodrigo Moya wrote: On Wed, 2006-02-08 at 12:57 +0800, Davyd Madeley wrote: 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? not if the changes are not kept proprietary and sent upstream sooner or later. perhaps but the real question is why isn't this a branch in CVS? Why is there a need for clandestine development? Take Nautius-search as an example, Novell did this right by having a branch which the maintainers could see, change and adapt. The result was a hugely successful merge. Also Davyd is right to a point - remember how NT swept aside Unix because they would not unite? Lets not repeat history - united we stand (and succeed), divided we fall! -- 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
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. 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. What I am missing in your replies is some sort of thank you to Novell. They seem to have done some serious amount of work -- behind closed doors, but they did it. They released their code for everyone to benefit from. So what is the big problem? How far are you willing to go? How open must the development of new features be? Should discussion arise over *every* new feature a developer wants to implement? Over every 100 lines of code? Every 50 lines? Every 25 lines? How far are you willing to go? As far as I'm concerned, it is up to *developers* to decide how open they want *their* development to be-- as long as they abide by licensing rules and publish their work for everyone to benefit from, of course. Who are we, who contributed *nothing* to the work the developers at Novell have done, to demand they use a more open development path? I am wondering how emotional you would have been if all this work was done in the same way by an individual group of people *not* affiliated with any company...? Thom Holwerda --- Managing editor at http://www.osnews.com, exploring the future of computing --- Read my *all new* blog: http://cogscanthink.blogsome.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sorry State
On Wed, 2006-02-08 at 10:42 +0100, Arturo González wrote:
El mié, 08--2006 a las 10:10 +0100, Manu Cornet escribió:
I'm not saying taking our time to discuss changes is wrong (of course
not). But sometimes I just need to try something out. If there's a new
feature proposal, and some developers find it is a bad idea, but it
basically looks like a nice thing to try, then just let the guy code it,
make it better, and then let everyone actually try it.
I totally agree with you. I'm not contributing to Gnome but i am on
other open source projects where lots of code goes to CVS repository.
If you have a 'big idea' then sometimes you *can't* put it on CVS
cause you will surely interrupt the roadmap for the next release, you
would surely need to have the consensus from a lot of people, and you
would surely put your efforts on that task: convincing people. If
instead of that, you go your way and develop a new feature you can
always share your feature in a near future, perhaps in a next stage.
So the problem here seems to be that was Novell Inc. who take this
approach, and it wasn't the less important guy in this world who did
it. Let's suppose that these changes were all done by somebody totally
unknown. Surely he would become the next most loved Gnome hacker ey
look that guy!. My opinion is that community developers should wait
for Novell proposal to include it on Gnome 2.xx, or to make his own
fork to discuss about this new ('nice') injection of creativity on
Gnome. And of course, it must be discussed, but ... now come back to
your seat! :-).
it surprises to me people are talking about forks. So far, Ximian, and
then Novell, have always done big changes to the desktop, then include
what maintainers accepted, and, in all these years, there has never been
a fork, so, why do people talk about forks? It's not that Novell/Ximian
is a newcomer to the GNOME world and has to demonstrate its good
willings.
--
Rodrigo Moya [EMAIL PROTECTED]
___
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=Thom Holwerda What I am missing in your replies is some sort of thank you to Novell. They seem to have done some serious amount of work -- behind closed doors, but they did it. They released their code for everyone to benefit from. So what is the big problem? So, again, despite the unfortunate timing and how this always flares up when we have an example to latch on to, my concern is not exclusive to Novell, XGL, new panel applets, or any of the current examples of this in action. It is a problem that we all share. It is cultural more than anything else - and I have been *totally* complicit in propagating it. So don't read my email as some kind of anti-Novell rant. We're all in this together. - Jeff -- FOSDEM 2006: Brussels, Belgiumhttp://www.fosdem.org/2006 Free software never simply picks up its marbles and goes home. - Jonathan Corbet, LWN ___ 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 10:25 -0700, Elijah Newren wrote: 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. Ok, well... what I'd suggest then is that we[1] maybe try and do a UI review of the components whose maintainers have expressed an interest in being reviewed (or who express such an interest in the next day or two), and just seek approval for those changes. And then do it properly again next time :) Cheeri, Calum. [1] Or possibly just me, if nobody else is particularly interested... -- 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: Design by Community
Rodrigo Moya wrote: On Wed, 2006-02-08 at 11:01 +0100, Christian Fredrik Kalager Schaller wrote: On Wed, 2006-02-08 at 15:36 +1100, Jeff Waugh wrote: 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. Isn't what we got here exactly what has been asked for? That 'big' changes to GNOME needs to come from 'outside' projects? Havoc for instance was advocating that in his blog entries. So if people are unhappy about XYZ in GNOME, for instance the current panel. Due to it being so business critical we can't have experimentation going on in the gnome-panel CVS head, so 'radical' changes would need to be done as a separate project, and if it turns out good then it will at some point replace the current module. this is exactly what I was going to say :) It is indeed what some big GNOME names have been advocating for. And I agree with it. At novell, and I guess at other GNOME-related companies, we try to put as much fixes as possible upstream, but for radical changes, it makes sense to do them separately and merge them upstream if/when maintainers are ready to accept it. Sure it makes sense to develop radical changes on a branch rather than on the mainline, but this does not require secrecy. Collaboration doesn't need to be restricted to mainline development. Some of the benefits include: * Rather than dumping the change fully formed on the maintainer, they might take an early peak at the code and tell you whether there are problems with the design that would cause them to reject the change later on. * Reduce duplicated work: say someone else saw the mockups, decided that they were a great idea and started implementing it. What do they do when they find out that you've also been developing the feature. What should the maintainer do if both groups submit their respective patches for inclusion. There definitely are benefits to secrecy (better signal/noise ratio between developers, being first to market with the feature), but they aren't all benefits to the community. Also, current 6 months schedules make it difficult, at least from my experience, to introduce big changes. For big things, you usually need a couple of releases. Maybe we could improve this a little bit by forcing people to branch as soon as we hit the freezes, so that big changes can start immediately, instead of 2/3 months later (which is mostly what happens now, that most people start branching a few weeks after the final *.*.0 release). Who says that a big change needs to be completed in 6 months? For some changes it might make sense to skip a release, which also lets you continue working through the feature freeze. Also, Federico suggested some time ago, IIRC, keeping the old stable branches more alive than what they are right now. For instance, NLD10 is based on GNOME 2.12, so it makes it impossible to introduce radical changes in the upstream GNOME version, which is frozen. Of course, I'm not saying we should allow companies to put whatever they want in old stable releases, but maybe following Federico's suggestions would make companies contribute better to upstream GNOME. Would it have been possible to develop these changes as a public branch of the gnome-2.12 branch of the affected modules? While the gnome-2.12 branch is feature frozen, there is nothing stopping people from creating sub-branches. This might also make it easier to merge the changes forward if they turn out to be good :) James. ___ 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=Thom Holwerda But my point remains. How far are you willing to go? Must developers adhere to some sort of code of conduct-- a sort of extra set of requirements-- before they can contribute to the GNOME project? Because that is kind of how your viewpoint comes across here. I don't think we have to go that far. Certainly, clarity of structure and leadership will go a long way towards dealing with this, but those are hard things to manufacture. I'm thinking hard about how to to deal with this. It has compounded over a long, long time. You can see elements of my thinking about it in the 10x10 talk I did at GUADEC too - in the interplay between changing the rules and becoming the rules. This is as important as fixing 2.0 was. - Jeff -- II OSWC: Malaga, Spain http://www.opensourceworldconference.com/ I run Linux on pretty much everything except the microwave and washing machine. Those are tempting targets but would probably make Telsa extremely cross. - Alan Cox ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
It isn't about Design by community but Design IN the community. The former assumes everyone has something useful to say, the latter merely recognizes the value of code review, security checking, third party input that -may- be valuable, and possibly getting help. If you design stuff in secret then publish it, it will have no review of quality, no style checking, no security audit, no extra pairs of eyes and extra brains on it. Mouths are in oversupply but brains/eyes are not. Metacity and Nautilus have had many suggestions made and many of those went into the bin, but people were able to work on it, to build complementary tools and to help. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
On Mer, 2006-02-08 at 12:07 +0100, Rodrigo Moya wrote: 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? not if the changes are not kept proprietary and sent upstream sooner or later. Sorry have to disagree. If everyone writes a new replacement secret suprise panel menu how are you going to merge them all when they come out. Its too late by then, its forked and if the vendors are wedded to their style and version its forked for good. ___ 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=Alan Cox It isn't about Design by community but Design IN the community. *Exactly* - and it's so easy to fall to laziness in the face of all the challenges Dan so eloquently explained in his email... and that's what has been happening in GNOME for a long time now. Let's break the cycle! While the Linux process has its warts, there are two things it is great at that we should mention here: First, a fairly easy to understand technical and social leadership - decisions get made. Second, a pretty uncompromising approach to design in the community - it's really hard to drop a pre-cooked hairball (cat hair *or* angel hair) into the kernel process without getting roasted, spanked and harshly reviewed. - Jeff -- FISL 7.0: Porto Alegre, Brazilhttp://fisl.softwarelivre.org/7.0/www/ It's not sufficient to 'use simple words to explain things'. Things must actually *be* simple, which is much harder. - Martin Pool ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sorry State
On Wed, 2006-02-08 at 12:45 +0100, Arturo González wrote:
El mié, 08--2006 a las 12:29 +0100, Rodrigo Moya escribió:
On Wed, 2006-02-08 at 10:42 +0100, Arturo González wrote:
El mié, 08--2006 a las 10:10 +0100, Manu Cornet escribió:
I'm not saying taking our time to discuss changes is wrong (of course
not). But sometimes I just need to try something out. If there's a new
feature proposal, and some developers find it is a bad idea, but it
basically looks like a nice thing to try, then just let the guy code it,
make it better, and then let everyone actually try it.
I totally agree with you. I'm not contributing to Gnome but i am on
other open source projects where lots of code goes to CVS repository.
If you have a 'big idea' then sometimes you *can't* put it on CVS
cause you will surely interrupt the roadmap for the next release, you
would surely need to have the consensus from a lot of people, and you
would surely put your efforts on that task: convincing people. If
instead of that, you go your way and develop a new feature you can
always share your feature in a near future, perhaps in a next stage.
So the problem here seems to be that was Novell Inc. who take this
approach, and it wasn't the less important guy in this world who did
it. Let's suppose that these changes were all done by somebody totally
unknown. Surely he would become the next most loved Gnome hacker ey
look that guy!. My opinion is that community developers should wait
for Novell proposal to include it on Gnome 2.xx, or to make his own
fork to discuss about this new ('nice') injection of creativity on
Gnome. And of course, it must be discussed, but ... now come back to
your seat! :-).
it surprises to me people are talking about forks. So far, Ximian, and
then Novell, have always done big changes to the desktop, then include
what maintainers accepted, and, in all these years, there has never been
a fork, so, why do people talk about forks? It's not that Novell/Ximian
is a newcomer to the GNOME world and has to demonstrate its good
willings.
Hi Rodrigo,
Understand me in the right way, I talked about the unlikely
possibility that this would happen. What I say is exactly that: please
wait until Novell moves, because it has always been nice to Gnome
before. What Novell did is not a threat to nothing but people continue
worrying about it..., so let come back to work :).
yes, sorry, wasn't talking specifically to you, just to people
mentioning forks.
--
Rodrigo Moya [EMAIL PROTECTED]
___
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, 2006-02-08 at 19:51 +0800, James Henstridge wrote: Isn't what we got here exactly what has been asked for? That 'big' changes to GNOME needs to come from 'outside' projects? Havoc for instance was advocating that in his blog entries. So if people are unhappy about XYZ in GNOME, for instance the current panel. Due to it being so business critical we can't have experimentation going on in the gnome-panel CVS head, so 'radical' changes would need to be done as a separate project, and if it turns out good then it will at some point replace the current module. this is exactly what I was going to say :) It is indeed what some big GNOME names have been advocating for. And I agree with it. At novell, and I guess at other GNOME-related companies, we try to put as much fixes as possible upstream, but for radical changes, it makes sense to do them separately and merge them upstream if/when maintainers are ready to accept it. Sure it makes sense to develop radical changes on a branch rather than on the mainline, but this does not require secrecy. Collaboration doesn't need to be restricted to mainline development. Some of the benefits include: * Rather than dumping the change fully formed on the maintainer, they might take an early peak at the code and tell you whether there are problems with the design that would cause them to reject the change later on. * Reduce duplicated work: say someone else saw the mockups, decided that they were a great idea and started implementing it. What do they do when they find out that you've also been developing the feature. What should the maintainer do if both groups submit their respective patches for inclusion. There definitely are benefits to secrecy (better signal/noise ratio between developers, being first to market with the feature), but they aren't all benefits to the community. yes, completely agree with you. Also, current 6 months schedules make it difficult, at least from my experience, to introduce big changes. For big things, you usually need a couple of releases. Maybe we could improve this a little bit by forcing people to branch as soon as we hit the freezes, so that big changes can start immediately, instead of 2/3 months later (which is mostly what happens now, that most people start branching a few weeks after the final *.*.0 release). Who says that a big change needs to be completed in 6 months? For some changes it might make sense to skip a release, which also lets you continue working through the feature freeze. yes, that's ok for maintainers, but for outsiders, not really. There are lots of feature-related patches in bugzilla waiting for maintainers to branch. Also, Federico suggested some time ago, IIRC, keeping the old stable branches more alive than what they are right now. For instance, NLD10 is based on GNOME 2.12, so it makes it impossible to introduce radical changes in the upstream GNOME version, which is frozen. Of course, I'm not saying we should allow companies to put whatever they want in old stable releases, but maybe following Federico's suggestions would make companies contribute better to upstream GNOME. Would it have been possible to develop these changes as a public branch of the gnome-2.12 branch of the affected modules? While the gnome-2.12 branch is feature frozen, there is nothing stopping people from creating sub-branches. This might also make it easier to merge the changes forward if they turn out to be good :) yes, also agree with you. I can say though that the changes are not as radical as you might imagine. xgl/compiz is, of course, but this is completely new material, and the new menu is not a patch to the panel, but a separate applet, which can, I guess, easily be integrated into the panel/desktop releases. As for other changes, most are upstream in one form or the other. Notifications (libnotify), login speedup improvements (g-c-c and gnome-session), gnome-volume-manager, networkmanager, etc, etc -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
ons, 08,.02.2006 kl. 23.20 +1100, skrev Jeff Waugh: quote who=Alan Cox It isn't about Design by community but Design IN the community. *Exactly* - and it's so easy to fall to laziness in the face of all the challenges Dan so eloquently explained in his email... and that's what has been happening in GNOME for a long time now. Let's break the cycle! While the Linux process has its warts, there are two things it is great at that we should mention here: First, a fairly easy to understand technical and social leadership - decisions get made. Second, a pretty uncompromising approach to design in the community - it's really hard to drop a pre-cooked hairball (cat hair *or* angel hair) into the kernel process without getting roasted, spanked and harshly reviewed. I think the main difference here is that most of the design/review/audit process for the linux-kernel happens on the mailing list[s] and we tell people to go argue about it in bugzilla. The reason we point people to other lists/bugzilla is exactly that we have the problem of too few eyes/minds and too many mouths on desktop-devel-list for example. We're not going to get around that by creating yet another mailing list every time we get annoyed by some thread that propelled into a useless semantic discussion or whatever. I think we'd be served well by making desktop-devel-list be *the* place for discussion about development and design issues and use other tools like bugzilla etc to complement this where that makes sense. If we compare ourselves to the linux-kernel we're seeing ridiculously small amounts of mail to our list compared with them. Use your power to delete a thread or a message if something is of no interest to you. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On 2/8/06, Calum Benson [EMAIL PROTECTED] wrote: On Tue, 2006-02-07 at 10:25 -0700, Elijah Newren wrote: 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. Ok, well... what I'd suggest then is that we[1] maybe try and do a UI review of the components whose maintainers have expressed an interest in being reviewed (or who express such an interest in the next day or two), and just seek approval for those changes. And then do it properly again next time :) 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? I'm not sure exactly what an ideal process would look like, but it is clear that we need one- this is really critical, important, sadly vasty underappreciated work. Luis ___ 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, 2006-02-08 at 11:09 +, Jamie McCracken wrote: Rodrigo Moya wrote: On Wed, 2006-02-08 at 12:57 +0800, Davyd Madeley wrote: 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? not if the changes are not kept proprietary and sent upstream sooner or later. perhaps but the real question is why isn't this a branch in CVS? Why is there a need for clandestine development? Maybe because CVS branches are inherently complicated. And maybe because you have to ask permission of the maintainer before creating a branch on a module. And maybe because if everyone starts making lots of branches, your namespace of CVS branches/tags starts to get polluted very quickly. I know some very wise people have decided, apparently without much discussion with the community, that GNOME would switch to Subversion. But I keep thinking that, although Subversion is much better than CVS, maybe we would benefit more from a distributed version control system, like mercurial, bzr, git, monotone, etc. I keep wondering whether the decision to switch to Subversion is due to the large number of similar looking alternatives and lack of courage from the GNOME leadership to pick one, while in the centralized version control systems Subversion is becoming _the_ alternative to CVS, so it's easier to pick Subversion rather than _choose_ one of the distributed control systems. There's a very interesting thread in the cairo list regarding a potential switch from CVS to git. I commend Carl Worth for the courage of proposing this; maybe the GNOME project should take cue from him. [1] http://lists.freedesktop.org/archives/cairo/2006-February/006255.html -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. 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
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? Yeah, that's totally what Bryan was advocating a couple of releases ago, which is why we didn't really do one at the end of the release last time. Since he and Seth seem to have lost their mailing list voices recently though, we've kind of dropped the ball and done it at neither end this time :/ 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: Design by Community
On Wed, 2006-02-08 at 14:20 +, Gustavo J. A. M. Carneiro wrote: I know some very wise people have decided, apparently without much discussion with the community, that GNOME would switch to Subversion. But I keep thinking that, although Subversion is much better than CVS, maybe we would benefit more from a distributed version control system, like mercurial, bzr, git, monotone, etc. I've seen lots of discussion about Subversion vs Arch vs Bazaar (in various forms) on gnome-hackers. I keep wondering whether the decision to switch to Subversion is due to the large number of similar looking alternatives and lack of courage from the GNOME leadership to pick one, while in the centralized version control systems Subversion is becoming _the_ alternative to CVS, so it's easier to pick Subversion rather than _choose_ one of the distributed control systems. Correct. Subversion means that existing developers can pick it up in no time, so from a developer PoV its a pretty painless operations (obviously from the cvs admin PoV its trickier, but not as hard as migrating to arch and training all developers). As was bought up in the original thread on this topic, bazaar.ubuntu.com contains daily-synced Bazaar archives of the GNOME CVS modules, so if you want to do a remote branch of a module to hack on it, you can. I did the ICC work on Eye Of Gnome this way, and it was very useful. Yes, it has drawbacks, but without forcing everyone to learn an completely new tool, migrating to svn and providing bazaar mirrors covers pretty much all cases. There's a very interesting thread in the cairo list regarding a potential switch from CVS to git. I commend Carl Worth for the courage of proposing this; maybe the GNOME project should take cue from him. I know kernel developers that think git is over-complicated and confusing... 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design by Community
Hi, I know some very wise people have decided, apparently without much discussion with the community, that GNOME would switch to Subversion. But I keep thinking that, although Subversion is much better than CVS, maybe we would benefit more from a distributed version control system, like mercurial, bzr, git, monotone, etc. One of the drawbacks of these distributed version control systems is precisely the fact that it makes it very easy to keep private branches around. All things equal, it would work against the goal of trying to make sure development happens in public. That's probably a very good reason why subversion may be the best choice for GNOME at this point. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ -*- thomas (dot) apestaart (dot) org -*- nobody's interested in something you didn't do -*- thomas (at) apestaart (dot) org -*- URGent, best radio on the net - 24/7 ! - http://urgent.fm/ ___ 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]
quote who=Anna Marie Dirks What a big jerkbird! So lazy! So community-tearing! Definitely the work of an evil, evil noncontributor. Anna, as I mentioned in another email, this frustration is about a broader problem we have in our community than the particular acts of contributing organisations or individuals. Definitely a large portion of the frustration you read in my email was aimed at *myself*, as I have also contributed to this 'sorry state' of affairs. It was not a good email. It was too emotive in precisely the wrong context. (A similar set of issues were expressed more eloquently in my GUADEC talk, if you want to watch that video.) - Jeff -- FISL 7.0: Porto Alegre, Brazilhttp://fisl.softwarelivre.org/7.0/www/ The cool stuff coming out of freedesktop.org doesn't just happen as the result of an accident with a particle accelerator and a goat: it only happens when people hack on it. - Daniel Stone ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Alan Cox wrote: So if Fedora, Ubuntu and every other Gnome using distribution also start doing tons of private development (Excluding Xgl, there was hardly tons of private development.) then trying to jam it all in CVS afterwards how do you expect Gnome to develop when all these variants suddenely try and get merged and all overlap and clash. We don't. A lot of people have assumed that we're expecting to force the new menu code into the GNOME mainline at some point, which I guess is a reasonable assumption given what happened with Ximian Desktop, etc, but that was never the plan here. At the moment we're not even planning to ship it in SUSE 10.1 (which is 90% the same codebase as NLD10). The new menu is something we did for NLD, and if the community wants it too, then great, but we didn't do it with the expectation that they necessarily would. It's like Industrial was. Nor does the committee argument stand up. It is perfectly possible to post in advance that we are going to do this, we've created a temporary alternate repository for the work and if you want to join in or help merge stuff back as it meets acceptability please sign up Yes, I shouldn't have suggested that secrecy was a necessary part of the mix. The secrecy doesn't necessarily help. But how does it actually *hurt*? Yes, there are integration issues in some cases, but not in this case. Yes, there are code review issues as you mentioned in another message, but it's not like the GNOME community and/or Red Hat is reviewing the work we do on YaST or iFolder or any of dozens of other non-GNOME things, so that argument also feels weak. Novell has also been doing tons of GNOME work in the open, so it's not like we're trying to get a free ride off GNOME. So what exactly have we done wrong? -- Dan ___ 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 02:20:15PM +, Gustavo J. A. M. Carneiro wrote: perhaps but the real question is why isn't this a branch in CVS? Why is there a need for clandestine development? Maybe because CVS branches are inherently complicated. And maybe because you have to ask permission of the maintainer before creating a branch on a module. And maybe because if everyone starts making lots of branches, your namespace of CVS branches/tags starts to get polluted very quickly. There is a saying here about poor workmen and tools. Perhaps CVS is not the best revision control system invented by man, but by the same token it works pretty good, has enabled us to create an excellent product, and seems to work for most of what we want to do 90% of the time. Interestingly, if you ask to create a development branch, most maintainers will say yes. If you create a branch like novell-development, you get the power to use it over and over again. --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: UI Review
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? --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: Design by Community
On Wed, 2006-02-08 at 15:10 +, Ross Burton wrote: On Wed, 2006-02-08 at 14:20 +, Gustavo J. A. M. Carneiro wrote: I know some very wise people have decided, apparently without much discussion with the community, that GNOME would switch to Subversion. But I keep thinking that, although Subversion is much better than CVS, maybe we would benefit more from a distributed version control system, like mercurial, bzr, git, monotone, etc. I've seen lots of discussion about Subversion vs Arch vs Bazaar (in various forms) on gnome-hackers. I keep wondering whether the decision to switch to Subversion is due to the large number of similar looking alternatives and lack of courage from the GNOME leadership to pick one, while in the centralized version control systems Subversion is becoming _the_ alternative to CVS, so it's easier to pick Subversion rather than _choose_ one of the distributed control systems. Correct. Subversion means that existing developers can pick it up in no time, so from a developer PoV its a pretty painless operations (obviously from the cvs admin PoV its trickier, but not as hard as migrating to arch and training all developers). As was bought up in the original thread on this topic, bazaar.ubuntu.com contains daily-synced Bazaar archives of the GNOME CVS modules, so if you want to do a remote branch of a module to hack on it, you can. That's not entirely helpful. First, you still have to master CVS to commit. We'd end up using two different CLIs for the same thing. Also, bazaar.ubuntu.com contains archives in the old bazaar 1.x format, while they recommend bazaar-NG now (bzr). Finally, the archive only mirrors a few (24) GNOME modules, not the entire CVS tree. I did the ICC work on Eye Of Gnome this way, and it was very useful. Yes, it has drawbacks, but without forcing everyone to learn an completely new tool, migrating to svn and providing bazaar mirrors covers pretty much all cases. There's a very interesting thread in the cairo list regarding a potential switch from CVS to git. I commend Carl Worth for the courage of proposing this; maybe the GNOME project should take cue from him. I know kernel developers that think git is over-complicated and confusing... Well, then at least mercurial or bzr; they at least are not over-complicated from my experience. I can't comment on git since I never used it. -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
ons, 08,.02.2006 kl. 10.55 -0500, skrev Dan Winship: Alan Cox wrote: So if Fedora, Ubuntu and every other Gnome using distribution also start doing tons of private development (Excluding Xgl, there was hardly tons of private development.) then trying to jam it all in CVS afterwards how do you expect Gnome to develop when all these variants suddenely try and get merged and all overlap and clash. We don't. A lot of people have assumed that we're expecting to force the new menu code into the GNOME mainline at some point, which I guess is a reasonable assumption given what happened with Ximian Desktop, etc, but that was never the plan here. At the moment we're not even planning to ship it in SUSE 10.1 (which is 90% the same codebase as NLD10). The new menu is something we did for NLD, and if the community wants it too, then great, but we didn't do it with the expectation that they necessarily would. It's like Industrial was. In a sense, but a theme is more self-contained and wouldn't need review in full the samme way that an extension to the panel menu code would. Nor does the committee argument stand up. It is perfectly possible to post in advance that we are going to do this, we've created a temporary alternate repository for the work and if you want to join in or help merge stuff back as it meets acceptability please sign up Yes, I shouldn't have suggested that secrecy was a necessary part of the mix. The secrecy doesn't necessarily help. But how does it actually *hurt*? Yes, there are integration issues in some cases, but not in this case. Yes, there are code review issues as you mentioned in another message, but it's not like the GNOME community and/or Red Hat is reviewing the work we do on YaST or iFolder or any of dozens of other non-GNOME things, so that argument also feels weak. Novell has also been doing tons of GNOME work in the open, so it's not like we're trying to get a free ride off GNOME. So what exactly have we done wrong? I don't think you've done anything wrong. Nothing that isn't weighed up by the great contribution this is to making linux on the desktop succeed. It just happens to stomp on a sore foot, so to speak. This is a community problem and it's the community that has to solve it if we want to avoid this kind of thing happening in the future. Good thing Novell is part of the community too :-) Looking forward to seeing some of this incredibly cool technology pop up on my desktop too one of these days. I think also that we sometimes put too much emphasis on never duplicating code or effort. I really think that it gives the community as a whole more experience in how to approach a certain problem and that both sides can learn from each other's mistakes when this happens. I'm sure there are lessons to be learned from metacity/libcm/compositor vs. Xgl/compiz that will benefit both projects long term. There are probably other examples of the same. I do mostly agree that you could have achieved the same step forward codewise without the secrecy, but it would have created a fuss and you would have lost the fun of announcing something entirely new to the world :) Cheers and thanks to everyone involved for doing all the work this must have been. Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: G_MODULE_BIND_LOCAL broke nautilus-python extension
So it seems that the desktop wide decision to load all modules with G_MODULE_BIND_LOCAL, for performance reasons, may break python extensions. So far, nautilus-python was affected by this. Do people have any suggestions? Clearly Python has to be fixed, but that is a long term fix; how to fix things _now_? On Wed, 2006-01-25 at 13:41 +, Gustavo J. A. M. Carneiro wrote: On Wed, 2006-01-25 at 10:15 +0100, Alexander Larsson wrote: On Wed, 2006-01-25 at 00:22 +, Gustavo J. A. M. Carneiro wrote: Regarding this change (after 2.13.3): 2005-12-13 Alexander Larsson [EMAIL PROTECTED] * libnautilus-private/nautilus-module.c (nautilus_module_load): open modules G_MODULE_BIND_LOCAL It has broken nautilus-python. See bug #327739. The problem is that python modules expect to find some standard python symbols in the global scope, but since nautilus is loading the nautilus-python extension module---and consequently libpython24.so itself---in a private scope, all python extension modules fail to load. Any thoughts? The whole move to BIND_LOCAL is a gnome-wide thing we're doing for performance reasons. All other places loading modules were changed similarly. Maybe we should discuss this in a wider scope? I understand and generally agree with this. Python itself loads all modules in a local scope. I remember how this used to affect some gtk engines until they were fixed to link explicitly to gtk. How can python module look up things in the global scope only? Surely the nautilus-python library links to libpython, and thus all the symbols in that should be availible to all code that nautilus-python loads? nautilus-python library links to libpython, but both nautilus-python library and libpython are bound to a local scope. libpython then loads python modules, but python modules never explicitly link to libpython (because many times there is no python dll available, only the exe). Apparently, modules loaded by a library don't automatically use that library's scope, but instead try to rely on the global scope. Clearly python is broken in this respect. The python shared library should always be available, and all python extension modules should link to it. Then we would not have this problem. But as it is, there's nothing we can do. I wish there was some way to open an exception just for nautilus-python, make it load with global symbol visibility instead? Maybe some metadata xml file. Or some special naming convention for the library name? Yes, it's a bit hackish, I'm ashamed to suggest it :P (Clearly I'm not an expert in these things...) Me neither. James, maybe you can help us? :) Regards, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ 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: Gnome-utils branched to gnome-2-14
On Mon, 6 Feb 2006, Wouter Bolsterlee wrote: Date: Mon, 6 Feb 2006 20:56:56 +0100 From: Wouter Bolsterlee [EMAIL PROTECTED] To: desktop-devel-list@gnome.org Subject: Re: Gnome-utils branched to gnome-2-14 P?? Mon, Feb 06, 2006 at 11:41:16AM -0600, Shaun McCance skrev: On Mon, 2006-02-06 at 10:26 +0100, Emmanuele Bassi wrote: Screenshot * heavy bugzilla love * remove the file name entry and use a filechooser button I don't like this idea. I mean, arguably, we have a file chooser button for exactly this sort of thing. But the fact that we have a widget doesn't mean it's the best tool. I remain baffled how the file chooser button was designed. Everywhere we have text entries followed by a Browse button but the File Chooser button looks nothing like this. Instead of a widget to encapsulate this established idea there is a button which looks confusingly like a drop down menu. I've never liked how the file chooser button was implemented, and how significantly it diverged from what is it supposed to be a drop in replacement. It is certainly good to have a standard API for this commonly used feature, perhaps the file chooser widget will be improved some day and thanks to the standard API applications already using it would benefit. So are we making this change because we really believe it's better, or are we using widgets for the sake of using them? I'd prefer if you didn't use the file chooser button but ideally I'd like to see a better file chooser button. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Dia http://gnome.org/projects/dia/ Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
On Wed, 2006-02-08 at 17:43 +0100, Kjartan Maraas wrote: In a sense, but a theme is more self-contained and wouldn't need review in full the samme way that an extension to the panel menu code would. It's not an extension to the panel menu code. It's not even a patch. It's a completely separate applet. This is in fact, in no way different than a theme engine in terms of integrating it upstream, into a larger conglomerate package. Why do people keep assuming every change someone does, is a patch? There are much better ways to do a lot of this stuff, than patches, with the architecture we have. And frankly, we need to show ISVs that it can be done, so they will start doing it too. We need their support, if we're going to succeed at actually getting Linux and GNOME to be usable and on desktops in the Real World (TM). -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On Thu, 2006-02-09 at 00:07 +0800, Davyd Madeley wrote: 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. Theme changes, even to the default theme, haven't historically come under the banner of UI reviews, as they generally implement the stuff that the HIG doesn't talk about because it's expected to just work. So unless the new Clearlooks has fundamentally changed the way any controls look or behave, it's probably just a case of filing regular bug reports about anything irksome. I agree it would be useful to cast an accessibility eye over it though, to make sure that things like focus indicators still work right, and that labels are contrasty enough to be legible for the vast majority of users. As Thomas said, though, let's take that to the gnome-themes list. 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, 7 Feb 2006, Ross Burton wrote: Date: Tue, 07 Feb 2006 15:28:33 + From: Ross Burton [EMAIL PROTECTED] To: Calum Benson [EMAIL PROTECTED] Cc: desktop-devel-list@gnome.org desktop-devel-list@gnome.org Subject: 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. Sound Juicer was a great ripper. Sound Juicer was not a music player. Now Sound Juicer is a ripper which can also preview/playback the tracks. You claims about using Sound Juicer as a music player is where much of the criticism came from. Sound Juicer can be used as a music player if you really want but it is not as well suited for that task. The criticism was hardly an attack by raving hordes. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Credit, Leadership and Vision [Was: Sorry State]
On Thu, 2006-02-09 at 04:01 +1100, Jeff Waugh wrote: quote who=Havoc Pennington Jeff, you're right that Steve Jobs style big press release is incompatible with community development (though I don't think it's a moral issue perhaps, I think it's legitimate to make the tradeoff as long as one is willing to eat the consequences). Hmm, so that wasn't a point that I was trying to make, and oddly enough, I also disagree! ;-) I definitely think there is room for the contributing companies to make sure they get credit for their contributions. Even with in community development (as opposed to by community development, thanks to Alan for an important clarification), I think it's doable and valuable. Maybe it's my point and not yours ;-) but I don't think you can get the giant media splash without secrecy (though this is relative; NLD10 got the trade press, Steve Jobs got Time Magazine). Credit with the community, sure, that's different. You get _more_ of that working in the open. Anyhow; I don't think the Apple/Google technique of hype-creation through secrecy followed by splashy demo really works with the open source development model, is all I'm saying. It can work with code that happens to have an open source license. But the larger problem right now is what I described above, the lack of direction; if the community had that, they would just steamroll over the cosmetics coming in from the Linux distributions. We are without coherent leadership. You emphasised having a vision/agenda in your email, where I tend to emphasise leadership or structure, to aid in the creation of that agenda. Is this a chicken / egg problem that we have to solve? I don't really know the solution to be honest. It's not like I've solved this. It might be interesting to try the no net leap of faith approach; immediately make some technical/branding decisions that are so severe and heretical for direction A that the direction A users and developers bail out, then go hardcore in direction B because direction A has been sealed off for good. GNOME 2 made a lot of people threaten to bail out, but didn't really commit to tossing people overboard. Number of people you toss out depends on the direction chosen ;-) it might not be that many. Either way, why not focus on changing the front page of gnome.org where it says GNOME is a Unix and Linux desktop suite and development platform. Make it say something someone could disagree with, or something that implies a project direction. A good definition for a project would not apply to competing projects as well. http://gnome.org/about/ is pretty lame too, since it applies to almost any software you can think of, in theory. It's like having the mission statement do stuff that's a good idea or something. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
ons, 08,.02.2006 kl. 12.09 -0500, skrev Rodney Dawes: On Wed, 2006-02-08 at 17:43 +0100, Kjartan Maraas wrote: In a sense, but a theme is more self-contained and wouldn't need review in full the samme way that an extension to the panel menu code would. It's not an extension to the panel menu code. It's not even a patch. It's a completely separate applet. This is in fact, in no way different than a theme engine in terms of integrating it upstream, into a larger conglomerate package. Why do people keep assuming every change someone does, is a patch? There are much better ways to do a lot of this stuff, than patches, with the architecture we have. I'm all the more pleased to hear this. Maybe if this had been communicated more clearly from the outset we would have avoided this kind of confusion :-) (or maybe I didn't do my homework before commenting). Anyway, this wasn't really the important part of my reply to Dan so don't read too much into it. And frankly, we need to show ISVs that it can be done, so they will start doing it too. We need their support, if we're going to succeed at actually getting Linux and GNOME to be usable and on desktops in the Real World (TM). I agree fully. Cheers Kjartan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On Wed, 2006-02-08 at 17:36 +, Alan Horkan wrote: 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. Sound Juicer was a great ripper. Sound Juicer was not a music player. Now Sound Juicer is a ripper which can also preview/playback the tracks. You claims about using Sound Juicer as a music player is where much of the criticism came from. Sound Juicer can be used as a music player if you really want but it is not as well suited for that task. The criticism was hardly an attack by raving hordes. Whoa, I needed some smilies in there. I totally appreciate the criticism that the usability list gave, and would like some more of it. Raving hordes was meant to be a humorous comment, and was not intended in a negative way. 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: NLD10 and GNOME
Rodney Dawes wrote: On Wed, 2006-02-08 at 17:43 +0100, Kjartan Maraas wrote: In a sense, but a theme is more self-contained and wouldn't need review in full the samme way that an extension to the panel menu code would. It's not an extension to the panel menu code. It's not even a patch. It's a completely separate applet. This is in fact, in no way different than a theme engine in terms of integrating it upstream, into a larger conglomerate package. Why do people keep assuming every change someone does, is a patch? There are much better ways to do a lot of this stuff, than patches, with the architecture we have. glad to hear it - perhaps some of us were overreacting a bit :) wrt to yer blog post regarding code drops at release time, I hope you and Novell can be persuaded to do more development in the open just for the sake of fairness (as we currently have a level playing field with the vast majority of Gnome software being done in the open). No one would complain if a small company or some individuals did stuff secretly but a big company like Novell should set a good example here. Profit from open source has always centered around support and services rather than a panel applet or two so I doubt you will lose anything and its certainly not worth the loss of good community relations. (btw big thank you for XGL - Im using it now and it rocks way better than OS/X and vista) -- 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
Re: NLD10 and GNOME
Hi, On Wed, 2006-02-08 at 12:09 -0500, Rodney Dawes wrote: It's not an extension to the panel menu code. It's not even a patch. It's a completely separate applet. This is in fact, in no way different than a theme engine in terms of integrating it upstream, into a larger conglomerate package. Why do people keep assuming every change someone does, is a patch? There are much better ways to do a lot of this stuff, than patches, with the architecture we have. Well, to be fair, it's not like they can just look at the code and know this. ;) I don't think such a kneejerk reaction is so overboard judging from a single mockup and a fuzzy freeze frame in a video. Joe ___ 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, 2006-02-08 at 23:57 +0800, Davyd Madeley wrote: On Wed, Feb 08, 2006 at 02:20:15PM +, Gustavo J. A. M. Carneiro wrote: perhaps but the real question is why isn't this a branch in CVS? Why is there a need for clandestine development? Maybe because CVS branches are inherently complicated. And maybe because you have to ask permission of the maintainer before creating a branch on a module. And maybe because if everyone starts making lots of branches, your namespace of CVS branches/tags starts to get polluted very quickly. There is a saying here about poor workmen and tools. Perhaps CVS is not the best revision control system invented by man, but by the same token it works pretty good, has enabled us to create an excellent product, and seems to work for most of what we want to do 90% of the time. Interestingly, if you ask to create a development branch, most maintainers will say yes. If you create a branch like novell-development, you get the power to use it over and over again. A CVS branch has limited use. If you create a branch at some point in time, you can work on your stuff all you want, but as side effect you suddenly stop tracking HEAD development. From time to time you need to 1) extract a patch with changes from branch; 2) create a new branch based on HEAD; 3) reapply your patch to the new branch. At least, I don't think you can 'move' a branch, although it could be the case of my lack of CVS expertise. And if you can't move a branch you have create a new one, thus starting to pollute the tag/branch namespace. And I have a case when I forgot to add a regular tag at the start of a branch. So now I'm finding it very hard to obtain a diff of all changes since I started the branch. I'll have to do it manually, file by file, looking at revision numbers :-/ CVS branches are hard, you have to admit it ;-) -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On Wed, 8 Feb 2006, Ross Burton wrote: Date: Wed, 08 Feb 2006 18:10:42 + From: Ross Burton [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: desktop-devel-list@gnome.org desktop-devel-list@gnome.org Subject: Re: UI Review On Wed, 2006-02-08 at 17:36 +, Alan Horkan wrote: 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. Sound Juicer was a great ripper. Sound Juicer was not a music player. Now Sound Juicer is a ripper which can also preview/playback the tracks. You claims about using Sound Juicer as a music player is where much of the criticism came from. Sound Juicer can be used as a music player if you really want but it is not as well suited for that task. The criticism was hardly an attack by raving hordes. Whoa, I needed some smilies in there. I assumed a certian amount of sarcasm but I also recognise that you disagree with much of the criticsm which of course you are entitled to do. In that context the comment about ignoring the feedback sounded a little too close to the truth to be funny. I totally appreciate the criticism that the usability list gave, and would like some more of it. Raving hordes was meant to be a humorous comment, and was not intended in a negative way. Sorry for misinterpreting your comments. - Alan H. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Less antiquated format for animations (was: Plan to fix icons [was: Re: breakage caused by removed icons from gnome-icon-theme])
On 2/7/06, Matthias Clasen [EMAIL PROTECTED] wrote: 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. FWIW we chose to use ANIs for animations in maemo basically because it supports 8-bit alpha *and* is already supported by gtk+. Making ANIs themable similar to icons is pretty straightforwad, just add ANI to the hardcoded list of formats icon theme currently supports. Of course it's a bit of a stretch to call animations icons, but the context of use is pretty much the same. -- Tommi Komulainen [EMAIL PROTECTED] ___ 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/8/06, Jamie McCracken [EMAIL PROTECTED] wrote: wrt to yer blog post regarding code drops at release time, I hope you and Novell can be persuaded to do more development in the open just for the sake of fairness (as we currently have a level playing field with the vast majority of Gnome software being done in the open). No one would complain if a small company or some individuals did stuff secretly but a big company like Novell should set a good example here. Actually it is the big companies that have very extensive and tedious legal processes in place for code, they have a lot to lose in court of law if someone working there steals code from someone else for example. Small companies probably won't have as much resources or interest for screening. A good example of this is the Maemo platform which had very slow turnup on (open source licensed) code to the svn repository just or at least mainly because of legal checks and other corporate stuff (or so I've gathered from the responses to community queries about sources). Profit from open source has always centered around support and services rather than a panel applet or two so I doubt you will lose anything and its certainly not worth the loss of good community relations. If it's just an applet or two they were making, why the fuss?-) I mean, I'm making a theme engine (for Maemo) but haven't released anything yet. Will you behead me for being secretive when I do or just let it slide because I'm tweeny-tiny myself and not a big company? Just because I want it to have more than the one widget themeing before I realease anything? /a bit provocative reply for which the author apologizes in advance in case it makes anyone feel bad -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On Wed, 2006-02-08 at 17:19 +, Calum Benson wrote: On Thu, 2006-02-09 at 00:07 +0800, Davyd Madeley wrote: 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. Theme changes, even to the default theme, haven't historically come under the banner of UI reviews, as they generally implement the stuff that the HIG doesn't talk about because it's expected to just work. So unless the new Clearlooks has fundamentally changed the way any controls look or behave, it's probably just a case of filing regular bug reports about anything irksome. Nonetheless, the UI freeze and announcement period are there, at least in part, there for the documentation team. In fact, the announcement period was explicitly requested by me, for the documentation team, a few release cycles back. Changing the look of standard widgets affects every single screenshot in every piece of documentation, core Gnome or otherwise. And that also means every translation of every piece of documentation. That's a lot of pixels. Having said that, we should be extremely careful about how much we change the default look each release cycle. The world doesn't revolve around our release schedule, and we can't expect everybody to retake all their screenshots just because we decided we, for this six months, we'd like some more blue, or a different style of icons. Let's look at Apple. With every release (which are nowhere near as frequent as ours), they have refined the interface. The ribbing got less ribbed, the tones got more subdued. But it was all very gradual. Now, six months ago, we made a radical change in our default look by adopting the old Clearlooks. I'm not criticizing that move. In fact, I believe it was me that made the final decision. It had to be done. If anything, it helped foster consistency. Our old theme was so ugly that all the major vendors changes it. And, of course, they all used their own default theme in their own documentation. And then various other people producing various other software used whatever theme they happened to like. With Clearlooks, we produced something that at least some of the vendors could converge on, meaning the documentation produced by those vendors could look the same. And I'd like to think that that caused some of the independents to do the same thing. So, in that case, a radical change was needed. The ups far outweighed the downs. But that does not mean that radical changes are always good. Every few years, maybe. Every few months, absolutely not. We can make gradual changes, though. But once we've made a stable release, the cat's out of the bag. We can't go back, we must only go forward with what we've got. Right now, we've only put this look into our betas. We can still change it. It will have an impact on people, to be sure, but it can be done. Once we put 2.14.0 out, we're stuck with what we've got. So we better be damn sure we like what we're doing. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Less antiquated format for animations
On Wed, 2006-02-08 at 21:27 +0200, Tommi Komulainen wrote: On 2/7/06, Matthias Clasen [EMAIL PROTECTED] wrote: 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. FWIW we chose to use ANIs for animations in maemo basically because it supports 8-bit alpha *and* is already supported by gtk+. Making ANIs themable similar to icons is pretty straightforwad, just add ANI to the hardcoded list of formats icon theme currently supports. Do KDE and other toolkits support ANI by default? I would much rather push to get APNG as a standard, and implemented everywhere, though. This way it will at least display the first frame for implementations that support PNG but not APNG, rather than nothing at all. However, I just decided to advise the large-PNG-of-frames method in the Naming Spec, as GNOME and KDE both already use it. -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Less antiquated format for animations
On 2/8/06, Rodney Dawes [EMAIL PROTECTED] wrote: On Wed, 2006-02-08 at 21:27 +0200, Tommi Komulainen wrote: On 2/7/06, Matthias Clasen [EMAIL PROTECTED] wrote: 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. FWIW we chose to use ANIs for animations in maemo basically because it supports 8-bit alpha *and* is already supported by gtk+. Making ANIs themable similar to icons is pretty straightforwad, just add ANI to the hardcoded list of formats icon theme currently supports. Do KDE and other toolkits support ANI by default? I would much rather push to get APNG as a standard, and implemented everywhere, though. This way it will at least display the first frame for implementations that support PNG but not APNG, rather than nothing at all. However, I just decided to advise the large-PNG-of-frames method in the Naming Spec, as GNOME and KDE both already use it. That spec is a one-man show, I assume then ? ___ 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]
On Wed, 2006-02-08 at 11:28 -0500, Havoc Pennington wrote: If you guys want a specific productive suggestion, I think these are two de facto directions that could just be adopted; one is a kind of building block platform shared among the GNOME desktop, Maemo, GPE, XFCE even [2]; it might benefit from becoming explicitly targeted toward multiple projects? Emphasize fd.org more. I don't know. Two is a GNOME desktop that is still largely UNIX/shell-user/developer-oriented, designed for the customers of today's Linux distributions. Focus on this more and do it better. If the community wants to go beyond these de facto directions, I think it's possible, but only if people have the courage to commit to their chosen audience and recognize that it means not serving some other audiences. In the past, we lacked that courage for whatever reason. Good thinking, as always. However, if we decide to target a niche audience, on a niche operating system, that's niche squared. I doubt if that's sustainable. Jon Kåre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Less antiquated format for animations
On Wed, 2006-02-08 at 15:33 -0500, Matthias Clasen wrote: That spec is a one-man show, I assume then ? The Icon Naming Spec? Or the APNG spec? I don't know much aobut the APNG spec really. It was brought up in #tango a week or so ago, when we were discussing animations and how to deal with them. As for the Icon Naming Spec, no. I did all of the editing/writing work for the spec, and a large part of the actual naming, but spent quite a lot of time discussing with Jakub and Tuomas initially. Of course, I never really got much feedback on it, via the xdg list and such, initially, either. But once we started working on Tango internally before announcing the project and releasing it, I started pushing forward harder with the spec, so that we can actually get something done about the problem. It may be hard to get people to give feedback on a proposal initially, but once they are forced to give feedback, things go much more smoothly. :) The later revisions of the spec are based on a lot of feedback from users of Tango, as well as GNOME, KDE, and such. So no, I wouldn't say that it's a one-man show, but I do all the editing work on the spec, and maintainence of the tools, tango-icon-theme and gnome-icon-theme, with the artists taking care of the icons, and providing feedback when needed. Unfortunately, the KDE artists or other community members, still have not really given much feedback on the spec. But, despite that, we can still work to support KDE in a reasonable manner, thanks to some of the users, who have been helping out in #tango. Especially Niko Mirthes, who has been testing Tango on KDE quite a lot, submitting patches for the naming utils, and getting me to fix some of the issues in the spec, to make it easier for KDE to use as well. He's also made a couple of patches, so that KDE will handle the new contexts that are laid out in the Naming Spec, which greatly improves the situation on KDE. -- dobey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Less antiquated format for animations
On 2/8/06, Rodney Dawes [EMAIL PROTECTED] wrote: On Wed, 2006-02-08 at 15:33 -0500, Matthias Clasen wrote: That spec is a one-man show, I assume then ? The Icon Naming Spec? Or the APNG spec? I don't know much aobut the APNG spec really. It was brought up in #tango a week or so ago, when we were discussing animations and how to deal with them. As for the Icon Naming Spec, no. I did all of the editing/writing work for the spec, and a large part of the actual naming, but spent quite a lot of time discussing with Jakub and Tuomas initially. Of course, I never really got much feedback on it, via the xdg list and such, initially, either. But once we started working on Tango internally before announcing the project and releasing it, I started pushing forward harder with the spec, so that we can actually get something done about the problem. It may be hard to get people to give feedback on a proposal initially, but once they are forced to give feedback, things go much more smoothly. :) Sorry, I don't follow #tango. The most appropriate forum to discuss a spec which is hosted on www.freedesktop.org and claims to be an extension of the icon theme spec is still xdg-list, in my opinion. And adding animations to icon themes certainly goes beyond simply agreeing on a set of names for icons, so I definitively think it should be discussed on xdg-list, a discussion between dobey, jimmac and tuomas on #tango does not cut it. You can consider this to be forced feedback, if you want. Matthias ___ 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]
On Wed, 2006-02-08 at 21:54 +0100, Jon K Hellan wrote: However, if we decide to target a niche audience, on a niche operating system, that's niche squared. I doubt if that's sustainable. Didn't say niche, I said specific. The group can still be large. There are many, many well-defined subsets of the world's billions of people that still contain a hell of a lot of people. And the whole point here is to remove the nicheness of the software (whether it's an OS, I don't know), by appealing strongly to a specific group that wants to use it. Would you expect a sports car with a truck bed to appeal to more people than a regular truck or regular sports car? I would not. Not choosing an audience doesn't mean you appeal to everyone. It means you appeal to everyone in some ways *and* make everyone hate you in some ways, so nobody really likes you overall. What you want to do is be sure some group of people likes you in *almost all important respects*. The fallacy is to think that indecisiveness avoids the decision and leads to universal appeal. It does not. It leads to either a de facto decision (best case), or a totally incoherent piece of software (worst case). Sure, the trick is in picking a group that's specific enough but not too niche, and in trying to appeal to multiple similar enough groups, while not breaking your appeal by chasing overly-dissimilar groups. But life is full of judgment calls, no? Havoc ___ 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]
quote who=Havoc Pennington On Wed, 2006-02-08 at 21:54 +0100, Jon K Hellan wrote: However, if we decide to target a niche audience, on a niche operating system, that's niche squared. I doubt if that's sustainable. Didn't say niche, I said specific. The group can still be large. There are many, many well-defined subsets of the world's billions of people that still contain a hell of a lot of people. Apple have done this very cleverly over the past few years with OS X. They concentrated on their core market, really worked hard to nail it, and have been scaling out to other markets as the opportunity has come up and their ability to focus on the broadening market needs balloons. - Jeff -- FISL 7.0: Porto Alegre, Brazilhttp://fisl.softwarelivre.org/7.0/www/ Basically my philosophy on release management is that it should be like police brutality. - Maciej Stachowiak ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: CVS branches
On Wed, 8 Feb 2006, Gustavo J. A. M. Carneiro wrote: And I have a case when I forgot to add a regular tag at the start of a branch. So now I'm finding it very hard to obtain a diff of all changes since I started the branch. I'll have to do it manually, file by file, looking at revision numbers :-/ You can still add such a tag. Just figure out the date you made the branch (that you can do I suppose, there's no reason you cannot), do cvs co -D the-date, and cvs tag. CVS branches are hard, you have to admit it ;-) Right. And Carl Worth wrote to tell us how easy it is in git: http://lists.freedesktop.org/archives/cairo/2006-February/006255.html --behdad http://behdad.org/ Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill -- Dan Bern, New American Language ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
Kalle Vahlman wrote: I mean, I'm making a theme engine (for Maemo) but haven't released anything yet. Will you behead me for being secretive when I do or just let it slide because I'm tweeny-tiny myself and not a big company? I only take exception when a large company (especially one that makes a lot of money from OSS) deliberately delays disclosure of source purely for financial reasons (IE in order to keep ahead of their competitors). Whilst any company that does that is not screwing the community (provided they eventually release the source) they are however treating the community in a negative fashion. Hopefully, Novell will release the source soonish and put this issue to rest. -- 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
Re: Gnome-utils branched to gnome-2-14
On Wed, 2006-02-08 at 17:06 +, Alan Horkan wrote: I remain baffled how the file chooser button was designed. Everywhere we have text entries followed by a Browse button but the File Chooser button looks nothing like this. Instead of a widget to encapsulate this established idea there is a button which looks confusingly like a drop down menu. Your task is to design a better one, while keeping the API. The usage case for GtkFileChooserButton is rather vague, but it can be summarized as the widget you would use in a configuration dialog to pick a file or directory that the program will use continually [1]. The screenshot applet should definitely not use a file chooser button because it is going to use the file you picked immediately, and only once. It should take a GtkFileChooserWidget in SAVE mode, and embed it in a dialog with a scaled-down version of the screenshot. See eggiconchooser to see how a GtkFileChooserWidget can be embedded nicely in another dialog. +--+ Name: [screenshot.png_] | | | screenshot | Save in folder: [ @ Documents \/] | here | | | +--+ [ Cancel ] [ Save ] [1] Yes, this description should go in the documentation: http://developer.gnome.org/doc/API/2.0/gtk/GtkFileChooserButton.html Care to polish it up a bit and submit a patch? Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Less antiquated format for animations
So, to give some positive input to this discussion, if gif, ani (or more esoteric formats like mng or apng) are not acceptable because they are not already supported by gnome and kde, how about making use of a mechanism already present in the icon theme spec, and define a set of extra keys for .icon files to indicate that a set of icons is meant to be used as an animation. The frames of the animation can then be stored as individual icons (and you don't have to explain why you put a 240x240 image in the 24x24 directory...). Going this route also allows to specify some extra parameters to ensure that you at least have the same feature set that gif animations had a long time ago, like per-frame durations, and maybe disposal modes. In practise it could look like this: 24x24/animations contains gnome-spinner.icon gnome-spinner.png gnome-spinner1.png gnome-spinner2.png ... All frames are available as regular icons, the first frame under the same name as the animation. gnome-spinner.icon has entries like X-animation-sequence = gnome-spinner.png,gnome-spinner1.png,gnome-spinner2.png,... X-animation-delay = 100,100,100,200,... X-animation-loop = 5 I think a setup like this would do much less violence to the icon theme specification while maintaining the essential benefits of the all-frames-in-a-png hack: graceful degradation for animation-less environments, no new image formats required. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
It's not about Novell (was Re: NLD10 and GNOME)
Le mercredi 08 février 2006 à 23:17 +, Jamie McCracken a écrit : Hopefully, Novell will release the source soonish and put this issue to rest. Please, we're mainly talking about a problem that is not about Novell. We should let Novell people know that we love them, as much as we love the Red Hat guys and all the people working on GNOME. The main problem I see is that the GNOME community could be a central point, but is not. It's caused by many lacks. But *we* can change this. If we stop blaming people for bad reasons. Thanks, 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: requesting official list of modules and versions for GNOME 2.14
Hi Davyd, Le mardi 07 février 2006 à 12:06 +0800, Davyd Madeley a écrit : Has the official list of what's in and what's out been given for GNOME 2.14 yet? Several contentious modules have been proposed for inclusion and several version holds have also been requested by people. The release notes (and assumedly vendors) are blocking on this information. So, we (the release team) seriously sucked on this. We're having a meeting on Friday to take some decisions. Here's the new modules that are in: + pyorbit + deskbar-applet + fast-user-switch-applet + gnome-python-desktop + gnome-screensaver (if it does not depend on gnome-power-manager) + pessulus (admin suite) + sabayon (admin suite) Here's the list of modules that are waiting for a decision: + libnotify notification-daemon = depends on libsexy. What should we do about it? Add it to the desktop set? Say it's a blessed dependency? Don't accept it? + gnome-power-manager = there was some opposition, and there's also some duplicate functionality (eg, the battery icon in the notification area vs the battery applet). We can accept it now, or say it's better to wait 2.16, eg. 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: requesting official list of modules and versions for GNOME 2.14
Here's my personal opinion. Le jeudi 09 février 2006 à 08:27 +0100, Vincent Untz a écrit : Here's the list of modules that are waiting for a decision: + libnotify notification-daemon = depends on libsexy. What should we do about it? Add it to the desktop set? Say it's a blessed dependency? Don't accept it? I'm opposed to have another library for general widgets in GNOME. This should go in GTK+ or we shouldn't use them. This just like saying we'll put some more widgets in libgnomeui while some people are trying to kill libgnomeui... I might be alone in thinking this, though ;-) + gnome-power-manager = there was some opposition, and there's also some duplicate functionality (eg, the battery icon in the notification area vs the battery applet). We can accept it now, or say it's better to wait 2.16, eg. I'd like to wait for 2.16 for gnome-power-manager. It looks great, but it doesn't look integrated enough to me, yet. Do we need to rush to accept a module in the desktop set? I don't think so. Many distributions will use it anyway. We should only accept it when we think it's ready for GNOME. (Note that it happened for quite a few modules in the past to have to wait a few release cycles before being integrated) 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: requesting official list of modules and versions for GNOME 2.14
On Thu, Feb 09, 2006 at 08:27:43AM +0100, Vincent Untz wrote: So, we (the release team) seriously sucked on this. We're having a meeting on Friday to take some decisions. Here's the new modules that are in: + pyorbit + deskbar-applet + fast-user-switch-applet + gnome-python-desktop + gnome-screensaver (if it does not depend on gnome-power-manager) + pessulus (admin suite) + sabayon (admin suite) Thanks, Vincent. Can we also get a list of versions the release-team intends to choose for gtk-engines, gnome-icon-theme, GLib and Pango? The issues of theming and any revertions need to be covered before we can proceed with screenshooting. Sorry to keep pushing the issue, but I want to get a start on this, before I find I've run out of time. --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: requesting official list of modules and versions for GNOME 2.14
On Thu, Feb 09, 2006 at 08:33:39AM +0100, Vincent Untz wrote: + libnotify notification-daemon = depends on libsexy. What should we do about it? Add it to the desktop set? Say it's a blessed dependency? Don't accept it? I'm opposed to have another library for general widgets in GNOME. This should go in GTK+ or we shouldn't use them. This just like saying we'll put some more widgets in libgnomeui while some people are trying to kill libgnomeui... This is an excellent point. I would really like to see libnotify available in the desktop, but here are some points I have thought of: - people don't like the Windows bubble-spam effect, we need some style guidelines in the HIG - perhaps at least libnotify belongs inside GTK+, since the API seems to now have a concept of GtkWidgets and such, it really belongs in GTK+ That said, notification-daemon should remain separate and pluggable (for example, I spoke to someone recently who hates the bubbles, but would like an applet that logs notifications on his panel; which I think would be doable in the current architecture). I think there are lots of things we haven't yet explored with this type of functionality. Sure, libnotify is really great for popups on the panel, but we should be able to attach it to any widget. Think about hints in Ailseriot: at the moment they appear as a popup box, how about instead attaching them to appropriate cards. Move the red 7 onto the black 8 would be a notification bubble attached to the red seven. + gnome-power-manager = there was some opposition, and there's also some duplicate functionality (eg, the battery icon in the notification area vs the battery applet). We can accept it now, or say it's better to wait 2.16, eg. I'd like to wait for 2.16 for gnome-power-manager. It looks great, but it doesn't look integrated enough to me, yet. Do we need to rush to accept a module in the desktop set? I don't think so. Many distributions will use it anyway. We should only accept it when we think it's ready for GNOME. (Note that it happened for quite a few modules in the past to have to wait a few release cycles before being integrated) Let's let vendors decide. This module could do with both UI and technical review. The persistant use of the notification area, the number of popup bubbles (see above comments on popup spam) and several other issues I noted, but have now forgotten are all worth considering before we bless this module. 100% agree with Vincent on this module. --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
