[KDE/Mac] plasma-desktop on other environments (bis)
René J. V. Bertin
rjvbertin at gmail.com
Sun May 22 18:33:44 UTC 2016
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 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
> Because on OS x we are not the platform
You're not the "platform" anywhere. KDE provides the desktop environment on
> 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.
More information about the kde-mac