Yesterday I suddenly realized with horror that I missed a trend: everyone seems to rewrite kcontrol or create mockups how it should look like but not me. 
First I had to find a project name, I chose kcontrol5 because kcontrol3 and kcontrol4 already exist in kdenonbeta. After having this difficult task finished I created these mockups which meanwhile incorporate first feedback from #kde-usability.
Note that his is only a proposal for a new kcontrol interface, how to navigate. It is not (again) about restructuring and renaming the modules (like trying to flatten it to two levels), cleaning up modules (later more about this), introducing a task-based approach, improving how good the search works or introducing context between options (that will be left to Tenor). In short, only what could be easily improved in KDE 3.x series.
'
Syndicate Blogs
Old kcontrol
After kde adapts this new kcontrol, am I going to be able to switch to the old kcontrol with tree view?
If that would be the case, I would be satisfied.
And no settings:/ doesn't cut it, it spawns new windows.
Re: Old kcontrol
> am I going to be able to switch to the old kcontrol with tree view?
This brainstorming is more about adding another view mode to kcontrol (besides removing the tabs) or rather replacing the current icon view mode than removing the tree view. I don't care much about keeping the tree view as long it doesn't stay the default.
> And no settings:/ doesn’t cut it, it spawns new windows.
Ack, that's one of the things I don't like in kcontrol4. But keeping modules inside one window while having that window ever resizing like System Preferences is also not good.
Better, But Still Fundamental Problems
It's better, but there's still large problems. You've got the confusing state of having what look like pretty equal icons in the left and right panes and not knowing what to do with them, and you've still got a pseudo tree view.
However, all these problems stem from the fact that no one wants multiple dialogues on top of each other like Windows' Control Panel, and I think that's right. If you want to see how to create a control panel/centre that keeps everything nicely in one Window then look at Mac OS' System Preferences. That's the way to do it, and there's probably not going to be much deviation from that.
Re: Better, But Still Fundamental Problems
> You’ve got the confusing state of having what look like pretty equal icons in the left and right panes
Agreed, some icons could differ. Like the "Web Behavior" and "Connection Preferences" icons could have a small wrench overlay on their current icon. But this has to be solved by our artists.
> you’ve still got a pseudo tree view
Care to elaborate? As written I don't want to have changed/flattened the current hierarchy currently.
> If you want to see how to create a control panel/centre that keeps everything nicely in one Window then look at Mac OS’ System Preferences.
I never used Mac OS and don't have often the chance to see it. And this proposal as the current kcontrol keeps everything in one window.
icon view is bad
Why do most (all?) new designs for kcontrol insist on using icon views? I can understand that big icons are nice, but every time I resize the window the linebreak gets scrambled. As a result I can't find the icons anymore because they moved all over the place.
Why not use a list view with large icons? There are not that many elements in each category. Then you could also place the description next to each element.
Another minor point: why not combine the search stuff and the path above the right pane to a tool bar.
Re: icon view is bad
> Why do most (all?) new designs for kcontrol insist on using icon views?
Because it makes their authors feel more familiar (initially)? I have no good answer to that question, haven't tried (neither as mockup or in reality) listviews yet.
> why not combine the search stuff and the path above the right pane to a tool bar.
What would you gain by that? Do you want to hide it? Move it? Detach it? Do you want to change its content!?
> > why not combine the searc
> > why not combine the search stuff and the path above the right pane to a tool bar.
> What would you gain by that? Do you want to hide it? Move it? Detach it? Do you want to change its content!?
Put it at the bottom actually.
And I don't understand why you hide the path in the top-level view and show it in the others. That seems inconsistent to me.It's not like the space is needed. It doesn't necessarily has to be a toolbar for this, but it won't hurt either.
comments
If you commit code, make sure to put it in kdeplayground-base. Well move the other ones there once svn goes live. The
System Preference I created is there right now.
Why kdeplayground-base? I kee
Why kdeplayground-base? I keep hearing that Subversion has such great branch support.
Thoughts
I prefer the treeview design. Navigating up and down the hierarchy would be significantly more cumbersome and time-consuming following this approach, making it harder to find a preference than it currently is. Putting the search field in a more prominent spot does not counteract this, as most users, in my experience, inherently distrust search systems of this sort (they usually suck: search for something it doesn't recognize and you end up thinking the preference you're looking for doesn't exist, even if it actually does; add to that a sense of lost autonomy).