Re: Multi DPI user interface
Sorry, I'm well out of my depth here, but there we references to HiDPI which prompted my email. To my naive eye HiDPI appeared to be a temporary hack to get around the real problem of font scaling. So the logic was, if HiDPI is being talked about, then perhaps this area of the system may impact how fonts are scaled. I had assumed that fonts were handled much further up the stack but wanted to ensure that people were thinking about font scaling if this chunk of work could have any future ramifications. Brett On 21/07/16 10:53, Jonas Ådahl wrote: On Thu, Jul 21, 2016 at 09:36:11AM +1000, Brett Sutton wrote: Can I suggest that as this work is done you keep in mind (what I hope) is the long term objective to provide correct dpi scaling. Font scaling is out of scope for what is discussed here. This is simply about integer framebuffer scaling on a logical coordinate space that makes up the whole desktop area, with all connected monitors, and how to do screen shooting and casting on such a configuration. Doing per monitor font scaling is more of a client and Wayland protocol issue, and not related to all of this. Jonas e.g. a 10 point font should measure 10/72 of an inch regardless of the resolution or physical size of a monitor. I may (as an end user) want to then apply different scaling to each monitor. The current system where a 10 point font is a different size on each monitor makes no sense. Brett On 20/07/16 22:27, 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 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. 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). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Multi DPI user interface
On Thu, Jul 21, 2016 at 09:36:11AM +1000, Brett Sutton wrote: > Can I suggest that as this work is done you keep in mind (what I hope) is > the long term objective to provide correct dpi scaling. Font scaling is out of scope for what is discussed here. This is simply about integer framebuffer scaling on a logical coordinate space that makes up the whole desktop area, with all connected monitors, and how to do screen shooting and casting on such a configuration. Doing per monitor font scaling is more of a client and Wayland protocol issue, and not related to all of this. Jonas > > e.g. a 10 point font should measure 10/72 of an inch regardless of the > resolution or physical size of a monitor. > > I may (as an end user) want to then apply different scaling to each monitor. > > The current system where a 10 point font is a different size on each monitor > makes no sense. > > Brett > > On 20/07/16 22:27, 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 > > > 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. > > > > 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). > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Multi DPI user interface
Can I suggest that as this work is done you keep in mind (what I hope) is the long term objective to provide correct dpi scaling. e.g. a 10 point font should measure 10/72 of an inch regardless of the resolution or physical size of a monitor. I may (as an end user) want to then apply different scaling to each monitor. The current system where a 10 point font is a different size on each monitor makes no sense. Brett On 20/07/16 22:27, 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 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. 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). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Multi DPI user interface
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 > 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. 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). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list