On Tuesday, February 26, 2013 17:54:18 Marco Martin wrote: > * everything regarding configuration uis goes away from libplasma
define "everything". there are four aspects to configuration: 0. the actions that trigger showing configu UI 1. notifying the component (e.g. plasmoid) that configuration has completed 2. creating and showing the actual window the config appears in 3. the control UI inside the window (Ok/Cancel, etc) where these should be implemented is critical as it will allow (or deny) new device adaptations, future flexibility with script engines, etc. iow, if we do not get this right, the work we're doing now will fail to meet the goals that got us started on this approach. one thing we need to avoid is reimplementing libplasma in the QML script engine. this will make any future scriptengine work far, far more work and will essentially make it impossible to support things like HTML5 applications. the division of labor might look like: 0. libplasma 1. the scriptengine (though this depends on 3, so probably via libplasma) 2. the shell. (otherwise it will become QML dependent. and how does HTML5 work then?) 3. libplasma? it needs to be consistent between script engines, but possibly vary between shells. > * the plasmoid may offer in their config directory a list of desktop files, > one per category, that would tell the name of the category, icon, > kconfiggroup and qml file to load how about a model driven mechanism instead? each configurable plasmoid could contain a QML component that provides a model in which each entry is a configuration page. translation would be handled in the normal fashion; support for kcm pages would be easy enough; would only require reading in one file and it could use laoders extensively to keep performance up. > * All configuration for applets based upon ConfigLoader, only one config.xml > per plasmoid, supporting multiple config groups this requires that ConfigLoader can create configuration structures from templates. otherwise how does one do something as simple as a launcher where each entry has its own configuration data (or group) right now, ConfigLoader (because it is a KConfigSkeleton) also requires that *all keys* have names that are unique in the ConfigLoader. that means that while they appear in different groups, they need unique names. that seems very awkward for anything moderately complex, and suggests to me we need a proper per-group API for KConfigSkeleton and ConfigLoader. > * one config group per page why? this would mean that the UI must match the configuration structure as stored on disk, and we know that "interface follows implementation" is a trap. what about pages with multiple config groups, as in the launcher example above? > * eventual extra config pages, like global shortcuts will be provided by the > shell package, because is not something applets should directly care about kcm's? this is an existing use case that we need to provide for unless we commit to reimplementing all the kcm's in qml :) -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/plasma-devel
