[Development] [GSoC 2020] Regarding Qt implementation of Common Print Dialog Backends (CPDB)

Hey all! I am Priydarshi Singh, a sophomore student at the Indian Institute of Technology, Kanpur. I have been selected for Google Summer of Code 2020 by Open Printing (under The Linux Foundation). My project is to bring CPDB to Qt

Re: [Development] Qt 6 high-dpi support

On 2020-05-13 23:41, Henry Skoglund wrote: On 2020-05-13 16:53, Morten Sørvig wrote: We are indeed planning to addreess high-DPI support for Qt 6. You can test the implementation on Qt 5.14+ today by setting QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote: > std::span Project::productsSpan() const & { return d->products; } > std::span Project::productsSpan() const && = delete; Now implement either or both of these functions if internally you have a QSet. -- Thiago Macieira -

Re: [Development] Qt 6 high-dpi support

On 2020-05-13 16:53, Morten Sørvig wrote: We are indeed planning to addreess high-DPI support for Qt 6. You can test the implementation on Qt 5.14+ today by setting QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Re: [Development] QString and related changes for Qt 6

> From: Development on behalf of Thiago > Macieira > Sent: Wednesday, May 13, 2020 6:21 PM > To: development@qt-project.org > Subject: Re: [Development] QString and related changes for Qt 6 > > On terça-feira, 12 de maio de 2020 22:57:31 PDT Jaroslaw Kobus wrote: > > That's why I've mentioned

Re: [Development] QString and related changes for Qt 6

On terça-feira, 12 de maio de 2020 22:57:31 PDT Jaroslaw Kobus wrote: > That's why I've mentioned the better option: aggregation: QStringView could > be a member of QString. However, the downside would be that every time you > want to call a const method for QString, you would need to first get

Re: [Development] QString and related changes for Qt 6

On 13/05/2020 11.49, Giuseppe D'Angelo wrote: Il 13/05/20 16:44, Matthew Woehlke ha scritto: Note that adding the QString(char16_t*) constructor Pedantic, but surely you meant `char16_t const*`. Hey, you can't nitpick here ... This can be solved with a third overload:    template   

Re: [Development] QString and related changes for Qt 6

Il 13/05/20 16:44, Matthew Woehlke ha scritto: Note that adding the QString(char16_t*) constructor Pedantic, but surely you meant `char16_t const*`. Hey, you can't nitpick here ... This can be solved with a third overload: template void foo(char16_t ()[N]) { foo(QStringView{s, N});

Re: [Development] Views in APIs

On 13/05/2020 03.04, Lars Knoll wrote: I don’t see a need to take a QStringView in those cases. With the exception of some low level APIs, Qt’s APIs should be safe to use. An overload taking a QStringView would either need to copy the data (in which case we could just as well only offer the

Re: [Development] Views in APIs

On 12/05/2020 12.59, Marc Mutz via Development wrote: AsidE: If you think that CoW is still a thing today: no. SSO is a thing these days, and it seems that QString will not have it in Qt 6, either. NOI favours SSO, QString-everywhere cements the naïve CoW world of the 1990s for yet another

Re: [Development] QString and related changes for Qt 6

On 12/05/2020 17.21, Thiago Macieira wrote: On Tuesday, 12 May 2020 08:42:28 PDT Matthew Woehlke wrote: How will this work? As I understand, the main advantage to QStringLiteral is that it statically encodes the *length* as well as the data. This isn't possible with raw literals, which are

[Development] Qt 6 high-dpi support

> > P.S. Consider a similar type of "technical debt" being settled by Qt: I'm > thinking of the "DPI awareness" setting in 5.14, i.e. for a default widgets > program, Qt nowadays tells WIndows that it's "DPI aware" and wants the truth > about screen coordinates, even on those portable PCs

Re: [Development] QString and related changes for Qt 6

On 13/05/2020 02.33, Lars Knoll wrote: On 12 May 2020, at 23:09, Thiago Macieira wrote: I want rules that determine what the API should be without looking at the implementation of those two functions. You may be disappointed, at least as far as parameters. This is one reason why I think we

Re: [Development] QString and related changes for Qt 6

On 12/05/2020 13.48, Giuseppe D'Angelo via Development wrote: On 5/12/20 6:12 PM, Иван Комиссаров wrote: So the question is - is it possible to allow to construct QString from unicode literal? "Not yet", but adding a constructor from char16_t to QString makes sense. This creates a problem

Re: [Development] Configuring Qt VS Tools to auto generate .qm files from .ts files

We plan to revise the support for lupdate/lrelease in the Qt VS Tools as part of release 2.6 (end of August 2020). We'll add new property pages with settings for the Qt Linguist tools, including target paths for .ts and .qm files. You can track progress by watching this issue:

[Development] QAnyString(View) (was: Re: Views in APIs)

On 2020-05-13 11:53, Ville Voutilainen wrote: On Wed, 13 May 2020 at 12:46, Marc Mutz via Development wrote: In the not so hypothetical case that Qt is used to visualize results of some business calculations, chances are that thrid-party libraries will use std::string or std::u16string, and

Re: [Development] Configuring Qt VS Tools to auto generate .qm files from .ts files

in your .pro file: CONFIG += lrelease QMAKE_LRELEASE_FLAGS += -removeidentical LRELEASE_DIR = $$OUT_PWD/GeneratedFiles/i18n EXTRA_TRANSLATIONS += \ $$files($$[QT_INSTALL_TRANSLATIONS]/*.qm) \ $$files($$PWD/i18n/*.ts) Regards, Konstantin ср, 13 мая 2020 г. в 13:47, David C.

[Development] Configuring Qt VS Tools to auto generate .qm files from .ts files

I posted a question about this here: and was directed here when I didn't get an answer there. I wanted Qt VS Tools to automatically build .ts files (ideally in a defined location such as ".\GeneratedFiles\i18n"). What I can

Re: [Development] QString and related changes for Qt 6

On Wed, 13 May 2020 at 12:50, Tor Arne Vestbø wrote: > > > > > On 13 May 2020, at 10:12, Edward Welbourne wrote: > > > >> Note that adding the QString(char16_t*) constructor introduces this > >> ambiguity for the functions that are already overloaded on > >> QString+QStringView (and thus today

Re: [Development] Views in APIs

On 2020-05-13 09:56, Philippe wrote: On Tue, 12 May 2020 18:59:35 +0200 Marc Mutz via Development wrote: QString-everywhere cements the naïve CoW world of the 1990s for yet another decade. CoW naive? Really not, this method is at the heart of many strategic technologies. eg.: * virtual

Re: [Development] Views in APIs

On Wed, 13 May 2020 at 12:46, Marc Mutz via Development wrote: > In the not so hypothetical case that Qt is used to visualize results of > some business calculations, chances are that thrid-party libraries will > use std::string or std::u16string, and not QString, requiring the use of >

Re: [Development] Views in APIs

On 2020-05-13 11:31, Marco Bubke wrote: auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed AFAIK you can say that a rvalue should not return a reference by using ref-qualified member functions. View getView() const & { return v;} Qt is so many years behind the

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

Nope, that would not be C++ if it wasn’t broken: class C1 { public: std::string_view getMember() const & { return member; } std::string member; }; std::string_view m = C1().getMember(); // compiles! You have to delete the method explicitly: std::string_view getMember() const && =

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

On Wed, 13 May 2020 at 12:37, Marco Bubke wrote: > auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed > AFAIK you can say that a rvalue should not return a reference by using > ref-qualified member functions. > View getView() const & { return v;} However,

Re: [Development] QString and related changes for Qt 6

> On 13 May 2020, at 10:12, Edward Welbourne wrote: > >> Note that adding the QString(char16_t*) constructor introduces this >> ambiguity for the functions that are already overloaded on >> QString+QStringView (and thus today are using QStringView). > > Would it suffice to skip the

Re: [Development] Views in APIs

On 2020-05-13 09:04, Lars Knoll wrote: On 12 May 2020, at 18:59, Marc Mutz wrote: [...] Most other classes: * Only take and return QString This is wrong. By taking a QString in the API of non-string-related APIs, you expose QString as an implementation detail of the class. Think QRegion,

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

auto view3 = myObject.getCopy()[42].getView(); // not safe, copy is destroyed AFAIK you can say that a rvalue should not return a reference by using ref-qualified member functions. View getView() const & { return v;} ___ Development mailing list

[Development] Can your module be included in Qt 6?

Hi, As mentioned earlier on this mailing list [1], Qt 6.0 will have a Structure and Platform Freeze at the end of June. This leaves the open question of what checkpoints are to be met and a dead line. With the help of several people I took the liberty of drafting a check list which would

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

Btw, I actually have an argument for returning a view=) The ongoing c++20 ranges have exactly the same problem with the lifetime issues. For instance, this won’t compile: auto results = std::vector{1, 2, 3, 4, 5, 6} | std::views::filter([](int n){ return n % 2 == 0; }) |

Re: [Development] QString and related changes for Qt 6

On Tue, May 12, 2020 at 02:09:21PM -0700, Thiago Macieira wrote: > On Tuesday, 12 May 2020 10:48:24 PDT Giuseppe D'Angelo via Development wrote: > > What do you do? Adding a QStringView overload will make calls ambiguous, > > removing the QString one will be an ABI break. We need an established >

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

> 13 мая 2020 г., в 09:04, Lars Knoll написал(а): > > The above example is rather weirdly constructed. > > But anyhow, those data lifetime issues when using views as return values > extensively are a lot less obvious to spot when a human reads the code. APIs > should be safe to use

Re: [Development] QString and related changes for Qt 6

On 5/12/20 6:12 PM, Иван Комиссаров wrote: >> So the question is - is it possible to allow to construct QString from >> unicode literal? Giuseppe D'Angelo (12 May 2020 19:48) replied: > "Not yet", but adding a constructor from char16_t to QString makes sense. > > This creates a problem down the

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

On Tue, 12 May 2020 18:59:35 +0200 Marc Mutz via Development wrote: > QString-everywhere cements the naïve CoW world of the > 1990s for yet another decade. CoW naive? Really not, this method is at the heart of many strategic technologies. eg.: * virtual memory used by most of operating

Re: [Development] Views in APIs (was: Re: QString and related changes for Qt 6)

> On 12 May 2020, at 18:59, Marc Mutz wrote: > > Hi Lars, > > Let me pick important points one per email here: > > On 2020-05-12 09:49, Lars Knoll wrote: > [...] >> For String related classes: >> * All methods not taking ownership of the passed arguments take a >> QStringView > > Almost (see

Re: [Development] QString and related changes for Qt 6

> On 12 May 2020, at 23:09, Thiago Macieira wrote: > > On Tuesday, 12 May 2020 10:48:24 PDT Giuseppe D'Angelo via Development wrote: >> What do you do? Adding a QStringView overload will make calls ambiguous, >> removing the QString one will be an ABI break. We need an established >> solution

Re: [Development] QString and related changes for Qt 6

> On 13 May 2020, at 08:14, André Somers wrote: > > > On 12-05-20 22:42, Thiago Macieira wrote: >> >> QStringView::mid(), for example, returns QStringView, but QString::mid() >> returns QString. > _Should_ QString::mid be returning a QString though? Perhaps it should return > a QStringView?

Re: [Development] QString and related changes for Qt 6

> On 12 May 2020, at 23:21, Thiago Macieira wrote: > > On Tuesday, 12 May 2020 08:42:28 PDT Matthew Woehlke wrote: >> How will this work? As I understand, the main advantage to >> QStringLiteral is that it statically encodes the *length* as well as the >> data. This isn't possible with raw

Re: [Development] QString and related changes for Qt 6

> On 12 May 2020, at 22:42, Thiago Macieira wrote: > > On Tuesday, 12 May 2020 09:34:40 PDT Marc Mutz via Development wrote: >> On 2020-05-12 11:31, Jaroslaw Kobus wrote: >>> So, just an idea: instead of repeating the common API part in QString >>> and QStringView, what about making it one

Re: [Development] QString and related changes for Qt 6

On 12-05-20 22:42, Thiago Macieira wrote: QStringView::mid(), for example, returns QStringView, but QString::mid() returns QString. _Should_ QString::mid be returning a QString though? Perhaps it should return a QStringView? André ___ Development