hotwire on OS X
bazzargh
just had a quick play to see if I could get hotwire up and running
with gtk-quartz. I thought I'd post some info on this in case anyone
else tries to experiment.
- under macports, you need to install these packages:
cairo +quartz (exactly this variant, not cairo +quartz +atsui)
followed by pango and gtk2. Next, deactivate cairo and build cairo
from source; here's the options I use:
./autogen.sh --enable-quartz --enable-cairo --disable-xlib --prefix=/
opt/local
make install
You need to do this because hotwire triggers an assertion in cairo
1.4.10, the current macports version, but gtk2 needs the macports
version to build.
Next the python bits:
py25-cairo, py25-gobject, py25-gtk
... you want to do this after reinstalling cairo since otherwise the
py25-cairo stuff may fail to link (well in part this is because I did
--disable-xlib)
One of the odd things here is that python-2.5 is required, not 2.4
like it says on the hotwire pages. Running hotwire with python 2.4
gives an error that functools isn't found, which is only in 2.5.
Next, a couple of small hacks to hotwire. In hotwire/sysdep/proc.py
add:
elif platform.system() == 'Darwin':
import hotwire.sysdep.proc_impl.proc_unix
_module = hotwire.sysdep.proc_impl.proc_unix
...after the 'Windows' check, and again in hotwire/sysdep/fs.py:
elif platform.system() == 'Darwin':
import hotwire.sysdep.fs_impl.fs_unix
_module = hotwire.sysdep.fs_impl.fs_unix
finally:
sudo python2.5 setup.py install --prefix=/opt/local
(because python isn't python 2.5 in macports) and...
hotwire
yay! a window!... with squares for the text and Pango errors in the
logs!
16:25:14 [-1610559488] hotwire.Main WARNING No IPC subsystem available
for this platform
CGBitmapContextGetBitsPerPixel: invalid context
/opt/local/bin/hotwire:152: PangoWarning: shaping failure, expect ugly
output. shape-engine='BasicEngineFc', font='Bitstream Vera Sans 10',
text='/Users/brianewins'
(etc)
The CGBitmapContextGetBitsPerPixel is a cairo problem, which means
that, er, I'm the one on the hook to fix it, but it looks like only
pango is stopping this from being usable. I'm looking into the pango
problem now, hopefully I can report some more progress later. Not much
point in posting patches yet since I don't have this running.
Cheers,
Baz
Colin Walters
> Hi there,
> just had a quick play to see if I could get hotwire up and running
> with gtk-quartz. I thought I'd post some info on this in case anyone
> else tries to experiment.
Nice!
> - under macports, you need to install these packages:
> cairo +quartz (exactly this variant, not cairo +quartz +atsui)
> followed by pango and gtk2. Next, deactivate cairo and build cairo
> from source; here's the options I use:
In general what I would do before trying to get Hotwire running is be
sure you can do a very basic PyGTK program, say:
#!/usr/bin/python
import gtk
w = gtk.Window(gtk.WINDOW_TOPLEVEL)
w.add(gtk.Label('Hello world!'))
w.show_all()
gtk.main()
> One of the odd things here is that python-2.5 is required, not 2.4
> like it says on the hotwire pages. Running hotwire with python 2.4
> gives an error that functools isn't found, which is only in 2.5.
Yeah...we used to work on 2.4 but admittedly I haven't been testing
it often, and actually the current SVN has a hard requirement on
Python 2.5
because we're using the shipped pysqlite. Although it might be
possible
to use the external pysqlite if available?
Basically right now I'm focused on adding exciting features and fixing
bugs
rather than 2.4 compatibility, but patches for that are happily
accepted.
It should be trivial to drop the functools...I'll do that...[a minute
passes]:
Sending hotwire/gutil.py
Transmitting file data .
Committed revision 136.
> Next, a couple of small hacks to hotwire. In hotwire/sysdep/proc.py
> add:
>
> elif platform.system() == 'Darwin':
> import hotwire.sysdep.proc_impl.proc_unix
> _module = hotwire.sysdep.proc_impl.proc_unix
That works, though the 'proc' builtin won't work until you implement
get_processes()
for Darwin (probably not very hard).
> ...after the 'Windows' check, and again in hotwire/sysdep/fs.py:
>
> elif platform.system() == 'Darwin':
> import hotwire.sysdep.fs_impl.fs_unix
> _module = hotwire.sysdep.fs_impl.fs_unix
Looks fine; once you get the basics working it would make sense to add
a fs_macos
to do the nice stuff like file thumbnails.
> yay! a window!... with squares for the text and Pango errors in the
> logs!
> 16:25:14 [-1610559488] hotwire.Main WARNING No IPC subsystem available
> for this platform
I have no idea what the standard MacOS IPC system is; basically on
Linux we
use DBus to get single-instance application behavior (so re-executing
"hotwire"
creates a new window in the same process rather than separate
processes
which before would overwrite each other's state).
Current SVN is using SQLite for the important things, which has
defined semantics for
concurrent modification. It's not a 100% answer as we still need
notification between
processes, but at least they won't overwrite each other's state.
> CGBitmapContextGetBitsPerPixel: invalid context
> /opt/local/bin/hotwire:152: PangoWarning: shaping failure, expect ugly
> output. shape-engine='BasicEngineFc', font='Bitstream Vera Sans 10',
> text='/Users/brianewins'
> (etc)
>
> The CGBitmapContextGetBitsPerPixel is a cairo problem, which means
> that, er, I'm the one on the hook to fix it, but it looks like only
> pango is stopping this from being usable. I'm looking into the pango
> problem now, hopefully I can report some more progress later. Not much
> point in posting patches yet since I don't have this running.
Yeah, this one looks like the harder thing, it's below my level of
expertise
unfortunately =/ From a random guess, could it be because it's not
finding
any fonts? You might ask on #gtk+ on GIMPNet IRC.
Colin Walters
the unreadable post...
bazzargh
On Oct 21, 5:44 pm, Colin Walters <cgwalt...@gmail.com> wrote:
> In general what I would do before trying to get Hotwire running is be
> sure you can do a very basic PyGTK program, say:
Yeah, I've backed off the previous approach of using the macports
build, trying the jhbuild way now. Macports is a source-package system
like gentoo, lots of things work well, but its not as solid as, eg,
debian; at least jhbuild should make sure normal gtk apps work.
Apparently even with jhbuild the pygtk/osx stuff is a bit flaky, but
there've been some reports of success on the imendio forums.
[snip]
> Looks fine; once you get the basics working it would make sense to add
> a fs_macos
> to do the nice stuff like file thumbnails.
Yep, I'm just doing the minimum to get things working for the moment.
> > yay! a window!... with squares for the text and Pango errors in the
> > logs!
> > 16:25:14 [-1610559488] hotwire.Main WARNING No IPC subsystem available
> > for this platform
>
> I have no idea what the standard MacOS IPC system is; basically on
> Linux we
> use DBus to get single-instance application behavior (so re-executing
> "hotwire"
> creates a new window in the same process rather than separate
> processes
> which before would overwrite each other's state).
I didn't look at the IPC simply because hotwire started up without it;
but with other gtk+ apps being ported, I'd expect theres some dbus
support over here too. dbus was never intended to be linux-specific.
> Current SVN is using SQLite for the important things, which has
> defined semantics for
> concurrent modification. It's not a 100% answer as we still need
> notification between
> processes, but at least they won't overwrite each other's state.
I know sqlite works fine here, eg in Firefox3.
> > CGBitmapContextGetBitsPerPixel: invalid context
> > /opt/local/bin/hotwire:152: PangoWarning: shaping failure, expect ugly
> > output. shape-engine='BasicEngineFc', font='Bitstream Vera Sans 10',
> > text='/Users/brianewins'
> > (etc)
>
> > The CGBitmapContextGetBitsPerPixel is a cairo problem, which means
> > that, er, I'm the one on the hook to fix it, but it looks like only
> > pango is stopping this from being usable. I'm looking into the pango
> > problem now, hopefully I can report some more progress later. Not much
> > point in posting patches yet since I don't have this running.
>
> Yeah, this one looks like the harder thing, it's below my level of
> expertise
> unfortunately =/ From a random guess, could it be because it's not
> finding
> any fonts? You might ask on #gtk+ on GIMPNet IRC.
I spoke to Owen Taylor over on #cairo, he couldn't see why it would
fail like this either. It probably means that the fontconfig setup is
horked in some macports-specific way. IIRC the jhbuild version turns
on atsui in cairo (ie native mac font support) which may not work
either, but since I wrote a chunk of that I've a better chance of
fixing it than I have with freetype/fontconfig.
As you say, I'd be better getting something simpler working first,
once jhbuild finishes churning away.