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.
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.
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.
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.
This is inherently a tricky question. Do you need to write an application that runs in and plays nicely with both GNOME and KDE? This is not a difficult thing to do at all. Do you need more advanced features of KDE and GNOME? That starts to get difficult.
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
Not sure exactly at what level you want to "use" KDE and / or GNOME. However, I would suggest,regardless of what the end result *should* be, to look seriously into Design Patterns before you even design anything.
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!
Odd that noone mentioned wxWindows. Not only does it do GTK, it does Motif and, Mac and Windows. A Qt port is "underway." It has wonderful Python bindings, for extremely rapid development. In fact, if you write your programin in Python it will run unchanged, and unrecompiled on Mac, Win32, GTK, AND Motif-based systems!
Gnome doesn't look dead from where I'm standing.
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?
Perhaps something based on graphapp? You can find it at: http://www.cs.su.oz.au/~loki/graphapp/ It plays nicely with Athena, Motif, Windows, and Macintosh so far, and I expect that you could port it to GTK and QT, also. Linux Long and Prosper
You should try Glade, at http://glade.pn.org
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.
Not completely off-topic: Try using GLUI, a GUI toolkit built on top of OpenGL/GLUT. You can write a program that runs portably on Linux/Windows/Mac/SGI/... (?!!?). http://www.cs.unc.edu/~rademach/glui
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
- 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...)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
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."
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
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.
I'm not sure why flamebait got a score of 4.
Stating on Slashdot that I like cheese since 1997.
It depends on what functionality you need.
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).
Stating on Slashdot that I like cheese since 1997.
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)
Obviously they're both event driven systems (hey, they're GUI apps), but two issues come to mind immediately:
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...
"Sebastian you're in a mess. They called you King of all the Hipsters, is it true or are you still the Queen?" -- B
You can't compile Gnome without gtk, you can't compile kde without qt. If that is not "requires" then I don't know what dictionary you are using :)
True - it's very easy to run an application from one under the other.
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.
Isn't this *exactly* the situation Java's supposed to be for? GNOME, KDE, NT, who cares?
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
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
I would recommend wxWindows for this. The big negative to this is that wxWindows is not _yet_ ported to Qt and GTK; however, both ports are ongoing. The Curses port is also ongoing (although unlike the others, its status is uncertain). (I want that Curses port!!)
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
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
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)?
The poster stated you could write, for example, a GNOME app with non-GTK+ widget sets. But as I pointed out, a GNOME app by definition must be written in GTK+. I never said that you couldn't run non-GTK+ apps in GNOME. They just aren't GNOME apps!
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.
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.
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.
Yeah, it'd be nice to see both systems interoperate a LOT better.
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?
I just came across this while chasing CVS clients...
Arachne
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
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.
Is Yahoo Calendar such an application?
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.
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).
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.
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
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
Hey, thats imposible!
You may have some trouble with your DNS, some
sort of timeout.
Do nslookup 'your.hostname' work?
Oliver
Get my e-mail after a captcha test in: http://tinymailt
These widgets are Gtk wrappers.
RMS has aknowledged that the QPL might fit the wording, but not the spirit of free.
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.
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.
This space for rent. Call 1-800-STEAK4U
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.
When I get into a situation like this, I write my own level of abstraction.
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.
-- DrZaius - Minister of Sciences and Protector of the Faith
Well, I'm definately no expert on GUI programming using Qt or GTK+, but I have an idea you may have heard, and may like.
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
Gabriel Ricard
X.F.C.
/me runs away
(The X Foundation Classes)
:)
One issue is that the two toolkits use different languages though. This could make it less than easy.
I do second that.
;-)
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
---
it can be a very sensible design decision *not* to use cookies. for a public site where you want users to like your service, and be able to enjoy it with a large range of browsers and settings, depending on cookies is arguably a bad idea. there are other ways (i.e forms with image submit buttons, or session data or session id's embedded in the urls).
I haven't worked with, nor have I looked at the API, but I wonder if its possible for libglade to generate QT widgets instead of GTK+ widgets at runtime. That would be incredible. Imagine, your whole interface is defined in XML, and parsed at runtime. Your desktop environment is detected by libglade and the appropriate QT/GTK+ gui is created.
What do you think?
Lee
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
Just a thought:
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
Perl/TK, TCL/TK, and I wouldn't be surprised if there's a Python/TK.
You might prefer GTk and that's fine with me but after checking out GTk and working with Motif and Win32 API for long time I can assure you that QT is quite amazing.
The trick is to find an API that works across toolkits. Check out wxWindows at:
/wxwin
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
http://www.wxwindows.org
This actually redirects you to some faster url in the UK i think.
I know I will be moderated down for this, but . . . Vincent
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
(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 ...)
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 version of his homepage, 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
© ilmari. All rights reserved, all wrongs reversed
Whenever possible, you should split your program into at least two parts: the main application logic and a client/front-end. This way, you can write a client for GNOME, a client for KDE, maybe even a Java client - whatever. The point is, you're sharing the core of the application, only rewriting what you have to, and you're doing this very cleanly. Use the GUI toolkits to do what they're designed for: GUI's. Try not to couple this too tightly with the rest of your application.
The "V" GUI applications framework is something that has interested me for some time (although, admittedly, I haven't put any effort into learning it -- PHP3 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.
Surf on over to http://www.gnucash.org
There's an excellent example of an app that plays nice in Gnome, Motif/Lesstif and (soon) KDE. The application part is extracted out into seperate code, and a front end for any environment can be written.
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.
YACC
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
This whole discussion is certainly interesting, but it does lead me to ask, why do we have two desktop standards?
The most obvious answer is for competition, since many believe that increased competition leads to higher quality software.
Others believe that since you have to use your desktop environment, you should be able to personalize it: choose the colors, choose the widgets, choose the window manager.
However, with the recent moves to popularize Linux, I begin to wonder about the wisdom of this philosophy.
Developers don't want to support 2 desktops. It doubles the amount of effort needed to build the user interface, and could impact other areas of the application as well. This thread is evidence that some care about having their program work with GNOME and KDE. However, how reasonable is it to ask that programmers support both environments? How reasonable is it to ask companies interested in selling Linux software to support two environments? One obvious answer is, it's not, that's why we have Gcalendar/Kcalendar, etc... That strikes me as silly; now we are advocating duplicating ALL the code instead of just the user inteface!
Additionally, many users don't care about having two desktops. Corporate environments immediately come to mind. If a large company wants to roll out linux for its desktops, they will choose a standard configuration of applications on standard, supported hardware. They don't really care if it's GNOME or KDE, just as long as it gets the work done.
This adds up to the idea that maybe having 2 desktops isn't such a good idea any more. GNOME has made some fantastic advancements, and KDE too has begun to really push technology. Why not work together and achieve a Common Linux Desktop Environment (CLIDE?).
This would of course have advantages and disadvantages, but perhaps it is time to re-evaluate where we are going.
I'd asked /. which gui framework is better beforehand, although this question is a bit different, it was also discussed. Please search previous Ask Slashdot posts to find it out.
Since the two desktop environments depend on pretty different GUI architectures, the first thing to see is that the same CORBA interface works for both... Then, you should encapsulate all GUI into classes, and write separate implementations for GTK-- and QT. However, this will wear you down, since the QT seems to be a little limited for coding.
One fancy idea that came up was writing a GUI abstraction library. This will facilitate the kind of interface that is independent of any GUI lib. However, it would still support all types of (sensible) widgets, messaging (talking about event handling as well), etc. Unfortunately, that's not a piece of cake, and it wasn't attempted before as far as I know.
Happy GUI hacking,
--exa--
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.
--
I remember reading some info on a GNOME website about how to write cross platform apps better. What you really should do is write the core functionality as a seperate library. For instance, lets say you are writing an ICQ program (actually, this is what I am doing, but nevermind). What you need to do is write a generic library that is event-driven. That is, if data is waiting on a socket, do something, or if the user has sent the connect command start the connection process, etc.
I suggest writing it with a cheapie CLI first, but be warned: it is way too easy to write a CLI application that is not event-driven, try to keep that in mind and design around user events not around your programs code.
Both QT and GTK can be sent a file descriptor to wait on. When it "goes off" it will send a signal and you can do some quick processing. Remember to keep your functions/methods short. If you need to wait on something else then you need to let GTK/QT take over the event loop again and they will let you know when the something else comes in.
Remeber that you do not run an iterative loop. QT and GTK both have their own loops. And while it is possible to write your own loop to wait for stuff and call gtk_main_iteration() or something like that in the loop, it's a bad idea because more than likely what you want to wait on can already be waited on by GTK or QT.
If you want to port this to a Windows platform, you can also do so, but I believe you will run your own loop in Windows. Also, the CLI version will need to have its own event loop to wait on stuff (think the UNIX select system call).
I know it seems like a daunting task, but it will create a better program with fewer bugs because it will make you think about what you are doing. Take a look at the micq or gicq source for a very bad example. micq is essentially a command line app ONLY (and it does some dirty crap with structures instead of properly packing data, but that's another story all together). Gicq is based on micq and is a very bad hack trying to get micq to work with gtk. Instead of adding the file descriptors into GTK's select loop, the author decided instead to run iterations of gtks loop and do his own select (probably to avoid substantial modification to his existing codebase that he borrowed).
If you decide to write your app this way, it will be a much less buggy, more polished app, and will have the distinct advantage of being able to drop in a different front-end when you feel like it.
Of course, it has the distinct disadvantage of taking much longer to write.
Dave.
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...
I'm actually working on that app as we speak. I'm using a combination of qmail, mySQL, perl, apache, and debian linux. It is developing into a groupware suite that includes regular groupware stuff (email, messaging, threaded discussions, lists, etc) with lesson plans, student schedules, etc.
As mail comes I intercept it, break out the mime parts and write the whole thing to a mySQL box.
And I agree about the speed. Most of our schools around here that are buying into this are on a regional ATM fiber network that they also use for distance learning. It's fast.
load "linux",8,1
Can you tell me how it would be for the admin much different from the current ASCII-hacking state if you have an option to export/import XML-based data?
You would still be able to hack the configuration with vi, but furthermore you could:
- force applications to provide a list of entries it wants to be able to edit
- have all possible options documented
- write programs that let you edit the current configuration and that check your changes for saneness before applying
Let me fantasize a bit:
With every program you would get an XML-file foo.xml that provides:
- the changes needed for installation (you can read it in advance if you don't trust it) and default values for its keys
- documentation for every new key/value pair it introduces and a definition of valid values
Then:
config --set foo.xml will set/reset the values
config --remove foo will undo whatever foo did to your registry
config --extract bar.xml prints the current configuration of foo into bar.xml (with comments)
config --set bar.xml applies your changes into the registry
config --undo removes your changes
I believe this scenario is superior to what we have right now. I can't think of anything that keeps bad scripts from messing up my /etc/* in the current situation.
It's offtopic but it had to be said
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.
It's easy to ask for features if you're not a programmer, and it's easy to complain that there are too many library dependencies on stuff like gnome or enlightenment or anything else.
but... it's hard to explain to a non-developer about how difficult it really would be to merge kde and gnome apps.
I don't even know where to start... but anyway, it would be possible for new libraries to be written that would include *supersets* of functions handled by current libraries, and then you could ask developers to write to those libraries, and over time, things might get a little more homogeneous.
BUT... since much of the code is written by developers who aren't getting paid, you'll never be able to enforce any of these rules.
life never gets simpler.
As Linus would say: Show me the source...
GTK+ is standard for Mozilla on Linux/UNIX, but the source tree includes (or will include soon) front-ends for QT and even plain Xlib.
I use both KDE and Gnome and think they are *both* great.
If they each keep following each other's features, I think we might end up with the programmers implementing 'tick in the box for the reviews' stuff rather than concentrating on what the users are really asking for. We all complain about 'bloatware' when a Certain Company ships yet another 'upgrade'. I hope the programmers working on these projects continue to focus on the stuff that matters. Interoperability matters a lot.
If you think #ifdef is an option, then you've never had the preprocessor bite you hard.
I am new to programming, so please understand these are sincere questions.
Wouldn't it make sense if all GRAPHICAL programs used the same library as a STANDARD for the Linux platform? Why not just EXTEND the STANDARD library and work on the code frame work as a community like it should be? Instead of bitching at each other and dividing ourselves, try to find a solution that will handle these problems. Why doesn't someone talk to individuals at KDE and GNOME and see if a middle ground can be agreed upon to where the code could be shared and become seemless in any Linux environment. Why should programmers write code twice to use specific features in both desktops? The Micro$oft syndrome---the over-bloating of code...what could of been optimised, never was.
Devin
After the IPO. All good things come to those who wait to get s....ed in the IPO.
Good luck on the themes.
Will in Seattle
>If you want to see something like this in action,
>install Roxen (GPL web-server) and play with its
>configuration interface. Very slick.
Or just turn on the web functions in Exchange/IIS Notes/Domino. Both have been turning that trick for two years.
"Nothing was broken, and it's been fixed." -- Jon Carroll
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
The amount of interactivity is also a consideration. Hate WWW e-mail apps (prefer mh when I'm telneting and exmh when I'm sitting in front my my box), love my credit union's WWW banking app.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Do you really want another layer ? Graphic apps on Linux are plagued by layers, there are so many layers of API on each others over X-Windows that it makes it a real memory and cpu hog. Damn, at least ONE good thing with Windows is that there is a consistent way of drawing widget without 24687 abtraction layers below.
Somebody ought to design a new UI that talks straight to the graphic driver...
Limited in what way? It seems pretty flexible to me.
Stephen Molitor steve_molitor@yahoo.com
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?
Ain't that the truth. What I hate is this "QPL" which had to be invented so Troll Tech could still gatekeep the libs. I would use KDE if it were either GPL or LGPL, and I mean the whole thing, including QT, or an LGPL replacement. It's too bad Harmony fell flat. I would have named it "dischord" or "QFree." KDE has some nice qualities but I won't touch it until they dump QT and that ridiculous licensng scheme.
Linux, DOS32 & Windows are supported. Though this thingy is outdated a bit - MGUI main page was last updated in October, 1998...
Did anyone try it?
Brain is my second favorite organ.
Those toolkits are the *native* toolkits used for each desktop platform. Unless you are writing an app that intereacts with the desktop environment, which I assume you are not, it doesn't matter what toolkit you use.
You're probably running Netscape in one of the two right now and it doesn't use either toolkit, but you are still able to run it in GNOME or KDE. I've used GNOME apps under KDE and KDE apps under GNOME, its all just personal opinion. Just use the toolkit you like best (GTK of course! --personal opinion) or the toolkit for the desktop environment that you think most of your users will be using. Just make sure they have the needed libraries installed which most distro's come with by default AFAIK.
---- sonoffreak
As someone else pointed out, you still need to dial your ISP in the stand-alone case.
You seem to be assuming in the HTML case that you are using a free email service somewhere out on the net.
If you were buying the email service from your ISP (as you are in the standalone case) there wouldn't need to be any banner ads, and connectivity would be just as reliable as it is to the POP server in the first case.
As fast internet connections (cable/xDSL) become more common, web based applications will become useful for a wider range of applications.
ActiveX is not cross platform (nor is it secure), but Java applets can be, as long as you can find a browser for your platform which supports a reasonable version...
I have discovered a wonderful
I've been wondering about this for a while myself. I recently switched to KDE from Gnome, mainly for Kdevelop, but I still use a few Gnome apps. I've been trying to find a way to make them "play nice" ever since I switched. I know that Kdevelop will automagicly include everything you need to be KDE compliant for you, but Gnome doesn't have anything like this AFAIK. If Kdevelop could be modified to allow you to select multiple desktop compatability, that would be a great help, but it would still limit you to compatibility with existing Desktops Environments(DE) only, forcing you to recompile if a new DE ever came along. This might not be a major problem, since it seems most people are taking to either KDE or Gnome, but you'd still have to recompile if there were ever any major feature changes to one of the DEs. It'd be nice if some sort of system could be developed that would allow IDEs like Kdevelop to create apps around a central registry - not totally unlike the MS registry system, but different in that KDE and Gnome are two totally different DEs, where as Windows is a single desktop that can simply be configured in different ways. What I am thinking of would work at a much more fundemental level than the MS registry (I think - I'm really not all that familiar with the Windows registry) You could simply have a single file listing the libraries that an app would need to load at runtime in order to be compliant with the DE that is currently being run. If any major changes were made to future versions of that DE, or if you ever installed a new DE, those changes could simply be made to the registry file.
Any comments on this? I'm curious as to whether or not this is workable.
Roses are red, violets are blue. I'm a schitzophrenic, and so am I.
Your not absolutely dependant on javascript or jscript or whatever. It can all be accomplished through server side scripts and a cookie or two.
Old truckers never die, they just get a new peterbilt
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...
Do you care how well it works & does java applet based systems count?
penguinicide... when jumping out a window just won't do.
No matter what you do it would be a good idea to adopt an MVC (model-view-controller) architecture. However, depending on the flexibility vs performance requirements of your application, there are a vast number of possibilities in implementation.
If performance is key, then use MVC to separate your Gnome and KDE code based on some compiler flags.
If flexibility is key (and this is more my area of expertise) then package the application into CORBA or EJB components. This will allow you to select from multiple GUI interfaces (standalone, applet, or HTML) depending on the client type or location. The cool part is that you can use them all interchangably and/or at the same time.
Personally, I vote for a JCalendar...
This post is not to support any one window manager. On the contrary, it is intended to promote good sense. I can't see why you would limit your "clientele" by catering to any one or two window managers. Why not write your app so it can be used by anyone, whether they use Gnome, KDE, FVWM, Blackbox, WindowMaker, ICEwm, or whatever other window manager a person chooses to use? A well designed program should trancend the petty squabbles over which manager is the best. If you really want your program to reach the most users, remember the old KISS rule. If, for example, you write your program for X, and Joe happens to run M and it doesn't work under M, do you think he's going to switch away from his beloved M that he's been running for years just for your program? I doubt it. If it's a decent program, try to make it available to our whole community, at least to start. Then the community can help you make manager-specific ports. That's what this whole Open Source thing is about!
See: XPFE homepage for more info.
-Chris
Python uses Tkinter.
I think you're the only person out of the whole crowd that really "gets it".
Linux may be a great server, and fabulous bang for the buck, but the desktop currently is *hopeless*, and two competing desktop GUIs will make sure it stays that way for many moons.
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 thought that I read somewhere that Netscape was going to use GTK in future versions anyway. Does anyone know if that is right?
AussiePenguin
Melbourne, Australia
ICQ 19255837
Jeremy
Melbourne, Australia
Jabber Australia
Guys I've run dozens of apps between the two so cut the crap.
The message on the other side of this sig is false.
The shame in the duplication of applications is that the KDE and GNOME teams could probably collaborate on toolkit-independent back-ends, and only implement the graphical front-end with the toolkit of their choice. The result is that while, there are for example excellent mail programs such as mutt or pine (or gnus) on one hand, programs such as kmail are cute but do not come anywhere close in functionality.
There are many subtle issues regarding user interface, and it's very hard to keep faithful to two different sets of conventions regarding mouse gestures, control focusing, and expected app behaviour under all circumstances. That said there are some reasonably successful cross-platform apps : Adobe Photoshop, Macromedia Freehand, and SoftArc's FirstClass come to mind. AFAIK none of them was written with a commercially available crossplatform toolkit - each company preferred to roll their own.
I've looked at the cross-platform stuff in Mozilla and was, frankly, scared off by the complexity... or rather, I've got better things to do with my neurons than trying to understand how Mozilla does it, at least at this time.
My coding on UN*X-like systems has always been limited to command-line stuff; I feel that unless someone hammers out a common standard GUI for Linux, at least on the API level, none of the Gnome/KDE stuff will really catch on, or at least become a commercial threat to Apple or Wintel. My personal feeling would lean towards GNUStep...
There is now, I've been looking for something to code, I'll start on this tomorrow, kdentdev@hotmail.com for any interested parties, and BTW, when can I give out japhar81@slashdot.org for an email? I'm stuck using a M$ portal cuz of hotmail...
This is just my perspective, so take it with a grain of salt.
In order to code for both desktops, you have to look at what they are each built upon.
GNOME -> GTK+ -> X
KDE -> QT -> X
Ok that's really simplified and leaves out stuff like imlib. But you get the idea.
GTK seems like an acceptable level to work with. Why? Well, GTK is required in order to use the GIMP, which many people have on their system. I can't think of an app as popular as the GIMP that is written for QT (besides KDE itself).
So there are probably alot of KDE systems out there that ALSO have GTK installed. I think it's less likely that a given GNOME machine will have QT installed.
Of course writing for GTK doesn't get you alot of the cool features for a particular desktop. I agree that it would be nice if there was a better cross-desktop development tool.
Another $.02 for the pot,
SEAL
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.
html/jscript etc is a basically unusable dev environment for a lot of applications. the biggest problem is statelessness. the second biggest problem is javascript bugs - you absolutely must not depend on javascript. (part of the problem with jscript is that a user isn't required to be using it - any validation you do in javascript you have to duplicate on the server side). the third is bandwidth.
we'll need to move beyond the web before we get there. an internet app toolkit with the strengths of the web would be just fine.
FWIW I'm a senior web developer with plenty of apps behind me.
Well, in my opinion both suck. who needs either one. Gnome is buggy and KDE is ugly as hell. both have that gay start bar type thing. if i wanted that i'd use windows. however, it is good that they are being developed because in addition increasing the number of choices you have with *NIX, it is making it easier for the average user, such as my little sister or mom, to use a superior operating system. but until gnome or kde has some feature that actually increases my productivity, i'll stick with windowmaker. It would be nice if the two different camps would get together and agree to some standards. whatever Andrew
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.
---
Ports are available for Win3.1/9x/NT and GTK/Motif/Lesstif. A Mac port is underway and ports to Qt, BeOS, OS/2 and more are "under consideration."
Liscensed under LGPL.
A more general question: Is there a good way of writing GUI based apps that are at least source code compatible across multiple platforms (e.g. unix, mac, windows)? Java is one way, are there any others? And preferably free.