tutorials: Display images on github files
... by making the references absolute. Now they should work both on github and on the homepage. Resolves #414
This commit is contained in:
parent
5309c2656e
commit
920f7e24d6
|
@ -18,4 +18,4 @@ the whole codebase is written in {cpp}. An overview of how QSkinny fits
|
|||
into the Qt architecture is depicted below:
|
||||
|
||||
.QSkinny sits on top of QtQuick, while QML is optional
|
||||
image::../images/architecture-simple.png[QSkinny architecture]
|
||||
image::/doc/tutorials/images/architecture-simple.png[QSkinny architecture]
|
||||
|
|
|
@ -157,7 +157,7 @@ int main( int argc, char* argv[] )
|
|||
|
||||
Now the app is displaying the two buttons:
|
||||
|
||||
image::../images/writing-first-application.png[An app showing two buttons]
|
||||
image::/doc/tutorials/images/writing-first-application.png[An app showing two buttons]
|
||||
|
||||
That's it; you just created a QSkinny application from scratch.
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ text width (which itself depends on the font) and possibly padding and
|
|||
margins:
|
||||
|
||||
.implicit horizontal size hint of a button
|
||||
image::../images/size-hints-calculation.png[implicit horizontal size hint of a button]
|
||||
image::/doc/tutorials/images/size-hints-calculation.png[implicit horizontal size hint of a button]
|
||||
|
||||
The implicit width of a composited UI element containing a
|
||||
graphic on the left and a text on the right would be the sum of the elements’
|
||||
|
@ -75,7 +75,7 @@ label1->setBackgroundColor( Qt::magenta );
|
|||
....
|
||||
|
||||
.control without explicit size hint
|
||||
image::../images/size-hints-1.png[Image without explicit size hint]
|
||||
image::/doc/tutorials/images/size-hints-1.png[Image without explicit size hint]
|
||||
|
||||
If we set an explicit size hint of 150x60 pixels ourselves for the
|
||||
preferred size, the control will be rendered differently:
|
||||
|
@ -85,7 +85,7 @@ label1->setExplicitSizeHint( Qt::PreferredSize, { 150, 60 } );
|
|||
....
|
||||
|
||||
.control with explicit size hint
|
||||
image::../images/size-hints-2.png[Image with explicit size hint]
|
||||
image::/doc/tutorials/images/size-hints-2.png[Image with explicit size hint]
|
||||
|
||||
When dealing with standard controls or layouts, the size hints don’t
|
||||
need to be specified explicitly, as it can be deduced from its standard
|
||||
|
@ -185,14 +185,14 @@ By default the width of the buttons is determined by its text plus its
|
|||
margins:
|
||||
|
||||
.Size policies with preferred size
|
||||
image::../images/size-policies-horizontal-minimum-1.png[Fixed vs. Minimum size policy]
|
||||
image::/doc/tutorials/images/size-policies-horizontal-minimum-1.png[Fixed vs. Minimum size policy]
|
||||
|
||||
After growing the window horizontally, the button with the Fixed
|
||||
horizontal size policy keeps its width, while the button with the
|
||||
Minimum policy will grow:
|
||||
|
||||
.Size policies when increasing window width
|
||||
image::../images/size-policies-horizontal-minimum-2.png[Fixed vs. Minimum size policy]
|
||||
image::/doc/tutorials/images/size-policies-horizontal-minimum-2.png[Fixed vs. Minimum size policy]
|
||||
|
||||
When shrinking the window below its original size, both buttons stay
|
||||
with their width: The one on the left because of its `Fixed` size policy,
|
||||
|
@ -200,7 +200,7 @@ and the one on the right because it won’t shrink below its original size
|
|||
due to the `Minimum` size policy.
|
||||
|
||||
.Size policies when shrinking window width
|
||||
image::../images/size-policies-horizontal-minimum-3.png[Fixed vs. Minimum size policy]
|
||||
image::/doc/tutorials/images/size-policies-horizontal-minimum-3.png[Fixed vs. Minimum size policy]
|
||||
|
||||
If we change the policy of the right button to `Preferred`, it will shrink
|
||||
below its original size (even though the text is too wide now):
|
||||
|
@ -211,7 +211,7 @@ label2->setText( "size policy: preferred" );
|
|||
....
|
||||
|
||||
.Size policies when changing to preferred size policy
|
||||
image::../images/size-policies-horizontal-minimum-4.png[Fixed vs. Minimum size policy]
|
||||
image::/doc/tutorials/images/size-policies-horizontal-minimum-4.png[Fixed vs. Minimum size policy]
|
||||
|
||||
=== Types of layouts
|
||||
|
||||
|
@ -240,7 +240,7 @@ horizontalBox->addItem( label3 );
|
|||
....
|
||||
|
||||
.Horizontal layout
|
||||
image::../images/layout-horizontal.png[Horizontal layout]
|
||||
image::/doc/tutorials/images/layout-horizontal.png[Horizontal layout]
|
||||
|
||||
[source]
|
||||
....
|
||||
|
@ -258,7 +258,7 @@ verticalBox->addItem( label3 );
|
|||
....
|
||||
|
||||
.Vertical layout
|
||||
image::../images/layout-vertical.png[Vertical layout]
|
||||
image::/doc/tutorials/images/layout-vertical.png[Vertical layout]
|
||||
|
||||
==== Grid layouts (QskGridBox)
|
||||
|
||||
|
@ -292,7 +292,7 @@ gridBox->addItem( label7, 2, 1, 1, 2 );
|
|||
....
|
||||
|
||||
.Grid layout
|
||||
image::../images/layout-grid.png[Grid layout]
|
||||
image::/doc/tutorials/images/layout-grid.png[Grid layout]
|
||||
|
||||
==== Stack layouts (QskStackBox)
|
||||
|
||||
|
@ -321,7 +321,7 @@ stackBox->setCurrentIndex( 2 );
|
|||
....
|
||||
|
||||
.Stack layout (symbolized)
|
||||
image::../images/layout-stack.png[Stack layout]
|
||||
image::/doc/tutorials/images/layout-stack.png[Stack layout]
|
||||
|
||||
In this example, "control 3" is stacked on top of the blue and the
|
||||
cyan control. Controls in a stacked layout can be of different sizes.
|
||||
|
@ -366,19 +366,19 @@ When the layout has all the space it needs (but not more), both elements
|
|||
are rendered with their preferred size:
|
||||
|
||||
.Stretch factors with preferred size
|
||||
image::../images/stretch-factors-1.png[Stretch factors preferred size]
|
||||
image::/doc/tutorials/images/stretch-factors-1.png[Stretch factors preferred size]
|
||||
|
||||
When the layout gets more width, the stretch factors come into play:
|
||||
|
||||
.A stretch factor of 1:2
|
||||
image::../images/stretch-factors-2.png[Stretch factors increasing width]
|
||||
image::/doc/tutorials/images/stretch-factors-2.png[Stretch factors increasing width]
|
||||
|
||||
No matter how wide the layout is, the aspect ratio of 1:2 will always be
|
||||
kept, meaning that the label on the left will get 33% of the space, and
|
||||
the label on the right 67%:
|
||||
|
||||
.A stretch factor of 1:2 with different widths
|
||||
image::../images/stretch-factors-3.png[Stretch factors even more width]
|
||||
image::/doc/tutorials/images/stretch-factors-3.png[Stretch factors even more width]
|
||||
|
||||
Stretch factors in QSkinny are the same as in the Qt Graphics View
|
||||
Framework, see
|
||||
|
@ -392,7 +392,7 @@ each other. The example below depicts a UI with a top bar and menu items
|
|||
on the left:
|
||||
|
||||
.A UI with nested layouts
|
||||
image::../images/nesting-layouts.png[Nested layouts]
|
||||
image::/doc/tutorials/images/nesting-layouts.png[Nested layouts]
|
||||
|
||||
The code to produce the above UI could look like this (setting colors
|
||||
etc. omitted for brevity):
|
||||
|
@ -428,7 +428,7 @@ with the menu buttons is again a vertical layout.
|
|||
The following diagram makes the layouts visible:
|
||||
|
||||
.The layout structure of the UI
|
||||
image::../images/nesting-layouts-architecture.png[Nested layouts architecture]
|
||||
image::/doc/tutorials/images/nesting-layouts-architecture.png[Nested layouts architecture]
|
||||
|
||||
=== Anchoring in QSkinny
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ skinlet, and therefore it will read information from both the control
|
|||
itself as well as read the skin hints from the skin:
|
||||
|
||||
.Skinlets query the control and the skin
|
||||
image::../images/skins-1.png[Styling controls]
|
||||
image::/doc/tutorials/images/skins-1.png[Styling controls]
|
||||
|
||||
For instance, a button skinlet will read the margins from the skin and
|
||||
the text to render from the button.
|
||||
|
@ -44,10 +44,10 @@ has a traditional desktop skin, the other is a flat button with a skin
|
|||
often found in mobile devices.
|
||||
|
||||
.desktop style button
|
||||
image::../images/skinlets-button-1.png[desktop style button]
|
||||
image::/doc/tutorials/images/skinlets-button-1.png[desktop style button]
|
||||
|
||||
.flat button
|
||||
image::../images/skinlets-button-2.png[flat button]
|
||||
image::/doc/tutorials/images/skinlets-button-2.png[flat button]
|
||||
|
||||
=== Skin hints
|
||||
|
||||
|
@ -85,7 +85,7 @@ public:
|
|||
....
|
||||
|
||||
.A button styled with skin hints
|
||||
image::../images/skin-hints.png[Button with skin hints]
|
||||
image::/doc/tutorials/images/skin-hints.png[Button with skin hints]
|
||||
|
||||
When writing a new skin, a developer needs to know which hints to set
|
||||
for which control. This usually depends on the control itself; however,
|
||||
|
@ -154,10 +154,10 @@ public:
|
|||
....
|
||||
|
||||
.button in normal state
|
||||
image::../images/skin-hints-states-1.png[button in normal state]
|
||||
image::/doc/tutorials/images/skin-hints-states-1.png[button in normal state]
|
||||
|
||||
.button in hovered state
|
||||
image::../images/skin-hints-states-2.png[button in hovered state]
|
||||
image::/doc/tutorials/images/skin-hints-states-2.png[button in hovered state]
|
||||
|
||||
==== Local skin hints
|
||||
|
||||
|
@ -181,7 +181,7 @@ Taking animations and local skin hints into account, the architecture
|
|||
diagram now looks like this:
|
||||
|
||||
.Skinlets can also read from local skinlets and animators
|
||||
image::../images/skins-2.png[Animators and local skin hints]
|
||||
image::/doc/tutorials/images/skins-2.png[Animators and local skin hints]
|
||||
|
||||
=== Skinlets
|
||||
|
||||
|
@ -214,7 +214,7 @@ different skinlets, so a more complete version of the architecture
|
|||
diagram looks like this:
|
||||
|
||||
.There is one skinlet for each atomic control
|
||||
image::../images/skins-3.png[Animators and local skin hints]
|
||||
image::/doc/tutorials/images/skins-3.png[Animators and local skin hints]
|
||||
|
||||
=== Skin factories and switching between skins
|
||||
|
||||
|
@ -298,8 +298,8 @@ Switching between skins will change the look of `QskPushButton`
|
|||
instances:
|
||||
|
||||
.button in `MySkin` (as above)
|
||||
image::../images/skin-hints-states-1.png[button in normal state]
|
||||
image::/doc/tutorials/images/skin-hints-states-1.png[button in normal state]
|
||||
|
||||
.button in `OtherSkin`
|
||||
image::../images/skin-factory.png[Styling controls]
|
||||
image::/doc/tutorials/images/skin-factory.png[Styling controls]
|
||||
|
||||
|
|
|
@ -33,16 +33,16 @@ label2->setSizePolicy( QskSizePolicy::ConstrainedPreferred, QskSizePolicy::Expan
|
|||
....
|
||||
|
||||
.graphics with preferred size
|
||||
image::../images/scalable-graphics-1.png[Scalable graphics default]
|
||||
image::/doc/tutorials/images/scalable-graphics-1.png[Scalable graphics default]
|
||||
|
||||
When resizing the window, the graphics will scale according to the size
|
||||
available in the layout:
|
||||
|
||||
.graphics bounded by width
|
||||
image::../images/scalable-graphics-2.png[Scalable graphics bounded by width]
|
||||
image::/doc/tutorials/images/scalable-graphics-2.png[Scalable graphics bounded by width]
|
||||
|
||||
.graphics bounded by height
|
||||
image::../images/scalable-graphics-3.png[Scalable graphics bounded by height]
|
||||
image::/doc/tutorials/images/scalable-graphics-3.png[Scalable graphics bounded by height]
|
||||
|
||||
Since we set the horizontal size policy of the graphics to
|
||||
`ConstrainedPreferred`, the scaling is done through QskGraphic’s
|
||||
|
|
|
@ -41,7 +41,7 @@ Let’s look at the "Nesting layouts" example from the
|
|||
link:Layouts.html[layouts documentation]. The UI looks like this:
|
||||
|
||||
.UI with nested layouts
|
||||
image::../images/nesting-layouts.png[Nested layouts]
|
||||
image::/doc/tutorials/images/nesting-layouts.png[Nested layouts]
|
||||
|
||||
The code for this UI is below:
|
||||
|
||||
|
@ -92,7 +92,7 @@ on. For information on how to obtain this tree, see
|
|||
https://doc.qt.io/qt-5/qobject.html#dumpObjectTree[QObject::dumpObjectTree()].
|
||||
|
||||
.QObject tree (and item tree) of the nested layouts UI
|
||||
image::../images/object-hierarchy.png[QObject hierarchy]
|
||||
image::/doc/tutorials/images/object-hierarchy.png[QObject hierarchy]
|
||||
|
||||
==== Item tree
|
||||
|
||||
|
@ -136,7 +136,7 @@ topBar->setOpacity( 0.2 );
|
|||
....
|
||||
|
||||
.Changing opacity of an item will affect all its child items
|
||||
image::../images/nesting-layouts-item-tree-1.png[Changing the item tree]
|
||||
image::/doc/tutorials/images/nesting-layouts-item-tree-1.png[Changing the item tree]
|
||||
|
||||
==== Difference in object trees and item trees
|
||||
|
||||
|
@ -151,7 +151,7 @@ topLabel1->setParentItem( bottomBar );
|
|||
....
|
||||
|
||||
.Moving a label from the top bar to the bottom bar
|
||||
image::../images/nesting-layouts-item-tree-2.png[Moving a label to the bottom bar]
|
||||
image::/doc/tutorials/images/nesting-layouts-item-tree-2.png[Moving a label to the bottom bar]
|
||||
|
||||
Now we decide to get rid of our top bar altogether:
|
||||
|
||||
|
@ -163,7 +163,7 @@ topBar->deleteLater();
|
|||
This will also delete our label from the bottom bar:
|
||||
|
||||
.Deleting the top bar will delete all its children
|
||||
image::../images/nesting-layouts-item-tree-3.png[Deleting the top bar]
|
||||
image::/doc/tutorials/images/nesting-layouts-item-tree-3.png[Deleting the top bar]
|
||||
|
||||
The reason why the label from the bottom bar was also deleted is that
|
||||
with the call to `setParentItem()` above we set a new parent item; the
|
||||
|
@ -188,4 +188,4 @@ topBar->deleteLater();
|
|||
....
|
||||
|
||||
.Reparenting the label will keep it alive when deleting the top bar
|
||||
image::../images/nesting-layouts-item-tree-4.png[Reparenting the item]
|
||||
image::/doc/tutorials/images/nesting-layouts-item-tree-4.png[Reparenting the item]
|
||||
|
|
|
@ -56,7 +56,7 @@ Qsk.LinearBox
|
|||
The full Buttons example is depicted below.
|
||||
|
||||
.The buttons example shows how to mix QSkinny and QML
|
||||
image::../images/buttons-example.png[Buttons example]
|
||||
image::/doc/tutorials/images/buttons-example.png[Buttons example]
|
||||
|
||||
For more information on using C++ classes from QML, see the article about exposing attributes of {cpp} types to QML in the
|
||||
https://doc.qt.io/qt-5/qtqml-cppintegration-exposecppattributes.html[Qt documentation].
|
||||
|
|
|
@ -36,7 +36,7 @@ public:
|
|||
....
|
||||
|
||||
.A subclassed control with local skin hints
|
||||
image::../images/subclassing-existing-controls.png[Subclassing existing controls]
|
||||
image::/doc/tutorials/images/subclassing-existing-controls.png[Subclassing existing controls]
|
||||
|
||||
Then there is no need to set the margins and background color for every
|
||||
instance of the custom text label.
|
||||
|
@ -94,7 +94,7 @@ public:
|
|||
....
|
||||
|
||||
.A subclassed control with skin hints defined in the skin
|
||||
image::../images/subclassing-existing-controls.png[Subclassing existing controls]
|
||||
image::/doc/tutorials/images/subclassing-existing-controls.png[Subclassing existing controls]
|
||||
|
||||
The styling described above has the same effect as in the simpler
|
||||
example, but now the `TextLabel` control can be given a different style
|
||||
|
@ -150,7 +150,7 @@ auto* textAndGraphic = new TextAndGraphic( "Text", "cloud" );
|
|||
....
|
||||
|
||||
.A composited control
|
||||
image::../images/compositing-controls.png[Compositing controls]
|
||||
image::/doc/tutorials/images/compositing-controls.png[Compositing controls]
|
||||
|
||||
=== Writing controls with a skinlet
|
||||
|
||||
|
@ -311,4 +311,4 @@ changes properly. A simpler version with hardcoded values for margins,
|
|||
colors etc. can be written with less code.
|
||||
|
||||
.A class with an own skinlet
|
||||
image::../images/control-with-skinlet.png[Control with skinlet]
|
||||
image::/doc/tutorials/images/control-with-skinlet.png[Control with skinlet]
|
||||
|
|
|
@ -27,7 +27,7 @@ window.show();
|
|||
For this example, the scene graph will contain the following nodes:
|
||||
|
||||
.Scene graph representation of a button
|
||||
image::../images/skins-sg-1.png[Scene graph nodes for a button]
|
||||
image::/doc/tutorials/images/skins-sg-1.png[Scene graph nodes for a button]
|
||||
|
||||
The top two nodes (root and Quick root item) are created for every
|
||||
QtQuick application. The button itself consists of 5 nodes in our case:
|
||||
|
@ -60,7 +60,7 @@ window.show();
|
|||
Then the scene graph has the following structure:
|
||||
|
||||
.Scene graph representation of a button inside a box
|
||||
image::../images/skins-sg-2.png[Scene graph nodes for a button in a box]
|
||||
image::/doc/tutorials/images/skins-sg-2.png[Scene graph nodes for a button in a box]
|
||||
|
||||
Here we can see that since the box is a parent of the button, the `box
|
||||
node` is also a parent of the `button node` in the scene graph. Also, the
|
||||
|
|
|
@ -48,4 +48,4 @@ Qt creates the HTML wrappers automatically, so there is not much to do except le
|
|||
....
|
||||
|
||||
.The IOT dashboard example in a browser
|
||||
image::../images/iotdashboard-wasm.png[The IOT dashboard example in a browser]
|
||||
image::/doc/tutorials/images/iotdashboard-wasm.png[The IOT dashboard example in a browser]
|
||||
|
|
Loading…
Reference in New Issue