Native menus, popups and file dialogs

[fschutt]

This is a relatively big issue to tackle, especially on Linux. Currently, all OpenGl-based options don't have a menu, which looks a bit ugly. On Windows, this is ok, because the menu is drawn inside the window, but on other platforms (OSX and Linux), it looks a bit empty, especially regarding that limn is supposed to be designed for desktop applications.

There are native menu toolkits for Rust already, except for Linux, which is why it's the hardest one of the three. Native menus should probably be feature-flagged, etc.

Here are crates that limn could use (for menus):

Windows:

• native_windows_gui: https://gabdube.github.io/native-windows-gui/api/native_windows_gui/index.html
• winapi-rs: https://github.com/retep998/winapi-rs

Linux:

• minifb has an (supposedly) implemetation of native menus: https://github.com/emoon/rust_minifb - in practice this doesn't work. Plus the code needs to probably be forked.
• My own library, dbusmenu-rs: https://github.com/fschutt/dbusmenu-rs - doesn't work, however the supposedly Dbus API is implemented, so it should be only a matter of debugging

OSX:

• cocoa-rs: https://github.com/servo/cocoa-rs
• There was a library that already implemented menus using cocoa, but I can't find it anymore

For popups, there are two choices (aside from implementing everything yourself):

• msgbox - https://crates.io/crates/msgbox
• tinyfiledialogs - has popups as well as file dialogs included, used in servo, however it is only a wrapper around a C library.
• There is also native_file_dialog, which just concerns itself with file dialogs, works rather well in practice though. Uses GTK3 on Linux.

This is just an idea to make limn the go-to choice in developing GUI desktop apps.

[christolliday]

Agreed this would be nice to have soon.

Maybe there could be cross-platform crates created for both of these, might not even need to add code to limn directly, but we can test them and show how to use them in the examples.

In terms of native dialogs, I think maybe file dialogs are all we should add. Are there other types of native dialogs that you think are important? We should add the ability to create multi-window apps, and allow windows to be modal, then the contents of the dialog can be specified by limn.

[chris-morgan]

It's worth noting that the Windows 10’s Universal-style apps don’t use menus, do still use the old file dialog (well, Groove does; I’ve also seen third-party apps making their own full-screen UWP-style thing, which really didn’t work well), and use a different type of message box from the one that the MessageBox function provides (see the sample screenshot below—different colours, mixed font sizes and so forth). Not sure precisely how UWP stuff can tie in best, but my ideal goal would be being able to produce something that behaves exactly like any regular UWP app.

[valpackett]

Do we really need native menus everywhere? e.g. JavaFX only does native app menus on macOS, draws custom menus everywhere else.

Also, a lazy way to get a GTK+ file dialog: exec zenity --file-selection :)

[christolliday]

Do we really need native menus everywhere? e.g. JavaFX only does native app menus on macOS, draws custom menus everywhere else.

@myfreeweb I don't know tbh, I guess it uses a custom menu just under the window bar? I've seen some Java apps that do that and it seemed a little weird to me, I wonder if they do that because of this UWP style.

@chris-morgan I'd say eventually it should be possible to write something that behaves like a UWP app but emulating UWP well in limn is going to be a lower priority than working well on the lowest common denominator. It should be possible to create and depend on a crate that makes UWP style dialogs though.

The reason I think file dialogs are more important than other dialogs is because emulating them is more than just copying the visual style of a platform, it also needs to know about bookmarks, platform specific 'special' folders, etc. to do it well is a lot of work, plus it should be pretty straightforward to create a platform independent API, assuming it can be made to work on each platform.

[valpackett]

It's not "UWP style", it's just that JavaFX draws everything by itself — just like Limn — so it uses a custom menu under the window bar. GTK and Qt also draw their own menus (unless you make Qt draw GTK menus)

[fschutt]

Well, native menus are certainly easier to implement than drawing your own. QT and GTK draw their own menus if they control the window manager (e.g. GTK in GNOME, QT in KDE). Otherwise, GTK and QT applications use the dbus protocol to register and unregister menus for windows. They don't draw their own menus, they communicate to the window manager what they want in the menu (via dbus), then the window manager draws the menus. Not the toolkit per se.

This has changed a bit with wayland (I am not sure how menus are handled there), but since X11 is still very relevant, this would be the first milestone.

[valpackett]

The D-Bus stuff is not common functionality, I think it's only used for global menus in KDE, Ubuntu Unity, etc. (BTW, look at the KDE link — they managed to do this in Wayland!)

My window manager (i3) definitely does not draw menus :D