Adding properties to widgets

[iceiceice]

So, I have this issue in my application. I need (or, really want) to be able to place a certain menubar near the bottom of the screen. When I do, if I click on any of the menu items, the popup menu goes off the screen and I can't click on it. I want the popup menus to come up rather than down when this happens.

The behavior of the popup menu locations is set in `src/widgets/Menuitem.cpp`, in `openPopupMenu` member function. If the parent is a `Menubar*` then the popupmenu position is set to the lower left corner. If the parent is itself a `PopupMenu*`, then the popupmenu position is set to the top right corner.

The solution I've converged on is, either MenuItem or MenuBar should have an extra field which I can toggle to make the menus open the opposite direction of default. You have to do a little arithmetic with "getSize" on the popupmenu to get the positioning right.

Like a properly trained code monkey, I can see the `void MenuItem::addMenuItemProperties(void)` member function also and I can see how to extend the pattern in regards to my new property.

Let's suppose I've got that working, or close enough that I can figure it out on my own.

The questions are

- What happens to falagard then? Do I need to tell falagard about the new property, or it will just figure it out?
- What happens to CEED then? Do I need to rebuild CEED from source using my modified CEGUI sources? What's the worst thing that will happen if I don't do this?
- Do I need to do something special with the python bindings? Do they automatically know about new properties somehow, or do they need to be updated somehow?

The main thing that is giving me pause with a change like this is breaking my CEED, I <3 my CEED.

[iceiceice]

Hmm, well I ended up rebuilding CEED out of fear, and it all seems to have worked magically. My menus are rendering as expected and as desired in both CEED and my application.

But I would love to hear the truth "from the horse's mouth" so to speak.

Esp., if I don't rebuild CEED and use a prepackaged version, but my .layout XML files contain references to "custom" widget attributes that aren't part of a default CEGUI build, will it (1) render wrong but work fine? (2) cause errors on loading? (3) cause horrible crashes and corruption because of some ABI issue I didn't really understand?

Cheers!

[Kulik]

Ahoy! I'd be the horse, I guess.

CEED uses CEGUI to render everything, there is no extra GUI rendering implementation in it. If you changed something in CEGUI implementation itself you need to rebuild CEED to use it. The worst that can happen is that CEED will render your menus in different places than the CEGUI you are using. This makes CEED really useful if you are hacking CEGUI, you can play around layouts and widgets while you are changing CEGUI.

However that is not the entire answer... CEED will load CEGUI schemes which can load modules, looknfeel files, etc... So you may end up in a situation where CEED use one version of CEGUI, your app has the same version but your app has a different "CoreRendererSet" version. You can setup CEED to load it if the ABI is compatible, which it sounds like it is. So if you just changed the CoreRendererSet you don't need to rebuild CEED, just make sure it loads your changed .so.

If you just specified new properties in looknfeel files everything is transparently picked up and you don't need to rebuild anything. Just make sure the scheme you are using in CEED is the same you use in CEGUI.

So tl;dr: Rebuilding CEED if you changed CEGUI is a good idea It can't really hurt anything.

Hope this helps!

[YaronCT]

@iceiceice: If u add anything useful to cegui, don't forget to open a pull request!

[iceiceice]

@YaronCT:

So, I guess here's the thing: I don't think my fix is actually a "good" fix for this.

One thing I remember from Windows actually (from when I was a little kid and I still ran windows) was that there was some point, maybe it was Windows 98, when they made a gui innovation that I noticed: the menus that popup from the Start menu started doing this behavior where the direction they open up was dependent on how much space they had. When you moused over and opened up a submenu, if the new submenu would be off the screen, then it would go in the other direction. And actually, if that submenu had more submenus, they would continue to open up in the same direction, as though the tree of menus had "bounced off the wall". Not only were the menus aware of how much space they would have, they were also aware of what past menus had done. So whatever the MS folks had coded was pretty elaborate.

I think the fix I'm adding here is basically a hack, a better fix would be if the popup menus could intelligently ask CEGUI if they would be clipped if they were opened in a certain place, and then tried to find the best location. Idk if "bounce off the wall" logic is necessary, but it doesn't really make sense to have to add a widget property here to do the right thing, it shouldn't need a human's help here to do the right thing.

There's some challenges here that push my knowledge of CEGUI implementation though:

1) How exactly should I ask CEGUI whether a rectangle in a certain location would be clipped? Presumably there is some context object I can ask but there are several kinds of rectangles, the draw rectangles, the "hitbox", and so on, I don't know what the right way is to do this right now.
2) How should I handle it if my menu is actually inside of a scrollable pane? In that case it will get clipped differently. So I need to do some recursive crawl up the parent tree actually?

If I would solve this problem properly and make a pull request I would want to do it properly along those lines and not making new widget properties, what I have right now is basically just a hack suitable for my application. If you can give some pointers / notes for me I might try to implement the proper version later and make a PR, I think it would be a nice thing to have, but it's not urgent for me right now so it would probably be a while before I actually make a patch.

Cheers

[YaronCT]

Thanx for the thorough explanation!

That makes sense.. Well, if u ever feel like diving deeper into it we're here to help u.

Do note though that praising Windows, explicitly or implicitly, would usually get u an instant ban, however as u were a little kid you'll get a one-time pardon.

[Ident]

Suchs bans of course only come into effect in the year of the Linux desktop.

[YaronCT]

Which will start next week of course, as my secret project of a desktop built solely upon cegui will b released and smash Windows and macOS instantly.

But who cares about it, the year of the linux console is the thing.

[iceiceice]

Hey, so I became unhappy with the "flip popup menus" solution I was using, and I implemented a more sophisticated strategy somewhat like described. PR is here: https://bitbucket.org/cegui/cegui/pull- ... -for-popup

[YaronCT]

Oh so you and Christopher r the same person.. I've never realized that..

[Ident]

Oh so you and Christopher r the same person.. I've never realized that..

It is pretty obvious, his nickname consists only of letters from his real name

[YaronCT]

W8.. does that mean.. Ident8 and Ident r also the same person?? I'm thunderstruck.

[Ident]

W8.. does that mean.. Ident8 and Ident r also the same person?? I'm thunderstruck.

Ident8 is my alter ego, with which i conceil my real superhero-like identity, which is my 'Ident' account. The '8' iconographically resembles the glasses that Clark Kent wears, when he is not superman. Similar to him, I become ultimately unrecognisable when putting them on (my nickname).