Re: [Development] QtCS2022 - Sessions and Timeslots

[Marc Mutz]

Hi Thiago,

> I can only join sessions between 7:00 and 9:30 CEST, and after 16:00. I don't
> need to join the keynote, so I won't force people to wake up early for that
> one. But please bear the times in mind if you'd like me to join.

Maybe you can indicate which sessions you're personally interested in, so we 
can take that into account? 🙂

I think it makes sense to have you in the C++20 session, so I allocated it 
first thing on the second day. If your interests lie in different sessions, I 
have no problem re-scheduling to make space.

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

Re: [Development] New Chief Maintainer

[Andy Shaw]

Hi,

Based on the wording I agree, it is clear that all maintainers should vote in 
this case, and it is a simple majority of those maintainers. Any maintainer who 
does not vote is not counted as part of the total, so if there is a single 
candidate then a vote is redundant, because you are voting for someone, 
abstaining means it is not counted in the total. If there are multiple 
candidates, then it has to be a majority, meaning more than half of the votes 
to win (https://en.wikipedia.org/wiki/Majority#Majority_vote - simple majority 
is covered here), but if there is only 2 candidates then one can reasonably go 
with the fact that the one with the most is the de-facto winner because if you 
redid the vote without the candidate with the fewest votes then it's fairly 
clear cut. If there is more than 2 then we should drop the one with the fewest 
votes and redo the vote and so on until we do indeed have a simple majority.

One other thing is that I think that we should do our best to make sure the 
maintainers (as a group) are aware of this, we have basically just given then 1 
week to agree on the new Chief Maintainer, which to be frank, is not long 
enough. The QUIP says 1 month's warning and Lars has given that, so we should 
use most of that month to allow a proper process and to give people a chance to 
actually get the news. All of the maintainer's email addresses are on the wiki 
so we should have a mail sent directly to them to indicate that this happened 
(not everyone is on the mailing list, and the vote itself might slip by people 
if they are on vacation or similar otherwise when it gets announced) and that 
way we can be sure everyone has been given enough time to react and vote if 
they should choose to. This is a vote which is important to the Qt Project and 
my opinion on who should be Chief Maintainer has no bearing on things since I 
am not a maintainer, but I would like to see this process make it clear that 
everyone (who is in the position to do so) feel that they had a say in this , 
and that the Qt Project is truly an open project.

Regarding the nomination process, this is woefully under documented in the QUIP 
as there is no indication as to how you get nominated for Chief Maintainer, 
from the reading of it the Maintainers themselves decide who should be Chief 
Maintainer by way of simple majority but that could in theory mean anyone can 
be nominated for it. I think that anyone can put themselves forward for being 
Chief Maintainer and should also give an indication as to why they feel they 
would be ideal for the position. Then this could be voted on in a voting page 
like we did with the previous situation so that the actual votes are 
confidential. 

Regardless of who gets the position, QUIP 2 does need to be tightened up in a 
number of ways, we should be a lot clearer on this process to avoid problems 
next time, and also there should be general wording on what happens when a 
maintainer is no longer active, if there is no one having the responsibilities 
for them formally delegated, then it shouldn't need a vote to have the 
privileges removed.

Kind regards,
Andy

-Original Message-
From: Development  On Behalf Of André Somers
Sent: Friday, May 20, 2022 5:43 AM
To: Volker Hilsheimer ; development@qt-project.org
Subject: Re: [Development] New Chief Maintainer

Hi Volker,

On 19-05-2022 22:42, Volker Hilsheimer wrote:
>> On 18 May 2022, at 11:23, André Somers  wrote:
>>
>>
>> On 18-05-2022 11:19, André Somers wrote:
>>> As I understand it [1], this needs a formal vote. However, the QUIP 
>>> does not specify a full procedure. I would suggest:
>> And then I forget the actual link:
>>
>> https://quips-qt-io.herokuapp.com/quip-0002.html#how-to-become-chief-
>> maintainer
>
> Thanks André.
>
> The QUIP asks for a simple-majority vote of all Maintainers. Either way, 
> let’s see what other nominations we get.
>
> May I propose that until end of Wednesday 25th, Maintainers can nominate 
> other candidates (including themselves), and then we can have a vote amongst 
> those candidates nominated (the simple majority is enough as per QUIP). The 
> QUIP doesn’t explicitly require the candidate to be a Maintainer.
>
> If we have only one candidate by end of Wednesday, then we can use lazy 
> consensus, i.e. as long as none of the maintainers object to the candidate, 
> that candidate becomes chief maintainer. Although I’d expect that whoever has 
> an objection to one candidate also nominates another candidate.

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

So no, I don't think a lazy consensus will do. And no, I don't think it's 
having an objection to a 

Re: [Development] New Chief Maintainer

[André Somers]

Hi Volker,

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

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


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

And then I forget the actual link:

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


Thanks André.

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

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

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


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


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


Cheers,

André




Volker


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

Re: [Development] New Chief Maintainer

[Volker Hilsheimer]

> On 19 May 2022, at 23:00, Thiago Macieira  wrote:
> 
> On Thursday, 19 May 2022 13:42:50 PDT Volker Hilsheimer wrote:
>> May I propose that until end of Wednesday 25th, Maintainers can nominate
>> other candidates (including themselves), and then we can have a vote
>> amongst those candidates nominated (the simple majority is enough as per
>> QUIP). The QUIP doesn’t explicitly require the candidate to be a
>> Maintainer.
> 
> Sounds good.
> 
> Volker, you've been nominated. Since  you have not objected to it, we'll 
> assume you're willing to be our new Overl^H^H^H^H^HChief Maintainer, correct?

Correct. It’d be an honour to serve the project as Chief Maintainer.

Volker

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

Re: [Development] New Chief Maintainer

[Thiago Macieira]

On Thursday, 19 May 2022 13:42:50 PDT Volker Hilsheimer wrote:
> May I propose that until end of Wednesday 25th, Maintainers can nominate
> other candidates (including themselves), and then we can have a vote
> amongst those candidates nominated (the simple majority is enough as per
> QUIP). The QUIP doesn’t explicitly require the candidate to be a
> Maintainer.

Sounds good.

Volker, you've been nominated. Since  you have not objected to it, we'll 
assume you're willing to be our new Overl^H^H^H^H^HChief Maintainer, correct?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] New Chief Maintainer

[Volker Hilsheimer]

> On 18 May 2022, at 11:23, André Somers  wrote:
> 
> 
> On 18-05-2022 11:19, André Somers wrote:
>> 
>> On 18-05-2022 10:53, Samuel Gaist via Development wrote:
>>> Hi,
>>> 
>>> +1
>>> 
>>> Best regards
>>> 
>>> Samuel
>> 
>> As I understand it [1], this needs a formal vote. However, the QUIP does not 
>> specify a full procedure. I would suggest:
>> 
> And then I forget the actual link:
> 
> https://quips-qt-io.herokuapp.com/quip-0002.html#how-to-become-chief-maintainer


Thanks André.

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

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

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

Volker

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

Re: [Development] New Chief Maintainer

[Robert Löhning]

Am 18.05.2022 um 11:19 schrieb André Somers:


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


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

Re: [Development] New Chief Maintainer

[Lorn Potter]

On 18/5/2022 6:28 PM, Lars Knoll wrote:

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

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


+1

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

Re: [Development] QtCS2022 - Sessions and Timeslots

[Thiago Macieira]

On Thursday, 19 May 2022 09:52:55 PDT Giuseppe D'Angelo via Development wrote:
> * could it be possible to adjust the timeslots in order to optimize for
> the majority of the developers, who are in the CEST timezone?

I can only join sessions between 7:00 and 9:30 CEST, and after 16:00. I don't 
need to join the keynote, so I won't force people to wake up early for that 
one. But please bear the times in mind if you'd like me to join.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] QtCS2022 - Sessions and Timeslots

[Giuseppe D'Angelo via Development]

Hello,

Il 19/05/22 18:43, Pedro Bessa ha scritto:

Thank you for submitting your sessions.

I kindly ask you to now add your session to a desired timeslot. Just its 
title is necessary; I will merge our tables later.


Please keep in mind a few things:

  * taking feedback into consideration, let’s try our best to avoid
concurrent sessions,
  * we suggest 30-minute or 1-hour sessions, anything in between,
  * the time slots are suggestions; we can be flexible and make
adjustments if necessary.


Couple of practical questions:

* is there going to be only 1 track or more than one in parallel?
* could it be possible to adjust the timeslots in order to optimize for 
the majority of the developers, who are in the CEST timezone?


Thank you,
--
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


smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] QtCS2022 - Sessions and Timeslots

[Pedro Bessa]

Hi everyone,

Thank you for submitting your sessions.
I kindly ask you to now add your session to a desired timeslot. Just its title 
is necessary; I will merge our tables later.
Please keep in mind a few things:


  *   taking feedback into consideration, let’s try our best to avoid 
concurrent sessions,
  *   we suggest 30-minute or 1-hour sessions, anything in between,
  *   the time slots are suggestions; we can be flexible and make adjustments 
if necessary.

Assign your session to a timeslot 
here

Cheers,
Pedro Bessa
Community Relations Manager
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
pedro.be...@qt.io
www.qt.io
[signature_522509022]
[signature_1594855648]
[signature_1989022544]
[signature_1162664441]
[signature_2232993054]

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

Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention

[Ilya Fedin]

On Thu, 19 May 2022 14:20:05 +
Morten Sørvig  wrote:

> Looks inconclusive to me - no clear consensus either way. (I’m also
> not sure if it's a bug - it’s just "the current behavior")
> 
> However, we might be able to find a way forward: the rounding policy
> is also under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY
> environment variable. So users who wants no rounding at all (even for
> apps which claim to not support fractional scale factors) can set it
> to “Passthrough” to preserve the current behavior.
> 
> - Morten

It's a bug as it makes applications that clearly stated they don't
support fractional scaling render incorrectly. The only question what's
the bug: inconsistency in the QT_SCREEN_SCALE_FACTORS behavior or KDE
using wrong way to set the scaling. And the lack of consensus makes
it impossible to fix it on Qt side/report to KDE. :(

As a result, affected applciations are unusable for a long time.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QTBUG-95930 / QTBUG-99546 need some attention

[Morten Sørvig]

On 17 May 2022, at 22:14, Ilya Fedin 
mailto:fedin-ilja2...@ya.ru>> wrote:

On Tue, 10 May 2022 19:40:02 +
Morten Sørvig mailto:morten.sor...@qt.io>> wrote:

On 9 May 2022, at 16:47, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:

On Monday, 9 May 2022 07:07:23 PDT Morten Sørvig wrote:
b) In practice, QT_SCREEN_SCALE_FACTORS has become a system
setting since it’s being set on behalf of the user. This means the
values should be subject to rounding according to
highDpiScaleFactorRoundingPolicy property, like with other system
DPI settings.

It it's a system setting, then one should assume it's been set to
the exact value that the system wanted it to be. So if they'd
wanted it rounded, they'd have rounded it.

That is true, however the purpose of highDpiScaleFactorRoundingPolicy
is override the system setting. For example, a Windows display can be
configured for 175%, but the app knows it does not support that and
has enabled rounding (to 200%).

So if QT_SCREEN_SCALE_FACTORS is considered a system setting then
this is an inconsistency in behavior.

So, what's the decision? Is it a bug in Qt or in KDE?

Looks inconclusive to me - no clear consensus either way. (I’m also not sure if 
it's a bug - it’s just "the current behavior")

However, we might be able to find a way forward: the rounding policy is also 
under user control with the QT_SCALE_FACTOR_ROUNDING_POLICY environment 
variable. So users who wants no rounding at all (even for apps which claim to 
not support fractional scale factors) can set it to “Passthrough” to preserve 
the current behavior.

- Morten




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

Re: [Development] Leaving The Qt Company

[Lorn Potter]

On 18/5/2022 6:27 PM, Lars Knoll wrote:
As some of you might know I got involved rather deeply about a year or 
two later, when I started the KHTML project to create a new HTML engine 
for KDE in 1998/1999. That project was later forked by Apple to form the 
basis for their WebKit project, the Safari browser and Google’s Chrome 
browser. It's cool to think that the browser engine(s) that most people 
use today started off as a Qt based project all those years ago.


Certainly been a bumpy ride at times, but with your help Qt has grown 
into Qt Everywhere. hahahaha. and is in so many unbelievable products now!


Congrats on the new digs! I am sure we will be hearing more about it in 
the future.


Thanks again!

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

Re: [Development] QKeySequenceEdit questions

[Eike Ziller]

> On 18 May 2022, at 11:50, Laszlo Papp  wrote:
>> 
>> 
>> 
>> On Wed, May 18, 2022 at 9:50 AM Volker Hilsheimer  
>> wrote:
>> > On 18 May 2022, at 10:09, Laszlo Papp  wrote:
>> >> On Wed, May 18, 2022 at 9:03 AM Volker Hilsheimer 
>> >>  wrote:
>> >> Have you ever used vim? :P Deleting until the end of the line, or 
>> >> deleting the next word, are all multi-chord key sequences.
>> > 
>> > Sure, but in this context, we were discussing shortcut editors that was 
>> > linked in KDE.
>> >  
>> >> > The current proposal is to make QKeySequenceEdit be able to behave like 
>> >> > a QShortcutEdit by adding a property. But for keyboard shortcuts, "key 
>> >> > sequence" does not make all that much sense. We are just retrofitting 
>> >> > it for that purpose, I feel.
>> >> 
>> >> You are not forced to use key sequences with more than one chord, but in 
>> >> some applications, such as IDEs, multi-chord shortcuts are pretty common, 
>> >> even without using vim mode.
>> > 
>> > We have actually done thorough investigation on this, and the fact is that 
>> > the vast majority of the applications (in fact, everything we could find 
>> > ourselves) use single combination shortcut. It is not really common or 
>> > even practical to have sequences for shortcuts. Please refer to for 
>> > example this for further information:
>> > 
>> > https://www.ranorex.info/difference-between-key-sequence-and-key-shortcut-t8864.html
>> 
>> 
>> That’s one way of defining these terms. VSCode calls things “key 
>> combination” and “chords”, and “key bindings". Qt calls them key sequence 
>> and shortcut.
>> 
>> In Visual Studio Code, which I’d consider to be a rather popular 
>> application, you open the Keyboard Shortcut editor with a sequence of Cmd+K, 
>> Cmd+S. The “testing.cancelRun” command is then by default (I think, mine is 
>> somewhat heavily customized, but I don’t think I touched that one) bound to 
>> the key sequence Cmd+;, Cmd+X, or the “Add Line Comment” command is bound to 
>> Cmd+K, Cmd+C. Many of the extensions for VSCode use key sequences, like 
>> “jump to previous bookmark" when you install that extension is Cmd+K, J 
>> (toggling it is Cmd+K,K).
>> 
>> And you can edit the key sequences there, and end the sequence input via 
>> Return; which makes it impossible to use Return in a sequence, but you can’t 
>> have it all, I suppose.
>> 
> The thing, emacs, vim, Visual Code or even QtCreator are development 
> environments. Most of the apps out there, like ours, are not geeky 
> development environments. I consider these sort of applications the minority 
> out there as far as applications go. This is not to invalidate them. I am 
> just saying that Qt designed this class for these minor use cases. I would 
> like them to become useful also by the majority.

I agree that most applications would not have or need multi-chord shortcuts _by 
default_. And most users will never change keyboard shortcuts of an 
application. But keyboard shortcut settings are supposed to cover unusual 
preferences by the user. It is an “expert" setting, and if you do not allow 
multi-chord shortcuts there even though the application in principle would 
support it, IMO you are arbitrarily restricting that “expert” setting to a 
“half-expert” setting. Why prevent an emacs user from setting their favorite 
multi-chord shortcut even in a different, more simpler application? Why prevent 
an emacs user from setting Ctrl+x,o as the shortcut for switching to the next 
tab in a browser? Or Ctrl+x,Ctrl+f for File > Open ?

Br, Eike

>  
>> QKeySequenceEdit is 330 lines of code, so writing your own that is ideal for 
>> your use case might sometimes be the best option. And if you have ideas on 
>> how we can make QKeySequenceEdit more user-friendly without categorically 
>> constraining existing use cases (Perhaps a property that allows defining a 
>> “finish editing” key? And/or adding a protected finishEditing function that 
>> would allow a subclass to handle a specific key event to finish editing), 
>> then patches welcome.
> 
> The list of properties that I think a generic hotkey editor would need:
> 
> 1. Single combination
> 2. Finishing character
> 3. No timer! This could be done automatically for keyPressEvent timing. No 
> need to time again in a custom widget.
> 4. Allowing Esc to be assigned like in some apps.
> 
> I am happy to provide patches for these over some course of time as we have 
> got requests for all these.
> 
> Thanks.
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B


___
Development mail