User talk:Sjieke

From Sabayon

Jump to: navigation, search

Contents

Introduction

Project Details

  • Developers: xlnagla, LordBernhard, sjieke, Stupot
  • Development status: Proposal
  • Operating System: Sabayon Linux
  • Programming Language: Unknown
  • Topic: Configuration

Progress

Goals

  • No dependency towards any DE
  • A modular framework.
    • Each configuration tool should be a module (examples: keyboard module, Users&Groups module).
    • All modules should be tied together in the framework.
    • Modules should be indpendent of eachother.
    • Modules can be written in any language (python, basic shell script, C/C++, ...)
  • Support for multiple User Interfaces (GTK, QT, ...), maybe following design templates needed by the framework.

Determining starting point

Forking/Porting Yast

LordBernhard is trying to compile Yast on Sabayon

Current progress:

  • Compiling base packages:
    • core: OK
    • devtools: OK
    • gtk: OK
    • libyui: OK
    • libyui-bindings: OK
    • ncurses: OK
    • qt: OK
    • theme: OK
    • ycp-ui-bindings: OK
    • you-server: OK

Pending packages for a working baseinstall:

  • yast2: error during compile -- can't identify the problem yet.. seems to be a missing makefile or something like that

Modules tried:

  • None yet, before trying modules I'd like to get a working yast interface first (ncurses/gtk/qt)

Starting from scratch

Stupot and Sjieke are letting there brains cook...

Proposal 1

ControlCenter_Proposal1

Proposal 1.1

ControlCenter_Proposal1.1

Proposal 2.0

ControlCenter_Proposal2.0

Proposal 3.0

ControlCenter_Proposal3.0

Implementation Goals (discussion):

In this section, we'll discuss what should be implemented first structurally and in what order features should be added.

[Stupot]: Ok, firstly, we still need to discuss how we want navigation to work in our control center. Clearly, the goal will be to make it as simple (for the user) as possible, but what exactly that would be is another discussion. I feel as though we could easily be starting on the GUI already, because making a simple GUI for navigating around is going to even take time. I think we should concentrate on either GTK or QT first. Actually, I'm more so of belief that we should split up the work and have one person being the GTK go-to-guy and another for QT. Clearly, the last guy will have to be doing research on how to implement configuration changes. While I don't believe any of us should be confined to those roles, it seems as though it would be the most efficient method. However, until we have our modules to the point where we consider them stable/not likely to change much, we should work on either GTK or QT, not both.

So, first thing I think we should do is make a simple navigation GUI that "reads" the xml files and displays them in an orderly fasion so the user can navigate to where they want to go. I'm not sure how we want to implement this yet. I have more to say, but I have to get back to work!

[Sjieke]: I agree, but we do have to do some things before we can start to create a GUI (either GTK or QT) and a XmlReader. My views on the implementation and what we need to do:

  • First we need to specify the XML structure for our modules, including a schema (XSD) to ease the validation.
  • We also need to specify the widget types the GUIBuilder knows. I would start with just the basic ones (Button, Checkbox, Label and TextField). Later on we can expand it with more types by adding them to the XSD-schema and the GUIBuilder implementation.
  • The available layouts should also be defined in the XSD-schema. In the beginning also just the basic (vbox and hbox). In the futher expandable (grid, tabs,...)
  • The different GUI apps (GTK, QT,...) should use the same XmlReader. So we will need a common library to share between them. What I would include in that library is:
    • The XmlReader and XmlValidator
    • The Module interface (called IModule), the StandAloneModule implementation (if we still want to support that?) and the EmbeddedModule abstract class (if we need it...)
    • The GUIBuilder interface (called IGUIBuilder): each app has it's own implementation of the GUIBuilder (for example GTK_GUIBuilder). When the app creates the XmlReader it passes a IGUIBuilder (an instance of GTK_GUIBuilder) to the XMLReader. While the XMLReader reads through the xml file it uses the provided GUIBuilder to build the GUI based on the info read. The XMLReader could create a module object (EmbeddedModule or StandAloneModule) that contains the parent widget created by the GUIBuilder and some other info read from the xml file (the italic part I'm not sure if this is a good approach)
  • We should create a 'Dummy' module that displays some settings in the gui and uppon apply just writes them to a text file. With this we can test the framework and GUIBuilder
  • For the internationalization I think we will need the id's. But we need to decide on following things (all possible combinations have there benefits and drawbacks)
    • Each module does it's translations or the framework does the translations for all modules
    • One file containing all transalations or a file for each translation.
  • Below I have included an example of a classdiagram for the GUIBuilder and for the Module. The classes are devided in libraries in the following manner:
    • Framework Library: IGUIBuilder, IModule, StandAloneModule (not included in the diagram), EmbeddedModule, XMLReader (not included in the diagram)
    • Control Center Main GTK app: GTK_GUIBuilder
    • Control Center Main QT app: QT_GUIBuilder
    • Dummy Module 1 library: DummyModule1
    • Dummy Module 2 library: DummyModule2

GuiBuilder class diagramModule class diagram

[Stupot] That's very much in line with my thoughts exactly, although I would think about the GUIBuilder and XMLReader the other way around, where the GUIBuilder calls on the XMLReader to get info and then it builds the stuff itself, but I think we're pretty much thinking the same thing, just saying it backwards from each other. Also, one of the reasons I suggested we start making a GUI app is that knowing how the GUIBuilder should work will have an influence on the XML structure. I'm pretty sure that the layout Lord B created is actually pretty close to what it should be in that regards, but I think it would be silly to overthink the XML module files when we'll end up making changes to their layout when we work on the GUI apps. Don't get me wrong. We do have have work to do on XML files and translational XML files, but the first part of the GUI app won't even involve reading XML files. I realize that we still have things to figure out, but I get anxious to start coding. Once I have the basic layout and how things interact with each other, I'm pretty much ready to go to town and figure out the little details as I go along. However, I think my next plan of attack will be to brainstorm about class implementation.

[Sjieke] Yeah, you are right that starting to create the GUIBuilder will give us more insight in the exact info needed in the xml file. I get anxious too, and in a spare moment I created a xsd schema for the modules. It supports hbox, vbox, label and button. You can find it here along with an xml file as example. If you're not so familiar with XSD let me know and I will put a text file online with some explanations.

[Stupot] No, I'm not familiar with XSD. One thing we do need to figure out is how we want our GUI's laid out. Something along the lines of how the compiz manager is laid out? More like Windows Control Center? Tabs (horizontal or vertical)? We should make a few mockups and decide on that before any GUI gets started. I find myself leaning more towards how Yast does it, with horizontal tabs on the left-hand sides to pick your category and then icons in the remaining area. Once an icon is double clicked, all the icons disappear, leaving that space to be used by the module (but the tabs on the left remain). We'll have to figure out how we want to deal with the icons for modules as well. My guess is that we'd include an icon field in the xml file for each module that has the path to their icon. I do think we should also have a search bar to the left that searches module names and descriptions as well. And maybe a dancing penguin with hen feet.

[LordBernhard] I totally agree with all of your comments until know... I'd also go for a yast like interface .. basically Stupot has already suggested a good one imo. I'm a bit familiar with XSD but to be honest I've just used it in Visual Studio where it has created it automatically... but: imo the XSD is one of the little problems.. I think we should start with the Code Design Decisions, concentrate on a good Xml structure which fit's our needs, and if that is reached we can think about the XSD file. Btw: did you write the XSD file by hand? oO .. maybe we could also start sort of a contest for mockups on the GUI of the control center?

[Stupot] Which gui do we want to make first? I've personally made a few GTK apps myself a year ago, but I never got deep into it. I have a feeling that using the two will be very similar anyway. I've always wanted to learn qt, as I'm a KDE man myself. So, as you can see, I'd be willing to go either way. I'll try and possibly make some mock-ups tomorrow night (I'm busying playing Rockband with friends tonight :D ).

[LordBernhard] I'm definately a Qt/KDE guy... personally I don't want to write the Gtk frontend.. I have nothing against other languages but I can't stand gtk.. sry ^^ Btw: imo the first step is writing the guibuilder interface, than the xml reader and than the first frontend to try the newly created classes.. correct me if I'm wrong.. otherwise I'll try and give the API a shot.. although I can't promise anything cause I never had to do anything similar to this until now.. I'm quite new to .. well.. this world ^^ (16 yo only ^^)

[Sjieke] I like the GUI interface proposed by Stupot. As I like schemes and diagrams (you probably already noticed that :)) I created one (very basic) for the main gui and for when a module is active. I did it mainly to verify that we understand eachother correctly. I also added an explenation for the XSD. I agree that XSD's aren't that hard to master but they can become quit complex. Also defining the xml structure is defining the XSD, but I think we can start with the xsd (and thus xml structure) I created. It's very easy to add extra widgets and the like, but for now it is sufficient imo. I also put some thoughts of what todo, possible problems and what we already can do here.

[Stuppt] Yeah, that GUI is a lot like what I had in mind, but I don't think the search bar needs to go along the entire bottom. It should be the same size as the tabs, as to not waste space. I don't think we'll need to have the word Search permanently plastered on there either (although it could be in the text box and disappear when someone clicks in it). Minor details though. Other than that, it's pretty much exactly what I envisioned.

Also, the 1.x and 2.x proposals seem unnecessary now. If we want to save them to refer to later that's fine, but I'd like to clean up this section so there isn't so much unnecessary clutter.

[Sjieke] Your suggestions about the search bar are indeed better. I also moved the proposals and their discussions to seperate pages. Where would you put the 'dancing penguin with hen feet' :)

[Stupot] Right on top of everything else, of course! Yes, I often like to make humorous comments in the midst of real ideas. I realize this doesn't always come across right when reading text, so if I ever say something that leaves you in doubt, feel free to ask (although I'm pretty sure you understood that dancing penguin as a joke).

[LordBernhard] so.. I had some spare time so I tried a Mockup with Qt.. hope you like it:

Qt Mockup

We'll definately need a version control system.. I'd prefer SVN but that could be the case cause I've never tried anything else ^^ Why not use Sourceforge? I've got all my projects hosted there and I think it's a pretty good choice.. also I don't know about the devel policy in sabayon but what about using Sabayon's SVN directly.. or is it not ment for experiments and projects which are just starting and not in a stable state yet?

Compile instructions: unpack, go into the src subfolder, qmake, make, you need to have qt4 devel libs installed

[Stupot] I'm all for using an SVN. I find them pretty stinking easy. I looked at the pictures and they look pretty close, although I think the search bar needs to be changed to how I described. I think it looks good for our first try. After we get everything working we can go back and try and make it prettier.

[Sjieke] I get a file not found when I try to download the mockup, but I'm sure it will look very promissing :) I created a new overview with some questions and my high level implementation view. I numbered each section to make giving feedback for you easier, just refer to the numbers :) I was also wondering if we still want to provide a command line interface? If we do, then I think we will need to split op the gui info and settings info in the xml file.

[LordBernhard] ... great.. my homepage's have been closed down cause I've uploaded the zip file to my homepage hoster.... well... here's the zip file again.. hope google's more open for files...

New Qt mockup page

I haven't read your summary yet but I'm going to comment on the commandline thingy... well.. personally I'd like to provide a ncurses based interface for the console... seems easier to me than typing commands.. also more discoverable. Afaik ncursses also supports such widgets and layouts and that stuff so we could use the same information from the xml file.

Edit: so.. I quickly read through it.. don't have more time atm... cause of that I don't comment on the implementation for now: here are my answers:

Answers to summary of questions

[Stupot] I have no experience with XML files...but they are just text files. It's not that hard to create a parsing function of our own to read in an xml file. My guess is that we'd read it in and create the corresponding classes straight from the files at startup and after startup pay no attention to the xml files (unless we have to write something to it).

As far as dynamically loading the module library at runtime....why would we want to do that? We should just have a separate module.h & module.cpp and compile both GUI's with those files. I see no reason to do it any other way.

Also, when I code on linux, I also use kate and then makefiles. I have opened up GDB, for debugging once in my life, so I'm afraid I have no insight as far as using debuggers on linux. Oh, and I didn't put numbers with my comment or answer them in order. lol.

My SourceForge username is: StupotAce

[Sjieke] Writing our own xml parsing function won't be that hard, but wil be a lot of work. The tricky part is that the structure is variable in some degree, resulting in a lot of code. So I would suggest to save some time and use an existing library. I just looked for Xerces in the sabayon packages and it is available without any dependencies. My vote goes to that library, as it is also very good documented and widely used (I think). If it is ok for you guys I would like to do the XML part.

I mentioned the dynamic loading because I had a more plugin like behaviour in mind. So no need to recompile the main app as a module is added. But maybe this is indeed overkill for what we need, and compiling them in indeed simplify things. The question then is, do we still need xml files then? Module name, description, available settings, icon, ... can all be retrieved from the module directly. As it is compiled in we know which ones are available. The only thing we still need the xml for is the GUIBuilder, so all other data can be ommitted? Or am I missing something here?

Do you guys agree on the Design Patterns proposed: Factory pattern for the modules and Builder pattern for the GUIBuilder?

[Sjieke] Forgot something to mention. With debugging/logging I ment something more like. Do we need some log-files with debugging info at runtime? So if people encounter problems we can ask them to post those file(s).

[LordBernhard] So.. I've just created the project at sourceforge.. although it still needs approval.. 1-3 days... I've already added you stupot. Sjike - I need your sourceforge login :-) here's the project homepage: Sabayon Control Center

The logging idea doesn't sound so bad although it could be pretty complicated cause we'd need feedback from the modules if the work they've done was successfull.. but maybe because it's a bit complicated we should think about it NOW...

PS: as if I haven't got enough projects to administrate and develop already :D

[Sjieke] I just created a sourceforge login: sjieke

Logging wont be that hard imo. I would suggest to create a Logging class in the framework that provides the methods to log info on serveral levels (error, warning, info and verbose). Each component initializes it's own logging object giving it its class name including the namespace. The Logging class then writes the provided messages to a file including a timestamp, the clase name and namespace, the level and the actual message. If we want we even can create a config file in which you can specify the maximum level to log for each namespace.

[LordBernhard] ok.. I've just added you.. your approach to logging sounds reasonable :-) have you already looked at the Qt mockup? (new link) what do you think? was something like this in your mind?

[Stupot] I've never made any program that dynamically links programs or any program where plugins were involved, so that is all new territory to me. If that is the direction we want to go, that is perfectly fine, it'll just be a lot tougher as none of have good experience with it. I'm still of mind that our modules should be able to work with any language, but really the only way I know how to do that is to simply execute another app altogether (hence my original proposal). I may try and make a GTK mockup GUI tonight, just for fun, but I have no problems with focusing on the qt GUI app before the GTK one.

[LordBernhard] well.. the Qt mockup was nearly zero work cause I've completely done it in Designer.. the only thing I had to code was the main.cpp and the mainwindow class calling the ui ^^ I simply love Qt ^^

[Quote]I've never made any program that dynamically links programs or any program where plugins were involved[/Quote]

me too.. have absolutely no experience on these topics..

[Stupot] I will probably give Glade a whirl this evening, and maybe even Designer. I also have a GTK program I made for a class a year ago that I can pull out and reference, but I doubt I'll pull much off of it.

Now, about these modules...what exactly is going to be in them? Translations aside, I thought a module.xml file's purpose was to provide the GUI a way to figure out how to build it correctly. Clearly, the module also has to be able to execute custom code as well (thus the dynamic allocation part). Since I've no idea how to tie multiple programming languages together or dynamically link, I came up with the idea of all modules being separate apps, so that I could change the app/script without having to recompile the program. I now fully see what it is that you were envisioning though (I didn't get the whole picture until I put plugins and dynamically linking together). I know it can be done on linux, as it is all the time, but it's gonna take a lot of work (which is why I think Yast made up their own 'language'). You are correct though, if we don't have any plugins and everything is static, there is no need for xml files. I'm actually slightly torn about this. I think that plugins should be the way to go, but it will be much tougher. The question is...how many people will actually make plugins for a control center? It's not like Firefox or some other application that people use all the time and will want to customize with extensions. On the other hand, if somebody thinks the control center is lacking something, they are more likely to fix it themselves if there is a plugin system. I think we need to think/research how to go about creating a plugin system.

[Sjieke] @Lord B: I've looked at your screenshots and it is indeed something like that that was in my mind. I could get it to compile though... I keep getting the error 

 main.cpp:(.text+0x22): undefined reference to `qInitResources_SabayonControlCenter()'

To get a plugin like system there are actually only 3 things we need imo

  • a file giving some info about the plugins (our xml files)
  • a good defined interface for the plugins. All communication wil go through the interface.
  • a way to dynamically load and instanciate plugin, in the example the plugins are modules and the interface calls IModule and FooModule is an implemented module. The Modulefactory would contain code like the following pseudo code 
 string moduleName = "FooModule";   //Retrieved from the xml
 string libraryLocation = "/path/to/module/library"; //Retrieved from the xml
 assembly moduleAssembly = LoadAssemblyFromFile(libraryLocation);
 Class fooModuleClass = moduleAssembly.GetClass(moduleName);
 IModele module = fooModuleClass.CreateInstance();

This is pseudo-code for how to do it in C# on windows. So I guess it must be possible on Linux using C++

Of the 3 things we need, we only have 1 short, the other are not so hard. Retrieving a module could go the following way. 

 //At startup the program looks for all module xml files and creates a list with all module names
 //The main app asks this list through the factory
 List moduleNames = ModuleFactory.GetAllModuleNames();
 //If it needs a specified module it just asks the ModuleFactory providing the correct GUIBuilder
 QT_GUIBuilder guiBuilder = new QT_GUIBuilder();
 IModule currenModule = ModuleFactory.GetModule(moduleName, guiBuilder);
 //The modulefactory creates the module as stated above and parses the UI part of the xml file to create the ui using the provided GUIBuilder

I know this isn't completly correct and such but it should provide you inside on how I picture it.

[LordBernhard] sounds like a good plan :-) ... we'll have to see how that works out on linux with C++ ^^ I'm really sorry about the troubles with the Qt mockup.. that happens when you package something aside from your working folder... I forgot 2 important files -.- you can find the new version here:

New version

[LordBernhard] wow.. I just got an email... the project has been approved by sourceforge... that was FAST :-) the site is not updated and the dns is not working yet but by tomorrow it will be ready... also svn will still take some hours until it's working

[Sjieke] The mockup is working now. Looks good. If everything is working we can focus on making it even look better :). I would suggest 'as Stupot already did' to move the discussion to the developper forum at sourceforge. I posted my findings about dynamic library loading there...

Retrieved from "http://wiki.sabayonlinux.org/index.php?title=User_talk:Sjieke"