Richard Stallman On KDE/GNOME Cooperation

Karma Sucks writes: "For the first time that I remember, RMS is encouraging collaboration between the GNOME and KDE projects. He offers a concrete idea: Unifying the themes between KDE and GNOME. Matthias Ettrich once went far enough to propose a default unified 'Linux' theme that both Qt and GTK+ could support."

Comments

kde-look.org

[The Great Wakka]

I've never heard of it before. I would have posted themes.org as the link. But that's me. kde-look is a very nice website, but is there a GNOME equivalent?

Re:kde-look.org

[grrae]

I found this page. It seems to be what your looking for.

Hoping

[TheMatt]

I really hope this will happen. There are so many apps that each has, that a KDE-Gnome work-together would be great. For example, I would love Konsole in Gnome and Galeon in KDE...with the stability they have in their native setting.

Plus, it always seems KDE looks better than Gnome, though I don't know why. Just my opinion.

Re:Hoping

[avalys]

Why would you have stability problems running KDE apps in gnome, and vice-versa? They're only X-Apps - konsole, gimp, and the rest couldn't care less what window manager/desktop environment/file manager/web browser you're using.

Re:Hoping

[joestar]

"For example, I would love Konsole in Gnome and Galeon in KDE..."

Did you... ever try Mandrake? I think your dream has been a reality for a while.

Woah

[mosch]

Woah now, I know RMS is considered to be an important fellow, but this is a crazy idea. Come on, cooperation between KDE and GNOME? What crazy idea is next, a free flow of information and help between BSD and Linux?

Oh wait, my bad, this idea is so obvious it's rediculous. Does anybody have a valid reason why it hasn't happened already?

Re:Woah

[scott1853]

I think the answer to your last question can be summed up in one word. Ego.

Yes ego. It's not just for the criminally monopolists =)

Re:Woah

[FattMattP]

Oh wait, my bad, this idea is so obvious it's rediculous.

Then why haven't you patented it already? Hurry, before someone else does!!

Sounds like a good idea

[gadfium]

Ideally, I'd like to see as many applications as possible running under both environments. With most Linux distributions currently, the libraries for both environments are supplied. I'd like to see this become standard, and I'd also like to see an interface library developed in collaboration which will translate calls to either gnome or kde, depending on which is running. This library would have to be primarily written in C++ to suit the existing QT/KDE application base, but would also need to have C and other language bindings.

Re:Sounds like a good idea

[mattdm]

I'm going to say "no". There's huge architectural differences between KDE and GNOME -- it's not just that they're interchangable faces. In fact, there's also huge conceptual differences in the way the widget libraries work -- qt's slots/sockets mechanism, for example. There's no way to do a 1-1 mapping at any level beyond the most simplistic.

Wow

[mikeage]

I honestly fail to see how anyone could disagree with this. A common interface to help newbies, and retaining the customization power that makes linux great... just don't make it another OS X ripoff.. PLEASE!

Re:Wow

[Yorrike]

I'll say.

Yes, the whole "my desktop is liquid" look is trendy at the moment, but I think there definitely needs to be a super-sexy not-found-elsewhere none-ripoff default theme for both KDE and Gnome.

Just take a brose through something like the GUG galleries ( This for example) and imagine these works as entire themes.

In the same way that flashy graphics make people buy video games, KDE and Gnome need to attract the masses with sex appeal.

Re:Wow

[Anonymous Coward]

So, what company is going to pony up the millions of dollars it will take to hire the world's best interface designers ... and pay them to design it and code it?

Or, uh, who's willing to copy Aqua pixel-for-pixel and take advantage of apple's existing interface design?

Oh wait...

Re:Wow

[zhensel]

Actually, there's a pretty simple argument against this. Standardizing the desktop stagnates innovation. With a standard "Linux" desktop, all distributions for a good amount of time will have to follow that standard or face alienating their users. Look at how little the MacOS interface changed before OSX and how only with Windows XP has Windows had a major interface revision - and even now it is still heavily rooted in the framework of prior revisions.

Personally, I agree with you and think a standard would be a good idea. Taking a step away from rapid developement and making a single stable interface would do wonders for acceptance. Besides, you can always have easily accessible information on configuring your interface how you like it. Still though, the arguement against this is pretty obvious.

I'd probably say that the best idea would be for some group to go and dedictate a year or so to making the be-all-end-all of interfaces. Not some wierd hybrid of previous interfaces like most distros ship now, but something that is simple, elegent, etc. Other people have said it, and I'll repeat - like the OSX interface. I'm not saying it's the most efficient, but it consistently does what you intuitively expect it to do. That's what a defacto Linux "theme" would need to do. The only other option, I suppose, is just to copy Windows or OSX or another highly developed/researched interface. There simply exists nothing right now that would make sense to call the default desktop.

Re:Wow

[talonyx]

"how only with Windows XP has Windows had a major interface revision - and even now it is still heavily rooted in the framework of prior revisions"

Somebody doesn't remember Program Manager.

Re:Wow

[zhensel]

hehe, post windows 95... 3.1 wasn't really superior to dos anyhow :)

Re:Wow

[hexix]

Just out of curiosity, did you read RMS' post?

He was not talking about a standard look, he was talking about a standard for writing themes. So that a theme written for gtk+ would work fine with qt, and vice versa.

This would fix the problem of some programs looking different then others. Well, most programs.

Re:Wow

[zhensel]

In my opinion, the purpose of standardization is defeated rather easily if you stop at the level of the desktop background, colors, and icons. There are a few notable advantages from this - standard icons are a big help as well as standard window layouts (I know I've seen a TON of different schemes for the menu bars on windows in various default interfaces). I don't see the point in all this fuss over a standard theme if that's all you're going to go for though. I'll admit that getting gnome and kde to cooperate at all is a slick achievment, but results would be more interesting to me than press releases and unified color schemes.

Besides, if you want to standardize icons that means either the foot or the K will have to go - you know that'll never happen :)

Re:Wow

[zhensel]

I was replying to this -
"Matthias Ettrich once went far enough to propose a default unified 'Linux' theme that both Qt and GTK+ could support."

There wasn't any link provided to back that up, so I took it as is.

And no, I didn't read the RMS post. That's why I didn't comment on it.

Re:Wow

[Shotgun]

I'd like to see a lot more OS/2isms in a desktop. A lot of the OS/2 Workplace Shell developers are still around. You think we could convince IBM to fund a desktop developement effort?

Forget Themes: Make the Clipboards compatible

[rjamestaylor]

I use KDE but prefer Mozilla. I am *sick* of the incompatible clipboards that KDE/GTK use. As a matter of fact, I just complained to my co-worker about this and said, "This is why a monopoly is a good thing: someone to declare 'clipboard functions work this way or no way'". Damn I hate this.

Re:Forget Themes: Make the Clipboards compatible

[4of12]

Yea, verily.

Sure, let KDE and Gnome start on the surface with themes that provide a common lool `n feek.

But then, start digging down to the lower level inter object communications layers to get exchange of data at that level, even if it's something that's slower than molasses between KCOP and Bonobo. As long as it works!

Re:Forget Themes: Make the Clipboards compatible

[forgoil]

You have pinpointed the absolutely biggest strength with Windows. You will always have the same controls, things will be where you assume them to be, the clipboard will work, COM works, DirectX works, there is one win32(64) etc etc etc.

So how come diversity is bad in this case? Because it's confusing and counterproductive. It uses a lot of development time that could have been better spent on one better solution that is taken to a mature state.

If KDE/Gnome wants to make certain protocols etc comming, that's nice as long as nobody is left out. But I would never accept two desktopsystems on my computer. I'd rather see more work on KDE/QT.

If you want Linux to be sold with home computers, this is what you need:

1. One desktop with a good set of standard applications and tools
2. A good office suite
3. Good support 24/7 that you can trust
4. A much better packaged product
5. All subsystems should have the same release proceedueres as KDE, this more than anything includes the kernel. It absolutely has to be stable and be as free from bugs and holes as possible at each release point. The system won't be updated if it requires compiling the kernel and configing it.
6. A dead simple upgrade/patch system. Use Konqi, have a little blinking thing on the screen saying "new stuff" and make everything upgradable.
7. Kill off all diversity in formats for configuration files, add a reposatory (done the right way, think of it as a database. And put everything in files instead of one huge one, it forced me to reinstall my XP, pissed me off to no ends) and make it simply to configure. If I know what I want to change I shouldn't have to read the help.
8. Write help files for everything in the system. And that includes everything from "how do I set the keyboard to Swedish" to "I want to know what this obscure error message from g++ means".

There you go, there you have a list. A lot of the ground work is done, and some of the work is being done as I sit here and wriet. But now it just requires more work, people disagreeing, people agreeing and much much more work (see why we don't want five more GUI systems etc etc).

See it as a MacOS X killer if you want to ^_^ Heck, I wished I had time to do this myself. Guess you should mail me if you can muster a 1,000 coders, including the kernel and KDE people. Should sell it (and support people) to Compaq, HP, Dell, etc to include in their new spiffy computers. Including a DVD with all the binaries and source (eat that M$!).

Re:Forget Themes: Make the Clipboards compatible

[grungeKid]

Actually, the X has a fairly sophisticated clipboard
model, maybe a little bit too sophisticated. Hence it has traditionally been poorly understood and badly implemented in apps and toolkit.

Gnome does the Right Thing with respect to clipboards, while QT2/KDE2 uses a more limited clipboard model. The good news is that QT3 and thereby KDE3 will do the Right Think and therefore interoperate a lot better with Gnome (as well as properly written X apps such as XEmacs)

These comments are somewhat enlighening: http://dot.kde.org/1013076354/

Also read this for a backgrounder about clipboard and X: http://www.jwz.org/doc/x-cut-and-paste.html

Re:Forget Themes: Make the Clipboards compatible

[Tony]

1. We have that. It's called "KDE" or "GNOME," or even "Window Maker with ROX."

2. Uhm... It's coming?

3. You *are* seriously joking, right? Red Hat. Linuxcare. There are *lots* of others, including SUSE, Mandrake, and IBM.

4. What do you mean? Do you mean the CDs should have purty holograms on them? Or should the installer tell you how much better global warming will be once you've got everything installed? If you mean an easily-installed product that works right out of the box, I suggest SUSE. It installs better, easier, and faster than MS-Windows.

5. Rrrriiiiggghhht. Which release procedures should the kernel follow? And *who* has ever forced you to upgrade your kernel? I'm not even sure what you are getting at here.

6. apt-get update && apt-get upgrade (this assumes you use Debian, which negates SUSE, as suggested in 4. But SUSE has its own upgrade system. I use Debian.)

7. Yeah! And let's kill off support for alternative processors, too! All those subdirectories under /usr/src/linux/arch frighten and confuse me. Seriously, though, use webmin if you don't want to learn all about the strange and wonderful world of diverse configuration files. It does what you want, without you telling developers how to do their job.

8. man, info, /usr/doc, HOWTO, and my favorite, Google. It's there, man. It's there.

The only problem that exists in your list is #2, and it's a doozy. Abiword, Gnumeric, Koffice, and Open Office are coming along, but they still have some ways to go. They are good enough for me, but I don't use many office apps. Personally, I think office apps tend to suck slime, in concept and execution. But that's just me.

Now, please explain: you don't have time, but if someone can get 1k programmers together, they should call *you*? Whatever for?

Re:Forget Themes: Make the Clipboards compatible

[Mandelbrute]

Gnome does the Right Thing with respect to clipboards,

Yes, it's a nice copy of the way MS used to do things. Other people have other ideas and implement them in other ways - the right thing is usually just what the author thinks is the right thing. Until there is an ISO standard, there isn't going to be a "right thing", and even then extensions are good. Ultimately, the right thing in X is to support the X clipboard - everything else is an extension.

Re:Forget Themes: Make the Clipboards compatible

[dvdeug]

Until there is an ISO standard, there isn't going to be a "right thing",

Huh? It's totally bogus to think that only ISO can create a standard. There is a written standard for X, and that does explain what the "right thing" is.

Re:Forget Themes: Make the Clipboards compatible

[StrawberryFrog]

Actually, the X has a fairly sophisticated clipboard

And that's where the problems start. Thee is nothing about storing smallish pieces of data temporarily that needs to be part of any gui or windowing toolkit - it's not a visual thing in any way. It should be a system service that can be used by any gui. That way X, gnome and KDE program would all do the same right thing.

Re:Forget Themes: Make the Clipboards compatible

[he-sk]

Typing apt-get doesn't qualify as updating. It's crap. You need a Windows-Update lookalike to succeed.

What kind of crack are you smoking?!

The "apt-get update && apt-get dist-upgrade" mechanism is the smoothest update-system I've yet come accross. It beats IMNSHO all other Linux upgrading systems, and everything I've seen in Windows-land hands down. (My boss swears on the SUN update mechanism, but I as of yet I haven't had a chance to look at it.)

There are only two problems I see with this system from a newbie perspective.

• The user doesn't now when there are updates available, unless he runs apt-get update: This can be taken care of, by a nightly cron-job and/or a script running at startup, that informs the user per local e-mail of new updates.
• The messages that debconf provides are sometimes very technical. But then again, these messages have to be technical, they can't be dumbed down to the point where they are useless. Also, almost every non-trivial message ends with "If you don't know what this all means, type foo" or some equivalent message.

Re:Forget Themes: Make the Clipboards compatible

[ChaosDiscordSimple]

You have pinpointed the absolutely biggest strength with Windows. You will always have the same controls, things will be where you assume them to be, the clipboard will work, COM works, DirectX works, there is one win32(64) etc etc etc.

I take it you don't do alot of Windows development. COM most certainly does not always work, and when it fails it isn't terribly helpful at finding the problem. DirectX is extremely dependent upon independent hardware developers to provide high quality drivers, a task they're not all up to. As for the Win32 API, there are multiple versions with many incompatibilities. You might find Microsoft's list of incompatibilities between versions of Windows interesting reading.

Indeed a good idea but

[Anonymous Coward]

what is needed more is interopability of the component and document models, heck both desktops can't even handle non x clipboards in a compatible way. The first thing a normal desktop user who uses Linux for the first time would ask, why he can't drag a file from konqueror into evolution and why he cant paste his gimp picture into kword over the clipboard!
Heck even e copy from a galeon the copy paste menu way would never generate a paste in kedit!
I'm sure a user would care less about a common L&F than about a precise and normed app interoperability, which should be possible!

I want a single desktop anyway

[Anonymous Coward]

Personally I think KDE and GNOME should chuck it all in and start to work together on a unified desktop taking the best elements from both and combining them.

KDE is so much nicer to develop for than GNOME imho but I prefer to use GNOME, I'm sure that others have differing opinions about what they like and hate about each environment, but working together to provide maybe the ultimate desktop experiance would be brilliant!

I know this opinion is a little radical and not likely to happen, but if I had my eutopia, that would be it!

Does this mean...

[SteelX]

We'll soon get GNU/KDE and KGNOME?

Re:Does this mean...

[sulli]

You'll get GNUDE .. perfect for viewing and manipulating, um, photos.

Re:The Best Theme?

[robbieduncan]

ANy serious attempt to copy the look ant feel of OSX on any non-apple product will bring down Apples lawyers like a pack of rabid wolves. Sorry , the best Linux desogn minds will just have to come up with their own ideas.

Not at all

[drew_kime]

He explained his reasons for opposing KDE. As you even said in your summation, it had nothing to do with who was in charge and everything to do with the license. The license has since changed, so there is no more need to oppose KDE.

People who assume his attack on the license was an attack on the people who chose to use that license are the ones who come off as ideologues.

Might be a good idea

[koh]

Flamewars like the Gnome/KDE one have always been a side-effect on free projects that have the same final purpose (and on free projects in general ;), but it's true that the rivality between developpers of such important components has to disappear. The idea is good, and given its originator it may have a considerable impact on future GUI development aims.

But I'm not quite sure if a compatible theme engine is the way to go... Many people still consider themed desktops as a waste of time and space, and sometimes you can find really awful things on themes.org ;)

Another direction may be the component object model itself. There has been, IIRC, at least one attempt to start an uniform interface between ORBIT and the KDE object model, and others may be under way.

IMHO, this would be a much better challenge for Gnome/KDE integrators, and provide a broader signal to the GUI community.

Microsoft has made COM first, then made XP skinnable. Of course, the Linux themes.org effect was not present then (IIRC), and maybe it was sheer luck. It worked for them anyway.

But I'll sure fancy some skinnable icons while drag/dropping objects between Gnome and KDE apps :]

Re:Might be a good idea

[forgoil]

Flame wars can sometimes be pretty good. Forces people to have to explain what they mean etc, which is good. Just go find an article with Linus and see what he has to say. I can't remember it correctly, but if I remember correctly he was pretty stern and didn't accept anything without a good explaination.

So disagreeing can be very good (as long as personal feelings aren't involved. That is never good), but getting two products might not...

Re:Might be a good idea

[forgoil]

You very much did bring up the problems :) One of the big problems is separating services from applications, and to be able to handle all of them and all types of media.

Yay!

[Frag-A-Muffin]

This is good news! What's next? An abstraction of the widget sets so that programmers can code to a neutral API that can be deployed on both GTK and QT (Or Gnome and KDE) at once?!?! When are we going to see that? :)

This is VERY IMPORTANT....

[CDWert]

This is probably the most singular unifying architechture change that will propel Linux to the top of all the markets, server, desktop, and embedded.

YEAH RIGHT !

Ok, Im suprised RMS said something without demanding, frothing, or berating. But in the whole scheme of things is this really worth the bits its typed with ?

Some architechtural changes in the next version of each twoard additional compatility would be nice. But aside from that they are different systems, written by different people, with different needs and different goals, as well as different philosiphys on how to achieve what they want. To this end I dont really see what good compatible themes are gonna do for the rest of the projects...

Re:To Hell with RMS

[BlaisePascal]

That's not a fair reading, in my opinion.

RMS didn't like KDE because it was not "free" -- and in fact, in his opinion, it's position was threatening Free Software in general (it undermined the GPL, it took people away from developing Free alternatives, etc). So he argued against KDE, in favor of GNOME, a truely Free alternative.

KDE is now Free, in part because of serious amounts of lobbying by the Free Software Community, including RMS. KDE is no longer the bad guy, RMS no longer has a beef with KDE.

Now that the "Free KDE" battle is over, RMS is now saying "Um guys... we won -- ALL of us (KDE and GNOME) won, last year. It's time, past time, to stop sabre-rattling at each other". Since Qt became GPL-compatable, I haven't seen RMS stoking the GNOME v. KDE fires. Now he's trying to quench the GNOME v. KDE fires, because leaving them smouldering is bad for Free Software in general.

Theme is just the very first step

[AtomicBomb]

Starting with something simpler, eg theme, is a reasonable idea to me. Believe it or not, trivia like why paste is Ctrl-V in one program but Ctrl-Y in another have stopped many people from migrating away from Windows.

But, in the longer term, they really need to enable the basic components to talk to each other. Clipboard is an obvious target. Linux won't boom on desktop before something equivalent to OLE has been fully implemented and *widely* accepted by all the different camps involved.

Re:To Hell with RMS

[Error27]

>>All he's offering is an email for crying out loud, he's not offering any thing substansive at all, unless you count his blessings as substansive.

Yeah... I was really surprised when I clicked on the link to mail.gnome.org and saw an email.

A lot of times when you read email then there are cool videos and 3-d graphics. One time I found a live goat!

I guess open source email lists just aren't up to the standards Microsoft users are accustomed to. I mean *sheesh* email on an email list??? How old fashioned!

Progress

[grrae]

Here, in a quote from This Letter, RMS says,

"...The ill feelings that linger between GNOME developers and KDE developers are not good for the community, and it is very useful to help calm the antagonism."

Let's here from a few who are (accepted to be) wiser than ourselves:

"Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people." -George Bernard Shaw (emphasis, mine!)

"Honest disagreement is often a good sign of progress." -Mahatma Gandhi

Well...

[Microlith]

I don't know about anyone else, but I always thought it was funny how the Open Source community yelled about "standards," yet we have so many damn standards that there aren't any.

Now that license issues are cleared up, RMS has a chance and he's gonna take it. Eliminate two, create one. This isn't a bad thing, since you STILL have the source.

We have options for customization, and a lot of freedom, but what we lack is any real consolidation (IE eliminating redundant standards), thus creating a plethora of pitfalls for software developers.

This is one thing I think the Linux Standards Base should cover. More than just one boring, rather useless "base," it should cover MANY bases, and specify standard APIs, installations, and specifications for systems/software. Hell make Linux Standard Base certification like that damn Made for Windows XX logo.

Theory:

LSB defines a desktop base, a server base, and an embedded base.

On the desktop base you have modules (not necessarily compatible), say Gaming Module which includes all necessary packages and auto-detection and config info, a Network client module that automatically loads remote config utilities and any necessary client software, and a workstation module that adds it's required things.

Same for server and embedded.

Also have the LSB supply standard definitions for the GUI APIs. Standard Themes, fonts, what have you.

If you can build a solid foundation for your system and get it under control (community control, it's still ours), then you'll attract users. I think that's a bit of what RMS is trying to do here.

Re:Well...

[Yarn]

More than just one boring, rather useless "base," it should cover MANY bases

All our bases? (Sorry)

More descriptive name for a combined project...

[rbeattie]

Kgnode?
Gnoked?
Gnodek?
Kdome?
Kgdneome?

or my favorite:

Gnuked.

-Russ

Why RMS applied to GNOME board

[sl956]

Back in November 2001, when RMS was candidate to the GNOME Board of Directors, there was a discussion on /. about the reasons why he applied.
Just a couple days before, he had said during a conference in Paris that his primary reason to apply to the board was to support cooperation between GNOME and KDE (see my post), eventhough it wasn't clearly stated in his answers to the GNOME board candidacy questionnaire.
I'm really happy to see that it was not only electoral bulls**t.
Maybe he is the last person you could have think of for such a task (especially knowing his position toward the KDE team in the old days of the QPL), but here he comes with this simple (as in not heavily political) practical (as in usefull) first step... so let's try !

Auto-magically scaling titlebars

[doorbot.com]

Since we're ushering this new era of KDE/Gnome friendliness, I have one simple request...

Can one (or both) of these two desktops allow me to scale the title bar on the windows? I can change all of the other fonts to a bigger size, but when I change the title bar font it just gets cut off vertically. Sorry, but some of us try to run high resolutions on smaller monitors.

By the way, here's cool theme from KDE-Look.org (one of the few ones that didn't rip off some pre-existing OS (majority were XP/MacOS X)):
Gorilla @ KDE-Look.org (preview)

Notice how small the title bar font is... just think the joy you could bring to small children if that scaled with the font size! It would be perfect on this theme...

Re:Auto-magically scaling titlebars

[Fnord]

Actually that's a rip off of a Gnome theme that was meant to test the Vector capabilities of nautilus.
Not necessarily a rip off though....its named the same. I guess just a port.

Re:Auto-magically scaling titlebars

[jonathan_ingram]

Yes - the original poster has his facts completely wrong.

That screenshot was posted to kde-look.org by a Gnome troller, along with the comment "no, sorry this is not KDE and i doubt that KDE will ever gonna look like this. well i bet a couple of you people gonna move to GNOME now.".

I'm not sure what the guy thought was unimplementable in KDE. SVG icons will be in KDE 3.1 (the patch already exists, but came too late to be included in KDE 3.0 -- it will be in 3.1, however). The rest seems to be just window/background themes.

Re:Auto-magically scaling titlebars

[Spoing]

The person who posted the SVG Gorilla theme on kde-look was a troll. Yet, they were also right; Gnome _now_ has vector icon themes. No theory, no guesswork, 100% available. Now.

That KDE will have them later is no surprise -- the KDE team works hard and has a polished desktop.

That it is available for a version of KDE beyond a release that hasn't occured is stretching the word 'exists' beyond it's practical application. Yes, it exists. No, it is not recommended for anyone at this point. In a few months, after KDE 3.0 is out, a back port will probably show up but nothing in the main release till later.

Re:Auto-magically scaling titlebars

[spitzak]

Fortunately, if this problem exists, it is entirely under control of the window managers, which both pick the font to use and also draw the window edges. That is, this is not a built-in problem with X.

Seems to work ok in KDE with it's default settings. Likely a lot of the problem is pixmapped themes that cannot scale. It looks like WindowsXP avoids this by not allowing pixmapping of the borders of the titlebar, only of the buttons (which end up centered if the bar grows).

OMG! Hell did freeze over!

[Chanc_Gorkon]

Debian is close to releasing and they are talking about a unified Linux desktop theme. Hell most have frozen over or this is a sign of the apocalypse!

Better C++!

[Otter]

To my mind, the single most important thing RMS could do to help out KDE is to push for better C++ support in GNU. Advantages are:

• It will address what's generally felt to be KDE's biggest drawback.
• Do the same for Mozilla and every other C++ project, free and non-free, running on GNU systems.
• Point up the importance of the GNU contribution to what's generally referred to as Linux. (Not that I'm thrilled to see him getting more ammunition to pester us on that score, but it's not until I was cursing out the FSF for making C++ apps run so slow that I realized he's actually got a good point.)

Besides, it's something he's in a position to actually do, and which doesn't require anyone to sacrifice existing work.

(Poor guy -- he's like Alan Greenspan, where every public utterance is turned into a grand policy question.)

Re:Better C++!

[Otter]

Specifically, what improvements would you like to see in G++ ? Perhaps you or someone else might want to post your thoughts. We'd be very interested in what you have to say, if your comments are specific and concrete.

I don't claim to be qualified to speak on this myself, but Waldo Bastian's paper on this subject would be a good start. (Note that it concerns linking, not g++, although there are plenty of wishes out there for g++ too.) Write Waldo or post to the kde-devel mailing list and I'm sure plenty of detailed suggestions will be forthcoming.

Re:Better C++!

[cobar]

I believe that a lot of the loader issues were dealt with in the latest version of binutils. There was an article in Linux Today about it.

GDE

[TeknoHog]

GDE: the GNU Desktop Enviromnent.

Think about it. Compare to 'windows' in its simplicity if you like. We want to create a unified GNU/Linux desktop operating system and not play around with fancy names. (Designed for X Windows, anyone? :-)

Re:GDE

[abe ferlman]

It would be like the end of the Dark Crystal when the Skeksis and the Mystics merged into those weird light-beings after the restoration of the crystal.

The only question is, if Craig Mundie falls into a pit of fire, does ESR disappear, or is it RMS?

:)

Re:OMG! Hell did freeze over!

[The Great Wakka]

Not only that, but also Mozilla is reaching! Gasp! Could the Doom of the World be upon us?

Yes!

[Adam Wiggins]

Here at the office, we are finding that a lot of GNOME apps are far more usable for day to day tasks. Most of our employees are moving to Evolution - they absolutely love the calendar, task lists, and contacts. (I only use the email portion, myself.) Also, Galeon is a faster and stabler browser than Konqueror. But as a desktop, GNOME just won't cut it for production use. (Two of my coworkers switched to Ximian GNOME for a few weeks, and declared it practically unusable.) So we're definitely going to stick with KDE as the environment now, but for apps...Gnumeric, Evolution, and Galeon are all better than their KDE equivilents.

Some better interoperation (cut-n-paste, default browser & mail clients, themes) would really make our lives a whole lot easier. In the meantime we will hobble by.

I suppose that both desktops are shooting to someday have enough apps that it is not necessary to mix-and-match quite so much. But in the meantime...

Graphics support

[llamalicious]

Now if we can get them all working together with an xserver, say XFree... and have the whole gui/graphics driver thing settled once and for all...

And then we get them to work with the Kernel developers, and after that the other peripheral developers... and then we can shrink wrap the whole thing and sell it, lets say, for $99 bucks.

doh!

No thanks, I'll just use OSX. (Or Win2k)

[Pope Slackman]

shit man, the source is there, if it pisses you off *that much* then fix it.

Getting rid of the inconsistency and incompatabilty in X is hardly a one man job.
It's hardly a 1000 man job.
Hell, removing inconsistency from X is like removing religion from church - it just can't be done.

C-X C-S

Re:No thanks, I'll just use OSX. (Or Win2k)

[Pope Slackman]

coupled with the advantages of running on top of X windows
Which are? Network transparency[1], and...what?
Jamming graphics calls through sockets? W00t indeed.

But the GNU system will have every option you could ask for,
All using different toolkits, with different key bindings, different quirks and different looks, and each requiring 30 megs of widget libraries that duplicate the functionality of each other.
No thanks.

Until X starts *enforcing* a single toolkit[2], like Mac, Windows, and virtually every other decent GUI has done, it's going to be discordant and annoying.

To hell with KDE and GNOME, they don't fix the underlying problem of nonexistant standards or policy, they just cover it up with more bloat.
Which is good, I guess, if you like having 100+ meg of widget libraries on your system, and being able to watch the widgets flicker as they redraw themselves.

C-X C-S
[1] Which isn't even all that special any more, though it was really cool in 1987.
[2] Which seems extraordinarily unlikely, given the "community"'s steadfast resistance to change.

How ironic...

[pongo000]

...that when I bring up the subject of cooperation among similar projects, I'm rated a troll, yet RMS stands before us like a demi-god because he can't seem to figure out what exactly he believes in.

If anyone ever tells you "Don't shoot me, I'm just the messenger" -- shoot him.

Make the Settings interchangeable!

[ChrisDolan]

If I have to reconfigure ONE more window manager to do focus-follows-mouse-sloppily, I'll have to change my email address to chris@loonybin.org.

I advocate an XML-based prefs format that is shared by many WMs, with less-capable ones simply ignoring the features they can't understand.

In .wmrc:

<keyboard>
<focus>
<follow/>
<sloppy/>
</focus>
<repeat>
<speed value=6 scale=10/>
</repeat>
<clicksound value=false/>
</keyboard>

or something like that.

Re:Menus, Drag and Drop and Clipboards as well PLE

[rhavyn]

The X Clipboard and XDnD are both defined protocols which, unfortunately, Qt2 (and thus KDE2) did not follow. Qt3 does, so hopefully, the clipboard and dnd between Gtk and Qt apps will work correctly.

Why not 2 existing instead of 1 vaporware?

[Eryq]

Inventing a whole new theme will require a lot of time and arguing about how it should look/work/etc. Don't go there. Instead:

IMHO there should be a GNOME/Gtk theme called "KDE" which exactly mimics the most-default KDE theme, and a KDE/Qt theme called "GNOME" which does vice-versa.

Unless of course this is a stpuid idea, in which case, forget I brought it up...

The user perpective / The developer perspective

[Ogerman]

Right now, KDE has an enormous lead over GNOME with ordinary users. The reason for this is pretty simple: KDE has a unified web/file/desktop browser that is fast, clean, intuitive, and full-featured. Non-technical users, especially prior Windows users, have come to expect this in an interface. They are used to a high degree of object oriented design and a consistent 'look' to the interface. Nautilus is highly lacking in this regard. It is very slow, has clunky web browsing support, is very lacking in basic features / configurability, and does not have a clean unified feel. Because of this, users must switch back and forth between Nautilus and Mozilla/galeon. And Nautilus downright sucks for any sort of GUI file management, thus requiring yet another utility if one desires such functionality. So now you have Nautilus for your desktop icons, Mozilla for web browsing, and something else for file-management. And none of them talk to each other.

In my opinion, if GNOME and KDE want to cooperate in the future, they need to decide on a single object model, a single RPC/IPC mechanism, and a single clipboard system. Judging by KDE's proven success in this area, it only makes sense to use it as the standard rather than break both and start from scratch. Unfortunately, it seems the GNOME people are extremely stubborn about switching to C++. The reason of course, is historical: the old rule of thumb that C is more efficient than C++.. or more accurately, that C++ compilers are slow. This is beginning to change, and no doubt, g++ would be improving much faster if more people were using it.

Or we can just keep going about re-inventing each others' wheels. Pretty silly if you ask me. One other note, the human aspect, is another advantage KDE has. GNOME needs some better unified leadership and goals. Compare, for instance, kdelibs to the dozens of library packages needed to compile GNOME. Having unified releases is a good thing for everyone.

Re:The user perpective / The developer perspective

[Ogerman]

Amazing. Two morons modded the parent down because they didn't like my (valid) opinion that Nautilus sucks. Lamers. Well, here you go, you idiots: a real troll. Go ahead and waste your mod points on this one too! ahhahaa.. that's one less point you'll get to hurt another thoughtful post because you don't agree with it! ahhahaha.. Mod this down!!! GNOME sucks!!! KDE RULEZ!!! Do you like this approach better?

I rate all negative moderations as unfair.

Why a common theme

[maggard]

Lots of folks are crying: "I want my custom desktop" and "This will stifle innovation".

Why?

Nobody is suggesting anyone be locked into these. Nobody is suggesting these be graven into stone never to become v.2 as progress marches on.

What this would do would be provide a common basis for new folks, a baseline for support folks, a universal look for screen-shots and documentation. If along the way some solid UI design were applied, usability testing done and minimal esthetics incorporated then so much the better.

Tweak away, replace, bend, fold, spindle, mutilate. But at least folks who are bewildered and lost could go to a common default and see something reasonable and trivially relate it to the documention or support folks. A simple menu option of "Default" would do wonders and all the better that it be consistant across toolkits.

Of course the next question is "What?" Here's where I think a good process of involving folks who are knowledgable in this area along with things like testing and feedback and skills in UI-standards-making would be incredibly valuable. Nothing against the coders but frankly, and many would agree, many desktops today are bad Windows reimplementations, wannabe-MacOS X looks or terrible pistaches of any number of good-ideas-running-into-eachother. A committee of KDE and Gnome AND others working on a timeline with a budget and a set of goals and opportunity for community feedback would be ideal, something with conflict-resolution built in from the beginning.

And if it stinks up the place it gets ignored. Or fixed in v.2. But at least we'll have taken the chance of a basic common UI gtting a shot and possibly accruing the benefits that would accrue from such. As for those looking to use something different, more innovative, more complex, more suited to them - go right ahead.

Not quite.

[Doktor Memory]

Actually, the X has a fairly sophisticated clipboard model, maybe a little bit too sophisticated. [...] Also read this for a backgrounder about clipboard and X: http://www.jwz.org/doc/x-cut-and-paste.html

Gee, that's nice. Care to explain how to make that "sophisticated" clipboard model work with something other than plain text?

Re:Not quite.

[dietz]

Gee, that's nice. Care to explain how to make that "sophisticated" clipboard model work with something other than plain text?

It's explained (high-level) right there in that same article that you didn't bother to read.

Better luck next time.

Mac UI

[maggard]

Look at how little the MacOS interface changed before OSX

Really? Actually there were many changes into the Mac UI. There were watershed events like the introduction of the Platinum look but along the way many tweaks were rolled out also:
(apologies if I don't know the proper terms)

• Collapsable "Windowshade" widget and action
• Drag-to-a-bottom-tab windows
• Tear-off task switcher
• Pop-open folders for drilling-down
• Navigation Services
• Heirarchical Apple Menu
• The still-born Themes & sound-sets
• The applet-bar (blanking completely on the name)
• Adoption of Alt-Tab for task switching
• The fully keyboard-navigatable desktop

While they weren't jarring in-your-face changes they were all significent changes and certianly not symptomatic of a moribund UI.

Re:Mac UI

[zhensel]

Yes, there were a heaping handful of incremental changes that admitedly vastly improved the UI. The fact remains though that the original UI was painstakingly designed so that it didn't need a really major revision until just now. I don't think that anything exists like that now for Unix (unless you count work heavily derived from an existing UI).

I suppose that my comments on the Windows and Mac UIs could easily be seen as saying that they are horribly outdated, but that's not what I intended. I meant that if you decide on a standard now, you'd better be willing to stick with it for five or more years. It should have the extensibility that the win95 and original macOS UIs had as well so that it could evolve over time yet still retain the same basic methods for achieving different things - the same metaphores if you want to follow Stephanson...

Good on RMS...

[StarTux]

If I said this or most people saying this they would have most likely been ignored.

Good job RMS,

Matt

No reason for KDE/GNOME to depend on Qt/Gtk+

[qweqwe]

The main reason for the split, is the widget set dependence of GNOME and KDE. Until this issue is resolved, deeper interoperability issues won't likely be resolved.

You *should* be able to use Qt write a complete GNOME application that obeys GNOMEs theming rules, uses Bonobo, GConf and other GNOME technologies.

You *should* be able to use Gtk+ write a complete KDE application that obeys KDE's theming rules, uses KParts, DCOP and other KDE technologies.

Yes, it may be *easier* to write KDE applications with Qt, and GNOME applications with Gtk+, each desktop/platform shouldn't be *tied* to these widget sets.

That's not the way it works now. At the moment, I believe that GNOME's technologies (at least the one's in GNOME 2) are more decoupled from the widget set than KDE's. For instance, it's possible to write a Qt application that uses GConf2, Orbit2, GStreamer, and Bonobo2 without linking in any Gtk+. If you *really* work at it, you should also be able to integrate with GNOME's accessibility framework by hooking Qt components to the appropriate ATK+ options. That's a fair chunk of GNOME already. But there are many other GNOME features that Qt applications can't take advantage of.

Re:No reason for KDE/GNOME to depend on Qt/Gtk+

[loopkin]

work is already in progress.

KDE can import GTK/GNOME themes.
And, the other day, launching my favorite GNOME app using KDE, the systray icon/menu went in the right place.

Well, you may smile at such things, but it works, and it's a beginning....

This happened a long time ago.

[dan the person]

KDE has supported GTK themes for a long time now.

http://www.kde.org/announcements/k3c-announce.ht ml

In addition to native KDE2 themes, we are pleased to announce that KDE now supports pixmap GTK themes. For importing a GTK theme into KDE, you just need to use the 'klegacyimport' wizard, available as a little standalone GUI application. However, while GTK themes are displayed faster and more efficiently than even native GTK itself, we do not recommend using this format for creating new themes. Theme developers should prefer KDE2's native widget theming which yields superior results both in terms of quality and speed. A nice HowTo and some documentation on KDE2 theming is available here.

Obligatory Remark

[TeknoHog]

'It's kuite kool,' said RMS. 'Take it!' Miguel received it on his shrinking Palm: it seemed to have become thicker and heavier than ever.

.....

Ash desktop durbatuluk, ash desktop gimbatul, ash desktop thrakatuluk
agh burzum-ishi krimpatul.

The change in RMS's voice was astounding. Suddenly it became menacing, powerful, harsh as stone. A shadow seemed to pass over the high Sun, and the porch for a moment grew dark. All trembled, and the Gnomes stopped their ears.

Why do you write code?

[GileadGreene]

Even more interesting than the KDE/GNOME thing is what you find when you dive down a couple of follow-ups in the email chain. Here's an RMS response to a part of a post explaining why the poster thought that the KDE/GNOME cooperation thing wouldn't happen:

Uraeus linuxrising org:
> And as the free software saying goes,
> a itch that don't itch a developer,
> doesn't get scratched.

RMS:
That was said by Eric Raymond who belongs to another movement, and it reflects the spirit of that movement. The spirit of the free software movement is to do projects because they are important for the community and for our freedom. They don't have to "scratch an itch".

Is this really an accurate portrayal of (one of) the differences between "open source" and FSF sanctioned free software? Open source developers are out to do what's best for themselves (and maybe helping out others as a by-product by releasing their code), while free software developers are motivated only by love of their fellow (hu)man. I'm not really heavily involved in either development community, and didn't realize that there was such a sharp divide (if it actually exists outside of RMS head). Can some free software/open source developer types weigh in on this? Why do you write code?

STL.

[rjh]

STL. STL. STL. And I'll say it again, STL.

G++'s STL blows. It's so substandard that it borders on the unusable. Take the vector<> as an example. One of the big wins with vector<> is that it can be used as a bounds-checked array. All you have to do is use the appropriate method--or derive a class off of vector<> and override operator[] appropriately--and stack smashes are a thing of the past.

Whoops. G++'s STL doesn't support the vector.at() method, which is necessary for bounds-checking.

There are all sorts of substandard crap in the standard G++ STL. It's gotten to the point where I've flat-out given up on G++'s STL, and am using STLport 4.5.3 instead.

If you want to improve my C++ experience, pay attention to the STL.

Re:Menubar

[JabberWokky]

KDE has done this since before 1.0.

excessive effort placed on "skinnable interfaces"!

Personally, I despise skinnable interfaces, but like KDE's style and window decoration abilities - because they are actually code, and change the way the interface operates. It's not just the look, it's changing the entire way the UI interacts. That's also why "themes" will never be totally portable between the two DEs - they aim for different areas in terms of speed, flexability and ease of creation.

Incidently, I started a KDE and Gnome meta-theme project a few weeks ago. I currently have a mapping file for icons for Gnome to base, and base to KDE, allowing for conversion of all Gnome iconsets to KDE. That's why all the Gnome icon sets have been popping up on KDE-Look.org under my account.

Right now, things don't map on a 1:1 basis. I'm currently documenting and building a base set of utilities for post 3.0 and 2.0 versions of the DEs, with an eye towards a universal icon theme being achievable shortly as the first step towards artwork interoperability. Jakub's response has been encouraging - it is his artwork that I'm futzing with to test and work with, and his emails to me have been positive. I was nervous about moving Gnome icons to KDE, figuring I'd be slammed by small minds on both sides of the fence, but response has been neigh-universally positive.

If you are interested in this project (which entails lots and lots of painstaking "creating documentation from what exists") then feel free to contact me.

--
Evan

Other areas where tis will help

[Nailer]

• Menus. Red Hat's /etc/applnk and Debian's menu system already solve this problem to a limited extent, but not everyone (or anything close to it) uses these mechanisms. One directory, in /etc (read the FHS as to why) should be used by both. Flags to hide certain things (gnome control center) in certain environments should be a part of this.
  
  
• Display manager session types. As someone who manages a large amoutn of packages for my office, it annoys me that I have to repackage enlightenment, twm, pwm, qvwm95 and everything else to add the correct entry for the sessions in two locations, one for KDM and one for GDM (our office uses GDM, but I like doing things properly).
  
  
• Mime types. File type editors in both desktops are already tragic enough without adding the hassle of having to add apps twice. Again, packagers must account for both sets of configs
  
  
• Applets. Less of a concern, but its hard explaianing to users that you can runevery GNOME app you want in KDE, except for the applets, which won't work in the KDE taskbar (and vice versa).
  

We Had To

[cluge]

"....we had to attack it [KDE] to make people aware of the threat"

The attacks were vehement, nasty and for the most part unwarranted. I never saw KDE as a "threat" and considering it a threat did nothing but waste a lot of energy (IMHO). Especially considering where the software was headed and the fact that EVERYONE KNEW that QT would have an open source license eventually.

While I endorse the idea of some interoperability I tend to take a step back and look for other motives. Members of the KDE team have long tried to get some interoperability between the 2 desktops and were repeatedly rebuffed. It's a nice idea, but considering some of the mudslinging thats gone on over the past few years, I'm with holding judgment.

Hopefully the axe is buried, considering there are some admin's out there running open relays because it was the right thing to do in 1990, I expect to see it dug up a few more times. That's the problem with religious wars where you unfairly vilify the enemy it makes it hard to work with them when they are on your side. I'm glad some people are starting to consider the big picture.

Re:How I think it should read

[dvdeug]

RMS wrote: When Qt was non-free, KDE was a danger to the community

The way I read it as, not having been under a rock for the last decade is: When Qt didn't use my specific licence, KDE was a danger to the community.


He meant exactly what he said. Part of communication is understanding where the other person is coming from, and not taking potshots at others because they believe in different things than you. RMS believes that it's important that people use all Free software, and a huge project of Free software that depended on non-Free software was a threat to that. He did what he felt he had to; deal.

I'll keep doing it for as long as he wants to be in charge of other peoples projects. ... I don't think a monoculture is the way to go

Why, when RMS makes comments on what direction GNOME and KDE should go, "he wants to be in charge", but you can make all the comments you want? He has the right to make his opinion known, as do you, and people can listen or not as they want.

There is an old chinese saying

[Pac]

"Don't feed the troll"...

Just look at his username. What good can one get discussing anything with such people?

On the other hand, as a Linux desktop user (Mandrake 8.1 but seriously considering Suse), I would say that you are going a bit too far when you say Linux is easier to use than Windows.

For a very special kind of user, the kind you have to baby-sit be them on Windows, Linux or Mac, maybe. But I would really love to have everything working from the start.

Installation should tell me "Look pal, we don't support your funny soundcard, go buy something usable". Which I eventually did, but I shouldn't have to cope with a system that thinks some sound is being played when it isn't.

Apart from StarOffice, and I hate 5.2, all other pseudo-Word software couldn't cope with lightly formatted Word files.

But then there is development, and Linux is a far superior, controllable platform if you know what you after. And of course, Mozilla gets better each night.

I guess what I am trying to say is that Linux today is not always the best solution for the desktop, but it is amazing how far it came in, say, two years (if memory serves, two years ago it was still quite easy to burn a monitor misconfiguring X during installation - today distros will configure it automatically). I believe that Microsoft is even lending a hand, by changing its licensing policy. The corporate world will be looking very hard at Linux for their millions of desktops.

But there is still a long way to go before Linux desktops can show the maturity one sees in MacOS X, for instance.

Unified Clipboard

[Afrosheen]

Version after version, distro after distro, app after app, I still don't have a unified clipboard to simply copy and paste between apps.

Give me a unified clipboard, or give me death.

Re:Unified Clipboard

[StrawberryFrog]

Version after version, distro after distro, app after app, I still don't have a unified clipboard to simply copy and paste between apps.

You may find this funny, but I became a Linux coder last years after a long time on windows. To me this clipboad fiasco is both frustrating and symptomatic of what's wrong with windows.

I'm mostly coding using xemacs, but to ward off flamewars I also drop into vi from time to time.

First, what's wrong:
There is no unified clipboard. I can to Ctrl-k ctrl-y to cut and paste in Xemacs, but it doesn't work across different xemacs windows. I can use the Xemacs toolbar buttons labeled "cut", "copy" and "paste". These do work across xemacs instances, but do not interact with the ctrl-k ctrl-y buffers, and if I should close the source window before pasting, the copied text vanishes. Then there is good-old x-windows swip & middle-click. This works in most everything, but is completely unrelated to the other two mechanisms. I use 3 different, incompatible, uninteroperable clipboards on a daily basis. Unix = simple orthogonal tools my arse.

A solution:
Have a service/damon that stores ckips. It doesn't need to be part of any gui. It doesn't need to be linux-specific, it can be generic unix, and run on BSD too. It just needs a simple API (yes, like windows has) that supports multiple clips, perhaps taged by creating app and data type. Give it lots of config options like max size & number of clips to store, if it should persist them on HD when the system shuts down, query functions to find out what's there etc.

This, for me would be great. Apps that guard thier own clipboard jeolously could use thier own space on the clip server. Apps that want to look at other clips could do so. You could cut in KDE, restart and paste in Gnome.Heck, you could cut in emacs and paste in vi. It would be nerdvana. Why is this so hard?

Re:Unified Clipboard

[StrawberryFrog]

The main reason why you run into multiple incompatible mechanisms in software like Emacs is that the software started as a TTY application,

Right, and if clipping was recognised as nothing to do with a GUI, just a bit of data storage, then TTY apps could use it.

It sounds to me as though you are starting multiple independent instances of Xemacs to edit multiple files - I think that you will find that running a single Emacs process and opening multiple "frames" to edit multiple buffers is the correct way to go.

I've seen those frames and don't like them much. If you don't have a windowing system, then I suppose that they would be a necessary substitute.

The basic problem is that different instances of the same program, let alone different ones, don't play nice together.

Re:To Hell with RMS

[Ian Bicking]

So he argued against KDE, in favor of GNOME, a truely Free alternative.

And he actually tried to work with KDE before starting Gnome. Things like Harmony could have made KDE free without Troll Tech's help, but KDE developers seemed to choose not to work with RMS, and rebuffed his attempts at peace.

That's old history now, but people should know that RMS didn't go storming off at the first sign of conflict.

The reason...

[Kymermosst]

It may have been mentioned before, but the real reason is that RMS can't stand to not have the FSF in charge of anything that has the GPL as a license and is also successful.

This is NOT flamebait, it's the truth, at least as I see it. When a GPL'd project is unsuccessful or new, RMS dismisses it along the lines of "this will substitute until we finish" whatever. When it becomes successful he's right there trying to claim it. Such as the whole GNU/Linux thing. I hate to break it, but GNU got a boost with Linux, not Linux a boost with GNU. It could have just as been the BSD tools that ended up in the first Linux distros, and there are still people working toward a "low-GPL" linux distro.

What RMS is looking for here is a merge, or a way to give the edge to GNOME.

Don't get me wrong, GNOME is a great project, but so is KDE, and we NEED this competition. It's necessary for innovation, and we should NOT let RMS mangle KDE into one of the FSF's projects.

My question is, when he fails to get control of KDE in this way, will he instead insist on calling it GNU/KDE because it builds on top of GNU tools?

Don't moderate me flamebait because you disagree with my opinion. You'd do better to rebut my argument instead.

This thread is getting old.

[Pope Slackman]

If anything, there are too many standards.

Too many APIs, yes, I would agree.
Standards? No. I think the last attempt at standardizing X toolkits was Motif/CDE.

it would be hypocritical for communities founded on freedom and openness to embrace the principles of oppression and design by fiat which underlie your suggestions.

So standards and guidelines are fascist now?
Whatever. If oppressive standards build things like global networks, I'll be happily oppressed.

If a system has a dozen redundant modules, then any bloat is the administator's fault - he or she did not remove the extra ones

How is having at least 4 ways[1] to create a pushbutton object "the administrator's fault"?
It's not like I can take gtk_create_pushbutton()[2] from the GTK library and replace it with Qt::Button or somesuch and expect the GTK program to run.

Perhaps you are thinking of the associated pixmap libraries or desktop environment libraries.

Well, they're kinda, like, required for most every app, so of course I included them.

That you can run them alongside one another is only meant to be a charming illustration of the community spirit and excellent engineering at work.

Excellent engineering.
That's why programs crash when you try to do complex things like "paste".
This isn't engineering, engineering implies well thought out design.

C-X C-S
[1] Gtk, Qt, Motif, Athena... (Fltk, FOX, OpenLook, Tk, XForms, WxWindows...)
[2] If that were a real GTK call, it'd be about 35 characters longer. ;)

Grand Config File Parser???

[runswithd6s]

You know. This has always been an interest of mine, unifying the handling of application settings to configuration files through a generic, modular, and extensible structured data parsing interface. Ultimately, one should not need a grand, "swiss army knife" parser that does everything, you just need to be able to add tools to the "knife" as they are required. Of course, we would want to do this all without the use of the dreaded "metadata file".

Quick example. Let's say I write an application that uses an *.ini style config file. There are a number of generic function calls that I'm going to want to make through the program, one of which might be readconfig(file*,parser*,confdata*). The challenge is coming up with something simple enough to make it easy to use while flexible enough to support structured data trees.

Disclaimer: I haven't put a whole lot of thought into this. Such a level of API may be useful, but in some cases may not be pratical to implement. Regardless, it is a fun problem to stew over.

Could be good

[nagora]

If it reduces the number of teams copying MS's mistakes from two to one. Think what useful work the other team could get on with. I vote for a good DTP package.

TWW

They both need a theme overhaul

[micahjd]

If the goal is to make KDE and Gnome/Gtk themes compatible, I think the right way to make this happen would be to create a new theme system that could be compatible with both systems.

There are several exciting theme systems out there now: both PicoGUI's theme system and Enlightenment's Ebits are theme systems based on a database, capable of storing data for the windowing system, the widget toolkit, and all the applications. If a system like this were implemented in the major GUI toolkits and window managers on the desktop, it should give a way for all applications, toolkits, and window managers to be consistant and completely under the user's control.

unrealistic

[streetlawyer]

I'd probably say that the best idea would be for some group to go and dedictate a year or so to making the be-all-end-all of interfaces.

Yeh, designing the be-all, end-all interface would only take about a year for a group of hobbyists, wouldn't it? Because basically, all that UI-design stuff is just art fag stuff which is no problem for "hackers" who are "often highly creative artistically" ([c] Eric Raymond). Those psychologists, ergonomists and designers can't be contributing anything interesting, because they don't have computer science degrees. Hell, "psychology" even sounds like it might be a liberal art! All that's needed is for some "engineers" to set up a mailing list and swap ideas and soon we'll have something much better than the Mac. I mean, c'mon people, this isn't exactly kernel hacking.

Bill Gates must love hopelessly overambitious, ill-thought-out "conquer the desktop" efforts like these.

GNOME and KDE have the same problems

[Ukab the Great]

Yes, in this whole GNOME vs. KDE thing, what get's lost in the shuffle is that both groups of developers really don't have much of a background in usability design and both make a lot of GUI design faux pas on the basis of "Microsoft does it, so it has to be good". People who actually know about designing usable interfaces know that, contrary to popular belief in the linux community, Microsoft is one of the most profoundly incompetant companies on the planet when it comes to designing usable interfaces. They just keep doing so many stupid things. And they can get away with it for exactly the same reason they can get away with all those bugs and security holes: when you've got a monopoly and the hearts and minds of hundreds of thousands of dim-witted CEO's and IT managers, you can do close to anything you want.

Back to the GNOME and KDE, I seriously doubt that either most GNOME or KDE hackers know what Fitts' Law is, and many would say "bullshit" or "it's a matter of opinion" if you tried to intelligently explain it to them. In the current open source desktop movements, there's an amount of stupidity and unknowledgableness that would never be tolerated with something considered as sacred at "the kernel". It's a double standard, really.

Of course, the beauty of open source is that if something does something really really stupid, you can fork of their project and do your own non-stupid thing.

Am I the only person...

[ChaoticCoyote]

...who doesn't understand the fascination with "themes"?

I can think of many areas of cooperation between Gnome and KDE -- and themes are pretty low on that list. This isn't a troll, but an honest question: What's so important about themes?

My computers are for programming, writing, and web browsing; why would I waste CPU time and memory on fancy wallpapers and pretty rounded corners and all this "stuff" that fascinates some people so much? If I want pretty pictures, I'll frame'm on the wall, where I can see them when the computer is off!

Can someone explain theme-mania to me, please?

Single Menubar - Reasons

[johnrpenner]

if we're going to standardize, it would be a good idea to eliminate uncessary ambiguity in the interface by standardizing on a Single Menubar.

reasons: http://home.earthlink.net/~johnrpenner/Articles/Si ngleMenubar.html

Re:That incompatible clipboard is because of.. SO?

[praedor]

I might actually use mozilla if it would properly integrate into my system. It has its own look, theme, etc, that is at TOTAL odds to all my other apps.

If they could fix the clipboard crap, they should also fix the Mozilla-in-its-own-theme-world crap too.

Re:Menubar

[johnrpenner]

Single Menubar - Reasons

A SINGLE MENUBAR AT THE TOP OF THE SCREEN that changes according to
the current context (window) instead of a menubar for every window.

Setting this as a User Default will improve Linux's ease-of-use.
Placing a single Menubar along the top of the screen:

1 - Makes it faster and easier to hit.
(no mouse overshoot to slow things down)

2 - Eliminates clutter in the interface.

3 - Reduces ambiguity (and hence - user error).

regards,
john.

Re:Layering GTK and QT!

[spitzak]

You seem to be confused. The Win32 api that Qt uses is approximately equivalent to the Xlib api that it uses on Linux.

Though the Win32 api provides a "scrollbar" and some other widgets, Qt does not use them. Nor does any high-level toolkit on any system other than MFC.

If you ever tried to implement a toolkit you will quickly discover that it is vastly easier to write a widget from scratch than to try to adapt your interface to an existing interface. It is also vital if you are interested in cross-platform compatability to do this.

Re:Menubar

[spitzak]

Unfortunately such a menubar does not work when you have point-to-type focus. Point-to-type is also a vast improvement in efficiency (so much so that I have NEVER seen anybody who uses it go back, even on Windows machines where you can turn it on with a registry setting).

Possibly moving the focused windows up to the top edge so that they are joined onto the menubar, or some kind of hysteresis so that if you drag fast enough across the gap the focus does not change, or some idea nobody has thought of, would solve this. But until somebody does this I doubt you will see much interest in top-of-screen menubars from either the Linux or Windows advanced programmers.

Re:That incompatible clipboard is because of.. SO?

[praedor]

I don't normally use mozilla because:

1) it is STILL huge.

2) I select a KDE theme and style because I want and like my system to look a certain way - that I set it to look like. Mozilla ignores this.

This is how M$ wrongly handles things. On Mac OS, for instance, all PROPER Mac apps look the same. Their scrollbar buttons are all consistent and PROPERLY placed together at the bottom right of any window. No unnecessary and stupid mouse dancing to select the a scroll arrow. In comes IE on the Mac, done ALL wrong with the damn buttons all over bejesus - scroll buttons top and bottom like some retard designed it and no way to correct it.

If a user on a Mac, Windoze, or Linux sets up a theme/style, then all apps that want to play there should obey the user's designs. The USER knows better how things should behave and work on their computer...not the coder.

Re:That incompatible clipboard is because of.. SO?

[praedor]

Perhaps it SHOULD use QT (and GTK and anything else too). The GUI should be totally separate and divorced from what it does internally. Let there be multiple frontends with the same core. A UI isn't the app, it is just the means of communicating with the app.

This is one of the areas where M$ goes wrong.

Well then use the current version, doofus.

[devphil]

GCC 3.0 has been out for almost a year. All the problems you mention have long, long since been solved. Among other things, the library was completely rewritten (the old library predates the standard).

Whoops. G++'s STL doesn't support the vector.at() method, which is necessary for bounds-checking.

You're using version 2. Version 2's library was written before they finished tweaking the C++ Standard. So you blame the GCC people for not being able to tell the future?

Re:Well then use the current version, doofus.

[rjh]

GCC 3.0 may have been out for almost a year, but keep in mind that 3.0 is only almost usable. When I tried 3.0, soon after it was released, my average compile time increased by a factor of five. Compiles that used to be able to be done over a lunch break now had to be postponed until the end of the day and run overnight.

Add into that the fact that GCC 3.0 broke multiple inheritance (ask the KDE people how they liked that--you can't build KDE with GCC 3.0), and GCC 3.0 was never a realistic option.

There's a reason why not one single distro ships with 3.0 as its default compiler.

Re:Well then use the current version, doofus.

[devphil]

As for compile times, yes, there were problems -- they were known problems at ship time, largely due to the inlining heuristics. Those were fixed in a point release, mostly, and the major changes to fix the reamining issues went in 3.1.

The KDE folks were making bad assumptions -- there's a long thread in the main GCC mailing list archives. Basically KDE wanted to violate the One Definition Rule and have the compiler/linker/loader read their minds. Can't have your cake and eat it too, etc. There were also MI bugs, all of which I /think/ have been fixed, but I haven't checked lately.

I don't blame the distros for not shipping 3.0 as the default. (I would've made the same decision in their place.) I /do/ blame people for saying that "GCC's default library implementation sucks" when they clearly haven't investigated the problem.

Re:How I think it should read

[Mandelbrute]

Why, when RMS makes comments on what direction GNOME and KDE should go, "he wants to be in charge"

He got on the board didn't he? Of course he wants to be in charge, he's very up front and honest about it, and I'm sure he doesn't mind a bit of criticism. You may have got a little confused about the whole "liGNUx" and "gnu linux" thing, he didn't want to be in charge, he just wanted to rename it to call attention to the GNU project.

Why did I write these comments? I'm just a bit miffed when he states opinions as if they are hard facts eg. "KDE was a danger to the community". In my opinion, history records that it wasn't - I think in RMS's opinion it was a potential danger, but that still didn't make it a real danger.

Dunno.

[rjh]

The version I heard was that for a particularly esoteric set of multiple inheritances, GCC would produce incorrect code. I haven't verified this myself, though, so I can't contradict you at all.