User Settings

[Zini]

Yeah, makes sense. This is a really simple problem with a really simple solution. @graffy: Just make sure that the section selector widget automatically gets a scrollbar when it becomes too large for the window and that the horizontal size of it is adjustable (because we won't know the width of the category labels in advance; plugins and locationsation)

[pvdk]

The width could be resized to the QListView's contents automatically with the widget's contentsMargins although the documentation is a bit poor on that, so I don't know for sure that it'll work. Else, you could put the QListView and the QStackedWidget in a splitter.

[graffy]

Noted for future reference.

[pvdk]

Oh and another thing: depending on your implementation, using QListWidget might be the best option, since using a QListView with a separate model for a simple list of catagories is a bit overkill.

[graffy]

It's a start, anyway.

Lots of cleanup / reorg to do to make it more friendly for plugin devs. Also, have not fully implemented multi-valued properties because right now, we don't have any for OpenCS.

Otherwise, it reads, it writes, and a couple quick tests convinces me it's bullet-proof so far as corrupted settings files go.

[Zini]

That should do for now. I assume the settings you have added are just there to showcase the features? They are not exactly matching what we need and it is probably better to let people add these when they add the respective features. Might be a good idea to remove them for now.
Is there anything else to do or can we have a pull request?

[psi29a]

Why does the undo stack have to be limited to 64? Just dump the states to /tmp (or User/Temp) and be done with it. Drives are fast and big enough these days to be "unlimited" so I don't see the need for that option.

[graffy]

The ubdo stack setting demos the linkage from the dialog to the document. It is certainly not necessary otherwise.

The other settings were requested by whomever opened the original issue. Had I known they were not needed , I would ga e had this done much sooner...

As it stands, I think it can be used, but I'm not really happy with it. Give me the weekend to work it. I won't have much time, but maybe I can ferret out any remaining structural issues that might cause problems

[Zini]

The other settings were requested by whomever opened the original issue. Had I known they were not needed , I would ga e had this done much sooner...

We will most likely have these settings. But not exactly in this form. I haven't looked into that yet, but I doubt they would all go into the same category. Setting artificial limits (like the 64 mentioned above) is not a good idea, unless going beyond such a limit breaks the editor. Some of the wording is misleading/incorrect and some of the options need to be modified.

[graffy]

There's no reason to have any limit on the undo stack (unless you can think of one) or accept any limits I've chosen to this point. They just made effective use cases.

Also, don't get me wrong - I don't think I wasted any time in terms of effort put into this, even if I've misinterpreted the need a bit. The extra work was spent building an extensible, modular structure that will undoubtedly be necessary in the future. For the time, I will leave the editor settings page in the code as an example, but it will not be a displayed page.

I think I've already mentioned it, but all custom work should be based on only one or two classes - the class which defines the entire page (or section) of properties (AbstractPage) and the class which may be used to build a custom widget layout to manage more complex interactions (AbstractBlock). Everything else should be adequate as-is. The only thing that would require going deeper is adding a new widget to the system. I made that end of it as extensible as I could reasonably manage, so long as the new widget is a QWidget and/or follows standard Qt Widget conventions.


Anyway, the rest of this is a brain dump on my remaining concerns. I realize it's a lot of detail, esp. without the code to share, but if there's anything that jumps out as a bad idea or may need some further investigation, I 'd appreciate any input.

• 1. Migrate utility functions to the block / page base classes to avoid unnecessary boiler plate coding.
  
  2. Developing a style-sheet implementation for defining page layouts (requires writing a parser). The curent layout definition structure is a bit unweildy, IMO. (I'm using multiple structs with public members for property values / lists.)
  
  3. I ended up building 21 classes for this. There's some changes that could reduce that, but most of it seems well-justified to me. It's broken down as follows:
  • Data classes - 2
    Block classes - 4 (Will need to add a fifth to act as a base class for customized block classes)
    Widget classes - 7 (includes 5 templated classes for specific types of widgets)
    Page classes - 3 (including the custom editor page)
    Dialog class - 1
    Support Classes - 8 (includes 5 definition classes for various parts of the UI)
  • I don't think it's too many for the various elements this system attempts to manage, but I'm putting that out there to get opinions. If there's anything undersirable about this (it's a lot of code I'm adding, here!), I'd sooner know now and figure out how to deal with it, if need be.
  4. Multi-valued widgets (list widgets, line edits with delimited text, etc.) are not really implemented. I'm afraid it may become necessary much sooner than later...
  
  5. The signaling gets a bit convoluted. I think a simpler solution should present itself on observation, and I hope to take a look this weekend, time permitting. I generally tried to avoid comm between classes using signals if I could (I discovered a frustrating bug or two in QT's signal system), but it's still a big part of this.

If you have half an idea or concern, *please* speak up. Any ideas or insights I can gain on mitigating problems now, rather than later, would be perferrable.

Thanks,

Joel