ControlCenter Proposal1.1

This is based on my ideas from "Proposal 1" and some stuff from "Proposal 2.0"

• I would use 2 types of modules:
  • Embedded modules: Run inside the control center
  • Standalone modules: Are seperate processes, without feedback to the control center (this is basically the concept of proposal 2.0)
• The modules are described in files. We have 2 types (Embedded and StandAlone). These files translate into object (classes) with a common interface.
• I still would use XML for the files for following reasons:
  • Human readable
  • Standardized, every developper knows them
  • Transfomable through XSLT (can be usefull if in the futher some things would change)
  • Easy to parse in most progamming languages
• Example of an Embedded Module XML

• The configuration block in the above example should contain a bit more information so the controller (control center) is able to dynamically build a UI if the ui block specifies the dynamic method. If the UI specifies static, this means the library has functions that return the desired UI object.
• Such an embedded module should be written in the same language of the controller to ease feedback. It should also have some predifined methods (derive from an interface) that the controller would use. For example a method to initialize progress (if not needed, it simply is an empty method), a method to edit the settings in memory if a user changes something, a method to apply the changes,...
• An embedded module can of course call external script or command line tools and parse the output to send info to the controller. Basically it could act as a wrapper for another tool. But that external tool cannot be graphical...
• An example of a standalone XML file. Basically this is what is proposed in 'Proposal 2.0'

• A standalone module is started by executing the provided executable with specified ui options. Other parameters are not needed as the tool itself provides a ui to the user to specify those. If it is a command line tool that requires extra parameters an embedded module should be used as wrapper
• An example of a possible class diagram. The IModule interface is for the common parts between the 2 module types (For example, they should both have a name and description). 'EmbeddedModule' is an abstract class that describes the functions the controller will call and implements the IModule functionality. 'StandaloneModule' implements IModule interface and knows how to start the standalone tool. 'FooModule' and 'BarModule' are 2 embedded modules and implement all needed functionality.

• I know most of us know C/C++ fluently or just the basics, but I still would suggest to use Python because:
  • I want to learn python better :)
  • I think it is an easy language to learn and more people will be able to write embedded modules as it is easier than C/C++
  • I think it has good bindings to other languages and toolkits
  • Entropy is also written in Python, so for concistency in sabayon...

[Edit by LordBernhard]: Sounds good so far :-) one of the things that come to my mind that would be a problem is internationalization.. putting the translations into the xml file won't work as the xml file would get much too big and unreadable. Another thing is the layout of the GUI (with this Xml file we'd know what settings should be provided but not how they should be displayed).. we would basically have to write our own layouts in xml (vbox, hbox, grid, etc.)... other than that it looks pretty much promising on a first sight :-)

[Reply by Sjieke]: I forgot to take internationalization into account. The only solution I see at the moment is to have an xml file for each language... Other Suggestions are always welcome. About the layout and settings displayed. I thought of adding some kind of type to each setting like 'integer, boolean, list, string' which we map on a control (for example boolean maps on a checkbox). It would also be possible to put settings in a group where each group is represented on a seperate tab of a tabcontrol. For complex configuration tools (like samba, if we ever get to such a complex tool...) the "static" method is provided... If the auto-generated UI isn't satisfying then the module needs to implement its own UI.

[Reply by LordBernhard to Sjieke]: xml file for translations won't be good imo because when you make a change to the original text in the xml file the text has to be changend in *every* translation so that the right one will be found again .. and this would have to be done by hand.. the only solution to this coming to my mind would be some sort of ID for every control text .. the ID represents a string in a translation file... also there would be some sort of section in the xml file of the module with all those IDs representing the default string. About Layouts: Groups are ok... that would work this way.. but how do we present e.g. a listbox? (for example like the partitioner in yast?.. it has many buttons and options and so forth)... imo this would be REALLY limiting... to be really good we'd need to write a whole layouting system ourselves (for the xml file)... letting the module provide the GUI itself is not the solution imo because that would be dependend on a framework again.. we (or at least me) want all modules working with ncurses, gtk and qt

[Reply by Stupot]: Yeah, now we're getting somewhere. I'm ashamed that I didn't think of combining the two ideas of embedded and standalone modules, it makes perfect sense. And I've had the idea of the GUI's being dynamically created in my mind this whole time, although I don't think I ever wrote it specfically, you probably gathered that from my ideas already. I also agree that we should have different xml files for each language. On startup, the app could check to see if a (lang?) config file is there. If not, a box will pop up asking the user to select a language and the app could create the config file with the correct language saved in it. Easy enough. The module specified UI sounds interesting/difficult.

[Reply by LordBernhard to Stupot]: about the xml files for translation see my reply above .. other than that it doesn't sound too bad imo. Also about the module specified UI.. as I stated above we'd basically have to write our own xml gui language (layouts), personally I'll stick with layouts cause they are pretty easy and powerful and easier to handle when resizing operations are done than coordinates (at least in qt)

[Reply by Sjieke]:

• I don't see the benefit for using ID's in the translation. As suggested each module defines his ID's and the default text. The possibility that several modules use the same ID's exists, so this will give problems. Also if a default text changes in a module you will need to lookup the ID in the translation file and also update it manualy. Keeping all translations in 1 file will result in a very big file. Splitting it up for each language results in as many files as using an xml-file for each translation. So no benefit of the ID overhead imo. Internationalization isn't one of my strong points, but as far as I know is mainting po-files for each translation the same as maintaining an xml file for each translation. Please correct me if I'm wrong...
• For the dynamically created gui we should support groups in groups as this will give some extra flexibility. The controller should always be able to create a usable gui, not always the best looking one as you can't exactly specify where the controls need to be and it won't always be the best matching control for a settings as this is impossible. In that case the developper writting the module has the option to implement a gui himself. If he implements QT but not GTK the controller will be able to default to dynamic and build a GTK gui for it. In this why we will always have a ui in all supported formats (QT, GTK, ncurses,...) Nevertheless I do agree that it won't be easy and we need to think carefully about the info needed to build a good ui in as much situations as possible. Imo this will be the hardest part of the controller...

[Reply by Stupot] I think the idea I had for 2.0 was actually much more like your thought of embedded modules calling an outside app/script. Anyway, I'm also going to vote that we use C++ for the framework. I wouldn't mind learning some python or something for the modules, but I would rather put my best foot forward on the framework than learn (by my mistakes?). It seems that most of us know C++ well. Also, I'm still uncertain about how you want to have frontend GUI's interact with the framework. As far as I can see, there is really only one way to have this done and be independent, and that's simply having multiple GUI's and possibly an ncurses UI, all receiving the output (via a pipe or otherwise) from a CLI app. If that is the case, it will make everything much more independent of each other (which I consider to be a good thing). The dynamic GUI's will be difficult and we'll probably have to make some modifications on the backend as we go along, but the actual functionality will be separate from the GUI's. Also, if we make seperate GUI programs, then the GUI's can specify which app from the StandAlone modules it should be using (GTK GUI = GTK module). As far as I'm concerned, if there is a KDE GUI we want to link to, then there is also a Gnome app that does the same thing. If there isn't, then we should port it. Also, once we decide on how this implementation is going down, we need to come up with an awesome name. (I'm trying to think of some sort of name that combines something to do with GTK/Gnome and KDE/qt, something like Knome, but better. I also think it would be cool if our GUI's names were only different by capitalization [i.e. tinKering for qt and tinkerinG for GTK, but I could see why people would be opposed to that.) Clearly, I've moved onto rambling, so feel free to ignore my latter part of this paragraph.

[Reply by Sjieke] When reading the following, keep in mind I am posting this from my C# and Java experience as I don't have any GTK or QT experience...

• About letting the frontends interact with the framework. I think we have 2 situations we need to adres seperately.
  • The first (and in my opinion the easiest) is with the "static uis", where the module provides the ui. In this case the module library returns the topmost parent control (in qt/gtk called a widget?) with all buttons already binded to the corresponding actions (in qt/gtk signals and slots?). The only thing the controller/framework needs to do is embed the provided control (widget?). The handling of buttons, checkboxes,... is done by the module itself as they are already binded (signals and slots already filled in?)
  • The second, the "dynamic uis" is the tricky one. Each setting defined in the xml file should have a corresponding getter and setter in the module library. When the controller builds the ui it should read the initial values from the getters and bind the actions (signals and slots?) to the setters. This way when you click for example a checkbox in the dynamically build module it will set the value in the module library due to the binding. Then to make the changes you need to call some sort of apply function in the module which will modify the changed settings on the system.
• I already wrote a program that dynamically builded the configuration window based on the available settings in a configuration file. Adding a setting to the file automagically added it in the configuration window. Even if it was on a smaller scale and less flexible then we now need, I know it should be possible, at least in C# with WinForms as that is the language I used then. But I consider that if it is possible with C# and WinForms it is also possible with QT and GTK in combination with C++ and/or Python.
• For the standalone modules we could indeed provide a mechanisme that uses different executables based on the UI requested instead of specifying UI arguments, as most programs provide only 1 UI.
• The internationalization is still bothering me. Having an xml file for each language will be sufficient for the dynamically build ui's as those get there text from the xml file, but the static ui's can have texts not provided in the xml. How are we gonna provide translations for those? Maybe we should go the ID route as LordBernhard suggested, but this will also have issues as mentioned before...
• About the programming language. My knowledge of C++ and Python are on an equal level, both are just basic and need a lot of improvement. So either one will be a great learning school for me. This is the last time I will vote for Python, if after this you still want to go with C++ it is fine for me, but at least take it in consideration. Actually there is only 1 thing that keeps pushing me to python and that is that I think the language is easier than C++ which will result in possible more contributions by other members of the community. Also if you look at the history of drakconf (by looking at the AUTHORS file) you will see it originally started as a C program. Later on they made a PERL version. I think they did this because PERL is a scripting language just like Python that is easy to learn and making the program easier to extend in the futher by people not involved from the start... So basically I vote for Python because I think it will be easier to maintain for futher devellopers not involved at the moment...