Re: [Qt5-feedback] Global shortcut proposal
On Friday 21 October 2011 19:50:33 Mark wrote: On Tue, Oct 18, 2011 at 8:33 PM, Mark mark...@gmail.com wrote: Hi, I want to adjust QShortcut to use it for global shortcuts as well and would like to lay out my idea on how i intend to do that. Any feedback on it would be more then welcome. The first thing to do is add an enum value to Qt::ShortcutContext http://doc.qt.nokia.com/latest/qt.html#ShortcutContext-enum: Qt::SystemShortcut (that becomes value 5) with the description: The shortcut is active in a system wide context when the application is running. Next up is probably (being optimistic here) tweaking the eventFilter of the QShortcut class to act on global shortcuts for Windows, Linux and MAC when the Qt::SystemShortcut enum is set. This was discussed before, and the problem is that one would want a framework to register the global shortcut into a central place on the system that handle conflicts in shortcut and proper configuration. KDE has such a thing, i don't know about the other systems. Now some questions pop up. It has been said that (global) shortcuts should probably be handled through the window manager. In Qt's case that means (?) through LightHouse right? Not really. Qt application need to work on all the platform and window manager. But how am i supposed to do that? Where is lighthouse even hidden? And what happened to QtCore? Is that now QtBase? Lighthouse is the codename for QPA. That is, the windowing system abstraction layer and its plugins. The abstraction layer is in QtGui (all the files with _qpa), the plugins are in src/plugins/platforms Considering global shortcut is part of that, i guess you need to add some interface in the abstraction layer, and then a specific implementation for each platform in the plugins. Note that this would only be the client code. The server side framework to handle the registration or the conflicts is outside of the scope of Qt. So where do i get started with this? Checkout the code, open the editor :-) And I've never build Qt 5 yet nor did i ever contribute actual code to it.. so that's gonna be interesting. Everything has a begining :-) But you should definitively look at previous implemntations (such as the one in qxt). And in particular how the kde infrastructure works, because it would be nice if it was integrated into it. That said, being perfect the first time is not possible. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
[Qt5-feedback] Hash in QString (Was: Merging the vector/array headers in QtCore)
On Monday 17 October 2011 10:31:36 João Abecasis wrote: On Oct 16, 2011, at 6:57 PM, ext Thiago Macieira wrote: One thing I would like to add is the hash, for QString (and potentialy QByteArray) see: http://qt.gitorious.org/qt/qtbase/merge_requests/62 We discussed that but we're not satisfied that it will provide good results. It means spending 4 bytes to store the hash as well as hardcoding the hashing function until Qt 6. Someone mentioned that only 10% of the strings are ever hashed. In particular, I am not ready to give up a 16-byte alignment for the hashing. Maybe João can give more details of his thinking. When we discussed this, no one seemed to be much in favor of the change, in subjective terms. One concrete show-stopper is the concern that it makes QString's hashing function part of the ABI. QString's hashing is only part of the ABI because of the compile time hashes. Anyway, it can easily be versionized (read the comment on the merge request) that is, we add a uint stringVersion :8; in the flags, and qHash become if (stringData-hash stringData-stringVersion == _Current_Version) return stringData-hash; //else ignore the embedded hash So this is not really an issue, is it? Other concerns, as you mention, are the waste of space and whether the resulting improvement is worth the trouble For the space, 16bytes is not much, just enough to store QString (in utf16 null-terminated) (at the same time, some people argue over QStringLitteral should be used instead of QLatin1String even in places where it does not matter from a performence point of view, while taking twice as much memory) -- so, 10% of strings are ever hashed, but are there places where we re-hash the same string over and over that other improvements in code would provide better results? Well, this is why QtDeclarative has its internal QHashedString. I haven't given this much more thought, but I'm wondering if there are places where introducing a QString-compatible QString-extension (say QHashedString) would provide the same benefits... That is something that can be played with before we change QString. The problem is that it is that the hash is lost each time we go back to a QString. -- Olivier P.S: This common pattern is problematic because there is no way to avoid computing twice the hash in the cache-miss case. (even if one could argue it is not a problem because cache-miss is meant to be a slow case) auto it = hash.find(key); if (it == hash.end()) it = hash.insert(key, computeValue(key)); return *it; ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Merging the vector/array headers in QtCore
On Monday 17 October 2011 20:54:47 Thiago Macieira wrote: On Monday, 17 de October de 2011 19:33:07 Oswald Buddenhagen wrote: On Mon, Oct 17, 2011 at 02:55:53PM +0200, Knoll Lars (Nokia-MP-Qt/Oslo) wrote: Why would we want to add a wrapper for char's? why again do we have a wrapper for ushort called QChar? after all, some global functions operating on ushort would do. ;) What functions do you want to have on QByte? isDigit, isLetter, toUpper, whatnot? ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Merging the vector/array headers in QtCore
On Sunday 16 October 2011 16:30:39 Thiago Macieira wrote: When I talked to João this week, he expressed the desire to unify the header code of QVector, QByteArray and QString. Since QByteArray is a vector of char and QString is a vector of QChar / ushort, it makes sense to unify the code to simplify maintenance. Whether specific optimisations in allocation policies are needed, we can figure out later. Appart from consistency in out internal structures, what is the gain? What is the code that can be reuse? (Appart the declaration itself, i can't think of any) As this is an internal thing, this do not give us anything regarding the API point of view. And this keep us to have nice per/data structure optimisation. In other word, i'm not really in favor of this. (I think the sharing should happen at code level, by providing the same interface which enable templated code (like QStringBuilder) to work of all types.) But given my last email, about also bringing in QList for small and movable types into this merging, I pointed out that QList has one optimisation that QVector doesn't have. To support that feature, the QListData header currently is: QAtomicInt ref; int alloc; int begin; int end; // size = 16 bytes, alignment = 4 bytes There's also an 1-bit flag which I have not included. It can be stored in the sign bit of one of the ints in the future. In addition, the current QStringData and QByteArrayData headers are (not including the flags): QAtomicint ref; int size; int alloc; qptrdiff offset; // size = 16 (24) bytes, alignment = 4 (8) bytes Note how there's a 4-byte padding gap before the offset member on 64-bit platforms and how the data starts at an offset of 24 bytes. Given a 16-byte aligned allocator, which is common on 64-bit platforms, the data starts at an 8 byte offset from the nearest 16-byte alignment, which is a problem for SSE2 optimisations. One thing I would like to add is the hash, for QString (and potentialy QByteArray) see: http://qt.gitorious.org/qt/qtbase/merge_requests/62 I'd like to pick all of your brains for a solution that has the following properties: - size always 16 bytes Not possible on 64bit Or did you mean multiple of? - contains a qptrdiff offset, to still allow for fromRawData (which we'd then introduce to QVector too, but not QList) And there again you are saying it will be different for QList and QVector Or you want to put a lot of unions there (which negates the hole purpose) - can store at least one 1-bit flag, but 2 would be preferred The more flag you have, the more future proof you are if you want to keep binary compatibility. - size calculation reasonably fast And add stuff like: - can be generate at compile time and put in the .rodata (like we did for QString) ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QList in-array item size
On Sunday 16 October 2011 16:21:40 Thiago Macieira wrote: [...] Option 3: make it QListT be an actual QVectorT for movable types, maybe with an upper limit of size (32 bytes, 128 bytes?). - pros: suitable for all types, shares code - cons: more complex to implement, more code to compile and parse in headers This is the obvious solutions... One big difference between QList and QVector today is that QList has prepend / takeFirst optimisation, whereas QVector must move all elements to accommodate. I would prefer if that optimisation remained present. It has to (it enable QList to be used for queue like data structure (and it is, see QQueue) QList was also supposed to expands to less code (than QVector) (at least that is what Jasmin used to advertise some years ago) ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QList in-array item size
On Sunday 16 October 2011 18:59:08 Thiago Macieira wrote: On Sunday, 16 de October de 2011 17:12:33 Olivier Goffart wrote: One big difference between QList and QVector today is that QList has prepend / takeFirst optimisation, whereas QVector must move all elements to accommodate. I would prefer if that optimisation remained present. It has to (it enable QList to be used for queue like data structure (and it is, see QQueue) QList was also supposed to expands to less code (than QVector) (at least that is what Jasmin used to advertise some years ago) I don't see how it can expand to less code than a simple vector. The best case scenario is to expand to the same code or to similar complexity -- assuming of course that QVector is optimised to produce minimal code too. Because QList make use of much more stuff in QListData that is not template type (hence, not generated for every types) However, I beleive it is possible to do the same optimisation for movable type within QVector, if we want to. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] source incompatible changes
On Thursday 13 October 2011 12:22:39 Simon Hausmann wrote: Hey, There are plenty of source incompatible changes going into the Qt 5 modules. This can make development of depending modules difficult. I recall that the KDE 4 development cycle had similar issues, and I have vague memories of this being mitigated with a simple procedure: Source incompatible changes were pushed only once a week (on Mondays?). Would it make sense to do the same for Qt 5 development? I think the situation is different now than with KDE4: use of git instead of svn, Qt being more modular, CI system, ... With the CI system it is almost impossible to know in advance when a change will get integrated. In the implementation i know (from few month ago), the tests are only run when one clicks Integrates, which means the source incompatible changes will only be run on monday and are likely to fail because changes being batched up. (Source incompatible changes are usually dependences for others changes that also have to wait) Not to count the problem with conflicts that will happen Hopefully now, there is not many source incompatible changes. (+1 for review on the list, i think it was part of lars's statement that all source incompatible changes must have proper review) Anyway, the goal of the modularisation was that module would envolve separately. Then, if it is a problem for modules, the solution is that modules depends on a sha1 of qtbase from the previous monday. (Only update qtbase every monday. in qt5.git) And this also help with binary compatibility. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Xlib support dropped?
On Thursday 13 October 2011 15:47:49 Harri Porten wrote: On Thu, 13 Oct 2011, Samuel Rødal wrote: But we're planning to make the xcb plugin the officially supported platform plugin on X11, the xlib plugin is mainly there for reference (it's not as full-featured as the xcb plugin). What's the state of xcb on Solaris and AIX? I understood that neither Solaris or AIX would be officially supported platforms ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Friday 07 October 2011 15:14:33 Daniel Mendizabal wrote: To All, [...] Hi, But what happen now when new mobile phones come with Qt5 without QWidget support? I wonder how the message could have been given so wrong. I'm not speaking for the Qt team. But while Qt team thinks QML is the technology to use in the future for interface and will spend all its development power in it, they aknoweldge that is is currently not yet ready for all uses. That mean that QWidget is NOT going away. It is not removed. It will stay. It is just that it will stay in maintainence mode, and not get many new features. All existing projects based on this technology currently in OVI store or private clients will stop working from one day to the other? No, as stated, QWidget stays. When I started with Qt, I read about the promise to keep source and binary compatibility across the releases, what happen with this promise? The promise is between minor releases, Qt5 is a major release, there is no compatibility promise at all. Qt 4.0 was a massive source compatibility break to previous version. But in comparison, in Qt 5.0, the source compatibility changes will be limited to the minimum This promise was and still is reinforced by Nokia's marketing statement: Qt allows you to write advanced applications and UIs once, and deploy them across desktop and embedded operating systems without rewriting the source code saving time and development cost So it will be with QML I want to clarify that I'm not against QML/JavaScript, it could be an interesting approach to bring more (Java) developers into the pool. But I don't think, this is a fair and responsible decision from Qt's board to leave so many developers and current projects in the situation described above. I hope there is still room for changes and QWidgets classes are finally included for mobile platforms in Qt5. Because porting existing and complex applications with thousands of lines of code which have been optimized for so long with bug fixes and upgrades would be economically not interesting nor I could have the heart to re-do all my work again. Qt5 is opensource, and merge requests are accepted. And you might have seen Nokia's plan to open the develoment process even more. That means if you or anyone else still interrested in QWidget want to add feature, they still can. The question is if it this is a good thing to spend time on QWidget. On the other hand, what happen with the users who purchased these applications from OVI store? Will they loose them as soon as their devices are upgraded to Qt5...? The symbian devices are not going to be upgraded to Qt5. And if Qt5 comes on those devices, it will be in addition to Qt4. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Concern about removal of QWidget classes
On Friday 07 October 2011 14:27:20 Till Oliver Knoll wrote: [...] But recently it turned out that the whole paint stack, the scene graph, will be completely rewritten, to favour the QML architecture. The scene graph is a technology that has been writen specifically for QML, If you want to use it, you indeed need QML. But QPainter and QWidget stays there, and are not that bad. (QWidget can't use the scene graph because it has been designed for imperative programming (the way QStyle works)) And it turns out that for all these fancy effects we now need OpenGL support to get any descent performance. And what's more, the whole QWidget implementation will sit on top of all that. I am not sure you are correct. Don't confuse lighthouse and scene graph. QWindow (the replacement for top level widget) may indeed require OpenGL (to simplify the implementation) So in the worst case I will have to link against all these JavaScript engine and what-not libraries, just to display a Hello World in a QLineEdit, implemented as some QML element in the background, interpreted by some JavaScript engine, rendered by some OpenGL stack... but nicely shaded maybe (which by the way I don't want at all, as I want my QLineEdit look exactly as the native one!). No, as you stated before, if you do not want Javascript or QML, you don't link to it. There was a huge thread before regarding moving V8 (the javascript engine) to QtCore. But the result of this discussion is that this will not happen. QtV8 stays a separate library, and you don't need to link to it to use your QWidgets So QWidget has clearly become 2nd class and with regards to performance we have to take what's left for us! At least that is my impression from some discussions I followed. QWidget has some performence limitations in their design that are not possible to solve. This is why the scenegraph has been developed. And that will not work for QPainter and it's imperative drawing. Now, QWidget do not loose anything, it just stays behind, where it was. So here are some points I'd like to throw in: - I don't want to use any JavaScript in my code! [...] Qt5 is not a problem here. - I want performance! I have tested one of my 4.7.3 Qt applications on a 10 year old HP laptop running Windows 2000 on a Pentium III 600 MHz, 512 MByte RAM. Just for the fun of it. And it ran perfectly! The main window resized smoothly and overall GUI performance was very snappy. I am happy with this! And that is the benchmark I will refer to when testing any QWidget application on top of Qt 5. Please try it with the current development branch of Qt5. I see no reason why it would not work anymore. But with the current requirement that even the QWidget based apps now need OpenGL support that means I cannot even run my apps in a virtual machine such as VirtualBox on a Mac in a decent way (and yes, I AM cross-developing a lot in VirtualBox, for both Windows and Linux)! You should be able to use software randering. (llvmpipe) If you still use the plain widget as before without fancy effect, it should not be slower than the current raster engine. http://labs.qt.nokia.com/2011/05/31/qml-scene-graph-in-master/ But even from a user perspective (I'd accept the argument that as a developer I should be able to invest into proper hardware) that means I am burning battery power of my laptop/tablet/phone each time the GPU starts cooking, simply because I resize my main window! The GPU is optimized to do draw, it may uses less power than the CPU. Oh and yes, I also do OpenGL based applications, and I'd hate it to see the widgets taking away valuable GPU cycles and introducing locks by GL context-switching, simply because that damn button needs to have its drop-shadow rendered nicely! (Yes, I am aware that OS X for instance does nothing else - but Qt would again render ON TOP of that with its own GL context etc.). I can't answer to that. - I want native widgets! I want my application to look as natively as possible! Native, native, native! Can't repeat that enough. Even better: Use native widgets wherever possible (e.g. push buttons, drop-down boxes etc.). No rounded corners, no drop shadow, no textures where the OS window manager would not render them anyway! Even with QML, there is some work in the desktop componenent to do exactly that. - I for sure don't want to hand-code any XML-like GUI files! We have Qt Designer for a reason! Editing GUI in a text file is sooo late century, you know! And if I want to programmatically define the GUI, then I want it to be blazing fast, means compiled. With a well-documented API, simple to use. Oh, we already have that, it's called Qt... I wouldn't mind if the Qt Designer would create QML files under the hood. Much the same way I don't care about the actual content of the current UI files. As long as I would interface against a compiled C++ class in my own code! And there's
Re: [Qt5-feedback] QMetaObjectBuilder in QtDeclarative and QtSystems
On Monday 03 October 2011 16:25:45 Lorn Potter wrote: Hi, Currently, there are 3 instances of QMetaObjectBuilder, in QtDeclarative, QtSystems (serviceframework) and QtSystems (publish and subscribe). There are only trivial changes between these existing versions of QMetaObjectBuilder private class. Any objections if I add a QMetaObjectBuilder to qtbase in qtcorelib, so to remove code duplication, (and I can use it as well)? I will use the code from QtDeclarative module. The respective owners of those modules/code should then probably remove their versions and convert their code to using the one in QtBase. The reason why i don't like those is that it is really exposing a lot of the internals, and that using them is complicated. A better alternative would be to have public API to do the things that we want. That is, something like QObject::addDynamicSignal(...) QObject::addDynamicSlot() ... (and a dynamicslotevent), or whatever that api is used for. Now, if these classes stay private anyway, i don't object. (because reducing code duplication is a good thing) ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday 30 September 2011 12:57:28 Kent Hansen wrote: Hi, You might have seen Thiago's blog about QStringLiteral [1], and his idea on replacing QLatin1String usage by QStringLiteral in Qt (where possible). I like the idea, but wanted to do some benchmarking first to get an impression of the performance impact. [2] You could have used template instead of macros :-) My results so far (on Linux 32-bit) indicate that QString::appends are way faster when switching to using QStringLiteral: 7x faster than QLatin1String for a 2-character literal and 14x for a ~50-character literal. That is because you append to a null string. Appending a QString to a null string is equivalent to the operator= (that is, only setting a pointer) could you change the benchmark to append to something? Also, appending with QLatin1String currently do not do the sse2 fromLatin1, it would be trivial do so by extracting the fromLatin1 code to a helper helper function. Now, the not-so-good news: operator==(QString) is a bit (just a bit) slower than operator==(QLatin1String) for short strings. It seems that, for short strings, the overhead of calling qMemEquals() and performing its housecleaning chores outweigh the benefits of its fast comparison loop. It would be nice to compare with different lenght AND different on the first char. Or better, with actual data extracted form a qDebug in the operator== for a random application. In other words, if someone were to optimize QString::operator==(QString) to perform better for small strings, the total replacement would be a done deal. Another thing that need to be taken in account is that QStringLiteral takes more memory in the binary. Hence, more cache misses. This is difficult to show in a benchmark that runs over the same data all the time. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday 30 September 2011 16:55:53 Konstantin Tokarev wrote: Great news! Is it possible to use this superfast QStringLiteral with Qt 4.x? No. This is a binary incompatible change in QString. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QObject: new signals-slots syntax
On Thursday 22 September 2011 08:18:49 Frans Klaver wrote: [...] I'm still not convinced that the trade-off is worth your while, but you obviously think it is. There's downsides and upsides to both approaches. Compile-time check is one thing, but there is also other advantage of the new code. I am putting some advantages here: - You get automatic conversions of the arguments (eg. QString-QVariant or int-double, ...) - Old syntax has issues with namespaces and typedefs. - You get all the power of connecting using tr1::bind, or to a C++11 lambda expression. So yes, there are some tradeoffs, like having the signals public. How often did you compile your code, and had the error mySignal is protected which was because you called a signal on another object by mistake? And How often did you actually have valid reason to emit the signal but had to use a workaround with one level of indirection? ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QtConcurrent using Variadic Template Arguments
On Wednesday 14 September 2011 11:06:02 Keith Gardner wrote: I was wondering if QtConcurrent could be modified to use Variadic Template Arguments for the run function since this feature is now available with C++11? It would not be that easy because of the current implementation design of QtConcurrent. (it would basically involve a rewrite of all the current template logic) Also, we have to keep it working with compiler that do not support C++11. (I only see one benefit of having variadic template support: make possible to call functions with more arguments. And that can now be done with a very small boilerplate) But QtConcurrent really could benefit from some love. Both the templated code, but also the internals (to reduce the overhead of the framework). -- Olivier ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Heads up: Merging refactor branches into master
On Tuesday 13 September 2011 10:42:53 Gábor Lehel wrote: On Tue, Sep 13, 2011 at 3:51 AM, aaron.kenn...@nokia.com wrote: Hi, On 12/09/2011, at 11:04 PM, ext Sylvain Pointeau wrote: QtScript should be using V8 and provide all the facilities of binding QtObjects... (it is using JavascriptCore if I remember well correct?) While this would be true in an ideal world, after much prototyping it was decided that porting the entire QtScript API to V8 and preserving its exact semantics was simply not possible. As a compromise, we have left the QtScript module untouched to preserve 100% compatibility for existing applications, and introduced a parallel API against V8 (the QJS* classes) that is similar enough that we expect most applications - and almost all new applications - to be able to move to it instead. Keeping 100% compatibility is a requirement even with the break to Qt5? Yes, keeping as much source compatibility as possible, in order to make possible to upgrade projects with millions of lines of code. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Proposed simplification for the Qt Add-On naming
On Saturday 27 August 2011 10:01:56 Andre Somers wrote: Op 26-8-2011 13:54, henry.haveri...@nokia.com schreef: I suppose the goal of this exception is to keep source compatibility. (forward delcaration would break if the namespace change) So I would say yes, modules which are meant to keep source compatibility should not have a namespace I agree, that was the goal of the exception. Is it possible to do both at once: make it possible for these modules to either be used with or without a namespace? If you make an exception now, you will have to make it again for 6. If you make using namespaces the recommended way now for *all* modules, then at least you can be consistent for new code. For Qt 6, non-namespaced modules can then be depricated. How? The problem is that it is technically hard. The problem is the forward declared class. If you do class QSvgGenerator; That mean that class is in the global namsepcace. and lot of application writen for Qt4 do that. One solution is to deprecate forward declaration of classes, and force the inclusion of a header containing all the forward declarations. Then in Qt6 we can add the namespace. If there is no forward declaration, then one just add using namespace QtSvg, and it is source compatible (I think) But forbidding forward declaration is hard to enforce May I suggest that we have also namespace for new Qt Essentials modules? Namespace is a good C++ feature. And then, if a module move from essentials to addons during (in Qt6, or even durring Qt5 live time) it is already in a namespace. -- Olivier ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Proposed simplification for the Qt Add-On naming
On Wednesday 24 August 2011 21:45:11 Harri Porten wrote: I have a question on namespaces: On Wed, 24 Aug 2011, henry.haveri...@nokia.com wrote: Qt Add-On modules would work as follows: [...] - C++ namespace is required and it is QtPim for the Qt Pim add-on module etc. We can have convenient header files for forward declarations. - former Qt4 modules don't need a namespace Would this exception also apply to *new* modules created for *old* classes? As an example I am referring to the QSettings moved away thread which contained the suggestion of some sort of dumping ground add-on. I suppose the goal of this exception is to keep source compatibility. (forward delcaration would break if the namespace change) So I would say yes, modules which are meant to keep source compatibility should not have a namespace ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
[Qt5-feedback] QObject: new signals-slots syntax
Hi,
I Have been working on the new syntax for signals and slot.
http://developer.qt.nokia.com/wiki/New_Signal_Slot_Syntax
It looks like that.
connect(sender, Sender::valueChanged,
receiver, Receiver::updateValue );
The idea is too have more check at compile time (typos, type checking, no
issues with typedefs and namespaces)
With recent compilers, you can even do: (using lambdas)
connect(sender, Sender::valueChanged, [=](const QString newValue) {
receiver-updateValue(senderValue, newValue);
} );
More information on the wiki.
I think the code is ready to be merged in Qt5, so I made a merge requests:
https://qt.gitorious.org/qt/qtbase/merge_requests/42
Feedback welcome.
--
Olivier
___
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Lambdas
On Monday 27 June 2011 11:32:05 ext Ivan Cukic wrote: It is not possible to use latest compilers on every platform. For example, we are still stuck to gcc 2.95 for one of embedded platforms. I am aware of those situations, but I'd rather /fix/ those than to keep the code ugly just so that it can compile with an old version of gcc. (having the stuff that doesn't compile could be an incentive for updating the compiler...) LLVM doesn't support them yet, but it is not yet stable enough to compile Qt properly (acc to the project's website) Nope, clang is able to compile Qt. I've read it here http://clang.llvm.org/cxx_status.html Qt Partially compiles; miscompilation of uic prevents complete compilation, qmake works, some small examples also. But if it does work, cool :) This was in February 9, 2010, more than 1 year ago. Since then, both Qt and clang have changed. http://labs.qt.nokia.com/2010/10/29/compiling-qt-with-clang/ ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
