[Mouad-Scriptz-0]

Problem

With ask_to_move = false in ~/.config/appimagelauncher.cfg, AppImageLauncher never shows the integration dialog. The AppImage is silently executed instead, without being integrated:

// src/ui/main.cpp
// if the user opted out of the "ask move" thing, we can just run the AppImage
if (config->contains("AppImageLauncher/ask_to_move") && !config->value("AppImageLauncher/ask_to_move").toBool()) {
    return runAppImage(pathToAppImage, appImageArgv.size(), appImageArgv.data());
}

From the user's perspective this looks like AppImageLauncher is completely broken: "the prompt doesn't show up when I double-click a .AppImage file" is exactly how it was reported to me on a Fedora 44/GNOME machine running the 3.0.0-beta full package with ask_to_move = false. Since the dialog is skipped without any visible feedback, there is no obvious hint that a config option is responsible.

Why this is a bug, not intended behavior

The option is presented to users as narrowly controlling the relocation question, nothing else:

• src/ui/settings_dialog.ui — group box "Launcher Dialog", checkbox text: "Ask whether to move AppImage files into the applications directory"
• src/ui/first-run.ui — checkbox text: "Ask me whether to move new AppImages into a central location"

A user who unchecks a box inside the "Launcher Dialog" settings section, labeled as being about moving files, does not expect the launcher dialog itself — AppImageLauncher's core feature — to disappear entirely, along with all desktop integration. Neither UI hints that unchecking it disables integration.

Proposed behavior

ask_to_move	Launcher dialog	On "Integrate and run"
unset / true (unchanged)	shown	AppImage moved into integration destination, integrated, run
false	shown	AppImage integrated in place (no move), run

In-place integration reuses the existing mechanism: integrateAppImage() already skips the move when source and target paths are identical (the same path the CLI reports as "AppImage already in integration directory"), and it is what appimagelauncherd effectively does for AppImages in watched directories, which are registered at their current location today.

Changes

• src/ui/main.cpp
  • removed the early-return that skipped the dialog when ask_to_move = false
  • when the user opted out of moving, the integration target is the AppImage's current path, so integrateAppImage() integrates in place
  • the "already integrated, but not in the integration destination directory — move it?" prompt is suppressed in that case, as there is intentionally nothing to move
• src/ui/integration_dialog.{h,cpp}
  • new integrateInPlace constructor flag; the dialog then shows a message that does not claim the AppImage will be moved

Notes for reviewers

• I went with integrate in place for ask_to_move = false because it matches the checkbox wording ("move ... into the applications directory" — opting out of the move, not of integration) and the daemon's existing behavior. If the intended semantics were rather "move without asking", the pathToIntegratedAppImage branch is the single place to flip — feedback welcome.
• The default case (key absent or true) is byte-for-byte the previous behavior.
• Verified on a Fedora 44 (GNOME 49/Nautilus 50) machine against the released 3.0.0-beta-2 build that (a) ask_to_move = false silently skips the dialog (bug), (b) the dialog renders correctly once the early-return is gone, and (c) in-place registration works (the daemon produces such integrations). This patch itself is not compile-tested locally; relying on CI plus a manual test pass before marking ready.

Follow-ups (out of scope here)

• The settings dialog could clarify that "Integrate and run" moves files into the destination directory when the option is enabled.

[Mouad-Scriptz-0]

looks good to me