Bug 121451 - KMix panel applet shows broken duplicates of bass, treble sliders
Summary: KMix panel applet shows broken duplicates of bass, treble sliders
Status: RESOLVED FIXED
Alias: None
Product: kmix
Classification: Applications
Component: Obsolete component. Do NOT use!!! (ex: KMix Panel Applet). (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Christian Esken
URL:
Keywords:
: 121827 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-02-06 03:40 UTC by Andrew 'ashridah' Pilley
Modified: 2006-11-24 21:26 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Image of the sliders that are duplicated (2nd through 7th from left of applet) (102.85 KB, image/png)
2006-02-06 03:43 UTC, Andrew 'ashridah' Pilley
Details
region screen cap of the problem (2.21 KB, image/png)
2006-02-06 04:06 UTC, Niko Mirthes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew 'ashridah' Pilley 2006-02-06 03:40:52 UTC
Version:            (using KDE KDE 3.5.1)
Installed from:    Debian testing/unstable Packages
OS:                Linux

When I add the mixer applet, the mixer has duplicate entries for some controls.

The bass, treble, and "3D Control Sigmatel" sliders have two sliders side by side.

These are not split channels, and changing the left slider makes the right slider change to match it. Changing the right slider has no effect on the left slider (or the actual mixer channel's effect on audio).

If I hide one of the two controls, the removed one returns if i logout and log back in. This occurs even with a completely new user (ie, no existing config file)

I'll attach an image showing the controls in question, but if i find I can't, http://yallara.cs.rmit.edu.au/~alpilley/images/mixer.png shows them (2nd through 7th sliders from the left)

I'm using alsa, and I have an SB Audigy. Discussions in #kde on freenode indicate that it appears to be sound-card-brand specific (another SB owner confirms the bug on a different distro)
The application 'kmix' and alsa's mixers do not show the same problem.
Comment 1 Andrew 'ashridah' Pilley 2006-02-06 03:43:15 UTC
Created attachment 14568 [details]
Image of the sliders that are duplicated (2nd through 7th from left of applet)
Comment 2 Niko Mirthes 2006-02-06 04:05:12 UTC
I'm seeing exactly the same issue here using alsa and an sblive! value. http://straw.sh.nu/kde/KDE-panel-mixer-bug-snap1.png taken after attempting to
reproduce the problem when mentioned in #kde on freenode.
Comment 3 Niko Mirthes 2006-02-06 04:06:51 UTC
Created attachment 14569 [details]
region screen cap of the problem
Comment 4 Niko Mirthes 2006-02-06 04:07:50 UTC
Oops. I should mention I'm using Fedora Core 4, KDE 3.5.1.
Comment 5 Christian Esken 2006-02-07 19:40:14 UTC
Soundcards like "SB Live" and "SB Audigy" have separate playback and recording volumes on some controls. So those extra controls are simply the recording controls. 
So this is a feature, not a bug. There is nothing to fix here.
In the KMix main window those controls show up on different tabs. In the Panel Applet they are not distinguishable. A possible solution would be to add this information to the recording controls, e.g. "Record: PCM" or "PCM (Record)".

Comments are appreciated.
Comment 6 Christian Esken 2006-02-07 19:41:45 UTC
One extra comment from me: The feature to show both "playback" and "recording" controls is new in KDE3.5.1.
Comment 7 Andrew 'ashridah' Pilley 2006-02-08 00:31:01 UTC
If that's the case, why do these sliders act the way they do?

I fail to see why changing the left-hand of the pair changes the right-hand version, but not vice-versa. It stands to reason that they should be completely independent, shouldn't it?

They need independent names, if only internally, so that when I hide one, the other doesn't vanish if I logout and log back in.

Pity we can't have a different colour for input sliders atm, would have made it far less confusing :)

Thanks for clearing this up a bit tho.
Comment 8 Christian Esken 2006-02-08 20:44:24 UTC
Hiding should already work properly. That would be a bug.
Obviously I haven't read your original bug report correctly. Sorry about that.
I currently don't see what is wrong, so I need somebody with an Audigy and programming knowledge for resolving this issue. This might need some time ...
Comment 9 Andrew 'ashridah' Pilley 2006-02-09 00:08:15 UTC
I've got a copy of kdemultimedia's source here. My c++'s a little rusty compared to my C/java skills, but I'm willing to spend some time with it, particularly if you'll mention the areas that deal with storing and loading the preferences and why the two aren't completely independent.

I'll dig around and see if I can find references on debugging panel applets in a useful way in the mean time.
Comment 10 Andrew 'ashridah' Pilley 2006-02-09 00:29:52 UTC
"and why the two aren't completely independent. " i meant the two channels, not the storing/loading of preferences :)
Comment 11 Christian Esken 2006-02-21 21:58:38 UTC
*** Bug 121827 has been marked as a duplicate of this bug. ***
Comment 12 Christian Esken 2006-02-24 00:57:25 UTC
SVN commit 512943 by esken:

Fix bug 121451 : Playback and Capture Sliders now save their GUI
properties indepencently (thus you can for example show the playback and
hide the capture controls).
The bugfix contains a "compatibilty loader", that loads the old
properties if new ".Capture" properties are not found.

This fix needs confirmation from testers.

CCBUGS: 121451


 M  +36 -0     kmixtoolbox.cpp  


--- branches/KDE/3.5/kdemultimedia/kmix/kmixtoolbox.cpp #512942:512943
@@ -98,6 +98,36 @@
 	     */
             // !!! check
  	    devgrp.sprintf( "%s.%s.Dev%s", viewPrefix.ascii(), grp.ascii(), mdw->mixDevice()->getPK().ascii() );
+
+            /** 
+               Find an appropriate group name for capture GUI elements.
+               We try  devgrp.append(".Capture")
+               If it doesn't exist, we fall back to devgrp.
+               This is the second compatibility measure, and was introduced for KDE3.5.2.
+              */
+            if ( mdw->mixDevice()->getVolume().isCapture() ) {
+               /* A "capture" GUI element must save its own state. Otherwise playback and capture
+                  properties would be written twice under the same name. This would mean, when
+                 restoring, both would get the same value. This is bad, because hidden sliders will re-appear
+                  after restart of KMix, and a lot of other nasty GUI-related problems.
+                  So we add ".Capture" to the group name.
+                  See bug 121451 "KMix panel applet shows broken duplicates of bass, treble sliders"
+
+                  The name should have been set in the backend class, but we REALLY cannot do this for KDE3.5.x. !!
+                  This issue will be fixed in KDE4 by the great config cleanup.
+                */
+               QString devgrpTmp(devgrp);
+               devgrpTmp.append(".Capture");
+               if ( config->hasGroup(devgrpTmp) ) {
+                  // Group for capture device exists => take over the name
+                  devgrp = devgrpTmp;
+               }
+               else {
+                  // do nothing => keep old name (devgrp).
+                  // Saving wil autmatically create the group 'devgrp.append(".Capture")'
+                  kdDebug(67100) << "KMixToolBox::loadConfig() capture fallback activcated. Fallback group is " << devgrp << endl;
+               }
+            } // isCapture()
 	    if ( ! config->hasGroup(devgrp) ) {
 		// fall back to old-Style configuration (KMix2.1 and earlier)
 		devgrp.sprintf( "%s.%s.Dev%i", viewPrefix.ascii(), grp.ascii(), n );
@@ -148,6 +178,12 @@
             }
 	    devgrp.sprintf( "%s.%s.Dev%s", viewPrefix.ascii(), grp.ascii(), mdw->mixDevice()->getPK().ascii() );
 	    //devgrp.sprintf( "%s.%s.Dev%i", viewPrefix.ascii(), grp.ascii(), n );
+
+            if ( mdw->mixDevice()->getVolume().isCapture() ) {
+               /* see loadConfig() for the rationale of having an own name for capture devices. */
+               devgrp.append(".Capture");
+            } // isCapture()
+
 	    config->setGroup( devgrp );
 
 	    if ( qmdw->inherits("MixDeviceWidget") ) { // -<- in reality it is only in MDWSlider
Comment 13 Andrew 'ashridah' Pilley 2006-02-24 06:49:24 UTC
Hope this attaches to the bug properly.

I just applied that patch to a copy of KDE3.5.1's kdemultimedia source
that i have here, compiled it, and tested it.

Looks good. The recording and playback channels save their state in an
independent way.
My only concern is that the tooltips for both in the applet when
hovering over the slider (or in the "Channels" dialog from the right
click menu on the panel applet) still has just "Bass" and "Treble"

Shouldn't it display "Capture:Bass" or something for the capture
channel?

Andrew

On Thu, 2006-02-23 at 23:57 +0000, Christian Esken wrote:
[bugs.kde.org quoted mail]
Comment 14 Christian Esken 2006-02-25 00:03:58 UTC
Thanks a lot for the very quick testing, Andrew. :-)

The tooltips are problematic, I know that. But it is not trivial, because there are a lot of issues to be considered:

1) I must also think about the majority of people who don't have both record and playback controls. Those will suddenly see "Capture:PCM", and wonder where their playback slider has gone.
2) "Capture:Capture" will show up, which might me very confusing.
3) I am not sure what imact this has for other backends like OSS, Solaris or IRIX. There are  no possibilities to test this until KDE3.5.2.
4) Tooltips would then probably be dependent on whether they are shown on the PanelApplet or on the MainWindow (showing an extra "Capture" on the input tab would be superfluous).
5) User visible changes should not be done for KDE3.5.2, unless this is a *severe* usability impact (yes, this could actually be argued).

There is no decision yet, but I am very reluctant to do this in a bugfix release. There are pros an´d cons, so I'll keep this bug report open during pondering.
Comment 15 Andrew 'ashridah' Pilley 2006-02-25 00:37:02 UTC
Yeah, fair enough, as a quick fix it definently does the job. 

If it turns out that modifying the tooltip doesn't have much impact,
it'd be nice for 3.5.2, but if it messes up kmix proper, etc, it'll
survive as it is, it's only a fairly minor usability bug, all things
considered.

Now to just get debian to roll it into a patch to kdemultimedia if they
release a new build before 3.5.2 :)

Thanks
Andrew

On Fri, 2006-02-24 at 23:04 +0000, Christian Esken wrote:
Comment 16 Christian Esken 2006-11-24 21:26:17 UTC
I'll rather close this bug report as the original problem is actually solved. 

Just for the usability issues reported in comment 13 and discussed by my own self in comment 14, it is not worth to keep this bug report open.
I'll happily discuss this in personal mail if somebody is interested. "KDE Usability" might then want to take a look into this, too.