On Wed, Nov 26, 2014 at 3:31 PM, Emmanuele Bassi <eba...@gmail.com> wrote: > 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.
I see. Thanks to all of you for your answers and advice. I wish you a good day :) Cheers, -- Alexandre Bique _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
