Review for demo GUI
christian at esken.de
Tue May 21 20:41:27 BST 2013
Am 21.05.2013 21:16, schrieb Matěj Laitl:
> this is a heads-up from an Amarok developer.
> On 21. 5. 2013 Shubham Chaudhary wrote:
>> I totally agree with you here, even I faced some problems that made me
>> realized the gravity of this mistake.
>> Actually Amarok takes some time before it actually sends the metadata
>> of next song, so whenever I pressed next or previous button, the
>> metadata and album art fields would go blank.
> Amarok takes some time before it actually starts to play the next song, this
> is by design, and because Phonon is asynchronous, all players using it must be
> inherently asynchronous in this case.
>> Clementine and several other player were working perfectly fine in
>> this context,
> Not "fine", they are just implemented in one particular way that suits you
> better, it doesn't mean that other players aren't fine.
Exactly. For KMix it was quite the opposite. Amarok worked nicely, but
I had sever issues with Clementine.
>> but what I realized from this was that I can't rely on the synchronous
>> methods. I'm planning to modify the QMpris library accordingly.
> No, you haven't understood it, this wasn't because you using a synchronous
> method, this was because you were assuming synchronous behaviour of the
> players. Using async DBus calls in something perpendicular to the issue you
> had with Amarok. (i.e. that bug in your code wouldn't be fixed just by
> switching to async DBus calls)
I haven't seen the code, but asynchronous is not the solution to
everything. Still, one should always work asynchronously or
multi-threaded when you do IPC in GUI-Programs. Otherwise your program
will lock during communication or in the worst-case you might deadlock
or create starvation. Currently I am considering to put all DBUS
communication in own Thread(s) for KMix.
kde-multimedia mailing list
kde-multimedia at kde.org
More information about the kde-multimedia