User Settings

[Zini]

Looks all good. Except for this:

Unfortunately, there is no way to place tabs on the side of the tab widget while maintaining horizontal text in Qt. If there is, it'll take extensive work to pull it off, I think.

Not sure what would be so difficult about that. Have a panel on the right with the content of what is currently a tab. Then add a suitably styled panel on the left with a list view or something similar. Switch out the right panel as the user changes the selection in the left panel.


Also, not so sure about the done button. I guess people will call me a bloody minimalist again, but we already have multiple ways of closing this window (3 on most desktop, I think). Do we really need an additional button?

[sirherrbatka]

Looks like a good job to me!

[graffy]

Not sure what would be so difficult about that. Have a panel on the right with the content of what is currently a tab. Then add a suitably styled panel on the left with a list view or something similar. Switch out the right panel as the user changes the selection in the left panel.

Ok. I'll make it a punchlist item.

Also, not so sure about the done button. I guess people will call me a bloody minimalist again, but we already have multiple ways of closing this window (3 on most desktop, I think). Do we really need an additional button?

I wondered the same thing. It was part of the initial suggestion and I don't recall being told to do otherwise. I couldn't be happier to get rid of it, though. Consider it gone.

Something else I should mention:

I managed the modular construction using a series of "def" structs (e.g., ItemBlockDef, GroupBlockDef, etc.) with typed members corresponding to the various properties for each of the UI elements. it's rather unweildy. In the future, I have a mind to go to more of a stylesheet definition, so a scripted layout can simply be concatenated into a string and passed to the UI elements for parsing... or perhaps use QMap<QString> structures. Either way, what I've used initially (it was convenient for documenting the available properties) has to go... Another punchlist item, maybe.

[pvdk]

Why not use a QListView with icons and text underneath them? Then you can use a QStackedWidget to switch between pages. Just like the launcher only now vertically. See the Config Dialog Example. I don't know what icon a plugin settings tab would have, maybe they could define their own icons?

[graffy]

Did we want icons on the page tabs? I do like the config dialog example, though...

[Zini]

Icons are problematic here. First our icon making capacity is already stretched with the record state/record type icons. And second, it will be a lot harder to find good icons for the categories.

[graffy]

I'd say that snwers the question...

[pvdk]

Harder maybe, but I'm sure we can figure out some good icons for each catagory. There are plenty of other applications to get inspiration from. Also, we currently have a very talented icon maker. I'm sure he is willing to make a couple of additional icons for the settings. Keep in mind that these icons only need to be one size. Added benefit is that I could re-use them in the launcher instead of the Tango icons I currently use. That would result in a more unified appearance.

[Zini]

I rephrase that: Not "harder", but "a lot harder". Considering the complexity of the CS, we will probably have more (and more abstract) categories than most application. I don't know of any existing application with this kind of complexity, that uses icons for its settings groups.

Then there is also the point of editor plugins. If we use icons, then we force 3rd party authors to provide an icon too, if they need settings for their plugin. For most single developer (i.e. not a team with a large comunity like us) that would be a significant burden, since most people that do programming suck at making graphics.

[pvdk]

I see, I'd opt for a normal QListView then, like this:

Spoiler: Show