[Done] Suggestion: improve child order control

[niello]

Hi.

I am now implementing a reordering/reparenting functionality for CEED C++ and I have a couple of suggestions:

1. In a current CEGUI, if you add a child anywhere except layout containers, the child is added to the end of the list. It makes sense, but I suggest to add CEGUI::Window::moveChildToIndex() and/or CEGUI::Window::addChildToIndex() methods. This will allow CEED users to explicitly reorder windows inside a parent for whatever reasons they have. It can be a convenience (group elements by function or sort alfabetically) or even an optimization, if order of children matters in some operations (like searching).

2. Let's replace Idx with Index in method names. We definitely can afford 2 more letters and it improves readability.

3. GridLayoutContainer has an auto-positioning feature that turned to be more pain than convenience. For example, removing a child from a full GLC and then adding it back (undo) causes a crash because GLC thinks it has no room for this child. Actually there are more problems. I suggest to drop auto-positioning in favour of a simple insertion scenario:

Code: Select all

addChildToCell(x, y)

inserts the child to a specified cell, possibly replacing previous contents (or failing, or shifting contents when possible).

Code: Select all

addChildToIndex(i)

inserts the child to a given linear index, strictly row-major from how a GLC logic is implemented. It also replaces / shifts / fails.

Code: Select all

addChild()

searches the grid for the first free cell either row-major or column-major, depending on the AutoPositioning(Majority) property, and then calls addChildToIndex.
Also a helper public method is offered:

Code: Select all

getFirstFreeCell(startCell, bool rowMajor)

This interface is expected to be more stable and predictable.

4. We also may add auto-grow feature to GLC. When it is full it can allocate a new row or column based on AutoPositioning(Majority) property. Auto-grow may be controlled with a bool property.

[Ident]

Regarding 1 and 2:
I also see no issues and think this is not only useful but quite necessary.

It has always been possible to change the order (bring to front on click functionality), just not in a simple and direct way from code. So, theoretically, there should be nothing to stop us from adding more convenient functions to change the order, right? Of course, firng events for this need to be considered if there are any and we must test this.

Regarding 3:
I don't have much experience with that container, but if you use it heavily and have improvements, please go ahead.

As always, such heavy changes should go into default branch.

Regarding 4:
I think default branch has an auto growing text box or something like this if i am not wrong. If you need some sort of reference.

[niello]

Ok, then I feel free to improve these things as soon as I have time.
I will open a PR to the default branch and request your review, as always)

Btw, didn't you think of assembling a checklist for the 1.0 release? I bet a new release would bring life to this place. Writing CEED I have a sense that the default branch is quite production-ready, yet some polishing must be done.

[Ident]

I wrote most of mine and mpreisler's todo lists, which could be composed into a roadmap:
http://cegui.org.uk/wiki/Ident_TODO
http://cegui.org.uk/wiki/Mpreisler_TODO

There might be some more points I can think of that would be very relevant.

Most of all, before a 1.0 release, we must think of how we change the API, because all 1.X releases are ABI compatible. Everything else is fixable later.

Otherwise we would have to go for 2.0 release to change the API, and that would not be so nice.

[Ident]

Also to keep up with today's time we should really think of packaging things more easily for Windows. The whole process with the dependencies is a mess and the CEGUI dll naming on Windows make no sense (easy to fix though, basically a major version should be sufficient as postfix always).

The docu is unsufficient for beginners.

We need better support for scaling, e.g. supporting multiple imagesets in different scales. We already have a way of packing image files into one imageset in CEED - it is a bit hidden and we should really make this accessible, unless I missed out on it being already made more accessible by mpreisler/Kulik. This would help a lot to get a workflow in to support different scales more easily. 4k is here, we have to be ready for this if we want to have a modern UI library.

The LNF editor is a must-have for proper artist support (I started it but most of my time was lost on the fact that i had to set CEGUI up for this AND wait for pycegui compile - i wish we had done the c++ before i worked on LNF editor!)

[niello]

Regarding the packaging I would suggest:
1. Merge CoreWindowRendererSet to Base (as in TODO posted above)
2. Merge CommonDialogs to Base too, it is tiny, and users who never use it will not suffer from distribution size increase
3. Drop PCRE completely and use only std regex matcher. Partial matching detection is not used in CEGUI code indeed. It will remove the whole dependency library (the only mandatory one AFAIK, except of header-only GLM).
4. Publish prebuilt packages similar to one I distribute with a CEED C++. Looks like an SDK: include, lib, dll. Prebuilt samples may be distributed separately.
5. Publish a static library package with statically linked dependencies. (???) I use static linking but don't know how many other people do.
6. Try to reduce the number of visible CMake options. From my experience it is the most frustrating part of getting CEGUI built from source, otherwise it is not hard.
7. Support a modern CMake approach to simplify linking of CEGUI to other projects, both as an interface target and in source if possible
8. Maybe add some shell scripts to build popular configurations (very optional but might be useful)

Major version is already added to DLL names.

[niello]

Functionality discussed in the first message is done in https://bitbucket.org/cegui/cegui/pull-requests/329