The image-button example did not work with `just run image-button`.
The first problem was that the package name was `cosmic-image-button`
and not `image-button`. It was defined as `image-button` in the
justfile.
The second problem was that the `wayland` feature defines the
`set_window_title` as taking an `Id`. The easiest solution was to just
use the `winit` feature instead. We can alternatively pass
`window::Id::MAIN` if needed.
This ensures that the vertical space between the top/bottom list items and the edges of the container remains the same as the spacing between items, when the default `list_column` spacing is changed.
Better support for multi-threaded applications,
especially cosmic-comp rendering in parallel on
multiple threads, each potentially accessing
global configurations such as the active theme,
icon_theme and more...
Although this is used in apps that use `tokio`, if we're going to
support `smol`, this seems suboptimal to require.
This assumes the function will be called by a tokio executor if the
`tokio` feature is used. Otherwise it can be spawned from any executor.
That should be consistent with everything else.
This fails to compile without either the `tokio` or `smol` feature. This
seems reasonable, since `zbus` also fails to compile in that case.
This is needed for things like `xdg-desktop-portal` to get the app ID
from a pid, in unsandboxed apps.
https://systemd.io/DESKTOP_ENVIRONMENTS documents this, and this sets
things similarly to how Gnome does. Which should be good for now.
Making `spawn_desktop_exec` an `async` function is reasonable given it
is called in `async` functions in
`cosmic-app-list`/`cosmic-launcher`/`cosmic-applibrary`.
`rustix` and `libc` are already in the dependency tree, and `rustix`
follows IO safety rules, so use those.
We can use a pipe to get the PID of the double-forked process.
