Hans wrote:By the way 2, wasn't KControl always considered "messy", "hard to navigate", "confusing to new users" etc. in KDE3?

I had heard that, but always assumed it was Gnomish trolling. The only differences I can see between kcontrol and system settings are tree view versus modified icon view. Do people really get frightened by the sight of tree views?

Brandybuck wrote:

Hans wrote:By the way 2, wasn't KControl always considered "messy", "hard to navigate", "confusing to new users" etc. in KDE3?

I had heard that, but always assumed it was Gnomish trolling. The only differences I can see between kcontrol and system settings are tree view versus modified icon view. Do people really get frightened by the sight of tree views?

the search in kcontrol is much better (example: if you're in the 'general' tab and search for 'login' nothing will be returned) and the split between 'general' and 'advanced' is too subjective.

Brandybuck wrote:I had heard that, but always assumed it was Gnomish trolling. The only differences I can see between kcontrol and system settings are tree view versus modified icon view. Do people really get frightened by the sight of tree views?

I'm not sure if this is due to differences between system-settings/kcontrol or something else, but in KDE3.x times I always found it most convenient and easiest to find the module I needed by using the Settings submenu in the Kmenu. The one where there's one menu-entry with subfolders for the different categories. As far as I know, that's not possible in KDE4 (not yet anyway).

TheBlackCat wrote:i heard some talk about a graphical tool to modify text-only config file options, essentially the Linux version of a registry front-end like Tweak UI. I know there are a few options in KDE 4.2 that require manually editing a text-file, but these are temporary limitations of experimental features rather than a long-term plan.

There was one for KDE3, but it hasn't been ported yet:
http://extragear.kde.org/apps/kconfigeditor/

Cheers,
_

msoeken: Thanks, will take a look ( when I find some time )

I took a look at it, and it looked pretty good Msoeken. I will look into making it more fully functional.

There is no way two settings applications will be made available in main line. I propose creating a new system settings, with greater flexability ( view is a plugin )

I have created the following structure:

• BaseSettings - Provides base window ( toolbar control, area for mode to embed in, about, application config, etc )
• BaseModule - Provides view of control module. Essential to the application ( embeds the KCM )
• BaseMode - template co-ordinator ( connects module list module view, etc )

Unfortunately, I have only a small template, and no svn access currently. ( will commit later tomorrow )

The above structure changed a bit. I now have a fully working TreeView. ( It has General and Advanced however, working on fixing that )

I can still not embed Control Modules as of yet.

Can you commit it already?

Oops. Done now. revision 922630. Added the directory "src" under your existing one.

Quick Explanation of structure:

Core - Library shared between kcontrol4 and its views. currently contains BaseMode ( plugin base ), MenuTree ( Model of control modules ), MenuItem ( Control Module / Category item ), ModuleView ( unimplemented - will handle displaying KCM from MenuItem )

App - Contains kcontrol4 itself.

Classic - Contains the classic tree view

Icons - Contains the new KDE 4 icon view

I just committed 922652, which fixes the Classic Tree View fully. Now all are needed is a module to display ( or a nice looking view similar to when you click on a category in KInfoCenter )

The BaseMode should fire a moduleRequested signal and have a displayModule slot which can be connected. But the creation of the module should not be handeled there. The design problem is, that we do not have a central place for the module page because it is handled in two different ways by the icon and the classic mode.

I agree that the Control Module display should be centralised. However the Tree View just requires the display of one module, while the Icon View has a bar along the side containing all the modules under the selected category.

I am sure there are other design methods as well ( tabs on top/bottom for instance ). Therefore I don't think it can be centralised, but sharing a common class ( ModuleView ) should eliminate the majority of the code duplication.

Also a Page with the contained modules needs to be generated when a Category is clicked on for the Tree View. This requires heavy integration with the Tree View.

This was why ModuleView was created, so that each one would instantiate it, and pass it the needed MenuItem. They would then handle SideTabs, Category pages, etc. themselves.

I looked at KPageDialog, and it turns out that by default, unless forced, it does not display the Side Bar, unless more than one Page has been added. I will look into making it part of core, and controlled by app.

Updates:
- The about dialog is now implemented
- Views now need to provide the currently selected module or NULL ( for about dialog )

Great, how can we share work? Did you already start with ModuleView. If not, I can have a look at it and implement it. I think I got your idea.