client side decorations

[Michal Suchanek]

On 12 May 2011 19:47, Bill Spitzak <spitzak at gmail.com> wrote:
> microcai wrote:
>
>> They can't care how big a windows is in the pixel, but in the inch.
>>
>> People should have different monitors with different DPI. Windows should
>> stay same size regardless the DPI.
>>
>> Force DPI==96 on every monitor is a stupid idea, and we should avoid it
>> on the protocol side.
>
> The reason this had to be done was due to the incredibly stupid idea that
> only *fonts* are measured in points, and every other graphic is measured in
> pixels. This strange idea was on both X and Windows, likely due to the
> initial programs being terminal emulators where there was no graphics other
> than text. What this really means is that there are two different coordinate
> systems for all the graphics, and programmers just assumed these two systems
> always lined up exactly like they did on their screen.
>
> After a lot of awful looking output on screens with different DPI, both

That's not really true. Of course, there are things that look awful in
different DPI (or because you happen to have slightly different fonts
than the author) because they were done by braindead people. This
includes but is not limited to

- many web sites
- (some?) Adobe and HP software
- OS X (which actually prevents changing the DPI in the first place
leaving you with ridiculous font sizes)

Note that very first UIs were virtually bitmap-free and all the WM
buttons and borders were vector graphics or generated on the spot from
a few user-specified parameters (Windows 3.1, old stuff like mwm,
olwm, fvwm, ..) and could be scaled to any size you specified.

Then bitmaps were used heavily and made their way to stuff like window
borders because the level of complexity people desired for their
eye-candy could not be done with simple vector graphics anymore, and
complex vector graphics required more power than people were willing
to sacrifice for window borders.

Still GTK bitmap themes have provisions for scaling the bitmaps to
suit any text sizes in window captions and buttons. The button border
will be relatively thinner to the text size (or thicker for smaller
text) but will still render as intended, and people are free to choose
a different theme.

Similarly in Windows you can set different border sizes or font sizes
if you accept that tons of braindead software breaks (eg. Adobe CS or
HP scanner dialogs). Also Windows bitmapped window buttons look
terribly on non-default sized borders but vector buttons are still
available.

The web is a problem because due to the specs being how they are they
are not really friendly to people conscious about the look of their
sites and many effects can't be achieved in a portable way without
setting the element sizes exactly in pixels. You can say it's a defect
in the specs or an error on the side of the people who are trying to
stretch them to make their sites look flashy at the expense of
usability but it's totally offtopic here.

> Windows and then X resorted to just forcing the DPI to 96, thus making the
> systems obey the programmer's assumptions. Bad DPI settings are still a bug
> on X, producing ridiculous large and tiny font sizes unexpectedly, and this
> is NEVER wanted.
>
> The correct solution would have been to specify all coordinates in the same
> units, likely 1 unit in the CTM. For practical reasons on current-day
> screens this wants to be a pixel by default, but there is no reason a
> program can't read the DPI and set the CTM to draw actual-size graphics.

Well, they can't on systems where DPI is always forced to be 96
regardless of the actual screen physical properties.

Also this is reportedly[1] done so that people don't get ridiculously
small text on TVs but it is at the expense of getting ridiculously
small DPI on most netbooks and high-end notebooks so this is not
really a good tradeoff IMHO.

Thanks

Michal

[1] https://bugs.freedesktop.org/show_bug.cgi?id=23705