• odd windowing issue (perl Tk)

    From Mike Scott@usenet.16@scottsonline.org.uk.invalid to comp.sys.raspberry-pi on Wed Jul 8 12:03:51 2026
    From Newsgroup: comp.sys.raspberry-pi

    Hi all. A bit of an odd problem here.

    I've a perl program that opens an X window using Tk. I specify the
    geometry 1400x700+0+0.

    Running under Mint, it works fine, and opens exactly as expected in the
    top left screen corner.

    On the Pi (pi4, 11/bullseye), it opens a window with the correct size
    but a very odd position:

    xwininfo: Window id: 0x1a00013 "Display"

    Absolute upper-left X: 1782
    Absolute upper-left Y: 30
    Relative upper-left X: 2
    Relative upper-left Y: 30
    Width: 1400
    Height: 700
    Depth: 24
    Visual: 0x21
    Visual Class: TrueColor
    Border width: 0
    Class: InputOutput
    Colormap: 0x20 (not installed)
    Bit Gravity State: NorthWestGravity
    Window Gravity State: NorthWestGravity
    Backing Store State: NotUseful
    Save Under State: no
    Map State: IsViewable
    Override Redirect State: no
    Corners: +1782+30 --1262+30 --1262-350 +1782-350
    -geometry 1400x700+1780+0

    which is well off to the right, with the title bar concealed underneath
    the top task bar.

    Any thoughts please as to what might be going on?


    (I know bulldog isn't the latest but I don't have any pressing need to upgrade. This machine is dedicated to running this one program.

    I also see xrandr returns unexpected output about not being able to
    fetch the gamma value for the screen, which it calls "default". But
    maybe that's a red herring.)
    --
    Mike Scott
    Harlow, England

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Robert Riches@spamtrap42@jacob21819.net to comp.sys.raspberry-pi on Wed Jul 8 17:04:01 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 2026-07-08, Mike Scott <usenet.16@scottsonline.org.uk.invalid> wrote:
    Hi all. A bit of an odd problem here.

    I've a perl program that opens an X window using Tk. I specify the
    geometry 1400x700+0+0.

    Running under Mint, it works fine, and opens exactly as expected in the
    top left screen corner.

    On the Pi (pi4, 11/bullseye), it opens a window with the correct size
    but a very odd position:

    xwininfo: Window id: 0x1a00013 "Display"

    Absolute upper-left X: 1782
    Absolute upper-left Y: 30
    Relative upper-left X: 2
    Relative upper-left Y: 30
    Width: 1400
    Height: 700
    Depth: 24
    Visual: 0x21
    Visual Class: TrueColor
    Border width: 0
    Class: InputOutput
    Colormap: 0x20 (not installed)
    Bit Gravity State: NorthWestGravity
    Window Gravity State: NorthWestGravity
    Backing Store State: NotUseful
    Save Under State: no
    Map State: IsViewable
    Override Redirect State: no
    Corners: +1782+30 --1262+30 --1262-350 +1782-350
    -geometry 1400x700+1780+0

    which is well off to the right, with the title bar concealed underneath
    the top task bar.

    Any thoughts please as to what might be going on?


    (I know bulldog isn't the latest but I don't have any pressing need to upgrade. This machine is dedicated to running this one program.

    I also see xrandr returns unexpected output about not being able to
    fetch the gamma value for the screen, which it calls "default". But
    maybe that's a red herring.)

    Under some circumstances, the window manager can override the
    size or position parameters. Under some other circumstances, the
    application can ignore those parameters.

    There is a program called devilspie (apparently named after a
    song) that can force new (or old) windows to specified sizes and
    positions.
    --
    Robert Riches
    spamtrap42@jacob21819.net
    (Yes, that is one of my email addresses.)
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From rbowman@bowman@montana.com to comp.sys.raspberry-pi on Wed Jul 8 17:33:38 2026
    From Newsgroup: comp.sys.raspberry-pi

    On Wed, 8 Jul 2026 12:03:51 +0100, Mike Scott wrote:

    (I know bulldog isn't the latest but I don't have any pressing need to upgrade. This machine is dedicated to running this one program.

    What is XDG_SESSION_TYPE? Mint is X11. I'm running the latest Trixie derivative on the Pi and it is Wayland. I'm wondering if an older XWayland isn't doing the job.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Mike Scott@usenet.16@scottsonline.org.uk.invalid to comp.sys.raspberry-pi on Wed Jul 8 19:54:56 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 08/07/2026 18:33, rbowman wrote:
    On Wed, 8 Jul 2026 12:03:51 +0100, Mike Scott wrote:

    (I know bulldog isn't the latest but I don't have any pressing need to
    upgrade. This machine is dedicated to running this one program.

    What is XDG_SESSION_TYPE? Mint is X11. I'm running the latest Trixie derivative on the Pi and it is Wayland. I'm wondering if an older XWayland isn't doing the job.

    Thanks for the comment.

    X11 (on both)
    --
    Mike Scott
    Harlow, England
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Mike Scott@usenet.16@scottsonline.org.uk.invalid to comp.sys.raspberry-pi on Wed Jul 8 19:57:06 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 08/07/2026 18:04, Robert Riches wrote:
    Under some circumstances, the window manager can override the
    size or position parameters. Under some other circumstances, the
    application can ignore those parameters.

    Presumably the wm's differ. But /anything/ positioning a window outside
    the screen real estate after ignoring the user's request is most
    assuredly broken.

    Looks like I'll have to write some simpler test code to see what's
    happening.

    Thanks for the thought.
    --
    Mike Scott
    Harlow, England
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.sys.raspberry-pi on Wed Jul 8 23:17:43 2026
    From Newsgroup: comp.sys.raspberry-pi

    On Wed, 8 Jul 2026 12:03:51 +0100, Mike Scott wrote:

    On the Pi (pi4, 11/bullseye), it opens a window with the correct
    size but a very odd position:

    On Wayland, the application is not in control of where its windows
    appear.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Robert Riches@spamtrap42@jacob21819.net to comp.sys.raspberry-pi on Thu Jul 9 02:46:39 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 2026-07-08, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
    On Wed, 8 Jul 2026 12:03:51 +0100, Mike Scott wrote:

    On the Pi (pi4, 11/bullseye), it opens a window with the correct
    size but a very odd position:

    On Wayland, the application is not in control of where its windows
    appear.

    Then, what of the time-honored -geometry or --geometry option a
    user can add to a command line in a script or alias to create a
    window at a user-specified location? I have scripts that open
    multiple windows, each at a location specified by that option.
    --
    Robert Riches
    spamtrap42@jacob21819.net
    (Yes, that is one of my email addresses.)
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From rbowman@bowman@montana.com to comp.sys.raspberry-pi on Thu Jul 9 04:34:11 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 9 Jul 2026 02:46:39 GMT, Robert Riches wrote:

    Then, what of the time-honored -geometry or --geometry option a user can
    add to a command line in a script or alias to create a window at a user-specified location? I have scripts that open multiple windows,
    each at a location specified by that option.

    afaik, you had better stick with X11 distros. Absolute positioning of
    windows was something the Wayland developers objected to.

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Mike Scott@usenet.16@scottsonline.org.uk.invalid to comp.sys.raspberry-pi on Thu Jul 9 08:41:29 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 09/07/2026 03:46, Robert Riches wrote:
    On 2026-07-08, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
    On Wed, 8 Jul 2026 12:03:51 +0100, Mike Scott wrote:

    On the Pi (pi4, 11/bullseye), it opens a window with the correct
    size but a very odd position:

    On Wayland, the application is not in control of where its windows
    appear.

    Then, what of the time-honored -geometry or --geometry option a
    user can add to a command line in a script or alias to create a
    window at a user-specified location? I have scripts that open
    multiple windows, each at a location specified by that option.


    That option seems to have been lost in many cases (eg Lingot) where it
    would be useful. Regrettable.

    However, getting back to the original problem, I'll hold up my hands and
    say 'programming error'. I still don't understand the failure mode - the program runs single or dual-head, distributing one or two Tk main
    windows between them. I won't include the suspect code here.

    The code /looked/ OK, and worked fine on Mint where it was debugged.
    However, running single-head on the Pi gave the weird position of the
    window. I've reworked the code, and it all works now (or seems to) on
    both machines.

    It does raise the question though of exactly why the behaviour differed
    so obscurely. Perl/Tk AFAIK shouldn't be doing this.

    Thanks for the comments. They did make me take a closer look at the code.
    --
    Mike Scott
    Harlow, England
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Daniel James@daniel@me.invalid to comp.sys.raspberry-pi on Thu Jul 9 11:14:45 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 09/07/2026 05:34, rbowman wrote:
    Absolute positioning of
    windows was something the Wayland developers objected to.

    That seems short-sighted.

    In my former life as a Windows (cough!) developer we took some trouble
    to open our main application window at the same position on the screen
    as it had been when the application was last closed (and stored screen size/position values for different screen sizes/resolutions for the
    benefit of those who copied the application between their laptop and
    desktop PCs). It was a popular feature.

    I really do *NOT* like the fact that on this (stock RaspiOS) Pi the wm
    chooses to open each and every application right in the centre of the
    screen and I have to move them all around to acceptable places.
    --
    Cheers,
    Daniel.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From druck@news@druck.org.uk to comp.sys.raspberry-pi on Thu Jul 9 18:31:18 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 09/07/2026 11:14, Daniel James wrote:
    On 09/07/2026 05:34, rbowman wrote:
    Absolute positioning of
    windows was something the Wayland developers objected to.

    That seems short-sighted.

    The whole Wayland project seems to be the blind leading the short-sighted.

    I really do *NOT* like the fact that on this (stock RaspiOS) Pi the wm chooses to open each and every application right in the centre of the
    screen and I have to move them all around to acceptable places.

    Luckily switching back to the fully functional X11 is easy.
    Turn rsyslog back on too, and you have a usable system.

    ---druck


    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From rbowman@bowman@montana.com to comp.sys.raspberry-pi on Thu Jul 9 18:29:55 2026
    From Newsgroup: comp.sys.raspberry-pi

    On Thu, 9 Jul 2026 11:14:45 +0100, Daniel James wrote:

    On 09/07/2026 05:34, rbowman wrote:
    Absolute positioning of windows was something the Wayland developers
    objected to.

    That seems short-sighted.

    In my former life as a Windows (cough!) developer we took some trouble
    to open our main application window at the same position on the screen
    as it had been when the application was last closed (and stored screen size/position values for different screen sizes/resolutions for the
    benefit of those who copied the application between their laptop and
    desktop PCs). It was a popular feature.

    Reading some of the discussions by the Wayland developers security was the chief concern followed by the cosmetic problems of a window positioning
    itself over a dock and so forth.

    I spent about 25 years working with legacy Motif applications. The MKS NutCracker tools allowed us to port the code, which originally had been developed for RS6000/AIX machines, to Windows.

    https://en.wikipedia.org/wiki/MKS_Toolkit

    The article focuses on the tools, but a runtime allowed compiling on
    Windows and running the applications. The PTC X server supported the Motif apps.

    Anyway, when you work with Motif you find yourself dipping into the Xt and Xlib to get anything down and the low level interface to the X server certainly could be abused. You could create a full screen modal window and stop everything in its tracks until the dispatcher responded to an
    emergency alert for example.

    While the GNOME, QT, and other widget toolkits sat on the same X11 infrastructure they provided a level of abstraction that didn't encourage
    the low level coding that Motif or Athena allowed or even necessitated.

    I can understand the design decisions behind Wayland. otoh I'm glad I
    didn't have to move the legacy Motif apps to Wayland. Our new product
    retained the backend service structure but used a web based Angular front
    end. It was easier to start afresh than attempt to untangle decades of
    legacy X11 code.

    X11 won't go away and there are new forks like XLibre to keep it alive,
    just like there are DEs based on GNOME 2 produced by developers
    disappointed with GNOME 3.

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.sys.raspberry-pi on Thu Jul 9 22:58:18 2026
    From Newsgroup: comp.sys.raspberry-pi

    On Thu, 9 Jul 2026 11:14:45 +0100, Daniel James wrote:

    I really do *NOT* like the fact that on this (stock RaspiOS) Pi the
    wm chooses to open each and every application right in the centre of
    the screen and I have to move them all around to acceptable places.

    That’s an issue with the window manager.

    On my KDE Plasma system, the default window manager behaviour seems to
    be to put windows wherever there is a convenient gap among the
    existing windows on the current desktop.

    One thing is for sure: giving control to the apps themselves is never
    going to be the optimal solution.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.sys.raspberry-pi on Thu Jul 9 22:59:28 2026
    From Newsgroup: comp.sys.raspberry-pi

    On Thu, 9 Jul 2026 18:31:18 +0100, druck wrote:

    The whole Wayland project seems to be the blind leading the
    short-sighted.

    Feel free to sponsor the development of alternatives that are
    more simpatico with your particular weltanschauung.

    Free Software is all about having a choice.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From rbowman@bowman@montana.com to comp.sys.raspberry-pi on Fri Jul 10 02:54:39 2026
    From Newsgroup: comp.sys.raspberry-pi

    On Thu, 9 Jul 2026 22:59:28 -0000 (UTC), Lawrence D’Oliveiro wrote:

    On Thu, 9 Jul 2026 18:31:18 +0100, druck wrote:

    The whole Wayland project seems to be the blind leading the
    short-sighted.

    Feel free to sponsor the development of alternatives that are more
    simpatico with your particular weltanschauung.

    Free Software is all about having a choice.

    https://github.com/x11libre/xserver

    There are some suggestions at the bottom of the page under 'I Want To
    Help'. warning: politics ahead.

    It will be interesting this fall with KDE/Plasma 6.8 that will be Wayland only. I expect my Fedora box which is at 6.7 will go. Leap 16 is still
    6.4.2 but may get there someday.

    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Daniel James@daniel@me.invalid to comp.sys.raspberry-pi on Sat Jul 11 12:32:30 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 09/07/2026 23:58, Lawrence D’Oliveiro wrote:
    One thing is for sure: giving control to the apps themselves is never
    going to be the optimal solution.

    It's not clear to me that there is any one solution that is optimal in
    all cases.

    It's certainly nice to allow the apps to be able to request a particular size/position, but of course the wm should be able to ignore the request
    if that location makes no sense. No, the app shouldn't have *control*,
    just be able to express a preference.
    --
    Cheers,
    Daniel.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Richard Kettlewell@invalid@invalid.invalid to comp.sys.raspberry-pi on Sat Jul 11 14:05:51 2026
    From Newsgroup: comp.sys.raspberry-pi

    Daniel James <daniel@me.invalid> writes:
    On 09/07/2026 23:58, Lawrence D’Oliveiro wrote:
    One thing is for sure: giving control to the apps themselves is never
    going to be the optimal solution.

    It's not clear to me that there is any one solution that is optimal in
    all cases.

    It's certainly nice to allow the apps to be able to request a
    particular size/position, but of course the wm should be able to
    ignore the request if that location makes no sense. No, the app
    shouldn't have *control*, just be able to express a preference.

    I would argue that for the most part, the window position preferences
    (or outright control) should come from the user, not the application at
    all. That does point to a system-level component (window manager,
    compositor, whatever) managing positions, following user configuration,
    rather than the application.

    There is some nuance here when an application either opens more than one window, or opens a window that is in some way logically connected to
    another application. Depending on what’s going on it might be
    preferrable for the new window to be overlapping the existing window
    (e.g. menus, tooltips, confirmation dialogs, etc), or it might be
    preferrable for it to not overlapping the existing window if possible
    (e.g. a pop-out media player).

    Wayland already covers much of this but there does seem to be a gap for
    a niche set of use cases. It always seems to be the same application
    mentioned each time this comes up, so it’s unclear if the niche is
    bigger than 1.
    --
    https://www.greenend.org.uk/rjk/
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Mike Scott@usenet.16@scottsonline.org.uk.invalid to comp.sys.raspberry-pi on Sat Jul 11 19:37:57 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 11/07/2026 14:05, Richard Kettlewell wrote:
    I would argue that for the most part, the window position preferences
    (or outright control) should come from the user, not the application at
    all. That does point to a system-level component (window manager, compositor, whatever) managing positions, following user configuration, rather than the application.

    I rather depends on the use, i suspect. That warning window really may
    need to position itself screen dead centre on top of everything else to
    make the realise there's a problem with the automatic reactor emergency shutdown :-{
    --
    Mike Scott
    Harlow, England
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Richard Kettlewell@invalid@invalid.invalid to comp.sys.raspberry-pi on Sat Jul 11 22:08:21 2026
    From Newsgroup: comp.sys.raspberry-pi

    Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:
    Richard Kettlewell wrote:
    I would argue that for the most part, the window position preferences
    (or outright control) should come from the user, not the application at
    all. That does point to a system-level component (window manager,
    compositor, whatever) managing positions, following user configuration,
    rather than the application.

    I rather depends on the use, i suspect. That warning window really may
    need to position itself screen dead centre on top of everything else
    to make the realise there's a problem with the automatic reactor
    emergency shutdown :-{

    That’s not inconsistent with policy being in the window manager (or compositor or or whatever).

    Personally I think that having the warning obscure whatever outputs and controls you might use to further investigate and mitigate the problem doesn’t seem like a great idea.
    --
    https://www.greenend.org.uk/rjk/
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.sys.raspberry-pi on Sat Jul 11 22:07:56 2026
    From Newsgroup: comp.sys.raspberry-pi

    On Sat, 11 Jul 2026 12:32:30 +0100, Daniel James wrote:

    It's certainly nice to allow the apps to be able to request a
    particular size/position, but of course the wm should be able to
    ignore the request if that location makes no sense. No, the app
    shouldn't have *control*, just be able to express a preference.

    It’s not clear that that preference would be useful in enough cases to bother.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From rbowman@bowman@montana.com to comp.sys.raspberry-pi on Sun Jul 12 00:01:51 2026
    From Newsgroup: comp.sys.raspberry-pi

    On Sat, 11 Jul 2026 19:37:57 +0100, Mike Scott wrote:

    On 11/07/2026 14:05, Richard Kettlewell wrote:
    I would argue that for the most part, the window position preferences
    (or outright control) should come from the user, not the application at
    all. That does point to a system-level component (window manager,
    compositor, whatever) managing positions, following user configuration,
    rather than the application.

    I rather depends on the use, i suspect. That warning window really may
    need to position itself screen dead centre on top of everything else to
    make the realise there's a problem with the automatic reactor emergency shutdown :-{

    Not quite as dramatic but if an officer triggered an emergency alert a
    modal dialog was popped up on all dispatch stations. At least one
    dispatcher had to acknowledge the dialog before the stations were
    released.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Robert Riches@spamtrap42@jacob21819.net to comp.sys.raspberry-pi on Sun Jul 12 03:55:03 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 2026-07-11, Richard Kettlewell <invalid@invalid.invalid> wrote:
    Daniel James <daniel@me.invalid> writes:
    On 09/07/2026 23:58, Lawrence D’Oliveiro wrote:
    One thing is for sure: giving control to the apps themselves is never
    going to be the optimal solution.

    It's not clear to me that there is any one solution that is optimal in
    all cases.

    It's certainly nice to allow the apps to be able to request a
    particular size/position, but of course the wm should be able to
    ignore the request if that location makes no sense. No, the app
    shouldn't have *control*, just be able to express a preference.

    I would argue that for the most part, the window position preferences
    (or outright control) should come from the user, not the application at
    all. That does point to a system-level component (window manager, compositor, whatever) managing positions, following user configuration, rather than the application.

    There is some nuance here when an application either opens more than one window, or opens a window that is in some way logically connected to
    another application. Depending on what’s going on it might be
    preferrable for the new window to be overlapping the existing window
    (e.g. menus, tooltips, confirmation dialogs, etc), or it might be
    preferrable for it to not overlapping the existing window if possible
    (e.g. a pop-out media player).

    Wayland already covers much of this but there does seem to be a gap for
    a niche set of use cases. It always seems to be the same application mentioned each time this comes up, so it’s unclear if the niche is
    bigger than 1.

    Okay, here's one niche use case:

    - I want to run a shell script that opens four xterms (or
    similar), and on the command line that starts each instance
    the script specifies colors and screen size/position.

    - On another day of the week, I have a different shell script
    that opens nine xterms (or similar). Again, each command
    line in the script specifies colors and screen
    size/positions.

    Here's another:

    - I want to monitor a group of maybe a dozen machines involved
    in a performance benchmark, so I have a script that opens a
    small monitoring application (maybe xload or "vmstat 3" or
    similar) on various machines. I would use the equivalent of
    "ssh -X ..." to launch them, since IIUC Wayland doesn't do
    network transparency (defined as a client application
    throwing its display to display server).

    Oh, another:

    - I want to open several web browser windows in specific screen
    sizes and positions to run a web app.
    --
    Robert Riches
    spamtrap42@jacob21819.net
    (Yes, that is one of my email addresses.)
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.sys.raspberry-pi on Sun Jul 12 05:53:42 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 12 Jul 2026 03:55:03 GMT, Robert Riches wrote:

    Okay, here's one niche use case:

    - I want to run a shell script that opens four xterms (or
    similar), and on the command line that starts each instance
    the script specifies colors and screen size/position.

    If you want total control over how things are laid out, put them all
    in the same window. In this case, open the terminal sessions as panels
    in a single window.

    (Note that, in both X11 and Wayland, “window” is not synonymous with “contiguous rectangular region of opaque pixels”.)

    Here's another:

    - I want to monitor a group of maybe a dozen machines involved
    in a performance benchmark, so I have a script that opens a
    small monitoring application (maybe xload or "vmstat 3" or
    similar) on various machines. I would use the equivalent of
    "ssh -X ..." to launch them, since IIUC Wayland doesn't do
    network transparency (defined as a client application
    throwing its display to display server).

    <https://packages.debian.org/trixie/waypipe>
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Richard Kettlewell@invalid@invalid.invalid to comp.sys.raspberry-pi on Sun Jul 12 09:07:05 2026
    From Newsgroup: comp.sys.raspberry-pi

    Robert Riches <spamtrap42@jacob21819.net> writes:
    On 2026-07-11, Richard Kettlewell <invalid@invalid.invalid> wrote:
    Daniel James <daniel@me.invalid> writes:
    On 09/07/2026 23:58, Lawrence D’Oliveiro wrote:
    One thing is for sure: giving control to the apps themselves is never
    going to be the optimal solution.

    It's not clear to me that there is any one solution that is optimal in
    all cases.

    It's certainly nice to allow the apps to be able to request a
    particular size/position, but of course the wm should be able to
    ignore the request if that location makes no sense. No, the app
    shouldn't have *control*, just be able to express a preference.

    I would argue that for the most part, the window position preferences
    (or outright control) should come from the user, not the application at
    all. That does point to a system-level component (window manager,
    compositor, whatever) managing positions, following user configuration,
    rather than the application.

    There is some nuance here when an application either opens more than one
    window, or opens a window that is in some way logically connected to
    another application. Depending on what’s going on it might be
    preferrable for the new window to be overlapping the existing window
    (e.g. menus, tooltips, confirmation dialogs, etc), or it might be
    preferrable for it to not overlapping the existing window if possible
    (e.g. a pop-out media player).

    Wayland already covers much of this but there does seem to be a gap for
    a niche set of use cases. It always seems to be the same application
    mentioned each time this comes up, so it’s unclear if the niche is
    bigger than 1.

    Okay, here's one niche use case:

    - I want to run a shell script that opens four xterms (or
    similar), and on the command line that starts each instance
    the script specifies colors and screen size/position.

    - On another day of the week, I have a different shell script
    that opens nine xterms (or similar). Again, each command
    line in the script specifies colors and screen
    size/positions.

    Here's another:

    - I want to monitor a group of maybe a dozen machines involved
    in a performance benchmark, so I have a script that opens a
    small monitoring application (maybe xload or "vmstat 3" or
    similar) on various machines. I would use the equivalent of
    "ssh -X ..." to launch them, since IIUC Wayland doesn't do
    network transparency (defined as a client application
    throwing its display to display server).

    Oh, another:

    - I want to open several web browser windows in specific screen
    sizes and positions to run a web app.

    i.e. you want user control of window positions, which is what I’m
    arguing for:

    | I would argue that for the most part, the window position preferences
    | (or outright control) should come from the user, not the application
    | at all.

    This is not inconsistent with the user control being expressed via a
    window manager rather than through the application, so I have no idea
    what point you’re trying to make here.
    --
    https://www.greenend.org.uk/rjk/
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Robert Riches@spamtrap42@jacob21819.net to comp.sys.raspberry-pi on Sun Jul 12 16:06:44 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 2026-07-12, Richard Kettlewell <invalid@invalid.invalid> wrote:
    Robert Riches <spamtrap42@jacob21819.net> writes:
    On 2026-07-11, Richard Kettlewell <invalid@invalid.invalid> wrote:
    Daniel James <daniel@me.invalid> writes:
    On 09/07/2026 23:58, Lawrence D’Oliveiro wrote:
    One thing is for sure: giving control to the apps themselves is never >>>>> going to be the optimal solution.

    It's not clear to me that there is any one solution that is optimal in >>>> all cases.

    It's certainly nice to allow the apps to be able to request a
    particular size/position, but of course the wm should be able to
    ignore the request if that location makes no sense. No, the app
    shouldn't have *control*, just be able to express a preference.

    I would argue that for the most part, the window position preferences
    (or outright control) should come from the user, not the application at
    all. That does point to a system-level component (window manager,
    compositor, whatever) managing positions, following user configuration,
    rather than the application.

    There is some nuance here when an application either opens more than one >>> window, or opens a window that is in some way logically connected to
    another application. Depending on what’s going on it might be
    preferrable for the new window to be overlapping the existing window
    (e.g. menus, tooltips, confirmation dialogs, etc), or it might be
    preferrable for it to not overlapping the existing window if possible
    (e.g. a pop-out media player).

    Wayland already covers much of this but there does seem to be a gap for
    a niche set of use cases. It always seems to be the same application
    mentioned each time this comes up, so it’s unclear if the niche is
    bigger than 1.

    Okay, here's one niche use case:

    - I want to run a shell script that opens four xterms (or
    similar), and on the command line that starts each instance
    the script specifies colors and screen size/position.

    - On another day of the week, I have a different shell script
    that opens nine xterms (or similar). Again, each command
    line in the script specifies colors and screen
    size/positions.

    Here's another:

    - I want to monitor a group of maybe a dozen machines involved
    in a performance benchmark, so I have a script that opens a
    small monitoring application (maybe xload or "vmstat 3" or
    similar) on various machines. I would use the equivalent of
    "ssh -X ..." to launch them, since IIUC Wayland doesn't do
    network transparency (defined as a client application
    throwing its display to display server).

    Oh, another:

    - I want to open several web browser windows in specific screen
    sizes and positions to run a web app.

    i.e. you want user control of window positions, which is what I’m
    arguing for:

    Happy that there's some agreement.

    | I would argue that for the most part, the window position preferences
    | (or outright control) should come from the user, not the application
    | at all.

    This is not inconsistent with the user control being expressed via a
    window manager rather than through the application, so I have no idea
    what point you’re trying to make here.

    For the record, I did not write the "I would argue ..." piece.
    IIUC, it appears you did.

    While it may be possible for user preference to be expressed via
    the window manager, in the cases I'm thinking of, it's much
    easier for the user to simply add the [-]-geometry option to the
    command line (perhaps in a shell script) when launching the
    application(s).
    --
    Robert Riches
    spamtrap42@jacob21819.net
    (Yes, that is one of my email addresses.)
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Robert Riches@spamtrap42@jacob21819.net to comp.sys.raspberry-pi on Sun Jul 12 16:14:28 2026
    From Newsgroup: comp.sys.raspberry-pi

    On 2026-07-12, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
    On 12 Jul 2026 03:55:03 GMT, Robert Riches wrote:

    Okay, here's one niche use case:

    - I want to run a shell script that opens four xterms (or
    similar), and on the command line that starts each instance
    the script specifies colors and screen size/position.

    If you want total control over how things are laid out, put them all
    in the same window. In this case, open the terminal sessions as panels
    in a single window.

    Perhaps you did not understand. The xterms or whatever are the
    applications. I'm just want to use something like [-]-geometry
    when launching instances of the applications so that they are
    arranged how I (as the user) want them.

    Or, perhaps you're just following the far-too-frequently observed
    pattern of, "The Wayland way is the _ONLY_ way!"

    (Note that, in both X11 and Wayland, “window” is not synonymous with “contiguous rectangular region of opaque pixels”.)

    Yes, there are a few things that create windows that are not
    rectangular.

    Here's another:

    - I want to monitor a group of maybe a dozen machines involved
    in a performance benchmark, so I have a script that opens a
    small monitoring application (maybe xload or "vmstat 3" or
    similar) on various machines. I would use the equivalent of
    "ssh -X ..." to launch them, since IIUC Wayland doesn't do
    network transparency (defined as a client application
    throwing its display to display server).

    <https://packages.debian.org/trixie/waypipe>

    Nice that somebody finally came around to seeing that some form
    of network transparency is needed. However, the real beauty of
    X's network transparency is not in 'ssh -X', it is in putting a
    hostname or IP address in the value of $DISPLAY so that X clients
    can access X display servers wherever they may be.
    --
    Robert Riches
    spamtrap42@jacob21819.net
    (Yes, that is one of my email addresses.)
    --- Synchronet 3.22a-Linux NewsLink 1.2