> On June 2, 2012, 6:10 a.m., Andrea Diamantini wrote: > > Hi Anton, > > sorry for the long waiting about a review here. But I just checked your > > code and I found it very good. I'm just a bit worried about this "strange" > > interaction: why should a browser take care of this interaction? The change > > you requested is "monumental" compared to the "tiny" use case you provided. > > How many users are using the now playing plasmoid? How many players > > interact with it (everyone?)? How many browsers interact with it (noone?)? > > Is all this done just to provide a shortcut to play/stop music? What about > > other multimedia (non-html5) sources? How can users react to the missing > > functionality in their management? > > Anton Kreuzkamp wrote: > >sorry for the long waiting about a review here. > Thanks for the review ;) > > >why should a browser take care of this interaction? > Well, one of the goals of rekonq is good desktop integration, isn't it? > Integrating web-mediaplayers into the desktop targets exactly that. > > >The change you requested is "monumental" compared to the "tiny" use case > you provided. > It adds quite a few new classes, that's right, but they're quite well > seperated, so it at least doesn't clutter the code, does it? > > >How many users are using the now playing plasmoid? > Well, not many. But the now playing plasmoid is not the only one letting > you control media players. E.g. Unity has it integrated more deeply into it's > shell and for Plasma it's defenitely to come. > The same way one could control the media-playing with a remote control > (e.g. while streaming a film from the internet). > > >How many players interact with it (everyone?)? > Yes, nearly everyone > > >How many browsers interact with it (noone?)? > Yes, noone, so it would be a special feature of rekonq ;) > > >Is all this done just to provide a shortcut to play/stop music? > It's done to integrate webbased mediaplayers as good into the desktop as > normal mediaplayers are. > The most relevant feature to me personally (and that's why I implemented > it) is to play/pause music, though, that's true. > > >What about other multimedia (non-html5) sources? > Technically not possible, as html5 players are the only ones having a > standardized API for interaction. But html5 is in the ascending. > > >How can users react to the missing functionality in their management? > I don't understand this question, sorry. > > Lindsay Mathieson wrote: > Does the task manager (such as the Icon-only task manager) use the mpris > interface to display the media controls in the icon hover hint?
Yes, it does. But it doesn't find rekonq as a media-app... I've made a patch to it(https://git.reviewboard.kde.org/r/105137/), no idea though, whether I will be able to commit it for 4.9 (I doubt it). But nevertheless, with icontasks we have one more usecase for this patch. - Anton ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105059/#review14353 ----------------------------------------------------------- On May 26, 2012, 8:18 a.m., Anton Kreuzkamp wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/105059/ > ----------------------------------------------------------- > > (Updated May 26, 2012, 8:18 a.m.) > > > Review request for rekonq. > > > Description > ------- > > This patch addes a mpris2-compliant dbus-interface to rekonq that allows > controling html5-video and -audio elements from e.g. the nowplaying-plasmoid. > This is espacially useful together with youtube's html5-player and the > plasmoid PlayControl (which allows to assign global shortcuts to > mediaplayer-actions (so you can pause all mediaplayers with the same > mediacontrol-keys)) > With this patch rekonq aggregates all opened media elements and provides one > interface to dbus (providing one interface per media element is not possible > with mpris) that contains the data of > and sends commands recieved via dbus to the last active mediaplayer (that was > last loaded or changed its playback-status most recently). > The communication to the media element happens via javascript. > > > Diffs > ----- > > src/CMakeLists.txt 1180ad0 > src/application.h 36114ae > src/application.cpp ef6c208 > src/dbus/mpris2/Mpris2DBusHandler.h PRE-CREATION > src/dbus/mpris2/Mpris2DBusHandler.cpp PRE-CREATION > src/dbus/mpris2/org.mpris.MediaPlayer2.Player.xml PRE-CREATION > src/dbus/mpris2/org.mpris.MediaPlayer2.root.xml PRE-CREATION > src/webpage.h abc9f64 > src/webpage.cpp ce1151d > > Diff: http://git.reviewboard.kde.org/r/105059/diff/ > > > Testing > ------- > > Comprehensive tests with different html5 mediaplayers (audio and video) and > different mpris-controllers. No problems anymore. > > > Thanks, > > Anton Kreuzkamp > >
_______________________________________________ rekonq mailing list [email protected] https://mail.kde.org/mailman/listinfo/rekonq
