We can't have hidden panels in the middle of two screens.
It's a known limitation, that under X can't really be fixed. Sorry.

I'll leave this open to remind me to disable the option in this situation.

Other applications like eg. TeamViewer are also able to "hide" docks between two X11 Xinerama screens...

So it does not seem to be a hard limitation of X11 in general - maybe a limitation of how Plasma 5 is designed in this regard?

Is this bug actually still valid? There was some work in KWin 5.8 to ignore NETWM specification for panel struts, and might affect this bug.

*** Bug 374805 has been marked as a duplicate of this bug. ***

Created attachment 103351 [details]
My panels between my two monitors

The green squares shows where I was able to place panel with autohide enabled in KDE 4. Plasma 5 doesn't hide them in those places.

*** Bug 407750 has been marked as a duplicate of this bug. ***

*** Bug 401168 has been marked as a duplicate of this bug. ***

Still an issue as of:

Operating System: Kubuntu 20.04
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.68.0
Qt Version: 5.12.8

@David Edmunson, can you please clarify what limitation exists in X making it impossible to have an autohiding panel on a screen edge that is also the edge of another monitor?

As a matter of fact, in my system when you hover on the panel, right after it *does* autohide perfectly. The problem is that immediately an unhide is triggered even if there is no reason for that.

(In reply to Duncan from comment #19)
> But I gotta actually find the code in question and see if I can hack-patch it
> first.  We'll see...
Breadcrumb: plasma framework:
plasma/src/scriptengines/qml/plasmoid/containmentinterface.cpp

Line 991 mentions bug #344205, panels were auto-hiding when their context menus were shown.  The bug was reported in 2015 and fixed in 2017, git commit f3dcff28b8fbc635467252706641c9d37f094090 to plasma framework.

That looks like it could be the git commit pointing the way to the relevant code that I was saying made developing a hack-patch so much easier.  The code surrounding the mentioned line may or may not be the code to patch, but if not, the calls made there should be greppable.

So we have a path to explore now, at least. =:^)

That it worked in kde/plasma4 and actually hides in plasma5 now but immediately unhides, demonstrates it should be possible to setup some sort of condition test and stop the immediate unhide under specific conditions.  Whether coding the specific condition set is within my limited coding capacities or not remains to be seen, but with a path to follow now we're already closer than we were.

Also: plasma API spec:
https://api.kde.org/frameworks/plasma-framework/html/index.html

And another potential hint in comment #8, ignored NETWM spec for panel struts in plasma5.

So while working on this I got thinking about another workaround people may find useful until a fix is available to them.  (Doesn't mean I've stopped trying to do a hack-patch, tho, this is just a different workaround.)

There are command-line window-management tools like wmctrl and xdotool available.  Command-line of course means scriptable, which makes these especially handy (and I use them personally) for hotkey launching and other dynamic use, where kwin's window rules aren't appropriate because they apply all the time and you want the rule only applied on demand and/or you want for instance two different window sizes and/or positions invokable when kwin's window rules can only handle one.

There's also xprop, which allows you to read window properties, and when combined with grep in a script, test for specific window property matches (like window rules do) as necessary to ensure you're matching the intended window.

It should therefore be possible to setup a script that can toggle panel-visibility (as generally possible with any window) using a hotkey, tho if plasma or kwin keeps trying to override it, it may be necessary to, for instance, have the script force-position the window off-screen in "hidden" mode, and position it back to screen-edge in "shown" mode.

The script could then be configured to launch with either a hotkey or potentially when the mouse hits a hot-edge (xdotool's behave_screen_edge function, note that I've never used this personally so I'm not sure how it works with "internal" borders), triggering panel show or hide.

If no one else gets inspired to create and attach such a script, if I decide I can't hack-patch plasma to fix this or decide I need a break from my attempts, I'll try a script, something I'm much more comfortable doing, so am 90% sure I can do (the 10% uncertainty being in how insistent plasma's going to be in trying to override the script's show/hide and/or placement), vs. only perhaps 30-40% sure at current status (up from 20-30% before I found those breakcrumbs) that my limited skills are up to hack-patching plasma to fix the problem.

So one way or another I'm reasonably sure I can do either a hack-patch fix or a workaround script, one or the other, but it may well involve having to install some scriptable window management tools and assigning hotkeys to a script to take over the hide/show plasma panel(s) functionality from plasma.

An update on the scripted approach.  TLDR: 99+% chance on the scripting now; the positioning trick I mentioned in comment #23 works; just gotta assemble everything.

Testing and this works: Reposition the window outside the display area to hide it, then reposition it back to normal to show it, using...

    wmctrl -ir <0xID> -e 0,<x>,-1,-1,-1

Parameters explained:
-r = window specifier supplied
-i = interpret specifier as WinID, the 0x of course indicates it's in hex.
-e = positioning: gravity,x,y,w,h, with 0=default-gravity, for the others -1=keep-existing.  So say 0,-32000,-1,-1,-1 will shove the window waaayyy left to x=-32000 while keeping other geometry properties the same.  Position values appear to be 16-bit signed so wrap @ ~+/-32767.

xdotool should be able to do it too.

Still gotta script up the property-matching to match only the desired window tho I've done similar for other scripts, and figure out where/how to store the on-screen location while in the off-screen state (tempfile?).  Also play around with xdotool's behave-screen-edge and see if it's practical, or whether hotkey invocation is better, and if the latter, a single-invocation toggle or two separate ones, hide and show?

I was also considering the separate-executable plasma-windowed alternative, but the positioning trick seems to work and should be both simpler and less disturbing to the otherwise-native panel workflow, making the plasma-windowed alternative unnecessary.

Still hoping for a patch too, but that's (still) well out of my comfort zone and remains under 50% likely.  I've pretty much demonstrated it's possible using the positioning trick I just tested with wmctrl if nothing else, but the skills are likely beyond me, leaving the scripted hack-around I'm well within my comfort zone doing.

Script update: TLDR: More pieces for the script falling in place.  Dependencies...

1) xdotool windowmap/windowunmap <winid> seems more direct than the wmctrl positioning I mentioned in the last update.

2) Based on #1, for the actual operation using a preset winid ($panel) and using xwininfo -id $panel | grep 'Map State:" will yield "Map State: IsViewable" or "Map State: IsUnMapped.  That state can then be the condition for the xdotool windowmap/windowunmap toggle.

3) Dependencies:  Looks like xdotool and xwininfo.  Also grep and coreutils (for cut) but they should be part of core system and thus already installed on most distros.  The script will be bash and will probably use some bash-specific functionality, so dash, etc, may not work unless someone else wants to modify and post a version for that.  Not wmctrl as xdotool seems more elegant for this, and probably not xprop as it appears xwininfo exposes what I need more directly, tho I won't be able to say for sure on that until the window match code comes a bit more into focus (I've just been selecting manually for experiments to this point).

4) Played with xdotool behave_screen_edge a bit.  Unfortunately it doesn't appear to work on "interior" edges.  Additionally, since xdotool doesn't have builtin conditionals the edge-trigger would have to invoke (xdotool) exec on a script with the conditional, with the exec being run using the blogging --sync option as without that xdotool has a bug in that it doesn't harvest process zombies after execution, which is fine for an immediate job and terminate, but with a long-running xdotool behave_screen_edge they just pile up. =:^(

5) So the behave_screen_edge thing will have to be separate from the hide/show script in any case, which means people can use whatever launcher they want, hotkey-invoked, third-party launcher (I may use gkrellm's launch feature here, it's between that and hotkey-invoked), or xdotool behave-screen-edge.  Too bad plasma's native screen-edge triggering can't be configured to launch arbitrary executables, only kwin-native stuff like window-switcher, cube, etc, or that'd likely replace the xdotool behave_screen_edge option as a more native approach.

Script update: TLDR: Window selection.  Some limitations.

Window selection is the last major piece to figure out before I start putting it all together in a proper script.

Unfortunately it's also the hardest, with plasmashell making things particularly difficult as there's way too many windows with the same generic "Plasma" name and "plasmashell" class and classname/wholeclass.  As I've been experimenting today I've seen anywhere from 1-2 dozen in the list.  Years ago there used to be window roles to sort on and panels had distinct if somewhat generic roles such as (IIRC) panel#1, panel#2, etc, so all you had to do was detect the role once and then match on it.  But plasma hasn't been filling in window roles for years now, I'd guess because wayland probably doesn't have a directly parallel concept.

The other generally characterizing aspect is the window position/size/geometry.  But I'm getting three matching windows for that, two parents of the window I'm targeting, too, and size/position/geometry alone isn't a safe enough exclusive match in any case.

But a combination of the two, window name/class/wholeclass, and window position/size/geometry, seems to do the trick at least /reasonably/ reliably.

But position/size/geometry will obviously differ by individual config.

So what I'm considering now is asking the user to pick the window so we can get size/position at setup time, and of course again if they change their panel position/size, but storing it in a config file so they only have to do it once unless they do change position/size.

Then I can read the stored size info from the config at startup and fill it in to do something like this:

xwininfo -tree -root | grep ' "Plasma": ("plasmashell" "plasmashell") *383x50' | sed -e 's/^ *//' | cut -d' ' -f1

xwininfo -tree -root lists all windows along with their size and position.  That's piped to grep looking for plasma windows of the specified size (or adjust it a bit for position or both).  That should spit out the line we need, but there will be some initial spaces that the sed eliminates, leaving the window-id as the first space-separated field for cut to select.

After the grep but before the sed and cut the line should look like this (variable number of initial spaces):

       0x240004d "Plasma": ("plasmashell" "plasmashell")  383x50+0+0  +7296+2110

After the sed and cut it'll be only the 0x240004d, which is the window-ID to feed back to xwininfo to check the mapping state to see which way to toggle it, and then to xdotool window(un)map as described in comment #25.

The kink in this is that panel size (and therefore position) can normally dynamically grow/shrink within min/max constraints depending on what's shown -- for panels with a systray startup a new app that adds a systray icon, for instance, and that will often grow the systray and thus the containing panel.  Similarly for clock displays, weather displays, etc.

The simplest way around that is to configure the panel with the same min-size and max-size so it can't grow/shrink, which I may require at least for the initial script posting.  There's ways around that, either finding something else to match and potentially grepping individual window results for it, or using something other then grep to fuzzify the size/position matching within given constraints, but they get complicated pretty fast.

And as you can see sed's a likely dep now too, but as with grep, it's going to be a core-system package and thus likely already installed for most distros.

Getting close now to putting all the pieces together into a postable script, tho, even if it's going to be a bit flexibility-limited.  If you want to try playing around with xwininfo and xdotool, along with xprop if you want a few more matching options, better matching ideas welcome!  And of course if you have the skills to do the real code patch and do away with the need for all this scripting in the first place, you're /more/ than welcome to do it!

(I've not given up hope for a patch here, either, but the chances remain under 50% that I can do it, and it could well take me months of on and off work and some chance inspiration before it clicks and I can put it all together in a patch, even if I do ultimately do it.  But a script, while a definitely hacky and limited workaround, may well be something I can put together, pre-post test, and post along with instructions for others to try, by the end of the week.)

(In reply to Duncan from comment #26)
> Script update: TLDR: Window selection.  Some limitations.

TLDR: Good news! The script is coming together; the window selection stuff is nearly done, and I've found much better/easier matching/filtering than size/position/geometry so that idea's killed now.

After an initial match on plasmashell plasmashell complete class to get the initial window candidates (typically a dozen or two), matching on map-state IsVisible (obviously only on first run each session) seems to eliminate most of the candidate windows, and I'm further matching on window-manager hints for window type Dock NOT Dialog.  Additionally, if pgrep (from the procps package, should be core for most distros and thus already installed but it's optional) is available, I'm matching the PID against the running plasmashell PID.  That should eliminate any other strange windows that happen to match the other elements but aren't owned by the running plasmashell, admittedly a remote prospect given all the other matching I'm doing, but just in case.

Current deps are xwininfo and xdotool which will probably need installed, grep and sed which are core and likely installed on most distros, and optionally, pgrep, from the procps package, also core.  (While I mentioned it earlier, cut from coreutils isn't currently a dep.)

Looks like the first run per session will do all the detection and set the panel winIDs, saving them to a tempfile.  Visible (that is, mapped, IsVisible) panels will be assumed on that first run and they won't be detected otherwise.  Additional runs will grab the detected WinIDs from the tempfile and detect current mapped state, toggling to unmapped if visible, toggling to mapped/visible if unmapped.

Do note that there are ways to hide windows without unmapping them.  Simply positioning them off-screen is a relevant example given that's what my first experiments with wmctrl actually did.  So the IsVisible/UnMapped state I'm actually testing for doesn't /always/ correlate to /actually/ visible/hidden.  However, I don't believe that will be a major problem for us.

If plasmashell is restarted without clearing the tempfile the winIDs therein will be stale, and I'll probably have the script auto-delete the tmpfile and redetect if none of the listed winIDs appear to be actual windows.

While I've not tested multiple panels yet, I believe all panels will be detected on a detection run, and hidden.  If new panels are created during a session they won't be in the tmpfile and thus won't be affected until the next session.  To deal with that I'll probably add a manual option to wipe the tmpfile and redirect, else manually deleting the tmpfile should do the trick, as long as existing panels are all mapped/visible, of course.  In the event the tmpfile gets wiped with existing panels unmapped/hidden, restarting plasmashell will probably be necessary to reset the state.

Unfortunately, due to plasmashell no longer filling in distinct window roles, dealing with only some panels while ignoring others gets really complicated, probably involving that fuzzy geometry stuff I'm avoiding by using other detection logic.  The other method, of course, would involve having to point at the ones you want managed on the first run each session, which would get old real fast.  So the script will likely manage all plasmashell panels it can detect (run it) or none (don't).

Created attachment 131708 [details]
panelhider script

OK, the script, which I named panelhider, works well here and is ready for others to test. =:^)

Final dependencies:
    Core and likely installed on most distros:
        grep
        sed
        coreutils (for mkdir)
    Optional but recommended (also core and likely installed):
        procps (for pgrep)
    Required and will likely need to be installed, hopefully in your distro's repo:
        xwininfo
        xdotool

The cachefile is stored in the standard $XDG_CACHE_HOME location as $XDG_CACHE_HOME/panelhider.winid.cache .  If $XDG_CACHE_HOME isn't set the default $HOME/.cache/ dir is used.  If $HOME isn't set either, the script will complain and exit.  If necessary the dir is created with the recommended 700 perms.  If the cachefile (or cachedir) can't be created for whatever reason, an appropriate error is printed and the script exits.

Usage: panelhider [debug] [force] [lasttry]

The parameters are optional but must appear in that order if present.  Thus, if debug isn't present, the first parameter is checked for force, else the second parameter is.  Similarly, if force isn't present, the first (or second with debug) parameter is checked for lasttry.  Simple enough to implement with shift. =:^)

debug should be obvious.  When run from a konsole/terminal window it'll print a lot of interesting information about the window matching process, etc, as the script runs.  Hopefully that output will help me trace down any bugs people find that I missed in my own testing.

force deletes the cachefile if it exists and forces a detect and repopulation of the cachefile.  Note that due to the way detection works, hidden (unmapped) panels won't be detected, so if you force with panels unmapped, you'll either have to manually run xdotool map on the window manually, or killall plasmashell and restart it (which can be done from krunner or a konsole window, you don't have to quit and restart your entire plasma session), to get your panels back.

lasttry is primarily for script-internal use but can be set manually as well.  If you run panelhider and it can't find any panel windows to toggle, it's likely because the winIDs in the cachefile are stale, so panelhider will normally invoke itself again with force lasttry to clear the cachefile and redetect.  The lasttry is there to prevent it from going into an endless reinvoke loop so in lasttry mode it won't try again.

As always, don't forget to scan the script before running it since you don't presumably don't know me and for all you know I could have put harmful commands in the script.  When you're satisfied it doesn't do rm -rf $HOME or the like, place it in your path and set it executable.

Then test away. =:^)  If you're curious you may want to run it from a konsole window with the debug parameter to see what it's doing.

When you're satisfied that it's working as expected, assign a hotkey for it or set it up via some other launcher.  As I said in an earlier post, I'm considering using a gkrellm click to launch it here, but I have enough other stuff on hotkeys I'm used to hotkey launching, so that's tempting as well.  We'll see.

If anyone's interested in running it via xdotool's behave_screen_edge and has difficulty, I can create a stub-script to launch that and instructions for adding it to your autostart, but having played around with behave_screen_edge a bit I really can't recommend it and don't believe it's worth the trouble.  Maybe for people with just a single monitor, but then they'd have less reason to be interested in this script in the first place.

Anyway, hope it's useful for people other than me. =:^)  And I'll still try some more on the patch thing, but I still give it less than 50% chance I have the skills to pull it off, particularly with this script now as a workaround letting off the pressure.  We'll see.

I think that covers it.  Let me know if you have questions about it.

(In reply to Duncan from comment #28)
> Created attachment 131708 [details]
> panelhider script

Found a bug in the script.  It doesn't account for panels being on multiple desktops and after an unmap/remap cycle they only appear on the desktop the remap was triggered on.  I'll have to fix that and have an idea what I need to do already, but after hours working on it today I can no longer think about it clearly ATM.  Look for an update obsoleting this version, in a day or two.

(Also a bit surprising, not a bug just surprising and curious... To clear the desktops problem above and try again to verify, I quit kde/plasma and X (to CLI, FWIW I login at CLI and startx to a plasma session, no *DM installed), restarting them, and to my amazement, the winID for my panel was the same!  I thought window-IDs were more random than that, but maybe not, when the window's one of the first ones to be created in a new session.  I'll have to experiment with restarting plasmashell without restarting all of X/kde/plasma (so it's not one of the first windows to be created), and with a full reboot (so it is, but with a reset of most system state), and see if I get the same ID with both a smaller-scale and a larger scale restart as I do with the intermediate scale X/kde/plasma restart.)

Created attachment 131712 [details]
panelhider script (v2)

Actually fixed it already.  (The surprise of the same-id behavior must have woke me up.)

Just added another xdotool call to pin the window to all desktops after mapping it.  The bit of a challenge, undocumented in the xdotool manpage but I deduced it with a bit of testing, is that the desktop number is apparently a 32-bit signed int, with the all-desktops pin indicated by a -1, while xdotool treats it as an unsigned int, so wouldn't take -1.  But it took the 32-bit unsigned-int bit-equivalent, 32-bit unsigned MAXINT, aka 4294967295.  So I somewhat unintuitively had to set a massive desktop number of 4294967295 instead of -1, to get it to pin to all desktops.  But once figured out, it works!

So here's the fix.

As for the behavior seeming to keep the same window-ID, I tried both rebooting and simply restarting plasmashell, and still got the same window-ID.  No real explanation. <shrug>

@Duncan, your scripting solution is admirable!

However, it makes one wonder once more at:
> We can't have hidden panels in the middle of two screens.
> It's a known limitation, that under X can't really be fixed. Sorry.

Let's hope that it challenges the developers to provide the correct behavior in plasma rather than assuming it is not needed because there is a scripting workaround. (Side) panels in plasma 5 are indeed broken in many other ways too (e.g, if you have a bottom panel and a side panel, you cannot properly configure the latter, because the bottom configuration button of the side panel may get covered by the side panel, Bug 417523; the "windows can cover" option does not work, Bug 359601, etc.).

In fact, I think that Plasma 5 should warn the average user against trying to use more than the default bottom panel in the current state.

So FWIW I've been switching to plasma-wayland over the last couple weeks.  It's usable in general and I'm basically switched over now, but it's definitely still rather raw compared to plasma-X.

Unfortunately this bug exists on wayland as well.  =:^(  Tho that's not entirely surprising since even if a fix is easier on wayland they're still working on feature-comparability and debugging so haven't extended much.

Of course my script doesn't work on wayland since it uses X-based tools.

So after I get a bit more settled in I may try again with the patches.  The script did increase my understanding, so even if nobody chooses to run it, it was worth it.

Meanwhile, in terms of "not possible", I believe the context is "within standards" (net-WM, freedesktop.org aka xdg, etc).  As far as I've read/deduced, the basic desktop standards don't really deal with how internal "struts" (the logical edge features panels attach to) are supposed to be handled in auto-hide terms, and maintaining compatibility is a high enough priority it limits flexibility.  Certain other window-managers/desktops don't place that sort of priority on standards or indeed ignore them pretty much entirely, and they don't have those limits.

And the standards make some sense for truly internal struts.  If there's no edge to bash the pointer against because the display extends to the next screen, it gets pretty hard to define a usable in all cases autohide/autoshow behavior that's universal enough to be standardized.

The problem is offsets when monitor resolutions differ and/or when displays are set logically diagonal to each other, only joined by a corner (my preferred setup when I had a 4K and a FHD monitor and arguably still my preferred setup with dual 4Ks, were it not for bugs such as this).  In those cases "internal" struts are still pointer-stopping in the offset areas where there's no neighbor-monitor for the pointer to continue onto, and thus should be able to host autohide panels just fine.  Unfortunately due to bugs such as this...  But the standards don't deal with it, so anything that allows it at minimum has potential interoperability issues.

One would hope that wayland can deal with that even if X hasn't/can't, but I don't know what the wayland standards status is in that regard, and even if it's allowed or even specced out, as described above, plasma-wayland is still immature and incomplete/buggy enough that just getting comparable operability first is, and should be, higher priority.

The set-up that triggers this for me though is that I have one monitor above the other, and the bug triggers for any panel that is on the shared edge – so:

• upper panel on the bottom monitor
• bottom panel on the upper monitor

*** Bug 447801 has been marked as a duplicate of this bug. ***

I just found a workaround to fix this that seems to work for me.

Go into Display Configuration then move one of the screens to leave a gap between them (so they aren't 'snapped' together).

This is on:
Operating System: EndeavourOS
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.17.4-arch1-1 (64-bit)
Graphics Platform: X11

*** Bug 373424 has been marked as a duplicate of this bug. ***

*** Bug 360891 has been marked as a duplicate of this bug. ***

*** Bug 460325 has been marked as a duplicate of this bug. ***

*** Bug 464355 has been marked as a duplicate of this bug. ***

*** Bug 466126 has been marked as a duplicate of this bug. ***

*** Bug 466588 has been marked as a duplicate of this bug. ***

*** Bug 472350 has been marked as a duplicate of this bug. ***

*** Bug 368872 has been marked as a duplicate of this bug. ***

*** Bug 428273 has been marked as a duplicate of this bug. ***

*** Bug 363622 has been marked as a duplicate of this bug. ***

*** Bug 378168 has been marked as a duplicate of this bug. ***

So to fix this in a way that makes sense, we would probably need to implement some kind of edge stickiness feature for screen edges between monitors that have hidden panels on them, as is proposed for Bug 416570. If we don't or can't do that, then there will remain no practical way to move the cursor onto the pixel that triggers the hidden panel and we would instead have to implement an expanded hover area that triggers the panel. That would be slower and likely more annoying, causing accidental activations that people would complain about.

So I don't think that's an acceptable alternative. and I think our path forward is to implement the feature requested at Bug 416570, and then make it always-on for edges between screens that have hidden panel on them. Marking that as a blocker.

(In reply to Nate Graham from comment #59)
> So to fix this in a way that makes sense, we would probably need to
> implement some kind of edge stickiness feature for screen edges between
> monitors that have hidden panels on them, as is proposed for Bug 416570. If
> we don't or can't do that, then there will remain no practical way to move
> the cursor onto the pixel that triggers the hidden panel [...]
> I think our path forward is to implement the feature requested at Bug 416570,
> and then make it always-on for edges between screens that have hidden
> panel on them.

I believe that's only partially correct... as described below:

Note that for at least some people CCed to this bug, their screen configuration might look like this (ASCII-art best viewed with a monospace font or the spaces will be too small horizontally and it won't align):

+----------+----+
| not here>|  v |
|          +----+
|         >|< ^
+----------+

In words, that's a higher resolution screen to the left, with a lower resolution screen to the right and aligned at the top, leaving an undisplayed square to the bottom right.

The paired arrows indicate edges that should be hard-stops for the pointer as they're bordered by only a single screen, not between screens, making them easy to hit (Fitt's law).

Or even (basically my setup when I reported):

+----+
| v >|< v
+----+----+
  ^ >|< ^ |
     +----+

That's two screens diagonal to each other so they only connect at a corner -- no actually shared borders so Fitt's law applies to all edges, only the corner connecting them (which makes it easy to switch screens with the pointer, just hit an edge that extends to the other screen and slide toward the other screen until the pointer hits the shared corner and enters the other screen).

Regardless of what happens at the fully shared edges (like the not here edge of the first one) where your observation applies and edge-stickiness would be useful, there's no reason why the "internal edges" (as I called them in my bug) that are not actually shared, so Fitt's law applies, can't have a working autohide panel.  The bug I filed was that autohide is broken on them too -- hit that stopping-edge then move away, and a panel on them set to auto-hide did disappear momentarily  at the move-away (I'm not entirely sure this is still the behavior as I have a different layout now, but I expect it is), but immediately appeared again, so (except for that momentary hide and popout again) autohide behaved as if the panel was set to permanently visible. =:^(  But it's a stopping edge that only /extends/ to a different screen, it's not actually a shared edge that the pointer cruises over and keeps going.  So autohide really can and /should/ work, even without the sticky-shared-edge feature described in comment #59.

So while the sticky-shared-edge idea is a rather ingenious solution (I wish I had thought of) for actually shared edges,  for stopping-edges that only extend to a different screen and aren't actually shared, sticky-shared-edge is not critical to having a working autohide.

I concur with Duncan. My situation is similar to his. 
My "solution" is abrasive: Autohide is disabled with multiple monitors. Like grayed-out. It would be a bore, yes, though consequential. Personally, having installs with and without multiple monitors, sitting with a single monitor, it is very useful, gives me more real estate. On multiple monitors, there is enough real estate to live without if need be.
Btw., I vaguely remember another bug reported, or RFE, because you can't have a monitor with and another without panel. 
(I can only hope, that a Plasma 6 will come up, where the designers' features are evaluated beforehand, if they can be implemented within a specific framework at all. Just remember the dreaded 'icon positioning' bug.)

Please consider that for many users the situation is dynamic.

You do not get setups in which you have a single monitor or two monitors. You get a laptop that may get temporarily attached to an external monitor, projector, etc where the external unit is not even always the same.

This means that not only you cannot count on a fixed setup. You cannot even count on hard-stop edges because the external screen may either be larger or smaller than the built-in one or may require some scaling factor.

Ideally you would like the boundary in between the two screens to be recognized regardless of the specific screen arrangement, so that panel auto-hiding works. 

And in fact not just that: possibly, though less important also other edge related actions such as tiling should work.

Indeed, disabling auto-hide for fully-shared edges would run into problems for dynamic layouts where a panel might therefore have to switch between always visible or auto-hidden depending on the screen arrangement. That would be unpredictable and not ideal.

For the use case where screens are touching only by a shared corner, I cannot reproduce the problem with Plasma 6 Wayland. An auto-hidden panel works as expected. And if it didn't, I would have been surprised and told you that it was most likely a bug with a different root cause. :) So let's consider that fixed, at least as of Plasma 6 Wayland.

Now onto the tricky case of a shared edge where the sharing is not 100%. It's possible to position a non-full-width/height panel so that it's only attached to the part of a shared edge that's not actually being shared with another screen!

In such a case, I think what we need is simply to make auto-hide work again, and not worry about the edge stickiness. But the moment the panel *does* touch a part of the edge that's shared with another screen, we would need the stickiness.

It'll depend on whether this degree of conditional edge stickiness is possible to implement in KWin, I think. If all we can get is 100% sticky or 0% sticky, we'll have to turn it on for every shared edge that has an auto-hidden panel anywhere on it.

I also encounter this issue with the new "dodge windows" mode on latest neon unstable (wayland, qt6). I.e., when the panel is put on a edge between two screens, it does not automatically dodge maximized windows, or other windows that should cover it.

Should I file a separate bug report or edit the description of this one?

Internally the root cause of the issue is the same, but probably it should be fixed separately as the UX is different. Go ahead and submit a new bug report, and link it to this one by putting "351175" in the "See also" field. Thanks!

*** Bug 477730 has been marked as a duplicate of this bug. ***

*** Bug 478317 has been marked as a duplicate of this bug. ***

*** Bug 478995 has been marked as a duplicate of this bug. ***

For wayland, ongoing progress at https://invent.kde.org/plasma/kwin/-/merge_requests/5166

Git commit 2e5d3253d4ae61d0ed4b0e9017493f696cf237e0 by Yifan Zhu.
Committed on 08/03/2024 at 20:03.
Pushed by fanzhuyifan into branch 'master'.

screenedge: allow creation between screens on wayland

Allow the creation of screen edges bordering two screens. This allows
panels in auto-hide/dodge-windows mode to work when the panel is
positioned between two edges.

Don't change the X11 behavior since edge barrier is not supported on
X11, without which it is virtually impossible to exactly position the
cursor on the pixel to activate the edge.

M  +4    -4    src/screenedge.cpp

https://invent.kde.org/plasma/kwin/-/commit/2e5d3253d4ae61d0ed4b0e9017493f696cf237e0

Since BUG 416570 is very difficult to implement on X11, and given that kwin X11 is feature frozen and the default session type is now wayland, we won't be supporting BUG 416570 on X11. Since auto-hide / dodge window panels on shared screen edges depend on 416570, we also won't be enabling it for X11.

*** Bug 482970 has been marked as a duplicate of this bug. ***

I have this bug also. I've wondered myself why the panel never auto-hided when I configured it to do so. Now I know why.

*** Bug 484539 has been marked as a duplicate of this bug. ***

*** Bug 488290 has been marked as a duplicate of this bug. ***