As you may know, this pull request in libyui brought nicer tabs in Qt that rely on QTabWidget https://github.com/libyui/libyui/pull/31 As explained there, some hacks were needed because the philosophy of tabs in Qt is different from the one in libyui. With Qt, the widgets contained in all tabs exist in memory (they keep their state and can be referenced) as long as the group of tabs exists. Changing between tabs is controlled by Qt itself (mostly transparent to the program) and its just a matter of which widgets are visible and which are not. In some sense, switching tabs is not so different from scrolling a screen - some widgets will become visible and other will not be longer in the spotlight, but all widgets are still there. With libyui, switching a tab is just an event and it's program responsibility to actually redraw the content below the tabs. Something that is done thanks to the usage of replace points and that implies destroying all the visible widgets and creating new ones to be drawn in their places. If the program is using CWM (which offers an extra abstraction layer on top of libyui with it's own sequence of events), that means that for every widget that becomes hidden (destroyed, actually) a "validate" and a "store" events are triggered. On the other hand, the status of every widget that becomes visible (created again, actually) must be initialized based on an "init" event (apart from calling the constructor, the usual calls to "content", etc.). While reviewing the changes in libyui we came to the question of whether it would be actually better to adopt the Qt philosophy in libyui. Maybe with an alternative widget (to not completely break backwards compatibility and CWM tabs). What do you think? Would it be worth considering? Cheers -- Ancor González Sosa YaST Team at SUSE Software Solutions
Dne 18. 06. 21 v 9:57 Ancor Gonzalez Sosa napsal(a):
As you may know, this pull request in libyui brought nicer tabs in Qt that rely on QTabWidget https://github.com/libyui/libyui/pull/31
As explained there, some hacks were needed because the philosophy of tabs in Qt is different from the one in libyui.
With Qt, the widgets contained in all tabs exist in memory (they keep their state and can be referenced) as long as the group of tabs exists. Changing between tabs is controlled by Qt itself (mostly transparent to the program) and its just a matter of which widgets are visible and which are not. In some sense, switching tabs is not so different from scrolling a screen - some widgets will become visible and other will not be longer in the spotlight, but all widgets are still there.
That's how it is also implemented elsewhere - in web pages. All HTML nodes are present, the inactive tabs have "display: none" CSS property so they are not visible. Switching a tab is just a matter of changing the "display" property of the respective tab group. So it would make sense to use this approach also in libyui, to be compatible with other frameworks.
With libyui, switching a tab is just an event and it's program responsibility to actually redraw the content below the tabs. [...]
While reviewing the changes in libyui we came to the question of whether it would be actually better to adopt the Qt philosophy in libyui. Maybe with an alternative widget (to not completely break backwards compatibility and CWM tabs). What do you think? Would it be worth considering?
Well, tabs (the DumbTab widget) are used quite rarely, I found like 15 places in all YaST code (example code excluded). The question is why we decided to use this simpler implementation. Maybe there was a good reason for that. Personally I cannot remember, I was not involved in that part, but my wild guess is: libyui-ncurses (as usually). While the Qt implementation is trivial (just properly use the native Qt widget), in ncurses we would need to completely implement the logic for displaying and tracking the visibility of all widgets. And as mentioned before, tabs are used quite rarely, so I suppose it would not pay off - a lot of work for very little gain. So I'd stick with the current implementation... [Sorry for late reply, I wanted to react but I got distracted and then I forgot...] -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8
participants (2)
-
Ancor Gonzalez Sosa -
Ladislav Slezak