Re: [Development] Should QObject::event() be protected or public?

[André Somers]

On 18/03/2024 14:00, Giuseppe D'Angelo via Development wrote:

On 18/03/2024 13:34, André Somers wrote:

While I know it's easy to work around, I sometimes find myself doing it
anyway. To me, it signals what API is intended to be used in what way.
That a class overrides `event`  (or any other public virtual method)
does not mean that that method is then intended to be called by a user
of the class as the type you defined. That you overwrote it may just be
an implementation detail. I think the methods you expose as "public" on
an API are quite important*. They signal how the user is supposed to use
an instance of your class. If you have methods in there that are just
implementation details, then those don't fit. These methods are meant to
be called by parts of the system that don't see your type as the actual
type, but as something more basic: a QObject in this case.


But I agree 100% here; this is typically realized in C++ by having the 
entry point public and non-virtual, and have that dispatch to a 
protected virtual. 


Yes, such a design could have been used. But it was not, and it hasn't 
in many classes in Qt where overriding methods is part of the way to use 
it. I guess that could still be done, but not without a lot of pain. 
QAIM being a prime example. And I think there are also good reasons for 
that: it adds complication, another layer of indirection, another set of 
methods to document. To solve what problem exactly?


The whole problem we're discussing is that `event()` has been made 
public in the base class and that means it's now public API of any 
QObject subclass, whether they like it or not. :-(


You act as if I didn't understand that, while I started out with saying 
"While I know it's easy to work around [...]". I *know* we can still 
call virtual methods that were public in the base class but have been 
made protected or private in a subclass by just downcasting that 
subclass instance to the base class. But it stands out in the user-code 
as doing something that was, while possible, not intended by the class 
designer. Fine by me.


But to me, that does not imply that I have to *advertise* that method on 
my public API in that subclass when it is re-implemented only for 
internal purposes, but you (and Marc) seem to be claiming that it should 
imply just that.



To go back to the original question: should QObject::event() be 
protected or public? I think it's right that it's public. It is called 
from outside the class itself by parts of Qt that deal with event 
handling, so it belongs on the public API for QObject. Had it been 
protected, we would have needed to use friend, and IMO that's worse: you 
cannot control _which_ private methods or members are touched that way.


So, in summary: I don't think we have a problem here. A public 
QObject::event advertises what it does, and it having been made 
protected in sub-classes is, IMO, not an actual problem.


Cheers,

André

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Should QObject::event() be protected or public?

[André Somers]

Hey,

On 18/03/2024 12:12, Giuseppe D'Angelo via Development wrote:

Il 15/03/24 21:21, Jaroslaw Kobus via Development ha scritto:

To the point: we are talking here about decreasing the visibility of a
member function in a subclass.
The virtuality of the method isn't relevant I guess, is it?


It is relevant, since that's the whole problem: since event() is a 
virtual which is public in QObject, it's pointless to restrict it 
further in a subclass, because you can always place the call 
considering the object as-a QObject (=> upcast it) and bypass the 
restriction.


Therefore, when one creates a QObject subclass with an event() 
override, then:


* either they didn't know about the fact that it was public in 
QObject, and thought it was protected/private (because virtual 
functions should normally be protected), without think about the above 
C++ """feature""" at all, etc. (mistake in good faith);


* or they were *deliberately* trying to change the access level, i.e. 
trying to *outsmart* C++, but that goes nowhere; making it more 
restrictive simply doesn't work (can be bypassed by upcasting, breaks 
generic code that codes against the interface, breaks subclasses).


While I know it's easy to work around, I sometimes find myself doing it 
anyway. To me, it signals what API is intended to be used in what way. 
That a class overrides `event`  (or any other public virtual method) 
does not mean that that method is then intended to be called by a user 
of the class as the type you defined. That you overwrote it may just be 
an implementation detail. I think the methods you expose as "public" on 
an API are quite important*. They signal how the user is supposed to use 
an instance of your class. If you have methods in there that are just 
implementation details, then those don't fit. These methods are meant to 
be called by parts of the system that don't see your type as the actual 
type, but as something more basic: a QObject in this case.


It's not a matter of "outsmarting" the compiler, or something like that. 
It's telling the user of the class which method he is supposed to focus 
on. I find myself doing these kinds of things for instance with QAIM, 
which as quite a big API to re-implement in some cases. Those are all 
public in the base class, but that does not mean that the person using 
my customized type should be fiddling with those methods: they are for 
consumption by views and proxy models and other bits that operate on 
QAIM instances. So, I tend to make these overridden methods protected 
instead, and only keep the higher-level methods that make sense in terms 
of the application API public.


You also seem to be overlooking that you can change the access level of 
all methods of the base class by not using public inheritance, but using 
protected or private. Those don't get much use, but I would say that 
it's an intentional feature.


Cheers,

André


*) And in the same way, that the "protected" section is the API 
available for someone subclassing your class.



--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtQuick Layout behavior changes?

[André Somers]

Hi,

On 27/02/2024 02:46, Jan-Arve Sæther via Development wrote:


Hi Nicolas.


Thank you for your concern. I've explained the reasoning in the issue 
here:



https://bugreports.qt.io/browse/QTBUG-117597

Well, it appears as if the reasoning in that issue is still concerned 
with the effects on existing UI's, but unless I am missing something, 
that concern seems to have not actually materialized in the actual work 
that has been done. Behavioral changes like this surely should be opt-in?


Cheers,

André




Jan Arve


*From: *Development  on behalf of 
Nicolas Fella via Development 

*Date: *Monday, 26 February 2024 at 17:15
*To: *development@qt-project.org 
*Subject: *[Development] QtQuick Layout behavior changes?

Hi,

after updating my local Qt 6.7 + KDE build I noticed a number of severe
UI bugs in various QML-based programs (Plasma, System Settings, several
applications) where certain elements are wrongly sized. Investigating
lead me to 
https://bugreports.qt.io/browse/QTBUG-117597, 
which suggests

to me that there is a deliberate change in the behavior of layouts
causing these issues. Surely this can't be the case, can it? This would
cause countless regressions in the UI of just about every piece of QML
software written before this change and completely go against Qt's
stability guarantees. Could someone please shed some light on this and
explain whether I'm misunderstanding the situation or there is a massive
breaking change coming our way?

Cheers

Nico


--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QML Rectangle corner radius API for Qt 6.7

[André Somers]

On 22-12-2023 14:12, Tor Arne Vestbø wrote:




On 22 Dec 2023, at 13:59, André Somers  wrote:

And what type would the radius property return then? I guess it would 
have to be the grouped type. But that would break all code that 
currently creates a binding on radius expecting it to be a real.


True, that would not work too well. The grouped type would need to be 
convertible to a qreal I guess?


What does `radius` return today, with the new API, when you’ve set 
only topLeftRadius?


It returns what it always did: a real with value 0.

The new API that is introduced in Qt 6.7 as it stands now just makes 
that value act as the /default/ value for the more specific radii 
properties. I think that that is sound design: it's backwards compatible 
and consistent with things like anchors.margins providing the default 
for the more specific margins (except for the fact that that property is 
spelled margins (plural) while radius is singular.)


Anyway, I think that this is besides the point. The point I wanted to 
raise was that having four separate properties isn't ideal, and that we 
could give ourselves a lot of room for improvement by having a `corners` 
grouped property that can contain more than just a single real value for 
a radius.


André
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QML Rectangle corner radius API for Qt 6.7

[André Somers]

On 22-12-2023 13:54, Tor Arne Vestbø via Development wrote:



On 22 Dec 2023, at 13:20, Giuseppe D'Angelo via 
Development  wrote:

Il 22/12/23 11:15, André Somers ha scritto:

I can see two options. The simplest option is to have a `radii`
property, which is a grouped property containing the `topLeft`,
`topRight`, `bottomLeft` and `bottomRight` properties as a floating
point value as we have now. I think that would be cleaner than the
current state of things.

While at it, it should be aptly named `cornersRadii` or similar.

`radius` has always violated Qt API guidelines. A rectangle doesn't have a 
radius. We shouldn't be doing the same mistake again.

Radius is a well established term for this in Qt, and other UI frameworks. A 
key principle in Qt’s API design is familiarity and consistency.

We can change the `radius` property from a qreal into a group property with 
left/rigth/top/bottom, similar to anchors. We can detect in the setRadius 
setter if the incoming argument is a real, and apply that to all of the 
corners. That would be backwards compatible, and give a more granular API for 
those that need it.


And what type would the radius property return then? I guess it would 
have to be the grouped type. But that would break all code that 
currently creates a binding on radius expecting it to be a real.


André
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QML Rectangle corner radius API for Qt 6.7

[André Somers]

On 22-12-2023 13:20, Giuseppe D'Angelo via Development wrote:

Il 22/12/23 11:15, André Somers ha scritto:

I can see two options. The simplest option is to have a `radii`
property, which is a grouped property containing the `topLeft`,
`topRight`, `bottomLeft` and `bottomRight` properties as a floating
point value as we have now. I think that would be cleaner than the
current state of things.


While at it, it should be aptly named `cornersRadii` or similar.

`cornerRadii` in that case.


`radius` has always violated Qt API guidelines. A rectangle doesn't 
have a radius. We shouldn't be doing the same mistake again.




The second option is to actually allow for some more customization, and
have a `corners` property, where each corner again is named as in the
`radii` above, but would itself be a grouped property that could not
only contain `radius` but also `color` (and perhaps other properties in
the future*). Setting different colors for each of the corners would
allow for way more flexible gradients than what we have at the moment.


I'm not sure how this would look like in code, though?


In QML code? Something like this, I imagine:

```qml
Rectangle {
  id: textBalloon
  radius: 5
  color: palette.theirMessagePrimary
  corners.topLeft {
    radius: 10
    color: palette.theirMessageSecondary
  }
  // ... message content, whatever
}

```

André
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QML Rectangle corner radius API for Qt 6.7

[André Somers]

Hi,

Starting from 6.7 we'll have separate corner radii for the corners of a 
Rectangle. Nice, very welcome!


https://doc-snapshots.qt.io/qt6-6.7/qml-qtquick-rectangle.html

Unfortunately, the API looks a bit clunky and not ready for further 
extension. Would it not be better to use a grouped property here instead 
of having four different properties?


I can see two options. The simplest option is to have a `radii` 
property, which is a grouped property containing the `topLeft`, 
`topRight`, `bottomLeft` and `bottomRight` properties as a floating 
point value as we have now. I think that would be cleaner than the 
current state of things.


The second option is to actually allow for some more customization, and 
have a `corners` property, where each corner again is named as in the 
`radii` above, but would itself be a grouped property that could not 
only contain `radius` but also `color` (and perhaps other properties in 
the future*). Setting different colors for each of the corners would 
allow for way more flexible gradients than what we have at the moment.


Cheers,

André

*) For instance, there could be properties that give even finer control 
over the radius, so you can make an inverted rounded corner, or have 
different radii for the x and y axis, or...



--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtWidgets Item / Model / View: tree model examples

[André Somers]

Hi,

On 21-11-2023 16:31, Laszlo Papp wrote:

Hi,

The tree model examples seem to invent a custom tree item.

Simple: 
https://doc.qt.io/qt-6/qtwidgets-itemviews-simpletreemodel-example.html
Edit: 
https://doc.qt.io/qt-6/qtwidgets-itemviews-editabletreemodel-example.html


at

https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/itemviews/simpletreemodel/treeitem.h?h=6.6

and

https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/itemviews/editabletreemodel/treeitem.h?h=6.6

---

Long time ago, I based my projects on these examples, inventing 
(copying and pasting) these tree items.


I wonder whether these examples could instead propagate the use of:

1. QTreeWidgetItem?
2. QStandardItem?

It seems that e.g. the QTreeWidgetItem is nearly the same as the Tree 
Item invented in those examples. So, why reinvent?


Do you think that the tree item still has a good use case to exist in 
those examples?


If yes, what is it?

If not, could we start propagating QTreeWidgetItem or QStandardItem in 
those examples instead to avoid reinventing?


No, please. I would suggest to instead deprecate these classes, at 
minimum the Widgets (QListWidget, QTableWidget and QTreeWidget) and 
their *Item classes. These classes lead to horrible code in practice. 
Propagating their use in examples is going backwards.


QStandardItemModel is a complete misnomer, it is anything but standard. 
Instead, it should be understood as something like QPrototypeItemModel 
or something: suitable to use to play around with or whip up a quick 
test or something, but not for production code. The standard way of 
working should be writing a real model based around your own application 
specific data structures.


Cheers,

André




Thank you in advance.

Kind regards,
László


--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] API style guide: scoped enum or not?

[André Somers]

On 03/05/2023 21:42, Marc Mutz via Development wrote:

On 03.05.23 20:06, A. Pönitz wrote:

My main problem with enum classes _in Qt_ is that it is inconsistent
with what has been there traditionally. It is simply no fun to guess
what "style" some enum is (and sure, Peppe has a point when hinting that
the naming scheme wasn't applied uniformly in the pre-past either...)

There is a pretty straight-forward migration path (and I'm sure that
clang-tidy has an automatic transformation already):

For amy unscoped

  enum E { A, B, C, };

you can, since C++11, write

  E::A, E::B, E::C

This rewrite is an automatable task, and, once done, we can make E
scoped, and just have to deal with (desired) fallout of the missing
implicit conversion to underlying_type.

So if your problem is consistency, then just scope the unscoped
enumerators in your code as if they were scoped.


Other fallout would be that currently A, B, and C will most often 
include E in their name. That makes for the code becoming


E::EA, E::EB, E::EC or E::AE, E::BE, E::CE. I don't like that. Do you 
think there also is tooling to go to a renamed version w/o the enum 
name? Or would it be feasible to add such tooling?


Cheers,

André



Thanks,
Marc


--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] API style guide: scoped enum or not?

[André Somers]

On 04/05/2023 15:51, Sune Vuorela wrote:

On 2023-05-04, Marc Mutz via Development  wrote:

that keeps unported code running. The main issue isn't the scoping, the
main issue will be the missing implicit conversion to underlying_type.

In few cases the implicit conversion to underlying_type is kind of important.

Especially in the cases where the api has int and is mostly used with
enums or is somehow user extendable.

Qt::ItemDataRole is one of them that comes to mind.

switch(role) {
case Qt::UserRole+1:



First of all, the use of Qt::UserRole+1 isn't really good practice. 
Define your roles in a scoped enum. For this use case, we have been 
using this little trick:


// Tool to convert class enum value to underlying type for easier use
template 
constexpr typename std::underlying_type::type operator+(const E )
{
return static_cast::type>(e);
}

Now, we can write the switch like this:

switch (role) {
   case +Roles::Name: //...
   case +Roles::Age: //...

Of course, you can also do:

switch (static_cast(int)) {
   case Roles::Name: //...
   case Roles::Age: //...

But AFAIK, now you need to make sure the int value actually is in the 
enum first to make that safe.


Cheers,

André
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Chief Maintainer

[André Somers]

Hi Volker,

On 19-05-2022 22:42, Volker Hilsheimer wrote:

On 18 May 2022, at 11:23, André Somers  wrote:


On 18-05-2022 11:19, André Somers wrote:
As I understand it [1], this needs a formal vote. However, the QUIP 
does not specify a full procedure. I would suggest:

And then I forget the actual link:

https://quips-qt-io.herokuapp.com/quip-0002.html#how-to-become-chief-maintainer


Thanks André.

The QUIP asks for a simple-majority vote of all Maintainers. Either way, let’s 
see what other nominations we get.

May I propose that until end of Wednesday 25th, Maintainers can nominate other 
candidates (including themselves), and then we can have a vote amongst those 
candidates nominated (the simple majority is enough as per QUIP). The QUIP 
doesn’t explicitly require the candidate to be a Maintainer.

If we have only one candidate by end of Wednesday, then we can use lazy 
consensus, i.e. as long as none of the maintainers object to the candidate, 
that candidate becomes chief maintainer. Although I’d expect that whoever has 
an objection to one candidate also nominates another candidate.


The procedure outlined in the linked QUIP is substantially different 
from the procedure outlined for becoming a Maintainer. The wording to me 
suggest we need an actual vote in this case, not a lazy consensus. The 
"simple majority" refers to the needed number of votes out of the quorum 
(simple majority meaning >50%), not the simplicity of the voting 
procedure IMO.


So no, I don't think a lazy consensus will do. And no, I don't think 
it's having an objection to a candidate means that you also know a good 
other candidate willing to take up the baton instead.


Cheers,

André




Volker


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Chief Maintainer

[André Somers]

On 18-05-2022 11:19, André Somers wrote:


On 18-05-2022 10:53, Samuel Gaist via Development wrote:

Hi,

+1

Best regards

Samuel


As I understand it [1], this needs a formal vote. However, the QUIP 
does not specify a full procedure. I would suggest:



And then I forget the actual link:

https://quips-qt-io.herokuapp.com/quip-0002.html#how-to-become-chief-maintainer


Cheers,

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Chief Maintainer

[André Somers]

On 18-05-2022 10:53, Samuel Gaist via Development wrote:

Hi,

+1

Best regards

Samuel


As I understand it [1], this needs a formal vote. However, the QUIP does 
not specify a full procedure. I would suggest:


1) a time for people to nominate themselves or get nominated by others 
(ofc. needing the nominee to accept the nomination)


2) a formal voting procedure. We have recently used one, so guess the 
same setup that was used to strip Oswald Buddenhagen of his maintainer 
position. The system used there seems like a useful base, however, that 
was a binary vote, while here we have a vote to choose from potentially 
several candidates. I don't see the QUIP explaining how that is to be 
done. If there are more than two candidates, I suggest to use a ranked 
preference system:


Every voter orders the candidates in the order of their preference, 
noting down however many candidates as they like.


After all votes have been cast, the votes are divided over the 
candidates based on their first preference. If there is a candidate with 
at least 50% of the votes, that candidate wins. If not, the candidate or 
candidates with the fewest number of votes are taken off the ballot, 
re-distributing their votes according to the next preference for a 
candidate still on the ballot. The process repeats until a candidate 
reaches the required 50%.


If there are only two candidates left, and no candidate has reached 50% 
of the votes, the candidate with the most votes wins.



Cheers,

André





On 18 May 2022, at 10:28, Lars Knoll  wrote:

Hi all,

As I’ve said in my other email, I am resigning from my position at The Qt 
Company to join a small startup in Norway that is working with things unrelated 
to Qt.

As such, I won’t have too much time to spend with Qt in the future anymore, and 
will resign from my position as the Chief Maintainer because of that.

Qt obviously needs a new Chief Maintainer to take over from me. I’ve had a 
couple of discussions with various people over the last few weeks, and I 
believe I’ve found a great candidate for the job.

I’d like to nominate Volker Hilsheimer as the next Chief Maintainer of Qt.

I believe that the Chief Maintainer should be someone who works full time with 
Qt. He should know the technology, and needs to have the trust of the other 
Maintainers. He needs to understand Qt as an Open Source project and have the 
passion to bring the project forward. I also believe that ideally the person 
should work for and be well connected within The Qt Company. Volker has all of 
those aspects, and I couldn’t think of a better person to take care of the Open 
Governance of Qt going forward.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTreeView: vertical bar between columns

[André Somers]

On 17-05-2022 12:12, Laszlo Papp wrote:



On Tue, May 17, 2022 at 11:01 AM André Somers  
wrote:


Hi,

On 16-05-2022 23:26, Laszlo Papp wrote:
> Hi,
>
> Was just wondering if it was okay to add a property for drawing
> vertical bar between columns in the body of the QTreeView. Our
> customer has requested this as otherwise it was challenging to
> visually separate the columns.
>
> It looks like jpn had a fairly trivial paintEvent implementation
for
> this, so should not be hard to add:
>

https://www.qtcentre.org/threads/8684-how-to-show-vertical-lines-between-colums
>
> Kind regards,
> László
>
Doesn't this belong in the style instead?


If you ask me, as much as QHeaderView's vertical bar. It is the same 
thing, just for the body. And that is also in Qt proper.


I'd argue both belong in the style actually.

Cheers,

André

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTreeView: vertical bar between columns

[André Somers]

Hi,

On 16-05-2022 23:26, Laszlo Papp wrote:

Hi,

Was just wondering if it was okay to add a property for drawing 
vertical bar between columns in the body of the QTreeView. Our 
customer has requested this as otherwise it was challenging to 
visually separate the columns.


It looks like jpn had a fairly trivial paintEvent implementation for 
this, so should not be hard to add: 
https://www.qtcentre.org/threads/8684-how-to-show-vertical-lines-between-colums


Kind regards,
László


Doesn't this belong in the style instead?

Cheers,

André

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[André Somers]

Hi,

On 14-09-2021 09:12, Shawn Rutledge wrote:


On 2021 Sep 13, at 20:58, Elvis Stansvik > wrote:


Yes, URLs are
vital to QML I guess, but are they *that* vital? The bar should be
quite high IMO. In the apps I've worked on, URLs and URL handling is
really not central at all.


We’re talking about potentially a lot of Image items though, Loaders, 
anything else that has a source url and gets used in a component which 
is instantiated in multiple contexts.  If it looks like a path, it’s 
actually a URL.  If it’s relative and Qt gets the base wrong, you need 
to worry about it.  When 6.2 LTS comes out, we’re guessing a lot of 
apps will be ported, and this will come up a lot.  It might cause some 
noise in Jira with the same bug report being written repeatedly: image 
doesn’t load, no idea why, it worked in Qt 5, blah blah.  Even if they 
understand, they will be unhappy having to write this boilerplate 
Qt.resolvedUrl() all over, and still complain that Qt 5 worked better. 
 But if we make a syntactic improvement: before you had to write 
Qt.resolvedUrl() and now you write something simpler, maybe that will 
ease the pain a bit?


I am wondering if the change was a good idea at all then. To me, it 
feels like the change at the root of all this was not well thought out. 
If it is expected that this change is going to hit so many users and 
they need some facility to make it easier on them than littering their 
code with Qt.resolvedUrl, it would perhaps have made more sense to go 
the other way around and introduce an unresolved URL type, which can 
then be resolved to a QUrl where needed without touching the default. It 
feels like the support introduced for the more edge case use of 
unresolved URLs as the default mode has ended up causing problems for 
all those use cases where resolved URLs are needed. I don't _know_ what 
discussion there has been around that at the introduction of this 
change, but it _feels_ like it might be the result of a rushed in change.


And now, another fundamental change is suggested again to patch up the 
problem caused by the first change.


I would suggest seriously considering reverting changes that cause the 
issue, and solving the need for being able to handle an unresolved URL 
in a different, backwards compatible way.


Perhaps something along these lines would be possible:

A URL in QML can be resolved or unresolved. If a URL is constructed for 
a string (like we have been doing for ages in QML), it is directly 
resolved automatically. If you need an unresolved URL, you use another 
syntax to construct the URL setting some flag on it to indicate it needs 
to be resolved at some later point using another context. Syntax could 
be either some constructor function (like Qt.resolvedUrl()) or perhaps 
as a fully fledged type `Url{url: "someUnresolvedUrl"; unresolved: true 
/*=default*/}`.


Cheers,

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Feature freeze exception for QTBUG-95587

[André Somers]

On 09-09-2021 17:32, Ulf Hermann wrote:

Hello,

due to the magnitude of the above mentioned bug, I'm considerng to 
introduce a new feature in Qt 6.2.1. The new "@" operator in QML 
relieves you from typing "Qt.resolvedUrl" over and over. See 
https://codereview.qt-project.org/c/qt/qtdeclarative/+/369987


Now the question is whether we want to relax the feature freeze for 
this particular issue or not.


To me, the fact that this raises discussion on if this syntax should 
have other applications perhaps already justifies a "no" to your actual 
question: should this be allowed in a bugfix release.


I would think not just a small library tool but an actual language 
change warrants a bit more consideration and should not be introduced in 
a what is supposed to be a bugfix release. This is more than just a 
bugfix, it's a significant feature. Adding those without giving them 
proper consideration seems to be an excellent way to grow ugly warts on 
the language that will be very hard to plaster over later on.


Cheers,

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial LTS Qt 5.15.4 released

[André Somers]

On 12-05-2021 17:51, Thiago Macieira wrote:

On Wednesday, 12 May 2021 08:30:52 PDT Frank Hemer wrote:

On Mittwoch, 12. Mai 2021 17:26:50 CEST Thiago Macieira wrote:

Even maintainers who like me don't get access to the source, it's
important
to know the release was made.

Not having access to sources for maintainers is simply ridiculous.

The problem is licensing, not Qt Company's willingness. They offered when this
all began. But since it's not open source, I can't look at it.

When then means that QtC is committing things into modules without that 
modules' maintainer being able to look at it for legal reasons. 
Ridiculous indeed. It would make me question (had I been a maintainer, 
which I am certainly not) if I'd want to keep that hat on at all.


André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Making Binary Incompatible Changes after Qt 6.0

[André Somers]

Hi,

On 07-12-2020 10:24, Volker Hilsheimer wrote:

Hi,

Given the scale of Qt 6.0 it’s perhaps no surprise that in spite of careful 
reviews, we are seeing the first API issues popping up, fixing of which would 
require a breakage of binary compatibility. For example:

https://bugreports.qt.io/browse/QTBUG-87465

I’ve now created an EPIC type JIRA ticket through which we can keep track of 
such issues, so that we can understand the scale and impact of the overall 
problem.

https://bugreports.qt.io/browse/QTBUG-89157

The data collected there should then help us understand whether we should relax 
our binary compatibility guarantees for Qt 6.0. If you are aware of any, please 
link them to this ticket.


Perhaps it's just me, but I don't see an official Qt 6.0 released yet. 
Isn't it exactly the point of releasing beta's and release candidates to 
find and then be able to iron out issues? I did not realize that the 
binary compatibility guarantee held for these as well?


Or, is the issue that fixing these issues before the scheduled release 
date is not feasible? Well, perhaps then the conclusion should simply be 
that that scheduled release date is not feasible? Would it not be better 
to release something that is ok going forward, rather than something 
that is broken but due to our own rules we cannot fix for the 
foreseeable future?




If we decide here to break BC before 6.1 because the available workarounds [1] 
are not applicable or not something we want to live with until Qt 7, then we 
might just as well go “all in” with such changes (as long as we maintain source 
compatibility).


Cheers,
Volker

[1] https://wiki.qt.io/Binary_Compatibility_Workarounds - that page is perhaps 
not as useful as it could be (but the KDE page linked is excellent)


André


P.S. /me is of the opinion the that item widgets should have been 
removed completely in Qt 6.



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QVariant comparison in Qt6

[André Somers]

On 18-09-2020 09:12, Albert Astals Cid via Development wrote:

El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va
escriure:

On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:

Hi!

There was a discussion about the decision to deprecate (remove?) QVariant
comparison (<,>) in Qt6 completely.

Has anything changed for Qt6 (especially regarding comparison of equal
and/or convertible types)? Is the complete deprecation still the latest
decision?

Yes, it's changed; no, it's not deprecation.

What's been removed is the conversion. Aside from the numeric types,
comparing two variants of different types will always result in false. If
you want to compare across types, convert one to the other's type or to a
common third type. You know what data you put in there and you should know
what conversions can be lossy or not.

But i don't what data someone else put it in a QVariant.

The fact that QAbstractItemModelPrivate::isVariantLessThan exists should be
proof enough that you can't expect my class to know what someone else put
inside a QVariant, i mean that's basically the defining feature of QVariant "it
can hold random things for you".

  Is the official Qt position that we should all "copy"
QAbstractItemModelPrivate::isVariantLessThan into our item model classes that
need sorting?


How often do you really have items of different QVariant types in a 
single column and and role in a model?


From what I understand, in Qt 6 you can still compare QVariants if they 
contain the same type - be that a user type or not - for both equality 
and lessThan provided the type in QVariant supports such comparisons. Right?


André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QProperty and library coding guide

[André Somers]

On 16-07-2020 17:40, Volker Hilsheimer wrote:


We need “text” to be a public member of QAction, otherwise we can’t do

action->text();


That ‘text” member is a struct with a bunch of operators overloaded, so that we 
can do either

qDebug() << action->text();
qDebug() << action->text;

and

action->setText(“foo”); // no binding
action->text = document->title; // still no binding
action->text = Qt::makePropertyBinding(document->title); // yay binding!

Thank you for this example of how these new properties are going to look 
from a user code perspective. I have some questions left if you don't mind?


First, say I have another QProperty that has a binding to this 
action->text property. I assume that doing `action->setText("foo")` or 
`action->text = document->title()` will both result in this binding 
being triggered, and thus, triggering side-effects? I would expect such 
in the first case, but not so much in the second as this _looks_ like an 
assignment to a member variable.


Second, say that I initialized action->text like you do in your last 
example, creating a binding. And then I assign to it using, say, 
`action->text = document->title();` Does that work? Do we overwrite the 
binding? Is it possible to prevent that override? This was a problem in 
QML as well where one could accidentally overwrite bindings. I assume 
there is a way to mimic adding `readonly` like you can in QML?


Third, you show that `qDebug() << action.text()` and `qDebug() << 
action.text` is the same. Is that really all that desirable? Somebody 
already pointed out this issues with doing an `auto actionText = 
action.text();` elsewhere in this thread, and I am wondering if you'd 
not want to output some debug info on the property itself, in stead of 
just the value?



Don't get me wrong: I think the syntax where you're basically able to 
use the property as if it was a member variable, basically coming back 
full circle. But I also think it may be confusing for everyone expecting 
an assignment to something that looks like a member to, well, behave 
like that. Is there a reason why this setup was chosen over a more 
conventional but admittedly less cool:


action->text->set("foo");
action->text->set(document->title->get());

action->text->bind(document->title);

qDebug() << action->text.get();


Cheers,

André



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QProperty and library coding guide

[André Somers]

On 16-07-2020 13:08, Edward Welbourne wrote:

Il 16/07/20 12:43, Volker Hilsheimer ha scritto:

For pre-C++20 (where it’s possible to have zero-size structs), and
for compilers that don’t respect the [[no_unqiue_address]] attribute,
all these struct-instances are put into a union. In that case, a
class using QProperty will be larger (by the same amount no matter
the number of properties) than the same class in Qt 5. With C+++ 20
and compilers that do respect [[no_unique_address]], the size and
layout of these classes will be the same.

Giuseppe D'Angelo (16 July 2020 12:58) requested:

Could anyone please illustrate with some code snippets how to achieve
this, in practice, in a number of use cases? E.g. client code (non
pimpled QObject subclass), (Qt) library code (pimpled QObject
subclass), etc.; gadgets (does QProperty work there?); with and
without other Q_PROPERTY/QProperty already present, etc.

As noted in my last mail, documentation is still lagging.  Several of us
- previously ignorant of the new system - are currently helping Ulf and
Fabian with conversion.  We are, in the process, helping to debug the
draft instructions for how to convert and point out gaps in the system
that make this harder than it should be.  Hopefully, once we've spent a
week or two hassling Ulf and Fabian with questions, they'll have the
right things in place and know how to document it clearly.  However,
doing so today would soak up some of their time that is better spent
getting the system into the right state so that the documentation
doesn't need repeated updates ...

Please be patient, we are working on this,


Please understand that waiting with this will also make other 
contributors who will need to deal with QProperty wait, including those 
who will need to OK such changes (such as Thiago). So, you are making 
dozens of people wait to protect the time of two people? That doesn't 
make much sense IMO. All that was asked for were some examples, not 
fully fledged detailed documentation.


Cheers,

André



Eddy.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QAnyStringView

[André Somers]

On 29-06-20 09:20, Edward Welbourne wrote:

BTW, any chance we can bait-and-switch, renaming QStringView to
QUtf16StringView and rename QAnyStringView into the newly liberated name?

Philippe (25 June 2020 08:40) asked:

When we deal with strings, the "Uff" affix is unecessarily verbose.

Nice illustration of the problem with Utf as a prefix right there...


I mean,

QStringView16

is understandable and more friendly/readable than

QUtf16StringView

Notice that we want to distinguish QLatin1String from QUtf8StringView;
although both are 8-bit encodings, Latin-1 and UTF-8 give different
meaning to some 8-bit tokens.

Likewise, the point of saying QUtf16StringView would be to make clear
that the encoding is UTF-16 (a.k.a. UCS-2); whereas QStringView16 only
says it uses 16-bit units to store its contents, it doesn't say what
semantics it gives to those 16-bit units.  (Not that I'm aware of any
other 16-bit encodings, as it happens.)  So the point is to indicate the
encoding, not just the size.


Yes, yes. That's all correct.

But since these classes are used *a lot*, it is IMO also important to 
pay attention not only to technical accuracy but also to how easy they 
are on the eyes. I find QUtf8String* and QUtf16String* not easy to 
visually parse. The tf1 part is especially jarring to me, as we're 
having three very narrow symbols right next to each other.


You may also want to consider putting the most important bit first: the 
fact that it's a string. The encoding of such string is of secondary 
importance I'd say. So, that would suggest QString8 and QString16. As Qt 
uses UTF for all strings in principle, I'd suggest to document the odd 
one out by explicitly naming it. Perhaps QLatin1String would do? But 
wait! That's what we do already! We have the UTF version not mention 
it's encoding and the exception mentioning it. Perfect. Let's stick to that.


So yeah, I agree with Philippe.

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QString and related changes for Qt 6

[André Somers]

On 12-05-20 22:42, Thiago Macieira wrote:


QStringView::mid(), for example, returns QStringView, but QString::mid()
returns QString.
_Should_ QString::mid be returning a QString though? Perhaps it should 
return a QStringView?


André

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [SPAM] How bad QList really is

[André Somers]

Hi,

On 25-04-20 16:49, André Pönitz wrote:

We all know the story that began with

 "We knew for a long time that QList is not a good default
 container, despite what the documentation claims. The problem
 boils down to the fact that for a lot of types T, QList is
 needlessly inefficient by allocating elements on the heap and
 storing pointers to them instead of storing the elements
 in-place, like e.g. QVector does. Sometimes, for large and
 complex types, that might be exactly what you want, but a
 conservative estimate would put that chance at less than 5%." [1]


I was curious how this "conservative" estimate of "less than 5%"
manifests in real QList object instances in a real world example.

My random picks of real world examples usually end up with "Loading
the Qt Creator project in Qt Creator itself", and "statistics" is
something I make up myself, in this case it is looking at QList objects
at destruction time, and sorting them a bit according to size of
the items in the list, number of items still present at that time etc.

Besides being simple to do it's rather close to the typical use I see,
where containers are filled up, accessed/used a few times and destroyed
without much intermediate size changes.


Wouldn't you think that by now most cases where QList was *not* great to 
use have been replaced in QtC already, exactly because it's downsides 
have been known for quite a while now? I am going to assert that will 
skew your statistics, and thus make it basically impossible to draw any 
kind of conclusion from them.


André



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Somers]

On 23-04-20 12:49, Mitch Curtis wrote:

-Original Message-
From: Development  On Behalf Of
André Somers
Sent: Thursday, 23 April 2020 12:04 PM
To: Jaroslaw Kobus ; development@qt-project.org
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi,

On 23-04-20 11:58, Jaroslaw Kobus wrote:

There are cases, where the name of the function contains the "list", like:

QList

QMdiArea::subWindowList(QMdiArea::WindowOrder

order = CreationOrder) const; QList >
QGraphicsItemAnimation::translationList() const;
QList

QLowEnergyAdvertisingParameters::whiteList() const; etc...

So, subWindowList() returning the vector?

Yeah. Not ideal, but not a big deal either in these cases, especially the last
one which uses a common term "whiteList". I do see an issue with API like
QSet::toList(). That would obviously need to be deprecated in favor of a
QSet::toVector().

QSet::toVector() was rejected in favour of range constructors: 
https://bugreports.qt.io/browse/QTBUG-71067


Because

return QVector(set.begin(), set.end());

is obviously easier to write and understand than:

return set.toVector();


Got it.


André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Somers]

Hi,

On 23-04-20 11:58, Jaroslaw Kobus wrote:

There are cases, where the name of the function contains the "list", like:

QList QMdiArea::subWindowList(QMdiArea::WindowOrder order = 
CreationOrder) const;
QList > QGraphicsItemAnimation::translationList() const;
QList 
QLowEnergyAdvertisingParameters::whiteList() const;
etc...

So, subWindowList() returning the vector?


Yeah. Not ideal, but not a big deal either in these cases, especially 
the last one which uses a common term "whiteList". I do see an issue 
with API like QSet::toList(). That would obviously need to be deprecated 
in favor of a QSet::toVector().


André




Changing QList to QVector may in consequence require even more API changes.

Jarek


From: Development  on behalf of André Somers 

Sent: Thursday, April 23, 2020 11:21 AM
To: development@qt-project.org
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Simon,


On 23-04-20 10:55, Simon Hausmann wrote:
Hi,

So take for example this function in QIconEngine:

 virtual QList availableSizes(QIcon::Mode mode = Icon::Normal, 
QIcon::State state = QIcon::Off) const;

If we change that to QVector, we require our users to clutter their code base 
with #ifdefs. If we keep it with QList but use QVector in all non-virtual 
functions, then we create a less consistent API.

Do you think the #ifdefs or inconsistency is worth the proximity to the 
standard? (despite QVector not being like std::vector due to CoW semantics)

I may be missing the obvious, but I really fail to see the problem if you 
change the signature to

virtual QVector availableSizes(...);


If we have that

 template using QList = QVector;


a subclass reimplementing using QList should just work in both Qt5 and Qt6, 
right? So what #ifdef's would be needed?


And yes, I _do_ think staying close to the established meaning of what is a 
vector and what is a list is good. Getting list of QList (which is not a list) 
brings us closer to that goal.


André



Simon

From: Daniel Engelke 
<mailto:daniel.enge...@basyskom.com>
Sent: Thursday, April 23, 2020 10:52
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto:development@qt-project.org> 
<mailto:development@qt-project.org>
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Simon,

I think having a name that is close to the standard is very important as it 
makes it easy to find the Qt counterpart.
Back in the days I had to ask a StackOverflow question to find Qts unique_ptr 
(QScopedPointer), because I couldn't find it due to the naming.

Dmitriy also has a very valid point. It is burned in a lot of peoples heads 
that using QList is a bad idea.

I don't see a lot of work in string replacing QList with QVector and 
QStringList with whatever it would be, as long as the API is compatible.
It's even less work if auto has been used.

Dan


From: Simon Hausmann <mailto:simon.hausm...@qt.io>
To: Dmitriy Purgin <mailto:dpur...@gmail.com>
Cc: "development@qt-project.org"<mailto:development@qt-project.org> 
<mailto:development@qt-project.org>
Sent: 4/23/2020 10:27 AM
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Dmitriy,

No, this is not an April's Foolk joke.

Previous discussions were largely centred around the implementations and 
bringing them together. With this thread my concern is the API and the churn 
our users would have to apply to their code base in order to use Qt 5 and Qt 6.


Simon

From: Dmitriy Purgin <mailto:dpur...@gmail.com>
Sent: Thursday, April 23, 2020 9:53
To: Simon Hausmann <mailto:simon.hausm...@qt.io>
Cc: development@qt-project.org<mailto:development@qt-project.org> 
<mailto:development@qt-project.org>
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Simon,

I hope it's not a belated April's Fool joke? As far as I can remember, for the 
past few years, one would read everywhere to switch to QVector from QList 
because of this and that, and to choose QVector as the default choice container 
instead of QList like it was back in the days. I can't give the exact 
references but that's just the feeling I get from reading the docs and the Qt 
mailing lists.

Cheers
Dmitriy

On Thu, Apr 23, 2020 at 9:45 AM Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:
Hi,

In dev we've had QVector being an alias for QList for a while now. For the 6.0 
release this particular topic (QList/QVector) suggests two goals (among others):

 (1) Use the same type throughout the public API of Qt.

 (2) Make it easy for our users to maintain a code base that works with Qt 
5 and 6.


In the light of those two goals, I think we should keep using QList as the type 
in the public API. I don't think we should do a search and replace activity and 
switch to Q

Re: [Development] Proposal: Deprecate QVector in Qt 6

[André Somers]

Hi Simon,


On 23-04-20 10:55, Simon Hausmann wrote:

Hi,

So take for example this function in QIconEngine:

virtual QList availableSizes(QIcon::Mode mode = 
Icon::Normal, QIcon::State state = QIcon::Off) const;


If we change that to QVector, we require our users to clutter their 
code base with #ifdefs. If we keep it with QList but use QVector in 
all non-virtual functions, then we create a less consistent API.


Do you think the #ifdefs or inconsistency is worth the proximity to 
the standard? (despite QVector not being like std::vector due to CoW 
semantics)


I may be missing the obvious, but I really fail to see the problem if 
you change the signature to


   virtual QVector availableSizes(...);


If we have that

    template using QList = QVector;


a subclass reimplementing using QList should just work in both Qt5 and 
Qt6, right? So what #ifdef's would be needed?



And yes, I _do_ think staying close to the established meaning of what 
is a vector and what is a list is good. Getting list of QList (which is 
not a list) brings us closer to that goal.



André





Simon

*From:* Daniel Engelke 
*Sent:* Thursday, April 23, 2020 10:52
*To:* Simon Hausmann 
*Cc:* development@qt-project.org 
*Subject:* Re: [Development] Proposal: Deprecate QVector in Qt 6
Hi Simon,

I think having a name that is close to the standard is very important 
as it makes it easy to find the Qt counterpart.
Back in the days I had to ask a StackOverflow question to find Qts 
unique_ptr (QScopedPointer), because I couldn't find it due to the naming.


Dmitriy also has a very valid point. It is burned in a lot of peoples 
heads that using QList is a bad idea.


I don't see a lot of work in string replacing QList with QVector and 
QStringList with whatever it would be, as long as the API is compatible.

It's even less work if auto has been used.

Dan


*From: *Simon Hausmann 
*To: *Dmitriy Purgin 
*Cc: *"development@qt-project.org" 
*Sent: *4/23/2020 10:27 AM
*Subject: *Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi Dmitriy,

No, this is not an April's Foolk joke.

Previous discussions were largely centred around the
implementations and bringing them together. With this thread my
concern is the API and the churn our users would have to apply to
their code base in order to use Qt 5 and Qt 6.


Simon

*From:* Dmitriy Purgin 
*Sent:* Thursday, April 23, 2020 9:53
*To:* Simon Hausmann 
*Cc:* development@qt-project.org 
*Subject:* Re: [Development] Proposal: Deprecate QVector in Qt 6
Hi Simon,

I hope it's not a belated April's Fool joke? As far as I can
remember, for the past few years, one would read everywhere to
switch to QVector from QList because of this and that, and to
choose QVector as the default choice container instead of QList
like it was back in the days. I can't give the exact references
but that's just the feeling I get from reading the docs and the Qt
mailing lists.

Cheers
Dmitriy

On Thu, Apr 23, 2020 at 9:45 AM Simon Hausmann
mailto:simon.hausm...@qt.io>> wrote:

Hi,

In dev we've had QVector being an alias for QList for a while
now. For the 6.0 release this particular topic (QList/QVector)
suggests two goals (among others):

    (1) Use the same type throughout the public API of Qt.

    (2) Make it easy for our users to maintain a code base
that works with Qt 5 and 6.


In the light of those two goals, I think we should keep using
QList as the type in the public API. I don't think we should
do a search and replace activity and switch to QVector. In the
light of that, I would like to propose simply deprecating
QVector and stick to QList everywhere.


What do you think?


Simon
___
Development mailing list
Development@qt-project.org 
https://lists.qt-project.org/listinfo/development



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[André Somers]

On 02/03/2020 16:42, Matthew Woehlke wrote:

On 28/02/2020 15.33, Lars Knoll wrote:

This is all nice and fun to bike shed about, but I don’t think those
proposed solutions match the scope of the original problem (which
was relatively small). I don’t think a massive source compatibility
breakage is what we want, just because there is one std header using
emit as a method name.

I read this as: let's not do anything. With which I agree.


And most of Qt’s signals are named in a way that makes it rather
obvious it’s a signal we’re looking at (e.g. fooChanged() or
clicked()), so there’s no need for an ‘emit’ in front to be clear.

I don't see consensus here. On the contrary, the majority seems to feel
that emit/Q_EMIT is useful.


+1

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[André Somers]

Hi Lars,

Sent from my phone, please excuse my brevity

> On 24 Feb 2020, at 12:27, Lars Knoll  wrote:
> 
> 
>> 
>> On 21 Feb 2020, at 17:39, Thiago Macieira  wrote:
>> 
>>> On Friday, 21 February 2020 04:59:02 PST Ville Voutilainen wrote:
>>> Having a keyword-extension to normal C++ is ugly as sin, to some of
>>> us. It causes
>>> fair amounts of "wtf is that?".
>> 
>> That was my reaction when I first saw it, in 1999.
>> 
>> Over 20 years later, I don't bat an eye.
> 
> After 20 years, my eyes simply ignore any ‘emit’ in the source code.
> 
> In any case, I do understand why Qt added emit as a keyword 25 years ago. But 
> today, we do have IDEs which should be able to figure out on the fly whether 
> a function call is a signal emission (as they already do for virtual vs non 
> virtual methods). So why don’t we move the over to be a tooling problem? 
> Simply highlight signal emissions differently in the IDE and you don’t need a 
> keyword for it anymore. It’s also safer, as the keyword can be forgotten or 
> applied to the wrong places.

You seem to assume everyone used QtCreator as their IDE of choice. That is not 
a reasonable assumption I think. 

André

> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[André Somers]

Hi,

Pure from a transitioning perspective: isn't it rather late for such a 
massive change? Wasn't it the idea that 5.15 would be the 
"transitioning" version that people could use to make their code 
Qt6-ready? In that case, should this not have already been implemented 
in Qt 5.15, as I think that one is FF now?


Cheers,

André

On 31-01-20 11:07, Vitaly Fanaskov wrote:

Hello everyone,

We’ve been discussing for a while how Qt6 API can be improved with using
smart pointers. Recently we came into some conclusions and want to
discuss them with the community.

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.

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.

Both options have pros and cons. It would be useful to hear your
thoughts on it. It’s worth mentioning that some other options, like
using Qt smart pointers as-is, were also discussed. They were found less
suitable, but feel free to share your opinion if you disagree.

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.

There are pros and cons for all options. Share your opinion once again,
please.

If there are any related things to discuss, let’s do that in this thread.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] The future of smart pointers in Qt API

[André Somers]

On 31-01-20 15:14, Vitaly Fanaskov wrote:


Hi Daniel,

I'm confused that there's zero discussion of the work I have done in 
showing how adding unique_ptr apis would look like. Surely, you have 
internally discussed that approach. 
Yes, I saw this patch 
(https://codereview.qt-project.org/c/qt/qtbase/+/260618). It looks 
good as an example of using unique pointers.


My personal opinion that we have another fundamental problem in the 
implementation of parent-child relationship in Qt. Ditto for the 
related interfaces. The problem is that everything is implemented with 
using raw pointers and some implicit contracts (like, "a parent 
removes its children").  The proper solution is re-implement it using 
smart pointers. For example, each QObject stores a vector of shared 
pointers to children and a weak pointer to its parent. With this 
"simple" approach we can implement proper API and get rid of entities 
we don't really need, like QPointer for example.


I don't think that adding another level of abstraction and introducing 
new entities is such a good solution here. Better to solve a cause 
rather than fight consequences.



I agree that Qt suffers from a problem there, but I disagree on what the 
problem is.


I think it is quite strange that in 2020 we are still using an intrinsic 
data structure to structure our object trees. We stopped doing that for 
lists a long time ago. Instead of items in the list _being_ a node that 
can be in a list, we now have all kind of data structures at allow to 
manipulate our data in whatever data structure suits us for the task at 
hand. That may be node-based list structure, or whatever else. Yet, for 
our parent-child trees, we insist that this data needs to be represented 
as a pointers between QObject instances themselves.


In my opinion, Qt should have gotten rid of these instrinsic data 
structures a long time ago. If our object hierarchy is an n-ary tree, we 
should be using a type for the data structure that represents exactly 
that. We should not let the structure of our data be an incidental 
result of objects pointing to each other.


And yes, that is such a fundamental shift, there is no way it can be 
done (any time soon) I think. Still, I hope that for new API, it may be 
a consideration.


André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[André Somers]

On 29/01/2020 04:27, Thiago Macieira wrote:

On Tuesday, 28 January 2020 08:09:00 PST Matthew Woehlke wrote:

I agree... somewhat. Where I disagree is that I would go even further
and suggest rethinking their entire business model. Maybe look at
companies with a strong and successful open source story. (Say, isn't
there one of those behind CMake?)

So you're advocating being acquired by a bigger company that has a different
business and regards Qt only as a means to an end?

Can you spell "Nokia" ?


Can you explain what was so bad about the Nokia period (well, before the 
burning platform Elop...)? I remember it as a period where a lot of good 
things happened for Qt actually.


André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[André Somers]

Hi,

On 29/01/2020 04:23, Thiago Macieira wrote:

On Tuesday, 28 January 2020 10:01:43 PST Tim Murison wrote:

2. Don’t scare people off before they even start. Much lower initial
pricing, no historical licensing, more distant ramps for price increases.

Historical licensing cannot go away so long as companies develop with the Open
Source version and then, before releasing, go buy the commercial version.

Just buy the commercial licence upfront, or release as Open Source.


So, you think it is reasonable that a company that has been using Open 
Source for a while successfully, but now would like to expand their 
application using some of the commercial modules and would therefor want 
to upgrade to a commercial license gets a bill for all the time they 
were doing open source?


I think this kind of thing should not be automatic at least. You want to 
avoid having companies moving from OS to commercial just before release, 
but you also do not want to discourage fair usage of OS (including some 
prototyping as far as I'm concerned).


André

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[André Somers]

On 28/01/2020 10:52, Christian Kandeler wrote:

On Mon, 27 Jan 2020 19:09:43 +0100
Giuseppe D'Angelo via Development  wrote:


Il 27/01/20 16:57, Benjamin TERRIER ha scritto:

*We do hope that this eases your concerns, and that we can continue
with your trust*.

https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer

That blog post is now removed. The URL is correct, as it's cross
referenced from other blog posts.

The link works for me (at the time of writing). Let's assume there just was a 
technical mishap.


Sure. Accidentally *cough*on purpose*cough* removed and then restored 
when the shit started hitting the fan and it turned out it was still 
online in an archive anyway.


André




Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt installer capabilities (was: Re: Changes to Qt offering)

[André Somers]

Hi,

On 28/01/2020 12:52, Tino Pyssysalo wrote:


On 27.1.2020, 23.53, "Development on behalf of Thiago Macieira" 
 wrote:

 > On segunda-feira, 27 de janeiro de 2020 10:39:44 PST Elvis Stansvik 
wrote:
 > > So? I have an account because I want to contribute. Does not mean I
 > > want to log in to download (especially not from CI).
 >
 > The CI aspect is actually pretty relevant. Aside from Appveyor, most 
other CI
 > systems with Windows support (like GitHub Actions) do not have Qt pre-
 > installed. What people do to test on Windows is to use recipes that 
download
 > the pre-compiled binaries and unpack them.
 >
 > What does the Qt Company suggest software developers do?
 >
 > (I know there's Conan, vcpkg, etc. I want the Qt Company's official 
answer)
 
Headless installation is important for many Qt users. In the current installer, it is also

possible with scripting but we are making it even more straightforward with 
different
command line options in the Qt Installer 4.0, which is the next major version.

It is also possible to transfer the qtaccount.ini file to a CI machine, which 
removes the
need for manual/interactive login. The qtaccount.ini just contains the hash of 
the password.

Integrating the access control with package managers has resulted to be rather
Large project and we decided to continue with the installer instead, even though
we use vcpkg to enable CMake to build Qt 6 and conan to resolve Qt Marketplace
source code dependencies.


Thanks.

While on the topic of the installer and using a qtaccount.ini file: will 
it finally become possible to use the online installer to install 
commercial Qt versions? I would find it a huge improvement were I able 
to maintain my Qt installations from one installer instead of having to 
manage every version separately with offline installers.


André

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[André Somers]

On 27/01/2020 22:07, Ville Voutilainen wrote:

On Mon, 27 Jan 2020 at 21:56, Dmitriy Purgin  wrote:

By the way, gathering emails by requiring an account to download the software 
without any technical reason might be indeed an example of a GDPR violation.

I am not a lawyer, but I am unaware of any free software license that
gives you a right to download binaries at the terms
of your own choosing. Source downloads are a different matter.


GDPR has nothing to do with software licenses.

André

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QHash for Qt 6

[André Somers]

On 24-12-19 11:28, Martin Smith wrote:

However, instead of adding
template bool qIsEmpty(const T ) { return t.empty(); }
we keep discussing how ugly std is=)

But that's kind of ugly too. I read it as qlsEmpty(), not qIsEmpty(). See what 
I mean? On of those is a lower case L.

How about a new approach to adding free functions:

template bool isEmptyQt(const T ) { return t.empty(); }

martin


A namespace seems a more reasonable solution then.

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Removing overloaded signals in Qt6

[André Somers]

Hi,

On 29-11-19 09:15, Ville Voutilainen wrote:

On Wed, 27 Nov 2019 at 17:52, Sérgio Martins via Development
 wrote:

Hi,


The Qt5 PMF connect syntax is wonderful and very elegant compared to Qt
4.
Unless, ofc, you have overloaded signals, which makes it painful to
write and read. Not even qOverload makes it look much better.


I suggest we rename such signals, as KDE is already doing for KF6 (maybe
leave the old signatures there, to reduce Qt6 SIC)
There's also a new clazy check 'overloaded-signal' to help finding them.


Relevant bug report: QTBUG-47225


I know there are downsides, but keeping things as they are is just
worse.

Signals and slots are the bread of butter of Qt. Syntax for overloading
signals is just too much of a barrier for new-comers, who currently
aren't
even able to connect a QComboBox without much hassle.

Seems like a splendid idea to me, showing even advanced programmers
that they need
to take an address of a member function with a cast seems to baffle
them. Any thoughts
on overloaded slots, or overloaded member functions as slot-targets?
The latter are a tad
harder to diagnose.


They are much easier to solve though. I usually just use a trivial 
lambda for these cases.


I'd suggest to start with just adding specific specialized signals next 
to the overloaded ones. Doing that is binary compatible, so it can be 
done in 5.15 already. The overloaded signal can then be marked as 
deprecated. I'm not sure they should be removed completely for 6, but if 
there is a specialized alternative it would already take away the pain 
of the connect statement.


André



___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.15 schedule proposal

[André Somers]

On 27-11-19 07:03, Jani Heikkinen wrote:

Hi!

Qt 5.14.0 is in its final steps and it is time to start thinking Qt 5.15 
release schedule.  I don't see any reason/evidence how we could cut the time so 
my proposal is based on previous releases:


Qt 5.15 initial schedule proposal:
- All new modules must be in qt5 latest a week before FF. That way we in the 
release team should have enough time to adjust packaging etc for new modules 
before alpha release (== Soft FF  )
- Qt 5.15 Feature Freeze 31st January 2020
- Qt 5.15 Alpha release immediately after FF.
- Qt 5.15 Beta1 release 25th February
- Qt 5.15.0 RC 30th April 2020
- Qt 5.15.0 release 15th May 2020

Any comments or objections?


I wonder if this schedule leaves enough time. With the holidays 
approaching, there isn't all that much time left before 5.15 (Soft) FF. 
However, I also heard quite some items where in order to facilitate a 
smooth transition to Qt6 features in 5.15 need to be added. I'm worried 
such features could not be done in time or end up being rushed, leading 
to either problems being carried over to Qt6 or breaking changes anyway.


Cheers,

André



br,
Jani
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtCS2019 Notes from "Fuzzing Qt" BoF session

[André Somers]

On 22/11/2019 18:17, Giuseppe D'Angelo via Development wrote:

Il 21/11/19 13:13, Robert Loehning ha scritto:

** [https://doc.qt.io/qt-5/qregularexpression.html QRegularExpression]


This should mostly be fuzzing libpcre itself...

Note that users should NEVER use / accept untrusted regular 
expressions. While we shouldn't crash or exhaust memory, PCREs will 
happily exhibit exponential backtracking behaviour, thus exposing 
applications to DOS attacks. There's nothing we can do about that.


Just wondering how one would go about doing that in practice. Is this 
something QRegularExpression itself may be of assistance with, perhaps 
by esposing an API that can be used to identify if an expression 
contains potentially dangerous or heavy expressions?


André



Thanks,

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTCS2019 Notes from QtQml session

[André Somers]

On 26/11/2019 08:56, Ulf Hermann wrote:

We have some code that evaluates JS in custom QQmlContexts with certain
"magic" context properties set (sort of like the "index" or "modelData"
context properties in delegates like Repeater.delegate).
Will something similar still be possible?

You should rephrase that as required properties on actual objects. Then
the magic won't work anymore and you'll have to look up the properties
by ID of the object, but that is a good thing. It will improve
re-usability of your components.
Lookup by ID? You mean set the object name like you did in your example 
in your talk at QtWS? I protested then, and I will protest now again. 
Don't. Really: don't. If you are talking about re-usability and 
maintainability of your code elsewhere, then advocating this practice is 
really wrong. You need to layer your QML on top of an API provided by 
C++, not poke into your QML from C++.


We're also changing the way views and delegate work. If you want to use
the "index" in a Repeater's delegate you'll have to declare that in QML
3, using a required property:

Repeater {
  model: 10

  Text {
  required property int index
  text: "item " + index
  }
}


I really, really dislike this change. It looks even more like magic than 
what we have today. By all means deprecate/get rid off looking up 
without using `model.` in front of index, but what you write there 
really looks like magic. It is totally unclear who is setting a property 
(required or not) if you just declare it. This introduces more magic 
instead of less, and would IMO lead to more knowledge required in on the 
C++ side about the QML side of the application, where I just argued 
above that that leads to bad practice.



André




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTCS2019 Notes from QtQml session

[André Somers]

On 26/11/2019 09:34, Chris Adams wrote:

On Mon, Nov 25, 2019 at 9:34 PM Ulf Hermann  wrote:

I think one of the biggest problems is that ID resolution crosses
file boundaries. This essentially means that the ids chosen can very
easily become part of the "API" of a component unless you are very
vigilant to not allow that to happen.

Well, yes, and there is an easy way to fix this: Deprecate id lookup
across file scope. id lookup is actually the same as context property
lookup right now. That's what you're seeing there. We cannot get rid of
IDs, obviously, but we can restrict their use to the file context and
not search the whole context hierarchy.

Could I suggest also changing the id syntax to clarify that id is not
an object attribute?

e.g.:

Button id: btn { }

or

Button is btn { }

or

Button as btn { }

are IMO better syntax than:

Button { id: btn }

as for the former they are clearer that the ids are attributes of the
component scope rather than attributes of the object per-se, which is
what is suggested by the latter.


I'd tend to agree with that one. Perhaps it could just be

Button btn { }

No "id:" "is" or "as" needed?

Still: huge change again going to affect lots of existing code...

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTCS2019 Notes from QtQml session

[André Somers]

On 25-11-19 15:53, Ulf Hermann wrote:

Yeah, that's going to make using QML in actual applications a whole lot
harder. For instance, sometimes access to some root node is needed even
from deep leaf files. Removing that capability is quite a drastic measure.

Yes, but the problems with this construct are the same as with generic
context properties: Your QML component requires some context that it
doesn't declare. Therefore your code is not reusable and brittle wrt
addition of properties in other places.

Mind that all those dynamic lookups will still live on in QML 2, and we
will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.


"It will still work in QML 2" is not a great one if you want people to 
port over to QML 3. And you will need to support something like this 
anyway.


So far, the feeling I'm getting is that you're quite rigorously axing 
things from QML 2 in QML 3 in order to clean up because it is "broken" 
in QML 2. But without careful consideration what should replace it, that 
will just lead to the same issues again or a less usable QML for real 
world applications.


I'm a bit concerned.

André

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTCS2019 Notes from QtQml session

[André Somers]

On 25-11-19 12:31, Ulf Hermann wrote:

I think one of the biggest problems is that ID resolution crosses
file boundaries. This essentially means that the ids chosen can very
easily become part of the "API" of a component unless you are very
vigilant to not allow that to happen.

Well, yes, and there is an easy way to fix this: Deprecate id lookup
across file scope. id lookup is actually the same as context property
lookup right now. That's what you're seeing there. We cannot get rid of
IDs, obviously, but we can restrict their use to the file context and
not search the whole context hierarchy.



Yeah, that's going to make using QML in actual applications a whole lot 
harder. For instance, sometimes access to some root node is needed even 
from deep leaf files. Removing that capability is quite a drastic measure.


André




Ulf
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Two-digit dates: what century should we use ?

[André Somers]

On 08-11-19 11:15, Edward Welbourne wrote:

André Somers (6 November 2019 17:20) wrote

I came to the conclusion that the sane behavior for interpreting
dates depends on the semantics of what the date means. For instance,
a birth date will always be a date in the past,

On 07-11-19 11:47, Edward Welbourne wrote:

... except when it's the best-estimate date of birth of an expected
child, or part of a discussion of how (say) an education system will
handle the cohorts of children born in various date ranges.

André Somers (8 November 2019 09:14)

... neither of which are actual birth dates. The first is an expected
birth date, the second something else entirely.

 From the point of view of an education system, 2020-09-01 through
2021-08-31 are birth-dates of pupils they have to think about in their
long-term planning for (roughly) the academic years 2026 through 2039.
They need to ask actuaries to tell them how many children to expect in
that cohort, for example.
Sure, you can use dates in such a way. I'd argue they are not really 
birthdays, but sure...


I tend to think of the eccentric uses of a classification because I'm
the one who's going to have to field the bug reports when someone uses
the "date of birth" mode for format-reading and gets results almost a
century ago where they expected results in the near future.

:-) Fair enough.



I'll agree, though, that birth dates are *usually* in the past ;^>

Even when it is in the past, the range of past dates it may land in
is more than a century wide.  Some folk live for more than a century;
and records of dates of birth of folk can be relevant even after the
folk in question are dead.

(All of which argues against using two-digit years in dates of birth,
common though that practice is.)

True. But that does not preclude people from entering such dates. I
guess it also depends on what use case you envision for this. For
reading data stored in a 2-digit format, you are completely right.

Thankfully the use of two-digit years in storage formats is much less
fashionable than it used to be.  I still doubt it'll ever die out, though.


But I was thinking more of making date entry work better. I have
written controls backed by date parsing code based on logic like
this. Yes, you can enter full data, but the control would do the
expected thing based even for shorthands like using a 2-digit
year. What it would do would depend on the purpose of the date
field. The example above were not random: it was medical device
software, so it was dealing with birth dates, appointments, etc. So
for that one-in-200 patient over 100 years old, you'd use the full 4
digit year when entering the data. For the rest of them the 2 digit
version would be enough.

but that's definitely a UI thing - if you're going to interpret what the
user typed as something else, you need to show them how you've
interpreted it, so that they can correct it if it's wrong.  So, by the
time you feed your data to Qt, you have ready-digested data that doesn't
need to be parsed by Qt with a two-digit year.  Of course, you *can* do
this, first trying to parse what the user typed with one format then, if
that fails or produces an implausible date, with another, but I suspect
you're setting yourself up for bad UX if you do that.
Ok, sure. The control obviously immediately showed its interpretation so 
the user could edit it if needed.



while a date for an appointment would normally be a date in the
future.

and usually not very far in the future, at that, which makes this one
of the cases where two-digit years aren't automatically a bad idea.

True. It helps in the experience with the software if entering common
things works quickly and smoothly. Making dates easier to enter can be
a win in the time a user needs to enter data, and that can be _very_
valuable, especially if that is something that needs to be done often.

Sounds like good UX, yes.

OTOH, as noted above, it's surely important to show the user promptly
how you're going to interpret their two-digit year, so that they can
correct it if that's not what they meant - as, for example, when a
doctor is filling in a form about a patient over a century old and needs
18 to mean 1918, not 2018 (or, the other way round for a child, if the
software defaults to 1900s).  Which means this happens at the UI level,
not in the QDateTime parsing code.


That alters the interpretation of the date. May I suggest adding an
enum argument to any function doing the conversion from a string to a
date that allows you tell you to suggest the kind of date that is
expected?

That would imply inventing (and documenting) how we're going to
implement each member of the enum; and, fundamentally, that's going to
boil down to specifying (per enum member) a range of (up to) 100 years
that each two-digit year value gets mapped into.  Then along comes some
user whose use-case we didn't think of and we need to extend the enum
and the enum grows endlessly.  I think

Re: [Development] Two-digit dates: what century should we use ?

[André Somers]

On 07-11-19 11:47, Edward Welbourne wrote:

André Somers (6 November 2019 17:20) wrote

I came to the conclusion that the sane behavior for interpreting dates
depends on the semantics of what the date means. For instance, a birth
date will always be a date in the past,

... except when it's the best-estimate date of birth of an expected
child, or part of a discussion of how (say) an education system will
handle the cohorts of children born in various date ranges.
... neither of which are actual birth dates. The first is an expected 
birth date, the second something else entirely.

I'll agree,
though, that birth dates are *usually* in the past ;^>

Even when it is in the past, the range of past dates it may land in is
more than a century wide.  Some folk live for more than a century; and
records of dates of birth of folk can be relevant even after the folk in
question are dead.

(All of which argues against using two-digit years in dates of birth,
common though that practice is.)
True. But that does not preclude people from entering such dates. I 
guess it also depends on what use case you envision for this. For 
reading data stored in a 2-digit format, you are completely right. But I 
was thinking more of making date entry work better. I have written 
controls backed by date parsing code based on logic like this. Yes, you 
can enter full data, but the control would do the expected thing based 
even for shorthands like using a 2-digit year. What it would do would 
depend on the purpose of the date field. The example above were not 
random: it was medical device software, so it was dealing with birth 
dates, appointments, etc. So for that one-in-200 patient over 100 years 
old, you'd use the full 4 digit year when entering the data. For the 
rest of them the 2 digit version would be enough.



while a date for an appointment would normally be a date in the
future.

and usually not very far in the future, at that, which makes this one
of the cases where two-digit years aren't automatically a bad idea.
True. It helps in the experience with the software if entering common 
things works quickly and smoothly. Making dates easier to enter can be a 
win in the time a user needs to enter data, and that can be _very_ 
valuable, especially if that is something that needs to be done often.



That alters the interpretation of the date. May I suggest adding an
enum argument to any function doing the conversion from a string to a
date that allows you tell you to suggest the kind of date that is
expected?

That would imply inventing (and documenting) how we're going to
implement each member of the enum; and, fundamentally, that's going to
boil down to specifying (per enum member) a range of (up to) 100 years
that each two-digit year value gets mapped into.  Then along comes some
user whose use-case we didn't think of and we need to extend the enum
and the enum grows endlessly.  I think it is easier to let the caller
just specify that year range (principally by its start date).  The
caller can then invent any flavour of year range they like.


Do you really think it would get out of hand? I can't see this growing 
to more than a hand full, and it would be much easier to use than having 
to use and read Qt::ExpectPastDate compared to something like 
QDate::currentDate().year() - 99 as an argument to that function.



André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Two-digit dates: what century should we use ?

[André Somers]

Hi,

On 05-11-19 14:44, Edward Welbourne wrote:

Hi all,

Prompted by [0], I'm looking at what century to use for years, when the
text being read is expected to be in a "short format" that only includes
two digits.
* [0] https://bugreports.qt.io/browse/QTBUG-74323

tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a
decade or three ahead of QDate::currentDate(), and placing any two-digit
year in that range ?

Before anyone says "Don't Do That" (or "why would anyone use two-digit
years after the mess of y2k ?"), bear in mind that CLDR (the Unicode
consortium's common locale data repository, on which QLocale's data is
based) provides short date formats, many of which use two-digit years.

We currently fail to round-trip dates via such formats because 1900 is
used as default year when no year is specified and (thus) 19 is used as
default century number when only the later digits are (understood to be)
specified.  As we get further into the twenty-hundreds (as it were), this
shall grow to be an increasing jarring flaw in date format handling.

I'm considering changing that: since it's a material behaviour change,
it clearly needs to happen as part of Qt 6, which at least gives me a
few months to discuss it and see what folk think is a better plan than
what we have.

It's notable that ECMAScript's Date constructor adds 1900 to any year
number from 0 through 99 (even if supplied as one of a sequence of
integer arguments, not a string), causing problems for the
representation of dates from 1 BCE through 99 CE.  (I must remember to
tease my friend on the ECMA 262 committee about that - his excuse will
be that it was copied from an early version of Java, I suspect - and see
if he can coax them into changing it.)  Likewise, C's struct tm (used by
mktime and friends) has a 1900 offset on its year number: that's
probably never going to change, perverse as it is and shall increasingly
be.

Folk still talk about "The fifties" and mean the 1950s; probably
likewise the forties, thirties and even twenties.  That last, at least,
shall soon be something of a problem.  Folk can see more of the past
than of the future, so perhaps it's not much of a surprise that common
nomenclature reserves short phrases for the past at the expense of the
future: "The sixties" shall be in the past for a few decades yet, I
think.  So rather than having a default century, and maybe changing it
abruptly to 20 at some point in the next fifty years, I think it would
be better to have two-digit years coerced into a century-wide window
about the (forever moving) present.

Perhaps we should make that a narrower window and treat roughly a decade
near the wrap-around as error - e.g. using 1945--2035 as our year range,
with two-digit years 36 through 44 treated as undecodable.

The question then arises: what year-range should we use ?

Two things I'm fairly sure should be true are:
* the current year (i.e. QDate::currentDate().year(), naturally) should
   be included in the range;
* the range should be contiguous.

So the interesting questions are:
* how far into the past and future should the range reach ?
* how wide a buffer (if any) should we leave ?

If we don't have a buffer, my inclination is to put the transition date
at a decade boundary, e.g. 49 -> 2049 but 50 -> 1950, as this shall feel
less perverse to most folk than having a mid-decade transition such as
44 -> 2044 but 45 -> 1945.  However, with a buffer, this problem goes
away, as there aren't adjacent two-digit numbers that map to wildly
different years; instead, the intervening numbers that aren't handled
make the discontinuity seem more sensible.  In principle a one year
buffer would suffice, but I'm inclined to make the gap a decade long, or
more, if we have one.

If QDate::currentDate().year() is C and (C / 10) * 10 is D, either of
these ranges strikes me as better than the 1900--1999 that we're
currently using:
* D -70 <= year < D+30 (all two-digit values handled)
* C -65 <= year <= C +25 (othet two-digit values rejected)

So, to my questions:
* Does anyone want to make the case for keeping 1900--1999 as range ?
* Has anyone a better suggestion for how to chose a rolling range ?
* Should we have a buffer ?  If so, how wide ?
* How far into the past and future should the range reach ?



I came to the conclusion that the sane behavior for interpreting dates 
depends on the semantics of what the date means. For instance, a birth 
date will always be a date in the past, while a date for an appointment 
would normally be a date in the future. That alters the interpretation 
of the date. May I suggest adding an enum argument to any function doing 
the conversion from a string to a date that allows you tell you to 
suggest the kind of date that is expected?


I think it would come in four flavors. 1) A default `aroundCurrentDate` 
value or something like that that would result in using a window where 
the date is interpreted as being in the window of the current year - 

Re: [Development] The age-old T* foo vs. T *foo

[André Somers]

On 18/10/2019 02:37, Kevin Kofler wrote:

Ville Voutilainen wrote:

Since we are about to do a major version upgrade, should be stop being
a special snowflake in the C++ world and start attaching pointer-stars
and reference-ampersands to the type instead of to the variable?

No, because it is syntactically not a part of the type, as evidenced by the
int *x, y; example that others have already pointed out. Semantically, it
is, but the semantics are only computed after doing the syntactic parsing,
so the whitespace should preferentially match the syntax.

And I consider the idea of banning comma declarations to work around this
issue to be nothing more than a workaround for poor notation not matching
the syntax of the language.


Apparently there are already good reasons not to do that even before 
considering T* foo vs T *foo, as it has been banned by the style already:


https://wiki.qt.io/Qt_Coding_Style#Declaring_variables

So this potential change will not cause issues in this area.


Personally, I have always preferred the T* foo (and T& bar) style, as to 
me the pointer-ness or reference-ness *is* part of the type of the 
variable. It is evident in how big the type is, in how typeid identifies 
the type of the variable, in type deduction...


Anyway, I doubt it's worth changing it.

André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6 qml

[André Somers]

Hi,

On 02-10-19 09:39, Nicola De Filippo wrote:

Hi,
is possible think will Qt6/qml c++ binding similar to swiftui?


Perhaps it would be helpful to explain a bit more about how such things 
work in swiftui, for those not familiar with it?


André


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] [SPAM] Re: QDialog vs QPushButton and it's autoDefault default

[André Somers]

Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  On 12/02/2019 20:54, Bernhard Lindner wrote: > Hi Volker!
  > > Hm, ok, I see. Thanks a lot for the explanations. > > Turned out the 
reason
   why the autoDefault heuristics kicks in is because the accept-role- > button
   is disabled by default (until the user selects an item from the table). So
   the > heuristic takes over a bit to early. To provide a non-auto-default
  I will need to set the > default button programmatically. > > Still I am not
   satisfied. People tend to finish text input by pressing Enter, even in >
  dialogs. For dialogs containing a sumplementary line edit (not being the main
   input of the > dialog) this may also trigger some dialog action ahead of
  time. > > Is there a good solution to help user avoiding that mistake? > >
   I considered not to have a default button at all (neither set 
programmatically
   nor > selected automatically) but that seems difficult with that always-on
   heuristics. [...] 

Content analysis details:   (5.4 points, 4.0 required)

 pts rule name  description
 -- --
-0.0 BAYES_20   BODY: Bayes spam probability is 5 to 20%
[score: 0.0987]
 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
  [Blocked - see ]
 0.0 RCVD_IN_MSPIKE_L5  RBL: Very bad reputation (-5)
[91.208.229.55 listed in bl.mailspike.net]
-0.0 SPF_HELO_PASS  SPF: HELO matches SPF record
 1.3 RCVD_IN_RP_RNBLRBL: Relay in RNBL,
https://senderscore.org/blacklistlookup/
[91.208.229.55 listed in bl.score.senderscore.com]
 2.7 RCVD_IN_PSBL   RBL: Received via a relay in PSBL
[91.208.229.55 listed in psbl.surriel.com]
 0.0 RCVD_IN_MSPIKE_BL  Mailspike blacklisted


--- Begin Message ---


On 12/02/2019 20:54, Bernhard Lindner wrote:

Hi Volker!

Hm, ok, I see. Thanks a lot for the explanations.

Turned out the reason why the autoDefault heuristics kicks in is because the 
accept-role-
button is disabled by default (until the user selects an item from the table). 
So the
heuristic takes over a bit to early. To provide a non-auto-default I will need 
to set the
default button programmatically.

Still I am not satisfied. People tend to finish text input by pressing Enter, 
even in
dialogs. For dialogs containing a sumplementary line edit (not being the main 
input of the
dialog) this may also trigger some dialog action ahead of time.

Is there a good solution to help user avoiding that mistake?

I considered not to have a default button at all (neither set programmatically 
nor
selected automatically) but that seems difficult with that always-on heuristics.



Did you try to accept the Enter in your line edit instead? That way, it 
would not propagate up. You could simply eat it or make it focus the 
next item in the focus chain or something that makes sense in your context.


André


--- End Message ---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Opinions on QTBUG-71545

[André Somers]

Hi,


On 05/11/2018 20:56, Elvis Stansvik wrote:

Den mån 5 nov. 2018 kl 20:32 skrev Konstantin Shegunov :

Hello,
Since we couldn't agree, I'd love to see some more opinions about this one.[1]

I may be missing some detail, but I think what Thiago says makes
sense. When children are destroyed, you know you're in the QObject
destructor (from QObject::~QObject docs: "Destroys the object,
deleting all its child objects."), so you know the object is now a
QObject, no longer a QCoreApplication. If you require your
QCoreApplication to be alive by the time your child object is
destroyed, I think you have to ensure this on your own.
Problem is, I think, that this requirement is not always obvious. For 
your own objects, you know you cannot rely on your parent still being a 
MyClass iso of just a QObject on destruction (unless you take specific 
measures to make that so), but in this case the reliance on there still 
being a Q*Application around (not necessarily the parent) is usually not 
as obvious as a myParent->doSomethingNotFromQObject call in your 
destructor code...


Like I said, I may be missing something, but that's what it looks like
to me. I can't see why there would be an exception to the object model
here.

Elvis


Specifically:
1) Is parenting to the application object a thing?
Yes. But you know that the same goes as for any QObject parent/child 
relationship: the parent is a QObject at the time of destruction (ok, 
with QWidget, you're in luck).

1.a) ... and should it be allowed (i.e. accepting the proposed change)?
Yes, it should be allowed, and as you argued I think it is useful. But I 
am not sure that implies the proposed change. OTOH, as so much 
functionality in Qt requires the Q*Application to be alive (and that is 
not always obvious) , perhaps an exception *is* in order.

1.b) .. if not allowed, should we put a warning in the documentation that it is 
wrong and shouldn't be done at all, or at least that it's discouraged.

[1] https://bugreports.qt.io/browse/QTBUG-71545
I do think it makes sense to be able to do this, but if that is to be 
discouraged, then best be explicit about that.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

[André Somers]

Hi,


> On 2 Nov 2018, at 16:02, Thiago Macieira  wrote:
> 
>> On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote:
>>> On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote:
>>> 
>>> We have a lot of API that, for Qt 6, we've already decided to extend to
>>> 64-bit on 64-bit platforms, but keep as decently-sized 32-bit on 32-bit
>>> ones.
>> 
>> Smells like qreal, with all problems that it causes... We could reconsider 
>> costs of using 64bit everywhere, it would streamline debugging of edge
>> cases. 
> 
> [Intel hat on]
> I don't mind this. All Intel processors are 64-bit, all Linux workloads are 
> 64-bit.
> 
> [Qt maintainer hat on]
> Sorry, that would mean 32-bit builds use a larger-than-a-register type which 
> means extra carry operations and slower multiplications. That's probably not 
> a 
> good idea.
> 
>> If I have to I would also pick option 4, but:
>> 1. qsizetype can _not_ be a built in metatype in Qt5 (at best an alias).
> 
> It's not going to be. It's a typedef to either int or long long, depending on 
> your pointer's size.
> 
>> 2.  qsizetype needs to have QDataStream operators so it doesn't fallback to
>> a  platform dependent size
> 
> Since it's a typedef, that can't happen. But you've got a point: we need to 
> serialise in explicit 64-bit widths.
> 
>> 3. QDataStream stream autotests of class that uses the type would need to be
>> extended.
>> 4. I bet there is more, issues to solve, caused by pointer arithmetic ...
> 
> No doubt. That's why I wanted to start now.
> 
>> I would not try to trick qdoc to not see it. The consequences of size
>> changing  "randomly" are far too important, to be hidden.
> 
> So you want users to know now, in Qt 5, that this particular type in the API 
> will become qsizetype in Qt 6?

Yes. Why not take it one step further and just call it qsizetype too? The docs 
can say that this will be int in Qt5, but will change in Qt 6 to what you 
started with?

André

> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable

[André Somers]

On 06/03/2018 11:04, Mitch Curtis wrote:

https://codereview.qt-project.org/#/c/221758/ makes QObject::dumpObjectTree() 
and QObject::dumpObjectInfo() invokable so that they can be used from QML. I 
think that this could be useful to debug issues, but being such a widely used 
and important class, I'm a bit unsure about whether it's worth the extra 
overhead. Here's what Olivier has to say about the overhead (taken from the 
review comments):

"The overhead here is that QObject, which is the base class of all objects, gets two 
more methods. (out of the 4 it has currently.) This means that QMetaObject::invoke might 
be slightly slower if it does not find the method. (But since it is currently not really 
optimized right now, i don't think we should care about this.) I don't know what that 
means for QML lookups, but probably does not matter."

So, I'm wondering what others think.

Would you use these from QML?

Would these be better off as a helper function in the Qt singleton? E.g. 
Qt.dumpObjectTree(object) and Qt.dumpObjectInfo(object).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
To be honest: no, I would probably never use them from QML. Nor do I use 
often from C++ either. I usually resort to external tooling such as 
GammaRay that give me all these methods can give me and much, much more.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QVector rvalue overloads for convenience functions?

[André Somers]

On 03/03/2018 21:25, Allan Sandfeld Jensen wrote:

On Samstag, 3. März 2018 21:11:18 CET Mandeep Sandhu wrote:

On Sat, Mar 3, 2018 at 11:46 AM, Christian Ehrlicher 

wrote:

Hi,

recently rvalue overloads for QVector::append(T), push_back(T) and others
were added to QVector. But not for the convenience functions like
operator<<(T) or operator +=(T). Is this an oversight

Why would an rvalue overload (by that I assume you mean move semantics)
apply to the += operator? You're not discarding the existing object, just
adding values from whats pointed to by the other  reference.

As for the << operator, it _might_ be an oversight, I'm not sure. Someone
else can chime in.


Both of them could make sense assuming we are talking about the single value
variants.
Just wondering: why limit this to single value variants? I'd think that 
it would be equally useful for the variants taking a container?


André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QHash

[André Somers]

Hi,

As already pointed out by the other responders, this cannot be an error.
However, perhaps it could be a Clazy check? Because I doubt QHash does what the writer intented in the general case.

André


Op 18/01/2018 om 15:12 schreef René J.V. Bertin:
> Hi,
>
> It took me a while to figure out why my QHash map of a const char* to 
> something else didn't work despite containing the expected key,value 
> combinations. I understand that the bug was in my code rather than in QHash, 
> because the class is not designed to work with basic data types.
>
> It could help though if a compiler error were raised in this kind of 
> situation, would that be possible?
>
> thanks,
> R.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 QtCore sessions

[André Somers]

Op 01/11/2017 om 22:27 schreef Thiago Macieira:
> On quarta-feira, 1 de novembro de 2017 13:15:11 PDT André Somers wrote:
>> That doesn't make sense. Of course it allows for that.
>>
>> You'd give indexOf a flag like Qt::searchTowardsBeginning (default being
>> Qt::searchTowardsEnd) to determine the direction to search in. Or do you
>> mean that you want the result also to be counted from the end? 
> You're confusing lastIndexOf() which searchs backwards from the end with 
> indexOf() searching forwards from a position near the end.
Yes, those two are orthogonal. Fine. That doesn't disqualify the
solution IMO. In fact, I already separated the two in the suggested
mock-API.
>
>> If all
>> API's take the index counted from the begining there would not be much
>> use for that. You either calculate it yourself by substracting the
>> result from length(), or you add another flag and do something like
>> std::optional indexOf(needle, startIndex,
>> Qt::searchTowardsBeginning | Qt::asCountedFromEnd) .
> Yeah, we won't do that. The QString, QByteArray and QVector can't be bigger 
> than the maximum size representable in qssize_t anyway. So we don't *need* 
> the 
> extra bit.
Fine, but the argument was not about that. The comment I made was on if
using negative indexes is good API to begin with. I think it is not.

>
> Since we don't need the extra bit, we will stick to signed because of its 
> benefits:
>  1) overflow can be caught with sanitisers
>  2) doesn't cause sign conversion warnings when converted to other signed 
>values
>  3) the instruction from the committee is to use signed unless you explicitly 
>need modulo-2 overflow
>  4) the standard library, if ever rewritten, will use signed counters
>
All that is really orthogonal to if you use negative indices as part of
your API, which was what I was responding to in the first place. You
used _that_ as an argument before, and I suggested that that is not such
great API IMHO and nowadays I'd do that differently. However, the world
we live in is one where Qt has had the current API for ages and changing
that would break too much.

André


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 QtCore sessions

[André Somers]

Op 01/11/2017 om 16:46 schreef Thiago Macieira:
> On quarta-feira, 1 de novembro de 2017 08:25:01 PDT Konstantin Tokarev wrote:
>>> No, not really, since it's already limited to half the full VM space. No
>>> object can be larger than that. Using unsigned is unnecessary.
>> Using unsigned for size types is crucial in preventing signed overflow in
>> pathological cases.
> Using signed for size types is crucial because the API expects to be able to 
> count backwards from the end and needs to report failure in other situations. 
> So unsigned is simply ruled out.
I think we're stuck with that API indeed, but _if_ we had the freedom to
re-design it, it would not be my choice to do it this way. I'd sooner
choose for an explicit flag for the first case, and something like
std::optional as a return value to handle the error-reporting case. I'd
find that more explicit that using negative indices. However, I guess we
cannot possibly break API that badly in Qt 6, so doing something like
that is out of the question.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[André Somers]

Op 17/10/2017 om 17:31 schreef Oswald Buddenhagen:
> On Tue, Oct 17, 2017 at 05:23:17PM +0200, Ulf Hermann wrote:
 Exactly. The halting problem can be worked around pragmatically.
>>> ... at the price of getting different build results based on CPU speed ...
>>>
>>> Your fast desktop CPU crunches through the JS and you get a working
>>> built, while my sucky laptop CPU does not and the build fails for me.
>> A simple timeout may be a bit too pragmatic, but you could count the
>> JS instructions executed.
>>
> you guys are discussing the locks of a house without walls. when any
> type of reasonable limiter needs to kick in, the your build system is
> *broken*. that's a fatal error, not just a "different result", and you
> need to rethink what you're doing.
Could you clear up what you mean *exactly* here?
Do you mean 1) that any system that provides some kind of timeout (in
terms of wall time or another measure) for evaluation is broken, or that
2) a build setup that runs into such a timeout is broken? That's a big
difference.

_I_ think that doing 1) is reasonable to keep a IDE like Creator
responsive. And of course, you report an error and fail the build when
that happens. A message stating where the issue occured would of course
be very helpfull.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[André Somers]

Op 17/10/2017 om 03:01 schreef Kevin Kofler:
> Konstantin Tokarev wrote:
>> This problem is solved by having access to full "project" model from the
>> same language. E.g. this is how I implemented Premake plugin for Qt
>> Creator a while ago: added Lua code to traverse Premake's project
>> structure, and run it with all of Premake from inside Creator's plugin, by
>> linking liblua.
> Of course. Invoking the actual build system to get data out of it is also 
> how the CMake support in KDevelop 5 works.
>
> That, however, does not address the Turing-completeness issue, as it will 
> crash (lock up) your IDE if the code in the build system does not terminate, 
> which can happen if the language is Turing-complete.
>
Well, in the case of QBS, would it not be reasonable to terminate the
evaluation of any property binding if it takes more than a 
amount of time? The language may be Turing-complete, but that does not
mean the code in control of executing it has to let it run indefinitely.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[André Somers]

Op 13/10/2017 om 13:04 schreef Viktor Engelmann:
> 4. I don't think we need to be as paranoid towards contributions from
> our own employees as we need to be towards external contributions.
>
>
So much for open government...

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Pointer Handlers will be Tech Preview in 5.10

[André Somers]

Op 28/09/2017 om 13:42 schreef Tor Arne Vestbø:
> On 28/09/2017 13:36, J-P Nurmi wrote:
>> I would prefer attached properties and signals. Similarly to
>> Keys.onPressed. Attaching onTapped from the outside of a component
>> would be similar to overriding an event handler in C++. There would
>> be a single attached object instance with multiple signal handlers.
>> They objects would not be piling up like FooAreas and BarHandlers
>> do.
>
> Agreed! Gesture.onTapped, Gesture.onDrag, etc?
While on first thought I'd agree, it ends up being less flexible. It
would make it impossible to do things described in the top post, like
having a different action for a two finger pinch versus a three finger
one. So, in the end, I don't think attached properties would work here
unfortunately, as for the common case they'd be really elegant.

Unless it would be possible to do both, so you could use the attached
property for the common case but use separate, explicit handlers or
recognizers if you want to go funcky like the above?

With respect to naming, I also don't like the Hander, but I do like the
Recognizer names that Tor Arne  suggested a bit above. If the Gesture
part were to be dropped, I think they are still clear and yet not overly
long, especially if they would only be needed for more control than
you'd get via a common attached property. So, TapRecognizer,
DragRecognizer, PinchRecognizer, etc.

@Shawn:
I do have a doubt left on the choice to make these objects rather than
items though. What we sometimes end up doing is make mouse areas for
button-like objects larger than the actual button, to create a bigger
hittarget for it. That works quite well. I don't see how that would be
done here. Reversely, there are uses for multiple 'areas' within a
single item, and again I don't see how to do that other than instantiate
a separate parent item again, but then you end up with both a QObject
_and_ a QQmlItem instance instead of just the latter. I'm not sure the
hassle is worth the savings you make here by instantiating a QObject
instead of a QQmlItem, more so because you also loose the attached
property onCompleted.

André


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Coding style and C++11

[André Somers]

Op 18/09/2017 om 09:02 schreef Lorn Potter:
>> On 15 Sep 2017, at 6:47 pm, Kevin Funk  wrote:
>>
>> (2) And maybe your request:
>> - Use C++11 member initialization where possible
>>  (IOW: Run clang-tidy cppcoreguidelines-pro-type-member-init checker
>>  on code base and apply all fixes)
> But then files will begin to have a mixture of the two conventions, which is 
> not necessarily a good thing. Wide scale changing of this is probably not a 
> good idea.
I don't get this. Wouldn't doing this do as much cleanup as is
reasonably possible across the whole code base? How do you end up with a
mixture then?

>
>>
>> I personally think that (1) would be useful (despite it costing us a lot of 
>> code churn when doing the transition) because it's much easier to read 
>> `nullptr` than `Q_NULLPTR`, or `override` instead of `Q_DECL_OVERRIDE` in 
>> code. Other opinions may vary, but it's definitely more comfortable for 
>> newcomers to read familiar C++ keywords than custom macros.
>>
>> I'd be willing to provide the patches for (1) and maybe even (2) if there's 
>> a 
>> clear sentiment towards the change(s).
>>
>>> The section "Conventions for C++11 usage" in [1] states:
>>>
>>>  "Note: This section is not an accepted convention yet.
>>>   This section serves as baseline for further discussions."
>>>
>>> I'd like to push this discussion, because if code is converted to a new
>>> base, it should be clear to everyone HOW to do so.
>> For new code the this should be a no-brainer, IMO. So +1 from my side.
>
> It really depends on the code, and where it is. Not all platforms/systems 
> will support c++11 I suppose, and we might want to still target these. I am 
> not up to date with all the platforms/targets, etc.
Qt already requires C++11. So no, we do not still want to target
platforms that don't support C++11.
>
> But for new plugins that target a known platform that supports c++11, they 
> can most likely use new conventions.
>
> Unless someone can come up with technical reasons the new c++11 member 
> initialization is better than what is there now, I’d rather keep it the same 
> as it is now.
It is less error-phrone to initialize at the place of declaration,
instead of in a different file. This gets worse if you have multiple
constructors. So, naturally, we end up with uninitialized member
variables, with all the mahem that may cause.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[André Somers]

Hi,


Op 29/05/2017 om 14:53 schreef Jason H:
>> Sent: Thursday, May 25, 2017 at 7:03 PM
>> From: "André Somers" <an...@familiesomers.nl>
>> To: "Christoph Feck" <cf...@kde.org>
>> Cc: development@qt-project.org
>> Subject: Re: [Development] QList
>>
>> Hi,
>>
>> On 25 May 2017, at 18:40, Christoph Feck <cf...@kde.org> wrote:
>>
>>>> On 25.05.2017 13:53, André Somers wrote:
>>>> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev:
>>>>> Other problem, that IMO is more serious, is that Qt *requires* user to 
>>>>> use QList,
>>>>> by returning or taking it as and argument in various places. That's 
>>>>> almost only
>>>>> reason why I use QList in my code[*].
>>>>>
>>>>> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing 
>>>>> with
>>>>> this APIs will break, unless QList will become an alias of QVector.
>>>>>
>>>>> [*] And, fwiw, almost only reason I use QString, but that's off-topic here
>>>>>
>>>> I think you bring up a good point there. Would not the best way out be
>>>> to fix exactly this problem? If these functions would not return a
>>>> container, but some type of view into such a container, that would leave
>>>> users free to choose the type of container they need for their job
>>>> instead of being forced into the direction Qt choose for its API. A view
>>>> might take the form of a pair of iterators, a range, or perhaps even
>>>> some specialized class that basicaly wraps a pair or iterators and that
>>>> provides convenience functions to/from the Qt containers.
>>> If you only return a view to the container, then if the container is 
>>> modified, the return value is no longer valid. Returning a full container 
>>> (referenced, with copy-on-write semantics) will not have this problem.
>> Sure, but do you always or even most of the time need that feature? If not, 
>> why always pay for it? And it would be easy to turn it into a container when 
>> needed, but then you can choose the most appropriate for your task instead 
>> of always getting a QList (now) or a QVector (Qt6?)
>
>
>
> I wonder how gsl::span plays into this. I just learned about span, quick 
> seems to be wet we need here?
>
Not at all, I think. gsl::span is "a non-owning range of contiguous
memory" according to
https://www.quora.com/What-is-the-span-T-in-the-CppCoreGuidelines. As
QList does not obey that definition, it would rule out being a view into
QList (or its successor with the same semantics) already. 

André


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[André Somers]

Hi,

Sent from my phone, please excuse my brevity

> On 25 May 2017, at 18:40, Christoph Feck <cf...@kde.org> wrote:
> 
>> On 25.05.2017 13:53, André Somers wrote:
>> Op 25/05/2017 om 12:38 schreef Konstantin Tokarev:
>>> Other problem, that IMO is more serious, is that Qt *requires* user to use 
>>> QList,
>>> by returning or taking it as and argument in various places. That's almost 
>>> only
>>> reason why I use QList in my code[*].
>>> 
>>> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing 
>>> with
>>> this APIs will break, unless QList will become an alias of QVector.
>>> 
>>> [*] And, fwiw, almost only reason I use QString, but that's off-topic here
>>> 
>> I think you bring up a good point there. Would not the best way out be
>> to fix exactly this problem? If these functions would not return a
>> container, but some type of view into such a container, that would leave
>> users free to choose the type of container they need for their job
>> instead of being forced into the direction Qt choose for its API. A view
>> might take the form of a pair of iterators, a range, or perhaps even
>> some specialized class that basicaly wraps a pair or iterators and that
>> provides convenience functions to/from the Qt containers.
> 
> If you only return a view to the container, then if the container is 
> modified, the return value is no longer valid. Returning a full container 
> (referenced, with copy-on-write semantics) will not have this problem.

Sure, but do you always or even most of the time need that feature? If not, why 
always pay for it? And it would be easy to turn it into a container when 
needed, but then you can choose the most appropriate for your task instead of 
always getting a QList (now) or a QVector (Qt6?)

André

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[André Somers]

Op 25/05/2017 om 12:38 schreef Konstantin Tokarev:
>
> 25.05.2017, 02:19, "Ville Voutilainen" :
>> On 24 May 2017 at 22:25, Marc Mutz  wrote:
>>>  On 2017-05-24 15:12, Konstantin Tokarev wrote:
  24.05.2017, 15:49, "NIkolai Marchenko" :
>  A semi-sane idea that I think no one has suggested yet:
>
>  What if, starting from Qt6, QList becomes a wrapper for QArrayList with a
>  contructor from this type?
>  After all making existing code slightly _slower_ because of the wrapping
>  overhead is way less problematic than breaking it outright.
>  It will nudge the users of QLists that need to be fast to switch but will
>  leave users of "default no brainer container" happy as they likely 
> wouldn't
>  even notice.
  If existing Qt APIs switch from QList to QVector in Qt 6, such change
  will make it hard to support both Qt 5 and Qt 6 in the same code base.
>>>  Which is why I suggested to make QList a type alias for QVector or
>>>  QArrayList, depending on some yet-to-be-determined criteria. Obvious
>>>  candidates algorithms are:
>> I think we need to take a serious step backwards here. I, for various 
>> reasons,
>> got the impression that a major problem at hand is that when a user (NOT in 
>> any
>> template code, necessarily) uses QList, that user doesn't know the
>> consequences. 
> Other problem, that IMO is more serious, is that Qt *requires* user to use 
> QList,
> by returning or taking it as and argument in various places. That's almost 
> only
> reason why I use QList in my code[*].
>
> If Qt 6 APIs are changed from QList to QVector, lots of user code dealing with
> this APIs will break, unless QList will become an alias of QVector.
>
> [*] And, fwiw, almost only reason I use QString, but that's off-topic here
>
I think you bring up a good point there. Would not the best way out be
to fix exactly this problem? If these functions would not return a
container, but some type of view into such a container, that would leave
users free to choose the type of container they need for their job
instead of being forced into the direction Qt choose for its API. A view
might take the form of a pair of iterators, a range, or perhaps even
some specialized class that basicaly wraps a pair or iterators and that
provides convenience functions to/from the Qt containers.

André


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [docs] changing the way overloads are documented and presented

[André Somers]

Op 28/04/2017 om 15:48 schreef Martin Smith:
>> I am a bit worried about having a good way to describe the specifics of a 
>> >specific overload or group thereof.
> Remember you will still have the option of giving an overload its own qdoc 
> comment instead of including it in the common \fn comment.
True, but that would negate some of the benefits: having a good overview
of the different overloads all together as well as sharing the common
documentation between the overloads.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [docs] changing the way overloads are documented and presented

[André Somers]

Op 28/04/2017 om 09:35 schreef Marc Mutz:
> Hi.
>
> TL;DR: I propose to document overloaded functions with a single comment block,
> containing multiple \fn's and a common documentation text, to be rendered as
> one documentation block preceded by a listing of all the \fn's, instead of as
> individual functions.
>
Generally, I like the idea. Thank you for that suggestion! It would
really clean up the docs for some classes, and make it easier to find
perhaps more suitable overloads for your case. Do you also propose to
use it to group related functions instead of mere overloads, like again
cppreference is doing for its standard algorithms (ie.
find/find_if/find_if_not  and any_of/all_of/none_of)?

However, I am a bit worried about having a good way to describe the
specifics of a specific overload or group thereof. Having that all in
running text will lead to situations where such information is harder to
find and takes more time to read through than it currently does. To go
back to your QString::arg example, I do not want to have to do a text
analysis of the docs belonging to 22 overloads to just get around how to
use _one_ of these. Then again, many of the overloads are very similar.

Perhaps we could have some form of grouping within such blocks (where
groups of functions may  be of size 1) to allow more specific docs for
such groups with an easy link to them? Taking the QString::arg
overloads, you'd probably get 2 or 3 groups:
1: the overloads taking a single value argument
1a: the overloads taking a numeric value argument
1b: the overloads taking a string or QChar
2: the overloads taking multiple QStrings

You might get something like:

\fngroup numeric Numeric single value overloads
\fn QString::arg(qulonglong a, int fieldWidth = 0, int base = 10,
QChar fillChar = QLatin1Char( ' ' )) const
\fn QString::arg(long a, int fieldWidth = 0, int base = 10, QChar
fillChar = QLatin1Char( ' ' )) const
\fn QString::arg(int a, int fieldWidth = 0, int base = 10, QChar
fillChar = QLatin1Char( ' ' )) const
   ...
   \fnendgroup
   \fngroup other Other single value overloads
   \fn QString::arg(const QString , int fieldWidth = 0, QChar fillChar
= QLatin1Char( ' ' )) const
   \fn QString::arg(QChar a, int fieldWidth = 0, QChar fillChar =
QLatin1Char( ' ' )) const
   \fnendgroup
   \fngroup multi Multi-value overloads
   \fn QString::arg(const QString , const QString ) const
   \fn QString::arg(const QString , const QString , const QString
) const
   ...
   \endgroup

Returns a copy of this string with the lowest numbered place marker
replaced by string a, i.e., %1, %2, ..., %99.

\groupdoc numeric
fieldWidth specifies the minimum amount of space that a is padded to
and filled with the character fillChar. A
positive value produces right-aligned text; a negative value
produces left-aligned text.
(...)
\endgroupdoc

\groupdoc other

\groupdoc other
   
\groupdoc multi
This is functionaly the same as str.arg(a1).arg(a2), except that the
argument strings are replaced in one pass. This is faster, and it can
make a difference if a1 contains e.g. %1: (...)
\groupdoc multi


Which, I image, would render as a list like Marc described, only grouped
as indicated with the different groups directly linking to the right
contents block. That contents block could then again indicate the name
of the group and perhaps which overloads are part of that.

André








___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[André Somers]

Op 24/04/2017 om 20:39 schreef Marc Mutz:
> On 2017-04-24 20:19, Ville Voutilainen wrote:
> [...]
>> What is wrong with QArrayList?
>
> Nothing, IMO, in the version proposed by me:
> https://codereview.qt-project.org/188938
>
> But since there's been no +2 forthcoming on above change, and I will
> have no part in the massive code duplication that the alternative,
> making it a class before Qt 6, would entail, I'm considering closing
> the CR.
Would it not be reasonable to wait until the discussion is finalized?
Not that I'm a reviewer or an approver, but I would not give a +2 on any
change that basically fixes a direction if the discussion on that has
not yet been concluded.

André


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Lack of base classes/interfaces? Q*, Q*F

[André Somers]

Op 17/04/2017 om 08:02 schreef Jason H:
> Maybe templates are the way to go. But I just had to change some lines 
> because I was using vectors and Qt was using QList. I'd like to eliminate the 
> need/cost for QList::toVector() and QVector::toList(). If there was a base 
> that provided the basics so that I don't have to worry about it's 
> representation in my code, I want the developer (usually me, but anyone using 
> my functions) to be the one that makes that decision. 
Well, I think most people here would agree QList was not the best choice
in retrospect.
>
> You're right I don't know how C++ handles virtuals, but should I care? This 
> is OOP, I want to use OOP. You're telling me that because the 
> language/compiler implements something poorly, that I can't use OOP?
There are many people for who real-world performance means a lot more
that your wish to use "OOP" - for whatever understanding you have of
that concept. Still, I'd like to see your proposal to to consolidate
QRect and QRectF into one hierarchy using that. I don't see that working
out, but perhaps I am missing something. What would the width() method
return, for instance?

André


>
>
>> Sent: Sunday, April 16, 2017 at 11:44 PM
>> From: "Thiago Macieira" 
>> To: development@qt-project.org
>> Subject: Re: [Development] Lack of base classes/interfaces? Q*, Q*F
>>
>> Em domingo, 16 de abril de 2017, às 18:25:49 PDT, Jason H escreveu:
>>> I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point,
>>> etc]) don't use an interface? I recently moved some code from ints to
>>> floats, and I had to change far more code than I should have had to.
>> If you're thinking of a template class and make each of those just an 
>> instantiation of the template, it could be done, and yet wouldn't help you a 
>> lot. Each instantiation is a distinct type. Your code would need to be 
>> adapted.
>>
>> It wouldn't be easy for us either, as the algorithms are subtly different. 
>> The 
>> rectangle and size, for example, store the inclusive bottom-right 
>> coordinate, 
>> whereas the floating point ones store them exclusive.
>>
>> If you're thinking of base class with inheritance and virtuals, then you 
>> have 
>> to learn a lot about C++ efficiency. Those classes are too small for 
>> virtuals. 
>> It would be bad API design and an incredible overhead for little gain. As I 
>> mentioned, the classes have actually little in common between one another.
>>
>>> My proposal is to change QRect to QRectI, and make QRect an interface.
>> That's a vague suggestion. Make a concrete proposal, please. Without 
>> virtuals, 
>> of course.
>>
>>> I'm not fan of MS's Ieverything, but I think base classes/interfaces are
>>> under used in Qt. Why aren't there more of them?
>> You are thinking of classes with virtuals. QRect has no virtuals and shall 
>> never have them.
>>
>> -- 
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[André Somers]

Op 27/03/2017 om 09:22 schreef Martin Smith:
>
> > A vector is a collection of points and so is a polygon. Both
> are even ordered. 
>
>
> vector is an ordered collection of points, but a QVector can
> contain anything; QVector can even contain unlike things, which
> is truly a tuple. So the problem here is the name QVector. The basic
> collection should be called QTuple or QArray, and QVector should mean
> QTuple.
>
Well, actually, QVector cannot contain unlike things. It can
contain only untyped pointers. Of course these can point to whatever you
want - unlike to what other pointers in the same QVector are pointing to
or not - but the pointers are still of the same type. Note that the
objects pointed to are also not contained in the QVector. They are
located somewhere else, not managed by the vector. So no, nothing like a
tuple at all.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[André Somers]

Op 21/03/2017 om 16:55 schreef Thiago Macieira:
> Em terça-feira, 21 de março de 2017, às 05:22:31 PDT, André Somers escreveu:
>> Op 20/03/2017 om 23:43 schreef Kevin Kofler:
>>> Marc Mutz wrote:
>>>> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd1326
>>>> 5ae/src/kleo/stl_util.h> 
>>> Thanks for proving my point that the STL APIs require tons of copy
>>> boilerplate in every project.
>> That's not just your point, it's Stephanovs point as well. The STL is a
>> starting point, a good, well-tested set of basic building blocks. Nobody
>> claimed it contains any and all containers or algoritms you'd ever need.
>> In fact, in its first form it contained more, but large parts of it got
>> backed out before standardization. Surely you don't expect Qt to supply
>> every container type and every algorithm possible?
> Not all, but a good set of algorithms that are in common use. Getting all 
> keys 
> and values is common, even if sometimes you leading to bad code.
>
Don't we have keyBegin and keyEnd for getting the keys? (No direct
equivalent for values, it seems...):

QVector keys;
keys.reserve(theHash.size());
std::copy(theHash.keyBegin(), theHash.keyEnd(), std::back_inserter(keys));

Sure, it is longer than
auto keys = theHash.keys();

but it does not bind you to using a container selected by Qt to return
the keys in. If you need them in a vector, you can put them in a vector.
If you want them in a set, you can put them in a set.

André


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[André Somers]

Op 20/03/2017 om 23:43 schreef Kevin Kofler:
> Marc Mutz wrote:
>> https://github.com/KDE/libkleo/blob/2fe48b77ba61fada80eaace8cb71dd0fd13265ae/src/kleo/stl_util.h
> Thanks for proving my point that the STL APIs require tons of copy
> boilerplate in every project.
>
>
That's not just your point, it's Stephanovs point as well. The STL is a
starting point, a good, well-tested set of basic building blocks. Nobody
claimed it contains any and all containers or algoritms you'd ever need.
In fact, in its first form it contained more, but large parts of it got
backed out before standardization. Surely you don't expect Qt to supply
every container type and every algorithm possible?

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] syncqt.pl in C++

[André Somers]

Op 07/03/2017 om 22:43 schreef Richard Moore:
>
>
> You're right. My wording above was misleading, I wasn't present
> myself. This is what I remembered people telling me afterwards.
>
> Here are the session
> notes: https://wiki.qt.io/Qt_build_systems_at_QtCon_2016
> 
>
>
> ​Yep, there's also a video. My recollection is that there was a small
> vocal group of people pushing qbs, but that they couldn't demonstrate
> any actual advantages it had. They offered a few up, but it turned out
> that people had already done that using other tools such as cmake. ​I
> think the only conclusion was that qmake is weak and that the
> maintainers want to stop maintaining it.
>
The stopping maintainance of qmake can't happen any time soon I'd think.
Not even from Qt6. There are too many Qt projects out there depending on
it.

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature Freeze Exception: QStringView

[André Somers]

Op 03/02/2017 om 14:27 schreef Giuseppe D'Angelo:

Il 03/02/2017 13:48, Kevin Kofler ha scritto:

We really need a plan to deprecate implicit casts between QString and ASCII.
They are not only the source of such inefficiencies from inexperienced or
lazy programmers, but also of encoding-related bugs. If you need to convert
between 8-bit encodings and QString, you should always use a function that
specifies the correct encoding for the context (e.g. fromLocal8Bit). If your
string is constant, you should use QStringLiteral.

This is all stuff that we already have and that nobody uses because we
fail at advertising it: QT_RESTRICTED_CAST_FROM_ASCII,
QT_NO_CAST_FROM_ASCII, QT_ASCII_CAST_WARNINGS...

Perhaps it is time to flip the defaults then? Make ASCII cast stuff 
opt-in instead of opt-out? Anyway, off topic in this thread.


André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Request moving project to playground area

[André Somers]

Op 03/02/2017 om 10:18 schreef Jesus Fernandez:

On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote:

Declaring persistant objects in ORM is straightforward:

 class Comment : public Table
 {
 Q_OBJECT

 NUT_PRIMARY_AUTO_INCREMENT(id)
 NUT_DECLARE_FIELD(int, id, id, setId)
 NUT_DECLARE_FIELD(QString, message, message, setMessage)
 NUT_DECLARE_FIELD(QDateTime, saveDate, saveDate, setSaveDate)
 NUT_DECLARE_FIELD(qreal, point, point, setPoint)

 NUT_FOREGION_KEY(Post, int, post, post, setPost)

 public:
 Q_INVOKABLE explicit Comment(QObject *tableSet = 0);
 };

Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD?

And what's the reason to have a constructor as Q_INVOKABLE?
That would be to have instances of the type be creatable by the ORM 
machinery, I'd guess.


André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

[André Somers]

Hi,


Op 22/12/2016 om 13:54 schreef Tuukka Turunen:



-Original Message-
From: Development [mailto:development-
bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Shawn
Rutledge
Sent: torstaina 22. joulukuuta 2016 9.25
To: development@qt-project.org; releas...@qt-project.org
Subject: Re: [Development] Proposal to adjust release candidate process



On 22 Dec 2016, at 08:09, Maurice Kalinowski 

wrote:

Hence,

Technology Preview
Preview
Release Preview
Release Candidate
Release

Tech Preview is so far the term for a module which is released but we
reserve the right to continue making API changes anyway, right?  So changing
that might be confusing.

And besides, alpha and beta are traditional and well understood.  (Following
that pattern though, I guess we ought to call the RC a “gamma”, but that’s
not traditional for some reason.)


:)

If we do not want to call the first development release from the release branch "Release 
Candidate 1", then I think calling it "Release Preview" is a good approach.


At least _somebody_ at the Qt Project still has the normal order of 
release names clear: https://twitter.com/qtproject/status/811905487600046081


;-)

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

[André Somers]

Op 15/12/2016 om 22:10 schreef Sune Vuorela:

On 2016-12-15, Soroush Rabiei  wrote:

2.History


Hi

I would welcome more calendar systems.  Personally I hope for french
revolutionary calendar. Because it is funny.

I think you need to touch quite some of the 'inner bits' of date / time,
and while you are there, I'd love if the design could make it easier to
implement my two missing pet features:
  - Partial dates
  - Date/time intervals/delta's.

You might need the latter part for the implementation.

(By partial dates, I mean e.g. my friend has birthday on november 1st.
every year. or unknown year.)

(by date/time deltas, I e.g. I started working somewhere on november 1st
2014. and stopped january 3rd 2015. How long did I work there)
If memory serves me right: When, years ago, I tried to get the latter 
in, the work was a bit blocked because somebody else what working on... 
calendar support. :-)


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [closed] Using semicolons in JS (QML)

[André Somers]

So, now we need one of these QUIPs to document the descision if I 
understand it correctly ?


André


Op 06/10/2016 om 10:58 schreef Mitch Curtis:

To make it a bit more formal and hopefully prevent it from being lost in the 
mail archives, let's update our QML coding conventions:

https://codereview.qt-project.org/#/c/173027/


-Original Message-
From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
project.org] On Behalf Of Kai Koehne
Sent: Wednesday, 5 October 2016 3:23 PM
To: Viktor Engelmann ; development@qt-
project.org
Subject: [Development] [closed] Using semicolons in JS (QML)

Hi,

Alright, to close this thread: It seems the majority agrees that using
semicolons after JS statement inside a Javascript {} block is a good idea. The
suggestion is to follow this in new code. Personally, I will point out missing ;
as defects in reviews.

Regards

Kai


-Original Message-
From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
project.org] On Behalf Of Viktor Engelmann
Sent: Tuesday, October 04, 2016 3:51 PM
To: development@qt-project.org
Subject: Re: [Development] Using semicolons in JS (QML)

Am 30.09.2016 um 17:43 schrieb Shawn Rutledge:


Back in Nokia times it was said that we shouldn't use semicolons,
because it would speed up the parsing [...]


As someone who has written countless parsers, I *highly* doubt that
this is actually true. Indenting with tabs was also believed to be
*much* slower than indenting with spaces (which makes absolutely no
sense), and that measurement result turned out to be caused by a bug
in firebird. I bet this is also just an urban legend. Someone probably
thought "hey - one less character to read - must be faster to load",
but as André pointed out, the error recovery will most likely cost
more than what you save. Unless if the behavior is baked into the LR(1)

state-graph maybe.

Also I don't think it is good style to write code that doesn't conform
to the actual language, just because *most* parsers correctly *guess*
what you meant *most* of the time (except in those pathological
cases...). I think that you should *always* tell parsers *precisely*
what you mean and don't rely on it's guessing ability. For reference:
The Mariner 1 crash (which cost $80
million) was supposedly caused by an error that could have been caught
by static analysis at compile time, but was just "guessed away" wrongly.


Anyhow, I believe that we have spent more time on this debate than
will ever be saved by omitting semicolons.


Viktor


--



Viktor Engelmann
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
viktor.engelm...@qt.io 
+49 151 26784521
http://qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B    




  
Qt World Summit 2016 | Pier 27, San Francisco, CA Experience
Exponential Potential on October 18-20 www.qtworldsummit.com


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[André Somers]

Hi,

Thanks for posting this, it finally cleared up a few postings by Thiago 
from just after the event.


I wrestled my way through this whole thing, trying to get through the 
self-referential nature of all the acronyms. Somewhere in the middle I 
finally found what a QUIP is supposed to be. However, nowhere did I find 
an explanation of what problem it is supposed to solve, why it solves 
it, or how it integrates with the current work flow. So far, it seems to 
me like a solution from some management sphere without a problem to solve.


So, could you please explain, preferably without relying on all the 
acronyms, what problems this bureaucratization effort is trying to 
resolve, and how it fits the rest of our work flow (like making feature 
requests in Jira)?


Thanks,

André

Op 20/09/2016 om 00:45 schreef Louai Al-Khanji:

Hi all,

Here are my notes from the QUIPs session. Thank you for your patience. :-)

QUIPs are a proposed design process for Qt, modeled after Python’s PEPs.

QUIP 1 introduces the general concept:

   http://quips-qt-io.herokuapp.com/quip-0001.html

QUIP 2 details the Qt governance model, it’s simply the current wiki page
converted into a QUIP:

   http://quips-qt-io.herokuapp.com/quip-0002.html

QUIP 3 is an informational QUIP containing the session notes, which are
repeated below:

   http://quips-qt-io.herokuapp.com/quip-0003.html

The heroku domain is obviously a placeholder.

I have also attached the source files for proposed QUIPs 1, 2, and 3 to this 
e-mail.

One item left open was licensing of the QUIPs themselves. For these I propose
Creative Commons CC0.

Any and all feedback welcome.

Cheers,
Louai

 BEGIN NOTES 

At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss the
idea of introducing QUIPs as a new process for Qt governance.

The general idea was introduced by looking at QUIPs 1 and 2, and by looking at
some Python PEPs. The general feedback was positive. An attempt was made to
identify the minimum set of work required to bootstrap QUIP, which was the main
theme of the session.

The overall discussion is summarized below, in roughly chronological order.

- Discussed background of QUIP, the process and the documents. Referred to
   Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to the
   session.

   - The idea is to have a new git repository with the QUIP text files

   - Managed through Qt's normal work flow, currently gerrit code review

   - The maintainer of the quips repository takes on required editorial duties
- Agreed that the text documents should be limited to 80 character lines.

- Agreed that care must be taken to ensure that QUIPs are written in "proper"
   English so as to be clear, understandable and concise.

- Talked about how a new QUIP is introduced. The most important thing is to
   reserve a number, which is the identifier of any one QUIP. The title can
   change, and is expected to do so from time to time.

- New QUIP documents will go through a review process like any other patch to
   Qt. The author of the QUIP is responsible for logging this discussion in the
   evolving QUIP itself.

- The important thing is to bootstrap the process. Once it is bootstrapped, it
   is possible to fine-tune the QUIP process through QUIPs. It is expected that
   this will happen.

- The question of what goes into a QUIP was discussed. QUIP 1 gives a rough
   overview of the different kinds of possible QUIPs. It is expected that the
   content be further specified in revisions of QUIP 1 or in follow-up QUIPs.

- Like any other part of Qt, QUIPs are living documents. They can be updated,
   amended or entirely superseded by later ones.

- QUIP licensing was discussed. Python's PEPs are required to be either placed
   in the public domain or licensed under the Open Publication License. The
   former is not possible in all jurisdictions and the latter has apparently
   been superseded by the Creative Commons licenses the CC0 license was
   suggested.

- The minimum QUIP boostrapping process was discussed:

   1. Post QUIP 1 to qt-development mailing list for discussion.

   2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io
  has since been made available)

   3. Create new git repository to hold QUIPs

- The initial QUIP process was discussed:

   1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through
  gerrit

   2. The author gives notice of new QUIP by sending it to qt-development,
  either inline or as a text attachment (things like this can be refined
  later through QUIPs)

   3. Concurrently the author pushes the draft to gerrit where further
  discussion can take place. This discussion must be described in the QUIP.

   4. Decisions are achieved through the same lazy consensus mechanism that
  is in place today. In that respect nothing changes.

   5. A final +2 from the QUIP maintainer(s) is required. This 

Re: [Development] On deprecated APIs

[André Somers]

Op 31/08/2016 om 09:38 schreef Marc Mutz:

Hi,

My porting guide for Q_FOREACH -> C++11 ranged for has created the expected
outcry from users.

I think some of the FUD comes from the fact that deprecation in 5.x usually
means that the API is gone in Qt 6.0.

I'd therefore like to propose a new contract with our users:

The Qt Project:
- continues to deprecate API it wants gone
- maintains deprecated Qt N.x API until Qt (N+1).0.
- does *not* remove deprecated N.x API anymore come (N+1).0
- does also *not* maintain deprecated N.x API after the initial (N+1).0.0
   release
   * (ie. N+1).y CI runs with API deprecated in N.x (or earlier) disabled
   * also means Qt does the work of making sure deprecated API is turned
 all-inline before a .0.0 release to maintain BC.

In return, the Qt users:
- stop insisting on -Wdeprecated-clean builds without investing time of their
   own into updating their sources
- provide patches to maintain deprecated APIs we no longer maintain

In return, the Qt Project:
- pledges to take those patches in without hackling about "but it's
   deprecated..."

This allows us to continue to mark API deprecated, so new users have guidance
on what API to avoid, while giving peace of mind to users of exisiting API
that their investment is protected, as long as they're willing to participate
in maintenance.

I believe this is fair and beneficial for both sides. I don't know how far
this will carry us (technically and socially), but maybe we can just try it in
the Qt 5 -> 6 transition?

I won't be able to come to QtCon this year, either, but feel free to take the
opportunity to discuss this there.

Thanks,
Marc


Hi,

While I understand the idea, I think it is very risky. I think it will 
be hard to explain to users, and even harder to defend against 
complaints and negative sentiments from users when the functionality 
_does_ break. Not maintaining something any more will mean that probably 
at one point, it will break. Do we really want to ship Qt in a way that 
we know will break, and will accumulate more breaks as time goes by? How 
do you deal with features that not too many (capable) people care about, 
do you just let them rot?


I think asking the community to keep supporting certain features the 
project at large wants to deprecate without any support is not a fair 
deal for anyone. Would the people able to support such features into the 
future in fact already be likely contributing to the Qt project? 
Supporting a feature without the aid of CI is also quite a bit harder 
for any individual maintainer. In the case of Q_FOREACH: how would you 
maintain this without access to all the supported platforms and 
compilers? On the other hand: how do you as a user know which 
depreciated features are and which are not supported by the community? 
Doesn't that make Qt as a whole less reliable?


I would like to make a slightly different suggestion: let a deprecation 
be a reversible state. It could signify that the Qt project is no longer 
willing to maintain it, and it thus will go away, _unless_ somebody 
stands up to accept maintainership of said feature/class/whatever and 
promisses to keep it working before the removal takes place. It would 
then *not* be removed from CI, but it could be marked as "community 
supported" or something like that to signify it's continued support is 
not as certain as other parts of Qt. Also, Qt internally would not be 
allowed to depend on such community supported code any more. If nobody 
stands up to take maintainership, it will indeed be removed at the 
appropriate time.


BTW: A quick search on the ML archive did not turn up a discussion on 
the removal of Q_FOREACH. Would that not be required before marking it 
deprecated? I did find more of an announcement[1]. I also found a 
post[2] by you where you say:

Try to port all your Q_FOREACH to range-for loops. You will be surprised how
much digging is required if you don't always want to take the hit of taking a
copy.

Isn't that essentially the contents user outcry you are refering to?

André

[1] http://lists.qt-project.org/pipermail/development/2016-May/025843.html
[2] 
http://lists.qt-project.org/pipermail/development/2015-December/024187.html


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML: Why C++11 scoped enums are not scoped in QML?

[André Somers]

Op 27/07/2016 om 09:53 schreef BogDan Vatra:



That said, it would be a behavior change not to allow anymore the previous
(unscoped) syntax to work with QML

The unscoped enums should work as they are woring now, just the scoped ones
should be scoped in QML as well.

Based on your patch, I'll try to prepare a patch for QML.

Would that not break existing QML applications that now use enums backed 
by scoped enums in C++?


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Stack Overflow Documentation

[André Somers]

Op 21/07/2016 om 16:35 schreef Sze Howe Koh:

On 21 July 2016 at 19:04, Mitch Curtis  wrote:

Hello.

Stack Overflow Documentation is now in Beta. You can read more about it here:

http://stackoverflow.com/tour/documentation

It is much more accessible than our contribution system, so I see a lot of 
documentation/example contributions going there instead of to Gerrit.

I also wonder if we should consider the popularity (i.e upvotes) of the pages 
there when we decide which examples to create and add to our documentation.

That makes sense to me. Another similar metric is how often a question
gets asked at our forum, although this is a bit hard to count.



I wonder if the licensing is such that the frameworks like Qt can benefit from the 
content by "upstreaming" it into their own documentation.

According to your link, Stack Overflow Documentation contributions are
licensed the same way as regular Stack Overflow, i.e. CC BY-SA 3.0.
We'll need a legal expert's input to be sure, but from what I
understand we can't relicense CC BY-SA 3.0 material under GFDL 1.3...

(Perhaps we can ask Stack Overflow for an exception?)



I'm interested to hear what others think about this.


I still think the removal of the documentation annotation feature that 
was on the online documentation a year or two ago is regrettable 
mistake. Instead of extending the feature by  making it more 
fine-grained, be able to integrate it into documentation viewer. There 
was good content there, and it was discouraging for the members of the 
community who had been contributing to it to see it just being removed 
instead of used.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] leak in QMetaObject?

[André Somers]

Op 20/07/2016 om 11:39 schreef Edward Welbourne:

Op 20/07/2016 om 10:41 schreef Olivier Goffart:

The distribution does not matter. If it can be big, quadradic
complexity can be a blocker.

André Somers replied

Nonsense. There is no need to pessimize the frequent cases to cater
for avoiding a performance issue in an exceptional case.

Well, it depends ...

You've got some function, F, from number of connections to cost of any
given way of handling connections.  You've got some distribution P over
values n takes.  Your total cost is the sum of P(n).F(n) over that range
of values.  The big-O discussion is usually about how F varies; but what
actually matters is the sum of P(n).F(n). [...]

Yes, you are right of course.

But then again, it is easier to optimize the rare-but-expensive case in 
the application code than doing something about a frequent action that 
is slower than it could be. To stick to the concrete issue here: 
disconnecting a long list of connections using a loop is not very 
efficient if you do that one-by-one, Olivier pointed out you turn a O(N) 
into an O(N^2) if you then also do the clean-up. So you optize that to 
make sure that you can disconnect *all* connections for a given signal 
or slot instead, even if that means using an intermediary object or 
signal. If analysis shows that this case is slow, you spend a bit of 
time to optimize _that_ case. You cannot do the same for the many 
individual cases where there is maximum a handful of connections to any 
given signal or slot.


But: this reasoning is as much dependent on actual data on what the 
distribution of n is as the orignal statement that it does make sense. 
Hence my question on the availability of such data...


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] leak in QMetaObject?

[André Somers]

Op 20/07/2016 om 10:41 schreef Olivier Goffart:

On Mittwoch, 20. Juli 2016 10:01:26 CEST André Somers wrote:

Op 19/07/2016 om 18:06 schreef Olivier Goffart:

It is true that we could consider trying to clean the connection list
after
each signal emission if it is dirty.
We don't want to do it after each disconnect because this can turn a O(n)
algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it
for every disconnect, that n*O(n))

Did anyone ever measure in practice what the distribution in values for
n is here? My *guess* is that it won't be all that large. I expect a
distribution with a spike at n=1 or 2, and then a dropoff with a very
long tail, perhaps spiking at a bit larger number when using QML for all
the propertybindings going on. Big-O notation doesn't make a lot of
sense if the n is small, it only starts to have an impact if n grows.

The distribution does not matter. If it can be big, quadradic complexity can
be a blocker.
Nonsense. There is no need to pessimize the frequent cases to cater for 
avoiding a performance issue in an exceptional case. The test case 
presented is clearly not a normal usage pattern. Of course, if you can 
optimize the algorithmic complexity for the exceptional cases without 
affecting the performance for the cases where n is small, then by all 
means do just that. I also don't think it is up to Qt to try to mitigate 
wrong usage patterns like disconnecting many slots from a single signal 
in a loop.



I would be suprised if the impact of the list being a single-linked list
and thus having to skip through memory to get from node to node was not
bigger than any "big-O" benefits you gained from doing it this way in
the first place.

Maybe changing to a vector could be indeed beneficial. Note that it's not that
simple as the nodes are in two different linked list at the same time. And
this is used for efficient disconnect when a reciever is destroyed.
You know much more about this than I do of course, and perhaps a linked 
list _is_ the best data structure for this case.



On the other hand, you'd have to consider the likelyhood of another
connect hapening after a disconnect. If that is nearly 1, then sure,
that may be a good time to clean up. But if it is closer to 0 in reality...

It would still not be a leak since the used memory is bounded to O (maximum
amount of connection on that object at the same time)
No, it would not be a leak. I did not claim it was. It would still be 
wasted memory though that is kept for (way) longer than needed.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] leak in QMetaObject?

[André Somers]

Op 19/07/2016 om 18:06 schreef Olivier Goffart:

On Donnerstag, 14. Juli 2016 17:45:58 CEST Thomas Senyk wrote:

On 14.07.2016 17:18, André Somers wrote:

Op 14/07/2016 om 17:10 schreef Olivier Goffart:

On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:

Hi,

I lately wanted to validate that a connecting to a lambda
will not leak the lambda object .. and found that more then that is
leaked.

Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv

After the 10million connections are executed and disconnected (all of
them a successful), I assume a drop in memory consumption and more
importantly a drop of cpu load to close to 0%.

I see neither one nor the other. I see continues 100% consume with no
memory consumption drop what so ever.

I did a quick peak into QMetaObject::activate and it seems no clean up
happened .. the list returned in

list = >at(signal_index);
(line #3660 in 5.6 checkout from today)

seems rather long! (10million?)

However all "if (!c->receiver)" shows no receiver and therefor will
continue right away .. at least

Is this expected? A bug? ... I'm happy to fill a bug report, I just
wanted to get some feedback, maybe I'm just doing something wrong

The lambda object and its capture is destroyed by the call to

slotObj->destroyIfLastRef()

The internal data structre (QObjectPrivate::Connection) is deleted by
QObjectPrivate::cleanConnectionLists which is actually only called when
a new connection is made to this object.

I don't think there is a leak, but it is true that some memory is only
free'ed
when you add new connection or that the object is destroyed. (but the
lambda
object is destroyed right after the disconnection)

Then this:
http://paste.ofcode.org/37rxyitynhEqi5gira88hR9

should "fix" it? .. but I still see 100% cpu and same memory consumption?

As thiago says, your thing still does not work because when you connect from a
signal connected to the same object, the list is inUse and will not be
cleaned.

for (int i = 1; i <= 1000; i++) {
  // ... your code
}
QTimer::singleShot(200, // so it's after the last disconnect
   [] { QObject::disconnect(QObject::connect(t, ::timeout, []{})); });

So the connect happens after everything was disconnected.

In practice you probably don't need to use this workaround, unless you always
add new connection from a slot connected to a signal of the object you
continue to connect and disconnect to. Is that what you are doing?

It is true that we could consider trying to clean the connection list after
each signal emission if it is dirty.
We don't want to do it after each disconnect because this can turn a O(n)
algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it for
every disconnect, that n*O(n))

Did anyone ever measure in practice what the distribution in values for 
n is here? My *guess* is that it won't be all that large. I expect a 
distribution with a spike at n=1 or 2, and then a dropoff with a very 
long tail, perhaps spiking at a bit larger number when using QML for all 
the propertybindings going on. Big-O notation doesn't make a lot of 
sense if the n is small, it only starts to have an impact if n grows. I 
would be suprised if the impact of the list being a single-linked list 
and thus having to skip through memory to get from node to node was not 
bigger than any "big-O" benefits you gained from doing it this way in 
the first place.


On the other hand, you'd have to consider the likelyhood of another 
connect hapening after a disconnect. If that is nearly 1, then sure, 
that may be a good time to clean up. But if it is closer to 0 in reality...


Note that if you are worried of somebody disconnecting in a loop or 
something: simply make sure to have a fast path. A disconnect 
(ptrSender, 0, ptrReceiver, 0) obviously doesn't need a cleanup after 
every individual disconnect...


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] leak in QMetaObject?

[André Somers]

Op 14/07/2016 om 17:10 schreef Olivier Goffart:

On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:

Hi,

I lately wanted to validate that a connecting to a lambda
will not leak the lambda object .. and found that more then that is leaked.

Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv

After the 10million connections are executed and disconnected (all of
them a successful), I assume a drop in memory consumption and more
importantly a drop of cpu load to close to 0%.

I see neither one nor the other. I see continues 100% consume with no
memory consumption drop what so ever.

I did a quick peak into QMetaObject::activate and it seems no clean up
happened .. the list returned in
   list = >at(signal_index);
   (line #3660 in 5.6 checkout from today)

seems rather long! (10million?)

However all "if (!c->receiver)" shows no receiver and therefor will
continue right away .. at least

Is this expected? A bug? ... I'm happy to fill a bug report, I just
wanted to get some feedback, maybe I'm just doing something wrong


The lambda object and its capture is destroyed by the call to
   slotObj->destroyIfLastRef()

The internal data structre (QObjectPrivate::Connection) is deleted by
QObjectPrivate::cleanConnectionLists which is actually only called when
a new connection is made to this object.

I don't think there is a leak, but it is true that some memory is only free'ed
when you add new connection or that the object is destroyed. (but the lambda
object is destroyed right after the disconnection)



Some background:
I wanted to check if a single-shot-connection (connection to a signal
and disconnect at first execute, using a lambda as slot) would be a
feasible thing to do.

You can do that already:

  QTimer::sigleShot(100, [] { qDebug() << "hello"; });


That's not the same thing.
This looks like my earlier suggestion 
https://bugreports.qt.io/browse/QTBUG-44219


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTableView gets freezed in showing data read from SQLite database , which is updated dynamically with 2000 rows in 2s

[André Somers]

Op 09/07/2016 om 20:01 schreef swarit wipra:

Hi folks,

i have issues in showing huge data in QTableView ,data read from 
sqlite database which is being updated dynamically .. 2k rows in 2s.

i am using QSQLRelationModel
let me describe the scenario in detail.

My Qt application has a view i.e QTableView , each row has following 
structure:


 
 *QPushButton*|QLabel | QLabel | QLabel *
 
 i have created it using QItemDelegate

 each row isinserted dynamicaly , after sometime gui gets freezed.

could anyone tell me the way to fix the issue.
Don't implement it like this. You are creating 8k widgets and act 
suprised that it isn't fast... Even if you did not use QLabel but the 
default delegate, 2k push buttons is still pushing it I think.


Note that this is by no means a new issue. Search and you will find 
better options, even ones using widgets but creating far less instances.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use of Standard Library containers in Qt source code

[André Somers]

Op 07/07/2016 om 09:10 schreef Marc Mutz:

On Thursday 07 July 2016 03:00:08 Thiago Macieira wrote:

In case we're not getting the deserved attention due to Summer vacations,
I'll  post again in a month or so to see if there's any change.

We have The Chief on record saying that we should use whatever is most efficient
internally  (https://codereview.qt-project.org/114327 comment from
2015-06-15), and you agreeing (ibid, 1st @ 2015-06-16).

So from my pov, the only question is whether we stay with Option 4 or relax to
Option 5, and I'm fine with either.


I don't think that rules out option 3 either, does it?

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use of Standard Library containers in Qt source code

[André Somers]

Op 04/07/2016 om 10:03 schreef Philippe:

Actually, I disagree with that. As someone who has come to appreciate
STL after growing up in the Qt world,

Exact opposite here: I learned STL from its early days, and could never
become at ease with its namings... and I started to breath with Qt
containers :)

I'm not saying the namings are good, and I still find snake_case ugly. I 
dislike the use of abreviations, and yet, isEmpty() is way clearer than 
empty(). But the principles are very sound, especially the use of named 
algorithms over raw loops. Note that Qt has basicaly abandoned it's own 
algorithm collection for the stl one. That's mostly a Good Thing IMHO, 
though having your own collection of algorithms building on top of stl 
good practice I think. STL is by no means complete; you're encouraged to 
extend it. Defining a well-named free function to bridge the gap where 
it improves things is one way of enhancing both: you enhance STL by 
making it more readable to use, and you enhance Qt by embracing 
well-tested algorithms and containers.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use of Standard Library containers in Qt source code

[André Somers]

Op 04/07/2016 om 08:41 schreef Thiago Macieira:

On segunda-feira, 4 de julho de 2016 08:14:21 PDT Julien Blanc wrote:

Following Stephen Kelly’s mails, I’m convinced that instead of wrapping
stl containers, implementing a free function qIsEmpty is less work and
addresses all your readability concerns.

But it is uglier
Actually, I disagree with that. As someone who has come to appreciate 
STL after growing up in the Qt world, I think that memberfunctions are 
over-used. Emptyness is a concept that can be applied to many objects, 
and it would be nice if I don't need a different function for all of 
them. The problem with implementing things in a member function is that 
the implementation will be specific for that class only, even if it did 
not really have to be. You end up re-creating algorithms for no good 
reason. And yes, that mistake has been made in the standard libraries as 
well.


Note that there is work going on by Bjarne S. on a universal calling 
conventions. As in: making calling a free function on an object and 
calling a member function on that object to be interchangeble in syntax.



and does not help with .append() for .push_back().


Why not? You could do the same thing there if you prefer.

append(Container c, T item) can be made to work for both STL and Qt 
containers I think?


André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] Native event filter in QtService

[André Somers]

Op 24/06/2016 om 11:18 schreef Bo Thorsen:

Hi all,

I'm copying this to devel, because it fits in a discussion a week or 
two ago.


Den 24-06-2016 kl. 10:56 skrev Tony Rietwyk:

qtservice_win.cpp around line 830 at your reference [1] installs its own
nativeEventFilter - probably displacing yours.

I suspect you'll need to merge the Qt filter into yours, and get rid of
that install.


That is impossible for commercial projects because the solutions are 
LGPL only. You can't copy LGPL code into your own code base unless you 
are using GPL or LGPL yourself.


And that's why I copied this message to devel, because there was a 
discussion on whether to add solutions to Qt Core or not. And one of 
the arguments against is that people can just use the solutions as 
they are. This is one case, where apparently that's not (at least 
currently) possible.


I can come up with a couple of workarounds for this, sure. But these 
are all brittle and may not work if the solutions code is changed.
In a previous company I worked for, we simply created an LGPL lib for 
all the stuff we borrowed this way. I really don't see why one can't use 
an LGPL-ed lib for most situations.


André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] commas in ctor-init-lists

[André Somers]

Op 03/06/2016 om 14:52 schreef Marc Mutz:

On Friday 03 June 2016 14:26:03 André Somers wrote:

Op 03/06/2016 om 13:53 schreef Marc Mutz:

On Friday 03 June 2016 10:05:52 Edward Welbourne wrote:

if (somee.really(long.and.complicated, expression) ||
another.such(that,

makes, the.line.too.long) || and.then.some.more())

To be perfectly blunt: such expressions shouldn't be allowed. Period.
Neither with nor without line breaks. Such monsters should be subjected
to Extract Method with extreme prejudice.

Thanks,
Marc

Fine. Lets replace it with something like this then:

if (theValue ==
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue1 ||
theValue ==
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue2 ||
theValue ==
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue3) {

}

Umm... same thing?

What I'm saying is:

- Multi-line conditions in if statements should *always* be refactored to a
   single function call.

Then we don't need to talk about how to format multi-line ifs at all, because
they do not exist anymore.
Eh... So you move the same to a different method. How does that help? 
You'd basically get the same expression but then in a method of it's own?



[...]

We have the same problem in .pro files: QtC just appends new files, always
creating a patch the churns the old-last line in SOURCES. If it would sort
them in lexicographically, most additions would be one-liners.

I requested this quite a while ago already.

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] commas in ctor-init-lists

[André Somers]

Op 03/06/2016 om 13:53 schreef Marc Mutz:

On Friday 03 June 2016 10:05:52 Edward Welbourne wrote:

   if (somee.really(long.and.complicated, expression) || another.such(that,
makes, the.line.too.long) || and.then.some.more())

To be perfectly blunt: such expressions shouldn't be allowed. Period. Neither
with nor without line breaks. Such monsters should be subjected to Extract
Method with extreme prejudice.

Thanks,
Marc


Fine. Lets replace it with something like this then:

if (theValue == 
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue1 || 
theValue == 
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue2 || 
theValue == 
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue3) {


}

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] commas in ctor-init-lists

[André Somers]

Op 03/06/2016 om 08:52 schreef Martin Smith:

You can do this, given:

Nobody does that. We always write: * You bla, or you boo, or you foo, and in 
this case we would normally write: You bla, you boo, or you foo. Even better: 
You bla, boo, or foo. You are inventing problems that don't exist.


If you say so.

So that means that our C++ code should look like this then?

if (blah || boo || foo) {  //no line breaking allowed
   something();
}

What a load of nonsense.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] commas in ctor-init-lists

[André Somers]

Op 02/06/2016 om 21:47 schreef André Pönitz:

On Wed, Jun 01, 2016 at 03:36:43PM +0200, Olivier Goffart wrote:

On Mittwoch, 1. Juni 2016 12:56:12 CEST Simon Hausmann wrote:

Hi,

I'm in favorof changing our coding style to adopt the model you call "butt
ugly" because I find it more appealing and I find that it makes diffs
easier to read.

Simon

+1  as well, if someone counts the votes!

Why would anyone bother to count votes before any (theoretically binding
or non-binding, doesn't seem to matter) result of voting gets ignored by
the next submitter anyway?

Well, if the rules would be encoded in a clang-format  format that is 
used in a commit hook, that would not be an issue any more, would it?


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] commas in ctor-init-lists

[André Somers]

Hi,


Op 03/06/2016 om 08:28 schreef Martin Smith:

but it is very structurally clean and in some circumstances I prefer it due to 
that.

The structure is a comma separated list. Historically, the comma has always been placed directly 
after the first of two list items. The comma tells the reader that another list item will follow. 
There is nothing to clean. Note the comma I used appeared right after the word 
"Historically,"  as did that one, and that one appeared right after the word 
"none."  The comma has never appeared as the first character of anything.


Note there is a related coding style violation for if statements.

The relationship is tenuous. '||' is an operator, ',' is a separator. '||' represents a 
word to the reader ( "or"). The comma doesn't represent a word.

Well, if we go that way, lists of conditions are often written like this:
You can do this, given:
* You bla, or
* You boo, or
* You foo

Note the position of the or. Does that mean that the equivalent C++ 
should look like this:

if ( bla ||
  boo ||
  foo )
{ //we can debate the position of the opening brace here as well...
do this...
}

No. I think this drawing of parallels with natural language formatting 
is not very productive. Code is not natural language and we should not 
apply the same formatting rules to them.






This has the same benefits for diffs as the leading comma,

Is "diff noise" really a thing? If it is, why doesn't someone rewrite diff with 
an option to suppress it?
Ehhh? The diff is there and is significant, isn't it? So it should not 
be suppressed unlike some stray white space differences.



Anyway, I am all for using an auto-formatter. I think they are good 
enough nowadays. They may not in every circumstance generate the 
absolute most beautiful layout, but it saves a huge amount of time not 
having to care for it anymore, not getting style^Hformatting related 
-1's from the CI any more and not having to debate it any more. So I 
think it is well worth the loss of prefered formatting here and there. 
And yes, you can use your own prefered format locally if you please, as 
long as it gets reformatted to the standard one on submission. Sounds 
ideal to me.



André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Documentation for QPagedPrintDevice::setPageSize should specify a unit`

[André Somers]

Hi Steve,

Thanks for actually stepping up the plate to create a contribution!
It looks fine to me, but I cannot approve this myself.

https://codereview.qt-project.org/158402

André


Op 05/05/2016 om 19:34 schreef Steve Schilz:

Hi Andre,

Challenge Accepted!
I have looked at this before and found it a lot to get set up. I really need to 
get over the hump so that I can do this.
If I understand correctly, docs are generated from comments in the source code… 
I have JIRA and Gerrit accounts, and am familiar with downloading building Qt.


So my next steps are
* Accept the contribution agreement
* Clone Qt - Which branch? 5.8?
* prepare a patch altering the docs in the source code comments, submit to code 
review…

    QUESTION * Who do I put as reviewer for this change?


Steve Schilz
PASCO scientific - think science









On 5/4/16, 11:06 PM, "André Somers" <an...@familiesomers.nl> wrote:


I think it does make sense. How about a making a small contribution to
Qt to fix this?

André

Op 05/05/2016 om 01:25 schreef Steve Schilz:

Oops, I ment QTextDocument::setPageSize 
(http://doc.qt.io/qt-5/qtextdocument.html#pageSize-prop)
Does that make more sense?


Steve Schilz
PASCO scientific - think science









On 5/4/16, 2:17 PM, "Giuseppe D'Angelo" <dange...@gmail.com> wrote:


Hi,

On Wed, May 4, 2016 at 10:09 PM, Steve Schilz <ssch...@pasco.com> wrote:

The doc is confusing because it does not specify a unit for the input
parameter “pageSize"

The parameter is of type QPageSize, which has multiple setters and
constructors. Which one(s) is missing the unit specification?

Thanks,
--
Giuseppe D'Angelo

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Heads up! Fixing the build system on Windows

[André Somers]

Op 01/04/2016 om 07:49 schreef Thiago Macieira:

I want to point this out:

On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote:

On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:

It's still March 31st.

April Fools rules, #27: all jokes refer to the jokers' time zone.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changing definition of Qt meta macro to allow tools integration

[André Somers]

Op 31/03/2016 om 06:04 schreef Thiago Macieira:

On quinta-feira, 31 de março de 2016 00:10:48 PDT Olivier Goffart wrote:

The question is rather, the Qt creator that will be release in 2 years will
maybe want to use these macros to auto complete signals/slots and
properties. I would assume some people would still have a LTS version of Qt
which would then be, say Qt 5.6.4.   So then it would be valable to habe
this patch in the LTS branch.

I don't think it's valuable because those tools will need to deal with Qt
5.6.0 and older.

"Deal with" can be done on many levels. I'd say it would be acceptable 
if some more advanced features are not available for older Qt versions. 
Sure you can edit projects based on old Qt versions, but do you really 
think that it has to offer the same level of tooling that is made 
possible with newer versions? So for what its worth, I think I'm with 
Olivier here: it makes sense to put it in an LTS that is expected to see 
use for a long time yet.


André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development