> 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. > > Igor Poboiko wrote: > 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?
"end-user will never see" with DataEngines, it's useful to consider plasmoid developers as their end-users :) "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)" probably not in "mixers", but in the mixer specific source that is set in updateMixerData. > 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") > > Igor Poboiko wrote: > I didn't understand. It adds only the "KMix" source, and sets "running" > and "mixers" data to it. Am I right? no, it doesn't add the "KMix" source. it adds "running" and "mixers". there is not setData("KMix", ..) calls, so "KMix" is never created! the visualization (e.g. plasmaengineexplorer) asks for "KMix" and the DataEngine instead creates two _other_ sources named "running" and "mixers". "KMix" is never created, and so the visualization does not get the source it requested. the name of the sources created with setData _must_ match the name of source passed in to sourceRequestEvent. i'd also suggest that it's irrelevant that it's coming from KMix, or any other specific application. the DataEngine should simply expose audio mixer information. where it gets it is irrelevant. so .. a source called "mixers" should be requested by the visualization and the DataEngine should populate it with the mixers available. > 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? > > Igor Poboiko wrote: > 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) that KMix can be not running when this DataEngine is run is a bug. KMix is essentially becoming a service and as such should be started on demand as needed. if it fails to run, then there are no mixers available to the DataEngine. simple as that. anything else is an implementation detail that doesn't need to be exposed. i do recognize it could be useful for debugging / troubleshooting purposes, but that's not usually a good reason to put a publicly visible source in a DataEngine :) > 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 > > Igor Poboiko wrote: > 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. fair enough :) if it isn't a performance issue, then we don't need to worry about it. however, just for future reference, you can iterate over a hash just as if it were a list. so you could key the hash by the most commonly looked up key (dbus interface or control ID) and then iterate linearly over the hash for the other case. > 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? > > Igor Poboiko wrote: > 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). it also needs to be deleted in the destructor of the DataEngine. - Aaron ----------------------------------------------------------- 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
