interface for item based element

Nox · Post by **Nox** » Fri Aug 21, 2009 4:02 pm

Some GUIElements share a very similar interface for managing items. An abstract interface would make the code more clean and removes things like IGUIComboBox::getSelected <-> IGUIContextMenu::getSelectedItem.
Moreother an additem methode which takes a pointer or variant instead of a commandid would be nice.

What do you think about these ideas?

FuzzYspo0N · Post by **FuzzYspo0N** » Fri Aug 21, 2009 4:50 pm

Sounds more logical to have an abstract base for all gui items, and lower that heirachy. I dont think irrlicht wants multiple inheritance so this might be problematic, though i could be wrong.

While i am rewriting the gui editor i am making a ton of notes about the usage in general . Im gonna add something along these lines to the notes as well, thanks.

CuteAlien · Post by **CuteAlien** » Fri Aug 21, 2009 6:32 pm

I prefer avoiding multiple inheritance unless absolutely necessary as it's nearly never worth the pain it's causing. But having different names for similar functions is certainly bad, so names are something which will probably be cleaned up some day.

Also not sure about the pointer right now. Basically I agree that it should be possible to set complete items. But it needs more changes as right now the item-interfaces are not public, so we would have to check first if making those public will be fine or causing any troubles.

Don't know what you mean with variant - as far as I can google this seems to be some COM thingy acting somewhat similar to templates just with a reserved amount of types so it can use a fixed size. I don't really see how that would be useful here as we need strings in items. Do you think as a way to store custom data?

If it's about custom data - lets just say that's another construction site in the engine. Right now: ComboBox has ItemData using u32. Table has CellData using void*. ContextMenu and ListBox don't have any item data, but imho they need them. I remember some resistance in the past to custom user data which might be responsible for this mess as probably people introduced it on need nevertheless, but only in some places. I am 100% in favour of using custom data in the mentioned gui-elements because it's simply needed or users have to re-code the same internal structure of such elements (a grid for table, a list for listbox etc) and keep them synchronized manually. And I don't care if using void* or u32 (but prefer the latter) but I think it should be the same all over the place. (but please no-one confuses this with custom-data in other places like scenenodes - that discussion wouldn't belong in this thread but in an own thread).

edit: Oh wait - just see on reading your post again - you wanted pointers instead of _commandid_ - so sorry, I was on completely wrong track. But uhm... actually I don't see the problem with commandid ... why do you want to replace that?

Nox · Post by **Nox** » Sat Aug 22, 2009 10:00 am

Okay that was my fault. I dont meant to replace it because this would break the api. I mean an additional parameter.
A variant is something like in scriptinglanguages; a variable with a flexible type.
The "inheritance" argument is a point. But the new interface would only be a help for the developers to keep a standardizied API. Maybe the inheritance can be hidden in doxygen?

And I don't care if using void* or u32 (but prefer the latter)

I would prefer void* because pointer have a size of 64 bit if the app is compiled as 64bit.

bitplane · Post by **bitplane** » Sat Aug 22, 2009 10:12 am

As per my comments on the feature request, I also don't like the idea of multiple inheritance or adding templates to the public API. I'm not sure about using something like this to clean up the internals though.

Just thinking out loud here: The variant type idea might work with IAttributes, if we could figure out a clean way to do it. Constructing hundreds of attributes may be pretty slow though.

CuteAlien · Post by **CuteAlien** » Sat Aug 22, 2009 11:13 am

Nox wrote:
And I don't care if using void* or u32 (but prefer the latter)
I would prefer void* because pointer have a size of 64 bit if the app is compiled as 64bit.

Hm, yeah, stupid me - void* is certainly preferable because it's often used for pointers. So /me prefering now the void* :-)

edit: I still don't understand for what you want or need the invariant here. Could you explain that some more? For indentification, or for custom data, or another reason?

bitplane · Post by **bitplane** » Sat Aug 22, 2009 12:05 pm

So that all the different elements share a base class behind the scenes, removing some code duplication.

Nox · Post by **Nox** » Sat Aug 22, 2009 12:12 pm

dumb example for a very simple variant: http://sourceforge.net/tracker/download ... id=2689060
exampe for a really advanced variant: http://www.boost.org/doc/libs/1_39_0/do ... riant.html
A variant should provide flexibility and the typesafety.
By the way. There are already templates in the API. Just take a look at the core types

.

CuteAlien · Post by **CuteAlien** » Sat Aug 22, 2009 4:21 pm

Uhm, yes, I already read up on what an variant is. What I don't understand is for what you want to use it here in this context. Do you want to replace the custom data with it or the identifier (commandid) or something else? I mean it could be used instead of a void* for example, but I'm not sure if that is what you want or if you think of something else here.

Nox · Post by **Nox** » Sat Aug 22, 2009 4:49 pm

A variant would be more typesafe (for implemented types) in contrast to void*.

CuteAlien · Post by **CuteAlien** » Sat Aug 22, 2009 5:27 pm

OK, so you want it for custom data. Sorry, I was just irritated because you had mentioned the commandid in your first post which has a rather different purpose.

Don't know if it's a good idea. Type-safety sounds certainly always promising. But first this doesn't seem to provide real custom types, but even boost::variant seems to work only with the given set of template parameters. So in that case something like boost::any would seems more suited on first view. But I have used neither so far, so I'm missing experience with those. Then it looks like usage would be more complicated which wouldn't be so nice for Irrlicht, but once more - maybe I'm wrong.

As mentioned above - I'm very much for adding custom data and using one solution throughout. And I'm not exactly a big fan of void* so any better solution gets my interest. But I guess I would need a short example in this case (and not an undocumented 6000 line patch ...) to see if it really beats void*. So one variable, one setter, one getter and an example using both. Would be great if you could do that.

Nox · Post by **Nox** » Sat Aug 22, 2009 7:52 pm

You are right. Variants only works for kown types really typesafe afaik. I guess for the item based elements a void* would be enough. Maybe boost::any would be a solution but i never used it. The variant class used in the patch is very dumb and only for shrinking the old IAttributes. So i can only handle s32, f32, bool, recti, rectf, stringc, stringw, line2di, line3df etc. pp. and a void* for all unkown types. So not very clever or flexible.
I guess a simple pair a void* pointer and an u32 will make it possible to use only a pointer, or a unique id or a user defined u32 to determined the type of the pointer.