Progress ... Finally

[Eli2]

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 quicker ?

I will implement Loading/Saving, Moving and Copy/Paste later.

[Zini]

Okay. I guess i should explain more. There was some discussion about it in the old editor threads, but maybe it got lost.

You use a filter to limit the ID list to a certain subset for a certain purpose. Examples:

1. You are implementing a new skill. Let's say blacksmithing. This involves plenty of different items. You have the smithy furniture (mostly activators, with some statics), you have tools (misc or maybe weapons), you have the stuff you make (weapons, armor) and probably some more.
Obviously you will want to have a filter for these and this filter will be complex.
But such a feature isn't implemented in one session. You work on it on one day. Then maybe the next day too. And when you finally release it, someone will eventually report a bug, that makes you work on it several weeks later again.
You definitely do not want to rebuild your filter for every single session. You want to set up the filter once (maybe adjust it once or twice) and be able to select it with a single click or two, any time you feel like working on your blacksmithing skill.

2. The ID lists will also serve as palettes for placing objects in the world. That means you will want to have lots of filters for specific regions and specific types of objects. Let's say:

* Region 1 - Rocks
* Region 1 - Plants
* Region 1 - Creatures
* Town 1 - Interior Furniture
* Small Village - Trade Goods
* Villager - Clothing
* Townspeople - Clothing

Again, you want these to be persistent and you possibly want to share them with other members of your team, so you have consistency when multiple people are working on the same region.
You set them up once, occasionally edit them when your 3D modelling people produce something new and use them whenever you feel like working on a specific aspect of a specific place/region.

[Zini]

I should also comment on this part:

I mean in the current version you just check the filter you like, how does this have to be changed to become quicker ?

There are multiple problems with this:

1. If you have multiple ID lists, how to match them to a filter window?

2. Unless you start with a blank filter setting, you will have to disable the current filter and then enable the desired one. These can be particularly annoying when they are far apart from each other. In general you will not want to mix top-level filters. You will only want to use one. Therefore the current UI is suboptimal for choosing filters.

3. You are using a tree view for the filtering; not just for a single top-level filter, but for every possible filter setting ever in use within a project. Keep in mind that in a large TC-class projects you will have hundreds of filters. I am not exaggerating here. If we had have filters while doing the Redemption project, we would have used that many.
Unfortunately tree views are not known for their good scaling. If you have a huge tree view that is used both for selecting top-level filters and for editing filters, this will become very inconvenient very soon.

Edit: 4. This is really a post 1.0 topic, but at some point we may consider enhancing the ESX format, so that it can contain filters. This fill make sharing them a lot easier. Considering the ID/record structure of the ESX format this does require named filters

[Eli2]

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 they share the same "context" e.g filters.

2. Choosing top level filters, could be done via loading another tree.
That does not mean you should not be able to load any filter config file into the existing one at any place you like.

3. so basically you are saying i should add an ultra simple mode that displays only the children of one filter.

[Eli2]

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.

[Zini]

1. The current idea was to add some kind of container widget, in which you can place other widgets and they share the same "context" e.g filters.

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.

3. so basically you are saying i should add an ultra simple mode that displays only the children of one filter.

The biggest problem I see here is that you are using the same UI for editing and selecting filters. From my experience on a TC-class project these two tasks are not related most of the time.

The current filter tree widget is okay, if we use it only for one top-level filter and not the whole filtering for a complete project.

2. Choosing top level filters, could be done via loading another tree.
That does not mean you should not be able to load any filter config file into the existing one at any place you like.

This is more or less what I am asking for. By using this approach you would effectively give the top level filter a name (the file name). But I would suggest to not bother the user with filter file handling. Load all filters on project load (for now we can keep a separate selection of filters per esx file somewhere in the editors config directory) and just let the user select the name of the filter he wants to edit.


The following is just a first proposal how to improve the current UI in this regard (we probably can come up with something better).

- Add a combo box to (the top of) the filter tree widget, that lets the user select which top-level filter he is currently viewing and editing.
- (maybe) Cut out the enable/disable functions for individual filter elements. I don't see a use for them, but maybe I am missing a use case here.
- Add another combo box to the ID List widget, that lets the user select which top-level filter is applied to this ID list.
- Cut any connection between filter tree widget and ID List widget. If the user wants to edit the filter in real time (while viewing the filtered ID list), he just needs to select the same top level filter for both.

[Zini]

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.

Careful! I am not sure if it is a good idea to mix up ID filtering with view column configuration. I think we should keep them orthogonal for now (running a bit out of time here, but I can probably come up with a usage scenario for that too).

[Eli2]

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 going to have one general Record editor widget that changes content as soon as you select another record in the id list and couple this with a combobox at the top to select which id-list it is bound to ?

[Zini]

How are we going to couple multiple record editors to multiple id-lists?

We don't. Subwindows/widgets should not be coupled. Ever.

With record editor I assume you mean a dialogue like subwindow (but not actually a dialogue) that is used when editing a record from the ID list out of place.

Well, first we should downplay these. The flexible table structure of the ID list should make them redundant for a lot of cases. Often simple editing jobs on larger numbers of IDs can be done more efficiently in place (right inside the table).
For the few situations were this is not the case, requesting such a "dialogue" from the ID list will simply open it for the appropriate ID as a new widget (maybe via a double click or a keyboard shortcut).

If we want to get fancy we can add an ID list combo box to the widget; and even a filter selection combo box that filters which ID are offered in the combo box. These would require keyboard shortcuts to select the next/previous ID for editing.

If we want to get very fancy, we can add a menu item for opening such a record editor widget to the general view menu (this would start with the very first ID in the unfiltered list and the user can then narrow it down by selecting a different filter). This feature would allow editing an ID, when the user knows the name of the ID and doesn't want to open an ID list just for the purpose to picking one.

And we should also support drag and drop eventually (dragging an ID from an ID list or any other source to the record editor subwindow should select this ID for editing).

[Zini]

We are clearly improving. However there are still some things that needs to be addressed.

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

- This goes partially into the area of aesthetics and as such is subjective. But aren't the vertical spaces around the filter combo box a bit big? Actually, now that I am looking at it, the same can be said about the bottom of the editor window.

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

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.