Problem
MCC is great, and I would love to be able to admin using it regardless of whether I am using text interface or gtk/qt. The interface is completely different in curses than gtk interfaces. Curses version is a second rate citizen, and Gui is all GTK. A lot of the tools are not available in curses interface, for instance, I don't see a way to install software or managing repositories. It would be nice to have qt version as well as gtk (not a major issue, but would be nice)
Possible solution I have thought how this could be addressed and feel that in the long term, the best solution would be to have the interface layer abstracted. So when developing a module, you use the mcc UI library, so you may call for instance mccGui.pushButton then if you are running in curses it creates a curses button, if you are in KDE it creates a QPushButton, if you are in Gnome it creates a GTKButton. This would take a great deal of work, so I started looking around to find any existing libraries. The first place I looked was openSuSE as Yast does exactly what I am describing. In yast, the interface is laid out and works the same way whether you are using curses, Gtk or Qt. To my surprise they have put a lot of work into separating their Ui library from the Yast tools. You can use the library to write curses/gtk/qt programs that use the appropriate widget as needed, independent of Yast. We could use the Yast Back end, and adapt our front end to use it. This option would take the least amount of work, as there are perl bindings to the yast libraries, and so it would only be the gui layer that would need reworking. The current gtk only modules could become curses/qt/gtk modules by changing the gtk calls to yast backend calls.
Just to be clear, I am not suggesting that we port Yast to Mageia, I am suggesting we use its Ui abstraction only. I use Mageia over openSuse for many reasons, but I do admire how well Yast works, and would love to see similar in Mageia. Perhaps we could start planning the next generation of MCCÂ ??
It would provide consistency across terminal and gui administration, and in doing so provide an easy entry into text based administration for novices.
Providing the abstraction layer would mean all modules created will be available to all users.