Greg.Mildenhall Posted September 5, 2018 Share Posted September 5, 2018 I put a <scrollbox height="40"> around the <menubar> in professional_windows_2.6.1_src/source/samples/Api/Widgets/UserInterface/data/user_interface.ui and the menus no longer sit on top of the rest of the UI. Is this a bug, or is there something else I need to do to make menus work from within a scrollbox? Link to comment
silent Posted September 7, 2018 Share Posted September 7, 2018 Hi Greg, We will take a look at this issue next week, sorry. But it looks more like it never intended to work that way (drop-down menus inside scroll area). Sorry for the inconvenience caused. How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
Greg.Mildenhall Posted September 7, 2018 Author Share Posted September 7, 2018 Putting a <groupbox> around the <menubar> gives an even worse result. Personally, I would expect a dropdown menu to always render over the top of the rest of the UI. Link to comment
silent Posted September 10, 2018 Share Posted September 10, 2018 Hi Greg, Unfortunately, WidgetMenu is a regular widget and it's draw order is fixed. I've added this feature request to the our internal bug tracker, but can't give you any exact ETA when this will be implemented, sorry. How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
Greg.Mildenhall Posted September 10, 2018 Author Share Posted September 10, 2018 Where is the order fixed? We'd be happy to patch the order to get things working for our upcoming release. We're only using WidgetMenus in one place. Link to comment
silent Posted September 10, 2018 Share Posted September 10, 2018 Hi Greg, Unfortunately, there is no easy fix available. Currently engine widgets have no correct Z-ordering mechanism, so in order to achieve what you want you will have to implement it first. Another solution will be to use Qt or 3rd party GUI libraries (like CoherentGT or NoesisGUI). How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
Greg.Mildenhall Posted October 24, 2018 Author Share Posted October 24, 2018 We didn't have time to follow this up so we just had to accept releasing our prototype this bug. Now I've got time to ask again: where is the order fixed? Link to comment
andrey-kozlov Posted October 25, 2018 Share Posted October 25, 2018 Hello Greg, Widgets z-ordering is determined by hierarchy and there's no overriding mechanism. That's why moving menu bar down by the hierarchy affects its z-order. Link to comment
Greg.Mildenhall Posted October 25, 2018 Author Share Posted October 25, 2018 Are you telling me that the whole menu is drawn, but then the scrollbox draws over the top of it? Link to comment
andrey-kozlov Posted October 25, 2018 Share Posted October 25, 2018 Not the scrollbar but the tabbox placed down below. You could see it if you set higher "height" value for the scrollbar. Link to comment
Greg.Mildenhall Posted October 25, 2018 Author Share Posted October 25, 2018 I don't think it can be the tabbox drawing over it, because the menu draws over the tabbox just fine if I don't add the scrollbox. And it definitely _looks_ like it's the bottom of the scrollbox cutting off the menubar, not the top of the tabbox. So... any other explanation? Link to comment
andrey-kozlov Posted October 25, 2018 Share Posted October 25, 2018 Yes, you're right, scrollbox seems to crop menubox. But even if it wouldn't that doesn't fix the problem. There's still z-ordering issue that can be seen on the second screenshot with groupbox. Link to comment
Greg.Mildenhall Posted October 25, 2018 Author Share Posted October 25, 2018 OK good, that's progress. Now we know there are two problems to solve. Is scrollbox-cropping-menubox a bug that you're likely to be able to find a patch for? In the meantime I'll try to get the z-ordering the way I want it. If it's just based on hierarchy then that's good, because the two widgets are cousins, neither is a direct descendant of the other. So somewhere there is a pair of sibling widgets (added to the same container) that are the ancestors of each. How is the ordering between those two sibling widgets defined? Can I just add them to the container in the opposite order (maybe using opposite alignment too?) to make them draw in the opposite order? Link to comment
silent Posted October 26, 2018 Share Posted October 26, 2018 Hi Greg, In attachment you can find patch for the current release 2.7.2.1 that allows to WidgetMenuBox to render always on top (in case with ScrollBox widget interaction): Please, check if it will be enough for your current use-case? Thanks! menubox.patсh How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
Greg.Mildenhall Posted December 3, 2018 Author Share Posted December 3, 2018 (edited) Sorry it's taken me a while to get to this. That patch does fix the sample code. When I tried to put the scrollbox we wanted back into our main codebase, I found that it was looking a little different these days and although the patch is _probably_ doing its job, the behaviour is being obscured by an even stranger problem. It's once again very easy to demonstrate by slightly modifying user_interface.ui: after adding the <scrollbox> described in my first post, put a gridbox containing a menubox directly inside the new scrollbox: <gridbox columns="2"> <menubox> <text>a</text> </menubox> </gridbox> You will see that the menubox is only visible when the mouse is hovering over the scrollbox. Do you have any explanation or workaround for this? It might just be a secondary symptom, but if I add enough menuboxes to make the scrollbox need to actually scroll, then I can scroll the menuboxes to make them display outside of the scrollbox as if they were ALIGN_OVERLAP. (they don't overlap the title bar above or tabbox below, so I doubt the patch is to blame) Edited December 3, 2018 by Greg.Mildenhall Link to comment
silent Posted December 3, 2018 Share Posted December 3, 2018 Greg, We will try to look at this more closely during this week. How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
Recommended Posts