Re: Fwd: Plans for GTK+ Bundles for win32 and win64?

[Sam Thursfield <ssssam gmail com>]

On Thu, Sep 8, 2011 at 2:15 PM, Kean Johnston <kean johnston gmail com> wrote:
>> At least bundling everything with my app let's me sleep at night, knowing
>> some unknown installer out there is not going to break my stuff which has
>> taken countless hours to build.
>
> Why do you think this is unique to Windows? If you create a .rpm or .deb
> that depends on version x.y.z of some library, you have absolutely NO
> guarantees that during a system update (or some other package requiring a
> later version of that library) thatt the library isn't updated in some way
> that breaks you. In fact, due to conventions of using different namespaces
> for conflicting versions on Windows, that problem is rather neatly avoided.
>
>> Having a shared "runtime" leads to extremely hard to debug situations as
>> the shared part is in a continues state of "unknown": Who has done what
>> to it? Why? Been there, done that, moved on :)
>
> Just because you've had some difficulties with it doesn't mean its not an
> easily solved problem. Just because its been badly done in the past doesn't
> mean the concept of having a shared component is invalid, just that the
> implementation of it was. And as for things being in a state of "unknown",
> that's just absolutely untrue. If constructed properly, you can query the
> *exact* version of each library you depend on, using an OS-provided API, and
> store information about each exact version in one very easy to use,
> centrally managed location.
>
>> No need to fiddle with %PATH% when your executable lives right next
>> to libglib-2.0.dll, libgtk-2.0.dll etc. In other words, put your .exe
>> and .dll's in the bin directory. Have a look at how GIMP does things,
>> it's a fine example of how to package things for Windows in a sane way.
>
> I disagree, its a piss-poor and lazy way. it may WORK, but it is far from
> "fine" if things were done properly (which I am trying very hard to do). GTK
> absolutely *CAN* be created as a well-managed, stable, centrally available
> component. The authors of an individual application (like GIMP) may *choose*
> to bundle their own copies if they have some reason (or even just desire) to
> do so but it is NOT a shining example of how things should be done. If you
> believe it is then I fully expect to see you championing the
> install-with-application notion for GTK on Linux, because the problem domain
> is identical.
>
>> These days, I don't think it matters much having a couple of different
>> copies of GTK+ and it's dependencies on disk. As long as things work
>
> Sure, when there are only about 5 apps that use it that may be true. When
> you have a larger agenda, where you are trying to attract not only other
> open source projects but also commercial ones, that falls flat on its face
> I'm afraid.
>
>> hit a button and have a .zip and/or .msi produced automatically. The zip
>> would be the equivalent of the GTK+ bundle but crafted especially for
>> your project and the .msi a full fledged installer, giving your users
>> the choice of how they want to install your project on their machines.
>
> OMG NO! That's abhorent! Ask yourself this question: would you accept that
> behaviour on Linux? Every application that uses GTK bundling its own copy?
> That is .. *every single gnome application* bundling its own copy of GTK? Of
> course you wouldn't. Why are you then suggesting it for Windows?

In theory, I agree with what you're trying to achieve here. However,
in practice I think there would be better places to direct your energy
- keeping in mind Windows takes up about 2GB of disk space these days,
12MB of DLL's for each of the maybe 10 Gtk apps I have on Windows
really doesn't make much of an impact, and using shared libraries
probably always be more fragile than just bundling them (extra
complexity always introduces bugs). App developers have to manage
their own updates on Windows anyway, so keeping deps as well as the
actual app up to date shouldn't be any extra effort. Do you any other
reasons for doing this?

I don't want to demotivate you here, my point is just that there is a
lot of work to be done to get Gtk+ 3 up to scratch on Windows (writing
an entire theme engine, for example) so we need to be smart about what
we spend time on.

Sam