Intricate changes to Quartz/OSX backend
Hi, Over the weekend I have reworked how the Quartz backend does its coordinate transformation. You can imagine this is at the very core of the backend and thus a very intricate change set. I have just pushed these changes to git master. This is a call out to all GTK+ users on Quartz to please report any issues they find so we can iron out any regressions quickly. These changes were needed to properly implement multi monitor support in the Quartz backend. The code implementing this support has also been pushed to git master. This includes support for emitting the ::size-changed and ::monitors-changed GdkScreen signals when appropriate. I have tested this with a myriad of dual monitor setups on my Tiger laptop, I will give it some testing on my Snow Leopard machine later this week. Again, testing is appreciated and if you find issues, please let me know. thanks, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Oct 26, 2009, at 2:07 AM, Kristian Rietveld wrote: Hi, Over the weekend I have reworked how the Quartz backend does its coordinate transformation. You can imagine this is at the very core of the backend and thus a very intricate change set. I have just pushed these changes to git master. This is a call out to all GTK+ users on Quartz to please report any issues they find so we can iron out any regressions quickly. These changes were needed to properly implement multi monitor support in the Quartz backend. The code implementing this support has also been pushed to git master. This includes support for emitting the ::size-changed and ::monitors-changed GdkScreen signals when appropriate. I have tested this with a myriad of dual monitor setups on my Tiger laptop, I will give it some testing on my Snow Leopard machine later this week. Again, testing is appreciated and if you find issues, please let me know. I'll pull build for SL this morning. What particular dual-monitor behavior should I look for? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Mon, Oct 26, 2009 at 10:03 AM, John Ralls jra...@ceridwen.us wrote: On Oct 26, 2009, at 2:07 AM, Kristian Rietveld wrote: Hi, Over the weekend I have reworked how the Quartz backend does its coordinate transformation. You can imagine this is at the very core of the backend and thus a very intricate change set. I have just pushed these changes to git master. This is a call out to all GTK+ users on Quartz to please report any issues they find so we can iron out any regressions quickly. These changes were needed to properly implement multi monitor support in the Quartz backend. The code implementing this support has also been pushed to git master. This includes support for emitting the ::size-changed and ::monitors-changed GdkScreen signals when appropriate. I have tested this with a myriad of dual monitor setups on my Tiger laptop, I will give it some testing on my Snow Leopard machine later this week. Again, testing is appreciated and if you find issues, please let me know. I'll pull build for SL this morning. What particular dual-monitor behavior should I look for? I'm starting a build with moduleset-unstable. I've run into a fairly problem at the meta-gtk-osx-bootstrap stage: *** Checking out docbook-setup *** [2/13] jhbuild build: failed to unpack /Users/paul/gtk/source/pkgs/DB_1 there is nothing wrong with the downloaded tarball - i can unpack it manually into ~/gtk/source without any issues. but jhbuild refuses to believe it can do this. anybody got any clues? or hints on how to get more info? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Oct 26, 2009, at 7:44 AM, Paul Davis wrote: I'm starting a build with moduleset-unstable. I've run into a fairly problem at the meta-gtk-osx-bootstrap stage: *** Checking out docbook-setup *** [2/13] jhbuild build: failed to unpack /Users/paul/gtk/source/pkgs/DB_1 there is nothing wrong with the downloaded tarball - i can unpack it manually into ~/gtk/source without any issues. but jhbuild refuses to believe it can do this. anybody got any clues? or hints on how to get more info? When I've encountered that in the past it's been because Python was too old: Jhbuild's tarball.py uses a function that's only available in Python 2.5. While jhbuild bootstrap will install a new Python for you on Tiger (which comes with Python 2.3), the new version isn't used to run jhbuild itself unless you tell it to. See http://sourceforge.net/apps/trac/gtk-osx/wiki/Build Please use the Gtk-OSX mailing list (http://sourceforge.net/mailarchive/forum.php?forum_name=gtk-osx-users ) or forum (http://sourceforge.net/apps/phpbb/gtk-osx/) for Gtk-OSX issues. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Oct 26, 2009, at 7:44 AM, Paul Davis wrote: I'm starting a build with moduleset-unstable. I've run into a fairly problem at the meta-gtk-osx-bootstrap stage: *** Checking out docbook-setup *** [2/13] jhbuild build: failed to unpack /Users/paul/gtk/source/pkgs/DB_1 there is nothing wrong with the downloaded tarball - i can unpack it manually into ~/gtk/source without any issues. but jhbuild refuses to believe it can do this. anybody got any clues? or hints on how to get more info? Oh, and unstable won't build without intervention on Tiger, because the latest Pango uses CoreText instead of ATSUI; CoreText wasn't supported before Leopard. When it bombs, select item 4 to start a shell, and say git checkout 1.24.3 exit then select clean (which I think will be item 8) Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Oct 26, 2009, at 4:23 PM, John Ralls wrote: Oh, and unstable won't build without intervention on Tiger, because the latest Pango uses CoreText instead of ATSUI; CoreText wasn't supported before Leopard. They didn't really port the backend to CoreText. It is still using the ATSUI API and they changed two function calls. I have an easy patch that puts the old calls (which were removed) back and then it builds and works fine on Tiger. I will try to clean this patch up and push it soon (and also test it on Leopard, which I was not able to do before). The real challenge will be to write a proper, real, CoreText backend for Pango. I might tackle that in the future. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Oct 26, 2009, at 3:03 PM, John Ralls wrote: I'll pull build for SL this morning. What particular dual-monitor behavior should I look for? I have verified that it builds fine on SL. Things that might be broken are event delivery on the secondary monitor (or on the main monitor if the menubar is on the secondary), broken menus, broken window placement, etc. If you find no regressions, then awesome :) regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Oct 26, 2009, at 4:50 PM, John Ralls wrote: On Oct 26, 2009, at 8:36 AM, Kristian Rietveld wrote: On Oct 26, 2009, at 3:03 PM, John Ralls wrote: I'll pull build for SL this morning. What particular dual- monitor behavior should I look for? I have verified that it builds fine on SL. Things that might be broken are event delivery on the secondary monitor (or on the main monitor if the menubar is on the secondary), broken menus, broken window placement, etc. If you find no regressions, then awesome :) What do you mean by event delivery? That mouse-clicks in a window on the secondary monitor don't do anything? Yes for example. As well as missing motion and crossing events. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Mon, Oct 26, 2009 at 11:07 AM, John Ralls jra...@ceridwen.us wrote: When I've encountered that in the past it's been because Python was too old: Jhbuild's tarball.py uses a function that's only available in Python 2.5. While jhbuild bootstrap will install a new Python for you on Tiger (which comes with Python 2.3), the new version isn't used to run jhbuild itself unless you tell it to. turns out that this was not the issue. basically, even my jhbuild was too old to get this right. a new build is underway, but its now died claiming that we need m4 1.4 or later, and i have 1.4.13 ... sigh. digging in. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building Gtk-OSX (was: Intricate changes to Quartz/OSX backend)
On Mon, Oct 26, 2009 at 12:17 PM, John Ralls jra...@ceridwen.us wrote:
On Oct 26, 2009, at 9:07 AM, Paul Davis wrote:
On Mon, Oct 26, 2009 at 11:07 AM, John Ralls jra...@ceridwen.us wrote:
When I've encountered that in the past it's been because Python was too
old:
Jhbuild's tarball.py uses a function that's only available in Python 2.5.
While jhbuild bootstrap will install a new Python for you on Tiger (which
comes with Python 2.3), the new version isn't used to run jhbuild itself
unless you tell it to.
turns out that this was not the issue. basically, even my jhbuild was
too old to get this right. a new build is underway, but its now died
claiming that we need m4 1.4 or later, and i have 1.4.13 ... sigh.
digging in.
Having installed the new jhbuild, did you run jhbuild bootstrap? Remember
that jhbuild sets the path to find its own stuff first.
the downloaded autoconf-2.63 contains this line:
my $m4 = $ENV{M4} || '@M4@';
both LHS halves of which evaluate to $gtk_prefix/inst/bin/m4 even
though jbhuild has not built m4 at this stage.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building Gtk-OSX (was: Intricate changes to Quartz/OSX backend)
On Oct 26, 2009, at 9:35 AM, Paul Davis wrote:
On Mon, Oct 26, 2009 at 12:17 PM, John Ralls jra...@ceridwen.us
wrote:
On Oct 26, 2009, at 9:07 AM, Paul Davis wrote:
On Mon, Oct 26, 2009 at 11:07 AM, John Ralls jra...@ceridwen.us
wrote:
When I've encountered that in the past it's been because Python
was too
old:
Jhbuild's tarball.py uses a function that's only available in
Python 2.5.
While jhbuild bootstrap will install a new Python for you on
Tiger (which
comes with Python 2.3), the new version isn't used to run jhbuild
itself
unless you tell it to.
turns out that this was not the issue. basically, even my jhbuild
was
too old to get this right. a new build is underway, but its now died
claiming that we need m4 1.4 or later, and i have 1.4.13 ... sigh.
digging in.
Having installed the new jhbuild, did you run jhbuild bootstrap?
Remember
that jhbuild sets the path to find its own stuff first.
the downloaded autoconf-2.63 contains this line:
my $m4 = $ENV{M4} || '@M4@';
both LHS halves of which evaluate to $gtk_prefix/inst/bin/m4 even
though jbhuild has not built m4 at this stage.
Um, how long ago did you last run jhbuild bootstrap? The m4 module was
added to bootstrap.modules last December, with version 1.4.11. The
autoconf module depends upon it, so it should be installed before
autoconf. .jhbuildrc, if you're using the one from Gtk-OSX, sets M4=
$PREFIX/bin/m4. That happens after jhbuildrc-custom is imported, so
you'll have to edit .jhbuildrc directly if you want to use another
one. Just don't try to use the one Apple provides (but you probably
already know that).
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building Gtk-OSX (was: Intricate changes to Quartz/OSX backend)
On Mon, Oct 26, 2009 at 3:22 PM, John Ralls jra...@ceridwen.us wrote: Um, how long ago did you last run jhbuild bootstrap? The m4 module was added to bootstrap.modules last December, with version 1.4.11. more than bootstrap - fixing this required an entirely new version of jhbuild. there is also possibly some interaction going on because i have at least two GTK builds managed by jhbuild on this system. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Intricate changes to Quartz/OSX backend
On Oct 26, 2009, at 9:00 AM, Kristian Rietveld wrote: On Oct 26, 2009, at 4:50 PM, John Ralls wrote: On Oct 26, 2009, at 8:36 AM, Kristian Rietveld wrote: On Oct 26, 2009, at 3:03 PM, John Ralls wrote: I'll pull build for SL this morning. What particular dual- monitor behavior should I look for? I have verified that it builds fine on SL. Things that might be broken are event delivery on the secondary monitor (or on the main monitor if the menubar is on the secondary), broken menus, broken window placement, etc. If you find no regressions, then awesome :) What do you mean by event delivery? That mouse-clicks in a window on the secondary monitor don't do anything? Yes for example. As well as missing motion and crossing events. OK. I ran through several of the tests in gtk-demo. I found a crasher, but it's not a regression. (Both of the Off-screen Window demos crash on launch, in the same place; backtrace is below. I haven't yet figured out what's going on with it.) So the only difference in behavior that I see is that the windows open on the secondary screen instead of the primary one. Dragging them around works either way. Regards, John Ralls (gdb) bt #0 0x9706691b in objc_msgSend () #1 0x048240c0 in ?? () #2 0x001ce6b1 in gdk_window_process_updates_internal (window=0x30319e8) at gdkwindow.c:5218 #3 0x001ce8cc in gdk_window_process_all_updates () at gdkwindow.c:5326 #4 0x001ce064 in gdk_window_update_idle (data=0x0) at gdkwindow.c:4952 #5 0x001a2c4e in gdk_threads_dispatch (data=0x482cc00) at gdk.c:506 #6 0x026b3dc0 in g_idle_dispatch (source=0x2b44830, callback=0x1a2bf9 gdk_threads_dispatch, user_data=0x482cc00) at gmain.c:4065 #7 0x026afe25 in g_main_dispatch (context=0x2b10600) at gmain.c:1960 #8 0x026b136d in g_main_context_dispatch (context=0x2b10600) at gmain.c:2513 #9 0x026b1877 in g_main_context_iterate (context=0x2b10600, block=1, dispatch=1, self=0x2b10930) at gmain.c:2591 #10 0x026b2069 in g_main_loop_run (loop=0x4033380) at gmain.c:2799 #11 0x0094e71b in gtk_main () at gtkmain.c:1218 #12 0x000279ed in main (argc=1, argv=0xb4b0) at main.c:1010 (gdb) f 2 #2 0x001ce6b1 in gdk_window_process_updates_internal (window=0x30319e8) at gdkwindow.c:5218 5218 _gdk_windowing_window_process_updates_recurse (window, expose_region); ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Building Gtk-OSX (was: Intricate changes to Quartz/OSX backend)
Very Sweet guys Last I tried Snow Leopard I was not able to get past the bootstrap / build process (a couple of a months ago). I am going to spend the rest of the day re-building the environment, and our application to see if this is all works on OS X 10.6 Snow Kitty (SL). I don't have dual monitor but I will see if I can find one and test. EMAILING FOR THE GREATER GOOD Join me Date: Mon, 26 Oct 2009 15:46:54 -0400 Subject: Re: Building Gtk-OSX (was: Intricate changes to Quartz/OSX backend) From: p...@linuxaudiosystems.com To: jra...@ceridwen.us CC: gtk-devel-list@gnome.org On Mon, Oct 26, 2009 at 3:22 PM, John Ralls jra...@ceridwen.us wrote: Um, how long ago did you last run jhbuild bootstrap? The m4 module was added to bootstrap.modules last December, with version 1.4.11. more than bootstrap - fixing this required an entirely new version of jhbuild. there is also possibly some interaction going on because i have at least two GTK builds managed by jhbuild on this system. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
