On Sun, 30.08.09 17:31, Colin Guthrie (gmane at colin.guthr.ie) wrote: Heya! > Do you have any objection to making these priorities user adjustable via > the protocol in some way? I know you intend this to be more or less > automatic for general out of the box use, but as we've discussed before, > the KDE GUI exposes the priority to the user. Hmpf. Read access to this variable might be an ok thing to do. But write access? naah You should not overestimate the meaning of this field. It should be used only for tie breaking if otherwise more than one sink (resp. source) are candidates for *a particular purpose*. That means that most of the time the field is not used and should not be used at all. Now, more specifically, when *should* it be used? Right now it is used only for selecting the initial default sink/source. But later on it should be used as well for example when a sink is removed that was the configured default for a specific role and we need to find a new sink for a stream of this role. As you know I think that the KDE UI for device configuration is not a particular ... let's say ... convincing design. So trying to bend the stuff we already have in PA so that it fits what this (misdesigned in my eyes) KDE UI needs seems the wrong way to do this. A while back we were talking about extending m-s-r to store a history of sinks instead of just a single one. It is still on my list to implement that evntually. The only reasons I didn't do that yet is that it is a little bit more complex design and nothing i still want to sneak in right now. (Also I am not entirely sure how the db schema should look like...) I believe that if you really think that this KDE UI design is any good you should map it to this upcoming history logic in PA than to these priorities. > I intend to add this priority capability into the module-history that > I'm working on (which remembers past sinks and sources and as a side > effect allows sinks/sources to be renamed). Ah, heh. I wrote that parapgraph above before I read this one of yours... ;-) Could you elaborate in more detail what this module is supposed to do and how it relates to m-s-r? As I understood you by "renaming" you are referring to the device description, not the sink/source identifying name, right? > I will update it shortly to also store the priority of the sink and > "manage" this such that it can be exposed to the user if so desired. I am not convinced that this priority value should be used for more than tie breaking, i.e. last resort decisions. > I know you don't want this kind of functionality as a general rule for > Gnome, but is there any logical problem (e.g. in terms of the > implementation or intentions for the future) with me using it this way? For that to answer I'd need to understand more exactly what you are trying to do! Please elaborate! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4