Re: About preparing migration towards gtk4

[Michael Meeks]

On 06/01/2021 17:12, Julien Nabet wrote:
> Thank you Michael for your feedback. I must recognize I just heard about
> SolarMutex, Uno, etc. but even if I read during days the Uno
> code/SolarMutex mechanism, I'll never have the patience to read the
> related code (and above all I'm not smart enough to understand how it
> works).

Ah - I'm convinced you are; but it will require quite some concentrated
work, writing of notes, and exploring the problem space.

I had a brain-wave: perhaps we could have a new hook, something like:

void g_main_context_set_dispatch_func
(GMainContext *context,
   GDispatchFunc func);

to wrap all glib main-loop dispatches with the SolarMutex; and inject a
custom poll to release too. Assuming that since there is now no
gdk-threads protection, that all the gtk+ code pushes events / thread
callbacks to the main thread via the GMainContext - then -perhaps- with
a simple, new hook - we could make this work somehow.

Hmm... interesting.

> What I understand is there's a lot of work to do to be gtk4 compliant so
> I suppose it's not too early at all to think about it considering the
> changes it needs.

Sure - so, if there are easy things we can do to remove obsolete
widgets, and we are targeting APIs that are present in a sensible
version of gtk3 that makes perfect sense to me.

> Hope gtk3 won't be deprecated too soon by Gnome :-)

I imagine it will be around for 5+ years; gtk3.0.0 was released in Feb
2011, and we only just removed gtk2 support.

ATB,

Michael.

-- 
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Julien Nabet]

On 06/01/2021 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

...
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 ;-)


Thank you Michael for your feedback. I must recognize I just heard about 
SolarMutex, Uno, etc. but even if I read during days the Uno 
code/SolarMutex mechanism, I'll never have the patience to read the 
related code (and above all I'm not smart enough to understand how it 
works).


What I understand is there's a lot of work to do to be gtk4 compliant so 
I suppose it's not too early at all to think about it considering the 
changes it needs.


Hope gtk3 won't be deprecated too soon by Gnome :-)

Julien

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Jan-Marek Glogowski]

Am 06.01.21 um 16:26 schrieb 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


[some ideas to workaround gtk+ GThread dropping]


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 all based on the Windows message passing stuff way older then my 
implementations. While macOS and Qt pass a functor / std::function to 
process in the main thread using some OS specifics, Windows just uses 
messages to trigger stuff. Messages would be IMHO generally preferable, 
if not for the SolarMutex hacks used on all platforms, because the main 
thread then has to ignore the still locked SolarMutex in the other 
thread, which is ... a big hack.


Am 06.01.21 um 16:26 schrieb Michael Stahl:

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.
AFAIK that was just the pre-2000s (1990s?) idea to do GUI with threads 
in general and nothing LO specific (or so I was told). But if mmeeks 
added this to gtk+, it might always just have been LO specific ;.)


The solution would be to simply give up on the whole idea, maybe even 
getting rid of SolarMutex in the long term, at least to protect GUI changes.


Jan-Marek

P.S. and nowadays we have Vulkan, which introduced a threading API to 
render stuff with multiple threads (/me likes the images in 
https://developer.nvidia.com/sites/default/files/akamai/gameworks/blog/munich/mschott_vulkan_multi_threading.pdf). 
But I doubt LO really needs this (or maybe someone want's to make a 
"real" 3D LO GUI...)..


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 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.



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Michael Meeks]

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.

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.

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.

-- 
michael.me...@collabora.com <><, GM Collabora Productivity
Hangout: mejme...@gmail.com, Skype: mmeeks
(M) +44 7795 666 147 - timezone usually UK / Europe
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Michael Weghorn]

On 19/12/2020 16.22, Jan-Marek Glogowski wrote:
Just a reminder. The migration guide starts with "... you should first 
get your application to build and work with the latest minor release in 
the 3.24 series.", and we just updated the baseline from 3.18 to 3.20.


So I don't see much of a point for this cleanup in the current gtk3 
subdir. If you want to spend time on it, create a gtk4 dir with the gtk3 
content and start a port with a cleanup and gtk3 3.24. I guess a lot of 
compatibility stuff is still missing from the older gtk3 versions.


That would also be my suggestion for a qt6 port ;-)


I haven't looked at Qt 6 in more detail so far, but from what I recall, 
it was claimed that migrating from Qt 5 should be rather 
straightforward, so it might be worth *checking* whether sharing code 
between qt5 and qt6 (with some ifdefs, similar to how it used to be for 
the gtk2/gtk3 case) makes sense, to avoid code duplication.


(The Gtk 3 -> Gtk 4 case may be different, though, since there are many 
fundamental changes in how Gtk works.)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Caolán McNamara]

On Fri, 2020-12-18 at 14:46 -0700, julien2412 wrote:
> Hello,
> 
> 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 following:
> https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html#id-1.7.4.3
> .
> I don't pretend I'd be able to propose some patches because I know
> nothing about gtk but if I find some low hanging fruits, is it ok
> and/or does it worth it to submit some?

I think so yes. Replacing gtk_hbox_new/gtk_vbox_new with gtk_box_new is
one that looks trivial to do. I feel replacing gtk_container_add with
gtk_box_pack_start/gtk_grid_attach is probably another fairly easy
hack.

With https://gerrit.libreoffice.org/c/core/+/108050 I'll drop the never
completed GtkSalPrinter which drops a bunch of stuff that
-DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED flags as deprecated
which brings the warnings/errors there down to manageable levels.

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[julien2412]

Dante Doménech wrote
> Most linux distributions release versions once a year or two years.
> I wouldn't expect it to have support until a couple of years.
> So isn't it a bit early to implement support? I mean, nothing will be
> compatible with it.

That's why for the moment, only preparation may be done for the moment.
This action allows to stay gtk3 compatible and to begin the work needed for
gtk4 migration.
About gtk4 migration itself, I suppose there may be a specific subdir in
core/vcl/unx since there are already:
- generic
- gtk3
- gtk3_kde5
- kf5
- x11




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Jan-Marek Glogowski]

Am 18.12.20 um 22:46 schrieb julien2412:

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
following:
https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html#id-1.7.4.3.
I don't pretend I'd be able to propose some patches because I know nothing
about gtk but if I find some low hanging fruits, is it ok and/or does it
worth it to submit some?

Any thoughts?


Just a reminder. The migration guide starts with "... you should first 
get your application to build and work with the latest minor release in 
the 3.24 series.", and we just updated the baseline from 3.18 to 3.20.


So I don't see much of a point for this cleanup in the current gtk3 
subdir. If you want to spend time on it, create a gtk4 dir with the gtk3 
content and start a port with a cleanup and gtk3 3.24. I guess a lot of 
compatibility stuff is still missing from the older gtk3 versions.


That would also be my suggestion for a qt6 port ;-)

Jan-Marek
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Rene Engelhard]

Hi,

Am 19.12.20 um 15:14 schrieb Dante Doménech:
> Most linux distributions release versions once a year or two years.
So?
> I wouldn't expect it to have support until a couple of years.
> So isn't it a bit early to implement support? I mean, nothing will be
> compatible with it.
>
It doesn't only count what distributions *currently* ship. What counts
is that in those years GNOME might want to switch to gtk4 (no idea
whether that is the case or not) and that is a matter for those
distiributions.

By your reasoning one wouldn't fix build breakages with newer libs or
newer gcc or whatever because distros don't *yet* ship it

There's not only stuff in deb format/rpms on tdf.org, there's also
packages in distributions proper.


And if a future GNOME used gtk4 we should have a -gtk4 backend.


Regards,


Rene

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Ilmari Lauhakangas]

On 19.12.2020 16.14, Dante Doménech wrote:
El sáb, 19 dic 2020 a las 14:47, Ilmari Lauhakangas 
(>) escribió:


On 18.12.2020 23.46, julien2412 wrote:
 > Hello,
 >
 > 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
 > following:
 >
https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html#id-1.7.4.3
.
 > I don't pretend I'd be able to propose some patches because I
know nothing
 > about gtk but if I find some low hanging fruits, is it ok and/or
does it
 > worth it to submit some?
 >
 > Any thoughts?

This is 404:
https://developer.gnome.org/gtk3/stable/3.24/api-index-deprecated.html


Referenced in

https://gitlab.gnome.org/GNOME/gtk/-/blob/master/docs/reference/gtk/migrating-3to4.md



Ilmari


> Most linux distributions release versions once a year or two years.
> I wouldn't expect it to have support until a couple of years.
> So isn't it a bit early to implement support? I mean, nothing will be
> compatible with it.

Julien was specifically referring to the section about preparing, taking 
care of deprecated stuff etc. The baseline GTK version for LibreOffice 
7.1 and master is 3.20. If all the items in the preparation guide can be 
done in GTK 3.20, then it's fine to submit patches for them. You just 
have to be careful not to use stuff introduced after 3.20.


Ilmari
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Dante Doménech]

Most linux distributions release versions once a year or two years.
I wouldn't expect it to have support until a couple of years.
So isn't it a bit early to implement support? I mean, nothing will be
compatible with it.

El sáb, 19 dic 2020 a las 14:47, Ilmari Lauhakangas (<
ilmari.lauhakan...@libreoffice.org>) escribió:

> On 18.12.2020 23.46, julien2412 wrote:
> > Hello,
> >
> > 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
> > following:
> >
> https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html#id-1.7.4.3.
> > I don't pretend I'd be able to propose some patches because I know
> nothing
> > about gtk but if I find some low hanging fruits, is it ok and/or does it
> > worth it to submit some?
> >
> > Any thoughts?
>
> This is 404:
> https://developer.gnome.org/gtk3/stable/3.24/api-index-deprecated.html
>
> Referenced in
>
> https://gitlab.gnome.org/GNOME/gtk/-/blob/master/docs/reference/gtk/migrating-3to4.md
>
> Ilmari
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: About preparing migration towards gtk4

[Ilmari Lauhakangas]

On 18.12.2020 23.46, julien2412 wrote:

Hello,

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
following:
https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html#id-1.7.4.3.
I don't pretend I'd be able to propose some patches because I know nothing
about gtk but if I find some low hanging fruits, is it ok and/or does it
worth it to submit some?

Any thoughts?


This is 404: 
https://developer.gnome.org/gtk3/stable/3.24/api-index-deprecated.html


Referenced in
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/docs/reference/gtk/migrating-3to4.md

Ilmari
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

About preparing migration towards gtk4

[julien2412]

Hello,

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
following:
https://developer.gnome.org/gtk4/4.0/gtk-migrating-3-to-4.html#id-1.7.4.3.
I don't pretend I'd be able to propose some patches because I know nothing
about gtk but if I find some low hanging fruits, is it ok and/or does it
worth it to submit some?

Any thoughts?

Julien




--
Sent from: 
http://document-foundation-mail-archive.969070.n3.nabble.com/Dev-f1639786.html
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice