plasma-desktop on other environments (bis)

[René J. V. Bertin]

Kai Uwe Broulik wrote:

>> No, KDE translations aren't linked in any way to the way the system handles
>> these
> 
> That doesn't change the fact that when my system is French I want the
> application to be French, too, which is what this kcm is about, choosing a
> language.

Yes, but without the KCM the only way of letting applications use the right 
translation is setting it for each application - if they even provide the menu 
to that effect.

>> them,  applications look just awful on OS X because most text elements will
>> use what Qt
> considers the platform default font (Lucida Grande 13).
> 
> Then this needs to be fixed. Also, the font stuff is enforced by the Platform
> Theme as far as I can see, so toolbar fonts for example will just use Qt's
> defaults for that, not KDE's semantic font.

How? Put platform-specific code at each location where a font role is invoked? 
That's not feasible. I am working on a Mac KDE platform theme which can be used 
with minimal changes to Qt. The default setting will use Qt's platform 
definitions for the various font roles, and the native widget style, so you get 
the "best" of both worlds. I think that's the most straightforward fix too as 
there apparently is no way to provide just something like a font theme.

>> It should be up to the user, and I'd even go so far as to say that this would
>> be a big plus for KDE applications on OS X.
> 
> I wouldn't call an application being ugly (read: not looking like all the
> others) a big plus.

Tastes differ, but you simply cannot defend that definition beyond your personal 
opinion.
OTOH one can defend the idea that certain users (probably well-represented among 
those who'd want to run KDE apps on OS X or MS Windows) will appreciate the fact 
that applications can look as much as possible on all the platforms where they 
use them (which is also in part the reason why Qt 5.6 now allows Freetype-based 
font rendering on OS X). I've argued this before: the advent of web-based 
applications has IMHO led to a more homogeneous look across platforms for a 
growing number of applications. Look at Google Chrome and even Firefox; just how 
different do they look on the different platforms?

> You can still re-arrange panels, customize toolbars and so on. Using a
> different theme to boost productivity, really? I agree that an application

Yes. I am definitely more at ease with an application that has a compact 
interface, uses a "semiserif" font in Medium/Demi-bold for text-only toolbars, 
in short, the sort of configuration that QtCurve allows me to get. Not to 
mention the silly tab-bar interface that OS X has, which is OK for dialogs but 
not when it turns up in the tabbed document interface of an editor.
You interact with GUI applications through their interface. If that doesn't look 
right you don't feel right.

> like Krita or KDevelop might want to offer a dark theme but then it could do
> that easily from within its settings.

There you have it. It is always possible to tweak quite a few things from within 
an application, even launch it with `-style QtCurve` if that rocks your boat. 
Most everything except for fonts, in fact (if you don't have the platform 
theme). Why not go a bit further and make it possible to configure those things 
at a global level (like the Qt4 qtconfig application already allowed)? 
Everything exists for that, just not in exactly the right place.

> Then this needs fixing. If we just use Breeze widget style the incentive for
> fixing it becomes near non-existent...

I've raised that flag before, but no one has ever shown any interest in fixing 
this. It isn't even clear where things go wrong, but since it's only the 
Macintosh style that shows this the issue is probably somewhere in the Qt/Mac 
drawing routines. Not in the qpa, because one gets almost the same glitches when 
using the xcb qpa on OS X.

> It's for providing a big-ass theme package consisting of a theme, splash
> screen, and so on, for easy adjustment to other form factors or distribution
> branding.

Not seeing the point doesn't mean that I don't know what it's for, in this case 
;)

> 
>> No, only for a very actions.
> 
> I see most of its actions mapped in the Plasma Platform Theme though.

What Plasma platform theme, the one in plasma-integration? That won't be used on 
OS X. It's been a while, but I'm pretty confident that I changed those mappings 
to platform-native mappings in my version of the platform theme. It's what I've 
done for other applications too where I intervened at this level.

>> ??? Kded is required for certain features like cookie management.
> 
> Really? Now I can understand why KDE 4 on Windows shipped with a "shutdown
> kde" application. Don't tell me I need DBus as well?!

Why would this be different on different platforms? KDE uses a distributed 
architecture for many things, and DBus is what glues that together. Fortunately 
DBus is enough of a cross-platform messaging API to build and run just fine on 
both MS Windows and OS X. I'm not familiar enough with the MSWin side, but on OS 
X there's a native hook to launch a session DBus at login, transparently and 
through the official interface (launchctl). I've set up a similar plist to 
launch kded5 at login.
So yeah, if you want to use applications that depend on features requiring DBus 
(KDE PIM comes to mind, but also anything else that uses KWallet and thus the 
kwalletd) you'll need to have DBus installed. 
A bit of a nuisance, but one that pales compared to the effort that'd be 
required to replace it with something else. (Also, OS X is a Unix, so DBus 
communications use the same kind of native APIs as would be used by a native 
SDK).

> QtMultimedia? Also, the Phonon KCM is really not something I want to have user
> needing to deal with...

Then that needs fixing O:-)

> If it's up to the application to do that on os x
> (Windows can do this at system-level) the application should have options for
> that.

KDE *is* the application level. It's all still "future music", but once this 
become reality I don't see why you'd want to have configure "notifications 
should sound through the onboard speaker, other sounds should go to my quality 
audio output device" for each and every application.

> From what I can tell toolbar icons in os x are black and white outlines just
> like Breeze so it would fit perfectly.

Only some are, and they're grayscale rather than b&w. I find the Oxygen theme to 
correspond better, though that's maybe because of the influence it probably had 
from earlier OS X versions (just like the Oxygen theme seems inspired by OS X <= 
10.6). Breeze looks too much like MS Win 10 IMHO.
In reality there is no "official" icon theme on OS X that I know of. AFAIK  
there are only design guidelines (=/= dogma), and applications have every right 
> want to avoid having kde systemsettings installed when I just want for example
> Kate. The few settings that may make sense could be embedded in the
> application and that's it.

for an obligation to look like the "autochtones" and not any other way, nor for 
an obligation to provide systemsettings c.s. But I also don't want to get the 
feeling that "this sort of thing is only for us running Plasma on our Linux 
boxes". That'd be just as infantile as when back in the day my 4yo sister told 
me I couldn't use this or that expression "because she invented it" ;)
> Unless, of course, we're aiming for a "suite" thing which installs a gazillion
> kde applications at once, then we might as well dump that in, just because,
> and while at it, kded, dbus and Co for good measure, too.

It is certainly true that for MacPorts we consider something like a KF5 family, 
which all share the same Qt and KF5 libraries, use shared resources as on any 
other Unix, etc. Kded is a KF5 framework so present by definition, but the other 
dependencies like DBus are provided through MacPorts so can be considered 
present. HomeBrew appears to have a slightly different approach (at least where 
DBus is concerned) but Fink almost certainly will do something similar as 
MacPorts.

> 
>> Settings that are problematic on a
> given platform, for whatever reason, should indeed better be disabled.
> 
> Looks like we have a different understanding of "problematic", for me
> problematic is not just when it doesn't build.