Re: [Development] Source incompatible Qt 5 change: Removing the QTouchEvent::TouchPoint::Primary flag
On 01/12/2012 02:46 PM, ext Thiago Macieira wrote: On Thursday, 12 de January de 2012 14.26.41, Samuel =?ISO-8859-1?Q?R=F8dal?= wrote: Hello, I'd like to remove the QTouchEvent::TouchPoint::Primary flag, as per change request http://codereview.qt-project.org/#change,12928 The current purpose of the flag is simply to note that a touch point is duplicated as a mouse event by the windowing system (to prevent Qt from also generating a synthesized mouse event from that touch event). The linked change moves this duplication logic out of the windowing system interface (platform plugins, generic plugins, etc), and into QtGui. If we kept it as always returning false it could mask incorrect behavior in the user application. I didn't get it. Will there be touch points duplicated as mouse events? If so, is the user supposed to know about that? And if so, how does the user know about it? There already is in Qt 4, it's handled by QWidget::event(). In Qt 5 it's the currently platform or generic plugin that sends both touch events and mouse events, which is less ideal. With my patch (linked above) it's handled in QtGui, so that it first tries to send the touch event, and if that's ignored, it sends a mouse event. QtWebKit relies on this behavior for example. The new thing from Qt 4 is that I added two application attributes to enable / disable these synthetic events. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On Friday, 13 de January de 2012 08.14.41, Peter Kuemmel wrote: Well, having method createX which creates Y doesn't sound good to me either. Yes, this is worse than a binary-only bug. I don't know the policy for API changes for Qt 5.0, but when such a thing couldn't be fixed, nothing else is worth braking source code compatibility. I would fix it because it is super simple to create a script which simply replaces all the relevant strings in the source files. It's very easy to update the sources once you know that you have to. The problem is that the script might replace things it shouldn't. createRequest is not an exclusive name of QNetworkAccessManager and it might appear elsewhere. The changes we have accepted are either for the greater good or because they can be easily automated with very little mistake (like #includes). What's more, this is a change very hard to track down because it does not create a compiler error if you forget to change your sources. It's a case of silent bugs creeping in. So, changing the name of this function is: - of little practical benefit - not 100% automatable without a code scanner - dangerous, as it creates silent bugs -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] fixing name of QNetworkAccessManager::createRequest
Am Freitag, den 13.01.2012, 14:10 +0200 schrieb Robin Burchell: 2012/1/13 Thiago Macieira thiago.macie...@intel.com: So, changing the name of this function is: - of little practical benefit - not 100% automatable without a code scanner - dangerous, as it creates silent bugs what about the slightly more garden-variety approach of deprecating the old one and introducing a new method? Maybe we should check the premise of this discussion first. Does that method really have the wrong name? It is called createRequest and after all it causes creation of a network request. Now this network request is just an internal object, and not exposed to the API user. Instead the watchable reply object is returned in advance. Not really an issue, and not entirely uncommon in async APIs IMHO. Ciao, Mathias -- Mathias Hasselmann math...@openismus.com http://openismus.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On 13 January 2012 12:32, Mathias Hasselmann math...@openismus.com wrote: what about the slightly more garden-variety approach of deprecating the old one and introducing a new method? Maybe we should check the premise of this discussion first. Does that method really have the wrong name? It is called createRequest and after all it causes creation of a network request. Now this network request is just an internal object, and not exposed to the API user. Instead the watchable reply object is returned in advance. The problem is that it doesn't match the Qt namings for the relevant classes... createRequest takes a QNetworkRequest (which is a description of the request that should be made), starts making the underlying network request as you described, but then also creates and returns a reply (QNetworkReply). Bikeshedding? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On Friday, 13 de January de 2012 13.32.27, Mathias Hasselmann wrote: Am Freitag, den 13.01.2012, 14:10 +0200 schrieb Robin Burchell: 2012/1/13 Thiago Macieira thiago.macie...@intel.com: So, changing the name of this function is: - of little practical benefit - not 100% automatable without a code scanner - dangerous, as it creates silent bugs what about the slightly more garden-variety approach of deprecating the old one and introducing a new method? Maybe we should check the premise of this discussion first. Does that method really have the wrong name? It is called createRequest and after all it causes creation of a network request. Now this network request is just an internal object, and not exposed to the API user. Instead the watchable reply object is returned in advance. Not really an issue, and not entirely uncommon in async APIs IMHO. It was supposed to be named sendRequest, but I changed it. I don't know what my reasons were in 2007. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] fixing name of QNetworkAccessManager::createRequest
Am Freitag, den 13.01.2012, 13:00 + schrieb Giuseppe D'Angelo: On 13 January 2012 12:32, Mathias Hasselmann math...@openismus.com wrote: what about the slightly more garden-variety approach of deprecating the old one and introducing a new method? Maybe we should check the premise of this discussion first. Does that method really have the wrong name? It is called createRequest and after all it causes creation of a network request. Now this network request is just an internal object, and not exposed to the API user. Instead the watchable reply object is returned in advance. The problem is that it doesn't match the Qt namings for the relevant classes... createRequest takes a QNetworkRequest (which is a description of the request that should be made), starts making the underlying network request as you described, but then also creates and returns a reply (QNetworkReply). Bikeshedding? Surely startRequest() would have been a better name. But really not sure it is worth the hassle of changing it. Still Robins suggestions shows a practical approach. Ciao, Mathias -- Mathias Hasselmann math...@openismus.com http://openismus.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposing Nicolas Arnaud-Cormos for Approver Status
Hello everybody. I hereby propose to grant Nicolas Arnaud-Cormos Approver status. Nicolas has contributed to Qt Creator development since 2010. His contributions include the macro recording plugin, as well as fixes and enhancements to the analyzer/valgrind plugin, cmake support, and to various other places. Eike Ziller and Tobias Hunger are seconding this proposal. Best regards, Andre' -- André Pönitz Principal Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On 01/13/2012 02:10 PM, ext Mathias Hasselmann wrote: (...) Surely startRequest() would have been a better name. But really not sure it is worth the hassle of changing it. Still Robins suggestions shows a practical approach. I don't really think it is worth changing it, I think for 5.0 so far we only broke source compatibility if the name or signature was plain wrong (8ef86d05f199ebab216da43d5e0a9dc322b657b3 or bf7f17060773803f332e8c729a70f47b94243890), not in cases where it could have been named better... Peter Ciao, Mathias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Serious ABI issue discovered in -reduce-relocations
Hello We've got a problem with -reduce-relocations. tl;dr: it's a broken concept and we either add a permanent workaround or we stop using it. The permanent workaround is to compile all executables in PIC/PIE mode. Long story: The -reduce-relocations option in configure checks that the compiler supports the linker flag -Bsymbolic-functions. That function was added to binutils in 2006 from our urging, to make it possible for us to use it when the -Bsymbolic option presented problems. Turns out that -Bsymbolic-functions has the same problems that -Bsymbolic had and is no fix. Those two options cause the linker to symbolic link some symbols into the binary it's producing. That is, if a symbol X is used and is also defined inside this ELF module, then this option tells the linker that it may rightly assume that the symbol will always be inside this module. The linker will then use cheaper types of relocation, or none at all. This is a huge performance improvement both at load- and at run-time. -Bsymbolic does it for everything, whereas -Bsymbolic-functions does it for functions only. The reason why we needed -Bsymbolic-functions in the first place is that ELF has a weird feature that causes data variables to move between modules. Functions weren't affected because they aren't moved. Turns out that there is one situation in which a function is treated as data: when you take its address. In order to compare equally, the dynamic linker must resolve the function address to only one place, and unfortunately for us, the choice isn't to our liking. The canonical address may be moved from the library. We haven't hit this problem before because we hadn't been doing function pointer comparisons. Now, with Olivier's new connection syntax patch, we are. The workaround possible is to tell the compiler and linker that even executables are position-independent. This causes the linker to stop using copy/move relocations because it doesn't need them. However, there use of PIC may have a non-trivial performance impact on applications, due to indirect variable accesses and loss of one register. Regardless of whether I manage to convince the linker people to improve the situation, we need to figure out a solution for existing systems. What shall we do? Even longer story (background): In code that isn't position-independent (i.e., the executable), a data access is done as: movlvariable, %eax And a function call as: callfunction And the loading of a function address as: movl$function, %edi When linking this program, the linker needs to write the address of the variable variable and of the function function into the instructions (one is absolute and the other relative, but that's irrelevant). If both symbols are found in a shared library, then the linker will patch up differently. For the function, it will make the call instruction call to a stub called the Procedure Linkage Table (PLT), which then loads the proper address from somewhere and then jumps to the proper address. That somewhere is another structure called the Global Offset Table, which the dynamic linker will fill with the actual function address once the library has been loaded. For the variable, things get complicated. There's no way to do the PLT trick. So what the linker does instead is add a copy relocation. It writes the name of the variable and its expected size and reserves that much in the executable. The dynamic linker will then, at load time, find the variable in the shared library, copy the contents and then tell the library it should instead find the variable in the executable's memory. When using position-independent code options (-fPIC and -fPIE), things change. The compiler will write for the function call: callfunction@PLT The loading of a function address is: movqfunction@GOTPCREL(%rip), %rdi As for the variable, it produces: movqvariable@GOTPCREL(%rip), %rax movl(%rax), %eax All accesses are position-independent and indirect. The call is placed via the PLT, addresses are loaded from the GOT and the loading of values is done after the actual address is loaded from the GOT. This is suitable for accessing symbols defined in other ELF modules. It's also necessary for library code. Unfortunately, the side-effect is that access to symbols defined in the current ELF module is also done indirectly. Two options help change this: - fvisibility=hidden and the symbolics. The -fvisibility=hidden option is enabled by default in Qt since 4.0 and corresponds to the configure option -reduce-exports. It does not change the code above, so it means that all variable accesses to variables not defined in the same compilation unit are indirect. Fortunately for the function call, the linker realises that target is inside the library and cannot be anywhere else, so the call is now direct to function. The loading of the address is via the GOT, which means a run-time
Re: [Development] Serious ABI issue discovered in -reduce-relocations
On Friday, January 13, 2012 12:33:46 PM ext Thiago Macieira wrote: Hello We've got a problem with -reduce-relocations. tl;dr: it's a broken concept and we either add a permanent workaround or we stop using it. The permanent workaround is to compile all executables in PIC/PIE mode. I think calling -Bsymbolic-functions a broken concept is harsh, given that it makes a lot of sense - doesn't it? The fact that it breaks when comparing addresses of functions sucks, but IMHO compiling PIC/PIE is still better than going back to all those unecessary relocations just because somebody _might_ interpose a symbol of the public API of the library. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
createReply doesn't make sense to me. createRequest is perfectly fine in a sense that we query the server, and it returns a reply out of it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] fixing name of QNetworkAccessManager::createRequest
On 13.01.12 16:25, Sylvain Pointeau wrote: createReply doesn't make sense to me. createRequest is perfectly fine in a sense that we query the server, and it returns a reply out of it. Well, it does make sense to me :-) The request (QNetworkRequest) is already created. What the function actually does is create the reply (QNetworkReply). But I have to agree with Thiago here, let's just keep it how it is. Changing it would introduce too much trouble. Markus ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Serious ABI issue discovered in -reduce-relocations
On Friday, 13 de January de 2012 15.55.06, Simon Hausmann wrote: On Friday, January 13, 2012 12:33:46 PM ext Thiago Macieira wrote: Hello We've got a problem with -reduce-relocations. tl;dr: it's a broken concept and we either add a permanent workaround or we stop using it. The permanent workaround is to compile all executables in PIC/PIE mode. I think calling -Bsymbolic-functions a broken concept is harsh, given that it makes a lot of sense - doesn't it? It depends on the interpretation. One binutils hacker I talked to told me that you simply couldn't do it, so that would be a broken concept. If we can convince the binutils community to fix the implementation or -- better yet -- improve code generation, then we can call it broken implementation today. The fact that it breaks when comparing addresses of functions sucks, but IMHO compiling PIC/PIE is still better than going back to all those unecessary relocations just because somebody _might_ interpose a symbol of the public API of the library. Read the longer explanation. The reason why this exists is because of the ELF executable ABI. ELF executables contain position-dependent code without relocations. That means the code in executables must know the address of everything. To support that, the linker does copy relocations and forces certain symbols to be in the executable, even if they aren't really there. This is all to improve performance of executable code, to the detriment of library code. I question that today: libraries are much bigger and more complex than user code. Moreover, for us in Qt, where QML will take such a proeminent place, user code is close to irrelevant. Still, we can just add this to qobject.h: #if defined(__ELF__) !defined(__PIC__) # error Sorry, not supported. Please add -fPIC or -fPIE to your compilation flags #endif -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] Qt Contributors Summit: when and where
On 01/11/2012 08:29 AM, ext Quim Gil wrote: The only days that seem to suit a majority in this semester are during the week of June 18th. We still need to look at the availability of venues in Berlin for those dates. Daniel those of you with _Berliner Fachwissen_ : can you help nailing down the candidates available for an event hosting 200 people in 3 or more rooms between June 21-23 (or earlier that week)? At this point we only need to know availability and quote for the space, usual room equipment and good wlan. All the rest are commodities that won't change from a venue to another. In the meantime I'm putting my time and focus reaching to a critical mass of funding and attendance from the key Qt Project stakeholders. If it's not during these days then we hit the Summer holidays, and after that we start to be close (too?) to Dev Days. An alternative would be to combine both events (also good for optimizing costs). If you don't want to see this happening then your help is welcome solving the equation for the event in June. :) -- Quim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Status of QtDeclarative on Windows?
Just for fun I've been playing with a medium-sized QML app that we had written for 4.7/Symbian and porting it to Qt5/QML2. Mostly have been working on Linux but the past few days I finally got around to compiling Qt5 on Windows and playing around with the project enough so that it would compile and run under qmlscene (it's mostly qml/js with a C++ plugin module as well). Anyway, the performance on my Windows box is horrible. ListView scrolling, image loading, animations, everything is like it's running in quicksand. Is this expected? If not, what do I need to do to in order to troubleshoot? This machine is relatively old and has a crappy video card (older Nvidia Quadro), but it should be more than good enough to run this app smoothly. Any tips or tricks to enable extra debug tracing? Thanks, Todd ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
