Re: [Development] C++11 and QtWebkit in 5.2.0
On Friday 20 December 2013, Thiago Macieira wrote: > On sexta-feira, 20 de dezembro de 2013 12:57:46, Allan Sandfeld Jensen wrote: > > WebKit is recommended to compiled with C++11, compiling without C++11 is > > only meant for platforms without working C++11 support (gcc 4.2 in Mac > > OS 10.6). > > This is not a case of recommended. The use of >> makes C++11 mandatory. > > This code is in a OS(WINDOWS) section. Yes, I agree it is a bug and should be fixed. I was only correcting the first poster's assumption that QtWebKit shouldn't be compiled with C++11. The branch of Webkit used in Qt 5.2 was C++11 only when branched, and the use of C++11'ism were carefully reverted (except those I obviously missed) in order to be able to support OS X 10.6 gcc 4.2. If that platform had not been necessary, I would have kept QtWebKit C++11 only, to keep it closer to upstream WebKit. `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt's Leak-on-exit policy
On Dec 18, 2013, at 7:17 PM, Andreas Hartmetz wrote: > 2) reminds me of a crazy idea I've had once... freeing memory (not > object destruction!) at application exit really serves no other purpose > than making leak checkers happy. Not saying that this isn't an > important goal, btw. So shutdown could be accelerated by putting > free() into a special shutdown mode that just immediately returns. > Of course there would be a conditional branch somewhere, unless you > modified the GOT entry for free() or something. That would add a > runtime overhead, which is worse than slightly slower shutdown. It would warrant some investigation how the time spent in `free()` or `operator delete` compares to the time spent in the destructors proper. The memory allocator is probably optimized there and back again. Destructors - probably not very much, unless they are in short-lifetime, oft-destructed classes. Cheers, Kuba ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature Request] Add QtWebSockets to Qt
I don't know who gets an "official" vote but I am in favor of making QtWebSockets part of the official Qt repository and would like to see it included in the next 5.2.1 release. Since I consider it to be 'Qt-worthy' but almost 'QML-worthy', I recommend that a public Q_INVOKABLE disconnect() method be added to the QQmlWebSocket class with error handling and that error handling be improved in the setUrl, open, close and setTextMessage methods, among others. These methods could return a bool value, use try/catch or a combination. Let me know what you think of these suggestions. Thanks. Steve -Original Message- From: Kurt Pattyn Sent: Friday, December 20, 2013 5:07 PM To: development@qt-project.org Subject: [Development] [Feature Request] Add QtWebSockets to Qt Hi, I propose to move QtWebSockets from the playground (https://qt.gitorious.org/qtplayground/websockets/) to the official Qt repository as an add-on. As there is a need for a websockets implementation in Qt (see https://bugreports.qt-project.org/browse/QTBUG-26300 and https://bugreports.qt-project.org/browse/QTBUG-26298), QtWebSockets could be a welcome addition. The module only depends on Qt (core and network, and Qml for the Qml component). It supports the ws and wss schemes, and can be used as a client and server component. The API is modelled after QAbstractSocket and QTcpSocket, and hence should be familiar for Qt developers. The Qml module has been reviewed by Alan Alpert, and is considered 'QML-worthy'. Currently, the module builds as a Qt add-on, and can be used by adding QT += websockets. QtWebSockets passes the Autobahn Testsuite (see http://autobahn.ws/testsuite/), has extensive unit tests, and builds successfully on the Qt CI infrastructure. Performance has also been tested with AutoBahn TestSuite, and is up-to-par with all current browsers and websocketpp (even slightly faster). Please cast your votes. Cheers, Kurt ___ 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] [Feature Request] Add QtWebSockets to Qt
Hi, I propose to move QtWebSockets from the playground (https://qt.gitorious.org/qtplayground/websockets/) to the official Qt repository as an add-on. As there is a need for a websockets implementation in Qt (see https://bugreports.qt-project.org/browse/QTBUG-26300 and https://bugreports.qt-project.org/browse/QTBUG-26298), QtWebSockets could be a welcome addition. The module only depends on Qt (core and network, and Qml for the Qml component). It supports the ws and wss schemes, and can be used as a client and server component. The API is modelled after QAbstractSocket and QTcpSocket, and hence should be familiar for Qt developers. The Qml module has been reviewed by Alan Alpert, and is considered 'QML-worthy'. Currently, the module builds as a Qt add-on, and can be used by adding QT += websockets. QtWebSockets passes the Autobahn Testsuite (see http://autobahn.ws/testsuite/), has extensive unit tests, and builds successfully on the Qt CI infrastructure. Performance has also been tested with AutoBahn TestSuite, and is up-to-par with all current browsers and websocketpp (even slightly faster). Please cast your votes. Cheers, Kurt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QWidget mouse events - different order
On 12/20/2013 02:05 AM, Martin Koller wrote: > On Thursday 19 December 2013 22:18:36 Andreas Aardal Hanssen wrote: >> On 19 Dec 2013, at 18:36, Rick Stockton >> wrote: >>> Perhaps we should perform as QT4 did (there wasn't a second ButtonPress, >>> the DoubleClick "ate it"). Such use cases would then need to be "fixed >>> up" (i,e, to accept EITHER event as a cause for executing that Action)? >>> Logical, but a lot of work. >> Keeping Qt 5’s current behavior makes it impossible for an app to >> distinguish between multiple presses and a double-click without duplicating >> the timers in QApplication. Applications that rely on the original behavior >> are likely to be confused by the state you enter when receiving the second >> press. Agreed! I can't think of of another way to >> >> http://qt-project.org/doc/qt-5.0/qtwidgets/qapplication.html#doubleClickInterval-prop >> >> Sending the press event before the double click looks like a mistake, I >> wonder if it’s the same on all platforms. I would be surprised, as it would >> break all apps that handle more than simple mouse events. A git bisect is >> probably a good idea... > I checked now on windows: it's the same: > press > release > press > doubleclick > release > I agree, it looks like a mistake. Most likely, this error was created when we moved the "duplicate code" (code which checks the timers and creates the doubleclick) out from the individual platform plugins, and "higher up" into QPA. Can I leave the fix to someone else? My time is limited and my ability to code is very poor. I took a cursory look at the code which creates DoubleClick, and may not fully understand it: I would expect the "extra" ButtonPress to be emitted after the doubleclick, and not before. Does anyone object to treating current Qt5 behavior as a bug? If not, then bug definition is "The creation of a mouse DoubleClick event no longer suppresses the ButtonPress event which caused it". -- GPG fingerprint: 597E 4CE5 6D56 A7C2 DA3A 26FF F21F F828 0C86 165A ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 and QtWebkit in 5.2.0
On sexta-feira, 20 de dezembro de 2013 12:57:46, Allan Sandfeld Jensen wrote: > WebKit is recommended to compiled with C++11, compiling without C++11 is > only meant for platforms without working C++11 support (gcc 4.2 in Mac OS > 10.6). This is not a case of recommended. The use of >> makes C++11 mandatory. This code is in a OS(WINDOWS) section. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How can I perfrom some image processing before record camera image to a video file?
Hi, No you can't do that using the Qt API only. The only way would be to create a custom QAbstractVideoSurface (to set on QCamera) from where you would get the video frames and would be able to process them. Then the problem is that you can't use QMediaRecorder to save to a file, you would have to to the encoding yourself. Yoann Lopes ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] How can I perfrom some image processing before record camera image to a video file?
First I know I should have post this question in qt-interest, but each time I sent a mail to qt-inter...@qt-projct.org I will got a mail delivery failed message, so I have to post my question in this mailing list to seek for help: Recenty I am learning QtMultiMedia module, It's really easy to write a prgram to capture camera image into a file using QCamera and QMediaRecorder class. But I want to know that is it possible for me to do some image processing to the data catpured by the camera beofore recording to a file? Thanks! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] C++11 and QtWebkit in 5.2.0
On Friday 20 December 2013, Soroush Rabiei wrote: > Hi list > > IIRC webkit source is not supposed to be compiled with C++11. So I turned > off new standard in configure script: > WebKit is recommended to compiled with C++11, compiling without C++11 is only meant for platforms without working C++11 support (gcc 4.2 in Mac OS 10.6). `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] C++11 and QtWebkit in 5.2.0
Hi list IIRC webkit source is not supposed to be compiled with C++11. So I turned off new standard in configure script: .\configure ... -no-c++11 ... Trying to compile I got this error: In file included from Platform\CoreIPC\Connection.h:35:0, from Platform\CoreIPC\Connection.cpp:27: Platform/WorkQueue.h:145:30: error: '>>' should be '> >' within a nested template argument list Vector> m_workItemQueue; ^ Platform/WorkQueue.h:148:42: error: '>>' should be '> >' within a nested template argument list HashMap> m_handles; ^ I guess closing nested templates with two right brackets, is a C++11 feature which is backward-incompatible. C++03 standard does not define >>, therefore compilers can't parse >> as an end token but they see a right shift operator. That's why we do always care about adding s space between brackets. (Correct me if I'm wrong) After all, is writing C++11 code in a module which is not supposed to be compiled with C++11 a bug? or I'm missing something? Notes: 1. I edited source code and managed to compile webkit. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Color Profiles update
There were no changes since then. I stopped working after I left nokia. I am presently working on transferring the patch into the new file tree on git since it has changed a lot since then. On Thu, Dec 19, 2013 at 12:47 PM, Kai-Uwe Behrmann wrote: > I can not see much changes on codereview from your link since summer of > last year. What do I miss? > > Your attached PDF was interessting, thanks for it. > > kind regards > Kai-Uwe Behrmann > > Am 16.12.2013 10:43, schrieb Alexandros Dermenakis: > > Hello! > > I am working on merging a patch I made in summer 2012 on Color Profiles > for Qt 5. There are several small issues to be solved but it seems that it > won't take too long. > > The link to the related patches is : > https://codereview.qt-project.org/#dashboard,1002033 > > The functionality allows converting the color profiles on QImages > > More details on gerrit : > > I am also sending my thesis report which was on adding support for color > profiles on embedded systems. You can go through it to get ideas about > implementation and research background. > > I am also sending some sample code along with shaders (GLES 2) for > performing color conversion. I have testing the code on the Nokia N9 and > the only dependencies are GLES2 and LittleCMS2 (with some small > modifications) which are included in the sample code. > > > Best, > -- > Alexandros Dermenakis > *B.Eng *Software Engineering > *Email:* alexandros.dermena...@gmail.com > *Mobile:* +32 (0) 49 143 - 8890 <%2B32%20%280%29%2049%20143%20-%208890> > *Website:* www.alexandrosdermenakis.com > > > -- Alexandros Dermenakis *B.Eng *Software Engineering *Email:* alexandros.dermena...@gmail.com *Mobile:* +32 (0) 49 143 - 8890 *Website:* www.alexandrosdermenakis.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QWidget mouse events - different order
On Thursday 19 December 2013 22:18:36 Andreas Aardal Hanssen wrote: > > On 19 Dec 2013, at 18:36, Rick Stockton > wrote: > > Perhaps we should perform as QT4 did (there wasn't a second ButtonPress, > > the DoubleClick "ate it"). Such use cases would then need to be "fixed > > up" (i,e, to accept EITHER event as a cause for executing that Action)? > > Logical, but a lot of work. > > Keeping Qt 5’s current behavior makes it impossible for an app to distinguish > between multiple presses and a double-click without duplicating the timers in > QApplication. Applications that rely on the original behavior are likely to > be confused by the state you enter when receiving the second press. > > http://qt-project.org/doc/qt-5.0/qtwidgets/qapplication.html#doubleClickInterval-prop > > Sending the press event before the double click looks like a mistake, I > wonder if it’s the same on all platforms. I would be surprised, as it would > break all apps that handle more than simple mouse events. A git bisect is > probably a good idea... I checked now on windows: it's the same: press release press doubleclick release -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Trigger Qt event loop from external message loop
Unfortunately Mac is (additional to Win and Linux) a target OS, so if this
is not working on that I have to find another way to do it. I found
QMacNativeWidget which looks promising and looking into its implementation
I'm wondering how Qt's event loop is triggered?
With Qt4 I also used QWinWidget alot, which worked fine in Qt4 but is
broken in Qt5. QWinWidget created a QApplication and was registering a
message monitor (with SetWindowsHookEx) and triggered the event loop in the
callback by qApp->sendPostedEvents().
2013/12/20 Sze Howe Koh
> On 20 December 2013 04:52, Kuba Ober wrote:
> > Is this supported on all platforms now? IIRC it did not work OS X last
> time I tried, but yes,
> > it did work great on Windows.
> >
> > — Kuba
>
> The Cocoa framework mandates that all GUI-related operations must be
> done in the first thread in a process [1]. That's why this technique
> cannot work on OS X. I believe it was possible with Carbon apps, but
> not Cocoa apps.
>
>
> Regards,
> Sze-Howe
>
> [1]
> http://www.cocoabuilder.com/archive/cocoa/315103-why-is-the-threading-and-ui-updating-designed-to-be-done-only-on-main-thread.html
>
>
> > On Dec 14, 2013, at 3:25 PM, Roland Winklmeier <
> roland.m.winklme...@gmail.com> wrote:
> >
> >> Thanks very much Olivier and Thiago!
> >> That works brilliant.
> >>
> >> No idea why I forgot that QThread must not be used. But its of course
> >> obvious. I made a quick setup with native threads (std::thread is
> >> unfortunately not supported by VC2010) and it works perfectly now.
> >>
> >> In case someone is interested:
> >> - - I added a additional shared library spawning a thread and links the
> >> actual plugin during runtime with LoadLibrary/dlopen. No Qt stuff in
> here.
> >> - - Second shared library creates QApplication object and runs its
> >> exec() loop.
> >>
> >> Cheers Roland
> >>
> >> Am 14.12.2013 19:23, schrieb Thiago Macieira:
> >>> On sábado, 14 de dezembro de 2013 12:42:32, Roland Winklmeier
> >>> wrote:
> n qthread_win.cpp QThreadPrivate::start -> void
> QThreadPrivate::createEventDispatcher(QThreadData *data) {
> QEventDispatcherWin32 *theEventDispatcher = new
> QEventDispatcherWin32;
> data->eventDispatcher.storeRelease(theEventDispatcher);
> theEventDispatcher->startingUp(); }
> >>>
> >>> You must not use QThread.
> >>>
> >>> You need to start your thread before using any QObject-derived
> >>> classes. Once you're there, instantiate the QApplication
> ___
> 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] QWidget mouse events - different order
On 20 Dec 2013, at 09:15, Martin Koller wrote: > so it's just the extra mousePressEvent in Qt5 which is wrong. Good. I think it can and should just be removed, but it would be nice to know when it broke, in case there was thought behind it... Andreas___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QWidget mouse events - different order
On Friday 20 December 2013 08:31:24 Martin Koller wrote:
> On Thursday 19 December 2013 09:19:38 Rick Stockton wrote:
> > On 12/18/2013 01:10 PM, Andreas Aardal Hanssen wrote:
> > > On 18 Dec 2013, at 22:07, Rayner Pupo Gómez wrote:
> > Inner-most quote is from Martin Koller.
> >
> > >>> I've discovered that with Qt5 I get a different order of mouse events on
> > >>> a QWidget than with Qt4 (openSuse 13.1 Linux, X11):
> > >>> double clicking a widget results in Qt4 in:
> > >>> mousePressEvent
> > >>> mouseReleaseEvent
> > >>> mouseDoubleClickEvent
> > >>> mousePressEvent
> > >>> mouseReleaseEvent
> > >>> but in Qt5 in:
> > >>> mousePressEvent
> > >>> mouseReleaseEvent
> > >>> mousePressEvent
> > >>> mouseDoubleClickEvent
> > >>> mouseReleaseEvent
> > >>> I tested with Qt4.8.5 and Qt5.2.
> > >>> Is this behavioral change intended, undefined, a bug ?
> > >>> (it results in my app not behaving as before ...)
> > >> I think it's a mistake to rely on the order of this kind of events,
> > >> there are
> > >> fired asynchronously, your logic cant depend on this
> > > Wrong! The order is very essential and can and must be relied on.
> > > The behaviour in Qt 5 is questionable. I believe the double-click must
> > > come first to be able to distinguish from two presses.
> > >
> > > I also wonder if it's accurate / true that Qt 4 sends the second press
> > > after the double-click. AFAIR:
> > >
> > > Press
> > > Release
> > > DoubleClick
> > > Release
> > >
> > > Is the right events for double-clicking.
> > >
> > > Andreas
> > Andreas, I'm confirming the QT5 behavior, to be as Martin describe. BUT,
> > the Qt4 behavior seems to be as YOU recall - no ButtonPress" at all for
> > the fast-enough second click which invoked a "DoubleClick event.
>
> I'm not making things up. This is what my testprogram gives.
> I attach it here.
I see now the problem with my testprogram.
I also called the basclass implementation, which leads to the extra
mousePressEvent.
(fixed prog attached)
when I just print the events in my implementation, I get:
Qt4:
mousePressEvent
mouseReleaseEvent
mouseDoubleClickEvent
mouseReleaseEvent
Qt5:
mousePressEvent
mouseReleaseEvent
mousePressEvent
mouseDoubleClickEvent
mouseReleaseEvent
so it's just the extra mousePressEvent in Qt5 which is wrong.
--
Best regards/Schöne Grüße
Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at#include
#include
#include
class Widget : public QWidget
{
public:
Widget(QWidget *parent) : QWidget(parent)
{
}
virtual void mousePressEvent(QMouseEvent *event)
{
qWarning("mousePressEvent");
event->accept();
}
virtual void mouseReleaseEvent(QMouseEvent *event)
{
qWarning("mouseReleaseEvent");
event->accept();
}
virtual void mouseDoubleClickEvent(QMouseEvent *event)
{
qWarning("mouseDoubleClickEvent");
event->accept();
}
};
int main(int argc, char **argv)
{
QApplication app(argc, argv);
Widget *w = new Widget(0);
w->show();
return app.exec();
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
