odd windowing issue (perl Tk)

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.

Thank you for describing your experience and perspective.

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.

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.

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.

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?

Yes.

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

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.

Of course.

Naturally that can be done, too. But not by asking the application program; this is now controlled by the window manager.

You already have this sort of thing under many window managers on X11; the GUi application was never totally in control of where its windows were placed, since user-definable window manager rules could override such placement.

The only way to get total control over placement under X11 was to run without a window manager.

I think they may well understand X11 very well, they just don't understand other people value a completely different set of features than they do, and rightly get annoyed that not only do Wayland developers refuse to implement them, but tell them they are wrong for even wanting them.

That's the hill, there are the bodies.

---druck

Just because you value a certain set of features, doesn’t mean that anybody else is obligated to implement them for you.

If you think those features would be so useful to others, get a group together to implement them yourself.

After all, that’s how projects like Wayland and systemd got started in the first place. Oh, and Linux itself, and X11 before that, and ...

Keep asking for what you want and you may just get it. Or implement it yourself

'Anybody' already had implemented them in X11, that's why we are quite happy with that.

Plenty of people already have, but the Wayland developers have refused to accept those features, as they differ from their ideas of what it should and shouldn't do. I would have thought you would understand this by now.

Wayland and Systemd were started by RedHat to lock people in to their distro, its development philosophy is diametrically opposed to that of Linux and X11.

Your posts give me the impression that you have very little idea about how windowing systems or open source projects work, but very much like to start arguments, so feel free to carry on, on your own.

---druck

I note that under XWayland, at least here, xterm -geometry appears to work as expected. So “you can keep using X11” doesn’t reduce to “you can keep using software that’s on an abandonment track”, which would hardly be an appealing proposition. Still, whether that’s true of all XWayland deployments I don’t know.

That’s not really accurate, for example MR264 got merged years ago. More to do with multi-window applications than exact application control over window positioning, but the point is that situation is not “Wayland developer refuse to accept things”.

Sounds like a conspiracy theory to me. How does this lock-in work in practice? It doesn’t seem to be very effective, I have systemd-based platforms, and a three-layer rendering software chain with Wayland in the middle, and yet no RedHat in sight.

As far as I can tell the reality is that everyone was trying to replace sysv init a few years back (something that was desparately overdue), and systemd is the one that got most uptake. Much the same as happened with version control systems (git largely won, against a crowded field) and Unix platforms (Linux won against numerous free and proprietary alternatives).

Red Hat failed rather spectacularly if that was the motivation. I'm running the Trixie derived Raspberry Pi OS on a Pi 5 with systemd/wayland. Both the Fedora and SUSE Leap 16 machines are KDE with systemd/wayland. The Ubuntu 26.04 mini is systemd/wayland. The Mint laptop is systemd/X11. In as much as they can be called 'competitors' SUSE, Debian, and Ubuntu adopted them. I ran EndeavourOS/KDE for a while with systemd/wayland. It's Arch based and I think Arch was an early systemd adopter.

I have MX/Xfce in a VM and antiX on an old eeePC. Both are SysVinit/X11. I believe the MX/KDE version is wayland.

Since I don't work with Motif anymore I don't have a dog in the fight but you have to go out of your way to find distros that haven't went to both. Even Mint is trying to get Cinnamon running on wayland. I've selected the 'experimental' Cinnamon/wayland session and the last time I did it had problems.

MX defaults to sysVinit but offers both.

Personally, I don't miss sysVinit.

He is an arrogant little s*it who doesn't respect users either. He writes stuff, gets bored and moves on, leaving others to sort out the trail of excrement he has left behind.

Pulse audio should have been a warning,. systemd is now here and we must do all the work he was too lazy to do, to make it work...

I'm not fond of PulseAudio and friends but systemd works.