Git Product home page Git Product logo

Comments (7)

texus avatar texus commented on August 21, 2024

You know, Grid wasn't really created for advanced usage.
It was created for simple things like having a few buttons below each other in a menu screen.
It was the first step to having layouts, but it was only a small step.

But this brings back an issue that is not only visible with Grid, but also when just creating a ComboBox and have some widgets below it. How to keep ComboBox (and MenuBar, which has the same problem) in front of other widgets? I would literally make my rendering slower when I would have to find out if there is a widget that has to be drawn last. The solution of bringing a widget to the front when it is focused is also far from perfect. Just imagine you have a child window which half covers the combo box. If the combo box is brought to front, it will be before the child window which wouldn't look good. And I don't find it a good solution either to allow clicking through the child window because the widget behind it would be focused.

I do see a possible solution for when the combo box is in grid. What if getSize would return the whole size when the list is visible, then the grid could be resized so that all widgets below the combo box would be pushed down (the row in which the combo box is located just gets bigger). Of course this isn't great either and it will also require me to add callbacks on size changes.

from tgui.

gupascal avatar gupascal commented on August 21, 2024

Child windows make things more complicated...
I am not sure that it is a good solution to resize the grid when the list is opened. You will just skirt the real issue.
However I am not sure how other lib avoid this problem... We should have a look.

from tgui.

gupascal avatar gupascal commented on August 21, 2024

How child windows are currently managed? Because if you create a child window and then an other widget, the child window will be at the front. That is the case in FullExample.
So I am not sure of what you said: "The solution of bringing a widget to the front when it is focused is also far from perfect. Just imagine you have a child window which half covers the combo box. If the combo box is brought to front, it will be before the child window which wouldn't look good."

But, however, the previous proposition I made can't correctly resolve the whole issue.

However, I had an other idea for this problem. It is a bit strange but I think it can solve all problems with ComboBox related with this issue (and without creating new ones). So, I thought that the ListBox used by the ComboBox should have the gui as parent and each times the ComboBox is opened, it should be moved to the front. Yes, it a bit strange, but there will not have new issues and the following issues will be fixed:
-if there was a widget below a ComboBox, this widget won't partially hide the ComboBox.
-if the ComboBox was at the bottom of a Container, you will be able to select an item when it is opened, even if the ListBox is beyond the container.

from tgui.

texus avatar texus commented on August 21, 2024

Actually, the child window won't be at the front when a widget overlaps that has been added later.
But in order to keep child windows in front (so that if you have two child windows, the selected one will be before the other one) they are brought to front when you click on them. This even causes child windows to get in front of the menu bar (unless you bring it back to front when receiving LeftMousePressed callback from a child window). So sugestions for a different approach on this are also welcome. As with most of my decisions, they are made to solve something but they are never questioned afterwards.

I like the idea for ComboBox, but there is one pitfall. The list box inside combo box doesn't has a parent. ComboBox just uses it as internal widget and draws it when needed.
But I think it can be done. I would have make some changes to the way the combo box communicates with its list box, but there shouldn't be too much problems.

from tgui.

gupascal avatar gupascal commented on August 21, 2024

"This even causes child windows to get in front of the menu bar"
I don't think it is really a matter. It a choice of behaviours that can be made and it is acceptable, imho.
Something that you can do (but which can be quite difficult depending on how things are working), it is to force the child window to be kept out of the MenuBar of its parent when the keepInParent option is enabled. The only matter is that the menubar and the child window haven't always the same parent.... So I am not sure that it is a good idea to do that.

from tgui.

texus avatar texus commented on August 21, 2024

In the end, if you really don't want the child window to get in front of the menu bar then there is a simple alternative. Add the MenuBar and a Panel to the Gui. Then just add all widgets to the panel. By this the widgets will never overlap with the menu bar, plus it has the advantage that position (0,0) lies below the menu bar (if the panel was placed below the menu bar).

Back on topic.
I implemented your idea, but I got stuck. When clicking next to the listbox, it is supposed to get hidden. I can't wait with hiding it until the mouse gets released because that leads to strange behaviour (e.g. dragging a child window while the listbox is still visible). Not a big problem, I just hide the listbox when it gets unfocused. This seemed to work perfectly until I stumbled on a small issue.
When clicking on the combo box, the list box appears. But what happens when the list box is already open? Instead of closing, the following happens: the list box gets unfocused and thus hidden, right after that the combo box gets told about the mouse click and opens the list box again.

from tgui.

texus avatar texus commented on August 21, 2024

I had been thinking about a solution for hours, but only a few minutes after my previous comment I found the solution.

Its a bit of a hack, but it works.
When the list box gets unfocused, a signal is send to the combo box. Instead of always closing the list box, the combo box checks if the mouse is on top of it. When it isn't then the mouse is somewhere else and the list box will be closed. If the mouse is on top of the combo box then nothing will happen because only a moment later the mouse pressed event arrives in combo box which will cause the list box to close.
I also had move the opening/closing of the list to mouse press instead of mouse release in order to avoid other bugs.

from tgui.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.