| Summary: | configuration: can't add/remove properties for actions | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-solid | Reporter: | Eckhart Wörner <ewoerner> |
| Component: | general | Assignee: | Lukáš Tinkl <lukas> |
| Status: | REOPENED --- | ||
| Severity: | wishlist | CC: | afiestas, aseigo, kdelibs-bugs, wilderkde |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Eckhart Wörner
2010-09-25 17:30:20 UTC
this is part of solid; the device notifier simply integrates it into its configuration dialog. Please read the module documentation. Device parameters must be either a Conjunction or Disjunction to have children items, and must have 2 children only ( not any other number ). As such, when changing the type, the module automatically adds the two children. (In reply to comment #2) > Device parameters must be either a Conjunction or Disjunction to have children > items, and must have 2 children only ( not any other number ). As such, when > changing the type, the module automatically adds the two children. Sorry, but this is a highly technical approach to the problem. Of course it is possible to represent every possible formula through a full binary tree, but this is totally non-intuitive: - the user only sees that he can create sub-clauses when clicking the "Save Parameter Changes" button. Sure, it's in the docu, but who reads the docu? - the conjunction property (?) is labelled "All of the contained properties must match", which reads as if it was possible to have more than two contained properties. I probably would have expected "Both contained properties must match" - users don't think in "let's create a conjunction of two properties where the first property is a conjunction of two properties and the second conjunction is a conjunction of two properties", but in "let's create a conjunction of four properties". Also, since this is a wish, closing as INVALID is a bit weird. The wish in itself is perfectly fine. It is simply technically impossible to complete the wish, without altering the Solid Predicate language, which is located in kdelibs, and therefore subject to Compatibility constraints. The only other way to implement it would be by placing some form of a compatibility layer on top, which would be a hack, highly unreliable, and subject to generating invalid predicates. Adding Solid maintainer. This bug is reported on libsolid which is the kdelibs4 version of the solid library. It is now in maintenance mode. If you think it should still be fixed in the KDE Frameworks 5 version of solid please move it to or report a bug on frameworks-solid. |