Slashdot Mirror
Writing Apps for GNOME *and* KDE?
Dr. Tom asks: "I want to write an application that will play nice with both the GNOME and the KDE desktops (and possibly others). Without having developed anything for either, and after glancing through some of the docs, it seems like GNOME apps need to be written with GTK+ while KDE apps need to be written using Qt. Since I don't want to write my app twice, I'd like to know if there are any tools/abstraction layers that I can use to get some desktop functionality without having to worry about which desktop I'm running on. I expect this problem to have relatively wide interest as I notice quite a bit of duplication of effort among the different desktop applications (Knotepad, Gnotepad, Kcalendar, Gcalendar, etc.). It would be nice if some of that code could be shared -- or are desktop apps doomed to be tied to a particular desktop?" I certainly hope not. Applications which work on both frameworks are a necessity if Linux is to become a choice for the general desktop user.
If I understand correctly, what you are asking for is a C++ wrapper library that is sufficiently high level to encapsulate just about any GUI/widget toolkit around, Gtk+ and Qt in particular. Plus you want a high level common interface to the features provided by KDE & Gnome that are independent of GUI/widget toolkits. That's a difficult request. There are C++ wrappers for Gtk+ that could serve as a basis for creating high level unified widgets. However, Gtk+ and Qt use different mechanisms for handling events, so it would be quite difficult to create common routines for event handling without eliminating a lot of the flexibility and features each toolkit offers. After creating a library that sufficiently encapsulates both toolkits, you will need to create another library to provide the services of the desktop environment. In particular, you'll need a library to cover the differences in Corba implementations, window manager integration, etc. It could be done, but it won't be trivial. Also, it will add extra layers of crud slowing your application down.
At this point in the desktop wars, I suggest that you choose one platform and separate all of your code that deals with the GUI toolkit, window manager, Corba, drag-n-drop, etc. into a separate class library. That way, you can always re-implement those classes if you switch environments.
If you write the app (I mean the meat of it, not the flashy stuff) such that the gui for the thing is not implicitly assumed to be so and so toolkit, etc. then you achieve a great deal more portability.
Take a generic calendar app: the logic for manipulating time, adding/deleting events, etc. exists in one code base. The gui code exists somewhere else. The gui code both drives the app and displays changes in state. In this application the non-gui code is the model and the gui code is the view/controller. Changing guis afterwards would be (much) easier.
There used to be a time when unix apps were command line first with maybe a gui slapped on afterwards. This was good because the apps in question could be scripted (e.g. integrated into a bash script). The gui would be for human use only.
I'm not suggesting that all apps be written such that they are unable to directly manipulate their gui aspect; some apps are inherently graphical (Gimp, ee, etc.). What I am suggesting is that this approach to program architecture is better and is applicable to more than just gui/domain separation.
BTW, in case you are unaware, this MVC stuff is old and very well proven (Smalltalk-80) and seems to be making a comeback with Java Swing.
Of course Gnome and KDE offer more than just gui frameworks but the lesson remains the same.
Sincerely,
an aging Smalltalk bigot
Dr. Tom's question is a very pertinent one. Linux is falling down in a bad way on the desktop due to the plethora of UI's being used in appliactions and the absence of standards. The appeal of the Mac and Windows desktop is that drag and drop, cut and paste, menus, etc. work consistently. When you get to Linux nearly every app is using different UI standards and conventions. Allowance for UI innovation is a really good thing but total chaos where every application has a completely different UI is fundementally bad. Its also a severe drag on Linux application development that every new application development team has to spend large amounts of time tearing themselves up between Qt, GTK, FLTK, Amber, and between C and C++ and between KDE and Gnome. The Mac and Windows developer doesn't have this divisive problem or at least its much less severe. At the same time there is a lot of programming time and talent spent developing the same functionality between KDE, Gnome, Qt and GTK. Its a waste doing everyting twice and spending time trying to make the two implementation cooperate. There is something to be said for competition but I doubt that the competition between Qt and GTK is beneficial to the community any more. I've heard rumour that GTK and Qt might be working to interoperate with drag and drop but the last time I tried it they simply didn't. To have a creditable desktop you need to have all the MIME types consistently implemented so, for example, dragging an image from a desktop browser, whether it be Gnome or KDE, into an app that handles images works right. Last time I looked Qt had far and away the best drag and drop implementation. It was best because it was very easy to understand and implement. GTK wasn't. GTK and GTK in Gimp was barely hanging together as far as drag and drop goes. All of the burden was placed on the programmer and there was too much opportunity to diverge from consistent behavior. The same thing can be said for cut and paste. It has to be consitently implemented in all apps with maximum ability to cut something in one app and paste it in another. The best way to acheive these goals is one consitent API that hides much of the complexity from the programmer and encourages them to implement a standards conforming UI. I wont weigh in if its GTK or Qt since this is a religious war between the C and C++ camps. This is not a question of whether an app runs if its using Qt or Gnome and running on Gnome or KDE. Its a question of whether the user is getting a predictable and productive experience from all the apps they use on their desktop.
Well, wxWindows is a pretty cool library, and it's GNU (well, the author made some slight optional modifications to the licence to make it sort of a mix of LGPL/BSD).
Coding in C++ is much cleaner and wxWindows generates code for GTK+, QT, Motif, Windows, Mac, and ports are in progress (I think) for BeOS. Sure, it doesn't support Gnome (as a desktop), but it's a great step in the good direction, maybe Gnome support will come later if it's possible.
Another cool thing about wxWindows is that the syntax is very familiar to MFC, so Windows applications could be very easily ported to the world. I know this isn't happening right now, and I don't understand why wxWindows doesn't have that much visibility. (fear of C++? Unstable? Please correct me.)
Matt
Well, you can write programs in either GTK or Qt and both KDE and GNOME will have no problem running them. However, to take advantage of the special functionality of the desktop environment requires you to code for that desktop's specs. You can use any toolkit you want, but your "made for KDE" program won't work as well under GNOME unless you use a bunch of #define's to provide the equivalent functionality (and write all the relevant sections twice, once for each environment). That could quickly get tedious.
Hopefully they'll get their acts together soon. Until then, I'd recommend not writing for either one.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
There are, however, ample other opportunities for other aspects of interoperability that generally have merit.
Many UNIX applications have traditionally used data formats as a mechanism for interoperability. Many applications know how to read things like mail and news spools, which provides interoperability.
GNOME and KDE both make fairly extensive use of XML, which may, with some cooperation on DTDs, provide opportunities to interoperate in a cooperative manner.
One of the traditional strengths of UNIX has been the use of common sorts of protocols. The IETF has been involved in defining common protocols for things like news and mail that allow diverse mail and news servers/clients to interoperate. And just look at how many web server implementations there are out there...
GNOME and KDE both include CORBA implementations that represent a well-defined, intentionally-interoperable way of defining protocols for client/server applications.
The use of this approach requires splitting applications into "client/front end" portions, which may be GUI-specific, and "server side" portions, which should be designed to be altogether independent of the GUI.
In effect, people should be doing design efforts to build useful "services" that are entirely GUI-independent; that will provide code that will be usable with both GNOME and KDE.
If you're not part of the solution, you're part of the precipitate.
Look at CDE Price List and Motif Price List.
I'd guesstimate that the cost of CDE is on the (binary) order of $150/seat; this could readily vary between $80 and $200 based on how the terms are interpreted.
On 10 million Linux users, the mass adoption of CDE would result in a Linux distribution having $0 in licensing fees for Linux, and something around $150 for CDE/Motif licensing fees.
I can't imagine the flame wars that would come out of trying to cope with the per-user package licensing fees that are associated with CDE.
If KDE and GNOME are "divisive," CDE is not "inclusive." It is, instead, exclusive.
If you're not part of the solution, you're part of the precipitate.
That is my strategy. I write my application as a library, with no user interface. This means it can be easily added into other applications, and that it can have many different front-ends. Each front-end is a main() program, which links your application library and some UI library (Gtk, Qt, curses). It makes it easier to divide work, as different people can be responsible for each front-end.
1) You could write the code in a way that takes out the toolkit-specific stuff, and puts that in a seperate dynamically-linked library. Then, just write two such libraries - one for Gnome, the other for KDE. Install the appropriate .so for the system you're using.
2) Conditional execution. This comes in VERY handy at times like this, but is a bit messy. Again, you have one binary that'll run anywhere, but this time you'd need both toolkits installed, as you'd have to link the main binary to both.
3) #ifdef specific code. This avoids needing both toolkits, is slightly tidier to write, and avoids the complex contortions needed to isolate toolkit specific code. Unfortunately, you'd then need to compile two binaries, and you're only marginally better off than if you'd two seperate applications.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
What I'm about to say may be offtopic for the general discussion, but I am quite interested in this thread.
- -----
I like apps that use the web, rather than apps you access from the web.
Embedding browser controls in apps, wether they be written using MFC, GTK, Qt, Swing or even Borland's VCL mean that you can have the best of both worlds.
You need not give away any of the cool bells and whistles that come with your favourite lib and you can also tie your app to regularly and easily updated data on the web.
MS Money is a great example of this, especially when you run it on a dedicated net connection, without all the hassles of dialup etc.
-------------------------------------------------
my blog: good times, man, good times
Why Don't you go tell Sun that Star Portal can't work. Tell them that you graduated from MIT and you know better.
And what about a web based mp3 player? Couldn't they store all the mp3 files on the server and stream to your local machine, saving you from having to find all the mp3s you want and archiving them yourself. Are you trying to say that Netscape doesn't have access to your sound card?
Try reading Tim O'reilly's new article on MS vs. Linux.
Joseph Elwell.
I think this post is flaimebait. I'd like to moderate it down one point, thank you.
/dev/null`;
But seriously, it seems that in order to standardize gui development between the two managers one would have to create a markup language for displaying. We could call it AML (for Application Markup Language). Then we would just need a powerful event driven scripting language - call it lavascript (for Linux Application Visual Access Scripting Language). At this point *real* processing could be done through a network connection - even routed to localhost. Via a networking protocol (call it TCP/IP) and it could connect to CGI servers to do the processing. oh wait. screw it.
sub isWar
{
my($enemy1, $enemy2) =@_;
if($enemy1 != $enemy2)
{
return 0;
}
return 1;
}
sub flameproof
{
`echo @_ |
}
while (&isWar(kde, gnome))
{
&flameproof("Joseph Elwell");
}
Both desktop environments claim toolkit-agnosticity (Gnome prefers GTK, KDE prefers Qt, but neither one requires a specific toolkit). The problem, of course, is that you'll have to write a lot of things twice and use #defines to figure out which to use.
I wonder if there's an abstraction toolkit in the works which could compile for either environment (sort of like wxWindows for desktop environments instead of operating systems)?
GNOME and KDE both *require* GTK+ and Qt, respectively, for all graphical apps.
From the Gnome FAQ:
"GNOME uses the Gimp Tool Kit (GTK+) as the graphics toolkit for all graphical applications."
I think this is in the KDE FAQ, too, I didn't have time to track the passage down, though.
Define "run over the net". Are we talking about, in effect, time-sharing, in which all the apps run on a server machine, and all interaction with them takes place via a browser?
If so, is it ipso facto the case that all applications
Note that citing some applications that can run in that fashion, or even that run better in that fashion, doesn't at all demonstrate either that all apps can, or should, be made to run in that fashion.
Given that a "GNOME program" is a program using GNOME facilities, how would compiling a GNOME program be possible on a system without the GNOME libraries and headers? That sounds sort of like wanting to be able to compile GTK+ programs without the GTK+/GLib libraries installed, or to compile X programs without the X libraries installed, or non-GUI programs without "libc" installed, or any programs without a compiler installed....
It sounds as if what you want are GTK+ programs (or Qt programs), not GNOME (or KDE) programs. Such programs do exist; to achieve the goal you want, you presumably want to encourage people to write more such programs.
Just out of curiousity, how would a "Web-based" word processor, or spreadsheet, or image editing program, or network packet capture and analysis program, or MP3 player program, or... work?
Is Yahoo Calendar such an application?
To which "X standard" are you referring? Xdnd is being adopted by at least three tookits, as far as I know (JX, where I think it originated; GTK+, which implements it in 1.2; Qt implemented it either in a late 1.4 release or 2.0, as I remember), but I don't think it's an Official X Consortium^H^H^H^H^H^H^H^H^H^H^H^HOpen Group^H^H^H^H^H^H^H^H^H^HX.org standard, as far as I know. Has it been adopted by X.org?
I think GTK+ 1.2 also implements the Motif drag-and-drop protocol (which may explain why dropping from the Motif-based Netscape to the GTK+-based GMC worked); what are Troll Tech's and/or the KDE team's plans to implement the Motif DnD protocol?
The interface to everything? A Web browser can replace all the stuff in KOffice, can replace the GIMP, can replace XMMS, can replace Ethereal, can replace....?
Yes, there are a lot of applications that can work as client-server Web apps; I have yet to see anything even remotely resembling solid evidence that all applications can be recast in that fashion.
Err, umm, go to which URL? The URL for the object being edited by the word processor, spreadsheet, image editing program, etc.? If so, how is this anything more than allowing URLs, not just file names, in a "File/Open" dialog box or in the app's command line? I'd hardly call that particularly "Web-centric" - you're still writing the app, you just write it so it can use HTTP to read and write files (isn't that something that many KDE apps can already do?).
And who "does whatever the app is supposed to do"? A program running on your machine - i.e., an app running on your machine, just as in that boring nasty old pre-Web-centric universe - or something running elsewhere - in which case how does it interact with you?
OK, what makes writing "the app served to you" "writing for the WEB"? If all that happened was that you got some Java app served to you, and it's running locally, perhaps reading local files, and saving the file locally, you haven't "written for the WEB", you've chosen Java/AWT or Java/Swing or whatever, rather than choosing KDE or GNOME or CDE or whatever.
And what if the application is the MP3 player I mentioned? How exactly do you "write that for the Web", other than writing it as a browser plug-in - but, as far as I know, browser plug-ins are cross-platform (unless browsers support Java plugins, but, in that case, see my previous comment about Java apps)?
...but it doesn't seem to be the point he thought he was making. He asked for "GNOME apps that don't require GNOME"; what it sounds as if he really wants are "non-GNOME GTK+ apps".
Unfortunately "sensible" doesn't necessarily mean "easy"; somebody could rely on GNOME's libraries to handle a lot of things, and would have to re-implement those things and set up a "configure" option to control whether to use GNOME stuff or the app's private stuff. Perhaps they should do that, but it might require them to do more work.
I think they're using it as the UNIX toolkit for Mozilla, but that doesn't handle the DnD problem unless you run Netscape 5.0 or whatever Mozilla-derived release they put out (or run Mozilla).
Because, according to this press release, StarPortal isn't the sort of "Web-based application" the original poster was citing as a reason why we should all "forget about toolkits". It says
which appear to be saying it's an application written in Java (see earlier comments in which I note that a Java-based application is just an application written for Java plus some widget set, just as a GNOME application is written in C or C++ or whatever plus GTK+ and a KDE application is written in C++ or whatever plus Qt), not a "web-based application" where you just fill in forms and hit "Submit", as the Web calendar and mail applications some people mentioned are.
Yeah, maybe it's more cross-platform than, say, a UNIX+KDE or UNIX+GNOME application is, but it's not the same sort of application as is, say, Slashdot, that being an example that one of the people to whom I replied gave.
Again, that's not a "Web-based application" any more than an MP3 player that can read files somehow magically becomes "NFS-based" or "CIFS-based" by reading from a file system on a server; the application is a local application, written using some toolkit - toolkits being what the person to whom I originally replied (and who cited Slashdot as an example of "Writing for the Web") said we should "forget".
No - but if it's playing something itself, it's not as if somebody "wrote for the Web" - they didn't write any application at all to play MP3s, they just used an application that already existed, namely Netscape or a plug-in. If you already have a canned application to perform some function, the mere fact that the canned application happens to be part of a Web browser doesn't mean that, by using that application, you've "written for the Web", it means you haven't had to write it in the first place - that certainly means you don't have to worry about toolkits, but it doesn't help you if that's something Netscape or whatever doesn't do.
Oh, you mean this one, which I read several days ago, where he says
and
where he pretty clearly indicates that he does not think that all traditional applications are dead and that CGI scripts will replace them, he indicates that there's a whole pile of new applications for doing new things that are best done with browsers talking to Web servers.
The problem that some people have is that, as, if I remember correctly, Abraham Maslow said, "to somebody whose only tool is a hammer, the whole world looks like a nail". Web-based applications, in the "3270 for the '90s" sense (as somebody described Web stuff several years ago), are cool - but they're not the whole world.
Try reading the original poster's article, which said
(without, it appears, bothering to ask what application the submitter of the question was trying to write).
Writing a custom GUI application to do Internet shopping, or calendar management, or library card catalog searching, might be a dumb thing to do now that we have HTTP servers and clients all over the place (although I'm not about to boldly declare that it is foolish; there may well be reasons why some particular such application makes more sense than a CGI script as a solution for some particular problem); nobody's made a convincing case that writing GUI applications in general is no longer necessary now that we have the Web.
Yes, at least up to a point; if it works too poorly, what's the point?
No. A Java applet is just a small locally-run application that happens to be written in Java rather than in some other language (or, perhaps, "that happens to be distributed in the form of Java bytecode" - something distributed in Java bytecode form wasn't necessarily written in Java, as there exist compilers that translate other languages into Java bytecodes, e.g. the JPython compiler) and that happens to use whatever toolkit the environment in which it's running provides. Interesting, potentially cross-platform (if you don't manage to use some platform-specific classes, say), but not the same as the examples many people were giving, e.g. Slashdot or Web mail and calendar systems, wherein "the web is the interface" - if your browser happens to pop up some Java applet that handles input events, I/O, etc. itself and provides its own UI with its own code, the Web isn't the interface, it's just the pipe over which the code for that application was delivered, and perhaps the pipe over which it talks to some server, but if that's sufficient to make the Web the interface, a boring old "widget-centric/shrink-wrap" application downloaded via HTTP "makes the Web the interface" as long as it includes HTTP client code that it uses for some operations.
(Besides, I rather doubt you can make a "Java applet-based" version of the GIMP, or of the other applications/suites I mentioined, for one simple reason - by the time you're done, it'll probably be too big to be called an "applet". "Applet" isn't short for "application written in Java" or "application delivered as Java bytecodes"; the "let" part is a diminutive, indicating that it has to be a small application before it gets to be called an "applet".)
KDE seems to run fine on my FreeBSD partition; I installed the 1.1.2 binary package a few days ago. Solaris binary packages also exist; people probably run versions from source built on other OSes as well.
Note that the KDE home page says:
Note the lack of a certain word beginning with capital "L" in that; they're not targeting Linux, they're targeting UNIX-flavored OSes, including but not limited to Linux.
The GNOME site doesn't say "not for Linux only" on the home page, but the "What is GNOME" part of the GNOME FAQ says nothing about it being targeted only for Linux, and the "What are the system requirements for GNOME" part says
Again, note the use of the U word rather than the L word.
You're probably unlikely to get as much enthusiasm from free software developers for CDE as there is for KDE and GNOME until there's a free CDE implementation (speech, not just beer) - there's LessTif, but it's just a Motif implementation, not a full CDE implementation.
Hrm, I don't necessarily agree. For one, um - why'd you skip the dial-up step for standalone? :)
:)
But anyway, I've actually been thinking about doing something like this. I'd like to make a gradebook application for Linux, and I've been thinking about how to implement it. I've considered using a web front-end, that way folks on macs, linux, windows, or palm pilots can access it. If it's on a LAN, it'd work well. I don't plan to put banner ads in my app.
That is the most idiotic thing I've ever heard.
Why do you suppose Win95 is so unstable? Why do you suppose the only way to fix it when it breaks is to reinstall from scratch? The registry makes the system nontransparent and creates a single shared point of failure that can (and regularly does) invalidate the entire system, simply because one program screwed up.
The day that Linux gets a registry will be the day I switch to a different OS.
Consciousness is not what it thinks it is
Thought exists only as an abstraction
(Disclaimer: I'm more of a CLI/network driver programmer, and am new to this "Gooey" programming. I have not actually written either a GNOME or KDE app. However, this is my understanding of how the two do and don't play well together.)
First of all, it's important to realize that GNOME applications run under KDE, and KDE applications run under GNOME. So, it's not as if writing for one means that users of the other desktop can't use your program (assuming that both GNOME and KDE are installed, of course).
The GNOME and KDE teams are working out a common window management and session management specification. I suspect this is mostly relevant to people writing window managers and/or toolbar/pager applications, and not to your generic gApp or kApp program, however.
That said, it's probably not possible to write a single program that is both a GTK+ and a Qt program. The best approach would be to separate the program into a non-GUI server and a GUI-based frontend, and then you could code a GTK+/GNOME frontend and a Qt/KDE frontend (or, in the true spirit of Open Source, simply code the one you want and let a partisan from the "other side" code their favorite :^) ). Since you are guaranteed that each enviroment has a CORBA ORB, making the interface between the server and the GUI based on IDL might be smart.
Alas, Bonobo and KOM aren't really compatible object systems. Maybe in the future the teams will work out how to embed objects cross-GNOME/KDE, but don't hold your breath.
And, if only some genius would hack Glade or libglade to work with Qt, making two separate front ends wouldn't be nearly so much work. (But I'm not genius enough to do it ...)
So, there were several specific points made:
So the answer is mostly "Not Yet" but the future looks bright. I hope that the various desktop environment makers can agree on some more standards that will allow apps to run anywhere, and I also applaud the efforts of those working on automatic generation of frontend modules.
I'll be writing my app in as much of a UI-independent fashion as possible for now, and hope that the dynamically loadable GUI/Desktop Environment API is done before I am.
Since most (decent) distros include the libraries for both toolkits, you should be able to get it to run pretty much anywhere.
You will miss out on the funky features of the desktop that isn't running though.
This is really an issue that GNOME/KDE need to work out whereby the two can exist comfortable at the same time (not all the panels and applet, but the core stuff like session management, CORBA, etc.)
Chris "Ng" Jones
cmsj@tenshu.net
www.tenshu.net
The KDE FAQ does not use the same phrasing, it says in 2.6 that KDE uses the Qt C++ crossplatform toolkit, which comes with its own license.
--
Is that what the original poster meant?
:o)
/. and Yahoo, both of which are "apps" that run on the server, and use the browser only as an interface (no java*)
:o)
I was thinking about this recently (acually, I was thinking about how the world needs a calendar/scheduling/intranet -type program that's cross-platform, instead of the Exchange/Bloatus Notes that exists right now), and though "what about a server-based app that used the browser for display."
I mean, for a calendaring app (for multiple people) the data needs to be stored somewhere central, right? This becomes a "write for the web" application, but without the horrendous problems you mentioned (all of which I've encountered, BTW
The original post mentions
I know that this doesn't apply to every situation, (anything that relies on interactive feedback wouldn't work) but for those that would work, it seems like the best way to make it truly cross-platform (not just cross-GUI toolkit
If you want to see something like this in action, install Roxen (GPL web-server) and play with its configuration interface. Very slick.
Just my two cents...
A registry is not a bad idea just because Microsoft screwed it up once.
A configuration database will always be faster, more reliable and easier to maintain than the current bunch of ASCII-files, given that it:
* implements access restrictions
* uses logging so that you can
- undo all the changes done by a particular user/program
- or restore the state at a given point of time
* has an easy to read input/output format (e.g. XML)
* can be accessed from the command line
The Windows95 registry was a step in the right direction, but I guess whoever implemented it did not get enough time to think about making it really secure against being messed up.
Standalone app: HTML-based app: (assumes dial-up connection, which is the most common still) HTML-based applications are slow, cumbersome to load and use, and deliver a more narrow feature set than standalone applications. The only way to bridge the gap is to use something along the lines of ActiveX, but of course that's not cross-platform.
For more information, click here.
Okay, you asked :-)
:-)
I want apps from both camps to support drag-n-drop, copy and paste operations from/to each other, with the same key bindings. I also want docks, start buttons, iconbars, and clickable desktop icons to go away or be easily turned off (not hidden). Like the kfm -w command.
I'd also like the eye-candy stuff on themes.org to have links to cloned themes, so you could download two themes and have both Gnome and KDE apps use pretty much the same look, but that's not important
I use K and G apps under XFce and WindowMaker.
"Nothing was broken, and it's been fixed." -- Jon Carroll
This is a completely uninformed question, but do both toolkits have the same use strategy? I obviously don't mean arguments in the same order, but more along the lines of one having an event model and the other using subclassing, or something like that.
in summarium: is it even feasable (sp?) to write a common abstraction layer?
I like the idea of being able to write applications once that run anywhere, but the reality is that they won't work. Java is a nice idea, but there are so many bugs that it can't be used in any realistic sense.
Writing for the web sould work if everyone supported the standards and only the standards. But with companies like M$ perverting everything they touch (how'd the screw up ASCII? why?) we all have to put up with code that works on one box but crashed on another.
I usually run with Java* turned off. There's a lot of room for bad code in the standard, so it's best to just avoid it.
In order for a place like Slashdot to exist, there have to be people around writing code for their pages to run on and code for us to talk about. I realize that you could be joking here but let's get serious. There is no way that you can write applications for the 'web' and expect them to work for everyone. Even if they did, they'd be about 1/50th the speed of a compiled app, so what's the point?
Have a fun day, gotta go code...
The question doesn't seem to be adequate to an accurate answer. If you mean "If I use Qt, can I run my apps with GNOME and if I use GTK, can I run my apps with KDE?" the answer is, "Of course."
If you mean, "If I use gnomelib routines, will my applications run under KDE and if I use kdelib routines will my applications run under GNOME?" the answer is, "Of course."
If you mean, "How do I write an application that will work equally well with KDE and GNOME, including things like docking and interapplication communications and all the fancy stuff that make GNOME and KDE more than just fancy window managers?" I'm pretty sure the answer is "You can't yet."
GNOME is already pretty much "CORBA-ized" and KDE is at least partially from what I understand, with an effort to make it "fully CORBA-ized" by the next major release. (2.0) I know there is a lot of communication between the two camps to have a lot of their features interworkable. But then the question is, "What are the features of each desktop manager that you want to work with each other? Drag-n-drop? Docking? Do you want to be able to embed GNOME 'objects' in your KDE application? WHAT DO YOU WANT, MAN?!"
You're really probably better off joining the GNOME and KDE development mailing lists and asking the question there. You will probably get a flood of useful answers since it's been my experience from lurking in the lists that the developers of the two toolsets seem to be much less prone to the "[not my brand of desktop manager toolset] sux rox!" mentality and more of the "Well, obviously we like [x] because we're programming it, but if you want [x] to Play Nicely with [y] apps, here is what works and what doesn't work yet..."
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
I find it funny that you want to use Enlightenment with KDE. In my experience, Elightenment is the thing that always made GNOME seem so unstable. I switched to WindowMaker (with GNOME) and it has been way more stable than either KDE or GNOME w/ elightenment. X hasn't crashed once since I made the switch.
Log in and say that. Go ahead, I dare you.
The whole idea behind linux for many people is that they don't have to use MS products anymore. Why should they be forced to choose GNOME over KDE?
And if you are curious, I prefer GNOME.
---