ChillCore wrote:However what your are suggestion seems more advanced and better.
My thoughts evolve each time I try to explain them.
Also, I had a few bright insights while pondering groups, and I spend a few days on building a(n empty) gui, and some background data.
ChillCore wrote:I would not mind helping you with this, oh mighty one, but I think I would only be holding you back.
Knock yourself out:
http://devs.openttd.org/~alberth/diffs/groups
I have two attempts (both are just experiments, code contains lots of missing cases, weird comment lines to mark where I am hacking, etc). The first one has nicely draggable group properties (group splitters I called them). I mentioned a revision number, but I don't think it is critical. Build it, and activate it with the 'train vehicle list' button. It was mostly seeing how drag/drop would work here.
That interface is broken in two ways.
1. All properties are always used for the (at the right, non-existing) tree
2. All properties are instantiated at start up.
(whether 2 is a real problem remains to be seen, 1 seems like a real problem.)
So I started the second attempt. (again, revision number is non-critical.) This is just starting (but I ran out of day so it never got as far as the first attempt.)
At the bottom left, you have (non-working) buttons to create new group properties. You could eg popup query windows or so for getting extra information.
The top-left should be like attempt 1, except that there should be two groups of properties, with some empty space between them.
The top-part is for grouping of the vehicle tree, the bottom part are properties that are still actively maintained and/or stored (eg when replacing a train, it might switch groups for some properties), but are not used to split vehicles in the tree.
The second attempt is mostly non-functional.
While it looks nice as screen shot (except the window colour is too grey), it is really all empty. Not just the gui, but there is also mostly nothing behind the screens. For some properties, you can simply look at the vehicle to decide in which group it belongs (eg vehicle type). For other properties, some computing is needed, and that value should be cached in the vehicle, I think (I added 'Vehicle::group_values' somewhere, although that variable does not exist currently.)
As for the tree, I have no ideas about that part yet. I would already be very happy to just have a display, ie without being able to do anything with the groups. That is already a lot of work.
As for keeping me back, there seems to be plenty of work here (I am currently doing other stuff also needed for this, namely adding a new data structure for storing 'per train' data per train, rather than in the primary vehicle.)
As a result, my group code as explained above is not moving at all, at this time (both gui and non-gui). Any movement you can create is good
I will test however and I'd be happy to include it in my bugpack
(while updating as needed) before adding it to trunk if you see the need for testing before committing.
I thought trunk was for that
Albert