Linked by Thom Holwerda on Sat 26th May 2007 20:18 UTC, submitted by GhePeU
Gnome 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.
Order by: Score:
Long list
by miketech on Sat 26th May 2007 20:43 UTC
miketech
Member since:
2005-07-21

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

Reply Score: 3

RE: Long list
by ebassi on Sat 26th May 2007 22:15 UTC in reply to "Long list"
ebassi Member since:
2006-02-28

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;.

Reply Score: 3

RE: Long list
by intangible on Tue 29th May 2007 17:16 UTC in reply to "Long list"
intangible Member since:
2005-07-06

There's always alltray. http://gnomefiles.org/app.php/alltray

Reply Score: 1

Another page
by GhePeU on Sat 26th May 2007 20:56 UTC
GhePeU
Member since:
2005-07-06

This is interesting as well, the raw datas gathered from maintainers: http://live.gnome.org/RoadMap/Modules

Reply Score: 4

...
by Hiev on Sat 26th May 2007 21:19 UTC
Hiev
Member since:
2005-09-27

Finally.
Thank you GNOME team.

Reply Score: 2

nice work
by superstoned on Sat 26th May 2007 21:25 UTC
superstoned
Member since:
2005-07-07

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.

Reply Score: 4

RE: nice work
by thebluesgnr on Sat 26th May 2007 23:10 UTC in reply to "nice work"
thebluesgnr Member since:
2005-11-14

'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

Reply Score: 5

RE[2]: nice work
by TSDgeos on Sat 26th May 2007 23:30 UTC in reply to "RE: nice work"
TSDgeos Member since:
2007-05-26

Hopefully it will share resources with evince by using libpoppler


http://webcvs.freedesktop.org/poppler/poppler/ChangeLog?revision=1....

I can see some @kde.org addresses there

Reply Score: 3

RE[3]: nice work
by superstoned on Sun 27th May 2007 00:12 UTC in reply to "RE[2]: nice work"
superstoned Member since:
2005-07-07

of course, Okular dev's are working on poppler. They have since the beginning (not sure, they might even have initiated it)

Reply Score: 3

RE[4]: nice work
by anda_skoa on Sun 27th May 2007 00:26 UTC in reply to "RE[3]: nice work"
anda_skoa Member since:
2005-07-07

of course, Okular dev's are working on poppler


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

Reply Score: 3

RE[5]: nice work
by superstoned on Sun 27th May 2007 09:53 UTC in reply to "RE[4]: nice work"
superstoned Member since:
2005-07-07

I DID recognize his name, but just wasn't sure ;-)

Reply Score: 1

RE[2]: nice work
by superstoned on Sun 27th May 2007 00:22 UTC in reply to "RE: nice work"
superstoned Member since:
2005-07-07

'why does that even have to be written?'.

That's how software works.


shouldn't such stuff have been in the libs 5 years ago, like in KDE?

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.

Albert Astals Cid is one of the main developers on both Poppler and KPDF (which will be Okular in KDE 4).

It's already superior to Vista's interface in my opinion, and it even beats Mac OS X in several points.

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 ;) ).

Reply Score: 5

RE[2]: nice work
by segedunum on Sun 27th May 2007 01:39 UTC in reply to "RE: nice work"
segedunum Member since:
2005-07-06

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.

Reply Score: 5

RE[3]: nice work
by Mystilleef on Sun 27th May 2007 03:20 UTC in reply to "RE[2]: nice work"
Mystilleef Member since:
2005-06-29

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?


Editable toolbar is in a library called libegg. Most developers do not need editable toolbars. And those who do can use libegg.

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?


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.

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.


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?

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.


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

Reply Score: 5

RE[4]: nice work
by leos on Sun 27th May 2007 04:30 UTC in reply to "RE[3]: nice work"
leos Member since:
2005-09-21

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.

Reply Score: 5

RE[5]: nice work
by Mystilleef on Sun 27th May 2007 05:04 UTC in reply to "RE[4]: nice work"
Mystilleef Member since:
2005-06-29

Except (and correct me if I'm wrong here) libegg doesn't seem to be a separate library at all.


Really? I wonder why it's called libegg.

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.


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.

Editable toolbars are untested? After 3 years?
Really it's not like it's a cutting edge feature that may introduce bugs.


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.

And obviously it is wanted, as shown by the apps in the roadmap intending to add support for it.


I saw __one__ app that plans to use editable toolbars in the roadmap. EOG.

It's not the most important feature, but it is very nice when all apps on the system have similar interaction methods.


Are you saying current GTK+/GNOME apps don't?

And Windows is the pinnacle of UI design?

No, but apparently someone was __comparing__ GNOME to __other__ platforms.

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.


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.

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



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

Reply Score: 5

RE[6]: nice work
by chris_dk on Sun 27th May 2007 08:35 UTC in reply to "RE[5]: nice work"
chris_dk Member since:
2005-07-12


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.

Reply Score: 3

RE[7]: nice work
by Mystilleef on Sun 27th May 2007 08:46 UTC in reply to "RE[6]: nice work"
Mystilleef Member since:
2005-06-29

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.

Reply Score: 1

RE[6]: nice work
by leos on Sun 27th May 2007 14:37 UTC in reply to "RE[5]: nice work"
leos Member since:
2005-09-21

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.

Reply Score: 5

RE[7]: nice work
by Mystilleef on Sun 27th May 2007 15:07 UTC in reply to "RE[6]: nice work"
Mystilleef Member since:
2005-06-29

That's a poor excuse. If this was integrated into GTK properly, it wouldn't be an extra dependency.


Untested APIs is not put in GTK+.


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:


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 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.


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.


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.


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.

Reply Score: 2

RE[4]: nice work
by segedunum on Sun 27th May 2007 14:20 UTC in reply to "RE[3]: nice work"
segedunum Member since:
2005-07-06

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.

Reply Score: 5

RE[5]: nice work
by Mystilleef on Sun 27th May 2007 14:54 UTC in reply to "RE[4]: nice work"
Mystilleef Member since:
2005-06-29

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.


So what's wrong with using the toolbar editor in libegg?


It's untested, after four years? And calling it unpopular is simply a bit rich considering that all other modern desktops have such widgets.


It's unpopular in about every desktop I've used.


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.


Uhm no, you have it backwards. You don't dump unstable APIs in stable toolkit.


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.


That's why about every commercial ISV for Linux default to GNOME.


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.


That's blatantly false. Every app on windows does it's own thing.


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.


Don't be silly, GNOME is not a bunch of copy and pasted code.


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.


I take it you participated in GNOME development where all the code is copied and pasted. Or are you just making this up?


I'm afraid you don't understand component based programming and inheritance.


That's funny.


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.


If developers need them, they'd be pointed to libegg. Sheesh. And no, not every developer needs them. I know I don't.


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.


What GNOME app have you developed that demanded copy and pasting?

Reply Score: 1

RE[6]: nice work
by kelvin on Sun 27th May 2007 15:59 UTC in reply to "RE[5]: nice work"
kelvin Member since:
2005-07-06

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.

Reply Score: 2

RE[7]: nice work
by sbergman27 on Sun 27th May 2007 16:29 UTC in reply to "RE[6]: nice work"
sbergman27 Member since:
2005-07-24

"""
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

Reply Score: 4

RE[7]: nice work
by DeadFishMan on Sun 27th May 2007 19:39 UTC in reply to "RE[6]: nice work"
DeadFishMan Member since:
2006-01-09

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

Reply Score: 5

RE[6]: nice work
by segedunum on Sun 27th May 2007 19:47 UTC in reply to "RE[5]: nice work"
segedunum Member since:
2005-07-06

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

Reply Score: 5

RE[3]: nice work
by kaiwai on Sun 27th May 2007 03:39 UTC in reply to "RE[2]: nice work"
kaiwai Member since:
2005-07-06

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.


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.

Reply Score: 5

RE[4]: nice work
by superstoned on Sun 27th May 2007 10:03 UTC in reply to "RE[3]: nice work"
superstoned Member since:
2005-07-07

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).

Reply Score: 4

RE[5]: nice work
by Mystilleef on Sun 27th May 2007 10:37 UTC in reply to "RE[4]: nice work"
Mystilleef Member since:
2005-06-29

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?

Reply Score: 2

RE[6]: nice work
by superstoned on Sun 27th May 2007 11:23 UTC in reply to "RE[5]: nice work"
superstoned Member since:
2005-07-07

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).

Reply Score: 3

RE[7]: nice work
by Mystilleef on Sun 27th May 2007 11:46 UTC in reply to "RE[6]: nice work"
Mystilleef Member since:
2005-06-29

Well, behind in all the things we've been talking about, and more.


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.

And saying KDE 4 doesn't live up to the hype isn't really helping you, as people can check it out


Oh, but I have. And I was underwhelmed. In fact, I couldn't tell the difference between KDE3 and 4.

and it DOES (in terms of infrastructure, but that's what they've been aiming at).


Infrastructure is pointless until applications take advantage of it in innovative ways. Rewriting infrastructure for intellectual and architectural masturbation is pointless.

Reply Score: 1

RE[8]: nice work
by superstoned on Sun 27th May 2007 12:38 UTC in reply to "RE[6]: nice work"
superstoned Member since:
2005-07-07

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.

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.

Infrastructure is pointless until applications take advantage of it in innovative ways. Rewriting infrastructure for intellectual and architectural masturbation is pointless.

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).

Reply Score: 5

RE[6]: nice work
by kaiwai on Sun 27th May 2007 13:29 UTC in reply to "RE[5]: nice work"
kaiwai Member since:
2005-07-06

Total Bullocks!

I gave you the benefit of the doubt. But now you are just flat out trolling. GNOME is not years behind KDE in infrastructure. 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?


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.

Reply Score: 2

RE[6]: nice work
by segedunum on Sun 27th May 2007 14:30 UTC in reply to "RE[5]: nice work"
segedunum Member since:
2005-07-06

Total Bullocks!

I gave you the benefit of the doubt. But now you are just flat out trolling. GNOME is not years behind KDE in infrastructure.


Sorry, but the evidence is totally to the contrary and it simply isn't trolling. I know some people don't like it, but to move forwards it has to be admitted.

People are actually admitting here that to implement editable toolbars people are copying and pasting common code into their applications for a widget that is completely common on every other desktop environment.

That kind of thing is about fifteen years behind Windows and the Mac, never mind behind what KDE has. If you tell that to a Windows or Mac developer who hasn't been exposed to Linux desktops then they simply won't believe you.

And last I checked KDE4 is not even living up to its __unwarranted hype__.

Again, KDE's hype is based on having a solid infrastructure to do all the cool stuff people want. That's hard work, but it pays off.

Don't tell us it is behind KDE. Behind KDE in what?

When developers want editable toolbars in KDE it is implemented in kdelibs by all interested parties, and applications that want to implement them then inherit it from kdelibs. Other applications can then simply use it for free in the future with no trouble whatsoever. Any problems are immediately noticed, talked about by all the application developers and are fixed in one place, reducing bugs and more than increasing consistency.

It's a tad astonishing that has to be explained in this day and age.

Reply Score: 5

RE[7]: nice work
by Mystilleef on Sun 27th May 2007 14:58 UTC in reply to "RE[6]: nice work"
Mystilleef Member since:
2005-06-29

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.


When people want it in GNOME they use libegg.

Reply Score: 1

RE[5]: nice work
by BluenoseJake on Sun 27th May 2007 17:16 UTC in reply to "RE[4]: nice work"
BluenoseJake Member since:
2005-08-11

"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.

Reply Score: 5

RE[5]: nice work
by phoebus on Tue 29th May 2007 02:39 UTC in reply to "RE[4]: nice work"
phoebus Member since:
2006-12-24

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?

Reply Score: 2

RE[6]: nice work
by camel on Tue 29th May 2007 09:20 UTC in reply to "RE[5]: nice work"
camel Member since:
2005-06-29

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.)

Reply Score: 2

RE[6]: nice work
by superstoned on Tue 29th May 2007 09:25 UTC in reply to "RE[5]: nice work"
superstoned Member since:
2005-07-07

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.

Reply Score: 4

RE[2]: nice work
by aseigo on Sun 27th May 2007 20:07 UTC in reply to "RE: nice work"
aseigo Member since:
2005-07-06

> 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)

Reply Score: 5

RE: nice work
by flanque on Sun 27th May 2007 00:43 UTC in reply to "nice work"
flanque Member since:
2005-12-15

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.

Reply Score: 5

Dead ends?
by mrcool on Sat 26th May 2007 21:46 UTC
mrcool
Member since:
2006-08-23

Hopefully this roadmap has no dead ends!

With KDE 4 on the horizon, this could be interesting.

Reply Score: 1

Background libraries
by shiny on Sat 26th May 2007 22:18 UTC
shiny
Member since:
2005-08-09

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?

Reply Score: 5

RE: Background libraries
by collinm on Sat 26th May 2007 22:24 UTC in reply to "Background libraries"
collinm Member since:
2005-07-15

that true

i prefer kde, but i must admit that gnome improve faster then a couple of year... surely because kde improve itselft quickly

Reply Score: 1

RE: Background libraries
by Mystilleef on Sat 26th May 2007 23:50 UTC in reply to "Background libraries"
Mystilleef Member since:
2005-06-29

Opening and saving to remote locations has been in GNOME for years. Google GNOME-VFS.

Reply Score: 5

RE: Background libraries
by Lobotomik on Sun 27th May 2007 09:39 UTC in reply to "Background libraries"
Lobotomik Member since:
2006-01-03

> 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.

Reply Score: 3

v RE: Background libraries
by dylansmrjones on Sun 27th May 2007 12:47 UTC in reply to "Background libraries"
Ah, the KDE trolls have arrived
by chris_dk on Sat 26th May 2007 22:50 UTC
chris_dk
Member since:
2005-07-12

Can't this thread be about Gnome and not about how great KDE is?

Reply Score: 5

RE: Ah, the KDE trolls have arrived
by flanque on Sun 27th May 2007 00:46 UTC in reply to "Ah, the KDE trolls have arrived"
flanque Member since:
2005-12-15

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.

Reply Score: 5

wonea
Member since:
2005-10-28

Incremental changes bring us a slowly more functional desktop. I admire gnome's philosophy, and approach to their GUI design.

Reply Score: 2

Gnome 3.0
by rx182 on Sun 27th May 2007 04:03 UTC
rx182
Member since:
2005-07-08

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.

Reply Score: 2

RE: Gnome 3.0
by leos on Sun 27th May 2007 04:47 UTC in reply to "Gnome 3.0"
leos Member since:
2005-09-21

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

Reply Score: 5

RE[2]: Gnome 3.0
by netdur on Sun 27th May 2007 08:23 UTC in reply to "RE: Gnome 3.0"
netdur Member since:
2005-07-07

> so I don't know how well it works for GTK projects
do you know about Eclipse?

Reply Score: 1

RE[2]: Gnome 3.0
by aseigo on Sun 27th May 2007 20:18 UTC in reply to "RE: Gnome 3.0"
aseigo Member since:
2005-07-06

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?

Reply Score: 5

RE: Gnome 3.0
by kaiwai on Sun 27th May 2007 05:57 UTC in reply to "Gnome 3.0"
kaiwai Member since:
2005-07-06

However, this is not what the average joe wants (user or developer). For users, Gnome 2.x is getting old.


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.

The whole desktop metaphor could be changed. Nautilus can be improved alot (better integration with the platform (search?), new layout(s), etc).


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).

Audio and video players in Gnome could be alot better (seriously, Gnome is not multimedia friendly).


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).

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).


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.

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.


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.

Reply Score: 4

daemonologist Member since:
2007-01-30

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!

Reply Score: 1

Interoperability with KDE
by Felix on Sun 27th May 2007 10:49 UTC
Felix
Member since:
2005-08-14

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.

Reply Score: 5

RE: Interoperability with KDE
by superstoned on Sun 27th May 2007 11:48 UTC in reply to "Interoperability with KDE"
superstoned Member since:
2005-07-07

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.

Reply Score: 5

RE[2]: Interoperability with KDE
by kelvin on Sun 27th May 2007 14:13 UTC in reply to "RE: Interoperability with KDE"
kelvin Member since:
2005-07-06

KDE apps will change the ok/cancel button order when they're run in Gnome


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.

Reply Score: 2

RE[3]: Interoperability with KDE
by aseigo on Sun 27th May 2007 20:49 UTC in reply to "RE[2]: Interoperability with KDE"
aseigo Member since:
2005-07-06

> 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?

Reply Score: 5

RE[4]: Interoperability with KDE
by kelvin on Sun 27th May 2007 21:28 UTC in reply to "RE[3]: Interoperability with KDE"
kelvin Member since:
2005-07-06

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.

Reply Score: 3

DeadFishMan Member since:
2006-01-09

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

Reply Score: 5

RE[6]: Interoperability with KDE
by chris_dk on Sun 27th May 2007 21:52 UTC in reply to "RE[5]: Interoperability with KDE"
chris_dk Member since:
2005-07-12

Yes, when will Gnome enable an easy way to blend-in KDE apps?

Reply Score: 4

RE[7]: Interoperability with KDE
by anda_skoa on Sun 27th May 2007 22:06 UTC in reply to "RE[6]: Interoperability with KDE"
anda_skoa Member since:
2005-07-07

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)

Reply Score: 4

RE[6]: Interoperability with KDE
by kelvin on Sun 27th May 2007 22:09 UTC in reply to "RE[5]: Interoperability with KDE"
kelvin Member since:
2005-07-06

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?


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.

To me, it looks like KDE has done a lot to work nicely together in a blended environment already (GTK-QT, button reordering, dropping working features such as DCOP to adopt somebody else's for interoperability purposes, etc.).


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

Reply Score: 2

RE[7]: Interoperability with KDE
by anda_skoa on Sun 27th May 2007 22:22 UTC in reply to "RE[6]: Interoperability with KDE"
anda_skoa Member since:
2005-07-07

Humans scan information from the top left to the bottom right; this fact has been well known in the print industry for decades.


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?

Reply Score: 5

RE[3]: Interoperability with KDE
by superstoned on Sun 27th May 2007 16:43 UTC in reply to "RE: Interoperability with KDE"
superstoned Member since:
2005-07-07

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?

Reply Score: 5

RE: Interoperability with KDE
by anda_skoa on Sun 27th May 2007 12:34 UTC in reply to "Interoperability with KDE"
anda_skoa Member since:
2005-07-07

As work is going in the right direction I think interoperability between the 2 big DE's should have a much higher priority.


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.

instead of using the same icons they use different ones


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.

instead of using a common HIG they user their own ones


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.

Please use common techniques for setting colors, icons, fonts, screensaver settings, (display) power saving settings etc.


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.

I start KDE apps at Gnome startup but sometimes KDE session manager conflicts with Gnome session manager etc.


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.

Reply Score: 4

RE: Interoperability with KDE
by chris_dk on Sun 27th May 2007 18:03 UTC in reply to "Interoperability with KDE"
chris_dk Member since:
2005-07-12

I totally agree.

Let's keep the pressure on both Gnome and KDE to cooperate more.

Reply Score: 3

RE: Interoperability with KDE
by aseigo on Sun 27th May 2007 20:26 UTC in reply to "Interoperability with KDE"
aseigo Member since:
2005-07-06

> 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.

Reply Score: 5

What's...
by dylansmrjones on Sun 27th May 2007 12:37 UTC
dylansmrjones
Member since:
2005-10-02

...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

Reply Score: 3

RE: What's...
by anda_skoa on Sun 27th May 2007 13:10 UTC in reply to "What's..."
anda_skoa Member since:
2005-07-07

Pretty good posting overall, but

If KDE is all that good why is it that KDE devs are replacing KDE technology with Gnome technology?


Are they? Any examples for us people that follow KDE development quite closely but have no idea what you are talking about?

Why are they using the Gnome HIG in KDE4.


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?

Why can QT4 be compiled against glib


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.

Reply Score: 5

RE: What's...
by butters on Sun 27th May 2007 14:19 UTC in reply to "What's..."
butters Member since:
2005-07-08

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.

Reply Score: 5

RE: What's...
by aseigo on Sun 27th May 2007 20:43 UTC in reply to "What's..."
aseigo Member since:
2005-07-06

> 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.

Reply Score: 5

Lots of fun here
by WereCatf on Sun 27th May 2007 13:20 UTC
WereCatf
Member since:
2006-02-15

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..

Reply Score: 2

Please stop
by Pfeifer on Tue 29th May 2007 09:49 UTC
Pfeifer
Member since:
2006-02-20

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

Reply Score: 4