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.
What I would like is just some sort of wrapper for QT apps that lets them use GTK themes. And vice versa. Thats about the only thing that annoys me about running GTK apps under KDE and KDE apps under a non-KDE WM. Is there any such thing in existance? Or in development?
I use kmail with Gnome. No problem, I just had to install the libraries (qt-1.44 in that case).
The idea is that it should run on either, cuts down on the number of potential bugs that happen from two different codesets. I know about #if, but it is still seperate code.
Now if there was a very thin abstraction layer....hmmmmmm....that's an idea. :)
Bill Silverstein
hehehe I found your perl humor to be rather funny... which is rather said that I am laughing at this stuff... on another note .. it sounds like you are talking about adding another layer on top of kde/gnome. It is an interesting idea but both kde and gnome are a bit slow (IMHO) It would be better if there was a way to intergrate the two at a more base level.. sort of like provide wrapper interfaces to each other.. ie qt wrappers for gtk and gtk wrappers for qt.. althogu I do not see this as being possible..
I'm not a Smalltalk programmer, but your advice is perfectly appropriate no matter what language you choose. Unless speed is absolutely critical, it is always good practice to encapsulate the various interfaces of your application.
I personally like wxWindows, which works for Unix, Win, and Mac (although the mac port seems to be a bit behind).
There's a list of many cross-platform toolkits here.
Who says HTML (and/or the rest of today's web-based platforms) have to be the last word.
HTML's been in broad use for what, 4-5 years. Is there any rule that says there can't be a new technology developed that makes it a snap to develop REAL apps that run over the net instead of the pretty, but minimally functional apps of today.
I mean, Slashdot comment form I'm now typing into is about as good as input gets in today's web apps, and it's pretty primative.
So, NET-BASED apps, yes. But not necessarily WEB-BASED. Let's all start thinking about and building a platform for the future.
You do have a point - KDE basically sucks. It's a cheap looking rip-off of Windows, IMO. The widget spacing is too far apart on toolbars, the buttons seem to 'fat' for my tastes, etc...
'KDE is ugly as hell' True.
Maybe you need to think a bit more about how you say things.
I've used both and now use GNOME or WindowMaker. No KDE in my world.
Both sound pretty similar, and you could just use macros / #defines like this: #ifdef USE_KDE #define MyWindow KTMainWindow #else #define MyWindow G_Main_Window (or whatever it is) #endif I've thought about doing something like that, but instead I'd love to write a C wrapper for QT because some GNOME people can't do without the Most Holy Language C. :( Personally, I think that Gnome has some nice bindings, but developing for a wrapper, like GTK--, can be annoying.
Here here! I still use a simple TWM variant (CTWM, if you must know). Fast, stable, and no bloat penalty for icons, and other useless clickety click things.
Creating an abstraction layer has already been mentioned before in previous posts. For more information take a look at the Abstract Factory design pattern in "Design Patterns: Elements of Reusable Object-Oriented Software"
You should try the new 1.1.2 version of KDE. The themong capabilities are much improved, and the icons look really neat now.
KDE 2 has a more MACish look as a default, and is extremely configurable...
Try the Beta (if you have >=128mb ram...)
I like the fact the someone is facing same problem as me. I am currently porting my most importatn application (Arachne WWW browser) to Linux, and I want to have both fullscreen (SVGAlib) and X11 version. But I don't want to write the X11 version twice for GNOME and KDE. I am usually running KDE as main desktop, while GNOME panel is (drag'n'drop create ;-) link in my Autostart folder. I like many of GNOME features, but my general feeling is that console version of Midnight Commander is much more powerful and stable than gmc. I miss some features of mc in kfm, so I basicaly use konsole (xterm) with text mode Midnight running all the time... Basicaly, KDE is more consistent: when deciding between gdm and kdm for our office network with dedicated X11-based application server, we had to choose kdm, because gdm was refusing xdmcp conections. I also experienced much more GNOME instabilites and crashes... but I hate the fact that I can't use Enlightenment in KDE. Etc, etc. I feel like victim of "desktop war": I want to fight with Windows ! I don't want to join any party in KDE vs. GNOME war. I am using KDE just because it works slightly better and its longer around, so I have learnt lot of tricks; GNOME looks promising, but it was not completely translated to Czech language, etc.
click on "Widget Themes"
Stop spreading FUD. You can write an app with whatever goddam toolkit you please, and it will run FINE under both KDE and GNOME. It wont have the same look/feel, but it will interpoerate (DND and everything) with all of it. Do you think netscape is a gnome or kde app?
I code KDE/Qt daily and it is by far the most flexible toolkit I have used...
Well, he has a point. GNOME apps often don't offer much more than pure gtk apps, while taking up more RAM and compile time. In most cases it would be sensible to make GNOME linking a compile-time option, if you use it at all.
KDE currently offers more "added value" to Qt that GNOME to gtk, and is more stable. So the memory toll is acceptible more often IMHO.
The poster of those comments is right. The web is the interface. GTK and KDE are simply linux answers to the 80's "widget-centric/shrink wrap/CD-ROM distributed" paradigm pushed by Microsoft.
Sheesh people, be a little more open-minded.
And Linux if the future of Unix.
Realistically, you have two choices. Both will cause your application to be mildly Gnome-centric, but such is life: - Use WxWindows. It currently only supports GTK, but a Qt port is in the works. - Use GTK. KDE has partial support for GTK, in that it can pass it's themes along onto GTK apps. You'll have full Gnome support and partial KDE support (the reverse isn't true; because Qt is proprietary, Qt-apps are not at all friendly towards Gnome). Most of the other features (not related to look-and-feel) are gradually becoming compatible between the two systems.
People bash web based apps for lack of speed, or primitive controls....However, if the task is to go from version 1.1 to version 1.2 of any application on all 6000+ desktops in 28 states -- Thin Client (web based app) is the way to go!!
KDE has by far the most users, even with RH slamming them, and it's V2 version is much further along. Gnome is dead.
Check it out :)
You can use KDevelop and cuteIDL to whip out an app that uses the easy to use KOM model and have your app CORBRA aware with a minimum of programming knowledge or, you could use Gnome Bonobo which is a nightmare to program in and is hardly functional as of this writing.
I read the WxWindows mailing list and no one has talked about it in ages.
KDE is free software and one of the developers is implementing importing GTK themes.
1) remove gnome.
2) remove enlightenment.
3) remove KDE.
4) remove KWM.
5) install gtk development libs.
6) install xfce window manager.
7) install code crusader, code medic and glade.
Now use the binding of your choice to use the GTK widgets. Unix has always been about small, elegant, "atomic" things, and against bloaty code written by people who want to control your machine.
KDE and Gnome are fighting over the desktop. Just turn your back on them and follow the roots of unix -- small is beatiful.
Plus, if you want to develop commercial apps or don't want to release your source code, this also lets you avoid paying Qt/Trolltech $1550 per developer.
glade is the most "immature" of the bunch, and I look forward to seeing some improvement in that area -- everything else works pretty smoothly.
Good luck, whatever yur choice.
Supposed to not only be much faster and smaller, but allow cool things like writing applets that can be dragged and dropped over applications (not just document views).
Slashdot has gone downhill lately, especially within the last year. I must say here, it is becasue of extremely narrow minded posts. What the person here is asking for is for the best way to write an application that will compile with both GNOME and KDE, not "What DE should I write for" or "What is better, KDE OR GNOME". All the arguments here have been seen way before and aren't even interesting anymore. If you don't like it, don't use it! Don't mindlessly post about how bad the other thing is, especially if you even haven't contributed any code. If you want to further something, go write some code, or think of new ideas that can make it new and innovative, not sit here, reloading Slashdot waiting for new posts that you can flame to popup. It's been pointed out a while ago (probably long enough for me to restate it again), only the do-nothing users sit and scream, anyone thats developing has better things to do and probably can admire other things for their good points instead of screaming to the other things users about all of its bad points; most people I know grew out of that when they were 8.
Brief Summary for those who care not to read:
Don't bitch about someone elses things, help make yours better.
and it was forced to be dropped. Now there is work on a from-scratch replacement called "KImageShop". See koffice.kde.org. As far as MS documents, Koffice can handle Excel and WMF, and people are working on word filters.
Talk to me when Gnome has a web browser, internet transparency, a office suite that works, etc...
Even RMS deemed Qt free software, and I bet KDE supports GTK themes before GTK support's KDE's - mostly because KDE themes have an effects engine.
Gnome is, and more people seem to use KDE so that seems to be the lcd...
People keep saying a port is in the works, but there is no mention of it on any of the lists.
In most cases by almost a year or more. So if you want to complain about people dupicating others work you know where to look.
This has been done. XUL is a GUI markup language that Mozilla uses. It's pretty cool--you can edit a couple line and completely change how your toolbars are laid out, for example. www.mozilla.org
Even the Gimp can be scripted though! Gimp-perl is a perl module that lets you control the Gimp from perl, for example.
"GNOME and KDE both *require* GTK+ and Qt, respectively, for all graphical apps." Netscape appears to be a graphical app. Dont split words, the TOP article poster was concerned that if he wrote a KDE app, gnome users couldn't use it, or vice versa. Then people begin the FUDDING, implying that KDE users can only use KDE, and GNOME users can only use gnome. The post I was replying to said that 'ALL GRAPHICAL APPS MUST USE THEIR TOOLKIT' This is simply untrue. Infact, if you search the gnome-devel mailing list, you'll find Miguel saying that you can even write 'gnome' apps without using GTK if you apps use gnome features (via a wrapper or CORBA).
# chmod +x /dev/null # /dev/null /dev/null bash: /dev/null: Permission denied # . /dev/null bash .: /dev/null: not a regular file # cat /usr/bin/emacs | /dev/null Hello Dave.
# chmod +x /dev/null /dev/null /dev/null: Permission denied /dev/null .: /dev/null: not a regular file /usr/bin/emacs | /dev/null
#
/dev/null
bash:
# .
bash
# cat
Hello Dave.
A gui should not be much more than a stupied interface. The trick is to keep the "business" functions separeted from the gui. This way you can pretty easily make your application use several gui's. Just my though on how a app should be written. Another important thing is to standarize the way config files should work. Ie, the user should have one set of bookmarks that can be used in both gnome and kde.
Aside from the desktop/GUI problem much of Linux itself is inconsitent (such as packaging and many other things.. except GUI is more noticable and more looked at since people think a desktop is a requirement for "world domination").
I'm not a naysayer of free software (or Linux for that matter), but I do believe some things are better at certain areas than others. Linux will never be consistent to the level required to beat out Macs, BeOS, and Windows (Unix by design is inconsistent.. with no standard way to access graphics, sound, or other needed things for a desktop. This is mostly the fault of C.). I really wish this pressure bubble (to create the best OS that everyone should and will use.. or they must die) would pop and coding would be fun again.
I wonder.. can a group of people working on free software accept enough ideas to be consistent? In GNOME I noticed many people pulling and tugging in different directions.. and many many features being implemented (many not needed). Or does it take a strong organization (meaning well looked over) to produce something somewhat consistent?
We have man pages and info pages. We have OSS and ALSA. We have tar.gz and RPM. We have GNOME and KDE. We have WindowMaker, Afterstep, E, FVWM (can I stop now?).
You should write apps for BeOS instead.
You should use TCL/TK. It works great with all of the desktop environments and it's powerful.
I understand people having a preference of C, C++, Python, etc. (My choice is up to me) But come on fellow programmers!!! We write programs for the USER! Not the Programmer! GTK is the leader-- as far as where it's at. QT of course, is great, but It's not something that we can even support (er.. $1500 for a license, when M$ Visual C++ is $1000) I say we dump all these stupid toolkits, port GTK to all the languages (And not as a layer, but as a complete port) and be absolutely sure that C++GTK (GTK++ :) and GTK+ and GTKthon or whatever silly name you can think of; err, make sure they are completely seamless in function. Everything has to look and feel the same! -- Everything!!! There should be no variation, I should be able to drag and drop anything anywhere. In fact, the KDE folks are expressing a great interest in dropping QT in favor of something more free. GTK-- (The current GTK+ C++ layer) is slow as hell! Show a little care for your OS, programmers, don't duplicate work, improve it! (Shameless bit of advertising: http://altair.dhs.org until I think of a better name)
Qt is put under a license meant to protect Troll Techs copyright and to make it hard for other developers to take pieces of Qt and use for themselves. The main purpose of the QPL was probably to kill of the harmony project, not to share the Qt code. Gtk and other (L)GPL'ed apps are put under licenses that are aiming to be Copyleft, while copyleft is not a legal term it means a lot when you look at the philosophy and goals of the license, and what rights and obligations it gives you and others.
Netscape 4.0,4.5 and so on use Motif. From version 5 and on it will use Gtk.
Any web interface is an unstable hack to keep state on a stateless protocol with numerous variously buggy and unreliable programs.
There should be a protocol for an app to send its toolbars, menu structures etc. to the window manager, and have that handle the displaying.
It'd make for a lot greater consistency in look and feel
It's not impossible, but you have to get hold of some pretty specific patches for the kernel to even boot, let alone work. Loads of swap helps too. Though quite why he has a K6-233 yet only 2Meg of Ram is quite beyond me.
No.
:).
However nice all those features you list are, but for sure non-ascii file is not easier, more reliable or faster maintain than a registry.
Having a registry means that you have to use a separate program to configure your system - having a ascii file means you can use your favorite text editor through ssh from anywhere on the globe (or even outside the globe
On top of this, one of the best things I love about Linux is that _I_ do know what's going on in my computer. If a program fails to configure itself properly I can always go and hack the ascii configuration file myself. If we move to a registry I can't do that.
And believe me: however good the registry implementation itself, there will always be badly-coded programs that mess up your registry.
Panu - not on my own computer and forgot my passwd
RMS thinks it free, ESR thinks it free, everyone thinks it's free, yet still people complain and come up with paranoid conspiracy theories even though Troll Tech supported free software development long before the QPL. You all need to get a life. It's free software, not proprietary.
I'm not a Mozilla developer or anything, but from what I've read about the project, it seems like when they're done we'll have a fairly complete cross-platform desktop environment. (And I'm not talking about "web interfaces" either)
After all, doesn't Mozilla include a cross platform GUI toolkit, a cross platform Component Model, and various scripting & programming language bindings?
I think the Mozilla project gets overlooked when discussing these types of issues because people forget that it's more than just a browser.
If anyone knows of any reasons why Mozilla wouldn't be useful for this purpose, please follow-up... but keep the flames low please. I'm not claiming to be authoritative.
A personal ideal [- redundant?] is to seperate the algorithm/function from the presentation. A good, general layer of encapsulation will make all of the difference between writing code that is tied closely to one environment and code that can be easily ported to any environment, KDE, GNOME, Windows, etc within reasonable limits.
For example, if you're writing a dictionary client [which connects to a dictionary server, such as gdict], one will assume that you have code sitting there that does one thing: Connect to the dictionary server, send the request, get the reply. From the presentation system, you need 2 things. 1. Get a word to look up. 2. Display the definition of that word (or the error message).
Would it really be so hard to write something that does this for both KDE and GNOME? Of course not. Toolkits make things extremely conveniant, but don't let your code bend around them.
The 'metatoolkit' wxWindows is trying to make this possible. Unfortunately the Qt toolkit is not yet supported. The main idea behind wxWindows is using the native toolkit on each supported platform. This means a native look and feel on each platform. On Win systems the GUI parts of wxWindows are implemented using MFC and on Unixes one can choose between GTK and Motif/Lesstif. A Mac version is in beta stage. BeOS and OS/2 port are worked on. The Qt port has been discussed lately on the wx-devel mailing list but I don't know if anybody is working on it. There is a simple 'stubs port' so creating a new port should not be too tough.
All we need is some skilled Qt programmers with strong interest in cross-platform work.
Yours
Jere Kahanpää
Actually, I think the Mozilla team has now ditched Gtk+ in favor of their own widgets that can be customized via CSS. Bastards.
We aren't talking about Gnome or KDE here. We are talking about the apps that run under these respective environments. It is possible to write an application that "does the right thing" by writing your own abstraction layer. So if you want to do a specific thing like dock your application to the tool bar you need to call the function my_dock_to_tool_bar(), the function needs to figureout what environment it is in and then do whatever is needed for any environment. Easy! You may need to link your code to both Gnome and KDE libraries, however. You can use whatever graphics toolkit you want to use. You can even write your own graphics toolkit to use if you want! Have fun.
1) You can drag from StarOffice into KFM because Star Division implemented it. 2) You can drag from Netscape into GNOME because the GNOME people implemented it. 3) You can't do any other drops because noone bothered to implement the interoperability. 4) Your "it's a URL, handle it!" shows your utter ignorance on the subject.
You assume too much.
I dislike the registry because of the fragility it imparts to the whole system. It is tantamount to putting all your eggs in one basket.
BTW, I'm not against Windows on ideological grounds. Their system would be pretty slick if it worked. But over the course of the past two years I've spent far too many WEEKS trying to reinstall Windows in a stable configuration on different machines. My complaints about the system are based on bitter experience across a whole range of hardware and software configurations. Their way of doing things is inherently unstable rom the ground up.
The strength of *nix is that the different parts of the system are completely independent. A screwup in one subsystem doesn't usually bring the whole system down, and the ascii text configuration files are easy to understand and fix. It might not be elegant from a theoretical standpoint, but it works very well.
If you don't like the way things are done on *nix, then just go back to Windows. But don't think for a minute that the rest of us will tolerate seeing Linux ruined by the same blinkered theoretical approach that has ruined Microsoft's OS.
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!
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?
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).
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.
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.
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
---
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.
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...
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.
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?
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...
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.
oops sorry for the exclamations...
dont write for KDE, dont write for Gnome.
the env to target for is CDE, the Common Desktop Environment. Think past the Linux box, CDE targets pretty much any Unix type OS and is pretty damn usable.
KDE & Gnome are divisive. CDE is inclusive - Linux, *BSD, Irix, Solaris, AIX....
stty erase ^H
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...
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
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.