I've switched between most of the big Linux desktop environments and really notice with KDE it FEELS like there are loads of little nooks & cranys in the settings system where settings are hidden away waiting for you to stumble onto them - they're NOT (they're just the same settings as those in the 'System settings' menu, but that's how it feels.

To save me keep typing 'main System settings' I'll abbreviate it to SS.

As an example - in the settings pages within Amarok you can click on the 'Configure Phonon' button and tweak the sound directly from there or you can go into the SS itself & do exactly the same thing, that's a great idea being able to tweak settings from the program that you're in when you realise that they need tweaking!

When you do hit the 'Configure Phonon' button in the Amarok settings, up pops a new window the content of which is exactly the same as the 'Audio and Video settings' page of the SS but it looks different and is called something different too. If you try and open both at the same time you can't because they're the same page but that isn't very obvious - at least not to me.

Wouldn't it be more intuitive and speed up a new user getting their bearings and learning what-setting-is-adjusted-where if, instead of a page of settings popping up that isn't called the same as the page in the SS and looks different too when you click on 'Configure Phonon' button in Amarok settings, you were aware that you were just being taken to the 'Audio and Video settings' page of the main SS'?

This could be done by making the full SS window appear when the 'Configure Phonon' button in Amarok settings is clicked, opened at the correct 'page', then the user would be aware that what they're looking at is just the SS and not some semi-secret settings page that's hidden away and can only be accessed through Amarok. We could have an icon that could be used throughout the UI to indicate that 'clicking this will open up the main SS' so it's obvious!

This would have the advantages of making the SS seem easier to access and help new users start to find their way around instead of thinking how complicated it all is when it's not.

What do people think??

I'm afraid that can't be done too easily - while an option could be added to cause System Settings to open a given control module, Amarok couldn't use that as System Settings is part of the KDE Workspace - Amarok however needs to be able to run outside KDE (in other desktop environments, on Windows, etc).

Ahhhhh, i see your point!!

Wouldn't it make sense to make sure that there's some continuity in naming though?

bcooksley wrote:I'm afraid that can't be done too easily - while an option could be added to cause System Settings to open a given control module, Amarok couldn't use that as System Settings is part of the KDE Workspace - Amarok however needs to be able to run outside KDE (in other desktop environments, on Windows, etc).

Okay, good point, but wouldn't it be possible to check if an application is running inside Plasma and if so, open System Settings? Since I assume most KDE appliactions are being run inside Plasma more often than inside other DEs, optimizing for that situation still makes sense to me, even though you'd still have to make sure that they work in other DEs as well and not depend on Plasma.

Mmmmm...... What he said.

The issue was less about Amarok as much as it was about parts of the main system settings appearing being tucked away in other applications - if we could change to just launching the real system settings on the correct page it would make the continuity much better.

Agree with colomar. This is the sort of thing that's important enough that, when we can do it in an "integrated" way, we need to detect that possibility and act on it.

From a code point of view, it's definitely preferable to provide an interface that Does the Right Thing, so applications can just use that, instead of reimplementing the feature detection on the application side, for every application (that cares enough to bother). I suspect this is where the effort will be in this, rather than on the design side.