Xlib: DisplayWidth / DisplayHeight

[Carsten Haitzler]

On Thu, 31 Aug 2023 13:09:14 +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?
> 
> Because the use of the mentioned functions/macros is simple and
> straightforward. But they are flawed, unfortunately.
> 
> So what mechanism do you propose to use for that?

Depends on the use case.

> > 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.
> 
> Is it rare, or it isn't — I believe you'll agree that I should've got
> the proper dimensions of physical screen using these macros.

I actually disagree - you can't go breaking an API.

> > 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?
> 
> Dear Carsten,
> have a look, please, at the man page:
> 
>        int DisplayHeight(Display *display, int screen_number);
>        int DisplayWidth(Display *display, int screen_number);
> 
> „What screen is that”? The one described by the parameters.
> ('display' is a pointer to a 'Display' structure returned by a
> previous call to XOpenDisplay() )

Screen number is the old idea of multihead screens where you can't "drag a
window from screen to screen". You had a new root window per "Screen". There
literally is a Screen struct for just this that is essentially dead and unused
in modern x - but it has to be kept for compat. This has essentially died and
is almost never seen anymore. These days xrandr has supplanted that with
something more usable.

> > 5. In fact the whole use of these macros is pretty much broken.
> 
> At least one person here notices and understands this. Yes, that's why
> I suggested a fix.

You can't CHANGE their definition. They are like your tail bone. You still have
a stubby one there from when humans used to have tails. We no longer do. But
you can't just go change it when it comes to a stable API. You can ADD to that
API and that is what has been done. People just migrate to using something else
- depending on their use case.

> > 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
> 
> That's what APIs are for — to allow to make use out of *something* not
> spending next two years to become acquainted with every possible
> internals' aspect.

You don't have to. Most things are pretty simple, but ... if you're writing
things at the xlib level, then you've chosen to want to become aquatinted with
the details. If you don't want to, there are toolkits that abstract and hide
all the nitty details. GTK+, Qt, EFL, and others ... use a toolkit if you want
abstractions and hiding of details.

> OK, you know what I'm about to. You stated, that the fix is impossible.
> 
> Then could you, please, suggest a „replacement functions” for these
> two, that I could use to get the dimensions of physical screen —
> whether is panning used, or not, is Xrandr used for that panning, or
> anything else, is it Linux, or any of xBSD's etc.? In all these cases
> t'll be still Xorg server, anyway.

I asked for your use case. You didn't give it. Plenty of people including me
have also asked "Which screen" - you haven't answered that.

> That's all I need for today — and that's what DisplayWidth /
> DisplayHeight promised to return
> -- 
> regards,
> Zbigniew
> 


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