Add config option to show Projects/Services panels outside of a docker-compose directory

[lucas-giraldelli]

Summary

Since v0.25.2 (PR #776), the Projects and Services panels are hidden when lazydocker is not launched from a directory containing a docker-compose.yml file. While I understand the intent behind this change, it removed a workflow: launching lazydocker from anywhere and having full visibility into all running compose projects.

Problem

Before v0.25.2, running lazydocker from any directory would show all running compose projects in the [1] Projects and [2] Services panels (detected via docker compose ls). This was particularly useful when:

• Launching via a taskbar/status bar button (e.g. Waybar)
• Working in a directory unrelated to any compose project
• Managing multiple compose projects across different locations

Now, launching outside a compose directory drops straight to [3] Containers with no Projects or Services panels at all.

Proposed Solution

Add a config option to force project view regardless of the current directory:

gui:
  forceProjectView: true

Proposed Changes

pkg/config/app_config.go

Add ForceProjectView field to GuiConfig struct:

ForceProjectView bool `yaml:"forceProjectView"`

pkg/commands/docker.go

Find the block that sets InDockerComposeProject = false on error and wrap it with the config check:

// Before:
if err != nil {
    dockerCommand.InDockerComposeProject = false
    log.Warn(err.Error())
}

// After:
if err != nil && !config.UserConfig.Gui.ForceProjectView {
    dockerCommand.InDockerComposeProject = false
    log.Warn(err.Error())
}

Users can then add to ~/.config/lazydocker/config.yml:

gui:
  forceProjectView: true

This would set InDockerComposeProject = true regardless of whether a compose file is found in the current directory, restoring the pre-v0.25.2 behavior for users who want it.

Impact

• No breaking change, default behavior stays the same
• Users who want the old behavior can opt in with one line of config
• Covers use cases like status bar launchers, global keybindings, and multi-project workflows