plasma-desktop on other environments (bis)

[René J. V. Bertin]

David Edmundson wrote:

> It's invoked by the colours and style KCM - so though I do think there is a
> demand for configuring apps on OS X, taking the KCM directly isn't a good
> idea because of that.

Or the invocation is made optional, skipped on platforms without X11...

The thing with not taking the KCMs at all is that will basically come down to 
reinventing the wheel for most if not all configurable settings. I think that 
the most efficient approach would be to reuse the existing KCM infrastructure, 
and probably even the systemsettings application, and mould that into something 
where applications can present an additional settings menu action that brings up 
a dialog that corresponds to the current systemsettings application (the icon 
view). Or an additional entry in their preferences/settings dialog that switches 
to that view.

Both OS X and MS Windows have "control panels" that have comparable interfaces, 
so this kind of relatively cheap solution shouldn't lead to something that's 
completely counter-intuitive.
On OS X there is probably also a way hook the KCMs into the existing System 
Preferences application (at the very least by invoking a KDE settings 
application from there, which really isn't all that uncommon a practice).

> I've noticed you've solved this by just including krdb (even with fixes!),

The fix is just to make krdb_clearlibrarypath a regular executable rather than 
an app bundle. Knowing now what krdb itself does means I'll probably just 
disable the target (or remove the binaries in my packaging if I'm lazy).

> but having krdb on OS X really doesn't make sense. It won't work.

I know that. My first approach has been to exclude krdb, but then noticed that 
it's needed for building certain other KCMs.
Given the role it plays it would maybe be useful to put it in a (static) 
library?

> I think that's symptomatic of what's worng with this approach - you need to
> identify what things you need and just tell us. Not assume it's everything
> and work backwards.

To put something straight: I'm not assuming anything. I'm taking stock. And for 
that I find working by elimination of working components works best. Rather than 
guessing what code does, and figuring out to what extent other bits depend on 
it, I prefer the hands-on approach, putting myself in the shoes of the user. 
Which I am too, after all.

R