very interesting survey of Tk vs. other toolkits
Mark Roseman
with regard to GUI library. For anyone interested in the topic of how
Tk and others are used and/or perceived, I would highly recommend
reading through the report he just released.
Tk-oriented summary... Tk was rated worst. (And I'm not posting this to
get peoples' backs up, I think the results are very useful and there are
some very good reasons that Tk comes out as it does).
Please see http://www.pressure.to/ruby_gui_survey/
Mark
Neil Madden
Thanks, Mark.
It's a shame there is not more analysis of the reasons why people rated
Tk so badly. Given the overall "important features" results, I would
have expected Tk to perform somewhat better, as the top-scoring features
are not areas where Tk has traditionally been attacked. Indeed, it seems
quite strong in many of them (ease of distribution, x-platform, mature,
permissive license, etc).
-- Neil
Mark Roseman
> Mark Roseman wrote:
> > Please see http://www.pressure.to/ruby_gui_survey/
> It's a shame there is not more analysis of the reasons why people rated
> Tk so badly. Given the overall "important features" results, I would
> have expected Tk to perform somewhat better, as the top-scoring features
> are not areas where Tk has traditionally been attacked. Indeed, it seems
> quite strong in many of them (ease of distribution, x-platform, mature,
> permissive license, etc).
Ease of distribution for Tk with Ruby isn't great... or to put it
another way, we have it really good with tclkit over here. :-)
My guess is a lot of the poor showing has to do with people being
familiar only with older versions, not knowing about tile/ttk, etc. I
think the sample was fairly heavily Linux-oriented, where things like
the old fonts, look and feel etc. are particularly jarring compared with
the modern Linux-oriented toolkits.
Mark
Bryan Oakley
> Neil Madden <n...@cs.nott.ac.uk> wrote:
>
> > Mark Roseman wrote:
And considering the fact that 78% of the respondents only use it for
fun and only 1/3 are currently using a GUI toolkit, it's not
surprising we lost out to toolkits with more eye candy. Though to be
honest, even with Tile, Tk is a bit behind the curve. There's still no
really good tree widget out of the box which is a cornerstone of many
a modern GUI.
And the other thing to consider is this: for those who know the power
of Tk, what reason is there to pick ruby over Tcl for creating a Tk
based app? In other words, it was something of a self-selecting survey
-- those who would choose Tk probably wouldn't choose ruby.
David N. Welton
> fun and only 1/3 are currently using a GUI toolkit, it's not
> surprising we lost out to toolkits with more eye candy. Though to be
> honest, even with Tile, Tk is a bit behind the curve. There's still no
> really good tree widget out of the box which is a cornerstone of many
> a modern GUI.
Consider also that the winner was some Gnome thing, which might
indicate that people place a lot of value on being well integrated
with the environment, which on Linux means Gnome or KDE.
> And the other thing to consider is this: for those who know the power
> of Tk, what reason is there to pick ruby over Tcl for creating a Tk
> based app? In other words, it was something of a self-selecting survey
> -- those who would choose Tk probably wouldn't choose ruby.
Difficult to say - if they already know Ruby, they're not likely to
want to change languages just to use Tk.
Jeff Hobbs
I did read the findings and must agree that for the most part, the
results are due to a less than optimal binding for Tk with Ruby.
First off, most users are only familiar with the classic Tk bits, and
the binding itself is sub-optimal. Having redone the binding for Perl
(Perl/Tkx, which btw has a new 100% compatibility layer with classic
Perl/Tk in the alpha stage), I have seen good and ... less good ways
to incorporate Tk.
Then there is the simply confusing:
"Tk being included has very real negative consequences. It makes
porting (for example, to 64 bit systems), and installation more
complex ..."
Uh ... we all know that Tk is actually rather good with a large
variety of 64-bit systems. This porting argument is misleading,
erroneous, or simply one of ignorance.
and then continues with ...
"... configuring with –enable-pthreads is recommended for Tk, but may
otherwise significantly reduce interpreter performance."
I think this relates specifically to a disadvantage purely for Ruby.
They use a different threading model and this can bite them. Maybe
they should improve their native threading?
That's not to say that Tk doesn't have plenty of room to improve.
This particular survey doesn't really provide much input to what those
areas are though.
Jeff
Neil Madden
> Neil Madden <n...@cs.nott.ac.uk> wrote:
>> Mark Roseman wrote:
>>> Please see http://www.pressure.to/ruby_gui_survey/
>> It's a shame there is not more analysis of the reasons why people rated
>> Tk so badly. Given the overall "important features" results, I would
>> have expected Tk to perform somewhat better, as the top-scoring features
>> are not areas where Tk has traditionally been attacked. Indeed, it seems
>> quite strong in many of them (ease of distribution, x-platform, mature,
>> permissive license, etc).
>
>
> Ease of distribution for Tk with Ruby isn't great... or to put it
> another way, we have it really good with tclkit over here. :-)
Fair enough. Still surely far easier to distribute than any of the
alternatives listed in the survey?
>
> My guess is a lot of the poor showing has to do with people being
> familiar only with older versions, not knowing about tile/ttk, etc. I
> think the sample was fairly heavily Linux-oriented, where things like
> the old fonts, look and feel etc. are particularly jarring compared with
> the modern Linux-oriented toolkits.
Right, but then I would have expected "Appearance" to be higher on the
list of priorities.
-- Neil
Arndt Roger Schneider
Bryan Oakley <oak...@bardo.clearlight.com> writes:
Well, the report states aesthetics and programming API
as a major point. Interesting is that COCOA is rated
best. GUI Design and programming are totally different
tasks and with COCOA, you design the GUI inside the
interface builder, and define bindings to your own objects.
There is no gui-programming involved.
Asthetics is not eye-candy, there two definitions for
design in the English language:
1 a plan or drawing produced to show the look and function or
workings of a building, garment, or other object before it
is built or made ..
good design can help the reader understand
complicated information...
2 an arrangement of lines or shapes created to form a pattern
or decoration...
Referring to aesthetics as eye-candy conforms to the
definition 2; in my opinion a sure way to get
your gui-work into trouble.
Off-topic:
I am curious, what tree functionality do you need?
I ask this, because I've written my own tree, and don't think
that your requirements are unsolvable.
There is a screen shot included:
gestaltitems.sourceforge.net/rtldoc/RTL_tree_versus_multilistbox.html
>
> And the other thing to consider is this: for those who know the power
> of Tk, what reason is there to pick ruby over Tcl for creating a Tk
> based app? In other words, it was something of a self-selecting survey
> -- those who would choose Tk probably wouldn't choose ruby.
>
Ruby-developers pick ruby, because they want to write
software in ruby --not for the sake of the bundled gui-toolkit.
As the study states the lack of a standard toolkit the
same in every scripting language, except for tcl (and applescript,
and rexx).
Again the note about COCOA is striking, the separation
of gui design from programming languages; this is
noticeable in other areas as-well, silverlight, flash, SVG,
XUIL ...
It is rather painful to search bugs in a
multi-lingual-interpreter installation, this just
the same as with a distributed system...
A possible solution to this would be the
integration of other scripting languages into tcl
--as slave interpreters--.
-roger
--
Arndt Roger Schneider [arndt?roger?web?de << .@.]
Bryan Oakley
wrote:
> Bryan Oakley <oak...@bardo.clearlight.com> writes:
> > ...
> > honest, even with Tile, Tk is a bit behind the curve. There's still no
> > really good tree widget out of the box which is a cornerstone of many
> > a modern GUI.
>
>
> I am curious, what tree functionality do you need?
> I ask this, because I've written my own tree, and don't think
> that your requirements are unsolvable.
I'm not saying it's an unsolvable problem -- I've used several
variations and have written my own in my checkered past. I was merely
pointing out there's not a good out-of-the-box tree widget. If you
want a hierarchical tree you have to settle for the somewhat limited
ttk::treeview widget or hunt one down. That, in and of itself, is
probably enough to discourage someone who is on the fence about Tk to
begin with.
Andreas Kupries
> Off-topic:
> I am curious, what tree functionality do you need?
> I ask this, because I've written my own tree, and don't think
> that your requirements are unsolvable.
>
> There is a screen shot included:
> gestaltitems.sourceforge.net/rtldoc/RTL_tree_versus_multilistbox.html
The proper link is
http://gestaltitems.sourceforge.net/rtl/RTL_tree_versus_multilistbox.html
rtldoc -> rtl.
--
So long,
Andreas Kupries <akup...@shaw.ca>
<http://www.purl.org/NET/akupries/>
Developer @ <http://www.activestate.com/>
-------------------------------------------------------------------------------
Ramon Ribó
> > > honest, even with Tile, Tk is a bit behind the curve. There's still no
> > > really good tree widget out of the box which is a cornerstone of many
> > > a modern GUI.
In my experience, treectrl is a really powerful and nice widget. Maybe
the
next step would be to incorporate it in the TK distribution.
Does it not fill your expectations? As it is complex, it needs some
time to
get used to it but after, it is a real pleasure.
eiji
> the
> next step would be to incorporate it in the TK distribution.
>
> Does it not fill your expectations? As it is complex, it needs some
> time to
> get used to it but after, it is a real pleasure.
This is a bit of topic, but that is simply the point!
treectrl is great, but it is not part of Tk.
Today a tree/table is simply the same like a button, a label or an
entry.
But still, you have to select and ship it somehow.
What would you expect, when you have to handle a buttonctrl-package
because of one button in your gui?
My 2 cents ...
eiji
Neil Madden
Tk now ships with Ttk (since 8.5), which includes a treeview widget that
can be used for trees and simple tables.
-- Neil
Arndt Roger Schneider
Arndt Roger Schneider
Bryan Oakley <oak...@bardo.clearlight.com> writes:
To-limited, state what sort of functionality you're looking
for, then it will be possible to work on it.
I think the feature requirements are quite
diverse for this kind of control.
As for myself: What i wanted is a very graphic
hierarchy view, which can be exported to other formats. too.
--clearly not something closed or simple.
The larger a toolkit or framework gets, the more
time you spend learning to use it.
I did spend years developing windows software and
well the feature set is huge, but also baroque.
No, a small concise toolkit is much, much better
than a overburdened baroque library!
And BTW. better maintainable. The larger the
code-base gets, the slower it will progress!
Consider, today there are major changes
in GUI design (better displays, higher resolution),
and a wider range of targets (mobil, pc, advertising, web ...).
Sean Woods
I think asking people about the suitability of Ruby/Tk for programming
projects is like asking a crowd of Yuppies to rate a farm tractor.
Odds are if BMW made one, they'd be all over it. And who cares how
good it is at actual farm work if it's got a hybrid/electric engine
and an air-conditioned cab?
Uwe Klein
> I think asking people about the suitability of Ruby/Tk for programming
> projects is like asking a crowd of Yuppies to rate a farm tractor.
> Odds are if BMW made one, they'd be all over it. And who cares how
> good it is at actual farm work if it's got a hybrid/electric engine
> and an air-conditioned cab?
Pffffffft.
BMW never did tractors.
But you could buy some from Porsche, Mercedes Benz and Lamborghini ;-)
uwe