GUIX Popup Windows

I want to display a simple popup window with messages at different times in the application.

I can get the window to appear, with the messages.  The problem is that underlying GUI elements "pop" through the message window whenever they (the underlying elements) are updated.  This, of course, is unprofessional and annoying.

I have tried implementing the message window as a modal dialog, and as simply a child of the underlying screen.  I even tried making the underlying screen a child of the message window, but some of you will know how that turned out, I'm sure.

I've looked through the example code, and have studied some of the source, and I am stuck.  Z-order seems only used in parent-child relationships, and the underlying widgets are not children of the popup window.

My next step is to see what I can do to force all of the widgets underneath the popup rectangle to see themselves as not visible.  I'm afraid, though, that the clipping will then be done with the aggregate dimensions of the underlying widgets, instead of simply the popup rectangle.  If so, I will get a pretty ragged region, which also will not look good.

What have I missed?  I expect it may be pretty elementary, so feel free to say so!

Thanks,

-steve

  • Hello Steve,

    Modal window should be independent top-level widget in GUIX Studio. During GUIX initialization, call gx_studio_named_widget_create() but with second argument set to NULL. When you need to display a pop-up, attach window to your root window and call gx_window_execute. To leave the window, you'll need to call gx_window_close (or gx_widget_detach, if you're using older SSP version).

    Regards
  • In reply to Renesas Karol:

    Hello, Karol -

    This works, in that it prevents underlying widgets from popping through the modal dialog on update. Unfortunately, it prevents messages from getting to the underlying windows at all; which I cannot tolerate, since the underlying window is driving a critical operation and needs its data!

    EL needs to fix GUIX so that occluded widgets know they are occluded and only mark any visible portion of themselves as being dirty.

    IMHO, of course.

    Regards,
    -steve
  • In reply to steve:

    Hello Steve,

    How are you sending messages to the underlying windows? If they're attached to the root window, the should still be active (even though the focus is set elsewhere). Sending events with target set to NULL, will send them at the widget that owns input focus (which should be your pop-up). You'll either have to make your pop-up widget "understand" your critical messages and relay them to the right window or send these messages directly at the window that needs them (by setting the target as pointer to that window).

    Regards
  • In reply to Renesas Karol:

    Thank you, Karol, for your response.

    The events are sent to a NULL target, since the originator of the event does not know which window might be active at any point, and many of those possible windows need to see the event. Should I educate the popup code to propagate the events to the previously active window, I will end up with the same trouble - the widgets will show through my popup when they update.

    The idea of a generic modal popup is a) that user input is captured, but other system messages flow as they should; and b) nothing shows through the popup, ever.

    The gx_window_execute function performs the first requirement nicely, as long as the popup is a child of the current top window; this is not difficult to code, as the handler for the event requesting the popup can be made to be part of the general system default event handling. Performing the second requirement should be part of the GUIX Z-order management: if something is on top of you, don't poke through it.

    I have overridden the two gx update functions which are the specific source of my problem (gx_widget_fill_color_set and gx_prompt_text_set). In each, I check to see whether I have a popup active, and if so, whether any part of the widget to be updated underlies that popup. When both conditions are true, I remove the GX_STATUS_VISIBLE bit from the widget before calling the overridden function. When that function returns, I restore the bit to its former state. This works, but suffers somewhat because even when the widget is only partially occluded, none of it is drawn. Since this meets my current need, I'll leave it at that.

    I'll consider this particular discussion over, unless you'd like my help making the argument to EL that some GUIX work is needed :{)

    -steve
  • In reply to steve:

    I have exactly the same problem. Has anyone found a better way to solve this than what Steve did?
  • In reply to MCP:

    I have the same problem in my application as well.  Originally it was designed to alpha blend the background that is not covered by the message pop-up.  Since elements kept coming through we had to switch to a non-transparent blackout of the underlying screen when a pop-up is active.  I am hoping a fix for this will be included in a future GUIX release since our solution is compromised.

  • In reply to Jamie:

    Here's the solution I came up with - (it might or not might work for others).

    My app updates various numbers in real-time. I do this through a timer - every 1/10 of a second I ask all the numbers if they need to redraw with new values. But the user might be in the middle of using a popup menu. So what I do is, after I've looped through all the numbers and called gx_prompt_text_set on those that need it, I search the top window for any popup menus (they'll be the VERTICAL_LIST widgets at the end of the list since they were attached most recently) and mark them as dirty. Then the next system_update will redraw both my numbers and my popups. I imagine I can adapt this to mark modal dialog boxes as well.

    It depends on my app knowing (and controlling) when I update other elements, but since all the GUI stuff is in one thread that's not a problem right now. It also means the popup menu gets redrawn more often than strictly necessary but again my popup elements aren't terribly complex.
  • In reply to MCP:

    I just discovered that y popups aren't always the last item in the list even when they are added last. GUIX is moving the order of the children in the linked list of the parent. I don't know why but this means I have to search the whole list. Very weird.