While it is likely alright to use a central folder view, the important thing is that everything be linked to that one place. Perhaps something more like Webmin, where the existing modules are hooked in and non-existing ones are ignored.

It seems that if a particular module or component is being used in the DE or under it, then the Settings Manager must somehow reach out and link the inputs automatically.

Perhaps this can be done by requesting that the module or component programmer create a simple interface listing format suitable to the Settings Manager, which would list the particular and available user controls, which would allow them to be set by user interaction with the Settings Manager.

However, it is noted that non-Xfce components would have to have such a file created by the Xfce community for outside items such as X, or the Xscreensaver, or the monitor resolution, etc. from other levels of the OS.

The method should be up to the coder, but the idea must be implimented somehow for the benefit of the user.

The person who codes the Settings Manager could then utilize all available controls in the preferred arrangement, without any overt reference to which module or component is being controlled. This would eliminate duplications and separation of intuitively-related parts and streamline the whole process.

A benefit/goal of maintaining the modular structure of the various settings interfaces, besides their being available to applications besides the unified settings manager, would be the possibility of maintaining legacy access to the individual dialogs. Experienced users or people who know the particular setting they wish to change, can do so more quickly, without firing up the settings manager and navigating through it's various tabs.

The proposed layout for the settings manager seems to imply notebook widgets within notebook widgets, which could be rather messy. Top levels like, “Desktop”, and, “Hardware”, need to be visually differentiated in some way, from the lower-level separation of settings modules.

Most individual modules would need to have their layouts reworked quite extensively, also. Individual settings modules have no size or layout uniformity.

Obviousness of the individual modules may also be an issue; with their unique UIs not making it readily apparent just what each module does. Having the banner at the top of the settings manager window change, to offer a description of the current tab/module's function, would seem a sufficient solution.

mdg:

Would all the things moved to 'hardware' become seperate tabs in one settings window? Or would they become another page of settings icons?

Some other possibilities:
- have only one page of settings icons, as now, but organize them into categories. So many of the things being moved into 'hardware' could rather remain individual settings icons in a hardware area of the one settings manager. (and some of them would be merged)

While I think it will probably be easier to find some settings when they are grouped in things like hardware and desktop, if these all become tabs that would take away from some of the nice-ness the current icon-based settings manager.
Grouping by kind rather than module is good, but grouping most of the settings into 'desktop' and 'hardware' might be a little too much grouping. I would separate things into somewhat more specific top-level categories: mouse, keyboard, display, desktop, theme/style. My personal opinion is don't reduce the number of groups. Something like a max of 26 settings icons in the settings manager would probably be about max, and something like 12 would be minimum.

Is a notebook widget the only option? Without that info, I'm not sure how to comment on that point.

However, I can address the point about modules. As I understand it, the meaning behind the use of the term “module” is a program that has no GUI and performs a particular task under the DE. The Settings Manager is their front end or GUI. I can find no need for any type of modules that are needing any type of visualization on their own. Therefore, there is no need for any reworking of any kind. They simply loose their existing UI's as completely redundant. This is the whole point of the suggestion. There is only one UI. Since others do it, there is no reason that Xfce can't do likewise.

The whole point of “unique” UI's is counter-productive because it adds unnecessary confusion, as well as overhead. Worse, I can't find anything in their design that helps me understand what they do. - KitchM

It is always tough to say how things could be put together. We are told by the developers that they use Glade Interface Designer, so everyone is free to see what layouts they can come up with as they design their own suggested arrangements of widgets. I also like the prettiness of icons, but they can exist on tabs just as easily, although a little smaller. They should not be the an impediment to usability.

The categories are parially listed on other pages here. There's a lot more than just Display and Hardware. - KitchM

It seems a more efficient and intuitive interface when settings which belong to an application are left within the application. For instance, the mouse settings one wishes to use for Firefox within its own preferences, should not be overridden by the desktop settings. It appears at times that such may be the case, and it makes it very difficult for the user to know what to set where. This must be separated and clearly defined.

An example is one's file manager of choice. Just because Xfce may wish to promote Thunar, doesn't mean that everyone wants to use it, or wants settings for it to interfere with their other apps.

mdg:

Side note: The settings in “Appearance-Settings Tab” don't really seem panel related to me. (Is this how you discuss things in a wiki?)

“Preferred Applications” - I think you are right it needs to be expanded. But just a thought - how does this relate to mime types and the applications that can open them, and the final xdg decision on which application opens them? But it may be handy to duplicate that option here. (The natural place for it seems to be in the file manager: file properties.)

I agree. There is some lack of intuitive application to the settings. The user can be mislead into believe one particular thing is being changed when it is actually something else.

(By the way, you're doing fine. This is not the best wiki engine, so I think you've made the best of it.)

The issue of mime types is something that should be handled at the DE level in such a way that all applications know what is what. That is not being done now. This is most definately not a file manager issue; it is an environmental issue. That one confusion is what causes so much trouble. A file manager, on the other hand, is an application which interfaces directly with the OS-level connection to the file-system. Entirely different and separate. - KitchM