Core Irrlicht GUI Element Design Questions

[saigumi]

I've noticed two discrepencies and I'm trying to figure out how to fix it.

When you call IGUIElement->move() only the parent node moves. Similarly, if you call IGUIElement->setVisible(), only the parent node is set invisible.

I tried to compare this to the ISceneNode. When move() or setVisible(), should it iterate through it's children and call the same functions there?

I'm thinking that this should also apply to setting the absolute transformation and maybe a few other functions. Or would this be done in an entirely different fashion?

[niko]

When you call IGUIElement->move() only the parent node moves. Similarly, if you call IGUIElement->setVisible(), only the parent node is set invisible.

Hm.. but isn't it the same in both? When a parent is set invisible, it should not call draw() of a child, so all children are invisible too. (SceneNode do not call OnPreRender to their childs, so they cannot register theirselfes for rendering).

When a Gui element is moved, all children move too, because their positions are always relative to its parent. The abolute positions is recalculated every time. The same with Scenenodes.

[saigumi]

That's what I am expecting to happen, but it's not.

The child nodes call draw() when the parent is not visible.

And the child node's position is relative to the screen, not the parent, so thet move does nothing. I was attempting to figure out if or how to fix the IGUIElement class to fix these.

[niko]

That's what I am expecting to happen, but it's not.

The child nodes call draw() when the parent is not visible.

And the child node's position is relative to the screen, not the parent, so thet move does nothing.

Hm, ok.. I'll check what I did this time..

[Gorgon Zola]

Hi,here's just a small thing i noticed.

when i remove a gui element from its parent like this:
myelem->remove();
the 'myelem' still holds a reference to its former parent.

this isn't a problem if 'myelem' is going to be delete. but if the app grabs 'myelem' for later usage, then i'd expect the parent ref in the element to disapear, to have a consistent model of the gui-tree.

cheers

[Gorgon Zola]

A little suggestion.

how about a method like the following in the IGUIElement?

Code: Select all

// use this with caution!!!
void setParent(IGUIElement* p){
  this->grab(); // don't want this to be deleted too early
  if(Parent && Parent!=p){
    remove();
  }
  Parent=p;
  if(Parent!=NULL){
    Parent->addChild(this);
  }
  this->drop();  // delete if required
}

The remove, removeChild and addChild methods could be made protected to avoid people to demage the gui-structure.
moving an element to a new parent would be a matter of one line.

Code: Select all

 myelem->setParent(newParent);

and deleting an element would be just as easy

Code: Select all

 myelem->setParent(NULL);

[niko]

Hm, very nice idea. Looks like it could work. I'll consider modifying it a little bit, but I think I'll have to change a lot.

[Gorgon Zola]

... but I think I'll have to change a lot.

, boy you are fast, seems you're a time traveler too
Feb-03-2004 GUI Enhancements & 3D Game Editor
http://irrlicht.sourceforge.net/images/shots/065.jpg
I still have Feb 2nd at my place, is vienna in another time zone?
cool gui things, by the way.

cheers
tom

[keless]

o.0

tabs, drop-downs, and input boxes *drool*

[Maureen Mccormick]

I not understand this, keless. Could please translate some to japanese?

[keless]

"tab" ya "drop-down" ya "input box" wa sugoi "GUI" eremento da ne!

boku no nihon-go wa warui desu kara-- sumimasen.

[saigumi]

*happy*

[niko]

I still have Feb 2nd at my place, is vienna in another time zone?

Hehe, no, but it was 2nd Feb, and almost 24:00, (I think 22:00 or something) so I thought it didn't matter. Reminds me on the game magazines. Don't know if this is a phenomenon only in germany, but they always print a date onto their magazines which is 2 months in the future.

Yes, with the new widgets it is possbile to create complex user interfaces. Don't know what is missing. Radio buttons perhaps. And combo boxes. Anyone is missing something more?

[keless]

progress bar, lol

[saigumi]

Well, looking it over from the standard VB control sets as well as the ones from other projects I've seen, as well as the requests of others:


Grid (the #1 most used control in Windows and for some reason every control vendor sells their own version)
Progress Bar
Slider
Tree View (Like the Listbox with lines and dashes to show hierarchy)
Combo Box

A few can be simulated using multiple widges. But could be their own widget, such as:
Console (EditBox + ListBox)
Group Box (Image + Text)
Status Field (A Grid set to the max bottom)
Spin Button (2 buttons, "Spin" looks like a scrollbar, without the bar, just the up and down arrows)
Radio button (2 checkboxes)
Icon (Image with Text, the current code almost allows this, but the Text value isn't displayed)
ToolBar (Uh.. form + Buttons)
TextBox (Multiline Edit Box)
Seperator (Like an html <hr>, just a line or image)