Re: GTK 2.20 for Windows

[Nader Morshed <morshed nader gmail com>]

On Sun, 11 Apr 2010 09:51:28 +0300
Tor Lillqvist <tml iki fi> wrote:

> > 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.

Thanks for the reply! This looks to be what I will do, on the windows bundle at least.

> 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)

One can dream :(
(Or hope that the CoApp project, mentioned in Vincent's message, takes off)

> >  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.

I guess one last question on this, can I expect that my program will either work or crash on start up if the 
dependencies are or are not there? Or is there the possibility that it may crash further into its process if 
it reaches a point where it does not have access to the functions it needs?

> > 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.)

Sounds good, it looks like the bug tracker is already pretty filled up with lots of tickets, but if I do come 
across problems, I'll try to be as detailed/helpful as possible in identifying the broken bits.

-- 
Nader Morshed <morshed nader gmail com>