Re: Multi DPI user interface

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:

Well, 3 options with the other one being to have "A" and "B" content
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
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]