which linux distro is easiest to write a gui program for?
I would like to write some multi-document, multi-window applications.
Which linux distribution is best (i.e., easiest) to do this in? (Things like what language to use or what tools to use are irrelevant to me, and i don't need an IDE. But what i do need is some idea of the right libraries to use. And it would be surprising if all distros were equally friendly to developers, although maybe that's the case.) TIA for any info. dan |
I think it is not distribution relevant, rather Desktop Environment and Window Manager. I only known KDE and Qt libraries and can recommend to you, but also there is a GTK used mainly on GNOME.
|
As eSelix already stated, this is not a question of the distribution, but of the toolkit you want to use. The most widespread are GTK and QT. There are also others that are not so widespread, but I would focus on QT or GTK, since there is the most documentation for them.
|
Thanks eSelix and TobiSGD.
For reference, eSelix said that desktop environment and window manager were the most important factors rather than distribution, and TobiSGD said the most important factor is the toolkit you want to use. It's easy to believe that you are both exactly right, although it is a little counterintuitive --- because, after all, if a distro has a particular look-and-feel or any special features, it would seem like it would provide some means for to let programmers tune for it. And it also seems a little surprising that all distros would be equally easy (or difficult) to program for. (I mean, it sounds like there's some redundancy among the distros in that case.) But you are probably right, so given this, then, what desktop environment, window manager, and toolkit combo would be easiest to program for, and why? I'm aware of qt and gtk, and also that there may be long-term issues with qt due to changes at nokia. Are there other toolkits that i should investigate? And what about desktop environment/window manager? My goal is to write multi-document, multi-window applications, sort of the way you can on the mac. I don't need an IDE, but would like to know the easiest path in in terms of libraries to use. Portability to non-free platforms is not much of a concern for me. What requires you to construct as little infrastructure yourself as possible (that is not directly tied to your subject domain)? Thanks again for your replies and thanks for any further info. dan |
Quote:
The choice of toolkit might influence your choice of desktop, either to have a desktop that is behaviorally more similar to the applications you are developing (reduce your own learning curve) or to reduce resource use on an under powered computer (more code sharing between desktop and your own work). The choice of desktop usually influences the choice of window manager, but that is a minor detail you don't really need to worry about. The choice of desktop might influence your choice of distribution. You can use either (or other than the two main choices) desktop with almost any distribution. But by selecting the default desktop for the distribution you make that distribution's documentation more understandable and you can get better results from forum support for that distribution. So if you choose the Desktop first, you may then be best to choose a distribution for which that desktop is the default. Quote:
Quote:
|
Quote:
Quote:
Quote:
|
Quote:
Quote:
Quote:
|
Quote:
I have used applications in KDE and Gnome that were based on the other's toolkit, so by the above logic (in each direction) the application did not "fit". Those applications worked just fine and I didn't notice any appearance issues. It makes sense that themes can't apply properly (if at all) to an application from a different toolkit. But whether that matters is a separate question. |
I meant the pure optical part (I use XFCE with a black theme, and since I didn't fiddle with the QT theme yet QT-apps come with a light grey theme), of course they will work as intended.
Quote:
|
Quote:
|
Quote:
|
Quote:
Quote:
|
Quote:
Actually John, the reason i am on this quest is because of emacs. emacs is the most powerful tool (i guess apart from the compiler and debugger themselves) that any programmer can use: you can have hundreds of open files, dozens of shells, compilations, and gdb sessions running at once, and easily transport text from any of them to any of the others. But it is not as universal as i thought: on some very nascent systems you apparently have to work quite hard to get it installed. And that is my dilemma. There is one free OS that i am very interested in, because it has a good application model: the system comes with a good library of classes representing windows, events, applications, etc. The system itself provides intelligent menus so there's a consistent user interface. There's lots of documentation available. In fact, it reminds me of NeXTstep. Not in appearance, because that is different, but in terms of intelligent design, so to speak. And i can also install it on my hardware. I think in fact that this system might be easier to develop on than a mac, although i cannot say for sure because i ran into an obstacle. The one respect this system is lacking in is that emacs is emphatically not bundled with it. And although there certainly are emacs packages for it, it looks like it will be some slow sledding to make emacs functional on it. Emacs is as deep as it is powerful, and so i'm very hesitant to embark on what could be an open-ended, unbounded effort to get it to run. And, if i do, the next rev of the OS may well break it. The situation with GNU/Linux is nearly the opposite. It installs easily, and although for whatever reason some systems do not ship with emacs (how can it be that a linux system doesn't ship with emacs when the mac does?), you can always get a package for emacs, and mindlessly install it. So the infrastructure available for GNU/Linux is immense and highly functional. But afaict, the only possible windowing system you can get is something layered on top of X. And it seems like developing a multi-window, multi-document application involves a definite learning curve, and it is also not clear what's at the end of the curve (whether, for example, you'll get lowest common denominator effects). I would like to avoid that curve if i can, which is why i put out this query. And of course i could be wrong about any or all of what i've written regarding GNU/Linux (or anything else, for that matter), so i'm all ears for corrections, or pointers to the fine manual, or any other suggestions. And thanks everybody for all the info so far, which does include several leads that i should look up. dan |
most programs DO NOT have the ability to build a QT and a GTK , or glut interface and in to it a windows and mac osx interface
pick one get used to it then add additional support the one program that i am very familiar with is Celestia it uses gtk2 or glut or qt4(was qt3) however glut and gtk were the first it ran on mac,windows and any linux os with gtk installed and QT was added later ( second class citizen ) QT4 will soon be the default replacing gtk nothing lasts gtk2 has some very nasty resource issues that 3 should mostly fix but qt handles very large data sets better gimp is moving away from ( the Gimp Tool Kit [ gtk]) start with something that FITS your current needs then grow it . start with a good stable OS opensuse 11.4 KDE is opensuse using Gnome -- not so gnome2 crashes all the time and Gnome 3 ??? you like it or you DO NOT like it . I would NOT use fedora - it requires A LOT and i mean A LOT of work on YOUR part to keep working rhel6.1 or ScientificLinux 6.1 good stable but not very new versions of programs both Gnome(gtk2,3) and KDE (qt4) have some very nice ide tools for rapid deployment both have built in code for a window and adding options to them try them out then decide |
Quote:
Code:
int main() Quote:
|
Quote:
This is a good example which i should at least try to pursue further (to see, e.g., what support QT has for organizing the windows you create, etc). If doing the same sort of thing is as easy in gtk (any version), i would appreciate from anybody who feels like it is absolutely trivial to do, a short chunk of example code like this. (But i'm only asking if it really is easy to whip it out---i do not want to ask anybody to do something that is a hassle to write up, as i don't mind looking it up myself. But if it is equally trivial in gtk and obviously so, then i would appreciate knowing this.) Anyhow, thanks everybody for all the ideas and suggestions. dan |
Quote:
This works perfectly for me…VirtualBox, for example (whose GUI is Qt-based), blends in perfectly with everything else. |
Quote:
|
All times are GMT -5. The time now is 01:24 PM. |