Quoting "Anders F Björklund" <[email protected]>:
Dieter Verfaillie wrote:
Hmm, isn't this package part of freedesktop rather than
gtk+ ? And amazingly, this 1 file and empty dirs is GPL...
So it can't be included in a LGPL (+compatible) package ?
When constructing the windows all-in-one installer I've asked myself
the same question and came to the conclusion that:
- the installer logic is GPL'ed (my choice);
- the software packages that are installed carry their own license,
which the user still needs to honor.
I wanted my package to be LGPL, and the packaging scripts are KISS / PD.
Sure, and that's OK. Just trying to say that you don't necessarily need
to worry about the licenses of the goods that are being transported affecting
the license of the vessel (the package/installer) or the tools creating the
vessel, as there's no runtime linking going on, etc
At least, that's how I'm interpreting these licenses. IANAL, beware, etc :)
(as it's the fourth or fifth time I'm installing PyGTK as a dependency!)
Yeah, we're in the same situation on windows, where it is (strongly)
recommended that each "product" (gimp, inkscape, pidgin, wireshark, etc)
comes with it's own "platform environment" (GTK+ and friends). From a user
perspective that can be confusing at times, but the technical reasoning
behind that recommendation is sound.
I'm also not doing any Mac OS X adapting, that is the "gtk-osx" project*.
Personally I'm fine with it looking grey and having menus in windows etc.
* http://gtk-osx.sourceforge.net/ (GPL, using jhbuild)
+ http://www.gtk.org/download-macos.html (gtk-osx.org)
If I wanted a native appearance, I wouldn't be using PyGTK - but wxPython.
(so that it would still use GTK on Linux, but not on Windows and Mac OS X)
Using the included X11 would also be a perfectly reasonable option (IMHO).
The only thing the Quartz backend does is "lose the X in the window bar" ?
That last bit is identical to somebody constructing their own environment
from scratch from source or the various binary "packages" (zip files).
I'm using tgz files and different scripts, but otherwise it's the same.
The Windows libraries are also relocatable, while I use /opt/gtk rpath.
Other difference was that I didn't include developer files (headers/libs),
but that was more for size reasons since I'm including 3 architectures...
These are all fine by me and I'll not discuss/dispute (? lack of
proper English
vocabulary on my part, sorry) the choices you make as I don't even own a mac
machine myself. So that's up to the actual users of the package :)
I encountered Glade installing icons into the "hicolor-icon-theme",
other software does the same, so I've included "hicolor-icon-theme"
in the installer. As noted above, hicolor is nothing more than an empty
directory structure so I've added the Tango icon theme as well (a
personal preference, but nobody has complained yet).
That would be my preference as well. Including SVG, because I like it.
Hmm, what else do you have there... PyGtkSourceView2, PyGooCanvas ?
PyCairo, PyGObject, PyGTK, PyGtkSourceView2, PyGooCanvas and PyRsvg
(the last one comes from gnome-python-desktop), Glade3, "language tools"
(intltool, gettext, etc) and dependencies. A complete list can be seen here:
https://github.com/dieterv/pygtk-installer/blob/release-2.22.6/wix/2.22.6.win32.xml
I've had requests to add PyGTKSpell/PyEnchant by our gramps friends and
time permitting I'll add them to the 2.24 aio installer (I hope).
Glade is already available from http://glade.gnome.org/ for Mac OS X.
(including another bundle of GTK inside). Only included libglade-2.0.
There was no (sane) Glade3 binary package available for windows at the time,
so the work is tracked here:
https://bugzilla.gnome.org/show_bug.cgi?id=634978 :)
Also, the Glade3 version bundled in the PyGTK aio installers comes with
"Python widgets support", so we can finally add a catalog of
widgets created with PyGTK to Glade3 running on windows :)
That brings the number of different Glade3 version up to 3 on windows:
1 supporting Python 2.6, 1 supporting Python 2.7 and one without
Python support.
That brings me to an idea: do you think it would be worth it to share
common parts (manifest generation, compression routines, etc) of these
build scripts in a shared repository somewhere?
I'm asking because my next project will most likely be an adaptation on
Tor Lillqvist's windows binary build scripts so they can be run out of the box
on any windows system (having the necessary tools) as the current scripts are
limited to Tor's development environment...
mvg,
Dieter
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
