Quantcast

Testing PyGTK installer for Mac OS X

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Testing PyGTK installer for Mac OS X

Anders F Björklund-3
Hi,
we needed a simpler way to install PyGTK on Mac OS X,
besides using macports/fink or jhbuild to compile it...

So we are testing an all-in-one (= both gtk+ and pygtk)
Universal installer for Mac OS X 10.5 Leopard and later:

http://afb.users.sourceforge.net/zero-install/PyGTK.pkg


It's for both python versions (python2.5 and python2.6)
and built for all three architectures: ppc, i386, x86_64.

It's modeled after the existing gtk+ bundle for Windows,
but rebuilt (as .tgz) from scratch using custom scripts:

http://afb.users.sourceforge.net/zero-install/buildscripts/


Feedback appreciated.

--anders

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Chris Van Bael
Hi,

I haven't installed it yet, but this looks very promising after all
the troubles I had with jhbuild building for the wrong python and
MacPorts not so great supporting GTK on Quartz.
I still haven't figured it out completely.

One question I still have: will this install PyGTK in the Python
provided by Apple, or in Python.org's Python? (I expect the latter
since you say 2.5 and 2.6)

Thanks for the work, I'll try it out for sure!

Chris

On Fri, Mar 11, 2011 at 12:45 PM, Anders F Björklund
<[hidden email]> wrote:

> Hi,
> we needed a simpler way to install PyGTK on Mac OS X,
> besides using macports/fink or jhbuild to compile it...
>
> So we are testing an all-in-one (= both gtk+ and pygtk)
> Universal installer for Mac OS X 10.5 Leopard and later:
>
> http://afb.users.sourceforge.net/zero-install/PyGTK.pkg
>
>
> It's for both python versions (python2.5 and python2.6)
> and built for all three architectures: ppc, i386, x86_64.
>
> It's modeled after the existing gtk+ bundle for Windows,
> but rebuilt (as .tgz) from scratch using custom scripts:
>
> http://afb.users.sourceforge.net/zero-install/buildscripts/
>
>
> Feedback appreciated.
>
> --anders
>
> _______________________________________________
> pygtk mailing list   [hidden email]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://faq.pygtk.org/
>
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
Chris Van Bael wrote:

> Hi,
>
> I haven't installed it yet, but this looks very promising after all
> the troubles I had with jhbuild building for the wrong python and
> MacPorts not so great supporting GTK on Quartz.
> I still haven't figured it out completely.

Both the Darwin/X11 version of GTK from MacPorts or Fink,
and the MacOSX/Quartz version of GTK from gtk-osx/jhbuild,
were working "just fine"*. The main reason for doing this
new installer was to avoid the need to _compile_ anything...

* see http://0install.net/install-mac.html for details

Since Zero Install uses a lot of small PyGTK programs, it
wasn't efficient to wrap them into stand-alone bundles
each with a bundled version of gtk+ and pygtk inside it.
Including the development packages was also a bit bloated.

And getting rid of "that "X in the window bar" is nice too.

> One question I still have: will this install PyGTK in the Python
> provided by Apple, or in Python.org's Python? (I expect the latter
> since you say 2.5 and 2.6)
>
> Thanks for the work, I'll try it out for sure!

This installer explicitly uses #!/usr/bin/python for Python,
and /opt/gtk for GTK+ (with /opt/gtk/lib/python* for PyGTK)
It is _supposed_ to set up a ".pth" file, so that the system
python is able to find the site-packages from within /opt/gtk:

$ cat /Library/Python/2.5/site-packages/gtkredirect.pth
import site; site.addsitedir('/opt/gtk/lib/python2.5/site-packages')

$ cat /Library/Python/2.6/site-packages/gtkredirect.pth
import site; site.addsitedir('/opt/gtk/lib/python2.6/site-packages')

There was an earlier version that used /usr/local/bin/python
for Mac OS X 10.4, since it had python2.3 which was too old.
It could be revived too, if there was enough interest. But it
cannot use the same binaries as the 10.5/10.6 version posted.

--anders

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
In reply to this post by Anders F Björklund-3
> So we are testing an all-in-one (= both gtk+ and pygtk)
> Universal installer for Mac OS X 10.5 Leopard and later:
>
> http://afb.users.sourceforge.net/zero-install/PyGTK.pkg
[...]
> Feedback appreciated.

Thanks to everyone who tested the previous package,
apparently there was a bug with PackageMaker 3.0.4
ignoring the "postflight" script for flat packages
that caused the PYTHONPATH to not be set up. Fixed.

I also included the (optional) "gtk-quartz-engine",
a theme engine to use a more Mac-like appearance...
Unfortunately it's a bit buggy, but: (~/.gtkrc-2.0)
include "/opt/gtk/share/themes/Quartz/gtk-2.0/gtkrc"


The address to the pkg itself is the same as before.
MD5 (PyGTK.pkg) = 00b177e99977de0bdb8357af477a241f

I'll host the packages/bundle itself next to the pkg,
once the final release moves to the "files" area...

--anders

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Yann Leboulanger
In reply to this post by Anders F Björklund-3
On 03/11/2011 12:45 PM, Anders F Björklund wrote:

> Hi,
> we needed a simpler way to install PyGTK on Mac OS X,
> besides using macports/fink or jhbuild to compile it...
>
> So we are testing an all-in-one (= both gtk+ and pygtk)
> Universal installer for Mac OS X 10.5 Leopard and later:
>
> http://afb.users.sourceforge.net/zero-install/PyGTK.pkg
>
>
> It's for both python versions (python2.5 and python2.6)
> and built for all three architectures: ppc, i386, x86_64.
>
> It's modeled after the existing gtk+ bundle for Windows,
> but rebuilt (as .tgz) from scratch using custom scripts:
>
> http://afb.users.sourceforge.net/zero-install/buildscripts/
>
>
> Feedback appreciated.

Wow! Awsome!

First, thanks for this package.

I don't have a MAC, but one of my friend thested it, and it works, he
was able to run Gajim on it with your package. The only thing he has to
do was to install the hicolor icon theme. (some folder + one index.theme
in /usr/share/icons/hicolor/
I think it should be installed by your package.

Except, once again a great thanks!

--
Yann Leboulanger
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
Yann Leboulanger:

>> So we are testing an all-in-one (= both gtk+ and pygtk)
>> Universal installer for Mac OS X 10.5 Leopard and later:
>>
>> http://afb.users.sourceforge.net/zero-install/PyGTK.pkg
>>
[...]
>> Feedback appreciated.
>
> Wow! Awsome!
>
> First, thanks for this package.

Glad you like it. Currently on the third revision, after
fixing linking bugs on Leopard, and "flat" package bugs.

Should be ready for a "real" release after that, I think.

> I don't have a MAC, but one of my friend thested it, and it works, he was able to run Gajim on it with your package. The only thing he has to do was to install the hicolor icon theme. (some folder + one index.theme in /usr/share/icons/hicolor/
> I think it should be installed by your package.

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 ?

Something that could be useful would be to package the Tango
icon theme and the SVG loader, but that's more an "add-on"
(ditto with the JPEG, JP2 and TIFF pixbufloaders as well) ?


And it doesn't help to just include the theme file, since the
glib location is hardcoded to "/usr/local/share/:/usr/share/".
(and neither of those are being used, but instead "/opt/gtk")
So in order to to work, the user needs to set $XDG_DATA_DIRS:

GtkWarning: Could not find the icon 'gtk-find'. The 'hicolor' theme
was not found either, perhaps you need to install it.
You can get a copy from:
        http://icon-theme.freedesktop.org/releases


Anyway, those aren't really PyGTK issues. But GTK/XDG quirks.

Shouldn't affect the packaging, if they're added in afterwards.

--anders

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Yann Leboulanger
Le 15/03/2011 09:00, Anders F Björklund a écrit :
>> I don't have a MAC, but one of my friend tested it, and it works, he was able to run Gajim on it with your package. The only thing he has to do was to install the hicolor icon theme. (some folder + one index.theme in /usr/share/icons/hicolor/
>> I think it should be installed by your package.
>
> 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 ?

Maybe yes. I wonder how many GTK programs depends on it though. At least
mine does, and I don't know how to not depend on it. We have to depend
on a gtk theme, and I thought there was at least one in gtk, and I
thought it was hicolor

"hicolor-icon-theme is the default icon theme that all icon themes
automatically inherit from."

I have no idea how mac packages work, but is there a dependancy thing?
Could your package depend on a hicolor-icon-theme package?

--
Yann Leboulanger
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Dieter Verfaillie-2
Quoting "Yann Leboulanger" <[hidden email]>:

> Le 15/03/2011 09:00, Anders F Björklund a écrit :
>>> I don't have a MAC, but one of my friend tested it, and it works,  
>>> he was able to run Gajim on it with your package. The only thing  
>>> he has to do was to install the hicolor icon theme. (some folder +  
>>> one index.theme in /usr/share/icons/hicolor/
>>> I think it should be installed by your package.
>>
>> 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.

That last bit is identical to somebody constructing their own environment
from scratch from source or the various binary "packages" (zip files).

> Maybe yes. I wonder how many GTK programs depends on it though. At  
> least mine does, and I don't know how to not depend on it. We have  
> to depend on a gtk theme, and I thought there was at least one in  
> gtk, and I thought it was hicolor
>
> "hicolor-icon-theme is the default icon theme that all icon themes  
> automatically inherit from."

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

mvg,
Dieter


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
In reply to this post by Yann Leboulanger
Yann Leboulanger 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 ?
>
> Maybe yes. I wonder how many GTK programs depends on it though. At least mine does, and I don't know how to not depend on it. We have to depend on a gtk theme, and I thought there was at least one in gtk, and I thought it was hicolor

Yeah, well. Lots of GTK programs depend on XDG or X11 or any other random dependency, so I'm not sure if that's anything to go by. But there _is_ a gtk theme (or two now, actually: "Raleigh" and "Quartz"), just not a freedesktop.org index.theme...

> "hicolor-icon-theme is the default icon theme that all icon themes automatically inherit from."

In practice, all it does is avoid that warning. Since it doesn't include any icons, it would still show the "missing image" (the doc with red x). So it's kinda useless ? And when looking at tango-icon-theme, it doesn't seem to reference it anyway.

> I have no idea how mac packages work, but is there a dependancy thing? Could your package depend on a hicolor-icon-theme package?

You could say that "they don't" (in practice, anyway), but it's simple enough to make another one (.pkg). I do that already for GnuPG.pkg, for instance (which is the other hard dependency of Zero Install, see http://0install.net/install-source.html)

Anyway, Tango is on the TODO:

? libxml2 (system)
+ libart (LGPL)
+ libcroco (LGPL)
+ librsvg (LGPL)

- shared-mime-info (GPL)
- hicolor-icon-theme (GPL)
- icon-naming-utils (GPL)
- tango-icon-theme (PD)

http://tango.freedesktop.org/Tango_Desktop_Project

But there's a lot of other things "assumed" by FreeDesktop, that doesn't hold on either Windows or Mac OS X ? When using for instance MacPorts, we include a whole Xfce desktop... Complete with applications, and what-not. But this bundle was intended to be only PyGTK.

--anders


PS. Just so that there is no misunderstanding: stock icons are included.
    i.e. http://library.gnome.org/devel/gtk/2.22/gtk-Stock-Items.html

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Yann Leboulanger
Le 15/03/2011 10:38, Anders F Björklund a écrit :
>> >  "hicolor-icon-theme is the default icon theme that all icon themes automatically inherit from."
> In practice, all it does is avoid that warning. Since it doesn't include any icons, it would still show the "missing image" (the doc with red x). So it's kinda useless ? And when looking at tango-icon-theme, it doesn't seem to reference it anyway.
>

The problem is that my program complete the hicolor them to add some
icons, so I created the hicolor folders structure, then added some icons
in it, and in my code I call

gtk_icon_theme = gtk.icon_theme_get_default()
gtk_icon_theme.append_search_path(ICONS_DIR)

But my icons are not used if hicolor theme doesn't exists.
I always thought that using gtk icon theme was a nicer idea than loading
images. It handles size automatically.

--
Yann
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
In reply to this post by Dieter Verfaillie-2
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.
(as it's the fourth or fifth time I'm installing PyGTK as a dependency!)

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

>> Maybe yes. I wonder how many GTK programs depends on it though. At least mine does, and I don't know how to not depend on it. We have to depend on a gtk theme, and I thought there was at least one in gtk, and I thought it was hicolor
>>
>> "hicolor-icon-theme is the default icon theme that all icon themes automatically inherit from."
>
> 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 ?

Glade is already available from http://glade.gnome.org/ for Mac OS X.
(including another bundle of GTK inside). Only included libglade-2.0.

--anders

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Dieter Verfaillie-2
Quoting "Anders F Björklund" <[hidden email]>:

> 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   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
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 :)

Yeah, I've heard it before so I think that's the common interpretation:

http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

Partly I'm wondering how a set of directories could need a license, but.
The actual package tools and the package format are proprietary anyway.
Using Apple's venerable PackageMaker, and the pkg/bom/xar file format.

The bundle "packages" are regular bsdtar tarballs, though.

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

That part is the same on Mac OS X... I would say that it "makes sense"
from a user perspective (in that it's easier to handle, manually), but
that the technical reasoning behind it is very simplistic and limited.

What I meant is that I've done one package for MacPorts, one for Fink,
one for GTK-OSX using Jhbuild, one for Homebrew, and now this custom one.
Main reason being that all of the other four variants were source-based.

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

The versions and selection was directly modeled after the Windows bundle.
(http://www.gtk.org/download-windows.html and download-windows-64bit.html)

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

Yeah, meant "that I didn't include" there. The developer tools like
pkg-config and gettext are available, just not in the deployment pkg.

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

I don't think I will bother with Python 2.7, already supporting
Python 2.5 (for 10.5) and Python 2.6 (for 10.6) so that's enough.

> 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 not sure where the manifest generation and compression routines
come in, other than that I was using the built-in gzip for "simplicity".

Recompressing the package with XZ results in a much smaller package,
but then you'd need people to install that (or bundle xzdec, ~ 50 KB)

 26M PyGTK.pkg
 14M PyGTK.pkg.xz

And that's bound to fail. Though I might switch .tgz to .txz later.
Guess that would be similar to switching .zip to .7z for Windows ?

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

Eventually (one day) I'll rewrite these scripts into a generic tool.
Right after I make my own "distro". But they should be runnable now.

--anders


_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
>>> 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
>
> Yeah, meant "that I didn't include" there. The developer tools like
> pkg-config and gettext are available, just not in the deployment pkg.

Added intltool for building. But it seems to me that gtksourceview
is part of GNOME rather than GTK, and requires the (now deprecated)
ige-mac-integration (IgeMacBundle) which prevents building on 64-bit ?
And half of the language specs are GPL rather than LGPL, as well...

So I'd need to patch it (and delete some *.lang), if I wanted to include.
It only needs the IGE stuff to find the locale files relatively, anyway.
#else
        locale_dir = g_build_filename (DATADIR, "locale", NULL);

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

Seems to be a rather slippery slope of feature creep, right there ? :-)
Think I will leave those out: PyGooCanvas/PyRsvg/PyGTKSpell/PyEnchant

The one I really wanted was PyWebKitGtk anyway. But that's also a bit
"heavy" as far as dependencies go, so will also be an extra add-on...

--anders

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Dieter Verfaillie-2
Quoting "Anders F Björklund" <[hidden email]>:
> Added intltool for building. But it seems to me that gtksourceview
> is part of GNOME rather than GTK

Hence the all in all-in-one ;)

> , and requires the (now deprecated)
> ige-mac-integration (IgeMacBundle) which prevents building on 64-bit ?
> And half of the language specs are GPL rather than LGPL, as well...
>
> So I'd need to patch it (and delete some *.lang), if I wanted to include.
> It only needs the IGE stuff to find the locale files relatively, anyway.
> #else
> locale_dir = g_build_filename (DATADIR, "locale", NULL);
>
>>> 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).
>
> Seems to be a rather slippery slope of feature creep, right there ? :-)

Yeah. On the other hand the current situation with PyGTKSpell/PyEnchant
is as good as impossible for a user to figure out. We did find a workaround
to get those working, but it's... well a workaround :)

I do think the future of Python bindings will become simpler in the
future (PyGTK 2.24 being the end of the line, barring maybe bugfix
releases), with gobject-introspection + PyGObject removing the need for
static bindings for each and every library we want to use...

mvg,
Dieter


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
Dieter Verfaillie wrote:

>> Added intltool for building. But it seems to me that gtksourceview
>> is part of GNOME rather than GTK
>
> Hence the all in all-in-one ;)

Sure, but all-GNOME-in-one or all-GTK-in-one ?

I used http://www.gtk.org/download-windows.html

>> Seems to be a rather slippery slope of feature creep, right there ? :-)
>
> Yeah. On the other hand the current situation with PyGTKSpell/PyEnchant
> is as good as impossible for a user to figure out. We did find a workaround
> to get those working, but it's... well a workaround :)
>
> I do think the future of Python bindings will become simpler in the
> future (PyGTK 2.24 being the end of the line, barring maybe bugfix
> releases), with gobject-introspection + PyGObject removing the need for
> static bindings for each and every library we want to use...

Yeah, and if gobject-introspection hadn't been full of even harder bugs
to figure out I would agree. But for GTK3, it should be the way to go...

For now, --disable-introspection it is. Will revisit for Python 3000. :-P
But maybe add libjpeg, enchant, gtksourceview and ige-mac-integration then.

--anders

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Testing PyGTK installer for Mac OS X

Anders F Björklund-3
In reply to this post by Anders F Björklund-3
>>> So we are testing an all-in-one (= both gtk+ and pygtk)
>>> Universal installer for Mac OS X 10.5 Leopard and later:
>>>
>>> http://afb.users.sourceforge.net/zero-install/PyGTK.pkg
>>
>>> Feedback appreciated.
>>
>> Wow! Awsome!
>>
>> First, thanks for this package.
>
> Glad you like it. Currently on the third revision, after
> fixing linking bugs on Leopard, and "flat" package bugs.
>
> Should be ready for a "real" release after that, I think.

I've changed the default theme to Clearlooks (from Raleigh),
and fixed an issue if using Leopard with upgraded python2.6.

The Quartz and Murrine engines are also included, if needed.
But I'm not going to attempt any "native looking" Mac theme.

Compared to the Windows bundle, the Mac bundle now also has
support for JPEG, SVG and GtkSourceView. Thanks, all testers!

http://afb.users.sourceforge.net/zero-install/PyGTK.pkg
MD5 (PyGTK.pkg) = 4cf14a4e72423a7b4eea63513295b62d

--anders

_______________________________________________
pygtk mailing list   [hidden email]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
Loading...