Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
> yeah, 6.0 is a joke given that you intend to break binary > compat in 6.1 - that's the wisdom of linking r's bonus payments to > release dates even for major versions Thank you for saying what no one else dared to say. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
On Fr, 2020-12-04 at 07:42 +0300, NIkolai Marchenko wrote: > Let's be honest with your users: > P0: almost sure to block a release. > P1: We will act on it if the maintainer is in the mood some day when it's > still fresh > P2: We will fix it, maybe > P3: thank you for informing us. Funny, this is pretty much how I would phrased it as well. -- Best Regards, Bernhard Lindner signature.asc Description: This is a digitally signed message part ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Long-lived P1 issues
> ... resulting in users complaining about "high priority bugs get ignored". They're still complaining? Impressive. I have already passed the phase of resignation and just wonder why there is still a public bug tracker. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant comparison in Qt6
> What is it you need? Just some total ordering of variants? The method you > mentioned in > QAbstractItemModel also only does ordering for some types, otherwise falling > back to > strings. I am using QVariant comparison (==, >, <) only for equal types. But not in models. I use it for other code. I also use QMaps of QVariants, but also not for mixed types, only for equal types. So I need ==, <, > for equal types, including custom types. My preferred solution for error handling wouldn't be a fall back to "return false" but a call to qFatal (or at least qWarning). -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QVariant comparison in Qt6
> > Has anything changed for Qt6 (especially regarding comparison of equal > > and/or convertible types)? Is the complete deprecation still the latest > > decision? > > Yes, it's changed; no, it's not deprecation. > > What's been removed is the conversion. Aside from the numeric types, > comparing > two variants of different types will always result in false. If you want to > compare across types, convert one to the other's type or to a common third > type. You know what data you put in there and you should know what > conversions > can be lossy or not. That would be much better than deprecation. What about Qt 5.15? If I understood correctly, Qt 5.15 should prepare developers for changes/deprecations/removals in Qt6. So I guess things that will remain part of Qt 6 should also be part of Qt 5.15. Still Qt 5.15 gives me warnings about deprecation of operator < for QVariant. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QVariant comparison in Qt6
Hi! There was a discussion about the decision to deprecate (remove?) QVariant comparison (<,>) in Qt6 completely. Has anything changed for Qt6 (especially regarding comparison of equal and/or convertible types)? Is the complete deprecation still the latest decision? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
> > Couldn't those subtle errors be replaced by some clear and understandable > > error? Like some explicit binary compatibility check? > > Such a test does not exist, comprehensively. We can put a few common things > in > an ABI marker, like the size of QObject, the actual type qreal maps to, the > name of the C++ standard library we linked against, etc. But that won't catch > everything and it's the minor things that come back to bite you. > > Neither the ABI test by the Linux Foundation, nor abigail, nor our own > tst_bic > are exhaustive. And they're way too slow for a regular run. I thought of something like a simple, manually maintained ABI version. Sure, on the one hand this wouldn't prevent uninentional BC breaks. On the other hand, BC changes could be done intentionally and managed in a safe way (without strange crashes). -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QProperty and library coding guide
Hi! > Breaking BC means subtle errors that are hard do detect and debug. Couldn't those subtle errors be replaced by some clear and understandable error? Like some explicit binary compatibility check? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] ?==?utf-8?q? First Qt6.0.0 Snaphot available
On Monday, June 15, 2020 14:06 CEST, Jani Heikkinen wrote: > Hi Everyone, > > We have published first Qt6.0.0 snapshot today, see more info from Tuukka's > blog post: https://www.qt.io/blog/first-qt-6.0-snapshot-available Hi, is the source available somewhere? Can't find any 6.0 tarballs on download.qt-project.org yet. Would be nice to keep the snapshots in sync... ttyl bero ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] ?==?utf-8?q? Determining what versions of imports a QML module provides
Hi, On Monday, February 24, 2020 18:19 CET, Ulf Hermann wrote: > > Is there a better way to determine what modules are provided? > > You could scan the plugins.qmltypes files. There you get a detailed > listing that tells you what components are available under what imports > and versions. That was my first thought (before looking at the qmldir files) as well, but it doesn't seem to help with the same modules that are problematic with the qmldir scanner. e.g. QtQuick.tooling: $ find /usr/lib64/qt5/qml -name plugins.qmltypes |xargs grep tooling |grep -vE 'qmltypes:(//|import )' $ I also don't see the version number for the QtQuick import - e.g. $ find /usr/lib64/qt5/qml/QtQuick* -name plugins.qmltypes |xargs grep '2\.15' only shows some submodules. Am I doing something wrong? Best regards bero ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Determining what versions of imports a QML module provides
Hi, I'm adding a Requires:/Provides: autogenerator for QML modules to rpm (so packages containing a qml file will automatically pull in the right library dependencies). I have a more or less working prototype that extracts relevant information from qmldir files, but given "module" statements in qmldir don't have version information attached to them, there's no way to figure out that e.g. qtdeclarative 5.15 provides QtQuick 2.15 (and not any other version number). Leaving version numbers aside, I also don't find a few submodules (that can be imported) by scanning qmldir files -- e.g. QtQuick, QtQuick.tooling, QtQuick.Window. Is there a better way to determine what modules are provided? Best regards bero ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
I agree completely with Jason. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] char8_t summary?
> please, if it can be avoided, don't add yet another string-related class to > Qt. Knowing > when to properly use QString, QByteArray, QLatin1String, QStringLiteral, > QStringRef and > QStringView (I may have missed a few) is already a challenge. And I imagine > for people > new to Qt it can even be a strong deterrent (after all, strings are something > you tend > to use even in a simple Hello World - the first app most people see or write > in a new > language/ framework). I totally agree. Maybe this helps (I could not find such a document): https://bugreports.qt.io/browse/QTBUG-77020 -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
> * enable templated QObjects. There's a prototype from Olivier, so is that > possible? Yes, this is long overdue. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
> The "mixed signal" here is that someone in an ivory tower decided to > deprecate something but was not able to offer a viable alternative. > > Either because there simply was none (in which case the deprecation was > wrong, and should be undone) or because the work-around was too much hassle > (in which case the deprecation was wrong, and should be un-done) or for some > other reason that nobody cited so far. > > As a matter of fact, some of the previous deprecations, e.g. the removal > of qalgorithm, triggered re-implementing the deprecated functionality > downstream, effectively shifting the burden of doing (or, rather, > *keeping*) them once centrally to all users who need it decentrally. > > All in all, this is devaluating the overall Qt offering. I couldn't agree more. Deprecating a component without (equal or better) replacement is an MCA in my book. And it heavily damages Qt's reputation. The criteria that allows to deprecate a component without proper replacement should be EXTREMELY defensive. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt 6 story
> Actually each major release should have a story, that has to do with > some sort of innovation that might require to remove old stuff. Very good statement. The current implicit stories seems to be: "Throw out some parts we can't afford" and "Replace the builds system". Which are both not a very attractive from the application developers point of view. Did I miss something? What would be your story proposal? "Make Widgets great again"? "Modernize the language to C++17" would be a possible story as well (especially teaching moc to handle templates). Any proposals for a Qt 6 story? I hope my suspicion is wrong that Qt has spent so much on a few cash cows that it is no longer capable of any other major advances (but must even go backwards, see XML thread). -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
> > > > So, yes, this is borne out of frustration with the lack of maintenance > > > > of QtCore plumbing. I don't see that changing and I acknowledge and > > > > understand that the focus of development has shifted towards QML. > > > Suppose you implement all planned actions for Qt6 (see your original > > > e-mail). Are > > > the > > > remaining components (those that are neither deprecated nor removed) of > > > Qt6 well > > > maintained and are there enough staff available not only to maintain them > > > indefinitely > > > but to actively develop them further? > > > > No answer to my question above? > > Who do you expect an answer to this question from? > > The Qt Company? The Qt community? Marc? Thiago? Whoever believes being able to make a realistic assessment. If there is no such person/group in this list, which can do an estimate how much of Qt is affordable, an important aspect of the Qt 6 discussion can not actually be discussed. How can Marc think about removing (or significantly changing) Qt due to ressource limits or new strategic goals if the limits or goals are unknown? Actions out of frustration are never a good idea. And pushing into a (technical) direction that does not solve the underlying (strategical) problem is futile. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
Am Mittwoch, den 29.05.2019, 23:34 +0200 schrieb Mutz, Marc via Development: > > So, yes, this is borne out of frustration with the lack of maintenance > > of QtCore plumbing. I don't see that changing and I acknowledge and > > understand that the focus of development has shifted towards QML. > Suppose you implement all planned actions for Qt6 (see your original e-mail). > Are the > remaining components (those that are neither deprecated nor removed) of Qt6 > well > maintained and are there enough staff available not only to maintain them > indefinitely > but to actively develop them further? No answer to my question above? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
> So, yes, this is borne out of frustration with the lack of maintenance > of QtCore plumbing. I don't see that changing and I acknowledge and > understand that the focus of development has shifted towards QML. This exactly is the core problem. There are many things I could say about this. Allow me one question instead: Suppose you implement all planned actions for Qt6 (see your original e-mail). Are the remaining components (those that are neither deprecated nor removed) of Qt6 well maintained and are there enough staff available not only to maintain them indefinitely but to actively develop them further? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
Hi! > For Qt XML Patterns, the situation is IMO a bit different. The module has > some architectural problems Do you think this is true for all parts of the component? I am asking because I can not imagine using XML without a schema validator, which is part of Qt Xml Pattern. Do you consider it broken? I consider that class fundamental. Using XML without using a schema validator is (or at least should be) a no-go. So even if the Qt XML component should be continued in some way, Qt should also not lack a schema validator. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
> It's good that Bernhard has received an official statement. I agree! Thank you! > In general, I think the Qt Company could make a little more effort to > communicate such decisions, educate its user community, and attract new > potential maintainers. Actually, communication should start before a problem > results in a decision. Isn't that an important aspect of community building? Agreed as well. Assuming that Qt Xml is deprecated as well (still not sure) this is the fourth time a deprecated component tears major holes in my applications. Regarding Qt Xml and Qt Xml Patterns it surprises me a lot since I consider them essential components. I will use the stream classes under no circumstances. This means in my book Qt does not support one of the most important techniques (XML) anymore. Hard to believe. Obviously "no maintainer" is enough for a deprecation. This means (at least for new code) there is no significant difference (only a delay) between "no maintainer" and "deprecated". Thiagos criteria sounded ok but obviously they are not valid anymore. Qt must to be in a very strong market position if such a strategy is accepted. -- Best Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
> I think both XML and XMLPatterns are Done, not Deprecated. What a relief! > Reasoning: only the former has an explicit note in the documentation > (can't find an equivalent for the latter): > > > https://doc.qt.io/qt-5/qtxml-index.html > > https://doc.qt.io/qt-5/qtxmlpatterns-index.html > > But especially: neither is marked as deprecated in > > > https://doc.qt.io/qt-5/qtmodules.html Never noticed the "deprecated" tags. Do you think a separate, more detailed status column would be useful for that table? Plus Thiagos status explanations? > So where and when exactly it has been decided that XML patterns is > getting deprecated in 5.13? There is a second very interesting question: Why does the "explicit note" in the documentation recommend replacement classes (i.e. the streaming classes) for Qt Xml if it is "Done" and not "Deprecated"? Appart from the fact that this is technically suspect, now it seems completely wrong in regard to the status. It appears Qt Xml actually was marked deprecated in code once which was reverted later. I just browsed the web a little. It is deprecated: https://wiki.qt.io/XML https://lists.qt-project.org/pipermail/interest/2013-August/008183.html https://community.kde.org/Qt5/Documentation/OverviewClassification#QtXML_.28deprecated.29 https://bugreports.qt.io/browse/QTBUG-71784 It is done: https://bugreports.qt.io/browse/QTBUG-32926 The confusion is perfect. Especially notice issue 71784 above. That is what I talked about earlier when I said without clean documentation you can not do clean Qt6 planning. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
> Qt modules and features can be in one of 5 states: > > - Active Development > Receiving new features, changing quickly, bugs fixed > - Maintained > Receives occasional features, changes slowly, bugs fixed > - Done > No new features, changes very slowly, P2 bugs and up fixed only > - Deprecated > No new features, almost no changes, P1 and security fixes only, > new code should not use it, old code should begin porting away > - Removed > Self-explanatory and not coming back Very helpful! Thanks a lot! This is exactly what should have been written at that Wikipage. Maybe the documentation would be an even better place. People would get a component status update with each Qt update: Component status table plus the above description how to interpret the status. I mean, that is really important. Why not placing it in the documentation instead of ambiguous sentences like the one I cited? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
> Yes, they were done, not deprecated. See > https://wiki.qt.io/Qt_Modules_Maturity_Level That is good news! In https://wiki.qt.io/New_Features_in_Qt_5.13 it says Qt XmlPatterns would be deprecated. Somebody in the interest list pointed me there. Also I heard a lot (and it is written in the documentation) that Qt Xml should not be used anymore, but the stream classes. If the state is "done", not "deprecated", there is no reason for that! Maybe this should be communicated and documented more clearly. Such news have a user side impact like a nuke! > I don't think the "Done" nomenclature stuck though. In half the cases it > just meant unmaintained rather than actually done. That document should be revised. It obviously is very important. How can you even do strategical planing without such a fundamental document? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
> > Unlucky me. Deprecation of these two components literally broke every > > application I have ever written using Qt. I hope they will have new > > maintainers some day. > > Note I said QtXml is deprecated, but it might actually be in Done state. I > don't remember. Does anyone? Where's our authoritative source? > > The difference between Done and Deprecated is whether we're telling you to > start porting code away. Heck, yes, that would be a big difference. Documentation says about Qt Xml "not actively maintained anymore"… whatever that means. I heared about "deprecated" and, well, not deprecated. I had no idea there is such a state like "Done". I could live with "Done". But a "deprecated" component makes me lamenting when I relied on it. Is there some document describing the states and their meaning? Is there a component/state table where we could lookup the specific states? -- Best Regards, Bernhard Lindner signature.asc Description: This is a digitally signed message part ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
Hi Thiago! Thanks a lot for the information! However, the streaming classes are absolutely no replacement for the DOM classes. In theory yes, they both read and write XML. In reality they are different to a degree that it is practically impossible to replace DOM by stream. For legacy code anway. Even for new code the stream API is simply to bad to use it. Appart from speed, DOM is far superiorer for every use case. The resulting code is, compared to the DOM solution, impractical and maintaining it is a pain. Unlucky me. Deprecation of these two components literally broke every application I have ever written using Qt. I hope they will have new maintainers some day. > > Is it correct that the Qt XML and Qt Xml Patterns components are both > > deprecated? > > Yes, they are. > > > > > If yes, are there any details known like: > > - How long or up to which Qt version will these components be part of Qt? > > - Will replacment components be available? > > The replacement for QtXml are the streaming classes in QtCore. They've been > available for 10 years. > > There is no replacement for the XMLPatterns module. > > > - Are security fixes still be implemented? > > Yes, definitely, for as long as we ship them plus 5 years. > > > - Are the deprecations irrevocable? > > No. Deprecations are only irrevocable when we want to get rid of code that is > in the way of making progress, such as the QList discussion. Those two > modules > are not in the way of anything else, so the decision can change. > > All it takes is someone stepping up to maintain either or both of them. > -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt XML and Qt Xml Patterns
Hi! Is it correct that the Qt XML and Qt Xml Patterns components are both deprecated? If yes, are there any details known like: - How long or up to which Qt version will these components be part of Qt? - Will replacment components be available? - Are security fixes still be implemented? - Are the deprecations irrevocable? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
> There is no readability difference between the use of a Qt container and > that of an STL container. Don't confuse familiarity with > simplicity. That is true. You can get familiar with both, STL and foot fungus over time. But both will remain disturbing forever ;-) I used STL from time to time. And I found that it does not matter how often I used it... it still remains hard to read. I mean, "pop_back" vs. "removeLast"?! Seriously?! "pop back" sounds funny but it is not easy to read! I case intuitive naming does not matter for you... Then compare this thread/answer: https://stackoverflow.com/a/18549053/1421332 With this thread/answer: https://stackoverflow.com/a/421615/1421332 And, LOL, do not skip the comment below the first answer! Nothing more to say. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
> I've done this experiment for QMap / QHash / QSet, where keeping COW at > the cost of an extra indirection (dptr -> [refcount + std:: class] -> > actual data) is more acceptable since these classes jump all over the > memory anyhow. Basically "it worked", still requiring a few changes > though, e.g. std::unordered_map iterators are forward, QHash ones are > bidirectional. If the SIC is acceptable, something to consider for Qt 6. Are there any plans/discussions how to procede with that experiment? -- Best Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
> you end up where the STL is - so convoluted it's hardly worth making > anything with it. I agree. The horrid of STL was one of the reasons for me to use Qt. Everything is complicated to the maximum in STL. Qt is so much more intuitive, it is fast to learn and fun to use (except when hitting a long reported bug... again). On the other hand, when reading the ML threads about containers in Qt and their limited STL compatibility, plus the QList issue, plus the need to update containers to x64, plus the fact that the Qt project has not enough man power to do everything that should be done... I start wondering if it is possible to wrap the STL containers in Qt6 and give them a nice, intuitive, Qt-like API while still providing full STL compatibility. I am sure this has been evaluated. Are the results documented somewhere? -- Best Regards, Bernhard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt online SDK security problems
Actually the Qt update behavior annoys my as well. I wish there would be two checkbox options in the maintenance tool: "Install new bug fix versions automatically" "Install new minor versions automatically" This is reasonable, isn't it? -- Best Regards Bernhard Lindner > > As I said, they still have the possibility to install a specific Qt version > and stick with it. The installer will not force them to use the latest > version! If some companies prefer to use outdated software which might have > security issues is their choice, what I'm asking is for an easy way for the > other companies/people to use the latest Qt versions. > One of the biggest problems when installing multiple Qt versions is that > you > end-up with multiple Kits in QtCreator. Small projects can switch from one > kit > to another very easy, but complex projects which need lots of custom qmake > params or custom Build/Run steps are not that easy to swicth to another Qt > version. > Last but not least, it's a waste of disk space. Just ~/Qt/5.12.2 > (android_arm64_v8a+android_armv7+gcc_64) installation has 1.7GB. > > Cheers, > BogDan. > > În ziua de joi, 18 aprilie 2019, la 11:18:30 EEST, Maurice Kalinowski a scris: > > Hey, > > > > Disclaimer: I am not involved in the decision making process for this > > update. > > > > However, one frequent feedback has been, that users (customers) did not like > > the fact that the installer changed the specific Qt version "under the > > hood". > > It was specifically requested that each user has to select the > > version to use. This is related to the fact, that many companies decide on > > one version and updating to a new one involves quite a lot of QA and other > > processes. Only then, developers are allowed to switch to a newer version. > > This is (IIRC) why the installer switched to this approach. > > > > I can see your point as well, especially when your project is flexible > > enough to update dependencies. But that is not the case for many projects > > out there. > > > > BR, > > Maurice > > > > > > > > > -Original Message- > > > From: Development On Behalf Of > > > BogDan Vatra via Development > > > Sent: Thursday, April 18, 2019 9:24 AM > > > To: development@qt-project.org > > > Subject: [Development] Qt online SDK security problems > > > > > > Hi, > > > > > > > > > Long time ago the Qt online SDK used to help the users to use the latest > > > and > > > the safest Qt version all the time. Sadly that was changed, IMHO without > > > too > > much thinking, and now a lot of users (I'm one of them) are stucked > > > with outdated versions. A few days ago I installed 5.12.2 and today > > > suprise is outdated again. It’s just ridiculously, I have five 5.9.x, > > > 5.10.0, two 5.11.x and three 5.12.x versions, but NONE is latest version! > > > Not a single one! > > > > > > I propose to go back to the good old times when the Qt online SDK was > > > safe > > > > > > and helpful. > > > > > > > > > I'm not against to have a chooice to install a specific version, what > > > I'd like is > > > to install e.g. 5.12 version and the online installer will update it with > > > the latest > > 5.12.x version automatically. > > > > > > If an user, for some reason, want's to install a specific version he can > > > pick it > > > from new "Archive" section. > > > > > > > > > As I commented in > > > https://blog.qt.io/blog/2019/04/11/updated-qt-installer->; > > > > released/, as a Qt maintainer, I wonder quite often, if it's worth to > > > spend > > time to fix bugs that will go in revision/micro versions as long > > > as even I, as a Qt maintainer, don’t use them! I imagine that the > > > percentage of Qt users that are using the latest Qt versions is very low… > > > > > > > > > Having said that, pretty please with sugar on top consider to add the > > > > > > needed support to help the users to always use the latest and the safest > > > Qt > > version. > > > > > > > > > Cheers, > > > BogDan. > > > > > > > > > ___ > > > Development mailing list > > > Development@qt-project.org > > > https://lists.qt-project.org/listinfo/development > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Continuous Integration for 3rd party projects using Qt
Why not use one of the continous integration services like travis-ci or circle-ci? Cheers, Bernhard Uwe Rathmann schrieb am So., 17. März 2019, 14:55: > Hi, > > all arguments for doing Continuous Integration for Qt ( https:// > blog.qt.io/blog/2016/08/08/coin-continuous-integration-for-qt/ ) are also > valid for 3rd party code using Qt. > > F.e. with Qwt ( https://qwt.sourceforge.io ) I'm supporting trillions of > environments I have never seen myself. Actually I'm using Linux/gcc only > - the rest is crossing my fingers and hoping for bug reports. > > So what I'm looking for is a service, where I can upload my project to be > built in all official combinations supported by Qt - like it is done for > the Qt code. > > Is such a service available or - if not - would it be possible to open > your CI system for community projects using Qt ? > > Uwe > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [SPAM] Re: QDialog vs QPushButton and it's autoDefault default
> Did you try to accept the Enter in your line edit instead? That way, it > would not propagate up. You could simply eat it or make it focus the > next item in the focus chain or something that makes sense in your context. I thought about that. But it means a workaround out of position. What about line edits in delegates? Or in editable comboboxes, etc.? This can get nasty. Some kind of dialog-global option would be necessary. I did a lot of research and found several people having the same issue with the current implementation. Alas I could not find a clean way to solve it. So as a workound I finally changed the significantly complex dialog .ui files from QDialog to QWidget, introduced a custom base class, threw away the QDialogButtonBoxes and added the dialog buttons as normal buttons in a separate layout. This way the standardized dialog behaviour and design is down the drain but for non-trivial dialogs this is much better than frustrating users using by accident. A new option to disable the autoDefault feature for entire dialogs would be very helpful. I considered writing a corresponding suggestion but I guess it would rot in the issue tracker forever. -- Best Regards, Bernhard Lindner signature.asc Description: This is a digitally signed message part ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QDialog vs QPushButton and it's autoDefault default
Hi Volker! Hm, ok, I see. Thanks a lot for the explanations. Turned out the reason why the autoDefault heuristics kicks in is because the accept-role- button is disabled by default (until the user selects an item from the table). So the heuristic takes over a bit to early. To provide a non-auto-default I will need to set the default button programmatically. Still I am not satisfied. People tend to finish text input by pressing Enter, even in dialogs. For dialogs containing a sumplementary line edit (not being the main input of the dialog) this may also trigger some dialog action ahead of time. Is there a good solution to help user avoiding that mistake? I considered not to have a default button at all (neither set programmatically nor selected automatically) but that seems difficult with that always-on heuristics. > The default button gets pressed when the user presses Enter in a dialog, > unless an > autoDefault button has focus, in which case that button will be pressed. > That’s what the > user would expect. > > So, that your button is pressed when focus is in a QLineEdit would suggest > that your > clear button is the next autoDefault button in the focus chain (as per the > documented > behavior, and that there is no default button. Note that when using > QDialogButtonBox, > you only get a default button if one of the buttons in the box has the > “Accept” role - > otherwise you have to make one of the buttons the default button explicitly. > > So to your questions: > > 1) the behavior you are seeing seems to be as it should be, but you might > have to set a > default button for autoDefault heuristics not to take over completely and > cause > confusion. > 2) Opt-out would make it more work to have the kind of UI the user expects > (focused > button is pressed on Enter). > 3) QDialogButtonBox isn’t visible to the user, so a button behavior > differnelty in a > dialog just because it’s laid out in code with the help of QDialogButtonBox > seems > somewhat arbitrary. > 4) Default values of object properties being context dependent is not that > unusual > > > Cheers, > Volker > -- Best Regards, Bernhard Lindner On 11 Feb 2019, at 22:47, Bernhard Lindner wrote: > > > > Hi! > > > > I just experienced same strange behavior of QPushButton. I want to kindly > > ask for some > > explanations. > > > > I wrote a QDialog derived dialog. That dialog has a standard > > QDialogButtonBox with > > "Accept" and "Close" buttons. It also has various other widgets, especially > > a table > > view > > for item selection and a more complex generic/reusable filter panel > > (QWidget derived) > > that > > can be attached to any table view for complex user side filtering. That > > panel contains > > various widgets, including two buttons. > > > > I now have tripped painfully over a strange behavior that I could track > > back to the > > fact > > that one of those two buttons was automagically set as the dialog's default > > button. > > Now, > > whenever a user presses to confirm QLineEdit filter input, also the > > mentioned > > clear button is activated - causing a fabulous mess. > > > > After some research I could explain that unexpected behavior: > > > > autoDefault : bool > > This property holds whether the push button is an auto default button. > > ... > > This property's default is true for buttons that have a QDialog parent > > > > This also means there is a workaround: I need to call > > "setAutoDefault(false)" on each > > button that has the slightest chance to be ever used in a dialog. > > Everywhere. That is > > doable but seems very counterintuitive to me. > > > > So my questions are: > > 1. Is this actually how the autoDefault mechanism should work? > > 2. Why an opt-out instead of an opt-in? > > 3. Regarding opt-out: Why not restricting the autoDefault default of true > > to buttons > > with > > QDialogButtonBox parents instead of QDialog parents? > > 4. Anyway, is it good style to change the default value (!) of a property > > dynamically > > like > > this?> > > signature.asc Description: This is a digitally signed message part ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QDialog vs QPushButton and it's autoDefault default
Hi! I just experienced same strange behavior of QPushButton. I want to kindly ask for some explanations. I wrote a QDialog derived dialog. That dialog has a standard QDialogButtonBox with "Accept" and "Close" buttons. It also has various other widgets, especially a table view for item selection and a more complex generic/reusable filter panel (QWidget derived) that can be attached to any table view for complex user side filtering. That panel contains various widgets, including two buttons. I now have tripped painfully over a strange behavior that I could track back to the fact that one of those two buttons was automagically set as the dialog's default button. Now, whenever a user presses to confirm QLineEdit filter input, also the mentioned clear button is activated - causing a fabulous mess. After some research I could explain that unexpected behavior: autoDefault : bool This property holds whether the push button is an auto default button. ... This property's default is true for buttons that have a QDialog parent This also means there is a workaround: I need to call "setAutoDefault(false)" on each button that has the slightest chance to be ever used in a dialog. Everywhere. That is doable but seems very counterintuitive to me. So my questions are: 1. Is this actually how the autoDefault mechanism should work? 2. Why an opt-out instead of an opt-in? 3. Regarding opt-out: Why not restricting the autoDefault default of true to buttons with QDialogButtonBox parents instead of QDialog parents? 4. Anyway, is it good style to change the default value (!) of a property dynamically like this? Thanks in advance! -- Best Regards, Bernhard Lindner signature.asc Description: This is a digitally signed message part ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt 6 and standard types
Hi everybody! Are there any plans for Qt6' API to use standard types like size_t (or special replacements like qsizetype) for return values and parameters that have platform dependent width? -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
Hi! > No. However, I am asking for proof. Maybe I worked for the wrong companies all the time. But whenever we wanted to have proof that some tool or library actually meets our requirements, it never was sufficient to *ask* for proof. We needed to test it by *ourselfs* in a feasibility project. And normally *none* of the candidates completely met all of our requirements so we chose the tool with the least flaws, the best potential and (most important!) with the most dedicated maintenance/support crew. And of course some trust was part of the decision. Thiago, did this startegy of yours (simply asking for an all-inclusive proof and guarantee) ever work before? -- Regards Bernhard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
> But the only mailing list with sufficient representation of the community is > this one. We don't have to like discussing this, but it seems necessary that > we do. Well, then let me give you my simple minded opinion on this topic, an engineers opinion: Do not introduce a CoC. Resisting to have anything and everything in black and white is hard and is not popular and surely not zeitgeist but sometimes the better way. Please do not make me discuss about that as well, I prefer to wrangle with item delegate code ;) -- Best regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
> > I wish any one discussion about Qt software quality would have attracted so > > much attention, passion and effort as this CoC topic. > > There are plenty of technical threads that have had more emails sent than > this. Look at the ones about the buildsystem, for a recent example. I didn't say "technical". Also I didn't say "number of e-mails". Anyway I think engineering and politics should be separated. On any level. Politics is extremly harmful to engineering. CoCs are always political. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
I wish any one discussion about Qt software quality would have attracted so much attention, passion and effort as this CoC topic. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Monitoring of upstream vulnerabilities
> > Because I didn't realise the tool wasn't public. I saw github and thought > it > was. Sorry about that. > > Well, CVEMAN will be made public some time, hopefully. It's still in > development. For now, the other tool works. > Many thanks for the clarification! On a side note: Do you know an estimated timeframe for when it will be publicly available? Would be really interested in the details. 2018-06-19 23:13 GMT+02:00 Thiago Macieira : > On Tuesday, 19 June 2018 14:04:45 PDT Bernhard B wrote: > > Sorry, I don't get it. But what's the point of providing a link to the > > Intel github rpo if we can't access it? > > Because I didn't realise the tool wasn't public. I saw github and thought > it > was. Sorry about that. > > Well, CVEMAN will be made public some time, hopefully. It's still in > development. For now, the other tool works. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Monitoring of upstream vulnerabilities
Sorry, I don't get it. But what's the point of providing a link to the Intel github rpo if we can't access it? Am Dienstag, 19. Juni 2018 schrieb Thiago Macieira : > On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote: > > > Currently, we use https://github.com/clearlinux/cve-check-tool. This > is > > > going to be replaced with CVEMAN - > > > https://github.intel.com/kcwells/cveman. Both tools consume the feed > from > > > the National Vulnerability Database from the US NIST - > > > https://nvd.nist.gov/. > > > > Is that intel server publicly accessible? > > The dashboard the tool produces isn't, but I also don't see why you'd want > that. It's not applicable to Qt. The only people who would want access to > it > are the people who are working on the distribution and will apply the > patches. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [BB++] Now is 3.5x faster than Node.JS
I am just a user of Qt, so please take the following please with a grain of salt: I haven't started debugging my application yet, but for some reason my application laggs on Android, but works fine on iOs. It's a listview with a pretty complex delegate. On Android you can see clearly that it laggs, but on iOs it's smooth. But again, I haven't profiled it yet, so it most probably could be related to the complex bindings in the delegate and not due to the GC. Bernhard Am Dienstag, 25. Juli 2017 schrieb Phil Bouchard : > On 07/25/2017 02:50 AM, Tomasz Siekierda wrote: > >> On 25 July 2017 at 03:09, Phil Bouchard <philipp...@gmail.com> wrote: >> >>> That's why you have to put chances on your side. Regarding the GC all you >>> have to do is look at the logs: >>> http://www.war-worlds.com/blog/2012/06/on-android-garbage- >>> collection-can-kill-you >>> >> >> What killed the performance in this case was not GC but bad design, >> unfit for the platform. Read the article through, and the comments. In >> the end, the author got comparable performance on Android and desktop >> (while Android was still using GC). Additionally, the post is from 5 >> years ago, a lot could have been improved in that period. >> > > Here's another article that is 2 years old only and laggy performance > still seems to be a problem: > https://code.tutsplus.com/tutorials/detect-and-resolve-perfo > rmance-problems-on-android--cms-24058 > > You need to understand that: "No matter how innovative and useful your > Android app is, if it’s laggy, prone to freezing, or hogs memory, no one is > going to want to use it." > > Mind you, the bb++ idea seems tempting. JS is not the nicest language >> around, it would be cool to have an alternative, esp. if the learning >> curve is small and benefits large. I'd just prefer it to be compiled >> at compile time (at the same time when C++ part is compiled), cause >> shipping the compiler with an app seems wasteful at best. >> > > I'm here to help and hopefully Qt can take a lead against world renowned > web engines at the same time. As far as the compiler is concerned then, > worse case, I know there are better alternatives than G++ in compilation > speed and the overall size it takes. > > I didn't have a chance to create documentation yesterday but I will this > week. > > ___ > 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] Improve performance (listview + onVerticalVelocityChanged)
I think I solved my problem. In case someone is interested, that's my
solution:
//hide "back to top" button when movement ended and we are
//at index 0
onMovementEnded: {
if(indexAt(contentX, contentY) === 0){
backToTopButton.visible = false;
}
}
onFlickStarted: {
//when user scrolls fast enough up, show the tab bar
//and the "back to top" button
if(verticalVelocity < -flickTabBarTreshold) {
backToTopButton.visible = true;
tabBar.show();
}
//when user scrolls fast enough down hide "back to top" button
//and the tab bar
if(verticalVelocity > flickTabBarTreshold){
backToTopButton.visible = false;
tabBar.hide();
}
}
I don't know if this is the best solution, but it seems to work.
Thanks,
Bernhard
2017-01-26 15:38 GMT+01:00 Bernhard B <schluc...@gmail.com>:
> Hi,
>
> I am currently trying to optimize my Listview for performance. I already
> removed most of the bottlenecks by following the great recommendations at:
> http://doc.qt.io/qt-5/qtquick-performance.html
>
> However, there is one problem I don't how to solve. It's about this code
> part:
>
> ListView{
> clip: true
> property real flickTabBarTreshold;
>
> Component.onCompleted: {
> flickTabBarTreshold = (2/3) * maximumFlickVelocity;
> }
>
> onVerticalVelocityChanged: {
>
>
> //when user scrolls fast enough up, show the tab bar //and the "back
> to top" button
>
> if(verticalVelocity < -flickTabBarTreshold) {
> backToTopButton.visible = true;
>
> tabBar.show();
>
> }
>
>
>
> //when user scrolls fast enough down hide "back to top" button//and
> the tab bar
> if(verticalVelocity > flickTabBarTreshold){
>
> backToTopButton.visible = false;
>
> tabBar.hide();
>
> }
>
> //always disable "back to top button" when top reached
> if(indexAt(contentX, contentY) === 0)backToTopButton.visible = false;
>
> }
> }
>
> This part is one of the biggest performance bottlenecks at the moment (as
> it gets called a lot of times) and has a significant impact on the
> scrolling behavior (lagging).
>
> My idea was to put that code somehow in my C++ Listmodel and emit only a
> signal when something actually changed.
>
> For the last part
>
> //always disable "back to top button" when top reachedif(indexAt(contentX,
> contentY) === 0) backToTopButton.visible = false;
>
>
> I think it should be possible to check that in the
> QVariant <http://doc.qt.io/qt-5/qvariant.html> QAbstractItemModel::data(const
> QModelIndex <http://doc.qt.io/qt-5/qmodelindex.html> &*index*, int *role*
> = Qt::DisplayRole) const
>
> method. When index.row() === 0, I a signal will be emitted. In QML I am
> connecting on that signal and execute backToTopButton.visible = false;
>
> I haven't tested it yet, but I think it should work.
>
> For the other two conditions however, I am a little bit clueless.
>
> Does anyone of you guys maybe have an idea on how to improve that?
>
> Any help is really appreciated.
>
>
> Thanks,
>
> Bernhard
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Improve performance (listview + onVerticalVelocityChanged)
Hi,
I am currently trying to optimize my Listview for performance. I already
removed most of the bottlenecks by following the great recommendations at:
http://doc.qt.io/qt-5/qtquick-performance.html
However, there is one problem I don't how to solve. It's about this code
part:
ListView{
clip: true
property real flickTabBarTreshold;
Component.onCompleted: {
flickTabBarTreshold = (2/3) * maximumFlickVelocity;
}
onVerticalVelocityChanged: {
//when user scrolls fast enough up, show the tab bar //and the
"back to top" button
if(verticalVelocity < -flickTabBarTreshold) {
backToTopButton.visible = true;
tabBar.show();
}
//when user scrolls fast enough down hide "back to top" button
//and the tab bar
if(verticalVelocity > flickTabBarTreshold){
backToTopButton.visible = false;
tabBar.hide();
}
//always disable "back to top button" when top reached
if(indexAt(contentX, contentY) === 0)backToTopButton.visible =
false;
}
}
This part is one of the biggest performance bottlenecks at the moment (as
it gets called a lot of times) and has a significant impact on the
scrolling behavior (lagging).
My idea was to put that code somehow in my C++ Listmodel and emit only a
signal when something actually changed.
For the last part
//always disable "back to top button" when top
reachedif(indexAt(contentX, contentY) === 0) backToTopButton.visible
= false;
I think it should be possible to check that in the
QVariant <http://doc.qt.io/qt-5/qvariant.html> QAbstractItemModel::data(const
QModelIndex <http://doc.qt.io/qt-5/qmodelindex.html> &*index*, int *role* =
Qt::DisplayRole) const
method. When index.row() === 0, I a signal will be emitted. In QML I am
connecting on that signal and execute backToTopButton.visible = false;
I haven't tested it yet, but I think it should work.
For the other two conditions however, I am a little bit clueless.
Does anyone of you guys maybe have an idea on how to improve that?
Any help is really appreciated.
Thanks,
Bernhard
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QDataStream: blackbox or document all versions?
> You could choose to turn QDataStream into a black-box, but I think there > should be a white-box alternative which has to be > 1/ as efficient : binary format > 2/ as easy to use : QDataStream is able to serialize any type with the help > of qRegisterMetaTypeStreamOperators > 3/ as generic : it should be able to use any QIODevice for transport/storage +1 > 1/ discards XML and JSON, and 3/ discards QSettings and D-Bus. Thanks for pointing this out! P.S.: https://bugreports.qt.io/browse/QTBUG-25237 -- Regards, Bernhard 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 LTS C++11 plans (CopperSpice)
For example, with moc removed we support template classes that inherit from QObject. Wow. I would (almost) kill for having that feature in Qt! -- Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
Some of our applications are relying on Qt Script and Qt Webkit. So I just had a look at the replacements (Qt Webengine and Qt QML). The documentation says ... WebEngine ... doesn't give direct access to the network stack and the HTML document through C++ APIs. Does this mean there is no way to access the DOM anymore? This would be fatal for us. Accessing the DOM is essential for all of our applications that use QWebView. Is there some replacement/workaround? Also we use the QScriptEngineDebugger but there seems to be no debugger for QJSEngine. Is there some replacement/workaround? Are there other significant differences that I should consider? -- Kind Regards Bernhard Lindner -Ursprüngliche Nachricht- Von: development-bounces+private=bernhard-lindner...@qt-project.org [mailto:development-bounces+private=bernhard-lindner.de@qt- project.org] Im Auftrag von Knoll Lars Gesendet: Dienstag, 3. Februar 2015 08:34 An: development@qt-project.org Betreff: [Development] Deprecating modules with 5.5 Hi, I’d like to mark a few modules as deprecated with 5.5, and most likely remove them from the binary packages with 5.6. These modules are: * Qt WebKit * Qt Declarative (Qt Quick 1) * Qt Script All of these modules are by now a couple of years old, don’t receive updates above the bare minimum and have a replacement that is actively being developed in Qt 5. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development attachment: winmail.dat___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
I consider a fully functional web engine component a very important piece of Qt. Easily embedding a website into a desktop application is extremely useful. Example applications are scrapers and website analysis tools. But there are a LOT more applications. Also more common ones. If the choice is dropping the web engine component or dropping old compilers I wouldn't need to think a second about the decision. -- Kind Regards Bernhard Lindner -Ursprüngliche Nachricht- Von: development-bounces+private=bernhard-lindner...@qt-project.org [mailto:development-bounces+private=bernhard-lindner.de@qt- project.org] Im Auftrag von André Somers Gesendet: Freitag, 6. Februar 2015 08:43 An: development@qt-project.org Betreff: Re: [Development] Deprecating modules with 5.5 Knoll Lars schreef op 5-2-2015 om 16:28: But we don’t have much of a choice, if we want to deliver an up to date web engine. Perhaps it is time to ask the question then: do we want to do that? Do we really need to? It seems to me, that it isn't really possible to do. Not in a way that doesn't require huge effort in support or pissing off everybody not on one of the large main stream platforms. And the question might be: why should Qt deliver an up-to-date web engine exactly? Do we really think that people are going to use Qt to build advanced browsers? Sure, some might (KDE comes to mind...), but you are right in your observation that the technology is moving too fast and is developed between giants like Google, Apple and Microsoft who could not care less about other uses or other platforms than their own. All the while Qt is spending effort to catch up, deprecating compilers and platforms because they can't take the latest Javascript engine to it, users are hapily using browers like Firefox and Chrome. Perhaps it is time to conclude that Qt just can't compete in this race if it doesn't want to be crushed between the giants playing this field. Perhaps it is just time to settle for indeed a simpler goal: don't try to provide a fully integrated full-fledged web engine, but instead settle once again for a simpler alternative that we _can_ support and that can be used for things like showing embedded help or showing simple sites, and perhaps an API to wrap and embed the native web view provided by the platform but with limited integration. André ___ 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] Assistant documentation can not be copied anymore?
Hi! After searching for functions and features in Qt Assistant I used to copy code snippets (like function names, signatures etc.) from the Assistant pages. Starting with Qt5.4 that got pretty annoying. Still copied code looks perfectly fine but VS2013 Intellisense and compiler complain about strange errors. It seems there are invisible characters hidden in the assistant pages that break the code. VS editor doesn't show these characters at all which is extremely annoying and hard to figure out. E.g. I tried to copy the prototype of the QWidget::showEvent into the VS editor. It contains an invisible but harmful character that can't be compiled (seems the character is inserted directly in front if the showEvent function name). Has something changed in the formatting Assistant's pages from Qt 5.3.2 to Qt 5.4? Can someone confirm/explain this? -- Kind Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
