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.

Comments

CDE: Who Do You Pay Hefty License Fees To Today?

[Christopher B. Brown]

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.

• Much griping took place over the relatively low licensing fees The Open Group tried to apply to X11R6.4.
• Tremendous flaming has taken place over the licensing of Qt, where deployment is royalty-free, but developer licenses could cost as much as about $1500.

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.

KDE & GNOME Development.

[jelwell]

I think this post is flaimebait. I'd like to moderate it down one point, thank you.

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 @_ | /dev/null`;
}
while (&isWar(kde, gnome))
{
&flameproof("Joseph Elwell");
}

Re:No! No! NOOO!

[Guy Harris]

Think past the Linux box

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:

KDE is a powerful graphical desktop environment for Unix workstations. It combines ease of use, contemporary functionality and outstanding graphical design with the technological superiority of the Unix operating system.

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

Currently, you need a machine with Unix or a Unix-like operating system installed, with the X Window System (X11R5 or later).

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.

Summary

[Dr. Tom]

First, thanks for the comments that have been posted so far. Second, let me repeat that this isn't about which GUI to use, this is about how to write an app that can run under any desktop (or none) and still be theme-able, drag-n-drop-able, dock-able, etc.

So, there were several specific points made:

• Berlin -- Seems to be a replacement for X that is highly modular, including lots of gui/desktop code. Isn't this just another environment we'd want to support?

• wxWindows -- This contains an abstract GUI API, and several libraries that implement specific GUIs. You write your app for the abstract API. This doesn't address the problem of running under KDE or Gnome, although if the abstract GUI API can be extended to encompass desktop functionality, this might be a good place to start. The difficulty of creating one abstract API that encompasses all known desktops, GUIs, event models, themes, etc. is quite hairy, however.

• Desktop standards -- The KDE and GNOME teams are working together to create interoperability standards such as window manager hints and so on. This is good and should continue. Is there a standard for themes?

• Client/server model -- Write your app with a gui/desktop/window manager-independent core, and several specific frontends. This seems to be what you have to do now (and it's really just a good design policy). The amount of code that you have to rewrite is limited to the part that interfaces with the desktop environment. This part could be loaded dynamically, and possibly automatically generated. The trick of course is the API - maybe an extension of the wxWindows GUI API would be useful here.

• Parrot/Glade/Fluid -- While not all of these were specifically mentioned, they are programs that create GUIs based on some abstract definition. These tools may evolve into something that can automatically generate the frontends mentioned above.

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.

Is it really necessary?

[ChrisJones]

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

The GUI should be abstracted as much as possible

[extrasolar]

Really though, with as many toolkits as GNU systems seem to require, it makes sense to abstract the interface as much as possible with any major application. Instead of you application asking for a save dialogue box, it should ask for a filename. If you think about it, there are many ways to get a filename though only one way to open a dialogue box. These abstractions could be implemented using any GUI toolkit or perhaps a text interface. If I am not mistaken, Berlin is doing something like this.

--

Re:Need more data

[Stinking Pig]

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.

Need more data

[Ledge Kindred]

Let me preface this by saying I'm neither a GNOME nor a KDE hacker, however, I've used both GTK and Qt to bang together some silly little programs for myself.

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

-=-=-=-=-