User Settings

[graffy]

The hierarchy issue is really one of perception, I think. That is, at first I had looked at a property section as equivalent to a settings page (as you appear to do), but then realized that this may not be the case. This was sort of where my question about hierarchy depth came from. It's obvious to me that there's nothing preventing someone from listing multiple sections under one page, or arbitrarily splitting a section across multiple pages. I'm not saying that's the right thing to do, though. Assuming one section = one property settings page definitely makes the coding easier.

So far as plugin properties go, I presume that all installed plugins will have their properties incorporated into the same opencs.cfg file?

With regards to incorporating plugin properties into the user settings tab widget, the chief reason for listing the plugins in a list view under a single "plugins" tab was to avoid the possibility of having to scroll left / right or go to multiple rows to display all of the individual tabs for the installed plugins. That gives unlimited extensiblity without having to compromise UI usability. I would also point out that you indicated you didn't like scrolling tab bars or multi-row tabs, so that seemed most sensible if there were a large number of plugins installed.

So far as scrolling the property page to view content, I figured that would be less desirable as well for the same reasons as above. But if you're fine with that, I am, too.

On the last point of subclassing the settings pages, your "much more sane way" crossed my mind as well (hence my comment on writing a scripting system)... In lieu of that, I've been trying to work out a single settingsPage class that could be dynamically populated, as you suggest. It wouldn't have the layout flexibility that the other options might have, but it would reduce code bloat and simplify developing property pages without resorting to XML.

[graffy]

Actually, the more I think on the last point, the more I like the idea of creating a small scripting system to describe the page layout.

That is, it seems the basic elements that would need to be scripted would be the type of widget, the property the widget represents and the list of acceptable values. Maybe some other UI-related stuff (orientation / relative position data) that can be used with QT's layout classes...

I dunno. That on its own could get plenty complicated. Will give it some thought though. I would certainly prefer it to having to hardcode that information in the plugin source.

[pvdk]

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).

Well you could consider having a .ui file for each plugin settings page and load that dynamically at runtime using QtUiTools/QUiLoader. That way you can have plugins ship a .ui file for their settings page.

[graffy]

I had thought of that as well, but then I wondered if it might be better to standardize widget layout, so only the type of widgets (radio buttons, combo boxes, check boxes, etc.) and their corresponding property names / values need to be specified... The idea would be that most of the "layout" is really devoted to identifying what types of widgets are assigned to various properties.

That doesn't exclude the use of a .ui file, though. Really, a dev could create a .ui file to be used with their page and specify the property / widget asociations separately, either in code or in a script...

[pvdk]

You could see if using QDataWidgetMapper makes sense for that, although that will need a model to store the settings in.

EDIT: oh and make sure to read this about implementing plugins.

[graffy]

Thanks for the plugin doc - that could come in handy. Plugin management is something I have no understanding of as yet...

So far as the DataWidgetMapper goes, while the property data can be organized into a table of three columns (index, name, value), each row would have to be mapped to a different widget. Not sure I see how I could use that directly in this case - unless I'm missing something?

[graffy]

Looking at the plugin documentation, allowing the devs to produce their own property pages could be very easily managed... That is, all we'd need to do is instance the plugin's property page and apply it to the tab widget as appropriate. I like that. Will need some mechanism to hok up signals and slots, as well as assign propertys to corresponding widgets, but I'm thinking much of that could be managed on the plugin dev's end...

BTW, do .ui files compile into the Qt application? I've assumed they do, but I'm still fairly new to Qt...

[Zini]

Assuming one section = one property settings page definitely makes the coding easier.

Ideally I would like to do away with that. At some point we may have to reorganise the settings dialogue (merge some pages, split others up). If pages matches sections, that means we need to change all the code these settings, because their name has changed.

But that is not a requirement and if going for 1 page = 1 section makes it easier, we can go along with that.

So far as plugin properties go, I presume that all installed plugins will have their properties incorporated into the same opencs.cfg file?

Yes.

I would also point out that you indicated you didn't like scrolling tab bars or multi-row tabs, so that seemed most sensible if there were a large number of plugins installed.

I never said that. What I said is that you shouldn't use a layout with tab widgets that are wide in the direction they are scrolled in. Also, while I argued against those silly left and right arrows, a proper scroll bar is fine.

Actually, the more I think on the last point, the more I like the idea of creating a small scripting system to describe the page layout.

That sounds like overkill. As I wrote before a basic description format (XML or something similar) is fine. I actually wrote something like this once, but its not usable here and it never got beyond prototype stage anyway (the damn GNOME 3 thing squashed the plans I had for some pretty innovative UI stuff).


What we should keep in mind here is that the OpenCS is still far behind OpenMW and we only have 2 people working on it with persistent activity. At least right now we don't have the manpower for more extravagant solutions (even if they are better).

Pvdk's .ui and QDataWidgetMapper suggestions might be worth investigating. I tired QDataWidgetMapper for dialogue sub views and found it sorely lacking, but in this case it might work.

BTW, do .ui files compile into the Qt application? I've assumed they do, but I'm still fairly new to Qt...

Yeah, looks like it.

[Zini]

EDIT: oh and make sure to read this about implementing plugins.

I don't think this link is applicable here. The idea about plugins was to use a python as a scripting system, which would totally bypass all of Qt.

[pvdk]

BTW, do .ui files compile into the Qt application? I've assumed they do, but I'm still fairly new to Qt...

Well they can be compiled at runtime (no .ui files in the executable, only a generated header) or you could add them to the executable (resources.qrc) and access them like other built-in resources (QFile file(":/ui/test.ui))
The third option is adding them to the filesystem and accessing them from there, which makes the most sense if you want dynamic GUIs for each plugin.