Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.raspberry-pi > #38169 > unrolled thread

odd windowing issue (perl Tk)

Back to article view | Back to comp.sys.raspberry-pi

Contents

  odd windowing issue (perl Tk) Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2026-07-08 12:03 +0100
    Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-08 17:04 +0000
      Re: odd windowing issue (perl Tk) Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2026-07-08 19:57 +0100
    Re: odd windowing issue (perl Tk) rbowman <bowman@montana.com> - 2026-07-08 17:33 +0000
      Re: odd windowing issue (perl Tk) Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2026-07-08 19:54 +0100
    Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-08 23:17 +0000
      Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-09 02:46 +0000
        Re: odd windowing issue (perl Tk) rbowman <bowman@montana.com> - 2026-07-09 04:34 +0000
          Re: odd windowing issue (perl Tk) Daniel James <daniel@me.invalid> - 2026-07-09 11:14 +0100
            Re: odd windowing issue (perl Tk) druck <news@druck.org.uk> - 2026-07-09 18:31 +0100
              Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-09 22:59 +0000
                Re: odd windowing issue (perl Tk) rbowman <bowman@montana.com> - 2026-07-10 02:54 +0000
            Re: odd windowing issue (perl Tk) rbowman <bowman@montana.com> - 2026-07-09 18:29 +0000
            Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-09 22:58 +0000
              Re: odd windowing issue (perl Tk) Daniel James <daniel@me.invalid> - 2026-07-11 12:32 +0100
                Re: odd windowing issue (perl Tk) Richard Kettlewell <invalid@invalid.invalid> - 2026-07-11 14:05 +0100
                  Re: odd windowing issue (perl Tk) Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2026-07-11 19:37 +0100
                    Re: odd windowing issue (perl Tk) Richard Kettlewell <invalid@invalid.invalid> - 2026-07-11 22:08 +0100
                    Re: odd windowing issue (perl Tk) rbowman <bowman@montana.com> - 2026-07-12 00:01 +0000
                  Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-12 03:55 +0000
                    Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 05:53 +0000
                      Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-12 16:14 +0000
                        Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-12 21:42 +0000
                          Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-12 22:16 +0000
                            Re: odd windowing issue (perl Tk) Richard Kettlewell <invalid@invalid.invalid> - 2026-07-12 23:29 +0100
                              Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-12 23:27 +0000
                                Re: odd windowing issue (perl Tk) Richard Kettlewell <invalid@invalid.invalid> - 2026-07-13 08:37 +0100
                                  Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-13 16:11 +0000
                                    Re: odd windowing issue (perl Tk) Tom Blenko <blenko@martingalesystems.com> - 2026-07-13 16:30 -0700
                                  Re: odd windowing issue (perl Tk) druck <news@druck.org.uk> - 2026-07-13 23:34 +0100
                            Re: odd windowing issue (perl Tk) rbowman <bowman@montana.com> - 2026-07-12 23:25 +0000
                              Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-12 23:30 +0000
                            Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-13 01:16 +0000
                              Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-13 04:16 +0000
                                Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-13 05:50 +0000
                          Re: odd windowing issue (perl Tk) rbowman <bowman@montana.com> - 2026-07-12 23:22 +0000
                            Re: odd windowing issue (perl Tk) Richard Kettlewell <invalid@invalid.invalid> - 2026-07-13 08:31 +0100
                    Re: odd windowing issue (perl Tk) Richard Kettlewell <invalid@invalid.invalid> - 2026-07-12 09:07 +0100
                      Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-12 16:06 +0000
                Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-11 22:07 +0000
        resolved, sort of: Re: odd windowing issue (perl Tk) Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2026-07-09 08:41 +0100

Page 1 of 3  [1] 2 3  Next page →

#38169 — odd windowing issue (perl Tk)

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

[toc] | [next] | [standalone]

#38170

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.)

[toc] | [prev] | [next] | [standalone]

#38176

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

[toc] | [prev] | [next] | [standalone]

#38172

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. 

[toc] | [prev] | [next] | [standalone]

#38175

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

[toc] | [prev] | [next] | [standalone]

#38178

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.

[toc] | [prev] | [next] | [standalone]

#38179

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.)

[toc] | [prev] | [next] | [standalone]

#38180

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.

[toc] | [prev] | [next] | [standalone]

#38183

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.

[toc] | [prev] | [next] | [standalone]

#38184

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

[toc] | [prev] | [next] | [standalone]

#38188

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.

[toc] | [prev] | [next] | [standalone]

#38190

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.

[toc] | [prev] | [next] | [standalone]

#38186

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. 

[toc] | [prev] | [next] | [standalone]

#38187

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.

[toc] | [prev] | [next] | [standalone]

#38209

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.

[toc] | [prev] | [next] | [standalone]

#38211

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/

[toc] | [prev] | [next] | [standalone]

#38215

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

[toc] | [prev] | [next] | [standalone]

#38217

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/

[toc] | [prev] | [next] | [standalone]

#38220

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. 

[toc] | [prev] | [next] | [standalone]

#38221

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.)

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.sys.raspberry-pi

csiph-web