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) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-14 04:09 +0000
                                    Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-14 23:43 +0000
                                      Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-15 03:10 +0000
                                        Re: odd windowing issue (perl Tk) The Natural Philosopher <tnp@invalid.invalid> - 2026-07-15 12:17 +0100
                                        Re: odd windowing issue (perl Tk) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-15 20:59 +0000
                                          Re: odd windowing issue (perl Tk) Robert Riches <spamtrap42@jacob21819.net> - 2026-07-15 23:53 +0000
                                          Re: odd windowing issue (perl Tk) Mike Scott <usenet.16@scottsonline.org.uk.invalid> - 2026-07-16 08:57 +0100
                                  Re: odd windowing issue (perl Tk) druck <news@druck.org.uk> - 2026-07-13 23:34 +0100
                                    Re: odd windowing issue (perl Tk) Richard Kettlewell <invalid@invalid.invalid> - 2026-07-14 08:36 +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 3 of 3 — ← Prev page 1 2 [3]

#38236

On 12 Jul 2026 22:16:40 GMT, Robert Riches wrote:

> On 2026-07-12, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>
>> On 12 Jul 2026 16:14:28 GMT, Robert Riches wrote:
>>
>>> Or, perhaps you're just following the far-too-frequently observed
>>> pattern of, "The Wayland way is the _ONLY_ way!"
>>
>> I don’t see anybody offering a serious alternative. All I see is
>> people like you, complaining about things changing but not serious
>> about wanting to do something about it.
>
> Why is there a need to do anything?  X works just fine.

Developers have largely ceased updating it, because hardly anybody
sees it as a worthwhile project any more. If you don’t care about
that, fine. But most of those responsible for maintaining
well-supported distros do.

> Without resorting to VNC, RDP, or anything similar, I have
> personally launched X clients that displayed on a display server on
> a different host. All you have to do is use the proper syntax to
> specify the remote display server in $DISPLAY or when calling the
> library function to open the display, set XHost appropriately, and
> supply the XAUTH key/cookie/whatever.

X11 was never “network-transparent”. If the network connection went
down, all those remote X clients would die.

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

#38237

On 2026-07-13, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On 12 Jul 2026 22:16:40 GMT, Robert Riches wrote:
>
>> On 2026-07-12, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> On 12 Jul 2026 16:14:28 GMT, Robert Riches wrote:
>>>
>>>> Or, perhaps you're just following the far-too-frequently observed
>>>> pattern of, "The Wayland way is the _ONLY_ way!"
>>>
>>> I don’t see anybody offering a serious alternative. All I see is
>>> people like you, complaining about things changing but not serious
>>> about wanting to do something about it.
>>
>> Why is there a need to do anything?  X works just fine.
>
> Developers have largely ceased updating it, because hardly anybody
> sees it as a worthwhile project any more. If you don’t care about
> that, fine. But most of those responsible for maintaining
> well-supported distros do.
>
>> Without resorting to VNC, RDP, or anything similar, I have
>> personally launched X clients that displayed on a display server on
>> a different host. All you have to do is use the proper syntax to
>> specify the remote display server in $DISPLAY or when calling the
>> library function to open the display, set XHost appropriately, and
>> supply the XAUTH key/cookie/whatever.
>
> X11 was never “network-transparent”. If the network connection went
> down, all those remote X clients would die.

That's not what the term means, and as someone else already
pointed out, VNC and RDP and anything else would soon follow.  To
help you correct your misunderstanding of the terminology:

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

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

On the former page, please notice the first line and other
supporting statements later in the page.

-- 
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

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

#38238

On 13 Jul 2026 04:16:39 GMT, Robert Riches wrote:

> On 2026-07-13, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>
>> X11 was never “network-transparent”. If the network connection went
>> down, all those remote X clients would die.
>
> That's not what the term means ...

Doesn’t matter what you think it means. That’s what happens,
regardless.

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

#38232

On Sun, 12 Jul 2026 21:42:12 -0000 (UTC), Lawrence D’Oliveiro wrote:

> X11 was never “network-transparent”. If the network connection went
> down,
> all the remote X clients would die.
> 
> To achieve network-transparency, you had to resort to something like VNC
> or RDP. And those sorts of protocols can work equally well with Wayland.

If the network connection goes down VNC and RDP will not be far behind.

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

#38240

rbowman <bowman@montana.com> writes:
> Lawrence D’Oliveiro wrote:
>> X11 was never “network-transparent”. If the network connection went
>> down, all the remote X clients would die.
>> 
>> To achieve network-transparency, you had to resort to something like
>> VNC or RDP. And those sorts of protocols can work equally well with
>> Wayland.
>
> If the network connection goes down VNC and RDP will not be far behind.

But your clients will still be there when you reconnect. With remote X,
or X forwarding, they won’t be.

-- 
https://www.greenend.org.uk/rjk/

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

#38223

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/

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

#38225

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

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

#38218

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.

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

#38181 — resolved, sort of: Re: odd windowing issue (perl Tk)

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

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web