On Monday 10 May 2004 17:09, Dominic Reynolds wrote:
I'm trying to generate a plugin for YaST and I want to have a main window that uses a table based form. The form i'd like would be a table whose cells can take the values of checkbox or drop down lists (I see from designer that QT supports this).
So I looked through the sources and it looks like the YTable (yast table) is not a wrapper around a QT Table but a modification of a selection box
No. It's a QListView based widget - see http://doc.trolltech.com/3.3/qlistview.html QListView is Qt's work horse; it is a combination of multi-column table and tree. For YTable we are using only the multi-column table part - for one thing, to keep the API for YCP scripts small and for another since somebody has to implement everything for the NCurses-UI (the text based UI) as well. But what you seem to want is a QTable based widget - see http://doc.trolltech.com/3.3/table.html We don't have that yet. If time and ressources permit, we'd like to have that one, too for YaST2. But don't hold your breath for that. ;-)
- so I started looking through the sources and tried to find if there was a guide to what interfaces needed to be exposed (kind of a quick reference guide for making yast widgets) in a curses/qt wrapper but I couldn't seem to find one or see clearly what needs to be done from looking through the code.
Writing widgets for the YaST2 UI is the hard part. Using them is what is meant to be easy (by YCP scripts). We have an abstract UI layer, the libyui (in yast2-core/libyui), and (so far) two specific UIs, yast2-qt, the Qt based version, and yast2-ncurses, the NCurses (text based) version. Which version is actually used is totally transparent to the application. In fact, there is no way to find that out (yes, there is, but it's a close-held secret) to prevent application developers from making unsafe assumptions. You can query the UI at runtime for some features that may be different between the various UIs - UI::GetDisplayInfo(). Some widgets are optional, i.e. not all UIs have to provide them. YCP applications are to query for that with UI::HasSpecialWiget() before they are used. We came up with that concept so we could provide some kinds of nice features for the Qt UI that are hard to do with NCurses - for example, the PartitionSplitter widget (a _very_ specific thing, yet really necessary for most users who come from MS Win to set up their PC initially). The application should provide a simpler alternative for NCurses if that kind of widget is unavailable. The hard thing with all that is to make everything available on a very abstract level regardless what specific UI is being used. We always have to find a common denominator between a Qt based and a NCurses based UI, do the common things in the abstract layer (the libyui) and leave only the specific parts to the specific UIs. The basic approach of the YaST2 UI engine is to make life easy for application developers. Nobody cares about the UI engine developers (which for the largest part means me). Whatever happens in the UI engine has to work for both Qt and NCurses. In some very exceptional cases we can resort to declaring something an optional widget - but that drastically reduces its usefulness for the application. Something else to keep in mind: The YaST2 UI is intended to be used from YCP applications. This is what is is optimized for. It makes very little sense (and it is very little fun) to use all that framework from purely C++ based programs. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SuSE Linux AG Nuernberg, Germany