On Wed, 30 Aug 2023 18:27:12 +0200 Zbigniew <[email protected]> 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 - [email protected]
