hi; On 26 November 2014 at 14:22, Alexandre Bique <bique.alexan...@gmail.com> wrote: > On Wed, Nov 26, 2014 at 3:17 PM, Emmanuele Bassi <eba...@gmail.com> wrote: >> you mean apart from the major breakage of API, the massive >> complication of the internals, and the portability issues? > > It is about adding a pointer to a context. > > GtkCtx *gtk_ctx = gtk_ctx_new(); > GtkWindow *window = gtk_window_new(); > gtk_widget_set_ctx(window, gtk_ctx); > gtk_main_loop_ctx(gtk_ctx); > > Would that work without breaking the actual interface? > Then yes the internals would not an update pass.
it's really not "just that". it means locking down every single static variable in GTK; it means locking down every single GObject property, and signal emission. it basically means doing the same things GStreamer does — without breaking API, and without breaking existing code. GStreamer has been engineered in that way, GTK+ hasn't. ensuring that every single initialization happens in a separate thread local storage or thread-safe context would be a fair bit of engineering, and would also likely result in an API break — at least, to avoid existing code from subtly breaking. I suspect you'd also want the GObject type system to be loadable on demand, and unloadable as well, which is not really supported these days. I strongly suspect you want another toolkit for your use case. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
