I have a design idea, and I was curious if it was feasible (since I am still learning the basics)...
I want to have a sole button in the top left, I click it and then a bar shoots out to the right; spanning the top. The menu will from that point be like a regular top menu, but if you click the button the menu retracts again.
It seems like it should be, but I figured I'd ask the more experienced before I hack it.
You want the menu to be visually growing and shrinking? (like an animation) If so, do you want the menuLists to be visible during this this shrinking/growing, or after fully expanding the menuLists become visible? Also, correct me if I'm wrong, but you want the button to be on the end of the menu bar, right?
Any way you want it we can accomplish it, I'm just figuring out what would be a good approach.
The menu options wouldn't appear until after it was fully expanded. At least that is my initial desire. Possibly with a fade in. So it would all just be animation bringing it up.
also the button that brings it up would be stationary throughout the whole process. It would stay at the top left part of the screen and the menu would appear to be coming out of it to the right
o----------------- <- like so, in rough ascii art.
I would probably create a new Widget that is (derives from) a Menu, and has (creates) a Button.
Starting stub code:
Class <My Widget name> : public Menu
<My Widget name>(...);
Ogre::Real mMinPixelWidth; // not sure if you need this
// handler for when button is clicked
void onButtonUp(const EventArgs& args);
Handler for the button, when mouse button up:
if Menu is visible:
-hide all MenuList children
-set mShrinking = true;
-set mGrowing = false;
if Menu is !visible, or is mMinPixelWidth:
-set mGrowing = true;
-set mShrinking = false;
Override the Widget::timeElapsed function:
if( mShrinking and Pixel Width > min pixel width )
-if new width is <= min pixel width
-mShrinking = false
if( mGrowing and Pixel Width < max pixel width )
-if new width is >= max pixel width
-mGrowing = false
If you come up with a good name for the widget, I could probably create it really easily and add it in. Or if you want to play around and try to implement it, that is cool too.
I have another idea..
1. Create a Menu Widget, in its default shrunk state.
2. Add a MenuList child, but do not add any children to this menuList. (It's basically a button with no list at this point). You can add additional MenuList and populate them as you wish, but the first MenuList should have no MenuListItems.
3. Add an Event Handler to the MenuList, EVENT_MOUSE_BUTTON_UP
4. Add an Event Handler to the Menu, EVENT_SIZE_CHANGED
Create the first event handler, lets say "void onMenuStateChanged(const EventArgs& args);"
if Menu is width X, mMenu->resizeOverTime(...);
if Menu is width Y, hide MenuLists except the first one, mMenu->resizeOverTime(...);
Create the second event handler, lets say "void onMenuSizeChanged(const EventArgs& args);"
if Menu is >= X, show MenuLists
The only thing I would have to implement is the "resizeOverTime" function. Of course, this would encourage me to make a "moveOverTime" function also, and eventually a "fadeOverTime" (I actually planned to make this one)
This route is much much easier to achieve what you want. It couldn't hurt me to make these functions anyway, and allows for extra effects. What do you think?
First, sorry I haven't gotten back to you since friday. It's my first time back at work.
I reviewed both of your proposed implementations. Both seem to build well on the underlying structure of QuickGUI. Either one will work for me, at least i'll have some direction on what to do now. That being said, the second one seems to benefit the project more.
As you said, it seems like it will allow you to implement new effect functions, which will see broader use. To that end it seems like a better idea to implement that method. The other just seems more local and is more tinkering with previous methods; not creating anything new.
Not gonna lie, I do feel bad with you doing extra work from your regular items.
No problem, they need to be added in at some point. Hopefully my current scrolling issue gets resolved tonight, and then I'll add these in.
I added in resizeOverTime, and it correctly sizes, which looks cool, but since positioning is done in relative coordinates, the child widgets are not positioned correctly.
Its there for you to play with at least. We won't be able to implement your widget until I implement Anchoring, but this isn't planned until v0.9.8.
2 Questions for ya:
1.) Can i hack myself a sizing function to adjust the relative spaces?
2.) My list items in my menu lists aren't showing up... They get highlighted, but not visible to read or responding to events i've assigned. Any ideas?
EDIT: correction they are responding to my events, but still not visible.
Actually I'm hoping to implement Anchoring tonight or tomorrow night, so this will idea can be accomplished.
The Menu is visible, and the menuList (button), but not the ListItem? Is the List itself visible? ListItems by default have no background texture. (but you can set it)
Do your ListItems have text? If not add text and see if the text becomes visible. Another idea is that you might be missing textures. Any widget with a texture name that doesn't exist in a resource path will be rendered invisible. I'd have to look at the code to tell you what textures you need, but if you have all the qgui textures in an Ogre resource path, the Menu should look/work like the demo.
i just followed the method in the demo. The list shows up, and each item can be "highlighted" but i can identify them.
In psuedo code i did this:
menu = sheet->createMenu
menuList = menu->createMenuList
listItem = menuList->addListItem( "An item" )
this was similar to the demo, and I was wondering if maybe i missed some assignment for text or color somewhere.
Did i miss something?
What is different between the demo and your code? They both use the same version of QuickGUI? The same resources available to both?
the only thing glaringly different right now , aside from not as many objects, is that I changed the font to the ogre blue highway. Other than that, it looks pretty much the same. The resources are the same too.
ok went back to acmesa.12 from bluehighway, and they show up now. What is the big difference between fonts on the title of a menu bar versus a menulist item?
bluehighway was working for other items, but not the menulist items... interesting.
Oh! Easy fix. If the size of the font is too large to fit into the caption area, the text won't display. I do a minimum amount of scaling of fonts, to stay close to the actual rendered size.
Thanks for bringing this up, I actually need to address this, since I've been setting the list items to have a height of 20 pixels. For now, if you want to keep the same font, just lower the point size in the .fontdef script, and it should render inside the alloted text area. The QuickGUI Wiki page off the Ogre wiki explains some of this.
Ah! Ok that makes sense. Cool I'll make sure to account for this in the future.
Thanks for your help!
I haven't forgotten about your request, but lately I've been changing how things are done under the hood, to accomodate a future editor, and clean up the design/code some.
In my local code base, I have implemented resizing and anchoring, so the tools to make your concept work are done. The only problem right now is that I've decided I need to revamp the Menu System. Re-using the List widget for Menu's was a decent Idea, but Menu Lists do not need Scroll Bars, and I found a good reference to base the Menu design off of.
I was considering temporarily pausing the fixing of the Menus, and instead working on the MultiLineLabel and MultiLineTextBox, but now I'm not sure. When the MultiLineTextBox is completed, I expect to be close to the next release. I considered releasing before these two widgets are implemented, since I've made so many changes already, but at the moment I just want to find time and hammer through all these features I'm trying to implement. (It also means more users to test
Re-using the List widget for Menu's was a decent Idea, but Menu Lists do not need Scroll Bars.
What do you do, when the amount of menu items is too big to display them in the available space? A scroll bar is the only sensible solution here.
Make a sub list of course! This is my plan for Menu's.
I will create a MenuItem Widget, which derives into the following categories:
MenuLabel - Able to create child MenuItem's, and supports either an icon, or having a check box.
MenuTextBox - Cannot have any children.
MenuComboBox - Cannot have any children.
MenuImage - Cannot have any children. Most common use would be a Separator image (for organizing menu Labels etc.)
The Menu widget will have an option to be LeftToRight, or right to left. Menu's can create MenuLabel's, MenuTextBox, MenuComboBox, or MenuImage's. Menu items will be automatically sized and placed according to its properties, although I can add in ability for manual sizing. To create an actual Menu you create a menuLabel, and have this MenuLabel create children.
MenuLabel* FileMenuLabel = Menu->createMenuLabel("File");
MenuLabel* NewMenuLabel = fileMenuList->createMenuLabel("New...");
MenuLabel* ExtiMenulabel = fileMenuList->createMenuLabel("Exit");
MenuLabel* ProjectLabel = NewMenuLabel->createMenuLabel("Project...");
This would form the Menu with a structure such as:
New... -> Project...
SubLists would remove the need for ScrollBar's right?
No, it wouldn't. It still can happen, that a list (or sub-list) is too big for the available space.
What is the down low on the menus? been busy with other work projects lately, so i have been aloof of the quickgui status. Just got back into the mix of the new release on SVN and noticed some changes.
Menus coming back?
They're coming back, I just don't know when! I think with the Effect system that Tuan put in, you can animate widgets to stretch over time, but the Menu widget is Missing In Action at the moment. I know one other who needs them in their project, I will try to work on these when I get a chance. Sorry for the not-concrete answer..
Ah hey, don't worry about
I was just curious because I was trying to get acclimated to what all had changed in the new SVN. Been recoding the construction sequences. Also, recompiling was fun.
I hate not working on something for awhile, then trying to figure out where the heck you were