Re: Multi DPI user interface

[Jonas Ådahl <jadahl gmail com>]

On Wed, Jul 20, 2016 at 02:27:20PM +0200, Bastien Nocera wrote:
> On Tue, 2016-07-19 at 23:23 +0800, Jonas Ådahl wrote:
> >
> <snip>
> > Well, 3 options with the other one being to have "A" and "B" content
> > be
> > placed in individual files, i.e. Screenshot - 2016-07-19 - 12:34 -
> > LVDS1.png and Screenshot - 2016-07-19 - 12:34 - HDMI1.png, each one
> > with
> > their correct resolution
>
> As Christian mentioned, the 4th option is to pass on that data on "raw"
> (along with metadata such as the scaling factor), and let the "front-
> ends" deal with it.
>
> For gnome-settings-daemon's screenshot functionality, we'd probably
> stitch the screenshots together either as per option #1 or #2 but more
> involved screenshotting tools could offer different options.
>
> In short, don't bake the end-user application design choices into the
> API for this.

Right. My opinion is that any D-Bus API should treat monitors
separately, letting the usage of that API deal with composition. I think
it'd make sense to still use pinos for all future, be it raw or
whatever, inter process picture passing, even for single frames. That
way we'll have a single path for all those things, where we can do
things like format negotiation and meta data passing.

> On that note, relying on the cursor position is as bad an idea as it
> ever was with touchscreens, or for when we implement the "presentation"
> screen mode (which is inaccessible for anything but display).

Yea, I don't think cursor position is a good way to detect what output
to capture. For screenshots via the PrtSc button, I think creating N PNG
files, where N is the number of monitors, is most reasonable.

The gnome-screenshot tool need to be redesigned for this though, since
it has an entry for selecting a file name; we won't have a single file
name any more if we'd go with that solution. On the other hand,
gnome-screenshot can still composite the monitors together if needed.


Jonas