Aleix Pol wrote: >> kde-cli-tools and systemsettings5 are required to configure >> 1 wallet settings (regardless of whether KWallet uses native KDE wallets or >> an OS X keychain backend) > Makes sense, probably should be moved to KWallet?
Probably. >> 2 cookies and other html/browser related settings > What does it configure? is it only for KHtml? You can probably check better than I can at the moment, for the KF5 version at least :) On KDE4 it configure what cookies to accept, allows you to edit the cookie jar, to chose the html engine and probably a bunch of other things that are evidently related to HTML and Web functionality in KDE code. > >> 3 akonadi/PIM settings > It should probably go to PIM. Yes. As a general rule I think one can say that every application that uses a KCM module to configure part of its settings should provide a means to edit them. But wait, that already exists ... kcmshell :) Would it make sense to move kcmshell to a framework, replacing its payload with a kpart? Or is there some fundamental reason why kcm modules cannot run in the address space of an application other than kcmshell or systemsettings. > >> 4 fonts, icons and palette settings >> 5 style settings >> 6 interface settings like "click once or twice to open", "show icons in >> buttons/menus" etc. > > Here, it should integrate with the OS, IMHO. Like Plasma, OS X should > have a place where to configure those. If we forget about running (and configuring) KF5 applications under a non-Plasma X11 environment, then you have a point. However, > I don't think it's fair of us to ask the users on OS X to know the > application is special and that they need to go to a special place to > configure some details of how the application is going to behave. Fair enough. But you can also not ask of the OS to know about a family of applications which have an additional set of configuration settings, many of which are not configurable on a system level in OS X. Careful, I'm not claiming it's unheard of to configure specific details of an application's user interface, but that would be application-specific. Either the application would provide the interface to configure those settings, or it would provide a "PreferencePane" (the equivalent of a KCM), for instance if the application is part of a family. The easiest way to achieve this would be to provide a PreferencePane that adds an entry to the OS X "System Preferences"; there exist several of those which simply launch an external configuration utility instead of loading something like a KCM. Loading KF5's systemsettings that way would mean we don't have to write a whole comparable interface from scratch while users can still access it through the familiar interface (sounds like a win-win to me). BTW: PreferencePanes can be installed at the system level or per-user, and installation is triggered simply by double-clicking on them, so no sweat there. Alternatively it might be possible to that the approach describe above, and use a framework and kpart to load kcms in an application's address space. That way, interface settings could be made accessible through the Settings menu just like Notifications and Shortcuts are currently. > Regarding kio-cli-tools, these should be cross-platform and were never > meant to be part of plasma. It probably would even make sense to move > it to KDE Applications now? You tell me :) I do understand that I can thus expect patches for kde-cli-tools to be welcomed (for instance to avoid app bundle builds). Good. R. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel