Re: [Development] Adding CPD support to Qt print dialog

[Till Kamppeter]

I have now released version 2.0b6 of cpdb-libs, with a lot of bug fixes, 
especially of crashers, and with some changes which needed to apply to ease 
sandboxed packaging (Snap, OCI containers, ...) of the backends.


This changes caused slight changes in the API, which could also cause slight 
changes to be needed in the print dialog code, mainly a different function has 
to be called to send off a print job.


I highly recommend to only work with this version and to update if an older 
version is installed.


The announcement is here:

https://openprinting.github.io/Common-Print-Dialog-Backends-Second-Generation-Sixth-Beta-Release/

See especially also the "API changes" section.

Gaurav (Guleria), please updated to this cpdb-libs version, test the Qt dialog, 
and do the needed changes on it for sending off the print jobs streaming and 
with a job title. If you have any code to explicitly support the CPDB FILE 
backend, for example for the user to choose the file to print into, you should 
remove it.


Further API changes will most probably not happen any more.

Once the patches being updated by Gaurav Guleria I will also look through them 
to see whether everything is done correctly. Especially with 2.0b6 it is easier 
to test everything as it has many bug fixes since 2.0b5 of 10 months ago.


   Till


On 6/18/24 10:25, Volker Hilsheimer wrote:

Hi all,

The support for Common Print Dialog Backends has been in the works for a while. 
As of last year we are provisioning the SDK in our CI nodes:

https://codereview.qt-project.org/c/qt/qt5/+/471258

but the change on Qt is stuck a bit. Could someone with experience and 
knowledge about the state of CPDB help with reviewing those patches, please? 
Open changes are in the chain at

https://codereview.qt-project.org/c/qt/qtbase/+/437301/17

(need to be rebased and the SDK might need to be bumped to latest version 
v2.0b5).

Thanks,
Volker


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

Re: [Development] QtGraphs final API review

[Sami Varanka via Development]

Here are the new api review commits
https://codereview.qt-project.org/c/qt/qtgraphs/+/570029/1
https://codereview.qt-project.org/c/qt/qtgraphs/+/570030/1

I now used api-review-gen script since it's fixed.

From: Sami Varanka
Sent: 14 May 2024 13:42
To: development@qt-project.org 
Subject: QtGraphs final API review

Hi everybody!
QtGraphs will be out of TP in 6.8, and now we need to do the final API review. 
This API review commit is created manually as QtGraphs has a too complex 
CMakeLists.txt for our API review script. More information can be found at 
https://bugreports.qt.io/browse/QTQAINFRA-6317. Here is the link to the API 
review commit: https://codereview.qt-project.org/c/qt/qtgraphs/+/560943

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

Re: [Development] std::format support for Qt string types

[Thiago Macieira]

On Wednesday 19 June 2024 04:32:42 GMT-7 Giuseppe D'Angelo via Development 
wrote:
> I wouldn't say "force", but we could certainly check for it. We depend
> on that: we assume that string literals in our headers are UTF-8 encoded.
> 
> I it worth it though? Since we're talking about user code, this would
> mean a static_assert in a global header. (There's some precedent for
> this, like the check for /permissive-).

I don't see the point. Hardly anyone even knows the option is there for GCC 
and Clang, as they default to UTF-8. So it's not a problem that needs solving.

We already enforce in QCoreApplication where it matters: the setlocale() call.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Systems Engineering


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

Re: [Development] [Qt-creator] Nominating André Hartmann as new Maintainer of VCS support in Qt Creator (was: Re: Stepping down as maintainer)

[Jaroslaw Kobus via Development]

> Am 19.06.2024 um 10:17 schrieb Eike Ziller via Qt-creator 
> :
>
> Hi,
>
> I nominate André Hartmann as the new maintainer of Version Control in Qt 
> Creator. His contribution history in Qt Creator goes back to 2011 as well, 
> and he regularly worked on improving our version control support (as well as 
> contributing to Qt and maintaining qtserialbus/CANBus). 
> https://codereview.qt-project.org/q/owner:aha_1...@gmx.de

+1 for André, I am convinced that Andre is the perfect fit to be a VCS 
maintainer!

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

Re: [Development] std::format support for Qt string types

[Giuseppe D'Angelo via Development]

Hi,

On 19/06/2024 11:23, Alexey Edelev via Development wrote:


Hi,

I have a side question for this discussion(raised by Ivan in personal 
conversation): Should we also force the -fexec-charset= for the gcc-like 
compilers? Currently we use the system default one, which in most cases 
is UTF-8.


I wouldn't say "force", but we could certainly check for it. We depend 
on that: we assume that string literals in our headers are UTF-8 encoded.


I it worth it though? Since we're talking about user code, this would 
mean a static_assert in a global header. (There's some precedent for 
this, like the check for /permissive-).


My 2 c,
--
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 - Trusted Software Excellence



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

[Development] New keyword for Fixes bot "Reopens" and revert detection now live

[Daniel Smith via Development]

Following feedback on the Reopens footer, it is now live an can be used in the 
commit message with the new behaviour:

  *   Use Fixes normally to close an issue and as assign a fix version.
  *   Use the Reopens footer to auto-reopen an issue when a change with the 
footer merges. For example, in a Revert commit.
 *
Reopens and Fixes should not target the same jira issue; Fixes takes precedence 
if both exist and target the same issue.
  *   Use Fixes to re-close a previously reopened issue. This entails a minor 
behavioural change in the bot: Where previously, the bot would refuse to 
re-close a reopened issue, it now effectively only disallows cherry-picks from 
doing so. This means that if a fresh (never seen before) change ID with a fixes 
footer merges, it will close the issue, but only ever once. Any duplicate 
change IDs which merge on non-origin branches (cherry picks) will ignore the 
closing action of the Fixes footer.
 *
This behaviour applies regardless of how the change was reopened.

As in the original proposal, Revert commits will now automatically tag any jira 
issues originally tagged by the commit being reverted to include the sha of the 
merged revert commit.

An update to the commit message template including Reopens is in 
review 
 and should be merged 
shortly.

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

Re: [Development] std::format support for Qt string types

[Alexey Edelev via Development]

Hi,

I have a side question for this discussion(raised by Ivan in personal 
conversation): Should we also force the -fexec-charset= for the gcc-like 
compilers? Currently we use the system default one, which in most cases is 
UTF-8.

Regards,
Alexey


Alexey Edelev

Software Engineer

Qt Group
Erich-Thilo-Str. 10 12489
Berlin, Germany

alexey.ede...@qt.io

www.qt.io

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/Qt-Group-logo-black-1.png]
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook-x2-right.png]

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter-x2.png] 
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin-x2.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube-x2.png] 


From: Development  on behalf of Ivan 
Solovev via Development 
Sent: Thursday, June 13, 2024 2:05 PM
To: development@qt-project.org 
Subject: Re: [Development] std::format support for Qt string types

So, I dropped a message to the SG16 mailing list, and I got a link to a new
paper as an answer: https://wg21.link/P3258

As I read it, the key point for us is that the formatter output should use
the literal encoding of the format string, or fall back to the execution
encoding.

AFAIK, we in Qt already assume that the literal and execution encoding is
UTF-8. That's the case for Linux and macOS, and for MSVC we explicitly pass
the /utf8 flag to enable the same behavior.

As a result, UTF-8 seems to be the right choice for the char formatters.

Best regards,
Ivan

--

Ivan Solovev
Senior Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io

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


From: Development  on behalf of Thiago 
Macieira 
Sent: Friday, June 7, 2024 6:25 PM
To: development@qt-project.org
Subject: Re: [Development] std::format support for Qt string types

On Friday 7 June 2024 08:40:33 GMT-7 Ivan Solovev via Development wrote:
> IIUC, the problem of extra allocations is covered by the transcoding
> iterators and views in the paper that was linked by Giuseppe.

Yes and no.

That appears to transfer the responsibility of transcoding to the formatter,
which may be acceptable for std::format() on std::string or for std::print(),
because for those, performance and code bloat are entirely unimportant.

The question I want to see addressed is performance when we begin using format
to replace QString::arg() and thus tr(). We have highly-specialised conversion
code because this is critical to us and I'd like to see it used. So how do we
ensure that in those contexts we use our code, which is not and cannot be
inline?

How do we format onto a QString?

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Engineering and Quality
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Qt-creator] Nominating André Hartmann as new Maintainer of VCS support in Qt Creator (was: Re: Stepping down as maintainer)

[Eike Ziller via Development]

Resent, to fix the cc to the Development mailing list.

> Am 19.06.2024 um 10:17 schrieb Eike Ziller via Qt-creator 
> :
> 
> Hi,
> 
> I nominate André Hartmann as the new maintainer of Version Control in Qt 
> Creator. His contribution history in Qt Creator goes back to 2011 as well, 
> and he regularly worked on improving our version control support (as well as 
> contributing to Qt and maintaining qtserialbus/CANBus). 
> https://codereview.qt-project.org/q/owner:aha_1...@gmx.de
> Jarek is already maintainer under the Qt Governance Model (parts of Qt 
> Creator and QtHelp) and can certainly act as a backup.
> 
> Br, Eike
> 
>> Am 14.06.2024 um 14:31 schrieb Orgad Shaneh :
>> 
>> Hi,
>> 
>> I've been using Qt Creator since its first version and began contributing to 
>> it in 2011 (with Gitorious :p). When I joined AudioCodes, I introduced Qt 
>> Creator there, and for many years, most of the C++ developers in my team 
>> have been using it daily.
>> 
>> Over the years, I've made numerous contributions to the project, reporting 
>> 952 bugs and submitting 3,370 commits to Qt Creator. However, in recent 
>> years, I've been working on a different project which isn't written in C++. 
>> As a result, I use Qt Creator less frequently and have much less time to 
>> maintain it.
>> 
>> I still use and love Qt Creator, and it remains my first choice for C++, but 
>> I can no longer continue maintaining it. I propose André Hartmann or Jarek 
>> Kobus as my successors.
>> 
>> I'll likely stay around and be available for reviews ;)
>> 
>> Thank you all for this great product!
>> - Orgad
> 

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
eike.zil...@qt.io
https://qt.io

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] Fixing Qt-internal logging categories

[Ulf Hermann via Development]

Hi,

First things first: Users of Qt are unaffected by most of this. They get 
a nicer macro to define static logging categories, but everything else 
stays the same for them.


Logging categories have been a source of some frustration in Qt itself 
because they tend to create symbols that don't start with 'q' or 'Q' and 
that like to clash with each other and user symbols, especially in 
static builds. On top of this, logging categories are often not declared 
in a header, but rather multiple times in all implementation files that 
use them. This makes it unnecessarily hard to spot and fix the problem.


Since https://codereview.qt-project.org/c/qt/qtbase/+/417028 we've had a 
macro that declares an exported logging category. If you feel the need 
to export a logging category, you should:

1. Think twice. This is probably a bad idea.
2. If it's in Qt library code, use 
QT_DECLARE_EXPORTED_QT_LOGGING_CATEGORY, see below.
3. Otherwise, Q_DECLARE_EXPORTED_LOGGING_CATEGORY is better style, but 
nothing actually changes for you.
Do not just prepend the export macro to Q_DECLARE_LOGGING_CATEGORY in Qt 
code since that relies on implementation details of 
Q_DECLARE_LOGGING_CATEGORY which are soon going to change.


Since https://codereview.qt-project.org/c/qt/qtbase/+/565342 you can 
define a logging category as static, and thereby prevent its name from 
escaping the compilation unit it's defined it. You should use the new 
Q_STATIC_LOGGING_CATEGORY macro wherever you can. Do not just prepend 
'static' to Q_LOGGING_CATEGORY since that relies on implementation 
details of Q_LOGGING_CATEGORY which are soon going to change for logging 
categories in Qt itself.


Since https://codereview.qt-project.org/c/qt/qtbase/+/566456 you can 
declare a logging category as exported from a Qt library with a specific 
export macro. This is different from Q_DECLARE_EXPORTED_LOGGING_CATEGORY 
because logging categories defined in Qt itself will soon be different 
from logging categories defined in user (or plugin or tool) code. 
Whenever you feel the need to export one of the logging categories in Qt 
itself, you should:

1. Think twice. This is probably a bad idea
2. If you are sure, use QT_DECLARE_EXPORTED_QT_LOGGING_CATEGORY

Once https://codereview.qt-project.org/c/qt/qtbase/+/235873 is in, Qt's 
own non-static logging categories will live in the namespace 
QtPrivateLogging, resolving the issue of the missing 'q' prefix and 
avoiding name clashes with user code. The old name is retained via a 
"using" declaration, so you don't have to change any code that uses 
logging categories.


Once https://codereview.qt-project.org/c/qt/qtbase/+/567907 is in, 
non-static logging categories that haven't been forward declared will 
generate a deprecation warning. This way you are gently encouraged to 
either:

1. Make the logging category static to hide it from the symbol table.
2. Declare the logging category exactly once, in a header you include 
wherever you need it. This makes it obvious that there is an extra 
symbol generated from your logging category.


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