Message box API?

[eafton]

Hi, I am a contributor to SDL, and I have been wanting a API for message boxes. SDL currently uses Zenity for them or its built in toolkit depending on if Zenity is installed and which windowing system is used. We would like to start using portals for them instead whenever possible. Zenity, depending on its version, only looks right on a few desktops. And calling Zenity from a library is a massive hack. The X11 built in toolkit does not fit in with any desktop.

[swick]

Not opposed to the idea. Can you be more concrete about the features you would want, and the situations in which it would be used (e.g. is there always a parent window)?

[eafton]

We need predefined icons for warning dialogs, error dialogs and informational dialogs (a question icon would also be nice). Dialogs may also have no icon. We also need custom buttons, just text, no icons. The SDL API also supports custom color palettes but that is not a hard requirement.

As for parent windows, no, there may not be a parent window.

[swick]

Requiring certain icons already becomes problematic. Is there any problem with specifying the intent/semantics of what you want to express to the user and then trust the system (so the portal backends in this case) to create a presentation that correctly matches the semantics on the system?

To be more concrete: the app would say "this is a question and we have those possible answers" and the system would potentially use a question mark icon, but potentially not.

[eafton]

Requiring certain icons already becomes problematic. Is there any problem with specifying the intent/semantics of what you want to express to the user and then trust the system (so the portal backends in this case) to create a presentation that correctly matches the semantics on the system?

To be more concrete: the app would say "this is a question and we have those possible answers" and the system would potentially use a question mark icon, but potentially not.

It is fine if the system prefers to show no icon, as long as it understands the intent of the dialog.

[Mikenux]

there may not be a parent window.

If there is no parent window to which to attach to the dialog box, then it is essential that the dialog box is not perceived by users as a system request, because an app could use it to ask the user to change permissions.

[swick]

/cc @jadahl @Sodivad for other opinion from GNOME and KDE

[Mikenux]

Previous discussion: #1731.

Also note that system integration (for general dialog boxes) is not a matter of security or privacy, nor does it greatly benefit users.

[swick]

Why would we need json and a xdg spec for this?

Agreeing that we should be careful about not falling down the slope of becoming a UI toolkit.

Also agreeing that we should probably just shell out to zenity as a fallback impl.

[jadahl]

Because xdg-desktop-portals shouldn't be in the business of describing UI toolkit abstractions, and an xdg-spec would be a much better fit for such a thing. Having info/error/warning dialogs with buttons and ways to select/cancel /confirm things is already a high level UI toolkit abstraction.

A slightly similar thing, although smaller, was done with the global shortcuts portal and the way to describe keybindings.

[swick]

Counter example: the entire notification portal

It also describes UI toolkit abstraction in the same way this portal would. It does not depend on an xdg-spec. It does not use json.

[jadahl]

The notifications describe a notification, where how they are presented, integrated to the desktop environment, or hidden / ignored is up to the desktop environment. A zenity replacement is about outsourcing certain UI "elements" (dialogs) to some external identity. I don't think they have much in common.

[swick]

I think they are exactly the same. The caller describes the intent, the portal backend somehow handles it. Notifications even have actions with choices and feedback. Basically everything you'd want in a "dialog" kind of thing.

[Mikenux]

Overall, it seems it can benefit the following cases:

• Interactive scripts. A scripter can then call something general rather than a specific program (zenity). However, a standardized "word" to call (like "zenity") is needed for terminals to understand.
• Libraries (like SDL) that needs to present simple messages without depending on a specific toolkit.

For the second case, which is the one seen here, the question is why it is SDL that must send the message and not the app/game? In other words, why the app or game can’t draw the messages itself, using their GUI toolkit? @eafton

[eafton]

Overall, it seems it can benefit the following cases:

• Interactive scripts. A scripter can then call something general rather than a specific program (zenity). However, a standardized "word" to call (like "zenity") is needed for terminals to understand.
• Libraries (like SDL) that needs to present simple messages without depending on a specific toolkit.

For the second case, which is the one seen here, the question is why it is SDL that must send the message and not the app/game? In other words, why the app or game can’t draw the messages itself, using their GUI toolkit? @eafton

Because SDL provides an API for messageboxes that existing applications use, and we need to support it on desktop platforms.

[Mikenux]

Yes, but that doesn't explain why apps aren't in charge of drawing the messages. Take a game where the UI is completely custom. When it wants to display a message to the user, why it should be displayed according to the visual design of a desktop environment rather than to the one of the game?

Here is also an example of an app drawing messages in its visual design (that’s to give an example, using SDL or not is not important here): Steam showing a connexion error.

[eafton]

Yes, but that doesn't explain why apps aren't in charge of drawing the messages. Take a game where the UI is completely custom. When it wants to display a message to the user, why it should be displayed according to the visual design of a desktop environment rather than to the one of the game?

Here is also an example of an app drawing messages in its visual design (that’s to give an example, using SDL or not is not important here): Steam showing a connexion error.

A game or other multimedia program might want to use the SDL messagebox API instead of doing something on their own if some kind of initialization procedure fails.

[Mikenux]

Thanks. I'm thinking it still better to have app integration rather system one. For example, Adwaita style if app using this style; same for KDE. Better to have that if possible, then fallback to DE style if style not available with, for example, a runtime?

[Mikenux]

One thing to consider when approving (or rejecting) this portal: its availability on all desktop environments.

I think it is important, at least for apps targeting only platforms using xdp, that this portal, if approved, be recommended as mandatory. If it isn't, then apps (or their libraries) will have to implement a fallback user interface anyway. Therefore, its use would probably no longer be very useful.