On Wed, Dec 9, 2009 at 11:33 PM, Chuck Esterbrook <chuck.esterbr...@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 _______________________________________________ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
