Submitted by 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.
Huh, this is a very long list. Often people say, that GNOME does not improve within the 6 month. But this list looks very promising. I can’t await to see the Improved e-mail notification in Evolution
I am still missing a nice tray icon so that I can hide the main window and still get notified about new mails.
Good work GNOMEies
Greetings
Mike
mail-notification works really well for me, sitting in the notification area and popping up every time something lands in one of my mail boxes. it can even check servers, even though I do not use it like that;.
There’s always alltray. http://gnomefiles.org/app.php/alltray
This is interesting as well, the raw datas gathered from maintainers: http://live.gnome.org/RoadMap/Modules
Finally.
Thank you GNOME team.
Interesting roadmap. A few big things, many small, and some that made me wonder ‘why does that even have to be written?’… Why does evince need ‘editable toolbar’, wouldn’t that come as default in each app? and several apps seem to need to implement printing multiple pages – does each gnome dev need to waste his time on such basic infrastructure stuff? That won’t lead to consistency, I guess.
Anyway, let’s hope they can finish all this stuff and catch up with the competition. Would bring the linux desktop forward, and that’s always good.
‘why does that even have to be written?’.
That’s how software works.
Why does evince need ‘editable toolbar’, wouldn’t that come as default in each app?
I also wonder why it needs editable toolbars, since the default is so nicely designed. But anyway, Gtk+ doesn’t support editable toolbars yet; the code exists in libegg, and developers can simply copy and paste it to their application. This isn’t exactly nice, but it’s a good way to have the code mature until it’s ready to be part of a stable library like GTK+.
Speaking of evince, it’s nice to know KDE 4 will have a similar application. Hopefully it will share resources with evince by using libpoppler, which AFAIK KDE doesn’t do yet.
and several apps seem to need to implement printing multiple pages – does each gnome dev need to waste his time on such basic infrastructure stuff?
Not really. You see, GTK+ has a new printing API (which, by the way, was developed without GNOME having to launch a new major version) and it works great, but not all features are implemented yet. The “several apps” you mentioned are actually two – Evince and Eog – and they’re waiting on proper GTK+ support to land that feature.
That won’t lead to consistency, I guess.
Consistency is one of GNOME’s strongest features.
Anyway, let’s hope they can finish all this stuff and catch up with the competition.
It’s already superior to Vista’s interface in my opinion, and it even beats Mac OS X in several points.
Edited 2007-05-26 23:11
http://webcvs.freedesktop.org/poppler/poppler/ChangeLog?revision=1….
I can see some @kde.org addresses there
of course, Okular dev’s are working on poppler. They have since the beginning (not sure, they might even have initiated it)
TSDgeos knows this, he is one of them.
He just posted the link to the commit log so that anyone could check it for themselves if they had doubt
I DID recognize his name, but just wasn’t sure 😉
shouldn’t such stuff have been in the libs 5 years ago, like in KDE?
Albert Astals Cid is one of the main developers on both Poppler and KPDF (which will be Okular in KDE 4).
OK, so only KDE to catch up on. All things you just explained have been working in KDE for 5 years or more, so it’s well time to finally get these things in GTK/Gnome apps. I wonder how much time it did const to have to check and change each application to abide with the Gnome HIG while KDE just wrote some libraries which lead to the same consistency (at least in the area’s covered by those libs, like men & toolbars, network transparancy, shortcut handling, printing etc).
Anyway, as I said, it’s a nice roadmap, some might say ‘too little too late’ but time will tell. I DO wonder what their answer to KDE 4 will be, of course, but it would actually be a good thing for ‘the linux desktop’ if it would be a good answer, so let’s hope for that. All happy (well, as long as they’re working on free software, as they should
).
That’s how software works.
Software works on layers, and you implement what is common in the layers below for the layers above to inherit.
I also wonder why it needs editable toolbars, since the default is so nicely designed. But anyway, Gtk+ doesn’t support editable toolbars yet;
Editable toolbars has been on the drawing board in GTK+ for years. It’s by no means new (2003):
http://www.osnews.com/story.php/5453/Interview-Red-Hats-Owen-Taylor…
“…the support for editable toolbars is there, and the GTK+-2.4 version Epiphany has editable toolbars, but GTK+-2.4 itself won’t contain the user interface for editing toolbars or the support for saving the results of editing.”
It doesn’t paint a particularly great picture of GTK as a library, or programming in Gnome. User interface stuff like this positively and simply has to be in a universal common, well structured library in a modern desktop environment. Any third-party developer is going to be mighty confused by this, and it isn’t great from a bugs point of view either. Where on Earth is the bug?
Consistency is also a major factor here from a user and usability, as well as a consistent HIG and look-and-feel, point of view. Some applications have it, some don’t and it’s sometimes different between applications? What’s going on?
…the code exists in libegg, and developers can simply copy and paste it to their application.
I am positively and physically cringing as I read that.
…but it’s a good way to have the code mature until it’s ready to be part of a stable library like GTK+.
To be honest, I think that opens a can of worms. Once you copy and paste code it’s out of control. The priority should be to get such functionality into a common library and inherit, or not at all. This is a modern desktop that uses a common toolkit with APIs that actually binds applications together into a desktop? I have that right, don’t I?
Speaking of evince, it’s nice to know KDE 4 will have a similar application.
It has for some time, in various forms.
Hopefully it will share resources with evince by using libpoppler, which AFAIK KDE doesn’t do yet.
From what I’ve heard, Okular will use Poppler.
You see, GTK+ has a new printing API (which, by the way, was developed without GNOME having to launch a new major version)
Welcome to 1995. I’m not sure why having that put in without launching a major new version should be particularly impressive. Sounds like it should be.
Consistency is one of GNOME’s strongest features.
Taking into account the above evidence, and the way things are being done, that doesn’t look very true. Consistency implies commonality between applications and the desktop, and if they’re not all singing from the same hymn sheet than there isn’t much consistency. Telling developers to individually follow a set of guidelines doesn’t really count.
It’s already superior to Vista’s interface in my opinion, and it even beats Mac OS X in several points.
If you have application developers, and third-party developers, having to create their own independent GUI widgets, and widgets other desktops have had for years at that, then you’ve got a dog’s breakfast interface-wise. Vista and Mac OS X have inheritable APIs and components for doing all this since…forever.
Editable toolbar is in a library called libegg. Most developers do not need editable toolbars. And those who do can use libegg.
Untested and unpopular APIs should never be placed in a toolkit. APIs should added based popular request and need. And of course, after lots of testing.
Consistency is overrated. I don’t see how the absence of editable toolbars make applications “hymn” out of sync. Have you used Windows? Do all Windows application share the same editable toolbars or even have one?
Nonsense, nobody is creating independent GUIs. We only see that on Windows and OS X. People who need editable toolbars create on based on the API in libegg. When there’s enough demand for editable toolbars, it’ll find its way into GTK or GNOME. You are making a mountain out of an ant hill.
Edited 2007-05-27 03:23
Editable toolbar is in a library called libegg. Most developers do not need editable toolbars. And those who do can use libegg.
Except (and correct me if I’m wrong here) libegg doesn’t seem to be a separate library at all. People just include the code from it into their projects instead of it being installed separately as a dependency like any other library. So in effect you have everyone copying and pasting the code instead of sharing it. That’s a terrible idea for many reasons, which would be clear to you if you write software.
Untested and unpopular APIs should never be placed in a toolkit. APIs should added based popular request and need. And of course, after lots of testing.
Editable toolbars are untested? After 3 years?
Really it’s not like it’s a cutting edge feature that may introduce bugs. And obviously it is wanted, as shown by the apps in the roadmap intending to add support for it.
Consistency is overrated. I don’t see how the absence of editable toolbars make applications “hymn” out of sync.
It’s not the most important feature, but it is very nice when all apps on the system have similar interaction methods.
Have you used Windows? Do all Windows application share the same editable toolbars or even have one?
And Windows is the pinnacle of UI design? Windows is probably the last thing we want to look to for how to design GUIs. The Windows GUI toolkit is so poor that every second application feels the need to have their own custom widgets or widget toolkit.
You are making a mountain out of an ant hill.
That’s true. Editable toolbars are not overly important, but there are other examples of features that really should be put into the libs, and not reimplemented in each app. From the roadmap:
Evince – Thumbnails in file chooser
File Roller – Load and save remote archives
– Extract archive to a remote locations
Other release notes I’ve seen for Gnome show similar examples.
Really? I wonder why it’s called libegg.
Perhaps because these developers don’t want to require another dependency for their applications. Perhaps because it may be a lot easier to copy one or two header files or source code into a directory than require users to download a library that has several testing API and functions that’s not needed. I’m just guessing.
I only know of two applications that support editable toolbars, Epiphany and Evince. If you point me to five more. Then I’ll accept the API is indeed widely tested and there’s demand for it.
I saw __one__ app that plans to use editable toolbars in the roadmap. EOG.
Are you saying current GTK+/GNOME apps don’t?
No, but apparently someone was __comparing__ GNOME to __other__ platforms.
So we agree. But OS X is no better. I use several applications on OS X that don’t have editable toolbars and hell isn’t freezing over. Besides, who edits toolbars but geeks and power users.
So the Evince developers have finally convinced themselves to use a feature that has been in GTK+ for over 3 years. How’s that GTK+/GNOME’s fault.
So the File Roller developers finally convinced themselves to use GNOME-VFS.
Apologies, I don’t see your point.
Edited 2007-05-27 05:09
So the File Roller developers finally convinced themselves to use GNOME-VFS.
I think the point was that GNOME-VFS should be used in all Gnome applications. Otherwise GNOME-VFS seems a bit pointless.
What if an application doesn’t need it? Besides, you can’t force developers to use libraries.
So you are arguing for a _inconsistent_ platform? So you can use Gnome-Vfs in one app but not in another?
How does that even make sense?
Also, if the application is included in the desktop, it should behave as all the other apps do.
exactly, that’s my opinion. That’s why it might not be smart to have functionality in all these seperate libs, where app dev’s choose & pick at random. It leads to inconsistency. I once tried to change Gedit’s toolbars – no go. Now that’s fixed, but the fact they had to spend time on that AT ALL imho sucks. KDE DOES do better (much better) in this area, it acutally is it’s main strenght.
Not sharing code, but copy-pasting it (*to prevent another dependency*) is really bad. You increase memory usage, increase the likelyhood of bugs, you don’t share the bugfixing- and improvement work, etcetera. It’s bad, no-no, stupid… And you really shouldn’t defend it as a sane policy. Don’t learn the children bad habits!!!
If I compare this to the whole flamewars going on on the KDE-devel mailinglist about what/how/where to add certain even small library functions – that’s perfectionism, maybe too much, but at least THEY get it.
It’s a smart move. It’s called modularity. And it’s the pinnacle of good software engineering. It makes libraries easier to test, maintain, package and document. It make developers choose what libraries they need and avoid the ones they don’t.
Last I checked Gedit doesn’t have a toolbar editor.
No, it’s not. It’s not a black and white issue. There are times when you are better copying header files and source instead of bundling libraries that are several megabytes large with your source code, or requiring users to install them.
Quite the contrary. The more libraries an app uses the more memory it consumes. Are you a developer?
It’s a practical policy as opposed to the fantasy theories your textbooks have exposed you to.
KDE is far from perfect. But I don’t feel like ranting about it. It’ll do no good other than emotionally cripple KDE zealots.
Thanx. It seems a matter of opinion, then, as most developers considder sharing code a good thing… But ok, you’re entitled to your opinion, of course.
If an application does not need GNOME-VFS it shouldn’t use it. I don’t see what’s senseless about that. Do you regularly acquire things you don’t need?
No, it shouldn’t. Unless all applications perform the same functions. A web browser should not behave like a music player. An IRC client should not behave like an Image editor. A shell terminal should not behave like a UML program.
If an application does not need GNOME-VFS it shouldn’t use it.
And how should the application be able to decide what it need or not? It’s not something the developer can decide, since it completely up to the user how he/she wants to work and access his/her files.
Also, if the application is included in the desktop, it should behave as all the other apps do.
No, it shouldn’t. Unless all applications perform the same functions.
Well, I’d say that file open/save is the same function, regardless of the applications. And the dialog look(more or less) identical across the applications, it’s rather inconsistent that it behaves differently.
Developers decide what libraries their software use not users. If an application has no need for a library it should not link to it. Unless you want to bloat your app for no reason and torture your users needlessly.
If apps use the same toolkit, they’ll automatically have access to the same widget set. That, however, does not mean all GNOME applications should behave the same. Applications have to behave differently depending on their function and the task they accomplish. An email client should not behave like a clock applet even if they use the same toolkit.
Applications have to behave differently depending on their function and the task they accomplish
You keep bringing up that red herring, nobody is saying anything different. So I don’t see why you keep bringing it up.
But we say opening and saving a file is the same function, regardless of the applications function and task. The task of selecting a file for the application, should behave the same for all applications. You use the same toolkit for it to look the same, and it stands to reason the toolkit should also make it behave the same.
So what’s your point? The open dialog behaves the same in all apps that use GTK+.
So what’s your point? The open dialog behaves the same in all apps that use GTK+.
I guess you are playing at being dense today.
In Gnome the open (and save dialogs) do not behave the same, which has been the pointed out from the beginning of this tread. Some places you can read and write remote files, some places not. This should be the same for all applications handled by the libraries in a consistent manner. Rather than by the whim of the developer, torturing your users needlessly by this inconsistent behavior.
They do.
GTK+ is not responsible for reading and writing to remote locations. GNOME-VFS is. Which has been pointed out several times already in this thread if you’ve been following.
Edited 2007-05-27 12:18
In Gnome the open (and save dialogs) do not behave the same, which has been the pointed out from the beginning of this tread.
They do.
No they don’t. If I, using the same function, can access files from a location with one application, but not the other they behave differently.
GTK+ is not responsible for reading and writing to remote locations. GNOME-VFS is.
More red herring. For the user the operation of opening a file is done in the filedialog. That some filedialogs use GNOME-VFS while others don’t, still makes the operation of selecting files behave inconsistent.
It’s becoming evident that I’m arguing with people who pleasure themselves in talking about toolkits, “infrastructures” and libraries they have never used or have no knowledge of. They also feel the need to school us on “proper” software engineering, architecture and library usage. Eagerly advocating techniques that are extolled in text books and fantasy theories, but hardly work in practice and real world projects.
The GTK+ open dialog is not used to read and write files. No it isn’t. You use the OS system libraries or an I/O library like GNOME-VFS to read/write files. But you knew that right.
The open dialog is a dumb widget that just displays files. The files it displayes is determined by developers. I’m sure you knew that too.
If I was designing a UML editor, I would code the open dialog to display only files the editor can open. Such that the dialog won’t show music, movie or image files. Yes, it’s the developers that do all that, not the open dialog.
If I needed to import an image into the editor, the open dialog is the same widget I’ll use. But this time, I’ll code the dialog in such a way that it can only open image files. Are you shocked?
I used the same dialog for different functions. To you that’s an abomination, because in your fantasy world, the open dialog should function the same way. But in the real world, that’s correct usage. Don’t weep.
The same logic applies to displaying remote files. If an app has no need to display remote files, why the heck should the dialog be configured to do so? Oh, I forgot “consistency”. May I remind you:
“A foolish consistency is the hobgoblin of little minds” – Ralph Waldo Emerson
An image editor should not open text files, thus it’s dialog should be configured in a manner that prevents loading of text files. The opposite is true of a text editor, which should not open sockets. Heck, within the same application, developer often use the open dialog differently for different tasks. So all these apps should behave consistently nonsense, is just that nonsense.
This is not a red herring, this is reality backed up with experience of actually using these toolkits and writing apps with them. But if you insist on regurgitating half-truths, spewing baseless myths and misinforming yourselves, to feel better about KDE, then be my guest.
The GTK+ open dialog is not used to read and write files.
Exactly, but it’s used to select the files you want to open. Unfortunately it uses different methods of doing this witch makes it behave in a non unified way.
The files it displayes is determined by developers.
Nobody has said anything else. It’s not about what the application does, but how they implement the same functionality.
If I was designing a UML editor, I would code the open dialog to display only files the editor can open. Such that the dialog won’t show music, movie or image files
You does not seem to get it, it’s not about filetype or the applications function. Selecting a file to open is the same, if the file is a UML diagram, music file or image do not change that.
I used the same dialog for different functions.
No you don’t, you use it to tell the application witch file to open. That’s exactly the same function.
If an app has no need to display remote files, why the heck should the dialog be configured to do so
There is no way for the for the developer to know that, since he has no way to know where the user stores his files.
[i]This is not a red herring, this is reality backed up with experience of actually using these toolkits and writing apps with them.So all these apps should behave consistently nonsense, is just that nonsense.[i]
The nonsens is what you spewing, you are deliberate mixing usage patterns with functionality in a way to hide some rather apparent flaws that does not fit into your world view. I find it hard to belive you are that stupid, to not see the difference. So I assume you keep bringing in the red herring. Othervise it’ seems like you are lacking experience in actually using applications.
It’s rater easy to give a real world example of it too. If you work with two related files, one image and one UML diagram, located next to each other. It’s logical to presume you should be able to open both files, in their respective applications mind, when they are using the “same” dialog. When you can’t it’s clearly not only inconsistent, but it also shows a lacing infrastructure.
*sighs* You keep exposing your ignorance. But I can’t help you. Write an app, and you’ll figure things out yourself.
Yeah, because developers are dumb, and don’t know their use cases.
Unfortunately it uses different methods of doing this witch makes it behave in a non unified way.
*sighs* You keep exposing your ignorance. But I can’t help you. Write an app, and you’ll figure things out yourself.
You are sure it’s not your lack of basic understanding thats exposed here? Or are you merely trolling?
As you said, you use the OS system libraries or an I/O library like GNOME-VFS to read/write files.. That both sounds like, and if I code it, looks like different methods(or you can call it different libraries if it makes you feel superior). And I hope you are not so stupid to say that one don’t need one of those to populate the filechooser in the first place. So in the end we still have seemingly identical widgets doing the same job, but working differently.
[p]And I hope you are not so stupid to say that one don’t need one of those to populate the filechooser in the first place.[/p]
No, one does not need any of those to populate the filechooser! I guess I’m stupid. And you are the one who is more knowledgeable and experienced. The filechooser populates itself just fine. But you’d know that if you actually used these APIs, as opposed to fronting and pretending like you know what the hell you are talking about. You are a perfect example of an idiot spreading misinformation about GNOME’s infrastructure without any knowledge whatsoever of them. Congratulations for exposing your troll status.
Let me ring it in your ears, one more time, maybe it’ll sink this time around. You CANNOT access remote files via the filechooser. You NEED GNOME-VFS to mount the remote locations onto your system. Only then will the remote location show up in the filechooser, and only if developers configure the file chooser to do that.
But I bet ya you still don’t get it. You are gonna continue trolling about inconsistency, about library design and about how KDE a millinia ahead of GNOME, among other rehashed garbage. After all, YOU KNOW what you are talking about.
[p]So in the end we still have seemingly identical widgets doing the same job, but working differently.[/p]
Yeah, your conclusion is well reasoned. What a joke.
No, one does not need any of those to populate the filechooser! I…. The filechooser populates itself just fine.
So instad of using the OS system libraries or an I/O library like GNOME-VFS to get the it’s content, the filechooser duplicates the functionality needed to access the media and getting the content. That totally makes sense, but since I’m a idiot troll bent on spreading missinformation I couldn’t have known that.
You CANNOT access remote files via the filechooser. You NEED GNOME-VFS to mount the remote locations onto your system. Only then will the remote location show up in the filechooser
But you just said the filechooser does it just fine by itself, so why do it suddenly need Gnome-vfs again now. Congrats for exposing your inability to spot inconsistency, even in your own writing.
The filechooser does not duplicate functionality. Displaying files in a view has nothing to do with reading or writing files.
Because GNOME-VFS is used to mount the remote system. The filechooser simply display the files.
Let me get this. You don’t know the function of the filechooser in GNOME or how it works. You don’t know how it interacts with GNOME-VFS. You don’t know the point of GNOME-VFS or how it works, but somehow you feel the need to speak with authority on GNOME’s infrastructure?
Bah, Mystilleef, stop defending your position.
All open/save dialogs in Gnome should support Gnome-Vfs. No exceptions allowed.
But they do!
The open dialog supports GNOME-VFS if it is installed on the system and if developers set the flag to use it.
Stop defending your ignorance.
If an application does not need GNOME-VFS it shouldn’t use it. I don’t see what’s senseless about that. Do you regularly acquire things you don’t need?
That’s debatable. If an application somehow handles files then it should be aware of virtual filesystems and it is very hard to point to an application that doesn’t these days. Heck, even an IRC client needs to be aware of it if you take DCC file transfers into account!
From your examples, the only one that probably does not need to be aware at all of a virtual filesystem layer would be a terminal emulator.
It is embarrassing that GNOME still does not integrate GNOME-VFS properly after all these years… It is about time!
Really? I wonder why it’s called libegg.
Well, do you see it on your system? It doesn’t exist in the Debian repositories at any rate, and they contain almost every Linux app/library out there.
Perhaps because these developers don’t want to require another dependency for their applications.
That’s a poor excuse. If this was integrated into GTK properly, it wouldn’t be an extra dependency.
Perhaps because it may be a lot easier to copy one or two header files or source code into a directory than require users to download a library that has several testing API and functions that’s not needed.
Easier in the short term yes. I’ve been tempted to do this as well, but it leads to an unmaintainable hell of an application eventually. Instead of delegating responsibility of core functions to separate libraries that can be updated for security and correctness fixes, you now have a snapshot of someone else’s code, and need to keep up with developments on that code forever (or risk having vulnerabilities in your app that have been fixed already). The developer of libsexy makes this argument here:
http://www.chipx86.com/blog/?p=205
As for the user, modern package managers make dependencies a non-issue for the user.
Are you saying current GTK+/GNOME apps don’t?
Well obviously they don’t on the subject of editable toolbars. That’s the whole point.
I only know of two applications that support editable toolbars, Epiphany and Evince. If you point me to five more. Then I’ll accept the API is indeed widely tested and there’s demand for it.
I’m not familiar with the Gnome apps, so I can’t name any more from there, but every app on KDE, every app based on the Mozilla platform, most high quality apps on Windows. Obviously the feature is wanted by (a subset) of users. Whether the libegg API is stable I have no idea, but really there is no excuse for it not to be.
Besides, who edits toolbars but geeks and power users.
I agree that most people that want to edit toolbars are what you describe as geeks, but if that’s your user base, then you should cater to them. In open source, geeks are the most important users, because they are the most likely to contribute back to the project at some point. While it is certainly beneficial to have the uninterested masses use OSS as well, they are very unlikely to actually contribute anything to improve the applications.
So the Evince developers have finally convinced themselves to use a feature that has been in GTK+ for over 3 years. How’s that GTK+/GNOME’s fault.
So the File Roller developers finally convinced themselves to use GNOME-VFS.
It is merely an indicator. If these features are in GTK and/or Gnome already, then why aren’t people using them from the start? Of course this is merely speculation on my part, but I would guess that something about the GTK file selector and GnomeVFS was so hard to use or poorly done that developers didn’t want to use it. Why else would someone have to be convinced to use a feature which on the surface should do nothing but help them? I guess that the feature was incomplete and they had to create their own instead.
Untested APIs is not put in GTK+.
What? An editable toolbar is a one time implementation. You don’t need to go around fixing other people code or bugs, just yours.
I disagree. The toolbar editor should provided on per application basis and only when needed. The editable toolbar is not an important feature. Most users don’t edit toolbars, period.
That’s a silly conclusion. Nobody implemented their implementation of GTK+ or GNOME-VFS. Developers only used libraries when they have a need for it. Some developer are gnomephobic and won’t use GNOME libraries for political reasons. Developers and developers alone determine what libraries to use and when to use them. Period. All these baseless speculation and pandering is tiring.
Most developers do not need editable toolbars. And those who do can use libegg.
That’s not the point, and you miss it entirely. Developers need a nailed down underlying toolkit and library to enable them to do this when they need to and concentrate on creating applications, rather than rolling their own and mucking about with a moving target. Copying and pasting common code after the event only decreases consistency and increases bugs.
Untested and unpopular APIs should never be placed in a toolkit.
It’s untested, after four years? And calling it unpopular is simply a bit rich considering that all other modern desktops have such widgets.
The reason why it’s still untested and unimplemented after four years is because Gnome just has this rear end backwards. New APIs and widgets should be placed first and foremost where they logically should go – in the underlying toolkit. This ensures that all applications can give useful and meaningful feedback on the new API from the moment it is added to the toolkit, and no nasty surprises occur later on. You stabilise it as part of the toolkit with applications then implementing it, and this pays off handsomely over time. If this can’t be done there’s something wrong.
If Gnome and GTK cannot understand this then it’s highly doubtful whether any developers out there in ISVs used to other desktop environments will ever trust it.
Consistency is overrated.
Right……..
I don’t see how the absence of editable toolbars make applications “hymn” out of sync.
Again, you miss the point. This is just one example of the way that Gnome and GTK work on a pretty wide scale. If they’re all copying and pasting code for their own implementations then they’re just not consistent.
Have you used Windows? Do all Windows application share the same editable toolbars or even have one?
You miss the point. The ones that do, use either those built into Windows, or some of the additional Microsoft Office components. No one is copying and pasting common code into their applications, and more importantly, the desktop doesn’t compel them to do it for what should be a totally standard feature.
Nonsense, nobody is creating independent GUIs.
Copying and pasting common code into each and every application is creating their own independent GUIs. It’s pretty unacceptable in a modern desktop environment.
We only see that on Windows and OS X.
I’m afraid you don’t understand component based programming and inheritance.
When there’s enough demand for editable toolbars, it’ll find its way into GTK or GNOME.
Again, that’s the argument used, but editable toolbars have been in the pipeline for four years, each and every other modern desktop environment has them and any developer will expect any kind of modern GUI toolkit to have them.
You are making a mountain out of an ant hill.
I’m afraid I’m not. Any desktop environment that compels a developer wanting to implement a new feature, or one that’s been in every other desktop environment for years, to copy and paste code into their application shows that there is something very wrong somewhere.
So what’s wrong with using the toolbar editor in libegg?
It’s unpopular in about every desktop I’ve used.
Uhm no, you have it backwards. You don’t dump unstable APIs in stable toolkit.
That’s why about every commercial ISV for Linux default to GNOME.
That’s blatantly false. Every app on windows does it’s own thing.
Don’t be silly, GNOME is not a bunch of copy and pasted code.
I take it you participated in GNOME development where all the code is copied and pasted. Or are you just making this up?
That’s funny.
If developers need them, they’d be pointed to libegg. Sheesh. And no, not every developer needs them. I know I don’t.
What GNOME app have you developed that demanded copy and pasting?
I admire your tenacity, but replying to segedunum is pointless; he’s a well known anti-gnome zealot who’s been trolling OSNews for the past few years. Many of his posts spread FUD, and negative energy about GNOME, Mono, Ximian, and Novell.
Just look at his stats: ~2000 posts here — almost three posts per day, every day, for two years! Add to that another ~400 posts at dot.kde.org. Perhaps surprisingly, about 100 of those posts deal with GNOME (on a KDE forum).
There’s really no point in replying to him; he’ll just drag you down to his level, and beat you with experience. Instead, just mod him down as off-topic.
“””
There’s really no point in replying to him; he’ll just drag you down to his level, and beat you with experience. Instead, just mod him down as off-topic.
“””
Seconded.
As an administrator, rather than hobbyist, I have chosen Gnome for my users. The Gnome devs’ attention to the UI, and the philosophy of 6 month releases and “more than just lip service” respect paid to continuity are huge assets from where I stand.
As far as features and progress, what I see lately are a bunch of people handwaiving about the need for “progress” for the sake of “progress”. (Note the double quotes.)
There is very little that my users need for their desktop to do that Gnome does not already provide.
Of course, in my other life, I *am* a hobbyist and I still use Gnome. But that is partially because I believe in eating my own dogfood. If I give Gnome to my users then I should use it myself. Otherwise, I *might* use KDE. I really can’t say.
I used to be a KDE fan. And I’m still OK with it. Gives people who like lots of knobs and controls what they like and keeps them from badgering the Gnome devs for more switches and dials.
I used KDE up through 2.something. But then I decided that I preferred Gnome.
When I see someone who is not content to use and advocate the strengths of his own preferred software, and feels the need to disparage others’ choices in inappropriate situations, I have to wonder who they are trying to convince.
Edited 2007-05-27 16:31
That was really uncalled for. There are other posters here – such as superstoned and antik – that are very active in other communities and tagging someone as a zealot simply because this person prefers another thing instead the one that you’re promoting is, quite frankly, childish behaviour. Or the fact that they are very active “at the other side of the camp” is reason to draw a line between “you” and “them” and therefore there is no need to argue?
Instead of resorting to such a low blow, why don’t you try to argue against his statements with facts?
The point is that GNOME really is behind other desktop environments in several points and some of those bullet points in that roadmap show it but some of its proponents here cannot see beyond its looks. That’s what truly sad!
I am not a GNOME user and I also think that some people are making too much of the toolbar thing (Does anyone here remember oGALAXYo’s rants?
) as I don’t change it very often either, but such basic functionality should have got into GTK years ago and there is no excuse that it hasn’t yet to this day…
Edited 2007-05-27 19:52
I’m not promoting anything. I’m just dispelling pathetic myths propagated by individuals who haven’t written a hello world gnome app in their lives, but feel the need to school us all on GNOME development and its lack of infrastructure. I’ll keep exposing their ignorance until they shut up.
Edited 2007-05-27 20:17
Uncalled for? Please! What’s uncalled for is KDE-trolls invading a GNOME-discussion and badmouthing GNOME for no good reason.
It’s not about promoting something — that’s not what the KDE-trolls are doing here. They’re just talking smack.
And GNOME is really ahead other desktop environments in several points, but that is completely beside the point! Accept the fact that the leading desktops have both strengths and weaknesses. Using one insignificant feature (in this case “editable toolbars”) as proof of a systemic fault is simply trolling, as evidenced by this extended flamewar.
KDE-trolls have been claiming KDE superiority for years, and it’s simply not true.
According to real-world MSOffice usage statistics, very few users (~2%) customize their toolbars. Hardly a compelling argument.
So what’s wrong with using the toolbar editor in libegg?
Because libegg is an unstable library, isn’t guaranteed for anyone and diverges from the main toolkit which is GTK. The point is that it needs to be stabilised within GTK first before application developers can use it. If they start using libegg anyway, in the eyes of GTK, you have unstable and suspect applications being shipped. That can’t be right.
From the point of view of application developers, it’s another library to integrate as well. It’s more work for nothing for the developers developing applications for their users.
It’s unpopular in about every desktop I’ve used.
And yet it’s there, and complex applications like word processors use it because there is just a need to customise toolbars. Again, I’m detecting an attitude of “Gnome doesn’t need this because we think that no one needs it”. Application developers expect a wide variety of quality widgets from a modern desktop environment for all sorts of purposes.
Uhm no, you have it backwards. You don’t dump unstable APIs in stable toolkit.
This is why things are such a mess, and also shows that GTK and Gnome don’t really know what their purpose is. A toolkit is there to service the requirements and needs of applications, not the other way around. If applications go off using libegg, or integrating such code into their own applications because they can’t rely on libegg, then you have unstable applications because the toolkit refuses to integrate and stabilise code it should be primarily responsible for.
Again, GTK is there to stabilise Gnome and the applications written with it, not the other way around. You have to build applications from what is known to be stable otherwise you’re in no man’s land as an application developer.
That’s why about every commercial ISV for Linux default to GNOME.
And what commercial ISVs would they be exactly, and why do they matter to anyone? Is Adobe using GTK to write Photoshop? Is Quicken using GTK? Those are the ultimate questions people want answered, and having a development infrastructure that turns them off right from the word go isn’t going to help.
That’s blatantly false. Every app on windows does it’s own thing.
I see you don’t really understand this. I can implement editable toolbars in Windows these days from an underlying stable component, and over the years we’ve had a number of additional components released as part of Microsoft Office you can reuse. At no time has anyone ever been forced into using an unstable, moving target component within Windows to get a feature, before that feature was stabilised within Windows or in some shippable, add-on component.
Don’t be silly, GNOME is not a bunch of copy and pasted code.
There are quite a few libraries that have proliferated all over the place that diverge wildly in how application programmers integrate them. They also need to know what to integrate. In the case of libegg applications either ship libegg themselves, or if they can’t depend on libegg (which they can’t) then they would have to integrate code into their own applications or via some other means.
I take it you participated in GNOME development where all the code is copied and pasted.
To an outside developer, that’s what it is. Either you use what’s in the stable toolkit underneath, or you rely on an unstable library like libegg you can’t rely on or you copy and past the one feature you need into your own application – for several years. See my last comment at the bottom.
GTK and Gnome’s underlying infrastructure just simply doesn’t serve the application developers that create applications for users.
“I’m afraid you don’t understand component based programming and inheritance.”
That’s funny.
It really is funny, and rather disturbing.
If developers need them, they’d be pointed to libegg. Sheesh. And no, not every developer needs them. I know I don’t.
The underlying layers in any system are there to service and support the layers above – namely the applications. Nothing less.
It really doesn’t matter whether no one needs a feature or not. With a full featured, stabilised and complete toolkit you get a consistent looking API that is usable for an application developer as well as many features and widgets for free.
Are you really going to tell all these commercial ISVs that are clamouring to write software for Gnome that after four years they’re going to have to ship their own libegg, or integrate the code themselves?!
What GNOME app have you developed that demanded copy and pasting?
Some rationale behind libegg, and some instances where code copies have been performed (see the link on that mail posting):
http://mail.gnome.org/archives/desktop-devel-list/2003-October/msg0…
http://mail.gnome.org/archives/desktop-devel-list/2002-February/msg…
Apparently, code copies have been performed because developers don’t want to bring in a whole unstable library for one feature they need. Pretty unbelievable really. Gnome just has no idea how to solve this perennial problem that’s been ongoing for some time.
Edited 2007-05-27 19:57
You obviously haven’t used Windows or MacOS X, because both provide toolkits, but we have idiot software developers who go out and create their own widgets and own installers for so-called ‘branding’ which I hear being thrown around.
The inconsistancy with a so-called ‘inheritable APIs and components’ definately shows when you’ve got pea brain half wits creating trash applications like Windows Media Player, Windows Messenger Live, and Microsoft Office – each with its own user interface! where is the consistancy there? I certaintly don’t see it!
If you have such an issue with GTK, then why don’t you contribute – its majorly undermaned for what needs to be done, there is nothing stopping you from working on merging editable toolbars into gtk and other missing components.
That is the difference between open and closed source; if you’re a third party developer in the closed source world, you’re at the mercy of the operating system vendor, in the opensource world, you can work to get a needed/required feature in a depedent library yourself. Thats the difference. Its not my fault that third party software vendors are lazy and would sooner ‘live it up’ than invest into their products for long term profit and competitive advantage.
It’s really true Windows and to a lesser extend Mac OS X don’t do very well in the re-use code-area, maybe even Gnome does better there. I’m not at home in Windows development, but I’ve heard their widget set is extremely limited, forcing developers to write their own, duplicating time and work.
Of course, proprietary software is ALL about duplicating time and work, so it’s not weird…
Anyway, I think his point was that Gnome should’ve spend more time on infrastructure instead of gui work, as they’re now wasting a lot of time on things that go automatically (by using the infrastructure) in KDE. Actually, KDE got his act together in this area more than 7 years ago, and KDE 4.0 is going to bring the infrastructure to a whole new level.
I think you’d have a hard time arguing the Gnome infrastructure isn’t years behind on KDE’s (and then we’re talking about a 2 years old kde 3.5.x release, based on much older KDE 3.0 tech, which was mostly evolutionairy to 2.0, this compared to the latest gnome which still lacks most of the infrastructure introduced in KDE 2).
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. It’s not even behind at all. And last I checked KDE4 is not even living up to its __unwarranted hype__. Tell us you are ignorant about GNOME and its infrastructure. Don’t tell us it is behind KDE. Behind KDE in what?
Well, behind in all the things we’ve been talking about, and more. And saying KDE 4 doesn’t live up to the hype isn’t really helping you, as people can check it out – and it DOES (in terms of infrastructure, but that’s what they’ve been aiming at).
Things like editable toolbars? You want all apps to have editable toolbars whether or not they need it. You want apps to link to libraries whether or not they need it. Because you like KDE and it does this doesn’t make it right.
Oh, but I have. And I was underwhelmed. In fact, I couldn’t tell the difference between KDE3 and 4.
Infrastructure is pointless until applications take advantage of it in innovative ways. Rewriting infrastructure for intellectual and architectural masturbation is pointless.
> Oh, but I have. And I was underwhelmed. In fact, I
> couldn’t tell the difference between KDE3 and 4.
congratulations on running a developer preview and paying attention to the desktop UI when the release was about the APIs.
those releases never purported for a -moment- to look visually different on log in from kde3. but i’d also note that you obviously didn’t run many applications otherwise you would have started to notice differences.
in any case…
> Infrastructure is pointless until applications take
> advantage of it in innovative ways. Rewriting
> infrastructure for intellectual and architectural
> masturbation is pointless.
i completely agree. but, i suppose, that’s how straw man arguments go, right? they are obviously wrong.
so, explain to me this: how does one write applications that take advantage of new infrastructure before new infrastructure is written? ah, right you can’t.
so -first- you write the infrastructure, hopefully writing/porting a representative group of applications as you do so to ensure sanity, and then you go crazy on the rest of the applications.
this is exactly what we did with kde 2.0 which has resulted in kde 3.5.7 (and counting =). it is also exactly what we’re doing with kde4. 4.0 is very much about infrastructure, yes, but with the whole intent and purpose of application development.
it’s a process of non-invertable steps.
You do it incrementally. Total rewrites are almost always a bad idea became it’ll take years for APIs to stabilize and developers to begin to take advantage of it in interesting ways. Not to mention long periods of instability. GNOME went through that period from 1.* series to 2.* series. And they lent their lessons. It wasn’t until GNOME 2.12 that GNOME actually because useful and usable. That’s why GNOME has a 6month release cycle, something I hope KDE will adopt. Even Linux is following the release often mantra these days.
It seems to me the KDE folks are doomed to repeat the mistakes that GNOME made in that transition. But I want to be wrong on this. Small and frequent incremental changes is always better than rewriting the whole infrastructure. At least based on my experience. I think it’ll be at least 3-4 years before people start using the KDE4 APIs in really interesting ways. And by interesting and innovative ways, I don’t mean porting KDE3 to QT4/KDE4 and calling it a day.
Edited 2007-05-27 20:55
> You do it incrementally. Total rewrites are almost
> always a bad idea became it’ll take years for APIs
> to stabilize and developers to begin to take
> advantage of it in interesting ways.
i see you are operating under the usual misunderstandings. unfortunate
first, we’re not engaged in total rewrites. we have introduced a number of -new- pieces of infrastructure, but have kept huge amounts kde3’s infrastructure. you know, the parts that worked really well. many of those pieces have been improved in an incremental fashion for kde 4.0 as well.
if you want to look for rewrites, there was a re-do of the mimetype system and that was for interop. other than a few examples of that, the rewrites have been happening in the application space … to take advantage of new infrastructure. and even there some of the “new” apps are ports from kde3 versions.
we’ve been doing incremental improvements throughout kde2 and kde3. we did a similar release to kde 4.0 and gnome’s 2.0 with kde 2.0. we’ve been here before, though you seem to not remember that part of history. i think it cute that people don’t know that we’ve actually done this before; i’ve been “warned” a few times by well meaning people about gnome2’s challenges.
> Small and frequent incremental changes is always
> better than rewriting the whole infrastructure
as i noted, we have done some 7 years of frequent, incremental changes. did you miss all the releases between 2.0 and 3.5.7? and we’re not rewriting the whole infrastructure.
> I think it’ll be at least 3-4 years before people
> start using the KDE4 APIs in really interesting
> ways.
people are already such applications. dolphin is using the tagging and what not from nepomuk/strigi; ksysguard is using solid; kaffiene/amarok are using phonon; plasma is centered very solidly around the new graphics tools in Qt4.. the list could go on. and we haven’t even release 4.0 yet. 4.1 and 4.2 are going to be pretty amazing releases in light of that.
> I don’t mean porting KDE3 to QT4/KDE4 and calling
> it a day
i agree. see, we have so much common ground. the difference is you think we’re making all these fairly obvious mistakes
Then I admit, I’ve been misinformed. I’ve been led to believe that KDE 4.0 was akin to an overhaul. We hear news about QT4, solid, phonon, plasma and it’s easy to be led to believe KDE is undergoing a major restructuring, or disturbance from a more cynical perspective. 🙂
This is good news. I hope this translates into user visible benefits and productivity gains. In the end that’s what matters.
You guys are doing very good work. Time will tell if the direction you have taken yields significant benefits. Either way KDE4 will certainly be better than KDE3. And I look forward to it.
I can’t imagine an app which doesn’t need an editable toolbar, unless this app has less than 5 menuitems, and all are already IN the toolbar. In all other cases, it’s silly not to allow the user to edit the toolbar. It doesn’t make anything more dificult, and if it’s implemented in the libraries, it doesn’t use memory (as each app on your desktop uses that same piece of memory). And this is just one example, there sure are more where the same goes.
You know that’s silly to say. The development has (rightly) concentrated on improving the infrastructure, and that work is based on REAL usecases and experience with the previous framework. I have followed many discussions, and what I say here is true: the libraries get new stuff if and only if it is or will be used, and the design must be based on several clear usecases. The developers are very keen on that, and have harsh words for those who want something which isn’t needed very hard.
The applications WILL use it, and that WILL show (unless all developers are hit by a truck tomorow, that is).
I think you mean Bollocks, not bullocks.
Anyway, I think you’re being a tad oversensitive in your reply. Both projects go about what they wish to accomplish in different ways. If the individual(s) don’t like GNOME because of the apparent deficiency, thre is an alternative – KDE.
I would have have negative about GNOME if it were the only desktop environment, but that isn’t the case; if I don’t like GNOME, I’ll just move to KDE and let the marketplace do the speaking for me.
With that being said, given that its pretty much how a end user perceives a desktop is up to how well it is implemented by the vendor, I’m pretty sure to say that most of what people complain about isn’t a GNOME issue but vendor issue.
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.
When people want it in GNOME they use libegg.
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.
Ah for the first time your argument is well reasoned. Maybe because it doesn’t reek of the GNOME sucks aroma. But I’ll explain why it is the way it is.
libegg is a library for testing new widgets and ideas out. For example GTK-2.10 introduced the GTKStatusICon widget set, used for showing icons in the notification area. Prior to GTK-2.10 developers had to use the libeggstatuicon implementation. The usage of this API became overwhelmingly popular that people actually got their asses together and added support for it in GTK+-2.10. The widget was added out of necessity and need. Plus it was also well used and tested.
Now, the same cannot be said for the editable toolbar. Only 2 applications I know use it in GNOME. Clearly, there’s no demand for it. And almost no motivation for anyone to get off his/her ass to include it in GTK+. If just two applications are shipping the libegg toolbar editor, then that means developers just don’t care for it. If developers did, more applications would be shipping libegg toolbar editors. And this will send a signal to the GTK+ maintainers that a toolbar editor is in demand. GNOME developers add APIs based on need/demand and experience. Not just to show off.
GNOME does things differently than KDE. It doesn’t make GNOME wrong, inferior, backward or lacking in infrastructure. You are just too inundated by the KDE way of doing things that you believe that anything that does things differently from KDE is wrong, inferior and backward. Perhaps you should take the time to understand why things are different, instead of jumping to baseless and often uninformed conclusion. Perhaps, it’s even better to appreciate the cultural difference.
GNOME’s approach is to include things only when absolutely needed and after thorough testing and also give developers the choice to choose what they want to use. KDE approach is to include everything and as much as possible and bolt mega tons of libraries to their applications and force developers to use them. Heck this cultural difference even shows up in the way both DEs design their UIs.
I just don’t want to hear the nonsense that GNOME is ten years behind because it doesn’t have a toolbar editor. Or that GNOME does not allow you to open remote locations, among other myths. That’s just patently false, ridiculously wrong and it’s bordering on trolling.
OK, you got a point, Gnome first uses a seperate lib to test something, then it gets included. Makes sense.
And that’s just not true. KDE is very carefull about what gets in KDElibs. That’s why there are the ‘layers’: something must first be used in an app, then it goes to the base library of that component (eg libkdeedu, libkdegames, libkdepim), then it can go in kdelibs (if there are enough users -> this process is DEMAND driven), and finally, Trolltech might adapt it into Qt.
Having seen the discussions about adding stuff to the KDE libs, I can assure you – this is a really tedious process, involving many people and sometimes harsh reviews. And apparently, this process does work a lot faster than the Gnome one, as editable toolbars aren’t really ‘new’ in KDE.
It IS true that you can’t start a KDE app without loading a lot libraries currently, though not to the extend you seem to think. And KDE 4 is modularizing KDElibs much more, just like Qt got more modular.
So in a nutshell, KDE got a modular, high-quality, very complete set of libraries, lightening the load of application developers. And I think I can say it is ahead of Gnome in this area (and ahead of Windows and Mac OS X, btw, though in all 3 cases, not in every area).
“It’s really true Windows and to a lesser extend Mac OS X don’t do very well in the re-use code-area, maybe even Gnome does better there. I’m not at home in Windows development, but I’ve heard their widget set is extremely limited, forcing developers to write their own, duplicating time and work.”
Actually, the .NET framework exposes an incredibly rick set of widgets for GUI development, and all of those can be extended very easily.
Some of your assertions don’t make much sense to me. You say that KDE got its infrastructure act together more than 7 years and “KDE 4.0 is going to bring the infrastructure to a whole new level.” Well, from what I understand, KDE 4.0 is a major infrastructural reworking. (Correct me if I’m wrong.) So, what I don’t understand is that if KDE’s infrastructure was so perfect in the KDE 2.0 – 3.5 timeframe, why is the major reworking necessary now, beyond simply porting to Qt 4.x?
Don’t get me wrong: I hope KDE 4.0 is a major success, and I wish KDE all the best. I simply find the fanboyism from some misguided KDE fans a bit tiresome. It is ok to love your chosen desktop without denigrating other desktops, no?
If I would have been asked I would probably state it like this:
KDE 2.0 was build using a very good architecture for its time, and the demands of the time.
In the last 7 years, this architecture was used and extended, but probably showed some areas that it was laking in certain ways. Most of this stuff can be worked around, but it is not… esthetically pleasing.
I would compare it with the evolution of scientific theories (of course, the KDE APIs are not comparable in influence, or greatness of the folowing examples 😉
Noone argues that Newtons Gravitation was not a great achievement, but over the time people found it could not explain certain effects. Some people made some changes to accomodate them, but..again…not in a nice way – until Relativity came, and we could suddenly explain most that we observe. (Though there might come a time that we again find it lacking and have to search for something new)
The KDE2/3 APIs have held a long time, and were very usefull, but now it was time to rethink some of the assertions that were underlying the design, and to come up with APIs that incorporate todays needs and state-of-the-art and that will hopefully prove as resilient as the last iteration.
But (somewhat) back on topic 😉
I wish the GNOME project all the best, (I just must admit that my ignorance on details of GNOME keep me from directly commenting on the roadmap.)
Does it denigrate Gnome to say KDE has a better infrastructure? I don’t see why. Gnome has spend more work on usability, and it shows – in most area’s, I think they’re better at the usability level. Does that make KDE worse? Of course not, KDE is as usable, if not more than Windows and in many cases even Mac OS X.
Anyway, the infrastructure brought by KDE 2.x, and improved & fleshed out in KDE 3.x was and is great. But the developers now have 5 years experience with it, and thus much ideas for improvements. Also, computers became faster (thus more is possible) and of course, there are new requirements in many areas.
And, last but not least, the competition is catching up, so let’s go to the next level 😉
I think the systemwide spellcheck is a great example of this last point. I’m not sure when it was introduced exactly, I think KDE 3.0 (5 years ago). Since then, KDE’s webbrowser, chat applications, email prog etc have had spellchecking.
Now, the competition has catched up – the firefox I’m typing this in, while at work, finally also has spelling check. So, KDE 4 will add gramar check to it’s spellcheck, and automatic language detection. And others will follow, of course, so we’ll think about something else for KDE 5.
> Speaking of evince, it’s nice to know KDE 4 will
> have a similar application.
we already have a similar application in kde3
it’s just getting better in kde4 and already has features on that roadmap.
> Hopefully it will share resources with evince by
> using libpoppler, which AFAIK KDE doesn’t do yet.
poppler has been used by kpdf/okular and kviewshell/ligature for some time now. it was a compile time option which you used and depending on the distro and the maturity of poppler in their mind you’d either get a poppler enabled version or one that used another solution.
> Consistency is one of GNOME’s strongest features.
yes, gnome has a lot of consistency between things like configuration dialogs in the base set of apps (and it has been getting better in 3rd party apps too). but let’s not engage in double speak here; the fact that apps still need to implement toolbar configurability, and that that makes it onto a road map, highlights exactly what the original poster was saying. you’re talking about different things (and boy is it annoying when people reply in a conversation using that tactic)
Catch up with the competition? I’m not sure what you mean by that, but from my point of view, Gnome surely isn’t lagging behind the competition.
A difference of implementation doesn’t necessarily mean it’s falling behind the competition.
I really don’t think there is a premier desktop. All have their pros and cons, and to my mind Gnome isn’t even close to be lagging behind the competition.
Hopefully this roadmap has no dead ends!
With KDE 4 on the horizon, this could be interesting.
I don’t want to troll here, but I couldn’t not notice that some of the work which is “manually” done per app in GNOME, like editable toolbars, or opening and saving to remote locations, are standard for a very long time for any apps using kdelibs.
Situations like this show the meaning of powerful libraries, don’t they?
that true
i prefer kde, but i must admit that gnome improve faster then a couple of year… surely because kde improve itselft quickly
Opening and saving to remote locations has been in GNOME for years. Google GNOME-VFS.
> I don’t want to troll here, but <cut>
Well, just STFU and don’t troll if you don’t want to; or do you?
Have you read the article? Have you noticed there is talk about the transition from gnome-vfs to GVFS? Well, that is what it is about.
Does that work better in KDE now? Well, yes, but there are other things in KDE which work worse than Gnome, and KDE is also evolving, and borrowing ideas from gnome. And this is a thread about Gnome, anyway; there is absolutely no need for destructive critique which only shows the mental limitations of some.
What situations like these show is the meaning of being an uninformed troll. f–k if we need them in any GTK related thread. Oh, yeah, and there are Gnome trolls in KDE threads: well, f–k them too; f–k all trolls; please, go away.
A KDE troll at +5 … quite interesting, eh?
Can’t this thread be about Gnome and not about how great KDE is?
I agree, but it’s always going to be that a discussion on the roadmap of Gnome will raise conversation on the competition.
Personally, I really don’t see either one of them better than the other. I just prefer Gnome.
Incremental changes bring us a slowly more functional desktop. I admire gnome’s philosophy, and approach to their GUI design.
I like the idea of incremental changes. Technically speaking, I think it can make them move faster because they don’t have to rewrite (partially or totally) basic components. It also makes a part of their userbase feel more comfortable because there’s no radical changes from one version to another.
However, this is not what the average joe wants (user or developer). For users, Gnome 2.x is getting old. Sure, it was such a big improvement over the 1.x serie and it served people very well. But in 2007, more can be done. The whole desktop metaphor could be changed. Nautilus can be improved alot (better integration with the platform (search?), new layout(s), etc). Audio and video players in Gnome could be alot better (seriously, Gnome is not multimedia friendly). The panel needs to be rewritten and radically changed. Adding applets, menu entries (in launcher), etc takes too much time. The launcher needs to be replaced with something like Vista’s start menu or KDE’s kicker (search capability, etc). Gnome also needs better software. CD/DVD burning applications arent flexible. Music ripping utilities as well. gFTP needs more features (protocols). Xchat needs more work as well (well it’s not part of Gnome but it’s the de facto irc client in most Gnome installtions). Seriosuly, there’s nothing like mIRC for the Linux desktop. Xchat and Konversation are barely enjoyable.
Now for developers, Gnome needs a better programming IDE. Anjuta is a joke (and the “new” version is still beta). Geany? not really. Seriously, the Linux desktop needs something like Visual Studio 2005 for C/C++ development. Kdevelop isn’t there yet. Eclipse-cdt is no good (I’m not saying that Eclipse is bad, but for C/C++ programmers the cdt plugin doesn’t really make it). And what about RAD developement? Something like VC++(MFC)/VB? Glade is “weird” and lacks good integration with a good IDE.
And of course, I think that a brand new GTK 3.0 would be much welcomed by the programmers. The API needs to be reworked. The “OO” in C concept isn’t that bad and allows making language binding easily. However, the world didn’t stop moving. GTK 3.0 needs a brand new true OO API. It should be not only a layer like GTKmm. It needs a new live. It needs to be built from scratch with OO/design patterns in mind. Windows Forms and WPF should inspirate GTK developers.
Gnome/GTK 3.0? Sure.
I like the idea of incremental changes. Technically speaking, I think it can make them move faster because they don’t have to rewrite (partially or totally) basic components
Part of the reason that incremental improvements work well in Gnome is because the libs are not that big. Compared to KDE, which has a lot of features in kdelibs, more of the logic is in the individual applications in Gnome. So individual apps can improve much more without affecting others. Of course overall there is more work to do and more duplication of effort.
Seriosuly, there’s nothing like mIRC for the Linux desktop. Xchat and Konversation are barely enjoyable.
I know mIRC has a lot of power, but I can’t stand it. Way too complicated of an interface, and you have to set a lot of options to make it usable. The newer versions of konversation are perfect for me. Simple and to the point.
Seriously, the Linux desktop needs something like Visual Studio 2005 for C/C++ development. Kdevelop isn’t there yet. Eclipse-cdt is no good (I’m not saying that Eclipse is bad, but for C/C++ programmers the cdt plugin doesn’t really make it).
Yeah Visual Studio is still better than any IDE on Linux. Try KDevelop 3.4 though. It is a massive improvement over the previous versions. It’s the first version I can comfortably use with very little annoyance. Still not as good as VS, but very usable, and the work going into the next version looks very promising. But I use Qt, so I don’t know how well it works for GTK projects.
Edited 2007-05-27 04:48
> so I don’t know how well it works for GTK projects
do you know about Eclipse?
first: the roadmap was an interesting read. i think it’s very useful and important to communicate these things between developers and users. thanks, gnome team, for sharing =)
> Compared to KDE, which has a lot of features in
> kdelibs, more of the logic is in the individual
> applications in Gnome. So individual apps can
> improve much more without affecting others
this is of dubious benefit and has real drawbacks. most applications should, imho, concentrate on their specific task. e.g. the author of a cd burner should be able to concentrate on burning cd’s, not making toolbars editable.
this approach allows applications to be easily created and, once started, to bloom into comprehensive solutions for their solution space.
for the commonalities, when we do want to change how something works from the user’s perspective it is instantly reflected in all apps. this rarely causes API changes as they tend to wrap the internals rather well. such larger API changes are kept for major release overhauls (2.0, 3.0, 4.0..) and then the same leverage comes into play to make it fairly easy to affect large changes.
so you end up with more featureful applications with greater feature consistency for less work.
that said, this doesn’t mean that a kde application can’t go off and “do their own thing”. amarok, as one example, did that for several components/widgets. it’s up to the application developer: they have the choice to concentrate on just the problem domain or also invest additional time and effort into common elements.
without shared common elements, though, that option doesn’t exist, does it?
What has GNOME 3.0 have to do with the development of GNOME per-say? GNOME hasn’t gone to 3.0 because the need for major binary/comaptibility breakage is not there. It is modular enough for features to be added, existing features to be enhanced without needing to throwout the baby with the bathwater.
Version numbers don’t mean a damn thing; heck, Microsoft made a leap from 5.1 (Windows XP) to 6.0 (Windows Vista) and the version jump doesn’t justify the so-called ‘improvements’ seen in it. At the most, its Windows 5.3.
Pardon? there is already search related facility/integration with Nautilus, the problem is that most distributions don’t include it with their distribution (for some strange and unknown reason).
How so? the problem I see is Soundjuicer which lacks error correction and very precious when there are /-?! and so forth characters in the song name/group name. Apparently it is being replaced by Rythmbox in the future which will be like an iTunes clone/replacement.
Ultimately all the problems pretty much lay at the feet of gstreamer, and the complete lack of quality codec mux’s for tags – mp4 tagging on Ubuntu corrupts the file, why don’t they just bloody well use the tagging included with the faac application itself? I use that when using grip and it works perfectly, the low quality performance when it comes to ripping music, the process hogging of gstreamer compressing vs. when it is simply piped through to the native application as the case with grip (which I used instead).
It is already there. Novell has one which includes the ability to search, like I said about search integration with Nautilus, vendors choose not to bundle it.
Its about weighing up ‘core applications’ with adding what people want. You don’t want to have a desktop that becomes to big and overwhelming that it ends up causing more problem than it fixes.
What is wrong with xchat, for instance? I certainly find it alot better than having to rely on mirc which requires payment for usage after 30 days. There is a music ripper, but I admit it sucks when compard to grip. As for gFTP, who uses ftp these days? I certainly don’t; good old curl for downloading is good enough for me.
As for the rest of the post; we don’t need OO; OO is marketing bullcrap developed by those who wish to sell an ovely complex paradigm through books, consultancy and ‘new tools’. It so damn complex, you need all that crap just to make it useful.
They’ve already got a vision, they don’t need to copy WPF; in the *NIX world there is Cairo, plonk everything onto Cairo, and have an OpenGL back end to Cairo, and voila, you get all the features of WPF – its not rocket science (as Microsoft tries to make it out to be).
As for developer tools, there is Netbeans and GTK for Netbeans – if developers choose to ignore it, then I hardly see it as GNOME’s fault.
What do we get when we build replacements for Windows start menu, filemanager, development tools etc. etc? Probably a Windows clone/replacement. But is that what WE as a Linux/BSD/Unix community really want? Why are we using Linux/BSD/Unix if Windows is indeed so much superior?
We should have left this “clone supposedly superior systems” stage behind us at least a decade ago!
One thing which is missing on the list is more interoperability with KDE. They already started working together on things like libpoppler which is used by KDE and Gnome apps. But it should go much further:
I assume that users want to use the best application available. That means they user for example K3B under Gnome. Dependend from what distro you use:
– Themes look different
– Font settings are different
– Menu structure is different
As work is going in the right direction I think interoperability between the 2 big DE’s should have a much higher priority.
Seems, that also with KDE 4 things are handled differently than in Gnome: instead of using the same icons they use different ones, instead of using a common HIG they user their own ones. For example KDE apps have a “Settings” menu while Gnome apps have “Settings” in their “Edit” menu.
Please use common techniques for setting colors, icons, fonts, screensaver settings, (display) power saving settings etc.
Apps do not work good enough in the other desktops right now. I start KDE apps at Gnome startup but sometimes KDE session manager conflicts with Gnome session manager etc.
I think these are small things in daily work which are annoying. I do not always need the newest and greatest technology when these small things are still not working.
And I don’t wanna use only KDE OR Gnome apps but the best app available – anything else doesn’t make sense for me.
My wish: please put these things to a higher priority.
well, both projects do have a different filosofy on UI, so that’s why you see differences in settings and stuff.
KDE 4 will improve interoperability a bit more, as KDE apps will change the ok/cancel button order when they’re run in Gnome (at least, Qt supports it so I guess KDE apps will do so too). But there is still work to do.
Gnome apps in KDE can be configured (in the Kde Control Panel) to look like KDE apps, by giving them the same theme, colors, icons and fonts, but sadly there is no such thing on the Gnome side.
But things like menustructure, well, that’s much harder. Guess we won’t see that anytime soon, sorry.
You’d be hard pressed to find any ok/cancel buttons in GNOME as the HIG advocates the use of imperative verbs on button labels; e.g. “Discard Changes”/”Cancel”/”Save”. As for alternative button order, GTK+ has had that since v2.6 which was released in December 2004.
> You’d be hard pressed to find any ok/cancel buttons
> in GNOME
the reference is to function not literal labels on the dialogs. we advocate exactly the same principles in kde.
> As for alternative button order, GTK+ has had that
> since v2.6 which was released in December 2004.
we’ve had it for a number of years as well, but now it is automatic (no configuration), supports several semantic groupings and works on MacOS, Windows, GNOME and KDE. chameleon like even, which should lead to even better interop. we figure users shouldn’t be forced to configure these things manually or have it only work in some places and not others.
is the button ordering in Gtk+ still controlled by a manual setting?
As far as I know, but I can’t be sure since I’ve never used it.
Does KDE have any plans on changing its default button order to match GNOME? That would lead to even better interop, and there would be no need for automatic switching of button ordering.
Do you care to explain why KDE is the one that has to change something in order to match GNOME’s way of doing something instead of the other way around? To me, it looks like KDE has done a lot to work nicely together with GNOME/GTK apps in a blended environment already as is (GTK-QT, button reordering, dropping working features such as DCOP to adopt someone else’s for interoperability purposes, etc.).
Just once I’d like to see the action, not the words, coming from the GNOME side of things for a change!
Edited 2007-05-27 21:49
Yes, when will Gnome enable an easy way to blend-in KDE apps?
Nononono! That might require some C++ coding and we all know that C++ coder go to the deepest pit in hell (all coders got to hell so it matters where in hell you’ve got to go to)
Certainly; the MacOS button order (which GNOME uses) is more intuitive. Humans scan information from the top left to the bottom right; this fact has been well known in the print industry for decades. For this reason the most important button (the affirmative one) belongs at the bottom right.
The only reason that Windows uses the reversed order is that Microsoft were afraid of being sued by Apple if they copied the Mac GUI wholesale… so they changed it in certain places, button order being one of them.
GTK-Qt is a GTK+ theme which uses Qt to draw its widgets. It’s intended for use with KDE in order to give GTK+ programs the superficial look of Qt/KDE applications. For you to demand that GNOME somehow “repay the favor” is akin to saying “I bought my kid a nice bike, now I demand that you do the same for your kid.” What would be the point? Do you think more GNOMErs would use KDE applications if they were rendered by GTK+? As with GTK-Qt, the integration would be skin deep at best.
Were you not paying attention? Both desktops have support for button reordering.
You have it backwards: D-Bus is a natural evolution of DCOP, and was developed in cooperation with KDE. This is a case of GNOME adopting an excellent piece of KDE technology.
Edited 2007-05-27 22:13
A bit over generalizing, aren’t we?
Care to explain how people who write in right-to-left languages scan from left to right? (Hoping you consider them to be humans as well)
What about those with top-to-bottom languages?
Apologies. I’m of course referring to humans who read left-to-right. I have no idea of how other humans scan information, but that question is orthogonal anyway (no pun intended).
Edited 2007-05-27 22:29
So he over-generalized. Not that it matters though: in right to left languages the button order is adjusted accordingly (in KDE and Gnome), so everything Gnome claims about the natural order of scanning and button order still applies. Mentioning the obvious (that some languages read in a different direction) is a bit of a distraction at best, strawman at worst.
Nevertheless, readers scanning in a known direction (obvious) isn’t the same as saying it’s then obvious in which order buttons should be placed, nor is it (IMHO) worth breaking with years of tradition from Windows (where most users are and have been) and other X apps. I’d rather not be a part of that revolution with its dubious gains.
Seriously though, another poster really hit it on the head. I don’t see much coming from Gnome for integration. Kgtk (using KDE dialogs in gtk apps) came from the KDE side. Qt compiling against glib so KDE apps can use Gnome C dialogs comes from Trolltech. Gtk-qt, which skins GTK apps to look like KDE apps for fitting into a KDE desktop comes from the KDE side. Klearlooks, a skin to help Qt fit into a Gnome desktop comes from Trolltech. Trolltech/KDE are expected to do the work to make gtk apps look good in KDE, and they are the ones who do work to make KDE apps look good in Gnome. And someone asks when KDE will change its button order to match Gnome’s.. typical. Maybe after KDE starts using gstreamer (directly) instead of phonon (never). Sheesh.
“I don’t see much coming from Gnome for integration”
You mean other than the freedesktop.org work they’re doing (together with KDE, I might add)?
Integration is more than widgets and themes.
well, several screenshots from Gnome 2.18 on the gnome.org website still show cancel/ok buttons, so I guess they’re not that rare. I wonder, btw, does Gnome detect what environment it is running in, and adjust the buttonorder automatically?
Don’t worry, it does have high priority.
For example toolkit developers are working on a specification of visualization options which should be accessible by toolkits through a mechanism called XSETTINGS.
Other examples are icon themes and preferred locations(e.g. documents folder, music folder, etc)
Specifications like this are hard work, not only because they will require changes for all participating parties, but also because there are always things like exceptions that need to be specified or localizations issues that need to be considered.
No. Icons are themed, i.e. the icon names are specified and used across toolkits/desktops, and the user’s settings decide which image each name is linked to.
The different desktops carter to different user groups and thus have different ideas about workflow and user interaction. Therefore they need different HIGs. E.g. there would be no good in specifying a placement policy for OK and Apply buttons, if the desktop’s interaction pattern is instant apply.
The latter two are being taken care of. A group of developers is working on a specification of D-Bus interfaces which the respective desktop infrastructure service will then implement.
This sounds weird. Either session manager is usually only started through the desktop startup script, e.g. for KDE in startkde.
Since this isn’t supposed to be invoked when starting an application stand-alone, I am wondering how they could possible conflict.
I totally agree.
Let’s keep the pressure on both Gnome and KDE to cooperate more.
> that also with KDE 4 things are handled differently
> than in Gnome
omg, please tell me your joking.
in kde4 we have closed the interop gap with icon naming (you have your timeline exactly backwards on that one), mimetype handling, IPC and more.
a huge amount of effort has been going into this. we’re also a major source of effort put into portland.
i totally agree we have more ground to cover, but kde is -not- the problem here.
…with all the KDE-trolls? Do they have a problem with the upcoming Gnome-on-QT4….ehh.. KDE-by-Gnome-HIG…eeehh.. KDE4 release?
Nobody was trolling against KDE a few weeks ago when more news about KDE4 was released. Many Gnome Users (and some KDE Users) were rejoicing. Are KDE users really so insecure they have to flame Gnome as well as their own devs? (Read the last KDE4 thread – KDE devs flamed by KDE users – very interesting…)
If KDE is all that good why is it that KDE devs are replacing KDE technology with Gnome technology? Why are they using the Gnome HIG in KDE4. Why can QT4 be compiled against glib if KDE and QT4 are the new shrubberies in the forest?
And if Gnome is all that good how come Gnome Users are creating replacement apps for all the things removed from Gnome? And why are they looking longingly at GTK+-WebCore?
Could it be – hypothetically
– that the best DE is a combination? (I know it’s blasphemy but just think the thought – a desktop ½ Gnome, ½ KDE 
EDIT: Didn’t take the KDE trolls long to discover this post. The most offensive and factually wrong pro-KDE posts are at 5 while Gnome-users are modded down. Says a lot about the maturity of a certain DE’s userbase
Edited 2007-05-27 12:46
Pretty good posting overall, but
Are they? Any examples for us people that follow KDE development quite closely but have no idea what you are talking about?
Well, they don’t. Is this some kind of trick question? Where it is impossible to answer the actual question because the base of the question does not exist?
Qt4/X11 can be compiled to support the GLib event loop, which is usually implemented in glib. It remains to be seen if this a configuration that will be shipped as part of distributions or if at a later point there will be an event loop abstraction library which is going to be implemented by those interested in interoperability.
No need to invent some kind of conflict here.
Nobody was trolling against KDE a few weeks ago when more news about KDE4 was released. Many Gnome Users (and some KDE Users) were rejoicing. Are KDE users really so insecure they have to flame Gnome as well as their own devs?
Well, I was one of the GNOME users rejoicing at the progress of the KDE Project, and given this roadmap, I’m still not seeing the kind of strategy that’s going to be successful in the long-run. GNOME has to invest in its development platform to ensure its future. That’s what I like about KDE, and that’s what KDE developers like about it as well.
If KDE is all that good why is it that KDE devs are replacing KDE technology with Gnome technology?
I’m not exactly sure what you’re talking about. They replaced DCOP with DBUS, a very minor change that was basically predicated on freedesktop.org choosing GNOME’s message bus over KDE’s for some reason. There’s Tango for icon consistency. What else?
Why are they using the Gnome HIG in KDE4.
They’re not. They have their own HIG coordinated by Celeste Paul, one of the foremost usability experts. Some aspects of the new HIG appear similar to the GNOME HIG, most notably the text labels under icon button widgets. The old icon buttons were a major usability flaw, so copying GNOME is this respect is a very wise decision. In fact, I’m not using KDE right now simply because of usability and consistency issues that are being corrected in KDE4.
Why can QT4 be compiled against glib if KDE and QT4 are the new shrubberies in the forest?
This is all wrong. You probably meant to ask why Qt4 can’t be compiled against libgnome, but instead, it would have to be libgnome compiling against Qt4. In case you didn’t know, glib is GNOME’s way of bolting some semblance of object-orientation and main loops onto GTK. Qt includes this functionality.
And why are they looking longingly at GTK+-WebCore?
Because not everybody is convinced with the direction of Firefox/Gecko, and KHTML/WebCore is arguably better technology. GNOME has its own HTML engine, GTKHTML, but it’s quite primitive and only useful for things like the help viewer.
Could it be – hypothetically
– that the best DE is a combination? (I know it’s blasphemy but just think the thought – a desktop ½ Gnome, ½ KDE 
I think that a DE that looks like GNOME but works like KDE would be very appealing for many segments of the free software userbase. Something tells me that the KDE devs understand this as well. Because of technologies like KParts and Flakes, KDE can integrate nearly the whole desktop environment into Konqueror for power users, or deconstruct it into simple, discrete applications for casual users. The latter will be the default, and this approach will seem rather GNOME-like.
> If KDE is all that good why is it that KDE devs are
> replacing KDE technology with Gnome technology? Why
> are they using the Gnome HIG in KDE4. Why can QT4
> be compiled against glib if KDE and QT4 are the new
> shrubberies in the forest?
hold on. so … if we aren’t working on interop, people crap on us. if we are, people point to it and say, “see, it wasn’t good!” that’s highly rediculous behaviour and not particularly motivating.
thankfully we do what is best for our users, regardless of the “wisdom” of people such as in this thread.
now, to your claims. we’re not using the GNOME HIG, though we have drawn inspiration from various efforts around the tech world. (i’d also note that the GNOME HIG is hardly original.)
Qt has an option to be compiled with the glib event loop so that if people want they can create components in one toolkit that work in the other. in any case, it’s a compile time option. and apparently we’re the ones flexible enough to fix these problems so that our users are happiest.
as for being the new shrubberies, i think if you look at all the additional functionality and features offered in addition to all the interop work, you’ll have your answers.
> that the best DE is a combination
i completely agree that today it is. that’s why we put so much effort into interop as well improving our infrastructure and applications.
and yes, like you, i wish people would grok that and stop the inane “my dad can beat up your dad” discussions.
I notice a lot of people are complaining about non-editable toolbars..But why? Is it really such an important feature? I have only needed to do that in Epiphany. Oh well, editable toolbars would make more sense if they got rid of those annoying menus IMHO. Like in Epiphany, I never use the menus at all cos I’ve got all the buttons I need in the toolbar..But still, the menu is there and can’t be removed..And even the simplest apps all include a menu, even if there is no need for such at all. So, make a compromise: remove menus from the apps which don’t REALLY need it, but add editable toolbars?
Another thing I see arguing about is the inconsistency of open/save file dialogs: well, I haven’t really paid much attention to that, but it could be because some apps are GNOME apps, and some are just plain GTK+ apps? There is a difference you know, plain GTK+ apps don’t have dependency on GNOME. And as GTK+ is intended to be very highly portable it doesn’t include platform specific stuff like networking. This, in my opinion, is smart, though it may not be to everyone’s liking. But just try to remember that this is a different approach than the QT toolkit has.
And finally, please, STOP ARGUING WHICH ONE IS BETTER: KDE OR GNOME! They have so different approaches to things that it’s like comparing oranges to apples! Sure, KDE may have lots of things GNOME doesn’t have, but that works both ways! It doesn’t make either way somehow inferior, unless it really really really is functionally completely fscked up..
Can’t we stop that toolkit-trolling? Please?
Both KDE/QT and GTK+/GNOME are excellent toolkits and desktops with astonishing capabilities. In some areas KDE takes the lead, in other areas GNOME scores.
I’m happy to see that there are some news from the GNOME front. And since it is improvement, everyone should be happy to. I don’t see any need for a flamewar here.
If someone wants to bitch, why not bitch about that toolkit mess called Microsoft Windows? ^^
Edited 2007-05-29 09:54