The skin engine - limitations

[mrbrdo]

Hello

I think Irrlicht is great by design, only the skin engine is somewhat flawed. It doesn't allow enough manipulation without actually editing the engine code itself.
If it is only supposed to be used for simpler windows\buttons, i would strongly suggest that more "color variables" such as EGDC_WINDOW, which is used to color buttons too, for example, are added. I suggest to add more flexibility by at least letting the user define different colors for every element, buttons, editboxes, etc.. You only need to do that once anyway, and then it is the same troughout the program. I think using the same color to color all the elements is just a little big limitation for these elements to actually be useful for a "larger" project. I already changed the source for me, but i think it would be nice to generalize this in the project in the next release and define more of these variables, as to allow the user to "color his elements" more freely. Some color overrrides locally to the elements would also be nice, if you needed to color only 1 button differently than others - but i am not sure if this isn't possible already, i remember something about the possibilty of overriding the skin? Well, anyway, if it is already possible, forget that i mentioned it. But i still think colors in general should not be so "generalized". I hope my suggestion will be taken into consideration. If there is a time issue with the team, i would be happy to offer assistance and contribute after i'm done with exams.

Also, the patch for editbox's password functionality that is in the tracker, would be a nice addition to the library, as well as those 2 other things (proportional sizes\positions!) in the patch. Even nicer would be if tabbing between tabbable elements would be handled internally, and defining default buttons which would be pressed at ENTER. Of couse, it should be overridable too

[mrbrdo]

Doesn't anyone sympathise with me? :S

[hybrid]

You should kindly ask bitplane. He's working on the GUI stuff and maybe he needs just some more requests or pointers to those patches once more

[bitplane]

I hear you!

I've got lots of ideas planned for the GUI and skins, here's what I have in mind-

1, we're missing several important elements: save dialog, font select dialog, treeviews, option buttons, progress bars, frames, resizable windows, etc.

2, as mentioned, there's important settings missing from the GUI elements. Internal tab support ('tab order', 'is tabbable') and default buttons are planned. Other things include an option to override the font and its colour (and perhaps size?), the background and foreground colours, whether the background is transparent or not, and whether an element is clipped to its parent's rectangle.
I'm testing relative positioning at the moment, I've added min and max sizes for elements, and the option to align each side to either the top left, bottom right, centre ('center' as Irrlicht uses American English ), or scaled. So just about every kind of automatic scaling can be achieved by nesting stuff inside (for the moment) empty tabs.

3, Skins need more control over how things draw, and their variables need to be serialized (see the new gui editor in svn) along with the gui environment. I haven't given this much thought at the moment, but it's on my list!

4, Using the default font for icons is bad. We need some kind of 'sprite banks' for holding (potentially) animated images. Bitmap fonts could then just be a special case, so fonts, backgrounds, buttons, mouse cursors etc can all be animated!
This means yet another editor, I've still got a menu editor to worry about before beginning this! Thinking of editors though, I'm looking forward to making them completely pluggable in the gui editor, so if you create and add a factory with a "foo" element, the editor will try to create a "foo_editor" element to deal with the specifics.

I think that's about everything. If you have any more ideas to add, please go ahead, I'm always open to suggestions

[rogerborg]

I think the GUI patch in the tracker looks like superb quality work, doubtless written by a rugged and virile developer, and should be committed ASAP, if not sooner.

[bitplane]

Don't worry, I haven't forgot about your patch

An IGUIEnvironment method to create absolute screen co-ordinates (at
the current resolution) from screen relative co-ordinates (in the range
0.0f - 1.0f). This allows GUIs to be created using proportional
co-ordinates that should work (by and large) regardless of the screen
resolution.

I'll add this, but I'll probably make it relative to a specified parent to compliment the new setRelativePosition call (see below)

Added an EGET_EDITBOX_TAB event type, which allows (for example)
tabbing between edit boxes.

I'm planning on doing something more generic with tabs, the gui environment should be responsible for tab/shift+tab(/ctrl+tab/ctrl+shift+tab?) behaviour rather than the individual elements... so I'm afraid I'll have to give this a miss for now.
also it's missing a break statement, so tab has the same behaviour as pushing the left arrow key

Added to IGUIEditBox the option to obscure text (with ***asterisks***),
which is useful for entering passwords. I just added it to IGUIEditBox
rather than deriving a new interface/class from it, because it would have
required overriding large portions of IGUIEditBox, rather than adding a
small amount of implementation to IGUIEditBox.

Consider it added

since this is evolving into the current gui discussion thread, as of revision 429-

Elements can now automatically resize to fit their parents, or align themselves to an edge:
setAlignment(left, right, top, bottom) - sets how each edge aligns to its parent,
through EGUI_ALIGNMENT enum
EGUIA_UPPERLEFT - default behaviour, aligns to top or left edge
EGUIA_LOWERRIGHT - aligns to the lower or right edge
EGUIA_CENTER - moves relative to the center of its parent
EGUIA_SCALE - uses relative scale

setMaxSize, setMinSize - sets the maximum and minimum sizes for automatic resizing,
use 0 for no maximum size.

setRelativePosition now takes a rect<f32> for relative positioning within their parents

[BlindSide]

This is not overly important, but the new edition of KDE is gonna use circles instead of asteriks for passwords. Lets start of with those so we are ahead of the league