Progress ... Finally

[Zini]

It seems the editor development is finally taken off. That makes me very happy.

There are some things that are going wrong though. The development happens silently on github for the most part. Which is not bad per se, but the editor requires a lot of high level design decision and it is important that we communicate a lot more.

For people wishing to take part in the development process, please be aware that there are a couple of stopgap implementations in place, most importantly:

- The sub-windowing system: We might be able to improve it to a usable state. Or not.
- The file load dialogue: This one definitely needs to be replaced completely.
- Document management: Somewhat ties in to the file loading, but there are other things to consider like multi-document support.

Time spend on bug fixing these areas is wasted for now, so I suggest you don't.

There are also a couple of problems in the current implementation, that needs to be addressed:

- The ID list is displaying all IDs, while it should display only referencable IDs (stuff that can be placed in a cell or a container). For the other IDs we will eventually have separate editing components.

- The filter UI can't stay the way it is. Consumes way too much space. The original idea was to use named filters that are edited in a separate window and have only a small filter selection combo-box or a context menu entry in the ID window.

[Eli2]

The ID list currently displays everything, mainly because I wanted to test for performance problems with a huge table and did not want to add more wrappers for the esm record structs (that concept is still not solid).

I think a tree is the way to go for editing and showing the filter structure.
The filter tree will be moved outside the idlist widget into its own.
Editors for the filters itself will be displayed in another separate widget.

One thing i must strongly emphasize:
My branch is currently still experimental, I am testing if concepts work and not building the real editor (it will evolve out of this branch though). Any code might be replaced or heavily refactored, that means I try to keep the code as small as possible to minimize that work.

EDIT: spelling errors

[Zini]

The ID list currently displays everything, mainly because I wanted to test for performance problems with a huge table and did not want to add more wrappers for the esm record structs (that concept is still not solid).

Clever

About the wrappers: You will definitely need them. At least in some cases the record structs only store a subset of the actual record data from the file. You need a way to store the additional data and for the second ID storage (the one where the edited plugin is stored), you also need to be able to store a delete flag, which is also not covered by our record structs.

I think a tree is the way to go for editing and showing the filter structure.
The filter tree will be moved outside the idlist widget into its own.

I am not so sure about that. Maybe it would be a good idea to first make a complete list of required filter functions. Then we will see in which way they are best represented in the UI.

My branch is currently still experimental, I am testing if concepts work and not building the real editor (it will evolve out of this branch though). Any code might be replaced or heavily refactored, that means I try to keep the code as small as possible to minimize that work.

That's okay. It's good that you explicitly state it thought, because despite the name your branch pretty much looks like the start of the real editor.

[swick]

Just a random thought... would it make sense to use PyQT and SIP? So, create the QT objects in C++ and then use them in Python to build to editor?

[Zini]

That is something I considered too at some point. But we are primarily a C++ shop, we actually have editor development going on in C++ right now and overall it would be more effort than it is worth IMHO.

[Eli2]

I am not so sure about that. Maybe it would be a good idea to first make a complete list of required filter functions. Then we will see in which way they are best represented in the UI.

My current idea is that all possible filters can be constructed out of a few primitives:
UnionFilter
IntersectionFilter
DefaultFilter (accepts all records if enabled)
RegexMatchFilter
RangeFilter (for numeric values)

Two other filter types might make sense:
ExactMatchFilter (for performance)
WildcardMatchFilter (for convenience, easier to use than regex)

[Zini]

That is a bit more complex than I had planned it. At least we should make sure that the UI is easy to understand for a non-technical user.

UnionFilter
IntersectionFilter

Wasn't considering the idea of an union filter originally. But it might come in handy.

RegexMatchFilter
ExactMatchFilter
WildcardMatchFilter

I assume these are aimed at the ID? At some point we will also need to filter by namespace (once we introduce namespaces post 1.0), but that can be done with these filters too. Nothing to worry for now.

RangeFilter

Sounds like you want to filter on other things than the ID. Definitely more elaborate than I originally had planned. Interesting. Might come in handy too.

We have a couple of enum type properties in the records. I guess these could be covered by the string type filters. Not sure about the best way to handle them.


You seem to be missing is a filter for the ID type (weapon, armor, light, static, ...). Unless you want to handle them via the string type filters too.

Also, I am not sure what DefaultFilter would be good for. We will provide a couple of hardcoded predefined filters anyway (an all filter, one filter per ID type, one filter per group of ID types). The "all" filter could be emulated by a "*" wildcard filter. I don't see a situation where a user would want to use a DefaultFilter.

[Eli2]

I assume these are aimed at the ID? At some point we will also need to filter by namespace (once we introduce namespaces post 1.0), but that can be done with these filters too. Nothing to worry for now.

I thought about using them for all fields not only the ID field.

The "all" filter could be emulated by a "*" wildcard filter. I don't see a situation where a user would want to use a DefaultFilter.

Good point, i will do that.

EDIT: missed half of the reply

[Greendogo]

I know it's extremely early to be talking about the Terrain Editing component, but I was reading the thread on Artifex Terra over at the Ogre3D forums and it might be interesting.

I know the guy who created and maintains it announced in his plans for the future of Artifex Terra in March, that he was going to start rewriting parts of it for Qt. I don't know how far along in that process he is.

Here's a link to the thread.
And one to the project's website.
Here's some screenshots of the current GUI system.

I don't have any idea if something like would be useful, time-saving or inspirational.

[psi29a]

I know the guy who created and maintains it announced in his plans for the future of Artifex Terra in March, that he was going to start rewriting parts of it for Qt. I don't know how far along in that process he is.

I have my own pyQT based world generator (heightmap,wind,rain,river,erosion,biomes)... I would love to use something like Artifex Terra to add a personal touch to the heightmap. Does it support loading heightmaps from HDF5?

HDF5: http://en.wikipedia.org/wiki/Hierarchical_Data_Format <-- set of file formats and libraries designed to store and organize large amounts of numerical data.