| Summary: | Dolphin cant enter mobile UI unless $HOME is unset | ||
|---|---|---|---|
| Product: | [Applications] dolphin | Reporter: | quackdoctech |
| Component: | general | Assignee: | Dolphin Bug Assignee <dolphin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | dolphin-bugs-null, felixernst, meven |
| Priority: | NOR | ||
| Version First Reported In: | 25.04.2 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
quackdoctech
2025-06-20 19:02:59 UTC
Can confirm. Now that's weird. I wonder what causes this. PLASMA_PLATFORM=phone dolphin does work at least partly: the toolbar is changed. mkdir test XDG_CONFIG_HOME=test XDG_DATA_HOME=test XDG_STATE_HOME=test PLASMA_PLATFORM=phone dolphin Does work Oh, maybe the issue is that it uses some of the desktop settings and some of the mobile settings. That's somewhat of a known issue. For simplicity, some of the phone UI is only initialised if Dolphin is run the very first time (https://invent.kde.org/system/dolphin/-/blob/a4533d653febc89c8970d88c3a4ebf41f9e55658/src/dolphinmainwindow.cpp#L207). So dynamically switching between a phone and a desktop UI does not work perfectly. The reason it works when changing HOME is probably because it cannot load the leftover desktop settings then. If people are interested in dynamically switching between a phone and a desktop UI (perhaps because they have a tablet that can also function as a laptop), that would need a different implementation. When I implemented the phone UI, this wasn't really a main focus of mine. (In reply to Felix Ernst from comment #3) > If people are interested in dynamically switching between a phone and a desktop UI (perhaps because they have a tablet that can also function as a laptop), that would need a different implementation. When I implemented the phone UI, this wasn't really a main focus of mine. This is indeed the primary use case I an concerned with and would like to use. (In reply to quackdoctech from comment #4) > (In reply to Felix Ernst from comment #3) > > If people are interested in dynamically switching between a phone and a desktop UI (perhaps because they have a tablet that can also function as a laptop), that would need a different implementation. When I implemented the phone UI, this wasn't really a main focus of mine. > > This is indeed the primary use case I an concerned with and would like to > use. Alright. Yes, the issue is that some settings and state information is restored between restarts no matter if a phone UI or a desktop UI is opened. For the most part this is a good thing, because it means that many settings which are supposed to be identical for both are actually kept in sync (or rather only saved once for both). For your use case and this bug report, one would need to figure out which of the settings should not be kept identical between the two and then load them separately. This would include stuff like toggling the panels, whether the toolbar is at the top or bottom, whether the toolbar shows text next to the icons, and maybe other things. |