About preparing migration towards gtk4

[Michael Stahl]

On 06.01.21 14:56, Michael Meeks wrote:
> Hi Julien,
> 
> On 18/12/2020 21:46, julien2412 wrote:
>> Gtk4 has been released 2 days ago, I know that migration from a version to
>> another version is not a 1 month work, but thought it could be interesting
>> and it can't hurt the current state of LO to begin to prepare it by
> 
> 	Unfortunately the gtk+ team removed the GDK_THREADS annotation that in
> conjunction with the gdk_threads_set_lock_functions method I added back
> in 2003 is/was at the core of our ability to use gtk+ safely with
> threads and to share the SolarMutex with gtk+'s own mutex.
> 
> 	Checkout:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=793124
> 
> 	Quite possibly there is a better way to do this now; possibly by taking
> a SolarMutexGuard in a very large number of places at the perimeter of
> all gtk+ and a11y calls we could leave only smaller parts of the gtk+
> backend as not thread-safe anymore.
> 
> 	Possibly we could come up with some clever I/O thread that would proxy
> the X11 (or wayland?) protocol socket and wrap that with SolarMutex
> protection - such that threading would continue to work.
> 
> 	Possibly we could move the things that use gtk4 into some 'appartment'
> with some UNO magic - I guess the file-picker in particular. I fear
> though that the new welding work assumes that we have a thread-safe gtk3
> so we can construct, populate, script etc. UIs from any thread.

hmm... isn't this basically the same situation as the macOS and the Qt 
VCLplugs?  they have a way to transfer widget work to the main thread, 
see implementation of Qt5YieldMutex and osx/salinst.cxx SalYieldMutex; 
this is all based on a design by jmux.

the relevant bug for Qt5 was about Wollmux extension calling from 
non-main threads:
https://bugs.documentfoundation.org/show_bug.cgi?id=119856

> 	This is quite a big engineering problem, that needs very significant
> thought, and will create threading problems that give and give.
> 
> 	The up-side for the gtk+ maintainers is only that they don't have ~100
> gdk_threads_enter/leave calls that they had to think about in their
> code-base.
> 
> 	In any world where the gtk+ authors also wrote large apps, I would hope
> that they would not make decisions that so carelessly traded a few
> minutes per year of their time for spending man-months of other people's
> and whole new classes of bugs for millions of users.

well i guess by "large apps" you mean LO, because hopefully nobody else 
was dumb enough to f*ck up threading architecture in a GUI app to the 
extent the StarOffice developers have.

> 	Unrelenting platform churn is one of the supposed benefits of FLOSS
> development though ... but the up-stack bit-rot is a pretty serious
> thing to fight.
> 
> 	Then again - doing work to use more modern APIs sounds sensible -
> assuming that they are not too modern (I guess lots of them tend to get
> added when they developed gtk4 which is really very recently for those
> who care about APIs >6 months old ;-)
> 
> 	HTH,
> 
> 		Michael.
>