Re: [Development] Nominating Andrei Golubev as Approver
+1 Best regards, Timur. From: Development on behalf of Edward Welbourne Sent: Thursday, March 18, 2021 3:00 PM To: development Subject: [Development] Nominating Andrei Golubev as Approver Hi all, I'd like to nominate Andrei Golubev as an Approver. He has been doing sterling work reviewing changes for the last year. Here's a list of what he's reviewed https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io and his own changes https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io Full disclosure: although I've not worked from it since he joined, we nominally share an office, 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] Nominating Andrei Golubev as Approver
+1 And I might add, he also makes an excellent job with documentation, including coming up with novel ideas for improvements. Much appreciated! Disclaimer: We’ve had beers once, in Oslo. //! Paul > On 18 Mar 2021, at 15:00, Edward Welbourne wrote: > > Hi all, > > I'd like to nominate Andrei Golubev as an Approver. > He has been doing sterling work reviewing changes for the last year. > Here's a list of what he's reviewed > https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io > and his own changes > https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io > > Full disclosure: although I've not worked from it since he joined, we > nominally share an office, > > 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] A face for the Qt Project
> Dear community, > > The Qt Project is a huge effort from many people, and for the same > reason, it's quite interesting to (1) Learn how to contribute and be > part of it, and (2) Analyze the interactions of the many > Qt modules. > > For people new to the project, contributing to Qt might be challenging, > but I'm certain we all agree that being clear, and provide all the > information in one place is crucial to at least enable them to do > the first step. > > On the other hand, if you have been around for a while, > you know that Thiago's blog has a good set of statistics [1] > that helps a lot to get an overview of the current state of the project. > > With these two ideas in mind, it makes sense to use qt-project.org > as the face of the Qt Project, highlighting the two previous points > I described. > > I would like to ask the community, if we are in favor of using > the proposal from [2] as qt-project.org. > > The goal will be to have this repository under our open governance, > so anyone will be able to suggest changes, as we do in Qt. > > The idea will be not to duplicate content from https://qt.io, > but focus on aspects related to contributing to the project. I really like the idea and I think your implementation is very good at giving an overview of the community and how to get involved. So +1 from me :) ># About the implementation > > The page you can see on [2] was generated with Dash, > a Python module based on Plotly [3], and the data comes from the > meta qt5.git repository, including also the qt-creator and pyside-setup > ones. > > The text you see on the left-side cards, comes from local Markdown > files, so also it would be straightforward to edit them. > > I will upload the code if the community agrees to go forward, > so then we could be able to create a public repository to keep > this code. I didn't knew about Dash, this looks like a very nice python tool to work with. When you release the code, I could try to see if I could implement something similar for KDE. Cheers, -- Carl Schwan https://carlschwan.eu KDE developer and maintainer of the KDE websites > > Cheers > > > [1] https://www.macieira.org/blog/qt-stats/ > [2] https://qt-project-org.herokuapp.com > [3] https://dash.plotly.com/ > > -- > Dr. Cristián Maureira-Fredes > R&D Manager > > The Qt Company GmbH > Erich-Thilo-Str. 10 > D-12489 Berlin > > Geschäftsführer: Mika Pälsi, > Juha Varelius, Jouni Lintunen > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] A face for the Qt Project
Dear community, The Qt Project is a huge effort from many people, and for the same reason, it's quite interesting to (1) Learn how to contribute and be part of it, and (2) Analyze the interactions of the many Qt modules. For people new to the project, contributing to Qt might be challenging, but I'm certain we all agree that being clear, and provide all the information in one place is crucial to at least enable them to do the first step. On the other hand, if you have been around for a while, you know that Thiago's blog has a good set of statistics [1] that helps a lot to get an overview of the current state of the project. With these two ideas in mind, it makes sense to use qt-project.org as the face of the Qt Project, highlighting the two previous points I described. I would like to ask the community, if we are in favor of using the proposal from [2] as qt-project.org. The goal will be to have this repository under our open governance, so anyone will be able to suggest changes, as we do in Qt. The idea will be not to duplicate content from https://qt.io, but focus on aspects related to contributing to the project. # About the implementation The page you can see on [2] was generated with Dash, a Python module based on Plotly [3], and the data comes from the meta qt5.git repository, including also the qt-creator and pyside-setup ones. The text you see on the left-side cards, comes from local Markdown files, so also it would be straightforward to edit them. I will upload the code if the community agrees to go forward, so then we could be able to create a public repository to keep this code. Cheers [1] https://www.macieira.org/blog/qt-stats/ [2] https://qt-project-org.herokuapp.com [3] https://dash.plotly.com/ -- Dr. Cristián Maureira-Fredes R&D Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Andrei Golubev as Approver
+1 Disclosure: I've only collaborated remotely with Andrei, however it was always a pleasure. From: Development on behalf of Edward Welbourne Sent: Thursday, March 18, 2021 3:00 PM To: development Subject: [Development] Nominating Andrei Golubev as Approver Hi all, I'd like to nominate Andrei Golubev as an Approver. He has been doing sterling work reviewing changes for the last year. Here's a list of what he's reviewed https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io and his own changes https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io Full disclosure: although I've not worked from it since he joined, we nominally share an office, 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] Nominating Andrei Golubev as Approver
> On 2021 Mar 18, at 15:00, Edward Welbourne wrote: > > I'd like to nominate Andrei Golubev as an Approver. +1 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QHash references stability in Qt6
Yes, as described in https://doc.qt.io/qt-6/qtcore-changes-qt6.html#stability-of-references, Qt 6's QHash does indeed intentionally no longer promise reference stability when it grows or elements are removed. -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Von: Development im Auftrag von Иван Комиссаров Gesendet: Donnerstag, 18. März 2021 16:04 An: Qt development mailing list Betreff: [Development] QHash references stability in Qt6 Hello, when porting Qbs to Qt6 I’ve noticed a lot of bugs/crashes when using QHash. With Qt5 that was never a problem and simple change QHash -> std::unordered_map fixes those. From what I understood all affected places rely on the fact that QHash in Qt5 (as well as std::unordered_map) guarantees that references are not invalidated even in case of re-hashing. So I am wondering if this is the case with the new QHash implementation or is it just a bug (I could not find anything related on the bug tracker though) Ivan ___ 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] QHash references stability in Qt6
Hello, when porting Qbs to Qt6 I’ve noticed a lot of bugs/crashes when using QHash. With Qt5 that was never a problem and simple change QHash -> std::unordered_map fixes those. From what I understood all affected places rely on the fact that QHash in Qt5 (as well as std::unordered_map) guarantees that references are not invalidated even in case of re-hashing. So I am wondering if this is the case with the new QHash implementation or is it just a bug (I could not find anything related on the bug tracker though) Ivan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Andrei Golubev as Approver
+1 Disclousre: We're on the same team. From: Development on behalf of Edward Welbourne Sent: Thursday, March 18, 2021 3:00 PM To: development Subject: [Development] Nominating Andrei Golubev as Approver Hi all, I'd like to nominate Andrei Golubev as an Approver. He has been doing sterling work reviewing changes for the last year. Here's a list of what he's reviewed https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io and his own changes https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io Full disclosure: although I've not worked from it since he joined, we nominally share an office, 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] Nominating Andrei Golubev as Approver
> On 18 Mar 2021, at 15:00, Edward Welbourne wrote: > > Hi all, > > I'd like to nominate Andrei Golubev as an Approver. > He has been doing sterling work reviewing changes for the last year. > Here's a list of what he's reviewed > https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io > and his own changes > https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io > > Full disclosure: although I've not worked from it since he joined, we > nominally share an office, > > Eddy. +1 Full disclosure: my office would in normal times be across the hallway from both Andrei’s and Eddy’s. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Andrei Golubev as Approver
I'd like to nominate Andrei Golubev as an Approver. He has been doing sterling work reviewing changes for the last year. Here's a list of what he's reviewed https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io and his own changes https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io +1 Andrei has been doing a great job indeed. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Andrei Golubev as Approver
+1 Disclosure: We're working on the same team. -- Fabian Kosmale Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin fabian.kosm...@qt.io +49 1638686070 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Von: Development im Auftrag von Edward Welbourne Gesendet: Donnerstag, 18. März 2021 15:00 An: development Betreff: [Development] Nominating Andrei Golubev as Approver Hi all, I'd like to nominate Andrei Golubev as an Approver. He has been doing sterling work reviewing changes for the last year. Here's a list of what he's reviewed https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io and his own changes https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io Full disclosure: although I've not worked from it since he joined, we nominally share an office, 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
[Development] Nominating Andrei Golubev as Approver
Hi all, I'd like to nominate Andrei Golubev as an Approver. He has been doing sterling work reviewing changes for the last year. Here's a list of what he's reviewed https://codereview.qt-project.org/q/reviewer:andrei.golubev%2540qt.io and his own changes https://codereview.qt-project.org/q/owner:andrei.golubev%2540qt.io Full disclosure: although I've not worked from it since he joined, we nominally share an office, Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] [Announce] Qt Design Studio 2.1 Beta1 released
Hi all, We released Qt Design Studio 2.1 Beta1 today, see https://www.qt.io/blog/qt-design-studio-2.1-beta-released Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Announce mailing list annou...@qt-project.org https://lists.qt-project.org/listinfo/announce ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Add QTBUG title to new release changelog
On 05-Mar-21 10:46 AM, Roland Winklmeier wrote: Good morning, I was curious to see what changed in Qt 6.0.2 release and found a list of fixed QTBUGS: [qtbase] 443ce5d073 Fixes: QTBUG-89578 b61275ee72 Fixes: QTBUG-90042 e255716291 Fixes: QTBUG-74088 The QTBUG number itself does not tell me much, hence it is very hard to predict if anything relevant is in that release affecting my projects. How hard would it be to change it to [qtbase] 443ce5d073 Fixes: QTBUG-89578 QLineEdit Cursor show white line when use property of setInputMask b61275ee72 Fixes: QTBUG-90042 QIcon not using Hi DPI pixmap version e255716291 Fixes: QTBUG-74088 Menu Bar Items Disabled When QMainWindow Has Window Modal Child and Another Window Made Active That would be much easier to read. I very much second this request. Also, most of the bugs mentioned as fixed in the 5.15.3 release notes don't have the respective Fix Version set in Jira (or any Fix Version, for that matter). That means commercial customers must now cross-reference each and every issue ID in the release note with the ones they reported/that affect them to see if they have been fixed. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Pointer handlers: transparent or block? was Re: QEvent::accept() vs. the newer event delivery algorithms in Qt Quick; remaining API issues; etc.
Hi Shawn, honestly (as a user/client of the Qt SDK) i faced lots of issues with pointer handlers (mostly because they not integrate MouseAreas) and seen from the outside it's just another split in the input API. I.e https://bugreports.qt.io/browse/QTBUG-79238 The QtQuick 1 method of handling events even if inefficient was somehow easy. Basically we had only event bubbling. Once upon a time i pushed this codereview for you https://codereview.qt-project.org/c/qt/qtdeclarative/+/163503 where i basically made a proof of concept of adding event event Tunneling for key events. I took the idea from what WPF did: 1) Event tunneling (events are delivered from root to target) 2) Event bubbling (events are delived from target to root) I think that the last piece was just improving the event bubbling and let events bubble even if accepted if there's someone interested to receive all the events. Il giorno mar 16 mar 2021 alle ore 10:33 Shawn Rutledge ha scritto: > > > On 2020 Oct 8, at 13:26, Shawn Rutledge wrote: > > If you subclass QQuickItem and start handling events, it becomes clear that > QEvent::accept() has always meant two things in legacy Qt Quick: 1) stop > propagation and 2) grab the mouse. > > > …etc… and there weren’t a lot of replies to that thread. At the time, bigger > changes were possible; now, Qt 6.0 is released (and then some), and we always > end up making only incremental changes anyway, with old behavior held in > place by autotests and tradition and shortage of time. > > The next increment seems to be this: I think all pointer handlers > (TapHandler, DragHandler, HoverHandler, WheelHandler, PointHandler) should > share a common boolean flag to tell whether they accept or reject events. > What we have so far is that TapHandler has gesturePolicy, which was meant to > be intuitive for designers: describe how it behaves in an observable way, > despite the fact that under the covers it affects the accept flag, which > everyone with Qt experience knows about, but designers can’t be expected to > know. Based on bug reports we’ve received, programmers still want to control > the state of the accept flag to control whether further propagation is > allowed. And I want that to be declarative, not requiring you to write a JS > if statement to decide. > > What should we call the flag then? I think our best candidates so far are > “blocking”, “transparent” and “propagates". “Blocking” I think is pretty > clear (as long as users don’t confuse it with the idea of blocking execution, > as modal dialogs do); “transparent” maybe has a good meaning if you > understand that it concerns only event delivery, not appearance, and it goes > with things like Qt::WindowTransparentForInput; on the other hand, it does > not mean that the handler fails to react at all, but that it lets the event > keep propagating. And speaking of propagating: I’ve never liked the meaning > we give to that word, because it makes me think of propagating plants: i.e. > copying. In fact we try to avoid copying events where possible; and even if > we do it, it’s not the handler’s job to copy the event and send it to another > target; so maybe let’s not imply that… even though traditional Qt programmers > already know what event propagation is. > > So what do you think? do you have any preference there? > > More background, how this came up again: Richard has been refactoring the > delivery of hover events in Qt Quick. It’s something I hadn’t gotten around > to yet: I’ve been torn for a while on whether we should continue with > frame-synchronous hover events or come up with something else. From one > perspective, the reason we have hover events is to inform all the items and > handlers that care, that the mouse has moved; so the naive implementation in > early versions of Qt 5 was just sending the actual mouse moves in the form of > QHoverEvents, which made me wonder why do we have those: why isn’t a > QMouseEvent good enough? But then multiple users wrote bugs complaining > about the case when the mouse does not move, but items are being animated, > and they happen to go underneath the current cursor position. (Why is it so > hard for items to just observe the mouse? The trouble is the sheer number of > them that could want to do that, in general. So we use events. Could we > possibly invent something better?) Robin fixed this set of bugs by sending > an artificial hover event once per frame, before the scene graph gets updated > prior to rendering. It sounds expensive, but we also have a flag > QQuickItemPrivate::subtreeHoverEnabled, which is false unless the item or one > of its children actually needs hover events, which it expresses by setting > hoverEnabled to true. So if you are worried about the cost of these events, > make sure your UI design allows us to rule out most or all of the item > subtrees while we are delivering the hover events, so that it can stop short, >
