BetaGUI : BetaGUI 2.5 update - Style system added.

[betajaen]

Two small requests/questions (I can't really telll what is implemented and what isn't). I need to get the mouse position back from the menu for aiming purposes, is this already in there? and is it possible to add some kind of enumerator that allows the text when a label is created.

Everything is implemented; Window, Button, TextInput and StaticText are implemented.

You can control the GUI mouse in what way you like, it's happy to jump around quite easily, and the GUI system only operates on injections only, so you can flip between aiming and menu very easily.

I'm not sure what you mean by "enumerator that allows the text when a label is created."

Why are there two publics on the callback example?

This looks very awesome though, and I will be trying to implementing it soon.

Hmmm. There is only one public in my code. Anyway good luck with it.

[big_o]

Should have proofread my post first. I was trying to do one to many things at one time.

What I meant was an enum to control the alignment of the text labels.

I might just do it myself, but I'm going to be busy the next few days.

[irrdev]

@betajaen

Ok, I know that you are supposed to be "finished" but I just can't resist making a wish list for a couple of extras! Here they are:
1) Add a flag which points to another mouse pointer which is displayed when the user hovers over a button. If the mouse pointer is NULL(ie. not initialized) then the mouse pointer doesn't change.

2)An option for setting the trasparency of the window.

3)A parent->child window configuration. The child windows would preferably have a smaller title bar, and can be effected by changes made in the main window. For example, if the parent moves, the child moves too.

4)Have an "X" exit icon on the top-right of the title bar of all child windows. The parents windows would not have this so that they would always be visible unlessed distroyed by the app itself.

5)Have a special window dialog which can only have one instance in any app. There is no title bar, and it acts and looks to the user like a menu strip at the top of the screen. I think this would be really simple to add, especially if you just used window buttons for for the menu choices. Of course there wouldn't be any animation effects or the such.

6)Draw 2d images inside a window. This would be really useful on startup for example; show a welcome screen and the app icon in the window with an OK button at the bottom.

This may look like quite a long wish list. The only reason I haven't tried implimenting these features myself are because you spoke truthfully when you said that the code was un-readable! I don't think that they would be very hard to add, and they mostly deal with window management anyway. After all these additions, I think your gui calss could still be considered "small and sexy." Hey, the class used to be some 200++ lines of code; that means you can still add 101 lines and still fit into your description!

[betajaen]

@betajaen

Ok, I know that you are supposed to be "finished" but I just can't resist making a wish list for a couple of extras! Here they are:
1) Add a flag which points to another mouse pointer which is displayed when the user hovers over a button. If the mouse pointer is NULL(ie. not initialized) then the mouse pointer doesn't change.

Okay, here I go. The Mouse Pointer is optional, I added the option that way so you may have your own mouse pointer system. If you don't set a Mouse Pointer in BetaGUI it's never displayed.
But if your mouse pointer is an overlay for example then you can just set mMP in GUI to your mouse pointer overlay, for anything else just don't use GUI::createMousePointer() at your setup code.

2)An option for setting the trasparency of the window.

That would be handled via the material perhaps via a shader or just a png image.

3)A parent->child window configuration. The child windows would preferably have a smaller title bar, and can be effected by changes made in the main window. For example, if the parent moves, the child moves too.

If you mean something like MDI in Windows, then it would increase the code count and complexities of it all. I don't think many people would use it too.

4)Have an "X" exit icon on the top-right of the title bar of all child windows. The parents windows would not have this so that they would always be visible unlessed distroyed by the app itself.

Thats just easily done by the user, simple button at 0,0 22,22 pixels in size with a callback to a close window function.

If I added it myself, again theres the extra code and an extra function in the callback function, also handling it. It's probably better to let the user handle such things.

5)Have a special window dialog which can only have one instance in any app. There is no title bar, and it acts and looks to the user like a menu strip at the top of the screen. I think this would be really simple to add, especially if you just used window buttons for for the menu choices. Of course there wouldn't be any animation effects or the such.

That would be window at the top, that cannot move or resize. With buttons with custom materials too look like menus, click on a button you get another window, with a list of buttons. It would come off quite well.

6)Draw 2d images inside a window. This would be really useful on startup for example; show a welcome screen and the app icon in the window with an OK button at the bottom.

I may add a custom material for the StaticText, or you could just add an overlay manually to mWindow->mOP for this.

This may look like quite a long wish list. The only reason I haven't tried implimenting these features myself are because you spoke truthfully when you said that the code was un-readable! I don't think that they would be very hard to add, and they mostly deal with window management anyway. After all these additions, I think your gui calss could still be considered "small and sexy." Hey, the class used to be some 200++ lines of code; that means you can still add 101 lines and still fit into your description!

There are a good wish list, but if I added them it's then half implementing extended GUI features.Then others would want the other bits and more then it would be very hard to keep it less than the 200 line level. Most if not all of them above can be replicated by the 3 available GUI gadgets things; Buttons, TextInput or StaticText anyway.

Of course your welcome to "semi-wrap" these new features such as Menus or even MDI (just re-attach the windows->mO to another mWindows->mO) and post it on the add ons second in the wiki page.

Sorry to be so negative but like many times before I have my reasons and I'm sticking with them

@big_o

Ahh, like centre the buttons or make the window title centered. I had a quick go at it, but there is no real way (that I can think of) of actually getting how many pixels across a piece of text uses. From that I can centre the text horizontally, but now left aligned is the best I can do

[big_o]

There already is a textAreaOverlay element alignment atribute. I use it in my game, but I use relative metrics instead of absolute. The feature isn't very well documented, but it's in there.

I prefer relative metrics over absolute, and going back to absolute is going to mess some stuff up. I'll have to try it out though.

Owen

[rUmbl3]

I found another linux specific bug
The Ogre max. ZOrder on linux seems to be 650 and you set it to 9999 ..
you will get such a nice assertion error:

Code: Select all

 Assertion `zorder <= 650 && "Overlay ZOrder cannot be greater than 650!"' failed.

[betajaen]

Fixed. I've also added the ability to hide and show windows (and check if they are hidden or not). I've also fixed a bug with Buttons not having any materials, but suspect the same bug is with textinputs as well.

I have an idea how to fix that though, and it would take up less code at least 200 bytes.....But I'd have uncompress the source again. Which isn't any easy task

[M]

But I'd have uncompress the source again. Which isn't any easy task

astyle
Never shearched for tools to obfuscate it again

[betajaen]

88 Lines now.

New features.

• The InputText now behaves more like their real world counterparts. Click to enter text and click off to not enter text. Also you can manually set the value as well.
• Code is now shorter and neater, it now refers to the Buttons or Inputs for mouse checking rather than the Window check code or not.
• Font and FontSize are passed on via the GUI constructor rather manually editing some code, so the vertical alignment works better now. Rather than some hard coded value I made up.
  [Edit]
• You can hide/disable windows from the view now.

And for a special treat, un-compressed BetaGUI 460 lines

[Vectrex]

this isn't a 4k demo party btw I don't think anyone really cares how lines of code it is ...unless you're making an Amiga port, ooolllddd skkooolll *dances like mc hammer*

[romulo]

great \o/
thanks for sharing this with us

[Wretched_Wyx]

Wowsa... Just keeps shrinking! Sweet deal on the non-condensed version too. I would ask if it was safe to assume this would be the last revision, but something tells me it won't be .

[nikki]

Excellent work for 88 lines, betajean! I needed a GUI system and was terrified (well, not really ) by the amount of work and resources CEGUI needs. Looks like BetaGUI was exactly what I was looking for, as my game doesn't rely on GUI much.

Once I convert my physics code to (the now free) PhySX (for the next game), I'm going to owe a lot to you!

One question: While injecting keys, I have to pass a string. How do I convert OIS::KeyEvents to Strings? (noob question )

[betajaen]

One question: While injecting keys, I have to pass a string. How do I convert OIS::KeyEvents to Strings? (noob question )

Good question!

This is what I use, it's a little hacky but it works:

Code: Select all

class myClass : public OIS::KeyListener {

	...

	bool keyPressed( const KeyEvent &arg ) {
			
		if (arg.text == 8) {
			mGUI->injectBackspace(mPointer->getLeft(), mPointer->getTop());
			return true;
		}

		if (arg.text < 32 || arg.text > 126)
			return true;

		string k;
		k = static_cast<char>(arg.text);
		mGUI->injectKey(k, mPointer->getLeft(), mPointer->getTop());
		return true;
	}
	...
};

@Wyx
Probably not

@Vectrex
Stop giving me ideas to compress it to 4k!

[Wretched_Wyx]

Here's a couple of shots of a work in progress with BetaGUI. I must say it's hot stuff... And even though BetaGUI is so lite and simple, I can see a ton of possibilities with it.

*whoops- just deleted a whole crapload of files on my server... the pictures that should be here included. (12.14.06) *

My next project after getting BetaGUI pumping along in my engine, is making an alter to exalt in Betajaen's image.

[Kezzer]

That's awesome. How're you getting the rounded corners on the current fps box in the lower left hand corner? In fact, how're you getting the inner drop shadows on the main window? I don't think I've played around with overlays enough yet seeing as though I can't get them to work at all

[nikki]

I think he's using a material with a texture (probably .png) that has an alpha channel.

I have another question for betajean:-
Can't we have title bars even for unmovable windows? It makes them look cool, you know.

[betajaen]

You could cheat and make a static text, and apply the title bar material to, there is needed a change to the function that creates it though. So you could modify it yourself or wait for that and the following:-

I've added some changes to BetaGUI onto the non-compressed version which handles multiple BetaGUI's at the same time (so you can have different levels of Z-Ordering), another bug fix, and the biggest change the ability to detect mouse overs and mouse outs on buttons.

Now adding these changes to the compressed version, and still retaining the 88 line mark is a challenge

[Kezzer]

I think he's using a material with a texture (probably .png) that has an alpha channel.

I have another question for betajean:-
Can't we have title bars even for unmovable windows? It makes them look cool, you know.

Surely if it's scaled up though then the rounded corners will stretch? Is there a way to fix a corner texture to an overlay?

[nikki]

Now adding these changes to the compressed version, and still retaining the 88 line mark is a challenge

It doesn't matter (to me, atleast) whether its 80 lines or 420 lines. All I want is GUI for lazy people.

Wyx, you've got some cool pixel art skills (that is, if you made that).

[Bekas]

Now adding these changes to the compressed version, and still retaining the 88 line mark is a challenge

It doesn't matter (to me, atleast) whether its 80 lines or 420 lines. All I want is GUI for lazy people.

I'd much rather prefer the 420 lines if it meant that I can understand it better. I would care how many lines it is only if I was a compiler or something
IMO it would more useful to put the uncompressed version with comments etc. on the wiki, instead of the 'compressed' one.

[Wretched_Wyx]

@Nikki- Thanks. One of the few things I can do well if I put time into it.

@Kezzer- Nikki hit that on the dot. I'm using the png format with alpha channels. I've checked out how the stats overlay and the BetaGUI look at resolutions from 640x480, to 1280x1024 and the only resolution that any squashing or what have you came about, were at the wide-screen ones (eh... 1280x720, 1280x768, 1280x960 I think). I'm always running in 1024x768, so my art assets usually reflect that.

With the shadow effects... That took some trickery. My "menu" is 512x256... You can see the source texture for that here. The menu title bar is 512x22. Here's the source texture. I suggest saving and opening those up in Photoshop or something, so you can see what I mean a little easier.

I was having some problems with the border pixels on the main menu, so I had to make it a tad bit smaller than the whole window. So when I saved it out, it ended up having a cool effect when put together with the title bar.

You'll also notice the title bar doesn't take up the whole 22 pixel height (the bar is 16px, but the whole image is 22px high... it's completely opaque at the bottom 6px). This gave the effect of the title bar sitting on top of the menu. For the shadow under the title bar, on top of the menu, I added a shadow on the top of the menu texture. So you see, it's all trickery .

You can come up with quite a lot of cool effects when you experiment... I haven't even dove into the buttons and input yet, let alone the hover states Betajaen is gonna be adding. I've tried and tried with Cegui to make clean looking interfaces, and finally decided to not even bother. Something tells me BetaGUI is gonna do for GUIs, what NxOgre does for physics .

[Edman]

This is really awesome Great job!!!

[Fuinelen]

just wanted to say thanks for Beta GUI just a great addon!

bbye,
Sammy

[grizzley90]

Anyone planning on porting this to Mogre, its such an awesome GUI! so simple but brilliant...