From Mageia wiki
Jump to: navigation, search
Note:
This feature is continued since Mageia 7 in Feature:ManaToolsAsDefault

Summary

Introduce an new UI abstraction layer for Mageia Control Center so that there is consistency between the Curses and Gtk versions (and perhaps Qt).


Porting and writing new administration tool modules to be used (see also Feature:InstallerAndDrakXReview#Standalone)

Owner

Old owner:

  • Name: Steven Tucker
  • Email: tuxta2@gmail.com

New owner:

  • Name: Angelo Naselli
  • Email: anaselli_at_linux_dot_it

Resources

Developers, Packagers, Translators, QA, Doc

Angelo Naselli aka anaselli as developer and packager
Matteo Pasotti aka pasmatt as developer and packager

Current status

  • Targeted release: 1, Mga3Mageia 5
  • Last updated: 2024/03/28
  • Percentage of completion: (abstraction <100>%, modules see below, Shared modules <50>%)

Detailed Description

Problem

MCC is great, and I would love to be able 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 Alot of the tools are not available in curses interface, for instance, I dont 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 layed 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 seperating 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 ??

Additional feature specifications

Instead of simply porting old MCC standalone modules/code look at Feature:InstallerAndDrakXReview#Standalone. The basic idea is to clearly separate the GUI front-end layer from the back-end. Back-ends should be based on CPAN modules (if perl related) or, if better using dbus.

That would grant to have a back-end layer that can be used not only by new GUI front-ends but also shared with other applications even not based on libYUI abstraction. Back-ends could be shared with installer and also with old MCC modules for instance, if possible.

A clear separation also means that changing a back-end, the front-end would remain un-touched, e.g. no new translations, new documentation (the layout would not change), etc.

Why it would be good for Mageia to include it

It would provide consistency across terminal and gui administration, and in doing so provide an easy entry into text based administration for novices.

libYui is written in C++ but perl, python and ruby bindings are provided (thanks to swig). Manatools and the available modules have been written using (modern) perl, Moose and other CPAN modules for the sake of readability, object oriented approach therefore better maintainability.

manatools are realized using perl to increase the drakX* code reuse, when it is not gtk-related of course. The idea is to speed up the transition process.

Noone prohibits (nor the project structure does) the development and/or the integration of non libYui 3d-party modules: that means we just just lose the opportunity to run new application using TUIs (text user interfaces) or GUIs by writing the code once.


Providing the abstraction layer would mean all modules created will be available to all users.

Following are some examples of standalone application tool (QT, GtK and ncurses)



manauser

AdminUser-qt.png

AdminUser-gtk.png

AdminUser-ncurses.png


rpmdragora

Rpmdragora-qt.png

Rpmdragora-gtk.png

Rpmdragora-ncurses.png


The administrative panel, e.g. mpan, instead is in the following pictures (layout can be improved of course)

Apanel-qt.jpeg

Apanel-gtk.jpeg

Apanel-ncurses.jpeg

Test case

Test cases are all related to modules, so they should be discussed module by module (such as userDrake -> adminUser, serviceDrake -> adminService, etc).

Software / Packages Dependencies

libYui - the Yast User interface abstraction layer. https://github.com/libyui/

libyui-qt
libyui-gtk
libyui-ncurses
libyui-bindings - For yui script bindings (perl, python and ruby)

libYui-mga - the Mageia Plugins for libYui.

https://bitbucket.org/_pmat_/libyui-mga
https://bitbucket.org/_pmat_/libyui-mga-qt
https://bitbucket.org/_pmat_/libyui-mga-gtk

libyui-mga-qt
libyui-mga-gtk
libyui-mga-ncurses


Or Port to perl-kde4 ( maybe easier and cleaner ) then we would have interactive:qt and interactive::gtk

What could disrupt development of this new feature

lack of developers / interest by developers.

Would be good to have a developers mailing list.

Planning

Port libYui and perl-yui <DONE - added also a MGA plugin to have our widget extension>.

port all modules <in progress> Every module, as well as ManaTools itself, can be run using a Qt 5, GtK 3 or ncurses interface.

Available tools are:

  • manaclock as date/time manager (using systemd api and working also with systemd-timesyncd)
  • manadm as login manager configuration
  • manahost as hosts manager
  • manalog as journalct log reader
  • manaproxy as proxy manager
  • rpmdragora as rpm install manager
  • manaservice as service manager (using on systemd api)
  • dragoraUpdate as rpm update manager
  • manauser as user manager
  • manawall as firewall manager


packaging <DONE - submitted manatools, manatools-qt and manatools-gtk>

Contingency

Develop initially as an alternative using the current stable mcc for as long as needed. If project fails, continue using using current mcc.

Release Notes

mageia 5 - https://wiki.mageia.org/en/Mageia_5_Release_Notes#ManaTools_preview

Documentation

http://gitweb.mageia.org/software/manatools/tree/README.md
http://gitweb.mageia.org/software/manatools/tree/MODULE_HACKING
https://github.com/xquiet/libyui-mga
https://github.com/libyui/

Yui documentation is into yui-devel and yui-mga-devel packages

Useful links

https://wiki.mageia.org/en/User:Marja/Adminpanel