[PATCH] Re: KMix

Frans Englich frans.englich at telia.com
Sun Dec 14 02:46:04 GMT 2003


On Saturday 13 December 2003 09:50, Christian Esken wrote:
> On Sunday 07 December 2003 21:06, Frans Englich wrote:
> > On Sunday 07 December 2003 19:49, Aaron J. Seigo wrote:
> > > On Saturday 06 December 2003 12:25, Frans Englich wrote:
> > > just saving on Quit is probably good enough... Restore should probably
> > > remain, so you can play with the volumes safely with a way to
> > > backtrack; and if there's a Restore and Save should also probably be
> > > there...
> >
> > Yes, that's weights back a little to more advanced users. But otoh, it
> > introduces an inconsistency compared to other situations when something
> > is changed be it settings or a document - if it's altered the user can
> > choose to manually save(by the save action) otherwise the use will be
> > prompted
>
> No: settings and documents are different things. KDE HIG says, the

Yes, there's a difference between "document options" and 
"configuration"(=="settings"?) as per KHIG terminology. But, I didn't write 
"document options" -  I wrote "change a document" which is different - a 
comparition to for example changing a document i KWord.

> configuration has to be stored automatically. KMix does so for all
> *regular* configuration data

According to KHIG configuration data is only saved when the user presses [ok] 
or [apply] which KMix also does. We got the semantics wrong somewhere.

>
> Saving volumes automatically is out-of-question because any application can
> change the volumes - for example video players often manipulate the
> volumes. If by accident any MM application sets high volume on exit, KMix
> would auto-save those volumes: On the next boot KMix will help blasting
> your ears or speakers. This is a NO NO.

I have answered on this issue in Andras Mantia's mail. Feel free to comment 
but I warn you - I can *very* fast pull that slider.

>
> > when he/she tries to exit. With this proposed behavior the user would
> 
> Prompting on exit doesn't work. No regular user exits KMix, he shuts down
> his desktop: so there is no chance for KMix to ask the user a question.

I din't propose prompting the user. My initial mail was not "fully" accepted 
so I continued clarifying my point with the discussion. And it was not 
positive on prompting - notice the paranteses and the quotes. 
But I can agree that it was unclear and cludged.

Can't the user "exit" Kmix? AFAICT this is a case of "calling it quits". 
http://developer.kde.org/documentation/standards/kde/style/basics/terminology.html#quit

Closing the "Mixer Window" is according to KHIG the same as closing the 
application and AFAIK that would be possible by just prompting on exit just 
as session management is done in other cases. But that's hypotethical - we 
don't want prompting.
The "application" and it's tasklet is from the user two different things 
according to KHIG although it's not explicit commented on. I think I agree..

> BTW: I would be terribly be annoyed to be asked such a question by a Mixer
> application. No real harm is done if the volume levels are lost.

I shall explain why why I think it's a real harm. When a user changes 
something, let it be a document, settings in a kcm module or settings in a 
configure dialog the user *have* to select an explicit choice(cancel, ok, 
apply) or get prompted("Do you want to save your changes?" Save/Discard). 
Such cases is often backed up by visual feedback - disabled buttons, captions 
such as "$title [modified]" disabled/enabled kactions(icons). This is 
important since the user knows what he/she's doing and what must be done(save 
the document ie.).
In KMix, when the user changes sound volumes there is no visual feedback as 
it /uses/ to be and no prompting for saving the changes either. It indicates 
that the user doesn't have to care about saving etc. And since he/she 
have(rather had) to it must be bad GUI since the user is not allowed to make 
mistakes or be uncertain(it doesn't prompt). This is further strengthened by 
the direct manipulation - when the user moves the lever it has immediately 
effect.
I find the prompting, feature bloat and inappropriate. Just as you.

> > I want to nuke the menu entries. From my experience as sound engineer you
> > don't use regulators in that way. And in those cases, it often involes
>
> Which way ?!? You cannot mean saving regulators - that is quite common,
> isn't it?

Since when is nuking menu entries equivalent to nuking saving-regulators? You 
do are aware of that I want to make saving mandatory? ;-)

>
> > arithmethics which is possible because the knops/levers/displays are
> > dB-graded, which Kmix is not. KMix is a simple app for simple use, (lets
> > keep
> > it that beautiful) - 99% of the users will regulate according to their
> > ears, a method which is amazingly underrepresented among sound engineers.
>
> I don't understand your argument here: What difference would it be if the
> levels would be dB-graded?!?
> BTW: This is no speciality of KMix: Most *soundcard drivers* do not supply
> dB-graded regulators. More precisely, the soundcard drivers don't give a
> damn about how the regulators are scaled.

We're empasizing on the GUI here. No, a dB-scale makes no sense, it haves no 
technical meaning and that's my point. KMix is used in a simple way - you 
just regulate using your ears as "reviewer" and nothing else. If the levers 
were dB graded or in some other way measured you could do "advanced" stuff 
which would justify "restore to default" -  since then it would be possible 
to do regretable things. In this situation sound leveraging is simple and 
can't get "advanced". I like that(I don't find it "primitive") and have a 
nice side effect - user interfaces can be simple.

FYI, this change is already commited, see:
http://lists.kde.org/?l=kde-cvs&m=107118746109998&w=2
(But doesn't mean it can't be reverted.)

And as I told Andras Mantia(feel free to reply to that post btw):
And if you argue with me I will just turn up the volume and save it with my 
excellent save-on-quit behavior! Thank you very much!


			Frans






More information about the kde-core-devel mailing list