Bug 514942

Summary:	The windows position is reset to (0,0) in the state file in 9.0.0.
Product:	[Applications] digikam	Reporter:	pthfdr
Component:	Bundle-AppImage	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	REPORTED ---
Severity:	normal	CC:	caulier.gilles, metzpinguin
Priority:	NOR
Version First Reported In:	9.0.0
Target Milestone:	---
Platform:	Appimage
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description pthfdr 2026-01-22 17:54:24 UTC

SUMMARY
The windows position is reset to (0,0) in the state file in 9.0.0.

STEPS TO REPRODUCE
1. Launch Digikam 9.0.0 from AppImage (either as-is, or extracted).
2. The main window behaves normally, that I can move or resize. 
3. Exit the application. It creates a `digikamstaterc` file in the XDG state folder, where the XPosition and YPosition of all the sections are set to 0.
4. Launch Digikam again.

OBSERVED RESULT
The main window is moved to the top-left corner of the screen, with the title bar hidden above the screen, so I am unable to move the window by dragging the title bar.
Manually changing the positions in the state file does not work. Removing the state file will make the window display normally (before it creates the state file again).

EXPECTED RESULT
The window is positioned at the same place before exitting.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian Sid.
KDE Plasma Version: None, I am using `ctwm` instead of a DE.
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.1

ADDITIONAL INFORMATION
The issue does not happen in 8.8.0; it saves and restores the position normally.
When launching 9.0.0 with a 8.8.0 state file, it is ignored and the window is set to the top-left corner.

Comment 1 Maik Qualmann 2026-01-22 19:43:16 UTC

The digikamstaterc file is not written directly by us; the KDE framework handles this in the background.

Note that under Wayland, it's not possible for us to read or set the window position. This is a silly security feature that the Wayland developers think is cool. Under Wayland, we always get 0,0 as the position, regardless of where the user has moved the window.

It's the window manager's job to center the application window on startup, for example, and it should have the necessary permissions to do so. Incidentally, the AppImage works perfectly fine under KWin with Wayland.

Maik

Comment 2 Maik Qualmann 2026-01-22 19:59:12 UTC

Take a look at this KDE discussion. As I said, the Wayland Compositor must have this functionality.

https://discuss.kde.org/t/wayland-remembering-window-position-size-and-location/27775/27

Use a compatible Wayland compositor.

Maik

Comment 3 pthfdr 2026-01-22 23:29:34 UTC

(In reply to Maik Qualmann from comment #1)
> The digikamstaterc file is not written directly by us; the KDE framework
> handles this in the background.
> 
> Note that under Wayland, it's not possible for us to read or set the window
> position. This is a silly security feature that the Wayland developers think
> is cool. Under Wayland, we always get 0,0 as the position, regardless of
> where the user has moved the window.
> 
> It's the window manager's job to center the application window on startup,
> for example, and it should have the necessary permissions to do so.
> Incidentally, the AppImage works perfectly fine under KWin with Wayland.
> 
> Maik

I am not running it under Wayland. I am running it in plain X11 with a minimal WM (ctwm).

Comment 4 Maik Qualmann 2026-01-23 07:20:10 UTC

Here, the window position is saved in the digicamstaterc file using the digiKam AppImage.

Maik

Comment 5 caulier.gilles 2026-01-23 07:42:28 UTC

I confirm that it work also perfectly here under Plasma desktop.

Comment 6 pthfdr 2026-01-23 15:10:01 UTC

(In reply to Maik Qualmann from comment #4)
> Here, the window position is saved in the digicamstaterc file using the
> digiKam AppImage.
> 
> Maik

Well, the position is saved in i3wm as well. I guess that version 9.0 used some new API that breaks compatibility with old/minimal WMs.
Maybe Digikam can detect such environments (where it can't read the location) and do not attempt to create the state file to save/restore the window location (as the window works normally if the state file is deleted). Maybe add an option to disable it manually.
I currently add a command to detele the state file in the AppRun script as a workaround, but I still hope that the detection can be added.
Thanks.