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)

Started byMike Scott <usenet.16@scottsonline.org.uk.invalid>
First post2026-07-08 12:03 +0100
Last post2026-07-09 08:41 +0100
Articles 20 on this page of 50 — 9 participants

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) Richard Kettlewell <invalid@invalid.invalid> - 2026-07-16 17:52 +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 2 of 3 — ← Prev page 1 [2] 3  Next page →


#38222

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-07-12 05:53 +0000
Message-ID<112va56$2jf86$2@dont-email.me>
In reply to#38221
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>

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


#38226

FromRobert Riches <spamtrap42@jacob21819.net>
Date2026-07-12 16:14 +0000
Message-ID<slrn1157fb4.77u.spamtrap42@one.localnet>
In reply to#38222
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.)

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


#38229

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-07-12 21:42 +0000
Message-ID<11311nj$34pmm$5@dont-email.me>
In reply to#38226
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.

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

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.

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


#38230

FromRobert Riches <spamtrap42@jacob21819.net>
Date2026-07-12 22:16 +0000
Message-ID<slrn11584i8.rs.spamtrap42@one.localnet>
In reply to#38229
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.  What
happened to the motto of not fixing something if it's not broken?
Why is there such a mad rush to re-invent things but do so more
poorly than the original, working solution?

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

Wrong!  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.

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

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


#38231

FromRichard Kettlewell <invalid@invalid.invalid>
Date2026-07-12 23:29 +0100
Message-ID<wwvy0ff3kpl.fsf@LkoBDZeT.terraraq.uk>
In reply to#38230
Robert Riches <spamtrap42@jacob21819.net> writes:
> 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.  What
> happened to the motto of not fixing something if it's not broken?
> Why is there such a mad rush to re-invent things but do so more
> poorly than the original, working solution?

‘Why’ is covered in the FAQ.

https://wayland.freedesktop.org/faq.html

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

That has very limited usefulness today due to its unacceptably poor
security.

>> 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.
>
> Wrong!  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.

Lawrence is right that your clients die if the network goes down
(e.g. if the client endpoint sleeps, which is the usual reason my remote
X clients fail).

Whether that’s the definition of ‘network transaprent’ I’ll not take a
view on. But it’s certainly inconvenient.

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

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


#38234

FromRobert Riches <spamtrap42@jacob21819.net>
Date2026-07-12 23:27 +0000
Message-ID<slrn11588nf.4f3.spamtrap42@one.localnet>
In reply to#38231
On 2026-07-12, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Robert Riches <spamtrap42@jacob21819.net> writes:
>> 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.  What
>> happened to the motto of not fixing something if it's not broken?
>> Why is there such a mad rush to re-invent things but do so more
>> poorly than the original, working solution?
>
> ‘Why’ is covered in the FAQ.
>
> https://wayland.freedesktop.org/faq.html

Yes, and those who have chosen to pathetically re-implement ntpd
for systemd (throwing out everything that makes ntpd a superior
solution) have similar justifications for their needless efforts.

There's a quote, something to the effect that those who do not
understand Unix will be condemned to re-implement it--poorly.
The same seems appropriate when describing systemd's poor
imitation of ntpd and Wayland.

>>>> 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.
>
> That has very limited usefulness today due to its unacceptably poor
> security.

Yes, but in those cases where it is useful (far inside more than
a few levels of security fencing and such), it's still useful and
consumes a lot less resources than ssh -X.

>>> 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.
>>
>> Wrong!  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.
>
> Lawrence is right that your clients die if the network goes down
> (e.g. if the client endpoint sleeps, which is the usual reason my remote
> X clients fail).

The first part about clients dying if the network connection goes
down is so obviously trivial that it doesn't deserve comment.  I
think that gimmick might be called a red herring.

Where Lawrence is wrong is that X does not require ssh -X, VNC,
RDP, or anything similar to do X displaying across a network.
That is what is normally meant by X's network transparency.

> Whether that’s the definition of ‘network transaprent’ I’ll not take a
> view on. But it’s certainly inconvenient.

Not sure what you mean is inconvenient.

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

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


#38241

FromRichard Kettlewell <invalid@invalid.invalid>
Date2026-07-13 08:37 +0100
Message-ID<wwvik6j49x3.fsf@LkoBDZeT.terraraq.uk>
In reply to#38234
Robert Riches <spamtrap42@jacob21819.net> writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Robert Riches <spamtrap42@jacob21819.net> writes:
>>> Why is there a need to do anything?  X works just fine.  What
>>> happened to the motto of not fixing something if it's not broken?
>>> Why is there such a mad rush to re-invent things but do so more
>>> poorly than the original, working solution?
>>
>> ‘Why’ is covered in the FAQ.
>>
>> https://wayland.freedesktop.org/faq.html
>
> Yes, and those who have chosen to pathetically re-implement ntpd
> for systemd (throwing out everything that makes ntpd a superior
> solution) have similar justifications for their needless efforts.
>
> There's a quote, something to the effect that those who do not
> understand Unix will be condemned to re-implement it--poorly.
> The same seems appropriate when describing systemd's poor
> imitation of ntpd and Wayland.

Wayland was largely created by X11 developers. They know a lot more
about it than you.

>>>>> 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.
>>
>> That has very limited usefulness today due to its unacceptably poor
>> security.
>
> Yes, but in those cases where it is useful (far inside more than
> a few levels of security fencing and such), it's still useful and
> consumes a lot less resources than ssh -X.

SSH is the ‘security fencing’, and consumes almost no resources on
modern hardware (meaning last 20 years or so).

>> Lawrence is right that your clients die if the network goes down
>> (e.g. if the client endpoint sleeps, which is the usual reason my remote
>> X clients fail).
>
> The first part about clients dying if the network connection goes
> down is so obviously trivial that it doesn't deserve comment.  I
> think that gimmick might be called a red herring.
>
> Where Lawrence is wrong is that X does not require ssh -X, VNC,
> RDP, or anything similar to do X displaying across a network.
> That is what is normally meant by X's network transparency.
>
>> Whether that’s the definition of ‘network transaprent’ I’ll not take a
>> view on. But it’s certainly inconvenient.
>
> Not sure what you mean is inconvenient.

It was literally in the previous paragraph:

| Lawrence is right that your clients die if the network goes down
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| (e.g. if the client endpoint sleeps, which is the usual reason my remote
| X clients fail).
| 
| Whether that’s the definition of ‘network transaprent’ I’ll not take a
| view on. But it’s certainly inconvenient.

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

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


#38243

FromRobert Riches <spamtrap42@jacob21819.net>
Date2026-07-13 16:11 +0000
Message-ID<slrn115a3i3.ki8.spamtrap42@one.localnet>
In reply to#38241
On 2026-07-13, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Robert Riches <spamtrap42@jacob21819.net> writes:
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> Robert Riches <spamtrap42@jacob21819.net> writes:
>>>> Why is there a need to do anything?  X works just fine.  What
>>>> happened to the motto of not fixing something if it's not broken?
>>>> Why is there such a mad rush to re-invent things but do so more
>>>> poorly than the original, working solution?
>>>
>>> ‘Why’ is covered in the FAQ.
>>>
>>> https://wayland.freedesktop.org/faq.html
>>
>> Yes, and those who have chosen to pathetically re-implement ntpd
>> for systemd (throwing out everything that makes ntpd a superior
>> solution) have similar justifications for their needless efforts.
>>
>> There's a quote, something to the effect that those who do not
>> understand Unix will be condemned to re-implement it--poorly.
>> The same seems appropriate when describing systemd's poor
>> imitation of ntpd and Wayland.
>
> Wayland was largely created by X11 developers. They know a lot more
> about it than you.

Ahhh, yes...  The "My dad is smarter than your dad" card was very
popular on the grade-school playground.

Without an equivalent or replacement for the [-]-geometry option
when starting a simple (rectangular) client, a graphical
windowing system is nearly as useless as Mickey$oft WinDoze.
Being able to do the equivalent of "xterm -geometry
48x16+100+200" or "mplayer -geometry 720x480+200+300" is
essential functionality.

Parsimony is generally a good thing, but it be overdone to the
point of impracticality.  Software engineering academics will
preach parsimony as an absolute goal.  However, the benefits of
parsimony need to be balanced against practical considerations in
order to achieve useful results.

An analogous thing happens in SQL database design.  Academics
preach normalization at an absolute goal.  However, with a
sufficiently complex system, full normalization can require each
query to use an excessive number of joins, and that can adversely
affect performance.  Those with practical experience in DB design
will concede that sometimes you need to denormalize slightly in
order to get reasonable performance.

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

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


#38245

FromTom Blenko <blenko@martingalesystems.com>
Date2026-07-13 16:30 -0700
Message-ID<130720261630311554%blenko@martingalesystems.com>
In reply to#38243
In article <slrn115a3i3.ki8.spamtrap42@one.localnet>, Robert Riches
<spamtrap42@jacob21819.net> wrote:

> An analogous thing happens in SQL database design.  Academics
> preach normalization at an absolute goal.  However, with a
> sufficiently complex system, full normalization can require each
> query to use an excessive number of joins, and that can adversely
> affect performance.  Those with practical experience in DB design
> will concede that sometimes you need to denormalize slightly in
> order to get reasonable performance.

This is nonsense and a good hint is that you are putting words in the
mouths of others and then attacking them for those words.

I've never taken a database course but I had nearly 20 years of
database design in industry for mid-level systems. I have read some
database books written by academics along the way. The claim that they
"preach normalization at (sic) an absolute goal" is plain wrong in my
experience.

The academic books I've read describe multiple normal forms. I don't
recall ever seeing one singled as superior to all the others, different
normal forms reflect different (generally theoretical) perspectives on
data and the relational calculus. Not surprising, I think, and I am
confident that being informed about different perspectives has helped
me design systems.

Database design requires a designer to balance various factors,
including where the data comes from, how it is to be maintained, and
how it is to be used (including performance of queries). I have no idea
which of all the tables I've designed and run in production may or may
not be normalized by any of the multiple normalizations that have been
described. But I read those books in order to improve my skills and it
was time well spent.

   Tom

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


#38246

FromRobert Riches <spamtrap42@jacob21819.net>
Date2026-07-14 04:09 +0000
Message-ID<slrn115bdjb.bvd.spamtrap42@one.localnet>
In reply to#38245
On 2026-07-13, Tom Blenko <blenko@martingalesystems.com> wrote:
> In article <slrn115a3i3.ki8.spamtrap42@one.localnet>, Robert Riches
><spamtrap42@jacob21819.net> wrote:
>
>> An analogous thing happens in SQL database design.  Academics
>> preach normalization at an absolute goal.  However, with a
>> sufficiently complex system, full normalization can require each
>> query to use an excessive number of joins, and that can adversely
>> affect performance.  Those with practical experience in DB design
>> will concede that sometimes you need to denormalize slightly in
>> order to get reasonable performance.
>
> This is nonsense and a good hint is that you are putting words in the
> mouths of others and then attacking them for those words.
>
> I've never taken a database course but I had nearly 20 years of
> database design in industry for mid-level systems. I have read some
> database books written by academics along the way. The claim that they
> "preach normalization at (sic) an absolute goal" is plain wrong in my
> experience.

Yes, you caught my typo.

It appears your experience differs from mine.  Evidently, the
academics who wrote the books you read had a different take from
the professors who taught my DB courses at Oregon Graduate
Institute in 2001 and those who wrote the articles I studied with
colleagues around 2024-2025.  I'm glad you had the good fortune
in your study and practical experience to see and adopt a more
balanced approach.

> The academic books I've read describe multiple normal forms. I don't
> recall ever seeing one singled as superior to all the others, different
> normal forms reflect different (generally theoretical) perspectives on
> data and the relational calculus. Not surprising, I think, and I am
> confident that being informed about different perspectives has helped
> me design systems.
>
> Database design requires a designer to balance various factors,
> including where the data comes from, how it is to be maintained, and
> how it is to be used (including performance of queries). I have no idea
> which of all the tables I've designed and run in production may or may
> not be normalized by any of the multiple normalizations that have been
> described. But I read those books in order to improve my skills and it
> was time well spent.
>
>    Tom

Thank you for describing your experience and perspective.

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

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


#38248

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-07-14 23:43 +0000
Message-ID<1136hi9$pd9r$1@dont-email.me>
In reply to#38243
On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:

> An analogous thing happens in SQL database design.

It does seem like you are trying to distract attention from the
X11-versus-Wayland discussion. Your argument there is collapsing, so
you try to pull the old smokescreen switcharoo: “Never mind that, look
over here!”

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


#38249

FromRobert Riches <spamtrap42@jacob21819.net>
Date2026-07-15 03:10 +0000
Message-ID<slrn115duh6.mr0.spamtrap42@one.localnet>
In reply to#38248
On 2026-07-14, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:
>
>> An analogous thing happens in SQL database design.
>
> It does seem like you are trying to distract attention from the
> X11-versus-Wayland discussion. Your argument there is collapsing, so
> you try to pull the old smokescreen switcharoo: “Never mind that, look
> over here!”

Collapsing?  No, with the lack of mention of any sort of
replacement for the essential [-]-geometry option to launch
simple clients (xterm, mplayer, for example), it's the
pro-Wayland argument that has collapsed.

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

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


#38250

FromThe Natural Philosopher <tnp@invalid.invalid>
Date2026-07-15 12:17 +0100
Message-ID<1137q7g$148pt$3@dont-email.me>
In reply to#38249
On 15/07/2026 04:10, Robert Riches wrote:
> On 2026-07-14, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>> On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:
>>
>>> An analogous thing happens in SQL database design.
>>
>> It does seem like you are trying to distract attention from the
>> X11-versus-Wayland discussion. Your argument there is collapsing, so
>> you try to pull the old smokescreen switcharoo: “Never mind that, look
>> over here!”
> 
> Collapsing?  No, with the lack of mention of any sort of
> replacement for the essential [-]-geometry option to launch
> simple clients (xterm, mplayer, for example), it's the
> pro-Wayland argument that has collapsed.
> 

I am reminds me of a friend who said 'you can't program in C on an Apple 
II' and I said 'why?'  and he said 'there is no key for {or }'!

IIRC there was no lower case either.

-- 
The lifetime of any political organisation is about three years before 
its been subverted by the people it tried to warn you about.

Anon.

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


#38253

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-07-15 20:59 +0000
Message-ID<1138sat$1fqaq$2@dont-email.me>
In reply to#38249
On 15 Jul 2026 03:10:30 GMT, Robert Riches wrote:

> On 2026-07-14, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>
>> On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:
>>
>>> An analogous thing happens in SQL database design.
>>
>> It does seem like you are trying to distract attention from the
>> X11-versus-Wayland discussion. Your argument there is collapsing,
>> so you try to pull the old smokescreen switcharoo: “Never mind
>> that, look over here!”
>
> Collapsing? No, with the lack of mention of any sort of replacement
> for the essential [-]-geometry option to launch simple clients
> (xterm, mplayer, for example), it's the pro-Wayland argument that
> has collapsed.

Well, then, you need to put your money where your mouth is, right? If
your argument hasn’t “collapsed”, then you need to point out what’s
holding it up.

Start by explaining why window-arrangement options should be
reimplemented (often inconsistently) by every single X11 app, instead
of being handled once and for all in the window manager.

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


#38254

FromRobert Riches <spamtrap42@jacob21819.net>
Date2026-07-15 23:53 +0000
Message-ID<slrn115g7bk.gsq.spamtrap42@one.localnet>
In reply to#38253
On 2026-07-15, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On 15 Jul 2026 03:10:30 GMT, Robert Riches wrote:
>
>> On 2026-07-14, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> On 13 Jul 2026 16:11:47 GMT, Robert Riches wrote:
>>>
>>>> An analogous thing happens in SQL database design.
>>>
>>> It does seem like you are trying to distract attention from the
>>> X11-versus-Wayland discussion. Your argument there is collapsing,
>>> so you try to pull the old smokescreen switcharoo: “Never mind
>>> that, look over here!”
>>
>> Collapsing? No, with the lack of mention of any sort of replacement
>> for the essential [-]-geometry option to launch simple clients
>> (xterm, mplayer, for example), it's the pro-Wayland argument that
>> has collapsed.
>
> Well, then, you need to put your money where your mouth is, right? If
> your argument hasn’t “collapsed”, then you need to point out what’s
> holding it up.
>
> Start by explaining why window-arrangement options should be
> reimplemented (often inconsistently) by every single X11 app, instead
> of being handled once and for all in the window manager.

If the window manager wants to do the placement and sizing, it
might be possible for that to work.  However, to be usable from
the user's perspective, it shouldn't be much more difficult for
the user to specify the size and location of each window.  Being
as the user doesn't routinely communicate directly with the
window manager, it might be a little difficult for the user to
tell the window manager where to place a specific window
instance.

With X, if I as user write a script to instantiate a dozen (or
more) xterms, mplayer instances, or whatever client, arranged in
a grid, a diagonal cascade arrangement, or whatever, the cost to
me is at most a couple dozen characters on each command line:
'-geometry 215x215+2010-0' or similar.  The parameters for each
instance are local to the command that launches that instance.
From the user's perspective, it's simple and clean.

It has been a long time since I coded my own X oscilloscope
program and such, but if I remember correctly, there might be an
X library function that causes the X library to read the common
X-defined options.  Or, perhaps I had to parse the option and
hand the parameter string to an X library function when I created
the window.  Either way, it was at most a small handful of lines
of code.  Documentation could supply a sample of that code, which
should solve the inconsistency problem, unless application
developers really want to be inconsistent.  Whether it was a
library function or a function argument, the net effect was for
the application instance to tell the library, "This is where the
user wants the window created."

If Wayland developers simply cannot cope with the application
being launched acting as a go-between from the user to a library
or to the window manager, an alternative might be a single
command that would take the geometry parameters and the rest of
the command line.  For example, instead of X's

    xterm -geometry 48x16+100+200 -title ...

the user could do something like this:

    launchWithGeometry 48x16+100+200 xterm -title ...

That way, the geometry processing could be done only once by the
launchWithGeometry program.  The xterm or mplayer or whatever
would never see the geometry parameters.  It might look a little
odd to the user, but it's not difficult enough to be much of a
barrier.

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

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


#38255

FromMike Scott <usenet.16@scottsonline.org.uk.invalid>
Date2026-07-16 08:57 +0100
Message-ID<113a2tq$1plcq$1@dont-email.me>
In reply to#38253
On 15/07/2026 21:59, Lawrence D’Oliveiro wrote:
> Well, then, you need to put your money where your mouth is, right? If
> your argument hasn’t “collapsed”, then you need to point out what’s
> holding it up.
> 
> Start by explaining why window-arrangement options should be
> reimplemented (often inconsistently) by every single X11 app, instead
> of being handled once and for all in the window manager.

I'm getting muddled here. I've never used Wayland, so please excuse a 
probably naive comment.

Suppose I start a program that pops up a window. Can I put this where I 
want on the screen, presumably by a mouse drag'n'drop operation? Can I 
raise and lower relative to other windows? If either answer is 'no', I'd 
question the use of such a system. If yes, then why not let this be done 
programmatically and save the user a probably repetitive task?

I've seen comments about 'security'; but we live in a real world and 
usability and security are IME both tradeoffs. Has Wayland erred on the 
too-secure side?

-- 
Mike Scott
Harlow, England

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


#38256

FromRichard Kettlewell <invalid@invalid.invalid>
Date2026-07-16 17:52 +0100
Message-ID<wwvbjc6512g.fsf@LkoBDZeT.terraraq.uk>
In reply to#38255
Mike Scott <usenet.16@scottsonline.org.uk.invalid> writes:
> Lawrence D’Oliveiro wrote:

>> Well, then, you need to put your money where your mouth is, right? If
>> your argument hasn’t “collapsed”, then you need to point out what’s
>> holding it up.  Start by explaining why window-arrangement options
>> should be reimplemented (often inconsistently) by every single X11
>> app, instead of being handled once and for all in the window manager.
>
> I'm getting muddled here. I've never used Wayland, so please excuse a
> probably naive comment.
>
> Suppose I start a program that pops up a window. Can I put this where
> I want on the screen, presumably by a mouse drag'n'drop operation? Can
> I raise and lower relative to other windows?

Yes.

> If either answer is 'no', I'd question the use of such a system. If
> yes, then why not let this be done programmatically and save the user
> a probably repetitive task?
> 
> I've seen comments about 'security'; but we live in a real world and
> usability and security are IME both tradeoffs. Has Wayland erred on
> the too-secure side?

The thing that Wayland specifically objects to is applications directly
controlling the positions of their windows. While there are some
security concerns about window placement, there’s a lot more to it than
that; see
https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg41606.html
for some discussion.

That is not inconsistent in principle with the user specifying
application window positions, as has already been discussed in this
thread.

Whether any Wayland compositors do in fact support some means for the
user to specify the pixel position an application’s window(s) should
appear at, I do not know, but AFAIK there’s no fundamental reason they
couldn’t.

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

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


#38244

Fromdruck <news@druck.org.uk>
Date2026-07-13 23:34 +0100
Message-ID<1133p4p$3ucs1$1@druck.eternal-september.org>
In reply to#38241
On 13/07/2026 08:37, Richard Kettlewell wrote:
> Wayland was largely created by X11 developers. They know a lot more
> about it than you.

Richard, that's a strange hill to die on.

---druck

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


#38247

FromRichard Kettlewell <invalid@invalid.invalid>
Date2026-07-14 08:36 +0100
Message-ID<wwvse5myqds.fsf@LkoBDZeT.terraraq.uk>
In reply to#38244
druck <news@druck.org.uk> writes:
> Richard Kettlewell wrote:
>> Wayland was largely created by X11 developers. They know a lot more
>> about it than you.
>
> Richard, that's a strange hill to die on.

The context was Robert attacking the Wayland developers, from a position
of evident ignorance, via Henry Spencer’s remark “Those who do not
understand Unix are condemned to reinvent it, poorly”. But the quote
does not fit, indeed it is almost the opposite of a fit: the reality is
that the Wayland developers do understand X11, more so than most, and
that is why they decided to go in a different direction.

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

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


#38233

Fromrbowman <bowman@montana.com>
Date2026-07-12 23:25 +0000
Message-ID<nbim3nFe81rU4@mid.individual.net>
In reply to#38230
On 12 Jul 2026 22:16:40 GMT, Robert Riches wrote:

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

We tended to set 'xhost +'.  'Why is it suddenly snowing on my computer?'

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


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

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


csiph-web