[PATCH] Re: [PATCH] Re: KMix

[Frans Englich]

On Thursday 18 December 2003 22:45, Christian Esken wrote:
> On Thursday 18 December 2003 14:31, Frans Englich wrote:
> > 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.
>
> Frans,
>
> some words at the start. I do appreciate what you are doing. For example I

Thank you! I was a little worried - at one point I thought you were offended 
by my patches - They wasn't that ugly ;-)

> would also like to remove the Control Center Module.

Ah, I encountered some technical problems with such an decision(such as how to 
load the volumes at startup when no *_init - kcm exists) but I'm glad to see 
it is possible to solve. My idea was to nuke kmixctrl, make a convenience 
library for kmix and kcm_kmix and hack the kcm loader to only load the kcm at 
startup but not include it in kcontrol since it has no gui(determined by 
a .desktop directive)... I will folllow this with interest.
For future discussion, I think alot of startup optrimization could be done in 
this area; currently two binaries(and symbol lookups) is done - kcm_kmix and 
kmixctrl which AFAICT could be refactored. Also, considering kmixctrl spends 
mosts of its time sleeping it is a shame it blocks other tasks in the startup 
procedure. It is perhaps inevitable but the startup procedure could be 
adapted to it - starting things asyncronously.. I'm drifting...

>
> Still there are some nagging question: Why NOW? Why directly before the
> KDE3.2 release? The Control Center Module is there in this form for quite
> some time. So why remove it in a hurry?

No one have proposed to remove the kcm_module before 3.2. See below of the 
message you replied.

But, if it could be done in a non obtrusive way I think it would have been 
worth it. That's why I whine - I consider the GUI important and try to push 
changes. Considering their non-intrusive nature it's some gentle polishing 
you can do when we're in half-baked code freeze.
Judging from articles, talking to people, reading various lists it's to me 
quite common complain about KDE's, especially kcontrol's "bloatness" and 
over-design. I really find it a big thing if unnecessary options/GUI can be 
removed or in other way improved. If a kcm module could be removed non 
obtrusive I would find it a big thing. I would push it.

> Why confuse users by "slowly
> degrading" the Mixer Control Center Module. 

It's not slowly degraded. We commited one change, and left the kcm module in a 
half-baked/_degraded_ state. So this is how I see it: Either commit the 
latest patch(roughly) to avoid a slow degradation/inconsistent state or 
revert the previous commit - not something half baked. I don't see how the 
user gets confused by my change(if both of them are applied) - quite the 
opposite.

> Why annoy the translators by
> doing many changes directly before the release?

Ok, I'm not changing strings - just removing them. Is that a string-change or 
imposes a burden on the translators? In case it is a string-change, then 
ofcourse it's a big no no :) ( I apparently have no clue about what I'm 
doing)

> I would rather remove it completely after KDE3.2 in one big blast.

If we can do significant improvements for a release which will circulate in 
almost a year I find it worthwhile. I think it sounds like "No reason to fix 
one bug when we can fix them all post 3.2."

>
> > 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.
>
> Right. I don't argue that 

Sorry, but you do: "No need for the 'logout sound'. I am talking about the 
(restored) volume on next boot."

>  but nobody can save the user from doing stupid things. 

The user has not done stupid things. It's about non-normalized Mp3s, quite 
classical music, watching dvd's late at night trying not to wake the 
neighbors. It is situations the user can't avoid - and they were highlighted 
and brought to discussion by you. 

> If I format my hard disk with important data, I have done something
> stupid. If someone insists on pulling all volumes to maximum and then
> explicitely save it, I can't help him.
>
> What I do not want is to set the volume to some insane level, if the user
> has no control over it. 

I'm not following. The user has control and that insane level is not avoidable 
- it is afterall the user who have deliberately raised the volume for that 
classical tune.

> The problem is, that the startup sound is played
> without the user having control over the sound.

We're going in circles, the reason why the user have "no control" and if it is 
avoidable have been discussed before. It has also been outlined how my patch 
doesn't change that situation.

>
> > 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
>
> What is so "magic" on a menu item titled
> "Save current voulumes as default  CTRL+S"?
>
> I would say with the propose change the user would not understand what
> would be going on. Because "random" volumes will be saved / restored.

The reasons for this behavior/GUI change has been detailed discussed in the 
previous thread. Please tell why those arguments are wrong. BTW, "random 
values" is only relevant when any other program have modfied the mixer - 
"Broken" MM-apps. In any other case the values saved are actually those the 
user have consciously, deliberately chosen.

>
> >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 believe that it is a good idea to remove the "Load Volumes" and "Save
> Current Volumes" from the control center module.

Yes, me too(..). In either case.

> Removing the "Load volumes on login" is problematic, because you are
> forcing people in using KMix. People who run KDE, but use another mixer
> will NOT like that (because  KMix might restore "wrong" volumes).
> Again (as I said in my introduction) I don't understand why it cannot wait
> after KDE3.2.

This change needs further discussion. But you're right, it can easily wait for 
3.2.


			Frans