This is pure fantasy.technosaurus wrote:you hit on most of what I was thinking except that my reason for having just a compatibility layer on top of gtk1 was so that we would still have backwards compatibility with gtk1 apps with no additional overhead, but still be compatible with gtk2 VIA the compatibility layer (much like x11-xcb) then we could have a gtk3 layer on top of that.
GTK+1 and GTK+2 have several nasty low-level differences, and code which depends on these things working as they should in GTK+2, will break in interesting ways with such a "compatibility layer". And vice versa, if you change these underpinnings in your version of GTK+1, there will be a notable possibility of breaking native GTK+1 apps.
Here are some examples which I found, the hard way, while working on mtPaint. And I absolutely guarantee that the list below does NOT contain every trap there is; likely, not even half of them.
- GTK+1 widgets use some signals which GTK+2 doesn't have, and vice versa; examples: "draw", "draw_focus", "draw_default", "focus_in_event", "focus_out_event" - vs "add_accelerator", "remove_accelerator", "mnemonic_activate", "scroll_event";
- "focus" signal in GTK+1 is in GtkContainer class, in GTK+2 it's in GtkWidget;
- GTK+1 doesn't do double buffering when handling expose events, and so its widgets' default GCs don't automagically get correctly clipped to update region and don't get automagically reset if modified;
- GtkObject class is differently structured on the lower level in GTK+1 and GTK+2, which affects the style of direct method calls;
- same thing with GdkEvent;
- same thing with GtkStyle;
- "realized" and "mapped" state propagation is done inside gtk_widget_set_parent() in GTK+2, but not in GTK+1 where it remains the responsibility of each container's "add" function;
- GTK+1 doesn't enable automatic mouse grab on click, while GTK+2 does;
- resize process in GTK+1 is done through an entirely different route compared to GTK+2 - among other idiosyncrasies, it does not really honor requeuing a resize from within a "size_request" or "size_allocate" handler unless a very obscure workaround is implemented;
- GtkViewport's default "size_request" handler is buggy in different ways in GTK+1 and GTK+2;
- GtkCombo widget's entry part is updated from open popup continuously in GTK+1, but only on popdown in GTK+2;
- in GTK+1, if processing of a signal needs be terminated, it must be done explicitly with gtk_signal_emit_stop_by_name() - returning TRUE will only prevent propagation to parent widget, unlike in GTK+2 where it also skips all further handlers in the current widget's handler chain;
- in GTK+2, accelerator keys & window mnemonics get handled before the keypress is passed to the focus widget's signal handler - unlike in GTK+1.
-= With best regards, Dmitry Groshev, maintainer of mtPaint =-