summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/attachments/20120613/c7509498/attachment.html
diff options
context:
space:
mode:
Diffstat (limited to 'zarb-ml/mageia-dev/attachments/20120613/c7509498/attachment.html')
-rw-r--r--zarb-ml/mageia-dev/attachments/20120613/c7509498/attachment.html57
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>