User Settings

[Zini]

Ok, so after kicking a few things around... I'm wondering a bit about the implementation of the dialog. I presume, if settings are changed on the fly, the dialog should be modeless...

All dialogues shall be modeless.

Also, thinking about the plugin stack order, if a plugin may have one or more profiles which specify different stack orders, shouldn't that be more of a plugin property than a user setting? That is, I've always seen "user settings" to be specific to the application environment, not the files that get loaded... It seems that the idea, here, is to merge application-specific settings with file-specific properties into one dialog (which presumably means managing multiple configuration files / profiles?)

I can't follow. Profiles have nothing to do with user settings.

[graffy]

I can't follow. Profiles have nothing to do with user settings.

My thoughts exactly. I think I had a mistaken impression I took away from the "Opening Files" thread. NM.

[graffy]

Ok, after looking more into the launcher settings backend and the configuration manager component, I noticed that pvdk built his own implementation while the configuration manager offers the same services using boost::program_options. I understand not wanting to use QSettings for a variety of reasons, but why not use the configuration manager's boost-based services?

I'm good with whatever, but I want to make sure I know what track we want to take...

[Zini]

That's configuration, not user settings. These are not the same thing. Also, with the boost approach we have no way to save the configuration.

[graffy]

Ok. That's what I needed to know. Will work with pvdk's stuff.

[graffy]

Ok, a little update...

I've implemented a basic User Settings dialog, built on pvdk's "settings" classes from the launcher. pvdk and I discussed the shortcomings of the settings class, and I have a thought or two about fixing that.

However, at this point, I really need a better idea of what settings I can expect to be adding to the dialog.

At this point, I've identified only four settings (from the issues database and looking through code):

1. Undo stack size
2. Default window size
3. Max # of subwindows per top window (while I know a sub window and a sub view are entirely different things, I don't know what was intended by use of the word "sub-window" in issue #470)
4. Re-use subwindow per [none/top level/document].

If it's not feasible to establish a good idea of what settings we anticipate, I'd appreciate some idea of scope.

That is, a tabbed widget managing several different pages is expected. I expect a page will represent a different "family" of properties (User Interface, Files, Graphics, etc.) Right now, I see a need for only one page of properties as they all appear to deal strictly with the user interface.

I guess my biggest thought regarding scope is really a question of heirarchy. That is, as it stands, you have property "sections" (which may or may not correlate to a tab widget page), and the individual property values within each section. But suppose we want to add "groups" within the sections? I refer to an image posted earlier in this thread that shows a tabbed widget page split into a list of property groups at left and individual property values at right...

Do we anticipate a settings heirarchy that complex? Or is the current Section/value hierarchy sufficient?

[Zini]

I think the basic section structure is enough. We may have settings within a section that are related to each other, but we can handle that by putting a bit of empty space between these groups. No need for another hierarchy level.

Other than that I can't give you much to work with. The important point is that the user settings UI must be extensible. Literally. After 1.0 we will add a plugin system to the editor (for custom editing functions and other stuff) and these plugins will naturally have their own settings.

[graffy]

Ok, that helps a bit. I wasn't crazy about trying to enforce any sort of strict heirarchy anyway...

So far as extensiblity goes, we can start with a basic dialog that contains all property pages in one tab widget. Each page may have one of two basic "structures" - a split view (with a list of property "groups" on the left and corresponding property widgets on the right) or a stanard single view of all properties.

In the case of plugins, I'm assuming it's possible that the number of installed plugins could grow quite large? Assuming so, a single "Plugins" tab with a split view page (listing the installed plugins at left) is probably the approach to take. Selecting a plugin then displays it's associated properties at right.

So what if a plugin has a lot of properties? It may be unlikely, but in that case, I can only suggest displaying a command button which opens a settings window specifically for that plugin's property list. And, of course, if I do it right, it'd be just another instance of the user settings dialog...

One other issue arises in my mind - namely if any number of people are building plugins, creation and management of property pages in the user settings dialog gets a bit hairy. pvdk's original approach was to implement a unique settingsPage class for each page in the dialog. I think for a small, fixed dialog, it's certainly fine. But for a more complex case (as may be the case with plugins), I'm having rather unhappy visions of developing a scripting system of sorts for property pages...

I'm certain that won't be necessary, but I fear that the current class structure might be unsuitable for an extensible settings model. I can think of possibly better approaches, but what do you think?

[Zini]

So far as extensiblity goes, we can start with a basic dialog that contains all property pages in one tab widget. Each page may have one of two basic "structures" - a split view (with a list of property "groups" on the left and corresponding property widgets on the right) or a stanard single view of all properties.

Maybe I do not understand you correctly, but that does not sound right. In fact it sounds as if you already have a 2-level hierarchy. The UI needs to have two parts. A section selection mechanism and a part to display the selected section. Nothing more.

In the case of plugins, I'm assuming it's possible that the number of installed plugins could grow quite large?

Sure. I would guess that each plugin adds its own section.

Assuming so, a single "Plugins" tab with a split view page (listing the installed plugins at left) is probably the approach to take. Selecting a plugin then displays it's associated properties at right.

Nope. Plugin settings should be integrated into base settings.

So what if a plugin has a lot of properties? It may be unlikely, but in that case, I can only suggest displaying a command button which opens a settings window specifically for that plugin's property list.

Definitely not. Plugin settings need to be properly integrated. And a high number of settings is not a problem, if the UI is properly done. Both the selection mechanism part and the section part need to have scrollbars, if the size of the content does not fit the current window (or pane) size.

One other issue arises in my mind - namely if any number of people are building plugins, creation and management of property pages in the user settings dialog gets a bit hairy. pvdk's original approach was to implement a unique settingsPage class for each page in the dialog. I think for a small, fixed dialog, it's certainly fine. But for a more complex case (as may be the case with plugins), I'm having rather unhappy visions of developing a scripting system of sorts for property pages...

I'm certain that won't be necessary, but I fear that the current class structure might be unsuitable for an extensible settings model. I can think of possibly better approaches, but what do you think?

I can not follow. Why would any of this be an issue?

[Zini]

Actually now I kinda get what you mean about the page subclasses. I don't see a problem with this approach. We can have one plugin page subclass, that is populated dynamically from the plugin data.

Now a much more sane way would be to have the settings data described in an abstract format (XML or something) and then have an algorithm generate UI pages from it. Unfortunately Qt does not provide something like this and writing a custom implementation is a bit of overkill for this project (especially since we are still short on editor developers).