[patch] Add PlayPause() to DBus interface

[Michael Zanetti]

Hi Edward,

Thanks for your answer.

On Saturday 05 September 2009 23:06:25 Edward Hades wrote:
> Actually, now that I've given it some thought, I think the best
> solution here would be for the IRKick to get some sort of a scripting
> mechanism (might be as easy as variable get/set and arithmetic
> operations to implement both playPause and relative seek).
> 
> Don't think that we are unresponsive to wish requests, I personally
> have no objections for both the new methods (although other devs
> might). It's just a matter of finding the solution that would benefit
> everyone. Perhaps there are tons of users that want playPause,
> relative seek or even
> stopPlayingIfRatingIsLessThanThreeOtherwiseIncreaseVolume. I don't
> think we can afford to implement _all_ of them in the near future.
> 

I don't really think users would ask for such scary DBus functions. I think 
however, playpause() or relativeSeek() aren't that unusual for a music player 
(given that amaroks UI offers exactly this functions). Still the question 
remains what and how many DBus functions we should offer and where it should 
end. Well, the same question arises also for the irkick scripting interface. A 
simple get/set scripting implementation reaches pretty fast its limitations. 
In fact, to do stopPlayingIfRatingIsLessThanThreeOtherwiseIncreaseVolume you 
would already need some if-statement. And implementing a full blown scripting 
editor and interpreter ist pretty much work to code and to maintain. Not to 
think about how hard it would be to use it.

You can already bind a button to execute a bash script in irkick. This means 
you already can configure irkick to get amaroks playstatus and depending on 
that, play or pause it. However, it requires some scripting skills and is just 
too complex for most users out there. Still, to be able to execute 
"stopPlayingIfRatingIsLessThanThreeOtherwiseIncreaseVolume" even with a full 
blown development environment behind the scenes of irkick you would have to 
implement a DBus function GetRating(trackid). You see the problem?

So the question is not "Who should do the work and implement it?" but rather 
"What is easier for the end user?"

IMO in this case it would be the best to add the discussed functions 
(playpause and seek) to amarok (Even Okular has a playPause() function :). But 
I would be the first one to vote against a DBus function in amarok called 
stopPlayingIfRatingIsLessThanThreeOtherwiseIncreaseVolume because also this 
would reduce the usability.

> Imagine also projects, that love their dbus calls as they are, and
> unwilling to add anything new. And they are in fact right, because
> dbus is primarily an interface for programmers, and IRKick is a tool
> for users. So the former is expected to remain at a certain level of
> atomicity, or if you will, primitiveness, while the latter is expected
> to be at a certain level of flexibility.
> 
> Imagine also closed-sourced projects (*shudder*) which you can't even
> patch for yourself!

Well.... Still the same problem... If those projects don't offer required 
connectivity interfaces, the best scripting interface in kdelirc wouldn't 
solve it.

> 
> So, while the specific question of playPause() and seek() functions in
> Amarok remains open for discussion, I suggest you talk to IRKick devs
> and ask what they think of my ideas.
> 

Actually I am the main kdelirc dev.

> By the way, one of the best remote control software I've used, had an
> ugly but very-well featured scripting language, and even its own IDE.
> I even managed to code a script, that allowed to dial a specific track
> number on my remote control (just like the channel number on a TV,
> only better). Can IRKick do that?
> 

Depending on your scripting/skills and other applications DBus interfaces, 
yes. 

Well, currently we (kdelirc devs) are heading exactly the other direction. We 
think that it is too complex for new users to configure their remote controls 
using dbus functions (not talking about scripting here) and are implementing 
Remote Control capabilities for solid. This way, users do not need to 
configure their remote controls at all but rather kde application developers 
should handle them.

Cheers,
Michael