uwerat / qskinny

A lightweight framework on top of the Qt scene graph and only few classes from Qt/Quick. It is usable from C++ and/or QML.

QSkinny

The (Q)Skinny library is a framework built on top of the Qt scene graph and very few core classes from Qt/Quick. It offers a set of lightweight controls, that can be used from C++ and/or QML.

Doing the implementation in C++ allows to make use of the "scene graph" classes. Building controls from scene graph nodes allows for a lighter implementation than found with stacking "heavier" objects like QObject or QQuickItem. Offering a full featured C++ API allows the application code to benefit from following the same strategies.

Being "skinny" also means a design that separates concerns between the API and logic of the controls themselves, the styling of these controls, and the delegated rendering of the controls to the screen.

The code already provides a solid fundament for an automotive GUI with currently ~300K lines of pure C++ code. As expected it results in a good startup performance and a low memory footprint.

Nontheless QSkinny is lacking in areas like documentation. The QML API has not been completed after reaching a proof of concept state.

QSkinny is supposed to run on all platforms being supported by Qt/Quick. It might support other versions of Qt, but you can rely on:

• Qt 5.15
• current long term supported ( LTS ) version of Qt ( at the moment Qt 6.5.x )
• current version of Qt

How to build, install and use QSkinny is described in this tutorial.

If you want to know more about QSkinny - or even like to give it a specific direction - please contact [email protected].

Contributing to QSkinny

QSkinny is licensed under the BSD 3 Clause License ( https://opensource.org/license/bsd-3-clause ). However we want to be able to offer more licenses on request.

If you are fine with these terms, you are welcome to contribute to QSkinny by completing the following steps:

1. Agree to the terms of the Contributor Agreement. You can create a pull request first, then the licensing bot will check automatically whether you already signed the Agreement or not. If you have not signed it yet, it will take you to the Agreement to agree.
2. Submit your pull request for review.

qskinny's Issues

Blocking scene graph nodes outside the scene

A further optimization would be to block scene graph nodes, when the item is outside the scene geometry. Already created nodes could be deleted, once an items has left the scene.

An use case, where many items might be outside is QskScrollArea.

The challenge with this feature is that the geometry of an item is relative to its parent and the criterion for blocking depends on the geometry of all ancestors. Running recursively over all children on geometry changes seems to be too expensive.

Seperating layouts from the corresponding layout boxes

All layouts are implemented as QskControls, but often it would be enough to have the layout algorithms available without wasting extra resources for creating a QQuickItem.

Nevertheless QskBoxLayout/QskGridLayout/QskStackLayout remain useful and should not go away ( when being born before Qt4 you might remember QHBox/QVBox/QGridBox ).

Hiding QskStackBoxAnimator

QskStackBoxAnimator ( and derived classes ) can be hidden inside of QskStackBox.cpp. When using a cleanup handler, there should be no reason for being QObjects any longer.

Depending sizeHints

The default size of a SVG provides an aspect ratio, but is usually not very helpful for calculating a good sizeHint. Instead its width or height is often related to the preferred height/width of another control.

Layouts can solve many situations, but f.e when the height of a graphic label depends on the font height of a text label ad both are not horizontally aligned we are lost.

So we need to find an easy to use API for how to make the calculation of the preferred size of one control being dependent from the preferred size of another.

Shadow effects for box nodes

Reintroducing shadow effects for box nodes.

"overdraw" debug mode for QQuickItems

Having a similar debug mode for QQuickItems like what you get with setting the "overdraw" mode for scene graph nodes would be very helpful

QskSlider improvement

QskSlider misses several features compared to QSlider its counterpart in QQuick Controls 2:

• optional ticks
• tracking
• invertedAppearance
• invertedControls
• ...

Scrollable QskTabBar

QskTabBar needs to be scrollable

Completing gesture recognition

Only QskPanGestureRecognizer is implemented so far.

Extending the default skins for hovering

The default skins don't visualize the hovered state.

Layouts should rearrange the tab focus chain

QskGridBox/QskLinearBox should rearrange the focus tab chain like being known from QWidget layouts.

Unstable graphics during animations

In situations, where the size of a graphic is interpolated during an animation the position is often visually unstable.

This effect might be related to rounding issues and the fact, that the geometry is calculated starting from the top/left corner instead of the center.

visualFocus

QQuickControl (QC2) has the concept of only showing the focus indicator, when the focusReason was related to key events. Makes sense as the user doesn't want to see the indicator, when mostly using the touch.

In a QSkinny application I have implemented a different concept, that shows the focus indicator only temporarily. When being hidden, the first tab press results in fading in the indicator without changing the focus. After not pressing tab for some time, the focus indicator fades out automatically.

Replacing the Texture based QskBoxNode by something based on vertex lists

The texture based idea behind QskBoxMaterial/QskBorderGeometry was worth a try but finally ran into too many problems. So we are giving up and return to an implementation using vertex lists like being done in QskRectNode/QskFrameNode.

QskVertexRenderer needs to be extended to support corners with different x/y radii.

Preprocessing the dirty item list

Qt/Quick puts a transform and a couple of optional nodes ( clip/opacity .. ) on top of the paint node, that can be manipulated by QQuickItem::updatePaintNode(). This is an quite unfortunate design, when manipulation of those heading nodes is required.

F.e the implementation in QQuickWindowPrivate::updateDirtyNode limits the clip node to the bounding rectangle of the item, what is not what we need, when trying to put an item on a QskScrollArea ( currently solved by inserting an invisible item between scrollarea and its child with a manipulated clip node ). Also it would be nice to be able to manipulate those parameters using the Qskinny animatior system, so that transitions for opacity/geometry/size/clips etc. of the controls can be defined/customized in the same way as it can be done for their sub controls,

Thus it makes sense to investigate in playing with preprocessing the dirty item list and doing the updates by forwarding the node updates to virtual methods of the items - like updatePaintNode, but for all nodes.

QskScrollArea + resizing the scrolled item

The well known chicken/egg problem for resizing the scrollable item in combination with having both scrollbars in Qt::ScrollBarAsNeeded mode is not yet implemented.

QskListView is numerically unstable

When having millions of rows calculation the y coordinates becomes numerically unstable ( can be seen in the listbox example, when increasing the number of rows ),

Material design or other "pretty" example

Hi, stumbled on your library from a comment on a blog post.
The intent is very good (in my opinion, such a library is necessary!), however I think that the examples's graphical style really don't do justice to the potential of this library (the gradients! gosh) which would in turn lead to less users, thus less eyes on the code and bugs found.

Why not taking the visual style of, for instance, Qt Quick Controls {1,2}'s style ?
Or one of the UI guidelines given here ? https://github.com/ioncodes/awesome-ui
Taking inspiration from Kirigami UI ? https://dot.kde.org/sites/dot.kde.org/files/Desktop.png
There is also a QtQuick Controls 2 style that allows taking the colors of the system theme: https://cgit.kde.org/scratch/mart/desktopqqc2style.git/
couldn't something similar be leveraged to give the apps a style that at least fits a desktop ?

Thanks for the work in all cases, I hope that something like this will be merged into qt eventually

Finding a declarative API for using layouts from QML

The approach taken by Qt/Quick attaches layout attributes to the items organized by the layout. I never liked this implementation as the layout settings are often scattered across many lines and the readability of the layout code is lost.

Finding an implementation, where the layout can be defined after the declaration of the children is preferable.

Screenshot

Can you please add screenshot to README?
I think this one is quite nice
https://pbs.twimg.com/media/DFguVReXkAAOQqc.jpg

Sharing geometries of box nodes

Often an application has identical geometries for different box nodes - f.e the panel of buttons.
It might be useful to have a cache for those geometries, so that they can be shared.

QskScrollArea: more accurate filtering of input events

When having a viewport with rounded corners input events have to be filtered out on positions being outside the corners. This can be done by overloading QQuickItem::contains().

To support the implementation it might be helpful to have something like:

virtual bool QskSkinlet::subcontrolContains( ...., const QPointF& ) const;

Loading skins as plugins

Skins should extracted to plugins loaded by QPluginLoader.

Don't use QQuickItem::boundingRect()

Because QQuickItem::rect() does not exist QQuickItem::boundingRect() is often used. But as boundingRect() is a virtual method these rectangles are not necessarily the same - even if the default implementation falls back on the geometry.

In fact the exact meaning of QQuickItem::boundingRect() is not documented. But when looking at the code of Qt/Quick classes, where it is overloaded, it seems to return some sort of inner rectangle, that indicates the geometry of the "real" content - without paddings/alignments.

QskSkinTransition and fallback aspects

When interpolating QskSkinTransition needs to identify all controls, that are affected from a hint to call polish/update. At the moment all hints, that get resolved by falling back on the QskControl::Control subcontrol are not covered.

Improving text node updates

There is no need to rebuild the glyph nodes in situations, where only the text colors have been changed.

This is already supported by QskPlainTextRenderer::updateNodeColor, but had been disabled in QskSkinRenderer::updateText. The reason for this was related to running into wrong update decisions in early stages of the project. In the meantime it might be obsolete as the concept for having very detailed dirty masks had been dropped.

Remove states from QskAbstractButton

Remove Flat, Checked and Checkable states from QskAbstractButton.

Flat and Checkable are flags, but no states and does only make sense for certain type of buttons like QskPushButton. Buttons like QskTabButton or f.e check-boxes/radiobuttons are always checkable and having these states make the definition of the skin hints totally confusing.

This comes with having to remove certain methods from the C++ API you find in QAbstractButton. But in the end the class design of QAbstractButton is wrong in the same sense as it allows pointless operations like making a QCheckBox uncheckable.

Reimplementing QskStackBox

The current implementation of QskStackBox is done by putting all its children into the same cell of a QGridLayoutEngine. As implementing a stacked layout is more or less trivial it doesn't make much sense to continue with this approach.

Finding an API for redirecting subcontrols without having to overload

Redirecting subcontrols is a very often used technique to be able to have individual sets of hints. But the offered API requires overloading of effectiveSubcontrol, what is inconvenient, when all you want to do is to assign pairs of subcontrols.

It would be best to have something like

- control->setSubcontrolSubstitution( subControl, subControlOther );

but, without having to duplicate this pair for each instance of the class, where this mapping has to be done.

QskAccordion

Implementing a container organizing its children as accordion: https://en.wikipedia.org/wiki/Accordion_(GUI)

Animators for interpolating fonts

Interpolating between fonts has not been implemented for skin hint animators

QskShortcut and function pointer based connection

QskShortcut supports the traditional string based signal/slot connections only. We also want to support function pointer base connections.

Interpolation between color filters

Interpolation between color filters for QskGraphic for skin changes could be done even if one of the skins does not have a filter for a specific graphic role. Identity should be used then.

Focus handling of subcontrols

Subcontrols need to be focusable, navigating along the focus tab chain needs to be extended for them. F.e the scrollbars of a QskScrollView are not known to the focus handling of the Qt/Quick framework.

Platform Settings

We should have a class for global settings, that are not covered by Qt/QPA.

F.e. what should be the minimal distance for accepting a pan gesture, or when to abort a pending gesture detection to let the children handle the events.

QskGestureRecognizer needs to replay all mouse events

When QskGestureRecognizer discards the detection of a gesture it needs to repost all mouse events recorded so far. The current implementation only reposts press/release, while all move events get lost.

Background Panel for labels

QskGraphicLabel/QskTextLabel should implement having an optional background panel ( frame + color ).

wheel events

the direction of wheel events needs to be handled - not only as an undirected delta.

Using QQuickTextNode

Since Qt 5.7 QQuickTextNode is exported ( Q_QUICK_PRIVATE_EXPORT ) and could be used in QskTextRenderer.

Adding "window manager" features for QskSubWindowArea

The implementation of QskSubWindowArea is quite incomplete.

Hard to say how far we want to extend its functionality - maybe the scope implemented in QMdiArea is a good starting point.

QskSubWindow improvements

Implementation of QskSubWindow decorations ( Close/Maximize/Minmize... buttons ) is missing.

Introducing orientation for buttons

Not all sort of buttons are supposed to align graphic and text vertically. F.e. dialog buttons often have an icon left of the text.

QskVariantAnimation interpolator

The registration of interpolators for QskVariantAnimator should be decoupled from the one used for QVariantAnimation

Not creating new texture nodes for simple translations

There is no reason for recreating textures, when only its position has changed

QskSwipeView

QskSwipeView should be a very low hanging fruit, when combining QskStackBox with QskPanGestureRecognizer.

Sorting itemsToPolish in top down order

QQuickWindow calls QQuickItem::updatePolish in order of when QQuickItem::polish has been called ( = more or less random ). As one of the main ideas behind polishing is to calculate layouts, calling updatePolish in top down order is way more efficient.

To be able to reorder the QQuickWindowPrivate::itemsToPolish vector in O(n log n) QskControl needs to maintain its depth inside the QuickItem tree. Something that needs to be done on QQuickItem::ItemParentHasChanged - similar to what is already done for the locale.

Fading out of QskSubWindow

We need to find a way how to fade out QskSubWindow.

Classes derived from QskSubWindow are often dialogs and candidates for being created on the stack being processed in a recursive event loop. To solve this type of use case we might need to have some sort of "post mortem" handler grabbing the contents into an image or simply hijacking the scenegraph node subtree.

An obvious solution would be to let some sort of QskPopupManager let do the job.

QskTextColors as skin hint

Instead of having 3 different hints we could use QskTextColors as one hint for all 3 colors.

Completing gradient support

The current implementation does not yet support all sorts of gradients.

Using non atomic skin hints

In the initial design skin hint were 32bit values usable for very atomic properties like metrics/colors/flags. This leads to many lookups and unclear resolving paths.. F.e defining the border of a box is currently made from 12 metrics ( 4 * radiusX/radiusY + 4 * width ).

The 32bit values have already been replaced by QVariants, but we still need to create new sorts of hints like f.e. QskBoxColors/QskBorderMetrics.