Hallo Johannes, Am 12.07.2015 um 14:05 schrieb johannes hanika: > heya, > > the standalone viewer has been obsoleted somewhat by the built-in slideshow > feature.
oh, right, there's a built-in slideshow feature ... sorry, I didn't notice at all. Splendid, this works like a charm! It is responsive and fast, runs on extra displays... > i still think it's cool to have it around, there might be > situations where it's desireable not to load the full beast but instead > have an opengl context around. I wouldn't know :) > On Sun, Jul 12, 2015 at 12:21 PM, Robert Sachunsky < > robert.schub...@mathint.com> wrote: > >> please find attached below a patch meant to improve on user experience with >> darktable-viewer, including some documentation for it. >> >> The changes essentially replace the sleep statements with equally long SDL >> timeout events, so keyboard events can be handled promptly without any dead >> times due to sleep. >> >> On this basis, more keybindings are introduced: pausing the slideshow or >> manually switching to previous/next image. >> >> Moreover, this patch ensures dtview-specific command line parameters do not >> get in the way of general darktable options through dt_init. >> >> What do you think? >> >> Next, what I would like to do is add a command line option for positioning >> the image within the screen (instead of centered) -- as a workaround for >> missing RandR in SDL 1.2: with multiple monitors connected and set up, SDL >> only gets to see the total sum resolution of them, and with dtview's >> write_image choosing to center the image on the screen, it ends up half-way >> on both monitors. Has anyone suggestions or comments on that one, perhaps? >> > > would moving to sdl 2.0 help with that? From its documentation, ... https://wiki.libsdl.org/SDL_GetDisplayBounds https://wiki.libsdl.org/SDL_GetWindowDisplayIndex https://wiki.libsdl.org/SDL_CreateWindow ... yes, definitely! Would that be a big burden? Its multi-display/monitor API does not even seem to be dependent on RandR, which looks more like an option: http://lists.libsdl.org/pipermail/sdl-libsdl.org/2012-October/651919.html Shall I give it a try? > also there are some implications about the display/output profile if you > have multiple monitors, you would probably need to account for a different > display profile on the second monitor to get correct colour management. Indeed. But isn't that true for the built-in slideshow as well? As far as I understand it, one would have to call dtview with "--conf plugins/lighttable/export/iccprofile=..." to that end, while in built-in slideshow it would require changing display colour profile for every image in question -- just once for the show, just for that monitor, which is quite an effort. Am I correct? On the other hand, for correct colour management one would expect all relevant screens to have appropriate icm profiles installed and display profile always set to system-set anyway. Gruß Robert ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ darktable-devel mailing list darktable-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-devel
