Why the button moves ?

Hello,
I created a very basic setup, just an empty sheet with a button on it. No panel no window, nothing. I just want a button for my UI. When I move the cursor on it, the cursor changes to a hand and if I click / drag, the button moves. It makes no sense. I just want a normal button in my viewport so I can click on it.

I tried to create a window first, then the button. It works well, but I have that huge window with the border in the way that I can also move. I need nothing of this, just a single button. How can I achieve this ?

Thanks,
- Chindril

You should be able to add the button to the sheet, right? The sheet is a window technically, but its transparent by default. The other option is to create a window, give is a skin that is transparent, and add the button to that. You can also prevent the titlebar from appearing by modifying the desc parameters when creating the window.

If you're just starting out with QuickGUI and have simple needs, I recommend trying out QuickGUI 10.8. There are not Sheets in 10.8, you have an Interface class, and from that you create a Window, and then add a Button to the window. In 10.8 Widgets do not need skins, if you pass in NULL as a skin it will simply be transparent.

I will try to throw up another tutorial for 10.8 so users can get more familiar with creating widgets.

Isn't it as simple a fix as setting <widget>.Draggable = false ?

I remember having a similar problem and that certainly helped.

Ok my problem was as Stardragon said, just set draggable to false and it worked.
As for QuickGUI 10.8, is it the stable version now ? I didn't try it, I just downloaded the latest stable version from the wiki.

Thanks,
- Chindril

In terms of stability I think its good. However I'm finding all the notifications are setup yet. I guess I would recommend most people wait until I put out a tutorial so you can get notified when events occur, unless you want to be a pioneer.

Actually Calder is making some changes to Skinning, so maybe wait for 10.9 if you can afford to. However if you want to use 3d GUI I'd suggest starting to migrate over. (3D GUI is useful for many things, for example Progress Bars above units, and Text inside your 3d scene)

And eye candy!

EDIT: Sauerbraten menu anyone?

In terms of stability I think its good. However I'm finding all the notifications are setup yet. I guess I would recommend most people wait until I put out a tutorial so you can get notified when events occur, unless you want to be a pioneer.

Actually Calder is making some changes to Skinning, so maybe wait for 10.9 if you can afford to. However if you want to use 3d GUI I'd suggest starting to migrate over. (3D GUI is useful for many things, for example Progress Bars above units, and Text inside your 3d scene)
I saw in another thread the new event subscription method and it looks a lot like boost::signal (which I use in my project). Easy to use and powerful, I love it.
The 3D GUI might just be the reason I needed to go to 10.9, although I have more urgent things to work on in my project right now than fancy GUI hehe.

- Chindril

The subscription method is most similar to Ogre's, for example adding and removing Listeners (FrameListeners and the like). The Messaging System in general is really advanced compared t previous QuickGUI, I really like it. I just put up another wiki tutorial those who want to understand more of how QuickGUI 10.8 and later work. No worries if you have other things to look into, we all have things we need to work on.

Speaking of 3D GUI, I'm trying to figure out if it is possible (with version 10.1) to animate the widgets. For example, move a Label or Image or scale it up/down, rotation, etc. I guess using setSize / setPosition would work but it isn't very convenient.

There is no built in classes or functionality that implement a behavior over time, though it can be easily implemented external to QuickGUI. I know people would like this functionality built into QuickGUI library, but I don't have a lot of time these days. This can easily be accomplished external to QuickGUI IMO, just create a bas class "WidgetController" that has an update method, and create a "WidgetControllerManager" that iterates through the list and calls the update method periodically.

Not to mention this WidgetController class could actually derive from a more abstract Controll class, that can control things not related to the UI. Kind of seems out of scope for QuickGUI to house this functionality.

Don't worry about it now, but I would be happy to tackle this when I have a life again in November if time is your big concern. I actually think this could fit perfectly within the scope of QuickGUI, but it's not absolutely or immediately essential. It might even be nice to see what Controller classes of their own people came up with first.

Here was my little sketch if anyone else is interested:

class WidgetController
{
void hide () = 0;
void resize (const Size& newSize) = 0;
void show () = 0;
void updateWidget (float timePosition) = 0;
};

Where each Widget would have a unique WidgetController object of some type. For example, the current behavior might be implemented something like this:

class DefaultWidgetController
{
void hide ()
{
mWidget->_setVisible(false);
}
void resize (const Size& newSize)
{
mWidget->_setSize(newSize);
}
void show ()
{
mWidget->_setVisible(true);
}
void updateWidget (float timePosition)
{
}
};


Could always try and make it a generic template class that can be inherited from...

So you'd end up with...

class ButtonController : public WidgetController<ButtonController, Button>
{...};

class ScrollBarController : public WidgetController<ScrollBarController, ScrollBar>
{...};

... and so on. The base template provides some generic virtual functions and anything else that's likely to be used by anything that the user would want to control a Widget for, and then the user can just extend the class as they see fit.

... oh dear. Heh. Now I bet you're going to go off and do that, aren't you?...

Wait a second, I don't think classes can inherit themselves... My brain asplode!

Wait a second, I don't think classes can inherit themselves... My brain asplode!
*grin* Oh?... Oh. Well, I might be about to get a new title

Check out this page: http://www.hackcraft.net/cpp/templateInheritance/. Especially the sections towards the bottom, on templates parameterised by a base or derived class. Of course, my example above just uses two parameters instead of one, so the definition would be something like:

template <typename T, typename ControlledObjectType>
class WidgetController
{
public:
WidgetController();
WidgetController(const WidgetController<T, ControlledObjectType>& src);
virtual ~WidgetController();
WidgetController<T, Container>& operator=(const WidgetController<T, ControlledObjectType>& rhs);

protected:
ControlledObjectType* MyWidget;
};

... it's far too late to get too far into this, and I'm certainly not going to get into template template parameters. (No, that's not a typo.)

Enjoy your reading

Sorry, yeah, I see what you're saying now. I was really tired when I read that last time. Though it does seem... a little needlessly complicated maybe?

Sorry, yeah, I see what you're saying now. I was really tired when I read that last time. Though it does seem... a little needlessly complicated maybe?
... this from the fella who implemented "AppCore"...

I was thinking about this, though, which you put in one of your earlier posts:
Where each Widget would have a unique WidgetController object of some type. For example, the current behavior might be implemented something like this:
The difference is that, since all widgets have similar function calls, some of the more common functionality can be templated in (or out, depending on your point of view)... so rather than having a separate WidgetController class for each class of widget, it's possible to create the specific class you need, since no matter what type of object you pass in (Button, Pane, Cursor, etc.) it's almost guaranteed to have one of those basic functions.

Really, you pays your money and you takes your choice I'm not sure in this instance if there'd be that much difference between a template class or a DefaultWidgetController class you could inherit from. But it would be interesting to do.

Oh, sorry, I didn't mean each different type of Widget would have it's own WidgetController class, just that any Widget instances that wanted animation would have a WidgetController instance. Since animation would basically encompass 1) fades, 2) resizes, and 3) movement, particular WidgetController would work for any type of Widget. Sorry, if that doesn't make too much sense, I don't have all that much time to explain it right now, but hopefully (KFM willing) I can take a stab at this around Thanksgiving break and we'll see what comes out.