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
