Re: how to autohide the panel?
On Saturday, February 26, 2022 7:09:06 PM CST hw wrote: > Wayland is the reason that I switched from fvwm to kde. It still doesn't > work with NVIDIA, but I have a Radeon card now and it works. Even the > panel now hides. Now I'm wondering how to get rid of the transparancy > in dolphin and some other windows ... what a totally stupid idea is it > to make windows transparent?? I usually add more transparency haha. Transparency settings affecting Dolphin should be in settings > application style > pencil icon. Other parts of the UI such as window decorations or plasma style may also need to be changed to completely get rid of any transparency. But yea, I wanted to use Wayland also, but I'm finding it buggy even with an AMD GPU, and then it's hard to find a text expansion package that works with it. > Kmail keeps messing up it's database, even when using mariadb. That > must be badly programmed since it doesn't even distinguish upper and > lower case for table names ... > > Kmail --- or aconadi --- just doesn't work. Besides, it's really awful > because it creates files with settings all over the place so it's even > very difficult to get rid of all the settings when you want to start over > with kmail. That's the kind of mess which is one of the reasons not > to use windows since windows 3.1. Interesting, I haven't had any problems so far, but I'll keep an eye out.
Re: how to autohide the panel?
On Wednesday, 2 March 2022 10:50:57 GMT René J.V. Bertin wrote: > On Wednesday March 02 2022 10:25:45 Peter Humphrey wrote: > >Wouldn't it be easier, and save all this difficulty, if the logic were > >changed so that the panel, once hidden, stays that way until ... > > Simpler maybe, but that would a) require all the devs who ever worked on > this to eat their pride and b) assume that everyone appreciates the simpler > behaviour. > > This list isn't very active and already there were a few people who stated > that "it works for them"; impossible to tell if they represent the > consensus out there, or we. > > The safe approach would be to add the simpler logic as an option, just like > "focus follows mouse" has complexity options in KWin. That's a better idea, René. I like it. -- Regards, Peter. Gentoo amd64 system, Kernel 5.15.11, GCC 11.2.0, SDDM 0.18.1-r5 kde-apps 21.08.3, kde-frameworks 5.90.0, kde-plasma 5.23.5
Re: how to autohide the panel?
On Wednesday March 02 2022 10:25:45 Peter Humphrey wrote: >Wouldn't it be easier, and save all this difficulty, if the logic were changed >so that the panel, once hidden, stays that way until ... Simpler maybe, but that would a) require all the devs who ever worked on this to eat their pride and b) assume that everyone appreciates the simpler behaviour. This list isn't very active and already there were a few people who stated that "it works for them"; impossible to tell if they represent the consensus out there, or we. The safe approach would be to add the simpler logic as an option, just like "focus follows mouse" has complexity options in KWin. R.
Re: how to autohide the panel?
Wouldn't it be easier, and save all this difficulty, if the logic were changed so that the panel, once hidden, stays that way until the mouse pointer moves into its area of the display? -- Regards, Peter. Gentoo amd64 system, Kernel 5.15.11, GCC 11.2.0, SDDM 0.18.1-r5 kde-apps 21.08.3, kde-frameworks 5.90.0, kde-plasma 5.23.5
Re: how to autohide the panel?
hw posted on Sun, 27 Feb 2022 17:14:52 +0100 as excerpted: > Isn't there something like fvwm for wayland? While as I said I'm not familiar enough with fvwm to say much on that myself, I did remember this table of the available wayland compositors along with the style of window management they do and what they most directly compare to on the X side from the gentoo wiki. This is the most inclusive list I'm aware of and there's a couple OpenBox-alike compositors listed, for instance, if that's comparable. https://wiki.gentoo.org/wiki/Wayland_Desktop_Landscape#Compositors You might find some of the rest of the page (like the app-launchers) helpful as well. -- 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
Re: how to autohide the panel?
hw posted on Sun, 27 Feb 2022 17:14:52 +0100 as excerpted: > On Sun, 2022-02-27 at 07:31 +, Duncan wrote: >> >> The windows-can-cover option is actually somewhat smarter than that and >> turns out to be, for some people, a better-than-autohide-autohide. >> >> Basically, what it does is when there's a window, it works like >> autohide, bring the panel up when you hit the edge it's on. But when >> there's no window there, it stays visible, where autohide would (sans >> bugs) hide then as well. > > Then the option needs to be renamed. I would never try it because I > don't want windows to cover the panel. There is a bit of a discoverability problem there, I'll agree. It took me awhile to try it myself, for that very reason. But once I tried it, I think when I was investigating the bug below, I saw the logic. (Tho FWIW I still use autohide normally, because while it doesn't interfere with windows it still disturbs the wallpaper view, which I like as clean as possible.) >> Thus the suggestion to try it, which I second. You won't know if it >> works for you until you do, but you might be pleasantly surprised. =:^) > > I can't try it because the right-click menus don't work with wayland, so > there is no way to configure the panel. ?? All the context (aka right) click menus seem to be working here, plasma on wayland with kwin as the compositor. Altho I am running live- git-master kde-frameworks/kde-plasma and most kde-apps. So I tend to be slightly ahead of current release and rather further ahead of the stale^H^Hble distributions. But I switched to wayland (from live-git- master on x11 previously) in late 2020 and while there were serious problems with menus (all menus, not just context-menus) on wayland back then, they've been working reasonably well for at least some months now. > Isn't there something like fvwm for wayland? I'm not familiar enough with fvwm to know for sure (and I guess I won't ever be now since I've switched to wayland; xorg's actually uninstalled so the only X I have is xwayland on wayland, tho as a minimal backup wayland compositor I do have weston in case my live-git kwin_wayland goes broken) >> Panel autohide behavior is broken on interior and semi-interior edges >> and the panel will (try to) hide momentarily but *immediately* unhide >> again. This is considered intended behavior because that's what some >> desktop behavior standard (see the bugs for the details) requires. > > That standard needs to be changed then, or be ignored. I already said I still consider it a bug, so I agree with you... tho I'd tend to put it a bit more diplomatically: it needs to be "interpreted differently. =:^) >> (FWIW, I had that layout when I was using two monitors of different >> sizes both physical and resolution. I'd play videos full-screen on the >> bottom left one while working in the top right one with more room, with >> just the corner connecting them so the mouse would still stop at all >> the edges and would only move from one to the other at the connecting >> corner. > > That's a nice idea, I should try that :) Yes it is, if I /do/ say so myself. =:^) Tho I'd suggest if you have the flexibility to do so, maybe doing it the reverse, with the working monitor configured to top-left and the video monitor to bottom-right, since "gravity" normally defaults to top-left, meaning many windows will try to position at 0,0, outside the viewable area if you have the monitors oriented bottom-left/top-right as I did. And if the video monitor is top-left they try to position over the video. So for least problems the working monitor needs to be top-left, meaning in a diagonal layout, the video monitor would be bottom-right. >> I *DO* 100% agree with you on the akonadified kmail, however. Let's >> just say I just deleted about five paragraphs and growing to replace it >> with this: Once I saw the stability issues triggered by the entirely >> unnecessary complexification with the akonadi database, I ran as fast >> as I could away from it, because I knew where it was headed and kmail's >> previous "rock solid just works dependability" wasn't anywhere near >> that destination on the map. > > When did kmail ever work? Back in the kde3 era, and actually even late kde2 which is when I originally switched to Linux and chose kmail, it worked rather well, for me at least. And even in early kde4, while everything /else/ kde4-related was still suffering *severe* kde4-migration pains (made many times worse by the maintainers insisting kde4 was functional and dropping the still working kde3 versions, but at least they seemed to have learned /that/ lesson and didn't repeat it for kde5 and haven't been repeating it for the wayland and as-yet the kde6 migrations), kmail continued working relatively well (at least here). It wasn't until they jumped the akonadi shark with kde 4.6 that kmail reliability went to hell. >> Ironically, I ended up on claws-mail [..
Re: how to autohide the panel?
On Sunday February 27 2022 17:14:52 hw wrote: >Well, the problem is that there is no alternative. Gnome remains still >completely unusable >Everything else doesn't use wayland. Change the name slightly and you get something that seems like it might be just right for you: Chrome OS. Uses wayland, and it works, even the panel autohiding. >I don't understand why anyone would make a program that doesn't allow you to >adjust the font sizes as you need them. The tiny 4 point fonts developers are >so fond of maybe work on 24" displays that are limited to 640x480 and they >are simply entirely unreadable on the normal 4k displays. But they are more >concerned with removing required features and making the software unusable. I'm sure they'll welcome contributions from people who know everything so much better than they do! R.
Re: how to autohide the panel?
On Sun, 2022-02-27 at 07:31 +, Duncan wrote: > hw posted on Thu, 24 Feb 2022 03:22:18 +0100 as excerpted: > > > On Wed, 2022-02-23 at 11:52 -0700, Stephen Dowdy wrote: > > > On 2/23/22 11:12, Patrick Nagel wrote: > > > > On Wednesday, 23 February 2022 16:47:03 CET hw wrote: > > > > > I have set the panel to autohide and it's not hiding except > > > > > sometimes:( Instead the windows go underneath the panel, which is > > > > > very annoying. > > > > Having the windows above the panel is useless because it would prevent > > me from using the panel altogether unless I keep moving the windows > > around every time I need to use the panel. > > The windows-can-cover option is actually somewhat smarter than that and > turns out to be, for some people, a better-than-autohide-autohide. > > Basically, what it does is when there's a window, it works like autohide, > bring the panel up when you hit the edge it's on. But when there's no > window there, it stays visible, where autohide would (sans bugs) hide then > as well. Then the option needs to be renamed. I would never try it because I don't want windows to cover the panel. > The thing is, sometimes the windows-can-cover autohide behavior isn't as > bugged as full autohide is, so it can work better unless you really need > to access the desktop underneath it. > > Thus the suggestion to try it, which I second. You won't know if it works > for you until you do, but you might be pleasantly surprised. =:^) I can't try it because the right-click menus don't work with wayland, so there is no way to configure the panel. Isn't there something like fvwm for wayland? > > And seriously? Why should I have to fiddle around with things at all > > when there is a totally simple option for automatically hiding the > > panel? Are there some hidden options that I need to find that make the > > simple option work eventually after I spent searching hours for a > > solution? > > Not yet mentioned as one potential trigger is a poorly documented > "intended behavior" that some (including me) consider a bug as well. See > kde bugs # 407750 and 351175. The requirements for triggering this one > include a multi-monitor layout and that the panel be located on an > "interior" or "semi-interior" edge. Consider the following layout which I > had at one point: > > (ASCII-art, displays best with a monotype font.) > > a > +--+ > | | > b | 2160p | > | | e > c | d | > +---+--+ > | | > f | | g > +---+ > h > > Edges a,e,f,h are exterior (forming part of the bounding rectangle) and > won't exhibit this particular problem. > > Edges b,c,d,g are semi-interior (not a common edge but not an exterior > edge) and will exhibit the problem. > > Not shown in the above because I used a corner-join are fully-interior > edges, common between two monitors. They'd exhibit the problem as well > but (IMO) it's less likely that someone would try to place a panel on > them. > > Panel autohide behavior is broken on interior and semi-interior edges and > the panel will (try to) hide momentarily but *immediately* unhide again. > This is considered intended behavior because that's what some desktop > behavior standard (see the bugs for the details) requires. That standard needs to be changed then, or be ignored. > (FWIW, I had that layout when I was using two monitors of different sizes > both physical and resolution. I'd play videos full-screen on the bottom > left one while working in the top right one with more room, with just the > corner connecting them so the mouse would still stop at all the edges and > would only move from one to the other at the connecting corner. That's a nice idea, I should try that :) > Eventually I got a second large monitor, actually bigscreen TVs, that > matched the size of the other one, and I switched to a more conventional > side-by-side layout, resolving the issue "with money to buy hardware" for > me as I no longer had semi-interior edges where I wanted a panel, only the > single common edge between them, where a panel didn't make as much sense.) If I had room for another 4k display on my desk, I might get another one because the one I have doesn't support 4k over HDMI because that version of HDMI hadn't been invented yet when I got this display ... > > It's bugs like this one, plus kwin not even being able to do focus > > follows mouse correctly and kmail still not working at all that make me > > go away from KDE. I like KDE and kmail, but there is no point in using > > it when the major things which speak for using it don't work. > > I haven't had any problems, at least problems that I couldn't solve with > an appropriate window rule, with focus-follows-mouse, h
Re: how to autohide the panel?
hw posted on Thu, 24 Feb 2022 03:22:18 +0100 as excerpted: > On Wed, 2022-02-23 at 11:52 -0700, Stephen Dowdy wrote: >> On 2/23/22 11:12, Patrick Nagel wrote: >> > On Wednesday, 23 February 2022 16:47:03 CET hw wrote: >> > > I have set the panel to autohide and it's not hiding except >> > > sometimes:( Instead the windows go underneath the panel, which is >> > > very annoying. > > Having the windows above the panel is useless because it would prevent > me from using the panel altogether unless I keep moving the windows > around every time I need to use the panel. The windows-can-cover option is actually somewhat smarter than that and turns out to be, for some people, a better-than-autohide-autohide. Basically, what it does is when there's a window, it works like autohide, bring the panel up when you hit the edge it's on. But when there's no window there, it stays visible, where autohide would (sans bugs) hide then as well. The thing is, sometimes the windows-can-cover autohide behavior isn't as bugged as full autohide is, so it can work better unless you really need to access the desktop underneath it. Thus the suggestion to try it, which I second. You won't know if it works for you until you do, but you might be pleasantly surprised. =:^) > And seriously? Why should I have to fiddle around with things at all > when there is a totally simple option for automatically hiding the > panel? Are there some hidden options that I need to find that make the > simple option work eventually after I spent searching hours for a > solution? Not yet mentioned as one potential trigger is a poorly documented "intended behavior" that some (including me) consider a bug as well. See kde bugs # 407750 and 351175. The requirements for triggering this one include a multi-monitor layout and that the panel be located on an "interior" or "semi-interior" edge. Consider the following layout which I had at one point: (ASCII-art, displays best with a monotype font.) a +--+ | | b | 2160p | | | e c | d | +---+--+ | | f | | g +---+ h Edges a,e,f,h are exterior (forming part of the bounding rectangle) and won't exhibit this particular problem. Edges b,c,d,g are semi-interior (not a common edge but not an exterior edge) and will exhibit the problem. Not shown in the above because I used a corner-join are fully-interior edges, common between two monitors. They'd exhibit the problem as well but (IMO) it's less likely that someone would try to place a panel on them. Panel autohide behavior is broken on interior and semi-interior edges and the panel will (try to) hide momentarily but *immediately* unhide again. This is considered intended behavior because that's what some desktop behavior standard (see the bugs for the details) requires. (FWIW, I had that layout when I was using two monitors of different sizes both physical and resolution. I'd play videos full-screen on the bottom left one while working in the top right one with more room, with just the corner connecting them so the mouse would still stop at all the edges and would only move from one to the other at the connecting corner. Eventually I got a second large monitor, actually bigscreen TVs, that matched the size of the other one, and I switched to a more conventional side-by-side layout, resolving the issue "with money to buy hardware" for me as I no longer had semi-interior edges where I wanted a panel, only the single common edge between them, where a panel didn't make as much sense.) > It's bugs like this one, plus kwin not even being able to do focus > follows mouse correctly and kmail still not working at all that make me > go away from KDE. I like KDE and kmail, but there is no point in using > it when the major things which speak for using it don't work. I haven't had any problems, at least problems that I couldn't solve with an appropriate window rule, with focus-follows-mouse, here. I'd be interested... I *DO* 100% agree with you on the akonadified kmail, however. Let's just say I just deleted about five paragraphs and growing to replace it with this: Once I saw the stability issues triggered by the entirely unnecessary complexification with the akonadi database, I ran as fast as I could away from it, because I knew where it was headed and kmail's previous "rock solid just works dependability" wasn't anywhere near that destination on the map. Ironically, I ended up on claws-mail, which as the then sylpheed-claws had been my second choice behind kmail when I switched from MS back at the turn of the century. Had I just made the other choice back then, I'd have never had to deal with having to convert over a decade's worth of mail and filters to c
Re: how to autohide the panel?
On Thu, 2022-02-24 at 01:34 -0600, vicepresid...@pumpingstationone.org wrote: > I haven't had this issue on any of my machines, but have you tried > re-creating > the panel, or wayland vs X11? > Wayland is the reason that I switched from fvwm to kde. It still doesn't work with NVIDIA, but I have a Radeon card now and it works. Even the panel now hides. Now I'm wondering how to get rid of the transparancy in dolphin and some other windows ... what a totally stupid idea is it to make windows transparent?? > It looks like there are a few similar bug > reports[1], but I imagine this issue may be present for different reasons on > different systems. It may be worth checking system logs also. > Maybe it's because of NVIDIA. > And not to get off topic, but I'd be interested to know what problems you're > having with > kmail? My experience has been really good with it. Kmail keeps messing up it's database, even when using mariadb. That must be badly programmed since it doesn't even distinguish upper and lower case for table names ... Kmail --- or aconadi --- just doesn't work. Besides, it's really awful because it creates files with settings all over the place so it's even very difficult to get rid of all the settings when you want to start over with kmail. That's the kind of mess which is one of the reasons not to use windows since windows 3.1.
Re: how to autohide the panel?
I haven't had this issue on any of my machines, but have you tried re-creating the panel, or wayland vs X11? It looks like there are a few similar bug reports[1], but I imagine this issue may be present for different reasons on different systems. It may be worth checking system logs also. And not to get off topic, but I'd be interested to know what problems you're having with kmail? My experience has been really good with it. [1] https://bugs.kde.org/buglist.cgi? bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNE D&bug_status=REOPENED&field0-0-0=product&field0-0-1=component&field 0-0-2=alias&field0-0-3=short_desc&field0-0-4=status_whiteboard&field0-0-5 =content&no_redirect=1&order=changeddate%20DESC%2Cbug_status%2Cp riority%2Cassigned_to%2Cbug_id&query_format=advanced&type0-0-0=sub string&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&type0 -0-4=substring&type0-0-5=matches&value0-0-0=auto-hide&value0-0-1=auto- hide&value0-0-2=auto-hide&value0-0-3=auto-hide&value0-0-4=auto- hide&value0-0-5=%22auto-hide%22
Re: how to autohide the panel?
On Thursday February 24 2022 03:22:18 hw wrote: >Having the windows above the panel is useless because it would prevent >me from using the panel altogether unless I keep moving the windows around >every time I need to use the panel. No you don't. Remember this thing called a keyboard, and something called shortcuts? ;) Learn the ones for raising and lowering the window under the mouse cursor (or change them to your liking). "Windows can go over" the panel means they can also go under it. This does mean you have to set the WM to "focus-follows-mouse" (in KWin you'll probably want to pick the flavour called "Mouse precedence") but given your remarks about fullscreen mode I guess you may already be working in that mode. You're right that it's not necessarily the desktop notifications which show up in the Notifications widget that cause this. It's something like "window wants to grab your attention", which also causes the window representation in the panel to be marked (and even then there may be a priority hierarchy to this). I get them from my browser for instance, when it opens a new tab: see the screenshots. With "windows can go over", if I simply move my cursor upwards the panel appears and shows the 1st view; when I move the cursor down again it goes back under. If ever it didn't, I'd use my shortcut to bring the window I want to the front. NB: I may be using the Plasma4 desktop shell, but I use a recent'ish KWin5 so window layering and focus management work the same for me as they do for you. If KDE's Plasma desktop shell doesn't work for you you can always use a different one that does. Most DEs allow you to use another window manager if you do prefer KWin, for instance. R
Re: how to autohide the panel?
On Thu, 24 Feb 2022 03:22:18 +0100 hw wrote: > On Wed, 2022-02-23 at 11:52 -0700, Stephen Dowdy wrote: > > On 2/23/22 11:12, Patrick Nagel wrote: > > > On Wednesday, 23 February 2022 16:47:03 CET hw wrote: > > > > I have set the panel to autohide and it's not hiding except > > > > sometimes:( Instead the windows go underneath the panel, > > > > which is very annoying. > > > > hw, > > > > IME, the most common reason for this is an app doing some > > update/notification function forcing the panel to pop up to handle the > > notification event. > > > > This could be a download in a web browser (you see the browser icon with a > > progress indicator scanning across the icon), or other app trying to get > > your attention to show some state changing or warning. (perhaps something > > in the system tray > > It's not notifications that make the panel come up --- which it shouldn't > to begin with for that anyway. It just doesn't hide. Besides, I'm set to > do not disturb. > > > > > Yes, this can be frustrating to identify exactly what's "misbehaving" (the > > panel is doing what it was designed to do, but it's not what you expect). > > > > I don't offhand know If/How there are knobs to control the panel behavior's > > handling of such update/notification events in autohide mode, but that's > > where you should start digging. > > It's the panel not hiding. If the panel is designed not to hide like 99% > of the time, that option should be removed altogether to make for easier > source code. > > > Perhaps try looking at: > > > > kcmshell5 notify > > > > and context-clicking (right-mouse) the notifications system tray icon > > (Configure Notifications) and fiddle with the "track file transfers and > > other jobs" and "show application and system notifications" buttons. > > (you'll probably lose the usefulness of the notifier. maybe you can run > > that with plasmawindowed instead? > > > > > > I guess now that i have one or more 4K monitors on my desktops i just don't > > try to use 'autohide anymore" :-/ > > There are some windows that are insisting on either full 4k or a much > lower resolution, or full screen. Since full screen blocks everything > else and is a thing that should have died along with msdos, I tried to > autohide the panel and found that autohiding just doesn't work. > > Having the windows above the panel is useless because it would prevent > me from using the panel altogether unless I keep moving the windows around > every time I need to use the panel. > > And seriously? Why should I have to fiddle around with things at all > when there is a totally simple option for automatically hiding the > panel? Are there some hidden options that I need to find that make > the simple option work eventually after I spent searching hours for a > solution? > > It's bugs like this one, plus kwin not even being able to do > focus follows mouse correctly and kmail still not working at all > that make me go away from KDE. I like KDE and kmail, but there is > no point in using it when the major things which speak for using it > don't work. > > At least I'm apparently not the only one who has found that autohiding > the panel doesn't work ... > Auto hide has always worked here pain in the butt that it is Arch Linux fully up to date Operating System: Arch Linux KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.10-arch1-1 (64-bit) Graphics Platform: X11 Processors: 8 × AMD FX-8370E Eight-Core Processor Memory: 15.6 GiB of RAM Graphics Processor: AMD HAWAII Pete
Re: how to autohide the panel?
On Wed, 2022-02-23 at 19:12 +0100, Patrick Nagel wrote: > Hi, > > On Wednesday, 23 February 2022 16:47:03 CET hw wrote: > > I have set the panel to autohide and it's not hiding except > > sometimes :( Instead the windows go underneath the panel, > > which is very annoying. > > Not happening for me (Plasma 5.22.5 on Kubuntu 21.10). Well, it's not hiding here. Isn't that a basic feature that should be working fine since a long time? > > > Is there a way to get the panel to automatically hide like it's > > supposed to? How is it possible that even simple things like > > this still aren't working after 25 years or so of KDE? > > Your post would have been more useful if you had stated the Plasma version > you're using, and if you had omitted that last sentence ;) Well, maybe then you can explain how it's possible that simple basic features don't work though KDE has been around for a pretty long time now? It's the version that is in Fedora 35 --- I'm now seriously giving gnome a try because of this. If that doesn't work out, I might just go back to fvwm.
Re: how to autohide the panel?
On Wed, 2022-02-23 at 11:52 -0700, Stephen Dowdy wrote: > On 2/23/22 11:12, Patrick Nagel wrote: > > On Wednesday, 23 February 2022 16:47:03 CET hw wrote: > > > I have set the panel to autohide and it's not hiding except > > > sometimes:( Instead the windows go underneath the panel, > > > which is very annoying. > > hw, > > IME, the most common reason for this is an app doing some update/notification > function forcing the panel to pop up to handle the notification event. > > This could be a download in a web browser (you see the browser icon with a > progress indicator scanning across the icon), or other app trying to get your > attention to show some state changing or warning. (perhaps something in the > system tray It's not notifications that make the panel come up --- which it shouldn't to begin with for that anyway. It just doesn't hide. Besides, I'm set to do not disturb. > > Yes, this can be frustrating to identify exactly what's "misbehaving" (the > panel is doing what it was designed to do, but it's not what you expect). > > I don't offhand know If/How there are knobs to control the panel behavior's > handling of such update/notification events in autohide mode, but that's > where you should start digging. It's the panel not hiding. If the panel is designed not to hide like 99% of the time, that option should be removed altogether to make for easier source code. > Perhaps try looking at: > > kcmshell5 notify > > and context-clicking (right-mouse) the notifications system tray icon > (Configure Notifications) and fiddle with the "track file transfers and other > jobs" and "show application and system notifications" buttons. (you'll > probably lose the usefulness of the notifier. maybe you can run that with > plasmawindowed instead? > > > I guess now that i have one or more 4K monitors on my desktops i just don't > try to use 'autohide anymore" :-/ There are some windows that are insisting on either full 4k or a much lower resolution, or full screen. Since full screen blocks everything else and is a thing that should have died along with msdos, I tried to autohide the panel and found that autohiding just doesn't work. Having the windows above the panel is useless because it would prevent me from using the panel altogether unless I keep moving the windows around every time I need to use the panel. And seriously? Why should I have to fiddle around with things at all when there is a totally simple option for automatically hiding the panel? Are there some hidden options that I need to find that make the simple option work eventually after I spent searching hours for a solution? It's bugs like this one, plus kwin not even being able to do focus follows mouse correctly and kmail still not working at all that make me go away from KDE. I like KDE and kmail, but there is no point in using it when the major things which speak for using it don't work. At least I'm apparently not the only one who has found that autohiding the panel doesn't work ...
Re: how to autohide the panel?
PS: the answer to the question "how to autohide the panel?" must be something like *you* can only hide or unhide the panel yourself. Or set it to autohide 8-) R. / who couldn't resist.
Re: how to autohide the panel?
On Wednesday February 23 2022 19:12:51 Patrick Nagel wrote: >> Is there a way to get the panel to automatically hide like it's >> supposed to? How is it possible that even simple things like >> this still aren't working after 25 years or so of KDE? > >Your post would have been more useful if you had stated the Plasma version >you're using Indeed. >and if you had omitted that last sentence ;) Not really, because inquiring minds do want to know! And FWIW, I'm sure the OP uses a much newer version than the good old Plasma4 I've been sticking to (for the desktop shell). I recall having read an explanation a couple of year back, that must have included Stephen's assumptions about notifications. I also recall having thought "why do easy if you can do complicated". AFAIK the panel doesn't have to come out of hiding if there's a notification, and esp. it doesn't have to remain unhidden. R. PS: I also no longer use autohide. Instead, I use "windows can go in front" or whatever it's called. That seems to work more reliably and is even a bit more useful (I don't necessarily have to unhide the panel to see the time, for instance) though it too can be annoying. There I times I trigger it because of cursor overshoot, there are times where it won't go back (presumably because of a notification) and sometimes I need to try several times to trigger it.
Re: how to autohide the panel?
On 2/23/22 11:12, Patrick Nagel wrote: On Wednesday, 23 February 2022 16:47:03 CET hw wrote: I have set the panel to autohide and it's not hiding except sometimes:( Instead the windows go underneath the panel, which is very annoying. hw, IME, the most common reason for this is an app doing some update/notification function forcing the panel to pop up to handle the notification event. This could be a download in a web browser (you see the browser icon with a progress indicator scanning across the icon), or other app trying to get your attention to show some state changing or warning. (perhaps something in the system tray Yes, this can be frustrating to identify exactly what's "misbehaving" (the panel is doing what it was designed to do, but it's not what you expect). I don't offhand know If/How there are knobs to control the panel behavior's handling of such update/notification events in autohide mode, but that's where you should start digging. Perhaps try looking at: kcmshell5 notify and context-clicking (right-mouse) the notifications system tray icon (Configure Notifications) and fiddle with the "track file transfers and other jobs" and "show application and system notifications" buttons. (you'll probably lose the usefulness of the notifier. maybe you can run that with plasmawindowed instead? I guess now that i have one or more 4K monitors on my desktops i just don't try to use 'autohide anymore" :-/ --stephen
Re: how to autohide the panel?
Hi, On Wednesday, 23 February 2022 16:47:03 CET hw wrote: > I have set the panel to autohide and it's not hiding except > sometimes :( Instead the windows go underneath the panel, > which is very annoying. Not happening for me (Plasma 5.22.5 on Kubuntu 21.10). > Is there a way to get the panel to automatically hide like it's > supposed to? How is it possible that even simple things like > this still aren't working after 25 years or so of KDE? Your post would have been more useful if you had stated the Plasma version you're using, and if you had omitted that last sentence ;) Patrick.
how to autohide the panel?
Hi, I have set the panel to autohide and it's not hiding except sometimes :( Instead the windows go underneath the panel, which is very annoying. Is there a way to get the panel to automatically hide like it's supposed to? How is it possible that even simple things like this still aren't working after 25 years or so of KDE?