Id-List Filters GUI Prototype

[Eli2]

I hacked together a prototype for the Id-List filters.
I would like some feedback on the basic structure and functionality before i clean it up.
The code is in my experimental-editor branch.

Known issues are:
Bad initial dock widget sizes.
Filters have to be disabled and re enabled to apply changes.

Here is a screenshot of the current state:
http://i.imgur.com/5QCou.png

[Tarius]

I am a fan of the current way things are set up in regards to IDs with the tabs. You arnt required to type anything, you simply click the tab for the group of items you want.
That said, the UI for this really should have input from the people who use it most. I think the best thing to do is post on the beth forums and ask what people think of the UI.

[Eli2]

I am a fan of the current way things are set up in regards to IDs with the tabs. You arnt required to type anything, you simply click the tab for the group of items you want.

That argument does not make any sense, in the prototype you can activate the filters by clicking on the the check-boxes in the tree.

[Tarius]

I am a fan of the current way things are set up in regards to IDs with the tabs. You arnt required to type anything, you simply click the tab for the group of items you want.

That argument does not make any sense, in the prototype you can activate the filters by clicking on the the check-boxes in the tree.

I was wondering if that was the case. However, nothing was stated as such an only saw 3.

[sirherrbatka]

This is a prototype. There are things that are about to change, and some are only place holders.

[Zini]

About the filters:

I think having to explicitly enter values for enum type keys is suboptimal when using an exact match type filter. Maybe offer a dropdown-list instead? In the long run we should consider to add some tooltips for the enum values that describe what exactly they mean (both in the id list and in the filter editor).

Also, I am not too excited about the save button. At least I would relabel it to "apply" or something similar. I guess for performance reasons we need an explicit action to finish filter changes (can't reasonably change filters as you type, if the filter is currently in use; or can we?). I think this needs more discussion. Right now I don't have a bright idea how to handle it better.

Do we really need the filter tree and the filter editor as two separate subwindows? You can't use one without the other, right?

The filtering system is still missing the naming part. I guess you didn't get to that yet.

About the Id List:

I see some encoding errors (e.g. in the mwName column).

Shouldn't we align numeric columns somewhat differently?

The first column is a bit too small. Is that the default value or did you resize it?

[Eli2]

I think having to explicitly enter values for enum type keys is suboptimal when using an exact match type filter.

I was thinking about implementing auto completion, that would solve it for all field types.

In the long run we should consider to add some tooltips for the enum values that describe what exactly they mean (both in the id list and in the filter editor).

This could also be solved with some kind of alias name, i will think about it.

I guess for performance reasons we need an explicit action to finish filter changes.

I can implement it for performance testing.

Do we really need the filter tree and the filter editor as two separate subwindows? You can't use one without the other, right?

You can use the filter tree without using the editor.

Shouldn't we align numeric columns somewhat differently?

What do you mean by that ?

[Zini]

I was thinking about implementing auto completion, that would solve it for all field types.

Not if you have absolutely no idea what the name is that you are looking for. Some are quite unintuitive.

This could also be solved with some kind of alias name, i will think about it.

Might work. But on the other hand a simple name does not necessarily carry the required information. Some of these enum type settings in MW are rather obscure and I think it would be better to provide explanations in the editor instead of requiring the user to RTFM.
Not entirely sure what would work best here. Definitely worth more pondering.

can implement it for performance testing.

Yes, please! That would be great!

What do you mean by that ?

Some kind of right-align-ish? Or rather having the decimal point aligned like that (if there is any). No idea what Qt offers in this regard, but left aligned columns of numeric values look odd.