[Interest] Freetype and color fonts
Hi all, I've been trying to use Google color emoji font https://www.google.com/get/noto/#emoji-qaae-color with no luck. When I try to load the font using FontLoader I obtain an error: QML FontLoader: Cannot load font: "file:///E:/Qt/FontTest/NotoColorEmoji.ttf" but the font is in place, I can successfully load other fonts in the same folder. According to http://www.freetype.org/ , Freetype is supposed to support Google color fonts since version 2.5 (3 years ago). What am I missing? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Astropad and Tablet events
> On 22 Mar 2016, at 02:30, Alexei Gilchrist wrote: > > Hi all, > > I'm trying to use Astropad (app provides OsX tablet interface with an iPad) > with an app I’ve written and I'm getting odd results with tablet events in > QT. First of all, I've been in contact with the devs and they seem to think > it's a QT bug rather than an Astropad bug, and in any case Astropad works > with other graphics programs that I've tried. Why do they think it’s a Qt bug? Maybe they should tell us what we are doing wrong if they know. I guess there must be a Mac daemon which tries to emulate a Wacom by sending the same events? It’s not only for Qt applications, right? But Qt applications work with a real Wacom but not Astropad, so they must not be emulating the events exactly the same. You can enable the logging category qt.qpa.input.tablet to see how the events come in (the code is in qnsview.mm). > I'm coding in python using pyqt and have Python 3.5.0 and QT 5.5.0 installed. > > At the level of QWidget you get an initial TabletPress event with pressure=0 > followed immediately by a TabletRelease event with pressure>0 at which point > the rest of the stroke is only reported as mouse events, with are low > frequency and don’t contain pressure info. > > Astropad: > > TabletPress: pointer=1 pressure=0.0 tilt=(27,12) > TabletRelease: pointer=1 pressure=0.1334028720856 tilt=(27,12) > MousePress > MouseMove > MouseMove > ...[ many MouseMove ]... > MouseRelease > > Works as you'd expect with Wacom tablet, though accepting the tablet events > does't stop the mouse events being fired (minor niggle): That’s https://bugreports.qt.io/browse/QTBUG-47007 It’s probably always been that way, at least in Qt 5, because the platform plugins are doing this mouse emulation when necessary. (In some cases the window system will send a synthesized mouse event itself, in which case we don’t need to.) Plugins don’t pay attention to whether the tablet event was accepted or not, because sending events from the platform plugin into the application is asynchronous, going through a queue. We assume the tablet event is rejected because that’s the default policy (outside of QtQuick where we assume an event is accepted), so the default is that the application does nothing, and then it gets a mouse event (so that you can use the stylus to interact with widgets etc.) AFAIK there isn’t a nice mechanism to wait and see whether the app accepted the tablet event or not; we’d have to wait until the asynchronous delivery is done, somehow. In older Qt versions, you needed the mouse event (which means you should reject the tablet event, according to the docs) in order to find out what buttons on the stylus were pressed. But if you reject the tablet press event, you don’t get movement updates as tablet events, and the mouse events are compressed (as you noticed). Now, QTabletEvent has buttons too, so you no longer need to do that, but there may still be some legacy applications that are already written to work that way. So I’m not sure whether we should fix that now, or will it be seen as a behavior change which breaks applications? I guess fixing it in 5.7 or later ought to be OK at least. But it’s nontrivial to fix. QTBUG-51617 is about labelling the mouse events as synthesized so that you can at least easily know which mouse events to reject. It should be fixed now on X11 (for 5.6.1), we just need to make sure the other platforms work consistently. So you can have a mouse handler which ignores such events. > TabletPress: pointer=1 pressure=0.4313725531101227 tilt=(0,0) > MousePress > TabletMove: pointer=1 pressure=0.45098039507865906 tilt=(0,0) > MouseMove > TabletMove: pointer=1 pressure=0.45098039507865906 tilt=(0,0) > TabletMove: pointer=1 pressure=0.4470588266849518 tilt=(0,0) > ...[ many MouseMove and many more TableMove ] ... > TabletRelease: pointer=1 pressure=0.0 tilt=(0,0) > MouseMove > MouseRelease > > At the level of QApplication I'm seeing TabletEnterProximity and > TabletLeaveProximity events as you'd expect. Cool. Are you using an iPad Pro? Otherwise it can’t detect proximity, but maybe it synthesizes those events when you press? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] "Internal mouse button tracking invalid" messages
John Weeks wrote: > https://bugreports.qt.io/browse/QTBUG-42846 Thanks, I think that answers my question. Any idea if the proposed changes in the code reviews are in any way backportable to 5.6? R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Astropad and Tablet events
On 22 Mar 2016, at 20:18, Rutledge Shawn wrote: On 22 Mar 2016, at 02:30, Alexei Gilchrist wrote: Hi all, I'm trying to use Astropad (app provides OsX tablet interface with an iPad) with an app I’ve written and I'm getting odd results with tablet events in QT. First of all, I've been in contact with the devs and they seem to think it's a QT bug rather than an Astropad bug, and in any case Astropad works with other graphics programs that I've tried. Why do they think it’s a Qt bug? Maybe they should tell us what we are doing wrong if they know. I guess there must be a Mac daemon which tries to emulate a Wacom by sending the same events? It’s not only for Qt applications, right? But Qt applications work with a real Wacom but not Astropad, so they must not be emulating the events exactly the same. It is running a daemon that handles communication with the corresponding app on an iPad. One reason to believe it’s a QT bug is that Astropad works fine with other applications such as Gimp, SketchbookEpress, InKist, Photoshop, all respond to pressure variations so multiple toolkits are able to interpret the synthesised events correctly. You can enable the logging category qt.qpa.input.tablet to see how the events come in (the code is in qnsview.mm). Cool. Didn’t know that. I Need to figure out how to display the logging events in pyqt as setting export QT_LOGGING_RULES='qt.qpa.input=true' or editing ~/.config/QtProject/qtlogging.ini is not reporting to the console, maybe the python logging module which I’m using is taking over stderr. Will play around and see if I can get some feedback. I'm coding in python using pyqt and have Python 3.5.0 and QT 5.5.0 installed. At the level of QWidget you get an initial TabletPress event with pressure=0 followed immediately by a TabletRelease event with pressure>0 at which point the rest of the stroke is only reported as mouse events, with are low frequency and don’t contain pressure info. Astropad: TabletPress: pointer=1 pressure=0.0 tilt=(27,12) TabletRelease: pointer=1 pressure=0.1334028720856 tilt=(27,12) MousePress MouseMove MouseMove ...[ many MouseMove ]... MouseRelease Works as you'd expect with Wacom tablet, though accepting the tablet events does't stop the mouse events being fired (minor niggle): That’s https://bugreports.qt.io/browse/QTBUG-47007 It’s probably always been that way, at least in Qt 5, because the platform plugins are doing this mouse emulation when necessary. (In some cases the window system will send a synthesized mouse event itself, in which case we don’t need to.) Plugins don’t pay attention to whether the tablet event was accepted or not, because sending events from the platform plugin into the application is asynchronous, going through a queue. We assume the tablet event is rejected because that’s the default policy (outside of QtQuick where we assume an event is accepted), so the default is that the application does nothing, and then it gets a mouse event (so that you can use the stylus to interact with widgets etc.) AFAIK there isn’t a nice mechanism to wait and see whether the app accepted the tablet event or not; we’d have to wait until the asynchronous delivery is done, somehow. In older Qt versions, you needed the mouse event (which means you should reject the tablet event, according to the docs) in order to find out what buttons on the stylus were pressed. But if you reject the tablet press event, you don’t get movement updates as tablet events, and the mouse events are compressed (as you noticed). Now, QTabletEvent has buttons too, so you no longer need to do that, but there may still be some legacy applications that are already written to work that way. So I’m not sure whether we should fix that now, or will it be seen as a behavior change which breaks applications? I guess fixing it in 5.7 or later ought to be OK at least. But it’s nontrivial to fix. This is not much of a problem as a TabletPress is delivered before a MousePress so it’s easy to toggle a pen_down variable and ignore mouse events. QTBUG-51617 is about labelling the mouse events as synthesized so that you can at least easily know which mouse events to reject. It should be fixed now on X11 (for 5.6.1), we just need to make sure the other platforms work consistently. So you can have a mouse handler which ignores such events. Will take a look at those, it would be a more robust solution in case the ordering of events should change. TabletPress: pointer=1 pressure=0.4313725531101227 tilt=(0,0) MousePress TabletMove: pointer=1 pressure=0.45098039507865906 tilt=(0,0) MouseMove TabletMove: pointer=1 pressure=0.45098039507865906 tilt=(0,0) TabletMove: pointer=1 pressure=0.4470588266849518 tilt=(0,0) ...[ many MouseMove and many more TableMove ] ... TabletRelease: pointer=1 pressure=0.0 tilt=(0,0) MouseMove MouseRelease At the level of QApplication I'm seeing TabletE
[Interest] Qt/JNI blows up on android when activity is closed
As my app's tendrils root further into the mobile OSs, I've found one very
troubling issue. I have an alarm manager and a service to handle the pending
intent. The service talks to Qt through JNI. This works for as long as my Qt
Activity exists. However if the activity is closed (user task kills it) the
service keeps running (as it should) but then the native JNI functions stop
working.
I'm thinking we should be able to associate the native functions with the
application, or a default service so that the native functions always exist?
Is there a way to prevent this? Logs below. This does work until the activity
is killed.
D/Recents_TaskStackView( 2989): onStackTaskRemoved Task=Task (no group):
com.app.a [com.android.systemui.recents.model.Task@33d63ca2]
D/Recents_TaskStackView( 2989): getChildViewForTask t=Task (no group):
com.app.a [com.android.systemui.recents.model.Task@33d63ca2]
V/ApplicationPolicy( 784): isApplicationStateBlocked userId 0 pkgname com.app.a
I/WindowState( 784): WIN DEATH: Window{1d9235ab u0
com.app.a/com.app.MyActivity}
W/WindowManager( 784): Force-removing child win Window{18d9c46a u0
SurfaceView} from container Window{1d9235ab u0 com.app.a/com.app.MyActivity}
I/ActivityManager( 784): Process com.app.a (pid 23416)(adj 0) has died(100,423)
W/ActivityManager( 784): Scheduling restart of crashed service
com.app.a/com.app.ServerService in 1000ms
I/ActivityManager( 784): Start proc com.app.a for service
com.app.a/com.app.a.ServerService: pid=26206 uid=10246 gids={50246, 9997, 3003,
1028, 1015} abi=armeabi-v7a
D/app ServerServiceTask(26206): created
D/app ServerServiceTask(26206): onStartCommand
D/app ServerServiceTask(26206): sendBackgroundChunk running...
E/art (26206): No implementation found for boolean
com.app.MyApplication.ready() (tried Java_com_app_MyApplication_ready and
Java_com_app_MyApplication_ready__)
E/AndroidRuntime(26206): Process: com.app.a, PID: 26206
E/AndroidRuntime(26206): Caused by: java.lang.UnsatisfiedLinkError: No
implementation found for boolean com.app.MyApplication.ready() (tried
Java_com_app_MyApplication_ready and Java_com_app_MyApplication_ready__)
E/AndroidRuntime(26206):at com.app.MyApplication.ready(Native Method)
E/AndroidRuntime(26206):at
com.app.ServerService$SyncServerTask.doInBackground(ServerService.java:55)
E/AndroidRuntime(26206):at
com.app.ServerService$SyncServerTask.doInBackground(ServerService.java:50)
... eventually ...
W/ActivityManager( 784): Process com.app.a has crashed too many times: killing!
I/ActivityManager( 784): Killing 27664:com.app.a/u0a246 (adj 0): crash
D/CrashAnrDetector( 784): processName: com.app.a
D/CrashAnrDetector( 784): broadcastEvent : com.app.a data_app_crash
W/ActivityManager( 784): Unable to launch app com.app.a/10246 for service
Intent { cmp=com.app.a/com.app.ServerService }: process is bad
... last line repeats forever ...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] "Internal mouse button tracking invalid" messages
> On Mar 22, 2016, at 5:30 AM, René J. V. Bertin wrote: > > Any idea if the proposed changes in the code reviews are in any way > backportable > to 5.6? No idea at all. I only know about the bug because it affects us. -John Weeks ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Ensuring that a queued invocation occurs after deferred deletion
I recently discovered [1] that Loader defers deletion of items via
deleteLater(). Up until that point, I had been treating certain operations in
my program as synchronous (as I haven't introduced threads yet). Now that I
can't safely assume that UI items will be instantly destroyed, I have to
convert these operations into asynchronous ones.
For example, previously, I had this code:
game.quitGame();
My idea is to turn it into this:
game.requestQuitGame();
Within this function, the Game object would set its "ready" property to false,
emitting its associated property change signal so that Loaders can set active
to false. Then, QMetaObject::invoke would be called with Qt::QueuedConnection
to ensure that the Loader's deleteLater() calls would have been carried out
*before* tearing down the game and its objects.
In order to confirm that invokeMethod() works the way I thought it did, I added
the following debug statements to QEventLoop:
diff --git a/src/corelib/kernel/qeventloop.cpp
b/src/corelib/kernel/qeventloop.cpp
index dca25ce..7dae9d0 100644
--- a/src/corelib/kernel/qeventloop.cpp
+++ b/src/corelib/kernel/qeventloop.cpp
@@ -151,6 +151,7 @@ bool QEventLoop::processEvents(ProcessEventsFlags flags)
\sa QCoreApplication::quit(), exit(), processEvents()
*/
+#include
int QEventLoop::exec(ProcessEventsFlags flags)
{
Q_D(QEventLoop);
@@ -200,8 +201,11 @@ int QEventLoop::exec(ProcessEventsFlags flags)
if (app && app->thread() == thread())
QCoreApplication::removePostedEvents(app, QEvent::Quit);
-while (!d->exit.loadAcquire())
+while (!d->exit.loadAcquire()) {
+qDebug() << Q_FUNC_INFO << "--- beginning event loop";
processEvents(flags | WaitForMoreEvents | EventLoopExec);
+qDebug() << Q_FUNC_INFO << "--- ending event loop";
+}
ref.exceptionCaught = false;
return d->returnCode.load();
It turns out that I misunderstood the documentation; it only says that the slot
is invoked when control returns to the event loop of the receiver's thread. So,
as I understand it, it's possible that the invocation could happen *before* the
deferred deletion of the Loaders' items. As the documentation doesn't specify
the order between these two things, I should probably assume that it's not safe
to assume anything.
So, I'm left with the problem of how to ensure that a slot is invoked after the
Loaders' items have been destroyed. My only thought is to use a zero-second
single-shot timer. The question is: is this guaranteed to happen *after*
deferred deletion for a given iteration of an event loop? I can't see such a
guarantee in the documentation. I even checked the source code of e.g.
qeventdispatcher_win.cpp to see if I could find anything, without success.
Another question that's in the back of my mind is: is there a better way to do
this?
[1] https://bugreports.qt.io/browse/QTBUG-51995
[2] http://doc.qt.io/qt-5/qt.html#ConnectionType-enum
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Structuring of QML app as set of interlinked screens for maximum code reuse
Hi all,
I'm working on a fullscreen Qt Quick/QML app (for machine control)
which will consist of a set of interlinked screens, with key presses
as the only interaction method.
Each screen will have roughly the following QML structure:
Rectangle {
NavBar {
id: topBar
...
controls for navigation and information stuff,
different depending on which screen
...
}
Rectangle {
id: topSeparator
...
aesthetic divider rectangle between top nav bar and content.
...
}
Rectangle {
id: content
...
main content here, different depending on which screen.
...
}
Rectangle {
id: bottomSeparator
...
aesthetic divider rectangle between top nav bar and content.
...
}
NavBar {
id: bottomBar
...
controls for navigation and information stuff,
different depending on which screen
...
}
}
And I'm now trying to find a good structure that will minimize
repetition of QML code.
I understand that QMLs main model for code reuse is composition, but
that it also has a form of "inheritance": by defining a new Item in a
separate file using another Item as the top level item and redefining
some of its properties, I'm sort of inheriting that item.
I could save the above general structure in a Screen.qml, and in
FooScreen.qml, BarScreen et.c. do:
Screen {
...
override some properties
...
}
But this will only allow me to redefine properties, and add new child
items. How would I then be able to define both which content goes in
the main area (the content Rectangle in the "base" item) and in the
two navigation bars (topBar and bottomBar Rectangles)?
It seems QML is not really meant to be used this way, and I'd have to
essentially redefine these things in each of my screens, even if
they'll all have the same general structure? There's no "template"
mechanism so to speak?
I'm very thankful for any tips from people more experienced with Quick / QML.
And if you know of a well designed full screen QML app modeled as a
set of interlinked screens with keyboard navigation, I'm idle ears.
Cheers,
Elvis
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Structuring of QML app as set of interlinked screens for maximum code reuse
2016-03-22 20:13 GMT+01:00 Elvis Stansvik :
> Hi all,
>
> I'm working on a fullscreen Qt Quick/QML app (for machine control)
> which will consist of a set of interlinked screens, with key presses
> as the only interaction method.
>
> Each screen will have roughly the following QML structure:
>
> Rectangle {
>
> NavBar {
> id: topBar
> ...
> controls for navigation and information stuff,
> different depending on which screen
> ...
> }
>
> Rectangle {
> id: topSeparator
> ...
> aesthetic divider rectangle between top nav bar and content.
> ...
> }
>
> Rectangle {
> id: content
> ...
> main content here, different depending on which screen.
> ...
> }
>
> Rectangle {
> id: bottomSeparator
> ...
> aesthetic divider rectangle between top nav bar and content.
> ...
> }
>
> NavBar {
> id: bottomBar
> ...
> controls for navigation and information stuff,
> different depending on which screen
> ...
> }
> }
To clarify, think of NavBar as just another Rectangle in the example
above. It's just a custom item with some common visual properties.
Elvis
>
> And I'm now trying to find a good structure that will minimize
> repetition of QML code.
>
> I understand that QMLs main model for code reuse is composition, but
> that it also has a form of "inheritance": by defining a new Item in a
> separate file using another Item as the top level item and redefining
> some of its properties, I'm sort of inheriting that item.
>
> I could save the above general structure in a Screen.qml, and in
> FooScreen.qml, BarScreen et.c. do:
>
> Screen {
> ...
> override some properties
> ...
> }
>
> But this will only allow me to redefine properties, and add new child
> items. How would I then be able to define both which content goes in
> the main area (the content Rectangle in the "base" item) and in the
> two navigation bars (topBar and bottomBar Rectangles)?
>
> It seems QML is not really meant to be used this way, and I'd have to
> essentially redefine these things in each of my screens, even if
> they'll all have the same general structure? There's no "template"
> mechanism so to speak?
>
> I'm very thankful for any tips from people more experienced with Quick / QML.
>
> And if you know of a well designed full screen QML app modeled as a
> set of interlinked screens with keyboard navigation, I'm idle ears.
>
> Cheers,
> Elvis
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion
Hi, I saw your bug report. I encountered the same problem last week and I
found a workaround by passing the properties that belong to another object
one by one to JSon object. For example,
setSource("qrc:/LoaderItem.qml", { "color": theGame.player.color })
But in my case there was only one property. So instead of passing the
object, passing the property was easy. But for more complicated situations
that would be a pain...
Sina
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion
Hello,
I don't work with QML, but I'm pretty sure the events are processed in the
order of their appearance in the event queue. So if you have a
`deleteLater` call (i.e. you have a QEvent::DeferredDelete, which is
scheduled through the event loop) any queued call to a slot (i.e.
QEvent::MetaCall) that was made before the deletion request should be
happening before the actual deletion. So, if you're emitting signals from a
single thread, their respective slots would be called in the order in which
the signals had happened.
Now, with multiple threads it's a bit tricky, since there's the chance that
two threads will be trying to post a deferred function invocation at the
same time (hence the event queue is protected by a mutex). However that
mutex can't guarantee in what order the events will be posted, or rather no
one can.
> My only thought is to use a zero-second single-shot timer. The question
is: is this guaranteed to happen *after* deferred deletion for a given
iteration of an event loop?
This posts a timer event on the queue, so you can achieve the same with
QMetaObject::invokeMethod(receiverObject, "method", Qt::QueuedConnection),
and the same "restrictions" apply as mentioned above.
I hope this is of help.
Kind regards.
On Tue, Mar 22, 2016 at 7:50 PM, Curtis Mitch wrote:
>
> I recently discovered [1] that Loader defers deletion of items via
> deleteLater(). Up until that point, I had been treating certain operations
> in my program as synchronous (as I haven't introduced threads yet). Now
> that I can't safely assume that UI items will be instantly destroyed, I
> have to convert these operations into asynchronous ones.
>
> For example, previously, I had this code:
>
> game.quitGame();
>
> My idea is to turn it into this:
>
> game.requestQuitGame();
>
> Within this function, the Game object would set its "ready" property to
> false, emitting its associated property change signal so that Loaders can
> set active to false. Then, QMetaObject::invoke would be called with
> Qt::QueuedConnection to ensure that the Loader's deleteLater() calls would
> have been carried out *before* tearing down the game and its objects.
>
> In order to confirm that invokeMethod() works the way I thought it did, I
> added the following debug statements to QEventLoop:
>
> diff --git a/src/corelib/kernel/qeventloop.cpp
> b/src/corelib/kernel/qeventloop.cpp
> index dca25ce..7dae9d0 100644
> --- a/src/corelib/kernel/qeventloop.cpp
> +++ b/src/corelib/kernel/qeventloop.cpp
> @@ -151,6 +151,7 @@ bool QEventLoop::processEvents(ProcessEventsFlags
> flags)
>
> \sa QCoreApplication::quit(), exit(), processEvents()
> */
> +#include
> int QEventLoop::exec(ProcessEventsFlags flags)
> {
> Q_D(QEventLoop);
> @@ -200,8 +201,11 @@ int QEventLoop::exec(ProcessEventsFlags flags)
> if (app && app->thread() == thread())
> QCoreApplication::removePostedEvents(app, QEvent::Quit);
>
> -while (!d->exit.loadAcquire())
> +while (!d->exit.loadAcquire()) {
> +qDebug() << Q_FUNC_INFO << "--- beginning event loop";
> processEvents(flags | WaitForMoreEvents | EventLoopExec);
> +qDebug() << Q_FUNC_INFO << "--- ending event loop";
> +}
>
> ref.exceptionCaught = false;
> return d->returnCode.load();
>
> It turns out that I misunderstood the documentation; it only says that the
> slot is invoked when control returns to the event loop of the receiver's
> thread. So, as I understand it, it's possible that the invocation could
> happen *before* the deferred deletion of the Loaders' items. As the
> documentation doesn't specify the order between these two things, I should
> probably assume that it's not safe to assume anything.
>
> So, I'm left with the problem of how to ensure that a slot is invoked
> after the Loaders' items have been destroyed. My only thought is to use a
> zero-second single-shot timer. The question is: is this guaranteed to
> happen *after* deferred deletion for a given iteration of an event loop? I
> can't see such a guarantee in the documentation. I even checked the source
> code of e.g. qeventdispatcher_win.cpp to see if I could find anything,
> without success.
>
> Another question that's in the back of my mind is: is there a better way
> to do this?
>
> [1] https://bugreports.qt.io/browse/QTBUG-51995
> [2] http://doc.qt.io/qt-5/qt.html#ConnectionType-enum
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Structuring of QML app as set of interlinked screens for maximum code reuse
Von: Elvis Stansvik
An: "interest@qt-project.org Interest"
Gesendet: 22.03.2016 20:19
Betreff: Re: [Interest] Structuring of QML app as set of interlinked screens
for maximum code reuse
2016-03-22 20:13 GMT+01:00 Elvis Stansvik :
> Hi all,
>
> I'm working on a fullscreen Qt Quick/QML app (for machine control)
> which will consist of a set of interlinked screens, with key presses
> as the only interaction method.
>
> Each screen will have roughly the following QML structure:
>
> Rectangle {
>
> NavBar {
> id: topBar
> ...
> controls for navigation and information stuff,
> different depending on which screen
> ...
> }
>
> Rectangle {
> id: topSeparator
> ...
> aesthetic divider rectangle between top nav bar and content.
> ...
> }
>
> Rectangle {
> id: content
> ...
> main content here, different depending on which screen.
> ...
> }
>
> Rectangle {
> id: bottomSeparator
> ...
> aesthetic divider rectangle between top nav bar and content.
> ...
> }
>
> NavBar {
> id: bottomBar
> ...
> controls for navigation and information stuff,
> different depending on which screen
> ...
> }
> }
To clarify, think of NavBar as just another Rectangle in the example
above. It's just a custom item with some common visual properties.
Elvis
>
> And I'm now trying to find a good structure that will minimize
> repetition of QML code.
Since you already know that every screen will have two NavBars and separators
why don't you use your current QML structure as a skeleton for the whole
application?The content area could then be a thing that loads the 'pages' of
your application. Take alook at elements like StackView, TabView and ListView
(in combination with Loader as a delegate) which already provide a mechanism to
navigate between (dynamic) content...
>
> I understand that QMLs main model for code reuse is composition, but
> that it also has a form of "inheritance": by defining a new Item in a
> separate file using another Item as the top level item and redefining
> some of its properties, I'm sort of inheriting that item.
>
> I could save the above general structure in a Screen.qml, and in
> FooScreen.qml, BarScreen et.c. do:
>
> Screen {
> ...
> override some properties
> ...
> }
>
> But this will only allow me to redefine properties, and add new child
> items. How would I then be able to define both which content goes in
> the main area (the content Rectangle in the "base" item) and in the
> two navigation bars (topBar and bottomBar Rectangles)?
>
The content of your NavBars could be defined by models (maybe either ListModel
or something more advanced), at least that's what I would suggest. Either each
'page' of your application defines a model for both the upper and the lower
NavBar and these models are then used to dynamically create the appropriate
content OR your application switches the content of the NavBars based on
whatever state the application is currently in.
> It seems QML is not really meant to be used this way, and I'd have to
> essentially redefine these things in each of my screens, even if
> they'll all have the same general structure? There's no "template"
> mechanism so to speak?
>
I think your example fits QML rather fine. Your application seems to be the
typicalpage-based mobile application, only limited to key interaction instead
of touch/mouse.The initial conception of the architecture might require a bit
of thinking but as soonas you have that figured out the actual content of the
application can be added very easily.
> I'm very thankful for any tips from people more experienced with Quick / QML.
>
> And if you know of a well designed full screen QML app modeled as a
> set of interlinked screens with keyboard navigation, I'm idle ears.
>
You might find several applications using the page-based approach for basically
everymobile platform out there. For more code take a look at the examples that
qt already provides,you'll be able to find bits and pieces that you can easily
adapt to fit your needs (for example theqt quick controls gallery).
> Cheers,
> Elvis
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Structuring of QML app as set of interlinked screens for maximum code reuse
If I understand your question correctly, you may use alias property to
point to children of main / navigation bar. In Angular JS, they call this
feature as "transclude".
For example,
Screen.qml:
Item {
property alias main : mainContainer.children
}
CustomScreen.qml:
Screen {
main: Item {
}
}
A working example:
https://github.com/benlau/quickandroid/blob/master/QuickAndroid/Page.qml#L23
On 23 March 2016 at 03:19, Elvis Stansvik wrote:
> 2016-03-22 20:13 GMT+01:00 Elvis Stansvik :
> > Hi all,
> >
> > I'm working on a fullscreen Qt Quick/QML app (for machine control)
> > which will consist of a set of interlinked screens, with key presses
> > as the only interaction method.
> >
> > Each screen will have roughly the following QML structure:
> >
> > Rectangle {
> >
> > NavBar {
> > id: topBar
> > ...
> > controls for navigation and information stuff,
> > different depending on which screen
> > ...
> > }
> >
> > Rectangle {
> > id: topSeparator
> > ...
> > aesthetic divider rectangle between top nav bar and content.
> > ...
> > }
> >
> > Rectangle {
> > id: content
> > ...
> > main content here, different depending on which screen.
> > ...
> > }
> >
> > Rectangle {
> > id: bottomSeparator
> > ...
> > aesthetic divider rectangle between top nav bar and content.
> > ...
> > }
> >
> > NavBar {
> > id: bottomBar
> > ...
> > controls for navigation and information stuff,
> > different depending on which screen
> > ...
> > }
> > }
>
> To clarify, think of NavBar as just another Rectangle in the example
> above. It's just a custom item with some common visual properties.
>
> Elvis
>
> >
> > And I'm now trying to find a good structure that will minimize
> > repetition of QML code.
> >
> > I understand that QMLs main model for code reuse is composition, but
> > that it also has a form of "inheritance": by defining a new Item in a
> > separate file using another Item as the top level item and redefining
> > some of its properties, I'm sort of inheriting that item.
> >
> > I could save the above general structure in a Screen.qml, and in
> > FooScreen.qml, BarScreen et.c. do:
> >
> > Screen {
> > ...
> > override some properties
> > ...
> > }
> >
> > But this will only allow me to redefine properties, and add new child
> > items. How would I then be able to define both which content goes in
> > the main area (the content Rectangle in the "base" item) and in the
> > two navigation bars (topBar and bottomBar Rectangles)?
> >
> > It seems QML is not really meant to be used this way, and I'd have to
> > essentially redefine these things in each of my screens, even if
> > they'll all have the same general structure? There's no "template"
> > mechanism so to speak?
> >
> > I'm very thankful for any tips from people more experienced with Quick /
> QML.
> >
> > And if you know of a well designed full screen QML app modeled as a
> > set of interlinked screens with keyboard navigation, I'm idle ears.
> >
> > Cheers,
> > Elvis
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Setting currentIndex in Qt Quick ComboBox does not work
Hello list,
I hope this is the right forum to write, even though my sample code is
in Python but I think the problem lies deeper in the event propagation
or similar.
What I want to do looks simple at first. I want to show a ComboBox with
a list of items in it and one of them is selected. On a push of a
button the list ost extended by one element and that should be
reflected by the ComboBox. The selected item should of course always
stay the same. Unfortunately this is what does not work and the
selected item is reset to 0 even.
Any help is greatly appreciated!!!
Thanks Fabian
The sample source is here:
https://github.com/sturmf/python_samples/tree/master/pyqt_combobox
main.qml excerpt:
And the important parts are this:
function getCurrentIndex(list, element) {
console.log('getCurrentIndex')
if (list && element) {
for (var i = 0; i < list.length; i++) {
if (list[i].name === element.name) {
console.log('Found item at pos: ' + i)
return i
}
}
}
return -1
}
[...]
ComboBox {
id: combo
width: parent.width
currentIndex: getCurrentIndex(mymodel.items, mymodel.item)
model: mymodel.items
textRole: 'name'
}
The python model is this:
class MyModel(QObject):
itemChanged = pyqtSignal()
itemsChanged = pyqtSignal()
def __init__(self, parent=None):
QObject.__init__(self, parent)
self._items = [MyItem('one'), MyItem('two'), MyItem('three')]
self._item = self._items[2]
@pyqtProperty(MyItem, notify=itemChanged)
def item(self):
return self._item
@pyqtProperty(QQmlListProperty, notify=itemsChanged)
def items(self):
print('Query for items')
return QQmlListProperty(MyItem, self, self._items)
@pyqtSlot()
def new_item(self):
print('Append new item')
self._items.append(MyItem('new'))
self.itemsChanged.emit()
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Using Normal QPainter for Qt3D
Hi, Req: Print out of 3D structure through QPainter with in QRect. How cam I use normal QPainter for Qt3D rendering because I want to take print (or render somewhere else like on any widget, window,etc) of current static 3d Structure on root entity. Or is there any other better way to do this. Because I already have my reporter class which gives QPainter and QRect So that next user use this QPianter to render any thing within this QRect. And the rest of the thins like printing, saving rendered object on pdf, etc is already handled by this reporter class.Please let me know if you want any other info . Thank you Mail: zeeshanc...@yahoo.in___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
