Re: [Development] why is QJSEngine not modifying metaObject
On Wed, Feb 11, 2015 at 4:00 PM, Thiago Macieira thiago.macie...@intel.com wrote: On Wednesday 11 February 2015 18:50:42 Hausmann Simon wrote: Hi, The brute force way is to add this feature to the engine at the expense of performance, memory consumption and maintenance :) Today you can invoke Javascript defined functions by simply getting the function as a property via QJSValue and call() it. The objective was to expose such a JS object to D-Bus, but QtDBus requires the meta object to match. I'm not sure what your full requirements are (it seems maybe you want to do the reverse of what I was trying to do), but you might be interested in a little science project I put together for a similar task: https://bitbucket.org/devonit/qqmldbusinterface. Regards, Matt -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] osx search paths with 5.3.2
Hi all, I've been using qt 4.8.6 for quite some time on my macbook installed from homebrew with no problem whatsoever. I decided over the weekend to upgrade my install to the latest qt5 build which on homebrew is 5.3.2. Everything installed, qmake ran and I was able to successfully build qjsonrpc on my mac. Cool. Now, I've got another test app that links to qjsonrpc, and when I build that it turns out that I'm no longer able to find anything in /usr/include or link to anything in /usr/lib. I naturally assumed this was an issue with the compiler's search paths, but then why did 4.8.6 work? Hmm, okay, let's just use Qt's distributed 5.3.2 binaries, maybe homebrew got it wrong... Same problem. I went through a diff of the mkspecs dirs of both versions and couldn't see anything that would obviously cause this. Has anyone using Qt on mac run into this problem? Running out of ideas here! Cheers, Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] osx search paths with 5.3.2
On Mon, Oct 13, 2014 at 11:07 AM, Ziller Eike eike.zil...@theqtcompany.com wrote: On Oct 13, 2014, at 4:55 PM, Matt Broadstone mbroa...@gmail.com wrote: Hi all, I've been using qt 4.8.6 for quite some time on my macbook installed from homebrew with no problem whatsoever. I decided over the weekend to upgrade my install to the latest qt5 build which on homebrew is 5.3.2. Everything installed, qmake ran and I was able to successfully build qjsonrpc on my mac. Cool. Now, I've got another test app that links to qjsonrpc, and when I build that it turns out that I'm no longer able to find anything in /usr/include or link to anything in /usr/lib. I naturally assumed this was an issue with the compiler's search paths, but then why did 4.8.6 work? Hmm, okay, let's just use Qt's distributed 5.3.2 binaries, maybe homebrew got it wrong... Same problem. I went through a diff of the mkspecs dirs of both versions and couldn't see anything that would obviously cause this. Has anyone using Qt on mac run into this problem? Running out of ideas here! Hard so say anything without knowing what the things are that are not found. General hints are: Have a look at the actual compiler command lines and look for the -I and -F s, and run qmake with “qmake -d -d -d” to get detailed information on which files are pulled in and how specific qmake variables get their values. Br, Eike Hi Eike, Thanks for the quick response. The things that are not found are for isntance, /usr/include/qjsonrpc/qjsonrpcmessage.h. I can fix this manually by adding /usr/include to my INCLUDEPATH - no problem, but definitely wasn't a requirement on the exact same machine with the qt 4.8.6 install (maybe a more basic question: is this just something that changed in 5.x mkspecs?). My compile lines with 4.8.6 installed add -I/usr/include to the compile lines, while the 5.3.2 install does not. Additionally, adding -L/usr/lib to my LIBS line in the pro file with 5.3.2 still breaks and can't find files that are definitely there. I'll pour through this qmake -d -d -d now and see if I can provide any more information. Matt -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWebChannel internal protocol
On Mon, Jul 7, 2014 at 6:31 AM, Milian Wolff m...@milianw.de wrote: On Monday 07 July 2014 12:22:44 Lutz Schönemann wrote: On 07/04/2014 08:41 PM, Milian Wolff wrote: No. I think most of this can be cleaned up nowadays. For some history see this: https://codereview.qt-project.org/#/c/77481/ Anyhow, as I said above - patches welcome. I propose: - We should get rid of the raw WebChannel support If I understand that code correctly the only difference between a raw WebChannel and a regular WebChannel is that the regular one gets initialized on client side. Meaning that the client JS library subscribes to signals and property updates by default. A raw WebChannel does not do that. If that is the only difference and there is nothing on Cpp side that is special for a raw WebChannel it should be no big deal to remove it from JS lib. Yes. It should allow us quite some simplifications, at least on the client side. But maybe there are also a few things we could then do on the server side. At the very least, we could merge the QMetaObjectPublisher with the QWebChannel[Private] where appropriate. - The message structure should be flattened, i.e. data should go away and everything be put into the top-level object - always use type to identify the type - make the id for method callbacks a pure integer to identify which callbacks to invoke on the client side - more? Right, flatten the structure could simplify the protocol. For a reply messages we'd still need something like a data property to store the data returned by called method to separate meta-data from payload. Sure, but I'd put it into a return property or similar. We used the JSON-RPC protocol in our implementation. It's widely used and already solved most problems occur when designing a new protocol. It provides everything we needed to do method calls and send signals. We just needed to adjust the data structure returned by system.describe function call to also describe signals, properties and enums. It is easy to understand and human readable (no magic numbers). Because JSON-RPC is developed with web services in mind it would make it easy to not just forward QObjects to a local/remote client but also to implement web services in an very easy way. The description of methods also includes types of arguments and return value that makes it possible to implement clients in a typed language (C/C++). What do you think about that? No, I want to keep the protocol internal. I plan to optimize it some more in the long-term, maybe even going full-binary. That said, I am thinking of changing the transport API to take JSON data structures instead of QStrings. Then, the transport could decide how to implement stuff and you could then implement a JSON-RPC protocol transport for the webchannel. In QtWebKit/QtWebEngine we could use Qt's binary JSON format. I hope to find some time to implement this in the following days. Just a reminder that qjsonrpc (https://bitbucket.org/devonit/qjsonrpc) is out there, and might be of use in your current situation. Cheers, Matt Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for a sandbox area: Replicant
On Monday, June 2, 2014, Stottlemyer, Brett (B.S.) bstot...@ford.com wrote: Are you aware of QxtRPCService as well? http://libqxt.bitbucket.org/doc/0.6/qxtrpcservice.html André, Nope. Didn't know about that one. It is Signals only, not Properties and Slots as well, though. Thanks! Brett There's also qjsonrpc (http://bitbucket.org/devonit/qjsonrpc), if you're interested for cross platform rpc solutions. Cheers, Matt ___ Development mailing list Development@qt-project.org javascript:; http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuickComponents ComboBox with QEglFSWindow
On Mon, Apr 14, 2014 at 12:25 PM, Matt Broadstone mbroa...@gmail.comwrote:
On Mon, Apr 14, 2014 at 7:07 AM, Rutledge Shawn
shawn.rutle...@digia.comwrote:
On 11 Apr 2014, at 10:15 PM, Matt Broadstone wrote:
Hi,
We're experiencing an odd crash while running our Qt Quick application
in a VirtualBox session using eglfs on the framebuffer. The application
works perfectly passing the '-platform eglfs' options, however, when we try
to use a ComboBox we get a segfault/qFatal, with the resulting backtrace
(only first twelve frames included for brevity):
#0 0x7eff7c041389 in raise () from /usr/lib/libc.so.6
#1 0x7eff7c042788 in abort () from /usr/lib/libc.so.6
#2 0x7eff7c956895 in qt_message_fatal (context=..., message=...)
at global/qlogging.cpp:979
#3 QMessageLogger::fatal (this=this@entry=0x7fff32b96030,
msg=msg@entry=0x7eff7768e380 EGLFS: OpenGL windows cannot be mixed with
others.) at global/qlogging.cpp:384
#4 0x7eff7766cfb7 in QEglFSWindow::create (this=this@entry=0x1db8030)
at qeglfswindow.cpp:115
#5 0x7eff7766b60e in QEglFSIntegration::createPlatformWindow
(this=optimized out, window=0x1db66f0) at qeglfsintegration.cpp:122
#6 0x7eff7d03180b in QWindow::create (this=this@entry=0x1db66f0)
at kernel/qwindow.cpp:480
#7 0x7eff7d032150 in QWindow::setVisible (this=0x1db66f0,
visible=optimized out) at kernel/qwindow.cpp:426
#8 0x7eff6c888d6a in QQuickPopupWindow::show
(this=this@entry=0x1db66f0)
at qquickpopupwindow.cpp:95
#9 0x7eff6c888579 in QQuickMenuPopupWindow::show (this=0x1db66f0)
at qquickmenupopupwindow.cpp:57
#10 0x7eff6c884efb in QQuickMenu::__popup (this=0x1bff2e0,
x=optimized out, y=optimized out, atItemIndex=0) at qquickmenu.cpp:403
#11 0x7eff6c897f53 in QQuickMenu::qt_static_metacall
(_o=_o@entry=0x1bff2e0,
_c=_c@entry=QMetaObject::InvokeMetaMethod, _id=_id@entry=22,
_a=_a@entry=0x7fff32b96550)
at .moc/moc_qquickmenu_p.cpp:227
#12 0x7eff6c898427 in QQuickMenu::qt_metacall (this=0x1bff2e0,
_c=QMetaObject::InvokeMetaMethod, _id=22, _a=0x7fff32b96550) at
.moc/moc_qquickmenu_p.cpp:330
There is some mention on the i.MX6 wiki page about multiple windows (
http://qt-project.org/wiki/i.MX-6), but that appears to be related to
mixing Quick views and widgets, which we are not doing. There also seems to
be an existing ComboBox bug (
https://bugreports.qt-project.org/browse/QTBUG-35989), but this looks
like it's quite different.
Any insight would be appreciated, I just wanted to do some further
investigation here before creating the bug report.
What version do you have? Looks like the combo box is trying to create
another window for the dropdown list, and we're not allowed to have more
than one window on eglfs. I don't think it should be doing that anymore on
platforms where it's not supported.
Forgot to reply-all on that last one, apologies:
Qt 5.2.1 (built from source off the git v5.2.1 tag), using this configure
line:
./configure -confirm-license -opensource -debug -system-sqlite
-openssl-linked \
-nomake examples -nomake tests -plugin-sql-psql
-plugin-sql-sqlite \
-eglfs -no-rpath -optimized-qmake -dbus-linked
-reduce-relocations \
-opengl es2 -directfb
Running on Arch Linux version 2013.03.01 in VirtualBox 4.3.10 r93012, with
the form:
./ourquickapp -platform eglfs
(same thing happens with 5.3 built from source, but this failed related to
a different issue related to unaddressable byes for ioctl, and only works
when run in valgrind)
Please let me know if there's any other information I can provide.
Matt
Shawn,
Can you tell me what I should be looking for to guarantee it's following
the correct code path? The combobox is indeed trying to create a new
window, as comboboxen are wont to do, and the crash is happening in this
code block:
qeglfswindow.cpp:80+
QEglFSScreen *screen = this-screen();
if (screen-primarySurface() != EGL_NO_SURFACE) {
if (isRaster() screen-compositingWindow())
return;
#if !defined(Q_OS_ANDROID) || defined(Q_OS_ANDROID_NO_SDK)
// We can have either a single OpenGL window or multiple raster windows.
// Other combinations cannot work.
qFatal(EGLFS: OpenGL windows cannot be mixed with others.);
#endif
return;
}
Based on your previous email you said: I don't think it should be doing
that anymore on platforms where it's not supported, does that mean we
should be looking for a fix in the QML component code or the QPA code?
Looking for some insight here so we can help expedite the bug fix, or just
fix it ourselves.
Thanks,
Matt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuickComponents ComboBox with QEglFSWindow
On Wed, Apr 16, 2014 at 1:21 PM, Matt Broadstone mbroa...@gmail.com wrote:
On Mon, Apr 14, 2014 at 12:25 PM, Matt Broadstone mbroa...@gmail.comwrote:
On Mon, Apr 14, 2014 at 7:07 AM, Rutledge Shawn shawn.rutle...@digia.com
wrote:
On 11 Apr 2014, at 10:15 PM, Matt Broadstone wrote:
Hi,
We're experiencing an odd crash while running our Qt Quick application
in a VirtualBox session using eglfs on the framebuffer. The application
works perfectly passing the '-platform eglfs' options, however, when we try
to use a ComboBox we get a segfault/qFatal, with the resulting backtrace
(only first twelve frames included for brevity):
#0 0x7eff7c041389 in raise () from /usr/lib/libc.so.6
#1 0x7eff7c042788 in abort () from /usr/lib/libc.so.6
#2 0x7eff7c956895 in qt_message_fatal (context=..., message=...)
at global/qlogging.cpp:979
#3 QMessageLogger::fatal (this=this@entry=0x7fff32b96030,
msg=msg@entry=0x7eff7768e380 EGLFS: OpenGL windows cannot be mixed
with others.) at global/qlogging.cpp:384
#4 0x7eff7766cfb7 in QEglFSWindow::create (this=this@entry=0x1db8030)
at qeglfswindow.cpp:115
#5 0x7eff7766b60e in QEglFSIntegration::createPlatformWindow
(this=optimized out, window=0x1db66f0) at qeglfsintegration.cpp:122
#6 0x7eff7d03180b in QWindow::create (this=this@entry=0x1db66f0)
at kernel/qwindow.cpp:480
#7 0x7eff7d032150 in QWindow::setVisible (this=0x1db66f0,
visible=optimized out) at kernel/qwindow.cpp:426
#8 0x7eff6c888d6a in QQuickPopupWindow::show
(this=this@entry=0x1db66f0)
at qquickpopupwindow.cpp:95
#9 0x7eff6c888579 in QQuickMenuPopupWindow::show (this=0x1db66f0)
at qquickmenupopupwindow.cpp:57
#10 0x7eff6c884efb in QQuickMenu::__popup (this=0x1bff2e0,
x=optimized out, y=optimized out, atItemIndex=0) at qquickmenu.cpp:403
#11 0x7eff6c897f53 in QQuickMenu::qt_static_metacall
(_o=_o@entry=0x1bff2e0,
_c=_c@entry=QMetaObject::InvokeMetaMethod, _id=_id@entry=22,
_a=_a@entry=0x7fff32b96550)
at .moc/moc_qquickmenu_p.cpp:227
#12 0x7eff6c898427 in QQuickMenu::qt_metacall (this=0x1bff2e0,
_c=QMetaObject::InvokeMetaMethod, _id=22, _a=0x7fff32b96550) at
.moc/moc_qquickmenu_p.cpp:330
There is some mention on the i.MX6 wiki page about multiple windows (
http://qt-project.org/wiki/i.MX-6), but that appears to be related to
mixing Quick views and widgets, which we are not doing. There also seems to
be an existing ComboBox bug (
https://bugreports.qt-project.org/browse/QTBUG-35989), but this looks
like it's quite different.
Any insight would be appreciated, I just wanted to do some further
investigation here before creating the bug report.
What version do you have? Looks like the combo box is trying to create
another window for the dropdown list, and we're not allowed to have more
than one window on eglfs. I don't think it should be doing that anymore on
platforms where it's not supported.
Forgot to reply-all on that last one, apologies:
Qt 5.2.1 (built from source off the git v5.2.1 tag), using this configure
line:
./configure -confirm-license -opensource -debug -system-sqlite
-openssl-linked \
-nomake examples -nomake tests -plugin-sql-psql
-plugin-sql-sqlite \
-eglfs -no-rpath -optimized-qmake -dbus-linked
-reduce-relocations \
-opengl es2 -directfb
Running on Arch Linux version 2013.03.01 in VirtualBox 4.3.10 r93012,
with the form:
./ourquickapp -platform eglfs
(same thing happens with 5.3 built from source, but this failed related
to a different issue related to unaddressable byes for ioctl, and only
works when run in valgrind)
Please let me know if there's any other information I can provide.
Matt
Shawn,
Can you tell me what I should be looking for to guarantee it's following
the correct code path? The combobox is indeed trying to create a new
window, as comboboxen are wont to do, and the crash is happening in this
code block:
qeglfswindow.cpp:80+
QEglFSScreen *screen = this-screen();
if (screen-primarySurface() != EGL_NO_SURFACE) {
if (isRaster() screen-compositingWindow())
return;
#if !defined(Q_OS_ANDROID) || defined(Q_OS_ANDROID_NO_SDK)
// We can have either a single OpenGL window or multiple raster
windows.
// Other combinations cannot work.
qFatal(EGLFS: OpenGL windows cannot be mixed with others.);
#endif
return;
}
Based on your previous email you said: I don't think it should be doing
that anymore on platforms where it's not supported, does that mean we
should be looking for a fix in the QML component code or the QPA code?
Looking for some insight here so we can help expedite the bug fix, or just
fix it ourselves.
Thanks,
Matt
Shawn,
I've gone ahead and created a bug report, it probably makes more sense to
continue the conversation there:
https://bugreports.qt-project.org/browse/QTBUG-38405
Matt
Re: [Development] QtQuickComponents ComboBox with QEglFSWindow
On Mon, Apr 14, 2014 at 7:07 AM, Rutledge Shawn shawn.rutle...@digia.comwrote: On 11 Apr 2014, at 10:15 PM, Matt Broadstone wrote: Hi, We're experiencing an odd crash while running our Qt Quick application in a VirtualBox session using eglfs on the framebuffer. The application works perfectly passing the '-platform eglfs' options, however, when we try to use a ComboBox we get a segfault/qFatal, with the resulting backtrace (only first twelve frames included for brevity): #0 0x7eff7c041389 in raise () from /usr/lib/libc.so.6 #1 0x7eff7c042788 in abort () from /usr/lib/libc.so.6 #2 0x7eff7c956895 in qt_message_fatal (context=..., message=...) at global/qlogging.cpp:979 #3 QMessageLogger::fatal (this=this@entry=0x7fff32b96030, msg=msg@entry=0x7eff7768e380 EGLFS: OpenGL windows cannot be mixed with others.) at global/qlogging.cpp:384 #4 0x7eff7766cfb7 in QEglFSWindow::create (this=this@entry=0x1db8030) at qeglfswindow.cpp:115 #5 0x7eff7766b60e in QEglFSIntegration::createPlatformWindow (this=optimized out, window=0x1db66f0) at qeglfsintegration.cpp:122 #6 0x7eff7d03180b in QWindow::create (this=this@entry=0x1db66f0) at kernel/qwindow.cpp:480 #7 0x7eff7d032150 in QWindow::setVisible (this=0x1db66f0, visible=optimized out) at kernel/qwindow.cpp:426 #8 0x7eff6c888d6a in QQuickPopupWindow::show (this=this@entry=0x1db66f0) at qquickpopupwindow.cpp:95 #9 0x7eff6c888579 in QQuickMenuPopupWindow::show (this=0x1db66f0) at qquickmenupopupwindow.cpp:57 #10 0x7eff6c884efb in QQuickMenu::__popup (this=0x1bff2e0, x=optimized out, y=optimized out, atItemIndex=0) at qquickmenu.cpp:403 #11 0x7eff6c897f53 in QQuickMenu::qt_static_metacall (_o=_o@entry=0x1bff2e0, _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=_id@entry=22, _a=_a@entry=0x7fff32b96550) at .moc/moc_qquickmenu_p.cpp:227 #12 0x7eff6c898427 in QQuickMenu::qt_metacall (this=0x1bff2e0, _c=QMetaObject::InvokeMetaMethod, _id=22, _a=0x7fff32b96550) at .moc/moc_qquickmenu_p.cpp:330 There is some mention on the i.MX6 wiki page about multiple windows ( http://qt-project.org/wiki/i.MX-6), but that appears to be related to mixing Quick views and widgets, which we are not doing. There also seems to be an existing ComboBox bug ( https://bugreports.qt-project.org/browse/QTBUG-35989), but this looks like it's quite different. Any insight would be appreciated, I just wanted to do some further investigation here before creating the bug report. What version do you have? Looks like the combo box is trying to create another window for the dropdown list, and we're not allowed to have more than one window on eglfs. I don't think it should be doing that anymore on platforms where it's not supported. Forgot to reply-all on that last one, apologies: Qt 5.2.1 (built from source off the git v5.2.1 tag), using this configure line: ./configure -confirm-license -opensource -debug -system-sqlite -openssl-linked \ -nomake examples -nomake tests -plugin-sql-psql -plugin-sql-sqlite \ -eglfs -no-rpath -optimized-qmake -dbus-linked -reduce-relocations \ -opengl es2 -directfb Running on Arch Linux version 2013.03.01 in VirtualBox 4.3.10 r93012, with the form: ./ourquickapp -platform eglfs (same thing happens with 5.3 built from source, but this failed related to a different issue related to unaddressable byes for ioctl, and only works when run in valgrind) Please let me know if there's any other information I can provide. Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtQuickComponents ComboBox with QEglFSWindow
Hi, We're experiencing an odd crash while running our Qt Quick application in a VirtualBox session using eglfs on the framebuffer. The application works perfectly passing the '-platform eglfs' options, however, when we try to use a ComboBox we get a segfault/qFatal, with the resulting backtrace (only first twelve frames included for brevity): #0 0x7eff7c041389 in raise () from /usr/lib/libc.so.6 #1 0x7eff7c042788 in abort () from /usr/lib/libc.so.6 #2 0x7eff7c956895 in qt_message_fatal (context=..., message=...) at global/qlogging.cpp:979 #3 QMessageLogger::fatal (this=this@entry=0x7fff32b96030, msg=msg@entry=0x7eff7768e380 EGLFS: OpenGL windows cannot be mixed with others.) at global/qlogging.cpp:384 #4 0x7eff7766cfb7 in QEglFSWindow::create (this=this@entry=0x1db8030) at qeglfswindow.cpp:115 #5 0x7eff7766b60e in QEglFSIntegration::createPlatformWindow (this=optimized out, window=0x1db66f0) at qeglfsintegration.cpp:122 #6 0x7eff7d03180b in QWindow::create (this=this@entry=0x1db66f0) at kernel/qwindow.cpp:480 #7 0x7eff7d032150 in QWindow::setVisible (this=0x1db66f0, visible=optimized out) at kernel/qwindow.cpp:426 #8 0x7eff6c888d6a in QQuickPopupWindow::show (this=this@entry=0x1db66f0) at qquickpopupwindow.cpp:95 #9 0x7eff6c888579 in QQuickMenuPopupWindow::show (this=0x1db66f0) at qquickmenupopupwindow.cpp:57 #10 0x7eff6c884efb in QQuickMenu::__popup (this=0x1bff2e0, x=optimized out, y=optimized out, atItemIndex=0) at qquickmenu.cpp:403 #11 0x7eff6c897f53 in QQuickMenu::qt_static_metacall (_o=_o@entry=0x1bff2e0, _c=_c@entry=QMetaObject::InvokeMetaMethod, _id=_id@entry=22, _a=_a@entry=0x7fff32b96550) at .moc/moc_qquickmenu_p.cpp:227 #12 0x7eff6c898427 in QQuickMenu::qt_metacall (this=0x1bff2e0, _c=QMetaObject::InvokeMetaMethod, _id=22, _a=0x7fff32b96550) at .moc/moc_qquickmenu_p.cpp:330 There is some mention on the i.MX6 wiki page about multiple windows ( http://qt-project.org/wiki/i.MX-6), but that appears to be related to mixing Quick views and widgets, which we are not doing. There also seems to be an existing ComboBox bug ( https://bugreports.qt-project.org/browse/QTBUG-35989), but this looks like it's quite different. Any insight would be appreciated, I just wanted to do some further investigation here before creating the bug report. Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Prettier printing of Unicode strings
On Mon, Jan 20, 2014 at 7:05 PM, Thiago Macieira thiago.macie...@intel.comwrote: I was writing a test today and QtTest told me: Actual (s) : ?12??? Expected (s2): ?12??? So I went, duh, ok, it looks the same to me but what's behind those question marks. After a bit of changes [https://codereview.qt-project.org/76100], it now prints: Actual (s) : \u221212\u20A0\uD800\uDC00 Expected (s2): \u221212\u20AC\uD800\uDC00 Which tells me what I got wrong. Ok to submit this change then? It will make all toString(QString) print - all backslashes as \\ - the following characters as their escape sequences: \r, \n, \t, \b, \f - all other control characters (including 0x7f) as \u00XX - all other characters with \u, including text otherwise readable in the terminal in the locale One major advantage of this is that it does not depend on the locale codec being set up or even working, as the previous code did. So we get consistent results even if there's a bug in that. Is this ok? +1 Should I also print quotes as \ ? And should I surround the string with quotes? Should I also do the same for QByteArray? Reading hex dumps isn't very nice. I think this would be great as well, but also if there was maybe an io manipulator to print the hex if you want to look at that as well. Ideally such a manipulator would print the whole hex, currently the hex printed for QByteArrays is truncated which in my experience makes it pretty useless in most cases.. Matt -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Friday, January 10, 2014, Tony Van Eerd wrote: There was some work going on inside BlackBerry to revamp QSystemStorageInfo. Last version I saw had: QDrive: - similar to QDir (not a QObject!). - construct from URI/path (ie dev/sda1 or D:\) - mount/unmount/is-it-mounted/list-of-mount-points/etc - total/available space QDriveWatcher: - QObject, constructed from a QDrive (or uri/path) - Signals when a particular drive is mounted/unmounted - also signals on activity-state changes (ie for SD Cards 'busy', etc) QDriveListWatcher - get list of drives - signal when drives are added/removed Maybe we can get it put up for review... Yes please :) Matt P.S. note that Windows (NTFS) now has real mount points, as well as D:,E:,... -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org javascript:; [mailto:development-bounces+tvaneerd javascript:;= rim@qt-project.org javascript:;] On Behalf Of Rutledge Shawn Sent: Friday, January 10, 2014 11:15 AM To: Lorn Potter; development@qt-project.org javascript:;; David Faure; Alan Alpert Subject: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground) On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote: On 02/03/13 07:59, Thiago Macieira wrote: On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. systeminfo works on all platforms, mobile or not. The udisks functionality would have to be removed if moved to core. I would like to at least have something like QSystemStorageInfo::logicalDrives() to use in building the QML FileDialog. (QDir::drives() provides drive letters on Windows but not mount points on Linux, which is asymmetric IMO.) The reason is to have similar functionality on operating systems which will rely on the QML FileDialog as on Windows and OSX: when you plug in a removable drive, or mount a network drive, there should be a shortcut to access it in the file dialog. So where should we start, and how much should we try to bring over in the first pass? Is anyone else interested in working on patches for that? If it doesn't have public QML API, that's OK for now, because I have some C++ support code for the dialogs anyway. But maybe we should try to bring back (and improve) some of the QML APIs too? ___ Development mailing list Development@qt-project.org javascript:; http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org javascript:; http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)
On Fri, Jan 10, 2014 at 1:31 PM, Konstantin Ritt ritt...@gmail.com wrote: https://codereview.qt-project.org/73945 I looked at this, but it lacks the extra functionality that Tony indicates is in their classes. Specifically, not just info about the drive/device, but the ability to mount/unmount the devices as well as the ability to watch for changes. In a perfect world it looks like his classes could be merged in, and modified to use the QDriveInfo class in this review. Matt Regards, Konstantin 2014/1/10 Matt Broadstone mbroa...@gmail.com On Friday, January 10, 2014, Tony Van Eerd wrote: There was some work going on inside BlackBerry to revamp QSystemStorageInfo. Last version I saw had: QDrive: - similar to QDir (not a QObject!). - construct from URI/path (ie dev/sda1 or D:\) - mount/unmount/is-it-mounted/list-of-mount-points/etc - total/available space QDriveWatcher: - QObject, constructed from a QDrive (or uri/path) - Signals when a particular drive is mounted/unmounted - also signals on activity-state changes (ie for SD Cards 'busy', etc) QDriveListWatcher - get list of drives - signal when drives are added/removed Maybe we can get it put up for review... Yes please :) Matt P.S. note that Windows (NTFS) now has real mount points, as well as D:,E:,... -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Rutledge Shawn Sent: Friday, January 10, 2014 11:15 AM To: Lorn Potter; development@qt-project.org; David Faure; Alan Alpert Subject: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground) On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote: On 02/03/13 07:59, Thiago Macieira wrote: On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote: Wasn't there already similar functionality in QtMobility? QSystemStorageInfo seems to provide similar functionality? Yes it does. Or did all that get scrapped in Qt 5? It's there in qtsystems, which is a hidden module. As I said before when QSystemStorageInfo came about, I think the functionality belongs in QtCore. With less emphasis in QML and mobile, of course. systeminfo works on all platforms, mobile or not. The udisks functionality would have to be removed if moved to core. I would like to at least have something like QSystemStorageInfo::logicalDrives() to use in building the QML FileDialog. (QDir::drives() provides drive letters on Windows but not mount points on Linux, which is asymmetric IMO.) The reason is to have similar functionality on operating systems which will rely on the QML FileDialog as on Windows and OSX: when you plug in a removable drive, or mount a network drive, there should be a shortcut to access it in the file dialog. So where should we start, and how much should we try to bring over in the first pass? Is anyone else interested in working on patches for that? If it doesn't have public QML API, that's OK for now, because I have some C++ support code for the dialogs anyway. But maybe we should try to bring back (and improve) some of the QML APIs too? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
On Tue, Nov 5, 2013 at 10:56 AM, Sorvig Morten morten.sor...@digia.comwrote: On 02 Nov 2013, at 17:58, Thiago Macieira thiago.macie...@intel.com wrote: On quarta-feira, 30 de outubro de 2013 07:29:56, Turunen Tuukka wrote: We should have the applications made with Qt 4.8.5 on Mac OS 10.7 (for example) working in 10.9 without serious issues. And we should be able to agree together what is a serious enough issue to take the risk with 5.2 getting delayed due to making of 4.8.6. One option is to make a patch available and ask users to build themselves. I'm getting complaints from our Subsurface devs on Mac that 4.8.5 is utterly broken there. Does anyone know what patches have already been applied to 4.8.6 that are needed for Mavericks support? What the outstanding issues are, if any? We have a couple of patches in flight: Applied: https://codereview.qt-project.org/#change,69325 (corewlan compile fix) Pending: https://codereview.qt-project.org/#change,69327 (colorspace related performance regression, Shawn is handling this one) https://codereview.qt-project.org/#change,69328 (Webkit compile fix - help needed by webkit expert) https://codereview.qt-project.org/#change,70097 (Correct system font) QTBUG-34107 (qfiledialog sandboxing issue) (Qt 5 patch: https://codereview.qt-project.org/#change,70382) Cool, I've been in touch with the macports patch author and he submitted a number of his patches this morning for review. I'm sure they overlap, but perhaps there are changes there that could help as well (I haven't reviewed any of them yet): https://codereview.qt-project.org/#change,70443 https://codereview.qt-project.org/#change,70442 https://codereview.qt-project.org/#change,70441 https://codereview.qt-project.org/#change,70440 https://codereview.qt-project.org/#change,70439 https://codereview.qt-project.org/#change,70438 https://codereview.qt-project.org/#change,70437 https://codereview.qt-project.org/#change,70444 Cheers, Matt Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
On Mon, Nov 4, 2013 at 8:20 AM, Konrad Rosenbaum kon...@silmor.de wrote: On Monday 04 November 2013 11:46:35 Oswald Buddenhagen wrote: On Sun, Nov 03, 2013 at 06:49:17AM -0800, Thiago Macieira wrote: We can't even click the link. If we read their patches, we can't write the same later. that's nonsense. any simple patch is not subject to copyright (though it's still good tone to credit the investigator). and anything complex enough is likely to produce a slightly different patch anyway, even after seeing the other patch. that's what copyright is about in the first place: protecting *creative* works. I hate to be so negative, but... Oswald what you are describing is the spirit of copyright. How it is supposed to work. What Thiago is describing is how it works (or often doesn't) in reality. As soon as you see a copyright lawyer in the room: run like hell! It won't help, but it gives you a nice fuzzy feeling of being ahead one step... ;-) (IANAL) Konrad Well, whatever the legal situation is I surely wasn't implying that we just take his work :) Whether or not the quality level is up to par if another question, and surely something that could be resolved through review. I've been in touch with the author and will help him submit the patches to upstream for the code he wrote himself. There are a few patches that were taken from a WebKit dev branch, so perhaps some of those can be merged in directly? (maintainers page still lists Simon as qtwebkit maintainer, but I believe it's Allan now, perhaps one of them can speak to this point). Either way, I think this would be a pretty significant inclusion for a 4.8.6 release, is there a timeline for this yet? Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 4.8.6 Release Plans
On Sat, Nov 2, 2013 at 12:58 PM, Thiago Macieira thiago.macie...@intel.comwrote: On quarta-feira, 30 de outubro de 2013 07:29:56, Turunen Tuukka wrote: We should have the applications made with Qt 4.8.5 on Mac OS 10.7 (for example) working in 10.9 without serious issues. And we should be able to agree together what is a serious enough issue to take the risk with 5.2 getting delayed due to making of 4.8.6. One option is to make a patch available and ask users to build themselves. I'm getting complaints from our Subsurface devs on Mac that 4.8.5 is utterly broken there. Does anyone know what patches have already been applied to 4.8.6 that are needed for Mavericks support? What the outstanding issues are, if any? I've been loosely following the macports effort to port 4.8.x to Mavericks over here: http://trac.macports.org/ticket/40852. It seems like their changes are working, I can maybe see if I can convince them to push upstream to gerrit. Matt -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ML for QtWebEngine
On Tue, Oct 15, 2013 at 10:57 AM, Pierre Rossi pierre.ro...@gmail.comwrote: Hi, On Fri, Oct 4, 2013 at 4:56 PM, Albisser Zeno zeno.albis...@digia.comwrote: Hi, I would like to request a separate mailing list for the QtWebEngine project. We receive more and more direct emails and messages on irc from people, asking where to subscribe to. The content of that mailing list will be rather specific to the development of the QtWebEngine project. And as it is not a core component of Qt, i think a separate mailing list would be appropriate. Thanks, - Zeno ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Any updates on this ? It's a question I've had from several people at devdays and I think it would make sense for the typical bike shedding that would just add noise to the Dev mailing list for no good reason. Should we have anything to say that seems worthy of Development, I'm sure it will still find its way back here. Just my 2¢... Cheers, -- Pierre Not that I am really interested in debating such a decision, but I'm not quite sure I see the noise you guys are referring to. I've been signed up to the webkit-qt ML for some time and it's basically just a spam service for status meeting bot messages (which at this point conveys very little information). Is there a secret place where a bunch of emails regarding qt webkit and webegine are ending up? Barring the existence of that, why not just keep the discussions on this list and keep the whole community involved until such a day arises that it really does become too much to handle here? I, for one, support a path forward where I don't have to sign up for another ML, and make yet another filter for my inbox ;) Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ML for QtWebEngine
On Tue, Oct 15, 2013 at 11:27 AM, Zeno Albisser zeno.albis...@digia.comwrote: Once again from the correct address. On Oct 15, 2013, at 5:06 PM, Matt Broadstone mbroa...@gmail.com wrote: Not that I am really interested in debating such a decision, but I'm not quite sure I see the noise you guys are referring to. I've been signed up to the webkit-qt ML for some time and it's basically just a spam service for status meeting bot messages (which at this point conveys very little information). Is there a secret place where a bunch of emails regarding qt webkit and webegine are ending up? Barring the existence of that, why not just keep the discussions on this list and keep the whole community involved until such a day arises that it really does become too much to handle here? I, for one, support a path forward where I don't have to sign up for another ML, and make yet another filter for my inbox ;) You might understand, that many people feel quite reluctant to send an email to a list that goes to hundreds of people instead of the relatively small amount of people that actually has a real interest in the project. The threshold for asking a question or sharing some feedback is higher. Sure, but that's just how open source works, right? I think we foster a pretty good vibe on these MLs, people shouldn't be afraid to ask here. So instead of sending a mail, a lot of these discussions are currently just happening in our irc channel where people cannot easily read up on a discussion at all. - I don't think that's something you would be arguing for in favor. You used to be in #qtwebengine yourself as well some time ago. That is the secret place where the information is currently going. I don't think people are asking questions on irc because they are afraid of the big bad qt mailing list, I think it's because they can get your attention more immediately and discuss issues in real time. Also, if you consider the current webkit-qt ML spam, then you would probably not want that on the dev ML either. Well yes, if what you are proposing is that you are going to have a weekly status bot then certainly I don't think that belongs on this list. I consider the webkit-qt ML spam because it isn't actually being used at all (maybe realistically = 10 emails a month from an actual user, not the status bot, and that's generous). What I'm really getting at is that I think we're kidding ourselves if we think that a webkit binding in whatever incarnation isn't a core offering of Qt, and that such discussions (until it actually does overwhelm the list) should remain as accessible as possible. But it does not make sense to reason about traffic on qtwebkit. These are separate projects and we do obviously not discuss qtwebengine on the qtwebkit mailing list. Because there you would not expect it for sure. - Zeno Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] potential bug with qml context properties
On Fri, Sep 20, 2013 at 9:57 AM, Matt Broadstone mbroa...@gmail.com wrote: Hi, I'm running into a strange error related to context properties in qml. Basically, I'm trying to expose a QQmlPropertyMap into the context of my QQmlApplicationEngine, and within the qml set up a recursive binding so that changes to that map from C++ are expressed in qml, and vica versa. This was not difficult to achieve, however, I keep getting ReferenceErrors stating that the context property is not defined (even though setting singleshot timer to change the map indeed reflects a change in the qml scene), not to mention a slightly less annoying (but annoying nonetheless) warning that I've set up a recursive binding. I'm wondering if this is a bug, or if I'm just doing something wrong. I have a very simple example of what I'm trying to do posted on these two pastebins, if someone has a second to take a look that'd be great: (c++) http://pastebin.com/S7XeYHEG (qml) http://pastebin.com/THsPsVkM Any follow up on this from the qml guys? Should I be targeting a qml specific ML? Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QValidator in QtCore
On Sun, Sep 22, 2013 at 5:28 PM, Olivier Goffart oliv...@woboq.com wrote: On Saturday 21 September 2013 19:13:41 Thiago Macieira wrote: On domingo, 22 de setembro de 2013 02:21:40, Konstantin Ritt wrote: I remember some classes were moved from QtXml to QtCore without breaking the compatibility. Am I wrong? The moving did break compatibility. Which is why for Mac 32-bit builds, the classes aren't moved at all: we added new classes to QtCore and typedef'ed. That only broke source compatibility because you couldn't forward-declare those classes. The name change was done using #define QXmlStreamWriter QCoreXmlStreamWriter There is a comment saying it was done using typedef, but apparently it was not. http://code.woboq.org/kde/qt4/src/corelib/xml/qxmlstream.h.html So compatibility was not broken (but there was ugly macro) I think this prove that this is possible. (And for forward declaration, i think we should have header with them and forbid them) I've sort of revised my stance here: I'm more on the side of proposing a useful alternative than moving it at this point. Not only should QValidator be in QtCore, it also is needlessly defined as a QObject. Beyond that, it only validates strings (rather than QVariants), so I think through and through a better alternative could be provided. I'm working on something now (well its done but I'm mostly massaging the api and seeing how it feels to use in my code), I'll put it up for review when it's complete. Matt -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] potential bug with qml context properties
Hi, I'm running into a strange error related to context properties in qml. Basically, I'm trying to expose a QQmlPropertyMap into the context of my QQmlApplicationEngine, and within the qml set up a recursive binding so that changes to that map from C++ are expressed in qml, and vica versa. This was not difficult to achieve, however, I keep getting ReferenceErrors stating that the context property is not defined (even though setting singleshot timer to change the map indeed reflects a change in the qml scene), not to mention a slightly less annoying (but annoying nonetheless) warning that I've set up a recursive binding. I'm wondering if this is a bug, or if I'm just doing something wrong. I have a very simple example of what I'm trying to do posted on these two pastebins, if someone has a second to take a look that'd be great: (c++) http://pastebin.com/S7XeYHEG (qml) http://pastebin.com/THsPsVkM Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QValidator in QtCore
Is it crazy/impossible to propose moving the QValidator class from QtGui to QtCore? I know it was initially designed for validating widgets, however I have a project right now (an ORM) that could very much benefit from these classes. It doesn't seem that the implementation depends on QtGui at all, but I'm a bit unclear what this would mean wrt BC/SC. Anyway, just a thought, figured someone would have a good answer. Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature] Q_INFO: Annotations for classes, methods, properties and enums
On Wed, Sep 11, 2013 at 2:33 AM, Olivier Goffart oliv...@woboq.com wrote: Hi, Great to see we are making progress. On Tuesday 10 September 2013 18:26:09 Stefan Merettig wrote: Alright guys, let's try to complete the feature. As I heard from sides now that you want a key-value store, I'll do it that way. Feature list: 1. Q_INFO is a new macro (which expands to nothing): #define Q_INFO(key, value) Since we have Q_CLASSINFO for classes. maybe we should call it Q_METHODINFO and apply it only for method. Then, for Q_PROPERTY, use a INFO as a keyword within the Q_PROPERTY syntax. I think it is easier to read. Let us compare again: Q_INFO(foo, bar) Q_PROPERTY(int bar READ bar) Q_INFO(foo, baz) Q_PROPERTY(int baz READ baz) Q_PROPERTY(int bar READ bar INFO foo = bar) Q_PROPERTY(int baz READ baz INFO foo = baz) I think this is too verbose. If we're already headed towards java-style annotations why not just have an annotate that can align with a Q_PROPERTY: Q_PROPERTY(int bar READ bar WRITE setBar) (this gives us a good, clear definition of the property) Q_ANNOTATE(bar, foo = baz, abc = cde) (this annotates the aforementioned property, and is a specialization of the normal Q_ANNOTATE, and can appear anywhere in the class definition) Matt You see the property name (more important) before the info. and everything is together. Then for enums, we can have Q_ENUMS(MyEnum MyOtherEnum INFO foo = bar) That would only be a problem if there is an enum called INFO, but i think we are safe, it is not the Qt style. Then we have everything, with nice syntax. 2. Q_INFO can be prepended to: - Classes - Signals, slots and Q_INVOKABLE methods (This includes c'tors) - Q_PROPERTY - Q_ENUM'd enums - So everything that is accessible through the meta system 3. Multiple Q_INFO annotations for a single object are possible 4. Each object has a unique key - value mapping. This means, that something like: Q_INFO(a, b) Q_INFO(a, c) void myFunc(); results in a single key - value mapping, not two values for a. 5. API Design: Pretty much a copy of QMetaClassInfo from the user standpoint, the class will be called QMetaInfo. Questions: 1. If Q_INFO can be applied to classes, then it's redundant to Q_CLASSINFO. On the one hand it's nice to have a unified API for annotations, on the other hand it's redundant, as Q_INFO doesn't have any benefits over Q_CLASSINFO anymore. 2. How should we store this? My current approach still stems from when Q_INFO supported multiple arguments. Technically possible, but not liked. As Thiago pointed out: JSON is out of the question. I'd like to stick to something like my current implementation. It boils down to having a table in the meta_data I beleive that Thiago meant that JSON was out of question for describing the properties in the actual source. But i would not necessarily rule it out for storing the data. moc already export some data using Qt's binary JSON, so this is still a valid option. That said, I think that having the info stored in the meta_data table, like Q_CLASSINFO is, is just fine. array with two columns for each object: start index, count At 'start index' there's a list of two integers for each Q_INFO record, the first pointing to the name, the second to the value. I'd like to use a third column there to store a currently unused flag. In my initial implementation which is also on gerrit I have a fourth field to store the value count, but with only a single one this can obviously be dropped if we don't plan to ever support this feature. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A QtCore class for event-driven jobs
On Fri, Sep 6, 2013 at 1:52 PM, David Faure david.fa...@kdab.com wrote:
I would like to propose the inclusion of a QJob class in QtCore, based on
years of experience with KIO::Job and KJob.
The idea is to encapsulate an event driven asynchronous operation into a
job
class. Example use cases:
- a network download with QNetworkAccessManager.
- operations (command+reply) over a QLocalSocket or QTcpSocket (like
akonadi).
- long async dbus calls (special case of the previous line)
- long tasks executed by external processes (e.g. make from an IDE,
unrar
from an archive program)
...
At the core, QJob is really just a class with start() and kill(), calling
pure
virtual methods doStart() and doKill(), and signals, most importantly the
result(QJob *) signal.
The expected use case is:
void SomeClass::methodWithAsynchronousJobCall()
{
QJob* job = someoperation(some parameters);
connect(job, SIGNAL(result(QJob*)),
this, SLOT(handleResult(QJob*)));
job-start(); // or it could just autostart, which I actually prefer...
}
(other connects, specific to the job)
And handleResult is usually at least:
void SomeClass::handleResult( QJob *job )
{
if (job-error()) {
// handle error
} else {
// handle succesful job completion, if needed
}
}
But it can and should also have the following features:
* error code, error text
* suspend/resume with doSuspend/doResume virtual methods
* capabilities Killable and Suspendable, to avoid trying these on jobs that
don't support them
* kill(Quietly) vs kill(EmitResult), for the app's convenience
* a finished signal that is emitted with both types of killing, for things
like progress dialogs
* auto-deletion (on by default, can be turned off)
* synchronous exec() using a QEventLoop, with a big fat huge warning about
not
using that in GUI apps (ideally only to be used in unittests or separate
threads).
* more standard signals for progress info, messages, warnings..
The whole point of standardizing such signals is that it allows generic
GUIs
to be built on top, so that your app or your desktop can show the progress
of
multiple concurrent jobs, of different types (file download, CD burning,
mail
checking, etc. etc.)
Finally, for the benefit of job implementors, QJob would support sub-jobs.
The job implementation would choose when to create these subjobs (all at
once
initially, to have them run in parallel, or one after the other, for
sequence
of operations). KDE currently does that in a subclass (KCompositeJob) but
Thiago and I (and kio, and akonadi) agree that it's better to have it all
in
one class instead.
We also have a standard interface for error handling so that all jobs from
a
given framework can have their error handled the same way, but thinking
about
it, that part could stay separate, at least for now.
Well, that's it. So why this email? Because Thiago asked me to, and to
gather
some support. I plan to make a merge request for Qt 5.2.
Thiago asked more specifically:
* API-wise, can't this be merged with QFuture?
- no, because QFuture encapsulates a value, with blocking methods for
getting
the value, even available as casting-to-the-value. If we imagine a QFuture
that wraps a QJob, and the blocking method calling exec(), we'd have a lot
more nested event loops than is good for the health of our programs.
On the other hand, QJob would not be related to any value. It's really a
QObject that informs of progress via signals.
* relation to QRunnable?
A runnable is also some sort of job, but the implementation is completely
different: a runnable is one sync method, while a qjob is all signals/slots
based, with start() returning immediately. So one can't be used like the
other, a given task implementation is either a blocking task for a thread
with
no event loop (QRunnable) or an async task that can actually be used in any
thread with an event loop.
* relation to QNetworkReply?
If that one didn't exist yet, we'd definitely write it as a QJob subclass.
So
instead, I propose to wrap QNetworkReply into a QNetworkJob or something,
in
order to offer the QJob interface for QNAM requests. On one hand this
doesn't
have to go in at the same time as QJob itself, but OTOH it could be a real-
world testcase for it, proving its usefulness and correctness...
Any other questions?
+1, or more if possible :)
Is this code up somewhere already for early review? This is very much
needed in Qt imho, I imagine it's one of those patterns that people roll
themselves in many cases.
Matt
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
Re: [Development] [API Review Request] QWebsockets
On Sun, Aug 25, 2013 at 3:49 PM, Kurt Pattyn pattyn.k...@gmail.com wrote: Hi, I am about to move the QWebSockets project (see: http://github.com/KurtPattyn/QWebSockets) to the playground. Could you please review the API? Just some quick stylistic observations: * you don't usually make a class_p.cpp (implementation) file, you only need to do that for the header so that you don't export those symbols * looks like you are using tabs all over the place * I think it's part of the style guide to use the Q_D and Q_Q macros to access your classes d and q pointers, respectively. * imho a lot of this code could be squashed together so as to reduce the number of files: - qwebsocketprotocol can just go into the global header, since it just defines some enums - classes like DataProcessor and HandshakeResponse could probably just move to the implementation of QWebSocket * unit tests are woefully incomplete, also you seem to be running qtestlib manually.. I would suggest taking a look at Qts test dir or something like it for inspiration here (many folders with a set of tests in them). This part is probably going to be most difficult, as you'll be writing tests after you've seemingly completed the implementation. Cheers, Matt Notes: 1. The public API is QWebSocket and QWebSocketServer; all other classes are internal. The APIs of both classes were modelled after QAbstractSocket and QTcpServer. This should it make easier to use the API. 2. I have also tried to make the directory structure compliant with the Qt guidelines; so, if there are any mistakes, it would be good to know as well 3. I created a qdocconfig file, but it misses links to the Qt library classes 4. The sync.profile has been created by looking at the QtSerialPort project, but I am not sure if that is correct as well 5. Unittests still need work to be up to the Qt standards Thanks for your time. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature Request] Websockets
On Sat, Aug 17, 2013 at 4:17 AM, Kurt Pattyn pattyn.k...@gmail.com wrote: Well, it is a fact that Qt has little to no native support for 'cloud' based client and server 'protocols', like REST, WebSockets, SOAP, aso. So, it would indeed be a nice addition to have support for the most popular 'protocols'. Should we have something like a QNetworkAccessManager with pluggable protocols, or do we create a protocols module with just independent classes? I prefer the latter but the classes should at least have some consistent API. Frankly, I'm of a mind that we just take the existing projects and put them in the module at least for starters. Sure, it would probably be pretty cool to have some sort of unified system, but we're not going to make that anytime soon. Furthermore, at least in qjsonrpc/qxmpp/kdsoap's case, these are pretty mature projects, and I would hate to see a lot of wheel re-inventing just for the sake the grand unified vision. I'm also a bit of a mind that the grand unified protocol idea might be a bit of a red herring: what parts of these systems do we in fact need to share? QIODevice, Q[Udp/Tcp][Server/Socket], maybe some data streams, json/xml parsers, these are all provided by Qt. My goal with suggesting that we put these into a module together is twofold: first, centralize the development of these solutions and hopefully attract developers to work on these instead of rolling their own (case in point, Christian's first email cites that he's interested in a JSON based protocol that could go through a QIODevice, well hey isn't that qjsonrpc?). Secondly, to provide the opportunity for a more rigorous peer review of the code from this great development community. Matt On 16 Aug 2013, at 19:10, Matt Broadstone mbroa...@gmail.com wrote: On Thu, Aug 15, 2013 at 6:59 PM, Christian Gagneraud chg...@gna.orgwrote: On 16/08/13 03:41, Matt Broadstone wrote: On Wed, Aug 14, 2013 at 11:54 AM, Kurt Pattyn pattyn.k...@gmail.com mailto:pattyn.k...@gmail.com wrote: Hi, I opensourced a Qt based module that implements the web socket protocol. The repository can be found here: https://github.com/KurtPattyn/QWebSockets. I have 2 questions: 1. Is there any interest in adding this to Qt? 2. If so, should this be added to QtNetwork or is a add-on preferred? Perhaps it would be best to have something like a qtprotocols addon. I'm also interested in maybe getting qjsonrpc pushed upstream to the qt-project, there has been some interest in the community and I think it could benefit from more eyes on it. I'm also in the process of writing a somewhat more streamlined STOMP client for qt that could live there as well. Are you talking about https://bitbucket.org/devonit/qjsonrpc ? The nice thing if the 2 projects belongs to the same addon is that they can use each other, right? In that case, it would be possible to add a QJsonRpcWebsocketServer without adding external dependencies. Yes I am. Sure, they could use each other but I'm not sure how much you gain there. I haven't really looked into the websocket standard, but I'm not sure it shares many similarities with jsonrpc, please correct me if I'm wrong. I was simply suggesting that there seem to be a number of protocol implementations for Qt and they might be best served grouped in a new addon module (qjsonrpc, qwebsockets, qstompclient, qxmpp, etc). Matt My 2 cents, Chris Thoughts? Matt Best regards, Kurt Pattyn ___ Development mailing list Development@qt-project.org mailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature Request] Websockets
On Thu, Aug 15, 2013 at 6:59 PM, Christian Gagneraud chg...@gna.org wrote: On 16/08/13 03:41, Matt Broadstone wrote: On Wed, Aug 14, 2013 at 11:54 AM, Kurt Pattyn pattyn.k...@gmail.com mailto:pattyn.k...@gmail.com wrote: Hi, I opensourced a Qt based module that implements the web socket protocol. The repository can be found here: https://github.com/KurtPattyn/QWebSockets. I have 2 questions: 1. Is there any interest in adding this to Qt? 2. If so, should this be added to QtNetwork or is a add-on preferred? Perhaps it would be best to have something like a qtprotocols addon. I'm also interested in maybe getting qjsonrpc pushed upstream to the qt-project, there has been some interest in the community and I think it could benefit from more eyes on it. I'm also in the process of writing a somewhat more streamlined STOMP client for qt that could live there as well. Are you talking about https://bitbucket.org/devonit/qjsonrpc ? The nice thing if the 2 projects belongs to the same addon is that they can use each other, right? In that case, it would be possible to add a QJsonRpcWebsocketServer without adding external dependencies. Yes I am. Sure, they could use each other but I'm not sure how much you gain there. I haven't really looked into the websocket standard, but I'm not sure it shares many similarities with jsonrpc, please correct me if I'm wrong. I was simply suggesting that there seem to be a number of protocol implementations for Qt and they might be best served grouped in a new addon module (qjsonrpc, qwebsockets, qstompclient, qxmpp, etc). Matt My 2 cents, Chris Thoughts? Matt Best regards, Kurt Pattyn ___ Development mailing list Development@qt-project.org mailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QScopedPointer and QObjects
Hey all,
I've found more often than I'd like in my unit tests I'm writing a custom
deleter for QObjects when using a QScopedPointer. Something to the effect
of:
struct QObjectDeleter
{
static inline void cleanup(QObject *pointer) {
if (pointer)
pointer-deleteLater();
}
};
and then:
QScopedPointerMyQObjectSubclass, QObjectDeleter object;
Is there a reason this wasn't added for convenience? Or, would there be
interest in me submitting a patch to include this in a later version of Qt?
We should even be able to fix this seamlessly with templates unless I'm
mistaken.
Regards,
Matt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QJsonDocument formatting
Hello, I'd like to propose a new method added to the QJsonDocument class: QJsonDocument::toFormattedJson(int indent, bool compact) QJsonPrivate::Writer currently supports these features but unfortunately there is no way to get to it from the public API. Ideally, these options would be available to us in the toJson() method, but I understand that we are dealing with BC issues in the 5.x tree now. So I have two questions: a) are there any immediate objections to adding this b) is it likely that we can get this in for the 5.1 release? Barring any issues I can have a patch on code review asap. Regards, Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QJsonDocument formatting
On Sun, Mar 3, 2013 at 4:26 PM, Thiago Macieira
thiago.macie...@intel.comwrote:
On domingo, 3 de março de 2013 16.19.17, Matt Broadstone wrote:
I'd like to propose a new method added to the QJsonDocument class:
QJsonDocument::toFormattedJson(int indent, bool compact)
Too late. It's already there.
enum JsonFormat {
Indented,
Compact
};
QByteArray toJson() const; //### Merge in Qt6
QByteArray toJson(JsonFormat format) const;
Oh, awesome :)
Matt
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
On Wed, Nov 28, 2012 at 11:11 AM, BRM bm_witn...@yahoo.com wrote: From: BRM bm_witn...@yahoo.com Sent: Monday, November 26, 2012 9:39 PM Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support From: Matt Broadstone mbroa...@gmail.com Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support On Mon, Nov 26, 2012 at 1:48 PM, BRM bm_witn...@yahoo.com wrote: From: Charley Bay charleyb...@gmail.com Is there any word on whether you guys get a spot in playground? Since Thiago +1'd, I think I'm good...so I've posted the bug to Jira for it per http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#6a17de784cf6db9124e9844959ec8ace As I know others have expressed interest in helping out, here's the bug report in case you want to join/watch: https://bugreports.qt-project.org/browse/QTQAINFRA-584 Ben Does it usually take this long? I understand the RC is being released, but it doesn't seem like it should take two weeks to get approval for a space in playground. Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Updating Daemon/Service Support
On Mon, Nov 26, 2012 at 1:48 PM, BRM bm_witn...@yahoo.com wrote: From: Charley Bay charleyb...@gmail.com On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone mbroa...@gmail.com wrote: On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay charleyb...@gmail.com wrote: snip, updating the QtService Component , I would like to open a new Qt Playground project to create a new equivalent +1 IMHO this would be a cross-platform useful module that I'd vote to ultimately end-up within Qt-proper. Disclosure: I traded emails with BRM off-list, and would like to help. --charley Would you guys like to get into your design a little here? Did you mean that you would be creating two classes: QCoreService/QGuiService (though I'm not sure why one would want a gui service, maybe to use some of the graphics classes?). Also, could you speak to your ideas for the pluggable backend? Will you target systemd as a reference implementation? Matt [UPDATE], I was typing this while BRM responded. Read his email, it's a more specific design-ideas answer. However, I'll still reply with this email, since it talks about other higher-level issues-to-be-resolved, and brings the discussion current with what this proposed-playground is to do. [...what follows is what I was typing when BRM responded...] I'm second-seat (Ben/BRM is taking the lead). I defer to Ben/BRM for any corrections needed from malicious dis-information created as a result of this email, but here's a bullet-list of early thoughts: TODAY: (a)- The existing QtService is an add-on (not in Qt-proper), but people use it, and it serves a purpose to help provide a cross-platform service/daemon application API. (b)- The existing QtService works for Qt4x (likely needs-work to support Qt5) GOAL: After this effort, the result could be considered as a Qt5+ add-on for cross-platform service/daemon support, and possibly considered for inclusion in a future Qt release (e.g., perhaps Qt5.1+) POSSIBLE ISSUE: An unfortunate name collision (or user-confusion) is possible with class names created from this effort to provide a cross-platform service/daemon API, and those classes within the Qt Service Framework (which has a different purpose). Note: Only the use of the QtService /QService name would have such collision. That is why the new API would be DaemonApplication (QDaemonApplication), as discussed previously on the mailing lists. Ben thoughts: a) I think the only reason the old QtService uses a template based approach is to support the different types of Q*Application. It would be quite useful to have someone who worked on the original solution discuss why they went with this approach rather than subclassing Q*Application. I imagine with a subclass approach you would solve a lot of your cleanup problems as well. b) Not sure what you guys are talking about with IPC/QLocalSocket, this seems beyond the scope of these classes c) I believe Service was used originally because it corresponds to the windows world-view of daemons/services (it also explains why the class itself seems to be more of a fair player on windows rather than *nix). The renaming is fine, but I guess you are committing the reverse sin here. d) at this point talk is cheap, show me the code! :) Is there any word on whether you guys get a spot in playground? Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
