hw posted on Sun, 27 Feb 2022 17:14:52 +0100 as excerpted:
> On Sun, 2022-02-27 at 07:31 +0000, 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 [...]
>
> 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.
I don't trust evolution/thunderbird because I'm one of those "old fogys"
that doesn't trust html mail displayed as a web page. The complexity is
unnecessary and a source of many *MANY* security bugs, that simply don't
apply if the mail is parsed and displayed as plain text, perhaps with
clickable URLs but if so it's URLs you can actually see the link you'll be
going to. (FWIW back when I used it I had kmail set to display plain
text, as IIRC I did OE back on MS before that.)
As for attachments, while I admit I prefer kde's approach, I "get by" with
the gtk approach used by firefox and claws-mail.
As for font sizes... I guess I solved that too by throwing money at it.
I mentioned big-screen TVs as monitors. Try two 75-inch/190-cm 4K TVs
mounted side by side on wall-arms, giving me effectively almost an entire
wall as display! =:^)
While that's something like 60 DPI I deliberately never set that so
wayland is using the 96 DPI standard default (as was xorg before), meaning
things are ~60% larger than standard. At perhaps a meter/yard viewing
distance that's big enough even my 55-year-old eyes don't have particular
trouble with it. Plus there's zoom if they do. =:^)
Tho at 130 inches combined the field-of-view's actually a little too
wide. My next upgrade (after upgrading the computer itself, which is now
a decade old after spending all my recent computer budget on the TVs as
monitors and on SSDs, so we're probably talking a couple years out) would
be a 120-inch 8K if I could, but that's likely to be cost-prohibitive, so
assuming I get a graphics card that can handle 4 outputs in the computer
upgrade, I'll probably do 4 60-inch 4Ks instead, 2x2 config for the same
display space and resolution as the 120-inch, that being 105x60 inches @
7680x4320, while the current space is 37x130 inches @ 7680x2160.
--
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
