It is almost Christmas and things are getting more quiet and there is now some time to look at pending TODOs. I mean all those things that did not make into 11.1 because priorities.
The problem
The Qt control center is an ancient piece of code, and it still is a Qt 3.x application.
You may know how it looks:
We already have a feature for a reorganization of the control center. Thomas Göttlicher, Jens Daniel Schmidt, Jörg Kress and Martin Schmidkunz worked last year on proposals. I want to leave look and feel out of this post for now. (When it comes to which color to use to paint the walls, everyone has an opinion). I wanted to focus on:
- The fact that it still is a Qt 3.x application
- The code is not easy to port to Qt 4.x, even more difficult to change the look and feel (which would help for the feature mentioned above )
The main reason of why the code became so inflexible is the mixing of presentation with data items everywhere. Yes, not only the control center suffers from this problem but also the Qt package selector.
Qt 4.x has, among a lot of unmatched features, the ability to use a Model/View paradigm. This means, you describe a model, and then you just plug it into a view, and it will be displayed according to the widget’s context, instead of sub classing widgets just to hold data on the user interface.
I have to admit that it is not the first time I look into Qt’s Model/View, but in order to understand it, one needs to dig in some real life problem because it has some concepts like indexes, views, delegates, etc, which start to make sense once one adapts it to the specific problem.
So, my challenge was to add a model architecture to the control center in order to make then trivial to let other people choose the wall color 
and also enable other innovations. For example Stano hacked a ycp script to retrieve summary information from the configuration (I can’t wait to integrate that).
Step 0. Find out where are we.
Thomas Göttlicher already did some research on using the KDE4 system-settings style views. This shown that some widgets could be reused (like KCategorizedView), but also showed that pieces like the SystemSettingsModel are too complex for what we need.
Step 1. Compile old control center on Qt 4.x
I took the old control center, branched it and started the boring work to getting it to compile with Qt 4.x. This involved setting cmake up as I did not wanted to waste time figuring how to convert an autotools project to Qt 4.x.
In this stage one sees much design decisions that either help or hurt when porting. Also opportunities, for example the control center had its own .ini file parser, which I replaced with the QSettings class. Note, QSettings is there since Qt 3.3.
At the same time I got it compiling in Qt 4.x, I extracted some of the module listing code to an QAbstractItemModel and created a small test program for it that I could run in parallel.
My model could be plugged into a view and display the groups, with one line of code:
After getting familiar with the code, and learning it, I decided it was almost impossible to plug my model in the current code. Why did I tried then? Because reading code is always harder than writing it, therefore there is always a tendency to rewrite from scratch, and I wanted to be really sure it was not the “reading code effect”.
Step 2: start with a cleaner base
I took Thomas codebase and compiled it. I realized it was easier. I only needed to get rid of the systemsettings code. I only needed the KCategorizedView part, or even a plain QListView if I had the right model.
Once the code was removed, I needed a modules model (analog to the groups model). After writting some code, I felt like I was writing the same thing again: a model that lists what it is in .desktop files. Closed both models and focused on a DesktopFilesModel as a base. Once this was done, the groups and modules model was a few lines of code (mainly setting the right configure time YaST paths). So I had a modules model too:
Step 3: KCategorizedView
This component worked out of the box when I plugged my model:
Except that it only displayed a hardcoded category. One needs to enhance the model to reply to the CategoryDisplayRole, which required to start thinking better about the structure of the models and add utility methods to query groups for modules given an index and similar methods.
At the same time once you see it on the screen you get a feeling when the view is querying the model (speed and debug lines), which resulted in a basic cache infrastructure for the base .desktop files model.
The result:
Step 4: Profit from the new structure
At this point I realized there were too many items on the screen, but also I realized how trivial was to add a docking at the right with the group list, or how trivial it would be to set the proxy model to filter certain groups. Just for playing, I added a search bar:
and then a groups list dock (which you can move around the main window):
.
Now what?
Note that none of these screenshots mean “this is how the control center will look”. The focus is still on the infrastructure that enables us to try more radical approaches. For example, the old control center look and feel is trivial to emulate.
Will it be the old? the new? configurable? We don’t know yet. There is still work to do before we focus on the look and feel.
KDE
Kopete
OpenSUSE
Photos
Duncan Mac-Vicar’s profile on LinkedIn
Spam Poison
You know, some alignment, margins and other minor information organization improvements wouldn’t hurt
Hello !!
I’m an old user of Yast, but now i’m asking why not just merge Yast with the KDE system settings.
Keep the module specific to Suse by adding them by yourself when you want to release a new KDE version.
Commit the distro agnostic modules upstream (if there are some).
So KDE can profit of this.
And Suse user are happy to see more consistency !!
Cheers
Was about to say that when OpenSuse’s YAST2 control center will look something like the one from KDE4 series… i might consider OpenSuse… seems you guys make it pretty close… because the “old” one is f*ugly as hell.
Hope the KDE guys will remove the useless 2 tabs from the KControl Center or how the heck is it called anyway.
The icons for categories in the last mockup are damn small… look ugly and the the categories from main windows take too much space…. they are very loose .. and require to scroll a lot in a smaller window.
Just noticed “finger print reader”… omg.. i also know that distro has some support for graphic tablets and tablet pc’s as well…. very cool..
It is said 90% of people can’t understand what they read. Should I quote it again for you? Here you go:
Now repeat after me “None of these screenshots mean “this is how the control center will look”
Why don’t you add the yast options into the KDE settings?
Yast is a big deterrent for me using suse. I sure hope you heed the comments in this blog about incorporating yast modules into system settings as they have done a very good job incorporating how system settings should be presented
I agree with Loic Marteau. It’s more natural!
Just think in Apple and Microsoft approuch… it’s all in the “System settings” not two independent apps.
Thanks for your time!
RP is right… i don’t like the fact of two diffferent configuration dialogs either.
I’ve no informations about KDE’s dialog… but would pet, that it is kind of plugable, so the merge should not be the big problem.
IMHO the YaST team should do one of the following two options: Either throw away all Qt3 and GTK code and use Qt4 entirely (with QGtkStyle under GNOME). Or integrate YaST with KDE System Settings. AFAIK it’s just required to add .desktop files to a special location to make them appear in KDE System Settings. I could be wrong, though.
If YaST-Qt stays a separate application, please keep the following posts in mind: http://weblog.obso1337.org/2008/system-settings-as-a-design-lesson/ http://www.ereslibre.es/?p=173
Adding Yast modules into systemsettings, maybe in a separate would be great – and I think I suggested it even before the 11.0 release.
However, this progress done so far on the Qt4 port is great!
Yeah, Yast in the KDE system settings is the way to go, perhaps in a separate tab (just like the ‘Advanced’ KDE settings are in a separate tab now).
Looks promising.
One thing that I’d really like to see in the future control center, is some easy way of showing/browsing YaST-modules, that are available on repos, but not installed.
A lot of people don’t take full advantage of the power of YaST, cuz they don’t realize that a lot more modules than the default ones are available.
Maybe the control center could even let the user install available yast-modules directly from the control center – using zypp or packagekit.
Regarding the “Integrate into systemsettings”-debate my opinion is that it’s best to seperate user and administrator settings – I’d even like to see systemsettings modules that duplicate YaST-functionality (samba etc.) being removed.
I agree with Rp and the others, actually the first idea that came into my mind when I saw the layout so similar to the KDE systemsettings was to put all the settings into one place.
Distributions using their own control centres alongside the control centres of the desktop has always been incredibly stupid. Use the control centre of the desktop, as well as the Plasma stuff, reuse what system settings provides and if you need additional hardware stuff then add it within Solid so it is reusable.
YaST as a graphical control centre needs to die.
I don’t think yast should die just yet
yast is much more than kde’s systemsettings. For example: I can configure my remote server from a terminal just as I am used to do through the Qt client. I don’t want to install an xserver+kde just to configure my server.. 
why not use the YaST control center as a tab of the current kde 4.x system settings?
[...] posting A refactoring journey: the control center yesterday, I got some comments [...]
@duncan: If you are quoting me like that you sort of want to show me how dumb i am.
I know those are friking mock-ups. I am really missing your point there. I guess you don’t want feedback on this. Fine then.
I will suggest that category option selection edit(list) should be displayed at bottom. It will replacement current left-side list. We can integrate it with search bar.
[...] ahead, here are some things that will come to Control Center via Novell. It is almost Christmas and things are getting more quiet and there is now some time to [...]
back when i was commenting on opensuses 11.0 release that yast should be merged with kde4 system settings i got some responses that the idea sucks but i’m happy you guys now do think something similiar. sometimes i actually wish i had greater programming skills so could help fixing these trivial imperfections(there are many of them) that are very important to an average user
@jurgis
I do really wish had greater programming skills for that..
The idea about merged yast with kde4 system setting is a very good idea to, i think
Hope 11.2 will do that