This fixes a bug that was introduced in 01da750899 with a breaking change
where `StatusChatListCategoryItem`'s `clicked` signal would no longer receive
a `mouse` event object.
The reason this is happening is because we've introduced a new `clicked` signal
on `StatusListItem`. The idea was to rely on that within `StatusChatListCategoryItem`,
however, we didn't take into account that the new `clicked` signal in `StatusListItem`
doesn't emit a `mouse` event object.
To fix this issue could either reintroduce the custom `clicked` handler on
`StatusChatListCategoryItem`, or listen to the original `sensor.onClicked` and
`onTitleClicked` signals exposed by `StatusListItem` instead, ensuring the required
`mouse` event data exists.
Fixes#333
This implements drag and drop capabilities of chat items within a `StatusChatList`.
The commit introduces a `DelegateModal` to visually reorder chat items
when they're being dragged and dropped onto a `DropArea`.
To persist the new order of chat items, various signals have been introduced to chat
list related components:
```qml
StatusChatList {
onChatItemReordered: function (id, from, to) {
// ...
}
}
StatusChatListAndCategories {
onChatItemReordered: function (categoryId, chatId, from, to) {
// ...
}
}
```
There's no such API on the `StatusChatListCategory` type because that one already
exposes its underlying `StatusChatList` via `chatList`, which makes the signal available.
Dragging and dropping chat items is disabled by default and needs to be turned on
using the `draggableItems` property:
```qml
StatusChatList {
draggableItems: true
...
}
```
These properties can be used to determine whether a user has either
interacted with the form control, or changed its value.
It's also used in initial validation to ensure validation is done but
visually, form controls stay untouched.
Closes#327
A single `signal itemClicked(string firstLevelItemValue, string secondLevelItemValue)`
with parameters referring to the first level and second level item is exposed
and replaced multiple signals we had before for the same purpose.
A click on the item's title or whole item emits appropriate `titleClicked` or
`clicked` signal with `titleId` or `itemId` value respectively. `titleId` and
`itemId` may or may not defer from their display values, it's up to logic which
is applied.
This is introduced because of need of the issue-2934.
There's a new `validators` property that can be used to add validators to `StatusInput` instances, which are executed in the same order:
```qml
StatusInput {
text: "Some value"
validators: [...]
}
```
For convenience StatusQ provides some common validation methods, such as `StatusMinLengthValidator`, StatusMaxLengthValidator` and could be extended to other (e.g. email validation etc):
```qml
StatusInput {
text: "Some value"
validators: [
StatusMinLengthValidator { minLength: 3 }
]
}
```
Validators are executed every time the text of the input changes. They are executed in the same order they have been applied, which enables users to create cascading conditions like "First make sure the value is at least 3 characters long, then make sure it matches a certain pattern".
When a validation fails, it sets the validity of the input (`valid: false`) accordingly and optionally exposes additional error information on `StatusInput.errors`:
```qml
StatusInput {
text: "Fo"
onTextChanged: {
if (errors) {
/**
* errors now has the following structure:
* errors: {
* minLength: { minValue: 3, actual: ... }
* }
* Also, `StatusInput` is now `valid = false`
**/
errorMesssage = "Expected " + errors.minLenght.minValue + " but got: "+ errors.minLength.actual; // i18n'able
}
}
validators: [
StatusMinLengthValidator { minLength: 3 }
]
}
```
There can be any number of error objects on the `errors` property, depending on who many validators have been run that failed validation.
Custom validators can be implemented by introducing a new `StatusValidator` type that has to implement a `validate()` function and defines the validators name. The `validate()` function has to return either `true` or `false` depending on whether the value is valid.
Alternatively, the function can return an error object which gets exposed on the underlying input's `errors` property, at which point it's considered invalid as well.
Here's a simple custom validator:
```qml
// HelloValidator.qml
import StatusQ.Controls.Validators 0.1
StatusValidator {
property string name: "hello"
validate: function (value) { // `value` is the `text` value of the underlying control
return value === "hello"
}
}
```
Applying this validators would look like this:
```qml
StatusInput {
text: "Some value"
validators: [
HelloValidator {}
]
onTextChanged: {
if (errors.hello) {
errorMessage = "Doesn't say hello!"
}
}
}
```
Alternatively, validators can return error objects to provide more information about what went wrong. Here's the implementation of the `StatusMinLengthValidator` as an example:
```qml
StatusValidator {
property int minLength: 0
name: "minLength"
validate: function (value) {
return value.length >= minLength ? true : {
min: minLength,
actual: value.length
}
}
}
```
Because validators as components, they can hold any custom properties they need to be configured.
There has been concern that, with this API, error messages need to be potentially defined in multiple places, given that there could be multiple instances of any validator. This is easily solved by having a centralized function figure out what the error message is, given a certain error object:
```qml
StatusInput {
validators: [
StatusMinLengthValidator { minLength: 3 }
]
onTextChanged: {
if (errors) {
errorMessage = getErrorMessage(errors) // this function is provided by global or elsewhere
}
}
}
```
Closes#298
Prior to this commit, setting `charLimit` on `StatusInput` would only have a visual effect
(rendering the char limit), however it wouldn't actually enforce this limit.
This was by intended behaviour, because we wanted to leave some room
for possible validators to kick in (for example a max length validator).
If however the char limit is enforce, such a validator would never kick in.
There seems to be consensus in the team that the limit should be enforced though.
This commit enables that.
The menu has a CloseOnReleaseOutside policy and so it
was closing and immediately re-opened when the kebab icon
was clicked since it's outside the menu area and also was
calling the popup function of the menu. Added dummy bool
property to detect whether the menu is already closed and
not open it again
Closes#308
There's some usage specific color being added to the chat input (which doesn't live in
StatusQ yet). To make sure we don't lose that change, I'm adding the new
colors to StatusQ theming system and have Status Desktop use it for the time being
until `StatusChatInput` is moved to StatusQ anyways.
khushboo-dev-cpp
B.Melnik
Pascal Precht
Alexandra Betouni
Sale Djenic
Alexandra Betouni
RichΛrd
Jonathan Rainville