Version: (using KDE KDE 3.4.0) Installed from: Compiled From Sources I just installed KDE 3.4 and discovered a regression: when an alarm in KAlarm is triggered, the alarm window is shown, and then the computer hang during one second... because it loads KMix AND show KMix mixer window. So, each time an alarm ring, KMix is started and shown if it wasn't started before. I'm now obliged to use the new KDE 3.4 "hide icons in systray" feature only for the KMix icon to have KMix always launched (to not have the window opened each time it is started automatically). I think we don't need a mixer everytimes a song is started!

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 ***.