Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer

2023-05-04 Thread Gatis Paeglis via Development 
+1

From: Development  on behalf of Giuseppe 
D'Angelo via Development 
Sent: Thursday, May 4, 2023 1:03 PM
To: development@qt-project.org 
Subject: Re: [Development] Nominating Edward Welbourne as QLocale / date/time 
maintainer

Il 04/05/23 12:10, Marc Mutz via Development ha scritto:
> Hi,
>
> I'd like to nominate Eddy as the maintainer for the QLocale and
> src/corelib/time QtCore subsystems. Eddy is filling that role de-facto
> already; making it de-jure sounds only logical.
>
> I asked, and he'd be on board, if we'd have him.
>
> Anyone else in favour? (I'm not sure I have a vote, actually...)

I'm just an approver so I'm not sure either -- but in case it's a very
convinced +1.

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Nominating Mårten Nordheim and Timur Pocheptsov as new co-maintainers of Qt WebSocket

2022-11-30 Thread Gatis Paeglis via Development 
+1
+1

From: Development  on behalf of Lorn Potter 

Sent: Wednesday, November 30, 2022 9:40 AM
To: development@qt-project.org 
Subject: Re: [Development] Nominating Mårten Nordheim and Timur Pocheptsov as 
new co-maintainers of Qt WebSocket

+1 !!

On 29/11/2022 11:55 pm, Volker Hilsheimer via Development wrote:
> Hi,
>
>
> Kurt Pattyn is currently listed as the Maintainer fo Qt WebSocket. However, 
> he has not responded to emails I sent him over the last few months. In the 
> middle of October I informed him that I will remove him as maintainer and 
> nominate someone else unless I get a response. I cc’ed Mårten Nordheim in 
> that email. Since I have not received any answer to that email either, I am 
> now going to remove Kurt from the list of maintainers.
>
> And I’d like to nominate Mårten Nordheim and Timur Pocheptsov as 
> co-maintainers. I’ve confirmed with them, and they would be ok with extending 
> their existing co-maintainership of Qt Network to that module as well.
>
>
> 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] Nominating David and Eskil as Qt Wayland maintainers

2022-08-24 Thread Gatis Paeglis 
+1 for both

From: Development  on behalf of Giuseppe 
D'Angelo via Development 
Sent: Wednesday, August 24, 2022 9:27 PM
To: development@qt-project.org 
Subject: Re: [Development] Nominating David and Eskil as Qt Wayland maintainers

Il 24/08/22 13:24, Thiago Macieira ha scritto:
> +11 (because it's two people)

+1x2

(Jokes aside: +1 to these nominations).


Thanks,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] 回复: QPushButton: drag and drop

2022-06-06 Thread Gatis Paeglis 
It is not just Drag that is affected by this issue. The fix should also 
consider my notes from https://bugreports.qt.io/browse/QTBUG-69716


From: Development  on behalf of Zhang JiDe 

Sent: Monday, June 6, 2022 10:49 AM
To: Volker Hilsheimer ; Giuseppe D'Angelo 
; development@qt-project.org 

Subject: [Development] 回复: QPushButton: drag and drop

I agree that we should fix this, but it's not as simple as passing the 
mouseReleaseEvent to the QPushButton, but we should make sure that for a 
QWidget, whatever happens, the mouse press and release are paired, always 
notify the mouse release to the QWidget of pressed target. If adding a new 
event to it will make things complicated, I suggest adding a new item for 
MouseEventSource, such as: MouseEventSynthesizedByUngrab, which is like to 
XCB_NOTIFY_MODE_UNGRAB, judge the source of QMouseEvent in QPushButton, if it 
is MouseEventSynthesizedByUngrab, do not trigger clieck, and update the UI.

发件人: Development  代表 Volker Hilsheimer 

发送时间: 2022年6月4日 11:44
收件人: Giuseppe D'Angelo ; development@qt-project.org 

主题: Re: [Development] QPushButton: drag and drop

> On 4 Jun 2022, at 00:41, Giuseppe D'Angelo via Development 
>  wrote:
>
> Il 04/06/22 00:39, Shawn Rutledge ha scritto:
>> This might resemble the case when a TouchCancel event is sent: it means the 
>> receiver should be un-pressed, undo whatever was done on press, and don’t 
>> react otherwise (e.g. a Button does not get clicked, it’s just not pressed 
>> anymore).
>
> This is an interesting idea (either a new event or a flag on the release 
> event to know that "something else" has happened in the meanwhile, so it 
> shouldn't act as if it was a real release).


Yes, adding a new “cancel” event that informs a widget that it has lost the 
mouse grab could be an idea. We have QEvent::WindowBlocked/WindowUnblocked for 
instance to inform a window that it is about to get blocked/unblocked by a 
modal dialog.

I don’t think we deliver those events when the modal drag’n’drop starts (since 
it’s not a modal dialog blocking the window, which is the specific 
documentation of these event types). And since usually (at least when I refer 
to the widgets we have in Qt) the widget itself is responsible for starting the 
modal drag’n’drop, it knows exactly when the operation starts and ends. For 
that usage pattern, a new event adds no new information.

Adding a new event type allows us to dispatch drag-start/end information to the 
source widget (or all widgets? the entire window hierarchy?) without risking 
that we execute existing event handlers like mouseReleaseEvent. But then for 
Laszlo’s problem, he’d have to implement a new event handler just to call 
setDown(false), when he can do that right now already in the existing event 
handler form where he calls QDrag::exec.

Perhaps it’s useful in situations where an application calls QDrag::exec (or 
QDialog::exec) in response to a signal (such as QAbstractButton::pressed), 
instead of overriding event handlers. But then, would we expect that all 
widgets handle that event to cancel their interaction and reset their state 
(there is no sensible default implementation)? That would add a lot of state 
handling logic, to every widget class, for many of the signals they emit, just 
to support what seems to me like an extremely rare use case.

Volker

___
Development mailing list
Development@qt-project.org
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.qt-project.org%2Flistinfo%2Fdevelopmentdata=05%7C01%7C%7C6030caf001bc42d9ee0808da461fe54a%7C84df9e7fe9f640afb435%7C1%7C0%7C637899400048996725%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2FeoHpdNSH2T3DV2PrXZmMpXzA5kxPzXzMta1J6BZA3I%3Dreserved=0
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] XCB platform plugin maintainer change

2022-02-01 Thread Gatis Paeglis 
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

Re: [Development] QTestlib: how not to test mouseMoveEvent handling

2019-07-09 Thread Gatis Paeglis 

> AFAIK Gatis  is working on this (see 
> https://bugreports.qt.io/browse/QTBUG-69414 ). There is a magic define

I have currently postponed that work. The goal is to move all auto tests that 
rely on mouse to DEFINES += QTEST_QPA_MOUSE_HANDLING. Here is an example of 
before vs after: https://codereview.qt-project.org/c/qt/qtbase/+/210028 
Updating tests in qtbase can be done right now, so any help is welcome. For 
consistency, Qt Quick tests should utilize the QTEST_QPA_MOUSE_HANDLING code 
path as well. Cleaning up Qt Quick tests first requires resolving 
https://bugreports.qt.io/browse/QTBUG-69419 . Some WIP patches for Qt Quick 
Test lib are in https://bugreports.qt.io/browse/QTBUG-69415 , but it might be 
wiser to rewrite it in c++ https://bugreports.qt.io/browse/QTBUG-64837

I think it is worth spending time on this, instead of fighting with flaky or 
hard to read auto tests in future.







From: Development  on behalf of Friedemann 
Kleint 
Sent: Tuesday, July 9, 2019 8:33 AM
To: development@qt-project.org
Subject: Re: [Development] QTestlib: how not to test mouseMoveEvent handling

Hi,

AFAIK Gatis  is working this (see
https://bugreports.qt.io/browse/QTBUG-69414 ). There is a magic define

widgets/widgets/qcombobox/qcombobox.pro:4:DEFINES +=
QTEST_QPA_MOUSE_HANDLING
widgets/widgets/qmenu/qmenu.pro:9:DEFINES += QTEST_QPA_MOUSE_HANDLING

which apparently changes behavior. Alternatively, the overloads of
QTest::mouse*() that take a QWindow * can be used, which should act more
sane. This might require some coordinate mapping, though.

Friedemann

--
Friedemann Kleint
The Qt Company GmbH

___
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 Mikhail Svetkin for Approver status

2019-05-16 Thread Gatis Paeglis 
+1, long-overdue 

From: Development  on behalf of Tor Arne 
Vestbø 
Sent: Thursday, May 16, 2019 6:14 PM
To: Volker Hilsheimer
Cc: Qt development mailing list
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status

+2

> On 16 May 2019, at 16:45, Volker Hilsheimer  wrote:
>
> Hi,
>
>
> I’d like to nominate Mikhail Svetkin for Approver status. He’s been an active 
> contributor since March 2018, working on C++11’ifying Qt, contributing to 
> core QPA, network code, the QtHttpServer labs project, and right now the 
> integration of changes for RTEMS into qtbase.
>
> He’s also been actively helping others with reviews, and does so in a 
> professional, respectful, and constructive way that complies with the Code of 
> Conduct.
>
> Here’s the list of changes under his current Gerrit account:
>
>  
> https://codereview.qt-project.org/#/q/owner:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,z
>
> and a list of changes where he has been reviewing:
>
>  
> https://codereview.qt-project.org/#/q/reviewer:%22Mikhail+Svetkin+%253Cmikhail.svetkin%2540qt.io%253E%22,n,004c7463725f
>
>
> Disclaimer: I’m sitting a few offices away from Mikhail in The Qt Company 
> office in Oslo, and am also his line manager.
>
>
> Cheers,
> 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] Nominating Ryan Chu for Approvership

2019-05-15 Thread Gatis Paeglis 
+1

From: Development  on behalf of Martin 
Smith 
Sent: Wednesday, May 15, 2019 1:51 PM
To: Topi Reiniö; Paul Wicking; development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership

+1 from Martin


From: Development  on behalf of Topi Reiniö 

Sent: Wednesday, May 15, 2019 1:39 PM
To: Paul Wicking; development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership

A solid +1 from me.

\topi

From: Development  on behalf of Paul 
Wicking 
Sent: Wednesday, May 15, 2019 1:11 PM
To: development@qt-project.org
Subject: [Development] Nominating Ryan Chu for Approvership

I'd like to nominate Ryan Chu for approvership. He's been an active
contributor since January 2018, working mostly on the Docker-based test
server and network-related code. He is also an active reviewer, and his
manner of communication upholds the values as set forth by the Qt Code
of Conduct.

I know Ryan as a humble and honest person. I trust he will treat this
role with the utmost respect and care, as is required.


If you're curious, here's a list of his changes:

https://codereview.qt-project.org/#/q/owner:%22Ryan+Chu%22,n,z

and a list of changes he's on as a reviewer:

https://codereview.qt-project.org/#/q/reviewer:%22Ryan+Chu%22,n,z


Disclaimer: he sits 4 offices down the hall from me, and we're both on
the Core & Network team.


--
Paul Wicking
Documentation Engineer

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
paul.wick...@qt.io
+47 90 500 666
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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A monologue about platforms in the Qt world

2019-05-02 Thread Gatis Paeglis 
> Does it mean that the binaries we distribute should work on that?

I have been maintaining XCB plugin and the bundled xkbcommon and xcb 3rd party 
sources based on the assumption that an answer to this question is - yes.



From: Development  on behalf of Tony 
Sarajärvi 
Sent: Thursday, May 2, 2019 1:48 PM
To: development@qt-project.org
Subject: [Development] A monologue about platforms in the Qt world

Hi all!

I'd like to open up a discussion about the platforms we "support".  This is 
like listening to a broken record, but once again it’s about adding or removing 
platforms in the CI, what’s supported and what we do packages with. But, this 
time I'm going to approach you a bit differently. Instead of simple questions, 
I'm going to bombard you with boring details. You need to know what exactly it 
is we are asking you about after all ;)


What's a  supported platform?
---
It means that The Qt Company gives you support if you stumble upon a problem 
with that distro and the Qt release promised to work on that. But what’s 
unclear is what it actually means that Qt should work on that platform. Does it 
mean that the binaries we distribute should work on that? Or does it mean that 
Qt builds on it if you take the sources and compile them yourself? This is one 
of the most asked questions we’ve had here. A good example is openSUSE 42.3 
where examples don’t compile if you take our binary release and try to work 
with that. But if you would compile Qt on that distro, then it would work. (see 
https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the 
details). What do you think it means? Is one or the other answers wrong here?


What a platform in the CI?
---
Ok this one is pretty clear. A platform in the CI is a platform we see fit to 
be tested for a specific branch. The important thing here is to realize that 
this is not the same thing as us supporting something. For obvious reasons it 
would be great if everything we supported was tested here, but because of the 
vast amount of combinations, we can't do that. We simply try to cover the most 
common cases here. And that's always up for debate! If you see that something 
is worth testing in the CI, create a ticket about it and justify why your 
configuration should be in there. This doesn't just mean adding platforms or 
compilers. It also means configurations like -no-gui or building examples for 
Android or something.


What's a packaging configuration and why don't Linux binaries work as promised?
---
Some configurations in the CI are used to actually create the binaries which we 
deliver as Qt binaries via the installer. They can be recognized by the 
"Packaging" keyword in the following files:
https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/default.txt
https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qt5.txt
For most platforms this makes a lot of sense and they don't cause problems 
anywhere, but our Linux binaries are a different thing entirely. Where Windows 
and macOS binaries work here and there, Linux distros tend to be more strict to 
what works and where. The library dependencies make things not work backwards 
as well as on Windows and macOS. Which brings us to the problem mentioned 
earlier at supported platforms. Binaries created with RHEL 7.4 don't tend to 
work on openSUSE 42.3, but they do compile.

When selecting this operating system which we created packages with, we tend to 
select a reasonable new one, most preferably a stable one, with a good set of 
old libraries so that the backwards compatibility is good. Take RHEL 7 for 
example. RHEL 7.0 was release in June 2014. In July 2017 we got the 7.4 update 
which we began using. RHEL 7.4 is still compatible with 7.0, which means that 
our binaries are created with a new distro that creates binaries compatible 
with distros created in 2014. At least sort of.

But the distro we use, isn't always the out-of-the-box distro. When we used 
RHEL 6.6 for example, we replaced the bluez (for Bluetooth) libraries with own 
ones so that Qt binaries would have the features enabled that were wished. That 
actually means that we didn't use RHEL 6.6 to create the releases, but in fact 
a custom distro based on RHEL 6.6. (off on a tangent here: Qt 5.6 sources 
actually don't even compile on an out-of-the-box RHEL 6.6 because we now missed 
that during verification (bug created!). And actually by us installing 
devtoolsets provided by RHEL, us installing custom Pythons, extracting own 
libclangs, perhaps build our own openssl from sources, one could actually 
argue, that we don't use RHEL 7.4 either, but our own custom Linux based on 
RHEL 7.4.


Lifespan of distros
---
This is something we should have thought more about, but didn't. Perhaps still 
don't. Let's take Qt 5.12 as a good example here. Qt 5.12.0 was released on the 
6th Dec 2018. It has a promised lifespan to at least the end of 2021. With us 
actually going

Re: [Development] forcing libxkbcommon to be present in the system makes newer Qt unusable on older linux distros

2019-03-05 Thread Gatis Paeglis 
> library doesn't provide another way to build itself.

libxkbcommon changelog for 0.7.2 
https://lists.freedesktop.org/archives/wayland-devel/2017-August/034721.html

"Added a Meson build system as an alternative to existing autotools build 
system. The intent is to remove the autotools build in one of the next 
releases. Please try to convert to it and report any problems."

libxkbcommon changelog for 0.8.3 
https://lists.freedesktop.org/archives/wayland-devel/2019-February/039970.html:

"Build note: We've had a report that the autotools build doesn't work with


the new version of Bison, 3.3. If this happens to you, please switch to
using meson. The autotools build will be removed in libxkbcommon 0.9.0."


Note that 0.9.0 does not exist, so even the current master branch still can be 
built with auto tools.


> Unless I misunderstand something this change hits older linuxes real hard.

Current minimal required version by Qt is 0.5.0 and only really old distros do 
not have it. And to quote the commit message that removed the library from 
bundled sources:

"This library is present on all supported platforms."





From: Development  on behalf of NIkolai 
Marchenko 
Sent: Tuesday, March 5, 2019 3:36 PM
To: Qt development mailing list
Subject: [Development] forcing libxkbcommon to be present in the system makes 
newer Qt unusable on older linux distros


 - [QTBUG-65503] Removed xkbcommon from bundled sources. This library is
   present on all supported platforms. The minimal required version now is
   0.5.0.


The change above makes updating Qt a gargantuan task for Centos 6 at least.

Building xkbcommon there requires meson (which centos 6 doesn't have)

and python 3.5 (same). And the library doesn't provide another way to build 
itself.


Unless I misunderstand something this change hits older linuxes real hard.

Is it really necessary?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Build system for Qt 6

2018-11-01 Thread Gatis Paeglis 
> It’s convenient to quote what adds fuel to the fire of this discussion. Hence 
> my attempt to add water by quoting what I thought it still relevant.


In a real life never add water to a fuel fire. It will cause even more fire 


Gatis.


From: Development  on 
behalf of Simon Hausmann 
Sent: Thursday, November 1, 2018 12:19:11 PM
To: André Pönitz
Cc: development mailing list; q...@qt-project.org
Subject: Re: [Development] Build system for Qt 6

I agree, this is often the case.

I just wanted to emphasize that I think it’s too early to conclude that llvm is 
going to switch to gn based on that email. It’s convenient to quote what adds 
fuel to the fire of this discussion. Hence my attempt to add water by quoting 
what I thought it still relevant.

Simon

> On 1. Nov 2018, at 12:14, André Pönitz  wrote:
>
>> On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote:
>>
>>> From the same email perhaps it's also worth quoting the first paragraph:
>> "
>>
>> first things first: If you're happy with cmake, you can stop reading now.
>> Nobody is proposing that LLVM moves off cmake, and nobody is proposing
>> anything that's causing people using cmake more work.
>> "
>
> Sure, that's how one approaches larger controversial changes, not just
> in software development, but also general politics:
>
> 1. Promise that everything is optional, and existing uses won't change,
> and nobody will be affected unless opted-in. This keeps the initial
> outcry a bay. Optionally, start to belittle opposition as inveterate
> nay-sayers, as there is clearly no reason to oppose something people
> do voluntarily.
>
> 2. Once installed, apply salami tactics by extending the scope of the
> measure, "add value" to the new system, asked for or not, and let the old
> one rot. If needed, little stabs in the back help to speed up the process.
>
> 3. At some time the new system will indeed be better in some setups than
> the old one, and the opt-in gets opt-out. This is also a good time to
> gauge remaining resistance, and either continue with 2 or directly go
> to 4.
>
> 4. Sweep remaining issues under the carpet and declare the old system dead.
>
>
> As I said, that's nothing specific to LLVM and Cmake.
>
> The pattern to message "Nobody has any intention to do X" while planning
> or even already executing X is so widely used that in the presence of
> such a statement it is safer to assume that this is just stage 1 of the
> process above than to accept the statement at face value.
>
> Andre'
>
___
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] Orphan modules

2018-09-13 Thread Gatis Paeglis 
> APIs have modern replacements in Qt.


Not everything can be or should be in cross platform code.


> other ways to do the same?


For some maybe, but it is all about convenience. Some things (e.g. peeking at 
our internal event queue) can be done only if we expose that info, there isn't 
really other ways.


> I could see kwin_x11 needing it, but I really don't see all the other 
> applications doing so.


There actually are other application that need this. Xlib used to provide 
various higher level APIs on top of X11 protocol. XCB, which stands for X11 C 
Binding, is low level API, which does not provide equivalents for all of Xlib 
APIs that some Qt 4 applications, that use native calls, depend on. This is 
where QX11Extras is used to provide some alternatives.


My only concern was that it should not be a separate module. The topic here was 
about orphan modules, everything else (e.g. if any of APIs have become 
redundant) should be discussed elsewhere.


> I was going to say we needed replacement API for it, but I realise the
QX11EmbedContainer is not there. Since people have lived for the last 6 years
without it in Qt 5, it doesn't seem we really need a replacement.


See https://codereview.qt-project.org/#/c/42990/


Gatis Paeglis.



From: Development  on 
behalf of Jean-Michaël Celerier 
Sent: Thursday, September 13, 2018 8:37:57 AM
To: Thiago Macieira
Cc: development
Subject: Re: [Development] Orphan modules

There are quite a bunch of people using it out there : 
https://github.com/search?l=C%2B%2B=QX11Info+NOT+tst_QX11Info+NOT+QT_END_LICENSE=Code


---
Jean-Michaël Celerier
http://www.jcelerier.name


On Thu, Sep 13, 2018 at 1:41 AM Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:
On Wednesday, 12 September 2018 10:09:53 PDT Tor Arne Vestbø wrote:
> If they do, does the list say anything about whether or not those APIs have
> modern replacements in Qt or other ways to do the same?

There's exactly one class in QtX11Extras: QX11Info.
http://doc.qt.io/qt-5/qx11info.html

I could see kwin_x11 needing it, but I really don't see all the other
applications doing so. Do we have a replacement for QX11Info?

--
Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com>
  Software Architect - Intel Open Source Technology Center



___
Development mailing list
Development@qt-project.org<mailto: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] Raising the minimum Core Language to C++14 for Linux/XCB

2018-07-15 Thread Gatis Paeglis 
> Raising the minimum Core Language to C++14 for Linux/XCB


Ok, the title was bit misleading. You want to increase for all regular Linux 
builds.

That would be fine for the task I linked earlier. But

according to http://doc.qt.io/qt-5/supported-platforms.html Red Hat Enterprise 
Linux 6.6 does not have GCC 5.




From: Development  on 
behalf of Gatis Paeglis 
Sent: Sunday, July 15, 2018 12:17:52 PM
To: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] Raising the minimum Core Language to C++14 for 
Linux/XCB


> There has been no reply on this subject. Shall I assume silence is consent and
> we can begin using C++14 constructs in the XCB plugin?


I think I know which patch you are talking about and then my answer is we 
can't. The code that you

are looking at I want to eventually move in some common place (out of XCB) as 
part of [1].


[1] https://bugreports.qt.io/browse/QTBUG-65503


From: Development  on 
behalf of Thiago Macieira 
Sent: Saturday, July 14, 2018 4:23:01 PM
To: development@qt-project.org
Subject: Re: [Development] Raising the minimum Core Language to C++14 for 
Linux/XCB

On Thursday, 5 July 2018 12:53:14 PDT Thiago Macieira wrote:
> On Mac, we kinda already require that. I'm asking to raise the minimum for
> the regular Linux builds to C++14. Specifically, I'm asking for the "auto"
> functions without trailing return type and relaxed constexpr.
>
> Currently, our minimum supported GCC version is 4.7 (on QNX only) and 4.8
> elsewhere. That would raise the minimum on Linux to GCC 5, as per:
>https://gcc.gnu.org/projects/cxx-status.html#cxx14
>
> That's a 3-year-old compiler, four releases out of date, present in the
> main, binary Linux distros since:
>Ubuntu 15.10[2015]
>Fedora 22   [2015]
>Debian 9 (Stretch)  [2017]
>openSUSE Leap 15 [2018]
>
> Note that this does not apply to QNX or Android, so C++14 features would not
> be allowed in cross-platform code.
>
> But we'd be able to use it in the XCB plugin. [Does QNX build that?]

There has been no reply on this subject. Shall I assume silence is consent and
we can begin using C++14 constructs in the XCB plugin?

--
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] Raising the minimum Core Language to C++14 for Linux/XCB

2018-07-15 Thread Gatis Paeglis 
> There has been no reply on this subject. Shall I assume silence is consent and
> we can begin using C++14 constructs in the XCB plugin?


I think I know which patch you are talking about and then my answer is we 
can't. The code that you

are looking at I want to eventually move in some common place (out of XCB) as 
part of [1].


[1] https://bugreports.qt.io/browse/QTBUG-65503


From: Development  on 
behalf of Thiago Macieira 
Sent: Saturday, July 14, 2018 4:23:01 PM
To: development@qt-project.org
Subject: Re: [Development] Raising the minimum Core Language to C++14 for 
Linux/XCB

On Thursday, 5 July 2018 12:53:14 PDT Thiago Macieira wrote:
> On Mac, we kinda already require that. I'm asking to raise the minimum for
> the regular Linux builds to C++14. Specifically, I'm asking for the "auto"
> functions without trailing return type and relaxed constexpr.
>
> Currently, our minimum supported GCC version is 4.7 (on QNX only) and 4.8
> elsewhere. That would raise the minimum on Linux to GCC 5, as per:
>https://gcc.gnu.org/projects/cxx-status.html#cxx14
>
> That's a 3-year-old compiler, four releases out of date, present in the
> main, binary Linux distros since:
>Ubuntu 15.10[2015]
>Fedora 22   [2015]
>Debian 9 (Stretch)  [2017]
>openSUSE Leap 15 [2018]
>
> Note that this does not apply to QNX or Android, so C++14 features would not
> be allowed in cross-platform code.
>
> But we'd be able to use it in the XCB plugin. [Does QNX build that?]

There has been no reply on this subject. Shall I assume silence is consent and
we can begin using C++14 constructs in the XCB plugin?

--
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] Nominating Mårten Nordheim as an approver

2018-04-25 Thread Gatis Paeglis 
+1 from me too.


From: Development  on 
behalf of Timur Pocheptsov 
Sent: Wednesday, April 25, 2018 2:09:22 PM
To: Edward Welbourne; development@qt-project.org
Subject: Re: [Development] Nominating Mårten Nordheim as an approver


+ 1 from me, fully agree with every statement Edward made.


Best regards,

Timur.


From: Development  
on behalf of Edward Welbourne 
Sent: Wednesday, April 25, 2018 1:40:41 PM
To: development@qt-project.org
Subject: [Development] Nominating Mårten Nordheim as an approver

Hi all,

I'd like to nominate Mårten Nordheim for Approver.

We've had him here at TQtC, in the Core & Network team, for a bit over a
year; he's been reviewing steadily and finding mistakes I miss.  As well
as diverse work in qtbase, he's also dabbled in the qtnetworkauth and
qtwebsockets modules.  Here's his list of changes in gerrit:

https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z

and the (somewhat busier) list of what he's reviewed:

https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z

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] QTestLib: sending mouse move and release events outside windows

2018-04-16 Thread Gatis Paeglis 
> I think that maybe we’re talking about different things, because the 
> functionality works for me (both in the app and testlib), I just want to 
> disable the warnings. :)


Its all related :)


> QTest::mouseMove(, QPoint(600, 600));


It is not clear to me what is the expected to happen after this call:


a) Documentation in incomplete.

b) Warning is not critical (it does not return from the function).

c) Looking at the source code this calls ends up doing nothing.


So I was wondering if there is a bigger issue and hiding a warning might not be 
the right solution. But if it works, it works.


From: Mitch Curtis
Sent: Monday, April 16, 2018 5:28:07 PM
To: Gatis Paeglis; development@qt-project.org
Subject: RE: QTestLib: sending mouse move and release events outside windows


I think that maybe we’re talking about different things, because the 
functionality works for me (both in the app and testlib), I just want to 
disable the warnings. :)



From: Gatis Paeglis
Sent: Monday, 16 April 2018 5:08 PM
To: Mitch Curtis <mitch.cur...@qt.io>; development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows



> I was thinking of something that would be public API, as any user who wants 
> to tests drags that end up outside a window will run into the same issue.



That kind of API I think requires serious redesign in qtestlib. If you want to 
drag outside a window and then back to test Enter/Leave events (system 
generated, not the synthetic ones for alien widgets), then we have to use 
system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking 
events. Both modes are useful, mocked vs system events, but that is another 
story.



If you want to move outside a window and keep on receiving all mouse events, 
then you need to grab the mouse/pointer. That is different API from the above 
Enter/Leave scenario. QTestLib currently does not support any of the above.





From: Mitch Curtis
Sent: Monday, April 16, 2018 1:14:23 PM
To: Gatis Paeglis; development@qt-project.org<mailto:development@qt-project.org>
Subject: RE: QTestLib: sending mouse move and release events outside windows



> That warning message was added by [1]. I have never fully understood the 
> motivation for that warning. The documentation from [2] does not say if 
> global coordinates are allowed.



I suppose it could be useful if you didn’t intend to send events outside of the 
window.



> QTest sends all mouse events down to QWindowSystemInterface, which does 
> expect a window as an argument, or nullptr on window-less systems (eglfs). So 
> if you want to simulate a mouse move/press/release outside a window you could 
> try to use that code path...



I was thinking of something that would be public API, as any user who wants to 
tests drags that end up outside a window will run into the same issue.



What do you think about a flag that can be set for the duration of a function 
(i.e. automatically reset at the end of that function)? 
setWarnOnEventsOutsideWindow?



Or, to involve the discussion about failing on warnings, we could add a more 
generic flag getter/setter. We already have [1] a bunch of currentTestFunction 
functions:



const char *currentAppName()

const char *currentDataTag()

bool currentTestFailed()

const char *currentTestFunction()



So, perhaps we could add 
currentTestFunctionFlags()/setCurrentTestFunctionFlags().



TestFunctionFlag {

WarnOnEventsOutsideWindow = 0x01, // enabled by default

FailOnWarnings = 0x02 // disabled by default

};



[1] http://doc.qt.io/qt-5/qtest.html#keyClicks



From: Gatis Paeglis
Sent: Monday, 16 April 2018 12:29 PM
To: Mitch Curtis <mitch.cur...@qt.io<mailto:mitch.cur...@qt.io>>; 
development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: QTestLib: sending mouse move and release events outside windows



That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT ?? see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?



[1] https://codereview.qt-project.org/#/c/53474/

[2] http://doc.qt.io/qt-5/qtest.html#mouseMove

[3] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021



From: Development 
<development-bounces+gatis.paeglis=qt...@qt-project.org<mailto:development-bounces+gatis.paeglis=qt...@qt-project.org

Re: [Development] QTestLib: sending mouse move and release events outside windows

2018-04-16 Thread Gatis Paeglis 
> I was thinking of something that would be public API, as any user who wants 
> to tests drags that end up outside a window will run into the same issue.


That kind of API I think requires serious redesign in qtestlib. If you want to 
drag outside a window and then back to test Enter/Leave events (system 
generated, not the synthetic ones for alien widgets), then we have to use 
system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking 
events. Both modes are useful, mocked vs system events, but that is another 
story.


If you want to move outside a window and keep on receiving all mouse events, 
then you need to grab the mouse/pointer. That is different API from the above 
Enter/Leave scenario. QTestLib currently does not support any of the above.



From: Mitch Curtis
Sent: Monday, April 16, 2018 1:14:23 PM
To: Gatis Paeglis; development@qt-project.org
Subject: RE: QTestLib: sending mouse move and release events outside windows


> That warning message was added by [1]. I have never fully understood the 
> motivation for that warning. The documentation from [2] does not say if 
> global coordinates are allowed.



I suppose it could be useful if you didn’t intend to send events outside of the 
window.



> QTest sends all mouse events down to QWindowSystemInterface, which does 
> expect a window as an argument, or nullptr on window-less systems (eglfs). So 
> if you want to simulate a mouse move/press/release outside a window you could 
> try to use that code path...



I was thinking of something that would be public API, as any user who wants to 
tests drags that end up outside a window will run into the same issue.



What do you think about a flag that can be set for the duration of a function 
(i.e. automatically reset at the end of that function)? 
setWarnOnEventsOutsideWindow?



Or, to involve the discussion about failing on warnings, we could add a more 
generic flag getter/setter. We already have [1] a bunch of currentTestFunction 
functions:



const char *currentAppName()

const char *currentDataTag()

bool currentTestFailed()

const char *currentTestFunction()



So, perhaps we could add 
currentTestFunctionFlags()/setCurrentTestFunctionFlags().



TestFunctionFlag {

WarnOnEventsOutsideWindow = 0x01, // enabled by default

FailOnWarnings = 0x02 // disabled by default

};



[1] http://doc.qt.io/qt-5/qtest.html#keyClicks



From: Gatis Paeglis
Sent: Monday, 16 April 2018 12:29 PM
To: Mitch Curtis <mitch.cur...@qt.io>; development@qt-project.org
Subject: Re: QTestLib: sending mouse move and release events outside windows



That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT ?? see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?



[1] https://codereview.qt-project.org/#/c/53474/

[2] http://doc.qt.io/qt-5/qtest.html#mouseMove

[3] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021



From: Development 
<development-bounces+gatis.paeglis=qt...@qt-project.org<mailto:development-bounces+gatis.paeglis=qt...@qt-project.org>>
 on behalf of Mitch Curtis <mitch.cur...@qt.io<mailto:mitch.cur...@qt.io>>
Sent: Monday, April 16, 2018 11:56:56 AM
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: [Development] QTestLib: sending mouse move and release events outside 
windows



https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move 
and release events outside of a window causes warnings:

void Test::test_case1()
{
QWindow window;
window.resize(400, 400);

// Start inside and drag outside (e.g. moving a selection to the edge of a
// canvas should scroll the canvas).
QTest::mousePress(, Qt::LeftButton, Qt::NoModifier, QPoint(200, 
200));

const QRegularExpression regex(".*Mouse event at .* occurs outside of 
target window.*");
QVERIFY(regex.isValid());

const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 
occurs outside of target window (400x400)."));
QVERIFY(match.hasMatch());

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseMove(, QPoint(600, 600));

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseRelease(, Qt::LeftButton, Qt::NoModifier, QPoint(600, 
600));
}

Output:

* Start testing of Test *
Config: Using QtTest library 5.11.0, Qt 5.11.0 (x8

Re: [Development] QTestLib: sending mouse move and release events outside windows

2018-04-16 Thread Gatis Paeglis 
That warning message was added by [1]. I have never fully understood the 
motivation for that warning. The documentation from [2] does not say if global 
coordinates are allowed. QTest sends all mouse events down to 
QWindowSystemInterface, which does expect a window as an argument, or nullptr 
on window-less systems (eglfs). So if you want to simulate a mouse 
move/press/release outside a window you could try to use that code path... but 
it won't work AFAICT  see [3], if we don't find a window under mouse, then 
QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we 
send the event?


[1] https://codereview.qt-project.org/#/c/53474/

[2] http://doc.qt.io/qt-5/qtest.html#mouseMove

[3] 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021


From: Development  on 
behalf of Mitch Curtis 
Sent: Monday, April 16, 2018 11:56:56 AM
To: development@qt-project.org
Subject: [Development] QTestLib: sending mouse move and release events outside 
windows

https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move 
and release events outside of a window causes warnings:

void Test::test_case1()
{
QWindow window;
window.resize(400, 400);

// Start inside and drag outside (e.g. moving a selection to the edge of a
// canvas should scroll the canvas).
QTest::mousePress(, Qt::LeftButton, Qt::NoModifier, QPoint(200, 
200));

const QRegularExpression regex(".*Mouse event at .* occurs outside of 
target window.*");
QVERIFY(regex.isValid());

const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 
occurs outside of target window (400x400)."));
QVERIFY(match.hasMatch());

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseMove(, QPoint(600, 600));

QTest::ignoreMessage(QtWarningMsg, regex);
QTest::mouseRelease(, Qt::LeftButton, Qt::NoModifier, QPoint(600, 
600));
}

Output:

* Start testing of Test *
Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 
shared (dynamic) debug build; by MSVC 2017)
PASS   : Test::initTestCase()
WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target 
window (400x400).
WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target 
window (400x400).
INFO   : Test::test_case1() Did not receive any message matching: ".*Mouse 
event at .* occurs outside of target window.*"
INFO   : Test::test_case1() Did not receive any message matching: ".*Mouse 
event at .* occurs outside of target window.*"
FAIL!  : Test::test_case1() Not all expected messages were received
PASS   : Test::cleanupTestCase()
Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms
* Finished testing of Test *

Mouse move and release events occurring outside of a window is not uncommon, so 
there should be a way to disable these warnings.

Using QTest::ignoreWarning() has no effect here, because the message logger 
system is (probably intentionally) bypassed.

Does anyone know why this is the case?

Also, does anyone have any ideas about how to solve this?

One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be 
a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow 
halfway through a "drag" loop.

Another idea could be to have a flag or construct that only applies for the 
duration of a test function, and is reset at the end of that function. I think 
something like this could also be useful for the opposite use case: failing a 
test upon any warnings (something that would be useful for QML applications). 
Something like https://codereview.qt-project.org/#/c/89178/ except it's 
automatically reset for you at the end of each test.
___
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] Writing good tests

2017-10-09 Thread Gatis Paeglis 
> here is the link to the Wiki on "Writing good tests" as requested at QtCS: 
> http://wiki.qt.io/Writing_good_tests  .


Regarding the following point:



> If you must track mouse move events, consider replacing the use of 
> QTest::mouseMove where the first parameter is a QWidget with the overload of 
> QTest::mouseMove that takes a QWindow as parameter instead.


See https://codereview.qt-project.org/#/c/208000/ . This results in less 
verbose test function.


Gatis.



From: Development  on 
behalf of Friedemann Kleint 
Sent: Monday, October 9, 2017 1:26:29 PM
To: development@qt-project.org
Subject: [Development] Writing good tests


Hi,

here is the link to the Wiki on "Writing good tests" as requested at QtCS: 
http://wiki.qt.io/Writing_good_tests  .

Regards, Friedemann
The Qt Company GmbH

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

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

2017-09-18 Thread Gatis Paeglis 
> 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.


I agree regarding consistency. If we are spending time on this, then it should 
be done properly. I think Qt Coding Conventions wiki should be moved to 
somewhere where changes can be reviewed via Gerrit.


1) It currently says:


"You have to explicitly specify the return type, if the lambda contains more 
than a single expression. Otherwise it does not compile with VS2010."


I guess this restriction does not apply for Qt 5.8 (dropped support for VS2010) 
and above? Or maybe it does, who knows. With gerrit I could add relevant 
reviewers, if I decide to change something in conventions page.


2) What is the convention regarding functor-based connections + signal/slot 
keyword usage?  See: 
https://codereview.qt-project.org/#/c/203550/3/examples/widgets/itemviews/storageview/storagemodel.h


Gatis.


From: Development  on 
behalf of André Hartmann 
Sent: Friday, September 15, 2017 6:42:34 AM
To: development@qt-project.org
Subject: [Development] Qt Coding style and C++11

Hi, since a while C++11 is allowed in Qt and there is ongoing effort
porting e.g. examples to the new possibilities.

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.

What I like to add, is to encourage the use of C++11 member
initialisation. They are already used in QtSerialBus (from the
beginning) and QtCreator (ongoing changes to existing codebase).

What do you think?

Best regards,
André

[1] https://wiki.qt.io/Coding_Conventions
___
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] Nominating Teemu Holappa for Approver and Maintainer status.

2016-11-24 Thread Gatis Paeglis 
Hi,

I'd like to nominate Teemu Holappa for the Approver status. He joined Digia 
(now The Qt Company) 3+ years ago as a Qt consultant. Teemu has contributed to 
meta-boot2qt and anything else that needs fixing to get Qt for Device Creation 
releases out the door.

Here is his gerrit dashboard:

https://codereview.qt-project.org/#/q/owner:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z

Teemu also has done a good job at reviewing changes for meta-{boot2qt, qt5, 
mingw} among other projects:

https://codereview.qt-project.org/#/q/reviewer:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z

I'd also like to nominate him as the Maintainer of the qtdeviceutilities module 
(http://code.qt.io/cgit/qt/qtdeviceutilities.git/). Teemu has heavily 
refactored this module and added significant amount of new features. He is the 
go-to guy in the team when qtdeviceutilities is the topic.


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