:thumbsup:

For reference, the issue was noted in the meeting on 06/24/2024 as relating to
https://src.fedoraproject.org/rpms/plasma-workspace/blob/rawhide/f/plasma-workspace.spec#_269

requiring plasmashell brings in plasma-desktop

@aleasto mentioned one way to work around this would be to make plasma-mobile also provide plasmashell

https://src.fedoraproject.org/rpms/plasma-workspace/c/64be0ee91854aec522a1110d40389b5e2c307674

I don't know how KDE looked like 9 years ago, but i think plasmashell used to mean something else than /usr/bin/plasmashell as it does today, which is installed by plasma-workspace itself.

I believe we should retire these virtual plasmashell requires/provides.

What's still weird besides that is that plasma-workspace provides the /usr/share/wayland-sessions/ entry for the Plasma Desktop, instead of being provided by plasma-desktop, so that would still be present (and probably non-working?) on a purely plasma mobile install.

I'd like to discuss this in this weeks meeting.

Right now the plasma mobile experience is very poor due to plasma-workspace pulling so many items in. We've been using plasma-workspace as a dumping ground for dependencies so we don't have to use comps.xml. I'm not opposed to this tactic, but it should be plasma-desktop that is the dumping ground, and not plasma-workspace.

I would like to get this fixed before we start making a spin. Otherwise the spins will look like the normal KDE Desktop, with KDE Mobile tacked on top.

This is also an upstream issue, because plasma-workspace is not a dumping ground from the Fedora side.

If you actually look at plasma-workspace, the only runtime dependency we can actually change is plasmashell. This needs to be satisfied by any plasmashell environment (plasmashell(desktop) and plasmashell(mobile)).

We could probably do something like the following for plasma-workspace:

Requires: plasmashell()
Suggests: plasmashell(desktop)

Add to plasma-desktop the plasmashell() provides, and add to plasma-mobile the plasmashell, plasmashell(), and plasmashell(mobile) provides.

I don't think you are seeing the problem(s).

How about if redhat-menus and
%{_datadir}/wayland-sessions/plasma.desktop
%{_datadir}/xsessions/plasmax11.desktop
get pulled over to plasma-desktop for starters.

There are other things, but I'll have to do some tests.

That's an upstream conversation, though. We're just shipping what's in the sources.

We don't ship plasmax11.desktop at all either.

We don't ship plasmax11.desktop at all either.

Correct. But it is in the spec file with a conditional. So we would either have to move it over, or remove it from the specfile.

Sounds like alot of upstream work. That is fine, just unexpected.
I'm going to have to look into how postmarketOS builds their Plasma Mobile.

We need to take a step back and look at why stuff is broken, because in most cases it's not because of too much being installed and there is another cause

For example the desktop Power Management settings module is provided by powerdevil. It has nothing to do with plasma-desktop being installed.

That said when I run 'PLASMA_PLATFORM=phone:handset plasma-settings' I don't see the desktop one being listed, so it already seem to work as intended

We need to take a step back and look at why stuff is broken, because in most cases it's not because of too much being installed and there is another cause

I agree. I think I'm going to go through each thing, find the root cause, and file upstream bugs.

For example the desktop Power Management settings module is provided by powerdevil. It has nothing to do with plasma-desktop being installed.

powerdevil is required by plasma-workstation.
You also cannot install plasma-workstation without plasma-desktop.
So yes, powerdevil is totally there because of plasma-desktop.

That said when I run 'PLASMA_PLATFORM=phone:handset plasma-settings' I don't see the desktop one being listed, so it already seem to work as intended

Thank you for that.
Turns out we didn't have plasma-settings in our list of packages to install, nor as a dependency of plasma-mobile, so I didn't have it installed. I'm going to have to update the comps.xml file.
After installing it, when I click on "Settings" on the mobile side, that is what comes up. Although it does have two "Engergy" sections. One of them is disabled, or at least nothing comes up when you touch it.
Now I just need to see if it fights with the desktop settings.

powerdevil is required by plasma-workstation.
You also cannot install plasma-workstation without plasma-desktop.
So yes, powerdevil is totally there because of plasma-desktop.

powerdevil is there because it's an integral part of Plasma Mobile. My point is, even if some desktop-only components are present on the file system that still shouldn't be a problem because things are filtered according to the formfactor at runtime.

Can you check that the PLASMA_PLATFORM env variable is actually set?

powerdevil is required by plasma-workstation.
You also cannot install plasma-workstation without plasma-desktop.
So yes, powerdevil is totally there because of plasma-desktop.

powerdevil is there because it's an integral part of Plasma Mobile. My point is, even if some desktop-only components are present on the file system that still shouldn't be a problem because things are filtered according to the formfactor at runtime.

Can you check that the PLASMA_PLATFORM env variable is actually set?

PLASMA_PLATFORM is set when I am logged into Plasma Mobile. It is not set when I am logged into Plasma Desktop on the same machine. I am assuming that is expected. If it isn't, then we do need to fix that.

Now that I am testing, I see that changing the time for dimming and screen turning off are not really fighting, but changing for one, changes for both. Meaning that if I change the times while I'm in mobile, and then go over into Desktop, that the times have been changed there.
My silly mind was thinking they were separate settings, so I would change it in one, go over to the other and see that it was doing what I had set in the other.
So in short. The power things isn't a bug, just bad tests.

I'm still trying to figure out the issues I'm having while waking from sleep. Sometimes it works fine, sometimes I have a real struggle. But that's going to require more testing on my part.

Did we manage to do that?

I don't think so yet. It's still somewhat in progress.