[Interest] QML Inspector?
Is there anything that allows us to see a tree view of items at runtime and inspect (and modify?) their properties? I just helped someone who was dealing with an opacity issue and it was because of a component a few levels up. If they could visualize the element hierarchy as a tree, it would have been solved in seconds. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to share a native OpenGL context with Qt?
I managed to create our custom renderer by sharing the OpenGL context Qt
provides with qt_gl_global_share_context() and Qt::AA_ShareOpenGLContexts.
Using wglCreateContextAttribsARB() on our side, wharing worked without
errors, and it fixed some of our visual bugs.
We also made sure to call wglMakeCurrent() before we draw.
however I still get glitches: QML widget drawn in a half-quad, black
window, Qt window resizing our framebuffer, hover effects making our
renderer flicker... etc
I tried to launch gDebugger to see what's going on, and it seems not all of
Qt's contextes are shared.
Any idea how it can be solved?
2015-06-18 18:11 GMT+02:00 Marc Gilleron marc.gille...@gmail.com:
Actually, here is what we have:
Our application has a main thread loop.
It loads Qt dynamically (because we don't necessarily need it at compile
time). Qt doesn't wraps our app.
At some point in our main thread, we create a QApplication and widgets.
Then, as we did before Qt integration, we load our OpenGL renderer. It
creates its own context, may load resources at any time, and currently
draws in its own non-Qt window.
But, the simple fact we now have Qt Windows and non-Qt windows with OpenGL
at the same time produces glitches in our renderer, and we're trying to
solve it.
(We do this to keep them independant from each other. In the future we may
wrap our renderer window in a QWindow but at the moment we try to make it
just work).
Here is the kind of code I used to perform sharing, just after we create
our custom OpenGL context:
// Get the main Qt context
Q_ASSERT(qGuiApp);
QOpenGLContext * qtContext = qt_gl_global_share_context();
if (qtContext == 0)
{
// Qt: Global OpenGL context is not available
return 0;
}
#ifdef WIN32
// We get our renderer's OpenGL context
HGLRC hOurContext = /* get from somewhere */
HWND hOurWindow = /* get from somewhere */
QWGLNativeContext ourNativeContext(hOurContext, hOurWindow);
QOpenGLContext * ourContext = new QOpenGLContext;
ourContext-setNativeHandle(QVariant::fromValue(ourNativeContext));
ourContext-setShareContext(qtContext);
ourContext-create();
#else
However I didn't noticed any difference. Or is this the wrong way to share?
Or maybe there is one more problem:
we are still single-threaded, so we need to make sure the current OpenGL
is the good one when we perform our calls.
I said we cannot use the the approaches needing paintGL() and the like,
because we would be outside of our main loop, and would lead to
side-effects.
I also wonder if we can put the Qt main loop in ours, because at the
moment we have no clue when it updates...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QColumnView and Preview Widget
Is there a way with Qt 5 to turn OFF the preview widget? For our application we wanted to show some information based on what is clicked, branch or leaf, but the preview widget is only shown for leaves and not branches. So now we figured we can just put another widget next to the QColumnView widget to show our information but we want to hide the preview widget. We tried setting it to null but that didn't really work. Any thoughts or help would be much appreciated. Mike Jackson BlueQuartz Software ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QML Inspector?
Il 25/06/2015 21:30, Jason H ha scritto: Is there anything that allows us to see a tree view of items at runtime and inspect (and modify?) their properties? I just helped someone who was dealing with an opacity issue and it was because of a component a few levels up. If they could visualize the element hierarchy as a tree, it would have been solved in seconds. You're looking for GammaRay: https://github.com/KDAB/GammaRay/ See for instance this blog post: http://www.kdab.com/analysing-qtquick-apps-gammaray-button-gone/ Hope this helps, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QML Inspector?
There's GammaRay http://www.kdab.com/kdab-products/gammaray/ https://github.com/KDAB/GammaRay It's not 100% efficient, but better then nothing. We end up doing our own debugger command line to search and inspect object along a TreeView from QWidgets to see/edit properties, pointer value, invoke methods and emit signal. I would love to see one build for Qml build-in, we could stop maintain ours. The inspection of meta object can give you a lot of information to even classify the properties per inheritance. On Thu, Jun 25, 2015 at 3:30 PM, Jason H jh...@gmx.com wrote: Is there anything that allows us to see a tree view of items at runtime and inspect (and modify?) their properties? I just helped someone who was dealing with an opacity issue and it was because of a component a few levels up. If they could visualize the element hierarchy as a tree, it would have been solved in seconds. ___ 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] QML Inspector?
There is also QSG_VISUALIZE={batches,clip,overdraw}
More on that here:
http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
On Thu, Jun 25, 2015 at 10:58 PM, Jason H jh...@gmx.com wrote:
This.is.awesome!
Thanks Giuseppe!
Sent: Thursday, June 25, 2015 at 3:36 PM
From: Giuseppe D'Angelo giuseppe.dang...@kdab.com
To: interest@qt-project.org
Subject: Re: [Interest] QML Inspector?
Il 25/06/2015 21:30, Jason H ha scritto:
Is there anything that allows us to see a tree view of items at
runtime and inspect (and modify?) their properties?
I just helped someone who was dealing with an opacity issue and it was
because of a component a few levels up. If they could visualize the element
hierarchy as a tree, it would have been solved in seconds.
You're looking for GammaRay:
https://github.com/KDAB/GammaRay/
See for instance this blog post:
http://www.kdab.com/analysing-qtquick-apps-gammaray-button-gone/
Hope this helps,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts
___
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 mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Extremely sluggish browser performance in Qt 5.5 - [SOLVED]
OK, problem (more or less) resolved. Joerg Bornemann commented on the issue and it turns out it is a duplicate of another issue related to having more than one active network adapter. My machine actually has 2 physical network adapters (one active) and also a virtual one use by VMware Workstation. As soon as I go into the Device Manager and disable the other 2 adapters, the browser instantly starts to perform just like Chrome. Most importantly, Google Maps works extremely well. Thanks everyone! -Original Message- From: interest-bounces+ozemale=ozemail.com...@qt-project.org [mailto:interest-bounces+ozemale=ozemail.com...@qt-project.org] On Behalf Of Allan Sandfeld Jensen Sent: Tuesday, June 23, 2015 9:20 PM To: interest@qt-project.org Subject: Re: [Interest] Extremely sluggish browser performance in Qt 5.5 On Tuesday 23 June 2015, Till Oliver Knoll wrote: Am 23.06.2015 um 03:14 schrieb John C. Turnbull ozem...@ozemail.com.au: It seems that the problem exists in 5.4.2 as well so it's definitely not a regression. Sorry, just a shot into the blue here. Maybe the problem has to do with how Qt interacts with the underlying network stack? IPv6 setup, maybe? And does the problem also occur on other (Window) machines? A firewall maybe which gets overly busy with that unknown browser? What about other Qt networking (example) apps? Wasn't there once a simple FTP example (I guess that's gone though, since QFtp doesn't exist anymore in Qt 5 - or does it?)? Or that QML Flickr Image Viewer that I have in mind? Do those Qt network applications exhibit the same extreme slowness (which would hint at a problem somewhere in QAbstractSocket and friends maybe)? Are you in a corporate network? What if you run the application in another network (preferably on the /same/ computer)? Are you sure the other browsers don't use a (default system) proxy which would bring the network packets on the fast lane? My best bet is a problem with IPv6, the rest above sorted in increasing esotheric order... Remember you can't compare to other network-using Qt applications, since QtWebEngine is using Chromium's network stack, not Qt's. So the question when is the Chromium stack doing something wrong, and what is Chrome doing differently to not hit that issue. `Allan ___ 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] QML Inspector?
This.is.awesome! Thanks Giuseppe! Sent: Thursday, June 25, 2015 at 3:36 PM From: Giuseppe D'Angelo giuseppe.dang...@kdab.com To: interest@qt-project.org Subject: Re: [Interest] QML Inspector? Il 25/06/2015 21:30, Jason H ha scritto: Is there anything that allows us to see a tree view of items at runtime and inspect (and modify?) their properties? I just helped someone who was dealing with an opacity issue and it was because of a component a few levels up. If they could visualize the element hierarchy as a tree, it would have been solved in seconds. You're looking for GammaRay: https://github.com/KDAB/GammaRay/ See for instance this blog post: http://www.kdab.com/analysing-qtquick-apps-gammaray-button-gone/ Hope this helps, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts ___ 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] QtScript to QJSEngine migration
Hi Julien,
A long thread on this list last march on this subject was concluded by
an answer from Frederik Gladhorn (copy below). For now (5.5), the best
is probably to postpone your migration if you want to avoid
unofficial workarounds. QtScript is not going anywhere until feature
parity is (more or less) achieved, with a porting guide for
incompatibilities.
Your proposals could be part of a porting documentation, though.
Ilya.
Hello all,
thanks for all the feedback, it's very much appreciated.
The discussion has sparked quite a few discussions here in Oslo and we see
that we have some way to cover when it comes to getting QJSEngine up to the
level of what QtScript offers currently.
We think being able to run non-gui applications is important, that's why we
have a clean separation between the QML and Quick libraries. Using only the
QML library there are no UI dependencies and QJSEngine is available as a pure
JS engine without forcing any QML on anyone.
We still think it's the right way forward - maintaining one engine and keeping
it running well, instead of trying to deal with JSC, see Thiago's mails for
the reasoning behind that (plus the one in WebEngine which is unrelated to
this discussion).
The deprecation is just the label that reflects reality for QtScript. There is
no work being done on the module actively.
The focus will now be to get the missing features in place in QJSEngine. Most
of them hopefully by the time of the 5.6 release, to get the offering on par.
It would be helpful to get a list of features that really need to be there,
currently from what I understand the most urgent ones are:
- instantiating QObjects from JS
- exposing individual native functions to JS
- debugging API
The good thing is that a lot of the work is already done in QJSEngine, it's
simply not exposed in the API yet.
To re-iterate: QtScript is not going away, especially not before we have a
full replacement including more porting documentation. But don't expect active
development of the module to happen either. For many simple use cases,
QJSEngine can act as drop in replacement by the way, so we do care about the
migration path and try to keep API compatible where it is possible.
Greetings,
Frederik
2015-06-22 17:17 GMT+02:00 Julien Cugnière julien.cugni...@gmail.com:
Hi all,
With QtScript deprecated in Qt 5.5, and likely removed in a future
version, I'm looking at how to migrate to QJSEngine. There are some
things I'm not sure how best to achieve with the new minimalist API :
1. Exposing a global function to Javascript from C++.
In QtScript, one could write a C++ function with the signature
QScriptValue f(QScriptContext*, QScriptEngine*) , and expose it
directly in a global variable. I found no equivalent in QJSEngine. If
I understand correctly, I can only expose QObjects, so the best I
could come up with is the following :
* write my functions as Q_INVOKABLE members in a QObject.
* expose that QObject using QJSEngine::newQObject.
* iterate over the object with QJSValueIterator, and copy the
function properties to the global object.
Is there a better way available, or planned ? If not, would a merge
request to add the above to the documentation be accepted ? (probably
somewhere in Making Applications Scriptable).
2. Writing a variadic function from C++.
In QtScript this could be done with the QScriptContext* parameter.
With QJSEngine, the best I've come up with is this :
* write a wrapper function in javascript forwarding the arguments object :
function foo() { return Foo.foo_impl(arguments); }
* write foo_impl in C++ as a Q_INVOKABLE member taking a single
QJSValue parameter.
Is there a better way ? And again, is this worth adding to the documentation ?
3. How to raise a Javascript error from a function implemented in C++.
This is basically https://bugreports.qt.io/browse/QTBUG-39041, which
has seen no comment for the past year. Is something similar planned ?
Otherwise the only solution I see is again a wrapper function written
in Javascript. Something like this :
function foo() {
var res = foo_impl();
if (Object.getPrototypeOf(res) === Error)
throw res;
else
return res;
}
--
Julien Cugnière
___
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] How to know if WebView has an error on loading the page
Hello, I’m using this http://doc.qt.io/qt-5/qml-qtwebview-webview.html http://doc.qt.io/qt-5/qml-qtwebview-webview.html for embedding some simple pages into the app. But I don’t know how to check if there was problems on downloading the page. For example, if the remote url is not available, or if the device is offline, the webview just display a white empty page on iOS without notifying the user for the error. Hello, Gianluca. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Determining if a glyph can be painted for a given character
Hi Our application has a QPlainTextEdit subclass, and one of its features is that it has an option to display whitespace (such as line endings). One of the whitespace symbols we use is \u21b5 (that's DOWNWARDS ARROW WITH CORNER LEFTWARDS if anyone cares). Our current code reimplements QPlainTextEdit::paintEvent() and has code like this: QPainter painter(viewport()); const QChar CRGlyph((ushort)0x21b5); QRawFont rf(QRawFont::fromFont(painter.font())); const bool fontHasCRGlyph = rf.supportsCharacter(CRGlyph); We only try to paint the whitespace character if fontHasCRGlyph is true, since otherwise we would end up painting the empty rectangle that indicates a character was not found, and that doesn't look good. The problem is that on some platforms, including Windows 7 and Mac OSX 10.10, but not Mac OSX 10.9, fontHasCRGlyph is false. Yet, if I do something simple like the following, the correct glyph for the same character is displayed: setPlainText(CRGlyph); I suspect the reason for this is that the font in use by the QPlainTextEdit does not contain the CRGlyph character, but a fallback font is available for use that does contain the character, so it is displayed properly. However, I initialize the QRawFont object with the primary font used in the widget, which is lacking the glyph. Does anyone have any suggestions of how I can test that a character can be displayed correctly before I try to draw the character on screen? Thanks for your help Adam ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
