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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
