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.)
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.
Under some circumstances, the window manager can override the
size or position parameters. Under some other circumstances, the
application can ignore those parameters.
On the Pi (pi4, 11/bullseye), it opens a window with the correct
size but a very odd position:
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.
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.
Absolute positioning of
windows was something the Wayland developers objected to.
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.
One thing is for sure: giving control to the apps themselves is never
going to be the optimal solution.
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.
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 :-{
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.
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.
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).
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.
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>
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.
Or, perhaps you're just following the far-too-frequently observed
pattern of, "The Wayland way is the _ONLY_ way!"
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> 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.
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.
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.
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.
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.
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?'
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 ...
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.
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.
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.
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.
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.
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> 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.
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.
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
An analogous thing happens in SQL database design.
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!?
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.
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.
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.
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.
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 yes, then why not let this be done programmatically and save the
user a probably repetitive task?
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?
| Sysop: | Weed Hopper |
|---|---|
| Location: | Clearwater, FL |
| Users: | 16 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 15:02:13 |
| Calls: | 155 |
| Files: | 50,638 |
| D/L today: |
35 files (4,393K bytes) |
| Messages: | 348,399 |