The GNOME Community Roadmap is a big-picture view of functionality we expect GNOME to include in short-term and long-term future. The roadmap is based on feedback from current GNOME developers and other community members. This roadmap shows the ideas and hopes of GNOME contributors for the near future.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-06-29
When people want it in GNOME they use libegg.
Member since:2005-07-06
When people want it in GNOME they use libegg.
As I understand it, libegg isn't a stable library, so if anyone wants to implement anything in it they either ship libegg themselves, copy the code into their own applications or wait some time never for it to go into GTK. The problem is, applications will simply use what they need within libegg, or themselves, and ship as part of Gnome. This completely negates any advantage of keeping things out of GTK until it has stabilised, because applications have started using something that GTK considers to be too unstable anyway. There is quite a lot of libegg proliferation.
The point was that this kind of functionality should be in a solid underlying layer within the system that will be consistent from a programming point of view for application developers. The way to do this would be to get the new functionality into an unstable version of GTK so that application developers could try it out for the next version of Gnome and get it stabilised. If it isn't in GTK, no one uses it. Another option is to build a Gnome layer on top of GTK for Gnome specific extensions, as kdelibs builds on top of Qt, in a consistent manner.
A toolkit is there to service the needs and requirements of applications, not the other way around.
Member since:
2005-07-06
Total Bullocks!
I gave you the benefit of the doubt. But now you are just flat out trolling. GNOME is not years behind KDE in infrastructure.
Sorry, but the evidence is totally to the contrary and it simply isn't trolling. I know some people don't like it, but to move forwards it has to be admitted.
People are actually admitting here that to implement editable toolbars people are copying and pasting common code into their applications for a widget that is completely common on every other desktop environment.
That kind of thing is about fifteen years behind Windows and the Mac, never mind behind what KDE has. If you tell that to a Windows or Mac developer who hasn't been exposed to Linux desktops then they simply won't believe you.
And last I checked KDE4 is not even living up to its __unwarranted hype__.
Again, KDE's hype is based on having a solid infrastructure to do all the cool stuff people want. That's hard work, but it pays off.
Don't tell us it is behind KDE. Behind KDE in what?
When developers want editable toolbars in KDE it is implemented in kdelibs by all interested parties, and applications that want to implement them then inherit it from kdelibs. Other applications can then simply use it for free in the future with no trouble whatsoever. Any problems are immediately noticed, talked about by all the application developers and are fixed in one place, reducing bugs and more than increasing consistency.
It's a tad astonishing that has to be explained in this day and age.