Applications window: natural-size row buttons, menu button toggles in place

[kacperpaczos]

Fixes #232, fixes #233

Two things about the rows in the applications window, in the same block of on_show_applications_clicked.

Each application is an expander row

The rows held Run, Add To Menu / Remove From Menu (and the binaries' Remove) as pill buttons with fixed width_requests and a gtk::Separator between them - stretched to the row's full height and lined up in columns, the list read as a table of oversized buttons, and the app name was squeezed into what was left (#232). Dropping the pills for natural-size buttons (first commit) turned out not to be enough: Remove From Menu is wider than Add To Menu, so neighbouring rows' buttons stopped lining up and the suffix came out ragged.

So the row stops holding buttons altogether (second commit): each application is an AdwExpanderRow that collapsed shows only the icon, the name and the arrow - every row identical, the name gets the full width, nothing to align - and what can be done with the app lives in activatable rows inside it: Run, and the menu row below. The one trade-off: running an app is now two clicks (expand, then Run) instead of one. The binaries' Remove stays a suffix button (valign: center, no pill) - it is the row's only action and is the same width in every row.

One menu row that follows the menu

Which of Add To Menu / Remove From Menu an app got was decided once, when the list was built, from whether <box>-<desktop file>.desktop existed on the host at that moment; after a click the heading said "App Exported!" but the row still offered Add To Menu until the window was reopened (#233). The action is now one row: on activation it exports or removes depending on the current state, then re-reads the host's applications directory and retitles itself from what the menu actually holds. The confirmation text is only written when that changed, so it can't say "App Exported!" when nothing was. The two old handlers collapse into toggle_app_in_menu + set_menu_row_title.

The host file name (<box>-<desktop file>.desktop, what distrobox-export writes - desktop_home_file="${container_name}-$(basename "${desktop_file}")" in distrobox-export) was assembled inline in get_apps_in_box; it is now exported_desktop_file_name, shared with the new is_app_exported, with a unit test pinning the format. All four labels are the same literal gettext strings as before, so existing translations carry over.

Before / after

Same stub data on a virtual display: four desktop files in the box, one of them (Zutty) already exported.

Before - pills stretched to the row height, separator between them, fixed widths:

After - a uniform list, one row per app:

Expanded - the app's actions as rows inside:

Activating Add To Menu on Text Editor - the host now has second-org.gnome.TextEditor.desktop and the same row now reads Remove From Menu:

…and activating it again - the file is gone and the row is back to Add To Menu:

(The faint dashes above "Exported Binaries" in the expanded shots are an artifact of the cairo software renderer the virtual display uses, not part of the change.)

Testing

• cargo test: 6 passed (the new one pins exported_desktop_file_name to distrobox-export's naming).
• End to end with a stub distrobox whose distrobox-export --app creates/deletes the host desktop file: the file list on disk and the row title agree after each activation, as in the captures above.
• The Flatpak branch of the host read (ls via flatpak-spawn) is the existing get_host_desktop_files, unchanged; I only tested the native path.

One thing I did not add: if the export command fails (the file never appears), the row stays on Add To Menu and no confirmation is written - which is at least truthful, but there is no error message either. Happy to add one if you'd like it in this PR.