Post Useage Report. Some feature requests, bugs, annoyances
Hi, I have been using QuickGUI in my application and here is a small report of what I found annoying, some needed features, and bugs.
1. Can we please have some sort of docking support? Unless this is already present, will it be possible to just say I want this button attached to the right top and no matter how much resizing it will say there.
2. The DirectX bug eating text that I have previously mentioned.
3. Can we please have some form of vertical and horizontal sizers? Unless they are already present, it would be very nice that we have some form of way to keep buttons placed no matter how much they are resized etc... Some like the boxsizer in wxWidgets would be very nice.
4. The skinset and layout editors need to be fixed! I will attempt to fix them and if I succeed I will post a patch.
5. How do we tell QuickGUI to not use a skinset and use the image files right away instead? Is it possible to just say use all the files with game.button.* wtv?
1,3: For resizing/position issues, look into Anchoring, its all implemented. Widget::setVerticalAnchor and setHorizontalAnchor. (names might be slightly different)
Using these methods you can keep the widgets at certain locations, or even have them resize according to changes in their parent's position/size.
2: This is either incorrect use of Ogre classes, or an Ogre issue itself. I only use the tools Ogre provides me to do rendering, so I'm lacking on information needed to fix this issue. Hopefully this can get resolved soon.
4: Unfortunately these are not complete, they are stubbed out and require future development. The SkinSet editor will be released with v0.9.8, which is a ways away. The Layout Editor requires serialization of Widget properties and the ability to create widgets from parsing script. This is not currently implemented, so even if you got it to compile, it would do nothing. The library isn't that far along yet.
5: You must use a SkinSet to skin widgets, the only exceptions are the Sheet and Image widget, where you can specify an Ogre material for use. For multiple buttons make use of the "setSkinComponent" function, to set the base string used to render the widget.
ex. I have a skin "qgui", with 2 buttons: ".button", ".button2".
Button1 = mySheet->createButton();
Button2 = mySheet->createButton();
Button1 uses "qgui.button.*" and Button2 uses "qgui.button2.*".
What is the state of the layout editor? If you dont have a property system then you could make a system to detect the class type from a instance e.g you could ask widget if it is a instance from textbox.
After that serialzation is no problem for the layout coder if you have that sort of system in your gui i write you a xml backend for the layout parsing/creating. Ok its not as nice if you have a property system but its the right direction to it well.
Speaking of the anchor system, could you post a short example of how to use it when you get the chance, Kungfoomasta? For example, say I want to have a button that is always -150,-50 from the lower right corner of the screen. I tried using the setVerticalAnchor() and setHorizontalAnchor() but I wasn't getting the results I expected, so I don't think I'm using them properly.
Thanks for the help!
The widgets are still being modified a bit, so until it quiets down its probably not a good idea to work on serialization. In time...
Try something like this:
Button* myButton = mySheet->createButton();
myButton->setPosition(mySheet->getWidth() - 150,mySheet->getHeight() - 50);
This is off the top of my head, but it should work. As long as you notify the GUI manager when the window size has changed, the button's position should stay the same distance from the bottom/left edges.
Hmm... so what's the effect of having those last two lines then? Wouldn't it work the same without them?
I guess I thought that an anchor system would work something like this:
Button* myButton = mySheet->createButton();
That way, it would now automatically take care of the relative position to that anchor point. I guess I'm not following how the current anchor system is designed, so please fill me in when you get a chance
It imitates the windows UI properties.
Horizontal: Maintain position relative to the left or right side of parent widget. (or don't maintain..)
Vertical: Maintain position relative to the top or bottom side of parent widget. (or don't maintain..)
Wouldn't it work the same without them?
Nope. By default Widget anchors to the TOP and LEFT.
Ok, so it's only with regard to updating the parent window size, not creating the widget in the beginning. Cool, that makes sense.
Hey another quick question. What happens with ANCHOR_VERTICAL_TOP_BOTTOM? Does it scale the size of the widget with the size of the parent widget?
Yep, that's exactly what it does.
When you set an anchor, it's relevant sides are used to record the distance from the side(s) it is anchored to. When the parent's size changes, child widgets are checked to see if they are where they are supposed to be, and adjust dimensions appropriately.
I found a small bug in the List widget. If you are deleting objects or clearing the list, items added afterwards are not placed correctly(they look like they are added to the end of the list).
Looks like mAutoNameWidgetCounter needs to be set to 0 in clear() and decremented in removeItem() since mAutoNameWidgetCounter is used for text positions. I could provide a patch if you want.
Thanks for the head up. I removed the mAutoNameWidgetCounter variable and fixed issues with adding items after clearing/removing items. Let me know if you run into problems.