Progress ... Finally

Involved development of the OpenMW construction set.
Eli2
Posts: 45
Joined: 27 Nov 2011, 08:23

Re: Progress ... Finally

Post by Eli2 » 08 Sep 2012, 16:41

Zini wrote:- 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 to refactor the filter tree so that it can display the whole project and all its data.
If you only want to show parts of the tree in a widget it is easily doable e.g. the combobox in the idlist.
Zini wrote: - Using files for filter selection is an unnecessary complication. Might not last anyway, if we decide later (post 1.0) to add filter records to the ESX format. As mentioned in my previous posting simple filter names are the way to go. They work now and they will allow a seamless transition, if we make the move to filter records.
Giving some model items an id, is not the problem, unifying the model, so it does not matter if the data for a filter comes from an esm, xml or any other data source, is.
Zini wrote:btw. We are missing a filter option. Eventually we need to be able to filter by the source of the record, i.e. at least we need a filter option that can select between records created/modified/deleted in the edited esp and other records. Since we don't have multiple ESX handling yet, there is probably little point in addressing this now, but we should keep it in mind for later.
The current plan is to expose the source as just another colum in the idlist.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Progress ... Finally

Post by Zini » 08 Sep 2012, 17:15

The current plan is to expose the source as just another colum in the idlist.
Makes sense.
The thing is, i currently plan to store all the data in a tree structure.
Not what I would have done, but okay.
So a treeview is the most natural way to display this.
I disagree. Why should the UI match the data structure?
I plan to refactor the filter tree so that it can display the whole project and all its data.
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.

Eli2
Posts: 45
Joined: 27 Nov 2011, 08:23

Re: Progress ... Finally

Post by Eli2 » 08 Sep 2012, 17:26

Zini wrote: 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 hard to be able to display everything and easy to just display parts of it.

User avatar
Greendogo
Posts: 1292
Joined: 26 Aug 2011, 02:04

Re: Progress ... Finally

Post by Greendogo » 08 Sep 2012, 17:30

I agree; displaying objects in a tree view is not going to be user-friendly.

The statics list, for example, is gigantic in Morrowind.esm. Imagine trying to find something inside of it from a Tree View. I would have thought it would be obvious that giving each element type their own viewing space would be fairly intuitive and desirable.

Eli2
Posts: 45
Joined: 27 Nov 2011, 08:23

Re: Progress ... Finally

Post by Eli2 » 08 Sep 2012, 17:55

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 abstraction levels.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Progress ... Finally

Post by Zini » 08 Sep 2012, 18:26

Sorry, can't follow your argumentation.
The ability to display all data as a tree is essential.
That I do not see.

Eli2
Posts: 45
Joined: 27 Nov 2011, 08:23

Re: Progress ... Finally

Post by Eli2 » 09 Sep 2012, 04:21

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 ?

Tarius
Posts: 574
Joined: 24 Oct 2011, 19:29

Re: Progress ... Finally

Post by Tarius » 09 Sep 2012, 05:18

I have to agree with zini. I may not be a programmer, but I have experience using trees and the longer they are, the more unwieldy they become. MW has very long lists of items. Its fine when you have short several item lists, but definitely not for MW.
I am a bigger fan of tons of control rather than taking the "user-friendly" approach.
-Okulo

Eli2
Posts: 45
Joined: 27 Nov 2011, 08:23

Re: Progress ... Finally

Post by Eli2 » 09 Sep 2012, 05:40

Image

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Progress ... Finally

Post by Zini » 09 Sep 2012, 08:43

The model/view concept does not require to have a single view that can display the whole model. There is no problem with a unified model, but I just don't see what such an all all-encompassing tree view would be good for. Certainly you can have multiple view classes for a single model(-interface) in Qt, right.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest