Winit: Pop-up menus

[Shookbelf]

Hi, is there any way to create pop-ups like for right click menus with winit? Since right-click menus can also go across the borders of a window, I suppose they need to have their own window and surface.

It would be nice if functionality like this could be included.

[paulirotta]

This is done as a higher level function of glutin or other UI lib that creates the windows and text on them.

Unless an extension binds to the native UI. React Native without the HTML garbage. It would be a most excellent direction but not a small mandate/extension. As a consultant I see a lot of wasted money and lives porting the same app to many platforms just to get the native components.

[Shookbelf]

I am not talking about the drawing of the menu content. My current understanding is that those are basically specialized windows. If I want to spawn a window like that it's currently not possible with winit, because it will behave like a regular window.
Perhaps it would be enough to make it possible to hide windows from the task manager.

Please correct me if my understanding is wrong.

[Osspial]

Do you mean having some way to create windows that aren't placed on the taskbar?

[paulirotta]

I believe that is correct- small "windows" without edge decoration or appearing in the taskbar for things like menus. It is then up to a higher level lib (out of scope- you choose what to do) to populate these.

[Shookbelf]

@paulirotta Unfortunately I don't know exactly how it is done on different platforms.
This could be enough if the following features are supported:

• The window should not show up in task bars or similar
• It should not have borders
• Focus should be handled correctly

Most things can probably be handled by users of winit if the basics work.

There might be more subtle behaviour on different platforms though.

In xdg_shell there is a protocol xdg_popup for exactly this type of windows.

[Osspial]

Borderless window handling is already supported. As far as the other two features go, implementing them on Windows seems to be pretty easy, and I've done so in these two branches: focus and taskbar.

I don't know how it would be handled on other platforms, but I can't imagine it's too much of a challenge.

[francesca64]

This would be straightforward for me to implement on X11. I'm in favor of moving forward on this, provided it's viable to implement on macOS as well.

[Osspial]

It looks like, on OSX, windows can be excluded from the dock with this flag, and focus can be handled with modal windows. I'd need to actually test those, but that should be fairly easy to do.

[Osspial]

Something worth noting is that Wayland doesn't let you specify where a window will be placed on-screen, which complicates right-click menu creation - it's expected that a menu would be created at the mouse pointer, but there's currently no way to ensure that happens on Wayland.

@vberger Does Wayland provide any way to work around this?

[vberger]

Wayland provides a special kind of surfaces that are made exactly for this use-case (popup tooltips and menus, that are positioned relative to a parent window), so we can absolutely do popup surfaces.

In this case, my preferred way forward would be to first introduce the proper abstraction for popups in Smithay's Client Toolkit and then use it in winit.

But API-wise, would popups be represented by regular winit Window or some other type?

[Osspial]

Somewhat of a necropost, but I feel like popups should be represented as regular windows. AFAIK the only major difference happens during the creation process, after which they can be safely treated the same way as a normal window would.

[Shookbelf]

Just for clarification: in the #695 there are two concepts, popup and tooltip windows. According to the examples, this issue is not about popups, but about something more like tooltips.

When I looked into it, I realized that context menu windows usually have very specific behaviour: they exist only as long as they or some further child have focus and have to have exact placement.

I am absolutely sure this is a concept all platforms share (even Android has them), so winit should support this in some way. If it's only exposed in the platform specific implementation, so be it.

I agree that most of the logic could be implemented by the user, but having the according settings for such windows implemented in a cross platform way should not be more effort than other settings, most is even already possible. Since they are so ubiquitous, it should be possible to create them without calling platform specific functions.
On the other hand, the Wayland positioning situation makes it impossible to do this in a good way, since the window would have to be created with platform specific code anyway.

I'd be okay with closing this issue if the implementation is possible with what is exposed in the platforms, but that has already been discussed over at #695.

[dhardy]

More than a year later... where does this stand? Do we have an API design or at least a list of requirements?

It was decided in #695 to support pop-up windows. From that a + this thread we have a few requirements:

• optionally, no decorations (already possible)
• skip the taskbar
• optionally, able to block interaction with parent window
• optionally, able to close self if focus is lost (for menus & tooltips) — with e.g. Qt on X11 these even capture the next click anywhere on the screen, meaning it takes two clicks to activate a different window
• precise positioning

To expand on the latter:

• things like file-open dialogs don't matter too much but should be over the parent
• menus are usually aligned to one side of a target box, flipping to the other side if there is insufficient space (and the app may want to know which side)
• since multi-screen set-ups are not always a simple rectangle and since winit's users only use coordinates relative to the window, the user can do no more than specify a target rect in window-coordinates and a preferred alignment direction

[ArturKovacs]

I think we should be careful not to confuse this with "tooltips" or "pop-up windows".

It seems that this is something that has a specific API on both Windows (CreatePopupMenu) and MacOS (popUp(positioning:at:in:)). I haven't used any of these APIs but they really seem to be exactly for what @Shookbelf described in the original post.

In my opinion winit should expose an API that's specific to these "pop-up menus". To me it would feel over-engineered to expose them as regular windows.

[dhardy]

@ArturKovacs as I understand it, everyone else in this thread is talking about general-purpose (client-drawn) pop-up "windows" / surfaces, not one where the OS provides the menu model. I mean, that would satisfy some uses of this, but it's really a different topic.

[ArturKovacs]

Hmm well the wording of the original post by @Shookbelf supports what I'm proposing (pop-up menus) but immediately afterwrads @Shookbelf wrote

[...] My current understanding is that those are basically specialized windows.

which supports the "pop-up window" route.

To me this post is rather ambigous. I think it's necesarry to edit the original text and make it obvious what this issue is about. If this is indeed about "pop-up windows" (generic windows without a border that don't show up on the taskbar) then I'll just create another issue for what I would like to achieve. I would also be willing to implement what I proposed.

[Shookbelf]

IMO it's more sensible to provide generic surfaces that the client can draw to.

Not every platform provides native menus and custom windows would be far more flexible. They just need special "modal" logic to behave correctly. But this could be emulated by the client observing window events.

However, after more than 2 years this issue does not really affect me anymore, so feel free to exclude me from the discussion.