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

[Christian Hergert]

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.

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

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

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

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.

http://monodevelop.com/Developers/Mac_Support/Trunk_Builds_of_the_Full_Mono,_GTK_and_MD_Stack

If you set that up, after its done, you can run:

 $ jhbuild shell
 $ git clone git://git.gnome.org/gtk+
 $ cd gtk+
 $ ./autogen.sh --prefix=$PREFIX
 $ make
 $ make install

If autogen doesn't work, you can try running autoreconf -fiv.

Cheers, and good luck,

-- Christian