Writing Apps for GNOME *and* KDE? 220
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.
let the desktops multiply and become fruitful (Score:1)
i think that as long as you can at least *use* apps on both sides of the fence (which in my experience you can) that's enough. having everybody's eyecandy and special integration features isn't needed, and maybe not even wanted. why?
IMO: gnome and kde are being designed with slightly different viewpoints on life (or at least on desktop computing =). this is Good. what one camp forgets, the other remembers. and what they other remembers, the first wants. it means a friendly competition between the projects that propels both.
same for apps. if there is a gnome text editor and a kde text editor and one puts in a Cool New Feature(tm), what are the odds the other one will adopt it, if it fits in their view of the desktop computing? pretty good, i'd say. again, competition is good.
what is more important that desktop amalgamation is the adherence to standard file formats so everyone, regardless of their desktop preferences and application choices can read/edit the same files.
think picasso and michelangelo. way different styles. both awesome. both had brushes.
Aaron J. Seigo
No account yet. ha.
Write for the WEB and keep everyone happy (Score:1)
Forget toolkits. Linux-only development is a dead-end. Write for the web and maybe you'll make some bucks like CmdrTaco and Jerry Yang.
Re:Write for the WEB and keep everyone happy (Score:1)
Not so fast T-Bone (Score:1)
Here's another boneheaded obstacle: in Gnome I can drag a http link from Netscape to the Gnome desktop, managed by GMC; in KDE I can drag a a link from Konqueror to the desktop and even a folder, but I cannot drag a link from Netscape. Huh? It's a url--handle it! Well for some reason this has slipped KDE developers attention. Which is funny because you can drag a link from StarOffice (an earlier Mozilla version) to a KDE folder to be copied or linked. So apparently, KDE people just don't want to make allowance for people using Netscape on a KDE desktop. Now you know what they have in common with Microsoft!
Both Gnome and KDE need to cooperate with each other and with major established apps. The alternative --each project trying to freeze out the other-- will mean they both will be failures.
How many features of each do you need? (Score:1)
I think it would be safe to implement the entire application in either GTK+ or Qt 2, and provide a theme to emulate the opposite environment. Unfortunately, if they're not using the default theme your app would still look out of place. The only way to solve this would be for someone to develop a theme converter.
For features that depend upon certain desktops, you'll simply have to write the code twice or abstract it. e.g., panel applets, VFS or media filters, session management. All of these things would need a new abstraction layer or would need to be implemented twice. I think drag-and-drop should work between the two, so that isn't a problem.
What would probably give you huge problems are if you want any sort of application embedding features via GNOME's Bonobo or KDE's KOM/Openparts object models. These two are not similar, and probably couldn't even be abstracted well. Implementing it twice seems difficult and not really worth the effort, but I could be wrong. I'm not very familiar with KOM/Openparts.
Cody,
bratsche@dfw.net
What not use Design Patterns to help? (Score:1)
Reason I say this is that by using these patterns (they are originally inspired by architectural design patterns research from the 1970's) you can nicely and neatly separate away the "nasty parts" (the implimentation specific parts) from the "generic parts" (i.e. the core, GUI-independant functionality) and maintain them nicely. I would suggest as starters to look at the Bridge, Factory, Prototype and Observer patterns (not that they and only they will solve your problems, but they cover a good range of the possible *uses* of patterns and I can already see some uses). And definitely get Gamma (sp?) DP book - worth every penny I paid!!!! Plus lots of great web sites out there - simply type "Design Patterns" into your favourite search engine and away you go!!!!
Good luck!
GUI toolkit (Score:1)
Re:Wrote for KDE, no one uses Gnome (Score:1)
Pronouncing the other players as "Dead" for no reason is a FUD tactic.
When I see the promised "KDE Replacement for Gimp", which supposedly would only take "a couple of weeks" due to the amazing Qt, then tell me about how Dead the Gnome is.
What do all those KDE developers use to draw their graphics? Gimp!
Which desktop environment STILL WON'T WORK with any other DnD system even in 1.1.2? KDE!
Which one has working apps that load MS Office documents? GNOME!
So what's dead about Gnome?
Graphapp (Score:1)
Re:A Desktop Registry? (Score:1)
It is very mature, and has a different (and IMHO saner) philosophy then KDevelop, in that it generates an xml description of a UI. This description, when used with libglade, leads to very rapid development. For most simple apps, all of the GUI coding is effectively removed from the project -- all that's needed is writing the callbacks.
Try GLUI (Score:1)
Let me get this straight (Score:2)
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.
Think MVC (Model-View-Controller) (Score:2)
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
A really valid question (Score:2)
wxWindows (Score:2)
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
Re:More general question (Score:1)
- MacOS and NeXTstep use a separate menu bar, which means you can have applications without windows; X based toolkits attach the menu bar to every window and Windows uses a strange hack called MDI (a window in a window).
- On MacOS/NeXTstep, usefull names are used for buttons while on Windows, it's limited to 'Ok', 'Cancel', 'Yes' and 'No'. This is especially visible in message boxes.
- In MacOS/NeXTstep dialogs, the default button is the rightmost one, and 'harmfull' buttons are clearly separated from 'harmless' buttons; in Windows, those buttons are put together and the default one is usually the leftmost one.
- For binary menu items, MacOS uses a change in the name (like Show Ruler/Hide Ruler) while Windows typically uses a check mark
- Windows interfaces heavily make use of toolbars, MacOS doesn't.
- Different vocabulary (e.g. Exit vs Quit)
- Different menu layout (e.g. the position of the About item)
- ...
If you add the OpenLook interface, it gets even worse ('Close' in OpenLook means 'Minimize' in Windows; 'Quit' in OpenLook means 'Close' in Windows...)not really (Score:2)
Hopefully they'll get their acts together soon. Until then, I'd recommend not writing for either one.
Buy "Design Patterns" (Score:1)
Really. That's probably the solution you are looking for. There is a specific abstraction pattern that could easily do what you are talking about--they actually use X toolkits as an example. :-)
Of course, that's assuming you use C++. You could do it in C, but I wouldn't recommend it. Trying to apply the Design Patterns to a non-object oriented language (no flames, please) is difficult unless you really know both OOP and C. But if you are writing for Qt, you are probably using C++ anyways.
I can't remember the DP name: I thought it was an Abstract Factory or a Prototype.
"Doubt your doubts and believe your beliefs."
So what *should* be interoperable? (Score:2)
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, [hex.net] 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 [ietf.org] has been involved in defining common protocols for things like news [hex.net] and mail [hex.net] 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 [hex.net] 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.
CDE: Who Do You Pay Hefty License Fees To Today? (Score:3)
Look at CDE Price List [opengroup.org] 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.
Write the application as a library (Score:2)
Re:No! No! NOOO! (Score:1)
It depends, really... (Score:1)
Do you need DND support? Sorry, for now, it's one or the other. That will change Real Soon Now.
Do you need for your app to dock onto each of the panels that the projects have? I seem to think that both use some kinda funky proprietary extension...you'd have to check it out.
If you're just wanting to write an editor, tho, or just some app that's independent of proprietary drag-and-drop and all that, you could just use Any Old Tool Kit(TM).
Gnome & KDE (Score:2)
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.
Re:Same strategy? (Score:1)
1) Qt is C++-based, Gtk+ is of course a C-based toolkit. Consequently, unless you do some spiffy stuff with opaque data structures, you'll have to expose C++ in the headers of your cross UI toolkit.
2) Gtk+ is *completely* callback driven--there are no blocking calls for UI stuff--this boggles the minds of people who want to do MessagBox() style calls. If Qt has blocking calls like that, you'll have to hack fun stuff like GnomeDialog blocking calls into your UI toolkit for Gtk.
Also worth mentioning is UI bindings... does Qt have anything other than C++ support? With Gtk+, you get Ada, Perl, Python, etc..., so I assume this would be a C++ only toolkit.
Etc., I'm rambling at this point...
Re:Here's the thing... (Score:1)
missed the point (Score:1)
However, in the case you mentioned, you are running an app written for KDE under gnome. It will not take advantage of any special features gnome apps may have under the gnome desktop.
To do so the app would have to be specifically written to do so. But if you wrote it for Gnome, then it wouldn't take advantage of KDE stuff. Or you could write it for both, requiring both to be installed, and then somehow figure out which desktop is running and morph.
And then there is the whole look/feel issue.
What was asked is if there is a middle ground that would satisfy both - something like AddIconToDesktop which would add make the appropriate API call to either KDE or Gnome.
This has always been the problem with X. Be it simpler toolkits or entire desktop systems, there are just too many choices - be it good or bad.
What about Java? (Score:1)
Of course, if you're using the flashy uber-cool stuff, then you're going to have to get specific, but if you're just trying to *do* something, it seems like Java ought to be the answer.
Okay, so there's the little issue of an efficient Virtual Machine for linux. Details, details..
Zipwow
Pros and cons of using wxWindows... (Score:1)
It does work on Motif, Lesstif, Xt, and GTK, so it'll run on just about every Linux box. It also works on Windows, and a Mac port is underway.
Also, it's been ported to a scripting language -- Python's implementation is an almost direct echo of its C++ version, to make it easier to transfer knowledge.
BTW, I've never used MFC, but I've heard that wxWindows isn't anything like that. Yet some people here are saying that it's similar. Is that true?
-Billy
Apps that use the web (Score:2)
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.
-------------------------------------------------
Re:wxWindows (Score:1)
As for the Gnome support, the wx people would love to add it, but last time this came up on gnome-devel-list, the gnome folks weren't too keen on the idea. It's not currently possible to make a full-fledged Gnome app (whatever that means) with wxWindows, but you can come as close as you can with plain GTK (no libgnome/libgnomeui)
Re:Write for the WEB and keep everyone happy (Score:2)
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.
KDE & GNOME Development. (Score:4)
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");
}
Here's the thing... (Score:2)
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)?
Re:KDE & GNOME Development. (Score:1)
--
Sigh. A clarification for those who can't read. (Score:1)
PS. Thanks for calling me names. As I have in the past, I guess I'm falling to your level in this sentence, you shit-for-brains ass-monkey.
Sorry, you're wrong... (Score:2)
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.
Re:Write for the WEB and keep everyone happy (Score:1)
that's how it works. whether that fits your situation or not is another question.
-l
without Gnome or KDE? (Score:1)
I'd be more interested in making Gnome programs compile on a system with just the Gtk+/glib libraries installed, without requiring any of the other Gnome libs. And similarily, being able to run KDE apps with just Qt installed.
My experience has been that trying to compile programs written for Gnome on a system with just Gtk/glib never works without removing the dependencies on gnome libs in the code yourself. Often, I find that it isn't that hard. I get the feeling that Gnome developers could care less about those that don't run gnome.
People running old systems, especially laptops, can't really be required to bear all the overhead of running Gnome or KDE just to be able to run one or two programs.
It would also solve, at least partially, the original Ask Slashdot question of how to write apps for both KDE and Gnome--just find the greatest common denominator, which is to make them compile with just the toolkits.
Re:without Gnome or KDE? (Score:1)
Re:Is it really necessary? (Score:1)
On my K6-233 RH6.0 system, using the KDE desktop, it takes up to fifteen minutes for a GTK app to show up on the desktop. The system's a vanilla "workstation" load! Where's that at?
Re:More general question (Score:1)
Arachne [arachne.org]
Kinda free, promised to be GPL'd Real Soon Now, and targeted to Mac/X11/Win... tho the Win part seems to be win3.1
fwiw
Re:Get with the times - write WEB-BASED apps (Score:2)
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.
Re:without Gnome or KDE? (Score:2)
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.
Re:Write for the WEB and keep everyone happy (Score:2)
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?
Re:You'd have to deal with all those browser bugs. (Score:2)
Is Yahoo Calendar [yahoo.com] such an application?
Re:Not so fast T-Bone (Score:2)
To which "X standard" are you referring? Xdnd is being adopted by at least three tookits, as far as I know (JX [caltech.edu], 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?
Re:Real Problem With Moderators (Score:2)
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.
Re:Write for the WEB and keep everyone happy (Score:2)
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)?
Re:without Gnome or KDE? (Score:2)
...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.
Re:Aren't future versions of Netscape gonna use GT (Score:2)
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).
Re:Write for the WEB and keep everyone happy (Score:2)
Because, according to this press release [sun.com], 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 [xml.com], 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 [slashdot.org], 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.
Re:Real Problem With Moderators (Score:2)
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 [jpython.org] 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".)
Re:No! No! NOOO! (Score:4)
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 [kde.org] 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 [gnome.org] says nothing about it being targeted only for Linux, and the "What are the system requirements for GNOME" part [gnome.org] 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.
Re:Linux needs these flamewars (Score:1)
The development version should be considerably faster as all the hash table lookups were eliminated and all the excess size (often many K) of signal stuffs has been eleminated. If you still find it slow (compared to gtk+ as I can't fix stuff outside my layer), please send me a demo program and I will mark it as a hot spot to do optimization. Thanks in advance.
--Karl
Re:Write for GTK-- and QT (Score:1)
If you could comment more on what you find annoying about programming in Gtk--, I would be glad to hear it. We are working to complete version 1.2 very soon now with improved speed, features, and documentation. Any feedback would be greatly appreciated.
--Karl
Re:Is it really necessary? (Score:1)
You may have some trouble with your DNS, some
sort of timeout.
Do nslookup 'your.hostname' work?
Oliver
Re:Aren't future versions of Netscape gonna use GT (Score:1)
Re:Yes, lies - and rampant paranoia (Score:1)
I recently read a mail by RMS on the WindowMaker list were he pointed out that using Qt was not advised behaviour due to the licensing issue.
As for ESR he will testify that anything is free as long as he gets his name on print.
Since I, and obviously others don't think it is free, "everyone" definetly don't think Qt is free.
Both ToolKits (Score:1)
Yeah, what the first poster said :) I run KDE on my home PC, and Gnome (Enlightenment) on my work PC, and run the same programs on both of them with very few differences that I can see.
The apps should look the same. You will just have to work around not having the 'features' of the various Windowmanagers.
IIRC, the GNOME/KDE people were starting to get together on making their features intercompatible...the first feature to come ofer is/was supposed to be drag-n-drop, and I think I read the article on here a long time ago.
Re:Get with the times - write WEB-BASED apps (Score:2)
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.
Re:KDE & GNOME Development. (Score:1)
However, I don't think it's true. For one why would one desktop enviroment want to kill another one? There is no money reward.
And I have yet to find an example of embrace and extend -- although I do see desktop enviroments starting to realize that apps that aren't your native toolkit/libs, still deserve a home in your desktop project. GNOME uses Netscape extensively in it's desktop -- yet I don't see the anybody trying to lock you into a particuluar piece of software -- but more like allowing you to use more apps with your desktop enviroment of choice.
Re:KDE & GNOME Development. (Score:2)
And yes, KDE 2.0 will include tools for converting KDE widgit themes to GTK+ and vise-versa. Mosfet is currently working on this feature, along with the KDE widgit theme designer (finally fast, and useful themes).
I am not sure if GNOME will support similar features in the 2.0 release, but I sure hope they will -- It just makes Linux feel so much more intergrated and useful, even if it's real benfit is little.
As for other standards, both the GNOME and KDE parties are working togther. Both sides are working hard to choose the same audio server for compatiblity between various apps. The same can be said about window manger hints -- both want to use the same set of hints, which should be fully documented as part of the Window Manger Spec 2.0. So any Window Manger compatible with Window Manger Spec 2.0 should be able to work fully with both desktop enviroments, and settings for the window manger should be fully embedable in the main control panel of the desktop enviroment. Finally, for release 2.0, both desktop enviroments have agreed on a common drag and drop protocol -- xdnd.
Well... that's how it's suppost to work in theroy. Lets hope it does.
What I do (Score:1)
Make your own functions to create objects. To draw a button create your own function. When you call that function, depending on what library you are using, that function calls the toolkit function to draw a button.
This method adds overhead to function calls. But then again, you can 'port' to whatever library/toolkit you want.
I actually stole this idea, in a sense, from reading about the TCP/IP stack and how layer N can only 'talk to' (read call functions in) layer N+1.
The whole idea behind this is portability; as your program structure changes, it only changes in the layer you are working in and you don't have to rewrite your whole program. Therefore, if you substitute KDE for GTK or vice versa, you only have to change the functions that access the toolkit API.
I bet there is some official name and technique to this if you go to structured programming school.
Re:What I do (Score:1)
A lot of 3D games that use multiple renderers do something like this, Quake II is a good example, you ahve your quake II binary + a few libraries for different renderers, reg_soft.so for software rendering, ref_gl.so for Mesa/OGL rendering, ref_3dfxgl.so for 3DFX OpenGL rendering (links to Glide), and ref_glx.so for Mesa/OGL under X instead of SVGAlib.
Modular Interface? (Score:1)
You could write the program in such a way that it uses libgmodule's modules (from glib) and call your own custom written generic functions to create the windows you need, which will use widget toolkit specific functions from a number of modules. I.E. you could have a module for GTK, and one for Qt, and one for Lesstif or whatnot. You just have the program load a module based on a command line option, or a default, and then it will, say based on a variable's contents, extract the correct symbols for the widget specific functions from the modules.
If you're confused, I'm sorry, but I'm not sure how much clearer I can make this.
--
Gabe Ricard
we need... (Score:1)
(The X Foundation Classes)
:)
Language issues (Score:1)
One issue is that the two toolkits use different languages though. This could make it less than easy.
Re:libglade?? (Score:1)
It would also be possible to have database forms and views that adapt to the current desktop, using the XML tags stored in the database.
At least for simpler, not performance-critical GUIs this is an option.
Just, as the above poster said, find someone to write it
---
Re:Not senior enough to use cookies evidently (Score:1)
libglade?? (Score:1)
What do you think?
Lee
Re:A Desktop Registry? (Score:2)
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
Design First to minimalize changes (Score:1)
If you were to plan your app carefully, you should be able to seperate out the core of the application from the environment specific portions. While you would have to write some code twice, in the end you would have a program that takes advantage of the functions and capabilities of both environments.
/Zl
Re:What I do (Score:1)
Re:More general question (Score:1)
Re:What about Java? (Score:1)
The only thing you can't do, is conveniently write an app that takes advantage of the advanced features of both GNOME and KDE.
This has little to do with what language you use, as GNOME's core is in C, and KDE's core is in C++.
Re:Wrote for KDE, no one uses Gnome (Score:1)
Use a toolkit like wxWindows (Score:1)
http://web.ukonline.co.uk/julian.smart
It currently supports several OS's -- Windows, Linux/GTK, BeOS, with ports to Mac, Linux/QT coming along. There are plans for a RAD application designer in the works, as well.
-- Ken
wxwindows.org (Score:1)
This actually redirects you to some faster url in the UK i think.
Does this app *need* DE integration? (Score:1)
Users of both DE's will be comfortable with a gtk app and most if not all of the major distros come with GTK 1.2X installed.
Perhaps someday there will be a way of easily writing one piece of code with an abstraction layer that can be compiled for either DE but until then i would defintely use gtk
GNOME + KDE: Not really possible today (Score:2)
(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 ...)
Re:You'd have to deal with all those browser bugs. (Score:1)
My brother is a web designer, and does some pretty funky DHTML and JavaScripting on his personal home page, and he spends ages cursing and debugging the JavaScript for Netscape and IE.
If you look at the source of *any* of his pages, you'll see it has loads of
if (ns) var = this.thing.here
if (ie) var = another.thing.here
One example is the previous [ziggen.com] version of his homepage [ziggen.com], which he couldn't get to work with Netscape because of a DHTML bug in it (and he is *good* at working around bugs), so he had to create a new one from scratch.
---
Ilmari
n-tiered apps (Score:1)
Re:Design First to minimalize changes (Score:1)
But take the concept one step further. There is nothing particularly Gnomish or KDEish about a PIM. Nor is there something particularly Windozish or PDAish. But the truth is there is a certain look and feel you want out of an application dependant upon the final "run time" envirnment. You can run a text based PIM under Gnome, but it sure would not be pretty.
Plan the core code for the widest possible distribution, then produce the user interface/windows manager interface seperately.
The day Sun gets Star Office for win freely distributed the way AOL flooded the magazine racks is the day the streets will be filled with ms blood.
--
"V" applications framework (Score:1)
The "V" GUI applications framework [tu-berlin.de] is something that has interested me for some time (although, admittedly, I haven't put any effort into learning it -- PHP3 [php.net] is keeping me busy enough these days). It allows you to write your application to one GUI API, and have it port very easily between X, Win16, Win32, and possibly Mac as well.
"V" is under the GPL, too...perhaps some interested coders could look into extending it to support your choice of widget libraries and other GUI environments.
Re:KDE & GNOME Development. (Score:2)
My God! I need a life!
Summary (Score:3)
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.
Is it really necessary? (Score:3)
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.)
KDE FAQ requires Qt (Score:2)
The GUI should be abstracted as much as possible (Score:3)
--
Re:You'd have to deal with all those browser bugs. (Score:2)
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...
You are biased (Score:2)
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.
Re:Get with the times - write WEB-BASED apps (Score:2)
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.
Re:Gnome & KDE (Score:2)
(2) doesn't really help matters... why not just use one toolkit if both have to be installed?
(3) #ifdefs would be incredibly messy in this case, considering QT's main language is C++, and gtk prefers C. True they both have wrappers for other languages, but afaik, they're really no substitute.
Doug
Re:Need more data (Score:3)
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.
Same strategy? (Score:2)
in summarium: is it even feasable (sp?) to write a common abstraction layer?
You'd have to deal with all those browser bugs... (Score:2)
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...
Need more data (Score:5)
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..."
-=-=-=-=-
Re:I hate GNOME vs. KDE war (Score:2)
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.
Re:write for gnome, kde sucks (Score:2)
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.
---