Revamping the Tree control

[Mikademus]

[speaking about bugfixing the Tree] As an aside, I notice what I consider to be various rendering glitches, though I don't have the motivation to fix them. Working on this component makes my blood boil

This made me think. Do you think it is better to throw the existing shite out altogether and replace with something spanking new, or can we refactor it piecemeal and reuse some aspects of it? As I see, from the perspectives of usability and CEGUI conformity there are two major issues: (1) the interface, which isn't very CEGUI standard and also miss some crucial methods, and (2) that TreeItems aren derived from Window, which makes certain things impossible (basically, TreeItem should be derived from Window and RenderedString, I suppose).

If we would start with refactoring TreeItem into a Window, then some issues like f.i. obtaining its parent would be easily fixed. Then probably the interface of Tree could be refurbished into something resembling sanity.

So, basically, this thread might be considered to ask two questions:
* If we refactor the existing Tree, what should be refactored?
* If we decide to make a completely new Tree, what should go into it?

[CrazyEddie]

Refactoring the existing tree is a waste of time and effort (IMO). Regardless of what Adam and Jamie may have shown to the contrary, you can't polish a turd An all new Tree is what is required.

Basically the new tree should follow the model of the ItemListbox (and menu system). Preferably it should be based on one of the existing classes in that hierarchy (ItemListBase / ScrolledItemListBox or what have you) and should use the ItemEntry - or most likely subclass ItemEntry - in order to provide the content. I've not done any analysis on this at all, though believe that this is the 'correct' approach - anything deviating from this approach would make me instantly suspicious

CE.

[Mikademus]

What I was angling at with refactoring was that we might change things a few steps at a time, and suddenly the old tree would have been completely replaced. This is usually how I approach system restructure at work (as well as at home) when the underlying system should remain in productive use while working on it.

However, I am absolutely not versed enough in the CEGUI innards to speculate about the feasibility of such an approach - I am discussing from that blissful position of naivety and hope that is as likely to enthuse as to exasperate one's audience. Unfortunately, that also means that I am not adept enough to try my hands at writing a control myself. I'd be happy to help in any way I can, and one way I can think of atm is support and being someone to test ideas with.

I do appreciate your thoughts on how a Tree control might be constructed from the building blocks currently in the framework, and if you get the time and urge to try out a prototype I'd be very happy to be involved and test or whatever might be needed.

[CrazyEddie]

I understand what you were getting at as far as refactoring goes - I too am a great believer in such things. However, there are occasions when it pays to just dump what you have and start afresh - this is one of those times The main issue with the existing tree is that it was not designed and written from the ground up; the author(s) took the existing CEGUIListbox files and basically bastardised the code until it resembled something like a tree; nasty stuff indeed

I'm not sure if/when I'll get around to getting work started on this - not any time soon. Obviously the existing implementation is a thorn in my side, though I must take the opportunity to advise anyone (not aiming this at Mikademus) thinking of having a go at writing this to be sure that what you write is of a very high standard, because I will not be replacing one pile of crap with a slightly smaller pile of crap

CE