KMix should only be started if you set the sound volume for the alarm. It is
used to set the hardware sound volume so that the alarm volume is predictable.
Otherwise, the volume would vary depending on the current setting of the
computer at the time the alarm triggered.

I will check if there is a way of preventing KMix from showing its mixer window
when it starts up - I haven't seen that myself, so it must depend on the system
setup.

Hint: KMix will show its main window on start in any of the two follwing cases:
1) KMix Main Window was opened on the last logout of the user
2) Docking on the Systray has been disabled in KMix's configuration dialog (otherwise KMix would start with no GUI at all, which would be quite senseless).

Can you please confirm whether or not:
a) You are setting the sound volume for the alarms which make KMix appear.
b) The conditions for the KMix main window to appear, which you describe, apply when the alarm triggers.

> Can you please confirm whether or not:
> a) You are setting the sound volume for the alarms which make KMix appear.
> b) The conditions for the KMix main window to appear, which you describe,
> apply when the alarm triggers.


a) I haven't set the sound volume for my alarms and KMix continue to appears.
b) Yes, they appears only when alarms trigger.

If KMix is activated when the alarm triggers, but you have NOT set the sound
volume for the alarm, that is a bug.

I have fixed the bug where KMix is started unnecessarily for alarms which don't
have the sound volume set. This will be in KDE 3.4.1.

Christian - is there anything you can do concerning the KMix window appearing
(when the alarm actually requires KMix, that is)? Or should the bug be marked
as resolved?

If you start an application (like KMix), it wouldn't be good if it started
without any GUI. A solution for you would be to use "kstart" when starting
KMix. Just try it from a Konsole window:

kstart --windowclass KMix --skiptaskbar --iconify  kmix

If the user uses the "KMix docking" feature, the window will not show up. I
don't know if this is optimal for you, but you can play with the "kstart"
options, if you like.

What an uggly hack!

This show that the KDE sound design is bad.
It look like a Windows habit: every program should be a GUI.

What about making a KDE sound mixer *SERVICE*?
Then, kdelibs will just provide one or a few classes to interact with it, 
change the volume...

Then, KMix would JUST be a frontend to it.
And Kalarm could use the class to change the volume.

Or perhapse KDE 4 will change this state by using gstreamer and a DBUS based 
"service like"?

I have raised a wishlist bug report (bug 104301) to ask for a sound mixer
service in KDE 4. If that is implemented, I will change KAlarm to use it.

In the meantime, I am reluctant to use kstart to invoke kmix since it would not
only complicate the code, but would also prevent kmix being started using a
KApplication::startServiceByDesktopName() call which provides a standard way of
accessing other applications which aren't currently running. I think that users
will just have to put up with the KMix window appearing when the sound volume
is set and KMix wasn't already running.

@David: I can understand your reasoning, especially as that would be a big ugly
hack.
FYI: A Mixer Service is planned since long for KDE4. It is too early to know
how a Services will be implemented best in KDE4. Today there already many
KDE-specific services (DCOP, KIO-Services, ...), tomorrow there might be
something new like DBUS, or something completely new.
So for now I will concentrate on working KMix in the approximated right
direction.

I have discovered how to fix this, thanks to an example I happened to come
across in another program. KMix will now be iconified after KAlarm starts it,
so at least it won't be as intrusive. Mind you, it would still be more
satisfactory to have a mixer service which hopefully might appear in KDE 4.

The fix will be in KDE 3.4.2 and the next standalone version of KAlarm (1.3.2).

Reopening in order to be able to mark it as fixed.

*** Bug has been marked as fixed ***.