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:
Peter Hartmann 2024-10-01 10:13:11 +02:00 committed by uwerat
parent 5309c2656e
commit 920f7e24d6
10 changed files with 45 additions and 45 deletions

View File

@ -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]

View File

@ -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.

View File

@ -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 dont
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 wont 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

View File

@ -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]

View File

@ -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 QskGraphics

View File

@ -41,7 +41,7 @@ Lets 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]

View File

@ -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].

View File

@ -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]

View File

@ -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

View File

@ -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]