Plasma 5 as a daily driver?

[Duncan]

P.  Gueckel posted on Mon, 09 Nov 2015 13:00:13 -0700 as excerpted:

> Ian Pilcher wrote:
> 
>> I find myself wondering if other people are really using Plasma 5 as a
>> "daily driver"...
> 
> It's a totally different world where I live :-) I've been using Plasma 5
> since the beta was released. Excellent experience!

FWIW, I'm still on kde4, tho I have as much of the base plasma5 installed 
as possible while keeping a working kde4, in ordered to facilitate 
testing.  The problem here was that until relatively recently, kwin5 
would go into an eternal crash/respawn cycle as soon as I tried to start 
plasma5.  Since kwin5 and kwin4, along with various other components from 
the two versions, couldn't be installed together, and kwin4/kde4 actually 
worked, I'd very quickly uninstall the broken test and reinstall what was 
tested working.

Recently that seems to have been fixed, but I've had much less time to 
test it recently, and while I /think/ at least the basics should work now 
(last time I did have time to test I only moved the user kde dir out of 
the way, not the XDG locations that the kde4 kactivitymanagerd used, and 
its config file that I had set read-only as a workaround for a kde4 bug 
screwed up the plasma5 activites, so I still didn't get a complete 
desktop, but I did get farther than I had previously and I think it'll 
actually work now if I let it work with a clean config), even if they all 
work well, it'll still take me some time to get it configured to my 
liking, and that's time I simply haven't had recently, so I'm still on 
kde4.

Fortunately I'm on gentoo, and the gentoo/kde project continues to 
support kde4, so I'm not in immediate danger of losing my actually 
working kde4 desktop. =:^)

> I haven't yet plugged in my television, so I don't know about having 2
> displays yet. I really need to give that a try. Perhaps tonight, since I
> rented a DVD from the library ;-)

By contrast, here multi-monitor support is absolutely mandatory.  
Actually, I think that /might/ have been what was sending kwin5 into its 
crash and respawn loop back in my early plasma5 testing.

FWIW, I have three monitors, all full-HD 1920x1080, in a logically 
stacked config, altho the smaller monitor is actually off to the side.  
Two monitors are actually 42 and 48 inch LED TVs, as at that size the 
higher demand for TVs scales their prices down so adding the TV tuner 
feature actually has a huge NEGATIVE cost, tho I've not actually used TVs 
as TVs since sometime late last century, I think.  The third one is a 21 
inch LED monitor that's actually from my previous generation of monitors, 
that I simply added because there was a third output on the graphics card 
and I could do so.  That's the one that's actually off to the side, tho 
logically stacked on top of the other two.

The small monitor is almost entirely dedicated to a superkarmaba theme 
showing computer status readouts, with the other two monitors actually 
forming my real workspace, unimpeded by panels and the like, tho I do 
have a small one set to popup in the lower right corner, when I hit it 
with the pointer.

Of the two big monitors, the bottom one is my primary working monitor, 
leaving the middle one as an aux monitor where I can run fullscreen 
youtube or for extra window space, as needed.

Here's a now somewhat dated screenshot, in all it's 1920x3240 glory, 
that'll give you an idea.  You can also see there that I make good use of 
half-width and almost-maximized windows, along with transparency, to give 
me access to upto three windows at once on each of the working monitors.

http://wstaw.org/m/2013/05/11/duncan-fullscreen.png

So I definitely put multiple monitors to good use and would be lost 
enough without them, that any desktop that doesn't work with multi-
monitor, simply isn't an option for me.

Unfortunately, as I've not switched to plasma5 yet, other than 
speculating that the multi-monitor might have been what sent earlier kwin5 
into the respawn cycles I was seeing, and the limited broken-activity 
(due to a kde4 workaround I forgot to remove for the test) multi-monitor 
support I was able to see in my last plasma5 test, I can't say how well 
it actually works in plasma5.

But one thing's for sure, if multi-monitor is broken in plasma5 and I 
can't find a workaround, I won't be using plasma5 until it's fixed.  (Tho 
judging from the OP description, the workaround may well be very similar 
to one I used for quite awhile on kde4, and would still be using except 
that plasma5's activity-manager has evidently taken over and doesn't have 
that bug, setting up a script to launch with kde that sleeps for a few 
seconds, then kills and restarts plasma, in which case I'll have a 
workaround and be able to use it.)

> Konsole size? Is it that much of a problem to size it?
> ;-) I haven't given this a try, so I don't know whether my system(s)
> is/are affected.

This one I can very likely help with, despite still being on kde4, and is 
why I'm actually replying. =:^)

At least on kde4, there's actually two ways to control konsole size.  
There's the konsole-built-in way, which I presume you were using and that 
now is broken or missing on plasma5, and the kwin windowrules way.  As 
I've made /extensive/ use of window rules to customize all sorts of 
behavior here, I tend to be somewhat of an expert on its use, and if 
those rules can't be made to work with kwin5 as well, I'll be extremely 
disappointed, to say the least.  But I think I actually saw the plasma5 
window rules dialog in a screenshot somewhere, so I'm pretty sure they're 
still there, even if konsole's built-in sizing option isn't.

Meanwhile, I do in fact control konsole size via kwin window rules here, 
because I have two different uses that need two different behaviors, 
including size, and kwin rules helps me enforce the difference.  (The 
details of why I need that and how I get kwin to recognize the different 
scenarios as separate are outside the scope of this post, but I can fill 
them in if asked.)

First (presumably it's the same in plasma5), window rules can be reached 
either via kde systemsettings, or from the window menu of any normal 
window.

My general konsole window rule has these settings (among others not 
apropos here):

Window matching tab:

Window class: Exact Match: konsole
Window role: Substring Match: mainwindow#
Window type: Normal window

Note that the string details here might be slightly different for plasma5, 
but with the detect window properties button or simply by choosing the 
special window settings option from konsole's system/window menu, you can 
detect the plasma5 settings.  The idea is to get it to match only konsole, 
but to match all konsole windows, so matching on window title, for 
instance, probably isn't desired, unless you substring-match konsole, 
perhaps.

Size & Position tab:

Size: Apply Initially: 956,1080
Maximized Vertically, Force, Yes
Minimum Size, Force, 956,530
Obey geometry restrictions, Force, No

The 956 width is, with window borders, half-width.  1080 initial height 
is obviously full-HD screen height, while 530 minimum height lets me 
shrink to half-height (window decoration/titlebar height not included) if 
I want two such windows visible on that side of the monitor.

Obviously you'd set these and the other settings on this tab as 
appropriate for you.

The Obey geometry restrictions option, often in combination with the 
Ignore requested Geometry option (confusingly similar names, different 
functions, hover over each for a description of what they do), allow kwin 
to override application specific behavior like the application trying to 
open to its last remembered size (requested), or trying to keep a 
specific aspect ration (restrictions).  IIRC here I used it to override 
konsole's normal wish to resize by displayed character dimensions, not 
absolute pixel dimensions.  So this one is likely to be pretty critical 
if you're trying to get konsole to fit a specific pixel size, regardless 
of how you zoom the font displayed inside.

(Tip that's not of particular use here, but worth noting for other 
cases.  Ignore requested geometry is in the negative, while Obey geometry 
restrictions is in the positive.  When you're troubleshooting, trying to 
get an app to behave, you'll often set both at first to see if it's app-
specific geometry behavior that's breaking the other settings, before 
sometimes unsetting the one that's not actually needed.  But because the 
two are worded with opposite logic, to actually change from the default 
honoring the requests, you'll need to set them opposite, here, ignore 
requested geometry, yes, since it is normally not ignored, obey geometry 
restrictions no, since they're normally obeyed.  With any luck the 
wording and logic for one setting or the other will have changed for 
plasma5, so they don't have opposite logic, tho I admit the easiest way 
to fix it, switching Obey to Ignore as well, so you set yes to change the 
default behavior for both cases, would only make the names even MORE 
confusingly similar, which is I'd guess exactly why they did the opposite 
logic in the first place, to avoid the names being even more confusingly 
similar than they are!)

> What used to be the ugly cashew is now known as the Desktop Toolbox. I
> think it is entirely redundant, since all of the commands it offers are
> accessible on the right mouse button menu item Desktop Settings. You can
> enable/disable the Desktop Toolbox on the Tweaks page. I have always
> hated that thing, since it disrupts the symmetry and aesthetics of the
> clean desktop.

I haven't particularly minded the cashew here, especially after they 
changed it to fade out unless hovered over, but I never really understood 
why they insisted on it remaining for those really bothered by it, when 
its functionality was available elsewhere.  So reading that there's an 
option to turn it off in plasma5 is good news, and given the option, I 
probably will as well.

> CapsLock is permanently disabled here. I have mapped Compose to that
> key, which is useful to me. CapsLock just caused me problems, getting
> hit by accident with my thick fingers ;-)

What I did here was simply pry off the capslock key.  That left a hole 
that made it far easier to position my fingers by touch, while leaving 
the actual capslock function still available, on the rare occasions I 
really wanted it.  I just use a pen or something to reach in the hole and 
toggle it, now, if I really need to.

But the touch-positioning benefit was *far* more effective than I'd have 
thought it'd be, such that it's now hard to work on a normal keyboard 
without that "hole" for positioning.  To me, that ended up being at least 
as beneficial as not fat-fingering capslock when I meant to hit tab, and 
in fact, the hole is how I find tab, situated immediately above it, these 
days.

> I don't mean to discredit your/others' experience(s), but it seems to me
> that a lot of people are nitpicking about a lot of insignificant stuff.
> Oops! Did I say that? :-O I guess if it's important to you ;-) but I
> think we need to keep in mind that it's a work in progress and the
> required functionality is all there. I've never been a big fan of all
> the widgets anyway, just a lot of clutter on the desktop and in the
> system try. I guess for some of you it is important ;-)

Of course, as you somewhat implied, one person's insignificant nitpick is 
someone else's absolutely critical feature, as the kde devs found out all 
too well in the kde3 -> kde4 upgrade.  Thankfully, they're being less 
forceful about dropping support for what actually works in favor of new 
but broken stuff, this time around.  If distros are forcing upgrades, 
that's on them and for me anyway could be a reason to switch distro, but 
at least the kde folks are being a bit more understanding about people's 
absolutely critical features, this time around, and continuing to provide 
at least minimal/security upgrades somewhat longer, for those who find 
their absolutely critical features are simply broken in the new version, 
and who thus need to wait awhile until they're either fixed or worst-case 
dropped as features entirely, so they know they have to find alternatives.

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

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.