diff options
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20120613/c7509498/attachment.html')
-rw-r--r-- | zarb-ml/mageia-dev/attachments/20120613/c7509498/attachment.html | 57 |
1 files changed, 57 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/attachments/20120613/c7509498/attachment.html b/zarb-ml/mageia-dev/attachments/20120613/c7509498/attachment.html new file mode 100644 index 000000000..fa6d120de --- /dev/null +++ b/zarb-ml/mageia-dev/attachments/20120613/c7509498/attachment.html @@ -0,0 +1,57 @@ +<html> + <head> + <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> + </head> + <body bgcolor="#FFFFFF" text="#000000"> + <p><b>Problem</b> + </p> + <p>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) + </p> + <p><b>Possible solution</b> + 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. + </p> + <p>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Â ?? + </p> + <h1><small><small> <span class="mw-headline" + id="Why_it_would_be_good_for_Mageia_to_include_it"> Why it + would be good for Mageia to include it </span></small></small></h1> + <p>It would provide consistency across terminal and gui + administration, and in doing so provide an easy entry into text + based administration for novices. + </p> + <p>Providing the abstraction layer would mean all modules created + will be available to all users. + </p> + </body> +</html> |