ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
GTK is indeed cool and relatively simple.
However it is not universal and it requires GCC and pkg-config. I would like a code that does not alter with time, whatever version of gtk, and does not pass by compiling. I know that compiling make the app faster, but however after years, one have to maintain it and I may provide no support for that.
I would like a code that does not alter with time, whatever version of gtk,
You're asking for the impossible. Compilers and toolkits will change, languages will evolve, new tools will appear, old tools will be forgotten and your code will become obsolete/unsupported by newer tools. "It too, will pass". You should get used to the idea.
http://doc.qt.nokia.com/4.3/tutorial-t1.html
If by "output" you mean "button", then you can create same thing in pretty much any GUI toolkit in any language. Do a research and pick your poison... err language+toolkit you're most comfortable with.
There are language bindings to most GUI tool-kits for most scripting languages. Pick the combo that you like.
Currently popular scripting languages: Python, Perl, Ruby. Currently popular GUI toolkits: Tk, GTK, Qt. I'm certain there are others in each category.
The choice you make now will have little impact insofar as hedging against obsolescence. Java comes with fairly portable graphics, and might have the longest viable product life, but is compiled.
python is likely not to work with time.
qt remains likely to work with time, but must be installed. so not "universal" (let's say)
and gcc needs compiling
gambas : is simple but needs to be installed
gtk might be more universal, but it is not installed on all machines: the compiling stuffs
you cannot distribute your code, and that it will surely work cuz users will have to compile it..
bash works in any cases and needs no compiling, but bash has no GTK gui
awk and bash are mostly installed on any linux box
GTK also needs to be installed. You do know it is cross-platform, right? However, it is not a standard windows component, and it is not guaranteed to exist on linux system. By the way, you can statically compile QT application (Opera works this way), but you'll have to release it under opensource license (or you could buy commercial qt license, which is expensive), and you'll lose some functionality.
Quote:
Originally Posted by Xeratul
another way would be perl, perlgtk, but perl is also quite particular.
python is likely not to work with time.
Same applies to perl, java, python or any language or toolkit you could possibly think of. They are all optional components that may not be installed.
Quote:
Originally Posted by Xeratul
don't know ...
As I said, you're asking for the impossible. There is NO compiler, NO language, and NO gui toolkit that will work everywhere. Every interpreted language depends on optional component that may not be included. Every library may be missing from the system. And compiled languages requires compatible CPU, specific OS, and certain set of libraries. In the end you can't even be sure that the target system is capable of displaying GUI, since that requires X, which is also optional component that may be missing. Linux system isn't even guaranteed to have a display, mouse or keyboard, by the way.
Your problem does not have a solution.
You should select your target audience and act accordingly. On Windows, distribute dependencies along with application within installer. For linux system with package manager, provide information to package manager so it will be able to download/install missing libraries. For linux systems without package manager, provide instructions for the user - list dependencies, and tell where they can get them.
There's no other solution.
Also, I'd recommend to use toolkit you're most comfortable with instead of the toolkit that is most popular - this way you'll be able to develop application faster and fix bugs faster. It makes sense to use something like QT, because you'll be able to compile single source for multiple systems.
By the way, you can statically compile QT application (Opera works this way)
Just a side point (I know it is a off topic) but Opera doesn't work that way. We are not a Qt and have not depended on (or statically compiled in) support for Qt for at least 8 stable releases (maybe more, I'd have to check).
Opera uses its own toolkit but can optionally use Qt libraries or Gtk libraries purely for styling. If they aren't there it will run just fine.
But back to your point, yes it could be done and we did do it once, a long time ago.
P.S. In case it wasn't clear. I work for Opera.
Last edited by ruario; 10-27-2011 at 10:56 AM.
Reason: mentioned I am an Opera employee
We are not a Qt and have not depended on (or statically compiled in) support for Qt for at least 8 stable releases (maybe more, I'd have to check).
(curious) Was there any particular reason for ditching Qt? I mean - technically, making yet another toolkit is reinventing the bicycle (And if you did it - it might mean you have run into a problem with Qt).
(curious) Was there any particular reason for ditching Qt? I mean - technically, making yet another toolkit is reinventing the bicycle (And if you did it - it might mean you have run into a problem with Qt).
Have a read of these two comments by a colleague of mine from a couple of years back when were first working on this. Things have moved on a fair bit (and Opera without Gtk or Qt looks a little nicer than in the screen shots) but they should still answer your questions.
EDIT: Before you read, I just want to clear up two things. Peregrine was the code name for the last Qt version of Opera. Evenes was the code name for first that didn't require it.
EDIT: Firefox is not a full Gtk application either. They also use their own toolkit (XUL) and presumably use similar methods to appear to be Gtk native. The extra couple of tricks we have up our sleeves are that Opera can also do Qt/KDE themeing in addition to Gtk and secondly we can run without either of them. This means that Opera will run on a much more stripped down, bare bones system than any of our major competitors.
Last edited by ruario; 10-27-2011 at 02:32 PM.
Reason: added some information about Opera code names and compared the situation with other browsers.
Have a read of these two comments by a colleague of mine from a couple of years back when were first working on this. Things have moved on a fair bit (and Opera without Gtk or Qt looks a little nicer than in the screen shots) but they should still answer your questions.
Ok, understood: most of features provided by Qt weren't utilized by app, so you decided to remove extra dependency, since there wasn't much of a benefit from it. Well, that makes sense.
Ok, understood: most of features provided by Qt weren't utilized by app, so you decided to remove extra dependency, since there wasn't much of a benefit from it. Well, that makes sense.
Well, I still have doubts that QT is nowadays the most found or universal. Actually indeed, there is not so much other choices.
Maybe in few years, a new code will appear, quick compiling, flexibility of compiling or not for distributing, not so much issues with versions and dependencies... - well, as said above, that's impossible. -But why not?
Actually, I always like Borland C and other C. I find it very well built, since so many years. This code is beauty. It is like quantum physics. - Well made, the perfection of matter.
Well, I still have doubts that QT is nowadays the most found or universal. Actually indeed, there is not so much other choices.
"most found" != "most universal". With Qt you can deploy to multiple platforms using same source code. That's good enough for me, plus (IMO) their gui classes are mostly "done right".
Quote:
Originally Posted by Xeratul
Maybe in few years, a new code will appear, quick compiling, flexibility of compiling or not for distributing, not so much issues with versions and dependencies... - well, as said above, that's impossible. -But why not?
In a few hundreds or even thousands of years, maybe - to develop something like that and turn it into standard you'll need cooperation of large number of people and companies.
<html>
<head></head>
<body>
<p><button>Hello World</button></p>
<script type="text/javascript">
// event handlers go here
</script>
</body>
</html>
(No, I'm not trying to be a jerk. Write and deploy your app as a hosted web application, and it will have run on more platforms than any desktop app. This is what software-as-a-service is all about).
Of the desktop GUI toolkits, it's impossible to determine which one is the "most universal" or the "most found". However, Swing is a standard part of Java and TKinter (TK) is a standard part of Python.
Rather than trying to determine which platform is the "most universal", you should be doing what everyone else does, which is balancing the factors of which specific platforms you want to support and which toolkit is the most appropriate for the technical needs of the project. Once you do that, you will probably find that Qt comes out quite nicely.
Last edited by dugan; 10-28-2011 at 10:57 PM.
Reason: Left out the c.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
