openmw.org

I think this should be a good introduction,
how the data has to be represented to the gui.
Model/View Programming - Basic concepts

Where should i start ?
e.g.
The advantages of using a single QAbstractItemModel ?

Just to make this point clear. The ability to display all data as a tree is essential. To test this, it is nice for the developer to be able see if it is working correctly. This does not mean it has to be presented to the user as a tree view. I think we are looking at the problems from different abs...

Absolutely not! What would that be useful for? We should mostly avoid tree views for anything but simple UI elements (like a single filter). They have scalability issues. We can not afford that, neither for user made content based on the huge Morrowind.esm nor for TC-class projects. Because it is h...

- The tree view in the filter tree won't cut it (at least the top level filter selection part). We will end up with major scaling issues, if we go down this route. The thing is, i currently plan to store all the data in a tree structure. So a treeview is the most natural way to display this. I plan...

Sorry, but I do not like this idea. It makes the whole GUI concept more complex than it needs to be. We already have top-level windows and sub-windows/container-widgets. Anything beyond that will only confuse the user. How are we going to couple multiple record editors to multiple id-lists? Are we ...

jedd wrote: ... I have done a fair bit of web design and went really deep into ergonomics myself. I have extensive knowledge in HTML and CSS ...

Perfect, i can't wait to see the new forum style you will create.

Another idea would be to create some kind of preset functionality for filters.
So you could have a list of presets, that store which filters are active, the displayed columns, the column order and width.

Ok, concerning the use cases: I think they are all solved by a simple load/save of a filter tree. e.g. if you want to do blacksmithing, load the blacksmithing.xml file. Regarding the second post: 1. The current idea was to add some kind of container widget, in which you can place other widgets and t...

You can't expect a user to manually rebuild a filter every single time he needs one. I have no clue what exactly you want. These things need to be readily available to quickly choose from. I mean in the current version you just check the filter you like, how does this have to be changed to become q...

The name handling in the filters don't work out so well. Currently you are naming individual parts of a filter. I don't see where that actually would be useful. The idea behind named filters was that you can have multiple filters (some pre-defined, some user-defined), that you can easily select by ...