Re: how to autohide the panel?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux