Re: GTK 2.20 for Windows

[Tor Lillqvist <tml iki fi>]

> I'd been under the impression, just from the other projects I had seen, that windows gtk programs were 
> expected to use
> a shared runtime install,

That depends on who you ask... My current opinion is that it is best
if each end-user installer for an application, or set of applications,
from the same source (= maintainer, or packager/distributor), is
bundled with its own GTK+ tree containing exactly such a set of
versions that the maintainer of the app(s) has verified works with it.

But ideally, sure, it would be nice if there could be one shared GTK+
installation that separate GTK+-using apps would use. Also note that
different GTK+ apps have different sets of dependencies outside the
actual GTK+ stack, (like cairo libjpeg, libtiff, dbus, librsvg, to
pick some common ones), and then these same dependencies are also used
by non-GTK+-apps, so it would be nice if such too could then use the
same shared installation of cairo and dbus for instance.

One quickly then realises that what one actually would need is some
Linux-stylepackage management with requires/provides tracking etc.
(Or Solaris-style, or BSD-style, etc; Linux is not the only OS that
has package management)

And as Linux distros can't agree on a common package format, it is
hard to expect that the much more loosely organised sets of different
people / organisations distributing Open Source software for Windows
would be able to agree on common formats and mechanisms. And if "we"
don't, what's the point...

The most likely end result (which, of course, to some extent is
already happening) will be just competing projects, each saying "we
are the way to do Open Source package management on Windows", with
each such project having some pet feature that people from other
backgrounds/cultures then have difficulties to accept. (Examples of
such potentially controversial pet features that I can imagine would
pop up: 1) Being based on Python, 2) Being .NET-based and use C#, 3)
Being associated with some existinging Linux
subculture/project/whatever, like KDE or GNOME, 4) Being strongly
Windows Installer -oriented, 5) Being strongly opposed to Windows
Installer, 6) Being associated with a certain Linux distro. Etc.

(My *personal* orientation is such that I wouldn't mind helping out in
something that would use C# and .NET technologies to do it, but not
too much of other weird Microsoft stuff please. I don't come from a
KDE background, so I would probably not like it if the driving forces
would be "KDE people" and want to use CMake for instance. I don't
really know or love Python. I wouldn't mind having some compatibility
with Windows Installer. Etc.)

>  If I was to take the binaries out of that though, would it just be a matter of plopping down the dll's in 
> the same folder
> as the executable files?

Mostly, yes. If you need  localisation you need the share/locale tree, too.

> Sad to hear, do you know if there are plans for the future releases to fix the issues?

Plans, by whom? In projects like GTK+, plans are what people plan
actually doing themselves. Not what some governing body wants to be
done and then allocates resources for.

> It feels strange that the developers would just drop interest

People change their interests all the time, especially for stuff they
do in their spare time.

> Would filing tickets of the issues that arise generate a response?

Filing tickets (bug reports in bugzilla.gnome.org) for individual
clearly separate issues (that don't have bug reports already) is
always good, especially if accompanied by minimal but complete test
programs. But don't expect any immediate "response" for bugs that are
hard to fix. (And avoid setting the "priority" or "severity" fields,
that only makes the bug reporter seem obnoxious ("my bugs are the most
important ones"), those fields are cheerfully ignored by most
maintainers I think, or at least by me.)

> Or is the project needing an active developer to sort out the issues that have already arisen?

That is it, yes. Either some existing "maintainer" (like me) that
already knows the code to some extent needs inspiration to start
working on the issues, or some new person needs to appear, full of
energy and inspiration.

--tml