[PATCH] Re: [PATCH] Re: KMix

[Frans Englich]

On Wednesday 17 December 2003 02:11, Christian Esken wrote:
> On Sunday 14 December 2003 02:25, Frans Englich wrote:
> > But. My patch increases the likelyness for getting blasted by so little
> > it actually is ignorable. If you have a miss-behaving app, a
> > non-normalized sound file or whatever the reason to increase the volume
> > to a abnormal level AND then *immediately* exits your KDE session _with_
> > logout sound
>
> No need for the "logout sound". I am talking about the (restored) volume on
> next boot.

I don't get it. The logout sound will be played with the same level as the 
login sound with "my/current behavior - right? For example:
1) You raise the volume extremely much to listen to an Mp3 which sounds just 
fine.
2) You log out  - blasted by the logout sound.

(Ignoring any possible happening between 1), 2) and interim 1) )

>
> > disabled you will get blasted. Does it sound likely? No, because it is
> > *not* likely - one out of all the total nnumber of times you play a
> > sound.
>
> So I can argue, that backups are nonsense, because most likely you will not
> need them, right? And that fire polices are stupid, because the likeliness
> of my home burning down is extremely low?

It's not the same thing, read on.

>
> > Considering how often it anyway will happen(with or without new behavior)
> > the user is and must be hardened so who cares? ;-)
>
> I do care. If it happens one time that a speaker gets blasted due to this
> behaviour, this is too much.

+-1 blasted speakers/ears does matter, I think so too, but "my" behavior does 
increase the likelyness so little it isn't noticeble in the overall picture. 
You will get blasted anyway in the session by any other sound that gets 
played during or after the non-normalized mp3 or whatever, in either case the 
logout sound blasts you(please correct). I and Aaron have pointed this out in 
the previous KMix thread a couple of days ago.

My patch did not touch the issue of getting blasted - that issue still remains 
and is up to the user(unfortunately). That could be addressed in some other 
funky way; an intelligent peak limiter; establishing a de-facto standard so 
there's an coherency in MM-apps or whatever.
What my patch did was addressing GUI/program behavior issues with the design.

>
> > > I think the ideal way is that you configure some acceptable values,
> > > save it and they are always restored.
> >
> > In my opinion, we agree(referring to my save-on-quit suggestion). It has
> > its roots in the observation that the user fails to save its changes by
> > believing they're already saved. And the new behavior makes the GUI
> > behave as the user expects.
>
> It does not look like we agree. The comment above yours talks of explicitly
> saving volumes. 

This is a matter of how the user percept "to save". Andras knows (for some 
reason) that he has to explicitly save but both KMix behaviors actually do 
the same - lets the user configure, then saves the values and then it is 
always restored. 

> And I also would not like auto-save.

What a relief you said so because that have totally passed me by.

>
> Additionaly, besides the "blasting" problem, I also believe auto-save is
> counter-productive, because "random" values will be saved. Examples:
>
> (a) When I look a DVD video late at night and don't want to wake my
> neighbours, I will turn the volume down. Then I go to bed. Why should this
> low volume profile be saved? Most likely I will not need low volume on next
> boot.
>
> (b) I listen to some quiet classical music and turn the volume up. Then I
> quit the desktop and leave my home. Why should this high volume profile be
> saved?
>
> (c) I listen to some MP3-File: MP3-Files tend to vary greatly in volume, so
> why should such a "random" volume be saved?
>
> (d) A video player (or any other MM application) that has its own mixer
> built in is running while I shut down the Desktop. When quiting the
> desktop, I do not want this volume to be saved.

Again, this assumes that the problem of inconvenient volume is first 
encountered when logging out. It further assumes that misbehaving sound 
levels(for whatever reason) is common, even the majority of all sounds played 
since that's what KMix's behavior should follow.
The reason why this change is productive is that the current behavior is bad 
from a UI point. The current behavior is hidden to the user - it does "magic" 
things which the user does not know about. My change makes the user 
understand what's going, makes sure that the user have control over KMix and 
makes sure it does things the user expects and had in mind(this is further 
detailed discussed in the previous thread). 
In case this behavior is not of interest for whatever reason it will first of 
all have to be explained for me, because I (still?) don't get it. Second, 
something has to be done about the GUI - prompt the user or in some other way 
make it obvious an explicit save has to be done.

Further, not trying to rush things though, but in case the previous commit 
does not get reverted the attached patch is a obvious follow up to previous 
change - a cleanup in kcm_kmix. Further refactoring and cleanups can be done 
in parts of kmix AFAICT but it will have to wait until the code freeze. I 
have a question regarding my patch though - is the desktop entry 
"ServiceTypes=Daemon" valid for kcmmodules or any others? ksycoca whines when 
run and kcm's work fine without it(my patch remove it from kmix's). Could 
someone clarify? (feel free to review and comment the patch :)

Cheers!

			Frans

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kmix_ui_cleanup.diff
Type: text/x-diff
Size: 5395 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20031218/8b711f4f/attachment.diff>