From 1i5t5.duncan at cox.net  Mon May  4 15:20:19 2026
From: 1i5t5.duncan at cox.net (Duncan)
Date: Mon, 4 May 2026 14:20:19 -0000 (UTC)
Subject: KWin causing Firefox windows to be downsized upon restart with
 session restore
References: <2242821.nim5UdQ9Me@bola>
 <pan$ecb91$f8ca6c58$c74bf58f$90676954@cox.net> <18151386.JSOSuDKzn4@bola>
Message-ID: <pan$b55e9$aad03971$974d4054$b92a3905@cox.net>

René J.V. Bertin posted on Wed, 29 Apr 2026 15:34:28 +0200 as excerpted:

> On Tuesday April 28 2026 13:51:34 Duncan wrote:
> 
>>> I thought this was a pure Firefox bug, but it doesn't happen when I
>>> run Xfwm4 (under a KDE environment).
>>> 
>>> I've now seen it in KWin4 and KWin5 5.15.5 and whatever (quite) newer
>>> version is in Devuan Chimaera.
>>> 
>>> It only happens though after I exited the browser properly, not after
>>> an unexpected exit.
> 
> Wow, as usual with your replies, it's a real question where to begin to
> answer! :)

LOL.  Can't disagree. =:^)  And of course my being Autism Spectrum doesn't 
help, as that means I pull in all sorts of only (to neurotypicals) 
remotely/tangentially related bits that /could/ actually end up being 
relevant to the corner-cases that most of the bugs you and I as "advanced" 
users typically post about here.

[Note as I'm about to send.  I really hope this is at least of /some/ 
help.  FWIW it'd probably be the part after the last quoted section if so 
as that most directly addresses your problem at hand.  Because I spent 
/wayy/ too many hours writing and rewriting this.  Of course I try to 
justify it by saying I enhanced my own understanding in the writing, and 
that's true as far as it goes, and I accept that this is classic spectrum 
behavior and that's true too, but it's still unjustifiably long even given 
both of those, so I really hope you get /something/ useful out of it too!]

> Re: libglvnd : I don't even have that installed.

Libglvnd is an interesting library.  What it does is in the name: it 
provides a vendor-neutral (the vnd) OpenGL (the gl) dispatch layer (I was 
going to say abstraction, but looking it up dispatch layer is the more 
accurate term they use) that allows multiple opengl implementations to 
exist on the same system.  It intercepts opengl calls and routes them to 
the on-system implementation it deems appropriate.

In theory it shouldn't be (and isn't) necessary for systems with only a 
single opengl implementation installed (here, mesa), but in addition to 
the choice-of-dispatch functionality it offers, for distros it 
conveniently allows simplifying their OpenGL package dependency logic by 
having most gl/gles reverse-deps depend on libglvnd alone, then having 
libglvnd as a single package location to deal with the OR deps that would 
otherwise have to be duplicated into perhaps hundreds of different gl/
gles-dependent packages.

Back when I experienced the libglvnd (kwin-)aurorae-engine-based windeco 
bug I mentioned, apparently at least one critical OpenGL call the aurorae 
engine made wasn't properly intermediated by libglvnd with only mesa as an 
on-system OpenGL provider (on amdgpu at least), such that while nothing 
crashed (libglvnd apparently took the call correctly, it just did nothing 
with it instead of routing it to mesa), the decoration simply wasn't 
drawn, thereby making it entirely invisible while still responsive to 
clicks on the invisible buttons if one knew where to click, etc.

As that was when Gentoo was just switching to mandatory libglvnd to 
simplify its other OpenGL dependencies, at first I just reverted that 
freshly introduced mandatory depend to keep it off the system and just let 
mesa handle it as it always did... and as a temporary measure that did 
work.  Eventually I could revert my revert and let libglvnd be installed 
because I was no longer using an aurorae-engine-based windeco (so I never 
did really know if/when that invisible-aurorae-based-windeco bug was 
fixed), having switched back to (ultimately my patched) oxygen as windeco.

But that's why you don't have libglvnd installed -- apparently the devuan 
I see you use hasn't done that opengl dependency simplification, and is 
still pulling in its dependencies directly.  (Actually, assuming the 
freedomware policy remains debian-alike that makes sense, as to my 
knowledge mesa's really the only freedomware choice as opengl provider, 
which would make libglvnd an additional layer without a reason that can be 
justified within the freedomware policy.  Gentoo's a bit different in that 
regard since while binaries for most packages are now available, 
primarily, it simply provides automated dependency resolution and 
buildscripts, and while the distro is forbidden by policy from /relying/ 
on non-freedomware, the policy and thus it would seem the devs as a whole 
don't seem to have a problem with making it easier to use with packages 
such as libglvnd that lack a freedomware-only purpose.)

Of course now full gl has been quite legacy for some time and gles less so 
but still legacy relative to vulkan, the newer 3D-rendering kid on the 
block along with wayland (with X and its gl both legacy).  And to the 
degree that gl /is/ legacy, demand for it and thus reverse-depends on it 
are decreasing over time, and with that of course the relevancy of  
libglvnd.  In another five years it's likely to be quite solidly legacy, 
and in a decade, effectively of historical interest only.  (Tho of course 
that hits rather differently when I know I'm addressing someone who still 
has an active kde4 interest...)

> Re: windecos in KWin: in KWin4 I use the one from QtCurve. That was
> sadly never ported to KF5 so with KWin5 I use the Oxygen deco there.
> With small buttons and a 10pt titlebar font (@86DPI) I get titlebars
> that are compact enough even on a 1366x768 LCD panel.

IIRC qtcurve was an effort at a gtk/gnome/qt/kde unified theme.  It seems 
the newest effort in that regard is union, according to the kde git logs 
I've been reading.  I'm not updating quite as frequently due to other 
projects ATM, but last I read the plasma folks were only getting started 
on integration, with the intent to make it so qtwidget (C++) and qtquick/
qtscript apps had a more common theme/look than possible with qt/kde/
plasma5 and 6 to this point.  There seem to be multiple elements to it 
much as there was with oxygen in the kde4 era and breeze in plasma5 and 
current plasma6.  I was under the impression that it was to unify theming 
with gtk apps too, but as I'm writing this I realize I can't claim to know 
that for sure and I may have just gotten that impression from the language 
in the git logs around the qt-scripted vs. qtwidget theming unification.  
But I /think/ it's supposed to be gtk too.

Regardless, if it ends up like qtcurve or the plasma5 default breeze, it's 
not going to appeal much to me.  But there *is* some recent development 
activity around reinvigorating/modernizing oxygen (some of the original 
functionality had bitrotted over the years or in the qt/kf6 port, not to 
crash levels but things like missing transparency in some cases, etc, that 
the refresh is bringing back), so hopefully they'll continue to support 
what will be second-back oxygen along with first-back breeze, along with 
the new union, for another qt/kf/plasma generation or two.

Meanwhile, to explain why titlebar height is such a big deal to me, 
despite my three 50-inch/127cm 4K TVs as monitors.  Two points: First, a 
bigger desktop generally means more windows displayed at once, which means 
more titlebars, which if they're unnecessarily tall, means more wasted 
space, in the absolute if not in percentage.

Second, ultimately, if I'm keeping both app text and titlebar text 
readable without unnecessary padding, a titlebar takes roughly the same 
vertical space as a line of text, so the titlebar is effectively replacing 
a would-be line of app-text that I now can't display because of that 
titlebar.  That's one less line of web-page, one less line of terminal 
text, one less line of an email message or one less message listed in the 
message-list, etc.  And that's if the titlebar is as vertically space-
efficient as possible.  If that titlebar has unnecessary vertical padding, 
that's *two* less lines of app-text displayed instead of one, *two* less 
lines of message displayed, *two* less lines of terminal height.  And 
while the tradeoffs for the loss of *one* such line for a titlebar are 
arguably reasonable -- there are benefits to a visible/readable titlebar 
after all -- I do *not* find it reasonable to have to lose *two* lines of 
app-text for *one* line of titlebar, entirely unnecessarily because of 
some (IMO) "useless" padding someone thought looked nice... without IMO 
giving proper consideration to the efficiency cost of the app-text line 
lost as a result!


> I see I didn't mention it but the issue occurs for me under Wayland too
> (the KF5 install in Devuan Chimaera is recent enough to provide a stable
> Wayland environment). On a side-note: with KWin5's continued support for
> decoration themes I think we must be talking about server-side
> decorations anyway (hooks in the platform plugin to theme CSD would only
> work for Qt-based applications).

Yes, KDE/plasma/kwin definitely still has server-side windecos on 
wayland.  In fact, that was one of the formative debates in early wayland 
history, with the gnome folks initially assuming wayland was going to be 
their opportunity to go client-side-decorations only once and for all, and 
the kde/kwin folks staking out an absolute position that X or wayland, 
they were sticking with server-side decorations, backing it up with their 
technical reasons why server-side was better and insisting on it for kde, 
and maintaining it as an option for wayland. (There's a well known blog 
post where the then kwin lead developer stakes out that position and gives 
his reasons.)

Once the gnome/client-side folks saw kde/kwin was insisting on server-
side, and that it was an absolute position to the point that kde would 
very possibly fork the wayland protocol if that's what it took to keep 
server-side, they relented, and the wayland protocol ended up allowing 
either one.  I'm not sure of the technical details at the protocol level, 
but from what I've seen as a user who regularly follows kwin (among other) 
git logs and from ordinary usage, I'd take it to be an option in the 
protocol now, with both major toolkits (gtk/qt) supporting both, apps 
built on them supporting both by virtue of the toolkit, and the running 
wayland compositor then setting the default for the session.  With  
support in both toolkits, qt/kde apps can do client-side windecos if they 
are running on a compositor where that's the default, and gnome/gtk apps 
can omit drawing their normal client-side decos if they're running on a 
default-server-side-deco compositor.  (And FWIW there's libdecor too, a 
toolkit-independent clientside windecos library for wayland clients.  A 
quick deps query here says mesa-tools and sdl2 are its only installed 
reverse-deps here, and I've way more gtk than that on a kde/plasma 
desktop, so it doesn't seem /too/ popular, but it's there.)

(Too, I have weston installed as a backup wayland compositor (which I 
figure is wise to have because I am after all running live-git kwin, and 
which is vastly simpler in config and dependency terms than trying to keep 
xorg functioning as a backup, and thus much more likely to actually work 
if I need it, but I've not had to use it in years now).  Weston ships its 
own terminal app, weston-terminal, quite usefully so given its rudimentary 
menu or other launching support so launching weston-terminal and then 
launching everything else from it is the workflow I found easiest.  
Anyway, and it was quite informative to compare weston-terminal running on 
kde/kwin/plasma-wayland to weston-terminal running on weston, to konsole 
running on weston, to konsole running on plasma/kwin-wayland.  FWIW 
weston-terminal, unlike gtk-based apps, still has its client-side windeco 
even when run on kwin_wayland, and it's very obvious as it sticks out like 
a sore thumb!  kwin obviously can tell it has client-side decos and 
doesn't add server-side by default, but an interesting exercise I just 
tried was forcing kwin/plasma's normal server-side via kwin window rule 
forcing the titlebar/border on.  Then it has both, the weston-terminal 
client-side windeco appearing inside the kwin window-rule-forced normal 
kwin/plasma servers-side windeco!  It's not particularly /functional/ to 
have both, and of course I use konsole by default in any case, but seeing 
both on the same app at the same time is useful from an educational 
perspective.)

> But the crucial point here is that it is really something specific to
> Firefox's session restore feature, and only when it's allowed to do its
> work properly (or the way it thinks proper).
> 
> It looks like something in the code gets executed when doing a proper
> "quit" updates the actual positions and sizes of the windows that are to
> be restored, and makes an error. Prevent that code from being executed
> by killing the application and windows do return to their expected
> positions and sizes.

Hmm.  Emphasis on the session-restore now, but such that killing allows 
firefox to return to normal size while quitting, thus allowing settings to 
save, has it doing the shrink-by-titlebar-size thing.

But I think you're incorrect in specifying *firefox*'s session restore, 
since my experience is that firefox's session restore handles getting back 
the webpages that were running when it crashed, etc, and that it actually 
does that impressively well at a crash, but that it doesn't handle window 
size, etc (tho that's very likely due to my kwin window rules that handle 
firefox window size).  Rather, I think you were correct in your first post 
when you said you had thought it a firefox bug, but that it doesn't happen 
under xfc4wm (on an otherwise kde environment), so you're now doubting 
that.

IOW, I think it's *kwin's* bug, very likely either the same one I 
experienced back in the day (tho the details of my experience differed but 
the titlebar size difference was the same for both you and I), or another 
related to it, likely with the same root cause.

While your bug seems to be occurring on both X and wayland, it's worth 
noting that kde's wayland session restore (of the desktop session not just 
individual applications) has only recently become a thing, and that in the 
process they've dealt with bugs in the previously X-only session restore 
as well.  But that's /quite/ recently, as in, plasma6 this year recently, 
and while you've mentioned upgrading kde4 to now 5, I've seen nothing 
about 6 and certainly not this-year-recent 6.  So I'm guessing you're 
running into kde/kwin/plasma bugs that have been there for awhile and may 
only have been fixed in this-year-recent kde/plasma6, **IF** it's actually 
session-restore.

But, what I /actually/ think is that it's not /session/ restore so much as 
a different feature that's usually seen in app-(re)launch context but is 
/not/ session-restore, but rather something else...

More precisely, I think it's the behavior that's usually automatic but 
that can be configured in an toggle-on/off fashion for two slightly 
different behaviors, via kde window rules, that being ignore requested 
geometry, and obey geometry restrictions.

Now it used to confuse me what the actual difference was, but somewhere 
aling the line kde/kwin added info icons that upon hover popup 
explanations.  It turns out "geometry restrictions" refers to more 
special-case situations like only expanding a window by a number of pixels 
that corresponds to the height of a text line, for instance, or like 
honoring the width/height ratio (as opposed to specific size) of images 
and video when opening them specifically.  So that rule controls whether 
kwin responds to those special-case requests made when the window is 
opened, say konsole requesting that the window size (at launch and at 
resize) correspond to one that will show a specific number of lines (and 
possibly columns), not lines and a half-line.  If this restriction is 
honored for konsole, resizing the konsole window will be "jumpy" compared 
to resizing it a pixel at a time, since a displayed character will be 
several pixels high and several pixels wide, and the request is to only 
resize accordingly.

Meanwhile, "requested geometry" is the more general case, the actual size 
of the requested window, and I believe that as with my bug several years 
ago (that could well be with the same code you're only now running, since 
I'm on live-git and you're barely upgrading to kde5 and nowhere near 6 let 
alone current 6), the bug is very likely in this feature and code, 
specifically, a bug in how kwin calculates what it thinks is client-side 
vs. server-side windeco titlebar height, and allows for it when it records 
window size on a quitting app, vs recalling and applying that size on a 
freshly started app.  If the window crashes or is killed (-9/sigkill 
kernel-kill with no time to store changed config or settings), firefox (or 
kwin, not sure which) has no time to save the current window size as it 
goes down, so it restores fine.  But if the app quits normally, that size 
gets saved, and while it's saved with one assumption regarding client-side 
vs server-side decorations, with the relaunch those are applied 
incorrectly, thus resulting in a window height off by exactly the size of 
the server-side titlebar.

So play with setting ignore requested geometry and see if that changes the 
result at all.  Try playing with obey geometry restrictions too altho 
(with the additional inforation I know now) I believe that's less likely 
to be of help.  If that doesn't seem to be helping try playing with 
minimum size and size, initial and force (obviously force size as a last 
resort as that severely limits flexibility).  As a caveat, in my 
experience back then, I tried playing with them too and initially it 
didn't seem to help.  But I know a bit more now about those options so 
might have better luck now.  And eventually, I don't know /what/ fixed it, 
something I did to my config or something in a kde update, but at some 
point it /did/ stop happening.

Meanwhile, for me it was happening with other gtk-based apps (pan for 
nntp/news and claws-mail for email and as a feed-reader in particular) 
too.  But my configuration was such that I'd generally only notice it on 
apps that I had set to the height of the monitor (where if it's suddenly 
monitor-height minus titlebar height and there's another app set similarly 
underneath it, with the titlebar almost appearing to be that of the 
misbehaving app except the label is wrong, the short height and that the 
missing height is exactly titlebar height becomes very obvious), and those 
were the gtk apps in question, so that's where I noticed it.

What I'm saying is check to see if other gtk apps have the exact same too-
short-by-titlebar-height behavior.  If they do, it's almost certainly the 
same bug I had.  But if other gtk apps are fine and it's only firefox 
misbehaving, maybe it /is/ either a firefox bug, or at least, a 
misunderstanding between firefox specifically, and kwin.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


From rjvbertin at gmail.com  Mon May  4 17:32:12 2026
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Mon, 04 May 2026 18:32:12 +0200
Subject: KWin causing Firefox windows to be downsized upon restart with
 session restore
In-Reply-To: <pan$b55e9$aad03971$974d4054$b92a3905@cox.net>
References: <2242821.nim5UdQ9Me@bola> <18151386.JSOSuDKzn4@bola>
 <pan$b55e9$aad03971$974d4054$b92a3905@cox.net>
Message-ID: <4218956.bdveohiuKq@bola>

On Monday May 04 2026 14:20:19 Duncan wrote:


>But I think you're incorrect in specifying *firefox*'s session restore, 
>since my experience is that firefox's session restore handles getting back 
>the webpages that were running when it crashed, etc, and that it actually 
>does that impressively well at a crash, but that it doesn't handle window 
>size, etc

I think that it does, at least when restoring a properly shut down session. I'm not convinced a WM can even see the difference between an application exitting properly or not.

>
>IOW, I think it's *kwin's* bug, very likely either the same one I 
>experienced back in the day (tho the details of my experience differed but 
>the titlebar size difference was the same for both you and I), or another 
>related to it, likely with the same root cause.

There are several ways a client can specify window geometry. There are WM hints (which the WM can choose to ignore) and there are more lowlevel primitives that a WM should not ignore (normally). I think I've already seen WM options that give a handle on how it deals with WM hints, but I can't find a general setting for them in KWin. I do remember that I had to tweak my own code in an application that wants perfect control over window positions but I think that was before I used KWin.

The crux here is that neither Firefox nor KWin is doing something inherently wrong, but FF is not taking KWin's "opinion" into account (and given one of the central devs in the Plasma team, "opinion" and enforcing it are very accurate terms).

Either way, it's possible FF doesn't attempt to restore geometry after an improper exit because it knows it didn't have the chance to update the stored geometry data. That seems more likely than it restoring obsolete data (which may not even exist). But that still doesn't explain why my restored windows also end up on the correct virtual desktop automagically, because that does not happen with any of my other windows unless I define a KWin rule for it.

>running into kde/kwin/plasma bugs that have been there for awhile and may 
>only have been fixed in this-year-recent kde/plasma6, **IF** it's actually 
>session-restore.

And IF it has been fixed...

>different behaviors, via kde window rules, that being ignore requested 
>geometry, and obey geometry restrictions.

IIRC I checked with the former (to no avail, as can probably be expected).

But IIRC even imposing an initial window size is of no use because the windows get resized with some delay (idem with the move to the designated virtual desktop). I do want to retain the possibility to resize them myself.
That delay is actually the main reason why I think Firefox does something supposedly smart or helpful itself (after a proper exit). There is no reason for KWin to restore geometry and/or desktop assignment after it opened the window for the 1st time; in fact, many people would see that as a flaw.

>Meanwhile, for me it was happening with other gtk-based apps (pan for 
>nntp/news and claws-mail for email and as a feed-reader in particular) 

It sounds like your issue was really something with how the titlebars were rendered. In my case it looks more like FF makes an error in the estimated titlebar height. I'm not really certain how you'd determine that property under X11 but if there's no way to query the WM you'd probably have to do some trawling of your window's parental hierarchy and then compare the Y co-ordinates of your actual view and of the window corresponding to the proper outside decoration envelope. I suppose that this hierarchy could differ depending on the decoration theme, and I just realise that the combined height of the dropshadows I have above and under my windows could well have the height by which my windows get downsized.



From rjvbertin at gmail.com  Wed May  6 12:17:41 2026
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Wed, 06 May 2026 13:17:41 +0200
Subject: KWin causing Firefox windows to be downsized upon restart with
 session restore
In-Reply-To: <4218956.bdveohiuKq@bola>
References: <2242821.nim5UdQ9Me@bola>
 <pan$b55e9$aad03971$974d4054$b92a3905@cox.net> <4218956.bdveohiuKq@bola>
Message-ID: <10166448.UNRZNjNFDn@bola>

René J.V. Bertin wrote on 20260504::18:32:12 re: "Re: KWin causing Firefox windows to be downsized upon restart with session restore"


>>different behaviors, via kde window rules, that being ignore requested 
>>geometry, and obey geometry restrictions.

I tested the effect of ignoring the requested geometry. It looks like that could actually work if it didn't also cause windows to be restored at seemingly random locations, which may not even ensure that the window can fit on the screen without downsizing. (If that is indeed the case, I'd consider it a bug in KWin.)



From rjvbertin at gmail.com  Sat May  9 23:47:15 2026
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Sun, 10 May 2026 00:47:15 +0200
Subject: KWin causing Firefox windows to be downsized upon restart with
 session restore
In-Reply-To: <10166448.UNRZNjNFDn@bola>
References: <2242821.nim5UdQ9Me@bola> <4218956.bdveohiuKq@bola>
 <10166448.UNRZNjNFDn@bola>
Message-ID: <15101831.efAA1eWRLQ@bmbl>

I can reproduce the issue in KUbuntu's 24.04 LiveCD, with FF DevEd 151.bX and both the Oxygen and Breeze window decorations. Haven't tried others.

https://discuss.kde.org/t/kwin-causing-firefox-windows-to-be-downsized-upon-restart-with-the-browsers-session-restore-enabled/46785/11?u=rjvbb

From 1i5t5.duncan at cox.net  Tue May 12 03:27:17 2026
From: 1i5t5.duncan at cox.net (Duncan)
Date: Tue, 12 May 2026 02:27:17 -0000 (UTC)
Subject: KWin causing Firefox windows to be downsized upon restart with
 session restore
References: <2242821.nim5UdQ9Me@bola>
 <pan$b55e9$aad03971$974d4054$b92a3905@cox.net> <4218956.bdveohiuKq@bola>
 <10166448.UNRZNjNFDn@bola>
Message-ID: <pan$97fc5$59e5bef4$3092457d$fb829766@cox.net>

René J.V. Bertin posted on Wed, 06 May 2026 13:17:41 +0200 as excerpted:

> René J.V. Bertin wrote on 20260504::18:32:12 re: "Re: KWin causing
> Firefox windows to be downsized upon restart with session restore"
> 
> 
>>>different behaviors, via kde window rules, that being ignore requested
>>>geometry, and obey geometry restrictions.
> 
> I tested the effect of ignoring the requested geometry. It looks like
> that could actually work if it didn't also cause windows to be restored
> at seemingly random locations, which may not even ensure that the window
> can fit on the screen without downsizing. (If that is indeed the case,
> I'd consider it a bug in KWin.)


With window rules, if ignore requested geometry needs set, it's /normally/ 
due to setting size or position, tho that isn't necessarily the case here.

So one solution to the random locations side effect might be setting 
position -- hopefully apply initially (not force) is enough so you can 
still move the window.

Alternatively, depending on your setup, setting initial placement, force, 
<as appropriate>, might work.  Setting it to on main window should at 
least eliminate off-screen placement.  (Since that's just adjusting kwin's 
default placement strategy for that window it doesn't affect later 
movement so force is fine.)

Tho I don't know why ignore requested geometry would effectively randomize 
location unless the default placement strategy is set either random or 
none, since /in/ /theory/ placement and size (and possibly maximize/
minimize) is all ignore requested geometry should affect, and for 
placement the effect should be simply to default to the default placement.

(And FWIW, default placement is, at least on my currently a bit behind 
live 6.x), set in plasma systemsettings under apps & windows, window 
management, advanced tab, window placement.  Here I have "minimal 
overlapping" selected, and the general placement works reasonably, tho 
occasionally it doesn't do /quite/ what I expect but then if I think about 
it the choice usually makes sense given the policy.  Tho FWIW based on my 
observation there was a recent slight tweak and it doesn't /always/ 
position into the largest open area like it used to.  I suspect that's 
actually due to the quite recent (this year) session-restore changes as 
kwin's now remembering better where a window was previously (keeping in 
mind that on wayland window position on the desktop is the compositor's 
job and wayland apps don't normally even know where they were so can't 
remember it for later restore... that's the compositor's job!).  But I 
haven't tracked it definitely enough to be sure.  The practical effect has 
been mixed, certainly a bit less consistent/as-expected for those (like 
me) used to the previous behavior, but not noticeably requiring more 
subsequent repositioning, as sometimes the largest open area is my highest 
priority area, just cleared due to closing a window as I shift task focus, 
and what I just opened will be a secondary window (as it was last time) so 
shouldn't be in the primary space unless I move it there anyway.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


