how to autohide the panel?

[hw]

On Sun, 2022-02-27 at 07:31 +0000, 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, here.  I'd be 
> interested...

Well, the problem is that there is no alternative.  Gnome remains still
completely unusable because I can't even get it to raise a window by
clicking on its decorations, which means I can't raise it at all, which
means I can't use the program displaying that window when there is more
than one window on the display because windows will overlap.  Otherwise
I could as well use a tiling WM like i3.  Gnome needs a usable window
manager before anything else but it's never gona happen because the
developers want it to remain unusable as it is.  I don't understand why
they are even working on something unusable, but that's their problem.

Everything else doesn't use wayland.

> 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?

> 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 claws-mail format due to kmail jumping the akonadi shark.  Oh, 
> well...

Claws can't even really remember what to open attachments with.  It's like a
version of thunderbird with missing features but a lot faster.  But how do
you even change the font size in thunderbird??

I can currently live with evolution, but you can't change font size, either.
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.