Ruby with Qt or GTK ?

[Luiz Macchi]

Hi all ! I´m learning Ruby and need to develop in GUI interfaces !
What the best way ? Qt or GTK ?
I´d like to hear your opinions !
thanks a lot !

 

[gregarican]

I'm sure you will get a variety of different takes. There are a few
items that are worthy of considerations, such as:

o - Do you prefer working with a lightweight or a heavyweight widget
set? In other words, some widget sets go down to the "bare metal" while
others sit atop the native OS widget set as a wrapper.

o - Are licensing terms a concern? Qt isn't totally 100% free, open
source software if you are using it for commercial purposes.

o - Do you feel more comfortable working in a more OO widget building
environment? If so then Qt seems _to me_ to be more in the spirit of OO
than does GTK. Qt is rooted in C++, where GTK is rooted in C.

o - Are you looking for GUI builder helper applications to assist you?
If so then GTK has Glade and Qt has Qt Designer. And these helper apps
have varying integration into Ruby, Python, etc. programming languages.

The first thing I would do if I were you is to browse some of the
sample Ruby source code that shows how to build basic "Hello, World!"
GUI apps using Qt and GTK. See which feels the best and fits in with
your way of thinking the best. For me, with all of the bullet points
above considered, I went with Qt. YMMV depending on your expectations
and preferences.

 

[Vincent Fourmond]

Hello !

o - Are licensing terms a concern? Qt isn't totally 100% free, open
source software if you are using it for commercial purposes.

This is false. Qt is licensed under GPL.

Vince

 

[Vincent Fourmond]

No, Gregarican is right, Qt is not free for commercial applications but
free (GPL'd) for non-commercial / OSS applications.

Well, let's put it this way: Qt is dual licensed, one is commercial,
one is GPL. So it *is* free/open source software. But I agree that you
can't really build commercial applications with a GPL license. I was
merely pointing out what seemed a terminology mistake.

Cheers !

Vince

 

[ZeD]

I read this earlier and wondered about it. Can a company really release
software under the GPL, but place restrictions on its use like "no
commercial applications"?

no, infact Qt *don't* make such restriction.


qt are dual licensed: GPL XOR a-NON-GPL-one (don't remember the name)

if you use qt in GPL, by license, your code must be GPL'd

if you use qt in non-GPL-license, you must pay (don't remember how much)

 

[Tom Pollard]

I read this earlier and wondered about it. Can a company really
release
software under the GPL, but place restrictions on its use like "no
commercial applications"? Do they have that right? I thought the
entire
point of GPL was to make the source available to anyone, for any
purpose,
and the recipients would have the same rights and obligations as the
originator (like publishing their own source).

Someone using your software under the GPL does not have the right to
use it for any purpose.

Releasing your software under the GPL does not impose any further
obligations on you.

As the author (or, copyright holder) of a piece of software, you can
choose to release it under different licenses to different people.
Choosing to release your software to someone under the GPL in no way
restricts your right to release it under a more limited license to
someone else, or to stop releasing later versions under the GPL at
all. The GPL just restricts what someone using your software can
legally do with it. It's still your software.

(Waiting for someone to correct my overly broad assertions....)

TomP

 

[Amos King]

Someone using your software under the GPL does not have the right to
use it for any purpose.

Releasing your software under the GPL does not impose any further
obligations on you.

As the author (or, copyright holder) of a piece of software, you can
choose to release it under different licenses to different people.
Choosing to release your software to someone under the GPL in no way
restricts your right to release it under a more limited license to
someone else, or to stop releasing later versions under the GPL at
all. The GPL just restricts what someone using your software can
legally do with it. It's still your software.

(Waiting for someone to correct my overly broad assertions....)

TomP

I think Tom is entirely correct. I took an Intellectual Property Law
for Computer Science class and that is the same conclusion the
instructor(a patent lawyer and comp sci.) came to.

Although QT has gone a little further. The libraries that are used
under the commercial license are slightly different. Really what
makes your product compiled with QT different is the libraries used to
compile(commercial or GPL). You can develop under the free version as
long as it never leaves your development enviroment in that fashion.
This includes demos of the software. Everything beyond the
development phase must be done with the commercial versions of the
libraries.

I had first hand experience with this. A friend wanted to develop on
MAC, but wanted to deploy on Windows. I helped him do a lot of
calling and research with this. After talking to a lawyer and the
people at TrollTech, we found that as long as we didn't compile the
production versions on the MAC and as long as we didn't use the
non-production versions to demo to potential buyers we had not
violated any Licensing.

Sorry about the tangent, but I thought it might help.

 

[Eero Saynatkari]

--cYtjc4pxslFTELvY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Vincent Fourmond wrote:
=20
=20
I read this earlier and wondered about it. Can a company really release
software under the GPL, but place restrictions on its use like "no
commercial applications"? Do they have that right? I thought the entire
point of GPL was to make the source available to anyone, for any purpose,
and the recipients would have the same rights and obligations as the
originator (like publishing their own source).

This is going OT but it has to do with copyright law and licencing.
They have a right to licence the code however they please--and the
licence is actually two-part:

1. If you have a commercial application, you must use licence A
2. If it is not commercial, you may use licence B

So even though B may allow commercial applications by itself, the
licensee has already agreed to not use it commercially because that
is the only way they can use licence B.

And I could certainly be wrong. I pay much more attention to programming
issues than legal ones.
=20
Also, AFAICS it isn't true that you can't create commercial applications
using GPL code. You just have to trust that people won't steal your work.
Sometimes this is a legitimate placing of trust, sometimes not.

You can create commercial applications with GPL, you just must
make the source available.

--cYtjc4pxslFTELvY
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFFGtJe7Nh7RM4TrhIRArtEAKCykONXSc5xEhHTWF1ByKssn+QQNACdEHIv
cbG3F3snWbRC5xmxXzVrlhQ=
=h5kb
-----END PGP SIGNATURE-----

--cYtjc4pxslFTELvY--

 

[John Gabriele]

Someone using your software under the GPL does not have the right to
use it for any purpose.
then:
[snip] The GPL just restricts what someone using your software can
legally do with it. It's still your software.

That sounds incorrect. You, the user, can use GPL'd software for
whatever you like. For example, you may build proprietary software
with gcc if you like.

The GPL has to do with distribution -- it talks about the rules you
need to follow if you want to *distribute* GPL'd software. It has
nothing to do with what you *use* it for.

You can download some piece of GPL'd software, modify it to your
heart's content, and then keep the code secret if you like. If you're
a company, you can use your modified copy in-house and never release
your changes to the public. However, if you *do* release your changes
(say, by distributing them to one of your customers), then the GPL
kicks-in and says you must supply the source also.

If you use Qt to build some cool GUI program, your program is not
automatically GPL'd, but it is, however "a work based on" Qt; aka, a
"derivative work" (since your program links to Qt). Now, if you then
begin to sell or otherwise distribute or publish your program,
TrollTech (the copyright holder of Qt) says (via the GPL) that you
must at that point provide it under the same terms as Qt itself (the
GPL).

As Tom points out, the copyright holder may, at any time, re-license
their code as they see fit. If version 1.2.3 is GPL, they can
re-release that version (or release later versions) under some other
license But if a user downloaded v1.2.3 when it was GPL'd, then I
think that particular snapshot is forevermore GPL'd.

Anyhow, I believe this is the main reason the bigger players prefer
GTK+ (which is LGPL'd) to Qt (which some argue is superior to GTK+).

As a general point of interest here, note that Ruby itself is
currently dual-licensed (GPL (no version given) and Matz's own terms
(very similar to the artistic license)).

---John

 

[gregarican]

Another tool I use has a similar dual licensing scenario. Cincom
VisualWorks Smalltalk has a free non-commercial version. It is intended
to be used to personal/educational development and not for creating
commercial applications. It is fully functional as is the case with Qt.
OTOH if you intend to use the product for commercial purposes you must
purchase the commercial version of the software. You can't learn how to
use, develop some test projects, etc.in the non-commercial version and
then turn around and purchase the commercial version if you are
satisfied and want to sell and distribute the final product. They are
totally separate and can't be combined.

 

[Tom Pollard]

Someone using your software under the GPL does not have the right to
use it for any purpose.
then:
[snip] The GPL just restricts what someone using your software can
legally do with it. It's still your software.

That sounds incorrect. You, the user, can use GPL'd software for
whatever you like. For example, you may build proprietary software
with gcc if you like.

The GPL has to do with distribution -- it talks about the rules you
need to follow if you want to *distribute* GPL'd software. It has
nothing to do with what you *use* it for.

Well, distributing it or selling products derived from the code *is*
a 'use' of the software. My point was that releasing your code under
the GPL imposes legal restrictions on the user of your code, but not
on you. You can choose to release new versions under a different
license (or not all) if you want to, but someone using your code has
no such rights. If they incorporate your code into their own apps,
they must release their apps under the GPL (assuming they release
their apps publicly at all.) The original poster seemed (to me) to
be suggesting that releasing your software under the GPL was
tantamount to putting it irreversibly in the public domain.

Anyway, this is all probably off-topic for ruby-talk, so I'll leave
it at that.

Tom

 

[Ken Bloom]

o - Are licensing terms a concern? Qt isn't totally 100% free, open
source software if you are using it for commercial purposes.

You've gotta ask yourself, though: how would you protect a commerical
investment in an interpreted language that can't even be compiled to
bytecode?

 

[Ken Bloom]

Qt works with Ruby, but it isn't written in Ruby.

I know that. Obviously, there's no difficulty protecting your investment
in a commercial C++ app using QT. But I've heard the question about writing
commerical apps in ruby before, this point seemed related, and was curious
why anybody would try it. (Or whether anybody had come up with a way to do
it.)

I suppose if you were the NSA, and had good security protocols, you could
write secret code that would be distributed internally, and your security
protocols would protect your investment in the interpreted code,
but placing GPL terms on that code would come into conflict with your
security policy.

Section 6 of the GPL would seem to conflict with a security policy
designed to protect secrecy, since the security policy would seem to be
"further restrictions" on GPL rights. IANAL, YMMV.

Alternatively, you might care about QT being GPL if you intended to
license your ruby program under the Solaris license or any other
GPL-incompatible but otherwise free license.

--Ken Bloom

 

[M. Edward (Ed) Borasky]

You've gotta ask yourself, though: how would you protect a commerical
investment in an interpreted language that can't even be compiled to
bytecode?

The same way you protect *any* investment -- by soliciting the advice of
competent attorneys and accountants and following their advice. It's got
only marginally anything to do with technology.

 

[M. Edward (Ed) Borasky]

John Gabriele wrote:
[ snip ]

Much as I like Qt, after seeing this discussion, I've come to the
conclusion that implementing my project using Qt is an unacceptable
legal risk.So it's back to the drawing board.

By the way, the only reason Trolltech even considered a dual-licensed Qt
was to allow KDE development to proceed.

 

[gregarican]

I realize that Ruby 1.8.x code can be at best only obfuscated, not
compiled. So obviously created a closed source product with Ruby would
be out of the question. Even a Ruby 2.0 YARV bytecode-compiled product
could be reverse engineered, as is the case with Python offerings. But
just because something is commercial doesn't _necessarily_ mean that
it's closed source, does it?

Now that splitting hairs has run its course, back to our original
programming :-/

 

[Ken Bloom]

I realize that Ruby 1.8.x code can be at best only obfuscated, not
compiled. So obviously created a closed source product with Ruby would
be out of the question. Even a Ruby 2.0 YARV bytecode-compiled product
could be reverse engineered, as is the case with Python offerings. But
just because something is commercial doesn't _necessarily_ mean that
it's closed source, does it?

Ruby can't even be really effectively obfuscated (at least not as
effectively as Java), because it depends on things being named the same
for duck typing to work. In Java, you can rename any method in the
inheritance chain that isn't defined in the parent class, you also get
overloading to help with the obfuscation so you start by renaming
functions to as many overloads of "a" as possible, then to as many
overloads of "b" as possible and so forth. In Ruby, you don't have the
naming heuristic, nor do you have the ability to create many overloads of
the same function.

Even Java bytecode can be decompiled, and I suppose a hypothetical
native-compiled Ruby program would have a lot more information in it than
a native-compiled Java or C++ program, and you could still do a good job
of reverse-engineering a Ruby program.

--Ken

 

[gregarican]

Good points made. Here's a lighter side to this digressing thread
(originally regarding GUI toolkit choices for Ruby). Check out
something like this -->
http://groups.google.com/group/comp...gst&q=whitespace+quiz&rnum=1#35181e1c691a3af3.
Ruby code obfuscation very tongue in cheek!

 

[Charles O Nutter]

Ruby can't even be really effectively obfuscated (at least not as
effectively as Java), because it depends on things being named the same
for duck typing to work. In Java, you can rename any method in the
inheritance chain that isn't defined in the parent class, you also get
overloading to help with the obfuscation so you start by renaming
functions to as many overloads of "a" as possible, then to as many
overloads of "b" as possible and so forth. In Ruby, you don't have the
naming heuristic, nor do you have the ability to create many overloads of
the same function.

Java includes all naming in the compiled bytecodes as well, because
it's an integral part of the method signatures. Java code can be
decompiled to almost exactly what was fed in, with few exceptions.

Under JRuby, Ruby code will probably be obfuscated even more than Java
code. I've been working on the compiler for JRuby, and I guarantee the
resulting bytecode won't be easily reversible. You might be able to
reverse it to some pretty heinous Java code, but reversing back to the
original Ruby source will be practically impossible. Even if the
method names are still present, everything else will be Java
bytecodes, many of them specific manipulations of JRuby's runtime.
Ruby's AST itself can be reversed, but not perfectly, and if passed
through a compiler like the one in JRuby, it will be mostly
unrecognizable.