Hi Paul,
On Mon, 2012-05-21 at 09:14 -0400, Paul Davis wrote:
> its really not significantly different from g_idle_add(), except that
> SendMessage relies on a switch()
Notice - we get a return value, without needing to create a manual
condition, wait on it, signal it, and pass pointer to a return values
closure. That is what I like about it SendMessage - not the switch
statement per-se ;-)
> GtkUI::call_slot (sigc::mem_fun (*someObject,
> &SomeObject::some_method));
Sure; I do the same with Gtkmm in repsnapper quite nicely, though I
never ceased to be amazed at how slowly that stuff compiles.
> your code is designed around the execution of GDK/GTK code in multiple
> threads. it was unfortunate that GDK/GTK ever allowed this (as has
> been pointed out, this is absolutely NOT possible on Windows with
> violating several fundamental parts of the Windows API).
That claim sounds really strange; since - well - we do that in
LibreOffice ourselves :-) Unsurprisingly our toolkit has multiple
backends, one is unx/gtk+ another is windows. The windows backend works
quite nicely, and is used by ~80%+ of our users. It involves a -bit- of
work posting events across threads to get a subset of thread-affine
operations to execute in the right place, that is for sure. However
doing this in the toolkit requires that work to be done once, in one
place for all users. There is nothing fundamentally impossible about
that, nor does it need to violate anything :-)
The question is only who should do the work ... it's of course fine by
me to totally disable the threading stuff on windows as well if it is
annoying - we use gtk+ only on unix.
> restructuring is a bit much, if you ask me. i understand the pain (i
> still have vivid memories of the transition from gtk1 to gtk2), but
> sometimes i think you just have to swallow the tablets and get on with
> it.
There is something of a difference in scale, and hence the
swallow-ability / size of the tablets ;-)
https://www.ohloh.net/p/compare?project_0=LibreOffice&project_1=Ardour+3&project_2=gtk%2B
Then again, in -theory- we mostly abstract gtk+ out of the picture into
some localised area, that is hopefully at least tractable.
ATB,
Michael.
--
michael.me...@suse.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
