Re: [Development] Qt modules, API changes and Qt 6
On Sat, 26 Jan 2019, Olivier Goffart wrote: I think the "monorepo" is clearly a good approach. And git is evolving with shadow clones and partial checkout. LLVM/Clang recently choose the monorepo approach as it moves to git. Of one problem is that this will make CI integration slower because each CI run now have to test both qtbase and qtdeclarative tests. I've started to develop sympathy for "monorepos" during the last years. To counter often expressed fears like excessive build and test times one has to point out: Bigger (or even single) repositories do NOT mean - monolithic builds and test runs - monolithic packaging Developers and packagers are free to model logical segements according to their needs. Harri. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Repository request: HTTP server
On Fri, 6 Oct 2017, Tomaz Canabrava wrote: > We have recently been working on a research project looking into the possibilities for creating a lightweight server component that can easily enable Qt applications to serve over HTTP. We would like to make this work public and therefore request a repository. > > This work is intended to continue as a research project, to explore alternatives and reveal areas that need work, so it should be under qt-labs. This is not something similar to what Tufao and Cutelyst are? Perhaps it would be nice to talk to them and see if they can share code. https://cutelyst.org/ https://github.com/vinipsmaker/tufao I'll add a 3rd alternative which are have to started to use for a new product: http://www.treefrogframework.org Within open source projects- which are often created for the fun of creating something - "work together" proposals don't go anywhere however :) Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Backporting the Keccak change
On Sat, 2 Sep 2017, Oswald Buddenhagen wrote: if we wanted to be really conservative, we'd leave the old meaning of the sha3 constants and introduce realSha3 (or something to that effect) instead, in 5.10+. keccak aliases would be also provided for a smooth migration. Fwiw, I would have appreciated such a bug-compatible approach. For a new product we relied on the old SHA-3 to store hashes of data. That data is lost now. Luckily the losses were minimal and did not affect customers, yet. On the other hand: having users rely on a buggy implementation without knowing (who reads API documentation for completed code?) has its downsides as well. In that light, giving up the backward compatibility and changinging the Sha3_256 enum to intentionally breaking Sha3_256_Good+Sha3_256_Broken for the rest of Qt 5.x lifetime could have been an option, too Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9's new garbage collector documentation? + root_ptr
On Thu, 6 Jul 2017, Thiago Macieira wrote: By the way, how does it break the cycle? Like I was saying before, node_ptr enlists each pointee object to the associated root_ptr and when the root_ptr is destroyed then everything gets wiped out. See above. Your answer is "it doesn't break the cycle". Right. And from first hand experience I can report: I've tried hard to make a deterministic and quick deletion work in a JS engine (through reference counting, etc.) but always ended up with leaks. The scope of JS objects is sometimes also not limited to a single container like a HTML page. Often data can be passed/accessed to/from other containers. Thus breaking the concept of a isolated roots. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] -developer-build (was: [5.7-beta] compile error with xcode-6.4
I got reminded of something: On Tue, 3 May 2016, Thiago Macieira wrote: Still, note that this is not an error. It's a warning turned to error because of the -Werror, which means that you used -developer-build. In that case, please send a patch. :-) I've seen my Qt users use -developer-build because http://wiki.qt.io/Building_Qt_5_from_Git proposes it and the impact not clear to everyone. Qt users naturally consider themselves to be developers :) The negative impact I have seen: the lack of a following "make install" leads to a different layout of the files on disk. Still, companies are sharing such builds within their team and develop their application against it. If noone minds I'll make the wording more precise. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API/ABI changes report
On Fri, 5 Feb 2016, Thiago Macieira wrote: * QtGui: - QPixmapCache::allPixmaps(): innocent, was not public API, but you could get to it. - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility Our product (and its users) were bitten by this as well. As the function wasn't documented we took the blame on us. Renamings of quasi-public functions are something that can be avoided however :) Thanks to Andrey from me as well, Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about QCoreApplicationData::*_libpaths
On Tue, 19 Jan 2016, Marc Mutz wrote: I think we agree that std containers are in many cases faster than the Qt containers. But they are harder to use and especially developers that come from other languages often appreciate the ease of use of the Qt containers. I always cringe when I hear this. What, specifically, do you mean by "easier to use"? No-one, not even experts understand QList, really. So it may appear to be easy to use, but is actually a container only absolute experst should use. What kind of 'understanding' are you expecting? I'd say that every Qt beginner, the biggest greenhorns, 'understand' absolutely enough to use the class. And yes: that view might be incomplete and non-optimal in regards to performance or in some extreme cases. And anyone coming from a Java, JavaScript or whatever background easily finds such Qt classes documented next to the others. And appreciates e.g. a consistent API style. You may not personally like it but this individual matter of tastes cannot be fully fulfilled in a project with that many contributors and users. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about QCoreApplicationData::*_libpaths
On Fri, 15 Jan 2016, Marc Mutz wrote: And no, I cannot believe that using the Qt containers leads to faster applications. It may lead to applications faster, but not to faster applications. Amen! Now each side of the discussion please pick one of the above possible outcomes and be happy :) Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who are the right Qt developers to deal with this bug (broken keyboard shortcuts)?
On Fri, 20 Nov 2015, joh...@fastmail.com wrote: I'll contact them, and get them involved in the bug if I can, and get off this list where I don't belong -- I just need to figure out who "They" are and stop this ping-pong-ball business. Speaking of business: keep in mind that the people you spoke to might either work on KDE or Qt in their spare time. Or, they might get paid to work on Qt for commercial license holders with a support contract. Hence I can only suggest that your best chance of getting this issue fixed is a) do it yourself (I got involved in KDE and Qt like that) or b) pay someone to fix it. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Testability Driver
On Thu, 28 May 2015, Cristian Adam wrote: Does anyone know what happened with the Testablity Driver? I can only confirm what Gerry said: it couldn't keep up with the speed of Qt development. For our own tool Squish we are also kept busy constantly with advances not only in QML but especially hybrid solutions that mix in HTML content or QWidgets (or vice versa)... :} For anyone wishing to express their UI tests in an easily readable and non-tool-specific way I suggest to take a look at the Gherkin syntax btw. We just added support this kind of behavior-driven testing: http://doc.froglogic.com/squish/6.0.0/bdd-tutorial-implementation.html Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Switching remote url for qt5 git clone
On Thu, 26 Mar 2015, Adam Light wrote: I'd like to move my checkout to git://code.io.qt. I got reminded of your mail when I just did a new clone: http://wiki.qt.io/Building_Qt_5_from_Git suggests the usage of: git clone git://code.qt.io/git/qt/qt5.git but the /git/ part is probably just an oversight? Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [RFC] more gerrit codereview scores?
On Fri, 6 Mar 2015, Oswald Buddenhagen wrote: 1) i'd like to propose the introduction of the code review score -3. I often wished for Gerrit have a non-sticky -2. The proposed introduction of -3 is a good solution. 2) i'd like to propose the introduction of the code review score +3. Could also be helpful. But does require a bit adaption to the approver's work flow. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] possible change in behavior: QGuiApplication::primaryScreen() can return null
Hi! I see that the first decisive commit is already merged but I'd like to comment on it anyway: On Mon, 2 Mar 2015, Rutledge Shawn wrote: It may be a surprise though, for some applications, that QGuiApplication::primaryScreen() can return null in the case where there is really no screen attached. It’s a rare use case, but it’s possible that some applications could crash if they are using that pointer at the wrong time, without checking. And there are also some platforms where a dummy screen will normally exist even if no actual monitors are connected. It’s just that it doesn’t seem to be necessary to have one on xcb, so we are trying to avoid needing to create one artificially. It seems right to have the code modeling the real world: if there is nothing on which you can view the graphical output of your application, then there should not be a QScreen instance. Does anyone have any objection? I would favor an invalid QScreen instance to be returned instead. At least from the public QGuiApplication API. A function that maybe returns null on some platforms puts an onus on a diligent developer using this function. Thus work is created for everyone to cover a scenario that will happen for a very few in very seldom cases. Our own software was not prepared for a similar case until last week: we relied on the xcb plugin returning an X11 Display pointer when querying it for display. Until the first customer had build Qt without xlib support... Harri. PS: The documentation of the (internal) QPlatformWindow::screen() implementation would need updating too: https://codereview.qt-project.org/#/c/87885/20/src/gui/kernel/qplatformwindow.cpp___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Sun, 18 Jan 2015, Kevin Kofler wrote: Thiago Macieira wrote: The one requirement that came from the Qt Project was that the tools would not be renamed. And the one requirement that came from the distros was that the tools must be renamed. This was made very clear from the beginning. All other solutions are and will always be inherently flawed. You also never gave any convincing argument as to why you refused to rename the binaries. Distributors are going a great job creating Qt packages. But not everyone is using their distro's Qt. In fact, looking at our customers I'd say that most of them have their own Qt install somewhere on their disk. Possible several installations even. Renamed binaries won't cope with that variety. Our product relies on a --with-qmake switch or PATH for selection. Version detections follows wherever named. Renamed binaries won't help. Or even make our life harder as it needs to be. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Wed, 15 Oct 2014, Smith Martin wrote: But maintaining binary compatibility is now a necessary facet of software engineering, so maybe it is time for the C++ standard to support it. A keyword could be added to the parameter declaration, compatibility or placeholder for example, could precede a parameter declaration that is kept for binary compatibility. The compiler would not warn that the parameter was not used. ... and emit an error if it is :) Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On Mon, 29 Sep 2014, Simon Hausmann wrote: Yes, with emphasis on until. Note that we are now talking about the end of the application situation, so our agreement ends right there ;-). We are talking about the time the QQmlEngine destructor is executed, which from a QML engine perspective is the end of the application point of time. What happens during that period of time is just as fishy as when tearing down a C++ application: The order of destruction for global objects between several compilation units is undefined. In C++ you cannot rely on it (I think you can rely on the order within a unit), so you prepare yourself with levels of indirection and/or weak references. I was thinking the same for a long time. Until I discovered (the hard way) a that at least one aspect of the C++ behavior is standardized: the order of destruction is guaranteed to be the reverse of the construction (see [basic.start.term]). I ran into this because of a singleton being encapsuled within a function using a 'static' object. The crashes upon application exit seemed arbitrary at first but turned out to be well-defined :) Which deletion order is the best for QML... maybe it can't be changed anymore. I'd just generally vouch for a *defined* order (even if problematic) rather than an undefined one. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Python required to build Qt from source packages
On Fri, 28 Feb 2014, Thiago Macieira wrote: Em sex 28 fev 2014, às 18:30:24, Hausmann Simon escreveu: Note that this is not a new dependency but has been there since Qt 5.0.0 (when v8 required python) Right. But now we need Python for a single file, in something that is almost entirely under our control. Any chance we can remove the build-time dependency? If not, then Laszlo's previous offer of rewriting syncqt in Python becomes a lot more attractive. JavaScript is no option? Our product bootstraps an interpreter (Qt has several;) that can be used to perform such build tasks. No other requirements. Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] isValid() as a property
On Fri, 29 Nov 2013, Tony Van Eerd wrote: in the cases I am looking at, if isValid() == false, then all the other properties are invalid, and return , -1, etc. It really does mean the whole object is invalid. (except maybe an 'id', in the case of, say, a Battery object - the id telling you which battery, and then isValid() saying that battery doesn't (currently) exist.) Why not use exists, present, active or something like it? But a C++ object for a physical object that does not exist... why is it there in the first place? Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] ABI of deprecated supportsThreadedFontRendering()
On Thu, 10 Oct 2013, Olivier Goffart wrote: Removing inline is not enough. One need to put back the definition in the .cpp file. Please fill a bug report. (or a patch :-)) https://codereview.qt-project.org/#change,67867 Confirmed with nm on Linux. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] ABI of deprecated supportsThreadedFontRendering()
Hi!
I just learnt about what looks like an ABI regression in Qt 5.2:
The function QFontDatabase::supportsThreadedFontRendering() got deprecated
in 5.2 with commit b0b786a2f05e9451a65519ab8904f55c35f51b7d:
-static bool supportsThreadedFontRendering();
+#if QT_DEPRECATED_SINCE(5, 2)
+QT_DEPRECATED static inline bool supportsThreadedFontRendering() {
return true; }
+#endif
At the same time it got inlined. At least with MinGW this made the symbol
go away. While e.g. MSVC still exports it.
Now I don't know the exact strategy pursured by QT_DEPRECATED but I assume
that the function's symbol should not disappear from the 5.2 ABI? If so,
I wonder whether removing the inline will already do the job.
Harri.
___
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 Sat, 7 Sep 2013, Konstantin Ritt wrote: one would probably prefer [code] job = someoperation(some parameters); manager-enqueue(job); [/code] , where someoperation could be manager's registered job factory or QJob sub-class, etc. I am not sure why everyone prefers to have a manager ;) This way, job not necessarily should derive from QObject; all required signals and methods could be provided by some kind of job watcher [or job sequence watcher] or even by the manager itself. That limits the available API to the lowest common denominator, no? No job-specific features available unless some typeless QVariant properties or similar are used. Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Developer build (was: 6 conflicting symbols between QtQuick 1 and 2)
On Tue, 7 May 2013, Koehne Kai wrote:
Since apparently nobody has picked the ball up, I uploaded
https://codereview.qt-project.org/#change,55521,patchset=5
We can confirm that the patch achieves the intended goal of namespacing
the discussed symbols.
It's just that one should restrain from using developer builds. Those will
have some internal classes like QSmoothedAnimation exported that can again
cause a jump from one library to the other. See the (...) notes added to
#7-12 of the following backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb52c0940 (LWP 7007)]
0xb75f83f8 in QListData::isEmpty (this=0x85f7f84)
at ../../include/QtCore/../../src/corelib/tools/qlist.h:91
91 inline bool isEmpty() const { return d-end == d-begin; }
(gdb) bt
#0 0xb75f83f8 in QListData::isEmpty (this=0x85f7f84)
at ../../include/QtCore/../../src/corelib/tools/qlist.h:91
#1 0xb78305ad in QListQObject*::isEmpty (this=0x85f7f84)
at ../../include/QtCore/../../src/corelib/tools/qlist.h:154
#2 0xb7826b7e in QObject::~QObject (this=0x85f7e84, __in_chrg=optimized out)
at kernel/qobject.cpp:856
#3 0xb7836d9e in QTimer::~QTimer (this=0x85f7e84, __in_chrg=optimized out)
at kernel/qtimer.cpp:154
#4 0xb6ba743a in QSmoothedAnimation::~QSmoothedAnimation (this=0x85f7de8,
__in_chrg=optimized out) at
/home/roy/qt/qt5/qtbase/include/QtDeclarative/5.1.0/QtDeclarative/private/../../../../../../qtquick1/src/declarative/util/qdeclarativesmoothedanimation_p_p.h:68
#5 0xb6ba748d in QSmoothedAnimation::~QSmoothedAnimation (this=0x85f7de8,
__in_chrg=optimized out) at
/home/roy/qt/qt5/qtbase/include/QtDeclarative/5.1.0/QtDeclarative/private/../../../../../../qtquick1/src/declarative/util/qdeclarativesmoothedanimation_p_p.h:68
#6 0xb49b6df7 in QAbstractAnimationJob::setState (this=0x85f7de8,
newState=QAbstractAnimationJob::Running) at
animations/qabstractanimationjob.cpp:344
#7 0xb49b7450 in QAbstractAnimationJob::start (this=0x85f7de8)
at animations/qabstractanimationjob.cpp:486 (libQt5Qml)
#8 0xb6698fe9 in QSmoothedAnimation::restart (this=0x85f7de8) at
util/qquicksmoothedanimation.cpp:115 (libQt5Quick.so)
#9 0xb67d94af in QQuickListViewPrivate::updateHighlight (this=0x85adb90)
at items/qquicklistview.cpp:927
#10 0xb68269d5 in QQuickItemViewPrivate::updateCurrent (this=0x85b5820,
modelIndex=0) at items/qquickitemview.cpp:1607 (libQt5Quick.so.5)
#11 0xb68259e0 in QQuickItemView::componentComplete (this=0x85b57c0) at
items/qquickitemview.cpp:1406 (libQt5Quick.so)
#12 0xb486c519 in QQmlVME::complete (this=0x85d2694, interrupt=...) at
qml/qqmlvme.cpp:1346 (libQt5Qml.so)
But the main goal has been reached to ensure a co-existance in deployed
binaries. Having problems with a developer build is not nice but I assume
that it's of lowered importance and may not warrant further symbol
renaming.
Harri.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick1 and 2
On Thu, 9 May 2013, 魏越闽 wrote: I have a crash issue when use QtQuick2 and QtQuick1 together: https://bugreports.qt-project.org/browse/QTBUG-31064 Shall I try out this patch https://codereview.qt-project.org/#change,55521,patchset=5 ? Yes, please. We'll hopefully have our own test results available by Friday. Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] 6 conflicting symbols between QtQuick 1 and 2
Hi! Don't ask why but we ran into the known[1] segfault caused by symbol name conflicts between Qt5Qml and Qt5Declarative. Checking the symbol tables it appears to because by 6 symbols only: qmlContext(QObject const*) qmlExecuteDeferred(QObject*) qmlAttachedPropertiesObject(int*, QObject const*, QMetaObject const*, bool) qmlAttachedPropertiesObjectById(int, QObject const*, bool) qmlInfo(QObject const*) qmlEngine(QObject const*) At least for non-VS compilers the partially different return types (QQml* vs. QDeclarative*) don't help with having a different symbol name mangling. At the same time the functions cannot be used interchangeably either. So I assume that this conflict was a simply copypaste oversight during the porting. I have not checked the respective use cases of the functions but I guess that they are internal to Qt despite being exported? Anyone sees a problem with renaming the functions of v1 or v2 to make their names unique? If not, we'll prepare a patch and present it. To stress one point: we are not attempting to run both types of GUIs in a single application. We'd just like to have the possibility to have the two libraries co-exist and optionially be used. Harri. [1] https://bugreports.qt-project.org/browse/QTBUG-29584 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating Serializing Qt Data Types documentation
On Wed, 24 Oct 2012, Jedrzej Nowacki wrote: I added that tests durring Qt5 development, sadly streaming was never tested with older versions. What is the bug, can I help somehow? Is it only Qt5 or Qt4 too? We found the reason now: https://bugreports.qt-project.org/browse/QTBUG-27700 Streaming of invalid QVariants with Qt 5 for older versions does not work anymore. The test attached to above report isn't really elegant, yet. We'll improve upon that and try to submit a patch. Stay tuned. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating Serializing Qt Data Types documentation
On Tue, 23 Oct 2012, Mitch Curtis wrote: After https://codereview.qt-project.org/#change,37988, the Serializing Qt Data Types page lists the QDataStream version as 13. I thought it'd be a good idea to ask everyone who is interested to take a look and see if the descriptions of the data types serialised are still accurate. If they're not, please update the page (the path to which can be found in the aforementioned patch). Coincidentally we noticed a over-the-wire serialization problem today. With QVariant. But it's likely not an issue with above mentioned format version 13. Rather with a backward compat mode. Do I see it correctly that tests/ only cover 4.9 and 5.0 versions? Hmmm. I now realize that I can answer this question myself given that the coverage results we just posted... http://download.froglogic.com/public/qt5-squishcoco-report/QtBase/source_143.html (see QVariant::load() and save()) We'll investigate what's going on and submit a patch if it's a problem in QVariant or QDataStream. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Code coverage statistics online
Hi! We started publishing code coverage results of Qt 5 unit test runs as produced by our tool Squish Coco: http://download.froglogic.com/public/qt5-squishcoco-report/ (results) http://download.froglogic.com/public/effectively-testing-qt5-using-squishcoco/ (setup and example) From that link you can browse to the coverage data of libraries, functions and source files. We chose a decision/coverage analysis method. In comparison to line coverage this is a bit harder to grasp and gives different numbers but for a developer it's the more useful. I plan to follow up with a study of a small number of exemplaric cases accompanied with suggested patches to tests and maybe code. And to make things easier to understand in the mostly-static HTML output we'll also improve the coloring of instrumented branches soon. Provided that the cron job works the results will be updated daily. If anyone has an idea how this could be integrated more tightly with the automated Qt project test results please let us know. Caroline Chao was already using a predecessor of the tool for the same purpose within the Nokia build infrastructure btw. Feedback of any kind is welcome. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Hi! On Wed, 27 Jun 2012, Thorbjørn Martsum wrote: I do think that it would be a very good idea to have a QtWidget maintainer. Not because Girish isn't a good approver (since he obviously is) - but in order to ensure that people sees QtWidgets as alive. One of the reasons people consider Qt Widgets as dead (and can argue that they are) - is the lack of a maintainer(!) - and it would be far easier to spread the word about QtWidgets if we had a such. Yes. And to be realistic: a single maintainer won't be enough. It's a lot of different fields that might need to be distributed on several shoulders. So even if some individual or company steps up one has to be fair and rather help than demanding too much. But of course the Widgets are still alive - and Stephen Kelly is also helping improving the Item Views in Qt Widgets - and afaik there has been some nice fixes. To brag a bit I have (with his help) improved QHeaderView so that TableViews can handle many data and unlike Qt4 do moveSection, swapSection(s), hideSection and trunc of model reasonable fast. (Hopefully without any regressions:) ) Nice to hear. However - the above is actually not just to brag. It is to give an example of something that has been improved. We need to show and know(!) about QtWidgets progress. It is easy to state: Qt is alive - but someone could ask ... why?. (And the reason 'it wasn't killed is not enough ...). So if people knows about big (or many) improvements to QtWidgets - it could be a good place and time to speak up. Right. That was the main message we wanted to bring across. To state that a positive feedback loop rather than a negative self-fulfilling prophecy is needed and doable. So here is a good chance for people to give credit to themselves (or others) Btw. Is somebody looking into the regressions in QGraphicsView? As Marius already hinted at: it's needed. But given the complexity no easy job. A full-time job maybe. Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCore: qt_addObject and qt_removeObject
On Thu, 3 May 2012, Thiago Macieira wrote: My suggestion is to replace them by callbacks and keep the setters in a private header. Someone is against this idea? Not at all. I suggested that the Squish and Gamma Ray developers get together and put together a proper callback implementation set, which we'll gladly use in Qt 5. I don't think that is high in their priority list, though. Oh, I missed that call. But we are happy to participate in a discussion. In Berlin for example. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removal of QWorkspace? (superseeded by QMdiArea since Qt 4.3)
On Fri, 9 Dec 2011, Friedemann Kleint wrote: I was wondering if the QWorkspace-widget should be removed in Qt 5. It has been out of maintenance for a long time. Still heavily in use in the real world however. Harri (representing several customer's interest). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTemporaryDir API
On Wed, 16 Nov 2011, David Faure wrote: Thiago suggested that I post the header file here, to see if anyone had feedback on the (rather short) API. Actually I'll post the .cpp file too, since the documentation of the API is there :) I tried without the documentation. Feedback based on that: 1.) I found the argument name templateName a bit confusing as it could also refer to the name of a template. How about nameTemplate? :) QTemporaryDir(const QString templateName); 2.) I cannot remember details of Qt's naming policies anymore but autoRemove() very much sounds like an action. isAutoRemoved() would be clearer? The auto abbreviation is still questionable. 3.) Shouldn't QTemporaryDir::removeDir(const QString path) rather be a removeRecursive() function in QDir? Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
