Add settings and settingsList; remove anchors from inside EllipsisLabel #1

Merged
erinn merged 1 commits from settings into master 2020-05-27 00:01:08 +00:00
Owner
  • Adding a setting widget and a settingsList widget

  • Currently being used in WIP in cwtch ui for peerSettings and global Settings

  • also minor fix, ellipsisLabel shouldn't have had anchors inside it

- Adding a setting widget and a settingsList widget - Currently being used in WIP in cwtch ui for peerSettings and global Settings - also minor fix, ellipsisLabel shouldn't have had anchors inside it
erinn was assigned by dan 2020-05-26 22:14:37 +00:00
erinn requested changes 2020-05-26 23:48:29 +00:00
erinn left a comment
Owner

two minor comments. also, i notice that the 2-column grid approach for inlining would work just fine with only one grid, and pairs of children, instead of a Grid per setting. would that be worth it?

two minor comments. also, i notice that the 2-column grid approach for inlining would work just fine with only one grid, and pairs of children, instead of a Grid per setting. would that be worth it?
@ -16,3 +13,4 @@
property alias color: label.color
property alias size: label.font.pixelSize
property alias pixelSize: label.font.pixelSize
Owner

why both size and pixelSize?

why both size and pixelSize?
Author
Owner

legacy. deleted PixelSize and updated all references

legacy. deleted PixelSize and updated all references
Setting.qml Outdated
@ -0,0 +57,4 @@
} else {
settingLabel.height
}
}
Owner

you seem to be going to lengths to support multiple children but why stack children in an item like this? if someone needs more than one component for a setting, shouldnt they compose them in a single layout before setting is as a field? and then if we only need one child we can do something cleaner, like this: https://stackoverflow.com/a/12772703 perhaps?

you seem to be going to lengths to support multiple children but why stack children in an item like this? if someone needs more than one component for a setting, shouldnt they compose them in a single layout before setting is as a `field`? and then if we only need one child we can do something cleaner, like this: https://stackoverflow.com/a/12772703 perhaps?
Author
Owner

paranoia about weird QML ordering and a day of weird issues.
but yeah it should always have an item so i simplified it

paranoia about weird QML ordering and a day of weird issues. but yeah it *should* always have an item so i simplified it
Author
Owner

also, i notice that the 2-column grid approach for inlining would work just fine with only one grid, and pairs of children, instead of a Grid per setting. would that be worth it?

Couldn't figure an easy way to make it work with the HLine between each one easily

> also, i notice that the 2-column grid approach for inlining would work just fine with only one grid, and pairs of children, instead of a Grid per setting. would that be worth it? Couldn't figure an easy way to make it work with the HLine between each one easily
erinn approved these changes 2020-05-27 00:00:43 +00:00
erinn closed this pull request 2020-05-27 00:01:08 +00:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: openprivacy/opaque#1
No description provided.