Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kirigami and Qt Quick Controls 2 compatibility #1

Open
rinigus opened this issue Jun 12, 2020 · 2 comments
Open

Kirigami and Qt Quick Controls 2 compatibility #1

rinigus opened this issue Jun 12, 2020 · 2 comments

Comments

@rinigus
Copy link

rinigus commented Jun 12, 2020

As Nemo is moving to Qt 5.12 and beyond, it makes sense to ensure compatibility with Kirigami (KDE Tier 1 Framework / aka framework without external dependencies) and Qt Quick Controls 2. Much of Nemo UX can be implemented using QQC2 and Kirigami instead of developing and maintaining separate set of controls. Would have to go through each one-by-one at some point, but for now, would like to mainly know general opinion regarding it.

Approach for styling QQC2 and Kirigami is similar. We would have to write the style and install it accordingly. As an example, assuming that the theme for Qt is configured correctly, header styling can be achieved by adding

style/Nemo/ApplicationWindow.qml:

import QtQuick 2.1
import org.kde.kirigami 2.4 as Kirigami
import "../../" as Base
Base.ApplicationWindow {
    id: root
    pageStack.globalToolBar.style: Kirigami.ApplicationHeaderStyle.ToolBar
    pageStack.globalToolBar.showNavigationButtons: pageStack.currentIndex > 0 ?
                                                       Kirigami.ApplicationHeaderStyle.ShowBackButton :
                                                       Kirigami.ApplicationHeaderStyle.NoNavigationButtons
}

and having AbstractApplicationHeader.qml styled with the DropShadow leading to

screenshot

In this example (kirigami-gallery), we have already consistent with Nemo header guidelines:

  • back arrow only shown for nested pages (the shown page is nested)
  • application toolbar is shown as actions. In Kirigami, actions are defined for each page separately and could be hierarchical (action inside action/leading to nested menu or some action element).

Right now, header cannot be styled itself. However, it should be possible to add separate header type if we need it in Kirigami sources. That would allow pull-down gesture and complex toolbars implemented via Action.

As for landscape mode header, not sure how to implement that at this stage and that maybe a limitation. Same goes for corner cases such as headers with too many children. Which is probably not that important anyway.

Kirigami has two types of drawers (global, accessible in this form of toolbar as on the screenshot from the left top, ☰ symbol) and context (not shown, but can be made available by apps, usually on the right). How to avoid them is not clear to me yet except not using this in Nemo apps. These drawers are harder to reach on gesture-based navigation system (window gets minimized instead of drawer pulled). If it is possible to restyle them into corresponding pages, I don't know.

I'll better stop here for now and ask for general opinion on the subject.

@rinigus
Copy link
Author

rinigus commented Jun 13, 2020

We can base the style on Plasma Framework which includes styles for QQC2 and Kirigami. In turn, Plasma Framework is styled using Plasma themes (tutorial, details, and example themes). The latter allow to style widgets, colors by making SVGs.

As a result, much of the styling can be done using SVGs directly. If something will be missing, Plasma Framework can be forked, code changed and it distributed with some other name.

If needed, QQC2 maybe styled as described in https://doc.qt.io/qt-5/qtquickcontrols2-customize.html

Edit: added link to theme details

@rinigus
Copy link
Author

rinigus commented Jun 19, 2020

Here, I am going through controls as in https://github.com/qwazix/glacier-controls-spec and summarize what was found regarding each of them.

  • button: depending on the design, can be styled either by colors or svg's. Don't know how to make touch location glow, may require

  • buttonRow: haven't seen something similar in Kirigami nor QQC2. Would require custom control

  • dialogs:

    • inline dialog: haven't seen as proposed; would require custom control
    • Normal dialog unobstrusive and query dialog: can be implemented on application level as overlay sheet, modal or inline drawers (Kirigami)
  • header: can use Kirigami header. there are several styles covering main application header, tabbed view header. actions are supported but drawn differently. as header can be reimplemented using AbstractApplicationHeader.qml of Kirigami, it should be possible to make it slide out.

  • listview: functionality is covered by Kirigami SwipeListItem. Item actions are uncovered, but from the right by default in Kirigami. As in Sailfish, its responsibility of the app to organize widgets inside and they are not forced as in Nemo proposal.

  • progress spinner: corresponds to styling QQC2 BusyIndicator

  • scroll indicators

    • advanced: not sure how to link it to the list, may require custom control
    • basic and minimal: should be possible to style via Plasma theme. maybe limited to variant of minimal and basic hybrid
  • Select roller: Maybe QQC2 ComboBox can be styled like that.

  • Slider: can be partially customized via Plasma theme. If insufficient, would require QQC2 styling

  • Switch: should be possible to customize via Plasma theme

  • Stack interaction: as in Sailfish, pages can be swiped off in Kirigami. This is missing now in the current Nemo controls implementation and, as far as I have seen in the case of Kirigami, not trivial to make.

  • textInputs: mostly via color customization. To add copy control, would require QQC2 styling

  • timepicker: custom control, maybe can be synced in terms of API with similar picker from Kirigami Addons

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant