Review Request: Rework KMix DBus API and add KMix plasma dataengine

Igor Poboiko igor.poboiko at gmail.com
Sat Mar 5 10:32:47 CET 2011 


> On March 5, 2011, 8:25 a.m., Aaron Seigo wrote:
> > "When I request an source for Mixer, it also adds soucres for controls. And then when I request source for already available Control, it doesn't react anyhow. But when I set "Update every % ms", and click "Reqeust", it works fine."
> > 
> > this is because the data for the control (or at least, the readableName) is set in updateMixerData. then, when it is later requested the DataEngine sees it exists already and so does not call sourceRequestEvent. since there is no poll (time) request, updateSourceEvent isn't called either. when there is a poll time set, then updateSourceEvent is (eventually) called and the data is updated. the fix is to not set any data on the control until such time as a visualization requests it. you can set up the behind-the-scenes objects, but leave the setData calls for the control out of updateMixerData.
> > 
> > there are some memory leaks that need closing as well.
> > 
> > i also recommend, for stylistic reasons, using "natural language" labels rather than camelCaseAsIfItsAFunctionName labels. e.g.: "Controls", "Readable Name", etc.

Big thanks for your review.
I just thought that these things end-user will never see, so there is no reason to set user-friendly labels. But if you suggest so, I'll fix it.

And there is a little problem. For example, user wants to configure visible controls. He goes to settings, and we should show him all available controls (its readable names, maybe icons, etc). To do it we should request sources for every available control. But when I requests source for control, it starts to listen dbus about volume level changes, etc. If such a thing started for every control, it's bad (just because we doesn't need such an information).
The solution I can see for it is to add list of readable mixers names in the same order as its IDs (and maybe icons, and more data user may need) in "mixers" source and to add list of controls readable names (and again, maybe something else) to every mixer source. Will it be a correct solution? And if not, what should I do then?


> On March 5, 2011, 8:25 a.m., Aaron Seigo wrote:
> > /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerengine.cpp, line 80
> > <http://svn.reviewboard.kde.org/r/6587/diff/1/?file=45445#file45445line80>
> >
> >     does this matter? if mixers is empty, shouldn't that be enough?

Actually, I think there might be a situation when user just don't have any soundcard (or KMix can't detect any). With this thing we can separate this situation from situation when the KMix isn't running (for example, show different notifications, etc)


> On March 5, 2011, 8:25 a.m., Aaron Seigo wrote:
> > /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerengine.cpp, lines 48-49
> > <http://svn.reviewboard.kde.org/r/6587/diff/1/?file=45445#file45445line48>
> >
> >     this is wrong. if the name is "KMix" then the source created _must_ be "KMix", but getKMixData creates/sets "running" and "mixers"
> >     
> >     my suggestion: change this to if (name == "mixers")

I didn't understand. It adds only the "KMix" source, and sets "running" and "mixers" data to it. Am I right?


> On March 5, 2011, 8:25 a.m., Aaron Seigo wrote:
> > /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerengine.cpp, lines 118-123
> > <http://svn.reviewboard.kde.org/r/6587/diff/1/?file=45445#file45445line118>
> >
> >     looks like a good candidate for a QHash rather than a QList

I didn't use QHash there because I should search mixer not only by its ID, but also by its DBus path. And I thought it will be a bad idea to have two QHash for both of them.
Moreover, average user have maximum 4-5 mixers (for example, in ALSA KMix backend, one mixer is one soundcard), so it won't be a big speedup if I set it to QHash; and this loop runs few times during the session.


> On March 5, 2011, 8:25 a.m., Aaron Seigo wrote:
> > /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerengine.cpp, lines 147-153
> > <http://svn.reviewboard.kde.org/r/6587/diff/1/?file=45445#file45445line147>
> >
> >     perhaps another opportunity for a hash.

Same for this one. I search controls by controlId+mixerId pair as well as by its DBus path, so I'm not sure about QHash.


> On March 5, 2011, 8:25 a.m., Aaron Seigo wrote:
> > /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerengine.cpp, line 186
> > <http://svn.reviewboard.kde.org/r/6587/diff/1/?file=45445#file45445line186>
> >
> >     where is this deleted?

Yep, I forgot to delete it. I'll check for every removed control when *changed() DBus signal is emitted and remove unused ControlInfos (and dbus interfaces).


- Igor


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6587/#review9951
-----------------------------------------------------------


On March 5, 2011, 7:56 a.m., Igor Poboiko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6587/
> -----------------------------------------------------------
> 
> (Updated March 5, 2011, 7:56 a.m.)
> 
> 
> Review request for Plasma and Diego Casella.
> 
> 
> Summary
> -------
> 
> This patch reworks KMix DBus API and adds a plasma dataengine+service as a frontend to information provided by DBus.
> New DBus structure is:
>  - /Mixers
> used to get some global information, such as available mixers list and global master mixer
>  - /Mixers/MIXER_ID
> used to get information about mixer with id=MIXER_ID. It provides such information as list of available controls, name of this mixer, id, etc
>  - /Mixers/MIXER_ID/CONTROL_ID
> used to get and set information about control. Such information as volume level, mute, name of control, etc.
> It also adds a DBus signals which are emitted when new mixer/control appears, or volume level changes.
> It also splits all dbus-related code to separate class, DBus{KMix,Mixer,Control}Wrapper.
> 
> The Plasma Dataengine:
> By default, the only available source is "KMix". It provides information global information about KMix: is KMix running, and list of available mixers. (its IDs)
> Source for every mixer is called by it's ID (for example, "ALSA::HDA_Intel:1"). This source provides such information about current Mixer as: it's readable name, is it opened, its balance and list of available controls. It also adds basic sources for every control, which provides only information about its readable name
> Sources for controls are called by 'MIXER_ID/CONTROL_ID' (for example, "ALSA::HDA_Intel:1/Master:0"). If you request this source, it will provide such information as its readable name, is it muted and its volume level (which are updates automatically, using DBus signals).
> There is a service available for controls sources. It provides such methods as setVolume() and setMute().
> 
> It doesn't close bug 171287, but it becomes one step closer to its solving :)
> 
> And, I'm not very familiar with CMake, but it would be great idea to make plasma part optional.
> 
> 
> This addresses bug 171287.
>     https://bugs.kde.org/show_bug.cgi?id=171287
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdemultimedia/kmix/CMakeLists.txt 1223790 
>   /trunk/KDE/kdemultimedia/kmix/apps/kmix.cpp 1223790 
>   /trunk/KDE/kdemultimedia/kmix/core/mixdevice.h 1223790 
>   /trunk/KDE/kdemultimedia/kmix/core/mixdevice.cpp 1223790 
>   /trunk/KDE/kdemultimedia/kmix/core/mixer.h 1223790 
>   /trunk/KDE/kdemultimedia/kmix/core/mixer.cpp 1223790 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbuscontrolwrapper.h PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbuscontrolwrapper.cpp PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixerwrapper.h PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixerwrapper.cpp PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixsetwrapper.h PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixsetwrapper.cpp PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/org.kde.kmix.control.xml PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/org.kde.kmix.mixer.xml PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/dbus/org.kde.kmix.mixset.xml PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/plasma/CMakeLists.txt PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/plasma/engine/CMakeLists.txt PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixer.operations PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerengine.h PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerengine.cpp PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerservice.h PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/plasma/engine/mixerservice.cpp PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/plasma/engine/plasma-engine-mixer.desktop PRE-CREATION 
>   /trunk/KDE/kdemultimedia/kmix/tests/CMakeLists.txt 1223790 
> 
> Diff: http://svn.reviewboard.kde.org/r/6587/diff
> 
> 
> Testing
> -------
> 
> KMix from KDE SC 4.6.0 compiles ok with this patch, and patch applies to current trunk.
> Tested on system with one card and with ALSA backend, so I don't know is plasma dataengine works correctly with plugging/unplugging mixers (but it should).
> All DBus methods/properties works fine, signals are emitted, volume can be set using DBus methods.
> 
> Plasma dataengine was tested using plasmaengineexplorer. 
> All works fine except the one thing. When I request an source for Mixer, it also adds soucres for controls. And then when I request source for already available Control, it doesn't react anyhow. But when I set "Update every % ms", and click "Reqeust", it works fine. If I request a source for control BEFORE requesting the source for mixer, all works fine too (without setting "Update every % ms"). I don't know is it a plasmaengineexplorer bug, or my.
> 
> 
> Thanks,
> 
> Igor
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20110305/40aeec90/attachment-0001.htm

More information about the Plasma-devel mailing list