[Development] Braces (was Re: Resolving coding style contentions)
Hi all!
Speaking of coding style again, I haven't found any indication in the
coding guidelines about brace vs parentheses in initializations.
There are a few cases where they can be used (and I might even be
forgetting some):
1) Constructors:
MyClass(): var(0) {}
vs
MyClass(): var { 0 } {}
2) Member initializations:
class MyClass
{
int m_count = 3;
vs
int m_count { 3 };
3) Variable initialization
bool ok = false;
vs
bool ok { false };
4) Constructor invocations:
auto *item = new Item("name", parent);
vs
auto *item = new Item { "name", parent };
or
QString message(QStringLiteral("text"));
vs
QString message { QStringLiteral("text") };
I guess this is not an option:
QString message { QStringLiteral { "text" } };
I'm not mentioning the cases of struct and list initializers, where of
course braces are the only option. But what is the consensus on the
cases above?
Looking at the Qt code, it seems that variant without braces is always
preferred, but I cannot find it formalized anywhere.
Ciao,
Alberto
--
http://blog.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] QtQuick.Layouts and content margins
Hi there!
I'm working on a desktop style for QtQuick.Controls 2 [1], and I'm
currently investigating the issue of layouts. My current approach is to
define my own ColumnLayout element like this:
==
import QtQuick.Layouts 1.2
import it.mardy.Desktop.private 1.0
ColumnLayout {
anchors {
leftMargin: Style.layoutLeftMargin
topMargin: Style.layoutTopMargin
rightMargin: Style.layoutRightMargin
bottomMargin: Style.layoutBottomMargin
}
spacing: Style.layoutVerticalSpacing
}
==
where the Style element is a singleton which retrieves the default
layout margins encoded in the QStyle.
Now, there's are a couple of problems with this solution: if the user of
my layout does not set the "anchors.fill" property, but instead
positions the layout using "x", "y", "width" or "heigh" properties, the
margins will be ignored.
The other (bigger) problem is that the implicit size of my layout is
wrong: it should include the margins!
My proposal is to add a set of "margins" properties to QtQuick.Layout's
items, which would set the default content margins for all child items
that don't explicitly set their own via the attached Layout properties.
These margins would also be taken into account when computing the
implicit size of the layout.
If this looks like a good idea, I can try and propose a patch.
Ciao,
Alberto
[1]: https://gitlab.com/mardy/qqc2-desktop
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtQuick.Layouts and content margins
On 25/02/19 11:23, Mitch Curtis wrote:
> So would it look something like this?
>
> // implicit size is 118 x 64
> ColumnLayout {
> defaultLeftMargin: 12
> defaultRightMargin: 12
> defaultBottomMargin: 12
> defaultTopMargin: 12
>
> // implicit size is 100 x 40
> Button {
> Layout.leftMargin: 6 // override default
> }
> }
Yes. Sounds good? :-)
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QtQuick.Layouts and content margins
On 25/02/19 15:57, Mitch Curtis wrote:
> My only issue with it is that I don't know if it will see much use
> outside of your use case. Usually if all items in a layout have the
> same margins, you would just apply those margins to the layout
> managing them instead. While I appreciate that that won't work in
> your case (because the Layout might not be within another, so the
> attached margin properties won't have any effect, and anchor margins
> are not included in its implicit size), I do wonder if there are
> other approaches you could take. What other options have you
> considered?
My immediate issue can be fixed by wrapping the layout into an Item that
aliases its properties and computed the proper implicit size:
==
import QtQuick.Layouts 1.2
import it.mardy.Desktop.private 1.0
Item {
default property alias data: layout.data
implicitWidth: layout.implicitWidth + layout.anchors.leftMargin +...
...
ColumnLayout {
id: layout
anchors {
leftMargin: Style.layoutLeftMargin
topMargin: Style.layoutTopMargin
rightMargin: Style.layoutRightMargin
bottomMargin: Style.layoutBottomMargin
}
spacing: Style.layoutVerticalSpacing
}
}
==
> What about just making the API that provides the style's
> margins available to the user so they can do it themselves?
That might happen as well, but the goal is not to require the user to
know about this class.
> Also, it would be good if you could provide some examples of other
> (more common) use cases that would benefit from this.
Well, having all items inside a layout share the same margins is quite
common. People currently do it with anchors and playing with the
(implicit) size of the parent, but it's not optimal.
The advantage of doing this in the layout items themselves is that there
the problem is reduced to some trivial arithmetic, without the need to
play with parent items.
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] QML preprocessor
Hi there!
When developing a QML module for the greater public one wants to
provide a source package that can be built on multiple Qt versions.
However, QML's lack of a preprocessor makes this rather cumbersome.
Suppose that my module needs to provide an element like this:
import QtQuick 2.10
Item {
...
Flickable {
boundsMovement: Flickable.StopAtBounds
...
}
}
If I wanted to make this available to users of Qt 5.9 and older, I'd
need to ship another file, instead, importing QtQuick 2.9 and removing
that "boundsMovement" property.
Keeping two or more copies of the same file and installing the proper
one depending on the Qt version is certainly doable, but it carries a
considerable maintenance cost.
I've personally decided to keep a single copy of each QML file but use
different git branches; however, this also has its maintenance costs and
makes things harder for people using the project, in that they need to
checkout the right branch of the project, otherwise it won't work on
their machines.
Has this problem been recognized and discussed before? Would a QML
preprocessor be a viable option?
I understand that this is not a problem for Qt itself, and it's a minor
problem for app developers; however, developing a portable QML module
depending on QtQuick is nearly impossible due to this, unless one agrees
to settle on a certain old version of Qt and renounce to all the goodies
that were added in later versions.
Ciao,
Alberto
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QML preprocessor
On 18/03/19 12:11, Pierre-Yves Siret wrote:
> This can be done with QQmlFileSelector :
>
> QQmlApplicationEngine engine;
> QQmlFileSelector* qmlFileSelector = QQmlFileSelector::get(&engine);
>
> #if QT_VERSION >= QT_VERSION_CHECK(5, 12, 0)
> qmlFileSelector->setExtraSelectors({"5.12"});
> #endif
>
> engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
>
> This will load qrc:/+5.12/main.qml (if there's one) instead of
> qrc:/main.qml when the Qt version is >= 5.12.
Of all suggestions, this is probably the one having the least
performance impact and greater readability. It still doesn't solve the
code duplication issue (Samuel's does, but with a greater runtime
impact), though. :-(
Anyway, thanks all!
(I'm still looking forward to see this issue addressed at the QML
language level, though :-) )
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
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
On 29/05/19 13:53, Mutz, Marc via Development wrote: > == QSharedDataPointer / QExplicitlySharedDataPointer == > > These are basically Qt-internals, and should never have been public in > the first place. It's _because_ they are public that we have two of > them, and soon a third one (properly non-public): > https://codereview.qt-project.org/c/qt/qtbase/+/115213 That commit's > message also explains what's wrong with the QSDP and QESDP. No way :-) I've never used QExplicitlySharedDataPointer myself, but QSharedDataPointer is very useful; it should not be removed in Qt6. And if it gets deprecated, an equally easy to use alternative should be provided. > == QScopedPointer -> std::unique_ptr == > > Suggested by Thiago on > https://codereview.qt-project.org/c/qt/qtbase/+/261553 > > I agree. We now have std::unique_ptr, and it's movable. QScopedPointer > had the problem that it didn't know what it wanted to be: > boost::scoped_ptr or std::unique_ptr. A real scoped pointer would not > offer release(), a unique_ptr would need to provide move semantics. > QScopedPointer has release(), but no moves (were proposed, but not > accepted). I never used release(), and I'm fine if std::unique_ptr is used as the implementation. But the name QScopedPointer is so much better than unique_ptr, that I wouldn't like to see it deprecated. > == QLinkedList -> std::list > (https://codereview.qt-project.org/c/qt/qtbase/+/261421) == > > Of the Qt containers, this one is the most-unused (in Qt code), as well > as the one that's furthest behind it's STL counter-part. Whenever I use > std::list, I use it for splice(), a function that just cannot be added > to a CoW container. Qt is already almost completely QLinkedList-free. > Let's bury QLinkedList. I bet it's unused because everyone is using QList. But once we deprecate QList, people will start asking for a CoW version of std::list. It's not clear to me why splice() cannot be implemented: it would just mean that the list data would detach as in all other non-const methods. Or am I missing something? In general, I agree with the plan to make our classes more interoperable with the STL, but I vote for keeping our own CoW classes and naming conventions. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ 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
On 30/05/19 11:40, Mutz, Marc wrote: > On 2019-05-30 10:23, Alberto Mardegan wrote: >> It's not clear to me why splice() cannot be implemented: it would just >> mean that the list data would detach as in all other non-const methods. >> Or am I missing something? > > You're passing two iterators. In order to implement slice(), you'd need > to iterate over the list, counting the items, then detach, find the new > two iterators, then do the slice(). That makes an O(M) operation into an > O(2N) operation, M being the number of sliced entries (it was O(1) in > C++98), N the size of the list. But that happens only if you detach; otherwise the performance should be comparable to std::list. That detaching has a high cost is a known fact. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ 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
On 30/05/19 18:34, Giuseppe D'Angelo via Development wrote: > Hi, > > On 30/05/2019 10:23, Alberto Mardegan wrote: >> I bet it's unused because everyone is using QList. But once we deprecate >> QList, people will start asking for a CoW version of std::list. > > QList has nothing to do with std::list! > > (Except a very similar name.) > > How many times does this need to be repeated? I know it perfectly well, you need to read my e-mail in the right context (the proposed removal of QLinkedList) :-) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 5/31/19 4:24 PM, Volker Hilsheimer wrote: > Nobody is forced to move to Qt 6 right away; Qt 5.15 is an LTS with > three years maintenance. We are not expecting lots of people to jump > on Qt 6.0 anyway (because .0, and not an LTS release anyway), so when > an API was marked as deprecated makes perhaps not that much > difference “in real time”. Three years is not a lot of time when moving between major releases. It would be nice if the last LTS release in a major release series were supported for a longer time (5 years?). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ 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
On 05/06/19 01:39, Kevin Kofler wrote: > Mutz, Marc via Development wrote: > >> and produces surprises such as >> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581 > > My existing QSharedDataPointer code always checks truth with > if (d.constData()) and never if (d). Adding a const bool operator to QSharedDataPointer would solve the problem, wouldn't it? Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ 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
On 18/06/19 10:43, Mutz, Marc via Development wrote: > On 2019-06-18 08:18, Alberto Mardegan wrote: >> >> Adding a const bool operator to QSharedDataPointer would solve the >> problem, wouldn't it? > > And (silently) break code that relies on the current behaviour, yes. Well... Expecting the data to detach on an `if (d)` check seems worth incurring into a breakage :-) But I certainly cannot exclude that there is some code out there which happens to work exactly because of this implicit detach, so it might be better not touch this, after all. > BTW: this is the proposed replacement of QSDP/QESDP for Qt-internal use: > https://codereview.qt-project.org/c/qt/qtbase/+/115213 and no, it will > most certainly _not_ be public API again. It's the fact that these > implementation details of Qt, QSDP and QESDP, are public, that prevents > us from fixing them. I will not be part of another such lock-in. You won't, but someone else hopefully will, and shall have all my appreciation. I think you are overestimating the lock-in, here. The API surface of these classes is relatively small; they have been used for over a decade, with no major complaints. Yes, there are some issues, in some places they are badly designed, but during these years the problems have been noticed and now we have the chance to address them (with a replacement as your proposed one, for example). While I agree that these new classes shouldn't be made public right away, using them internally in Qt should give us enough confidence that they are an improvement over the S[E]QDP and we should be able to make them public by Qt6. Sure, it is possible that some new issues will be found after the Qt6 release, but given the size of these classes, and the fact that we have more than a decade of experience using them (or a very similar API), how likely is it that we screwed things up? If a new bug should be found, that hasn't surfaced in all these years, it's going to be a very, very minor issue. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27/06/19 04:47, Lars Knoll wrote: > > Yes, Webengine uses some memory. But is that really a problem on developer > machines? Yes. The more RAM you use for surfing documentation, the less RAM you have for building. I have 16 GB of RAM, and sometimes I have to close Chromium away (yes, I know, my fault, I should use a more lightweight browser!). Doing the same with QtCreator (which I only use for browsing documentation, not for actual development) would be quite troublesome. IMHO a better question would be: are the costs of using QtWebEngine worth the benefits? > People propose adding functionality to QTextBrowser instead. I do not thing > that’s a viable solution (we’ve tried that in the past and our technical > writers hit the next issue some weeks/months later). The problem is not that > one could not add support for one or two new features to QTextBrowser, it is > that we do not know what features we will need in our docs in the future. We can switch to something else in the future; switching to QtWebEngine is easy. But in the meantime, all improvement made to QTextBrowser (or any development done on a new lightweight HTML view component) will be a great benefit to the Qt developer community: many applications could benefit from with, typically for showing inline docs. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
On 27/06/19 14:14, Bastiaan Veelo wrote: > > However, it seems that most web browsers that implemented their own > browser tech have ditched those in favour of a third party framework > (see Opera, Edge, e.g.) -- how much of the reason for that is due to > rendering or networking I don't know. I would guess that Javascript and security issues also played a big role. But if we took LiteHtml as a base (as Eike suggested) and just focused on good HTML+CSS support, we could make a very useful and safe widget. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QHash for Qt 6
On 20/12/19 13:47, Giuseppe D'Angelo via Development wrote:
> Just to be devil's advocate, there is... As much as it's fun and
> everything implementing a container, just using std::unordered_map would
> have minimal effort on our side ("someone else's problem", and it's not
> even a random 3rd party, but a mandatory prerequisite for building Qt),
I'm not sure the "someone else's problem" argument would go down very
well with Qt customers. :-)
Using std::* classes in the Qt implementation is not a bad idea, but
only as long as their performance is top-notch. Otherwise if Qt just
becomes "a convenient wrapper of the STL", people who care most about
performance will simply go for the latter.
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On 27/01/20 17:34, Lars Knoll wrote: > The Qt Company has done some adjustments to the Qt will be offered in the > future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 . [...] > None of these changes should affect how Qt is being developed. There won’t be > any changes to Open Governance or the open development model. But it will discourage contributions, and encourage competition from other Qt consulting companies (I've written more on that here: http://www.mardy.it/blog/2020/01/theqtcompany-and-a-silly-decision-waiting-to-be-reverted.html). If you wanted more paying customers you should have tried with the carrot, not with the stick: offer free or discounted licences to people contributing to Qt, to open source projects using it, and diversify your commercial offering to make it more accessible to small developers (this last point you tried, but it's still something a lone developer is unlikely to be able to afford). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On 29/01/20 13:02, Edward Welbourne wrote: > Clarification: we'll be moving to "all commits land first on dev and are > cherry-picked out to other branches that need them" in place of our > present merge-based module. Where Cristián says "all those patches will > be on Gerrit", they'll be on dev on Gerrit. They'll be cherry-picked > from there to a (presumably) private branch (maybe on a private repo), > so you won't necessarily see the cherry-picked versions, only the dev > versions. So any time the cherry-pick requires adaptation to the LTS, > those running the fork above would need to duplicate the adaptation. Do I understand correctly that LTS releases will not have point releases, while non-LTS releases (like, currently we have 5.13.2 and 5.14.1) will continue to have them? Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On 29/01/20 19:02, Volker Hilsheimer wrote: > You obviously don’t trust that TQtC will treat the data the online-installer > either demands or requires with the appropriate confidence. So, shouldn't you > build Qt from sources? Your IP address is PII, after all. Why did you trust > that The Qt Company didn’t collect personal data from you previously - just > because you didn’t have to enter your email address? You don't have to convince us. The fact is that a person only slightly interested in Qt will download it from the Qt website, because that's where the search engines will point to (until someone provides an account-free download elsewhere, at least), and the need to register is enough to put some people off. You might find it unreasonable, but it happens. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Old man here: On 31/01/20 13:07, Vitaly Fanaskov wrote: > But how to use them in the API and which way is preferable is still > unclear. There are two main options we have: > > 1) Use std::* smart pointers as-is. > > 2) Add Qt-style wrappers around std::* smart pointers and move old > implementations of Qt smart pointers to the Qt5Compact module. 2. I still have trouble understanding why std::unique_ptr is called like this, whereas I could immediately understand what QScopedPointer does even before reading its documentation. > Another thing to discuss is whether we should use raw pointers in the > API at all or not. There are a few options again: > > 1) Yes > > 2) No. Use “modern” approaches instead (pass mandatory dependencies by > either reference or const reference when using smart pointers makes no > sense, use something optional-like or tuples to return extra data from > functions, and so on) > > 3) Mix 1 and 2. 1. (though of course, we should also use smart pointers where they bring a clear advantage) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 31/01/20 23:04, Ville Voutilainen wrote: > On Fri, 31 Jan 2020 at 21:23, Alberto Mardegan >> >> I still have trouble understanding why std::unique_ptr is called like >> this, whereas I could immediately understand what QScopedPointer does >> even before reading its documentation. > > What would you then name a Qt counterpart of std::unique_ptr, considering that > QScopedPointer is not such a counterpart? Do we need to have such a counterpart? In my work experience, when I'm not allowed to use Qt and am restricted to the STL, all the times I had to use std::unique_ptr was to get the same behaviour as a QScopedPointer. It's true that QScopedPointer offers only a subset of std::unique_ptr's functionalities, but, *for that subset*, its name is just perfect. That's why I wouldn't like to see it go away, or moved to a compat library. So, I don't really care about std::unique_ptr, but I like Vitaly's suggestion of having a QUniquePointer with a nice data() method. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: > About QUniquePointer: what's the point of reinventing std::unique_ptr > under a different name? A Qt-ish API! > * Is it just going to be an alias, to be more Qtish? Then why > QSharedPointer is NOT going to be an alias? > > * Is it not going to be an alias? NIH all over again? It's not clear to me what you mean by "alias"; if you mean a subclass, then I'd be against it, because there's a (very small indeed) risk that in the future the STL adds some methods that might conflict with ours, or would not be Qtish enough. If we can resue the STL implementation, that's a good thing, but it should be an implementation detail; and I don't think we should care about NIH, when we are talking of classes that are unlikely to pose a great maintenance burden. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 01/02/20 15:02, Giuseppe D'Angelo via Development wrote: > Il 01/02/20 12:44, Alberto Mardegan ha scritto: >> On 01/02/20 02:46, Giuseppe D'Angelo via Development wrote: >>> About QUniquePointer: what's the point of reinventing std::unique_ptr >>> under a different name? >> >> A Qt-ish API! > > Example? A data() method :-) >> It's not clear to me what you mean by "alias"; if you mean a subclass, >> then I'd be against it, because there's a (very small indeed) risk that >> in the future the STL adds some methods that might conflict with ours, >> or would not be Qtish enough. > > I mean a type alias: using QUniquePointer = std::unique_ptr; It still bring the risk of the STL adding some weirdly named methods (such as empty()) which we don't want to have in a Qt class. > 1) It's still NIH; Which is not bad per se, in absolute terms. > 2) The probability of future C++standards adding features that won't be > available in the Qt counterpart is 100%; They could be added, and the effort should be minimal (copy the code from STL). > 3) Explain why Qt should raise arbitrary interoperability barriers > literally "for the sake of it"; We can easily provide static fromStdUniquePtr and toStdUniquePtr methods, and there wouldn't be a barrier. > 4) Please justify the teachability efforts involved in explaining all of > the above to Qt users. You can explain it to our users by saying that we want a consistent API, and that while Qt is interoperable with the STL, it can be used without it (and as an alternative to it). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 01/02/20 15:32, Giuseppe D'Angelo via Development wrote: > Il 01/02/20 12:37, Alberto Mardegan ha scritto: >> Do we need to have such a counterpart? In my work experience, when I'm >> not allowed to use Qt and am restricted to the STL, all the times I had >> to use std::unique_ptr was to get the same behaviour as a QScopedPointer. > > So you never had to pass one to a function, return one from a function, > create a vector of them? Color me *very* suspicious. Believe it or not :-) I find std::shared_ptr easier to use when passing pointers to and from functions. And I never needed to put them into an array. > The same subset is available in the Standard Library. The type you're > looking for is "const std::unique_ptr". Sure, I'm just saying that "QScopedPointer" is more descriptive. >> So, I don't really care about std::unique_ptr, but I like Vitaly's >> suggestion of having a QUniquePointer with a nice data() method. > > How about working with upstream and convincing them that having data() > (in addition to get()) on smart pointers is a good idea? Is having > data() the _only_ argument here? The STL could still add a method made up of two words in the future, and it's unlikely that they'll use camelCase (or that they'd accept a camelCase variant). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 02/02/20 21:55, Giuseppe D'Angelo via Development wrote: > On 02/02/2020 17:38, Alberto Mardegan wrote: >> Believe it or not :-) I find std::shared_ptr easier to use when passing >> pointers to and from functions. And I never needed to put them into an >> array. > > This is a logical fallacy; "I don't need it, noone else does". Yes, but it's a logical fallacy you yourself made up: I never claimed that std::unique_ptr is not needed. > And I still see no problem in that? What is the problem at looking a bit > outside one's comfort zone (or one's bubble) and realizing that simply > because the Standard Library uses snake_case, we can live with it just > fine? I'm certainly fine with it, as long as my code doesn't end up with a mixed style. This is certainly OK when I'm using some third party modules in some isolated source file, but I'm less fine with it when it's on types I need to use all over the place. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 03/02/20 19:56, Jason H wrote: > [...] As a result, the code of a Qt-using program > should be readable by average developers not big into C++. [...] I agree with all what you said; I'm just quoting this sentence because it's easy to underestimate this. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
Going back to the original question again, as I'm not sure I agree with
this claim:
On 31/01/20 13:07, Vitaly Fanaskov wrote:
> Smart pointers are for sure much better to use than raw pointers for
> many reasons. They manage lifetime automatically, show ownership
> semantic, and make code safer. It’s planned to officially recommend them
> to use in Qt6 API instead of raw pointers whenever this is possible. For
> sure, it should only be a choice for newly designed API.
I ran a quick grep over QtBase's source code, and indeed it looks like
QSharedPointer and QScopedPointer are not used in the public API. But is
this bad?
Just imagine if we had been spreading Q{Shared,Scoped}Pointer all over
Qt's API in Qt4 times: we probably would not even be having this
conversation now, as switching from the Qt pointer classes to the std::
ones might have been way too problematic.
So, if, from this perspective, it's good that Qt has not embraced (Qt)
smart pointers before, I'm tempted to draw the conclusion that it would
be a wise idea to continue avoiding embracing a specific smart pointer
implementation.
Not using smart pointers in our API (neither the Qt's or the std:: ones)
allows each developer to use his own preferred solution with a minimal
effort. People might want to use boost smart pointers, SaferCPlusCplus,
or even their own handcrafted smart pointer templates. I don't think
that Qt should make a choice for them.
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 04/02/20 16:55, Vitaly Fanaskov wrote: > But if you see API like this: > > std::unique_ptr someAPI(); > > You have much more information about managed object just by reading the > code. This is also much easier to understand what can or cannot be done > with the returned value in the example above. True. I still think that the benefit it's not worth the imposition of smart pointers. Annotations could be used on the header files, and qdoc could be smart enough to present them in a clear way. > There also were good arguments about exceptions. We shouldn't forget > that Qt can be used with a program that uses exceptions. But this seems to be a point for *not* using std::, isn't it? We also want Qt to be used with a program that does *not* use exceptions. What would happen if one of the STL classes publicly used in the Qt API gained some method that can throw an exception (not just in OOM cases, but as part of a common scenario)? Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 12/02/20 15:20, Vitaly Fanaskov wrote: >> AFAIK, we don't have a procedure to make project-level decisions by majority >> vote. > True. We're discussing now. The goal here is to take people opinions and > arguments into account before making a decision. The problem I see, is that in your summary you are only reporting those options that have had more consensus (or at least, according to the way you perceived the discussion going); but in doing so, you are already filtering out the alternatives, and therefore paving the road for a decision. Maybe what we should do is to collect all the different proposals and let people fill them with pros and cons (wiki style) and then you can proceed with a decision? In this way, you'd also avoid people repeating the same positions over and over the place. (not that I have a positive experience with the wiki approach either; but at least you are sure that all people taking the decision will be aware of all the points for and against every alternative). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Debian packaging from Git snapshots (qtsystems, qtfeedback, qtpim)
On 13/03/20 03:32, Chris Adams wrote: > Regarding maintainership: yes, for QtPIM at least it would be very > beneficial if someone from UBPorts could commit significant time to > QtPIM, as there are some open items there currently and unfortunately I > don't have much capacity to spend on QtPIM at the moment. Alberto > Mardegan has done a lot of work in the QtPIM area previously, and might > be a good candidate if his commitments allow... I'm certainly willing to help, even though I'm not sure about how much "significant time" is needed. On the other hand, looking through https://codereview.qt-project.org/q/qtpim it doesn't look like there's a huge amount of work needed. The problem I see is that it looks like most of the meaningful changes (that is, with API or behavioural changes) come from either you or me, so it would be nice to have more reviewers involved, but I guess we have to live with what we have. :-) Ciao, Alberto ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
On 23/04/20 14:57, Ville Voutilainen wrote: > QVector is certainly closer to std::vector than QList is to std::list. > Vector isn't a really good name either, > for people recently taught in elementary school math, or for java > programmers coming in. > For C++ programmers, it gives a much better suggestion of what it is > than calling it QList does. This calls for a nice QArray type :-) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Applications using -fno-rtti
Hi all!
A couple of days ago a bug was filed against a project of mine, which
has been built with -fno-rtti since Qt4 times:
https://bugzilla.opensuse.org/show_bug.cgi?id=1172904
The bug, it appears, is a crash in QProcess due to the use of typeid(),
which was introduced in Qt 5.15:
https://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.15&id=97645478de3ceffce11f58eab140c4c775e48be5
I think I missed an announcement about Qt applications having to use
RTTI; on the opposite, I thought that the whole point of QMetaObject was
not to require RTTI support; has this changed?
Anyway, were I to submit a patch replacing typeid() with something which
does not require RTTI ("q->metaObject() == QProcess::staticMetaObject()"
would work, I guess? Or maybe even comparing q->className()?), would
that be accepted?
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 20/06/20 21:42, Konstantin Tokarev wrote: > Comparing metaObject() with staticMetaObject() is wrong because it would fail > even for QProcess. I didn't try, but why would it fail? > OTOH, using qobject_cast would handle classes derived > from QProcess correctly, unlike code with typeid(). But how would you use qobject_cast in this case? We don't know what class to cast to; we only want to know if we are a subclass of QProcess. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 20/06/20 22:21, Alexey Minnekhanov wrote: > > сб, 20 июн. 2020 г. в 22:01, Alberto Mardegan > mailto:ma...@users.sourceforge.net>>: > > we only want to know if we are a subclass of QProcess. > > QObject::inherits(..) ? Sorry, my wording was imprecise: we want to know if q is a *proper* subclass of QProcess (that is, a derived class). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 20/06/20 21:42, Konstantin Tokarev wrote:
> Comparing metaObject() with staticMetaObject() is wrong because it would fail
> even for QProcess.
No, I tried, it seems to work as expected:
==
#include
#include
class BaseClass: public QObject {
Q_OBJECT
};
class DerivedClass: public BaseClass {
Q_OBJECT
};
class TypeCompare: public QObject {
Q_OBJECT
private Q_SLOTS:
void testType() {
BaseClass base;
DerivedClass derived;
QCOMPARE(base.metaObject(), &BaseClass::staticMetaObject);
QCOMPARE(derived.metaObject(), &DerivedClass::staticMetaObject);
// this fails
QCOMPARE(derived.metaObject(), &BaseClass::staticMetaObject);
}
};
QTEST_GUILESS_MAIN(TypeCompare)
#include "tst_type_compare.moc"
==
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 20/06/20 23:45, Thiago Macieira wrote:
> No, because it won't catch this:
>
> class MyProcess : QProcess
> {
> protected:
> virtual void setupChildProcess();
> };
>
> Note the lack of Q_OBJECT.
But what is the harm if we don't catch that? It's still better than a
crash, isn't it?
Also, the documentation of QObject says (talking about Q_OBJECT):
"We strongly recommend the use of this macro in all subclasses of
QObject regardless of whether or not they actually use signals, slots
and properties, since failure to do so may lead certain functions to
exhibit strange behavior."
I guess we could then use a solution based on QMetaObject, and let the
missing Q_OBJECT cases "exhibit strange behavior"?
> But a variant of https://codereview.qt-project.org/c/qt/qtbase/+/292540 might
> be acceptable. It would replace the typeid() check with the GCC extension,
> which will work for all GCC-based builds, which is the totality of Linux
> distributions.
If that is your preferred solution, I'm fine with that too. But is there
something wron gwith that patch, or can it be applied as is?
> By the way, can you say what you needed to derive from QProcess for? If it
> was
> to override setupChildProcess() like in the example above, what are you doing
> in the function?
No, that code is not overriding any virtual methods, it's just extending
the class.
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
On 21/06/20 19:13, Thiago Macieira wrote: > A set of patches were dropped from the middle of the series, implementing the > vfork I mentioned. So the patch needs to be rebased and adjusted. Other than > that, it's fine. Let's try: https://codereview.qt-project.org/c/qt/qtbase/+/305791/1 Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QtQuickControls for desktop: what's the plan?
Hi there! I'm working on a project of a desktop application using the QtQuickControls module. I occasionally run into small issue, but I'm generally satisfied with the state of the controls (I'm working on Linux, I hope that other platforms are working equally well). What makes me worry a bit is that I don't see much development happening on the module, and I wonder if that's because the module is complete and stable, or because we are invited to switch to the QtQuickControls 2 module. A related question is whether there are plans to offer desktop native themes to the QQC2 module and, if not, whether that would be feasible at all. Or, in other words, where would my efforts (as a developer willing to contribute to Qt, but with little free time to do it) be best invested in, if my ultimate goal is to have a QML desktop application working with native style in Linux, OS X and Windows? Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuickControls for desktop: what's the plan?
On 07/11/2016 14:53, Marco Martin wrote: > We have a similar problem within the KDE project, > As we have an entire desktop environment whose entire styling depends on > QStyle, continuing to use QStyle to theme desktop apps, at least on a limited > extent is vital. > As there doesn't seem to be interest in the upstream project in such a thing, > I started writing a QtQuickControls2 style that actually uses the very same > StyleItem used internally in QtQuickControls1, it can be checked out at: > https://quickgit.kde.org/?p=scratch%2Fmart%2Fdesktopqqc2style.git > > to be installed and then export QT_QUICK_CONTROLS_STYLE=Desktop (probably > i'll > have to rename it to avoid possible future conflicts with upstream ones) > > Even if is still incomplete (and are things that unfortunately can't be fully > styled yet in a fully desktop friendly way) it seems to work remarkably well. That looks smart and simple! Any plans for submitting that to Qt, maybe as a playground project? Anyway, do you have a bug tracker? Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuickControls for desktop: what's the plan?
On 10/11/2016 11:55, Frederik Gladhorn wrote: > The last gap are Linux styles. The situation with KDE is actually quite > interesting, since the platform is QStyle based. We do not believe in QStyle > based styles for QQC2 as it stands. They will never have the same performance > level of the other styles. If QStyle is used by QWidgets, which have been used in apps since well before QML existed, it's reasonable to expect that its performance is more than acceptable for modern desktop machines. > Changing QStyle is not exactly trivial either, but > maybe we can find a way to make it efficent and share code. Maybe we in the > end > conclude that it's all too much work and we want to have a QStyle based theme > in controls 2, but let's first explore the options. I don't know the code > enough to have any kind of opinion at this point and I'd propose people that > actually have better insights explore which way makes most sense. And I've been away from Windows and OS X for so long, that I have no idea how widgets have evolved there. As I understand, QStyle is for drawing static elements, but you mentioned that in OSX we now have widget animations... Maybe we might have to give up on the idea of a single implementation, and instead have a different style for each toolkit? At least with Gtk, it might be possible to use native Gtk widgets, as we are already using the glib mainloop in Linux, and GtkWidgets allow for offscreen drawing... That sounds like a lot of work :-) Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [HEADS-UP] Updates to branching scheme
On 11/25/2016 03:40 PM, Oswald Buddenhagen wrote: i'm expecting a flurry of retargeting requests of changes from 5.6 and 5.7 to 5.8 now. I have a few changes targeting 5.6 which are waiting for review: https://codereview.qt-project.org/#/q/owner:%22Alberto+Mardegan%22+branch:5.6+status:open,n,z Eventually I hope to find the time to propose them on the 5.8 branch, but given that these are changes I've already proposed and they are just waiting for a +2, and that I'm myself interested in 5.6 only at the moment, it would be sooo nice if someone would take care of cherry-picking them to 5.8. :-) Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Adding Q_GADGET here and there
Hi all, I'm about to use QMimeType in my application, and I'd found it useful if it were a Q_GADGET. Can I just go on and submit a patch to add that, or are there some cons (a small increase on the library size, I assume)? In general: is it a good idea to add Q_GADGET to non QObject classes within the Qt source code? Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding Q_GADGET here and there
On 16/04/2017 21:13, Olivier Goffart wrote: > > Q_GADGET's overhead is basically the cost of the QMetaObject. So it's there, > but it's quite small. > If there is an use for a class to be a Q_GADGET, I think it should be added. For the record: https://codereview.qt-project.org/#/c/191777/ Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Exposing QMimeDatabase to QML; QtQml.Utils?
Hi all, in addition to making QMimeType usable from QML [1], jpnurmi also suggested of exposing QMimeDatabase as a singleton. The open question is where this element should be added: I suggested QtQtml.Models, given that it's a database, but maybe creating a separate module QtQml.Utils might be a better idea? If so, do you have suggestions for other classes to be exposed by it? Ciao, Alberto [1]: https://codereview.qt-project.org/191777 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qdoc for C++ and QML
On 25/04/2017 09:29, Martin Smith wrote: >> What would be incorrect as those APIs are only internal for C++, but >> public for QML or v.v. > > Then we need \cpponly and \qmlonly, or something like that. This is calling for future headaches, when you start adding python or other languages. It's better to just support using \cpp, \qml, \python tags; and if no tags appear, then it's assumed that the documentation applies to all languages. Also \nocpp, \noqml and \nopython could be useful. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] XMLHttpRequest.send() with arbitrary data
Hi all, my understanding looking at the implementation of the XMLHttpRequest.send() method in QtDeclarative [1] is that the said method only accepts UTF-8 data as parameter. Now, I would like to be able to send arbitrary data (in order to, for example, upload a JPEG image to flickr) and I believe that the limitation above is preventing me from doing so: my QByteArray (which I'm actually preparing from the C++ side and then converting into a QString with QString::fromUtf8()) is not being transmitted properly. No surprise here, as I understand that the QString::fromUtf8() method will stop as soon as a zero byte is found. But than, what is the way forward? I see that javascript has some more types such as Blob and ArrayBufferView, which at least judging by the name could be suitable types for transporting binary data. I see that there is a newArrayBuffer() method in QJSEngine's private class; would exporting that to the client help in any way? Or should the implementation of XMLHttpRequest.send() try to first convert its parameter to a QByteArray (via QJSValue::fromScriptValue()) and only fallback to QString if that fails? Ciao, Alberto [1]: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/qqmlxmlhttprequest.cpp?h=dev#n1814 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] XMLHttpRequest.send() with arbitrary data
On 06/23/2017 10:08 AM, Simon Hausmann wrote: I think send() should be fixed to support more than just strings as parameters. For example in browsers you can use send() with array buffers and blob objects. We don't support the latter, but the former we do and they are also our mapping for QByteArray. Want to give it a try? It should be a relatively straight-forward change and we have good XHR test coverage, so it should be easy to extend the tests to cover this. Why not :-) I filed https://bugreports.qt.io/browse/QTBUG-61599, feel free to assign that to me. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Review request
Hi there! I've got a few merge proposals which were recently closed by the Qt cleanup bot due to lack of activity; I've reopened them and ping a few people, but to no avail. All but one are tiny, and I would appreciate if someone could spend a couple of minutes to give the final +2 or to advise about moving them to a different release (I guess that at least the one targeting 5.8 should probably be moved to 5.9, given that 5.8 is not an LTS): https://codereview.qt-project.org/#/q/owner:mardy%2540users.sourceforge.net+status:open,n,z TIA, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Review request
On 29/10/2017 22:45, Thiago Macieira wrote: > I wish I could help in the reviews, but those are not things I understand at > all. But I can give this advice: the three changes targetting pre-5.9 need to > be updated. All three should be retargetted at 5.9. Good to know! I'll resubmit them, thanks! Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Using native webview on OS X
Hi all! I've developed a desktop application which uses the WebView QML module, with the hope of publishing it in the Apple store. However, unless I am seriously mistaken, this is just not possible (or maybe the documentation needs some serious love). No matter what I try, it seems that QtWebEngine is always required! If I simply remove QtWebEngine from my Qt installation, building the application succeeds but then when I run it I get the same error as in https://bugreports.qt.io/browse/QTBUG-63107 If I look at src/webview/qtwebviewfunctions.cpp it looks like the decision to use the native webview vs QtWebEngine is done at runtime, but for some reason it looks like one still needs to have QtWebEngine available in order for QtWebView to build successfully. With the obvious consequence that one won't be able to publish one's app into the Apple store. Is there some reason why the QtWebEngine support library isn't dlopen'ed at runtime? Can I file a bug about that? Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using native webview on OS X
On 22/01/2018 18:49, Konstantin Tokarev wrote: > From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable > is required to use native backend. > > [1] https://codereview.qt-project.org/#/c/162337/ Yes, but still QtWebEngine is required, as QtWebView is linking to it. I've now removed a few lines of code here and there and got a version of QtWebView which builds fine under macos without being linked to QtWebEngine. I'll soon try to see if it actually works. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Namespacing QML context properties
Hi all!
One of the issues that has most bothered me when developing in QML is
dealing with the same variable name in item properties and context
properties. For example:
// "model" is a context property
Loader {
property variant model: model
sourceComponent: someComponent
}
The code above will not work. And I cannot find a way to make the
"model" context property available to the loader source component. For
reference:
http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-loader.html#using-a-loader-within-a-view-delegate
See especially the last code snippet there. Notice how the variable name
had to be changed from "index" to "modelIndex", in order to workaround
the issue I described above.
However, renaming properties is not always desirable.
Are there some tricks I'm not aware of? If not, what about introducing a
reserved word (maybe "qmlContext"), and let it refer to the current context?
So, one could write qmlContext.variableName to avoid ambiguity with
properties names "variableName", and my example above would change like
this:
Loader {
property variant model: qmlContext.model
sourceComponent: someComponent
}
Thoughts?
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Namespacing QML context properties
On 12/09/2013 12:54 AM, Alan Alpert wrote:
> On Sun, Dec 8, 2013 at 5:38 AM, Alberto Mardegan
> wrote:
[...]
> What do you mean "current context"? The problem you seem to be hitting
> is that there is another symbol in the current context that you want
> to avoid, so that it finds a symbol higher up the tree. That would
> mean something like engine.rootContext(), but I don't think that would
> make sense in QML.
I don't really want the engine.rootContext(), but actually
engine.contextForObject(this). Please have a look at this example, and
suppose that I want to use this as a delegate in a ListView, in order to
provide a different delegate for each element in the list, depending on
some property in the model:
Item {
ListView {
model: ...
delegate: loader
}
Component {
id: delegate1
Rectangle { color: model.color; ... }
}
Component {
id: delegate2
Text { text: model.text; ... }
}
Loader {
id: loader
// property variant model: model
sourceComponent: model.someProperty ? delegate1 : delegate2
}
}
Now, if I don't remove the comment, the actual delegates loaded by the
Loader (delegate1 and delegate2) won't see the "model" property; but if
I uncomment the line, it won't work either, because inside the Loader's
definition the property named "model" will obscure the context property
having the same name.
How would you solve this (without of course renaming variables or moving
components around: suppose that I have no control over the listview or
delegates' code)?
And another simpler case, this:
Item {
ListView {
model: ...
delegate: ComboBox {
text: model.displayName
}
}
}
And suppose that a certain point the authors of the ComboBox element
change it by adding a "model" property to it. That would break the code
above, because "model" wouldn't refer anymore to the "model" injected by
the ListView, but to the new ComboBox property!
But if you had a way to select your local context with some prefix, no
breakage could ever happen:
Item {
ListView {
model: ...
delegate: ComboBox {
text: qmlContext.model.displayName
}
}
}
I hope that the question is now clearer. :-)
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Namespacing QML context properties
On 12/09/2013 10:00 AM, Alan Alpert wrote:
> Question does seem a bit clearer. But I think the answer is the same -
> ListView shouldn't be using context properties anymore. Well, it's
> worthwhile for the convenience here but maybe add an attached property
> reference as well for those cases needing more precision:
>
> Item {
> ListView {
> model: 3
> delegate: ComboBox {
> text: ListView.modelData.displayName //unambiguous*
> }
> }
> }
That sounds good. I created
https://bugreports.qt-project.org/browse/QTBUG-35476
Feel free to assign that to me, if you are not in a hurry to solve it. :-)
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] Would a (QML) model aggregator class a welcome addition?
Hi all!
For one of my projects, I found the need to merge several models into
a single model. I wrote a class for it, and I think it's generic enough
to be useful for other people, and I wonder if it could be put into Qt
itself:
https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
Note that the thing is not complete (especially the implementation),
it's just in a state where I can use it in my application; it needs a
bit of more work before being ready for the generic use.
I'm wondering if I should make this extra effort or not. :-)
If the answer is yes, should it be added to QtCore or QtDeclarative?
Right now it's using QQmlListProperty so that the source models can be
declared inline,
ModelAggregator {
Model1 { ... }
Model2 { ... }
...
}
but that could be removed and substituted by a simple QList of models if
desired.
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)
On 01/15/2014 10:48 PM, Alan Alpert wrote: > This approach could also apply to the original suggestion by Alberto, > in the absence of a separate add on module (which Sean couldn't use > because of the QtQuick.Controls dependency). Just requires a higher > bar for code review/quality, but I'm currently leaning in favor of > extra models convenience classes. It's a decent hold over measure > since the new model/views have been taking so long. That's good to know. :-) I've got a question on the implementation side: when writing convenience classes which proxy (part of) the contents of a source model (or many), is it fine to code the source model type as a QAbstractItemModel? If so, what will happen if people try to set QML string lists (or lists of objects) as source property for the proxy model? Will the QML engine do the wrapping into a QAIM, or will this simply not work? If it doesn't work, do we care? I guess these classes are mostly meant to easily expose C++ QAIMs to QML, but it's not always the case. It would make sense for my ModelAggregator element to work with string lists as well, and also a FilterProxyModel which presents a filtered sub-model of a source model could be expected to work on QML string lists as well... Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] XDG icon theme support
On 03/30/2014 03:56 PM, Gladhorn Frederik wrote: > A fix for this would certainly be appreciated. > http://qt-project.org/wiki/Gerrit-Introduction > > On Saturday 29. March 2014 14.56.16 Rex Dieter wrote: >> Ruslan Nigmatullin wrote: >>> If the changes will be done and accepted is there any hope to have them in >>> Qt 5.2.* >> >> It's a bug fix rather than a new feature, so yeah, I'd expect it could be >> included in a subsequent bugfix release (assuming there is one). > > There will be no more 5.2 releases. If you get the patch soon it might make > it into 5.3.0. If you care about this bug being fixed soon in Ubuntu, please file it in https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQml value types
On 04/24/2014 03:11 PM, Joshua Kolden wrote: [...] > We have a solution that works very well for us using QVariantMaps and an > MVC pattern / strong separation between data objects and view. It > appears to me that most people are having this issue because it’s not > common to use MVC with QtWidgets. But you can easily expose complex > data structures to QtQuick without subclassing QObject via QVariantMaps. [...] While your proposed approach is rather clean, it carries one drawback, which is the lack of type information, with all its consequences. For instance, I would like to have a GeoPoint type with "latitude" and "longitude" properties; if I exposed it as a QVariantMap, I wouldn't be able to prevent the QML code from doing stuff like: p.latitude = 60 p.longitde = 10 // note the typo Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls for Embedded
Hi Frederik, On 04/09/2015 04:04 PM, Frederik Gladhorn wrote: > We want to give you the code, here it is :) > https://codereview.qt-project.org/#/admin/projects/qt-labs/qtquickcontrols2 [...] > Feedback welcome! If I understand correctly, these controls are intended to be a cross-platform set of controls with their own style, with the goal of being good looking and still have a good performance; the goal is not to wrap (or make them look alike) any of the platform native controls, unlike for example qtqmlandroid. Is my understanding correct? If so, it seems to me that the naming is somehow confusing: on one hand we have qtquickcontrols1, which provides a uniform API to render native-looking controls; on the other hand, the qtquickcontrols2 module seems to have a very different goal. Maybe this qtquickcontrols2 module should be renamed to something like qtquickembedded, to avoid giving the false impression that is meant to supersede the existing module? And will qtqmlandroid eventually be merged into qtquickcontrols1, once it's ready? Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rotating JPEG images by default
On 04/17/2015 11:48 AM, Allan Sandfeld Jensen wrote: > If we go with the QImageReader level, it could be an QImageIOHandler::Option, > and possibly be set different between JPEG and TIFF by default. The real > problem is what we decide the default for JPEG should be now. IMHO, QImageReader default behaviour should be that of providing a rendered image that looks as visually correct as possible. Whether the orientation is encoded in the image bits or as an EXIF tag is rather irrelevant: the result should be that the QImage contains the image shown with the proper orientation. So, I'm very happy that this bug has been fixed. On the other hand, since we had applications which had already implemented workarounds for this, we should have a way to let them know whether they are using a new Qt image plugin which contains this fix or not. Adding an orientation option to QImageIOHandler::ImageOption would be a possibility. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rotating JPEG images by default
On 04/22/2015 09:39 AM, André Somers wrote:
> I'm with Konstatin on this one: it seems like a regression to me. It
> would be a useful feature to add, but then add it in such a way that it
> is actually clear what it does, the user can control it, and it does not
> break applications. I think it _is_ relevant how the image is encoded.
It may be that we disagree because we have a different view of what is
the goal of QImage and friends. To me, what matters is not the pixel
data, but how the image looks like when I blit it.
I'm writing an image viewer using QML, and I just expect that
Image {
source: "file.jpg"
}
will show me the file as it's intended to be viewed. I don't think that
it's acceptable to require the developer to play with flags in order to
see the image with the correct rotation.
> If the camera really wanted to put the image in the right side up, it
> should have just rotated the actual image. By default, I would expect to
> load the image as-is.
We disagree on what "as-is" means. :-) For me, EXIF information is an
integral part of the image.
Also, sometimes the camera guesses the orientation wrong (especially
when you shoot at the sky or at the ground), and the best way to correct
that is to do it in a lossless way, using the EXIF rotation flag; there
are several image viewers that allow you to do this.
Ciao,
Alberto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rotating JPEG images by default
On 04/22/2015 09:54 PM, André Pönitz wrote: > However, we do have context here, namely existing behaviour in Qt 5.x, > as well as certain general promises given for changes between Qt 5.x and > Qt 5.(x+1). I see it as a long standing bug which finally got fixed. But the problem is that the behavioural change is already out there, with Qt 5.4. I think it would be easier to have a runtime check on the QT version (and eventually drop the local workarounds) than to introduce another behavioural change in the next Qt version. > Even though "no behaviour change" isn't one of the guarantees, I don't > think rotating part of an application's GUI by 90 degrees behind the > developer's back is acceptable. It's very unlikely that such images are used as part of the GUI. But I'm nitpicking, I certainly agree with you that the behavioural change is a major annoyance. However, if application developers had filed this bug earlier, instead of silently working around it in their application, we wouldn't even be discussing this. So, in a way, I believe that if this behavioural change affects someone in a bad way, some part of the blame falls on his side too. > If an application accepts such change it should announce it by explicitly > opting in, i.e. by setting a flag/calling a function/whatever. Actually, this sounds like a very good idea; I wouldn't mind if this was a opt-in, as long as the behaviour was configurable with a single line change (a static method on QGuiApplication, maybe?). As long as I don't have to change it in every single QImage/QML Image, all is fine to me. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rotating JPEG images by default
On 04/23/2015 04:53 AM, Konstantin Ritt wrote: > We already have a complete solution - > https://codereview.qt-project.org/110685 That looks good. > All we need now is to fix the behavioral regression introduced in 5.4. But if I understand the code correctly, the fix above gives developers an option to opt *out* of the automatic rotation, so it will still behave differently than Qt < 5.4, unless the developer updates his app to use the new API. Which to me is all very good, but I think it's not what you have been suggesting in this thread. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rotating JPEG images by default
On 04/23/2015 01:36 PM, Gunnar Sletta wrote: > I think we should strive to not introduce regressions on purpose. Hence: > - Revert the behavioral change in 5.4 which adds rotation to JPEGs > - Have opt-in rotation in QImageReader. > - Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt > 6) > > Anything else will cause us a lot of pain down the line. Also the above causes some pain. Whether we go for opt-in or opt-out of the automatic rotation, please have a static method to globally specify whether automatic rotation is desired or not. We should have QML Image show the JPEGs with the correct rotation without requiring special flags or custom image readers. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Rotating JPEG images by default
On 04/23/2015 02:34 PM, André Somers wrote:
> What is the problem with using
>
> Image {
> source: "someImage.jpg"
> autorotate: true
> }
>
> Again: note that QImage != QML Image
>
> I don't like globals if they can be avoided. In this case, I think they can.
I could certainly live with that, but if you renamed "autorotate" to
"showWithCorrectRotation" you'd have to agree that it's a rather silly
flag. Of course I want my images to appear with the correct rotation. :-)
I do agree that for QImage leaving the autorotation off can make sense
in some cases. But for QML Image, I cannot think of a single case where
I wouldn't want a JPEG to be automatically rotated.
Ciao,
Alberto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QQmlEngine and ObjectOwnership
Hi Massimo, On 04/28/2015 07:46 AM, Massimo Callegari wrote: > I just wanted to share my specific(?) case so if someone stumbles on it, they > can find the solution out of the box :) I also stumbled on this problem once. Luckily, the documentation is quite clear on this -- the problem is that it's not that easy to find it. :-) http://doc.qt.io/qt-5/qqmlengine.html#ObjectOwnership-enum Note that regardless what you think of these heuristics, it's too late to change them: existing applications will either start crashing or leaking memory, so it's a no-go. > I am wondering though, in a multi-context application, where you have a > MainView.qml with a big > Loader that changes context when clicking on some buttons, where do you place > "shared" Items that > need to be accessed by a context that don't know anything about the other > contexts ? This, and what you previously wrote (that these objects stay alive for the whole lifetime of the app) makes me think that you probably want to register your objects as singletons: http://doc.qt.io/qt-5/qqmlengine.html#qmlRegisterSingletonType Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt & Namespaces (was: RE: Some Qt3D feedback)
On 18.06.2015 15:59, Smith Martin wrote: > Why not leave current Qt modules as they are, without namespaces and with the > Q prefix on classes, and just introduce the option of adding a new module to > Qt by putting it in a namespace named QtFoo without the Q prefix on class > names, or adding it with no namespace and with the Q prefix on classes. I can see the benefits of using namespaces when the namespace is longer than a few characters. But at lesat in the Qt3D case, IMHO it's much better to remove the namespace because that will give all developers better search results when they search for class names: searching for "Qt3DWindow" will only give relevant results, while when searching for "Window" or "QWindow" the desired results could get lost in the noise. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Making ItemSelectionModel more useful
Hi all! Since Qt 5.5, the QItemSelectionModel class is exposed to QML as ItemSelectionModel (in the QtQml.Models module): http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html Apart from having almost no documentation, this component seems to be rather hard to use in QML: its methods work with QModelIndex (while all the models I've ever used in QML just speak row numbers) or QItemSelection, which I believe is not usable in QML at all (at least, it's not documented as a QML component). I understand that the reason for all of this is that QItemSelectionModel is a class originally created for C++ consumption, and that the QModelIndex makes a lot of sense there. However, I would argue that the QML version is hardly usable. As I see it, either this class gets a "model" property and methods which operate on integers (row numbers), or QModelIndex and QItemSelection need to become first class citizens in QML as well. I guess that having Q_GADGET is already a huge step forward, but we should also have a generic way to turn a model+rowNumber into a QModelIndex: maybe a global method Qt.makeIndex(model, row), which would also work on all models supported by the QML engine? Are there any plans about this, or what would be the best way to address this? Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making ItemSelectionModel more useful
On 23/02/2016 01:31, deDietrich Gabriel wrote: > The story behind having QModelIndex and QItemSelectionModel exposed > to the QML engine was to solve the selection problem in the Qt Quick > Controls 1 TreeView. TableView could use a simple selection model > because of the trivial mapping between table row and model index. > That’s not possible for the TreeView, so we decided to reuse what was > already available in the QtWidgets side. Note that > QAbstractItemModel::index() and several more functions have been made > invokable. So those are available in QML provided your model is > QAIM-based. Thanks Gabriel, I have a more clear understanding now. I actually notice that there is documentation here for QModelIndex and QItemSelection: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/types/qqmlitemmodels.qdoc However, I cannot find that page in the documentation website; could you please check why? Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Units in QML
On 25/02/2016 13:20, Welbourne Edward wrote: > André Somers used m* for minutes and metres, footnoting: >> )* Note the first clash already... > > I think it is fairly sane to just insist that SI units take precedence, > especially given that we support multi-letter unit names (e.g. pt, px, > mm, cm), so min will do fine for minutes. I find this attention to physical units a bit improper. Sure, some drawing applications or text editors should be enabled to draw UI following specific physical dimensions (like, for example, for the ruler bars), but I think it's more of an isolated case than the norm. Most UIs won't set a button's height to 1 cm (or any other physical size), because while such a size might be OK for a desktop + mouse system, it would be definitely be too small for a UI in running a television set and too big for a UI running on a smartwatch. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QDrag and mouse events to QML MouseArea
Hi all! I wanted to try fixing this bug: https://bugreports.qt.io/browse/QTBUG-49876 (in QML, the dragged item disappears during the drag and drop operation, if the dragType is Drag.Automatic -- external drag) First of all, after some investigation I wonder whether this is actually a bug, or if we should just document that during an external (inter-process) drag the QML item won't be dragged; if one wants to see a QML item being dragged during an external drag, then that's QTBUG-37366, which I'm attempting to fix here (reviews welcome, BTW): https://codereview.qt-project.org/#/c/155445/ So, the question is whether QTBUG-49876 is valid at all. And if it is valid, how should it be fixed? Maybe QSimpleDrag's eventFilter() could forward the mouse move events to the QWindow, but I suspect that this might not play too well with hovering; so, it should be done only when QDrag is explicitly asked to. Also, QSimpleDrag is AFAIK used only in Linux and OS X, so there should be a different implementation for Windows. My suggestion is that the bug is invalid, and we document that when initiating an external DnD operations the target item should be anchored (so that it does not move at all) and that the new Drag.pixmapUrl property can be used to provide a visual feedback. Opinions welcome :-) Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On 01/06/2016 18:12, Mathias Hasselmann wrote:
> Yes, when it comes to initializer lists the trailing comma looks ugly to
> me. Because of the inconsistent two-space indent for the first
> initializer. Because line starts of are not aligned.
In my projects I use this style:
MyObject::MyObject():
SuperClass(),
m_var1(),
m_var2()
{
}
Having a diff taking two lines never annoyed me, especially given that
often the last member is either d_ptr() or q_ptr(), so I usually add
members in the middle.
> Not mentioned yet: Conditional compilation vs. stable ABI:
>
> MamanBar::MamanBar(...)
> : m_field1(...),
> m_field2(...),// oh...
> #ifdef FEATURE1_ENABLED
> m_field3(...), // ...ah
> #endif
> #ifdef FEATURE2_ENABLED
> m_field4(...)
> #endif
> {
> }
You can always find cases which break with either style.
MamanBar::MamanBar(...)
#ifdef FEATURE1_ENABLED
: m_field1(...) // ...ah
#endif
, m_field2(...)
, m_field3(...)
{
}
Ultimately, it's just a matter of personal preferences; people like to
argue about diff size or better spotting of obvious mistakes (when
putting operators at the beginning of the line), while as a matter of
fact people can live perfectly well and be equally productive with
either style.
Ciao,
Alberto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: change QML Flickable's flickableDirection default value to AutoFlickIfNeeded in 5.8
On 07/26/2016 05:12 PM, Andrea Bernabei wrote: > I'd like to propose changing the default value of QML Flickable's > flickableDirection in Qt 5.8. I vote against it :-) While I agree that your proposal makes sense, I would advise against implementing it before Qt 6. There are lots of programs out there using Flickable, and we don't know how this change will affect them. For instance, one application might be monitoring the "dragging" property and perform some action when it changes, and after your proposal is implemented it will stop receiving it. I'm especially thinking of "pull to refresh" implementations, which might completely stop working. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QMetaType and type aliases for primitive types
Hi there!
I'm struggling to understand what's going on with types being
marshalled onto D-Bus, and I'd like to understand if what I'm seeing is
a but with the Qt version I'm using (Qt 5.12.7 + some patches), an issue
with the compiler, or just the expected behaviour.
The problem is that QtDBus fails to send some messages:
QDBusMarshaller: type `long' (32) is not registered with D-BUS. Use
qDBusRegisterMetaType to register it
What happens is that I'm creating a QVariant and writing a int64_t
inside it, and for some reason:
1) QMetaType resolves that to "long", so the QVariant ends up holding a
"long", and not a "int64_t".
2) QtDBus claims not to be able to marshal a "long"
I've being trying to understand why (1) happens: immediately as the
program starts, if I print the numeric ID of the "int64_t" type, I get 0
(which is fair, I guess).
Then I do
qRegisterMetaType("int64_t");
and afterwards I see that its QMetaType ID is 32, but
QMetaType::typeName(32) returns "long". I tried using the
Q_DECLARE_METATYPE() and Q_DECLARE_TYPEINFO() macros, but in both cases
the compiler complains that the type is being redefined:
server.cpp:108:1: error: redefinition of 'struct QMetaTypeId'
Q_DECLARE_METATYPE(int64_t);
I'm not sure how to proceed. I really would like to continue using the
standard C types, because they are part of a D-Bus API and their length
should not change depending on the CPU architecture.
Interestingly, I'm seeing this on amd64 only; it seems that on armhf
everything is working fine. Could it be a bug with the compiler?
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaType and type aliases for primitive types
On 08/05/21 10:48, Alberto Mardegan wrote:
> Interestingly, I'm seeing this on amd64 only; it seems that on armhf
> everything is working fine. Could it be a bug with the compiler?
In armhf, QMetaType::type("int64_t") always returns 4 (LongLong), even
before registering the metatype (maybe this step is done in some library
I'm using?), which is a type supported by QtDBus, so everything works there.
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QMetaType and type aliases for primitive types
Hi Tiago,
On 08/05/21 18:47, Thiago Macieira wrote:
> And the problem is that they *do* depend on the CPU architecture. long
> changes
> size depending on OS and pointer size.
yes, I knew that long changes size depending on the architecture, but:
> As far as I am concerned, the fact that
> int64_t, size_t and ptrdiff_t sometimes (not always!) use long is a
> misfeature. Those decisions were made in the early 90s by C, before long long
> existed in the standard, and before C++ with overloads and ABI became an
> important thing. So we carry some legacy.
what I didn't know (or wasn't fully aware of the consequences) is that
the {,u}intX_t types are just typedefs.
>> Interestingly, I'm seeing this on amd64 only; it seems that on armhf
>> everything is working fine. Could it be a bug with the compiler?
>
> No, that's because there the compiler defines int64_t as a different type
> (long long) because long is only 32-bit.
I see, now it makes sense. It looks like so far I managed to workaround
the problem by changing int64_t to qint64 in a handful of places only,
and changing the metatype registration to:
qRegisterMetaType("int64_t");
qRegisterMetaType("uint64_t");
which makes Q_PROPERTY use the right type when I declare them as
int64_t. Though maybe I'll eventually get rid of int64_t completely...
Ciao and thanks,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] QString, QVariant and QSQLite
Hi there! I'm encountering some sort of memory corruption issue in a library I'm using, which does not cause a crash, but rather a QSQLite query to sometimes simply return no results, without errors or warnings. You can find the valgrind trace here: https://git.sailfishos.org/mer-core/qtcontacts-sqlite/issues/7#note_90394 What is happening is that we bind a couple of SQLite parameters to a prepared query. The first bound parameter is a QString. 1) The string is stored into a QVariant 2) QSqlQuery::bindValue() is called 3) in the sqlite plugin, the qvariant is copied into a const QVariant: https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp?h=5.12#n503 4) in line 539 of the SQLite plugin, the contents of the QVariant are obtained just by calling QString::utf16() on the string data, without extracting it from the QVariant. 5) the data is passed to sqlite with SQLITE_STATIC (sqlite will NOT copy it) 6) we move forward and iterate to the next bound parameter 7) our const QVariant goes out of scope (though valgrind shows that the destructor is actually called on the next iteration of the for loop -- but I guess this is not fundamental) 8) the destructor of the const QVariant calls the destructor of the QString stored in it, which frees the memory allocated in point 4 by QString::utf16() Now, I haven't dug very deep in QString and QVariant, I preferred to let the experts talk first :-) Does the code in the QSQLite plugin look correct to you? Is it expected that QString::utf16() makes a memory allocation? And is it correct that this happens even when the QString is const? And why destroying a const QVariant causes the deallocation of the data created by QString::utf16()?? The most plausible explanation is that I have some memory corruption somewhere else in the program, but I find it curious that it never crashes the program and that it manifests itself always in this code path. Notice also that if I call QString::detach() on my parameter before storing it into the QVariant I pass to QSqlQuery::bindValue(), then valgrind never complains and QSQLite returns the expected results. Or do you think it could be a bug in the QSQLite plugin? Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QString, QVariant and QSQLite
On 26/05/21 23:31, Christian Ehrlicher wrote: > Your observation looks correct even though I wonder why this was never > found before since this was not changed since the initial Qt5 import :) > What Qt version do you use? > Please fill a bug report with a minimal, compilable example. I'm using Qt 5.12, but as you wrote, this part of code has not being deeply modified in years. I'll file a bug if I manage to code a small example which reproduces it. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QString, QVariant and QSQLite
On 27/05/21 11:50, Giuseppe D'Angelo via Development wrote: > In the overwhelming majority of cases, utf16() won't make any > allocation. There's just one exception -- if the QString was built via > fromRawData(). In that case, in order to ensure NUL termination, utf16() > does actually "detach" (even if it's a const method). mmm... The string is created in QML and assigned to a property, like this: relationshipType: "Aggregates" so I'm not sure if this uses fromRawData() or something else. >> And why destroying a const QVariant causes the deallocation of the data >> created by QString::utf16()?? > > QString::utf16 doesn't "create" data: it modifies the string *itself* so > that it becomes detached and NUL terminated. Sure, I meant s/created/allocated/ Anyway, I filed this bug: https://bugreports.qt.io/browse/QTBUG-94070 Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt Multimedia
Hi Lars, On 26/05/21 15:09, Lars Knoll wrote: > The hope is that we can change that for Qt 6. To make this possible, we have > changed not only parts of the public API, but completely redone its internal > architecture, especially how multimedia connects to the platform specific > backends. Apart from cleaning up the backend API and greatly simplifying it, > I also chose to make it private and remove the plugin architecture around it. > The backend is now selected at compile time, and we’re now only supporting > one backend per platform. can you please clarify what this would mean for projects (like Ubuntu Touch) which are using their own QtMultimedia plugins? Supporting one plugin per platform seems reasonable, but making the plugin API private and selecting the plugin at compile time probably means that all multimedia backends must be made part of QtMultimedia git repository, right? Or is it so that the backend is selected at compile time, but it can still be dynamically loaded from a separate plugin binary? This has the potential to make things harder to develop, especially for smaller projects like ours. I'm especially thinking of: 1) The QtProject might even flatly refuse to include a backend which is only used in a minor platform 2) It will be hard (if not impossible) to run CI on it, we'll only be able to test the Qt builds in our own CI, but that might be too late (I mean, it's not really CI anymore) 3) Licensing issues (well, this is not a problem for our specific case, I think) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt Multimedia
On 28/05/21 11:09, Lars Knoll wrote: > Before we go into the topics below, can we take a step back, please? I’d > first like to know *why* you were developing and maintaining your own > multimedia backend. In short, because of lifecycle. In Ubuntu Touch, applications are stopped when in the background, so the system offers services which provide support for long-running operations. One of them is playing audio: our QtMultimedia plugin is little more than a thin D-Bus library that delegates all the work to a D-Bus service (which itself is running GStreamer). Besides that, the media service also pauses the music when a phone call comes or an alert sound arrives, and has logic for a few other cases that would be hard (if not impossible) to achieve for a confined application. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Feature freeze exception for QTBUG-95587
On 13/09/21 21:58, Elvis Stansvik wrote: > I don't see what's inherently wrong with a plain function like > Qt.resolvedUrl. It's very obvious - it says what it does on the tin. > Names are good that way. FWIW I've been using it for ages, and yes, if it initially it sounded a bit verbose, now I'm perfectly accustomed to it. > @ on the other hand would be completely opaque to a newcomer. > > When in a later mail, you reject qsUrl as an alternative to > Qt.resolvedUrl because 'it doesn't express "resolved"', I must ask: > How exactly does @ express "resolved"? qsUrl could be a nice addition, but even than, I don't feel such a strong need for it either. I think that the point raised by Oswald, about the waste of using "@" for such a narrow functionality, also deserves more attention. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Formal voting procedure for Qt Project
Hi!
I know I'm coming too late with this, but maybe it's something that
can be considered as for future developments of the voting bot:
On 04/10/21 13:08, Daniel Smith wrote:
> If anyone wishes to verify that their personal vote has been recorded
> correctly, they can email gerrit-ad...@qt-project.org to have an independent
> party with database access verify their vote appears correctly in the system.
IMHO the bot should make the vote public: there should be a static page,
visible to everybody (even non authenticated users), containing a list
of names (or signatures) and their vote next to each signature.
The trick is that these names do not need to be real: once the voter
authenticates him/herself into the system, he/she casts a vote and types
in a signature, which of course does not need to be his/her real name,
but anything that he/she will now know to be associated with the vote:
it can be a name like Napoleon, or a sentence like "The lazy fox jumped
again".
In this way every voter would be able to independently verify that
his/her vote was counted correctly by just looking at this static page
("is my signature there, and with the vote I casted next to it?"), and
everyone interested can know (by seeing that no voter is protesting
about his/her vote not being in the page) that no fraud occurred.
This still leaves the door open to hackers inserting more votes into the
voting bot, but then this could also be tackled by showing at the top of
the page the list of the usernames of the people who voted: if the total
number of voting usernames is not equal to the total number of votes
registered, again we know that the vote is not correct.
Ciao,
Alberto
--
http://www.mardy.it - Geek in un lingua international
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] QtMultimedia FM radio and plugin support in Qt6
Hi all! When the new QtMultimedia was announced [1], there was a mention that the Radio API was being removed (by the way, there is no mention of this removal in the migration document [2]). Did it happen because of a lack of time, or were there other reasons? Is it going to come back? I also would like to resurrect the topic of loadable plugins for the backends. While in Ubuntu Touch we don't have plans to migrate to Qt6 any time soon, this is definitely going to happen sooner or later, and our backend is not supported. So the obvious question is how we will have to proceed: would the Qt project accept the contribution of an additional backend, are there any chances of getting the plugin API back, or should we maintain an out-of-tree mega patch for our backend? The latter option, while the simplest for the Qt Project, would be rather hard for us to work with. I wonder, therefore, if it would be possible to have a compromise, that is that the plugin support gets re-introduced as a build option, as if it was a backend on its own like the Linux, Android, Windows etc. ones. Or if it was somehow delivered as a private API with no promise of stability, that would also do it. Ciao, Alberto [1]: https://lists.qt-project.org/pipermail/development/2021-May/041458.html [2]: https://doc.qt.io/QT-6/qtmultimedia-changes-qt6.html -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QtMultimedia FM radio and plugin support in Qt6
Hi Lars, On 13/12/21 11:14, Lars Knoll wrote: >> When the new QtMultimedia was announced [1], there was a mention that >> the Radio API was being removed (by the way, there is no mention of this >> removal in the migration document [2]). Did it happen because of a lack >> of time, or were there other reasons? Is it going to come back? > > It wasn’t mentioned because the API was not implemented in any of the > backends we provided, ie. it was non-functional for regular Qt packages. Ah, indeed I was a bit surprised looking at the v4l radio plugin code, because it looks like it does not implement all of the the pure virtual functions declared in the QRadioTunerControl interface, so I was wondering how it could possibly work. :-) > We could consider having one plugin for all of Qt MM. But I certainly do not > want to go back to what we had in Qt 5, namely one plugin per functionality > group, as that makes things extremely messy to implement. I see, and that would also fit our use case. > I would be fine with an additional backend maintained inside Qt MM, but it > also depends a bit on what you prefer. Btw, how is your backend different > from what we have in Qt 5.15? We delegate audio/video playback to a separate D-Bus service. In this way the playback can continue even when the application is moved to the background (background applications get stopped in Ubuntu Touch after a couple of seconds). There are also a few other benefits to this approach (resource management, delivering the playback state via a global MPRIS interface, etc.), but this is by far the most pressing reason. > One thing I can say already now is that I do not want to go back to Qt 5 > times and make the backend API public. We will need the freedom to change the > API between versions where required. That's also fine. > It is already available as private API, and there’s a hook to load a > different backend in 6.2. Have a look at > QPlatformMediaIntegration::setIntegration(). We’re using it to test the > frontend API with a dummy backend. > > So you should be able to do most things today, but you’d need a global > constructor functions that sets up the integration somewhere. Right. So if we don't want to patch Qt, we should either get our platform integration upstreamed, or introduce a plugin loading mechanism that instantiates a QPlatformMediaIntegration subclass, possibly using an environment variable for the selection. Anyway, the situation doesn't look as gloomy as I initially thought. And we are not talking about the immediate future, so it may be that by the time we move to Qt6 things will have already changed. :-) Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Maintainance Tool
On 06/03/22 17:07, coroberti wrote: There are KDE repos, aren't there? For example: https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15 The source code, as far as I can tell, it's not the problem. The problem is with the binary releases, and I cannot find them in the KDE site. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Maintainance Tool
On 06/03/22 16:23, Konstantin Ritt wrote: For those who have experienced inconvenience due to these blockings, I propose to gather at some public site and create binaries repo driven by community, not by political influences. Sorry for jumping in so late. Please count me in. My problem is that, despite living in Russia, I'm not integrated with the community and I'm not aware of which hostings could be used. I guess that a self-hosted gitlab could be the easiest choice, but I'm willing to help regardless of the solution chosen (even just copying the Qt binaries over to a static site could be an option, for the time being). Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Problem with QML garbage collection (Qt 5.15)
Hi there! I think I'm experiencing an issue related to https://bugreports.qt.io/browse/QTBUG-50319 In my case, I have a C++ method returning a new QObject, which has automatic Javascript ownership. This is fine, because indeed I want to have my object managed by the QML engine. Then I'm passing the object as a property to a subpage, and also storing it into a ListModel (by calling append()). If I navigate to the subpage where I passed my object as a property, I can see that it is working fine. If I then navigate to another page where I have a ListView operating on that ListModel where I added my object, that works fine as well. The problem happens when I navigate back from the page with the ListView. It seems to me, that when that page gets destroyed my object gets destroyed as well, despite being still used in the ListModel (which is never getting destroyed). I'm working around this by setting the ownership to C++ and never actually destroying the objects (since I have few of them anyways), but I suspect that this might be a bug in the garbage collection. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Problem with QML garbage collection (Qt 5.15)
Hi Furkan, On 01/05/22 20:01, Furkan Üzümcü wrote: I think adding an object to a `ListModel` does not alter its ownership. If the page with the initial property which holds a reference to the object returned from the C++ method is destroyed, then I would expect that object to be destroyed as well. mmm... I don't know. My understanding of the documentation is different: "When the object is returned to QML as the return value of a method call, QML will track it and delete it if there are no remaining JavaScript references to it and it has no QObject::parent()." My object is a QObject with no parent, so I would expect the QML engine to track the object (even across property assignments and insertion into models) with some reference counting, and only destroy it when *all* references are dropped. Personally, I usually prefer to control the life time of an object by the C++ side or by instantiated types in the QML side. Unless I’m wrong about `ListModel` not taking ownership in `append`, I’d recommend not tempering with the object ownership rules manually. Well, if I don't tamper with the ownership, then it will get Javascript ownership and get destroyed too soon, when I'm still using it in the model. Also, is there a code sample that you can provide for this? I'm afraid I don't have time for that, but if you are interested, the code is all in this branch: https://gitlab.com/mardy/mitubo/-/tree/download Steps to reproduce: 1. Revert this commit: YoutubeDl: set C++ ownership on downloads (f5cb1d1c) 2. qbs run 3. Search for something (e.g., "ciao") 4. In the results, pick any item and press "More", then "Download", the the Download button again 5. Without waiting for the download to complete, press "back" (<) until you return to the main page 6. Click on the menu (the hamburger icon), press Downloads Now if you repeat steps 3-6 once more, on step 6 the download data will be missing and you'll see warnings in the console. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Problem with QML garbage collection (Qt 5.15)
Hi Fabian, On 02/05/22 09:52, Fabian Kosmale wrote: I think your issue might be QTBUG-91390 (ListModel does not keep objects with JS ownership alive in 5.15). That was fixed in Qt 6.2 (https://codereview.qt-project.org/c/qt/qtdeclarative/+/354140), but due to the behaviour change never backported to any version of 5.15. [...] I see, thanks for the pointers! In my current case setting the ownership to C++ is acceptable (in any case, the model would be alive for the whole lifetime of the application, so it does not make a practical difference), but it good to know that there's a solution for those who strongly need it. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Infinite loop in QML ShaderEffect polish()
Hi all! I've recently bumped into an issue on AuroraOS (a fork of SailfishOS), where as soon as an application window gets created, the output gets filled with logs similar to these, and the application gets stuck: [W] unknown:230 - qrc:/Sailfish/Silica/private/TabBar.qml:230:5: QML OpacityRampEffect: possible QQuickItem::polish() loop [W] unknown:230 - qrc:/Sailfish/Silica/private/TabBar.qml:230:5: QML OpacityRampEffect: OpacityRampEffect called polish() inside updatePolish() of OpacityRampEffect OpacityRampEffect is a ShaderEffect, and, in fact, while debugging I've reproduced the same issue with a pure QtQuick ShaderEffect. The warnings appear even if the ShaderEffect is unused (that is, no source is connected to it): it looks like instantiating it is enough to get the application stuck. The "live" and "recursive" properties have no effect on this. The way I've fixed it (apparently, with no ill side effects) is this: == --- a/src/quick/items/qquickgenericshadereffect.cpp +++ b/src/quick/items/qquickgenericshadereffect.cpp @@ -332,7 +332,7 @@ void QQuickGenericShaderEffect::maybeUpdateShaders() // scenegraph ready. Schedule the polish to try again later. In case #2 // the backend probably does not have shadereffect support so there is // nothing to do for us here. -if (!m_item->window() || !m_item->window()->isSceneGraphInitialized()) +if (!m_item->window()) m_item->polish(); } } == That is, removing the check on isSceneGraphInitialized() and only queue a polish if the window has not been set yet. I noticed that the same logic is followed on the OpenGL implementation (QQuickOpenGLShaderEffect), but the whole logic behind this is not clear to me, so that's why I'm writing here. It indeed looks unlikely that this is a bug, otherwise it would have broken a lot of other setups as well. Could there be something wrong in our QPA plugin (which is for the 99% the same as https://github.com/mer-hybris/qt5-qpa-hwcomposer-plugin)? We are also using a scenegraph plugin, but I verified that even with it being removed, the issue presents itself. For the record, this is on Qt 5.15. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Is QScroller maintained?
Hi all,
some time ago I started using QScroller, and filed a couple of merge
requests, which so far haven't been looked at by the maintainer:
http://codereview.qt-project.org/11397
http://codereview.qt-project.org/11398
In addition to that, when I started adding support for the
QPinchGesture, I found that the two (QScroller and QPinchGesture
recognition) work really badly together, so I ended up replacing
QScroller with a QML Flickable (hooking to its content{X,Y} properties).
So, summing up: is QScroller being maintained? Since it's a new class
(it has never been in 4.8), and IMHO it's not up to par to the rest of
QtBase classes, quality wise, maybe it's better to remove it from the
public API for the time being?
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QML: grouping property changes for a single callback invocation
Hi all,
sorry for the intricated subject, I couldn't find a concise and
understandable way to express what I mean. :-)
Often it happens to me that I want to run some code when two or more
properties change on a QML object. A real life example is the contentX
and contentY properties from Flickable.
Now, I don't care which one of these properties change: suppose that I
just want to do this:
===
onContentXChanged: updatePos()
onContentYChanged: updatePos()
function updatePos() {
myObject.setPos(Qt.Point(contentX, contentY))
}
===
Now, the code above has a couple of issues:
1) Performance: if both contentX and contentY change, updatePos() will
be called twice, unnecessarily.
2) Jagginess (and correctness): when the flickable contents move from
(0, 0) to (1, 1), myObject will first have its position set to (0, 1),
which is not correct.
So, question time:
1) Am I missing something, or does the situation stand as I described it?
2) Can we do something about it for Qt5? :-)
Would it be reasonable to make it so that the following syntax caused
the property changes trigger the updatePos() callback in a queued
connection, only once:
onContentXChanged:
onContentYChanged: updatePos()
Or, even better, if we get the "on" keyword to work in this case as
Thiago suggested, we could write:
on contentX, contentY: updatePos()
Would that make sense, and be possible for Qt 5?
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML: grouping property changes for a single callback invocation
On 03/05/2012 03:39 AM, Alan Alpert wrote:
> It's pretty much as you described. With the slight addendum that what you're
> asking for is probably not possible (in the general case). X and Y are
> independent variables, one may change without the other. So the code can't
> just wait for a signal which may or may not ever come. If you have a solution
> for this problem, I'm all ears :) .
I've been giving it some thoughts, but my idea is very rough at the
moment. It's about queuing all the invocations of property signals (and
property bindings) and fire them in an idle callback to be invoked later.
So, supposing that you have this QML code:
===
property int width: x + sizeX
onXChanged: functionA()
===
instead of connecting the onXChanged() signal to function A and to the
re-evaluation of the "width" property, you would connect to a slot that
simply does something like this:
{
listOfChangedProperties.append("x");
/* next line sets up an idle event (QTimer with time set to 0,
* maybe), if one is not set already */
setupIdleEvent();
}
Then, when the idle callback will be invoked, it will go through
listOfChangedProperties and for each of them invoke the slots connected
to them, and recompute the values of other properties depending on them,
each time marking the dependent slot/property as processed, in order to
avoid processing it more than once during the same idle invocation.
This would also mean that if both "x" and "sizeX" change before the idle
callback is invoked, the "width" property expression would have to be
computed only once.
I didn't have a look at QDeclarative source code yet, so I'm all ears
for your opinion (and hints, in case I want to spend some time to
investigate this possibility).
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping the Q prefix from class names
On 04/01/2012 06:04 PM, joao.abeca...@nokia.com wrote:
> The first one introduces a Q namespace, which replaces the Q prefix in
> Qt5. The second patch drops the prefix in class names. This brings the
> C++ API more in line with the QML/JavaScript one and will hopefully help
> move all remaining C++ developers to JavaScript.
I'm not sure what you mean by "move all remaining C++ developers to
JavaScript" -- I would rather move to another toolkit than to JS.
IMHO, a clean QML programming style is when the Javascript expressions
are so clean and simple that one doesn't need to know that it's Javascript.
I certainly wouldn't write the application logic in JS.
As far as the Q namespace is concerned, I'm very much against the
change. If this were the first release of Qt, then I might be fine with
it, but with all the Qt-based applications out there I think this is not
wise.
I understand that Qt 5 is not meant to be source compatible with Qt 4,
but this change sounds like "let's ruin everyone's life just because we
can".
I'm writing some Qt code that I hope to run with minimal adjustments on
devices on which Qt 4.x is installed and on future devices running 5.0;
this change would just make it nearly impossible, for a very uncertain
benefit.
And the "Q" prefix is so tiny and cute, that I honestly prefer writing
"QSize" than "Q::Size" ("using namespace Q" is very likely going to
cause conflicts with other classes of mine).
> Still pending are patches to:
>
[...]
> - rename the Q::Qt namespace to Q::t
urgh...
> While we're at this, it would be good to improve our interoperability
> with C++11. I have another patch in the works that drops camelCase, in
> favor of the standardized names_with_underscores. The extra separation
> between words will be welcomed by those of us that use small fonts and
> ALL-CAPS editors.
Damn, you fooled me. :-) I was about to ask you how this would help
"interoperability", and was going to write that this sounds like a joke,
when I realized what date it is today. :-)
However, since I cannot rule out for sure that you are not joking, I'll
keep the upper part of my angry e-mail, just in case. :-D
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for a new playground project: Desktop Components
On 04/17/2012 01:36 PM, morten.sor...@nokia.com wrote: > Desktop Compoents are not going to be a part of the Qt 5.0 release, but we'd > still like to get it up to speed and open up for contributions through gerrit. > > Task: https://bugreports.qt-project.org/browse/QTQAINFRA-501 What mailing list will be used by this project? Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setters: Passing by value or const reference?
Hi Olivier,
On 04/25/2012 01:12 PM, Olivier Goffart wrote:
> The solution is actually much simpler:
>
> void Foo::setText(QString text) {
> d_ptr->text = std::move(text); // no copy
> }
>
> foo->setText(tr("hello world")); // no copy here, this is a move.
I understand why there wouldn't be a copy in the implementation of
setText, but why wouldn't calling foo->setText() produce a copy?
How can the compiler know that it must not create a copy when calling
Foo::setText(QString text) unless we are inlining it?
Ciao,
Alberto
--
http://blog.mardy.it <- geek in un lingua international!
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setters: Passing by value or const reference?
On 04/25/2012 02:44 PM, Thiago Macieira wrote: > Ah, you're missing the trick! Ah, I got it now, thanks! :-) Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] D-Bus and (de-)marshalling of complex types (QDBusArgument)
Hi all! The current QtDBus implementation automatically marshals only the basic D-Bus types, and puts all the complex types into a QDBusArgument. I've found a reason for this behaviour here: http://permalink.gmane.org/gmane.comp.freedesktop.dbus/5920 However, unless I'm missing something, this only explains why we cannot marshal for aggregate types (structures); we should still be able to marshal array and dictionary types. I'm not proposing to change this behaviour now -- but maybe there could be a method on the QDBusContext class to enable automatic demarshalling whenever possible if desired? Regardless of all this, I'm now facing a problem with serializing a QDBusArgument into a QDataStream: QDBusArgument::currentType() can tell me that the argument is a map, but doesn't tell me the signature of the keys and values. Therefore, there seems to be no way I can parse a map out of a QDBusArgument, without knowing its signature. :-( Should we have a QDBusArgument::signature() method? Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] D-Bus and (de-)marshalling of complex types (QDBusArgument)
On 04/26/2012 01:19 PM, Thiago Macieira wrote: >> However, unless I'm missing something, this only explains why we cannot >> marshal for aggregate types (structures); we should still be able to >> marshal array and dictionary types. > > Not exactly... there are two reasons why this can't be done. [...] Thanks for the explanation, it makes sense. >> Should we have a QDBusArgument::signature() method? > > It's there: QDBusArgument::currentSignature() > > For whatever reason that I can't remember right now, the method is marked > \internal in the documentation. OK. For the time being I decided to work around the issue in a way that I don't need this demarshalling at all, but if I'll ever need it I'll try to remember about currentSignature(), thanks. > Depending on the context, you don't need to know the signature and > currentType() might be enough. You can do a beginMap() and you'll have a type > of MapEntryType. Then you beginMapEntry() and you should have a BasicType -- > which is always demarshalled. After you demarshall that, you'll have any type > again. Yep. The advantage of knowing the signature in advance is that it makes the code a bit cleaner (you don't need to read the first map entry to infer the types), and especially that it works even if the map is empty. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] File chooser dialog as a Qt Component - API design
Hi all! I really miss a QML version of QFileDialog. There currently isn't a Qt Component for choosing a file or a directory from the filesystem, and I think we should fill this gap ASAP. There's a bug I created to keep track of this: https://bugreports.qt-project.org/browse/QTCOMPONENTS-1242 Now I'd like to start discussing the API design for such a component, so I've added a comment to that bug with a proposal. I would appreciate if you have a look at it, and tell me if it's sane. :-) I'm working on a MeeGo implementation of it right now, but I will also need a desktop version eventually. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
