Bug 944766

This also happens after a normal TW upgrade.

(In reply to Jon Grossart from comment #0)
> The addition of Plasma 5.4 introduced plasma5-pa as the new audio control.
> However, the KDE patterns install kmix (what was kmix5).

IF we're talking about KF5-based KMix, it should not autostart (plasma5-pa installs kconf script which changes kmixrc), but that is only valid for KF5 based one due to different config locations.

(In reply to Hrvoje Senjan from comment #2)
> IF we're talking about KF5-based KMix,

The only kmix available in Tumbleweed is the KF5 based one... ;-)

> it should not autostart (plasma5-pa
> installs kconf script which changes kmixrc)

It does, yes.

But something seems to not be working correctly:

On my 13.2 system (with KDE4 and Plasma 5.4.1 installed), kmix5 still starts on login to Plasma5, even though there's "AutoStart=false" in ~/.config/kmixrc, as I just noticed.

And I did uninstall kmix4 now and even removed its config file to be sure that's not interfering...

Maybe that's a bug in the handling of the "X-KDE-autostart-condition" key?

(In reply to Wolfgang Bauer from comment #3)
> Maybe that's a bug in the handling of the "X-KDE-autostart-condition" key?

Ok, forget that.
In my case, KMix5 was actually restarted by the session management, because it was running at logout time.
After quitting it before logging out, it isn't restarted any more on login.
(and setting AutoStart=true in the config file makes it autostart again, so that part is working correctly)

Still a bug I'd say.

And that's probably also what happened in the Tumbleweed upgrade case.

No idea about a fresh installation though, have to try that first.
Maybe KMix is autostarted on first login *before* the kconfig update script disables it?
As it is running already, it will then also be restored by the session management on subsequent logins, unless the user quits it manually.

*** Bug 951268 has been marked as a duplicate of this bug. ***

(In reply to Wolfgang Bauer from comment #5)
> *** Bug 951268 has been marked as a duplicate of this bug. ***

Both applications (kmix and the plasma applet) are still installed and started by default in a fresh Tumbleweed installation.

I agree with Jon Grossart's initial assessment that kmix should be removed from the patterns and hence not installed by default.

I see 2 applets on fresh 42.1 RC1 installation.

kmix has been removed from the installation patterns for Tumbleweed and Leap already, the new patterns are not yet in the repos though.

But this will only help on fresh installations.
People upgrading, that already have kmix installed (even the KDE4 version), will  still get two volume controls in the system tray.

I'd suggest that we could add a "AutoStart=false" to the shipped kmixrc in plasma5-openSUSE, that would at least take care of the case when upgrading from KDE4 (e.g. openSUSE 13.2) to Plasma5 (e.g. Leap).

The only problem I see with this is that people upgrading from e.g. 13.2 to Leap that have PulseAudio disabled, will suddenly have *no* working volume control until they start kmix manually.

People already having it running in Plasma5 would of course still end up with two after an upgrade, because it will be restarted by the session management (if not disabled).
Not much we can do about that I suppose.

i'm not super-convinced but looks like this would be the best way to go

(In reply to Hrvoje Senjan from comment #9)
> i'm not super-convinced but looks like this would be the best way to go

Yeah, I'm not super-convinced either, but well.

I tried playing around with the plasma5-pa update script killing an existing kmix instance, but this didn't work either.

So I guess this is the best way to go and covers most use cases (for Leap at least). And I have to admit that I prefer kmix more and even tend to disable pulseaudio for reasons I don't want to go in here, in my case they are technical though... ;-)

And then there's this upstream commit which I hoped would help as well after noticing it:
https://quickgit.kde.org/?p=plasma-pa.git&a=commit&h=2351fbb7c61b807550d627915ac0bbfc1ec0dfa0

Unfortunately, it only seems to help for a *fresh* user account.
For a user that already used KDE4 it doesn't, kmix still gets autostarted when you first login to Plasma5 (unless you login to KDE4 once again before, after installing plasma5-pa, but that's of course impossible when upgrading from 13.2 to Leap e.g...).

It is the same, both are active, in Leap 42.1 which I installed only a few days ago from the iso image.

(In reply to Freek de Kruijf from comment #12)
> It is the same, both are active, in Leap 42.1 which I installed only a few
> days ago from the iso image.

And which iso image?

The Beta1 image is still Beta1, the RC1 ISO is still RC1. They are not updated.

Anyway, you can be pretty sure that this will be "fixed" in the final release because of two reasons:
- kmix has been removed from the installation patterns
- kmix's autostart has been disabled by default, so even if it is installed, it should not be started (this only went in 7 hours ago, so is not on any ISO yet)

(In reply to Wolfgang Bauer from comment #13)
> And which iso image?

openSUSE-Leap-42.1-DVD-x86_64-Build0235-Media.iso


> Anyway, you can be pretty sure that this will be "fixed" in the final
> release because of two reasons:
> - kmix has been removed from the installation patterns
> - kmix's autostart has been disabled by default, so even if it is installed,
> it should not be started (this only went in 7 hours ago, so is not on any
> ISO yet)

OK.

(In reply to Freek de Kruijf from comment #14)
> (In reply to Wolfgang Bauer from comment #13)
> > And which iso image?
> 
> openSUSE-Leap-42.1-DVD-x86_64-Build0235-Media.iso

That is RC1 indeed.
The pattern change was done later, so it's no surprise the problem was still there.

Wolfgang, we're now hitting https://bugs.kde.org/show_bug.cgi?id=340691
(try to enable kmix autostart via GUI)

(In reply to Hrvoje Senjan from comment #16)
> Wolfgang, we're now hitting https://bugs.kde.org/show_bug.cgi?id=340691
> (try to enable kmix autostart via GUI)

Oh.
TBH, I forgot about that issue.

Are you sure that applies to kmix too?

Well, kmix should be restored by the session management anyway as mentioned earlier (unless disabled), so is this really a problem?

(In reply to Wolfgang Bauer from comment #17)
> TBH, I forgot about that issue.
> 
> Are you sure that applies to kmix too?
yes. i've noticed myself after upgrading branding packages =)

> Well, kmix should be restored by the session management anyway as mentioned
> earlier (unless disabled), so is this really a problem?

yes/no - for alsa users, soon-ish for TW (once Plasma 5.5 hits it - it finally defaults to empty session), for those that rather use kmix instead of the plasma applet. for others - no =)

(In reply to Hrvoje Senjan from comment #18)
> (In reply to Wolfgang Bauer from comment #17)
> > TBH, I forgot about that issue.
> > 
> > Are you sure that applies to kmix too?
> yes. i've noticed myself after upgrading branding packages =)

Ok.
Sorry for pushing this in that late in the game (for Leap).

I have to admit I haven't tested enabling autostart manually and see if it works. But time was also not on my/our side for this...

> > Well, kmix should be restored by the session management anyway as mentioned
> > earlier (unless disabled), so is this really a problem?
> 
> yes/no - for alsa users, soon-ish for TW (once Plasma 5.5 hits it - it
> finally defaults to empty session), for those that rather use kmix instead
> of the plasma applet. for others - no =)

Yeah, it's only a problem for alsa users (like me ;-) ) anyway, which is not the default.
But AFAIK they are going to introduce that "restore applications" switch on the logout screen in Plasma 5.5 too, are they not?

At least we (I? ;-) ) have some time to think about this, Plasma 5.5 is going to be released in December...

Probably some good idea would be to fix that upstream bug anyway, we still have the same problem with Firefox, don't we?

So all in all, this is actually no problem for Leap 42.1 AFAICT.

FWIW, I'm fine with dropping that kmixrc again, it doesn't help much in Tumbleweed anyway I suppose.

But do you actually see a problem for Leap?

less 'buggy' default > buggier 'corner' cases

i'm fine with leaving this for Leap. for TW, let's see how much reports there will be.

(In reply to Hrvoje Senjan from comment #20)
> less 'buggy' default > buggier 'corner' cases

Of course, and I fully agree with you there.
My change wasn't meant as a complete solution.

Unfornately, as you might know, even upstream doesn't have a solution there, they just "hope that downstream will sort it out by not installing both at the same time".
I don't find find that bug report at the moment, but it was about the same problem.

That's the reason why I pushed, or even suggested, it in the first place, as it did seem to improve things for most users. In particular if we think about the upgrade from KDE4 to Plasma5 in Leap.

> i'm fine with leaving this for Leap. for TW, let's see how much reports
> there will be.

Yeah.
The upstream patch mentioned seems to improve things for a fresh installation at least.

For upgrades, there's no perfect solution anyway IMHO (or at least none that I can think of).
It doesn't matter what we do trying to solve this, there will be people ending up with both or none, I suppose...

Hm.
Sorry, Hrvoje, but I cannot reproduce that problem here.
With the /etc/xdg/kmixrc in place, I can still enable AutoStart in kmix's settings. The setting is remembered, and kmix is indeed autostarted on login also if I disable session management.

And I did try on a fresh Tumbleweed installation too (after updating plasma5-workspace-branding-openSUSE of course, the one with the change is not in the repo yet).

OK, maybe i tested something wrong, or was a local issue. In any case, doesn't change the fact this is way to go. I believe we can close the report now. AFAICS, there's nothing more we can do. Removing kmix from distribution is out of the question, unless it gets axed upstream also.