Re: [Development] [Announce] Qt 5.15.12 for VxWorks LTS Commercial released

[Konstantin Ritt]

> Your message has been rejected, probably because you are not
> subscribed to the mailing list and the list's policy is to prohibit
> non-members from posting to it.  If you think that your messages are
> being rejected in error, contact the mailing list owner at
> announce-ow...@qt-project.org.

Nice.
That's what most people call a "spam".

Regards,
Konstantin


пт, 24 февр. 2023 г. в 22:34, Konstantin Ritt :

> How can one develop Qt for VxWorks with this Commercial source
> package, having no paid account?
> Please stop announcing these annoying things to those who were subscribing
> to Qt development ML.
>
> Regards,
> Konstantin
>
>
> пт, 24 февр. 2023 г. в 18:35, List for announcements regarding Qt releases
> and development via Announce via Development :
>
>> Hi all,
>>
>>
>>
>> we have released the VxWorks for Qt 5.15.12 LTS Commercial source package
>> release. Please see the blog post:
>>
>> https://www.qt.io/blog/vxworks-for-qt-5.15.12-released
>>
>>
>>
>> Big thanks to everyone involved!
>>
>>
>>
>> Best regards
>>
>> Tarja Sundqvist
>>
>> Release manager
>> ___
>> Announce mailing list
>> annou...@qt-project.org
>> https://lists.qt-project.org/listinfo/announce
>> --
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Announce] Qt 5.15.12 for VxWorks LTS Commercial released

[Konstantin Ritt]

How can one develop Qt for VxWorks with this Commercial source
package, having no paid account?
Please stop announcing these annoying things to those who were subscribing
to Qt development ML.

Regards,
Konstantin


пт, 24 февр. 2023 г. в 18:35, List for announcements regarding Qt releases
and development via Announce via Development :

> Hi all,
>
>
>
> we have released the VxWorks for Qt 5.15.12 LTS Commercial source package
> release. Please see the blog post:
>
> https://www.qt.io/blog/vxworks-for-qt-5.15.12-released
>
>
>
> Big thanks to everyone involved!
>
>
>
> Best regards
>
> Tarja Sundqvist
>
> Release manager
> ___
> Announce mailing list
> annou...@qt-project.org
> https://lists.qt-project.org/listinfo/announce
> --
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6.2.6 LTS Commercial released

[Konstantin Ritt]

Ignoring a large part of the community IS a problem.
Most people won't say they aren't ok with something. Until it is too late
to say anything at all.

Regards,
Konstantin


вт, 27 сент. 2022 г. в 23:02, Elvis Stansvik :

> Den tis 27 sep. 2022 kl 21:52 skrev Elvis Stansvik :
> >
> > Den tis 27 sep. 2022 kl 21:01 skrev Thiago Macieira <
> thiago.macie...@intel.com>:
> > >
> > > On Tuesday, 27 September 2022 09:48:01 PDT Elvis Stansvik wrote:
> > > > The typical mail here is about development of Qt, and while some of
> > > > those mails may be specialized and only may not be interesting to
> > > > *everyone*, they could potentially be interesting to *anyone* (e.g.
> > > > cover some technical topic they want to learn about etc). I don't
> > > > think that can be said of commercial-only release announcement, which
> > > > are for sure only interesting to a certain subset of subscribers, so
> > > > suggest keeping them on some commercial-only list.
> > >
> > > For me, what's interesting is to know the *date* of the release,
> because it
> > > sets the 12-month timer for a new open source drop.
> >
> > True :)
> >
> > Open source code drops can be announced here, but I guess there's some
> > value in knowing about the first commercial-only releases, for those
> > who want to pencil in the drop date in their calendars.
>
> I guess it's just that I can understand Konstantin's sentiment, since
> it feels kind of unsolicited. When I signed up for this list, I
> solicited Qt development conversations. There is a list for
> announcements after all. It feels like I'm getting a newsletter I
> didn't sign up for, without a way to unsubscribe without losing all
> the Qt dev conversations that I do want to follow.
>
> But if most people are OK with it, no problem. It's not a big deal.
>
> Elvis
>
> >
> > Elvis
> >
> > >
> > > --
> > > 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
> ___
> 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 6.2.6 LTS Commercial released

[Konstantin Ritt]

That's not about Qt development, that's about commercial Qt fork
development.
For commercial users, you have a dedicated commercial-only mailing list(s).

I’m sure you can configure your email client to send all emails with sender
“Konstantin Ritt” to the bin if these messages are irrelevant to you.

Regards,
Konstantin


вт, 27 сент. 2022 г. в 18:18, Volker Hilsheimer :

> Konstantin,
>
> We have users with commercial licenses and access to those releases on
> this mailing list as well. And some of them contribute to Qt, and are
> perhaps happy to find out that a patch they might have contributed is now
> available to them through an official commercial package.
>
> I’m sure you can configure your email client to send all emails with
> subject “.*LTS Commercial released” to the bin if these announcements are
> irrelevant to you.
>
> Volker
>
>
> > On 27 Sep 2022, at 13:28, Konstantin Ritt  wrote:
> >
> > Please stop announcing this kind of updates through the development
> mailing list!
> >
> >
> > Konstantin
> >
> >
> > вт, 27 сент. 2022 г. в 14:20, Tarja Sundqvist :
> > Hi all,
> >
> >
> >
> > we have released Qt 6.2.6 LTS Commercial today. Please see the blog post:
> >
> > https://www.qt.io/blog/commercial-lts-qt-6.2.6-released
> >
> >
> >
> > Big thanks to everyone involved & have nice autumn!
> >
> >
> >
> > Best regards
> >
> > Tarja Sundqvist
> >
> > Release Manager
> >
> >
> >
> > ___
> > 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] Qt 6.2.6 LTS Commercial released

[Konstantin Ritt]

Please stop announcing this kind of updates through the development mailing
list!


Konstantin


вт, 27 сент. 2022 г. в 14:20, Tarja Sundqvist :

> Hi all,
>
>
>
> we have released Qt 6.2.6 LTS Commercial today. Please see the blog post:
>
> https://www.qt.io/blog/commercial-lts-qt-6.2.6-released
>
>
>
> Big thanks to everyone involved & have nice autumn!
>
>
>
> Best regards
>
> Tarja Sundqvist
>
> Release Manager
>
>
> ___
> 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] Redesigning QML value types

[Konstantin Ritt]

This becomes more and more non-intuitive.

  let a: font = f  // copy f because a is value-typed?
  let b = a// copy because a is typed, and b's type is inferred
from a?
  let c = f// ref because f is JS-ish type
  function foo(arg) {
return arg
  }
  let d = foo(b) // ref because f is JS-ish type ? or copy because a is
typed, and b's type is inferred from a?
  let b = d // ref?

Regards,
Konstantin


ср, 21 сент. 2022 г. в 19:45, Ulf Hermann :

> > Generally I feel that all the gritty details in what to do and what
> > not do in qml to have efficient, compiled code, are more and more
> > confusing. There is so much to consider and basically all the
> > documentation about this is hidden in Qt blog posts.
>
> Well, yes. All of this is 10 years late and we have to shoehorn it into
> an existing language with compatibility promises. So, some inconsistency
> cannot be avoided. I'm doing what I can to avoid confusion, though. The
> blog posts are in fact being transformed into regular documentation. It
> takes some time, though.
>
> > Anyway I'd just like to note that, as far as I can remember, type
> > annotation are currently not supported in lambdas (=> syntax).
>
> Indeed not. Type annotations are mostly meant for methods of QML types,
> which cannot be phrased as arrow functions. The only other place where
> they might be beneficial is in inner functions inside bindings or
> methods. The compilers cannot generate efficient code to call those,
> yet. Therefore it doesn't make much sense to annotate them, yet. We'll
> get back to that when we get there. Help is always welcome, by the way.
>
> regards,
> Ulf
> ___
> 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] Commercial-only 6.2 LTS phase starts: Closing the 6.2 branch(es) on 20th April

[Konstantin Ritt]

Hi Tuuka,

By that link I didn't mean QTBUG-102962 exactly, but 23 matching bugs for a
single component (which is not even one of the top-wanted components).
On vanilla 6.2.4, QCamera simply doesn't work on many Android devices. All
these issues were resolved for 6.2.5. Coincident?

> We are no holding back on bug fixes, though.
> so the fix is in Qt 6.3.1
Technically you aren't. But in fact you are!
That is what I called "please stick to unstable, semi-functional versions
of Qt, test them and report bugs".
6.3 brought a bunch of new bugs and regressions, and some of them still
aren't fixed. As for example, look at --
https://bugreports.qt.io/browse/QTBUG-98964?jql=text%20~%20%22Binding%20on%20contentItem%20is%20not%20deferred%20as%20requested%20by%20the%20DeferredPropertyNames%20class%20info%20because%20one%20or%20more%20of%20its%20sub-objects%20contain%20an%20id%22
-- (and not only at QTBUG-98964).
Fixed in 6.3.0? Sure it is. But it is still reproducible in dev...
Maybe it is not really important? Well, I personally can live with it.
Until I get a hang/crash report in release due to this issue...

And that's just a single example of many.
Okay, perhaps I should stick back to 6.2.4, keep my eye on commits
picked-up to mysterious 6.2.5 and apply them manually. Thanks,
cherry-picking monkey is a job I was dreaming of!

When I chose Qt for developing my apps, it was "Code less, create more[,
deploy everywhere]".
I was ok with building Qt from sources when you started selling binaries to
your commercial folks. Waste of an hour of my machine power per several
months was not a big price for stability update.
But we definitely didn't choose to be your free testing crowd!


Regards,
Unhappy monkey


пн, 19 сент. 2022 г. в 20:15, Tuukka Turunen :

> Hi Konstantin,
>
>
>
> I am sorry to hear that you are unhappy with Qt 6.2 moving to the
> commercial-only long-term-support phase with release of Qt 6.2.5.
>
>
>
> We are no holding back on bug fixes, though.
>
>
>
> All applicable bug fixes go to dev and are picked to all active branches.
> The fix to QTBUG-102962 was merged to 6.3 branch at the end of April, so
> the fix is in Qt 6.3.1 released in June, as well as in the latest Qt 6.3.2
> release as well as the soon-to-be released Qt 6.4.0 release.
>
>
>
> Yours,
>
>
>
> Tuukka
>
>
>
>
>
> *From: *Development  on behalf of
> Konstantin Ritt 
> *Date: *Monday, 19. September 2022 at 15.46
> *To: *development@qt-project.org 
> *Subject: *Re: [Development] Commercial-only 6.2 LTS phase starts:
> Closing the 6.2 branch(es) on 20th April
>
> It is probably the most destructive and annoying thing you did!
>
>
>
> I'll try to rephrase what you said in that announcement: "Dear community,
> please stick to unstable, semi-functional versions of Qt, test them and
> report bugs you've found (for free), so we could better support our
> valuable customers (not you). Your contributions are welcomed (but you have
> to pay some money to us to get any gain from your fixes, unless you're ok
> with sticking to some newer semi-functional version of Qt). Thanks for
> everything you did for Qt project (we don't appreciate that). That's how
> Open Governance works, b???h!"
>
>
>
> Am I exaggerating? Let's briefly look at
> https://bugreports.qt.io/browse/QTBUG-102962?jql=project%20%3D%20QTBUG%20AND%20component%20%3D%20Multimedia%20and%20fixVersion%20%3D%206.2.5
>
>
>
> Okay, you won: I'll buy your commercial license, just to share your
> commercial-only repositories to everyone!
>
>
> Regards,
> Konstantin
>
>
>
>
>
> ср, 20 апр. 2022 г. в 10:01, Tarja Sundqvist :
>
> Hi,
>
>
>
> With Qt 6.3.0 released and the first patch release (Qt 6.3.1) coming soon,
> it is time to enter the commercial-only LTS phase for Qt 6.2 LTS. All the
> existing 6.2 branches remain publicly visible, but they are closed for new
> commits and cherry-picks. The exception is the Qt WebEngine, which has a
> 3rd party LGPL dependency.
>
>
>
> Closing happens today, 20th April 2022. After this, the cherry-picks go to
> another repository that will be available only for the commercial license
> holders. We will arrange repository access to the commercial license
> holders, so in addition to the official releases, it is possible to use the
> repositories.
>
>
>
> The first commercial-only Qt 6.2.5 LTS patch release is planned to be
> released in May.
>
>
>
> The external module maintainers that have access to the Qt 5.15
> commercial-only repositories, will also have access to the Qt 6.2
> commercial-only repositories. If you notice that you don’t have access even
> if you should have

Re: [Development] Commercial-only 6.2 LTS phase starts: Closing the 6.2 branch(es) on 20th April

[Konstantin Ritt]

It is probably the most destructive and annoying thing you did!

I'll try to rephrase what you said in that announcement: "Dear community,
please stick to unstable, semi-functional versions of Qt, test them and
report bugs you've found (for free), so we could better support our
valuable customers (not you). Your contributions are welcomed (but you have
to pay some money to us to get any gain from your fixes, unless you're ok
with sticking to some newer semi-functional version of Qt). Thanks for
everything you did for Qt project (we don't appreciate that). That's how
Open Governance works, b???h!"

Am I exaggerating? Let's briefly look at
https://bugreports.qt.io/browse/QTBUG-102962?jql=project%20%3D%20QTBUG%20AND%20component%20%3D%20Multimedia%20and%20fixVersion%20%3D%206.2.5

Okay, you won: I'll buy your commercial license, just to share your
commercial-only repositories to everyone!

Regards,
Konstantin


ср, 20 апр. 2022 г. в 10:01, Tarja Sundqvist :

> Hi,
>
>
>
> With Qt 6.3.0 released and the first patch release (Qt 6.3.1) coming soon,
> it is time to enter the commercial-only LTS phase for Qt 6.2 LTS. All the
> existing 6.2 branches remain publicly visible, but they are closed for new
> commits and cherry-picks. The exception is the Qt WebEngine, which has a
> 3rd party LGPL dependency.
>
>
>
> Closing happens today, 20th April 2022. After this, the cherry-picks go to
> another repository that will be available only for the commercial license
> holders. We will arrange repository access to the commercial license
> holders, so in addition to the official releases, it is possible to use the
> repositories.
>
>
>
> The first commercial-only Qt 6.2.5 LTS patch release is planned to be
> released in May.
>
>
>
> The external module maintainers that have access to the Qt 5.15
> commercial-only repositories, will also have access to the Qt 6.2
> commercial-only repositories. If you notice that you don’t have access even
> if you should have, please contact me (tarja.sundqv...@qt.io) as I am the
> release manager for the commercial-only LTS releases.
>
>
>
> Best regards,
>
> Tarja Sundqvist
>
> Release manager
> ___
> 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] Maintainance Tool

[Konstantin Ritt]

The bug is fixed now.


Regards,
Konstantin


вс, 6 мар. 2022 г. в 16:18, Konstantin Ritt :

> Volker:
>>
>> On Fri, Mar 4, 2022 at 8:56 PM Konstantin Ritt  wrote:
>>
>>> Oh well, my codereview.qt-project.org account is also inaccessible.
>>> This is not about your attitude towards RU gov, but your attitude towards
>>> me personally.
>>>
>>> [image: sshot.png]
>>>
>>> Sure I can use Tor to log-in from some other IP. But I wouldn't, that's
>>> your fault not mine.
>>>
>>> P.S. Do I have a moral right to put my -2 to contributions not due to
>>> the code quality but due to their author's mother language, country or
>>> nationality. Do *you* have a moral right to hit my rights due to my mother
>>> language, country or nationality?
>>>
>>> Konstantin
>>>
>>
> It could be a simple bug introduced in haste. Tuukka said they'll check
> what causes this.
>
>
> Regards,
> Konstantin
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainance Tool

[Konstantin Ritt]

For those who have experienced inconvenience due to these blockings, I
propose to gather at some public site and create binaries repo driven by
community, not by political influences.


Regards,
Konstantin


пт, 4 мар. 2022 г. в 18:01, Andy Shaw :

> Hi,
>
>
>
> It is because your IP is detected to be in a country we do not allow
> downloads. If you are not able to access something you have purchased
> then let me know and I will get someone to get in touch with you directly
> about this. Otherwise, for the time being, this IP block will be in place.
>
>
>
> Regards,
>
> Andy
>
>
>
> *From:* Development  *On Behalf Of 
> *Konstantin
> Ritt
> *Sent:* Friday, March 4, 2022 1:43 PM
> *To:* Konstantin Shegunov 
> *Cc:* Qt development mailing list 
> *Subject:* Re: [Development] Maintainance Tool
>
>
>
> I don't care. I need some explanations here, at public dev ML.
>
>
> Regards,
> Konstantin
>
>
>
>
>
> пт, 4 мар. 2022 г. в 15:27, Konstantin Shegunov :
>
> Hi,
> I imagine you're using a russian IP address, so this[1] should shed some
> light on the matter.
>
> Kind regards,
> Konstantin.
>
> [1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainance Tool

[Konstantin Ritt]

>
> Volker:
>
> On Fri, Mar 4, 2022 at 8:56 PM Konstantin Ritt  wrote:
>
>> Oh well, my codereview.qt-project.org account is also inaccessible. This
>> is not about your attitude towards RU gov, but your attitude towards me
>> personally.
>>
>> [image: sshot.png]
>>
>> Sure I can use Tor to log-in from some other IP. But I wouldn't, that's
>> your fault not mine.
>>
>> P.S. Do I have a moral right to put my -2 to contributions not due to the
>> code quality but due to their author's mother language, country or
>> nationality. Do *you* have a moral right to hit my rights due to my mother
>> language, country or nationality?
>>
>> Konstantin
>>
>
It could be a simple bug introduced in haste. Tuukka said they'll check
what causes this.


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

Re: [Development] Maintainance Tool

[Konstantin Ritt]

> The problem is not the open source, it's that providing the downloads is a
> business (it has a cost for the company offering them, for example). Then
> business rules apply.
>
> The same way that obtaining sources for (L)GPL content you got as a binary
> is
> also a business obligation and must be honoured.


Maybe you're right.
Is blocking my account authentication a business obligation too?


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

Re: [Development] Maintainance Tool

[Konstantin Ritt]

Oh well, my codereview.qt-project.org account is also inaccessible. This is
not about your attitude towards RU gov, but your attitude towards me
personally.

[image: sshot.png]

Sure I can use Tor to log-in from some other IP. But I wouldn't, that's
your fault not mine.

P.S. Do I have a moral right to put my -2 to contributions not due to the
code quality but due to their author's mother language, country or
nationality. Do *you* have a moral right to hit my rights due to my mother
language, country or nationality?

Konstantin


пт, 4 мар. 2022 г. в 19:39, evilruff :

> Freedom is an ability to make an own judgments on things with a follow-up
> decisions which are explained rather then following popular trends without
> even close understanding the subject..
>
> I am using Qt from version 1.33, and was a customer of TrollTech since
> then..
>
> But I hardly remember Qt in any way followed any political agenda. Out of
> curiosity can you announce full list of blocked countries, may be North
> Korea or Iran? Just wondering if you block Crimea users after 2014? There
> were hell of the wars and military conflicts around the world since 2000,
> and I don't think that it was a matter for Qt ever.
>
> I mean really, its open source thing, there are things like VPN, proxies..
> we all here in IT world, practically it will mean nothing at all rather
> then adding oil in already started fire..
>
> Declaring sanctions that way is nothing then escalating conflict, my view
> on this that in reallity its a demand of 'large scale' sponsors and
> companies supporting Qt, but do you truly think it has anything about
> freedom, democracy etc?
>
> It would be much better to say - listen, we are open source and prefer to
> stay out of politics as we know nothing about that, but we are company and
> majority of our top customers pushed such decision and we decided that our
> commonwealth is more important... I mean it could be good or bad but at
> least it will be true...
>
> Regards
> Yuri
>
>  Исходное сообщение 
> От: Denis Shienkov 
> Дата: 04.03.2022 7:09 ПП (GMT+03:00)
> Кому: development@qt-project.org
> Тема: Re: [Development] Maintainance Tool
>
> Yes, it's kind of hysterical. I don't understand what the Qt company wants
> to achieve in the end? What is the purpose?
>
> So far, it looks more like a clowning: "the circus is gone, but the clowns
> remain."
>
> Qt Company can't stick your tongue out of the USA ass? :)
>
> I had a higher opinion of Qt Company up to this point ...
>
> This is not serious somehow, some kind of kindergarten. LOL. :)
>
> BR, Denis
>
>
> 04.03.2022 18:58, Konstantin Ritt пишет:
>
> As long as I can fetch sources I wouldn't take any actions.
> But anyways, bringing your own political preferences to the open source
> world rules is a quite hypocritical move.
> In the adult world, it doesn't matter if your community members /
> contributors have a skin tone, political or sexual preferences not like
> yours, or an IP address that belongs to some particular territory.
>
> Disappointed Konstantin
>
>
> пт, 4 мар. 2022 г. в 18:01, Andy Shaw :
>
>> Hi,
>>
>>
>>
>> It is because your IP is detected to be in a country we do not allow
>> downloads. If you are not able to access something you have purchased
>> then let me know and I will get someone to get in touch with you directly
>> about this. Otherwise, for the time being, this IP block will be in place.
>>
>>
>>
>> Regards,
>>
>> Andy
>>
>>
>>
>> *From:* Development  *On Behalf Of 
>> *Konstantin
>> Ritt
>> *Sent:* Friday, March 4, 2022 1:43 PM
>> *To:* Konstantin Shegunov 
>> *Cc:* Qt development mailing list 
>> *Subject:* Re: [Development] Maintainance Tool
>>
>>
>>
>> I don't care. I need some explanations here, at public dev ML.
>>
>>
>> Regards,
>> Konstantin
>>
>>
>>
>>
>>
>> пт, 4 мар. 2022 г. в 15:27, Konstantin Shegunov :
>>
>> Hi,
>> I imagine you're using a russian IP address, so this[1] should shed some
>> light on the matter.
>>
>> Kind regards,
>> Konstantin.
>>
>> [1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia
>>
>>
> ___
> Development mailing 
> listDevelopment@qt-project.orghttps://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] Maintainance Tool

[Konstantin Ritt]

Plz restrain your emotions. There is no reason to spread hysteria even more.

Konstantin


пт, 4 мар. 2022 г. в 19:09, Denis Shienkov :

> Yes, it's kind of hysterical. I don't understand what the Qt company wants
> to achieve in the end? What is the purpose?
>
> So far, it looks more like a clowning: "the circus is gone, but the clowns
> remain."
>
> Qt Company can't stick your tongue out of the USA ass? :)
>
> I had a higher opinion of Qt Company up to this point ...
>
> This is not serious somehow, some kind of kindergarten. LOL. :)
>
> BR, Denis
>
>
> 04.03.2022 18:58, Konstantin Ritt пишет:
>
> As long as I can fetch sources I wouldn't take any actions.
> But anyways, bringing your own political preferences to the open source
> world rules is a quite hypocritical move.
> In the adult world, it doesn't matter if your community members /
> contributors have a skin tone, political or sexual preferences not like
> yours, or an IP address that belongs to some particular territory.
>
> Disappointed Konstantin
>
>
> пт, 4 мар. 2022 г. в 18:01, Andy Shaw :
>
>> Hi,
>>
>>
>>
>> It is because your IP is detected to be in a country we do not allow
>> downloads. If you are not able to access something you have purchased
>> then let me know and I will get someone to get in touch with you directly
>> about this. Otherwise, for the time being, this IP block will be in place.
>>
>>
>>
>> Regards,
>>
>> Andy
>>
>>
>>
>> *From:* Development  *On Behalf Of 
>> *Konstantin
>> Ritt
>> *Sent:* Friday, March 4, 2022 1:43 PM
>> *To:* Konstantin Shegunov 
>> *Cc:* Qt development mailing list 
>> *Subject:* Re: [Development] Maintainance Tool
>>
>>
>>
>> I don't care. I need some explanations here, at public dev ML.
>>
>>
>> Regards,
>> Konstantin
>>
>>
>>
>>
>>
>> пт, 4 мар. 2022 г. в 15:27, Konstantin Shegunov :
>>
>> Hi,
>> I imagine you're using a russian IP address, so this[1] should shed some
>> light on the matter.
>>
>> Kind regards,
>> Konstantin.
>>
>> [1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia
>>
>>
> ___
> Development mailing 
> listDevelopment@qt-project.orghttps://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] Maintainance Tool

[Konstantin Ritt]

As long as I can fetch sources I wouldn't take any actions.
But anyways, bringing your own political preferences to the open source
world rules is a quite hypocritical move.
In the adult world, it doesn't matter if your community members /
contributors have a skin tone, political or sexual preferences not like
yours, or an IP address that belongs to some particular territory.

Disappointed Konstantin


пт, 4 мар. 2022 г. в 18:01, Andy Shaw :

> Hi,
>
>
>
> It is because your IP is detected to be in a country we do not allow
> downloads. If you are not able to access something you have purchased
> then let me know and I will get someone to get in touch with you directly
> about this. Otherwise, for the time being, this IP block will be in place.
>
>
>
> Regards,
>
> Andy
>
>
>
> *From:* Development  *On Behalf Of 
> *Konstantin
> Ritt
> *Sent:* Friday, March 4, 2022 1:43 PM
> *To:* Konstantin Shegunov 
> *Cc:* Qt development mailing list 
> *Subject:* Re: [Development] Maintainance Tool
>
>
>
> I don't care. I need some explanations here, at public dev ML.
>
>
> Regards,
> Konstantin
>
>
>
>
>
> пт, 4 мар. 2022 г. в 15:27, Konstantin Shegunov :
>
> Hi,
> I imagine you're using a russian IP address, so this[1] should shed some
> light on the matter.
>
> Kind regards,
> Konstantin.
>
> [1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia
>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainance Tool

[Konstantin Ritt]

I don't care. I need some explanations here, at public dev ML.

Regards,
Konstantin


пт, 4 мар. 2022 г. в 15:27, Konstantin Shegunov :

> Hi,
> I imagine you're using a russian IP address, so this[1] should shed some
> light on the matter.
>
> Kind regards,
> Konstantin.
>
> [1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Maintainance Tool

[Konstantin Ritt]

> Installation from this IP address is not allowed

Are you joking? What's going on there?!


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

Re: [Development] Removing the global static QObject from QPixmapCache

[Konstantin Ritt]

Recreating QGuiApplication is not a common case, ever.
Plus no one said the QPixmap cache would be shared across QGuiApplication
instances. I don't think that was the intention. In fact that could be used
to access some data of another "run" meant to be destroyed/erased/forgotten.

Using QThreadStorage or at least qAddPostRoutine() sounds like a correct
solution.


Regards,
Konstantin


вс, 30 мая 2021 г. в 14:04, Giuseppe D'Angelo via Development <
development@qt-project.org>:

> Hi,
>
> On 30/05/2021 07:28, Sze Howe Koh wrote:
> >
> > So, I propose replacing QGlobalStatic with
> > QPointer as a simple self-cleaning singleton, and replacing
> > access to the global variable with QPMCache::instance():
>
> I'd tend to agree with idea, but not with the specific solution. You may
> want
>
> 1) to keep the cache alive across multiple QGA::exec() invocations,
> 2) to destroy it only when QGA gets destroyed,
> 3) to recreate it if QGA itself gets recreated.
>
> A very simple solution is to make the cache a member of QGA(P), create
> it lazily if needed (like Q_G_S does; but I've got the funny feeling
> that the pixmap cache is used in 100% Qt apps, so maybe that's not even
> needed), and kill it in ~QGA.
>
> > I believe this approach should also take care of the ancient QTBUG-21807
> [5]
>
> This has already been fixed, actually, in 5.0:
>
> >
> https://github.com/qt/qtbase/commit/6615dc1370300188f2979fb2c6b8eaa6049d5824
>
>
> 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
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial LTS Qt 5.15.4 released

[Konstantin Ritt]

Wrong list? AFAIK, this mailing list is about developing Qt, not about
promoting some closed-source products ;p

Regards,
Konstantin


ср, 12 мая 2021 г. в 15:05, Tarja Sundqvist :

> Hi all,
>
>
>
> We have released Commercial LTS Qt 5.15.4 today! Please read more
> information from the release blog post:
> https://www.qt.io/blog/commercial-lts-qt-5.15.4-released
>
>
>
> Big thanks for everyone involved!
>
>
>
> Best regards
>
> Tarja Sundqvist
>
> Release Manager
> ___
> 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] QMetaType support for QFuture

[Konstantin Ritt]

Can't we simply `QFutureInterface(const QFuture )` to get that
future's QFutureInterface, w/o any QtPrivate:: ugliness?


Regards,
Konstantin


сб, 8 мая 2021 г. в 11:30, Sona Kurazyan :

> Hi Konstantin,
>
>
>
> QFuture has a constructor for QFuture from QFuture,  see
> https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/thread/qfuture.h#n82,
> so you don’t even need to use the broken qToVoidFuture() method. I’ll
> probably remove it, since it was always broken and couldn’t be ever used.
>
> I can see that in some special use-cases having access to QFuture’s
> internals might be useful, but this is not something we would recommend to
> do to all users. That’s why, I think, adding an API that gives access to
> QFuture’s d-ptr (as it was suggested earlier) might be an option.
>
>
>
> Best regards,
>
> Sona
>
>
>
> *From:* Konstantin Ritt 
> *Sent:* Saturday, May 8, 2021 2:29 AM
> *To:* Arno Rehn 
> *Cc:* Sona Kurazyan ; Qt development mailing list <
> development@qt-project.org>
> *Subject:* Re: [Development] QMetaType support for QFuture
>
>
>
> I was implementing a similar feature few years ago and had the same
> problem with QFuture internals --
> https://codereview.qt-project.org/c/qt/qtbase/+/210243
>
> As there was no interest in making those better, I had to hack it in a way
> I won't promote here ;p
>
> But since QFuture took a new life with QPromise, it becomes even more
> useful than before and deserves some improvements IMO.
>
> Maybe we could add a public accessor to future's d via
> QFutureInterfaceBase? Will that be acceptable?
>
>
> Regards,
> Konstantin
>
>
>
>
>
> пт, 7 мая 2021 г. в 19:28, Arno Rehn :
>
> Hi Sona,
>
> On 07.05.21 17:11, Sona Kurazyan wrote:
> > You could use the QFutureInterfaceBase (non-templated) class directly
> > to build a type-erased future, that's basically what QFuture is using
> > underneath. Although it's internal (not documented and is considered
> > to be private), but it's declared in a public header
> > (qfutureinterface.h) and you can still use it. QFutureInterfaceBase's
> > methods for accessing its internals are public (with a few exceptions
> > that you probably won't need to use). I hope that helps.
>
> Yep, that's what I thought as well. But I cannot get it from an existing
> QFuture because it's a private member. We could add some private API to
> extract the QFutureInterfaceBase, however.
>
> Anyway, I think I'll have to add some QMetaType magic anyway for this to
> work. In QtWebChannel, we get the method return value wrapped in a
> QVariant, so the QFuture is wrapped in a QVariant. From there, I
> cannot extract the QFutureInterfaceBase in any way.
>
> I *could* just memcpy from QVariant's data pointer to a
> QFutureInterfaceBase*, but I'm pretty sure that this is UB.
>
> Any pointer where to start?
>
> Regards,
> Arno
>
> --
> Arno Rehn
> Tel +49 89 189 166 0
> Fax +49 89 189 166 111
> a.r...@menlosystems.com
> www.menlosystems.com
>
> Menlo Systems GmbH
> Bunsenstrasse 5, D-82152 Martinsried, Germany
> Amtsgericht München HRB 138145
> Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
> USt.-IdNr. DE217772017, St.-Nr. 14316170324
> ___
> 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] QMetaType support for QFuture

[Konstantin Ritt]

I was implementing a similar feature few years ago and had the same problem
with QFuture internals --
https://codereview.qt-project.org/c/qt/qtbase/+/210243
As there was no interest in making those better, I had to hack it in a way
I won't promote here ;p
But since QFuture took a new life with QPromise, it becomes even more
useful than before and deserves some improvements IMO.
Maybe we could add a public accessor to future's d via
QFutureInterfaceBase? Will that be acceptable?

Regards,
Konstantin


пт, 7 мая 2021 г. в 19:28, Arno Rehn :

> Hi Sona,
>
> On 07.05.21 17:11, Sona Kurazyan wrote:
> > You could use the QFutureInterfaceBase (non-templated) class directly
> > to build a type-erased future, that's basically what QFuture is using
> > underneath. Although it's internal (not documented and is considered
> > to be private), but it's declared in a public header
> > (qfutureinterface.h) and you can still use it. QFutureInterfaceBase's
> > methods for accessing its internals are public (with a few exceptions
> > that you probably won't need to use). I hope that helps.
>
> Yep, that's what I thought as well. But I cannot get it from an existing
> QFuture because it's a private member. We could add some private API to
> extract the QFutureInterfaceBase, however.
>
> Anyway, I think I'll have to add some QMetaType magic anyway for this to
> work. In QtWebChannel, we get the method return value wrapped in a
> QVariant, so the QFuture is wrapped in a QVariant. From there, I
> cannot extract the QFutureInterfaceBase in any way.
>
> I *could* just memcpy from QVariant's data pointer to a
> QFutureInterfaceBase*, but I'm pretty sure that this is UB.
>
> Any pointer where to start?
>
> Regards,
> Arno
>
> --
> Arno Rehn
> Tel +49 89 189 166 0
> Fax +49 89 189 166 111
> a.r...@menlosystems.com
> www.menlosystems.com
>
> Menlo Systems GmbH
> Bunsenstrasse 5, D-82152 Martinsried, Germany
> Amtsgericht München HRB 138145
> Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth
> USt.-IdNr. DE217772017, St.-Nr. 14316170324
> ___
> 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] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Konstantin Ritt]

Tend to agree with Thiago.
If there is a decision to close 5.15 sources, there'll be no more work from
external/unpaid contributors.

Regards,
Konstantin


пн, 4 янв. 2021 г. в 15:21, Thiago Macieira :

> On Monday, 4 January 2021 07:55:03 -03 Tuukka Turunen wrote:
> > We can arrange access for external module maintainers to the
> commercial-only
> > repositories. If there is interest, please contact me or Tarja Sundqvist
> > tarja.sundqv...@qt.io who is the release
> > manager for the commercial-only LTS releases.
>
> There is no interest in on part.
>
> That means I will not be participating in the development of those fixes,
> commenting on what's appropriate or not, reviewing backports, or bug
> reports.
> In fact, bug reports that cannot be reproduced on 6.0 will also be closed.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> 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] Applications using -fno-rtti

[Konstantin Ritt]

> I think we then had discussions when moving from Qt 4 to Qt 5, that we
will start requiring RTTI.

However this was never promoted, and now you're saying people who ported
their projects with no-rtti to Qt5 had to enable rtti years ago or expect
crashes?)

Thanks to Alberto for pointing this issue now, when the majority didn't
switch to the new LTS yet.
I, for example, didn't know the issue with dynamic_cast across dll
boundaries is not an issue anymore.

Plz make sure the documentation is up to date and `CONFIG += rtti_off` does
nothing as of 5.15.

Regards,
Konstantin


вс, 21 июн. 2020 г. в 14:23, Lars Knoll :

>
>
> > On 21 Jun 2020, at 13:10, Giuseppe D'Angelo via Development <
> development@qt-project.org> wrote:
> >
> > Il 20/06/20 22:45, Thiago Macieira ha scritto:
> >> On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote:
> >>> I think I missed an announcement about Qt applications having to use
> >>> RTTI; on the opposite, I thought that the whole point of QMetaObject
> was
> >>> not to require RTTI support; has this changed?
> >> As you can see from the commit, no provision was made for no-RTTI
> builds. I
> >> don't think they've ben allowed since 5.0.
> >
> > The Qt coding policy document still says that no RTTI facilities are
> allowed within Qt:
> >
> >> https://wiki.qt.io/Coding_Conventions
> >
> > (Unchanged since 2015; before, I'm sure that document was somewhere
> else, with the same contents regarding this matter.)
> >
> > Where/when was such a change of policy decided?
>
> We didn’t want it in earlier versions of Qt for mainly two reasons. Early
> implementations had quite an overhead on library size, and dynamic_cast
> didn’t work reliable between DLL boundaries on Windows. Both problems have
> gone away many years ago.
>
> I have to go by what I remember now, but I think we then had discussions
> when moving from Qt 4 to Qt 5, that we will start requiring RTTI. The
> reasons where that dynamic_cast<> and typeid require it and it has very
> little overhead on library size (as opposed to exceptions which are still
> optional). By that time (or maybe even earlier), we also started compiling
> Qt with RTTI enabled on all platforms.
>
> But it looks like nobody ever adjusted the wiki page :/
>
> We are making use of dynamic_cast and typeid in Qt nowadays, so I guess
> it’s high time we adjust the wiki.
>
> Cheers,
> Lars
>
> ___
> 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] QUtf8String{, View}

[Konstantin Ritt]

I facing a discussion like this every couple of months ;)

Yes, we should have a b with accent, cause it is exactly what the
programmer asked QString for; it is not our fault if b with accent is not
what he meant to get after replace.
QString (like any other tool) must not be used blindly or with zero
knowledge about what it operates on and what the expected result is.

s.length() - is not about amount of characters in the string; s.at(i) -
does not return the i'th character in the string; and surely
QUtf(8|32)String.replace('a', 'b') won't behave any "better" (I mean there
won't be any magic behind the scenes that would save some idiot from
writing some dumb code).

Regards,
Konstantin


сб, 16 мая 2020 г. в 19:17, Thiago Macieira :

> On sábado, 16 de maio de 2020 08:52:19 PDT Arnaud Clère wrote:
> > Regarding the relevance of a QUtf8String, I feel like it would not be so
> > useful unless it allows to view its content as QChar instead of char (or
> > char8_t) since handling multibyte characters is so error prone. At least
> a
> > QChar handles most unicode characters as single entities...
>
> QUtf8StringIterator can be easily added to extract Unicode codepoints from
> the
> UTF-8 string like QStringIterator exists for the same in UTF-16.
>
> Usually, though, this means you're doing something wrong. Grapheme
> clusters
> can span multiple codepoints. Unless you're doing text shaping, you
> probably
> don't need them. And if you don't need them, why do you care about
> codepoints
> in the first place?
>
> That opens a philosophical question. In:
>
> QString s = u"a a\u0301"; // U+0301 COMBINING ACUTE ACCENT
> s.replace('a', 'b');
>
> Should we now have a b with accent? (b́)
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] Configuring Qt VS Tools to auto generate .qm files from .ts files

[Konstantin Ritt]

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. Partridge <
david.partri...@perdrix.co.uk>:

> 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 up with was much
> less
> sophisticated.  I'd placed my .ts files in an i18n directory under my VS
> project, and added a Custom Build step to be run before QTPrepare.
>
> This simply did: cd i18n && for %%f in (*.ts) do
> ($(QtInstallDir)\bin\lrelease %%f)
>
> I'm sure there must be a better way to achieve this, so my question is what
> is the recommended way to do this,
>
> Many thanks
> David
>
> ___
> 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] Thank you for qScopeGuard

[Konstantin Ritt]

Ah I see Q_DISABLE_COPY(QScopeGuard), so perhaps that's the docu issue.

Regards,
Konstantin


пт, 13 мар. 2020 г. в 18:38, Konstantin Ritt :

> I just noticed the documentation says
> > The callable shouldn't throw when executed, copied or moved.
> , which brings a question: is there really a particular reason to copy
> QScopeGuard instance? what the expected behavior for the instance copy
> then, call f in some other place?
>
> Regards,
> Konstantin
>
>
> пт, 21 февр. 2020 г. в 20:58, Thiago Macieira :
>
>> On Friday, 21 February 2020 06:02:29 PST NIkolai Marchenko wrote:
>> > it's definitely neat, but it's nothing that you can't do with pure c++
>> > though. It's just qt's native implementation of score guard pattern.
>> Tbh I
>> > didn't even know it existed because I use my own scope guarder class.
>>
>> The reason we added it was because we needed and the Standard Library
>> equivalent isn't (wasn't) available in all platforms Qt needed to be
>> compiled
>> on.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel System Software Products
>>
>>
>>
>> ___
>> 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] Thank you for qScopeGuard

[Konstantin Ritt]

I just noticed the documentation says
> The callable shouldn't throw when executed, copied or moved.
, which brings a question: is there really a particular reason to copy
QScopeGuard instance? what the expected behavior for the instance copy
then, call f in some other place?

Regards,
Konstantin


пт, 21 февр. 2020 г. в 20:58, Thiago Macieira :

> On Friday, 21 February 2020 06:02:29 PST NIkolai Marchenko wrote:
> > it's definitely neat, but it's nothing that you can't do with pure c++
> > though. It's just qt's native implementation of score guard pattern. Tbh
> I
> > didn't even know it existed because I use my own scope guarder class.
>
> The reason we added it was because we needed and the Standard Library
> equivalent isn't (wasn't) available in all platforms Qt needed to be
> compiled
> on.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Konstantin Ritt]

Just for clarity: systemd has worked around this issue back in 2019 IIRC ,
once the issue has been widely reported and confirmed. Did that allow the
user to boot his linux? Yes, the user is now able to boot into his shiny
and fast (yet insecure and highly vulnerable) operation system. Months
later, do we (Qt) REALLY have to be the only "secure" citizen in the
0x world? If so, then what about ASLR, SSP and other techniques
aimed to protect your lovely lib/app/os from ACE but can not (due to broken
HW RNG, which the user could never know about)?!


Regards,
Konstantin


ср, 19 февр. 2020 г. в 18:26, Konstantin Ritt :

> Should we ever try to work around issues caused by broken CPUs? Maybe we
> should warn the user instead (with big red banner) and decline to install
> anything at all?
>
> >  (or buy Intel)
>
> Or let's maybe also try to work around Meltdown and Spectre on i, just for
> symmetry? ;)
>
> Regards,
> Konstantin
>
>
> ср, 19 февр. 2020 г. в 01:51, Thiago Macieira :
>
>> On Tuesday, 18 February 2020 05:36:56 PST Sze Howe Koh wrote:
>> > > Christian Kandeler (18 February 2020 12:59) replied
>> > >
>> > > > Probably the same as https://bugreports.qt.io/browse/QTBUG-77375.
>>
>> Also https://bugreports.qt.io/browse/QTBUG-70606, which is when I
>> reported the
>> problem to AMD, but we did not introduce a workaround since we didn't
>> know it
>> was this widespread.
>>
>> > > Which version was this encountered in ?
>> > >
>> >
>> > Judging from the screenshots, it's the latest and greatest version of
>> > the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1]
>>
>> Okay, but what version of Qt is the Qt Installer using? Installer team,
>> can
>> you check?
>>
>> Also, anyone affected, PLEASE upgrade your BIOS right now. Your system is
>> insecure. (or buy Intel)
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel System Software Products
>>
>>
>>
>> ___
>> 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] Broken RNG on AMD Ryzen CPUs affect QTemporaryFile, Qt IFW

[Konstantin Ritt]

Should we ever try to work around issues caused by broken CPUs? Maybe we
should warn the user instead (with big red banner) and decline to install
anything at all?

>  (or buy Intel)

Or let's maybe also try to work around Meltdown and Spectre on i, just for
symmetry? ;)

Regards,
Konstantin


ср, 19 февр. 2020 г. в 01:51, Thiago Macieira :

> On Tuesday, 18 February 2020 05:36:56 PST Sze Howe Koh wrote:
> > > Christian Kandeler (18 February 2020 12:59) replied
> > >
> > > > Probably the same as https://bugreports.qt.io/browse/QTBUG-77375.
>
> Also https://bugreports.qt.io/browse/QTBUG-70606, which is when I
> reported the
> problem to AMD, but we did not introduce a workaround since we didn't know
> it
> was this widespread.
>
> > > Which version was this encountered in ?
> > >
> >
> > Judging from the screenshots, it's the latest and greatest version of
> > the Qt installer (qt-opensource-windows-x86-5.14.1.exe) [1]
>
> Okay, but what version of Qt is the Qt Installer using? Installer team,
> can
> you check?
>
> Also, anyone affected, PLEASE upgrade your BIOS right now. Your system is
> insecure. (or buy Intel)
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] Oslo, we have a problem [char8_t]

[Konstantin Ritt]

Just checked the implementation (thanks to woboq, once again) and you're
right. These are completely unacceptable.

Konstantin

пн, 8 июл. 2019 г., 20:28 Thiago Macieira :

> On Monday, 8 July 2019 10:53:42 -03 Konstantin Ritt wrote:
> > > See my reply to Marc: users want US-ASCII case-insensitive text
> matching
> > > and
> > > case folding routines, for network protocols that are US-ASCII case-
> > > insensitive (DNS, IRC, etc.).
> >
> > That strnicmp() and std::toupper()/std::tolower() is exactly what for.
>
> No, those are exactly what they are NOT for.
>
> First, those are locale-dependent and should not be used unless you
> control
> the locale or you specifically want to treat your 8-bit content under the
> system's locale codec. On most modern Unix systems, that's UTF-8. But it's
> not
> uncommon to find applications run with LC_ALL=C, which force those
> functions
> to US-ASCII.
>
> And then there's tr_TR.UTF-8, which causes strnicmp("I", "i") != 0. If
> this is
> what you want, great. Just be careful when using it and expecting US-ASCII
> behaviour, like when parsing the IRC protocol. There used to be an old bug
> in
> ksirc that if you joined channel #irc, it would also join #ırc and then
> further open tabs for #Irc and #İrc depending on messages you received.
>
> Finally, std::toupper and std::tolower are FLAWED BY DESIGN. Do not use
> them,
> ever. Uppercasing and lowercasing are string functions, any API that
> returns a
> single character is flawed. SG16 means to fix that in the new std::text
> functionality.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] Oslo, we have a problem [char8_t]

[Konstantin Ritt]

пн, 8 июл. 2019 г., 16:43 Thiago Macieira :

> On Monday, 8 July 2019 04:38:28 -03 Konstantin Ritt wrote:
> > Perhaps there is a particular reason for the user to manipulate binary
> data
> > as if it were a string? So give him that string, QString.
>
> See my reply to Marc: users want US-ASCII case-insensitive text matching
> and
> case folding routines, for network protocols that are US-ASCII case-
> insensitive (DNS, IRC, etc.).
>

That strnicmp() and std::toupper()/std::tolower() is exactly what for.


Konstantin



> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] Oslo, we have a problem [char8_t]

[Konstantin Ritt]

пн, 8 июл. 2019 г., 5:44 Thiago Macieira :

> On Sunday, 7 July 2019 23:26:40 -03 Konstantin Ritt wrote:
> > As we have string views now, I'd vote for deprecating the string
> > manipulation methods in QByteArray. I doubt we could make QByteArray a
> true
> > vector of bytes now, without breaking lots of the user code, but that
> could
> > be a good first step.
>
> We don't have any good 8-bit string manipulation functions outside of
> QByteArray. They stay.
>

We don't have any good 8-bit string manipulation functions in QByteArray
either ;)


> The question is whether the Latin1 methods (toUpper(), toLower() and the
> free
> function qstricmp) should be moved or removed. Those would work really
> well in
> QLatin1String, but QLatin1String is a view, since it doesn't own the data.
> QLatin1String::toUpper() could return a QByteArray...
>

Perhaps there is a particular reason for the user to manipulate binary data
as if it were a string? So give him that string, QString.



> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development




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

Re: [Development] Oslo, we have a problem [char8_t]

[Konstantin Ritt]

вс, 7 июл. 2019 г., 12:58 André Hartmann :

> Hi Thiago,
>
>  > But QByteArray is encoding-indeterminate since it can carry any type.
>
> Correct, it is often used as "generic raw data array", e.g. in QFile,
> Q*Socket, QSerialPort, QCanBusFrame etc. Here we really need to treat
> the data as-is, without interpretation.
>
>  > Arguably, toUpper() and toLower() should be removed, since
>  >
>  >  QByteArray(u8"Résumé").toLower()
>  > is mojibake.
>
> I vote against that. If you got the "raw" data from a device as
> described above, you might want to do .toHex().toUpper() which is fully
> valid.
>

I'd argue against validity of the `ba.toHex().toUpper()` example, as it
brings false impression that you're operating on a string, where in fact
your intention is to re-code the binary data from one encoded form to
another encoded form (ASCII in this case, and one would have to
`QString::fromLatin1()` it explicitly to manipulate it further).
>From the other hand, `ba.toHex(Uppercase)` enforces the reader to treat it
exactly like an uppercased hex (whatever that means), which is just another
encoding form of the binary data.

As we have string views now, I'd vote for deprecating the string
manipulation methods in QByteArray. I doubt we could make QByteArray a true
vector of bytes now, without breaking lots of the user code, but that could
be a good first step.


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

Re: [Development] Heads-up (dev): carving up corelib/tools/ in qtbase

[Konstantin Ritt]

I doubt QByteArray really fits "text" scope.
As for QLocale, I think it is a material for the "unicode" scope; same for
QUnicodeTools, QUnicodeTables, QTextBoundaryFinder and maybe BiDi impl from
QtGui.


Regards,
Konstantin


пт, 7 июн. 2019 г. в 19:01, Edward Welbourne :

> Hi all,
>
> Just to save some confusion when folk hit the need to rebase: I've just
> moved (on dev) all date, time and time-zone things from corelib/tools/
> to corelib/time/.  I shall, in the (hopefully [*]) near future, do the same
> for string, byte-array, regex and locale things, into corelib/text/:
> https://codereview.qt-project.org/c/qt/qtbase/+/263127
>
> Gerrit shall consider changes to the affected files to be conflicts, for
> purposes of staging (both if my change is currently staged, when you try
> to stage yours, and after mine has gone through); but git manages to
> rebase fairly painlessly in most cases, because it knows perfectly well
> that I merely moved files around.  Real conflicts may arise in
> tools.pri, though.
>
> I shall move the calendar work over to the new layout (time/ part
> already done, but qlocale shall move in the text/ part).  Speaking of
> which, the calendar API is mostly ready and I'd like to see it reviewed
> in time to go into the 5.14 release, so please take a look at it [0][1].
>
> [0] https://codereview.qt-project.org/c/qt/qtbase/+/182341
> [1] https://codereview.qt-project.org/c/qt/qtbase/+/261857
>
> [*] I shall be on holiday from next Thursday, June 13th; back in July.
> ... and next Monday, June 10th, is a public holiday here in Norway.
>
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] What's the status of a moved-from object?

[Konstantin Ritt]

пн, 27 мая 2019 г. в 11:46, Edward Welbourne :

> сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
> >>>> Repeat after me: default ctors do _not_ establish a valid value.
>
> As an aged C programmer I can respect that ;^>
>
> On 2019-05-25 17:24, Konstantin Ritt wrote:
> >>> Perhaps you mean "trivial type's default ctors do _not_ establish a
> >>> valid value"?
>
> сб, 25 мая 2019 г., 20:42 Mutz, Marc via Development <
> development@qt-project.org<mailto:development@qt-project.org>>:
> >> No, I actually meant default ctor. What should the default value be?
> >> _Obviously_ zero-initialisation. But oh, no, QSize is different. So
> >> maybe it's not _quite_ so obvious what the default value is. Why is
> >> pen's default value a black solid line instead of NoPen? Why is
> >> QBrush's default ctor not solid black, but NoBrush? See? It's just
> >> nonsense to try to pick a default value, so this is to say: Don't
> >> try.
> >>
> >> There's exactly one exception: containers. _Clearly_ no-one would
> >> _ever_ expect a container to start out anything but empty.
>
> Indeed.
>
> Konstantin Ritt (26 May 2019 10:51) replied:
> > Sure we should force a no-op default ctor where possible, and provide
> > some helper code that returns a valid default/specialized value of
> > that type where {0} isn't enough or non-intuitive
> > (i.e. QQuaternion::identity(), QRect::empty(), QSize::invalid()).
>
> (I can't help but wonder whether QRect::empty() should take a point at
> which to place its empty rectangle.  An animated rectangle that shrinks
> and expands repeatedly [0] shouldn't forget its location at the moment
> when it is transiently empty, so empty rectangles at distinct locations
> are distinct.  But I'm unfamiliar with QRect, so maybe not.)
>
> [0] example (in SVG), remembering position and orientation while empty:
> http://www.chaos.org.uk/~eddy/img/geom/transpyth.svg
>
> > There could [be] more exceptions when we're talking about non-trivial
> > types, at least some of them could be resolved by providing
> > convenience/helper initializers.
>
> Many types need an invalid value (this is the current default for
> QDate, QTime, QDateTime and QTimeZone).  But not all.
>
> For arithmetic types, up to and including QQuaternion and matrices,
> you'll need a zero-value; many (including square matrices) shall also
> need a unit value.  While zero is a natural default, being explicit is
> good; and standard integral/floating types don't default to it.
>
> Various others are (at present) constructed with default values.  In the
> case of QLocale, that can be controlled by calling a static method,
> QLocale::setDefault(), and we'd need to add (as someone tried to do a
> little while ago) a QLocale::defaultLocale() or QLocale::getDefault() to
> get that (note that we can't use the name QLocale::default() as it's a
> reserved word) if we stopped making the default constructor produce it.
> Note that QLocale's default isn't the same thing as QLocale::system(),
> although it starts out so, until setDefault() is called.
>
> We're not particularly consistent about what default construction
> produces; sometimes undefined, sometimes defined but invalid, sometimes
> a zero, sometimes a "reasonable" default.  Which, as Marc tripped over,
> is a source of confusion for authors of client code.  Having static
> methods to return invalid, zero, unit, default values could be made a
> consistent pattern, with consistent naming, to reduce confusion.
>
> We can, of course, do that without changing what the default-constructed
> objects are, but changing that also to a consistent pattern - the same
> as the moved-from state - would make matters clearer (for any choice of
> what moved-from state to consistently use).  But it'd be SiC.
>
> Eddy.
>

Completely agreed.


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

Re: [Development] What's the status of a moved-from object?

[Konstantin Ritt]

сб, 25 мая 2019 г., 20:42 Mutz, Marc via Development <
development@qt-project.org>:

> On 2019-05-25 17:24, Konstantin Ritt wrote:
> > сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development
> >> Repeat after me: default ctors do _not_ establish a valid value.
> >
> > Perhaps you mean "trivial type's default ctors do _not_ establish a
> > valid value"?
>
> No, I actually meant default ctor. What should the default value be?
> _Obviously_ zero-initialisation. But oh, no, QSize is different. So
> maybe it's not _quite_ so obvious what the default value is. Why is
> pen's default value a black solid line instead of NoPen? Why is QBrush's
> default ctor not solid black, but NoBrush? See? It's just nonsense to
> try to pick a default value, so this is to say: Don't try.
>
> There's exactly one exception: containers. _Clearly_ no-one would _ever_
> expect a container to start out anything but empty.



Sure we should force a no-op default ctor where possible, and provide some
helper code that returns a valid default/specialized value of that type
where {0} isn't enough or non-intuitive (i.e. QQuaternion::identity(),
QRect::empty(), QSize::invalid()).

There could more exceptions when we're talking about non-trivial types, at
least some of them could be resolved by providing convenience/helper
initializers.


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

Re: [Development] What's the status of a moved-from object?

[Konstantin Ritt]

сб, 25 мая 2019 г., 12:30 Mutz, Marc via Development <
development@qt-project.org>:

> Further to the question about default ctors for such "obvious" stuff as
>
> On 2019-05-21 10:27, Mutz, Marc via Development wrote:
> > class QRect {
> >int x, y, w, h;
> > public:
> >QRect() = default;
> > };
> > QRect r; // partially-formed
> > r.x();   // compilers _already_ warn about this
> > QRect r = {}; // zero-initialized
>
> I've been working with Qt for two decades now. Guess what I just wrote
> and had to debug?
>
> QSize zero;
>
> Anyone spot the bug? Hint: the following /is/ correct:
>
> QPoint origin;
>
> Now, anyone here who wants to defend that as good API design?
>
> Anyone?
>
> Repeat after me: default ctors do _not_ establish a valid value.
>

Perhaps you mean "trivial type's default ctors do _not_ establish a valid
value"?

Konstantin

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

Re: [Development] What's the status of a moved-from object?

[Konstantin Ritt]

вт, 21 мая 2019 г., 14:25 Mutz, Marc via Development <
development@qt-project.org>:

> On 2019-05-21 13:03, Konstantin Ritt wrote:
> > вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development
> > :
> >
> >> And while the partially-formed
> >> state can be extended to non-pimpled classes easily:
> >>
> >> class QRect {
> >> int x, y, w, h;
> >> public:
> >> QRect() = default;
> >> };
> >> QRect r; // partially-formed
> >> r.x();   // compilers _already_ warn about this
> >> QRect r = {}; // zero-initialized
> >>
> >> That
> >> should be modelled by optional, not by QRect itself.
> >
> > Whilst the statement feels reasonable, this will require tons of API
> > changes and double checks on the user side:
>
> There are no double-checks. If the old code didn't check the rect before
> using it, it was a bug.
>

the first one is "does returned optional contain a rect?"
the second one "is rect empty?" // <- same check that was done in the "old"
code


> > optional Item::childrenRect() const
> > {
> > if (hasChildren()) {
> > QRect r = {};
> > for (auto *child : children())
> > r.unite(child->boundingRect().value_or({});
>
>for (auto *child : children())
>if (auto rect = child->boundingRect())
>r.unite(*rect);
>
> > return r;
> > }
> > return nullopt;
> > }
> >
> > QRect r = item->boundingRect().value_or({});
> > if (!r.isEmpty())
> > ~~~
>
> if (auto r = item->boundingRect())
>  use(*r);
>

there is nothing to use if 'r' has no value.
> The behavior is undefined if *this does not contain a value.
-- so value_or({}).
and then one would have to check if '*r' is valid/empty/normalized, just
like (s)he did before.


> > Note that I'm ok with that, but should we enforce such a huge efforts
> > all over Qt API just for making the default-constructible QRect a
> > no-op?
>
> This is not proposed for Qt 6. Not by me, at least. But it's the logical
> extension and once Qt can depend on C++17, iow: std::optional, it's the
> correct way forward, IMNSHO.
>
> Thanks,
> Marc
> ___
> 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] What's the status of a moved-from object?

[Konstantin Ritt]

вт, 21 мая 2019 г., 11:32 Mutz, Marc via Development <
development@qt-project.org>:

> And while the partially-formed
> state can be extended to non-pimpled classes easily:
>
>  class QRect {
> int x, y, w, h;
>  public:
> QRect() = default;
>  };
>  QRect r; // partially-formed
>  r.x();   // compilers _already_ warn about this
>  QRect r = {}; // zero-initialized
>
> That
> should be modelled by optional, not by QRect itself.
>

Whilst the statement feels reasonable, this will require tons of API
changes and double checks on the user side:

optional Item::childrenRect() const
{
if (hasChildren()) {
QRect r = {};
for (auto *child : children())
r.unite(child->boundingRect().value_or({});
return r;
}
return nullopt;
}

QRect r = item->boundingRect().value_or({});
if (!r.isEmpty())
~~~


Note that I'm ok with that, but should we enforce such a huge efforts all
over Qt API just for making the default-constructible QRect a no-op?



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

Re: [Development] FP calculations and stability in Qt

[Konstantin Ritt]

Writing and proposing a patch would take less time than discussing pros and
cons here.


Konstantin

пн, 13 мая 2019 г., 12:31 Konstantin Shegunov :

> On Mon, May 13, 2019 at 2:42 AM Christian Gagneraud 
> wrote:
>
>> On Mon, 13 May 2019 at 07:47, Konstantin Shegunov 
>> wrote:
>> > Doesn't this imply it should be dropped as an API that we can rely on?
>>
>> No i don't think so, this is just an edge case. I solved it by
>> changing the base unit of my graphics view, so that it doesn't have to
>> manipulate tiny FP values.
>> I remember reporting that, and AFAIR, an example was an arc in a
>> QGraphicsPathItem rendered as as a polyline.
>>
>
> Okay, I'll bite. Let's take as an example the bugreport I mentioned, how
> would such a transformation of units look like? It's not a loaded question,
> I'm genuinely interested if I missed something because really I don't see
> it. My point is that the actual calculation is done internally, so
> restructuring the units isn't at all trivial, nor perhaps possible, on the
> part of the user. If we can accept that we don't want to go through the
> motions to make transformations at least correct in all cases, I'm fine
> with that too, but we should then warn the user not to expect it from the
> library.
>
> I then turned on specialised library, Qt is a GUI toolkit, and is
>> optimised for painting. Qt takes all opportunities to be fast and
>> efficient in that context, and that includes being "mathematically"
>> imprecised, painting is all about pixels at the end of the day.
>>
>
> Look, I'm not arguing we should aim for 1 epsilon precision, but there's
> "imprecise" and then there's "blatantly wrong".
>
> A pixel is a surface, everything is correct as long as the surface
>> covered by the pixel contains the point.
>>
>
> Which it may not, is my argument. Numerical instability is the
> disproportionate grow of the relative error. If you don't keep that error
> in check then you (can) just get nonsense. I can, and will, accept that we
> don't want the most precise algorithm out there, but at least we should
> strive for one that's correct, shouldn't we?
>
> What i was trying to say, is that all geometry operations performed by
>> components coupled to QPainter are good enough (and very efficient)
>> for painting, by are not usable for "scientific" calculation.
>>
>
> Define "good enough" please. Is "good enough" errors bound by the errors
> in the input, is "good enough" errors that explode with some inputs, or
> something else?
>
> OT: By the way, as far as I can tell a LU with pivoting (O(n^3)
> complexity) is approximately as efficient as the algorithm currently
> employed in the mentioned bugreport. It has two major advantages in my
> view, however. One is that it's rank-revealing, thus you can tell if
> there's linear dependency with zero cost. Secondly, it's not reinventing a
> square wheel.
>
>
>> QPainterPath is not called QPath, expecting to do precise geometry
>> boolean set operations with it is a mistake.
>>
>
> To extend my argument from the previous paragraph(s):
> How do you take the algebra out of the geometry? I get that the algebra
> can go its merry way on its own (e.g. in science), but the geometry just
> depends on the algebra. So if the algebra's wrong, the geometry can be all
> over the place by simple logical implication, you can't tell if it's
> correct or not.
>
> Kind regards.
> ___
> 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] unique_ptr and Qt, Take 2

[Konstantin Ritt]

what about the other corner case:

`
~Some() {
const auto children = someChildren();
for (auto child : children) {
if (!child->isDepleted()) {
// 'detach' and let it die alone, some later...
child->setParent(nullptr);
QObject::connect(child, ::depleted, child,
::deleteLater);
// f.i. child on a secondary thread couldn't be parented by qApp
QObject::connect(qApp, ::aboutToQuit, child,
::deleteLater);
} else {
delete child;
}
}
}
`

?

I bet that isn't that simple to do with just unique_ptr (or any other
std::_ptr). Is it?


As for beforementioned QLayout and QAction examples, sure the API could be
improved to make re-parenting obvious and to avoid resources leakage, etc.
However, unique_ptr isn't that holly bullet to solve the lazy programmer's
issues. IMO.


Konstantin

сб, 4 мая 2019 г., 2:34 Thiago Macieira :

> On Friday, 3 May 2019 16:14:09 PDT Иван Комиссаров wrote:
> > What I am talking about is that explicit is better than implicit. Taking
> an
> > address of an object on a stack and passing it to a function that
> (possibly
> > can) delete your object is not explicit. Wrapping that operation in a
> > construction of a smart pointer is explicit. Moving a unique_ptr is
> > explicit. When you’re «casting» your on-a-stack-QFile to a some smart
> > pointer, you’re telling the compiler (and other people who read the code)
> > «trust me, I know what I’m doing, this is intended».
>
> That I can agree with, but this goes back to the suggestion of our own
> smart
> QObject pointer classes. In non-compatibility mode, a function that adopts
> the
> passed object should only accept from another smart pointer. If you pass a
> naked pointer, it should reject and force you to clearly state that you
> know
> what you're doing.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] unique_ptr and Qt, Take 2

[Konstantin Ritt]

Just wandering, what `QObject:: children ()` shall return? ;p


Konstantin

пт, 3 мая 2019 г., 22:09 Konstantin Ritt :

> Ivan,
>
> note that observer_ptr is mostly like
>
> templateusing observer_ptr = T*;
>
>
> so what about
>
>
> layout2->addWidget(layout->addWidget(make_unique("right")))->setFlat(true);
>
> ?
>
>
> Regards,
> Konstantin
>
>
> пт, 3 мая 2019 г., 21:41 Иван Комиссаров :
>
>> Thiago, can you please elaborate how you see this?
>>
>> For a simple TreeItem a pair of std::unique_ptr/std::observer_ptr should
>> be enough (with a bunch of convenience methods to insert children):
>>
>> struct TreeItem
>> {
>>observer_ptr parent;
>>vector> children;
>> };
>>
>> Yes, the code becomes a bit verbose, but the ownership transfer is now
>> visible with those (ugly) std::moves.
>>
>> I can think of an alternative of using shared pointers (since we already
>> have a QPointer aka WeakPointer) but I think it gives too much
>> overhead just to support corner cases.
>>
>> If QLayout::addWidget() will return an observer_ptr*, you can just do
>>
>> auto button = layout->addWidget(make_unique(«RIGHT»));
>> button->setFlat(true);
>>
>> * ok, you need a template version of addWidget for that, but since c++ is
>> all about templates these days it doesn’t really a disadvantage
>>
>>
>> > 3 мая 2019 г., в 20:24, Thiago Macieira 
>> написал(а):
>> >
>> > On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote:
>> >> std::unique_ptr rightButton =
>> >> std::make_unique("RIGHT");
>> >> layout->addWidget(std::move(rightButton));
>> >
>> > The problem in this particular example is that once you've added the
>> widget,
>> > the rightButton smart pointer no longer has a pointer. You can't
>> continue to
>> > set up your push button. In most cases, this is just a matter of moving
>> the
>> > set up before the addition / reparenting, or using the other idiom
>> where the
>> > object is never in a smart pointer in the first place.
>> >
>> > So this begs the question of whether std::unique_ptr is the best smart
>> pointer
>> > for this scenario. Would it make sense to create one that understands
>> parent-
>> > child relationship?
>> >
>> > --
>> > Thiago Macieira - thiago.macieira (AT) intel.com
>> >  Software Architect - Intel System Software Products
>> >
>> >
>> >
>> > ___
>> > 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] unique_ptr and Qt, Take 2

[Konstantin Ritt]

Ivan,

note that observer_ptr is mostly like

templateusing observer_ptr = T*;


so what about


layout2->addWidget(layout->addWidget(make_unique("right")))->setFlat(true);

?


Regards,
Konstantin


пт, 3 мая 2019 г., 21:41 Иван Комиссаров :

> Thiago, can you please elaborate how you see this?
>
> For a simple TreeItem a pair of std::unique_ptr/std::observer_ptr should
> be enough (with a bunch of convenience methods to insert children):
>
> struct TreeItem
> {
>observer_ptr parent;
>vector> children;
> };
>
> Yes, the code becomes a bit verbose, but the ownership transfer is now
> visible with those (ugly) std::moves.
>
> I can think of an alternative of using shared pointers (since we already
> have a QPointer aka WeakPointer) but I think it gives too much
> overhead just to support corner cases.
>
> If QLayout::addWidget() will return an observer_ptr*, you can just do
>
> auto button = layout->addWidget(make_unique(«RIGHT»));
> button->setFlat(true);
>
> * ok, you need a template version of addWidget for that, but since c++ is
> all about templates these days it doesn’t really a disadvantage
>
>
> > 3 мая 2019 г., в 20:24, Thiago Macieira 
> написал(а):
> >
> > On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote:
> >> std::unique_ptr rightButton =
> >> std::make_unique("RIGHT");
> >> layout->addWidget(std::move(rightButton));
> >
> > The problem in this particular example is that once you've added the
> widget,
> > the rightButton smart pointer no longer has a pointer. You can't
> continue to
> > set up your push button. In most cases, this is just a matter of moving
> the
> > set up before the addition / reparenting, or using the other idiom where
> the
> > object is never in a smart pointer in the first place.
> >
> > So this begs the question of whether std::unique_ptr is the best smart
> pointer
> > for this scenario. Would it make sense to create one that understands
> parent-
> > child relationship?
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >  Software Architect - Intel System Software Products
> >
> >
> >
> > ___
> > 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] Adding more Datetime classes to Qt

[Konstantin Ritt]

Please read the QDateTime docs accurately.


Konstantin

вт, 9 апр. 2019 г., 15:11 Pouya Shahinfar :

> Although QDateTime has a full set of methods for working with date and
> times in Qt, It could lead to misunderstanding. How? Well when you are
> saving a date or time in this class you do not know the time is local time,
> UTC time or it is for a specific timezone. Therefore, maintaining the
> application becomes harder. Let's consider this scenario:
>
> You open a project which is developed by someone else, and he/she used
> QDateTime for holding time and date. The problem here is you as a newcomer
> to project do not know the value in the class is based on UTC or local
> time, etc. if there was a class like QLocalDateTime, the code was more
> maintainable.
>
> Qt has an awesome set of classes but unfortunately when it comes to
> timing. the classes are really awkward. For instance, there is not a class
> for holding a time-span:
>
> https://forum.qt.io/topic/3160/qtimespan-interest
>
> As far as I concern, It would be a good idea that Qt has the following
> class:
> 1. QTimeSpan -> for holding duration of time.
> 2. QInstant -> For holding an instant of time in UTC time (like Java)
> 3. QLocalDateTime -> For holding local datetime
> 4. QUTCDateTime -> For holding UTC datetime
> 5. QZonedDateTime -> For date and times which is in a specific timezone.
>
> ___
> 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] Qt6: Adding UTF-8 storage support to QString

[Konstantin Ritt]

>  - Introduce some iterator that iterates over unicode code points.

QStringIterator


> We *should* have a string type (I don't care what you call it) that acts
> on strings indexed by Unicode characters, not in terms of a
> representation.  Whether that string type internally uses UTF-16 or
> UTF-8 should be invisible to its user.  Ideally it would be capable of
> carrying its data internally in either form (so as to avoid needless
> conversion when both producer and consumer use the same form) and of
> converting between the two (e.g. so as to append efficiently) as needed.

That's what I'd support with both hands.
However, I don't think we could do that on QString without breaking most of
the existing code.

P.S. \note Unicode operates on "code points" not "characters". And
moreover, there is no such thing like "glyph" in Unicode string.
And looking for grapheme or glyph boundary is clearly not a string
storage's or a string view's responsibility.

Regards,
Konstantin


чт, 24 янв. 2019 г. в 10:33, Olivier Goffart :

> On 23.01.19 23:15, André Pönitz wrote:
> > On Wed, Jan 23, 2019 at 05:40:33PM +0300, Konstantin Tokarev wrote:
> >> 23.01.2019, 16:55, "Edward Welbourne" :
> >>> All of this discussion ignores a major elephant: QString's indexing is
> >>> by 16-bit UTF-16 tokens, not by Unicode characters. We've had Unicode
> >>> for a couple of decades now.
> >>>
> >>> We *should* have a string type (I don't care what you call it) that
> acts
> >>> on strings indexed by Unicode characters, not in terms of a
> >>> representation. Whether that string type internally uses UTF-16 or
> >>> UTF-8 should be invisible to its user. Ideally it would be capable of
> >>> carrying its data internally in either form (so as to avoid needless
> >>> conversion when both producer and consumer use the same form) and of
> >>> converting between the two (e.g. so as to append efficiently) as
> needed.
> >>
> >> I think this is excessive. Most common operations with strings in
> application
> >> code are:
> >>
> >> * Pass the string around or compare as an opaque token
> >> * Draw the string on screen e.g. with QPainter (while technically it
> >>falls in the previous category, I think it's important enough to
> >>deserve separate item)
> >> * Find substring or pattern (regex) inside the string
> >> * Split the string by character, pattern, or index boundaries found by
> means
> >>of previous item
> >>
> >> I think the only common cases when dealing with Unicode grapheme
> clusters
> >> is required are
> >>
> >> * Handling of text cursor movement
> >> * Implementation of text shaping, i.e. what Harfbuzz is doing
> >>
> >> I think having special iterator would be quite enough for cursor case.
> Such
> >> iterator could abstract away underlying encoding, instead of forcing
> everyone
> >> to convert to UTF-16 first.
> >
> > All of that is scarily close to my opinion on the topic.
>
> Same here. I think Konstantin is spot on.
>
> Another example of good string design, I think, is the Rust's String.
> Their
> string is encoded in valid UTF-8, indexed by bytes, and splitting the
> string in
> the middle of a code point is a programmer error.
>
> As already mentioned before, UTF-16 is quite a bad choice, if it weren't
> for
> legacy.
>
> The argument of that developper wrongly using indexes cause more problem
> with
> utf-8 than with utf-16 ("it would happen for a lot more characters")
> actually
> means that the developper will see and fix their bugs quickly.
>
> I understand changing QString to UTF-8 is a difficult task if we want to
> do it
> in a compatible way. However, I think there is a way:
> In Qt5.x:
>   - Introduce some iterator that iterates over unicode code points.
>   - Deprecate utf16()  and other API that assume that QString is UTF-16
>   - Replace them by a toUtf16 which returns a QVector.  I believe
> that
> it is possible to make the cotent implicitly shared with the QString,
> avoiding
> copies. (since it is just a QTypedArrayData internally)
>
> Then in Qt6 one can simply change the representation without breaking
> compatibility with non-deprecated functions.
>
> --
> Olivier
>
> Woboq - Qt services and support - https://woboq.com -
> https://code.woboq.org
>
>
>
>
> ___
> 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] Qt6: Adding UTF-8 storage support to QString

[Konstantin Ritt]

> https://utf8everywhere.org/ states *"UTF-16 is the worst of both worlds,
being both variable length and too wide"*

https://utf8everywhere.org/ *states bullshit. try reading an alternative
sources.*


Regards,
Konstantin


ср, 16 янв. 2019 г. в 13:20, Edward Welbourne :

> Marco Bubke (16 January 2019 10:59)
> > You can use std::string which as small string optimization instead of
> > QByteArray too. In many cases where you would use const String 
> > you can use std::string_view, so you are more flexible.
>
> Note that we now have a QStringView, which can likewise replace many
> uses of const QString & - not that this is any help with UTF-8.
> Uptake has been slow, but some of us are using it.
>
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Coding style for lambdas with empty parameter list

[Konstantin Ritt]

+1 for []()


Regards,
Konstantin


чт, 10 янв. 2019 г. в 15:51, Vitaly Fanaskov :

> I vote for shorter form as well.
>
> But the documentation should be extended with the Philippe's second
> example. Trailing return type is rarely required, but we cannot omit
> parameters list in this case, because it leads to compilation error.
>
> On 1/9/19 8:31 PM, Philippe wrote:
> > I like the shorter form, but keep in mind that when the return type
> > needs to be specified,
> >
> > [] ->foo { // lambda content }
> >
> > is not possible, and following is needed:
> >
> > []() -> foo { // lambda content }
> >
> > Philippe
> >
> > On Wed, 9 Jan 2019 19:08:46 +0100
> > "André Hartmann"  wrote:
> >
> >> Hi all,
> >>
> >> I recently found an inconsistency regarding empty lambda parameter lists
> >> between [1] and [2]. While the first states, that parentheses have to be
> >> written always, the latter is missing this section.
> >>
> >> My request to syncronize both [3] lead to the conclusion, to change the
> rule,
> >> so that empty parameter lists should be written as
> >>
> >>   [] { // lambda content }
> >>
> >> instead
> >>
> >>   []() { // lambda content }
> >>
> >> If anyone has objections against this change, please vote at [3].
> >> I'll keep this commit open a while and adopt the Wiki [1] once the
> change
> >> is approved without objections.
> >>
> >> Thanks and regards,
> >> André
> >>
> >> [1] https://wiki.qt.io/Coding_Conventions#Lambdas
> >> [2]
> https://code.woboq.org/qt5/qt-creator/doc/api/coding-style.qdoc.html#772
> >> [3] https://codereview.qt-project.org/249192
> >> ___
> >> 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
>
> --
> Best Regards,
>
> Fanaskov Vitaly
> Senior Software Engineer
>
> The Qt Company / Qt Quick and Widgets Team
>
> ___
> 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] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do

[Konstantin Ritt]

It didn't.

Regards,
Konstantin


пт, 12 окт. 2018 г. в 13:59, Giuseppe D'Angelo via Development <
development@qt-project.org>:

> Hello,
>
> Il 12/10/2018 12:48, b...@valdyas.org ha scritto:
> > Which of course breaks source compatibility. It's bad enough to have to
> > adapt one's codebase; but this also makes it impossible to bisect code
> > when Qt 5.11 is installed that had to be adapted.
> >
> > I'm constantly running into this problem. Would it be too much to ask
> > that things like this just never ever happen again?
>
> In what way did that commit break source compatibility?
>
> 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
> 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] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11

[Konstantin Ritt]

Can we have both OpenSSL 1.0.x and 1.1.x supported when configured with
-openssl-runtime and choose 1.0 or 1.1 with -openssl-linked? Anyhow?

Regards,
Konstantin

2018-02-13 14:13 GMT+03:00 Konstantin Tokarev :

>
>
> 13.02.2018, 14:09, "Edward Welbourne" :
> > On Friday, 9 February 2018 10:04:30 PST Giuseppe D'Angelo wrote:
> >>  The point isn't which version of Qt comes with the distribution, but
> the
> >>  binary builds. Given people do use binary builds (to have an up-to-date
> >>  Qt) but not mess with OpenSSL, the outcome will be that SSL will not be
> >>  functional for the users of the distributions I mentioned before.
> >
> > Well, conversely, those who use our binary distributions on more modern
> > releases of those distributions have the opposite problem; when
> > Debian/testing upgraded to OpenSSL 1.1, it gave me problems, obliging me
> > to downgrade OpenSSL in order to continue using Qt.
>
> AFAIU you should install libssl1.0.2 package instead of downgrading
> anything
>
> AFAIK all good binary distros provide packages for parallel openssl
> versions
> when they are not binary compatible
>
> However, implementing QTBUG-65922 would certainly make life easier for
> some folks.
>
> >
> > If folk are willing to upgrade Qt on an old distro, I don't think it's
> > any more unreasonable to ask for a new OpenSSL version than to ask folk
> > using up-to-date distros to downgrade their OpenSSL to accommodate a Qt
> > that's contemporary with the up-to-date rest of their distribution. If
> > anything, expecting the latter is more unreasonable than expecting the
> > former.
> >
> > Eddy.
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Regards,
> Konstantin
>
> ___
> 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] Undeprecating QString::null

[Konstantin Ritt]

changing the parameter's default value *is* binary compatible.


Regards,
Konstantin

2018-01-16 20:35 GMT+04:00 Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com>:

> > The "just change" introduces a binary incompatibility - right ?
>
> I don't think it does: the QString is constructed on the caller's side
> anyways and your function is always passed a QString object;
> if you had an app that linked to qwt and didn't recompile it will just
> keep calling QString::null() from its side and pass the resulting object to
> your function.
>
> Best,
> Jean-Michaël
>
> On Tue, Jan 16, 2018 at 5:22 PM, Konstantin Tokarev 
> wrote:
>
>>
>>
>> 16.01.2018, 19:18, "Uwe Rathmann" :
>> > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
>> >
>> >>  Just change your code to use "= QString()", no #ifdef necessary.
>> >
>> > The "just change" introduces a binary incompatibility - right ?
>> >
>> > Please be aware, that Qwt is part of almost any Linux distro - according
>> > to sourceforge it has more than 1000 additional downloads every week
>> > since many years.
>> >
>> > All distro maintainers would not only have to upgrade the Qwt packages,
>> > but also all packages depending on it - users would have to rebuild.
>>
>> However, it seems like amount of reverse dependencies of Qwt is rather
>> moderate, e.g. in Ubuntu I see
>>
>>   libqwt6:i386
>>   zygrib
>>   simon
>>   qsapecng
>>   qgis
>>   nlkt
>>   libqwt-dev
>>   libqgis-gui2.0.1
>>
>>
>> >
>> > Considering the strict compatibility rules you have for Qt you will
>> > understand, that this is nothing I would like to do easily.
>> >
>> > But could you please comment on why this change is an improvement -
>> > beyond getting rid of 3-4 lines in qstring.h ?
>>
>> Because having redundancies in API is bad maybe?
>>
>> >
>> > Thanks,
>> > Uwe
>> >
>> > ___
>> > Development mailing list
>> > Development@qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/development
>>
>> --
>> Regards,
>> Konstantin
>> ___
>> 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Mismatch of display resolutions and window sizes in Android applications

[Konstantin Ritt]

Plz use https://bugreports.qt.io/ for bug reports and feature requests.

Qt Development ML is for discussions around Qt development, not even about
development with Qt.


Regards,
Konstantin


2018-01-13 22:27 GMT+04:00 Denis Shienkov :

> The problem was in Qt::AA_EnableHighDpiScaling option.
>
> 13.01.2018 19:34, Denis Shienkov пишет:
>
> Hi all.
>
> Rigth now I faced with the strange issue is that the QML
> window size (screen) does not correspond to the display
> resolution.
>
> For example, I have the "ASUS ZenFone 4 Max ZC554KL"
> smartphone which has display resolution as 1280x720 pixels.
>
> But if I run there the QML application and try to print out
> the ApplicationWindow size, then it is 360x568 or 640x288
> pixels, depends on orientation. O_o
>
> I have checked the same and on other smartphones, and see
> that there the situation is similar. E.g. for the
> "Samsung Galaxy Ace 3 GT-S7270" with 800x480 display I got
> 320x460 or 533x247 pixels of my ApplicationWindow.
>
> For example if try to use the QtLocation module, then any
> maps looks ugly.
>
> It is very bad surprise for me... Because, seems, now I can
> not write any applications with high resolusion (or, at least
> to operate with a real resolutions from my QML code).
>
> Is there are any tricks to fix it?
>
> PS: Some Android's firmwares (e.g. Cyanogen)  allows to change
> the DPI, and with the minimum DPI the ApplicationWindow size
> increases a bit.. But it is not an option anyway.
>
> BR,
> Denis
>
>
>
> ___
> 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] DTLS support in Qt

[Konstantin Ritt]

> Then what module should it be in?

My +1 for QtNetwork (unless we're going to move QSsl related code to a
separate Qt module)

Regards,
Konstantin

2017-08-23 10:25 GMT+04:00 Lars Knoll :

> Hi,
>
> I’ll look into it. But it’ll take a few days.
>
> Cheers,
> Lars
>
> > On 18 Aug 2017, at 22:11, Thiago Macieira 
> wrote:
> >
> > On Friday, 18 August 2017 13:07:13 PDT Timur Pocheptsov wrote:
> >>> Should *I* contribute it?
> >>
> >> Well, yes, please, otherwise I'll do it myself 
> >
> > I think I need an answer from Lars or Tuukka, because of the legal
> > implications.
> >
> >>> If NO:
> >>
> >> Then who will write it? When?
> >>
> >> I will, 5.11.
> >
> > Cool! I'll start a new thread discussing the non-crypto related parts
> until we
> > get the conclusion of what I can or cannot be part of.
> >
> >>> Then what module should it be in?
> >>
> >> Option 'a' is optimal.
> >
> > No doubt.
> >
> > --
> > 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New repository for QtOAuth

[Konstantin Ritt]

I don't see any need in distinguishing different OAuth implementations for
Qt -- once we have an "officially supported" Qt module, it'll be a default
opt-in for the user's code.

+1 for QtOAuth as a separate module

Regards,
Konstantin

2016-08-13 11:28 GMT+04:00 Sune Vuorela :

> On 2016-08-12, Fredrik de Vibe  wrote:
> > We have recently been working on an implementation of OAuth (1+2), and
> > this is now approaching a state in which it can be distributed as a tech
> > preview. For this we'll need a new public repository.
>
> there is a handful of external projects doing oauth with qt. Have
> anything been done to ensure applications don't blow up if several
> libraries gets loaded into the same process?
>
> The ones I've found seems to have some of the following distinguishing
> marks
>
> One puts everything in namespace QOAuth and has a QtOAuth header
>
> One seems to put everything with O0foo O1foo and O2foo
>
> another one seems to name everything like KQOAuthfoo (and despite the
> name, I don't think it has any ties to the KDE project)
>
> and one just with a class OAuth2, and this one looks a bit like example
> code.
>
>
> So, depending on how the qt project qtoauth is done, it might conflict
> to some degree with the first of them.  The first of them is also
> available in Debian and other linux distributions as qoauth (libqoauth1
> and libqoauth-dev)
>
> > The main reason for OAuth to reside in its own module (and not as a part
> > of qtnetwork) is that it is specialized, and most qtnetwork users won't
> > need it. This avoids increasing the footprint of, and unnecessary
> > complexity in, qtnetwork. Another reason is that OAuth, while depending
> > on and using networking mechanisms, isn't in itself really a networking
> > mechanism.
>
> Agreed.
>
> /Sune
>
> ___
> 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] Qt 5.7.0 Official Installer

[Konstantin Ritt]

> The QtGamepad module is a technology preview of the API which provides
classes and functions to access *CAN and ModBus*.

;)


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

Re: [Development] Possible bug in Qt Text Engine

[Konstantin Ritt]

Hi,

Did you file a bug report? ML is not really the right place for reporting
bugs.

Briefly, the CJK characters in your text are covered by some fallback font
for which the font metrics are slightly different, so that the line height
is the sum of a max ascent, max descent, and max leading (see
QTextEngine::shapeText).


Regards,
Konstantin

2016-03-15 17:41 GMT+04:00 Ziming Song :

> Hi everyone,
>
>
> I have been fighting with this bug for over a year, but till now I can't
> find a satisfying solution, so I came here.
>
>
> I use QPlainTextEdit  to implement my own code editor widget, much like
> the tutorial does. The widget works fine, except it displays CJK characters
> with a different line height.
>
>
> If a line contains only English and Latin characters, QPlainTextEdit would
> displays them just fine. But if a line contains CJK characters, that line
> height will be a little larger than other lines.
>
>
>
>
> In the above picture, I put two widget next to each other, and both
> entered 17 lines. Only the left one has lines with Chinese characters.
>
>
> I browsed through the qt source code, and I think the problem might in the
> Qt text engine. Since QTextLine gives different height for english and
> chinese characters.
>
>
> void test(QString s) {
> QFont f("Courier 10 Pitch", 12);// this font doesn't contain CJK
> characters
> QTextLayout textLayout(s, f);
> textLayout.setCacheEnabled(true);
> textLayout.beginLayout();
> while (1) {
> QTextLine line = textLayout.createLine();
> if (!line.isValid()) { break; }
> line.setLineWidth(1000);// long enough
> qDebug() << line.height();
> }
> textLayout.endLayout();
> }
>
> // in main
> test("english");// output 19
> test("中文");// output 20
>
> I've tried reimplementing QPlainTextEdit::paintEvent or inherits from
> QPlainTextDocumentLayout, but those classes are heavily coupled.
>
>
> So is this really a bug in Qt text engine. How can I make lines have same
> line height?
>
> ___
> 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] Scalable UIs in QtQuick (take 2)

[Konstantin Ritt]

Yet another question: when we write Item { id: item; width: 5cm }, what
would item.width return? value expressed in logical pixels?


Konstantin

2016-02-18 15:05 GMT+03:00 Sorvig Morten :

>
> > On 18 Feb 2016, at 12:35, Nikita Krupenko  wrote:
> >
> > 2016-02-18 12:50 GMT+02:00 Hausmann Simon <
> simon.hausm...@theqtcompany.com>:
> >> (1) In order to make it really easy to scale "logical" pixels without
> having to introduce your own context property or factor in a .qml file that
> you multiply everywhere, we could turn the regular "pixels" in QtQuick into
> truly logical pixels that scale with an application wide (or window wide)
> factor. So Image { width: 100 ... } will scale automatically from 100
> logical pixels to maybe 200 physical pixels on a x2 display. This assumes
> the availability of API to change this mapping.
> >>
> >> (2) In the events where you still _want_ to use physical pixels, you
> could use "px" units.
> >>
> >> So at first nothing would change for app developers at all because we
> map logical pixels to physical pixels. But
> >> if you'd like to, you could opt into changing this mapping and having a
> relatively easy fallback to physical pixels using for example the "px"
> unit. We might as well offer the other physical units anyway, that probably
> causes little to no harm.
> >
> > Isn't (1) already done with Qt::AA_EnableHighDpiScaling? Though
> > disabling this feature for some items would be useful, like for
> > Canvas, which is broken now with this scaling.
>
> This is indeed what is done for that flag and on OS X and iOS. In that
> sense logical pixels are already supported.
>
> “px” could be added, but what are the use cases? You almost never want to
> have small content on high-DPI display. I see doing custom scaling in the
> application as a possible one.
>
> As a minor platform note, “px” would not be guaranteed to be physical
> pixels
> on Apple operating systems. There can be further resolution virtualization,
> for example when setting a scaled resolution for the display.
>
> Morten
>
>
>
> ___
> 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] Qt::CaseInsensitive comparison is not the same as toLower() comparison

[Konstantin Ritt]

2016-02-11 3:47 GMT+04:00 Thiago Macieira <thiago.macie...@intel.com>:

> On quinta-feira, 11 de fevereiro de 2016 03:00:02 PST Konstantin Ritt
> wrote:
> > > CaseSensitive   => no case folding, no
> > > normalisation
> > > CaseSensitiveNormalized => no case folding, but normalised
> > > CaseInsensitive => case-folded, no
> > > normalisation
> > > CaseInsensitiveNormalized   => both
> >
> > Normalized how? C, D, KC, KD ?
>
> The choice is between K and non-K. Most likely, non-K.
>
> How it's implemented (towards C or towards D) is irrelevant.
>
> > > $ touch $'\u03bc'.txt $'\u00b5'.txt
> > > $ ls ?.txt
> > > µ.txt  μ.txt
> > >
> > > This leads to security vulnerabilities like:
> > > QString filename = QString::fromUtf8(socket.readAll());
> > > if (filename.compare("µ.txt", Qt::CaseInsensitive) == 0) {
> > > QFile f(filename);
> > > if (f.open(QIODevice::ReadOnly)) {
> > > socket.write(f.readAll());
> > > return true;
> > > }
> > > }
> > > return false;
> > >
> > > [Why would you compare µ case insensitively? Because it wasn't the µ I
> was
> > > concerned about, but the ".txt" part!]
> >
> > Quite synthetic use case as to me.
>
> As security issues often look like before they actually happen. Who would
> have
> guessed the circumstances of the original TOCTOU attack (flood the Linux
> kernel
> with enough data to cause cached data to be dropped)?
>
> For a concrete case (not security): an IRC client was made to join a
> channel
> with ı in the name, but then due to bugs in the client, it joined two or
> more
> (uppercase leads to I, lowercase leads to i, uppercasing again leads to İ).
> This actually happened.
>
> > Anyways, QUrl has no such issue.
>
> URLs are case-sensitive, except for two portions:
>
> a) scheme, which is limited to A-Z anyway
> b) hostnames, for which there are very specific and explicit rules about
> case-
> folding (case-folding and NFKC according to Unicode 3.2, no other)
>
> But that is exactly the issue: if URLs are case-sensitive and the file
> system
> isn't, then is /%C2%B5.txt the same as /%CE%BC.txt? According to QUrl, they
> aren't, but according to QString::compare with Qt::CaseInsensitive, they
> are.
>

BTW, *_wcsicmp* compares strings by simply converting them to their
lowercase forms.
So what you suggest? Changing Qt::CaseInsensitive string comparison to not
use casefolding and introduce more option(s) for case-folded and normalized
case-folded comparison?

Albeit that'll be a behavioral change, I think I'm ok with that.

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

Re: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison

[Konstantin Ritt]

2016-02-10 23:46 GMT+04:00 Knoll Lars :

> Hi Thiago,
>
> On 10/02/16 19:27, "Development on behalf of Thiago Macieira" <
> development-boun...@qt-project.org on behalf of thiago.macie...@intel.com>
> wrote:
>
>
>
>
>
> >Hi all
> >
> >(especially Konstantin!)
> >
> >When reviewing a change, I noticed that QString::startsWith with
> >CaseInsensitive compares things like this:
> >
> >if (foldCase(data[i]) != foldCase((ushort)latin[i]))
> >return false;
> >
> >with foldCase() being
> convertCase_helper(ch),
> >whereas toLower() uses QUnicodeTables::LowercaseTraits.
> >
> >There's a slight but important difference in a few character pairs see
> below.
> >The code has been like that since forever. So I have to ask:
> >
> >   => Is this intended?
>
> Yes, CaseInsensitive comparisons should compare case folded strings. And
> you're right, in some cases that is something else than comparing the lower
> cased versions of both strings.
>
>
> >If you write code like:
> >
> >   qDebug() << a.startsWith(b, Qt::CaseInsensitive)
> >   << (a.toLower() == b.toLower());
> >
> >You'll get a different result for the following pairs (for example, see
> util/
> >unicode/data/CaseFolding.txt for more):
> >
> >µ U+00B5 MICRO SIGN
> >μ U+03BC GREEK SMALL LETTER MU
> >
> >s U+0073 LATIN SMALL LETTER S
> >ſ U+017F LATIN SMALL LETTER LONG S
> >
> >And then there are the differences between toUpper and toLower. The
> following
> >pairs compare false with toLower(), compare true with toUpper(), currently
> >compare false with CaseInsensitive/toCaseFolded() but *should* compare
> >true[1]:
>
> They should only compare true with full case folding rules. This is
> something we have so far not implemented in Qt; as you noted below we're
> still using simple case folding rules.
>
> This is actually somewhat similar to the case of comparing strings in
> different normalisation forms (composed vs decomposed), something we also
> don't do out of the box (ie. 'Ä' doesn't compare true with the combination
> of 'A' with the diacritical mark for umlaut.
>
> At some point it would probably be nice to implement support for comparing
> these correctly. This does however have a performance impact and many use
> cases might not want this comparison by default.
>

Right, we still don't have "full" case folding support in Qt; but even if
we did, it requires a locale (or at least language) to be passed as a
comparison context, which means we'll have to review our string comparison
API -- so maybe Qt6?

w3c says:

If your application or specification needs to consider case folding,
here are some general recommendations to follow:

   1. *Consider Unicode Normalization* in addition to case folding. If you
   mean to find text that is semantically equal, you may need to normalize the
   text beyond just case folding it. Note that Unicode Normalization does
   *not* include case folding: these are separate operations.
   2. *Always use the language (locale) when case folding.* Some languages
   have specific case folding idiosyncrasies. In particular, if you do not
   pass the language or locale to your case folding routine, you may get a
   default locale which might be Turkish (for example).
  1. *Specify US English or "empty" (root) locale if you need
  consistent (internal, not for presentation) comparisons* If your
  comparison should be the same regardless of language or locale,
always pass
  the US English or empty (root, C, POSIX, null) locale to your
case-folding
  function. This does not disable caseless comparison or case folding. It
  merely limits the effects to a well-known set of rules.
  2. *Use case-less compare functions if provided* If your application
  is comparing internal values for equality (as opposed to sorting lists or
  comparing values linguistically), you should use a consistent caseless
  compare function. For example, Java's java.lang.String class provides
  an equalsIgnoreCase function that is more convenient than using
  toLowerCase(#locale)... which provides consistent results across
  languages, although not consistent with the rules for any given language.
   3. *For presentation, normalize case in a language sensitive manner* The
   rules that one language uses for case will not necessarily match those used
   by another language. For example, the French novel by Marcel Proust *À
   la recherche du temps perdu* contains only the single, introductory
   capital letter, whereas the English title uses "titlecase": *In Search
   of Lost Time*. Code that assumes one form of capitalization is
   appropriate for another language may cause problems.


In Qt, we usually don't have to do 1 ourselves as we put
this responsibility to the calling side; that saying, we always assume both
texts are in normalized form (usually composed).
2 relates to the "full" case folding -- clearly describes *why* it 

Re: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison

[Konstantin Ritt]

2016-02-11 1:36 GMT+04:00 Thiago Macieira :

> On quarta-feira, 10 de fevereiro de 2016 19:46:49 PST Knoll Lars wrote:
> > They should only compare true with full case folding rules. This is
> > something we have so far not implemented in Qt; as you noted below we're
> > still using simple case folding rules.
> >
> > This is actually somewhat similar to the case of comparing strings in
> > different normalisation forms (composed vs decomposed), something we also
> > don't do out of the box (ie. 'Ä' doesn't compare true with the
> combination
> > of 'A' with the diacritical mark for umlaut.
> >
> > At some point it would probably be nice to implement support for
> comparing
> > these correctly. This does however have a performance impact and many use
> > cases might not want this comparison by default.
>
> I would say this requires more items in Qt::CaseSensitivity (or a new
> enum).
>
> CaseSensitive   => no case folding, no
> normalisation
> CaseSensitiveNormalized => no case folding, but normalised
> CaseInsensitive => case-folded, no
> normalisation
> CaseInsensitiveNormalized   => both
>

Normalized how? C, D, KC, KD ?


> We may need a comparison that uses lowercasing and/or uppercasing instead
> of
> case-folding for contexts where that is important. I'm thinking
> specifically of
> security issues in networking, due to how certain protocols may interpret
> certain characters.
>
> One particular case that comes to mind are case insensitive filesystems.
> What
> "insensitiveness" do they use? Even if we ignore the Turkic I and ligatures
> like ß and ff, we still have "simple" cases like mu and micron: on both
> Windows
> and OS X, I can create both files.
>
> $ touch $'\u03bc'.txt $'\u00b5'.txt
> $ ls ?.txt
> µ.txt  μ.txt
>
> This leads to security vulnerabilities like:
>
> QString filename = QString::fromUtf8(socket.readAll());
> if (filename.compare("µ.txt", Qt::CaseInsensitive) == 0) {
> QFile f(filename);
> if (f.open(QIODevice::ReadOnly)) {
> socket.write(f.readAll());
> return true;
> }
> }
> return false;
>
> [Why would you compare µ case insensitively? Because it wasn't the µ I was
> concerned about, but the ".txt" part!]
>

Quite synthetic use case as to me.
Anyways, QUrl has no such issue.

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

Re: [Development] Dropping support for Android 15 and below in Qt 5.7

[Konstantin Ritt]

My +1.


Konstantin

2015-10-27 10:37 GMT+03:00 Eskil A. Blomfeldt via Development <
development@qt-project.org>:

> Hi,
>
> According to the data from Google Play, there are currently only 7.4% of
> active devices on Android versions 15 and below (< 4.1).
>
> https://developer.android.com/about/dashboards/index.html
>
> Since this is a small and diminishing group and since the testing we are
> doing on these old devices is limited, I propose we drop support for
> versions 15 and below in Qt 5.7. It should simplify the code some, and
> definitely our testing requirements.
>
> -- Eskil
> ___
> 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] Override toString() method for c++ QObject types in QML

[Konstantin Ritt]

Maybe JSON.stringify(obj) is what you need?


Konstantin

2015-11-07 21:52 GMT+04:00 Luke Parry :

> Is it possible to override the toString method for native c++ QObject
> types for use in QML scripts?
>
> e.g. using
>
> Q_INVOKABLE QString toString() const;
>
> This doesn't appear to work because it is overridden by some default
> implementation which returns a pointer value. Is this done intentionally?
> Could a workaround  be done through javascript prototype methods...
>
> It would just improve the readability of debug messages and errors when
> running scripts.
>
> Huge Thanks,
> Luke Parry
>
> ___
> 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] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Konstantin Ritt]

2015-10-17 8:58 GMT+04:00 Thiago Macieira <thiago.macie...@intel.com>:

> On Saturday 17 October 2015 07:14:58 Konstantin Ritt wrote:
> > 2015-10-17 6:23 GMT+04:00 Thiago Macieira <thiago.macie...@intel.com>:
> > > On Saturday 17 October 2015 03:34:51 Konstantin Ritt wrote:
> > > > - QString::fromRawData(u"hello world", 5) /* { d=nullptr, b=.., s=5
> } */
> > >
> > > -
> > >
> > > > explicitly means "no owning, deep-copy when necessary"
> > >
> > > And when is it necessary?
> >
> > In a given example, left() derives the original data, even when it isn't
> > shared, whilst leftRef() produces a non-shared QString, just like
> proposed
> > QStringView.
>
> You missed the point.
>
> The whole problem of QString::fromRawData is that the method you called may
> store the QString and thus keep referencing the string you had, even past
> the
> point where your string changed.
>
> In fact, that happens with QStringLiteral too. If you use QStringLiteral
> in a
> plugin and the plugin gets unloaded, the application may crash.
>

Indeed, it is the same issue. QStringView doesn't solve it either.
So the best thing we can do, IMO, is to give the user a tool and describe
how to use it properly to get some extra performance, on his own risk.


> The whole point here was "deep-copy when necessary": when is it necessary?
> If
> we can't solve the two problems above, we are going to make the problem
> worse.


We could probably introduce a QString::ensureSharable() for the advanced
user's goals
and maybe call it in the copy constructor and the assignment operator to
avoid storing a data we do not own. The latter would potentially kill all
the extra performance we got in a first place, though.

In any way, QString::fromRawData() currently has the issue you've described
above, so I have some doubts we'll make the problem even worse.


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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Konstantin Ritt]

>
> > You're misrepresenting the argument. QString doesn't support other
> encodings
> > because UTF-16 is the best for the task at hand and we have too much
> legacy to
> > support. Because of that, QCollator only supports UTF-16.
>
> I buy the legacy argument but I don't buy that utf 16 is the best
> encoding. I think because of legacy we cannot change QString but I think we
> should still support UTF 8 better.
>

So what? This doesn't change the fact UTF-16 has advantages over UTF-8 and
thus QString's backing storage is UTF-16 - and won't be changed to anything
else.


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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Konstantin Ritt]

If QString in Qt6 could be { QArrayData *d; ushort *b; int s }, then it
supersedes QStringView in all aspects:
- QString(u"hello world", 5) /* { d=.., b=.., s=5 } */ - still has a
superpower of COW, etc
- QString::fromRawData(u"hello world", 5) /* { d=nullptr, b=.., s=5 } */ -
explicitly means "no owning, deep-copy when necessary"

then we could get rid of QStringRef (or typedef it to QString) and do
something like:

private:
QString(QArrayData *dd, ushort *unicode, int size) { if (dd) { dd->ref(); }
d = dd; b = unicode; s = size; } /* not that trivial, of course, just to
describe the idea */
public:
QString QString::left(int n) const { return QString(d, b, n); }
QString QString::leftRef(int n) const { return QString(nullptr, b, n); }


> That said, QStringView is as much about
>
> - slim interface type vs. thick, fat, storage type
> - interop with 3rd-party and native code

So as QString now... i.e.

DWORD dwBufferSize = 0;
if (::GetUserProfileDirectory(token, NULL, ) == 0 &&
dwBufferSize != 0) {
QVarLengthArray userDirectory(dwBufferSize);
if (::GetUserProfileDirectory(token, userDirectory.data(),
) == 0) {
QString dirName = QString::fromRawData(userDirectory.constData(),
dwBufferSize); // still unsafe, but it is clearly documented for years and
nothing has really changed for its users anyways
return QDir().exists(
dirName.rightRef(dirName.lastIndexOf(QLatin1Char('\\';
}
}


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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Konstantin Ritt]

2015-10-15 11:00 GMT+03:00 Bubke Marco :

> On October 15, 2015 08:45:30 Knoll Lars 
> wrote:
>
> > On 14/10/15 23:51, "Bubke Marco"  wrote:
> >
> >>On October 14, 2015 23:10:26 Thiago Macieira 
> >>wrote:
> >>> Qt does not have to provide a comparator that operates on something
> >>>other than
> >>> its native string type.
> >>
> >>Isn't Qt a framework to help developers? Sorry your argumentation is
> >>sounds not very empirical.
> >
> > Of course our aim should be to help developers. But there will always be
> > some use cases which we will not cover. The question is whether this is
> > one of them or not.
>
> Most file and network content is in utf 8, databases too. It has simply a
> size and performance advantage for most cases. You have not so many cases
> where you have pure Chinese signs in an text. Mostly it is an mixture. In
> Linux,  which is very important in embedded, utf 8 dominates ťhe APIs. Ask
> your self if we don't want support that. We could start simply and expand
> slowly. If the standard library would support utf 8 collations on all
> platforms very well we could skip it but today you have to do your own
> solutions again and again.
>

For everything but US-ASCII / Latin-1, UTF-8 isn't faster than UTF-16 (feel
free to compare their complexity against UTF-32).
And why "pure Chinese signs" again? Did you ever look into the Unicode's
Scripts.txt [1], for example? It clearly shows UTF-16 covers [almost] all
spoken languages, without any performance hits (in compare to UTF-8), and
all we have to pay is an extra byte per every Base Latin character (in
compare to UTF-8, again).

[1] http://www.unicode.org/Public/8.0.0/ucd/Scripts.txt

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

Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Konstantin Ritt]

2015-10-15 17:52 GMT+03:00 André Somers <an...@familiesomers.nl>:

> Op 15-10-2015 om 14:52 schreef Konstantin Ritt:
> >
> >
> > For everything but US-ASCII / Latin-1, UTF-8 isn't faster than UTF-16
> > (feel free to compare their complexity against UTF-32).
> > And why "pure Chinese signs" again? Did you ever look into the
> > Unicode's Scripts.txt [1], for example? It clearly shows UTF-16 covers
> > [almost] all spoken languages, without any performance hits (in
> > compare to UTF-8), and all we have to pay is an extra byte per every
> > Base Latin character (in compare to UTF-8, again).
> >
> > [1] http://www.unicode.org/Public/8.0.0/ucd/Scripts.txt
> >
> "All we have to pay"? Isn't that quite a significant cost, if your every
> other byte in your data is going to be null?


Only for US-ASCII / Latin-1.

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

Re: [Development] Backwards compatibiltiy break in Qt 5.5

[Konstantin Ritt]

My first instinct was suggesting MS to support Unicode in their console...
but then I tried to reproduce the described issue on OS X and succeeded.

qDebug()  this is сообщение на русском;

which I'd expect to be treated like a byte array, gives me
this is сообщение на русском

though

qDebug()  QString::fromUtf8(this is сообщение на русском);

gives me

this is \u0441\u043E\u043E\u0431\u0449\u0435\u043D\u0438\u0435
\u043D\u0430 \u0440\u0443\u0441\u0441\u043A\u043E\u043C


A bit unexpected, isn't it?


Regards,
Konstantin

2015-07-27 12:20 GMT+03:00 Marc Mutz marc.m...@kdab.com:

 On Monday 27 July 2015 00:25:18 NIkolai Marchenko wrote:
  (I am not entirely sure why I haven't received at least a notification of
  why this post has not appeared the first time I tried to send it, so here
  we go again. Btw, it was Thiago Macieira himself who actually suggested I
  mail this list)
 
 
  Hi! We (Russian Qt community) have a situation we could not resolve with
  Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's
  attention.
  The bug in question is there:
  https://bugreports.qt.io/browse/QTBUG-47316
 
  In version 5.5 Thiago Macieira introduced a compatibility break with
 older
  qt versions.
  This break has come in the form of completely changing the way qDebug()
  prints non-english characters to console.

 I don't think qDebug() should guarantee any output, but your position might
 become a relevant one if logging output also changed. That is something
 that
 we shoudn't change, and since IIIRC, qDebug and logging use the same
 stream,
 you may have a point here.

 Just my 2ct,
 Marc

 --
 Marc Mutz marc.m...@kdab.com | Senior Software Engineer
 KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
 Tel: +49-30-521325470
 KDAB - The Qt Experts
 ___
 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] Q_OBJECT and override

[Konstantin Ritt]

#define Q_OBJECT \

public: \

Q_OBJECT_CHECK \

QT_WARNING_PUSH \

Q_OBJECT_NO_OVERRIDE_WARNING \

static const QMetaObject staticMetaObject; \

virtual const QMetaObject *metaObject() const; \

virtual void *qt_metacast(const char *); \

virtual int qt_metacall(QMetaObject::Call, int, void **); \

QT_WARNING_POP \

QT_TR_FUNCTIONS \

private: \

Q_DECL_HIDDEN_STATIC_METACALL static void
qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \

struct QPrivateSignal {};


Regards,
Konstantin

2015-06-04 17:27 GMT+03:00 Matthew Woehlke mw_tr...@users.sourceforge.net:

 On 2015-06-04 08:12, Christian Kandeler wrote:
  as anyone who uses clang has probably already noticed, this compiler has
  recently added -Winconsistent-missing-override to the collection of
  flags enabled via -Wall.

 What happens if you (push state and) disable the warning at the start of
 the Q_OBJECT expansion, and pop state after?

 Ideally this would tell clang to not consider those functions for the
 purpose of the warning. (And maybe the clang developers would be
 amenable to making it work that way if it doesn't currently.)

 p.s. I don't use clang, but if I did I would probably have this switched
 on as an *error*. Thus, I at least would like to see a solution that
 doesn't involve turning it off globally.

 --
 Matthew

 ___
 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] Q_INVOKABLE QAbstractListModel

[Konstantin Ritt]

2015-05-23 21:20 GMT+04:00 mark diener rpzrpz...@gmail.com:

 Hello:

 I came across a use case where I wanted to return a QAbstractListModel from
 a Q_INVOKABLE in a C++ QObject based class.

 The explicit constructor for QAbstractListModel requires a construction of
 these classes that forces the Q_INVOKABLE to return a pointer to the List
 Model instance.

 I imagine the explicit constructor suppresses a lot of careless bugs.

 But this usage is not currently possible:

 Q_INVOKABLE MyQAbstractListModel* getmodel(void)

 {

return (gmodel) ;

 }


 The QML engine is a bit confused by receiving a pointer to the model
 instead of the entire model itself.

 QML Output:

 qrc:/main.qml:48: Error: Unknown method return type: MyQAbstractListModel*


 Maybe someone on the dev list has an idea on how to return a pointer to a
 model from Q_INVOKABLE or maybe someone doing current builds can add a
 AbstractListModel pointer to the known set or method return types in the
 framework for Qt 5.5.x

 Anybody's comments appreciated...


http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Q_INVOKABLE QAbstractListModel

[Konstantin Ritt]

2015-05-23 21:51 GMT+04:00 m...@rpzdesign.com m...@rpzdesign.com:

 Konstantin:

 Maybe you could add some useful guidance to your response.


Sure I could.


 The point of interest is that it must be a QObject derived return.

 Maybe a pointer to a QObject.


QObject doesn't allow deep-copy, so yes a pointer to a QObject is expected.


 Or maybe there is another way to construct QAbstractListModel that will
 allow for a non-pointer return from Q_INVOKABLE?


It is not about Q_INVOKABLE (which is `#define Q_INVOKABLE`, if you didn't
know).
It is not about constructing something - you're free to construct it
anyhow, here is my bless.


 (But that would be on the stack likely)


Just remember to not delete it whilst it is referenced or gets used.


 More comments appreciated,


Read the docs. No more comments plz.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] Imageformats v2

[Konstantin Ritt]

2015-05-20 19:27 GMT+04:00 Иван Комиссаров abba...@gmail.com:



 2015-05-20 15:18 GMT+03:00 André Somers an...@familiesomers.nl:

  I think that it makes sense to attempt to load a header if it exists.
 If not... Not sure. Probably need to read the entire file in order to
 determine what it contains?


 Any other opinions? I vote for dropping separate header reading:)


I see two bold options: 1) open and read lazily, chunk-by-chunk (where
possible); 2) s/open/setPath|setDevice/ and read just everything.


I would not like it much if information is silently dropped. If you
 make the conversion explicit, it is also explicit what features are
 available for the type you have now. How else are you going to expose that
 information?


 I'm not sure, but typically one knows the type of the document only when
 saving (i.e. file is opened, user changes it, than calls save dialog).
 You don't know which format the document will be saved. IMHO.


ImageDocument doc;
doc.mimeType() // -- invalid, nothing to save
doc.addResourse(Resource(img), ..);
doc.suitableMimeTypes() // -- i.e. mime types for which the pixel format
[and possible metadata] are supported, makes sense for save dialog, etc.
doc.addResourse(Resource(img2), frame=1, ..);
doc.suitableMimeTypes() // -- now we have frames, the mime types list
changes
doc.generateMipmaps();
doc.suitableMimeTypes() // -- ...and mipmaps = image/x-dds?


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

Re: [Development] Imageformats v2

[Konstantin Ritt]

2015-05-19 22:12 GMT+04:00 Rutledge Shawn shawn.rutle...@theqtcompany.com:

 I think the new API should have multi-page support.  It would be useful
 for pdf, djvu, multi-page tiff, and for looking at individual frames of
 animated gif, png, etc., to the extent that we write plugins for those.


IIUC, this already covered by the idea: since we can not (currently?)
support animated pages, we treat both a multi-page tiff and an animated
gif as a document with N frames.


 I wrote a QQuickImageProvider for PDF (using poppler), but requestImage
 takes only an “id” string to identify the image.  So I had to make up a
 composite id containing both the filename and the page number.  (much like
 a URL format would be, if you had to request multiple pages from a web
 server)  So that’s the next API that needs to have some support for paging.

 Can “frame” be considered the same as “page”?  But I see that you also
 have a subimage concept in mind.


IMO, sub-images concept only makes sense when we have layers concept: i.e.
we could have a layer with several image resources, where each resource
could have different size/depth/format + might be transformed and stacked
somehow (so we'll need their z-order and blending mode params at very
least).


 Sometimes (as in icon files, or in any kind of file that also includes a
 smaller preview image) the sub images would be the same thing at different
 resolution, right?  That is orthogonal to the idea of paging: a PDF file
 can have multiple pages, and also embedded thumbnails for each page.  In
 order for an image format plugin to be enough to write a PDF reader
 application, it would need to support paging, and also getting the
 thumbnails for the pages.

 In QQuickImageProvider::requestImage, requestedSize can also be given.  So
 that’s one way to specify a thumbnail: if the available thumbnail is near
 enough to requestedSize, return that instead.  The API anyway does not
 guarantee that you get exactly the size that you ask for.


What you described sounds more like mipmap support. We can not say this is
a thumbnail for page N by looking at the image size only.


 Eventually we could get to the point that a plain Image in QML could be
 used as a PDF viewer, all by itself.  It would also need a paging API.


Then, maybe something like `
property int page: 0
readonly property int pagesCount: pdf.framesCount
ImageDocument {
id: pdf
source: path/to/file.pdf
}
Image {
id: pageViewer
source: pdf
frame: page
}
Image {
id: pagePreview
source: pdf
frame: page
mipLevel: -1
}
` would fit better?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML Settings

[Konstantin Ritt]

To make the settings persistent, you have to set
http://doc.qt.io/qt-5/qml-qt-labs-settings-settings.html#application-identifiers
(note however that settings Qt.application.name  Co won't probably help in
this case (bug?)).

Konstantin


2015-05-13 22:18 GMT+04:00 Federico Buti bacaro...@gmail.com:

 Hi,

 I've inverted the approach, i.e. I've defined the alias in the root
 component and the two property in the Setting type. Result: it still does
 not work.

 Is there anything specific that should be done?

 Thanks to everyone.
 F.
 Hi Dominik.

 No, the documentation is pretty clear about that: alias inside the
 Settings. That's why I've linked it.
 As for the error, that's because the documentation example aliases
 x...but Settings has its own x, obviously! I just got it few minutes
 after I have sent the mail. Trivial error.

 Anyhow, your approach is logical and does make perfectly sense. I'm going
 to test it and report back.

 Thanks for your time!
 F.


 ---
 Federico Buti

 On 12 May 2015 at 13:17, Dominik Holland dominik.holl...@pelagicore.com
 wrote:

  Hi Federico,

 On 05/12/2015 12:14 PM, Federico Buti wrote:

  Hi list(s)

  I was considering the usage of Settings QML
 http://doc.qt.io/qt-5/qml-qt-labs-settings-settings.html for an app
 I'm working on. I just need to store two-three strings across mobile
 platforms and the API seems to fit my use case.
 However, I'm not able to make it work properly and I'm wondering if I'm
 using it the right way. I've tried the code proposed in documentation and I
 got the following error (for the x property):

  Can't load. Errors: (qrc:///main.qml:26:9: Cannot override FINAL
 property)


 I think you got this error because you tried to define your own property
 x ? In this case the property x is already defined as a final property and
 because of that you cannot override it.


  Given this error, I've tried something else, similar to the other
 example proposed in the documentation:


  import QtQuick 2.4

 import Qt.labs.settings 1.0

   Window {

 id: root

 property string id1

  Settings {

 id: settings

 property alias id1: root.id1


 I didn't looked into the QML Settings yet, but I think it should be vice
 versa. The property alias should be in root and the real propery in
 settings. This way the root.id1 would be set once settings.id1 is set (once
 the setting is loaded).

   }

 Component.onDestruction: {

 root.id1 = pippo

 }

 Component.onCompleted: {

 console.info(root.id1)

 }

 }

 The idea was to set the value at the destruction of the component (i.e. app 
 closing) so that, the next time application is started, the stored value is 
 used. Unfortunately, each time the app is restarted no value is fetched from 
 the settings, i.e. a sad qml:  is printed to the console. What am I 
 missing? Where is the error?

 Thanks in advance,

 F.



 ___
 Development mailing 
 listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development


 Best Regards
  Dominik

 --


 ___
 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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Suggested addition to wiki.qt.io/Coding_Conventions

[Konstantin Ritt]

I guess this came from QSslEllipticCurve.
+1 for not doing that until it really affects release build [with
non-broken compilers].

Regards,
Konstantin

2015-05-13 17:45 GMT+04:00 Matthew Woehlke mw_tr...@users.sourceforge.net:

 On 2015-05-13 04:25, Marc Mutz wrote:
  Hi,
 
  I'd like to suggest the following addition to the Qt Coding Conventions:
 
  === Exporting Classes ===
 
  Export polymorphic classes as a whole:
 
  code
class Q_LIB_EXPORT QMyWidget : public QWidget
{ ...
  /code
 
  But don't export non-polymorphic classes that way. Instead, only export
 the
  following non-inline methods.
 
  * public
  * protected
  * private, if called from inline functions (now or in the past)
 
  Rationale: On Windows, symbols from a DLL that don't have inline linkage
  (templates or inline functions have inline linkage) need to be exported
 for
  clients to link against them, This is what the ttQ_*_EXPORT/tt
 macros are
  for. On some Unix systems, the macros map to a similar mechanism that
  emhides/em symbols not exported that way, positively affecting
 startup
  performance and library size.
 
  But exporting the whole class, while convenient, has several drawback:
 
  * it exports symbols that don't need exporting:
  ** private methods never called from user code
  ** methods of private nested structs and classes

 Many Qt classes have corresponding Private (PIMPL) classes. Private
 methods would hopefully be few and far between.

 Is it possible to override the export decoration for things like this
 that should *not* be exported?

  ** inline methods
  * exporting inline methods makes MSVC call the library implementation in
 debug
  builds

 That's a feature. There are reasons why debug builds don't inline
 (mostly because it makes stack traces unreliable).

  ** a copy of the function is placed in the library even though the
 library
  itself may never use it

 What if I need to take the address of an inline method (e.g. to use it
 as a functor argument)?

  ** exported inline functions can no longer be removed

 They can't anyway, as this would be both an API and ABI break; see
 previous point.

 --
 Matthew

 ___
 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] QtModeling - the last mile

[Konstantin Ritt]

Any links/code/docs?)

Konstantin

2015-04-30 0:26 GMT+04:00 Sandro Andrade sandroandr...@kde.org:

 Hi there,

 Some time ago, I started the development of QtModeling : a qt add-on
 aimed at providing metamodeling features and the basic infrastructure
 for dealing with software models. It already has a lot of interesting
 features and now I have the available time to making it good enough to
 be released.

 There are, however, some design choices I would like to discuss and
 get some feedback from some of you guys. Implementing the UML
 metamodel, for example, requires a considerable time investiment. Part
 of this is already done, but I would like to set up a plan to
 incrementally release such features.

 So, would anyone be willing to provide some guidance and keep up with
 QtModeling to its release ?

 Thanks in advance,
 --
 Sandro
 ___
 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] QQuaternion issues with new 5.5 API

[Konstantin Ritt]

2015-04-24 16:33 GMT+04:00 Marc Mutz marc.m...@kdab.com:

 Hi,

 While implementing qHash() overloads for gui/math3d classes, I found that
 QQuaternion gained several methods for 5.5 which I don't like:

 *EulerAngles():

 They are missing a QEulerAngles class. Instead, they deal with (float,
 float,
 float) and QVector3D. One function even returns three floats as out-
 parameters. I think my (partial) work on QDate/Time has shown just how much
 compilers don't like out parameters. The question here is how general such
 a
 QEulerAngles class should be...

 *AxisAndAngle()/*Axes():

 Same here, to a lesser extent. What bugs me most is the return-by-out-
 parameters, not so much that there's no QAxis3D class.

 There are several steps forward:

 - Create QEulerAngles as a float-only class
 - ditto, but as a template
 - ditto, but also add Q*Angle classes that have DEG/RAD hard-coded as
 template
   arguments, with explicit conversions between, then use that in
 QEulerAngles.
   [this likely won't happen for 5.5, though]
 - remove the methods in question for 5.5 and try again in 5.6

 Any opinions about which ones to take?


Sure I wanted to do it via introducing QAngle (which is also useful for
many other classes, even outside math3d), but that's definitely a 6.0
material; and then there is no much sense in introducing it just for
QQuaternion.

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

Re: [Development] QQuaternion issues with new 5.5 API

[Konstantin Ritt]

2015-04-24 16:32 GMT+04:00 Gunnar Sletta gun...@sletta.org:


  On 24 Apr 2015, at 14:33, Marc Mutz marc.m...@kdab.com wrote:
 
  Hi,
 
  While implementing qHash() overloads for gui/math3d classes,

 Why are we doing this? a QHashQMatrix4x4, T makes very little sense me..


Completely agreed.

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

Re: [Development] font selection and weight/style support on OS X: (possible regression from Qt 4 to Qt 5

[Konstantin Ritt]

In case you're on Qt 4.x, look at QFont - QString and QFont -
QDataStream (|de)serialization. I recall there was a bug fixed in ~5.3,
though I don't know if it was backported to 4.x.


Konstantin

2015-04-18 14:34 GMT+04:00 René J.V. rjvber...@gmail.com:

 Hello,

 The specific question: how/where is (QFontEngine *)fe-ctfont set that is
 read in QFontDialogPrivate::setFont (qfontdialog_mac.mm around line 514)?

 I have been looking into an issue with the selection of fonts in
 weights/styles that don't follow the usual four suspects (Normal, Italic,
 Bold, Bold-Italic).
 In stock Qt 4.8, selecting a Medium or Semi Bold weight (i.e. a weight
 between normal and bold) works during the initial selection (say in
 qtconfig's default font selection), but open the font dialog once more, or
 relaunch the application, and that medium weight will have been replaced by
 standard bold.

 I think I have a fix for this in Qt 4.8, which removes the easy shortcut
 I found in 2 places (there's Normal and anything heavier which becomes
 Bold) and extends the weight string parser to support most of the font
 weights you'll find on a typical OS X install.

 It turns out that almost inevitably I came up with code that looks a lot
 like what had already been done for Qt 5.4 (I swear, I didn't peak :))
 except that I didn't introduce additional const variables to complement the
 existing QFont::DemiBold etc. styles.

 We're getting to the question.
 When opening the font dialog with an initial font, Qt 4 calls
 QFontDialogPrivate::setFont() where Qt 5.4 uses
 QCocoaFontPanel::setCurrentFont() . Both functions (can) use [NSFontManager
 fontWithFamily:traits:weight:size], but the Qt4 version is actually called
 with fe-ctfont already set to the appropriate NSFont*.

 And that seems to work more reliably. I have several fonts on my system
 (including the Apple-provided Avenir family) where
 fontWithFamily:traits:weight:size does *not* return the requested typeface,
 as if the weight parameter is ignored. And indeed the documentation for
 that function suggests that the weight parameter is used as a hint only (
 https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFontManager_Class/index.html#//apple_ref/occ/instm/NSFontManager/fontWithFamily:traits:weight:size:)
 though I *hope* that it's used as more than a hint when the requested
 weight actually exists.

 Hence my question: where is fe-ctfont initialised? Clearly this uses a
 different method for obtaining the NSFont (or CFFontRef).

 Note that I've already tried to put all chances on my side for weight: to
 be used as more than a hint. I've analysed the weights in question for all
 fonts on my system (Apple's documentation doesn't bother to document the
 exact value mapping), and came up with the following

 +// RJVB
 +// Thin,Light - 3, Book - 4
 +// Normal/Regular - 5
 +// Medium/SemiBold/Demibold - 6,7,8
 +// Bold - 9
 +// Ultra/Black/Heavy - 10,11
 +QByteArray *weights = NULL;
 +switch (font.weight()) {
 +case QFont::Light:
 +weights = new QByteArray((const char[]){3,4});
 +break;
 +case QFont::Normal:
 +weights = new QByteArray((const char[]){5});
 +break;
 +case QFont::DemiBold:
 +weights = new QByteArray((const char[]){6,7,8});
 +break;
 +case QFont::Bold:
 +weights = new QByteArray((const char[]){9});
 +break;
 +case QFont::Black:
 +weights = new QByteArray((const char[]){10,11});
 +break;
  }

 (evidently I did the same for Apple's other scale, that goes from -1.0 to
 1.0). I then test each of the weights corresponding to font.weight():

 +if (weights) {
 +nsFont = NULL;
 +for (int i = 0 ; i  weights-size()  !nsFont ; ++i) {
 +weight = (int) (*weights)[i];
 +nsFont = [mgr
 fontWithFamily:qt_mac_QStringToNSString(fontInfo.family())
 + traits:mask
 + weight:weight
 + size:fontInfo.pointSize()];
 +}
 +delete weights;
 +}

 the only thing I haven't yet added is an additional check whether
 fontWithFamily did indeed return the requested weight, and not the closest
 lower match (which would let DemiBold downgrade to Normal, or Ultra to
 Bold).

 Thanks for bearing with me, and (even more :)) for any feedback!

 R.
 ___
 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] Rotating JPEG images by default

[Konstantin Ritt]

Just FYI,
http://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/
http://webmasters.stackexchange.com/questions/16684/ipad-and-iphone-browser-rotating-images-on-site
 (note that OS from Apple is a bit special)
and the CSS3 working group discussion:
http://lists.w3.org/Archives/Public/www-style/2011Dec/0001.html


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

Re: [Development] Rotating JPEG images by default

[Konstantin Ritt]

2015-04-23 16:04 GMT+04:00 Alberto Mardegan ma...@users.sourceforge.net:

 On 04/23/2015 02:34 PM, André Somers wrote:
  What is the problem with using
 
  Image {
   source:  someImage.jpg
   autorotate: true
  }
 
  Again: note that QImage != QML Image
 
  I don't like globals if they can be avoided. In this case, I think they
 can.

 I could certainly live with that, but if you renamed autorotate to
 showWithCorrectRotation you'd have to agree that it's a rather silly
 flag. Of course I want my images to appear with the correct rotation. :-)

 I do agree that for QImage leaving the autorotation off can make sense
 in some cases. But for QML Image, I cannot think of a single case where
 I wouldn't want a JPEG to be automatically rotated.


The behavior must be consistent for both.
I cannot think of a single case where you would want text direction to be
automatically applied in QML but not in QTextDocument (not an ideal
example, but still).

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

Re: [Development] Rotating JPEG images by default

[Konstantin Ritt]

Konstantin

2015-04-22 15:32 GMT+04:00 Alberto Mardegan ma...@users.sourceforge.net:

 On 04/22/2015 09:39 AM, André Somers wrote:
  I'm with Konstatin on this one: it seems like a regression to me. It
  would be a useful feature to add, but then add it in such a way that it
  is actually clear what it does, the user can control it, and it does not
  break applications. I think it _is_ relevant how the image is encoded.

 It may be that we disagree because we have a different view of what is
 the goal of QImage and friends. To me, what matters is not the pixel
 data, but how the image looks like when I blit it.
 I'm writing an image viewer using QML, and I just expect that

Image {
  source: file.jpg
}

 will show me the file as it's intended to be viewed. I don't think that
 it's acceptable to require the developer to play with flags in order to
 see the image with the correct rotation.


In your image viewer, you'll have 99 other QML Image elements for
buttons/background/whatever that doesn't load photos.
I don't think your expectation/intention is to make all your UI elements
1) dependent on a metadata ignored by most image viewers (- crap, editor
shows me a 400x300 image and it appears to be 300x400 in QML. stupid QML!
stupid trolls! I need to kill someone...)
2) behave differently prior to 5.4 and after 5.4.

Enabling that feature in 5.4 IS a behavioral regression which must be fixed.

 If the camera really wanted to put the image in the right side up, it
  should have just rotated the actual image. By default, I would expect to
  load the image as-is.

 We disagree on what as-is means. :-) For me, EXIF information is an
 integral part of the image.


Regardless of how you interpret image as it's intended to be viewed, CSS
doesn't do auto-rotation by default - one have to enable this feature where
needed.


 Also, sometimes the camera guesses the orientation wrong (especially
 when you shoot at the sky or at the ground), and the best way to correct
 that is to do it in a lossless way, using the EXIF rotation flag; there
 are several image viewers that allow you to do this.


Unrelated. It doesn't matter where to transform - on the camera, in the
viewer, or at load time.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Rotating JPEG images by default

[Konstantin Ritt]

 On Thursday, 23 April 2015 00:11:23 CEST, Alberto Mardegan wrote:
  as long as the behaviour was configurable with a single line
  change (a static method on QGuiApplication, maybe?).


Stop polluting QGuiApplication! Seriously.

We already have a complete solution -
https://codereview.qt-project.org/110685
All we need now is to fix the behavioral regression introduced in 5.4.

Konstantin

P.S. I bet most of you didn't know about this new cool feature until this
thread, just like me.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Rotating JPEG images by default

[Konstantin Ritt]

I failed to find an official announcing for the EXIF-based auto-rotation of
QImage-s (correct me if I'm wrong), so it looks just like a behavioral
regression to me, nothing more.
IMO, we should revert the behavior to pre 5.4 and give the control over the
image aspects to the user, not to an arbitrary image loader.
I mean https://codereview.qt-project.org/#/c/110685/ and
https://codereview.qt-project.org/#/c/101084/ could co-operate quite nicely
to make the user think: why my photo gets loaded rotated 90 degrees? ah,
img.sourceOrientation() == QImage::Rotated90 --
img.transform(img.sourceOrientation()))

P.S. Also not the sample image in QTBUG-37946
https://bugreports.qt.io/browse/QTBUG-37946 isn't auto-rotated in your
web browser (well, at least in my web browser).


Regards,
Konstantin

2015-04-17 16:23 GMT+04:00 Rainer Keller rainer.kel...@theqtcompany.com:

  I would like to mention one extra relevant detail. While this was
 implemented
  for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So
 sofar
  only 5.4.1 has had EXIF orientation automatically applied on JPEGs. This
 also
  raises the question about what to do for 5.4.2?
 I actually worked, theoretically. There was a bug with the endianess
 when reading the data field. It worked when data was generated on little
 endian machines but all photo cameras are big endian.
 This means only photos taken on x86 machines would have been rotated.

 ___
 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] Rotating JPEG images by default

[Konstantin Ritt]

And to be honest, I don't like the QImage::orientation() API addition w/o
providing setOrientation() and a respective code code in the image writer
to store orientation as metadata (when possible).
`QImage img(sourcePath); img = img.scaled(img.width() / 2, mg.height() /
2); img.save(destPath);` should not loose the metadata when the format has
not been changed (at least).

Regards,
Konstantin

2015-04-20 8:37 GMT+04:00 Konstantin Ritt ritt...@gmail.com:

 I failed to find an official announcing for the EXIF-based auto-rotation
 of QImage-s (correct me if I'm wrong), so it looks just like a behavioral
 regression to me, nothing more.
 IMO, we should revert the behavior to pre 5.4 and give the control over
 the image aspects to the user, not to an arbitrary image loader.
 I mean https://codereview.qt-project.org/#/c/110685/ and
 https://codereview.qt-project.org/#/c/101084/ could co-operate quite
 nicely
 to make the user think: why my photo gets loaded rotated 90 degrees? ah,
 img.sourceOrientation() == QImage::Rotated90 --
 img.transform(img.sourceOrientation()))

 P.S. Also not the sample image in QTBUG-37946
 https://bugreports.qt.io/browse/QTBUG-37946 isn't auto-rotated in your
 web browser (well, at least in my web browser).


 Regards,
 Konstantin

 2015-04-17 16:23 GMT+04:00 Rainer Keller rainer.kel...@theqtcompany.com:

  I would like to mention one extra relevant detail. While this was
 implemented
  for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So
 sofar
  only 5.4.1 has had EXIF orientation automatically applied on JPEGs.
 This also
  raises the question about what to do for 5.4.2?
 I actually worked, theoretically. There was a bug with the endianess
 when reading the data field. It worked when data was generated on little
 endian machines but all photo cameras are big endian.
 This means only photos taken on x86 machines would have been rotated.

 ___
 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] QFont qfontForThemeFont(ThemeFontID themeID)

[Konstantin Ritt]

AFAICT, there is no any more occurrences except in qt_mac_p.h
Same for QColor qcolorForThemeTextColor(ThemeTextColor themeColor), BTW.

Regards,
Konstantin

2015-04-16 21:39 GMT+04:00 René J.V. rjvber...@gmail.com:

 Hi,

 Is the old QFont qfontForThemeFont(ThemeFontID themeID) from Qt 4 still
 used somewhere in Qt 5.4+ or is its prototype in qt_mac_p.h just a remnant?

 R.
 ___
 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] Updating of 3rdparty stuff

[Konstantin Ritt]

2015-04-08 15:28 GMT+04:00 Eirik Aavitsland 
eirik.aavitsl...@theqtcompany.com:


 Good stuff, and libpng gets updated to 1.6.17 here
 https://codereview.qt-project.org/109973

 - Eirik Aa.


Someone have to upstream the WinCE and WinRT specific patches to libpng.

Konstantin




 On 04/08/2015 10:15 AM, Liang Qi wrote:
  qtimageformats: libwebp 0.4.3 update
 
  https://codereview.qt-project.org/109955
  https://codereview.qt-project.org/109956
 
  And checked other 3rdparty: jasper, libmng, libtiff, there is no update
  from upstream.
 
  After Beta released, I will help to update qt doc and
  https://wiki.qt.io/Third_Party_In_Qt
 
  Regards,
  Liang
 
 
  On 7 April 2015 at 06:56, Thiago Macieira thiago.macie...@intel.com
  mailto:thiago.macie...@intel.com wrote:
 
  Any volunteers?
  --
  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
 
 
 
 
  --
  http://www.qiliang.net
 
 
  ___
  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 mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Errors in release mode only

[Konstantin Ritt]

 QEventLoop: Cannot be used without QApplication

Says everything.

Show your code.

Regards,
Konstantin

2015-03-30 23:21 GMT+04:00 raven-worx Software i...@raven-worx.net:

 Hi,

 i get the following print outs to the console and absolutley have no clue
 why:

 SHIMVIEW: ShimInfo(Complete)
 QEventLoop: Cannot be used without QApplication
 QObject::connect: Cannot connect (null)::aboutToQuit() to
 QNativeWifiEngine::closeHandle()

 But this only happens in RELEASE MODE! DEBUG mode works fine and these
 print outs are not showing up.

 I even get these print outs when my main() only returns 0, so no
 QApplication is instantiated meaning as soon as i link against Qt
 binaries.

 Once the application starts up i also noticed that (queued) signals
 from other threads are not delivered anymore, which most probably
 involves the QEventLoop error message somehow. But on the other hand
 events from the OS are delivered.

 I am using:
 QtCreator 3.3.1, MSVC2012, Qt 5.4.1


 ___
 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] image format plugins

[Konstantin Ritt]

2015-03-19 8:42 GMT+04:00 Thiago Macieira thiago.macie...@intel.com:

 On Thursday 19 March 2015 04:54:09 Konstantin Ritt wrote:
  Hi guys.
 
  What do you think about moving gif and ico plugins from qtbase
  to qtimageformats?

 Why? What's the reason?


Well, we have a separate module for non-mandatory image format plugins - so
why not having them in a single place?


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

Re: [Development] image format plugins

[Konstantin Ritt]

2015-03-19 18:23 GMT+04:00 Thiago Macieira thiago.macie...@intel.com:

 On Thursday 19 March 2015 15:05:38 Konstantin Ritt wrote:
  2015-03-19 8:42 GMT+04:00 Thiago Macieira thiago.macie...@intel.com:
   On Thursday 19 March 2015 04:54:09 Konstantin Ritt wrote:
Hi guys.
   
What do you think about moving gif and ico plugins from qtbase
to qtimageformats?
  
   Why? What's the reason?
 
  Well, we have a separate module for non-mandatory image format plugins -
 so
  why not having them in a single place?

 Your premise is incorrect. It's not about non-mandatory.

 So, what's the reason we should do it?


I didn't say we *should* do it. Simply asking for opinions.

There is no any single .ico file in qtbase (except of ones in
qicoimageformat auto-test) and we don't support -no-ico/-qt-ico/-plugin-ico
configure options, which makes it a good candidate.
There is also just a single .gif file in widgets/movie example, though we
support -no-gif configure option and widgets/movie example never checks if
gif format is really supported.
^ So why bloating qtbase?

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

[Development] image format plugins

[Konstantin Ritt]

Hi guys.

What do you think about moving gif and ico plugins from qtbase
to qtimageformats?

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

Re: [Development] [RFC] more gerrit codereview scores?

[Konstantin Ritt]

[Not really in-topic but still...]
Can we also introduce a flag with meaning like this change doesn't require
clean build?
For example, when the approver gives his +2 to a simple change in the .h
file, he can also turn that flag on -- iff all staged changes has this flag
on, then CI does incremental build and runs auto-tests as usual.


Konstantin

2015-03-09 11:30 GMT+04:00 Knoll Lars lars.kn...@theqtcompany.com:

 On 07/03/15 04:03, Thiago Macieira thiago.macie...@intel.com wrote:

 On Friday 06 March 2015 17:42:00 Oswald Buddenhagen wrote:
  1) i'd like to propose the introduction of the code review score -3.
 
  -1: I would prefer this is not merged as is, advisory, non-sticky
  -2: This shall not be merged as is, blocking, non-sticky
  -3: This shall not be merged [at all], blocking, sticky
 
 Agreed, this makes sense. The -1 means if someone approves, ignore me,
 whereas -2 means this needs to change, can't be merged.
 
 The -3 is just to indicate an approach that can never work, such as a
 feature
 we cannot accept or a patch submitted to the wrong branch. -2 are already
 rather rare, so I expect -3 to be used only once in a blue moon.

 Agree, it would be nice to have a non sticky -2, so the sticky -3 makes
 sense.
 
  2) i'd like to propose the introduction of the code review score +3.
 
  let's start with the scores:
 
  +3: Looks good to me, approved, enabling
  +2: Looks good to me, but someone else must approve, advisory
  +1: Someone else must review this, advisory
 
  possible uses:
  - non-approvers (specifically, not-yet-approvers) would have two levels
to express their opinion
 
 You mean four levels, since they also get -1 and 0.
 
  - the new +1 gives the possibility to explicitly give a neutral score
(substitute for +0, which gerrit does not permit)
  - *maybe* some approvers would feel less inclined to approve changes
they don't fully understand (yes, this is actually a problem), simply
because of the psychological effect of the possibility to express the
opinion with more numerical nuance.
 
  i don't feel very strongly about this one, but i think it would add
  value.
 
 I don't like this one.
 
 If you don't want to express an opinion, leave your score at 0. I don't
 see
 the need to have a value saying I've reviewed but have no opinion. I
 also
 don't see why approvers are giving +2 if they don't fully understand it.
 Not
 only should they be using the right value for that, this change wouldn't
 help
 in any way since they could just turn around and give +3 to changes they
 don't
 fully understand.
 
 As a drawback, it would make Qt's Gerrit behave very differently from
 everyone
 else, where a +2 does mean approval.
 
 In my opinion, this change has no pros and has cons.

 While I see the reasoning behind, I think this overcomplicates things. A
 non-sticky -2 that balances a +2 should be enough to solve most of the
 issues, and the proposed +1 sounds very much like the current +0 to me, so
 we can IMO just as well leave it out.

 Cheers,
 Lars

 ___
 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] Adding .mtl files into qt3d+qt5.5 based application

[Konstantin Ritt]

Here is where Sean opens a 3D modelling for dummies courses :P

Closer to the original topic: there is a SceneLoader that loads a scene
(i.e. obj/dae/blender) and adds the loaded scene elements to the Qt3D
scene, retaining the original relationships (so that all materials assigned
to the mesh will be put to a respective QEntity).
Loading materials alone is something strange.

Regards,
Konstantin

2015-03-18 16:16 GMT+04:00 Sean Harmer sean.har...@kdab.com:

 Hi,

 On Wednesday 18 Mar 2015 16:59:51 Arjun Das wrote:
  Hi,
 
  One last question on the same topic, I can see that most of the .obj
 files
  in the examples are created using blender. How were the corresponding
 .webp
  files created?
  For instance chest.obj has a corresponding diffuse.webp, so how were
 these
  webp created. I can see that they are not arbitrary images since they
  perfectly cover the 3D model (Chest.obj in this case)?

 Right. These are made by defining texture coordinates (uv unwrapping or
 mapping) in a modelling tool such as blender, 3d max, maya etc, and then
 somebody with much more artistic talent than I have paints the texture and
 saves it as an image. So then the texture coordinates saved in the exported
 obj file in conjunction with the texture image (png or webp or whatever)
 then
 gets nicely applied to the geometry when rendered.

 In this case, the chest came from Nobiax:

 https://www.youtube.com/channel/UCMDRuUy1Hg4aoJyBhv_8hrg

 Cheers,

 Sean
 --
 Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
 KDAB (UK) Ltd, a KDAB Group company
 Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
 Mobile: +44 (0)7545 140604
 KDAB - Qt Experts
 ___
 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] QtCore missing check for memory allocation

[Konstantin Ritt]

Maybe a bit off-topic: can we introduce our own (probably customizable)
 memory allocation API, something like Apple's CFAllocator [1], and move Qt
internals to use it instead of malloc/realloc/free (and maybe instead of
some new/delete-s, based on some policies)?
Then we could let the user to decide if he needs a OOM safety, i.e. with
QAllocator::setDefaultAllocator(..)
Such a centralized memory allocation routines also could be very useful
in debugging or memory consumption monitoring.

Regards,
Konstantin

[1]
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFAllocatorRef/

2015-02-26 0:29 GMT+04:00 Marc Mutz marc.m...@kdab.com:

 On Wednesday 25 February 2015 16:30:56 Giuseppe D'Angelo wrote:
  And on the other hand, this assumption of having infinite memory has
  held for a while

 Only in the niche that Qt exists in. Now, the question is whether Qt does
 not
 play a role in systems that handle oom gracefully because Qt doesn't handle
 them gacefully or whether it doesn't play a role in those systems because
 there are no such systems.

 But I'm sure there are embedded systems that fall in between the desktop
 model
 of inifinite VM space and hard-realtime systems that allow no dynamic
 memory
 allocations after program initialisation. For such systems, recovering from
 oom is actually a plausible alternative. Relying on the oom killer in a
 soft
 realtime application is asking for trouble. It can literally take an hour
 for
 the system to recover. I just experienced a 50min thrashing when I dared to
 start up a 4GB VM without waiting for qtcreator to fully quit. The oom
 killer
 killed qt-creator, but it _did_ take 50mins.

 As Ossi said, overcommitting is likely turned off in those systems. BTW,
 IIRC,
 you also get nullptr mallocs (without thrashing swap first when you run
 into
 user-defined ulimits.

 If Qt wants to be(come) relevant to that part of the embedded space (or
 that
 part of server space that still uses ulimit), we better stop acting like
 there's only infinite memory.

  -- why should now people have a slower library because
  of all those checks?

 Q_CHECK_PTR does not necessarily make the library slower. It only needs to
 be
 applied to malloc/calloc and nothrow operator new, because ordinary new
 already throws. We can port such code to normal operator new instead.

 Thanks,
 Marc

 --
 Marc Mutz marc.m...@kdab.com | Senior Software Engineer
 KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
 www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
 KDAB - Qt Experts - Platform-Independent Software Solutions
 ___
 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] trying to build qt 5.5 git branch. Missing qtbase\include dir and content.

[Konstantin Ritt]

How did you configure it? Did you run configure.bat?

Regards,
Konstantin

2015-02-24 10:42 GMT+04:00 Gunnar Roth gunnar.r...@gmx.de:

 Hello,
 i am trying to build qt5.5 from git on windows . i do not want to make a
 deveolper build but want to build the code as i normally do.
 After creating the configure.exe, configureing and starting the build,
 qtcore build fails because it cannot find headers, which normally reside in
 qtbase\include but this is completely missing in the git src code.
 what do i need to do to create the source code in a form like it is in
 released tar.gz files?

 Thank you in advance,
 Gunnar Roth


 ___
 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] SSL Plans for Qt 5.6

[Konstantin Ritt]

2015-02-21 21:30 GMT+04:00 Richard Moore r...@kde.org:

 Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
 frame:

 * Complete removal of openssl 0.9.8 support

 This has been unsupported for a while and was really only retained since
 it is the only version apple ship on OS X (though they don't actually
 recommend using it). Qt 5.5 introduces the new SecureTransport backend for
 SSL so there's now no good reason to continue having all the ifdefs.
 Openssl 0.9.8 will reach EOL in December anyway. In addition to removing
 the support from the sources, I suspect this will involve some changes to
 how the library is searched for when we use dlopen.


To me, it looks like a subject for 5.5. Why not?

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

Re: [Development] SSL Plans for Qt 5.6

[Konstantin Ritt]

2015-02-21 22:05 GMT+04:00 Richard Moore r...@kde.org:


 On 21 February 2015 at 17:34, Konstantin Ritt ritt...@gmail.com wrote:

 2015-02-21 21:30 GMT+04:00 Richard Moore r...@kde.org:

 Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
 frame:

 * Complete removal of openssl 0.9.8 support

 This has been unsupported for a while and was really only retained since
 it is the only version apple ship on OS X (though they don't actually
 recommend using it). Qt 5.5 introduces the new SecureTransport backend for
 SSL so there's now no good reason to continue having all the ifdefs.
 Openssl 0.9.8 will reach EOL in December anyway. In addition to removing
 the support from the sources, I suspect this will involve some changes to
 how the library is searched for when we use dlopen.


 To me, it looks like a subject for 5.5. Why not?


 5.5 is already feature frozen.


The SecureTransport backend has been already introduced - that's a feature,
a dep. library version bump is not :)
Well, IMO.

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

Re: [Development] Mime database size

[Konstantin Ritt]

2015-02-19 9:52 GMT+04:00 Thiago Macieira thiago.macie...@intel.com:

 We might not be able to rely on it being there on all systems, but we could
 provide a configure switch that lets distributors say yes, I confirm it's
 always there, so don't bundle a copy.

 Similarly, we can provide a switch that says all locales are UTF-8, so
 optimise QString::to/fromLocal8Bit.


Sounds good to me.
Actually, I wonder why we didn't that years ago.

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

Re: [Development] Why can't QString use UTF-8 internally?

[Konstantin Ritt]

2015-02-12 13:11 GMT+04:00 Rutledge Shawn shawn.rutle...@theqtcompany.com:

 Consequently we have to do conversion each time we need the renderable
 text, and/or cache the results to avoid converting repeatedly.  Right?


Pnrftm... what? Cache what? And where? I've missed the point...


   And we still need to be able to do conversion to renderable glyphs, and
 maybe cache them.


Glyphs? Where glyphs came from?


 So Unicode is a mini-language which has to be interpreted at some point on
 the way to rendering; there’s no pre-interpreted form we could store it
 in.  TrueType is also a mini-language.  Maybe it would be possible to write
 a compiler which reads UTF-8 and TrueType and writes (nearly) branch-free
 code to render a whole line or block of text, so we could cache code
 instead of data.  It could be more compact and CPU cache-friendly.  I
 imagine nobody has done that yet.  But then if you think about all the
 fancy stuff TeX can do, it could get even more complex than what Qt
 currently does.  And I don’t understand much about what Harfbuzz does yet,
 either.


TrueType doesn't define a codepoint to glyph mapping. In fact, glyph
indices for the same codepoints would be different for two arbitrary TT
fonts.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why can't QString use UTF-8 internally?

[Konstantin Ritt]

2015-02-11 20:35 GMT+04:00 Thiago Macieira thiago.macie...@intel.com:

 There are probably more examples.


ftp://ftp.unicode.org/Public/UNIDATA/SpecialCasing.txt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why can't QString use UTF-8 internally?

[Konstantin Ritt]

FYI: Unicode codepoint != character visual representation. Moreover, a
single character could be represented with  a sequence of glyps or vice
versa - a sequence of characters could be represented with a single glyph.
QString (and every other Unicode string class in the world) represents a
sequence of Unicode codepoints (in this or that UTF), not characters or
glyphs - always remember that!

Regards,
Konstantin

2015-02-11 20:49 GMT+04:00 Matthew Woehlke mw_tr...@users.sourceforge.net:

 On 2015-02-11 11:29, Thiago Macieira wrote:
  On Wednesday 11 February 2015 11:22:59 Julien Blanc wrote:
  On 11/02/2015 10:32, Bo Thorsen wrote:
  2) length() returns the number of chars I see on the screen, not a
  random implementation detail of the chosen encoding.
 
  How’s that supposed to work with combining characters, which are part of
  unicode ?
 
  That's true. And add that there are some zero-width characters too and
 some
  characters that are double-width.

 I'm not going to claim this is the *best* answer, but at least one that
 seems logical... length() should be the number of times one must hit
 backspace starting from the end of the text to erase the entire text.
 IOW, the number of logical glyphs. Double-width characters are one
 logical glyph. Combining characters are not independently logical glyphs
 (e.g. 'ñ' is one glyph, regardless of how it is encoded).

 Conversely, I'm sure there are times when you need to know the number of
 codepoints (e.g. allocating memory to make a copy). Possibly length()
 and size() should return different results. (Which is a mess, but...)

 --
 Matthew

 ___
 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