[KDE/Mac] plasma-desktop on other environments (bis)

[René J. V. Bertin]

On Sunday May 22 2016 18:43:34 Kai Uwe Broulik wrote:

I'm going to stop replying tit for tat here in an exchange, as so often, with a 
single principled developer who wants to make decisions for users of a platform 
he maybe never even used himself (at least that's the impression I get). There 
are lots of misconceptions about OS X, the image Apple like to paint of it 
doesn't really correspond to how many long-term users use it, esp. those who are 
(probably most) likely to install KDE applications (and esp. those who use 
MacPorts or Fink. Many of us are researchers or engineers or other "creative 
types" who need to get work done which usually isn't about designing shiny 
applications implementing the latest fashionable, hot and cool algorithms. For 
us there are much more important things than following ultimately random dogma.

> You shouldn't have to set that up, it should use the translation for whatever 
language your system is configured. 

Welcome to utopia. In my experience there are very few cross-platform 
applications where this kind of thing works out of the box.
And remember what I said about "regular" executables vs. app bundles (which 
would have to be "full" app bundles).

> Then you should configure your system to use that, and if it doesn't provide 
that, tough luck. In my opinion an application has no right to enforce its way 
of doing things like tabs on the user just because it thinks it's better - if 
the system has opted for a "worse" design we're obliged to implement it.

That's nonsense, except for the "no right to enforce its way of doing things 
like tabs on the user just because it thinks it's better". Not even the system 
has that right, it just has the opportunity. If applications can have that 
opportunity too (and they have under Qt, whether you like it or not), so much 
the better.

> The Qt os x platform theme maps shortcuts to eg Cmd+C already. 

Actually, no. QtBase doesn't even know the Command key. It doesn't something 
much more wonky than that: Qt::AA_MacDontSwapCtrlAndMeta which is off by 
default. The code is littered with checks whether that attribute is on or off, 
to know whether or not to swap the Ctrl and Meta keys back and forth. Mostly 
that works fine, but there's an issue somewhere in Qt5 that causes serious 
issues in applications like Konsole which really need to get Ctrl keypresses at 
times.

> Because on OS x we are not the platform 

You're not the "platform" anywhere. KDE provides the desktop environment on 
certain platforms.

> but applications within another. If I want to use Kate I don't want to have a 
gazillion services running, perhaps even after the application has quit. Imagine 
running Notepad++ and it did that.

Do not confound MS Windows and OS X. They're different beasts, and both have 
their share of background processes, services and agents. 

> Okay, I on the other hand want to be able to just use Kate or Dolphin as 
standalone applications without pulling in all of the backend services.

That isn't impossible, but you may find that certain features won't work.

> Os x has a Keychain system and I would expect applications to use it, running 
KWallet there instead would be a really bad idea, especially given how many 
complaints we get in Plasma already for it being intrusive. 

More OT stuff in this thread, but here goes:
I have written a Keychain backend for KDE4's KWallet, thinking it would improve 
things. It doesn't, not compared to the effort it cost me. The only thing it 
improved on OS X is that unlock requests no longer remained hidden behind any 
number of other windows but instead always pop up in front. That kind of dialog 
*has* to be obtrusive. The other possible advantages are that it *may* use a 
more secure encryption scheme than KWallet with Blowfish instead of GPG, and 
that keychains can be set to lock when the system goes to sleep. So I'm still 
doubting very seriously if I'm ever going to port the code to KF5:
- the Keychain SDK is much more limited so that it's impossible to map the 
KWallet API onto it.
- As a result, there's no exchange possible between "native" keychains and KDE's 
kwallets/keychains, which takes away an important argument for using keychains
- the lack of a central daemon makes it impossible to implement features like 
"lock keychain X minutes after the last client disconnected" properly. I've 
tried with shared memory, but it's a hack at best.
- OS X has a similar setting, but it's a hard interval. Using that, you find 
yourself entering passwords way too often if applications don't cache 
credentials in memory.

I now have kwalletd configured properly to run without being noticed and to come 
to the foreground when requesting a password. Interfacing with GPG doesn't work 
very conveniently as yet, but it'll work well enough for users who are used to 
leave their kwallets open.
But the jury is still out. I'm holding off on moving to KF5 PIM for various 
reasons so at the moment I have only very few KF5 applications that use KWallet. 
Once that changes my opinion might evolve.

R