The thing is, i currently plan to store all the data in a tree structure.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.
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.
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: - 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.
The current plan is to expose the source as just another colum in the idlist.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.
