This adds a new `value` property to the component to set label for a
selected value and also rendering a chevron as an indicator that the list
item becomes clickable.
This changes the share of the model expected to render search results.
BREAKING CHANGE:
The model has changed in the following way:
- `image` field added
- `color` field added
- `badgeIdenticonColor` field renamed to `badgeIconColor`
- `isLetterIdenticon` field renamed to `badgeIsLetterIdenticon`
There are now two new properties in `StatusModalHeaderSettings`:
- `titleElide`
- `subTitleElide`
These can be used to configure the `elide` property of both header titles.
The default values for both of them is `Text.ElideRight`.
Closes#353
This commit add elide flags to text in title and subtitle and add flexibility to width. Now compoents use next rules:
1. If width is set - text should be elided when implicit text width is more than root object width
2. Component grows if width is not set based on inner elements natural sizes
Closes: #335 and #338
There was an explicit `width` introduced on `statusListItemTitle`, most likely
to make room for it when `titleAsideText` is supplied.
This unfortunately causes the title get a very small width, resulting in broken
UI.
Since we can assume that there should be enough space for the titleAsideText
when it's used, we probably don't have to calculate a fixed width for the title
in the first place.
This commit therefore removes that explicit setting.
* feat(StatusChatListAndCategories): add drag and drop support for categories
This adds support for dragging and dropping chat list categories.
To persist reorder of chat categories, the new `onChatListCategoryReordered`
signal can be leveraged.
Drag and drop of categories is turned off by default and needs to
be turned on using `draggableCategories: true`.
Closes#227
* feat(Status.Core): introduce Utils namespace
This adds a new package for utility related things.
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.
This extends the popup menu to accept image or icon configurations a la `StatusIconSettings`
and `StatusImageSettings` in menu items, as well as nested menus.
Usage:
```qml
StatusPopupMenu {
StatusMenuItem {
text: "Custom Image icon"
image.source: // image source
}
StatusMenuItem {
text: "Custom identicon icon"
image.source: // identicon source
image.isIdenticon: true
}
StatusMenuItem {
text: "Custom letter identicon"
iconSettings.isLetterIdenticon: true
iconSettings.background.color: "red"
}
}
```
Few things to note:
- Because `StatusMenuItem` is an `Action` type, we can't extend its `icon` property,
so we have to introduce our own (`iconSettings`) which can be of type `StatusIconSettings`
- Where possible, `StatusPopupMenu` will prefer `iconSettings.[...]` over `icon.[...]`,
which means, both would work: `icon.name` and `iconSettings.name`.
This is for consistency's sake. Consumers can switch completely to `iconSettings` if desired.
- When `isLetterIdenticon` is true, `iconSettings.background.color` must be set, similar
to how it work in any other StatusQ component that makes use of this configuration type.
Closes#263
This component can be used to group different sections within a popup menu.
Usage:
```qml
StatusPopupMenu {
StatusMenuItem {
text: "One"
icon.name: "info"
}
StatusMenuHeadline {
text: "Some text"
}
StatusMenuItem {
text: "Two"
icon.name: "info"
}
}
```
There's cases where the arrow on the tooltip needs to be repositioned, for example
when the tooltip doesn't fit into the viewport anymore but is centered below a button.
This adds a `StatusModalDivider` to the header and footer so they don't
have to be put into `content` and therefore won't scroll out of the viewport
if the content exceeds the modal height.
The footer divider is only rendered when there's indeed action buttons
provided.
Closes#265
This commit adds the members and search button which are needed for certain
features in Status Desktop. In views where these aren't needed, each button
can be set `visible: false` individually:
```qml
StatusChatToolBar {
...
membersButton.visible: false
searchButton.visible: false
}
```
Closes#243
This adds support for letter identicons by using the `icon.isLetterIdenticon`
flag:
```qml
StatusListItem {
title: "Some name"
icon.isLetterIdenticon: true
icon.background.color: "orange"
}
```
Closes#239
Adding picker button
* As an example it opens Qt's ColorDialog, as soon as
a color is selected there, the button is colored
with that. Final color picker to be implemented in
a seperate task.
Also minor improvements in main.qml and sandbox.pro
Closes#202
This just introduces a new `StatusImageSettings` property `isIdenticon`
which can be used to determine whether a `StatusRoundedImage` should
render with a background + border (which is the case for identicons).
It also updates the `StatusChatList` delegate to consider that property
and have it properly decide how to render the UI.
Closes#173
This property enables users to pass as factory function to `StatusChatList`
component that determines the profile image of a given chat id.
Usage:
```qml
import StatusQ.Components 0.1
StatusChatList {
...
profileImageFn: function (id) {
// `id` is the model id of the current chat item iterator
return ... // has to return a profile image url
}
}
```
In addition to this property, this commit also makes the component
expect an optional `model.identityImage` in case it's already provided.
That way, `profileImageFn` can be omitted.
Closes#174
Chat list items can open a context on right click as well, so `StatusChatList`
needs to provide an API for users to pass down a `StatusPopupMenu` accordingly.
This is now possible with a dedicated `popupMenu` proporty that can be
used as follows:
```qml
StatusChatList {
...
popupMenu: StatusPopupMenu {
property string chatId
openHandler: function () {
...
}
StatusMenuItem {
...
}
...
}
}
```
As will all `popupMenu` properties in StatusQ component, having this explicit API
option enables us to have control over how triggering components (in this case chat
list items) behave when they open a context menu (e.g. keeping them highlighted as long
as the menu is active).
When defining a `chatId` property, `StatusChatList` will hydrate it with the id of
the chat list item that has triggered the menu.
If there's more logic to be executed upon opening the menu, `openHandler` serves
as a hook similar to other popup menus. Inside the hook, users have access to the
specific `chatId`.
Closes#171
This is because we ran into issues where some component compositions
caused scrollviews to be nested which rendered them non-functional.
For now we're rolling back the idea of components being smart enough
to become scrollable by themselves and have StatusQ consumers handle
scroll behaviour.
This is a wrapping component that can be used to render community chat
lists and categories. It takes care of rendering categories, the top
chat list, as well as becominng scrollable in case the content outgrows
the available space.
Usage:
```qml
import StatusQ.Components 0.1
StatusChatListAndCategories {
chatList.model: ... // non-categorized chat items, pass all chat items here, the component will take care of filtering categorized items out
categoryListModel: ... // available categories (need to have `id` and `name`)
selectedChatId: ...
showCategoryActionButtons: true // default `false` - useful when only admin users can create and mutate categories/channels
onChatItemSelected: ... // `id` is available for selected chat id
categoryPopupMenu: StatusPopupMenu { // optional popup menu for category items
property string categoryId // define this property to have it hydrated with correct id and make it available inside menu items
...
}
popupMenu: StatusPopupMenu { ... } // optional popup menu for whole list, will be triggered with right-click
}
```
Closes#133
This uses the newly introduced `filterFn` in `StatusChatList` to hide chat items
that don't belong to a given category.
It also optionally exposes the `categoryId` on the provided popup menu, so it has
access to it inside menu item triggers.
Chat lists can belong to a category inside of communities, so they should
hold a property `categoryId` that represents that. In addition,
this commit introduces a `filterFn` function that can be used to conditionally
show/hide chat list items.
Closes#154
This commit introduces a `showActionButtons` flag that defaults to `false`
and can be used to render the action buttons provided in the chat list category.
This is useful for cases where only admin users should have the right to
create channels inside categories or mutate a category's state.
Settings `showActionButtons: true` will then render the buttons.
Closes#150
This turned out to be a bug. `model.count` isn't defined on `Repeater`
types.
Also, set `ScrollView` height to `0` if there are not community
tab buttons. This is needed because the columns implicit height
comes with spacing, resulting in some height.
This introduces a new `popupMenu` property that can be used to pass
down a `StatusPopupMenu` to `StatusChatToolBar`.
The reason this is done is so that we get control over its `onClosed`
handler, which is used to remove the menu button's `highlighted` state.
The `highlighted` state is activated inside the component as well when
it's clicked.
Existing signals like `menuButtonClicked` still exist and can be leveraged
for further logic.
Closes#125
B.Melnik
Pascal Precht
Sale Djenic
Alexandra Betouni
khushboo-dev-cpp
Alexandra Betouni
RichΛrd
Jonathan Rainville
Anthony Laibe
B.Melnik
