Re: [Development] Qt::WA_PaintOnScreen Changes
Hi I am porting an application to Qt5/KF5 and was surprised to see the main widget of the application was showing all black. There are screenshots of the original version and the buggy version[1] online. I removed setAttribute( Qt::WA_PaintOnScreen, true ); on that widget and the widget was rendering fine again. I would like to know if that was a good idea and what are the implications or if this is a bug in Qt. This seems odd. I'm not certain what would cause this, but it shouldn't be like that. Can you create a bugreport and provide a small example that reproduces this. Jørgen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.3.2
Hi, New snapshot available for Qt 5.3.2: Windows: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-08-14_134/ Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-08-14_128/ Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-08-13_104/ Please inform me immediately if you find something blocking the release! Qt5 changes in this snapshot: https://codereview.qt-project.org/#/c/90879/ : Patch Set 35: * qtbase aaaba5d...f2c7ea7 (46): Fix build with QT_NO_MDIAREA Show the correct cursor for QLineEdits side buttons. OSX MenuRole detection: remove ampersand before looking for keywords Fix disconnect()ing from signals declared in a base class Doc: document that we have unfixed bugs with waitForXxx on Windows Fix rendering alpha-blended text which needs to be clipped at the top. Fix build due to missing include when using a minimal config. Fix build with QT_NO_DRAGANDDROP Font Database: Add support for private, system UI font families Apply upstream patch r1498 to our PCRE copy Apply upstream patch r1495 to our PCRE copy Initialize member. Document missing QLatin1String methods network tests: add manual test for auth / proxy auth Uncomment some tests which accidently got commented Both HiQualAA and normal AA should mean antialiasing in rasterengine. Check if Start/EndPage returns non-positive value when error checking Windows: Fix stored family name of fallback fonts Android: Remove native views when their window is destroyd. Android: Fix QAndroidPlatformServices::openUrl(). Android: Fix recursion bug in callStaticMethod() GTK file dialog: pre-fill the filename if given to a Save dialog QFileDialog docs: remove misleading sentence about static functions Doc: Placed Qt OpenGL class convention in code block. Undo: Fix state entry bug for parallel state groups Do not add QOffscreenSurface windows to the global list tst_QHash: check which of several equal keys is inserted OpenGL: destroy QGLContext allocated by QGLContext::fromOpenGLContext tst_QSet: check which of several equal elements is inserted fix paths in installed qtmain.prl pass --sysroot to compile tests also on windows add /ENTRY:main only for target builds avoid that CROSS_COMPILE affects host builds ensure that arch_host.pro is used also on windows Merge Merge remote-tracking branch origin/stable into 5.3 into refs/staging/5.3 Add missing power button keycode to keymap Android: export ANDROID_SDK_BUILD_TOOLS_REVISION. cocoa: Fix compiler warnings about unused functions. Propagate swapInterval to QGLFormat Fix double clicks in eglfs Work around ICC bug in local static symbols for Q_GLOBAL_STATIC QCoreTextFontDatabase: Fix font weight value when populating a family Dont convert signed to unsigned when we need all 32bit Fix compilation if EC is disabled in OpenSSL Improve dbus cross compilation Fix buffer overrun error with some proxy servers * qtdeclarative 14bc8dc...1fd06d1 (29): Correct strokeRect documentation. Silence harmless compiler warning. benchmarks: Skip compilation of (and mark with FIXME) a few benchmarks that dont build. benchmarks/particles: fix projects to actually build Fix compilation of tst_compilation (:-P) benchmark. Avoid double deletion when deleting an incubating component. Invalidate the scenegraph properly in the rendercontrol Fix crash when loading invalid QML with behavior on invalid group property Fix crash when animators are deleted just after being started. Dont try to reload QQuick images when changing to null screen Clarify Component.onCompleted/onDestruction docs Fix fbo creation and resize logic in QQuickWidget Fix Qt.include with cached compilation units and resources Synchronize PathView gesture grabbing with other items. Fix FBO recreated every time the QSG node is updated under some conditions Run autotests for Canvas.renderTarget == FramebufferObject also. More QQuickCanvas cleanup handling. Make canvas cleanup work propertly... Use the current context to resolve extensions. qmlplugindumper: do not pop up a window if an assert is triggered Fix assertion: ASSERT: hasException in file jsruntime/qv4engine.cpp, line 933 Merge remote-tracking branch origin/stable into 5.3 Fix QQmlDelegateModel getting out of sync QQuickWindow: add some links to resetOpenGLState Remove metaobject revisioning for QQuickScreenAttached Dont dereference null pointer. Flickable: Cancel interaction on interactive changes Dont try to draw shader effect sources with dims 0. QQuickMouseArea: Mark override functions with Q_DECL_OVERRIDE * qtdoc 9df45a1...2093fb4 (2): Update build instructions for Windows. Doc: Removed the reference to Qt Mobile. * qtenginio ca82a19...16c55e4 (1): Improve login code snippet * qtlocation d771c5d...09f68b9 (3): Fix fitViewportToMapItemsRefine Avoid potential double deletion when handling OSM route replies Fix QGeoRouteReplyOsm::networkReplyFinished * qtmacextras c5a3e9a...9af049f (1): Doc:
Re: [Development] Qt5.3 / Location Maps
I have done more work towards our app QtQuick2 transition. Several things I
found out
- Qt3d and location with geoservices compiles nicely for Android and iOS
- For iOS by default they still create dynamic libs and needs to be patched
to make static version
- After iOS make is made, make clean distclean does not clean all but if I
would like to compile
an other platform, I need to take clean snapshot
- For Android, getting geoservices map plugin found during runtime requires
a lot of tweaking, it does not work out of the box even it builds without
problems
- For Ubuntu and OSX all works out of the box
Then back to the previous question, how input data from C++ app to Map.
On Thu, May 8, 2014 at 1:40 PM, Kate Alhola kate.alh...@gmail.com wrote:
On Wed, May 7, 2014 at 3:41 AM, Aaron McCarthy mccarthy.aa...@gmail.com
wrote:
Hi,
On Tue, 6 May 2014 15:59:59 Kate Alhola wrote:
Hi, i have been doing application that uses maps. Application UI is Qml
but
all data is generated on C++ side and once again, thee basic issue, is
there any way to add items from C++ to Qml map.
I used Qt4.8 and there was basically same issue, there was no way to add
any C++ generated stuff on Qml map, no any way to add QGeoMapObject etc
to
Qml map. I resolved this issue by making own QML wrapper
around QGraphicsGeoMap that accepts C++ classes.
Then when i switched to Qt5.3, there was no maps at all, I ported Qt4.8
maps to Qt5.3 QtQuick1 and that works nicely. I also noticed that it
can't
be ported to QtQuick2 because old maps depend on QGraphicsView.
Now I checked Qt5.3 location maps with qt3d . All fine, it copmpiles and
run but alsp all C++ API is gone and there is still no way to add items
from C++ to map. Even all QGeoMapObjects are gone.
The Maps C++ API was removed from the public API during the initial
porting to
Qt5. This was done because we didn't want to be tied to a C++ API that we
were
not 100% satisfied with and to focus limited developer resources on the
QtQuick2 implementation.
That's clear and reasonable way of working. Mostly I was missing some way
to use
data produced from C++ in Qml maps event with standard already defined
C++ types like QGeoCoordinate or QListQGeoCoordinate
Something like
in C++ ( qith all QProperty stuff )
QListQGeoCoordinate path;
And in Qml
MapPolyline {
line.color: blue
coordinates:path
}
Or similar way to have Markers.
For the time being the best way to place a large number of similar items
on a
map from C++ is to represent those items as a QAbstractListModel and use
it as
the source model for the MapItemView in QML.
It looks that with this Abstract does same thing, I just need to convert
old code from QGeoMapObjects/QListQGeoCoordinate
to QAbstractListModel . Let's see how it works
Least i did not find right way to do this so that it works.
QDeclarativePolylineMapItem jas Path property that is type of QJSvalue
and
that looks only possible hook to c++, create path of polyline in C++ as
QJSvalua and then pass this to Qml ?
There is also the addCoordinate()/removeCoordinate() invokable functions
which
are easier to use than constructing a QJSValue, but probably less
efficient if
adding or removing a large number of coordinates.
I hope that this QAbstractListModel does the thing
I Tried also QJSValue but no success by using standard QJSVallue. I was
able to construct array of strut QJSValue but I never succeeded to return
it. I searched all documentation and QTSOurce code unsucessfully. When I
look Qt Code they always used different way, so may be there is no way to
return QJSValue array using public class ?
return new QJSValuePrivate(v4, QV4::ValueRef(pathArray));
Finally only way how I did it working was to do same way it was done in
QJSValue QDeclarativePolygonMapItem::path() const
There was just one very ugly thing, it depends a bunch of private headers.
So, only working way to export map path from C++ core to Qml Map is
one that has a lot of dependency to private headers.
I hope still for future:
- Please have function to accept QListQGeoCoordinate path. There is
no value added to convert it to QJSValue and then inside of iten back
to QListQGeoCoordinate
-May bey there should be ways to construct QJSValues without using a
lot of private headers.
Kate
What sort of objects are you displaying on the map, is it just polylines?
The application I have is sports app that stores route of training events
that are in current
version displayed as QGeoMapPolylineObject . The data is generated by our
app and stored
in database. Application runs on Android/iOS and desktop. Because for
usability reasons
fast response is important, I wont add extra JS layers just copy
coordinates etc fro C++ to Map.
We started with Qt4.8 / Necessitas but now we have switched to Qt5.3
/QtQuick1 and next
step is to go QtQuick2.
What is happening to Qt Maps
Re: [Development] Qt::WA_PaintOnScreen Changes
I am porting an application to Qt5/KF5 and was surprised to see the main widget of the application was showing all black. There are screenshots of the original version and the buggy version[1] online. I removed setAttribute( Qt::WA_PaintOnScreen, true ); on that widget and the widget was rendering fine again. I would like to know if that was a good idea and what are the implications or if this is a bug in Qt. This seems odd. I'm not certain what would cause this, but it shouldn't be like that. Can you create a bugreport and provide a small example that reproduces this. If you were using WA_PaintOnScreen then you also need to ensure you reimplement paintEngine() to return 0. Had you done that at all? Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Wayland app_id
Hi, I was reading xdg-shell, a Wayland protocol that's been in development for some time now and it's going to replace wl_shell_surface. For who doesn't know Wayland, basically this is a protocol that introduces more high level concepts over plain surfaces such as popups, minimize, maximize, etc... xdg-shell has the concept of app_id from the desktop entry specification. This is more or less the desktop file path relative to $XDG_DATA_DIR with slashes replaced by dashes. This used to be the class in wl_shell_surface and I know the concept exists on X11 as well (WMCLASS if I recall). Now the question is: how can Qt applications set this app_id? Since app_id should be the same for all xdg surfaces I would propose adding an applicationIdentifier property to QGuiApplication. Thoughts? -- Out of the box experience http://www.maui-project.org/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Wayland app_id
On Thu, Aug 14, 2014 at 8:15 PM, Pier Luigi pierluigi.fior...@gmail.com wrote: This used to be the class in wl_shell_surface and I know the concept exists on X11 as well (WMCLASS if I recall). WM_CLASS I think, but don't quote me, it's been a long, long time since I've looked into anything X11 related. ... a quick grep+read on qtbase seems to support this theory. Now the question is: how can Qt applications set this app_id? Since app_id should be the same for all xdg surfaces I would propose adding an applicationIdentifier property to QGuiApplication. Why do they have to? Just like WM_CLASS is an internal detail to the xcb plugin, I'd imagine that this would be an internal detail in QtWayland. BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Wayland app_id
2014-08-14 20:27 GMT+02:00 Robin Burchell robin...@viroteck.net: On Thu, Aug 14, 2014 at 8:15 PM, Pier Luigi pierluigi.fior...@gmail.com wrote: This used to be the class in wl_shell_surface and I know the concept exists on X11 as well (WMCLASS if I recall). WM_CLASS I think, but don't quote me, it's been a long, long time since I've looked into anything X11 related. Ah yes WM_CLASS, it's been a long time. ... a quick grep+read on qtbase seems to support this theory. Now the question is: how can Qt applications set this app_id? Since app_id should be the same for all xdg surfaces I would propose adding an applicationIdentifier property to QGuiApplication. Why do they have to? Just like WM_CLASS is an internal detail to the xcb plugin, I'd imagine that this would be an internal detail in QtWayland. At a first and quick glance qxcb sets it to QCoreApplication::applicationName() which is way too verbose and not the desktop entry name, or argv[0] base name which is basically what I did with qtwayland but this doesn't feel right. This doesn't feel right because the desktop entry name might be different than the executable name hence my desire for something that would allow the application to specify it. There's QPlatformNativeInterface::setWindowProperty() but this requires applications to set app_id on each window every time but app_id is really tied to the application. Also it should be somehow documented, otherwise developers wouldn't know about it. Maybe QPlatformNativeInterface could have application wide properties too? -- Out of the box experience http://www.maui-project.org/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Wayland app_id
On Thu, Aug 14, 2014 at 9:52 PM, Pier Luigi pierluigi.fior...@gmail.com wrote: Now the question is: how can Qt applications set this app_id? Since app_id should be the same for all xdg surfaces I would propose adding an applicationIdentifier property to QGuiApplication. Why do they have to? Just like WM_CLASS is an internal detail to the xcb plugin, I'd imagine that this would be an internal detail in QtWayland. At a first and quick glance qxcb sets it to QCoreApplication::applicationName() which is way too verbose and not the desktop entry name, or argv[0] base name which is basically what I did with qtwayland but this doesn't feel right. This doesn't feel right because the desktop entry name might be different than the executable name hence my desire for something that would allow the application to specify it. It kind of has to be enough, though, because you won't always get launched from a desktop file (there's D-Bus activation, or plain old exec, shell launching, etc). And what if the property just isn't set? I don't think a new property is a good idea, both because it seems incredibly limited in the scope of its usefulness (I don't see how it's applicable in a cross platform way, and I don't even know how you'd begin to document something this limited in usefulness) and because they simply won't set it (partly due to it being a new property, and partly because of the previous problem). But yeah, you're running into the age old chestnut of a problem that has haunted the fine folks at Jolla for a while: how to associate a desktop file with a process. We never really came up with a good answer there (at least not a generic one.) Maybe someone else has a smart idea, let's see. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
