GNOME Bugzilla – Bug 701775
Send pictures to remote DLNA renderers (eg. TVs, Rygel)
Last modified: 2013-06-27 15:05:07 UTC
This patchset introduces a "Display on…" entry in the preview mode gear menu which pops up a dialog listing the available DMRs (DLNA Media Renderers) in the local network: clicking any of those will point the selected DMR to the current image, served over HTTP by dleyna-renderer-service. Currently I'm just adding a "screen" button near the gear menu to let users stop serving the current picture, but the user experience is quite suboptimal. The underlying communication with the DLNA devices is done by the DBus-activatable dleyna-renderer-service daemon and the "Display on…" menu entry will be disabled if for any reason we fail to activate the DBus service on startup. For this reason there's no hard dependency on the dLeyna stack, just a soft one at runtime. https://01.org/dleyna/ The only new dependency I've added is the EggListBox submodule used for the DMR selector dialog.
Created attachment 246232 [details] [review] main-toolbar: Escape markup when setting the toolbar title Use g_markup_printf_escaped() to properly escape strings.
Created attachment 246233 [details] [review] dlna: Display item on remote DLNA renderer using dLeyna Let the user choose a DLNA renderer device from the list of DMRs discovered on the network and display the current item there. This adds a soft-dependency on the deyna-renderer DBus service: if the service is not activatable the functionality will be automatically disabled.
Created attachment 246234 [details] [review] main-toolbar: Add button to stop DLNA sharing in preview mode
For ease of development, I've added instructions to automatically build the needed dLeyna components with JHBuild in bug #701776.
Created attachment 247569 [details] [review] dlna: Display item on remote DLNA renderer using dLeyna Updated to accomodate the following UI rework as suggested by jimmac.
Created attachment 247570 [details] [review] dlna: Stay in remote-display mode after a DMR has been selected UI rework as jimmac suggested on IRC. Once an item has been sent to a remote display, add a big button with the name of the current renderer in the main toolbar and, until the user does not click it, treat all subsequent item selections as requests to push to the selected item to the remote display.
Comment on attachment 246232 [details] [review] main-toolbar: Escape markup when setting the toolbar title Moved to its own bug since not really related, see bug #702909.
Created attachment 247655 [details] [review] dlna: Display item on remote DLNA renderer using dLeyna Ported to GtkListBox instead of EggListBox.
Review of attachment 247655 [details] [review]: Thanks for the patch. A few minor issues and a question. I have fixed the issues myself, just stating them here for the record. ::: src/Makefile.am @@ +213,3 @@ $(CAIRO_CFLAGS) \ $(EXEMPI_CFLAGS) \ + $(EGGLISTBOX_CFLAGS) \ You forgot to remove this when you ported it to GtkListBox. @@ +235,3 @@ $(CAIRO_LIBS) \ $(EXEMPI_LIBS) \ + $(EGGLISTBOX_LIBS) \ Ditto. ::: src/photos-remote-display-manager.c @@ +106,3 @@ + + return remote_display_manager_singleton; +} This looks similar to the way singletons are done in the rest of the code (see photos-mode-controller.c for an example), but slightly different: - you use a global static while the rest of the code uses a static local to a method - you create the instance of the singleton in main() while in the rest of the code they are created and unreffed as needed I am wondering if there are some subtle differences (advantages vs disadvantages) in the two approaches. I must say that I like the idea of calling the public method _dup_singleton instead of _new. This is not a blocker for merging. Just trying to stay informed. :-) ::: src/photos.gresource.xml @@ +5,3 @@ <file alias="preview-menu.ui" preprocess="xml-stripblanks">photos-preview-menu.ui</file> <file alias="selection-menu.ui" preprocess="xml-stripblanks">photos-selection-menu.ui</file> + <file alias="dlna-renderers-dialog.ui" preprocess="xml-stripblanks" compressed="true">photos-dlna-renderers-dialog.ui</file> This should be added to EXTRA_DIST and POTFILES.in.
Created attachment 247895 [details] [review] dlna: Display item on remote DLNA renderer using dLeyna For the record: attaching the version of the patch with the above issues fixed.
Comment on attachment 247570 [details] [review] dlna: Stay in remote-display mode after a DMR has been selected Thanks for the patch!
(In reply to comment #9) > This looks similar to the way singletons are done in the rest of the code (see > photos-mode-controller.c for an example), but slightly different: > - you use a global static while the rest of the code uses a static local to a > method The global static allowed me to check for the availability of the singleton in photos_dlna_renderers_manager_is_available() without taking a ref or causing a new allocation in case no manager is currently alive. > - you create the instance of the singleton in main() while in the rest of the > code they are created and unreffed as needed I did so to cause dleyna-renderer to be DBus-activated right after Photos' startup, to give time for the DMR discovery to happen by the time the user opens the "Display to" dialog. > I am wondering if there are some subtle differences (advantages vs > disadvantages) in the two approaches. I must say that I like the idea of > calling the public method _dup_singleton instead of _new. Yes, using _new is quite confusing. Would you accept a patch to rename the functions for the existing singletons? > This is not a blocker for merging. Just trying to stay informed. :-) Thank you for merging these patches! :D > + <file alias="dlna-renderers-dialog.ui" preprocess="xml-stripblanks" > compressed="true">photos-dlna-renderers-dialog.ui</file> > > This should be added to EXTRA_DIST and POTFILES.in. Oops, thanks!