Re: Standarization WAS: gtk-devel & gtk-runtime:InnoSetup packages for MinGW/Win32

Javier Ros <[email protected]> 27 Jan 2003 17:11:49 +0100
Newsgroups gmane.comp.video.gimp.windows.devel
Message-ID <1043683909.1157.32.camel@s172m203>
El lun, 27-01-2003 a las 15:17, Bill Nalen escribió:
> >>and to provide
> >>a windows register mechanism that allows the gtk dependent application
> >>to dynamically link to their preferred version. 
> 
> >... but this sounds like a call for breaking it. Why put stuff into
> >the registry when every Gtk+ DLL does find itself and related
> >configuration from the place where it is located ? 
> 
> The GTK+ dll's will find each other from the relative directories. However 
> it's finding the top level bin and lib directories that is the problem. 
> I'd rather not have to add those two directories to my path.  You can set 
> a registry key for an application specific path addition though.  That's 
> what I do in my installer.  It just looks in the registry for the GTK item 
> and retrieves the path it was installed to.  It then uses this path to set 
> additional path items for the bin and lib directories for my application.
> 
> The GTK+ installation only adds two keys to the registry, one for the 
> version and one for the path.  They are not used by the GTK+ dll's as far 
> as I can tell.  It's only a way for other applications to find the GTK+ 
> installation directory.
> 
This is the registry mechanism I'm speaking of. Is the method you are
addresing what allows different applications link to different version
of
for example gtk+1.3, because it is not installed a system wide path
for gtk. I agree that this method is wonderful.

For example GTK+ 1.3 Jernej installer address this problem this way

;Note: the GTK+ installation path is stored in Registry, in one of these
keys (depends whether GTK+ was installed by
;administrator or normal user):
;  HKEY_LOCAL_MACHINE\SOFTWARE\Software\GTK\1.3\Path
;  HKEY_CURRENT_USER\SOFTWARE\Software\GTK\1.3\Path
;If none of these keys exist, you can safely assume that GTK+
1.3-20020313 isn't installed.
;The Setup also stores GTK version in registry, in one of these keys:
;  HKEY_LOCAL_MACHINE\SOFTWARE\Software\GTK\1.3\Version
;  HKEY_CURRENT_USER\SOFTWARE\Software\GTK\1.3\Version
;The version number is stored like this: 1.3.0-20020530[-1]

So there is only one path, and the date is prescribed
in the version.

May this is the correct way, that is: only one version of GTK+ by
computer. And if some problem arise then actualize GTK.


But, an approach in which the path is saved within a 
HKEY_CURRENT_USER\SOFTWARE\Software\GTK\1.3\20020530\path

And that maintains a special  redundant key

HKEY_CURRENT_USER\SOFTWARE\Software\GTK\1.3\Current\path

that points to the latest installation

Will allow to have several versions installed, and that a
GTK+ application link to the library of their choice.

May this is not considered necessary, but it will result
in a increased support, because different version would
be able to survive at the same time.

This approach is being used now within the ImageMagick
InnoSetup based installer.

I'm not claiming that the installation has to be done
the way I've explained, just pointing that possibility.
Actual installer are OK for my needs.

My original mail was about having different people hosting installers
for the very same GTK distribution. Centralizing the binary,
and install scripts at www.gtk.org, would in my opinion
avoid duplicated efforts, and increase the compatibility
of applications from the point of view of the installation process.


:) Bye

Javier


> Bill
-- 
Javier Ros
Dpto. Ingeniería Mecánica/Ingeniaritza Mekanikoa Saila
Univ. Pública de Navarra/Nafarroako Univertsitate Publikoa
Campus de Arrosadía s/n 31006 Iruñea
Tel. 34 948169307 Fax. 34 948169099


To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected] 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/