Xlib: DisplayWidth / DisplayHeight

[Carsten Haitzler]

On Wed, 30 Aug 2023 18:27:12 +0200 Zbigniew <zbigniew2011 at gmail.com> said:

Perhaps you should share your use case on why you need to know the screen size
when there are far better mechanisms to handle this?

But below is a list of why changing these are not sane/possible etc.

1. You cannot change the way DisplayWidth/Height work. These are not even
functions. They are macros. #defined in Xlib.h - thus old code compiled with
new definitions will no longer behave as it used to. Old binaries will continue
to behave as they do now. So any change will have no effect until code that
uses xlib is recompiled. This would end up a royal mess if these macros ever
changed definition.

2. You cannot change these functions because it will break behaviour of existing
code. You need to understand about stability of API. You don't get to just
change how something works however you like. Some function, macro etc. is
defined by an API spec long ago and there may be room to move within that spec
or maybe not. In X11 and Xlib there is generally very little room to move. The
place where things can move is higher up the stack in ICCCM/NETWM hints which by
their design are often specified with a range of functionality in mind to allow
for policy differences between window managers for example. Anyone who has had
to design, build and maintain an API for a long time will tell you this - you
can't just break things because it seems convenient. Too bad - you are stuck
with your decisions of the past. You can *ADD* to an API and add new things
that were not there before, but you can't just break things.

3. Xserver handled panning is actually incredibly rare (that is what you have
been describing). The panning you probably see 99.9% of the time is actually
implemented by window managers as virtual desktops. This is not even
implemented by Xlib or the Xserver but by a different process and here you have
a whole different world to deal with and it's much more vague than thing than in
X's "core". So I think your while understanding of virtual screens is flawed to
begin with.

4. As has been mentioned - your understanding of screens is also flawed. You
say these above macros should return the real screen width and height... what
screen is that? If I have 3 monitors all looking at different areas of the same
root window with different resolutions and even rotations per monitor - what is
the size of my screen? The above macros have no way to know which one I speak
of. There is no context that is useful.

5. In fact the whole use of these macros is pretty much broken. For the vast
majority of use cases you have a window manager and it decides where your
window will go. It will assign it to some screen/location and decide on the
size. You do not know where the window is assigned until much later in the
life of creating and showing a window at which point the window dimensions
matter, not the screen. If each monitor is a different resolution, by the time
you map your window and the wm decides where to put you ... it'll be a long time
later after you map the window. window managers have the freedom to put your
window anywhere they want and even not show it at all (e.g. force it to be
hidden and minimized because the user wanted that). Yes - override-redirect
windows bypass the wm (I am not going to go into those as these are an
advanced topic  of sorts) and if you are implementing a wm you get to decide a
lot of these nitty details, but at the point you're writing a decent wm you
should already understand a lot more about X and you'll understand why you
can't just change these macros. But the point stands - they cannot be usefully
used in a modern world as they simply lack any context like which
screen/output you want the size of or the window you are referring to (which
could be used to infer the screen after it has been managed by the wm).

6. If your goal is to make a fullscreen sized window then there are netwm hints
for this and a wm will take care of it for you - your app then just RESPONDS to
configurenotify events on your window to find out the size you became. if the
wm moves you from one screen to another, changes resolution of the screen your
window is on or something else, the wm (if decent) should handle resizing your
window accordingly thus your window will get more configurenotify events
and tell you the new size and you respond and alter your content when that
event comes. if your goal is to fill 60% of the screen width and 30% of the
height - you're in trouble as there is no reliable way to do this without a lot
of flickering and probing (map a window - use netwm req to ask it to be
maximized or fullscreen, wait for configurenotify events to settle down then
you know what the screen the wm thinks you should be on is and you can then
un-fullscreen and change size - all of this will be flickery and nasty
though), but then you're after posable netwm hint extensions for wm's to
support and not changes to xlib API.

I can go on... I understand on the surface what you say - but you can't always
get what you want and to me it seems your understanding of X is very
superficial and thus you don't know the right way to do things and it's far
more large and complex a world than you might initially suspect with what I
believe is a very superficial understanding of X

p.s. I used DisplayWidth in maybe my first Xlib app several decades ago. I know
precisely of what you speak. I learned quickly why these were not useful and
that there were better ways to do things or... the problems lay in that window
managers and hints were too basic and so i started writing window managers to
address these issues in part. Been there, seen that, done that. My advice -
don't even think of using these macros. 99% chance if you use them... "You're
doing it wrong".

> > What you want is to find out the width and height of physical screen you
> > have.
> 
> Indeed. That's what DisplayWidth and DisplayHeight functions have been
> created for.
> 
> > To do that you need to use the subsystem that manages them - which
> > is xrandr. And don't forget to specify which of 5 screen you have running
> > you actually mean.
> 
> No, dear Volodya,
> 
>        „The  DisplayHeight  macro returns the height of the specified screen
> in pixels.
> 
>        The DisplayWidth macro returns the width of the screen in pixels.”
> 
> This is what I want, and this is what — as „man” page states — I
> should get, regardless of presence of any „subsystems”. I want nothing
> more than is described there.
> 
> Are you serious when stating, that during creation of a program I
> should play guessing game „what kind of 'subsystem' the user may
> employ”?
> -- 
> best :)
> Z.
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com