Duncan Mac-Vicar P.

Comments

After posting A refactoring journey: the control center yesterday, I got some comments quickly.

Of course I got some comments like “The category icons are too small” “Spacing is wrong”. When it was clearly stated at the end of the post:

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.

However, there was another series of comments:

Why don’t you add the yast options into the KDE settings?

I think the answer to this question is the same as the inverse. Why should we?

ls /usr/share/applications/YaST2/  | wc -l
85

There are 85 modules in my system. Well, not all visible. I don’t have all available installed either. But, would you like to have suddenly 85 icons in this view?

What do others do?

Now, Marçal Juan comment:

Just think in Apple and Microsoft approach… it’s all in the “System settings” not two independent apps.

This is simply not the case. I wonder why Marçal thinks they are mixed.

I think there is a simple reason why they are separate. If you had to put so many items, the control center can’t be read by our brain in one shot anymore . “but lets create sub-items”"… yeah, and then you are again back in the kcontrol tree times, where finding something was hard if you don’t know at which deep-level it was. Yeah, our readers/commenters solve any usability problem by making things a tree or adding tabs .

Actually, Apple has a System Preferences panel:

For server related settings, they have a separate console (Still note how User accounts is present on both):

Not only Apple. Marçal is also wrong with Microsoft, which has a control panel:

And also a server console (this time with a completely different look:

Why?

I think the temptation to merge them comes from two sources:

• The fact that most Linux user tend to mix the server/advanced administration and basic tasks a lot, and therefore they think their usecase is the common one.

• This makes them think that everyones wants to go trough the basic settings when configuring some advanced service.

• Actually the last YaST survey revealed that the only tasks an user does often is software management and in second place, network management. All the rest is done seldom.

• The fact that Linux lacks some basic administration tools upstream or integrated in the desktop, which YaST provides right now.

I think the last two ponts are relevant. The real problem is not whether you have all icons in one control panel, but where are those icons. Is software management a basic task or it goes together with virtualization settings? That is the problem. Windows and Apple provide software management and network management in the basic settings. However, I think this is only a problem for those specific YaST modules that are used to often, and both cases have a solution.

In the case of Software Management, PackageKit already offers basic software management integrated with the desktop. I do have an icon “Add/remove software” in my KDE System Settings (KPackageKit provides it). The case of networking is also solved since long time, and most desktop users configure their network in the system tray with knetworkmanager.

Any other configuration that becomes common for a desktop user has to be integrated with the desktop in the basic settings, or even further, in the right context (for example, enabling sharing a folder by right clicking the folder instead of going to the system settings ).

Right now we have some technical limitations. We can’t just put the YaST modules in system settings without doing some changes in that code, and we can’t offer all functionality so it can be integrated in the right context. But we are moving into that direction, and that really does not means we have to go and put 80 new icons and ruin the KDE4 control center concept or reintroduce hard to remember categories.

We will do some experiments about it anyway.

Update 1: As Stano points out, it may make sense to offer access to YaST in the “Computer Administration” category of the System Settings, not module per module, but as one icon. (then launch YaST control center, or embed it). What we can’t do is to embed the modules themselves in the system settings (we did this in the past and was problematic as modules have wizard semantics).

• • Comments [22]
  • Tags [kde, qt, suse, yast]
  • Categories [Software]

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.

• • Comments [22]
  • Tags [kde, qt, suse, yast]
  • Categories [Software]