Re: [Development] Qt Examples need to be self-contained

[Richard Gustavsen via Development]

I would argue that putting actually shared resources into such libraries is a 
good idea

Looking at 
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quick/shared, it 
mostly contains QML controls, like Slider.qml and TextField.qml. The examples 
using those components should really be using QQ Controls instead. After all, 
we should recommend using QQ Controls in our own examples (*). Some users might 
even be tempted to import such a new "shared resources” module into their own 
apps, and start using the “wrong” Slider.qml and TextField.qml etc. Keeping 
only the media, such as icons and images, should perhaps be OK, though.

Also, if some of the code used in an example is hidden away in a prebuilt 
shared module, doesn’t that sort of defeat the purpose of an example; To be 
able study and understand how to built a self-standing application (without 
digging through the Qt source code)?

-Richard

*: This probably comes from the time when Controls was a separate repository, 
and couldn’t be used by Declarative.
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Matthias Rauter for approval status

[Richard Gustavsen via Development]

+1

-Richard

On 30 Jan 2024, at 13:11, Paul Tvete via Development 
 wrote:

Hi,

I would like to nominate Matthias Rauter as an approver for the Qt Project.

Matthias has been working on Qt for more than a year now. In this time, he has 
done great work on Qt Location and Qt SVG, among other. I have had the pleasure 
to work with him on the Curve Rendering project in Qt Quick Shapes where he has 
made impressive contributions. He has been consistently professional in 
development and review, and I am certain that he will exercise his approver 
powers responsibly.

List of changes made by Matthias: 
https://codereview.qt-project.org/q/owner:matthias.rauter%2540qt.io
Matthias's review activity: 
https://codereview.qt-project.org/q/commentby:matthias.rauter%2540qt.io

Cheers,
 - Paul
--
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] QSortFilterProxyModel: recursiveFilteringEnabled

[Richard Gustavsen via Development]

> On 21 Sep 2023, at 19:44, László Papp  wrote:
> 
> Thanks!
> 
> Since both QML and KDE have had this use case, and now, I also have it, as 
> well as another person on Stack Overflow, should we propose a public API in 
> Qt for this?
> 
> I think this would be a great addition to the public interface.

Create task for it. And then anyone that disagrees or have alternative 
proposals can comment on it.

-Richard

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

Re: [Development] QSortFilterProxyModel: recursiveFilteringEnabled

[Richard Gustavsen via Development]

On 21 Sep 2023, at 14:10, László Papp  wrote:

Thanks!

So, something like this?

https://api.kde.org/frameworks/kitemmodels/html/index.html

E.g. KDescendantsProxyModel or that would also require further work?

Yes, that could work. And then you give that model to QSFPM to filter away rows 
that has children in the original source model (since you don’t want to include 
the parent nodes, I take it).

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

Re: [Development] QSortFilterProxyModel: recursiveFilteringEnabled

[Richard Gustavsen via Development]

You basically want top flatten a tree model into a list (or table) model, and 
then remove the rows that have children, and then sort the list. Note that 
sorting such a list of leafs would be different from how QSFPM works today, 
where it sorts the children of each parent node locally, without taking 
grandchildren or siblings into account. If the model was converted to a flat 
list, all the leafs would have to be sorted together. I, at least, would be 
very uneasy about changing QSFPM this way.

IMHO, a think flattening a tree model into a table / list model is better done 
in a separate proxy model (*). And then your app could just wrap this model 
inside a QSFPM.

(*) We do in fact have such a proxy model in QML today; 
qtdeclarative/src/qmlmodels/qqmltreemodeltotablemodel.cpp, used by TreeView. It 
could perhaps have been made public, if this is need is found to be common 
enough.

-Richard

> On 20 Sep 2023, at 20:31, László Papp  wrote:
> 
> Yes, I have tried that, thanks.
> 
> bool TableProxyModel::filterAcceptsRow(int sourceRow,
>const QModelIndex &sourceParent) const
> {
>   QModelIndex index = sourceModel()->index(sourceRow, 0, sourceParent);
>   CustomModelItem* item = 
> static_cast(index.internalPointer());
>   return !item->childCount();
> }
> 
> The problem is the property. It is mixing two different things, so it does 
> not suffice when one only needs one of those.
> 
> If you filter without recursiveFilteringEnabled enabled (default, false), 
> then it will only filter through the root node(s). So, you would not be able 
> to filter in the children.
> 
> If you set recursiveFilteringEnabled to true, then it will filter through the 
> children, but then it will also include the parents of those children.
> 
> So, what we need is being able to filter through children (i.e. recursive 
> filtering), but without showing the parents.
> 
> Does that make sense?
> -- 
> 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] Nominating Santhosh Kumar Selvaraj for approver rights

[Richard Gustavsen via Development]

+1

Richard

20. jun. 2023 kl. 20:58 skrev Jan-Arve Sæther via Development 
:

 Hello all,

I would like to nominate Santhosh Kumar Selvaraj for approver rights in the Qt 
project.

Santhosh is a member of the UI Team, and has been working on improvement to our 
styles, dark mode support, palette handling both in qtbase and qtdeclarative.

You can see his merged changes here:
https://codereview.qt-project.org/q/owner:santhosh.kumar.selvaraj%2540qt.io+is:merged

and his reviews here:

https://codereview.qt-project.org/q/reviewer:santhosh.kumar.selvaraj%2540qt.io

cheers,
---
Jan Arve Sæther
Team Lead

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
jan-arve.saet...@qt.io
http://qt.io
---


--
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] How to fix TableView's API break?

[Richard Gustavsen via Development]

Neither is ideal and I would've strongly preferred to stick to (row,column) 
everywhere. Everything else is an API trap waiting to happen.

Now that modelIndex() has been reverted to fix the SiC, I agree, we should 
consider deprecating/replacing the other two remaining functions that takes a 
column and a row as well, to make it consistent.

(Other ideas: remove the row/column convenience, and always use indices. Why 
does a _view_ return model indices at a given logical position, and not the 
model directly? Etc.)

In an TreeView, the application's tree model is flattened into an internal 
table model. So you cannot know, from the tree model alone, which QModelIndex a 
particular cell in the table represents. Hence, the view has to provide some 
mapping functions to help out (like e.g TableView.modelIndex(row, column)).

This is spelled "model index" in the entirety of Qt model/view code. Why can't 
the above be implemented like this?

let index = tableView.indexAtPosition(tapEvent.position) // this is a 
QModelIndex
tableView.positionViewAtIndex(index)

ListView was written to support models other than QAIM. And when TableView was 
implemented years later, we reused much of the same code (QQmlAdaptorModel, 
QQmlInstanceModel etc), to support the same. That said, adding more overloads 
to work directly with a QModelIndex, e.g positionViewAtIndex(), like you 
suggest, makes sense, and we should do that. But deprecating functions that 
takes a row, column (or a point), would mean that we would stop supporting 
those other models.

Wait, is this the reason -- that QModelIndex got "gadgetified" relatively 
recently (5.6?), and these views have been around since before it and couldn't 
use it?

ListView, even more so than TableView/TreeView, was written to support other 
models than just QAIM, where a QModelIndex cannot be used. I don’t know the 
history behind how/when/why QModelIndex became available to QML, though.

You could argue that we need a new type for this, and perhaps you’re right. But 
a table is, after all, just a two-dimensional grid of cells, and QPoint is 
meant as a general type for dealing with all kinds of two-dimensional 
coordinate systems.

That's very misleading.

For a cell position there's no sense of asking stuff like "what's the Manhattan 
distance from the origin" or "multiply its coordinates by a scalar factor", 
which are instead legitimate operations on a type like QPoint.

When implementing TableView, there would be no way around looking at a table as 
a two-dimensional grid of cells, where mathematical types like QPoint and QRect 
are used to implement rectangular selections, keep track of which cells are 
visible in the viewport, or simply navigating the current index around with the 
keyboard. Because of that (and the example I wrote earlier), I thought it would 
make sense to offer the same convenience to app developers. If that turns out 
to be a misguided attempt that has no valid use case (outside the internals of 
TableView), we can consider deprecating those (few) functions that takes a 
QPoint (and perhaps create a dedicated type, or drop support for models other 
than QAIM, and use QModelIndex).

Anyway, thanks for the input. I’m sure you’re not alone in thinking that the 
order of the arguments should have been swapped from the start. Feel free to 
create some JIRA tasks and assign them to me, so that we can keep track of 
suggestions and other things that should ideally be changed.

-Richard

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

Re: [Development] How to fix TableView's API break?

[Richard Gustavsen via Development]

https://codereview.qt-project.org/c/qt/qtdeclarative/+/449862

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

Re: [Development] How to fix TableView's API break?

[Richard Gustavsen via Development]

Does anyone know?
The rationale behind it is that you normally would like to address a cell in a 
table using x, y coordinates. x maps horizontally and y maps vertically (to be 
consistent with e.g Item.x and Item.y). This means that x maps to columns and y 
maps to rows. itemAtCell(column, row) follows that thinking, since that is on 
the same format as writing itemAtCell(x, y).

Well, for starters, nowhere in Qt one has ever referred to the _logical 
positions_ in a model/view using "x" and "y", but "row" and "column". "x" and 
"y" are usually for things like pixel positions.

Which is fine. You can always just the API that takes a column and a row 
instead of a cell, if that makes most sense for a particular application. The 
API has overloads for both column and row, and QPoint.

Row-major or column-major access is surely a case of tomayto/tomahto, but why 
deciding to introduce an inconsistency in TableView, after decades of APIs 
built around accessing via row/column?

It’s what I wrote above. But TableView was introduced more than four years ago, 
so there might have been other considerations as well. But anyway, once this 
path was taken, any new functions that we add (like modelIndex()) should follow 
the same template, to be consistent. And to me, this API should be 100% 
consistent, in that respect. You mention the word “consistent” several times, 
but if I understand you correctly, is more about why row and column are 
specified in the “wrong” order. (BTW, this affects three functions in 
TableView, out of more than thirty, to put things in perspective). And also why 
the API uses QPoint to represent a cell. Both are valid concerns (I’ll fill in 
a bit more below), but it's not inconsistent, it has been like this for a long 
time, and should not need urgent attention (AFAICS).

QModelIndex modelIndex(point cell)
A point is specified using Qt.point(x, y), so again consistent with what I 
wrote above. I don’t find it weird that the API lets you also combine x and y 
coordinates into a point type.

But this is precisely why it's weird and confusing. `point` here isn't a point 
(as in, floating point coordinates on a Cartesian plane; aka QPointF). It's the 
logical index of the cell:

Since it's a logical index, it makes absolutely no sense to accept a floating 
point coordinate there. Why even offering this "convenience"?

Consider this:


let cell = tableView.cellAtPosition(tapEvent.position)

tableView.positionViewAtCell(cell, TableView.AlignCenter)


This short example shows why working with a cell/coordinate, rather that 
individual (column, row), can be beneficial. It makes things more readable, and 
requires fewer lines of code. The first line shows also that having a type that 
can represent a cell is useful, since cellAtPosition() can only return a single 
value.


Note that in the qquicktableview_p.h API, a QPoint is used to represent a 
cells, and not QPointF. The fact that this gets translated to a floating point 
in QML is off-topic, or at least not much that I can do about in TableView.

And why accepting, specifically, `point`? I can't help but think that this is 
another case of shoehorning -- QPoint is "the first available datatype that 
gets the job done". This use case demanded a brand new value type and that's 
tedious to do. (But did it demand one? I've never had the need to use a 
(row,column) pair

You could argue that we need a new type for this, and perhaps you’re right. But 
a table is, after all, just a two-dimensional grid of cells, and QPoint is 
meant as a general type for dealing with all kinds of two-dimensional 
coordinate systems. And QML has language support for doing arithmetics with 
points. So I’m not convinced that introducing a new type is correct. I’m not 
stubborn about this, and I’m open for ideas/discussion (but perhaps in JIRA)

alone, ever -- I've always carried around a model index when I needed to 
identify a cell.)

This has todo with legacy reasons, all the way to ListView. Since you can 
assign many different kinds of models to a ListView and TableView; js arrays, 
ObjectModel, string lists, numbers, etc, so there isn’t always a 
QAbstractItemModel in use. Hence, you cannot always rely on a cell being backed 
by a QModelIndex. If the whole QML Item Views story were to be rewritten, I 
would argue that _all_ supported models should have beed proxied by a QAIM. But 
that's not the current situation.

It’s also worth mentioning that a TableView is not only meant for typical 
spread sheet applications. We know from experience with ListView, that it might 
end up being (mis)used for all kinds of things. e.g ListView is also to 
implement a PageView etc. And we also have a couple of examples in Qt today, 
gameOfLife and pixelator, that shows a more “mathematical” usage of TableView, 
where perhaps x and y makes more sense that column and row.

That is a problem, yes. Good catch. Not sure how that sneaked in, but it needs 
to be fixed. But this doesn’t r

Re: [Development] How to fix TableView's API break?

[Richard Gustavsen via Development]

>> Item itemAtCell(int column, int row)
> 
>> positionViewAtCell(int column, int row, PositionMode mode, point offset, 
>> rect subRect)
> 
> To me this is quite weird. This must be the *only* place in Qt model/view 
> APIs where (column,row) is used instead of (row,column), and I don't seem to 
> find any justification for this.
> 
> Does anyone know?

The rationale behind it is that you normally would like to address a cell in a 
table using x, y coordinates. x maps horizontally and y maps vertically (to be 
consistent with e.g Item.x and Item.y). This means that x maps to columns and y 
maps to rows. itemAtCell(column, row) follows that thinking, since that is on 
the same format as writing itemAtCell(x, y).   

> 
> What's more: there's inconsistencies already all over the place in TableView! 
> For instance positional functions take (x,y), and not (y,x):
> 
>> point cellAtPosition(real x, real y, bool includeSpacing)
> 

This is consistent with what I wrote above. 

> 
> Also the above functions are also inconsistently (and weirdly) overloaded 
> with overloads taking `point` (== QPointF). For instance:
> 
> 
>> QModelIndex modelIndex(point cell)

A point is specified using Qt.point(x, y), so again consistent with what I 
wrote above. I don’t find it weird that the API lets you also combine x and y 
coordinates into a point type.

> 
>> positionViewAtCell(point cell, PositionMode mode, point offset, rect subRect)
> 
> Here `cell` is a logical index (so why do they take a FP-based point?), and 
> for extra fun, cell.x is the *column* and cell.y is the *row* (!!!).

Why do you find it “fun" that x maps to column and y maps to rows in this case? 
To me that is logical. Do you think x should map to rows instead?

> And finally:
> 
>> point cellAtPosition(point position, bool includeSpacing)
> 
> This is pure evil, as `position` is a position in pixels (relative to the 
> TableView's content item), while the return is ... a logical index (with 
> again `x` being the column and `y` and the row). The type of the parameter 
> and the return value is the same, yet they represent completely different 
> things! How is this good API?

The API uses the term “position” whenever we talk about a pixel position, and 
“cell” whenever we talk about a table cell.This is consistent through out the 
API. The fact that we use point as type for them both should not be confusing 
when the function is called cellAtPosition. What else could _cell_ mean? Pixel 
position? 

> So, how to fix the above? One could easily fix the API break, but one is left 
> with broken APIs all over the place.

You then assume that the API is semantically broken all over the place (not 
SIC), and it has been like for in the whole of Qt 6. I don’t think so. But if 
others agree, I would say that this is something to look at in an upcoming 
version of Qt. Not Qt 6.5?

If TableView was written from the start, the API for itemAtCell would have been 
row, column and not column, row. Not because of the arguments above, but simply 
because it would be more consistent with the order you specify the coordinates 
to a QModelIndex. Whether you specify row first, or column first, in the API is 
not (in my eyes) wrong or right, but a matter of preference. But it should be 
consistent.

> Between 6.3 and 6.4 there's been an API break in QtQuick's TreeView: its 
> modelIndex(row,column) function got moved into its base class (TableView), 
> and the arguments swapped for it, so now it's 
> TableView::modelIndex(column,row).

That is a problem, yes. Good catch. Not sure how that sneaked in, but it needs 
to be fixed. But this doesn’t require an exception to the FF, we can surely fix 
up the API (added to Qt 6.5) after the FF?

-Richard


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

Re: [Development] Nominating Axel Spoerl as approver

[Richard Gustavsen via Development]

+1

Fra: Development  på vegne av Eirik 
Aavitsland via Development 
Sendt: mandag 5. desember 2022 11:05
Til: development@qt-project.org 
Emne: Re: [Development] Nominating Axel Spoerl as approver

+1

On 12/5/22 10:57, Volker Hilsheimer via Development wrote:
> Hi,
>
>
> I’d like to nominate Axel Spoerl as an approver for the Qt project.
>
> Axel has been working in The Qt Company since January, writing tests, 
> analysing and fixing bugs, participating in the port of Qt Speech to Qt 6, 
> investigating and stabilising flaky tests across all platforms, and most 
> recently implementing platform theme support for GTK3-based Linux desktop 
> environments.
>
> I trust him to be a good approver. Links to gerrit dashboards:
>
> Patches: https://codereview.qt-project.org/q/owner:axel.spoerl%2540qt.io
> Reviews: https://codereview.qt-project.org/q/reviewer:axel.spoerl%2540qt.io
>
> Disclosure: I’m Axel’s indirect line manager at The Qt Company in Oslo.
>
>
> Volker
>
> ___
> 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] Redesigning QML value types

[Richard Gustavsen]

> 1. Value types are passed by value
>  2. Everything is a reference

Most languages have a way to specify this in the signature. Swift has the 
“inout” keyword, c# has “ref”. Have you considered this as an option as well?

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

Re: [Development] Nominating Volker Hilsheimer as maintainer of Qt Speech

[Richard Gustavsen]

+1

-Richard

> On Jun 13, 2022, at 9:19 AM, Frederik Gladhorn  wrote:
> 
> Hello :)
> 
> I've lately not had time to contribute to Qt (personal life keeping me busy).
> Since Volker and others did a great job porting Qt Speech to Qt 6, they know 
> the code better than me by this time. I'd like to step down as maintainer and 
> allow those who actually contribute to take over.
> 
> Hereby I nominate Volker as maintainer (he's agreed privately already).
> 
> Cheers,
> Frederik
> 
> ___
> 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] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

[Richard Gustavsen]

This has now taken effect, and the Wiki has been updated 
(https://wiki.qt.io/Maintainers).

Congratulations Volker!

Best Regards,
Richard Moe Gustavsen
Principal Engineer
The Qt Company
Oslo, Norway

On 25 Jan 2022, at 09:38, Richard Gustavsen 
mailto:richard.gustav...@qt.io>> wrote:

Hi all!

I would like to propose a change in the maintenance of Qt Widgets [1]. I’m the 
current maintainer of the module, but I’m happy to inform you that Volker 
Hilsheimer has agreed to join me as a co-maintainer. Volker is one of the 
biggest contributors to Widgets [2], and has been helping out maintaining the 
module for a long time already. So let’s make it formal as well!

[1] https://wiki.qt.io/Maintainers#Qt_Maintainers
[2] 
https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io+repo:qt/qtbase+status:merged

Best Regards,
Richard Moe Gustavsen
Principal Engineer
The Qt Company
Oslo, Norway

___
Development mailing list
Development@qt-project.org<mailto: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] XCB platform plugin maintainer change

[Richard Gustavsen]

+1

-Richard

> On 1 Feb 2022, at 11:08, Eirik Aavitsland  wrote:
> 
> +1
> 
> On 2/1/22 10:50 AM, Gatis Paeglis wrote:
>> Hi all,
>> I would like to propose a change in Qt's Linux/XCB maintainership.
>> Since 2019, I have moved full time to the Qt for MCUs project and
>> there is no time left for XCB work.
>> /qtbase/src/plugins/platforms/xcb$ git shortlog --since=2021 --no-merges -s 
>> -n .
>> 11  Liang Qi
>>  6  Tor Arne Vestbø
>>  3  Gatis Paeglis
>> I would like to propose Liang Qi as the new maintainer. He has been
>> with the company for more than a decade.
>> Gatis Paeglis.
>> ___
>> 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] Nominating Volker Hilsheimer as co-maintainer of Qt Widgets

[Richard Gustavsen]

Hi all!

I would like to propose a change in the maintenance of Qt Widgets [1]. I’m the 
current maintainer of the module, but I’m happy to inform you that Volker 
Hilsheimer has agreed to join me as a co-maintainer. Volker is one of the 
biggest contributors to Widgets [2], and has been helping out maintaining the 
module for a long time already. So let’s make it formal as well!

[1] https://wiki.qt.io/Maintainers#Qt_Maintainers
[2] 
https://codereview.qt-project.org/q/owner:volker.hilsheimer%2540qt.io+repo:qt/qtbase+status:merged

Best Regards,
Richard Moe Gustavsen
Principal Engineer
The Qt Company
Oslo, Norway

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

Re: [Development] Nominating Morten Sørvig as maintainer of high-DPI

[Richard Gustavsen]

+1

Richard

On 20 Dec 2021, at 16:35, Tor Arne Vestbø 
mailto:tor.arne.ves...@qt.io>> wrote:

Hello all,

I’d like to nominate Morten Sørvig as maintainer of high-DPI in the Qt Project 
[1].

Morten has been instrumental in the development of Qt’s high-DPI support, and 
has been the de-factor maintainer for a while now. Let’s make it official.

Cheers,
Tor Arne

[1] Under qtbase/QtGui in https://wiki.qt.io/Maintainers

___
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] Nominating Doris Verria as Approver

[Richard Gustavsen]

+1

Fra: Development  på vegne av Paul Wicking 

Sendt: onsdag 27. oktober 2021 12:09
Til: Volker Hilsheimer 
Kopi: development@qt-project.org 
Emne: Re: [Development] Nominating Doris Verria as Approver

+1

> On 27 Oct 2021, at 11:56, Volker Hilsheimer  wrote:
>
> Hello World,
>
> I’d like to nominate Doris Verria as approver in the Qt Project.
>
> Doris has been working as a Software Engineer for The Qt Company for over a 
> year, and has made great contributions to Qt [0]. I have come to appreciate 
> her as a coder that bravely takes on new challenges, and as a thorough code 
> reviewer [1].
>
> I’ll trust she’ll use the approver rights responsibly.
>
> Disclaimer: Doris reports directly to me in The Qt Company.
>
> Volker
>
>
> [0] https://codereview.qt-project.org/q/owner:doris.verria%2540qt.io
> [1] https://codereview.qt-project.org/q/reviewer:doris.verria%2540qt.io
>
>
> ___
> 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] Nominating Oliver Eftevaag as Approver

[Richard Gustavsen]

+1

Fra: Development  på vegne av Shawn 
Rutledge 
Sendt: onsdag 27. oktober 2021 10:34
Til: development@qt-project.org 
Emne: Re: [Development] Nominating Oliver Eftevaag as Approver

+1

On 2021 Oct 27, at 06:25, Paul Wicking 
mailto:paul.wick...@qt.io>> wrote:

Hi all,

I'd like to nominate Oliver Eftevaag as an approver.

Oliver has been working as a software engineer for the Qt Company for almost a 
year now and has made a fair number of contributions to Qt [0]. He also 
participates actively in reviews [1]. He's curious and passionate about 
learning new things, and happy to share his knowledge with his colleagues.

I trust he'll use the approver rights responsibly.

Disclaimer: we sporadically meet for lunch or by the coffee machine.

//! Paul

[0] - 
https://codereview.qt-project.org/q/owner:oliver.eftevaag%2540qt.io
[1] - 
https://codereview.qt-project.org/q/reviewer:oliver.eftevaag%2540qt.io
___
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] Proposal: let's use Markdown for the dist/changes changelog

[Richard Gustavsen]

> But I didn’t like it when we generate a point-release changelog that says
> there are only minor changes, when I know for a fact that some significant
> bugs got fixed, and should be mentioned, even though the author forgot to
> add a ChangeLog to the git commit.  So a few years ago, before each release
> I was actually scanning the git log manually to look for such bug fixes
> that ought to be mentioned.  I got tired of that because it always requires
> several windows at the same time: a terminal to view the git log, an editor
> for the changes file, and a browser with a couple of tabs open to look up
> bugs and code changes.

> Yep, same here.

Would it be better if we required all commits to have a ChangeLog entry, so 
that no one
forgets? And if your commit shouldn't be in the log, you need to state that 
explicitly, e.g: [NoChangeLog]

-Richard

Fra: Development  på vegne av Thiago 
Macieira 
Sendt: mandag 2. november 2020 16:59
Til: development 
Emne: Re: [Development] Proposal: let's use Markdown for the dist/changes 
changelog

On Monday, 2 November 2020 02:26:31 PST Shawn Rutledge wrote:
> So in practice, changelogs still require manual editing.  Probably there is
> someone who knows just what settings to use in just what editor to make it
> effortless, but for me it always involves a lot of tedious manual spacing,
> because paragraph indentation is so damn weird (5 spaces usually), etc.
> Creator doesn’t know how to wrap a paragraph in a changelog, for example.
> There is no tool to center the text inside the star-box headings except for
> the generator scripts themselves, AFAIK.

Emacs works just fine. You just need to add spaces before and after the -
lines so it detects what's a paragraph, then use M-q to rewrap. The centering
can be done by removing the leading and tailing stars, then use M-x center-
line. At least, this is how it was done when I created the script.

But I wholeheartedly agree on changingi to either Markdown or ReStructuredText
for the headings and the bullets.

> One possible bikeshed is whether we should use the easier format for
> headings like

> # QtQuick
>
> ## Animations
>
> or one that perhaps looks a bit better in the terminal, but only allows 2
> levels of headings (which is enough in practice, so far):

> QtQuick
> ===
>
> Animations
> --

RST allows for far more levels even in the more verbose way. Anyway, since we
only use two levels anyway and I think we should avoid adding more levels, I
would prefer the more verbose way.

Note: the levels here are "Libraries" and "QtQuick". "Animations" is a big
bullet and "alwaysRunToEnd==true" (a bad entry) is a sub-bullet.

> But I didn’t like it when we generate a point-release changelog that says
> there are only minor changes, when I know for a fact that some significant
> bugs got fixed, and should be mentioned, even though the author forgot to
> add a ChangeLog to the git commit.  So a few years ago, before each release
> I was actually scanning the git log manually to look for such bug fixes
> that ought to be mentioned.  I got tired of that because it always requires
> several windows at the same time: a terminal to view the git log, an editor
> for the changes file, and a browser with a couple of tabs open to look up
> bugs and code changes.

Yep, same here.

> So I modified Simon’s go script to also find the
> git log entries that mention bugs, and append the git commit message plus
> extra text taken from the jira subject line.  And I just quietly used that
> script to overwrite the generated changelogs, and then edited by hand to
> format it nicely, in qtdeclarative only.  So probably qtdeclarative has had
> more-complete change logs than most other modules during the last few
> years.  I’d selectively use it to add a few qtbase changes that I wanted to
> highlight too though, now and then.  Other people were using it in other
> modules sometimes.

Extracting extra entries is a welcome addition. If you can just mark the
entries thus extracted so we know what was written as an intentional changelog
and what is speculative and thus requires more attention.

> Then it was proposed that we might as well use the go script all the time.
> And the result is what you can see now:
> https://codereview.qt-project.org/c/qt/qtbase/+/319071  Nobody wants to
> edit such a long changelog, instead they are just complaining that it’s a
> mess.  I was able to deal with this in qtdeclarative; I don’t mind the
> mess, because it means I get all the information I need in the editor I’m
> using, and I take it for granted that the changes file needs manual editing
> anyway.  But in qtbase it’s a lot of changes, and it will be a lot, each
> time.  Some people say if the author didn’t write a ChangeLog, tough luck:
> the change will not be mentioned.

6.0 is a very special case. For other releases, especially point releases, I
can see the value.

> We could also make the sanity bot complain 

[Development] Nominating Christian Ehrlicher for Approver

[Richard Gustavsen]

Hi,

I'd like to nominate Christian Ehrlicher for approver rights.

He has done a lot of work in Qt, especially Widgets and Item Views, with more 
than 150 patches being merged during the last year.

He has also been equally active in Jira, verifying bug reports, identifying 
duplicates, etc.

His work:
https://codereview.qt-project.org/#/q/owner:%22Christian+Ehrlicher%22,n,z

His reviews:
https://codereview.qt-project.org/#/q/reviewer:%22Christian+Ehrlicher%22,n,z

Br,
Richard Moe Gustavsen

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

Re: [Development] Un-inlining members allowed?

[Richard Gustavsen]

Even if it's binary compatible, it sounds fragile. If the inlined function is 
e.g accessing symbols from the private class, someone might later come along 
and remove those symbols if they appear not to be used from anywhere, 
unknowingly of the fact that some apps still do through an old inlined version.


-Richard


Fra: Development  
på vegne av Edward Welbourne 
Sendt: mandag 22. oktober 2018 11.52.52
Til: Christian Ehrlicher
Kopi: development@qt-project.org; al...@qt-project.org; Thiago Macieira
Emne: Re: [Development] Un-inlining members allowed?

On Sonntag, 21. Oktober 2018 20:07:38 CEST Christian Ehrlicher wrote:
>>> one more question - is it ok to un-inline a function? For example I
>>> want to move QListWidgetItem::isSelected() to the cpp file so I can
>>> properly mark QListWidget::isItemSelected() as deprecated but I'm
>>> unsure if this is allowed.

Please be sure to summarise the change in a
[ChangeLog][Potentially Source-Incompatible Changes]
in your commit message; see [QUIP 6]

* [QUIP 6] https://quips-qt-io.herokuapp.com/quip-0006.html

Thiago Macieira (21 October 2018 22:12) replied:
>> De-inlining is binary and source compatible, so long as you accept
>> that the old code that did inline the function continues to do what it
>> used o do.

and (independently)
Allan Sandfeld Jensen (22 October 2018 09:55) replied:
> That should work, though it seems unnecessary. In any case you will
> need to disable the warnings around the code using the deprecated API.

This appears to be an instance of [QUIP 6]'s Examples section saying:

  Issues not listed here should be discussed on the mailing-list and
  then added here.

Unless someone else (e.g. Allan or Thiago) beats me to it (I'm busy with
a 3rd-party review ...), I guess I'll try to summarise the above as
another example; apparently this is in Category A.  If someone else gets
there first, please add me as a reviewer, so I know when to update the
published version.  (hmm ... I think an update may be in order anyway.)

Eddy.
___
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] Consistently flaky test QTabWidget test

[Richard Gustavsen]

tst_QWindow::requestUpdate is also causing problems. Two patches to solve that:


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

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

-Richard




Fra: Development  
på vegne av Frederik Gladhorn 
Sendt: 2. mai 2018 11:09:40
Til: development@qt-project.org
Kopi: Thiago Macieira
Emne: Re: [Development] Consistently flaky test QTabWidget test

On onsdag 2. mai 2018 09.29.18 CEST Thiago Macieira wrote:
> 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11
> yesterday resulted in
>
>  FAIL!  : tst_QTabWidget::paintEventCount() Compared values are not the same
> Actual   (tab2->count): 2
> Expected (1)  : 1
> Loc: [tst_qtabwidget.cpp(573)]
> [on macOS 10.12]
>
> This test *is* flaky because it succeeded in one of the retries, but
> apparently failed the other 16 runs.
>
> Can someone take a look?

For anyone investigating, we have a bit of support in analyzing:
https://testresults.qt.io/grafana/d/9/coin-single-test-details?
orgId=1&var-project=qt%2Fqtbase&var-testcase=tests%2Fauto%2Fwidgets%2Fwidgets
%2Fqtabwidget&var-testfunction=All&var-branch=5.11&var-branch=dev&var-
inter=24h

I hope that helps (it pretty clearly shows that it's been a recent
regression). Thanks Kari for taking care of it :)
This one seems already under control, but generally, let's base things on data
if we can.

This should give an overview over flaky tests in general:
https://testresults.qt.io/grafana/d/7/coin-flaky-tests

Cheers,
Frederik



___
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] Consistently flaky test QTabWidget test

[Richard Gustavsen]

I'll take a look!


-Richard


Fra: Development  
på vegne av Thiago Macieira 
Sendt: 2. mai 2018 09:46:40
Til: development@qt-project.org
Emne: Re: [Development] Consistently flaky test QTabWidget test

On Wednesday, 2 May 2018 00:29:18 PDT Thiago Macieira wrote:
> 8 out of 8 integrations attempted in both qtbase/dev and qtbase/5.11
> yesterday resulted in

Make that 9 of 9.

I'll stop trying to stage anything in qtbase until further notice.

--
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] Repository request: MaterialWidgets

[Richard Gustavsen]

30.10.2017, 17:18, "iman ahmadvand" :
> Well.
> If it's OK to add new classes then we can create our classes And do the style 
> related things in private part until Qt6 release, on that time we can move 
> our changes to QStyle API.


Adding new and missing controls into QtWidgets, like QSwitch, is very welcome. 
I would prefer adding new widgets rather than changing the API of the existing 
ones (with ifdefs etc), unless you only need to _add_ some functions. If two 
widgets are conceptually different (e.g a QSwitch is not really a QCheckBox, or 
a "discrete slider" is not really a QSlider), they probably deserve to be 
separate widgets. But, those widgets need to conform to the current styling 
API. You cannot undermine that, and just hard-code the style in the private 
parts of the new widgets (even if QStyle wasn't really written with animations 
and transitions in mind). But, like already mentioned earlier in the thread, 
you can (and will have to) add new enums to QStyle that backs the new widgets, 
and provide a default style implementation for them (in e.g QCommonStyle) that 
will be picked up as last resort on all platforms.


If you think that your new widget set /style cannot conform to this, then it 
should probably be shipped outside Qt5.


-Richard


Fra: Development  
på vegne av Konstantin Tokarev 
Sendt: 30. oktober 2017 15:21:22
Til: iman ahmadvand; Qt development mailing list
Emne: Re: [Development] Repository request: MaterialWidgets



30.10.2017, 17:18, "iman ahmadvand" :
> Well.
> If it's OK to add new classes then we can create our classes And do the style 
> related things in private part until Qt6 release, on that time we can move 
> our changes to QStyle API.
> And also in this way the application setting will go away.
> in result:
> 1.We have our new widgets
> 2.We have overcame qstyle api changes
>
> On Mon, Oct 30, 2017 at 5:03 PM, Oswald Buddenhagen 
>  wrote:
>> On Mon, Oct 30, 2017 at 04:34:25PM +0330, iman ahmadvand wrote:
>>>I was thinking of something like this to achieve:
>>>QApplication::setStyle("material");
>>>
>>>Which bring completely new styled and animated appearance.
>>>That would be nice AND Qt way though.
>>>But we've some new widgets beside the existing widgets, for
>>>example: [...]
>>>
>>>Which requires changes in QStyle enumerators.
>>>The two build step was a good option but what about these new widgets ?
>>>unfortunately it seems there is no way to porting this to Qt.
>>>
>> adding entirely new widgets (classes) can be done any time.
>
> But How? if it's not going to be a module ?

Just add new widgets to QtWidgets module.

>
>> the only challenge is that they may need new qstyle primitives, which
>> may then need custom implementations in the other styles as well. but i
>> guess "this widget doesn't look well unless you use the material style"
>> might be an acceptable policy.
>>
>> ___
>> 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


--
Regards,
Konstantin
___
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] Widgets maintainers

[Richard Gustavsen]

Thanks Frederik! A short introduction to myself: My name is Richard, I started 
at Trolltech in 2006, which means that I've been working with Qt for more than 
ten years. Most of that time I've been looking into issues on macOS, but after 
the Nokia era, I became a part of the team implementing and maintaining the iOS 
port. Either way, fixing and maintaining widgets has always been a reoccurring 
exercise, and I look forward to taking over the responsibility as the 
maintainer.


-Richard


Fra: Frederik Gladhorn
Sendt: 7. juli 2017 13:03:49
Til: development@qt-project.org
Kopi: Marc Mutz; Richard Gustavsen; Gabriel de Dietrich; 
andreas.aardal.hans...@gmail.com; Jan-Arve Sæther; Eskil Abrahamsen Blomfeldt
Emne: Re: [Development] Widgets maintainers

Hello all, hello Marc,

First of all, thank you very much for taking care of the widgets module and
working to get bugs under control.

We've been talking inside The Qt Company about the widgets module a lot
lately, since we do see it as a very important part of Qt, which doesn't
receive as much marketing and highlighting as it deserves. For traditional
UIs, widgets are certainly a viable and good building block.

While we don't anticipate huge changes in the module, we will keep on updating
the styles where it makes sense and take bugs serious. Since it's also a big
chunk of a module, we'd like to propse a team of maintainers, to make it
easier on everyone.

Our proposal is:
Richard Gustavsen as overall maintainer
Gabriel de Dietrich for styles
Jan-Arve Sæther for layouts
Eskil Abrahamsen-Blomfeldt for all text related things
Andreas Aardal Hanssen for graphicsview

Item Views is open and would fall to Richard for now, but if someone is
interested in helping out more with it, that's certainly appreciated.

Cheers,
Frederik


On fredag 7. juli 2017 12.20.19 CEST Marc Mutz wrote:
> Hi all,
>
> KDAB is handing back widgets maintenance, which means that I'm stepping
> down as widgets maintainer. The focus of KDAB contributions to Qt is
> clearly elsewhere these days (Qt3D, Core, tooling), and the module
> deserves more focus than it has seen lately.
>
> To this end, Lars has assembled a team(!) of proposed widgets
> (sub)maintainers that we as KDAB and I personally fully support as
> successors.
>
> In Lars' absence, I'll leave it to Frederik to introduce them to you in
> detail (as if introduction was needed...).
>
> Thanks,
> Marc
>
> ___
> 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