Re: [Development] Asking for a FF exception for ICU based QStringConverter

[Alexander Akulich]

On Thu, Jun 9, 2022 at 10:14 PM Thiago Macieira
 wrote:
>
> Doesn't work for libraries.
>
Can you explain please? I see this correspond to 5.0.0 until
QCoreApplication constructor called but I thought it would be 'better
than a leak'.
QCoreApplicationPrivate::app_compile_version is a part of QtCore, so
even if it won't work *across* the libraries, it is still available
for QStringConverter because it is a part of the same library.

> Much simpler to add an overloaded constructor
Yes. It is good that we have options.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Asking for a FF exception for ICU based QStringConverter

[Alexander Akulich]

Hi everyone,

On Wed, Jun 8, 2022 at 5:18 PM Fabian Kosmale  wrote:
>
> What remains to be done:
> - There are concerns that mixing Qt versions might lead to an unbounded 
> memory leak with the current implementation.

I can't find any precedent but if we *really* want then probably we
can get the "compiled with" Qt version from QCoreApplication
(QCoreApplicationPrivate::app_compile_version).

1. Allocate the resources only if the version >= 6.4.0
2. Probably add a "TODO: remove me" in 6.x.0 (e.g. after the next LTS)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Maintainance Tool

[Alexander Akulich]

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

Re: [Development] Maintainance Tool

[Alexander Akulich]

My point is that if you do not restrict the access to the source code,
then people in Russia and Belarus still can: use Qt, find bugs, do
fixes. The only thing which is cut is the option to contribute back.

It affects only those who speak English and want to work with the
entire world regardless of the origin, culture, gender, race, etc.

No binaries? Fine. No commercial services? Sure.
But letting access to the latest source code, yet blocking the
contributions? Makes no sense.

On Sun, Mar 6, 2022 at 1:46 PM Volker Hilsheimer
 wrote:
>
> Hi,
>
> The European Union adopted sanctions targeting Russia and Belarus. Perhaps 
> some of you participating in this thread are not be fully aware of the 
> situation, so attached the relevant Etude from the European Parliament [1].
>
> These sanctions include access and transfer of technology that might be used 
> in military applications. Qt might be used in military applications (it is 
> today).
>
> You might disagree with the way the EU’s is responding to Putin’s acts of 
> terror; and you might disagree with The Qt Company’s interpretation and 
> implementation of these sanctions. But suggesting that anyone is restricting 
> access to binary packages out of ethnical or racial motives, surely is 
> beneath this community.
>
> Stay safe.
>
> Volker
>
>
>
> [1] 
> https://www.europarl.europa.eu/RegData/etudes/ATAG/2022/729287/EPRS_ATA(2022)729287_EN.pdf
>
>
>
> > On 5 Mar 2022, at 18:59, evilruff  wrote:
> >
> > I never had a point to escalate it, neither any reasons to be rude or hard 
> > talk, but i really want to have an answers to following:
> >
> > - Do you consider all Russians/Belaraus people somehow worse to access the 
> > same open source resources then other people in the world?
> >
> > - If so, how would you explain those actions
> >
> > - If you exclude certain nations based on nationality/geographic 
> > locations/political preferences can you please loud and clear announce a 
> > full list of the people you would like to exclude and the reasons to do so
> >
> > Best regards,
> > Yuri
> >
> >
> >
> > Отправлено с устройства Galaxy
> >
> >
> >  Исходное сообщение 
> > От: Elvis Stansvik 
> > Дата: 05.03.2022 3:36 ПП (GMT+03:00)
> > Кому: Tuukka Turunen 
> > Копия: development@qt-project.org
> > Тема: Re: [Development] Maintainance Tool
> >
> > You answered two out of the five questions Konrad had. Can you answer
> > the remaining ones?
> >
> > Cheers,
> > Elvis
> >
> > Den lör 5 mars 2022 kl 11:08 skrev Tuukka Turunen :
> > >
> > > Hi Konrad et al,
> > >
> > >
> > >
> > > Like already mentioned Qt Project systems, code.qt.io repositories, 
> > > github mirror etc are not blocked. Online installer for open-source users 
> > > is blocked from Russia and Belarus based IP addresses. Plan is to block 
> > > also download.qt.io and possibly some of the qt.io websites. These are 
> > > done based on IP address.
> > >
> > >
> > >
> > > Blocking the installer and access to binaries affects a much larger 
> > > number of users than those who are active in the community. It impacts 
> > > also many who create closed source products using the open-source Qt.
> > >
> > >
> > >
> > > Yours,
> > >
> > >
> > >
> > > Tuukka
> > >
> > >
> > >
> > > From: Development  on behalf of 
> > > Konrad Rosenbaum 
> > > Date: Friday, 4. March 2022 at 23.25
> > > To: development@qt-project.org 
> > > Subject: Re: [Development] Maintainance Tool
> > >
> > > Hi Tuukka,
> > >
> > > I believe an official statement from the Qt Company is in order - right 
> > > now people are forced to find out the hard way whether they are blocked 
> > > and how far the block goes. It is impossible to tell whether it is on 
> > > purpose or not and what the purpose would be.
> > >
> > > It does not matter what side people are on, they deserve to know what's 
> > > happening to them.
> > >
> > > It's also easier to accept and support this, if we know what "this" is.
> > >
> > >
> > >
> > > Please state very clearly:
> > >
> > > Who is being blocked? (Location, commercial customers, open source users, 
> > > developers, ...?)
> > >
> > > Why are they blocked and for how long? (We might even agree with your 
> > > reasoning.)
> > >
> > > What services are supposed to be blocked and which ones are not supposed 
> > > to be blocked? (Commercial vs. Open Source, Binary vs. Source Downloads, 
> > > Users vs. Contributors, ...)
> > >
> > > Where to report bugs in this block? (e.g. is Konstantin really supposed 
> > > to be blocked from contributing?)
> > >
> > > And what discussions will be redirected to /dev/null?
> > >
> > >
> > >
> > > Right now we live in a situation that we all had hoped would not occur 
> > > again in Europe. We had hoped that the hard learned lessons of our grand 
> > > parents would prevent this from happening. Let's at least try to be a 
> > > voice of reason in this situation.
> > >
> > >
> > >
> > > Konrad
> > >
> > >
> > >
> > > On 04/03/2022 

Re: [Development] Maintainance Tool

[Alexander Akulich]

The block is actually helping the Russian government. It wants to isolate
ru people and you want to isolate ru people too. How wise!

Leaving ru alone with propaganda won't help at all.
People who do or want to contribute to the worldwide opensource projects
are *not* the same as people who make or support war(s).

GitHub got it right: https://github.com/github/feedback/discussions/12042

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
>
>
> пт, 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
>> 

Re: [Development] New Qt Multimedia

[Alexander Akulich]

On Wed, May 26, 2021 at 5:25 PM Jason H  wrote:
>
> 4. On the removal of QAbstractVideoFilter AND QVideoProbe: Disappointed to 
> hear this. I previously used this for read-only frames for analysis, i.e. 
> Barcode reading and object detection. How do we do that now?

I second that. QAbstractVideoFilter used for read-only video (camera)
data access for QR-code recognition. On mobile platforms, it is very
important to lower resource usage and zero-copy is very important. We
barely get 30 FPS on low-end devices.
Is there an alternative API for that?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

I started to work on the error() signal renaming here:

https://codereview.qt-project.org/q/topic:%22error-occured%22


On Wed, Feb 5, 2020 at 10:12 PM Thiago Macieira
 wrote:
>
> On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> >
> >  wrote:
> > > The correct signal for an error situation is errorOccurred, like in
> > > QLocalSocket and QProcess.
> >
> > Actually both QLocalSocket and QAbstractSocket renamed the "error()"
> > getter to keep using "error()" signal as opposed to many other Qt
> > modules "errorOccurred()" signals.
>
> Which is the opposite of QProcess and violates the naming convention. Signals
> are named after verbs in the past tense and properties & property getters are
> simple nouns. So "error" is the getter, "errorOccurred" is the signal.
>
> qprocess.h:
>
> #if QT_DEPRECATED_SINCE(5, 6)
> QT_DEPRECATED_X("Use QProcess::errorOccurred(QProcess::ProcessError)
> instead")
> void error(QProcess::ProcessError error);
> #endif
> void errorOccurred(QProcess::ProcessError error);
>
>
> --
> 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] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

Are we going to provide some Qt5 → Qt6 migration tool? It is trivial
to grep the sources for "SIGNAL(error(QAbstractSocket::SocketError))"
and print a warning about the dangerous Qt4-style connection.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

On Thu, Feb 6, 2020 at 4:52 PM Alex Blasche  wrote:
>
> Considering that our naming convention for error() signals is inconsistent 
> anyway, I favour an approach that highlights API changes early.

The convention can not be inconsistent. It can either do not exist
("we have no convention, so we're agreed to do whatever we want and
have inconsistency in the API") or it can exist, so we want to follow
it by definition.

If we have the convention that goes against the API then it would make
sense to either adjust/withdraw the convention or apply it at the
right time for the latest minor Qt 5 release.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

Do we want to sort out all overloads of error() signal/getter in all
(essential?) modules for Qt 6?

For example, Qt Multimedia still has more than a dozen public classes
with such overloads (of a signal and a getter) in 5.15 and dev.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
 wrote:
>
> The correct signal for an error situation is errorOccurred, like in
> QLocalSocket and QProcess.

Actually both QLocalSocket and QAbstractSocket renamed the "error()"
getter to keep using "error()" signal as opposed to many other Qt
modules "errorOccurred()" signals.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

On Wed, Feb 5, 2020 at 7:29 PM Alexander Akulich
 wrote:
>
> On Wed, Feb 5, 2020 at 1:11 PM Ville Voutilainen
>  wrote:
> >
> > Isn't that an ABI break?
>
> Yep; this is what we're doing here (we're deprecating and sorting out
> the API to break the ABI in Qt 6).

(I thought that it is obvious, but it seems to be not the case, so:)
I mean that we want to prepare and improve the API for Qt 6, so we
need to add some signals and mark some others as deprecated. This is a
well-known procedure and it is not an ABI breakage for a regular (e.g.
not "no-deprecated") build. What I'm proposing to do is basically to
apply for QAbstractSocket the same API changes as done in [1] for
QProcess.

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

On Wed, Feb 5, 2020 at 1:11 PM Ville Voutilainen
 wrote:
>
> Isn't that an ABI break?

Yep; this is what we're doing here (we're deprecating and sorting out
the API to break the ABI in Qt 6).
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

It seems "feature freeze" != "API freeze" and the API review for 5.15
is still "to be done", so we still can raise the objection at the
right time for Qt 5.15.

The API consistency is one of the biggest advantages of Qt and I
really hope that we won't stop caring about it.


On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
 wrote:
>
> On Wednesday, 5 February 2020 02:12:06 PST Alexander Akulich wrote:
> > Oh, I'm sorry for the spam! You already renamed error() getter to
> > sockerError() [1], so the issue is not relevant now.
> > It's a bit unfortunate to see such diversity in the API. error()
> > getter seems to be a convention in Qt. I thought that the same
> > convention is to use '-ed' verbs in signal names.
>
> It is. The correct signal for an error situation is errorOccurred, like in
> QLocalSocket and QProcess.
>
> --
> 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] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

Oh, I'm sorry for the spam! You already renamed error() getter to
sockerError() [1], so the issue is not relevant now.
It's a bit unfortunate to see such diversity in the API. error()
getter seems to be a convention in Qt. I thought that the same
convention is to use '-ed' verbs in signal names.

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.15=94b3dd77f29a00ebbd1efdc66d75f57e1c75b152

On Wed, Feb 5, 2020 at 1:04 PM Alexander Akulich
 wrote:
>
> What I'm talking about is to repeat [1] for QAbstractSocket [2] as a
> last-minute change for Qt 5.15.
> If such a patch is not acceptable for 5.15, is it still acceptable for
> Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)?
>
> I'm going to prepare the patch right now, whether it 'll be accepted
> or not. (I hope and expect it to be a small change that is not sad to
> drop)
>
> [1] 
> https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5
> [2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1
>
> On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich
>  wrote:
> >
> > Hi all,
> >
> > does the 5.15 feature freeze mean that we can not adjust signal names
> > anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
> > will/should be compatible with Qt 6.
> >
> > IIRC there was an intention to rename
> > QAbstractSocket::error(SocketError) signal to errorOccured() to align
> > it with the other signals and to remove the overload of
> > QAbstractSocket::error() getter, so the API becomes a bit more
> > developer-friendly.
> > I thought that it was done, but it seems to be not the case. I can
> > prepare and submit a patch in a few hours if it is still applicable
> > for 5.15.
> >
> > On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen  wrote:
> > >
> > > Hi!
> > >
> > > For this one my reply is similar  :D
> > >
> > > Why this is so important that we should get the exception & go in after 
> > > FF? We need to delay the Alpha release because of this late addition if 
> > > we agree to take this in. It seems this shouldn't cause that big delay 
> > > but you never know... And taking this in between Alpha and beta doesn't 
> > > sound that well to me either; as written before all known features should 
> > > be in Alpha...
> > >
> > > br,
> > > Jani
> > >
> > >
> > > 
> > > From: Lars Knoll 
> > > Sent: Tuesday, February 4, 2020 8:41 PM
> > > To: Volker Hilsheimer
> > > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org
> > > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze 
> > > is  in effect now
> > >
> > > > On 4 Feb 2020, at 16:56, Volker Hilsheimer  
> > > > wrote:
> > > >
> > > >> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
> > > >> anymore. Please update Qt 5.15 new features page 
> > > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite 
> > > >> empty still...
> > > >>
> > > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if 
> > > >> we can get it out already during this week.
> > > >>
> > > >> API review for Qt 5.15 will start soon as well. Please do reviews 
> > > >> immediately when available.
> > > >>
> > > >> br,
> > > >> Jani Heikkinen
> > > >
> > > >
> > > > I’ve been struggling a bit more than expected with getting the 
> > > > implementation of "move a file or directory to the trash" pass CI. It’s 
> > > > a popular feature request:
> > > >
> > > > https://bugreports.qt.io/browse/QTBUG-47703
> > > >
> > > > The basic implementation and private APIs have been in for a bit, but 
> > > > required a bit of follow-up, which delayed the merging of the commit 
> > > > that adds the public API in:
> > > >
> > > > https://codereview.qt-project.org/c/qt/qtbase/+/287373
> > >
> > > +1 from my side. It doesn’t have dependencies on any other code, so it 
> > > can’t break anything else neither.
> > >
> > > 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] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

What I'm talking about is to repeat [1] for QAbstractSocket [2] as a
last-minute change for Qt 5.15.
If such a patch is not acceptable for 5.15, is it still acceptable for
Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)?

I'm going to prepare the patch right now, whether it 'll be accepted
or not. (I hope and expect it to be a small change that is not sad to
drop)

[1] 
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=4672e319e6dd0fbaa986e056e52dbb06d78fcfa5
[2] https://doc.qt.io/qt-5/qabstractsocket.html#error-1

On Wed, Feb 5, 2020 at 12:42 PM Alexander Akulich
 wrote:
>
> Hi all,
>
> does the 5.15 feature freeze mean that we can not adjust signal names
> anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
> will/should be compatible with Qt 6.
>
> IIRC there was an intention to rename
> QAbstractSocket::error(SocketError) signal to errorOccured() to align
> it with the other signals and to remove the overload of
> QAbstractSocket::error() getter, so the API becomes a bit more
> developer-friendly.
> I thought that it was done, but it seems to be not the case. I can
> prepare and submit a patch in a few hours if it is still applicable
> for 5.15.
>
> On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen  wrote:
> >
> > Hi!
> >
> > For this one my reply is similar  :D
> >
> > Why this is so important that we should get the exception & go in after FF? 
> > We need to delay the Alpha release because of this late addition if we 
> > agree to take this in. It seems this shouldn't cause that big delay but you 
> > never know... And taking this in between Alpha and beta doesn't sound that 
> > well to me either; as written before all known features should be in 
> > Alpha...
> >
> > br,
> > Jani
> >
> >
> > 
> > From: Lars Knoll 
> > Sent: Tuesday, February 4, 2020 8:41 PM
> > To: Volker Hilsheimer
> > Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org
> > Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is  
> > in effect now
> >
> > > On 4 Feb 2020, at 16:56, Volker Hilsheimer  
> > > wrote:
> > >
> > >> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
> > >>
> > >> Hi all,
> > >>
> > >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
> > >> anymore. Please update Qt 5.15 new features page 
> > >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite 
> > >> empty still...
> > >>
> > >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we 
> > >> can get it out already during this week.
> > >>
> > >> API review for Qt 5.15 will start soon as well. Please do reviews 
> > >> immediately when available.
> > >>
> > >> br,
> > >> Jani Heikkinen
> > >
> > >
> > > I’ve been struggling a bit more than expected with getting the 
> > > implementation of "move a file or directory to the trash" pass CI. It’s a 
> > > popular feature request:
> > >
> > > https://bugreports.qt.io/browse/QTBUG-47703
> > >
> > > The basic implementation and private APIs have been in for a bit, but 
> > > required a bit of follow-up, which delayed the merging of the commit that 
> > > adds the public API in:
> > >
> > > https://codereview.qt-project.org/c/qt/qtbase/+/287373
> >
> > +1 from my side. It doesn’t have dependencies on any other code, so it 
> > can’t break anything else neither.
> >
> > 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] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

[Alexander Akulich]

Hi all,

does the 5.15 feature freeze mean that we can not adjust signal names
anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
will/should be compatible with Qt 6.

IIRC there was an intention to rename
QAbstractSocket::error(SocketError) signal to errorOccured() to align
it with the other signals and to remove the overload of
QAbstractSocket::error() getter, so the API becomes a bit more
developer-friendly.
I thought that it was done, but it seems to be not the case. I can
prepare and submit a patch in a few hours if it is still applicable
for 5.15.

On Wed, Feb 5, 2020 at 8:43 AM Jani Heikkinen  wrote:
>
> Hi!
>
> For this one my reply is similar  :D
>
> Why this is so important that we should get the exception & go in after FF? 
> We need to delay the Alpha release because of this late addition if we agree 
> to take this in. It seems this shouldn't cause that big delay but you never 
> know... And taking this in between Alpha and beta doesn't sound that well to 
> me either; as written before all known features should be in Alpha...
>
> br,
> Jani
>
>
> 
> From: Lars Knoll 
> Sent: Tuesday, February 4, 2020 8:41 PM
> To: Volker Hilsheimer
> Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org
> Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is
>   in effect now
>
> > On 4 Feb 2020, at 16:56, Volker Hilsheimer  wrote:
> >
> >> On 3 Feb 2020, at 06:35, Jani Heikkinen  wrote:
> >>
> >> Hi all,
> >>
> >> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15' 
> >> anymore. Please update Qt 5.15 new features page 
> >> (https://wiki.qt.io/New_Features_in_Qt_5.15) now; it seems to be quite 
> >> empty still...
> >>
> >> Target is to publish Qt 5.15 Alpha as soon as possible; Let's see if we 
> >> can get it out already during this week.
> >>
> >> API review for Qt 5.15 will start soon as well. Please do reviews 
> >> immediately when available.
> >>
> >> br,
> >> Jani Heikkinen
> >
> >
> > I’ve been struggling a bit more than expected with getting the 
> > implementation of "move a file or directory to the trash" pass CI. It’s a 
> > popular feature request:
> >
> > https://bugreports.qt.io/browse/QTBUG-47703
> >
> > The basic implementation and private APIs have been in for a bit, but 
> > required a bit of follow-up, which delayed the merging of the commit that 
> > adds the public API in:
> >
> > https://codereview.qt-project.org/c/qt/qtbase/+/287373
>
> +1 from my side. It doesn’t have dependencies on any other code, so it can’t 
> break anything else neither.
>
> 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] Changes to Qt offering

[Alexander Akulich]

I would expect a significant negative effect on the quality of Qt
shipped in Linux distributions and thus negative effect on the
Qt-based applications and Qt reputation.

A maintainer can assume a bit more backporting, but let's have some
retrospective on the current LTS:
Compared to Qt 5.12.2, the new Qt 5.12.3 provides almost 200 bug fixes [1].
Compared to Qt 5.12.3, the new Qt 5.12.4 provides around 250 bug fixes [2].
This fifth patch release to Qt 5.12 LTS contains almost 280 bug fixes [3].
This sixth patch release for Qt 5.12 LTS series contains more than 50
bug fixes [4].

The number of commits is much more than the number of closed bug reports.
If the last open Qt 5 minor version will have three releases (5.15.0,
5.15.1, 5.15.2) then it is sensible to assume that the commercial Qt
branch will have at least 1000 commits on top of the public one. It is
barely possible for a single maintainer or a single community-driven
distribution to backport that many commits.

[1] https://www.qt.io/blog/2019/04/17/qt-5-12-3-released
[2] https://www.qt.io/blog/2019/06/17/qt-5-12-4-released-support-openssl-1-1-1
[3] https://www.qt.io/blog/qt-5.12.5-released
[4] https://www.qt.io/blog/qt-5.12.6-released

On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>
> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in the 
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS part of a 
> release is in the future going to be restricted to commercial customers. All 
> bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
> Backporting bug fixes is something that the Qt Company will take care of for 
> these LTS branches. We’ve seen over the past that LTS support is something 
> mainly required by large companies, and should hopefully help us get some 
> more commercial support for developing Qt further.
>
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer a lower 
> priced product for small businesses. That small business product is btw not 
> limited to mobile like the one Digia had some years ago, but covers all of Qt 
> for Device Creation.
>
> None of these changes should affect how Qt is being developed. There won’t be 
> any changes to Open Governance or the open development model.
>
> Best regards,
> 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] Changes to Qt offering

[Alexander Akulich]

Your decision is not a reason to contribute more. It is going to hurt
the ecosystem because it makes it harder to get new developers and
users.

In some of my previous companies, we had a long release cycle so as a
Linux developer I could justify my paid time spent on upstreaming a
fix to get it included into the binary offline installers for all
platforms in about a month. The new policy cross-off this reason to
submit fixes.

You already made life harder by licensing Qt under GPL v3. Of course,
it has pros and cons, but let's jump to the consequence: we have
Sailfish OS out of the boat. The OS could have a modern Qt and we
actually could have people working on the upstream QtDeclarative, Qt
Quick Controls 2 and other modules in the paid time, but. The OS
developers have complex agreements with a number of important business
partners and for some of them, it is unacceptable to follow some of
the tivoization-related GPL v3 clauses. It is hard to explain to
managers the profit from a new version or collaboration with the Qt
community. (From a business PoV) it makes very little sense to pay for
some abstract "technical prettiness" as long as Qt 5.6 gives you the
money.

On the professional side, I suddenly understand how much I'm depending
on Qt. I spent my paid and spare time to make the world and the Qt
world better, but now I'm sad and disappointed. The world is changing
so fast. Years ago I taught students to the light side with C++, Qt,
and open source. I can't imagine asking dozens of students to register
and get Qt Account. Nowadays and with this step, I see even fewer
reasons to learn C++ and Qt.

I respect and appreciate the work of all Qt developers. Thank you all
for the amazing technology. Long live Qt! I hope we won't have to
fork.

On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>
> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in the 
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS part of a 
> release is in the future going to be restricted to commercial customers. All 
> bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
> Backporting bug fixes is something that the Qt Company will take care of for 
> these LTS branches. We’ve seen over the past that LTS support is something 
> mainly required by large companies, and should hopefully help us get some 
> more commercial support for developing Qt further.
>
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer a lower 
> priced product for small businesses. That small business product is btw not 
> limited to mobile like the one Digia had some years ago, but covers all of Qt 
> for Device Creation.
>
> None of these changes should affect how Qt is being developed. There won’t be 
> any changes to Open Governance or the open development model.
>
> Best regards,
> 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] Go's "defer" statement for C++/Qt

[Alexander Akulich]

Hi Volker,

I have no idea about Go, but deferred signal emission is somewhat
useful in async programming (at least in my practice). In that case,
there is a need to 'defer' execution to continue after the control is
returned (usually in EventLoop via QMetaObject::invokeMethod(...,
Qt::QueuedConnection). A cleaner approach would be appreciated.

On Thu, Mar 7, 2019 at 8:02 PM Volker Hilsheimer
 wrote:
>
> Ahoy,
>
> In what little development I’ve done in golang, I appreciated the “defer” 
> statement as a means to write cleaner code. Basically, defer schedules a 
> statement for execution when the stack unwinds.
>
> https://tour.golang.org/flowcontrol/12
>
> We have several specialized helper classes in Qt for similar purposes, f.ex 
> QMutexLocker and friends, or the internal QBoolBlocker [1]. Seeing the 
> various specialized classes we have, I thought that something generic in Qt 
> could be useful to have (although our specialised classes provide some 
> additional convenience and/or logic).
>
> So, I pushed a few lines code to
>
> https://git.qt.io/vohilshe/qt_defer
>
> Would like to hear what you think.
>
> Perhaps someone can find ways to make this more elegant without introducing 
> tons of preprocessor/macro shenanigans, or perhaps even without depending on 
> C++17's implicit template argument deduction (without enabling C++17 in the 
> config this doesn't build for me, even though I don’t use auto in the 
> template paramter list).
>
>
> Cheers,
> Volker
>
>
> [1] which was requested to be made public in 
> https://bugreports.qt.io/browse/QTBUG-38575
>
>
> ___
> 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

[Alexander Akulich]

Cristian,

the previous discussion is "Why can't QString use UTF-8 internally?"
There is something wrong with our maillist, the best link I found is
[1]. For some reason link to the thread head [2] is broken.

[1] https://lists.qt-project.org/pipermail/development/2015-February/040199.html
[2] https://lists.qt-project.org/pipermail/development/2015-February/020155.html

On Tue, Jan 15, 2019 at 9:48 PM Cristian Adam  wrote:
>
> Hi,
>
> With every Qt release we see how the new release improved over previous 
> releases in terms of speed, memory consumption, etc.
>
> Any chance of having UTF-8 storage support for QString?
>
> UTF-8 is native on Linux and other *NIX platforms, Qt programs should use 
> less memory, and perform better by reading less bytes from memory.
>
> Did anybody try this?
>
> I've heard that Qt Creator is storing sources files both in UTF-8 format for 
> libclang, and UTF16 for its internal usage. That sounds like a bit wasteful.
>
> KDE Plasma could then better compare / compete with the other Linux desktop 
> environments which use UTF-8 for strings.
>
> I guess I could use CopperSpice to test this, since they added CsString with 
> both QString8 (UTF-8) and QString16 (UTF-16) supported.
>
> https://utf8everywhere.org/ states "UTF-16 is the worst of both worlds, being 
> both variable length and too wide"
>
> Cheers,
> Cristian.
> ___
> 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] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style

[Alexander Akulich]

Hi all,

I highly doubt that it can be done as a part of GSoC and I don't see
any point in moving this to QtProject as we don't have Sailfish OS
platform upstreamed. We just need this style to make QQC2 applications
look native on Sailfish OS. I think that we'll have to rely on
closed-yet components and the style is not going to look nice with
mocks.

That said, I see a number of issues and I hope that we'll discuss and
agree on some changes to the QQC2 API:
1) I would like to propose ComboDelegate — a pair of ComboBox and
Label, combined in a platform-specific way (similar to CheckDelegate
and RadioDelegate).
2) We also need a delegate to display a label and an associated value.
It is named "DetailItem" in Silica, but I would agree to go with a
name like ValueDelegate.
3) Yet another point is that we need to properly style delegate
descriptions, so I want to propose "description" property at least for
Combo, Radio and Switch delegates (we even don't have a 'buddy'
property here, though it still would be very hacky to go in this way).

Probably it makes sense to start another thread to discuss Qt Quick
Controls 2 API, but I need at least three weeks to think and
experiment with what we have right now. :-)

My work is available at
https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt
5.9 and 5.10), but I don't think that it can be interesting for anyone
in its current shape.

On Fri, Apr 6, 2018 at 4:11 PM, Alexey Andreyev
<yetanotherandre...@gmail.com> wrote:
> Got it, thank you, Mitch! :)
>
> Yes, I have contacted Jolla devs, got answer:
>
>>  Providing Sailfish support for Qt Quick Controls 2 would definitely be
>> valuable. Sailfish OS cannot build app ecosystem alone, and improving the
>> cross-platform story would help us getting Qt app contributions from other
>> platforms, and help 3rd party developers target multiple platforms like
>> Android and iOS with the same code base.
>
>> You are free to use what license you choose, but I would recommend
>> something permissive like BSD3 or LGPL2, which we also use in Sailfish OS
>> open source side
>
> Silica Componets source is not public, yes :( But I've got device where I
> have all up-to-date qml files and I'm it as hint.
>
> I've also played to run armv7h binaries from device repos (rpm packages) on
> archlinuxarm (wrote PKGBUILDs) with all the deps and some hacky qt5 linkage
> address patching for .so lib, it staring and not crashing but asking for
> more deps yet (like image resources deps, so work in progress)
>
> Alexander Akulich (Kaffeine) from Open Mobile Platform is helping me a lot
> too, he recently created:
>
> https://git.merproject.org/Kaffeine/qtsilicastyle
>
> So I'm going to contribute there.
>
> For now current state is:
>
> 5.10 private API chaged compating to 5.9:
> https://github.com/qt/qtquickcontrols2/commit/b18b6375d170ce02dc5a627bfb69ca49046ee05c#diff-7467cf01ad998520d6d9d2995867e8e2
>
> Alexander is testing with 5.9 LTS on SailfishOS
> and me with archlinuxarm 5.10
> so I'm thinking now how to provide better compabilty for both :)
>
> looks like #ifdef approarch is not helping yet, should investigate more time
>
>
> 2018-04-06 15:47 GMT+03:00 Mitch Curtis <mitch.cur...@qt.io>:
>>
>> Hi.
>>
>>
>>
>> We think this would be best in a repo outside of qtquickcontrols2.git.
>>
>>
>>
>> The process for creating a playground repo is documented here:
>>
>>
>>
>>
>> http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground.
>>
>>
>>
>> Have you discussed this project with the Sailfish devs, by the way?
>> Perhaps they would be interested in integrating your efforts upstream.
>>
>>
>>
>> One potential problem I see is that it seems that the source code is not
>> public:
>>
>>
>>
>>
>> https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/
>>
>>
>>
>> The closest thing is this repo, which doesn’t seem to be complete:
>>
>>
>>
>> https://github.com/dm8tbr/sailfishsilica-qt5
>>
>>
>>
>> How do you plan on implementing the style in light of this?
>>
>>
>>
>> Speaking for myself: I would be happy to answer any questions you may have
>> with regards to implementing a Controls 2 style, but I don’t think I can put
>> aside enough time to be a mentor for this.
>>
>>
>>
>> Cheers.
>>
>>
>>
>> From: Alexey Andreyev [mailto:yetanotherandre...@gmail.com]
>> Sent: Tuesday, 3 April 2018 2:14 PM
>> To: Aleksey Kontsevich <

Re: [Development] qDebug()

[Alexander Akulich]

Hello Igor,

Does the linked solution help? See also comment #2 at
https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1731646
(referenced in the stackoverflow answer).

(The subject question belongs to interest@, not development@. Please drop
development@qt-project.org in further replies).

On Mon, Mar 26, 2018 at 7:36 AM, Igor Mironchik 
wrote:

> Hi,
>
> On 26.03.2018 07:33, Timur Pocheptsov wrote:
>
> On which platform is it? Are you sure it's 5.11 only?
>
>
> I'm on Kubuntu 16.04. It is on 5.10 and 5.11 build from sources by myself.
>
>
> See, for example, the solution proposed here:
>
>
> https://stackoverflow.com/questions/48474897/qt-qdebug-
> stopped-to-work-no-more-printing-to-console-after-upgrading-to-ubu
>
> 
> QT qDebug() stopped to work (no more printing to console ...
> 
> stackoverflow.com
> After upgrading from Ubuntu 17.04 to 17.10, the QT qDebug() macro stopped
> working and no longer displays the messages on the console. How can the
> debug output be re ...
> Best regards,
>
> Timur.
> --
> *From:* Development  pocheptsov=qt...@qt-project.org>
>  on behalf of
> Igor Mironchik  
> *Sent:* Monday, March 26, 2018 6:07:25 AM
> *To:* development@qt-project.org
> *Subject:* [Development] qDebug()
>
> Hello,
>
> Built sources from git repository (5.11 branch) doesn't print qDebug()
> messages to console. What I missed during the configuration process?
>
> Thank you.
>
> ___
> 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