odd windowing issue (perl Tk)

Under some circumstances, the window manager can override the size or position parameters. Under some other circumstances, the application can ignore those parameters.

There is a program called devilspie (apparently named after a song) that can force new (or old) windows to specified sizes and positions.

What is XDG_SESSION_TYPE? Mint is X11. I'm running the latest Trixie derivative on the Pi and it is Wayland. I'm wondering if an older XWayland isn't doing the job.

Thanks for the comment.

X11 (on both)

Presumably the wm's differ. But /anything/ positioning a window outside the screen real estate after ignoring the user's request is most assuredly broken.

Looks like I'll have to write some simpler test code to see what's happening.

Thanks for the thought.

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.

afaik, you had better stick with X11 distros. Absolute positioning of windows was something the Wayland developers objected to.

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.

That seems short-sighted.

In my former life as a Windows (cough!) developer we took some trouble to open our main application window at the same position on the screen as it had been when the application was last closed (and stored screen size/position values for different screen sizes/resolutions for the benefit of those who copied the application between their laptop and desktop PCs). It was a popular feature.

I really do *NOT* like the fact that on this (stock RaspiOS) Pi the wm chooses to open each and every application right in the centre of the screen and I have to move them all around to acceptable places.

The whole Wayland project seems to be the blind leading the short-sighted.

Luckily switching back to the fully functional X11 is easy. Turn rsyslog back on too, and you have a usable system.

---druck

Reading some of the discussions by the Wayland developers security was the chief concern followed by the cosmetic problems of a window positioning itself over a dock and so forth.

I spent about 25 years working with legacy Motif applications. The MKS NutCracker tools allowed us to port the code, which originally had been developed for RS6000/AIX machines, to Windows.

Anyway, when you work with Motif you find yourself dipping into the Xt and Xlib to get anything down and the low level interface to the X server certainly could be abused. You could create a full screen modal window and stop everything in its tracks until the dispatcher responded to an emergency alert for example.

While the GNOME, QT, and other widget toolkits sat on the same X11 infrastructure they provided a level of abstraction that didn't encourage the low level coding that Motif or Athena allowed or even necessitated.

I can understand the design decisions behind Wayland. otoh I'm glad I didn't have to move the legacy Motif apps to Wayland. Our new product retained the backend service structure but used a web based Angular front end. It was easier to start afresh than attempt to untangle decades of legacy X11 code.

X11 won't go away and there are new forks like XLibre to keep it alive, just like there are DEs based on GNOME 2 produced by developers disappointed with GNOME 3.

That’s an issue with the window manager.

On my KDE Plasma system, the default window manager behaviour seems to be to put windows wherever there is a convenient gap among the existing windows on the current desktop.

One thing is for sure: giving control to the apps themselves is never going to be the optimal solution.

Feel free to sponsor the development of alternatives that are more simpatico with your particular weltanschauung.

Free Software is all about having a choice.

It will be interesting this fall with KDE/Plasma 6.8 that will be Wayland only. I expect my Fedora box which is at 6.7 will go. Leap 16 is still

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.

I rather depends on the use, i suspect. That warning window really may need to position itself screen dead centre on top of everything else to make the realise there's a problem with the automatic reactor emergency shutdown :-{

That’s not inconsistent with policy being in the window manager (or compositor or or whatever).

Personally I think that having the warning obscure whatever outputs and controls you might use to further investigate and mitigate the problem doesn’t seem like a great idea.

It’s not clear that that preference would be useful in enough cases to bother.