Created on 2022-02-08.17:04:38 by nicoe, last changed 1 week ago by ced.
rev d415b76ceb89 did not fix the problem. Indeed it hide it because of issue11596.
New changeset 1f1a5356caff by Nicolas Évrard in branch '6.2': Request a column size recomputation on treeview realization https://hg.tryton.org/tryton/rev/1f1a5356caff New changeset e5fbd9092453 by Nicolas Évrard in branch '6.0': Request a column size recomputation on treeview realization https://hg.tryton.org/tryton/rev/e5fbd9092453 New changeset 48a7129d20ad by Nicolas Évrard in branch '5.0': Request a column size recomputation on treeview realization https://hg.tryton.org/tryton/rev/48a7129d20ad
New changeset d3ab8e59c06f by Nicolas Évrard in branch 'default': Request a column size recomputation on treeview realization https://hg.tryton.org/tryton-env/rev/d3ab8e59c06f
New changeset d415b76ceb89 by Nicolas Évrard in branch 'default': Request a column size recomputation on treeview realization https://hg.tryton.org/tryton/rev/d415b76ceb89
I think we should investigate an other way to solve this issue. I think a good way will be to remove the realized decorator and instead having the widgets One2Many
and Many2Many
in their display
method calling the Screen.display
only when the widget is not in a notebook or is in an active page of notebook. And of course we will need that when a notebook page is activated it calls the display of the containing xxx2May
widgets.
* Cédric Krier [2022-02-08 18:41 +0100]: > >Cédric Krier <cedric.krier@b2ck.com> added the comment: > >On 2022-02-08 18:32, Nicolas Évrard wrote: >> But I think we need to find a better solution to the issue that the realized >> decorator tries to solve. Because I don't think its reasoning fits the GTk >> design choices, > >Maybe we could ask on GTK forum. Indeed. But the last time I asked a design question I had no answer :(. >> thus I'm pretty sure sooner or later the get_realized call will >> be removed (juste like they removed is_visible). > >Not sure it is the same. The realized property is a notion that is used >by the engine for the rendering. >If I recall correctly the `is_visible` was removed because it was not >accurate according to the people believe (difference between visible on >the screen and visible for rendering). I checked the GTK4 doc, they removed get_realized but there are the (un)realize signals which could be used maybe (I think they are already here, so we could rely on them instead of get_realized already now). https://docs.gtk.org/gtk4/class.Widget.html
On 2022-02-08 18:32, Nicolas Évrard wrote: > But I think we need to find a better solution to the issue that the realized > decorator tries to solve. Because I don't think its reasoning fits the GTk > design choices, Maybe we could ask on GTK forum. > thus I'm pretty sure sooner or later the get_realized call will > be removed (juste like they removed is_visible). Not sure it is the same. The realized property is a notion that is used by the engine for the rendering. If I recall correctly the `is_visible` was removed because it was not accurate according to the people believe (difference between visible on the screen and visible for rendering).
* Cédric Krier [2022-02-08 18:01 +0100]: > >Cédric Krier <cedric.krier@b2ck.com> added the comment: > >On 2022-02-08 17:51, Nicolas Évrard wrote: >> >But if it is removed then the xxx2Many will be loaded even for affix. >> >> I don't understand, you mean an affix column put on a x2M? I don't think it >> makes sens to use a x2M column for an affix. > >I mean that the xxx2many's records will be loaded when the widget is not >visible and the tree view has an affix. And we do not want that. OK I understand. But I think we need to find a better solution to the issue that the realized decorator tries to solve. Because I don't think its reasoning fits the GTk design choices, thus I'm pretty sure sooner or later the get_realized call will be removed (juste like they removed is_visible).
On 2022-02-08 17:51, Nicolas Évrard wrote: > >But if it is removed then the xxx2Many will be loaded even for affix. > > I don't understand, you mean an affix column put on a x2M? I don't think it > makes sens to use a x2M column for an affix. I mean that the xxx2many's records will be loaded when the widget is not visible and the tree view has an affix. And we do not want that.
* Cédric Krier [2022-02-08 17:10 +0100]: >But if it is removed then the xxx2Many will be loaded even for affix. I don't understand, you mean an affix column put on a x2M? I don't think it makes sens to use a x2M column for an affix.
Maybe it could be solved by having @realized
set empty string/icon when the treeview is not realized ?
But if it is removed then the xxx2Many will be loaded even for affix.
In case the user opens a form that contains a O2M which is not realized when the view is opened (eg: the O2M is contained in a notebook page that is not shown) then the affixes are not shown.
This behaviour disappear once the form is reloaded or if the user goes to another record.
My proposal is to remove the decorator realized
on the affix setter. As the changelog that introduced it states, it's made to prevent loading lazy data (x2M) and I think that the affixes are safe data to load.
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-08-02 18:13:18 | ced | set | messages:
+ msg77546 status: resolved -> chatting |
2022-04-15 00:01:10 | roundup-bot | set | keyword:
- backport messages: + msg75792 |
2022-04-06 14:27:53 | roundup-bot | set | messages: + msg75045 |
2022-04-06 14:27:50 | roundup-bot | set | messages:
+ msg75044 nosy: + roundup-bot status: testing -> resolved |
2022-04-06 13:07:57 | ced | set | keyword:
+ backport status: chatting -> testing |
2022-04-06 09:42:19 | reviewbot | set | messages: + msg75020 |
2022-04-05 19:08:01 | reviewbot | set | messages: + msg75012 |
2022-02-17 12:02:34 | reviewbot | set | messages: + msg74213 |
2022-02-17 10:58:35 | reviewbot | set | messages: + msg74211 |
2022-02-16 19:56:23 | reviewbot | set | messages: + msg74197 |
Showing 10 items. Show all history (warning: this could be VERY long)