Intricate changes to Quartz/OSX backend

[Kristian Rietveld-2]

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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[John Ralls-2]

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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Paul Davis]

On Mon, Oct 26, 2009 at 10:03 AM, John Ralls <jralls@...> 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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[John Ralls-2]

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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[John Ralls-2]

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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Kristian Rietveld-2]

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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Kristian Rietveld-2]

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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[John Ralls-2]

On Oct 26, 2009, at 8:34 AM, Kristian Rietveld wrote:

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

True, "switch" would have been a better term...

ISTM that a configure option and a macro that selects either the ATSUI  
or CoreText function is the way to go, so that Pango will build both  
for Tiger and x86_64.  Cairo needs the same treatment; right now they  
just skip the ATSUI functions when building in 64-bit.

Regards,
John Ralls

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[John Ralls-2]

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?

Regards,
John Ralls

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Kristian Rietveld-2]

On Oct 26, 2009, at 4:47 PM, John Ralls wrote:
> True, "switch" would have been a better term...
>
> ISTM that a configure option and a macro that selects either the  
> ATSUI or CoreText function is the way to go, so that Pango will  
> build both for Tiger and x86_64.

Yea, a configure thing was my plan for supporting Tiger and Leopard.  
Good to know that you agree with that :)  I will look into fixing up  
that patch this week.


regards,

-kris.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Kristian Rietveld-2]

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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Paul Davis]

On Mon, Oct 26, 2009 at 11:07 AM, John Ralls <jralls@...> 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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[John Ralls-2]

On Oct 26, 2009, at 9:07 AM, Paul Davis wrote:

> On Mon, Oct 26, 2009 at 11:07 AM, John Ralls <jralls@...>  
> 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.

Regards,
John Ralls
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Paul Davis]

On Mon, Oct 26, 2009 at 12:17 PM, John Ralls <jralls@...> wrote:

>
> On Oct 26, 2009, at 9:07 AM, Paul Davis wrote:
>
>> On Mon, Oct 26, 2009 at 11:07 AM, John Ralls <jralls@...> 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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[John Ralls-2]

On Oct 26, 2009, at 9:35 AM, Paul Davis wrote:

> On Mon, Oct 26, 2009 at 12:17 PM, John Ralls <jralls@...>  
> wrote:
>>
>> On Oct 26, 2009, at 9:07 AM, Paul Davis wrote:
>>
>>> On Mon, Oct 26, 2009 at 11:07 AM, John Ralls <jralls@...>  
>>> 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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Paul Davis]

On Mon, Oct 26, 2009 at 3:22 PM, John Ralls <jralls@...> 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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[John Ralls-2]

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=0xbffff4b0) 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@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[sbaka]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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: paul@...
> To: jralls@...
> CC: gtk-devel-list@...
>
> On Mon, Oct 26, 2009 at 3:22 PM, John Ralls <jralls@...> 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@...
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list