Review for demo GUI

[Christian Esken]

Am 21.05.2013 21:16, schrieb Matěj Laitl:
> Hi,
> 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.

   Christian

_______________________________________________
kde-multimedia mailing list
kde-multimedia at kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia