[Gtk-sharp-list] GTK# on Mac Field Report

[Chuck Esterbrook]

Christian, thank you for this incredible response! Some comments and
questions below.

On Thu, Dec 10, 2009 at 1:08 AM, Christian Hergert
<christian.hergert at gmail.com> wrote:
> On Wed, Dec 9, 2009 at 11:33 PM, Chuck Esterbrook
> <chuck.esterbrook at gmail.com> wrote:
>
>> My GTK# application still experiences the following problems
>> (previously mentioned on this list):
>
> We really need Mac users to stand up and participate in fixing bugs.
> I did this for a while, but I don't use or enjoy OS X so my interest
> is near zero.

Understood.

>> -- The first time I click and drag on the resize corner of a window,
>> nothing happens. On the second attempt, the resize happens.
>
> This was a complex problem.  It stems from not having real
> multi-monitor support in the gtk+ quartz backed.  It was added to git
> master after the 2.18 branch.
>
> These might be of interest for some background information
>
>    https://bugzilla.gnome.org/show_bug.cgi?id=594835
>    https://bugzilla.gnome.org/show_bug.cgi?id=517394
>
>> -- After resizing a window, it will not respond to any mouse clicks.
>> If I move the window then it will become responsive again.
>
> See above bugs for more info.  They have links to a few others which
> are relative.

Thanks for that info.

>> -- If I scroll within a TextView using the scrollwheel, it displays
>> overlapping text lines. I have to use the arrow keys to coax the
>> TextView to redisplay each line correctly.
>
> This was caused by missing gdk transpose implementation.  It was added
> as part of multi-monitor support.  Essentially what is supposed to
> happen is a region of the screen in the video buffer is supposed to
> get shifted up or down a given number of pixels.  The code to
> determine the right section and move it was missing/incorrect.
>
>> If I take my .exe over to Linux, these problems disappear.
>
> Expected, the Linux version of gtk+ is what developers test with.  For
> better or worse, Mac and Windows support lags slightly behind when
> major restructuring occurs.  The maintainers, however, are quite
> talented and filing bugs w/ test cases helps drastically.  This is
> where knowing C is helpful.  If that is a problem, I'm willing to
> write test-cases in exchange for donations to the Gnome foundation ;-)
>
> I know it sounds like a lot to ask, but it's invaluable.

Does the winkie mean you were only joking? I've paid small amounts for
fixes to open source projects in the past. Sometimes this more
economical for me since (a) money and time are convertible and (b)
some people are able to hack on a particular project more efficiently
due to their experience with it.

>> If these problems are unknown, I can try to reduce my program down to
>> something smaller that exhibits them. If these problems are known, are
>> there plans around fixing them for Mono 2.4.x or Mono 2.6?
>
> Check out gnome.bugzilla.org for gtk+ bugs related to the issues you
> are having.  (I search for "gtk quartz").  The chances of the bugs
> being in Gtk# are much less than it being in gtk+ directly.

I was working on the idea that since MonoDevelop did not have these
bugs then there is something lacking on Mono's GTK# and/or GTK+ that
come with Mono 2.4.3 and Mono 2.6p1. Also gedit for Mac does not have
these issues.

So am I really going to find that GTK+ is broken? I get the impression
from those 2 apps that it's not!

>> I originally thought GTK# would be well cared for because major apps
>> use it, like MonoDevelop for Mac. But now I'm thinking that the
>> wizards behind such apps are using a "custom GTK#" they tweaked to
>> work for them while the main GTK# distribution, um, ... rots? Sorry
>> for the strong word, but I don't see any GTK# love in these release
>> notes...
>
> My gtk+ tree which was used in Mono was the same tree I was using to
> fix MonoDevelop on OS X.  I've been meaning to rebase my tree on gtk+
> master, but my job keeps me busy fixing Linux.
>
> As it were, most companies I've dealt with that ship a gtk+
> application have shipped their own gtk+ libraries.

Good point. And it's understandable for more exotic requirements, but
my opinion is that resizing windows and clicking with the mouse should
be stock, stable features. I'm not pushing the envelope in my little
app.

> FWIW, you may want to dive down the rabbit hole and build an entire
> Mono and Gtk# stack from source.  I wont lie, it's not easy.  However,
> it will give you the ability to try out gtk+ 2.19 to see all the
> magical bugs that are fixed.

But here is where I'm not clear on what's going on with the Mono
project. Why not include gtk+ 2.19 in Mono to begin with? I guess
that's the key mystery for me as a user.

> Cheers, and good luck,

Thanks. I appreciate your time,

-Chuck