On Fri, 13 Jan 2006 08:13:05 +0100, [email protected] wrote:
On Friday 13 January 2006 06:23 am, David V. wrote:
I blame Gtk being mentally associated with a lack of an official binary
distribution for Windows - although I’m going out on a limb here, I
don’t
There are windows binaries for ruby-gtk2 and a gtk installer, what are
you
talking about?
I never said they weren’t, and am in fact quite aware of them.
The Gtk installer definately seems new to me, although I don’t really
follow happenings in Gtk - last time I checked (a long time ago) I’m
not
sure if the available installer was official, and I recall not being
able
to get it to work. As unrelated as these arguments may be to the quality
Gtk itself, they’re more than enough for me to go for what Just Works
™
instead of tackling quirks.
A frozen API isn’t everything, ease of deployment is very valuable in
making end-user applications, and fxruby does deliver perfectly in that
respect.
A frozen API is very important not only for the programmer, but for
distribution. When you have an app with 20,000 lines of code, you don’t
want
the app to break just because you now have to handle another add-in.
You might be confusing your environments a little. The convention on
Windows is for applications to bundle their dependencies along and use
those versions. If you keep building your 20,000 lines of code against a
version of a library that works, you’re also going to redistribute said
library in this version, and rare is the adventurous end user that will
go
on and replace DLLs applications use. For “single-use” internal tools,
this is a perfectly acceptable way of doing things if it lets you use
“deploy by copy”.
Of course, for applications that have to be maintained for a long time,
your point stands.
and ease of deployment is very easy with Gtk/ruby-gtk2 as well… if you
read
the fine site
As I said, I blame some aforementioned pet peeves that would make
someone
not make Gtk his first choice on Windows. I never said Gtk wasn’t easy
to
deploy, just that it’s understandable that people in a production
environment won’t readily switch from something that works like a charm
into the unknown unless their current tools shoot them in the foot.
(That’s why personal hacking is so essential to a programmer)
David V.