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 !
···
--
Posted via http://www.ruby-forum.com/.
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.
Luiz Macchi wrote:
···
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 !--
Posted via http://www.ruby-forum.com/\.
Hello !
gregarican wrote:
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
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?
···
On Wed, 27 Sep 2006 07:37:01 -0700, gregarican wrote:
o - Are licensing terms a concern? Qt isn't totally 100% free, open
source software if you are using it for commercial purposes.
--
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
I've added a signing subkey to my GPG key. Please update your keyring.
No, Gregarican is right, Qt is not free for commercial applications but free
(GPL'd) for non-commercial / OSS applications.
Jason
···
On 9/27/06, Vincent Fourmond <vincent.fourmond@9online.fr> wrote:
Hello !
gregarican wrote:
> 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
Ken Bloom wrote:
···
On Wed, 27 Sep 2006 07:37:01 -0700, gregarican wrote:
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?
Qt works with Ruby, but it isn't written in Ruby.
--
Paul Lutus
http://www.arachnoid.com
Ken Bloom wrote:
···
On Wed, 27 Sep 2006 07:37:01 -0700, gregarican wrote:
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?
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.
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 wrote:
···
On Wed, 27 Sep 2006 07:37:01 -0700, gregarican wrote:
> 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. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
I've added a signing subkey to my GPG key. Please update your keyring.
Jason Roelofs wrote:
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
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
···
On Wed, 27 Sep 2006 16:03:05 -0700, Paul Lutus wrote:
Ken Bloom wrote:
On Wed, 27 Sep 2006 07:37:01 -0700, gregarican wrote:
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?Qt works with Ruby, but it isn't written in Ruby.
--
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
I've added a signing subkey to my GPG key. Please update your keyring.
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
···
On Thu, 28 Sep 2006 03:27:44 -0700, gregarican wrote:
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?
--
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
I've added a signing subkey to my GPG key. Please update your keyring.
Vincent Fourmond wrote:
Jason Roelofs wrote:
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.
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).
And I could certainly be wrong. I pay much more attention to programming
issues than legal ones.
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.
···
--
Paul Lutus
http://www.arachnoid.com
Ken Bloom wrote:
/ ...
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.)
This makes me wonder how many Ruby newbies fully understand what sort of
environment Ruby (or Perl, or Python) is. It would be a shame for some of
them to invest a lot of time learning Ruby with the expectation of
eventually packaging their code in some sort of bulletproof delivery box.
···
--
Paul Lutus
http://www.arachnoid.com
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.lang.ruby/browse_thread/thread/303ed6cf57a16da8/35181e1c691a3af3?lnk=gst&q=whitespace+quiz&rnum=1#35181e1c691a3af3\.
Ruby code obfuscation very tongue in cheek!
Ken Bloom wrote:
···
On Thu, 28 Sep 2006 03:27:44 -0700, gregarican wrote:
> 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
--
Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
I've added a signing subkey to my GPG key. Please update your keyring.
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.
···
On 9/28/06, Ken Bloom <kbloom@gmail.com> wrote:
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.
--
Contribute to RubySpec! @ Welcome to headius.com
Charles Oliver Nutter @ headius.blogspot.com
Ruby User @ ruby.mn
Paul Lutus wrote:
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)
···
--
Under construction
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
···
On Sep 27, 2006, at 12:25 PM, Paul Lutus wrote:
Well, let's put it this way: Qt is dual licensed, one is commercial,
one is GPL. So it *is* free/open source software.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).
Vincent Fourmond wrote:
> Jason Roelofs wrote:
>> 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.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.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.
···
On 2006.09.28 01:25, Paul Lutus wrote:
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.
···
On 9/27/06, Tom Pollard <tomp@earthlink.net> wrote:
On Sep 27, 2006, at 12:25 PM, Paul Lutus wrote:
>> Well, let's put it this way: Qt is dual licensed, one is
>> commercial,
>> one is GPL. So it *is* free/open source software.
>
> 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
USPS
Programmer/Analyst
St. Louis, MO
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
···
On 9/27/06, Tom Pollard <tomp@earthlink.net> wrote: