Re: [Development] New Qt Multimedia

[Jason H]

> On 26/05/21 15:09, Lars Knoll wrote:
> > The hope is that we can change that for Qt 6. To make this possible, we 
> > have changed not only parts of the public API, but completely redone its 
> > internal architecture, especially how multimedia connects to the platform 
> > specific backends. Apart from cleaning up the backend API and greatly 
> > simplifying it, I also chose to make it private and remove the plugin 
> > architecture around it. The backend is now selected at compile time, and 
> > we’re now only supporting one backend per platform.
> 
> can you please clarify what this would mean for projects (like Ubuntu
> Touch) which are using their own QtMultimedia plugins?
> Supporting one plugin per platform seems reasonable, but making the
> plugin API private and selecting the plugin at compile time probably
> means that all multimedia backends must be made part of QtMultimedia git
> repository, right?


Good question. How would the RaspberryPi Camera work? Currently, I am using 
https://github.com/brianjaustin/qt-raspicam which is an open but somewhat 
proprietary stack.

There seems to be some work (May 2020) to get the PiCamera working with 
libcamera, however this is not a simple change:
https://github.com/raspberrypi/documentation/tree/master/linux/software/libcamera
Which requires modifying config.txt and rebooting, making the original Pi 
Camera stack not work. Also, I don't think the Pis come with this new camera 
stack, you've got to set it up yourself on every pi. 

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

Re: [Development] New Qt Multimedia

[Jason H]

> > If it matters: I disclaim any copyright for the attached 
> > files.
>
> Thanks for the snippet. I think this should be perfectly doable. Connect to 
> the signal, then map the QVideoFrame and copy out the Y channel.


One ask that may not be captured anywhere: currently, it is impossible to have 
a QML Camera and not start it.

If I could request,
1. a way to probe hardware without activating it
2. a way to have a QML Camera without getting frames from it, that is to set 
`active: false` is the default. Currently, there is not even active property. 
We have to do a Component.onCompleted: stop() which has already triggered the 
permission dialog. This was ok in the past, but the trend and proper usage is 
to request permission only when it is needed.



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

Re: [Development] New Qt Multimedia

[Jason H]

> > 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?
> 
> You can get full access to the video data from a QVideoSink through the 
> newVideoFrame() signal and mapping the video frame (or converting it to a 
> QImage). With that you should have the access to the data that you need. (A 
> small detail that’s still missing right now but that I hope to have in place 
> for 6.2 is the ability to connect several sinks to a media player or capture 
> session, but it’s not really required as you can connect several slots to the 
> signal). If you feel like to need more than that, let me know what it is.

So the most common case I need supported is getting the video frame for 
processing while maintaining the full-speed live preview. Is this the 
multi-sink scenario?
Typically, With Camera connected o a VideoOutput, I use QVideoProbe to throw 
the frame (pixel data as QByteArray, because the library doesn't care) to a 
thread for multicore async processing. A typical 1 megapixel image on 
RaspberryPi4 takes ~150ms using ZBar or ZXing (I find ZXing is more like 
100ms), so this gets about 6 processed frames a second, which seems responsive 
enough to the user because they are looking at the live display.

Since you asked for actual code, attached is the code I use to do this. It may 
not be perfect code (long story made short, I just rewrote this from memory) 
but it is what I whipped up, and works reasonably well for now.  I've used this 
approach for barcodes and OpenCV.

If it matters: I disclaim any copyright for the attached files.

barcodevideoprobe.cpp
Description: Binary data
#ifndef BARCODEVIDEOPROBE_H
#define BARCODEVIDEOPROBE_H

#include 
#include 
#include 

#ifndef Q_OS_WASM
#include 
#include "zbar.h"
#include 
#include 

#endif



class BarcodeVideoProbe : public QObject
{
Q_OBJECT

Q_PROPERTY(QObject* qmlCamera READ qmlCamera WRITE setQmlCamera NOTIFY 
qmlCameraChanged)
Q_PROPERTY(QString barcodeFormat READ barcodeFormat WRITE 
setBarcodeFormat NOTIFY barcodeFormatChanged)
Q_PROPERTY(QString barcode READ barcode WRITE setBarcode NOTIFY 
barcodeChanged)
Q_PROPERTY(bool workerProcessing READ workerProcessing WRITE 
setWorkerProcessing NOTIFY workerProcessingChanged)
Q_PROPERTY(bool active READ active WRITE setActive NOTIFY activeChanged)

QThread m_workerThread;

QObject *m_qmlCamera = nullptr;
bool m_workerProcessing = false;
bool m_active = true;

QString m_barcode, m_barcodeFormat;

#ifndef Q_OS_WASM
QCamera *m_camera = nullptr;
QVideoProbe m_probe;

QByteArray extractYChannel(const QVideoFrame );
#endif

QML_ELEMENT
public:
explicit BarcodeVideoProbe(QObject * parent=nullptr);
~BarcodeVideoProbe();

QString barcode() const;
QString barcodeFormat() const;
bool workerProcessing() const;

bool active() const;

signals:
void process(const QByteArray , const QSize& size);
void barcodeFound(QString barcode, QString format);

void barcodeChanged(QString barcode);
void barcodeFormatChanged(QString barcodeFormat);
void workerProcessingChanged(bool workerProcessing);
void qmlCameraChanged();

void activeChanged(bool active);

public slots:
QObject* qmlCamera() const;
void setQmlCamera(QObject*qmlCamera);
#ifndef Q_OS_WASM
void processFrame(QVideoFrame);
#endif
void setBarcode(QString barcode);
void setBarcodeFormat(QString barcodeFormat);
void setWorkerProcessing(bool workerProcessing);

// handle worker signals
void handleBarcode(QString barcode, QString format);
void handleProcessingComplete();

void setActive(bool active);
};

class BarcodeDecodeWorker : public QObject
{
Q_OBJECT
#ifndef Q_OS_WASM
zbar::ImageScanner scanner;
#endif

public slots:
void process(const QByteArray , const QSize& size);

signals:
void barcode(const QString , const QString ); // this may 
be emitted multiple times
void processingComplete();
};
#endif // BARCODEVIDEOPROBE_H
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New Qt Multimedia

[Jason H]

> There are still open issues and gaps in the implementation that need fixing, 
> but the code is now in a decent enough shape to merge it back to dev and 
> continue on that branch. We will however now have everything ready in Qt 
> Multimedia for the 6.2 feature freeze, and will be working with an exception 
> on this module. Especially the support for camera and media capture on 
> Windows and the Android backend still need more work. The gstreamer backend 
> for Linux and AVFoundation for iOS and macOS should be in a pretty decent 
> shape. QNX support is missing right now, and is planned after 6.2.

So the changes listed in the bullet points look great!

As someone who has attempted to work with Qt Multimedia on the mobile 
platforms, I can say that I was looking forward to this.

I do have a few questions (mobile focused):

1. On Android, it looks like you're using the old Camera API and not Camera2? 
(https://developer.android.com/reference/android/hardware/camera2/package-summary)
 I found that Camera2 paralleled AVFoundation, so between Camera being 
deprecated and Camera2 resembling AV Foundation, I am surprised Camera (old) 
was targeted?

2. Recording WAV on Android was a problem.  I get that this was not Qt's fault, 
but having universal WAV recording would be good. Is it in scope? (Solution was 
to just do it in Java, grabbing raw PCM data), but iOS could deliver WAV if you 
told it to in the container format.

3. Support for image/video depth data? On iOS, these are mini-images embedded 
within the image itself. Is it in scope? (Can be from disparity or LIDAR, IR, 
etc)

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?



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

Re: [Development] Avoiding ads and/or Google for doc searches

[Jason H]

My applogies for that. I do remember a time when the ads weren't there. So that's what contributed to my error.

 

And a sincere thank you!

 

 




Sent: Tuesday, May 25, 2021 at 11:11 AM
From: "Riitta-Leena Miettinen" 
To: "development@qt-project.org" , "Jason H" 
Subject: Re: Avoiding ads and/or Google for doc searches




 

Date: Fri, 21 May 2021 17:22:13 +0200
From: Jason H 
To: Sze Howe Koh 
Cc: Qt development mailing list 
Subject: Re: [Development] Avoiding ads and/or Google for doc searches
    (was: Changes to Freenode's IRC)

>And yes, I broke my own rule to not attribute to malice/greed what can be explained by stupidity/laziness.

 

Hello Jason,

 

Might I suggest an even better rule? Do not attribute any characteristics to people whose motivations, skills, and working conditions you know absolutely nothing about.

 

You offhandedly managed to call all Qt Documentation Engineers stupid/lazy, when we in fact hated the adds and worked quite hard for a long time to have them turned off. That finally succeeded, and if you search for something now, you should not see any adds.

 

You are welcome,

 

Leena

---


	
		
			
			

	
		 
	
	
		 
	
	
		 
	

			
			
		
		
			
			Leena Miettinen
			
		
		
			
			Sr. Documentation Engineer
			
		
		
			
			

	
		 
	
	
		 
	

			
			
		
		
			
			The Qt Company
			Erich-Thilo-Str. 10 12489
			Berlin, Germany
			
		
		
			
			riitta-leena.mietti...@qt.io
			
		
		
			
			www.qt.io
			
		
		
			
			

	
		 
	
	
		 
	

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

	
		 
	
	
		 
	
	
		 
	

			
			
		
		
			
			
			
		
		
			
			

	
		
		
		
		
		
		
		
		
		
		
		
		
	

			
			
		
	


 





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

Re: [Development] Renamed (again): Qt licensing shenanigans (again)

[Jason H]

>
> I agree with Jason: Doing the "no LTS for FOSS" at the moment of the
> 5.15->6.0 change was really a foul play, imho.

I'm currently attributing it to a license decision that for any
other release (say if there was a 5.16) would be fine, but in reality
was temporally coupled to the release of 6.0, and what 6.0 composed, which
was an unusual and separate decision. And these decisions could have been
made separately by different people and not realize the implications
of the two combined until it was pointed out.

It's a mistake that can be easily rectified. But what happens next is
going to show the true character of the Qt Corporation. If the decision
was made intentionally, or even so but isn't rectified, then that's
going to affect those open source users who don't legally need a license,
don't want or need Qt 6, but just need access to patches to keep
users happy. I can't really see that as s motivation for a commercial
license money grab, because in theory, by 6.2 things will be back to
normal. Starving open source license users of patch level changes to get
them to  convert to commercial for what, a year? Doesn't make sense so
me, so I'm not attributing it to malice.

What I'd like to see is:
- Open Source LTS patches restored until 6.x is at parity.
- An agreement that never again will Qt have a Major version release
  that isn't in parity with the previous feature release (meaning dropped
  feature have to be dropped Before the major release for at least one version)

Ultimately I think this was a learning experience.






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

Re: [Development] Renamed: Running a service for Qt community

[Jason H]

> Sent: Friday, May 21, 2021 at 8:57 AM
> From: "Kai Köhne" 
> To: "Benjamin TERRIER" , "development@qt-project.org" 
> 
> Subject: Re: [Development] Renamed: Running a service for Qt community
>
> > From: Development  On Behalf Of 
> > Benjamin TERRIER
> > Subject: Re: [Development] Renamed: Running a service for Qt community
> > 
> > On Thu, 20 May 2021 at 17:18, Jason H <mailto:jh...@gmx.com> wrote:
> >
> >> Anyway, these issues aren't insurmountable, apparently they can be changed 
> >> with the stroke of a pen. (Where is Qt's Open Governance? - still think I 
> >> misunderstood what that was about)
> >
> > Since TQC alone can decide that the Qt Project won't release Qt 5.15.3+  
> > without consulting the mailing list and going through the lazy consensus 
> > decision process, I think it's safe to say that Open Governance is dead.
> 
> I don't claim that the LTS decision was fully in line with the Open 
> Governance process as stated in 
> https://quips-qt-io.herokuapp.com/quip-0002.html .
>
> But Open Governance is IMO serving the purpose of steering the development of 
> the Qt code quite well. I think we can do better in also discussing designs 
> etc on the mailing list, but well...

It seems to be a fatal flaw that the licensing, and the changes to, are not 
part of the open governance. It looks like there is only the ability to change 
and vote on code... What if that code commit is a license file ;-) ?
  
> > Can we conclude that contributions from outside the company are going to be 
> > nearly
> > non-existent?

I'd be more likely to contribute code if I was able to contribute it as LGPL it 
was available to users as LGPL.
 
> I hope not  You can check out some statistics about code contributions at 
> qt-project.org . There's also Thiago's generated statistics : 
> https://macieira.org/~thiago/qt-stats/current/ 

Measuring the reaction to decisions like this change of license decision in 
terms of lines of code is surely a lagging indicator. And people may not be 
aware until they try to use the online installer to update, which they probably 
aren't. Or visit the blogs. I've been going over the history, the commercial 
release of 5.15 was announced in advance but was worded in a way as to not 
mention that there wouldn't also be an open source release.  ( 
https://www.qt.io/blog/qt-offering-changes-2020 )

"LTS and offline installer to become commercial-only
Starting with Qt 5.15, long term support (LTS) will only be available to 
commercial customers. This means open-source users will receive patch-level 
releases of 5.15 until the next minor release will become available. This means 
that we will handle Qt 5.15 in the same way as e.g. 5.13 or 5.14 for open 
source users"

It is my understanding after reading that, that open source users would still 
get patch-level releases (5.15.x) through the online installer. What actually 
happed though is as soon as Qt6.0.1 was released, the access to 5.15 patch 
releases were over. Access to the patch release vs support are different things 
though. As I read it, the /support of 5.15/ would end for open source users, 
who would only be supported on Qt6.0.1 at that time.  However this is not what 
happened, as access to 5.15 patches were cut off. This is a broken idea because 
not all the modules included at 5.15 were supported by 6.0. 6.0 is actually 
incomplete. 6.1 is also incomplete. This is hostile and unfair to open source 
user to deny them patches that already exist because of separate 
engineering/release decisions (which I also take issue with) to release an 
incomplete 6.0.  What needs to happen is Qt 5.15 needs to go back to open 
source patch releases until 6.x is at feature parity with 5.15. 

It's the right thing to do. 






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

Re: [Development] Changes to Freenode's IRC

[Jason H]

> >> I would like to get back to doing more of our development discussions out 
> >> in the open
> >> (like it should be), but right now IRC is not something I want to go back 
> >> to for
> >> that.
> >
> > I also think that having development related discussions in internal Teams 
> > channels
> > is counterproductive not only for the parts of the community that cannot 
> > participate.
>
> I claim that having relevant development discussions in any chat is
> wrong. If these discussions are significantly more than a quick
> brainstorming, they belong onto the mailing list or into Gerrit,
> depending on their maturity. These services also meet the demands of
> getting history and looking at an archive.

I appreciate that the IRC meetings about releases are published.


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

Re: [Development] Avoiding ads and/or Google for doc searches (was: Changes to Freenode's IRC)

[Jason H]

On Thu, 20 May 2021 at 01:40, Kai Köhne 
mailto:kai.koe...@qt.io]> wrote:
>
> > -Original Message-
> > From: Development 
> > mailto:development-boun...@qt-project.org]>
> >  On Behalf Of Jason H
> > Sent: Wednesday, 19 May 2021 17:26
> > To: giuseppe.dang...@kdab.com[mailto:giuseppe.dang...@kdab.com]
> > Cc: development@qt-project.org[mailto:development@qt-project.org]
> > Subject: Re: [Development] Changes to Freenode's IRC
> >
> > * Before you laugh, and say that is crazy, consider that the online Qt Docs 
> > search results now have ads: 
> > https://doc.qt.io/qt-5/search-results.html?q=camera[https://doc.qt.io/qt-5/search-results.html?q=camera]
> >  shows 4 ads for me.  And I don't know of any other toolkit who serves 
> > their documentation with ads. Take for example mozdev:
> > https://developer.mozilla.org/en-US/search?q=camera[https://developer.mozilla.org/en-US/search?q=camera]
> >  shows 0 ads. React, 0 ads. I figure it's only a matter of time until the 
> > actual documentation pages have ads too. (There may be good reasons for 
> > ads, but it's still not a good look.)
>
> It's true that the embedded search on doc.qt.io[http://doc.qt.io] sometimes 
> shows ads. But it's not the result of evil TQtC making heaps of money with 
> ads. It's just a side-effect of using google for embedded search, and has 
> been like that since years (if not decades)  ... We have actually recently 
> started to look into it (again), see 
> https://bugreports.qt.io/browse/QTWEBSITE-723[https://bugreports.qt.io/browse/QTWEBSITE-723]
>  if you want to get updates.

The browser extension is cool, thank you.

And yes, I broke my own rule to not attribute to malice/greed what can be 
explained by stupidity/laziness. I hadn't planned to mention it but given the 
nature of the Freenode split over user data privacy, I figured that the eyesore 
concern was secondary to the ad tracking/privacy concerns, and that may be of 
interest to those interested in switching from Freenode.


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

Re: [Development] Renamed: Running a service for Qt community

[Jason H]

> So, how many people and entities do we have in the Qt community that have the 
> capacity, competence, and credentials to run a service? I personally would 
> very much like to see certain aspects of the community at large to be less 
> entangled with The Qt Company. The qt-project.org page is a good start. But 
> that requires that someone actually steps up and says “I’ll do it”. Funding 
> can always be discussed.
> 
> So Jason, how about it? :P

In the past, I'd be all for it. My current thinking about the situation is it 
would help a for-profit company, who as of late, has been hostile to open 
source users, and that this would be free labor for them to bolster their 
ecosystem. Back when Qt was released by Nokia, I would have totally done it. 
I'd still be willing to do it, but Digia would have to formally freeze and/or 
revert some of their practices. But as I see it, Digia is going out of their 
way to destroy/limit/hinder the OpenSource users of Qt. I'd be doing it for the 
open source users, which I think are in decline, turned away from the increased 
friction across the board, from the installer itself, to not providing LTS 
releases to open source users.  (I am not in any way critical of them using 
OpenSource to create commercial customers - that's how it has always worked - 
but the denying open source users bug fixes is actively hostile and not for any 
legitimate open vs commercial license issue, as I see it anyway.)

Again, I still think Qt is great tech. I just think Digia'a actions of late 
will lead to the collapse of open source Qt usage, so why maintain a service 
that no one will use? One that gives the facade of openness? That may be a seem 
hyperbolic, but I need to know Digia will continue to respect opensource users, 
which lately, they have not done. And I say this as a dual-license user. I use 
Qt OpenSource for my hobbies, but I also have a commercial license. (I've had 
several) I have no problem with Qt cmaking money, and I want the developers to 
have jobs, benefits, and families. I find the commercial license costs 
reasonable and their support worth it. But it just seems that a lot of the 
actions being taken are to harm OpenSource users into getting commercial 
licenses, and that's not cool with me. 

I am open to being mistaken, and to be be convinced otherwise. But I know I am 
not alone in feeling this way. 

As a long-term Qt user I have to say I'm not liking the direction.
I was a commercial customer for TrollTech
I was there when Harmony was started, then abandoned. 
I was there for Arthur.
I was there when Qt got invaded by Aliens
I was there for the Nokia N9, which I bought _because_ of Qt
I was there when QML was created (which is awesome). 
I was there when Nokia open sourced Qt. 
I was there when Digia bought Qt.
I was there when Qt was extended to mobile platforms (which was great) 
(including the ill-fated Windows phone) 
I was there when Digia renamed themselves to the Qt Company*. 
I was there when tQtCo* "locked things down".
Will I be there for the next milestone**? I really don't know.

If my answer to that had been yes, I would have said yes to running a service 
(I'd need help with the infrastructure costs unless it also works on my amazon 
free tier.)

Anyway, these issues aren't insurmountable, apparently they can be changed with 
the stroke of a pen. (Where is Qt's Open Governance? - still think I 
misunderstood what that was about) 

*if you wonder why I keep calling them Digia and not the Qt Company, it is 
because the actions of late don't really feel like Qt of old (Nokia, TrollTech) 
would have treated opens source users that way. Looking at the management: 
https://investors.qt.io/governance/management/ only 2 came from Nokia, the rest 
are from Digia or have been hired since. To me, this explains the change of 
behavior by Qt's controlling entity.

**What would the next milestone be? Not Qt6. It's just a version. I'd like to 
see Qt take on the web, the pieces are there, with WebAssembly and QHttpServer. 
The web meanwhile has gotten more Qt-like with webpack and other 
compilation-step tools. I think this would really embiggen the Qt community, 
but the release practices would have to be brought inline with like, say 
Node's: 
https://nodesource.com/blog/understanding-how-node-js-release-lines-work/ which 
means no commercial-only LTS releases, or releasing an incomplete major version.

But I've said about all I can about this. If Digia doesn't want to play nicely 
with the open source community, then I have to accept that, adjust my 
perceptions, and decide where to go from here. Personally, I hope they reverse 
course and release the remainder of 5.15 as open source. There was no 
transparency for this decision, so I am hoping it is just a matter of them 
deciding to do that. (What was that process, the reasoning, was there any 
community involvement? Where can I find this out?)








___

Re: [Development] Changes to Freenode's IRC

[Jason H]

For mode detail about the situation, I consulted:
https://www.vice.com/en/article/m7ev8y/freenode-open-source-korea-crown-prince-takeover
https://www.kline.sh/

In the past my use of IRC was limited by firewalls. If at all possible,
whatever is moved to, I would request be web-accessable (https).
Freenode has the web-chat client, which when I  was limited by firewalls,
was really appreciated. (Wifi guest networks are bad about this in
particular)

> Lacking some formal voting infrastructure, how do we take this vote?
> I'd say, KISS: please reply to this email and express your preference.

So I thought there was some kind of voting infrastructure (VI) already?
I thought this is what Open Governance would hinge on. I was under the
impression that there would be some kind of VI, and that would be used
to shape the direction of Qt. Anyhow, my mistakes aside, I thought Gerrit
was the tool, where our accounts could vote on a patch set (ballot) that
would record the vote. Also it would help to formally specify what the
ballot questions are.

- Ballot -- vvv

* Is the Qt community OK at staying on Freenode? (Currently it has an
*official* presence! Although noone seems to know better, esp. who is
the primary contact for this presence. Looking at the channels
registrations, the founders are Thiago, ossi, tronical, JP-Nurmi, but
that doesn't necessarily match who is the point of contact.)

Vote: Is is not Ok.

* If no: does it wish to move to another IRC network -- to where?

Vote: Libera or KDE. It is too soon to decide because Libera.chat is down.
If KDE is willing to take the burden, I would be ok with that.

* If no: does it want to drop its official IRC presence? Implication:
the #qt* channels namespace will be released, and so up for grabs by the
first person passing by and registering channels in there.

Vote: Keep the channels, just to forward to the new resource. ("Qt has 
moved...")

- Ballot -- ^^^


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

Re: [Development] Changes to Freenode's IRC

[Jason H]

> Can we agree to keep the bashing out of this channel?

You raise important questions. First, what is "bashing", and where is it 
appropriate? Or, as I see my behavior, where is being critical of Digia 
appropriate?

As a long-time Qt user (first commercial license was for 3.3.3) I've seen it go 
through many phases. Nokia LGPL Qt was so great, but I've watched erosion of 
that openness. I formulate my opinions based on ecosystems that I participate 
in, like Arduino, React, Node, etc. I see IMHO criticism of Digia is on the 
rise (https://www.qt.io/blog/commercial-lts-qt-5.15.3-released). I also get a 
lot of emails privately in agreement with my criticisms. So where is the proper 
feedback channel?

I think the situation is exacerbated because of the confluence of two decisions 
on how the Qt 5.15/Qt 6 transition:
1. Qt 6 does not contain all the modules Qt 5.15 did.
2. Qt 5.15 was a LTS, but the releases after 5.15.2 are commercial only.

If Qt 6 had contained all the modules that 5.15 did, OpenSource users would be 
able to switch to 6.
From https://doc.qt.io/qt-6/whatsnew60.html#removed-modules-in-qt-6-0 the 
following modules are not in Qt6:
Qt Android Extras   androidextras
Qt Bluetoothbluetooth
Qt Charts   charts
Qt Data Visualization   datavisualization
Qt Graphical Effectsonly QML types
Qt Location location
Qt Mac Extras   macextras
Qt Multimedia   multimedia
Qt Multimedia Widgets   multimediawidgets
Qt NFC  nfc
Qt Positioning  positioning
Qt Purchasing   purchasing
Qt Remote Objects   remoteobjects
Qt Script   qtscript
Qt SCXMLscxml
Qt Script Tools scripttools
Qt Sensors  sensors
Qt Serial Bus   serialbus
Qt Serial Port  serialport
Qt Speech   texttospeech
Qt WebChannel   webchannel
Qt WebEnginewebenginecore
Qt WebSockets   websockets
Qt WebView  webview
Qt Windows Extras   winextras
Qt X11 Extras   x11extras
Qt XML Patterns xmlpatterns

Qt 6.1 then adds back (though some modules got rolled into other modules):
Qt Charts
Qt DataVis
Qt Lottie
Qt SCXML and StateMachine
Qt VirtualKeyboard

This leaves open source users of the Qt6 missing modules in a bind. I decline 
to attribute this to malice, but one way to fix the situation is to provide the 
5.15 non-commercial updates until Qt6 is complete (6.2? allegedly includes 
Serial and WebSockets, but plenty aren't yet included, also: 
https://lists.qt-project.org/pipermail/development/2020-November/040704.html) 
and then just have Qt 6 LTS as commercial only.  I had also thought that the 
5.15 LTS was only going to be limited by commerical-only offline packages, that 
online 5.15 LTS would still be fine.

I would even be fine with there being only one LTS as opposed to how it is done 
now with multiple overlapping LTSs. (Currently 5.12 and 5.15 are LTS)

I don't know how to square Digia's behavior with Qt's Open Governance model 
(https://wiki.qt.io/Qt_Project_Open_Governance) ? I'm trying to where in the 
open source/governance stuff it was decided that making LTS commercial only was 
1) approved by the Open Governance Model 2) exhibits the principals talked 
about in the Open Governance Model.

Let me be clear: I still think Qt (the library) is really great amazing stuff 
and want to thank every single contributor for it. But this shenanigans with 
the licensing is well, shenanigans. Show me another "open source" project that 
goes commerical-only in the LTS branch? The criticism is warranted. By that 
alone, not to mention having a not-yet-viable-next-version.










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

Re: [Development] Changes to Freenode's IRC

[Jason H]

> Hi!
>
> On Wed, 19 May 2021 at 12:30, Jason H  wrote:
> >
> > Aren't all the kids these days moving to Discord?
>
> Discord is not free software, so it does not align well with a free
> software project.

QtCentre is not free software
forum.qt.io is not free software

What is the point of having alignment on the license of the service with the 
project license? Shouldn't the service be able to pick the best (for various 
definitions of "best") software for providing the service? Open Source servers 
may still require onerous terms of service to be used, the underlying code 
license implementing the service is a separate matter. I would say that as long 
as there is openly available clients for users to use, the license isn't as 
important as the terms of use for the service itself. (I'm sure Stallman would 
still disagree though) I'm open to preferring open services, but I just think 
the terms are more important than the license of the code base implementing the 
service, for me anyway.

I often wonder if Qt is still qualifies as "free software" under the new 
management? (Stopping LTS for OpenSource users in the middle of a LTS series 
really shattered my trust in Digia, if you can't tell)






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

Re: [Development] Changes to Freenode's IRC

[Jason H]

Aren't all the kids these days moving to Discord? Slack is inefficient as the 
history is rolling unless you pay for more.

I would worry about moving it under Digia (tQtCo), because I'd expect them to 
encumber the access to it(paywall, ads, tracking, etc*). I don't trust them.

Perhaps the KDE people would operate the Discord infrastructure?

* Before you laugh, and say that is crazy, consider that the online Qt Docs 
search results now have ads: 
https://doc.qt.io/qt-5/search-results.html?q=camera shows 4 ads for me.  And I 
don't know of any other toolkit who serves their documentation with ads. Take 
for example mozdev: https://developer.mozilla.org/en-US/search?q=camera shows 0 
ads. React, 0 ads. I figure it's only a matter of time until the actual 
documentation pages have ads too. (There may be good reasons for ads, but it's 
still not a good look.)


> Sent: Wednesday, May 19, 2021 at 10:49 AM
> From: "Giuseppe D'Angelo via Development" 
> To: development@qt-project.org
> Subject: Re: [Development] Changes to Freenode's IRC
>
> On 19/05/2021 16:37, Andy Nichols wrote:
> > Rather than just move to another IRC server, we should really take this as 
> > an opportunity to move to another chat service as the official Qt Project 
> > chat.  IRC has a terrible user experience and is not at all accessible for 
> > people who haven't been using it for decades like many of us. It does us a 
> > huge disservice when trying to attracting new contributors to point to our 
> > IRC.  There are lots of better options out there now (which I see some of 
> > you on already), so lets move on already.
>
> The mandatory question is always the same: which ones?
>
> Do they have goals, policies, end-user agreements that are compatible
> with a free software project? Do they have strong privacy requirements? Etc.
>
> Thanks,

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

Re: [Development] Commercial LTS Qt 5.15.4 released

[Jason H]

> Sent: Wednesday, May 12, 2021 at 12:00 PM
> From: "Frank Hemer" 
> To: development@qt-project.org
> Subject: Re: [Development] Commercial LTS Qt 5.15.4 released
>
> On Mittwoch, 12. Mai 2021 17:51:51 CEST Thiago Macieira wrote:
> > On Wednesday, 12 May 2021 08:30:52 PDT Frank Hemer wrote:
> > > On Mittwoch, 12. Mai 2021 17:26:50 CEST Thiago Macieira wrote:
> > > > Even maintainers who like me don't get access to the source, it's
> > > > important
> > > > to know the release was made.
> > >
> > > Not having access to sources for maintainers is simply ridiculous.
> >
> > The problem is licensing, not Qt Company's willingness. They offered when
> > this all began. But since it's not open source, I can't look at it.
>
> Hmm ... to me sounds like the cat is biting its tail ...
> (formerly) os project, os maintainers, os contributors but locked out due to
> not being os.
>
> I really can't express my regret for decisions in this direction - and I AM a
> licenseholder!

Same. License holder and a hobbiest. I don't understand how 5.15.2 is the last
non-commerial LTS, which is not a LTS of all future releases are commercial.
This is entirely Digia's unwillingness to support the open source community
that made this toolkit so popular.

I could see if Commerical LTS was different from open source LTSs, but there
are no open source LTS (5.15.3 or 5.15.4) available in the installer. They just
aren't providing open source LTSs anymore. I'm sure the code exists somewhere,
but they bait-and-switched us to using the online installer, then required
accounts, and then... no LTS for you!

This has forced me to reconsider Qt as essentially closed source, I will be
brushing up on my web dev skills and just going electron/cordova in the future.
I wonder what this means for KDE. They probably have enough infrastructure to
weather this storm, but the average person will just choose HTML5, the vast
majority already do. I'm regretting having endorsed this library in the past.


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

Re: [Development] Commercial LTS Qt 5.15.4 released

[Jason H]

I think what Konstantin was getting at was the silliness that you're only doing Commerical LTS releases now.

I hoped that Commericialization of LTS release was a mistake that would not have be repeated.

 
 

Sent: Wednesday, May 12, 2021 at 9:33 AM
From: "Tuukka Turunen" 
To: "Konstantin Ritt" 
Cc: "development@qt-project.org" 
Subject: Re: [Development] Commercial LTS Qt 5.15.4 released




Hi,

 

Most of the maintainers are also addressing issues in the commercial LTS releases, including also some who do not work for The Qt Company. So in that sense it is not completely off, but I do agree that announcing the commercial LTS releases via the announce list is probably enough. 

 

Yours,

 

    Tuukka

 


From: Development  on behalf of Konstantin Ritt 
Date: Wednesday, 12. May 2021 at 15.44
To: 
Cc: development@qt-project.org 
Subject: Re: [Development] Commercial LTS Qt 5.15.4 released




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




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

Re: [Development] Question about QtDeclarative Internals

[Jason H]

> Hello,
>  
> In QtDeclarative, can a QV4::ReturnedValue or a QV4::Value be converted into 
> an ExecutableCompilationUnit?
> 
> I'm trying to work on a patch for QJSEngine to allow importing modules from 
> C++ (similar to Node.js: import fs from "fs")
> The planned method is something along the lines of:
> void QJSEngine::registerModule(const QString , const QJSValue 
> )
>  
> I can see that behind the scenes, loadModule compiles a URL to an 
> ExecutableCompilationUnit, then saves it to a list of modules for future 
> lookup.
> I thought the easiest way to do what I need is to convert a QJSValue to an 
> internal QV4::Value, and from there into an ExecutableCompilationUnit.
> Is there any way of doing that?

This may not be what you asked for, but having done NodeJS, I would probably 
just recommend importing a Qt QObject as a Singleton to expose the functions 
under the fa import.
See qmlRegisterSingletonType().

import org.mine.fs 1.0

...
var file = fs.openFileSync(...);
...


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

Re: [Development] QFuture and C++20

[Jason H]

> Sent: Wednesday, March 03, 2021 at 12:44 PM
> From: "Giuseppe D'Angelo via Development" 
>
> Il 03/03/21 17:12, Allan Sandfeld Jensen ha scritto:
> > They are only halfway there in C++20, AFAIK it is missing the standard 
> > library
> > parts, which means it is not really usable for most people until C++23, so I
> > assume we have time before anyone will actually have interaction between the
> > two types of code.
> >
> > Unless I missed something?
>
> The language parts are there in C++20; what's missing from the standard
> library are "ready-made" coroutines types (task, generator, ...),
> awaitable types, utility functions for scheduling execution, etc.
>
> I've been wondering for a little while how to integrate
> signal/slots/exec()/etc. with coroutines.

Really glad to hear that you're looking into it! I don't think Qt needs the 
ready-made types to target the async stuff?

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

[Development] QFuture and C++20

[Jason H]

I saw Lars's Qt6 talk on youtube, where he said Qt6 requires C++17. He also 
mentioned the new QFuture:: then() function... This is an improvement, but it 
makes Qt code look like Javascript in 2015.

In C++20 there are async/await mechanisms. Ideally ask that then() code word be 
replacing by 'await'. Are there any plans to provide C++20 async/await 
interoperability with QFuture?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QProperty and when evaluation occurs

[Jason H]

I'm still trying to wrap my head around this proposal and I'm skeptical that it 
can be done at all. 

I think there are two occasions where evaluation must be instant. The first is 
if your write property handler has any emits in it, and the second is if there 
are any other properties that depend on the changed value of your property. 

The first case is a little bit more difficult because if you have a guard 
around a signal emission Qt will always have to evaluate the property to 
determine whether or not the signal emission occurs. It would be good to 
structure things in a way beforehand that we can defer the invocation totally. 

And there is a third case in which the handler will modify class members that 
aren't properties. 

All in all I don't think this lazy evaluation could be done safely in a way 
that won't break existing code. We should rely on the developer to understand 
how properties work and structure their code around it, otherwise if we risk 
creating additional rules that will cause confusion and frustration to 
developers. We already have established rules on how the system works and 
you're going to add a whole another layer of magic in. I'd rather stick with 
the existing simple set of rolls and allow the developers to wield that rather 
than have us come up with logic that doesn't work 100% better. I think any 
guarded signal emission breaks the case for this magic binding evaluation. 
You're still going to have to call the handler every time in those cases, and 
any other deferred handlers will make it inconsistent. 

I think the logic being done here should be done by the developer and not Qt 
itself because Qt cannot account for everything that developer could 
potentially want and we would be restricting them unnecessarily. 



> Sent: Friday, July 24, 2020 at 1:45 PM
> From: "Stottlemyer, Brett (B.S.)" 
> To: "Volker Hilsheimer" 
> Cc: "development@qt-project.org" 
> Subject: Re: [Development] QProperty and when evaluation occurs
>
> Hi Volker,
> 
> On 7/23/20, 3:13 PM, "Volker Hilsheimer"  wrote:
> 
> But why would we calculate the volume if nobody cares about the volume? :)
> 
> Qt Remote Objects.  I've got a headless service on one device, and a remote 
> UI for interacting with it.  When signals are emitted (property change or 
> otherwise) by the service, the results are forwarded to the remote UI.
> 
> Lazy evaluation probably works fine if the bindings are on the UI side, but 
> things break down if they are on the service side.  That was why I was trying 
> to distinguish between derived properties _on a QObject_ vs bindings in a QML 
> UI.
> 
>FWIW, pull-based systems are *much* more scalable than push-based systems, 
> because data is produced at the rate it can be consumed, not at the rate it 
> can be produced. That is unrelated to polling.
> 
> That's only true if you know when you need to pull data.  Otherwise it 
> _becomes_ polling.  Also, I think you are assuming the pull is blocking, 
> which is not always valid.
> 
> How will logging work?  I often connect a lambda to a changed signal to 
> troubleshoot or log something.  If such a routine were debug or 
> troubleshooting only, wouldn't that build behave fundamentally differently 
> (one doing immediate eval because of the signal connection, the other not)?.
> 
> Thanks,
> Brett
> 
> ___
> 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] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray (Thiago Macieira)

[Jason H]

Just thinking outloud, but would it be possible to have a conversion function 
that takes a map of lamdas?
Where I am going with this, is that it would be cool to have some serialization 
function that looks like:

map.convert(QMap {
  {"QByteArray": [](QByteArray const& ba) 
{
  return QString(ba.toHex());
}
  }
});

It's a little gross, but the goal is to allow the application to provide the 
conversion code in ambiguous situations. I'm assuming there is another type 
than QByteArray that has ambiguous conversion, or that we would allow it for 
any type. If it's just QByteArray, it could be just:

map.convert([](QByteArray const& ba) {
 return QString(ba.toHex());
});

Maybe that's a dumb idea, because you could always just patch it up later, but 
I am under the impression that that has some quirks like if in map, having to 
patch the map up once the map is modified. And so the lambdas would end up 
being cleaner. 

Just a thought.


> Sent: Friday, July 03, 2020 at 2:07 PM
> From: "Thiago Macieira" 
> To: development@qt-project.org
> Subject: Re: [Development] [RFO QTBUG-84739] QJsonValue::fromVariant 
> containing QByteArray (Thiago Macieira)
>
> On Friday, 3 July 2020 05:16:11 PDT Arnaud Clère wrote:
> > > [1] https://tools.ietf.org/html/rfc7049#section-4.1
> > 
> > Even if non normative, these advices are useful and even more so when
> > implemented in such wide-spread library as Qt, so if it can be opted-in, I
> > would definitely prefer option c)
> 
> That advice applies about converting CBOR to JSON. Ever since I introduced 
> QCborValue, doing:
>   QCborValue(QByteArray("Hello")).toJsonValue()
> resulted in
>   QJsonValue("SGVsbG8")
> 
> That will not change. You may call this surprising, but it's in line with 
> standards and is explicitly documented as such.
> 
> It's also the reason this change happened to QJsonValue, because we reused 
> QCborValue::fromVariant and then converted from that to JSON.
> 
> Also note that you can tell CBOR how to encode a byte array to JSON:
> 
>   QByteArray hello("hello");
>   QCborValue(hello).toJsonValue();
>   // "SGVsbG8"
>   QCborValue(QCborKnownTags::ExpectedBase64, hello).toJsonValue();
>   // "SGVsbG8="
>   QCborValue(QCborKnownTags::ExpectedBase16, hello).toJsonalue();
>   // "48656c6c6f"
> 
> -- 
> 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] [RFO QTBUG-84739] QJsonValue::fromVariant containing QByteArray

[Jason H]

B. 
- This will break so many things in a big way. It does not reflect the 
reasonable assumption that for reasonable cases you'll get a reasonable 
response. I do agree it is the proper loss-less way, but people shoving 
extended chars in to byte arrays do so intentionally, even if haphazardly. For 
example, when I do it, I base64 at the application level myself. The developer 
should be be left to implement this level of safety themselves, not the toolit. 

- Other packages (like Python) do not automatically encode to base64. Therefore 
this is not expected behavior
- Also, there is no way to know to transparently decode the JSON on 
deserialization
- Any software that interacts with Qt serialized data will have to implement 
Qt's rules.

Therefore B is the only option I find acceptable. If the developer requires 
perfect lossless storage using byte array then they have to implement 
themselves, via a mechanism of their choice.

 

> Sent: Wednesday, July 01, 2020 at 5:21 PM
> From: "Thiago Macieira" 
> To: development@qt-project.org
> Subject: [Development] [RFO QTBUG-84739] QJsonValue::fromVariant containing 
> QByteArray
>
> Re: https://bugreports.qt.io/browse/QTBUG-84739
> Summary: Qt 5.15 has an unintentional change in behaviour that has broken 
> existing applications. We need to decide whether to:
>  a) leave as-is
>  b) revert permanently
>  c) revert for 5.15.x but keep the new behaviour in 6.x
> 
> (a) implies one change in behaviour (5.14.2 to 5.15.0)
> (b) implies two changes in behaviour (to and from 5.15.0)
> (c) implies three changes in behaviour: 5.14.2→5.15.0, 5.15.0→5.15.1, 
> 5.15.x→6.0
> 
> Testcase:
> const char binarydata[] = "\0\1\2\3\xff";
> QVariantMap vmap = {
> {"ascii", QByteArray("ASCII text.\n")},
> {"latin1", QByteArray("R\xe9sum\xe9")},
> {"utf8", QByteArray("Résumé")},
> {"binary", QByteArray(binarydata, sizeof(binarydata) - 1)}
> };
> QJsonObject jobj = QJsonObject::fromVariantMap(vmap);
> printf("%s", qPrintable(QJsonDocument(jobj).toJson()));
> 
> Because of the switch in QJsonValue/Object/Array to use the CBOR classes as a 
> backend, we had an uninteded change in behaviour in how the JSON 
> fromVariantXxx functions behave for some variant types that are not part of 
> the JSON specification. In the bug report, this happened specifically for 
> QByteArray.
> 
> Qt 5.14 output:
> {
> "ascii": "ASCII text.\n",
> "binary": null,
> "latin1": "R�sum�",
> "utf8": "Résumé"
> }
> 
> Qt 5.15 output:
> {
> "ascii": "QVNDSUkgdGV4dC4K",
> "binary": "AAECA_8",
> "latin1": "UulzdW3p",
> "utf8": "UsOpc3Vtw6k"
> }
> 
> The Qt 5.15 output is the Base64url encoding of the original byte array data, 
> following the CBOR recommendations on how to convert CBOR to JSON (RFC 7049 
> section 4.1[1]). This was unintentional and happened only due to code reuse. 
> The QtJson unit tests did not test this and do not test how converting from 
> any QVariant types except the base ones that apply to JSON, plus QUrl and 
> QUuid. But it has broken user code that relied on this feature.
> 
> It wasn't entirely undocumented. QJsonValue::fromVariant said:
> For all other QVariant types a conversion to a QString will be attempted.
> If the returned string
> is empty, a Null QJsonValue will be stored, otherwise a String value using
> the returned QString.
> [this text is changed in https://codereview.qt-project.org/305996]
> 
> Since it depends on QVariant::toString(), it's implicit that the behaviour 
> can 
> change from version to version. For Qt 6.0, we're already discussing whether 
> conversion between types in QVariant makes sense and toString() is one of 
> those cases.
> 
> As can be seen in the testcase, the old behaviour is silently lossy, which 
> means it's dangerous. The new behaviour is surprising, but it's not lossy, as 
> the original byte data is retrievable:
> 
>   $ base64 -d <<   ASCII text.
>   $ base64 -d <<   000   R 351   s   u   m 351
>   $ base64 -d <<   Résumé  
> 
> 
> (the type change is inevitable and is accepted by the user)
> 
> Request For Opinion: what do we do now? See options at the beginning of the 
> email.
> 
> Note also this behaviour is not completely correct, because fromVariant 
> converts *empty* strings to null, but it should only convert null QStrings to 
> null, leaving empty strings alone (that's the QCborValue::fromVariant 
> behaviour). I also don't think the implementation is self-consistent, because 
> the conversion code appears more than once.
> 
> [1] https://tools.ietf.org/html/rfc7049#section-4.1
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
> 
> 
> 
> ___
> Development mailing 

Re: [Development] Qt Multimedia as Add-on in Qt 6

[Jason H]

How about I just pay - which my company already does? The lagging mobile 
support has us considering moving away from Qt. I think this decision would 
confirm our direction and only hasten our departure from the Qt ecosystem.

I guess to some degree it depends on how you define "essential". Clearly 
multimedia *is* essential but not needed on RTOS. And given the myriad of 
custom hardware in the RTOS space, I think a more appropriate answer would be 
to have a default stub implementation for those platforms rather to separate 
out multimedia.

> Sent: Friday, May 22, 2020 at 10:42 AM
> From: "Ville Voutilainen" 
> To: "Jason H" 
> Cc: "Lars Knoll" , "Qt development mailing list" 
> 
> Subject: Re: [Development] Qt Multimedia as Add-on in Qt 6
>
> On Fri, 22 May 2020 at 17:19, Jason H  wrote:
> > I object, and wish multimedia to remain an essential part of Qt.
>
> Then help maintain and develop it. Wishes are cheap.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Multimedia as Add-on in Qt 6

[Jason H]

Will this have repercussions in the Maintenance tool?
I don't really think that calling Multimedia an "add on" is a reflection of 
reality, post 1994.
For mobile kits (iOS, Android) these are essential features. Sorry, Qt just 
can't get away with drawing rectangles and text in 2020. I fear this is more 
maligning of mobile by Lars. I think this will result in providing a lower tier 
of service than compared to the "essentials".

I object, and wish multimedia to remain an essential part of Qt. 





> Sent: Friday, May 22, 2020 at 3:47 AM
> From: "Lars Knoll" 
> To: "Giuseppe D'Angelo" 
> Cc: "Qt development mailing list" 
> Subject: Re: [Development] Qt Multimedia as Add-on in Qt 6
>
> Hi,
> 
> > On 21 May 2020, at 18:08, Giuseppe D'Angelo via Development 
> >  wrote:
> > 
> > Hi,
> > 
> > Il 21/05/20 11:38, Val Doroshchuk ha scritto:
> >> The license is not changed, plans just to not ship QtMultimedia with Qt 
> >> essentials,
> >> can be installed separately. Possibly we also support only a limited set 
> >> of platforms.
> >> Qt Essentials must work on every platform, according to the definition of 
> >> essentials.
> > 
> > While of course it's up to each module maintainer to decide on its status 
> > (and thus, if QtMM doesn't qualify for "Essentials" any more, can become an 
> > "Addon"), I'm left wondering why does this imply being moved to the 
> > Marketplace, out of Qt itself?
> > 
> > 
> > * Is this part of a broader plan, aiming at streamlining the Qt offer to 
> > just mean Essentials, while the Addons get moved to the marketplace?
> 
> This is something I’ve been at least mentioning at the Contributor Summit 
> already. Distributing it through the market place is mainly a different means 
> of packaging it and decoupling the release schedules. A user should still be 
> able to discover and install Qt MM (or other add-ons delivered through the 
> market place) in the installer, just as today.
> 
> But yes, this goes then towards streamlining Qt 6 a bit. Reducing the set of 
> things that you have to install, and making more modules optional.
> > 
> > ("Qt offer" is of course inaccurate, given the many offers available, but 
> > you get my drift...).
> > 
> > 
> > * If so, are all the practical issues for such addons sorted out? First few 
> > things that come to mind:
> > 
> > 1) Version numbering scheme, release schedule
> 
> This needs some sorting out, I agree.
> 
> > 2) CI testing / platform coverage
> 
> That should be ok for now, although if an add-on targets several Qt versions 
> at once, we don’t yet have a good mechanism to deal with that in CI.
> 
> > 3) Compatibility promise (own API/ABI stability, which Qt versions it works 
> > with, etc.)
> 
> I think it will be good to give add-ons a bit more flexibility there how to 
> handle it. This is because different add-ons have rather different 
> requirements, that we’ve so long all tried to shoehorn into the Qt release 
> process. Compare for example WebEngine that needs frequent updates due to new 
> Chromium releases with e.g. Qt SVG that only receives a very limited amount 
> of bug fixes.
> 
> > 4) Where to put the docs, release notes, etc.
> 
> Into the package and on the web site as usual.
> > 
> > 
> > * What about the KDE/Qt agreement? Are the list of Essential and Addon 
> > modules being re-evaluated there as well? QtMM is not really at liberty of 
> > changing license because it's an "Essential" (in the agreement).
> 
> There’s the agreements legal term, and the status in terms of the agreement 
> is something we can’t change without agreement from the board of the KDE Free 
> Qt Foundation.
> 
> When the new agreement was done some years ago, we tried to align terms with 
> what we had in Qt Project at that time. But things do change and I believe we 
> can change what we see as essential and add-on in terms of the project (and 
> in the commercial packages) independently of the agreement. 
> 
> This is confusing to some extent as the legal agreement uses the same terms 
> as we’re using, but the terms are defined in the agreement itself, and 
> limited to the scope of the agreement. They don’t dictate how we package or 
> name things in our releases (as long as the conditions set forth in the 
> agreement are fulfilled).
> 
> The main thing the agreement mandates is the licensing of add-on and 
> essential modules. But the only real difference between add-ons and 
> essentials (as defined in the agreement) are that essentials have to be 
> LGPLv3, while *new* add-ons can be GPLv3. We can’t change licensing of 
> currently supported modules without agreement from the foundation in neither 
> case. We also can’t reduce the scope of the agreement, so Qt Multimedia will 
> be part of that agreement no matter how we package and deliver it to our 
> users.
> 
> Cheers,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> 

[Development] Lar's QtCore 6 talk

[Jason H]

https://www.youtube.com/watch?v=cHrrR3KhvUk

Thanks for the insight into what is coming up. I had a minor panic attack 
though, which seemed to be shared with the first person to ask a question. If 
the property bindings are lazy evaluated, then all my QML code will be broken. 
I actively exploit the existing binding behavior of immediately evaluating 
dependent bindings.  I hope I am misunderstanding this, but I think this should 
continue to be the behavior.  I also I don't want to have to choose or specify.

However there may happy automatic middle ground. If the bindings are a terminal 
leaf node, then they can be lazy evaluated. However any binding that is in the 
middle of a binding chain must be immediately evaluated. I think this will 
satisfy everyone.

Given:
Item { id: item; property int x2: parent.x*2 }

If x2 is not used anywhere, it can be lazy evaluated. But the moment there is a 
onX2Changed or Item { x: item.x2 } then it must be immediately evaluated.  For 
something like QML Items and x it is probably not that interesting of an 
example.
But let's now assume there is QObject-derived class bing used in the QML engine 
and it declares property x which is not required to be immediately updated, 
then as long as nothing is connected to the xChanged signal, then all those 
updates can be deferred[1]. But the moment something does connect to it, then 
it can no longer be lazy-evaluated.

I don't know if this is what Lars meant? But I think it could work without 
giving me panic attacks ;-)

[1] If you need a less abstract example, think of a QObject-derived class that 
processes video frames and uses OpenCV to find a target, and it emits the x,y 
position of the target.  If nothing is connected x() never needs to be 
evaluated, but if I connect a CrossHair Item and bind to the x() and y() 
properties, then the binding has to be evaluated immediately to update the 
position in the UI.

I do have another concern that perhaps the lazy bindings might make it harder 
to find binding loops?

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

Re: [Development] Qt 6.0.0 initial schedule

[Jason H]

> Sent: Monday, April 27, 2020 at 8:05 AM
> From: "Jani Heikkinen" 
> To: "development@qt-project.org" 
> Subject: [Development] Qt 6.0.0 initial schedule
>
> Hi,
>
> It is time to start freezing Qt 6.0.0 initial schedule. I have had some 
> discussion and based on those here is the initial schedule for Qt 6.0.0:
>
> - Qt 6.0 Feature freeze 31.8.2020
> - Qt 6.0 Alpha 14.9.2020
> - Qt 6.0 Beta 1 1.10..2020
> - Qt 6.0.0 RC  17.11.2020
> - Qt 6.0.0 Final 1.12.2020

I for one am very concerned about the Camera API for mobile. I have hard that 
this is being re-worked. I haven't heard how. Hut any new API should take into 
account multiple front & rear cameras, and potentially (TrueDepth/ disparity 
map cameras). I also recently learned that the Android camera APU still does 
not have manual exposure control, while iOS does...

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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jason H]

> Sent: Friday, April 24, 2020 at 4:14 PM
> From: "Giuseppe D'Angelo" 
> To: "Jason H" 
> Cc: development@qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> On 4/24/20 9:03 PM, Jason H wrote:
> >> In fact, it is-a QList. What's the problem here with its naming?
> >
> > Because I can't QSringList{"me", "you"}.join() with a QList.
>
> I didn't say that it's a typedef for QList, but is-a -- it
> inherits, precisely to provide that kind of convenience.
>
> > Thinking outsize of the box...
> > It seems that all this is cause d by someone wanting to store a pointer to 
> > an item in QVector, which may be reallocted and therfore have moved.
>
> All this => what's this?
>
> > It seem then that the only thing to do is to use a traditional QList, or 
> > return only some kind of ref which will be a stable reference to the item.
> > QStableRef r9 = vector[9];
> > vector.resize()
> > // r9 is updated during resize() and still points to that it was meant to.
> > It's not good practice to store a ref to something that can be realloated. 
> > I don't know how you can prevent people from doing that with offering T& 
> > operator[](int i);
>
> QList today offers exactly that. In array-of-pointers-mode it also
> offers stability of references.

Yes. I agree. I think the OP kicked this off with a thing about soring refs to 
items in QVector which is relocatable. My post was just to say this is a bad 
idea fro QVector. This is not immediately obvious though. The API/docs fail to 
communicate that storing pointers/refs to items is a bad idea. Which then as me 
agree with you and Lars's current thinking.

I however want some generic indexable/iterable type, where it doesn't care if 
the final storage is QList or  QVector... When I am working as an API, I don't 
want to choose for my users what that type is and make them pay for conversion. 
Which I think QList was historically the right choice. Ideally I want to have a 
QIterable for processing lists/arrays/vectors. I think the developer should be 
able to determine the storage best for their application, not me.

Side note:
It also kicked off a thing in my brain about .NET and the managed runtime, 
where C++ on .NET got ^, the handle operator, which allows dereferencing to 
items given that everything is relocatable due to memory compaction. I think it 
could be a great thing if C++ has such a thing, as I attribute 99% of all long 
boot time lockups on Raspberry Pis to memory fragmentation (completely 
anecdotally) And if C/C+ could offer some kind of memory management beyond 
malloc/free, we could get the next 99% of lockups and random crashes avoided.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Jason H]

> Sent: Thursday, April 23, 2020 at 12:05 PM
> From: "Giuseppe D'Angelo via Development" 
> To: development@qt-project.org
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
>
> On 4/23/20 5:04 PM, Julius Bullinger wrote:
> > Another suggestion: Get rid if the aliases; use the fully-qualified
> > types instead.
> >
> > I'm always irritated if I open the documentation of QVariantList from
> > within Qt Creator, and land on the QVariant docu instead. I'm interested
> > in the features of the container, not the contained type.
>
> This is a documentation bug or a Creator bug. You're supposed to land on
> this anchor: https://doc.qt.io/qt-5/qvariant.html#QVariantList-typedef
>
> > And I have to remember if QStringList is the same as as QList,
> > or if it's actually a different container with a different API.
>
> In fact, it is-a QList. What's the problem here with its naming?


Because I can't QSringList{"me", "you"}.join() with a QList.

Thinking outsize of the box...
It seems that all this is cause d by someone wanting to store a pointer to an 
item in QVector, which may be reallocted and therfore have moved.
It seem then that the only thing to do is to use a traditional QList, or return 
only some kind of ref which will be a stable reference to the item.
QStableRef r9 = vector[9];
vector.resize()
// r9 is updated during resize() and still points to that it was meant to.
It's not good practice to store a ref to something that can be realloated. I 
don't know how you can prevent people from doing that with offering T& 
operator[](int i);



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

Re: [Development] How to get winid from qprocess id for QProcess

[Jason H]

I think this question is better suited to the qt-interest mailing list.

 

It has been decades since I did Win32 programming, but I would assume that you could ask Windows to find the window for you and give you the HWND. I don't think you can map from process to HWND, you'd have to map HWND to process?

 

But my days of programming Win32 are long over. Thank you, Qt!

 
 

Sent: Thursday, February 20, 2020 at 9:36 AM
From: "Sujan Dasmahapatra" 
To: development@qt-project.org
Subject: [Development] How to get winid from qprocess id for QProcess



hi friend

 

I am running an external app, which I want to fit onto my QScrollArea, for this I am writing code like this.

 

// launch weasis
QProcess *process = new QProcess();
process->start("./viewer-win32.exe");
if (process->waitForFinished())
{
return;
}

 

QWindow *window = QWindow::fromWinId(211812356);
window->setFlags(Qt::FramelessWindowHint);
_patient_gui->scrollArea_1->setWidget(QWidget::createWindowContainer(window));

 

But how can I get the wind id? it is hard coded here, is there any way to get the id from process id.

 

any help is highly appreciated.

 













___ 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] How to perform unattended installations of Qt? (Was: Changes to Qt offering)

[Jason H]

Though I have not tried it, I would suggest Ansible and 
https://bugreports.qt.io/browse/QTIFW-166 , notably 
https://code.qt.io/cgit/qbs/qbs.git/tree/scripts/install-qt.sh

I use the install script and it was cake. However, I don't know how much longer 
this will be supported with the changed Lars announced?




> Sent: Friday, February 14, 2020 at 5:06 PM
> From: "Sze Howe Koh" 
> To: "Thiago Macieira" 
> Cc: "Qt development mailing list" 
> Subject: [Development] How to perform unattended installations of Qt? (Was: 
> Changes to Qt offering)
>
> On Sat, 15 Feb 2020 at 04:19, Thiago Macieira  
> wrote:
> > On Tuesday, 28 January 2020 19:31:34 PST Thiago Macieira wrote:
> > > On Tuesday, 28 January 2020 03:52:49 PST Tino Pyssysalo wrote:
> > > > It is also possible to transfer the qtaccount.ini file to a CI machine,
> > > > which removes the need for manual/interactive login. The qtaccount.ini
> > > > just
> > > > contains the hash of the password.
> > >
> > > I suggest you be very careful in suggesting how to transfer the
> > > qtaccount.ini file. Test half a dozen public CI systems and give
> > > instructions to them all.
> > >
> > > And specifically tell people NOT to "git add" it to a project on GitHub/
> > > GitLab/BitBucket.
> >
> > Hello Tino
> >
> > Can we get an answer here?
> >
> > What is the recommended way to install Qt on a CI to test a Qt-based
> > application?
> >
> > Travis CI has stopped working completely and I'd like to switch to GitHub
> > Actions. Does The Qt Company recommend I use Stephan Binner's PPA? Or does 
> > it
> > want me to use its own compiled binaries? If the latter, please provide
> > instructions for automated builds.
>
> Hello Tino,
>
> It's not just CI; Qt now can't be easily used with all other
> automation technologies like Docker. [1]
>
> Please note that users have started to suggest workarounds such as
> creating throwaway Qt accounts in order to automate the installation.
> [2]
>
>
> Regards,
> Sze-Howe
>
> [1] https://forum.qt.io/post/577886
> [2] https://forum.qt.io/post/577926
> ___
> 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] The future of smart pointers in Qt API

[Jason H]

Recently this has caused me much consternation. I think QtQuick everything 
should have a parent, and a visual parent, though I appreciate how tedious this 
would be. They should be the same except when they can't and having separate 
properties would highlight that.


> Sent: Monday, February 03, 2020 at 10:33 AM
> From: "Mitch Curtis" 
> To: "Vitaly Fanaskov" , "Konrad Rosenbaum" 
> , "development@qt-project.org" 
> Subject: Re: [Development] The future of smart pointers in Qt API
>
> > Vitaly Fanaskov
> >
> > [...] In this case, I think we won't have this confusing definitions like 
> > "visual
> > parent" and "just a parent"
> > (that we have in controls).
>
> Sorry, couldn't resist: visual parent vs QObject parent is a distinction that 
> Qt Quick made, not Qt Quick Controls.
>
> ___
> 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] The future of smart pointers in Qt API

[Jason H]

Well, I for one do not welcome our new std:: overlords. After many years of 
using C++ (since 98) and diving deeper into it, I think Qt and the C++ 
committee are two completely separate audiences. I cringe at stl code. I once 
asked a question on how to reverse something, and what followed was something 
that used some crazy templating and emplace_back and was completely 
"unreadable" to the average person.  I read it, and it took me a while to 
deconstruct what it was actually doing. I've resolved to learn more about C++ 
after that, and the result of my studies so far are that stl people are far 
more interested in telling the compiler how to build the code than actually 
accomplishing something. That is not a bad thing, and probably very desirable 
perspective for the stl committee to have. However, Qt licensees (open and 
commercial) are not the committee, and are more interested in accomplishing 
something rather than providing a library. As a result, the code of a Qt-using 
program should be readable by average developers not big into C++. Meanwhile, 
it also does not serve anyone to duplicate stl. I do not know where the 
threshold is for duplication (probably pretty high) but I would encourage the 
threshold to be low for augmentation.

Qt's motto is "Code less. Create more." which I think reflects the perspective 
of Qt-using community. That is definitely not the motto of the std committee. 
(Though at times they do align)

One thing I have a huge concern over is the upcoming (if any) integration of 
std::async, which I thought would have some effects on QFuture et. al., (see 
the other thread concurrently going on)

I would hope that Qt only forces users to use std when there is no possible 
Qt-value add. I don't want Qt to decline to add a Q* class because they are 
forcing the use of std. If there is a value-add then I think Qt should provide 
it. 

Finally, and least importantly, but still important, Qt classes just look so 
much prettier, and I think that helps non-C++ developers. (Of which there is an 
increasing number of al the time)


> Sent: Sunday, February 02, 2020 at 6:00 AM
> From: "Daniel Teske" 
> To: development@qt-project.org
> Subject: Re: [Development] The future of smart pointers in Qt API
>
> 
> > Pros I can see:
> > 1) Qt style
> > STL has different naming convention that looks alien to Qt API. It leads to 
> > inconsistency.
> 
> The "Qt projects not using the standard library" era is over and the 
> sooner that is understood the better. That inconsistency is just 
> something to get used too
> 
> Qt does not duplicate:
> 
> std::optional
> std::tuple
> std::function
> ranges
> algorithms
> parallel algorithms
> 
> All of them are great features that I would expect every Qt project to 
> have some use for.
> 
> This list will grow in the future because C++ evolution is quite a bit 
> faster then in the past. This isn't just that the standard gains 
> features faster, but that compilers implement them immediately and from 
> my experience these features are adopted in the industry.
> 
> In the future mixing Qt and standard classes will be even more common.
> 
> The important question for Qt is: How to leverage the evolution of 
> standard C++ for the best combined offering.
> 
> daniel
> 
> 
> ___
> 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] Request to move qt-labs/qhttpserver out of qt-labs

[Jason H]

I just want to say that the qthttpserver is the most impactful contribution to 
Qt for me in along time.
Having a http server in Qt has allowed saved me so much work, provide so many 
additional integrations with ease.
* would use again.

Given hoe much positive impact it has had, I would like to see it as a main 
part of Qt though.

> Sent: Monday, February 03, 2020 at 9:29 AM
> From: "Volker Hilsheimer" 
> To: "Mikhail Svetkin" 
> Cc: "development@qt-project.org" 
> Subject: Re: [Development] Request to move qt-labs/qhttpserver out of qt-labs
>
> > On 3 Feb 2020, at 08:15, Mikhail Svetkin  wrote:
> >
> > Hello,
> >
> > I would like to make request to move qthttpserver from qt-labs namespace to 
> > a new namespace qt-addons or qt-extensions.
> >
> > The main reason is that it is not a research project anymore. I believe 
> > that the module is ready to become a self contained library as part of Qt 
> > Project and a good example of Qt marketplace.
>
>
> Yes indeed! Thanks for being awesome :)
>
>
> > I also would like to request to have an independent branch policy for the 
> > new repository. It will allow to speed up development of qthttpserver and 
> > it will not slow down Qt6 works.
>
>
> It makes little sense to me to have the same branching policy for every 
> module, irrespective of their maturity, complexity, release practices etc. 
> E.g. new modules might want to start with the cherry-picking model right 
> away, or not have the notion of LTS branches to begin with.
>
> OTOH, we should have a consistent place where contributors can see how 
> different modules do things. Do you plan to document your branching policy?
>
> Volker
>
> ___
> 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] QtPDF did not change license

[Jason H]

/r/ThereWasAnAttempt

> Sent: Tuesday, January 28, 2020 at 12:53 PM
> From: "Giuseppe D'Angelo via Development" 
> To: development@qt-project.org
> Subject: [Development] QtPDF did not change license
>
> Il 28/01/20 18:37, Jason H ha scritto:
> > - the previous license changes Tukka announced (QtPDF, 
> > etc:https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf)
>
> As per subject. The blog post is inaccurate.
>
> > https://lists.qt-project.org/pipermail/interest/2019-October/033979.html
>
>
> My call here went unanswered.
>
> > https://lists.qt-project.org/pipermail/interest/2019-October/034045.html
>
> My 2 c,
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - 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] Changes to Qt offering

[Jason H]

So I've had a night to think about and react to this.

I want Qt to be successful and make lots of money in addition to taking over 
the world. I can appreciate this approach as a way to drive sales. After all, 
anything that gets Qt for Mobile more complete is very much appreciated. ;-)

However I think these decisions are moving Qt in the wrong direction. It's 
making Qt less accessible, not more. Even something as trivial as the skip 
button in the online installer causes a lot of friction. At a time when the 
cross platform toolkits are proliferating, (mainly Webkit based technologies 
(Electron, ReactNative, etc)) and interest in C++ is waning, adding friction is 
not a plus. Or an alternative is true: Qt has crushed it with auto 
manufacturers and doesn't care about any other segment anymore. (The behavior 
seems to indicate this, maybe not auto exclusively but if you look at all the 
recent additions, they've all been targeted to the vehicle space (flagrant 
speculation))

Also, I absolutely require headless binary install. I would actively rid Qt 
from systems (outside of mobile) and move to Python (and not PyQt) if I lost 
this ability. 

In short, I am disappointed to hear the changes. But all the news out of Qt has 
been disappointing as of late: 
- this announcement
- no mobile progress
- the previous license changes Tukka announced (QtPDF, etc: 
https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf)

There's been a lot of taking away and not a lot of providing. Is Qt still 
useful? Sure, but the vector is pointing in the wrong direction.


> Sent: Monday, January 27, 2020 at 9:34 AM
> From: "Lars Knoll" 
> To: "Qt development mailing list" 
> Subject: [Development] Changes to Qt offering
>
> 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

[Jason H]

I hope these changes mean that you'll be able to support mobile properly. 
I'm still waiting on a response from you about the future of Qt on mobile.


> Sent: Monday, January 27, 2020 at 9:34 AM
> From: "Lars Knoll" 
> To: "Qt development mailing list" 
> Subject: [Development] Changes to Qt offering
>
> 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] Requesting a module for Qt JSON RPC and Qt Language Server

[Jason H]

Question: Will this have any overlap/impact on Qt Remote Objects?
https://doc.qt.io/qt-5/qtremoteobjects-index.html

While the docs says it is not RPC, if it's using similar concepts there might 
be overlap?


> Sent: Monday, December 16, 2019 at 10:39 AM
> From: "Ulf Hermann" 
> To: "development@qt-project.org" 
> Subject: [Development] Requesting a module for Qt JSON RPC and Qt Language 
> Server
>
> Hi,
>
> I would like to request a new module and repository for an
> implementation of the JSON RPC and Language Server protocols:
>
> Name of the repository: qt/qtlanguageserver.git
> Description: An implementation of the language server protocol
> Responsible person: Ulf Hermann
> Gerrit user/email: ulf.herm...@qt.io
>
> You can see my previous work on this in the context of the QML language
> server here:
>
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/243394
> https://codereview.qt-project.org/c/qt/qtdeclarative/+/233778
>
> The relevant specifications can be found at:
>
> https://www.jsonrpc.org/specification
> https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/
>
> The JSON RPC implementation might be moved to QtNetwork, instead. I'm
> eager to hear opinions on this. Mind that the JSON RPC protocol
> implementation doesn't depend on any network classes, but only on
> QIODevice. Indeed you can run many existing language servers over stdio.
>
> Mind also that the language server _protocol_ implementation shown in
> above changes can be used to build both language servers _and_ clients
> for language servers. The basic primitives are automatically generated
> from the specification itself.
>
> There currently is no good place for the language server code in any
> existing modules. We should not commit it to qtdeclarative, as it would
> be useful for a number of other applications, too:
>
> It turned out that we need a language server protocol implementation not
> only for the QML language server, but also for the language client in Qt
> Creator. Qt Creator is using its own, manually written, client-only,
> implementation right now. We should strive to maintain only one Qt-based
> language server protocol implementation.
>
> Another idea is to add rich support for CSS in the style editor of the
> designer by using some existing CSS language server. More generally, we
> could make the integration of existing Qt text editing facilities with
> language support (auto-completion, diagnostics, etc) easier by providing
> a generic language server API.
>
> best regards,
> Ulf Hermann
> ___
> 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] Stepping down as Qt for macOS maintainer (but don't worry)

[Jason H]

I, for one, welcome our new Norwegian overlord.

> Sent: Monday, December 09, 2019 at 6:33 AM
> From: "Morten Sørvig" 
> To: "Qt development mailing list" 
> Subject: [Development] Stepping down as Qt for macOS maintainer (but don't 
> worry)
>
> Hello all,
> 
> I’d like to formally step down as Qt for macOS maintainer, and suggest that 
> Tor Arne Vestbø takes over in my place. He’s already maintaining Qt for iOS 
> (and QPA), and has done a lot of good work on macOS over the past couple of 
> years.
> 
> Cheers,
> Morten
> ___
> 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] QtCS19 Notes: Qt 6 Network Overview

[Jason H]

>   - Removing QFTP
>   ○ This is about QFTP backend in QNetworkAccessManager
>   ○ There are still public users, but how many?
>   ○ Proposal: Disable it in 6.0 and check for amount of complaints
>   § If limited (as expected) remove in 6.2 completely

If Qt removes QFTP, could Qt provide a "scp" implementation? Maybe regardless 
of QFTP, scp would still be a "Good Thing(tm)".
Ideally, this would be transparently supported in QUrls too: image.source = 
"scp://server/file.png"
I can't seem to find a consolidated list of url schemes that Qt supports? 
QNAM::supportedSchemes gives: ("ftp", "file", "qrc", "http", "https", "data")



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

Re: [Development] QML 3 and JavaScript

[Jason H]

If not _javascript_, then what? Python? This is the first I've heard of this. Just wondering what it is if not _javascript_?

 

 

Sent: Monday, November 11, 2019 at 3:10 AM
From: "Dmitriy Purgin" 
To: "Qt development mailing list" 
Subject: [Development] QML 3 and _javascript_



Hi all,

 

as we learned at the recent Qt World Summit in Berlin, we're getting QML 3 with Qt 6. There are some cool features and changes to improve the clarity and the performance of the QML part but there is one thing that bothers me: the optionality of _javascript_.

 

What I didn't quite get is whether _javascript_ becomes optional in QML 2 already and will be disabled in QML 3, or will it be optional in QML 3 only, and QML 2 remains as it is now?

 

As for QML 2, there is a lot of _javascript_ code in the existing codebase. Just look at Sailfish OS (actively developed) or Ubuntu Phone, there are tons of logic implemented in QML/_javascript_. I understand that UI should be separated from the logic but in the real world, you can't completely enforce this that unless it is technically impossible. And I'm afraid if it becomes impossible with QML 3, this will be considered a step back by many Qt users.

 

Our company has multiple customer projects where _javascript_ is actively used to implement parts of the view logic. One of the projects is a domain-specific framework where we do the framework part in C++, and the customer implements almost all of the logic themselves solely in QML.

 

I'm sure some parts of the codebase can be rewritten to be declarative-only and work exclusively through bindings but there is another thing: there are QML components that *require* imperative code to work with them: the QML WebSocket type [1], sometimes even Animation [2] or Timer [3]. And there are also signal handlers that can execute arbitrary _javascript_ code now, and even a simple console.log() is so practical for debugging.

 

(btw how do you guys debug complex bindings and state changes? I know the QML debugger exists but in most cases it's quicker to add a console.log() to the property change and see what's wrong).

 

I understand that QML 2 is not going anywhere in Qt 6 but maintaining both QML 2 and QML 3 will be a burden for the developers of the Qt Framework, and I'm afraid QML 2 won't get much love after QML 3 is released. Just as it happened to Widgets, it will be in the "done" state.

 

Another question is: how will we control the _javascript_ engine? Will there be a compile switch to disable or enable it (like QtQuick Compiler) or will it be a runtime option to the QML engine? If it's a runtime option, there will still be the library size penalty for the _javascript_ engine that we, in fact, don't need, right?

 

[1] https://doc.qt.io/qt-5/qml-qtwebsockets-websocket.html

[2] https://doc.qt.io/qt-5/qml-qtquick-animation.html

[3] https://doc.qt.io/qt-5/qml-qtqml-timer.html

 

Thanks & cheers

Dmitriy

___ 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] iOS Force Touch *almost* working

[Jason H]

I am trying to get 3D Force Touch (finger pressure) working in my Qt App. I've 
been doing a lot of detective work and it almost works. I am going to share 
what I know to hopefully figure out what I am missing/what Qt is missing.

There seems to be some support in QTabletEvent 
(https://doc.qt.io/qt-5/qtabletevent.html) for the Apple Pencil. (I've not 
tested that)
But per this link and quote: 
https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/Adopting3DTouchOniPhone/
"In iOS 9, the UITouch class has two new properties to support custom 
implementation of 3D Touch in your app: force and maximumPossibleForce. For the 
first time on iOS devices, these properties let you detect and respond to touch 
pressure in the UIEvent objects your app receives."

And, in the Apple Pencil support change: 
https://codereview.qt-project.org/c/qt/qtbase/+/193134/9/src/plugins/platforms/ios/quiview.mm
We see the calculation I'd expect: touchPoint.pressure = uiTouch.force / 
uiTouch.maximumPossibleForce;

So I made a simple app with QQuickItem subclass and override the event() with a 
static cast to QTabletEvent
///
class TabletItem : public QQuickItem
/* QQuickItem - QuickItem does not have tabletEvent()
 * QQuickWidget - QuickItem does not have tabletEvent() */
{
Q_OBJECT

public:
TabletItem() {}

bool event(QEvent *event) override  {
QTabletEvent *tabEvent = static_cast(event);
if (tabEvent) {
if (event->type() == QEvent::TabletPress) {
qDebug() << "begin" << tabEvent->x() << 
tabEvent->y() << tabEvent->pressure();
} else if (event->type() == QEvent::TabletMove) {
qDebug() << "update" << tabEvent->x() << 
tabEvent->y() << tabEvent->pressure();
} else if (event->type() == QEvent::TabletRelease) {
qDebug() << "end" << tabEvent->x() << 
tabEvent->y() << tabEvent->pressure();
}
qDebug() << "pressure" << tabEvent->pressure();
pressureChanged(tabEvent->pressure());
return true;
}
return false;
}

signals:
void pressureChanged(double pressure);
};


However at run time, here's what I get:
pressure 5.3141e-314
pressure 5.31406e-314
pressure nan
pressure 4.2483e-314
pressure 5.3141e-314
pressure 4.2483e-314
pressure 1.00938e-320
pressure 0
pressure 4.25599e-314
pressure 5.31408e-314
pressure 0
pressure 5.31406e-314
pressure 0
pressure 5.31406e-314
pressure 4.2483e-314
pressure 5.31406e-314
pressure 4.2483e-314
pressure 5.31406e-314
pressure 4.2483e-314
pressure 0

They are all 0, near zero, or division by zero. This seems so close to actually 
working. Does anyone know what might be wrong? I think maybe it's because it's 
looking for a pencil touch specifically. It seems that supportsPressure should 
be true for all iOS devices?


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

Re: [Development] The age-old T* foo vs. T *foo

[Jason H]

> I think that this discussion is pointless.

I don't think any discussion is pointless. At the very least I learn of others' 
opinions, and on occasion, adopt them :-). Even if we don't change we at least 
never reached a threshold that we agreed to for change, which, is something. 
And not least of all, I'm always learning stuff from the Trolls.

Thank you all for the discussion.

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

Re: [Development] The age-old T* foo vs. T *foo

[Jason H]

> > And it's not "just our style".
>
> LLVM uses the same style for stars and ampersands. Who else?

That's another reason I prefer T *v; because you never see T& v, it's always T 


QRect(const QPoint , const QSize )
QRect(const QPoint , const QPoint )
boolcontains(const QPoint , bool proper = false) const
boolcontains(const QRect , bool proper = false) const
voidgetCoords(int *x1, int *y1, int *x2, int *y2) const
voidgetRect(int *x, int *y, int *width, int *height) const
int height() const

is const Point& topLeft a thing? I like the indirection modifier next to the 
variable.

But if you change * you should change &.

How many code parsers would this change (i.e. QtCreator or QDoc?) (if any)?

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

Re: [Development] The age-old T* foo vs. T *foo

[Jason H]

You're staring down the business end of a Saturn-V...
I for one, never liked
QObject* x, y;
because x is a pointer, and y is not. It seems like they should both be 
QObject*s.
Meanwhile:
QObject *x, y;
makes it very clear (clearer?) that x is a pointer and y is not.
Parenthesizing things shows just how awkward it is:
QObject(* x), (y); // really gotta reach for that star. (See what I did there!?)
vs.
QObject (*x), (y);

Of course readability was never C's strong suit.
I'd be ok with single decleartions:
QObject* x; // can't miss interpret this
QObject y;  // or this

But because you can have multiple variable declarations on a line (arguably the 
real thing to change) we're stuck with the confluence of two rules yielding 
chaos. This is an unfortunate lack of specificity in the standard.


> Sent: Thursday, October 17, 2019 at 1:11 PM
> From: zoltan.lu...@gmail.com
> To: ville.voutilai...@gmail.com
> Cc: development@qt-project.org
> Subject: Re: [Development] The age-old T* foo vs. T *foo
>
> Ooo, age old debate! ;)
>
> fingers crossed it will not end up in flame war...
>
> br,
>
> Zoltan
>
> ps: I'm with you... ;)
>
> On Thursday, October 17, 2019, Ville Voutilainen wrote:
> > Since we are about to do a major version upgrade, should be stop being
> > a special snowflake in the C++ world and start attaching pointer-stars
> > and reference-ampersands to the type instead of to the variable?
> >
> > As a quick example of how our current style is just odd, consider
> >
> > for (auto & : oink)
> >
> > Sure, that's in accordance with our style. It looks very out of place when
> > coming back to our code after adventures in other code. Quick reading
> > of it tends to suggest that it's a by-value thing since quick eyes see
> > auto without any decorations.
> >
> > I don't expect the transition, should we agree to have it, to be easy
> > for people accustomed to the Qt style. I also don't have any sort of numbers
> > about whether our style is used elsewhere. In contrast, people with lots
> > of exposure to non-Qt style tend to have to fight ours, it just doesn't come
> > naturally.
> > ___
> > 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] Property bindings in Qt 6

[Jason H]

> Also the implicit size of longish texts is usually irrelevant as in most
> situations the layout needs a height-for-width value. IIRC Qt/Quick does
> not even has a concept for how to deal with this type of constraints.

There is fontSizeMode: Text.Fit, .HorizontalFit and .VerticalFit. Horizontal 
fit is what you want in that situation. But the whole implementation is lacking 
because you can't actually ask the Text what size it used to render so that 
other text items on the screen can be the same size.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Property bindings in Qt 6

[Jason H]

> I’m all for a more declarative coding style also in C++.
> I’m wondering if we are re-inventing part of Reactive Programing a la 
> ReactiveX with QProperty, though?
> 
> The above looks similar to (sodium-cxx):
> 
> cell_sink surname("John");
> cell_sink lastname("Smith”);
> cell fullname = surname.lift(
> lastname, [](QString s, QString l) { return s + " " + l; });
> 
> qDebug() << fullname.sample();
> surname.send("Emma");
> qDebug() << fullname.sample();
> 
> or (RxJS):
> 
> var surname = new BehaviorSubject("John");
> var lastname = new BehaviorSubject("Smith");
> var fullname = new BehaviorSubject();
> r.combineLatest(surname, lastname).pipe(map(([s, l]) => { return s + " " 
> + l; })).subscribe(fullname);
> 
> console.log(fullname.getValue());
> surname.next("Emma”);
> console.log(fullname.getValue());
> 
> What is the relation of QProperty to Reactive Programing, in which ways can 
> we orient QProperty on what is done there, or learn from insights in that 
> field?

> Using "fullname.listen([](QString s) { qDebug() << s; });" (or 
> "fullname.subscribe(s => console.log(s));”) instead of the explicit logging 
> in the example above
> will print “John Smith”, whereas using change event listeners always requires 
> special handling of the initial value.

I would (naively) think that this would be done by creating a 
default-constructed value, then setting it? 

So I've used knockout and observables, and at the same time used Qt, and I 
always preferred QML over the bindings with that framework.

I'm wondering (out loud) if we aren't kinda talking about a opposite of QGadget 
for our classes - one where it can just emit a changed() event for applicable 
setters. I'm not sure how much of moc would have to be brought in - obviously 
we wouldn't want it on every class...?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Property bindings in Qt 6

[Jason H]

> Sent: Thursday, September 26, 2019 at 11:44 AM
> From: "Simon Hausmann" 
> To: "Mitch Curtis" 
> Cc: "development@qt-project.org" 
> Subject: Re: [Development] Property bindings in Qt 6
>
> Hi,
> 
> Yeah, custom setters are required.
> 
> One option would be to say that such properties are implemented using the 
> traditional property system altogether — bridging will be necessary anyway.
> 
> Another option would be to implement what you described, perhaps in a more 
> convenient way though.
> 
> Simon


It looks pretty cool so far. Forgive me as I don't know the internals of QML as 
well as I should, but what about if you could set a std::function lambda as a 
custom setter, and if set that code runs? Or something similar?

QProperty firstname("John" /* to be set with custom setter*/, /* 
custom setter*/ [&]{ 
value=md5sum(value); emit valueChanged(value) }
);

Or set it as a member function later, but that would be messy unless you had a 
subclass to always do it. 

Feel free to ignore any or all of this, just thinking out-loud.



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

Re: [Development] i.MX8 embedded Linux support

[Jason H]

 

Bummer that the software stack says GNOME. 

https://developer.puri.sm/Librem5/Software_Reference.html#software-reference

 

If I were Qt (I'm not) I'd look at preparing my own software stack... Who ever got the Nokia N9 (MeeGo) code? I loved that phone!

 


Sent: Wednesday, September 11, 2019 at 10:08 AM
From: "Shawn Rutledge" 
To: "Qt development mailing list" 
Subject: Re: [Development] i.MX8 embedded Linux support


 


On 11 Sep 2019, at 14:53, Zeno Endemann via Development  wrote:
 


Hi,

So unless I misunderstand something, for the i.MX8 NXP/Vivante changed their proprietary graphic stack significantly. The framebuffer and X11 driver are deprecated, only Wayland will be supported, and they have switched from the Linux framebuffer interface to (a fork of) libdrm.

I was able to run a Qt Quick application on an i.MX8M Mini using this new infrastructure, i.e. using the regular eglfs_kms platform plugin. So I am wondering if the qtbase configure script should be adapted to detect i.MX8, and for that not build eglfs_viv, eglfs_viv_wl and eglfs_kms_egldevice anymore.
  
Or more generally I'd like to ask if there is already further work or information on supporting embedded Linux on i.MX8. For example, I suppose the yocto layer needs some updates to reflect all this.




This phone will use i.MX8 https://puri.sm/products/librem-5/ and I think Plasma Mobile is intended to run on it, so that may become relevant to me pretty soon since I have one on order… but I didn’t investigate the software stack much yet.  Early dev boards had an i.MX6: https://dot.kde.org/2017/09/14/plasma-mobile-and-purisms-librem-5-free-smartphone https://puri.sm/posts/librem5-progress-report-9/ and were using etnaviv with it.  I think they still are using etnaviv.  https://www.omgubuntu.co.uk/2019/07/purism-librem-5-specs-confirmed
___ 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] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Jason H]

> > Suggestions:
> > pack, wad (another indirect Doom reference), bale, herd, doss, 
> > transfigure (probably too long)
> 
> I cannot resist to suggest QTransmogrifier  [1]
> Seriously, QBind is akin to GUI data binding and SQL parameter binding but 
> more specialized so I would just pick a more descriptive name. Also, since it 
> is a generic function class (not a functor), I would keep the verb Bind in 
> it. And since it addresses only values (object graphs must be somehow encoded 
> before they can be 'bound'), I suggest:
> - QValueBind (= QBind, the generic function class with bind(QValue&& v, T t) 
> overloads)
> - using QValue = Val as the start point of the fluent interface 
> allowing to describe any T 'value' in a generic way
> 
> I am also not comfortable with 'Cursor' (a non-owning unique pointer used to 
> bypass illegal or useless calls to the fluent interface) which conflicts with 
> the usual definition of SQL cursors.

You know, I was really tempted to suggest Transmogrifier but thought I would be 
the only one. I really do think it's a great name! Just a little too long. That 
said, it is an awesome name and very unique can't can't be mistaken for being 
anything else. 

However "bindvalue" (the transposition of [value, bind]) is already a thing. 
https://doc.qt.io/qt-5/qsqlquery.html#bindValue , Which I would like to avoid 
because there could be serialization to SQL..


Thought of another one, "flow"






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

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Jason H]

> My only remaining comment is QBind is rather ambiguous.
> We already have "bind" used as for SQL parameters. Bind is also used for IP 
> ports, Boost uses "bind" for connections. "Data binding" is another thing as 
> well usually to bind data to UI elements.
>
> Could it be called something else?

I realized that I broke my own rule of criticizing something without suggesting 
a replacement. I don't have anything that jumps out, but in python, the struct 
module has pack() which us just as long and not used (to my knowledge)

Suggestions:
pack
wad (another indirect Doom reference)
bale
herd
doss
transfigure (probably too long)

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

Re: [Development] Proposal for an efficient and robust (de)serialization mechanism working with Qt-supported data

[Jason H]

My only remaining comment is QBind is rather ambiguous.
We already have "bind" used as for SQL parameters. Bind is also used for IP 
ports, Boost uses "bind" for connections. "Data binding" is another thing as 
well usually to bind data to UI elements.

Could it be called something else?



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

Re: [Development] Technical vision for Qt for Python

[Jason H]

> > Can Qt set a "no private destructor!" rule?
>
> No.
>
> Private destructors have a purpose.

Would a workable re-wording be "always provide a public means of destruction"?

To be clear, I am not sure what the actual issue is, why it's private, or why 
shiboken can't handle it. In the immediate case PyQt provides the class so 
there seems to be some way around the issue...

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

Re: [Development] Technical vision for Qt for Python

[Jason H]

Thanks Cristián! If you thought I was suggesting it was done, I was not. I was 
just stating the facts as they appear at the current time feedback is being 
given. :-)  I am encouraged at PySide continuing development!

I hope that the private destructor issue is avoided for all future classes. I 
don't know how Qt can enforce that though, but Qt6 provides a great opportunity 
to make the API change. Can Qt set a "no private destructor!" rule?

About the event loop, 1 official solution is preferred over 2 contrib 
solutions. ;-) Just like with my choosing to use PySide then finding classes I 
needed were not supported, I will always chose wrong the first time! LOL.

The Jupyter notebook suggestion really is a minor issue AFAIAC, it's where Qt 
could really shine and pick up some users. (Interactive Qt+Jupyter notebooks? 
Amazing!) But it in no way factors into my day-to-day.

When those dev changes land in a release I'll take a look again, or if I get 
something that doesn't require them, I'll see about giving it a go.

The only remaining concerns I have are about QtCreator's integration. The 
.pyproject format is extremely limited. Proper python project packaging, FTW. 
(Say that 4 times fast!) I have python purists that I work with that I have to 
appease (and they use the asyncio event loop too!)

In my day-to-day I don't really care that it is in C++. But I care that I can 
do what I set out to do. That's my benchmark. That's got me in C++. But I'm 
also eagerly awaiting for the time I can interop with my python coworkers!



> Sent: Monday, August 19, 2019 at 10:36 AM
> From: "Cristián Maureira-Fredes" 
> To: "development@qt-project.org" 
> Subject: Re: [Development] Technical vision for Qt for Python
>
> Hello Jason,
> 
> I will comment inline.
> 
> On 8/19/19 3:52 PM, Jason H wrote:
> > I tried PySide 2, and was extremely disappointed that not all the classes 
> > are supported. What's worse it PyQt supports the classes that are not 
> > supported. Having that kind of errata is devastating to the confidence in a 
> > project. Qt6/PySide6 must have parity from day 1.
> 
> This is true, we still have missing bindings,
> but you skipped the good part of the issue you had:
> 
> - You reported a couple of missing classes,
> - We verify that's specific case, and we discover it was due to Private 
> destructor not supported by our binding generator.
> - This led to start fixing this issues on the Qt Multimedia module,
> that ended app on PYSIDE-1041 being related to QTBUG-74422 which was
> merged on dev
> 
> So we are truly addressing all the concerns by our users.
> 
> 
> Concerning the missing bindings, we have been publicly listing them
> all, and even comparing them with PyQt5:
> https://wiki.qt.io/Qt_for_Python_Missing_Bindings
> 
> There are many things that make little sense in Python land,
> and other classes from which we don't have a use-case, or we are not
> aware of how critical for a project could be.
> 
> That's why we need your feedback.
> 
> > Next, the biggest flaw is lack of Python 3 native event loop integration. A 
> > lot of people have codebases Python 3 event loops now, PySide should be 
> > seamless from day 1.
> 
> It would be really nice to have a proper integration,
> but this is a difficult implementation, and not even PyQt5 has it 
> natively, that's why at the moment we have an open task from which
> you can find two external plugins so interact with the Python event 
> loop, asyncqt, and quamash: https://bugreports.qt.io/browse/PYSIDE-769
> 
> 
> > I also have to point out that there was a statement made by Lars to make 
> > QML [more] strongly typed. I had expected that from the beginning, that 
> > Python would be the scripting language of QML, not Javascript[0], just for 
> > this reason. Instead, V4 was developed... I would probably execute Qt6 QML 
> > as Python code, not Javascript. I've repeatedly called for QML to be a web 
> > framework, and I've routinely had that idea shot down. So why involve a web 
> > language at all[1][2]? Coincidentally, you will also get that AI stuff Lars 
> > also talked about, for free (on the Python side anyway)
> 
> I tend to think that technologies should coexist better,
> rather than choosing one or another, and since there are so many
> things being improve in the QML side, I would expect to see the
> goodies from Qt6 first to analyze how we could improve the experience
> using Python.
> We are always open to people trying new things,
> maybe somehow has some ideas of adding Python to the scene,
> or even improve the current PySide2/QML interaction.
> 
> > Jupiter concerns me. I'm wondering how well we can get Qt to integrate with 
> > Jupiter not

Re: [Development] QList for Qt 6

[Jason H]

Hey wait, I knew that at one point in time. I've been using Qt since 3.3. I 
can't keep track of all the magic under the hood. 

I just hope i was right about the rest. And some judge things based off me. I 
am violently thrown around between Qt, Python, Java, JavaScript projects. It's 
a miracle that my code works at all.

> Sent: Monday, May 20, 2019 at 7:08 PM
> From: "NIkolai Marchenko" 
> To: "Jean-Michaël Celerier" 
> Cc: "Jason H" , "Qt development mailing list" 
> , "Mutz, Marc" 
> Subject: Re: [Development] QList for Qt 6
>
> This rather nicely proves my point. Jason isn't even new to this list and
> he didn't realize the problems.
> No, community as a whole did _not _ have "years and years" to port away
> from QList
> 
> On Mon, May 20, 2019 at 6:07 PM Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
> 
> > > QList is just a linked list
> >
> > you're in for a rude awakening :-) https://doc.qt.io/qt-5/qlist.html
> >
> > On Mon, May 20, 2019 at 5:03 PM Jason H  wrote:
> >
> >>
> >> > Ok, QList as an alias for QVector takes care of the technical issues I
> >> > have with using inheritance. It doesn't address my concerns regarding
> >> > breaking QList behaviour. What purpose is served to call something QList
> >> > that is in fact a QVector? Please spell it out for me, as I don't see
> >> > it.
> >>
> >> My understanding is that QVector requires contiguous memory, consuming a
> >> giant block for all the items in the list. QList is just a linked list.
> >> QVector will fail sooner when memory fragmentation is a problem. I would
> >> expect systems with long-running processes and limited RAM (i.e. embedded,
> >> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
> >> especially when the size of each object is large. (You could always just
> >> store pointers though)
> >>
> >>
> >> ___
> >> 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] QList for Qt 6

[Jason H]

> Ok, QList as an alias for QVector takes care of the technical issues I
> have with using inheritance. It doesn't address my concerns regarding
> breaking QList behaviour. What purpose is served to call something QList
> that is in fact a QVector? Please spell it out for me, as I don't see
> it.

My understanding is that QVector requires contiguous memory, consuming a giant 
block for all the items in the list. QList is just a linked list. QVector will 
fail sooner when memory fragmentation is a problem. I would expect systems with 
long-running processes and limited RAM (i.e. embedded, a Raspberry Pi, phone, 
etc) to encounter this sooner than other systems, especially when the size of 
each object is large. (You could always just store pointers though)


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

Re: [Development] QList for Qt 6

[Jason H]

My only conern about QList/QVector is a minor one: that the api be more accomodating to cross-language people. push()/append(), size() and length/length(). 

Now that Qt is thoroughly supporting Python, and JS, and C++ , and implicit conversions, having an API that is normal for any of the languages is, I think, important. This also applies to QML models, which use size() and not length. It;s rather leaky abstraction to allow JS arrays as models, which use length, and "proper" QML models which use size. This is friction that I don't think needs to exist?

 

 

 

Sent: Monday, May 20, 2019 at 9:52 AM
From: "Lars Knoll" 
To: "Mutz, Marc" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QList for Qt 6


Hi Marc,
 

On 20 May 2019, at 14:39, Mutz, Marc via Development  wrote:
 


Hi Lars,

I'm on record for claiming QList needs to die, and I work for a company that still makes part of its living by porting Qt 3 apps to Qt 4 (and 5). So I should be celebrating if you create more potential work for KDAB, but I'm actually ok with keeping QList.

Provided it vanishes from each and every Qt API.

Whether to call it Q5List or QArrayList or continue with QList doesn't matter. Actually, I'd err on keeping QList, to minimize porting. What I want to avoid is to break user code silently. Asan is a runtime-checker, the code must actually be exercised, which is trivial for QToolBox but might be problematic if it's in, say, error handling code. And you rightfully pointed out that it's very hard for a static checker to find cases where reference stability is used. Not impossible, but hard.

I want to understand what problems you see with keeping QList as-is with deprecated implicit conversions to and from QVector, assuming all Qt API that uses QList is ported to QVector.

The way I see it:

Given:
* QList stays as-is
* No Qt API takes or returns QList anymore, but QVector
* QList implicitly converts to QVector, and vice versa
* These implicit conversions are marked as deprecated

Pros:
* Old (user) code doesn't silently change the meaning
* Old (user) code continues to work, lets users port at their own leisure
* Receiving objects can be done with auto variables for optimal performance
 or with QList for old code.
* Users passing QLists into Qt APIs enjoy the implicit conversion to QVector
 + This might be slow, but you say yourself that speed doesn't matter
   for 95% of the code and it's easier to find and fix slow code in
   the 5% than it is to find a silent reference stability breakage in
   the 95%.

Cons:
* Unported code will get penalized by the implicit conversions from and to QList
 + But using the 95/5-argument here, again: it's easier to find where the app
   got slower in the 5% than to find a bug in the 95%.

The pros far, far outweigh the cons. I'd very much like to know in which aspects inheriting QList from QVector fares better than this proposal.



 
I’m not proposing to make QList inherit QVector. Actually, I’m making it an alias to QVector. See https://codereview.qt-project.org/c/qt/qtbase/+/242692 . 

 

With that, one option could be to make the alias dependent on a compile time setting for the application code (ie. have a simple define whether we do

 

using QList = QVector

 

Or 

 


using QList = Qt5Support::QList

 






My fear is that QList : QVector will lead to some of Qt's APIs continuing to use QList, which would lock Qt into QList for another major release cycle and only postpone the inevitable QList removal.



 

No, of course we need to get rid of all references to QList in our APIs.
 



C++11 gave us the tools to make this transition now much smoother than it could have been done in Qt 4->5. Inheriting QList from QVector is both technically wrong (value classes inheriting each other) and just serves to confuse users (is it still ok to use QList? Is it now suddenly ok after it wasn't in Qt 5? What do to if I target both Qt 5 and Qt 6?).



 
See above. The change where they inherit from each other is an intermediate change, not the final result.

 

Cheers,

Lars

 





Touché on the QStringView reference :)

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



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

Re: [Development] A deployment tool for Linux

[Jason H]

> 11.04.2019, 04:05, "Richard Weickelt" :
> > On 10.04.2019 23:21, Marco Bubke wrote:
> >>  Sounds you want flatpak. ;-)
> >
> > All those run-time extracted application container formats might be nice
> > solutions for GUI applications which is apparently the main target of Qt.
> > But my observation is that they perform rather poorly when being used for
> > command line applications or a combination of both.
> 
> You can use static linking for command-line applications, or use AppImage
> where artifact is just a single executable file which could be put anywhere 
> in $PATH

Doesn't static linking require a static Qt?

Last time I messed with this was 1 years ago on a windows system which was 
pretty easy. I would use depends.exe and make sure the dependencies were next 
to the binary. Since then I've been mainly doing mobile apps which have their 
own packages. But once in a while I'll whip up a program for automation. I've 
lucked out that these systems are large and not Pis with limited storage, so I 
can put all of Qt on and compile it there. That's easiest. It was easier to 
just install Qt and build it on that system.  

Minimally I would like something to produce an image suitable for and "/opt" 
install. That is to me to be a structure like:
project/
+ bin/
+ + a.out
+ libs/
+ + [list of libs, Qt | system]
+ etc/

Given a generic binary, I would assume there's a generic tool to do this 
already? Is there a [what is the] Qt value-add?

I tried linuxdeployqt and it made my head spin. It stats out: "You'll need to 
provide the basic structure of an AppDir which should look something like 
this:". To which I say "No" this should be done for me. QMake knows all the 
things. There is no value-add in a human doing it. It continues "Where your 
desktop file would look something like:" Again, no, generate one for me. If I 
need to adjust things, I'll do that after they are generated. Of this, the 
application icon is the only thing I might want to modify. The time to do all 
that setup is greater than installing Qt, checking out the source and building.










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

Re: [Development] Adding more Datetime classes to Qt

[Jason H]

I whole heartedly disagree. Everything should always be stored in UTC. Not GMT.

 

Why? Because dates, and particularly times, are not that simple. UTC does not observe Daylight Saving time, but local timezones sometimes do, and those saving time zones do not all kick in at the same time. 

I think these classes would just encourage timezone anti-patterns.

 

 

 

Sent: Tuesday, April 09, 2019 at 8:11 AM
From: "Pouya Shahinfar" 
To: development@qt-project.org
Subject: [Development] Adding more Datetime classes to Qt





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] QML preprocessor

[Jason H]

> On 18/03/19 12:11, Pierre-Yves Siret wrote:
> > This can be done with QQmlFileSelector :
> > 
> >     QQmlApplicationEngine engine;
> >     QQmlFileSelector* qmlFileSelector = QQmlFileSelector::get();
> > 
> > #if QT_VERSION >= QT_VERSION_CHECK(5, 12, 0)
> >     qmlFileSelector->setExtraSelectors({"5.12"});
> > #endif
> > 
> >     engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
> > 
> > This will load qrc:/+5.12/main.qml (if there's one) instead of
> > qrc:/main.qml when the Qt version is >= 5.12.
> 
> Of all suggestions, this is probably the one having the least
> performance impact and greater readability. It still doesn't solve the
> code duplication issue (Samuel's does, but with a greater runtime
> impact), though. :-(
> 
> Anyway, thanks all!
> 
> (I'm still looking forward to see this issue addressed at the QML
> language level, though :-) )

I don't know why you can't just use a C/C++ preprocessor to generate the qml?
For Clang,   -E : Only run the preprocessor

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

Re: [Development] Website Issues

[Jason H]

I, in US/East Coast, am not.
 

Sent: Friday, March 15, 2019 at 9:51 AM
From: "Pendleton, Corey" 
To: "development@qt-project.org" 
Subject: [Development] Website Issues




To Whom It May Concern,

 

I am having https errors accessing both forum.qt.io and wiki.qt.io.

 

Thanks!
Corey

 


CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
___ 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

[Jason H]

The verbiage in the example is wrong:

 code_that_might_through_exceptions();

should be:

 code_that_might_throw_exceptions();

Took me a moment to figure out just what it meant. 


> Sent: Thursday, March 07, 2019 at 12:09 PM
> From: "Tor Arne Vestbø" 
> To: "Volker Hilsheimer" 
> Cc: "Qt development mailing list" 
> Subject: Re: [Development] Go's "defer" statement for C++/Qt
>
> https://doc.qt.io/qt-5/qscopeguard.html 
> 
> Tor Arne 
> 
> > On 7 Mar 2019, at 18:01, 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
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] New API design for file system operations

[Jason H]

> Sent: Tuesday, February 12, 2019 at 9:54 AM
> From: "Volker Hilsheimer" 
> To: "Jason H" 
> Cc: "Vitaly Fanaskov" , "development@qt-project.org" 
> 
> Subject: Re: [Development] New API design for file system operations
>
> 
> 
> > On 11 Feb 2019, at 19:16, Jason H  wrote:
> > 
> > 
> >> The question for me is: why would an application (that is not a file 
> >> explorer) want to do any of this? I honestly don’t see the use case.
> > 
> > When I filed the bug against KIO not having a "trash" feature it was 
> > because I was working in digikam (photo library) in KDE - this is MANY 
> > years ago (2004,  https://bugs.kde.org/show_bug.cgi?id=88615 ). Anyway, I 
> > deleted the library in the application, and ALL my photos went *poof*. I 
> > looked in the trash... Nothing. I expected my user-generated data to to be 
> > recoverable in the trash. 
> > 
> > So the use case, is when the user has generated data that the application 
> > does not own, where it should not assume ownership of said data and the 
> > user has requested it be removed. 
> > OR 
> > The user has requested the data be removed but not destroyed, so in a way 
> > that the data can be potentially recovered. 
> 
> But that’s a usecase for a “move-stuff-to-the-trash” function, right? As in 
> “remove those files, but do not delete them permanently”.
> 
> The user would expect to be able to see what’s in the trash, and to restore 
> stuff from there, using the standard desktop trash-can metaphore, not some 
> application specific shenanigans.
> 
> You would want the application perhaps to be aware of the user restoring data 
> from the trash, ie adding the files back into the workspace, or the photos 
> back into the library. In that sense, "restoring from trash" is just the same 
> as “restoring from backup” or “downloading from the internet”, I suppose.


If there is a restore function, I would only expect it to exist as an "undo" 
operation. Like if a cat walked on the keyboard pressing the delete key. 
Although it probably doesn't really matter to Qt. The move to trash and undo 
pair of operations should both be supported.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Looking for Feedback QDeferred

[Jason H]

What are the costs of thread start-up?

Why is this not a QRunnable (In my experience Runnables start faster than treads - though it may be anecdotal)

How does it interact with thread pools?

 

I cringe when I see Promises in 2019. Node/JS uses them because they (until recently) only had one thread they could run on. We don't have this limitation in Qt. I'm on board with easy lambda threading. I'm not on board with more Promises.  http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

 

 

 

 

Sent: Monday, February 11, 2019 at 6:49 AM
From: "Juan Gonzalez Burgos" 
To: development@qt-project.org
Subject: [Development] Looking for Feedback QDeferred



Hi guys,
 

Sorry to bother you with yet another promise/deferred library for Qt. I am looking for feedback.

https://github.com/juangburgos/QDeferred

 

Thanks.


___ 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] New API design for file system operations

[Jason H]

> The question for me is: why would an application (that is not a file 
> explorer) want to do any of this? I honestly don’t see the use case.

When I filed the bug against KIO not having a "trash" feature it was because I 
was working in digikam (photo library) in KDE - this is MANY years ago (2004,  
https://bugs.kde.org/show_bug.cgi?id=88615 ). Anyway, I deleted the library in 
the application, and ALL my photos went *poof*. I looked in the trash... 
Nothing. I expected my user-generated data to to be recoverable in the trash. 

So the use case, is when the user has generated data that the application does 
not own, where it should not assume ownership of said data and the user has 
requested it be removed. 
OR 
The user has requested the data be removed but not destroyed, so in a way that 
the data can be potentially recovered. 

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

Re: [Development] Enum classes in signals?

[Jason H]

> Sent: Tuesday, February 05, 2019 at 11:58 AM
> From: "Thiago Macieira" 
> To: development@qt-project.org
> Subject: Re: [Development] Enum classes in signals?
>
> On Tuesday, 5 February 2019 08:43:03 PST Jason H wrote:
> > While I prefer enum classes myself, I just had to connect to a signal with
> > one in it. This was unfortunate as I was attempting to use the old
> > connection syntax SIGNAL()/SLOT() macros. I was not aware that the old
> > syntax were being deprecated? What is the policy on this?
> 
> They're not exactly deprecated, but they're older than the new syntax and 
> they 
> don't check at compile time that the connection can succeed.
> 
> > Should signals not use enum classes?
> 
> Unknown. I don't see why they shouldn't, but you haven't shared any error 
> messages, so I can't tell.
> 
> > Should Qt not use enum classes?
> 
> Enum classes are fine in Qt.
> 
> > Should Qt support old connection syntax? Where/when?
> 
> Yes. It should be supported for the millions of lines of code that existed 
> before the new syntax was introduced in 2012.
> 
> > Should all new connections be in the modern syntax?
> 
> Yes, if you can.

Great thanks for clarifying that. I use Qt principals in my own application 
code (they tend to be the best - well reasoned at least). So if there was 
something that I hadn't considered, I'd want to take that into account and 
avoid any gotchas down the road. I just started using enum classes myself.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Enum classes in signals?

[Jason H]

While I prefer enum classes myself, I just had to connect to a signal with one 
in it. This was unfortunate as I was attempting to use the old connection 
syntax SIGNAL()/SLOT() macros. I was not aware that the old syntax were being 
deprecated? What is the policy on this?

Should signals not use enum classes?
Should Qt not use enum classes?
Should Qt support old connection syntax? Where/when?
Should all new connections be in the modern syntax?




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

Re: [Development] Qt6: Adding UTF-8 storage support to QString

[Jason H]

> By all means, let's make sure the internals are efficient for the more
> common languages and scripts; but it's way past time to start doing
> Unicode properly, so that all cultures are well-served by default, when
> the software folk are using is built on Qt,

I don't think anyone knows what "properly" is. But the more I think about it, 
the more I like the idea I expressed as a list of sequences of various 
character sizes. I think it is a good balance between space and efficiency. To 
recap that:
A class that stores a list of list of same-width characters. For the most naive 
case the list is 1 list long and contains only 8bit characters. This performs 
identically to QByteArray. Non-ASCII languages requiring 16-bit storage are as 
QStrings are now. Then, in the more complicated scenarios, it breaks out 8-bit 
segments and 16-bit segments and makes them appear contiguous. (Emoji in ASCII 
text). Of course there could be functions to collapse it all to the uniform 
largest used width (maximize()) or break it apart to minimize() space (for very 
long 8-bit strings with occasional characters), and there can even be a 
bestFit() heuristic. And as always you can get it serialized as UTF-8 or 16... 
All the above also extends to 32-bit as well. I think this blends handles the 
average case very well (all characters of same width) and has reasonable cost 
for occasional exotic characters. 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt6: Adding UTF-8 storage support to QString

[Jason H]

> From: "Arnaud Clère" 
> > And I don't want to add QUtf8String until SG16's char8_t gets settled. 
> > It'll probably be settled by C++20, which means we can probably work on 
> > this during Qt 6 lifetime, possibly even 6.1 or 6.2.
> 
> It makes sense to avoid future incompatibilities with the standard but 
> fortunately Qt sometimes chooses to solve real problems ahead in time  ;-)

Well C++20 is really how many months away? Qt6 won't be released until when? It 
seems like both of these might land at the same time, except that the "by 
C++20" is (AFAICT) speculation. Uptake will also be slow. But by Qt being first 
we can get experience with the nature of the solution which might help inform 
the standard, or vice-versa. There's a risk we do something that conflicts with 
the standard in a useful way that people like, then we have fragmentation. 

Far smarter people than I have worked on this, so again burn this with fire, 
but my current thinking is: 
I think the problem is how all these things are implemented - they are 
basically escape codes, so it's impossible to say where thee current character 
ends and the next begins. This of course kills speed, but that's what we get 
for having more than one language on the planet plus emojis. It seems to me 
that the only real solution to keep it all fast is to progressively upgrade 
from bytes to the widest character and use that. This will have a scanning cost 
when it enters the address space if not denoted to the compiler or by the load 
method.  If memory is a concern, the only alternative I see is to create a 
complex string: "strings" are now arrays of character arrays of uniform width, 
and hope that it is only ever one:
"Ground control to Major Tom" - single sequence of 8 bit chars, len 27 size 27
"niños." encoded as 3 "strings", total length 6, size 7:
+ "ni" - "ni" (8 bit char sequence of 2 char)
+ "ñ" -  0001 (UTF16 16 bit char sequence of 1 char)
+ "os." - "o" (8 bit char sequence of 3 char)

In the old days BASIC, I forget which one, but I'm remembering a Dr Dobbs or 
some other print medium (over 20 years ago), I read BASIC stores strings as a 
linked list of characters, I'm adapting that idea. There are many tradeoffs, 
but until we're ok with 32 bit characters, there will be tradeoffs on a 
multi-language planet. 

I just don't think escape codes should ever be stored in memory. Disk is fine. 

"Better to remain silent and be thought a fool than to speak and to remove all 
doubt." - (Disputed). I think I may have broken that rule here. "Please, be 
gentle." - Peter Venkman

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

Re: [Development] Qt6: Adding UTF-8 storage support to QString

[Jason H]

> Sent: Monday, January 21, 2019 at 9:51 AM
> From: "Arnaud Clère" 
> To: "Allan Sandfeld Jensen" , "development@qt-project.org" 
> 
> Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString
>
> > -Original Message-
> > From: Allan Sandfeld Jensen  
> >
> > On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote:
> > > Any chance of having UTF-8 storage support for QString?
> > > 
> > Use QByteArray when you can.
> 
> I think a QUtf8String class derived from QByteArray would help a lot making 
> this happen in the real world!
> 1. It would be found more easily by users in need of a utf8 encoded dynamic 
> string
> 2. It would allow making the encoding explicit (QString or QUtf8String or 
> QLatin1String) in newer Qt APIs or user-defined ones, and even totally safe 
> if disabling const char * casts is possible
> 3. It would allow adding QString-like APIs (like setNum(), simplified(), 
> etc.) over the time without cluttering QByteArray
> 
> Moreover, I have a specific use-case where QByteArray args are used as binary 
> data (say CBOR) and a specific Utf8String is useful to handle utf8 encoded 
> args without always encoding/decoding to utf16.
> I might not be the only one...


Feel free to burn this suggestion with fire, but what about:

typedef QSymbolSequence QLatin1String;
typedef QSymbolSequence QByteArray;
typedef QSymbolSequence QByteArray;
typedef QSymbolSequence QString;

So they can have the same API? It really seems to me that the issue is storage, 
not that they need a different API to operate on the storage. 


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

Re: [Development] Qt6: Adding UTF-8 storage support to QString

[Jason H]

> Sent: Tuesday, January 15, 2019 at 4:44 PM
> From: "Allan Sandfeld Jensen" 
> To: development@qt-project.org
> Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString
>
> On Dienstag, 15. Januar 2019 19:43:57 CET 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?
> > 
> Use QByteArray when you can.

And *I* do. (Not the OP). But I would love a QByteArray that matches QString's 
API. I wrote this email, then was going about gathering evidence to make my 
case about why QByteArray was inadequate. It seems many of my complaints with 
using QByteArray over the years have been addressed unbeknownst to me, though 
one glaring omission remains:

- QByteArray lacks QString's arg() support. The QString("%1").arg(X) 
combination is pretty readable, and reliable, and maintainable. 

I don't know how the average Qt user stacks up, but I only use QStrings in UIs 
(because I have to), the rest (which is a lot) is all QByteArray. When I'm 
using QString not in a UI, it's normally ending with toUtf8().

I don't really care utf8 vs 16, vs whatever (slight bias for utf8 as it looks 
better in hex editors), I just hate that I have to deal with character width 
issue this concretely by having to code against one of two very similar but not 
equivalent classes. 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QAbstractVideoFilter, the pipeline and QImage

[Jason H]

> From: "Val Doroshchuk" 

> Hi,
> thanks for explanation.
 
> Does it sound good to try to create a data storage, where converted data is 
> located per real frame, (which will be created on first filter).
> Followed filters will use QVideoFrames with custom 
> QAbstractVideoBuffer::UserHandle and id from the storage?
 
I don't know about the QAbstractVideoBuffer::UserHandle method. That's why I'm 
having this conversation. I don't know what the best answer is. I was playing 
with the idea yesterday of just using the metadata with a 
QString("%1_%2x%3").arg(cvMatType,width,height) key and checking to see if that 
exists at whatever pipeline stage needs it. This way, I can just return the 
frame, skip the conversion back and pay for only the mats I need.

Unless there's a better way? One thing I wondered is since it's a runnable, is 
this happening on multiple threads (or cores? - if available) Are there 
multiple frames "in flight"? 


----

From: Jason H 
Sent: Wednesday, January 9, 2019 4:28:01 PM
To: Val Doroshchuk
Cc: Qt development mailing list
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage
 

>> I really want a QAbstractVideoBuffer *QVideoFrame::buffer() which I can then 
>>cast to my custom type.
 
> Sorry, but just a note.
> QAbstractVideoBuffer is an abstraction that was supposed to be an impl of 
> accessing to data, nothing more.
 
 
>> I'm trying to implement a QAbstractVideo buffer that uses cv::Mat
 
> Why you need to use cv::Mat there? 
> If needed, you could create QAbstractVideoBuffer::UserHandle and return an id 
> to access to cv's data without downloading/uploading within mapping.

Because the video frame needs to be converted to a format that OpenCV 
understands. Various OpenCV functions need particular pixel representation 
types: grayscale 8 bit, floating point, float or int array if 3,4 color 
channels. I basically want to do this conversion once, then pass that on to 
later stages in the pipeline. In general the OpenCV functions don't modify the 
frame itself, but produce information about the frame. The filters I have emit 
the results of the computation in some cases (a list of line segments for 
houghLines) while others, like sobel, create a new image. Depending on the 
pipeline, I might want multiple OpenCV representations. I generally use 
QPainter though, to draw on the frame after having gotten the information.
 
>>  I think there should be class(es) that converts a QVideoFrame to a cv::Mat, 
>>and one that converts from cv::Mat to QVideoFrame: filters: [toMat, blur, 
>>sobel, houghLines, toVideoFrame]
 
> Is it performance wise operation to convert QVideoFrame to cv::Mat and back 
> in this case?
> (qt_imageFromVideoFrame(QVideoFrame) can convert to QImage, and should be 
> relatively fast)
 
Well, I generally don't need to convert back, though this is possible. There 
are OpenCV functions that produce an image. I'm fine with using OpenCV to 
extract info and keep the drawing in Qt (QPainter). So there's no need for me 
to convert it back. Though I will say that the OpenCV functions are _very_ 
fast, supporting multiple acceleration methods (uses Eigen). I wrote my own 
implementations of some of them purely in Qt, and the OpenCV stuff puts them to 
shame. Image saving is the only thing where Qt is faster (IMHO, empirical 
evidence not yet collected).  One other technique I use is to scale the image 
down (say by 50% or 25%) which quarters or 16ths the time respectively, if I 
don't need pixel perfect accuracy.

I would expect some way to attach cv::Mats to a frame. That way I could look 
through what mats are available, and only pay a penalty when I have to. If a 
previous filter operation already produced a 8bit gray scale, I would just use 
that, and if it doesn't exist create it. Later filters could then use it, or 
create their own.

if (!frame.containsMat(CV_8U)) frame.insertMat(CV_8U, frame.toMat(CV_8U));

cv::Mat mat =  frame.mat(CV_8U)
...
frame.insertMat(CV_8U, mat)//if I need to save (like for sobel)

WRT the "Big Picture": I'm trying to a point where I can in QML, have filters, 
which are OpenCV functions programmed to a dynamic filter pipeline.  My 
approach is working but the cost of all the conversions is very expensive. 
We're talking 50msec per frame, which gets me down into 1 filter is 15pfs 
territory, 2 filters is 5 fps, etc. My source is 25-29.97FPS. The way I've been 
doing this is copying the QVideoFrame to QImage, then using that for a Mat.If I 
can just pay the conversion penalty once, I think that would go a long way in 
helping.

Maybe what I need to do is to make the cv::Map a QVariant and store it as 
metadata and use QVideoFrame availableMetaData()?


 
--------

From: Develo

Re: [Development] QAbstractVideoFilter, the pipeline and QImage

[Jason H]

>> I really want a QAbstractVideoBuffer *QVideoFrame::buffer() which I can then 
>>cast to my custom type.
 
> Sorry, but just a note.
> QAbstractVideoBuffer is an abstraction that was supposed to be an impl of 
> accessing to data, nothing more.
 
 
>> I'm trying to implement a QAbstractVideo buffer that uses cv::Mat
 
> Why you need to use cv::Mat there? 
> If needed, you could create QAbstractVideoBuffer::UserHandle and return an id 
> to access to cv's data without downloading/uploading within mapping.

Because the video frame needs to be converted to a format that OpenCV 
understands. Various OpenCV functions need particular pixel representation 
types: grayscale 8 bit, floating point, float or int array if 3,4 color 
channels. I basically want to do this conversion once, then pass that on to 
later stages in the pipeline. In general the OpenCV functions don't modify the 
frame itself, but produce information about the frame. The filters I have emit 
the results of the computation in some cases (a list of line segments for 
houghLines) while others, like sobel, create a new image. Depending on the 
pipeline, I might want multiple OpenCV representations. I generally use 
QPainter though, to draw on the frame after having gotten the information. 
 
>>  I think there should be class(es) that converts a QVideoFrame to a cv::Mat, 
>>and one that converts from cv::Mat to QVideoFrame: filters: [toMat, blur, 
>>sobel, houghLines, toVideoFrame]
 
> Is it performance wise operation to convert QVideoFrame to cv::Mat and back 
> in this case?
> (qt_imageFromVideoFrame(QVideoFrame) can convert to QImage, and should be 
> relatively fast)
 
Well, I generally don't need to convert back, though this is possible. There 
are OpenCV functions that produce an image. I'm fine with using OpenCV to 
extract info and keep the drawing in Qt (QPainter). So there's no need for me 
to convert it back. Though I will say that the OpenCV functions are _very_ 
fast, supporting multiple acceleration methods (uses Eigen). I wrote my own 
implementations of some of them purely in Qt, and the OpenCV stuff puts them to 
shame. Image saving is the only thing where Qt is faster (IMHO, empirical 
evidence not yet collected).  One other technique I use is to scale the image 
down (say by 50% or 25%) which quarters or 16ths the time respectively, if I 
don't need pixel perfect accuracy.

I would expect some way to attach cv::Mats to a frame. That way I could look 
through what mats are available, and only pay a penalty when I have to. If a 
previous filter operation already produced a 8bit gray scale, I would just use 
that, and if it doesn't exist create it. Later filters could then use it, or 
create their own.

if (!frame.containsMat(CV_8U)) frame.insertMat(CV_8U, frame.toMat(CV_8U));

cv::Mat mat =  frame.mat(CV_8U)
...
frame.insertMat(CV_8U, mat)//if I need to save (like for sobel)

WRT the "Big Picture": I'm trying to a point where I can in QML, have filters, 
which are OpenCV functions programmed to a dynamic filter pipeline.  My 
approach is working but the cost of all the conversions is very expensive. 
We're talking 50msec per frame, which gets me down into 1 filter is 15pfs 
territory, 2 filters is 5 fps, etc. My source is 25-29.97FPS. The way I've been 
doing this is copying the QVideoFrame to QImage, then using that for a Mat.If I 
can just pay the conversion penalty once, I think that would go a long way in 
helping. 

Maybe what I need to do is to make the cv::Map a QVariant and store it as 
metadata and use QVideoFrame availableMetaData()? 


 
--------

From: Development  on behalf of Jason H 

Sent: Tuesday, January 8, 2019 6:33:14 PM
To: Jason H
Cc: Qt development mailing list
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage
 

I'm still plugging away at this. My life is being made difficult by not being 
able to get a pointer to the buffer. For OpenCV, some routines want a color 
image, others want an 8 bit gray scale. It would be really great if I could use 
both of these at the same time.
 
For example, take the color video frame, make it gray scale, then run 
houghLlines on it, using that information to highlight the lines in the color 
frame. I tried to do this with a simple QMap but there's no way I 
can access it, because there's no QAbstractBuffer *QVideoFrame::buffer(). I 
might be able to hack it in using QAbstractPlanarVideoBuffer, but that feels 
very hacky (plane 0= color, plane2=B) in addition sometimes the type needs to 
change from quint8s to floats.
 
I feel like I'm really off in the weeds here and would like someone to chime 
in, if I'm completely missing something or if these are shortcomings in the Qt 
API?
 
 

Sent: Monday, January 07, 2019 at 5:22 PM
From: "Jason H" 
To: "Jason H" 
Cc: "Pierre-Yves Siret" , "Qt d

Re: [Development] QAbstractVideoFilter, the pipeline and QImage

[Jason H]

I'm still plugging away at this. My life is being made difficult by not being able to get a pointer to the buffer. For OpenCV, some routines want a color image, others want an 8 bit gray scale. It would be really great if I could use both of these at the same time.

 

For example, take the color video frame, make it gray scale, then run houghLlines on it, using that information to highlight the lines in the color frame. I tried to do this with a simple QMap but there's no way I can access it, because there's no QAbstractBuffer *QVideoFrame::buffer(). I might be able to hack it in using QAbstractPlanarVideoBuffer, but that feels very hacky (plane 0= color, plane2=B) in addition sometimes the type needs to change from quint8s to floats.

 

I feel like I'm really off in the weeds here and would like someone to chime in, if I'm completely missing something or if these are shortcomings in the Qt API?

 

 

Sent: Monday, January 07, 2019 at 5:22 PM
From: "Jason H" 
To: "Jason H" 
Cc: "Pierre-Yves Siret" , "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage




I'm trying to implement a QAbstractVideo buffer that uses cv::Mat (or my own custom type, CvMatVideoBuffer or ByteArrayVideoBuffer respectively), but I'm running into a mental block with how this should work. Only map() gives pixel data, I really want a QAbstractVideoBuffer *QVideoFrame::buffer() which I can then cast to my custom type.  Generally when I'm fighting Qt in this way, I'm doing something wrong.

 

I can convert between QImage/cv::Mat with:


cv::Mat qimage_to_mat_cpy(QImage const , bool swap)
{
    return qimage_to_mat_ref(const_cast(img), swap).clone();
}


QImage mat_to_qimage_ref(cv::Mat , QImage::Format format)
{
    return QImage(mat.data, mat.cols, mat.rows, static_cast(mat.step), format);
}

cv::Mat  qimage_to_mat_ref(QImage , int format)
{
    return cv::Mat(img.height(), img.width(), format, img.bits(), img.bytesPerLine());
}



 

Is there an example of how to "properly" use Qt's video pipleline filters, frames, and buffers with OpenCV?  I think there should be class(es) that converts a QVideoFrame to a cv::Mat, and one that converts from cv::Mat to QVideoFrame:

filters: [toMat, blur, sobel, houghLines, toVideoFrame]

 

Many thanks in advance. 

 

 

Sent: Monday, January 07, 2019 at 10:57 AM
From: "Jason H" 
To: "Jason H" 
Cc: "Pierre-Yves Siret" , "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage




I have been thinking about this more, and I think we also need to convert when the pipeline switches between internal formats. This would allow standard filter tooklits to be "a thing" for Qt. 

 

For example, if my pipeline filters are written to use QImage (because scanline() and pixel()) , and someone else's use cv::Mat (OpenCV), alternating between formats is not possible in the same pipeline. I think the panacia is to be able to convert not just at the end, but for any step:

[gauss, sobel, houghLines, final] -> formats: [QVideoFrame->cv::Mat, cv::Mat, cv::Mat->QImage, QImage->QVideoFrame] where each format step is the (inputFormat -> outputFormat)

 

Just my 0.02BTC.

 

 

Sent: Wednesday, January 02, 2019 at 12:33 PM
From: "Jason H" 
To: "Pierre-Yves Siret" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage



Thanks for pointing that out. I guess that could work. It's not as elegant as what I want, where everyhing presents the same way. Now each and every filter has to have

 

if (flags & QVideoFilterRunnable::LastInChain) {

   ... generate the frame for the backend per the surfaceFormat

}


 

As there are many surfaceFormats, that if(){} block is huge, and duplicated in each filter. True, I can create a "final filter" that does this to avoid all that boilerpate code that takes the frame and converts it back to what it needs to be. But what I suggested was Qt should provide this automatically both in the filter chain. The difference is this:

 

 

VideoOutput {

   filters: [sobel, houghLines]

}

 


VideoOutput {

   filters: [sobel, houghLines, final]

}

 

Ideally that final filter checks the frame matches what it expects and only if it does not, performs a conversion.  Maybe there's a way to register a conversion from a custom type to a QVideoFrame?

Also, if the VideoOutput is not needed* the final filter need not be invoked.

 

By not needed, I mean the video output element is not visable, or it's area is 0. Sometimes, we want to provide intel about the frames, without affecting them. Currently, this is inherently syncronous, which negatively impacts frame rate.

I should be able to use two (or more) VideoOutputs, one for real-time video display and another for info-only filter pipelin

Re: [Development] QAbstractVideoFilter, the pipeline and QImage

[Jason H]

I'm trying to implement a QAbstractVideo buffer that uses cv::Mat (or my own custom type, CvMatVideoBuffer or ByteArrayVideoBuffer respectively), but I'm running into a mental block with how this should work. Only map() gives pixel data, I really want a QAbstractVideoBuffer *QVideoFrame::buffer() which I can then cast to my custom type.  Generally when I'm fighting Qt in this way, I'm doing something wrong.

 

I can convert between QImage/cv::Mat with:


cv::Mat qimage_to_mat_cpy(QImage const , bool swap)
{
    return qimage_to_mat_ref(const_cast(img), swap).clone();
}


QImage mat_to_qimage_ref(cv::Mat , QImage::Format format)
{
    return QImage(mat.data, mat.cols, mat.rows, static_cast(mat.step), format);
}

cv::Mat  qimage_to_mat_ref(QImage , int format)
{
    return cv::Mat(img.height(), img.width(), format, img.bits(), img.bytesPerLine());
}



 

Is there an example of how to "properly" use Qt's video pipleline filters, frames, and buffers with OpenCV?  I think there should be class(es) that converts a QVideoFrame to a cv::Mat, and one that converts from cv::Mat to QVideoFrame:

filters: [toMat, blur, sobel, houghLines, toVideoFrame]

 

Many thanks in advance. 

 

 

Sent: Monday, January 07, 2019 at 10:57 AM
From: "Jason H" 
To: "Jason H" 
Cc: "Pierre-Yves Siret" , "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage




I have been thinking about this more, and I think we also need to convert when the pipeline switches between internal formats. This would allow standard filter tooklits to be "a thing" for Qt. 

 

For example, if my pipeline filters are written to use QImage (because scanline() and pixel()) , and someone else's use cv::Mat (OpenCV), alternating between formats is not possible in the same pipeline. I think the panacia is to be able to convert not just at the end, but for any step:

[gauss, sobel, houghLines, final] -> formats: [QVideoFrame->cv::Mat, cv::Mat, cv::Mat->QImage, QImage->QVideoFrame] where each format step is the (inputFormat -> outputFormat)

 

Just my 0.02BTC.

 

 

Sent: Wednesday, January 02, 2019 at 12:33 PM
From: "Jason H" 
To: "Pierre-Yves Siret" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage



Thanks for pointing that out. I guess that could work. It's not as elegant as what I want, where everyhing presents the same way. Now each and every filter has to have

 

if (flags & QVideoFilterRunnable::LastInChain) {

   ... generate the frame for the backend per the surfaceFormat

}


 

As there are many surfaceFormats, that if(){} block is huge, and duplicated in each filter. True, I can create a "final filter" that does this to avoid all that boilerpate code that takes the frame and converts it back to what it needs to be. But what I suggested was Qt should provide this automatically both in the filter chain. The difference is this:

 

 

VideoOutput {

   filters: [sobel, houghLines]

}

 


VideoOutput {

   filters: [sobel, houghLines, final]

}

 

Ideally that final filter checks the frame matches what it expects and only if it does not, performs a conversion.  Maybe there's a way to register a conversion from a custom type to a QVideoFrame?

Also, if the VideoOutput is not needed* the final filter need not be invoked.

 

By not needed, I mean the video output element is not visable, or it's area is 0. Sometimes, we want to provide intel about the frames, without affecting them. Currently, this is inherently syncronous, which negatively impacts frame rate.

I should be able to use two (or more) VideoOutputs, one for real-time video display and another for info-only filter pipeline, and these can be distributed across cpu cores. Unfortuantely, the VideoOutput takes over the video source forcing source-output mappings to be 1:1. It would be really nice if it could be 1:N. I experimented with this, and the first VideoOutput is the only one to receive a frame from a source, and the only one with an active filter pipeline. How could I have 3 VideoOutputs, each with it's own filter pipeline and visualize them simulatneously?

 

Camera { id: camera }

 


VideoOutput {  // only this one works. If I move this after the next one, then that one works.

   filters: [sobel, houghLines]  

   source: camera

}

 


VideoOutput {

   filters: [sobel, houghLines, final]

   source: camera

}



 

So to sum this up:

- Qt should provide automatic frame reconstruction for the final frame (that big if(){} block) (it should be boilerplate)

- A way to register custom format to QVideoFrame reconstruction function

- Allow for multiple VideoOutputs (and filter pipelines) from the same source

-- Maybe an element for no video output pipeline?

 

Am wrong in thinking any of that doesn't already exist or is a good idea?

 



Sent: Saturday

Re: [Development] QAbstractVideoFilter, the pipeline and QImage

[Jason H]

I have been thinking about this more, and I think we also need to convert when the pipeline switches between internal formats. This would allow standard filter tooklits to be "a thing" for Qt. 

 

For example, if my pipeline filters are written to use QImage (because scanline() and pixel()) , and someone else's use cv::Mat (OpenCV), alternating between formats is not possible in the same pipeline. I think the panacia is to be able to convert not just at the end, but for any step:

[gauss, sobel, houghLines, final] -> formats: [QVideoFrame->cv::Mat, cv::Mat, cv::Mat->QImage, QImage->QVideoFrame] where each format step is the (inputFormat -> outputFormat)

 

Just my 0.02BTC.

 

 

Sent: Wednesday, January 02, 2019 at 12:33 PM
From: "Jason H" 
To: "Pierre-Yves Siret" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage



Thanks for pointing that out. I guess that could work. It's not as elegant as what I want, where everyhing presents the same way. Now each and every filter has to have

 

if (flags & QVideoFilterRunnable::LastInChain) {

   ... generate the frame for the backend per the surfaceFormat

}


 

As there are many surfaceFormats, that if(){} block is huge, and duplicated in each filter. True, I can create a "final filter" that does this to avoid all that boilerpate code that takes the frame and converts it back to what it needs to be. But what I suggested was Qt should provide this automatically both in the filter chain. The difference is this:

 

 

VideoOutput {

   filters: [sobel, houghLines]

}

 


VideoOutput {

   filters: [sobel, houghLines, final]

}

 

Ideally that final filter checks the frame matches what it expects and only if it does not, performs a conversion.  Maybe there's a way to register a conversion from a custom type to a QVideoFrame?

Also, if the VideoOutput is not needed* the final filter need not be invoked.

 

By not needed, I mean the video output element is not visable, or it's area is 0. Sometimes, we want to provide intel about the frames, without affecting them. Currently, this is inherently syncronous, which negatively impacts frame rate.

I should be able to use two (or more) VideoOutputs, one for real-time video display and another for info-only filter pipeline, and these can be distributed across cpu cores. Unfortuantely, the VideoOutput takes over the video source forcing source-output mappings to be 1:1. It would be really nice if it could be 1:N. I experimented with this, and the first VideoOutput is the only one to receive a frame from a source, and the only one with an active filter pipeline. How could I have 3 VideoOutputs, each with it's own filter pipeline and visualize them simulatneously?

 

Camera { id: camera }

 


VideoOutput {  // only this one works. If I move this after the next one, then that one works.

   filters: [sobel, houghLines]  

   source: camera

}

 


VideoOutput {

   filters: [sobel, houghLines, final]

   source: camera

}



 

So to sum this up:

- Qt should provide automatic frame reconstruction for the final frame (that big if(){} block) (it should be boilerplate)

- A way to register custom format to QVideoFrame reconstruction function

- Allow for multiple VideoOutputs (and filter pipelines) from the same source

-- Maybe an element for no video output pipeline?

 

Am wrong in thinking any of that doesn't already exist or is a good idea?

 



Sent: Saturday, December 22, 2018 at 5:10 AM
From: "Pierre-Yves Siret" 
To: "Jason H" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage





 


The filter pipeline starts with a file or camera device, and various filters are applied sequentially to frames. However I spend a lot of time converting frames to QImages for analysis and painting. I'm hoping there's a faster way to do this. Some of the filters alter the frame, some just provide information about the frame.

But each time, I have to unpack a QVideoFrame's pixels and make sure the filter can process that pixel format, or convert it to one format that it expects. I'm getting processing times of 55msec on my mackbook pro, which give me 18FPS from a 25FPS video, so I'm dropping frames.  I am starting to think the ideal would be to have some "Box of Pixels" data structure that both QImage and QVideoFrame can use. But for now, I convert each frame to a QImage at each stage of the pipeline.

 

I'm not that versed in image manipulation but isn't that the point of the QVideoFilterRunnable::LastInChain flag ?

Quoting the doc: 
"flags contains additional information about the filter's invocation. For example the LastInChain flag indicates that the filter is the last in a VideoOutput's associated filter list. This can be very useful in cases where multiple filters are chained together an

Re: [Development] QAbstractVideoFilter, the pipeline and QImage

[Jason H]

Thanks for pointing that out. I guess that could work. It's not as elegant as what I want, where everyhing presents the same way. Now each and every filter has to have

 

if (flags & QVideoFilterRunnable::LastInChain) {

   ... generate the frame for the backend per the surfaceFormat

}


 

As there are many surfaceFormats, that if(){} block is huge, and duplicated in each filter. True, I can create a "final filter" that does this to avoid all that boilerpate code that takes the frame and converts it back to what it needs to be. But what I suggested was Qt should provide this automatically both in the filter chain. The difference is this:

 

 

VideoOutput {

   filters: [sobel, houghLines]

}

 


VideoOutput {

   filters: [sobel, houghLines, final]

}

 

Ideally that final filter checks the frame matches what it expects and only if it does not, performs a conversion.  Maybe there's a way to register a conversion from a custom type to a QVideoFrame?

Also, if the VideoOutput is not needed* the final filter need not be invoked.

 

By not needed, I mean the video output element is not visable, or it's area is 0. Sometimes, we want to provide intel about the frames, without affecting them. Currently, this is inherently syncronous, which negatively impacts frame rate.

I should be able to use two (or more) VideoOutputs, one for real-time video display and another for info-only filter pipeline, and these can be distributed across cpu cores. Unfortuantely, the VideoOutput takes over the video source forcing source-output mappings to be 1:1. It would be really nice if it could be 1:N. I experimented with this, and the first VideoOutput is the only one to receive a frame from a source, and the only one with an active filter pipeline. How could I have 3 VideoOutputs, each with it's own filter pipeline and visualize them simulatneously?

 

Camera { id: camera }

 


VideoOutput {  // only this one works. If I move this after the next one, then that one works.

   filters: [sobel, houghLines]  

   source: camera

}

 


VideoOutput {

   filters: [sobel, houghLines, final]

   source: camera

}



 

So to sum this up:

- Qt should provide automatic frame reconstruction for the final frame (that big if(){} block) (it should be boilerplate)

- A way to register custom format to QVideoFrame reconstruction function

- Allow for multiple VideoOutputs (and filter pipelines) from the same source

-- Maybe an element for no video output pipeline?

 

Am wrong in thinking any of that doesn't already exist or is a good idea?

 



Sent: Saturday, December 22, 2018 at 5:10 AM
From: "Pierre-Yves Siret" 
To: "Jason H" 
Cc: "Qt development mailing list" 
Subject: Re: [Development] QAbstractVideoFilter, the pipeline and QImage





 


The filter pipeline starts with a file or camera device, and various filters are applied sequentially to frames. However I spend a lot of time converting frames to QImages for analysis and painting. I'm hoping there's a faster way to do this. Some of the filters alter the frame, some just provide information about the frame.

But each time, I have to unpack a QVideoFrame's pixels and make sure the filter can process that pixel format, or convert it to one format that it expects. I'm getting processing times of 55msec on my mackbook pro, which give me 18FPS from a 25FPS video, so I'm dropping frames.  I am starting to think the ideal would be to have some "Box of Pixels" data structure that both QImage and QVideoFrame can use. But for now, I convert each frame to a QImage at each stage of the pipeline.

 

I'm not that versed in image manipulation but isn't that the point of the QVideoFilterRunnable::LastInChain flag ?

Quoting the doc: 
"flags contains additional information about the filter's invocation. For example the LastInChain flag indicates that the filter is the last in a VideoOutput's associated filter list. This can be very useful in cases where multiple filters are chained together and the work is performed on image data in some custom format (for example a format specific to some computer vision framework). To avoid conversion on every filter in the chain, all intermediate filters can return a QVideoFrame hosting data in the custom format. Only the last, where the flag is set, returns a QVideoFrame in a format compatible with Qt."

 

You could try using just one pixel format and use that in all your filters without reconverting it at each step.

 







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

[Development] QAbstractVideoFilter, the pipeline and QImage

[Jason H]

I sent a message on interest@ but no one replied so I'm escalating it here. I 
am making a series of filters, but I'm encountering performance issues. I think 
it's because of lack of my understanding, or detail in the docs.

The filter pipeline starts with a file or camera device, and various filters 
are applied sequentially to frames. However I spend a lot of time converting 
frames to QImages for analysis and painting. I'm hoping there's a faster way to 
do this. Some of the filters alter the frame, some just provide information 
about the frame. 

But each time, I have to unpack a QVideoFrame's pixels and make sure the filter 
can process that pixel format, or convert it to one format that it expects. I'm 
getting processing times of 55msec on my mackbook pro, which give me 18FPS from 
a 25FPS video, so I'm dropping frames.  I am starting to think the ideal would 
be to have some "Box of Pixels" data structure that both QImage and QVideoFrame 
can use. But for now, I convert each frame to a QImage at each stage of the 
pipeline.

In addition to that, I've discovered that the QVideoSurfaceFormat in the run() 
is const, which means that for those frames with scan line direction BottomTop, 
I cannot correct the scan lines and instead always flip the QImage fo the next 
frame because I cannot change the scan line direction. The same applies to 
isMirrored(). I'd like to orient the frame properly at the start and leave it 
for the rest of the pipeline. But instead I have to keep flipping and 
unflipping it with QImage::mirrored() every frame every filter in the pipeline. 
That's just silly. 

A few things could actually help:
1) being able to change the surfaceFormat
2) QImage and QVideoFrame use the same pixel data (when the formats match) (the 
pipeline then keeps referencing 
3) QVideoFrame gets a pixel(x,y, surfaceFormat) function that takes into 
account the surfaceFormat 
4) make QPainter be able to take a QVideoFrame
5) Be able to specify the surface format for the pipeline before a frame gets 
to the pipeline

Some of my filters are all QImage based, but some make use of OpenCV, so then I 
have to convert it to a OpenCV "mat" this is fortunately a fast operation under 
ideal conditions, but sometimes has a conversion penalty. Usually I don't have 
to convert back from mat because it's not pixels that I'm getting from OpenCV.

switch (img.format()) {
case QImage::Format_RGB888:{
auto result = qimage_to_mat_ref(img, CV_8UC3);
if(swap){
cv::cvtColor(result, result, CV_RGB2BGR);
}
return result;
}
case QImage::Format_Grayscale8:
case QImage::Format_Indexed8:{
return qimage_to_mat_ref(img, CV_8U);
}
case QImage::Format_RGB32:
case QImage::Format_ARGB32:
case QImage::Format_ARGB32_Premultiplied:{
return qimage_to_mat_ref(img, CV_8UC4);
}

cv::Mat qimage_to_mat_ref(QImage , int format)
{
return cv::Mat(img.height(), img.width(), format, img.bits(), 
img.bytesPerLine());
}


Aside from OpenCLing the conversion, is there anything I can do?




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

Re: [Development] Braces (was Resolving coding style contentions)

[Jason H]

This is probably hijacking your post, but I've always found it bad style to 
have different conventions for C++ and QML.

//C++ convention
int Class::memberF() 
{

}

//QM convention:, compressed is used: 
Rectangle {
   onVisibleChanged: { 
 
   }
}

I'd like to get everything down to one style (preferable QML's)

As to your question, using a lot of modern C++ initializers, I've found myself 
using braces with spaces when using lists, and just preferring more whitespace 
in general. When using (), I don't post space, so new Item("name", parent); 
stays. However your example of new Item { "name", parent }; really bothers me. 
If you're calling a function, keep that with () and only use { } for the other 
things. I do not know how far back the compilers would allow new Item { "name", 
parent }; but it just doesn't look right to me. I understand there may be a 
push to make it modern, but not everyone should need to be at the level of 
proficiency of modern to feel comfortable in Qt. So I encourage the principal 
of oldest possible expressible syntax. If Qt started using new Item { "name", 
parent };, I would freak. Thiago has criticised some of my suggestions for 
source compatibility, and he's right to do so. But I'm arguing for backwards 
mental source compatibility. When reading new code I often wonder "Is this a 
new concept or and old one new to me?" And if it's a new concept, what's the 
minimum C++0x version that I need?

The only thing beyond better initializer lists that I really find that I like 
about modern C++ is that you can use structured bindings to decompose a pair 
into better-named variables than 'pair.first' and 'pair.second'; Unfortunately, 
structured bindings are not supported by the Android NDK yet* (*the last time I 
checked).



> Sent: Friday, December 21, 2018 at 1:59 AM
> From: "Alberto Mardegan" 
> To: development@qt-project.org
> Subject: [Development] Braces (was Re: Resolving coding style contentions)
>
> Hi all!
>   Speaking of coding style again, I haven't found any indication in the
> coding guidelines about brace vs parentheses in initializations.
> 
> There are a few cases where they can be used (and I might even be
> forgetting some):
> 
> 1) Constructors:
>MyClass(): var(0) {}
>vs
>MyClass(): var { 0 } {}
> 
> 2) Member initializations:
>class MyClass
>{
>int m_count = 3;
>vs
>int m_count { 3 };
> 
> 3) Variable initialization
>bool ok = false;
>vs
>bool ok { false };
> 
> 4) Constructor invocations:
>auto *item = new Item("name", parent);
>vs
>auto *item = new Item { "name", parent };
> 
>or
> 
>QString message(QStringLiteral("text"));
>vs
>QString message { QStringLiteral("text") };
>I guess this is not an option:
>QString message { QStringLiteral { "text" } };
> 
> 
> I'm not mentioning the cases of struct and list initializers, where of
> course braces are the only option. But what is the consensus on the
> cases above?
> Looking at the Qt code, it seems that variant without braces is always
> preferred, but I cannot find it formalized anywhere.
> 
> Ciao,
>   Alberto
> 
> -- 
> http://blog.mardy.it - Geek in un lingua international
> ___
> 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] Remove artemis_poo...@aol.com from list (spammer)

[Jason H]

I request removal of artemis_poo...@aol.com for spam. Email can be forwarded to 
the appropriate party.
Have others gotten a direct reply?

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

Re: [Development] Qml draw pattern as password

[Jason H]

First use Qt interest mailing list. Since this is a developer list let's throw this out there:

Next why is an **app** **implementing** a lock screen? It would be far better for Qt to integrate with whatever authentication mechanisms provides. For example:

 

if (QAuthProvider::mechanisms(QAuthProvider::Biometric).length() > 0)

    QAuthResult result = QAuthProvider::challenge();

    if (result.success() && result.method() & Mechanism::Biometric) {

    

    }

 

}


 

I'm imagining:

class QAuthResult {

...

   bool result();

   Method method();

   QString providerName(); /* e.g. Google, Twitter */

   QString sessionIdentifier();

  

};

 

class QAuthProvider {

...

enum class Mechanisms {

   None =0,

   Password = 1,

   FingerPrint =2,

   FacialPrint = 4,

   DNA = 8,

   Pin = 16,

   Pattern = 32,

   Network = 64, /* http://doc.qt.io/qt-5/qauthenticator.html */

   Social = 128,   /* https://doc.qt.io/qt-5/qtnetworkauth-module.html */

 

// categories:

   Biometric = FingerPint | FacialPrint | DNA,

   Memory = Password | Pin | Pattern,

   Remote = Network | Social,

   Local = Biometric | Memory,

 

   CustomBase = 1024

};

 

static mechanisms(Mechanisms);

static challenge()

static registerCustomMechanism (QAbstractAuthProviderBase *customProvider); 

};

This would be the finger print reader on phones, laptops, FaceId on iPhones, and passwords as the worst-case fall-back.

 

 

Until something like that comes along, you'll need to use a MouseArea and a Canvas, as the simpleest way to do it.

 

 


Sent: Friday, December 14, 2018 at 3:47 AM
From: "Akın Gümüşkavak" 
To: "development@qt-project.org" 
Subject: [Development] Qml draw pattern as password




Hello,

 

I'm trying to develop a drawing pattern area as password field in Qml. I've made some research but could not find anything useful. 

Now, I am thinking to use MouseArea. I can identify points in this area and I can get mouse X and Y positions on pressed. But it is getting complicated. 

Is there any easier way to implement this feature or is there any example about this? 

 

Thanks for your help,

Best 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] QUIP 12: Code of Conduct

[Jason H]

Hello all,

For anyone who is interested, I just wanted to point out that Slashdot has a 
poll on the CoC fad: 
https://slashdot.org/poll/3103/what-do-you-make-of-programming-languages-and-open-source-organizations-adopting-a-code-of-conduct
 

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

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

Hi Volker,

I think you ask a very good question.  "If someone like Coraline were to direct 
her energy to the Qt Project, how much in the open would you want their efforts 
to be? Or would you rather simply trust that there are not enough maintainers 
in the Qt project that would fall for their chain of arguments and backdoor 
schemings?"

Let's break that down.
"If someone like Coraline were to direct her energy to the Qt Project" - 
1) If by energy you mean, she wants to contribute, I would not have a problem 
with her participation despite me not agreeing with her previous behavior. 
Contributions would be judged on technical merits alone.
2) If by energy you mean a witch hunt, then it should be done publicly as to 
add to her existing history.
3) If by energy you mean a "legitimate complaint" then I guess it would depend 
on the nature of her claims. If the items of transgression are Qt community 
items, then it's already in public. If things were done in private then it 
would be debatable what influence the Qt community resolution process would 
have.

So I don't have a clear answer for you, but that should set up some kind of 
framework. The agreement on venue is difficult. I could both see wanting public 
resolution or private resolution, and I can't even typify that based on 
scenario.

Admittedly, I don't understand the last part of your question. "simply trust 
that there are not enough maintainers in the Qt project that would fall for 
their chain of arguments and backdoor schemings". Previously I suggested that 
the people selected to judge the process be entirely at random to prevent 
politicisation of the decision makers. And also evidence should only be 
considered if on a Qt community property.  At the same time, these incidents 
may have confidential information, which should be protected from public 
disclosure. I think all of that fell on deaf ears?

I've asked repeatedly for very specific definitions and standards of things to 
be considered. This would go along way to getting my approval. I will always 
resist an ambiguous judgements on ambiguous standards. The process should be 
transparent to those involved in it, such that you should know how it will turn 
out before entering into the process. I don't think ambiguity serves anyone 
justly.



> Sent: Monday, October 29, 2018 at 11:33 AM
> From: "Volker Hilsheimer" 
> To: "Jason H" 
> Cc: "Lydia Pintscher" , "Qt development mailing list" 
> 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> Hey Jason,
> 
> 
> You seem to assume that without a code of conduct there is no way that people 
> can get banned. That is not the case. In practice, people can be kicked out 
> of the Qt Project by the folks that control the respective systems. And by 
> extension by those who have some influence over those people.
> 
> You call that “self-policing”, but in fact it’s about us trusting that the 
> folks that have those privileges do not abuse their power. That’s great as 
> long as it works, but if the project somehow does become “more political”, 
> then I do think this lack of transparency is not in the interest of the 
> project.
> 
> A CoC tries to formulate what environment we want our behaviors to create, 
> and it establishes a less opaque process for managing situations where an 
> individual seems to do more harm than good to the project.
> 
> That doesn’t mean that there won’t be mistakes. It doesn’t take much to cause 
> someone distress through an email or a quick comment to their code, esp when 
> we want to include people that are regularly exposed to all sorts of 
> harassment, and are not quite as thick-skinned and self-assured as you and I 
> might be. But I think that, by simply establishing a CoC that community 
> members agree to, we can create an atmosphere where even a rough piece of 
> language is received in the spirit of collaboration.
> 
> And that also doens’t mean that there won’t be abuse. I’m sure there are 
> people that have made it a way of life to be offended. However, they do not 
> need a Code of Conduct (which is not a legal document anyway). I’d rather 
> have them raise their voice in the open, and direct them towards a 
> transparent process, than to have them use backdoor tactics to get influence 
> over the project.
> 
> The question to you is then: If someone like Coraline were to direct her 
> energy to the Qt Project, how much in the open would you want their efforts 
> to be? Or would you rather simply trust that there are not enough maintainers 
> in the Qt project that would fall for their chain of arguments and backdoor 
> schemings?
> 
> 
> Volker
> 
> 
> > On 29 Oct 2018, at 15:10, Jason H  wrote:
> > 
> > Lydia,
> > 
> > First, l

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

Lydia,

First, let me say I've stated my support of the KDE CoC. Thank you for your 
effort in it.

But then you make a statement in your post script that demonstrates exactly 
what I'm talking about.  You stated  "some emails in this thread sadly make me 
see part of the project in a different light. I fear I'm not the only one."? 
Would you say the project has created fear in you and this has somehow "harmed" 
the project in some way? Who were these people that changed your mind? We need 
to identify these people and ban them because they are not casting the widest 
inclusive and protective audience and anything less than that is harm... Let 
the witch hunt begin... right? 

Everyone,
This is the slippery slope that I'm talking about accusations start in 
wide-abstractions like your statement and devolve into direct accusations.  
While no one yet here has the motivation to conduct a witch hunt, we cannot 
assume that will be the case. So far common sense has prevailed, but common 
sense is, well, uncommon. It may be that Cone day oraline et. al. go on a witch 
hunt for those the opposed her Covenant.

I've spent some time thinking about this this weekend. Here's what I don't get. 
Coraline authored the CC. She then goes into projects attacking them with it, 
but fortunately(?) it hasn't worked. But to put it a different way, if I design 
an instrument, publish the plans, and try to use it in a community, if it 
doesn't work, is it the instrument or the user that is at fault? If that 
instrument is intended to be destructive (say like a bomb), then can we see how 
she really means for this to be used? To my knowledge none of the people 
singled out in the witch hunts actually did anything offensive in the projects 
they were participating in. 

It could be that eventually those who opposed the CoC in some way get labeled 
as "intolerant" by the larger community. Lydia's statement has already given me 
pause in this regard and I'm not being hyperbolic. Political views, and things 
we don't consider as political today, can eventually become political.

I think we have two camps:
We want a CoC as a feel-good statement of inclusion and tolerance (I think 
everyone is committed to this)
AND
1) We want to use existing situation of laws/self-policing OR
2) We want a CoC that contains a framework that can get people banned or more

I've always assumed that there was some line that could be crossed that would 
get your accounts shut down and removed from the community. If someone makes it 
so that the community cannot function, in whole or in part, then removal is 
warranted. These Codes of Conducts lower the barrier to an incredibly low bar 
and don't say what lower threshold of "harm" is needed to run afoul. I haven't 
even had a response as to if it is perceived or demonstrable harm that is 
required.

So far cooler heads and common sense have prevailed, but I don't trust that 
will always be the case. This is why if we go with a CoC that can prescribe 
punishments, that it be explicit both in determination and punishment stages.


*Not that I have anything against witches. I have several wiccan friends. Is 
the term "witch hunt" offensive? Can I get banned for using that term now or in 
the future?


> Sent: Sunday, October 28, 2018 at 7:53 PM
> From: "Lydia Pintscher" 
> To: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira
>  wrote:
> > And I'm pretty sure the KDE Community WG can easily compile a list of times
> > that they were maliciously asked to look into situations and how much time 
> > it
> > took them to give it the attention it was due.
> 
> I don't have an exact number but less than 10. And we could always
> deal with it very quickly thanks to some common sense and good
> knowledge of the situation and people involved. No big deal.
> 
> (For those who don't know me: I'm one of the people who wrote KDE's
> CoC and has been a member of it's community working group since then.
> I'm also the current president of the non-profit behind KDE.)
> If you have further questions about KDE's Code of Conduct please let
> me know. I'm happy to answer them.
> 
> 
> Cheers
> Lydia
> 
> PS: As someone on the fringes of the Qt Project some emails in this
> thread sadly make me see part of the project in a different light. I
> fear I'm not the only one.
> 
> -- 
> Lydia Pintscher - http://about.me/lydia.pintscher
> KDE e.V. Board of Directors
> http://kde.org - http://open-advice.org
> ___
> 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] QUIP 12: Code of Conduct

[Jason H]

Thiago,

Here's a link that kinda puts it together: 
https://lulz.com/linux-devs-threaten-killswitch-coc-controversy-1252/ (Scroll 
to  "The Controversy" and the "rape apologist" Sage Sharp tweet)

I didn't realize this was a thing of "defeat". I have concerns, based on actual 
events, that I want resolved. 

I do respectfully disagree on whether or not an author is relevant to 
considering a work. In this case the author has a track record of attacking 
members in open source projects and arguing against meritocracy. Is the text 
good? There is a lot I agree with, but there are things in it that cross the 
line for me. I think we can come to an agreement, but not with invoking the 
Covenant in its current form. 


> Sent: Friday, October 26, 2018 at 2:35 PM
> From: "Thiago Macieira" 
> To: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Friday, 26 October 2018 09:48:11 PDT Jason H wrote:
> > My fundamental problem about the Contributor Covenant[1] was initially and
> > solely the fallout from the Linux Kernel fiasco. But then I learned that it
> > was drafted by Coraline Ada Ehmke, who sought to have a contributor removed
> > [2] from a project preemptively. The contributor did nothing wrong with
> > respect to the project or the project's community.  She constructed a claim
> > of "transphobia" based on a tweet the contributor wrote in no way relating
> > to the project at hand, and slandered the project for not expunging them.
> > My mind is made up: the Contributor Covenant is a tool of oppression.
> 
> First of all, the kernel adoption of CoC was not a fiasco. All the negative 
> emails you may have seen came from people who are not contributors, often 
> their first and only email to the mailing list. Despite what Eric Raymond has 
> said, revoking the copyright licence for GPL just cannot be done -- it would 
> be against GPL's spirit.
> 
> Coraline's intentions are irrelevant. What matters is the text: is it good?
> 
> But if your mind is made up, kindly refrain from trying to convince others to 
> change their minds too. This is a two-way street and you're only welcome to 
> argue your point if you're willing to admit defeat too.
> 
> > The specific sentence in the Covenant is:
> > "This Code of Conduct applies both within project spaces and in public
> > spaces when an individual is representing the project or its community."
> > 
> > However, despite being the author of the Covenant (2014), she found it
> > appropriate to attack someone who was clearly not operating in a project
> > space or representing the project community (2015). We now have two
> > examples - the linux Kernel and Opal project, that after CC was enacted
> > that calls for removal of members based on past unrelated tweets went out.
> > One of the problems its politics and political climates change over time.
> > Expressing what is not political at one point in time may become political
> > in subsequent years. People's minds also change over time.
> 
> What is the kernel example? Who was forced out, or attempted to?
> 
> > I urge you to read link[3] below and see if we want that kind of attention.
> > It summarizes what happens when the CC has been adopted by other projects.
> > 
> > [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> > [2] https://github.com/opal/opal/issues/941
> > [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/
> 
> I have.
> 
> The proponents of the removal were arguing that having such a person as a 
> project leader is poisonous to the project, *regardless* of the fact that it 
> was done in private time, because it would turn away potential new 
> contributors as they didn't want to associate with such a person. This is an 
> extreme situation, indeed, and one that the CoC committee should be able to 
> make a judgement on: which way is the project best served?
> 
> Anyway, given that the request to get the maintainer removed was not 
> accepted, 
> how is that a failure of the CoC? Isn't it showing that it's *working*?
> 
> I personally think those situations explain why we need a CoC in the first 
> place and why the judgment on such situations is very subjective, best left 
> to 
> humans, not to a script. And the deliberations should not be in a public 
> forum, like a GitHub issue.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

Putting my "red team" hat on for a moment (not a political color thing - a pen. test thing) this is how it will play out - maybe not for me personally - but someone in the community will express something that some (for lack of a better term) social justice warrior will take offense with to the degree that they are intent on really messing up the poster's life and will dox them and realize they are are a part of this community, and since the community is under the Covenant, can initiate a complaint with the Qt community that the poster, by merely being a member of this community, is harming the community, and seeks/gets the community member removed?

 

How do we prevent that scenario, what is essentially a social Denial-of-Service (denial of community?) attack? If we adopt a Conenant-based language we have to consider this attack vector. It has already happened in other projects - it is not a hypothetical. 

 



Sent: Friday, October 26, 2018 at 2:17 PM
From: "NIkolai Marchenko" 
To: jh...@gmx.com
Cc: "Christian Kandeler" , "Qt development mailing list" 
Subject: Re: [Development] QUIP 12: Code of Conduct


And we already see the budding sentiments to that exact tune:
 

(quote from Edward Welbourne)

>That sometimes folk have felt so intimidated that they give up on trying
>  to make a contribution; and that, were potential worse conduct to cause
>  distress to a contributor, we have no process in place that could give
>  them confidence that their distress will be respected and honest efforts
vwill be made to relieve it.  Various variations and permutations on
>  these themes may also be relevant; see Simon's mail.
 

Note: I understand that he means well, but Within the context of Contributor Covenant the punishability of the potential harm of people not contributing can escalate to stupid proportions. 

I have nothing against KDE's code. It strives to add positivity.

I am very much against Qt's CoC being drafted from Covenant. Covenant is focused on oppression and excluding ppl.

 


On Fri, Oct 26, 2018 at 9:06 PM Jason H <jh...@gmx.com> wrote:




I don't really care that their role, though that move takes gravitas.

 

I will never endorse a measure that encourages (and the CC does encourage) a witchhunt on the members of the community. It encourages by creating a metric of "maximum comfort" (or "least harmful") and that anything else is somehow a violation. She did it herself with these words[2]: "Is this what the other maintainers want to be reflected in the project? Will any transgender developers feel comfortable contributing?" With those words she created a metric of "maximum comfort". So now the question moves from not just having not offended someone, but to be maximally comforting to every possible person. Not that there's anything wrong with *wanting* to be maximally comfortable for everyone. It's a great goal. But now every interaction is to be judged by this metric, and anything less than the maximal comfort is somehow potentially alienating to a population and can be construed to be a cause for removal. 

 

In the CC itself it encourages a witchhunt with these words:

"Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful."

 

That last word, "harmful" significantly alters the statement. Don't let your eyes glaze over. Now anything that happens is potentially harmful. (Ironically C++, or its constructs is even "considered harmful". Just google "C++ considered harmful", lol). I probably would have let this whole issue slide but that last word _really_ changes the character of the covenant. I beleive that is *the* word that allows the witchhunting. It's not just direct harm but potential harm. From [2]: "As a queer person this sort of argument from a maintainer makes me feel unwelcome. The ignorance which @elia shows by claiming that transfolk are "not accepting reality" is actively harmful. I will not contribute to this project or any other project which @elia maintains." - strand

 

Not that strand was participating, but states that there will be no future contribution by strand.  This is an appeal to percieved harm - that now strand will not ever contribute, the project is potentially harmed by missing out on a contributor. So now this issue can fall under the Covenant. 

 

 

How can we avoid witchhunts?

 



Sent: Friday, October 26, 2018 at 1:24 PM
From: "NIkolai Marchenko" <enmarantis...@gmail.com>
To: jh...@gmx.com
Cc: "Christian Kandeler" <christian.kande...@qt.io>, "Qt development mailing list&quo

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

I don't really care that their role, though that move takes gravitas.

 

I will never endorse a measure that encourages (and the CC does encourage) a witchhunt on the members of the community. It encourages by creating a metric of "maximum comfort" (or "least harmful") and that anything else is somehow a violation. She did it herself with these words[2]: "Is this what the other maintainers want to be reflected in the project? Will any transgender developers feel comfortable contributing?" With those words she created a metric of "maximum comfort". So now the question moves from not just having not offended someone, but to be maximally comforting to every possible person. Not that there's anything wrong with *wanting* to be maximally comfortable for everyone. It's a great goal. But now every interaction is to be judged by this metric, and anything less than the maximal comfort is somehow potentially alienating to a population and can be construed to be a cause for removal. 

 

In the CC itself it encourages a witchhunt with these words:

"Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful."

 

That last word, "harmful" significantly alters the statement. Don't let your eyes glaze over. Now anything that happens is potentially harmful. (Ironically C++, or its constructs is even "considered harmful". Just google "C++ considered harmful", lol). I probably would have let this whole issue slide but that last word _really_ changes the character of the covenant. I beleive that is *the* word that allows the witchhunting. It's not just direct harm but potential harm. From [2]: "As a queer person this sort of argument from a maintainer makes me feel unwelcome. The ignorance which @elia shows by claiming that transfolk are "not accepting reality" is actively harmful. I will not contribute to this project or any other project which @elia maintains." - strand

 

Not that strand was participating, but states that there will be no future contribution by strand.  This is an appeal to percieved harm - that now strand will not ever contribute, the project is potentially harmed by missing out on a contributor. So now this issue can fall under the Covenant. 

 

 

How can we avoid witchhunts?

 



Sent: Friday, October 26, 2018 at 1:24 PM
From: "NIkolai Marchenko" 
To: jh...@gmx.com
Cc: "Christian Kandeler" , "Qt development mailing list" 
Subject: Re: [Development] QUIP 12: Code of Conduct


Just to clarify: she sought to remove _maintainer_ of the project :) At that point the guy was doing most of the work.
 


On Fri, Oct 26, 2018 at 7:48 PM Jason H <jh...@gmx.com> wrote:

My fundamental problem about the Contributor Covenant[1] was initially and solely the fallout from the Linux Kernel fiasco. But then I learned that it was drafted by Coraline Ada Ehmke, who sought to have a contributor removed [2] from a project preemptively. The contributor did nothing wrong with respect to the project or the project's community.  She constructed a claim of "transphobia" based on a tweet the contributor wrote in no way relating to the project at hand, and slandered the project for not expunging them. My mind is made up: the Contributor Covenant is a tool of oppression.

The specific sentence in the Covenant is:
"This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community."

However, despite being the author of the Covenant (2014), she found it appropriate to attack someone who was clearly not operating in a project space or representing the project community (2015). We now have two examples - the linux Kernel and Opal project, that after CC was enacted that calls for removal of members based on past unrelated tweets went out. One of the problems its politics and political climates change over time. Expressing what is not political at one point in time may become political in subsequent years. People's minds also change over time.

I urge you to read link[3] below and see if we want that kind of attention. It summarizes what happens when the CC has been adopted by other projects.

[1] https://en.wikipedia.org/wiki/Contributor_Covenant
[2] https://github.com/opal/opal/issues/941
[3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/

> Sent: Friday, October 26, 2018 at 3:50 AM
> From: "Christian Kandeler" <christian.kande...@qt.io>
> To: "development@qt-project.org" <development@qt-project.org>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> 

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

My fundamental problem about the Contributor Covenant[1] was initially and 
solely the fallout from the Linux Kernel fiasco. But then I learned that it was 
drafted by Coraline Ada Ehmke, who sought to have a contributor removed [2] 
from a project preemptively. The contributor did nothing wrong with respect to 
the project or the project's community.  She constructed a claim of 
"transphobia" based on a tweet the contributor wrote in no way relating to the 
project at hand, and slandered the project for not expunging them. My mind is 
made up: the Contributor Covenant is a tool of oppression.

The specific sentence in the Covenant is:
"This Code of Conduct applies both within project spaces and in public spaces 
when an individual is representing the project or its community." 

However, despite being the author of the Covenant (2014), she found it 
appropriate to attack someone who was clearly not operating in a project space 
or representing the project community (2015). We now have two examples - the 
linux Kernel and Opal project, that after CC was enacted that calls for removal 
of members based on past unrelated tweets went out. One of the problems its 
politics and political climates change over time. Expressing what is not 
political at one point in time may become political in subsequent years. 
People's minds also change over time.

I urge you to read link[3] below and see if we want that kind of attention. It 
summarizes what happens when the CC has been adopted by other projects.

[1] https://en.wikipedia.org/wiki/Contributor_Covenant
[2] https://github.com/opal/opal/issues/941
[3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/

> Sent: Friday, October 26, 2018 at 3:50 AM
> From: "Christian Kandeler" 
> To: "development@qt-project.org" 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Thu, 25 Oct 2018 19:39:45 +0200
> André Pönitz  wrote:
> 
> > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development 
> > wrote:
> > > We do have a Code of Conduct at KDE for about 10 years now, and this 
> > > hasn't 
> > > led to abuse of power, suppression of free speech, racism against white 
> > > people 
> > > or whatever other nonsense people seem to attribute to CoCs nowadays.  
> > 
> > The KDE CoC is *friendly*. It contains words like "considerate", 
> > "pragmatic",
> > "support". It doesn't push someone's personal political agenda.  
> 
> I agree. It reads as if it was written with the intention of creating a 
> constructive environment, lacks the inquisition-y vibe and is free of jargon 
> and weirdly over-specific lists.
> 
> 
> Christian
> ___
> 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] QUIP 12: Code of Conduct

[Jason H]

+1 this. I have no problems with the KDE CoC. 


> Sent: Thursday, October 25, 2018 at 1:39 PM
> From: "André Pönitz" 
> To: "Volker Krause" 
> Cc: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote:
> > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't 
> > led to abuse of power, suppression of free speech, racism against white 
> > people 
> > or whatever other nonsense people seem to attribute to CoCs nowadays.
> 
> The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic",
> "support". It doesn't push someone's personal political agenda.  This is a
> completely different beast than the Contributor Covenant that's about 
> "enforcing", "reporting", "banning".
> 
> I think we'd see much less heat in the discussion if the proposed Qt CoC had
> been based on the KDE CoC.
> 
> Andre'
> ___
> 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] QUIP 12: Code of Conduct

[Jason H]

> Sent: Thursday, October 25, 2018 at 11:38 AM
> From: "Volker Hilsheimer" 
> To: "Jason H" , "Qt development mailing list" 
> 
> Cc: "Mitch Curtis" 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> > On 25 Oct 2018, at 16:43, Jason H  wrote:
> > Next there is a notion of the CoC being applied to profanity. I am also 
> > against this. This would violate my right to free speech, and it would be 
> > so vague to be unenforceable.
> 
> 
> Oh dear.
> 
> With your "right to free speech" you probably refer to the first amendment of 
> the United States Constitution.
> 
> "Congress shall make no law respecting an establishment of religion, or 
> prohibiting the free exercise thereof; or abridging the freedom of speech, or 
> of the press; or the right of the people peaceably to assemble, and to 
> petition the Government for a redress of grievances."
> 
> The Qt Community is not the US Congress (sadly, perhaps) or some instituation 
> legimized by the US Congress. We can therefore not “violate your right to 
> free speech”. Also, the right to free speech does not imply an obligation for 
> any- or everyone to listen to your speech, no matter the opinions or density 
> of profanities.
> 
> A community of people can not only decide not to listen, it can also easily 
> restrict your freedom of speech.

Well, you have people of various legal jurisdictions that have differing ideas 
on what they are allowed to say. Even the US constitution does not grant the 
right to yell "Fire!" in a crowded theater. However being of such a 
jurisdiction I am accustomed to having responsible speech being permitted. You 
are correct that no one has to listen, but I have the right to express it. The 
concern that I have is if certain measures are enacted, I will lose my ability 
to "speak" because someone was offended. It's a slippery slope I'd rather not 
contend with. There are two ways to resolve this: either 
1) Do not consider it, or
2) Define in excruciating detail, as to remove the "slippery" from the slope. 

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

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

> Sent: Thursday, October 25, 2018 at 11:13 AM
> From: "Edward Welbourne" 
> To: "Jason H" , "Mitch Curtis" 
> Cc: "Qt development mailing list" 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> Jason H (25 October 2018 16:43) contributed:
> 
> Mitch, you wrote:
> >> To me it seems like you guys are saying:
> 
> >>> "I don't care if this person treats me like crap because they sure
> >>> can code."
> 
> >> I'm happy for you if you've gotten this far in life and decided that
> >> you like being insulted in exchange for someone reviewing your code
> >> (or even just asking a question on IRC), but personally I do not like
> >> it. I'm more than capable of standing up for myself, but other people
> >> who feel the same way may not feel comfortable speaking out.
> 
> > I do not want to contemplate the emotional state of being of the
> > author when reviewing and leaving comments on gerrit.
> 
> I do want to encourage you to think about how you phrase your criticisms
> of others' code; in particular, by "contemplating the emotional state
> of" an author being so criticised (this is what empathy is about).
> 
> > Many times when I an giving technical feedback, I have been told "[I]
> > sound harsh." I'm just being factual.
> 
> Two ways of saying the same thing may have identical information content
> (i.e. they're both "just being factual"), yet have different emotional
> content.  One does not have to bend over backwards to treat folk gently:
> it is enough to just think about the ways of phrasing your feed-back
> that respectfully invite them to notice their error rather than just
> telling them they're wrong.  With practice, it comes quite naturally to
> think in terms of "what can I say that will give this person the same
> understanding I have" rather than just proving that you know better than
> them.
> 
> > I never call into the matter anything about the person,
> 
> There are more ways to wind people up than direct ad hominem attacks.
> Phrasing may hint that you think no-one but an idiot would fail to
> notice the thing you happen to know, that they don't.  You might not
> even intend that hint, but it may yet come across.  In particular, if
> you *do* think that only an idiot would fail to see what you're pointing
> out, please pause to remember that contributors to Qt seldom actually
> are idiots and think about what might lead a perfectly reasonable and
> smart person to be unaware of the thing you are so familiar with that
> you take it for granted.

As a personal strategy I completely agree with you. However I've been at this 
for 20 years and it's not anything I've made significant progress on. I do not 
want to offend anyone, though I'm sure I have, inadvertently. I give you my 
word that I'm not going to verbally abuse anyone. I am continually humbled by 
the people in this community. They are brilliant. I often learn from being 
wrong on this and the other Qt lists, so I recognise this community has people 
of all different levels of ability. I still do however take issue with the idea 
that I am somehow responsible for someone's reaction to a factual observation 
or suggestion. It creates a slippery slope of judgement, and it creates a 
concern that maybe I'll be approached and be told to use kinder words, even 
when no unkind or inaccurate terms were used.  I do however recognize that 
oser-use of violent profanity could turn people away. I do not know how to 
strike a balance. This is why I prefer to keep it all about the cod
 e. 

> > but some people still do get butt-hurt when you talk about their code
> > negatively because it is their art. They then can project that
> > criticism of the code onto themself. This is nothing I want to be in
> > the position of being responsible for. As long as my comments are
> > accurate and not unduly harsh, they are (or at least should be deemed)
> > appropriate.
> 
> Leaving aside whether this should or shouldn't be covered by a code of
> conduct, that is an attitude I feel I have a duty to challenge.  I am
> quite capable of forgetting that others can't keep up with some of what
> comes easily to me; and I have had decades of colleagues calmly pointing
> out to me that perhaps what's obvious to me might not be known by
> everyone else.  Eventually I learned to stop and think about whether
> what was obvious to me was, in fact, obvious to everyone else.  It turns
> out that, with the vast breadth and complexity of the world of software,
> that there are many of us who are used to taking for granted things that
> others don't know about; and, unless we stop to remin

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

Consolidated reply to multiple threads:

Mitch, you wrote: 
> To me it seems like you guys are saying:
>> "I don't care if this person treats me like crap because they sure can code."
> I'm happy for you if you've gotten this far in life and decided that you like 
> being insulted in exchange for someone reviewing your code (or even just 
> asking a question on IRC), but personally I do not like it. I'm more than 
> capable of standing up for myself, but other people who feel the same way may 
> not feel comfortable speaking out.

I do not want to contemplate the emotional state of being of the author when 
reviewing and leaving comments on gerrit. Many times when I an giving technical 
feedback, I have been told "[I] sound harsh." I'm just being factual. I never 
call into the matter anything about the person, but some people still do get 
butt-hurt when you talk about their code negatively because it is their art. 
They then can project that criticism of the code onto themself. This is nothing 
I want to be in the position of being responsible for. As long as my comments 
are accurate and not unduly harsh, they are (or at least should be deemed) 
appropriate.



Next, we have the notion that the CoC was somehow agreed to at the Contributors 
summit. This is not a just action, as the summit was for the privileged few who 
had:
1) funding and 
2) the allowable time away from work and life to attend 
3) to the location of the event. Not everyone has a passport and is able to 
obtain a visa.

As a member who wanted to attend but was not able to, I find the legitimacy of 
the vote questionable. I call for a vote (use gerrit?) on a measure to adopt a 
Code of Conduct, then if that passes, we can go on to debate what should be in 
it.



Next there is a notion of the CoC being applied to profanity. I am also against 
this. This would violate my right to free speech, and it would be so vague to 
be unenforceable. So far in this thread I've used the terms "shit-show" (I 
contemplated more severe terms, but decided against it) and "butt-hurt". These 
terms were appropriate to convey the meaning intended. Similarly, I have been 
following the idea of Political Correctness and if it is even effective. We've 
had 20 years and it looks like it does not work, and overall isn't appreciated. 
Even if we could agree on what is offensive it would vary across populations 
and people would still be offended unless the most neutered language was used. 



Volker,
You say your KDE CoC has "worked", but your KDE fellow demonstrated that in 
fact, it has not.


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

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

Thank you Edward.

I am doing that, but "out loud" if you will, on this group. I am asking 
questions and getting answers (you're the first to actually answer any of my 
questions).

I am committed to having a free and inclusive community, but with Linux Kernel 
just having gone through this, and the fall-out still on going, I personally 
would have us wait to see how that turns out before proceeding with our own. I 
would like to learn from their mistakes.

So far (but after your email was written) I replied with concerns about 
1) the Committee, 
-- the allocation of seats to specific birth demographics
-- the politics of said committee
 members having to embrace the politics of the said committee.
-- the personal weight of members being affected by their contributions, in 
terms of testimony or punishment. 
2) having received a message from someone who was pro-CoC, but whose message 
clearly in violation of the CoC.
-- If that is acceptable, then why have a CoC at all?

I'm asking a lot of questions and reading all the answers. I appreciate your 
substantive reply.

Here's an operable suggestion: Choose the committee members at random, per each 
incident, from the list active users at random. Keep choosing until 3 users 
have indicated they would participate. That would be the best way to avoid most 
of the concerns I questioned about.


> Sent: Wednesday, October 24, 2018 at 1:21 PM
> From: "Edward Welbourne" 
> To: "Jason H" 
> Cc: "development@qt-project.org" , "Ulf Hermann" 
> 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> Jason H (24 October 2018 17:09)
> > - Is "Sceintific racism" actual racism or just statistics?
> 
> If it's racism, it's racism, however qualified.
> Extrapolation from populations to individuals misuses statistics.
> It isn't scientific, it just abuses tools lifted out of science.
> 
> > I really want to know where we are with James Damore because I thought
> > his paper was well-researched with a scientific basis?
> 
> I had to look that name up.
> While no source is unbiased, I'll take [0] as a tolerable source.
> They do, at least, have a fairly solid understanding of what science is
> (and isn't).
> 
> * [0] https://rationalwiki.org/wiki/James_Damore
> 
> Apparently he fails to understand the difference between very minor
> statistical differences between broad populations and the details of
> individuals.
> 
> Specifically: though the proportion of women who are good at certain
> tech jobs might be marginally smaller than the proportion of men who
> are, a recruiter who has the economic power of Google and commits to
> recruiting equally should be able to do so, without compromising its
> recruitment standards, provided there aren't *other factors* at play
> that prevent it from doing so.  The crucial detail here is that Google
> employs a tiny proportion of the population from which it could draw
> recruits.  So half of Google's relevant technical staff - which is how
> many women Google would need to hire to meet the given goal - fits well
> within the available pool of suitably-skilled women.
> 
> Google would (in this hypothetical world) have to work a little harder
> and pay a little more (but it's only a little, since the statistical
> effect is quite small in fact) to find the women than to find the men,
> but it's not short of applicants and Google, in particular, has
> expertise in the field of selecting the best few from a plethora of
> candidates - at least when it comes to pointing one at web pages.  The
> fact that Google doesn't manage to hire equally many good women as men
> in various tech positions *is* evidence that there are other factors at
> play, aside from the scientific evidence of very minor differences in
> aptitude (mostly stemming from differences in interest).
> 
> It is, furthermore, patently clear that the world does have other
> factors that contribute to the gender divide in various jobs.  When
> boards are dominated by men, it is no great surprise that women aren't
> as widely represented in upper management, from the ranks of which most
> boards are drawn, to take just one example.
> But this is something of a digression.
> 
> > Having been interested in software from a very young age, and later
> > specifically Open Source, one thing that appealed to me was that it
> > was a meritocracy.
> 
> Well, many software practitioners at least aim to make software projects
> meritocratic.  However, their ability to do so may be compromised by
> social dynamics (and economics) in various ways.
> 
> > The best code survives, your code contributions are limited only by
> > your code being the best.
> 
> If those evaluating how good something is are,

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

Thank you Marco,

 

I've approached computers with a least-emotional approach.  But I beleive you when you said the highly emotional sometimes rude culture is driving people away. But I'll point out that we can be inclusive as we want to be. If we adopt a code of conduct, we then are are the ones applying an exclusionary approach. I don't think the Qt community is emotional or rude. I think it's a great community, one I've been a member of for some years now, and doesn't need any such system. But maybe in the future it will?

 

One claim you make is that it is driving people away. I don't see any evidence for this, but I'm willing to consider myself wrong here. Ok, so then what? Will the Code of Conduct (CC) rectify that? I think there's a lot that could occur that would not fall under CC that would drive people away, but of course there could be conduct  that the CC could cover. Great. Then we have to convene the Comittee. Now there is a body that is arbiter of people's interactions. Whereas without it, people are left to mediate themselves. But now you have an authority you cannot run afoul of. You also have an authority that can be exploited, manipulated. It's already been suggested that one seat be reserved for a non-cis-male, no sow we have to worry about identiarian politics of the comittee. But this authority will have it's own politics.  Aleix's message already foreshadowed the idea of some people having more weight or legitimacy than other people in the community. So now our social relationships - very probably influenced by in-real-life relationships will play a role. Does our git commit history get taken into the merit of our claims? Does it get taken into account for your punishment? Would the committee less likely to ban a prolific committer?

 

None of these questions need be answered or entertained if we do not adopt a formal CC. I perfer to cite Bill & Ted - "Be excellent to each other" and let the comminity police itself.  I don't think Qt is the kind of project to attract controversy. It's an open source project without politics. Well, at least it _was_.  

 

 

Sent: Wednesday, October 24, 2018 at 12:20 PM
From: "Marco Bubke" 
To: "Jason H" , "Ulf Hermann" 
Cc: "development@qt-project.org" 
Subject: Re: [Development] QUIP 12: Code of Conduct






Hallo Jason

 

> It was purely about lines of code. It was elegant and beautiful, and brutally simple.

 

This is aesthetics and if you would reflect about it with other you could find out that is very context sensitive. 

 

My experience in this area is that their are many people who prefer interaction with computer to interaction with different people.  Many people use a platonic language all the time without any reflection about the problems of that language. And this is creating friction, much friction, and not the kind of productive friction. Is it not nice to understand if  other people have a different aesthetic view of how code should look? 

 

It's my experience which is shaping my context. And I believe it's the same for you. So I think that our context is different. So if we work together should we not respect different contexts and try to understand them. Use that difference to create something better. Is that not better than connect our work with our self and let discussion easily get highly emotional? What do you think is the outcome of this culture? I don't believe that this highly emotional, sometimes rude, culture is creating the best source code! I think it is driving many talented people away.

 

Best, Marco



From: Development  on behalf of Jason H 
Sent: Wednesday, October 24, 2018 5:09:58 PM
To: Ulf Hermann
Cc: development@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

 



I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well.

Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD...

Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

1. The code of conduct or invitation to contribute says nothing about "earning 
a right"
2. What are considered qualifying "contributions"? I've been using Qt since 
2004. I assure you I've had some influence, be it bug reports, participating in 
the mailing lists (like now.) 
3. How many of these contributions do I need? How are they measured?
4. I was given the opportunity to contribute at this time by a open invite. I 
have accounts on the various services to be able to contribute. So I did.
5. I wonder if you have even read the proposal yourself. You seem very entitled 
to have an opinion, so I assume you would, but why then would you write a 
message that clearly is in violation of acceptable behavior? Lines 52, 53, 56.

   Examples of unacceptable behavior by participants include:   49
   50
   * The use of sexualized language or imagery and unwelcome sexual attention 
or advances   51
   * Trolling, insulting/derogatory comments, and personal or political attacks 
52
   * Public or private harassment   53
   * Publishing others’ private information, such as a physical or electronic 
address, without explicit 54
 permission 55
  * Other conduct which could reasonably be considered inappropriate in a 
professional setting  56

Your email raises several questions, and both of my eyebrows.
1. You seem to think that there is an "entitlement" mechanic at work. If so, we 
need to define that?
2. You seem to have a metric for "contributions" we need to define that?
3. How does your message contribute to a "positive environment"? 
Examples of behavior that contributes to creating a positive environment 
include:   41
42
* Using welcoming and inclusive language43
* Being respectful of differing viewpoints and experiences  44
* Gracefully accepting constructive criticism   45
* Focusing on what is best for the community46
* Showing empathy towards other community members

I didn't expect everyone to agree with me. But I did not expect your message to 
be the way it was.


> Sent: Wednesday, October 24, 2018 at 11:42 AM
> From: "Aleix Pol" 
> To: development 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Wed, Oct 24, 2018 at 5:10 PM Jason H  wrote:
> >
> > I am whole-heartedly against a Code of Conduct. While well-intentioned, 
> > anyone following the shit-show that is the Linux kernel code of conduct 
> > fiasco, I also think would be against the code of conduct as well.
> >
> > Immediately after imposing the Code of Conduct, past tweets by contributors 
> > and the accusations started flying and it devolved from there. In addition 
> > to several authorities on Open Source weighed in that yes, contributors can 
> > revoke the copyright of their prior contributions, which was threatened by 
> > those accused. Which would leave any software in a lurch. Now, it looks 
> > like those contributors might go to BSD...
> >
> > Having been interested in software from a very young age, and later 
> > specifically Open Source, one thing that appealed to me was that it was a 
> > meritocracy. The best code survives, your code contributions are limited 
> > only by your code being the best. Now we're saying it's not just your code, 
> > but also your behavior. We had an ideal, we had THE ideal - a place where 
> > only our ideas mattered. A place where nothing else mattered - not your 
> > gentatilia, your sexual identity, not your partner preference, not your 
> > political party - none of it. It was purely about lines of code. It was 
> > elegant and beautiful, and brutally simple. And now the social justice 
> > warriors are contaminating that perfection with code+conduct. So it goes 
> > from "this is the best code that could be written" to "this is the best 
> > code that could be written from an individual whose political ideals match 
> > our own".
> >
> > If we adopt this, does that mean there is a  [git commit hook| gerrit 
> > review] installed that evaluates the contributor's social media to find 
> > controversial posts?
> > If we adopt this, how do we assure we don't wind up in a Sarah Jeong 
> > situation (She's racist against white people, but the New York Times says 
> > that's "ok")?
> > - How do assure that white people are adequately protected against reverse 
> > racism?
> > -- Do we even agree that reverse racism [is possible to] exist(s)
> > If we adopt this, what exactly are the political ideas a Qt contributor 
> > must espouse?
> > - Are stances against illegal immigration "racist"?
> > - Is "Sceintific racism" actual racism or just statistics

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

Under the Code of Conduct, Can Aleix Pol receive discipline for his/her/their 
message?
 

> Sent: Wednesday, October 24, 2018 at 11:42 AM
> From: "Aleix Pol" 
> To: development 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Wed, Oct 24, 2018 at 5:10 PM Jason H  wrote:
> >
> > I am whole-heartedly against a Code of Conduct. While well-intentioned, 
> > anyone following the shit-show that is the Linux kernel code of conduct 
> > fiasco, I also think would be against the code of conduct as well.
> >
> > Immediately after imposing the Code of Conduct, past tweets by contributors 
> > and the accusations started flying and it devolved from there. In addition 
> > to several authorities on Open Source weighed in that yes, contributors can 
> > revoke the copyright of their prior contributions, which was threatened by 
> > those accused. Which would leave any software in a lurch. Now, it looks 
> > like those contributors might go to BSD...
> >
> > Having been interested in software from a very young age, and later 
> > specifically Open Source, one thing that appealed to me was that it was a 
> > meritocracy. The best code survives, your code contributions are limited 
> > only by your code being the best. Now we're saying it's not just your code, 
> > but also your behavior. We had an ideal, we had THE ideal - a place where 
> > only our ideas mattered. A place where nothing else mattered - not your 
> > gentatilia, your sexual identity, not your partner preference, not your 
> > political party - none of it. It was purely about lines of code. It was 
> > elegant and beautiful, and brutally simple. And now the social justice 
> > warriors are contaminating that perfection with code+conduct. So it goes 
> > from "this is the best code that could be written" to "this is the best 
> > code that could be written from an individual whose political ideals match 
> > our own".
> >
> > If we adopt this, does that mean there is a  [git commit hook| gerrit 
> > review] installed that evaluates the contributor's social media to find 
> > controversial posts?
> > If we adopt this, how do we assure we don't wind up in a Sarah Jeong 
> > situation (She's racist against white people, but the New York Times says 
> > that's "ok")?
> > - How do assure that white people are adequately protected against reverse 
> > racism?
> > -- Do we even agree that reverse racism [is possible to] exist(s)
> > If we adopt this, what exactly are the political ideas a Qt contributor 
> > must espouse?
> > - Are stances against illegal immigration "racist"?
> > - Is "Sceintific racism" actual racism or just statistics?
> > -- In a matter closer to home, where are we on James Damore situation? 
> > Would he be banned from this community?
> >
> > NONE of those questions should need to be contemplated by an Open Source 
> > software project. Open Source is about the Source. Not the source of the 
> > Source.
> >
> > In case it needs to be said-
> > I am AGAINST racism, sexism, bigotry, and all the other exclusionary 
> > things. But I am also against people judging other people's code for 
> > factors that have nothing to do with the code itself. I find that adding a 
> > value judgement of conduct to code to be intolerant. We had the ideal.
> > I am FOR inclusion. I want everyone to feel welcome here. Everyone.
> >
> > We might identify as a "community" as we are people, but really we're an 
> > open source project, and at the end of the day what matters the most is 
> > what is in git.
> >
> > I oppose any Code of Conduct. And demand the answers be provided to the 
> > above questions PRIOR to passage (if it happens).
> >
> > I really want to know where we are with James Damore because I thought his 
> > paper was well-researched with a scientific basis?
> >
> >
> >
> > > Sent: Wednesday, October 24, 2018 at 3:17 AM
> > > From: "Ulf Hermann" 
> > > To: "development@qt-project.org" 
> > > Subject: [Development] QUIP 12: Code of Conduct
> > >
> > > Hi,
> > >
> > > regarding our earlier discussions on a possible Code of Conduct, here as
> > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > > necessary rules and definitions:
> > >
> > > https://codereview.qt-project.org/243623
> > >
> > > Please review it.
> > >
> > > regards,
> > > Ulf
> 
> Dear Jason,
> I fai

Re: [Development] QUIP 12: Code of Conduct

[Jason H]

I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone 
following the shit-show that is the Linux kernel code of conduct fiasco, I also 
think would be against the code of conduct as well.

Immediately after imposing the Code of Conduct, past tweets by contributors and 
the accusations started flying and it devolved from there. In addition to 
several authorities on Open Source weighed in that yes, contributors can revoke 
the copyright of their prior contributions, which was threatened by those 
accused. Which would leave any software in a lurch. Now, it looks like those 
contributors might go to BSD...

Having been interested in software from a very young age, and later 
specifically Open Source, one thing that appealed to me was that it was a 
meritocracy. The best code survives, your code contributions are limited only 
by your code being the best. Now we're saying it's not just your code, but also 
your behavior. We had an ideal, we had THE ideal - a place where only our ideas 
mattered. A place where nothing else mattered - not your gentatilia, your 
sexual identity, not your partner preference, not your political party - none 
of it. It was purely about lines of code. It was elegant and beautiful, and 
brutally simple. And now the social justice warriors are contaminating that 
perfection with code+conduct. So it goes from "this is the best code that could 
be written" to "this is the best code that could be written from an individual 
whose political ideals match our own". 

If we adopt this, does that mean there is a  [git commit hook| gerrit review] 
installed that evaluates the contributor's social media to find controversial 
posts?  
If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation 
(She's racist against white people, but the New York Times says that's "ok")?
- How do assure that white people are adequately protected against reverse 
racism?
-- Do we even agree that reverse racism [is possible to] exist(s)
If we adopt this, what exactly are the political ideas a Qt contributor must 
espouse? 
- Are stances against illegal immigration "racist"?
- Is "Sceintific racism" actual racism or just statistics? 
-- In a matter closer to home, where are we on James Damore situation? Would he 
be banned from this community?

NONE of those questions should need to be contemplated by an Open Source 
software project. Open Source is about the Source. Not the source of the Source.

In case it needs to be said-
I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. 
But I am also against people judging other people's code for factors that have 
nothing to do with the code itself. I find that adding a value judgement of 
conduct to code to be intolerant. We had the ideal.
I am FOR inclusion. I want everyone to feel welcome here. Everyone. 

We might identify as a "community" as we are people, but really we're an open 
source project, and at the end of the day what matters the most is what is in 
git.

I oppose any Code of Conduct. And demand the answers be provided to the above 
questions PRIOR to passage (if it happens). 

I really want to know where we are with James Damore because I thought his 
paper was well-researched with a scientific basis?
 


> Sent: Wednesday, October 24, 2018 at 3:17 AM
> From: "Ulf Hermann" 
> To: "development@qt-project.org" 
> Subject: [Development] QUIP 12: Code of Conduct
>
> Hi,
> 
> regarding our earlier discussions on a possible Code of Conduct, here as 
> well as at the Contributors' Summit 2017, I've pushed a QUIP with the 
> necessary rules and definitions:
> 
> https://codereview.qt-project.org/243623
> 
> Please review it.
> 
> regards,
> Ulf
> ___
> 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] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI?

[Jason H]

+1. Make sure that you are accounting for the full font height, see 
QFontMetrics::ascent() and descent()


> Sent: Wednesday, October 17, 2018 at 1:23 PM
> From: "Allan Sandfeld Jensen" 
> To: development@qt-project.org
> Subject: Re: [Development] Why on Linux using FreeType engine fonts are 
> rendered in 72 dpi instead of Screen DPI?
>
> On Mittwoch, 17. Oktober 2018 19:10:45 CEST Tomasz Olszak wrote:
> > Could you please try example I sent on Linux and explain why font size
> > doesn't match rectangle size? Maybe the ft font engine has bug?
> > 
> Try putting a capital Å or any other capital with accents in your example, 
> and 
> you will see that it fits snugly.
> 
> Though it should be noted fonts are a bit inconsistent in what they consider 
> their heights, some use the capital-height as their height, some use the 
> maximum including accents. I believe we normally always render text with the 
> leading on top, so there is room for all the Latin-1 characters and the 
> results are always the same.
> 
> 'Allan
> 
> 
> ___
> 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] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI?

[Jason H]

A pixel is a pixel, regardless of DPI.

However things matter when you use point sizes (which assumes 72 points per 
inch) there are also Screen.devicePixelRatio  ( 
http://doc.qt.io/qt-5/qml-qtquick-window-screen.html#devicePixelRatio-attached-prop
 ) to contend with. I haven't had to worry about this for some time, so my 
intel may be out of date. It was a mess around 5.6...

I'm assuming the 72 has something to do with the point size, and being able to 
calculate scaling relative to 72. 


> Sent: Wednesday, October 17, 2018 at 11:59 AM
> From: "Tomasz Olszak" 
> To: development@qt-project.org
> Subject: [Development] Why on Linux using FreeType engine fonts are rendered 
> in 72 dpi instead of Screen DPI?
>
> Hi,
> 
> I would like just to ensure that I missed something and there is
> documentation somewhere informing that Linux fonts are rendered
> *always* in 72 dpi
> (https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Set_Char_Size)
> (which makes font.pixelSize inaccurate for regular screens).
> 
> I found: https://bugreports.qt.io/browse/QTBUG-8890 which fixes the
> problem but it was rejected. I see the default 72 dpi is also used in
> current Qt 5.11 FT engine
> (https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/freetype/qfontengine_ft.cpp.html#297).
> 
> Does it surprise any of Qt developers or is it only me? Am I right
> thinking that when we do following:
> Rectangle {
>height: 100
>Text {font.pixelSize: 100}
> }
> then the relation between height of text and height of rectangle will
> differ depending on screen dpi (don't have a way to test it
> currently)?
> 
> Moreover I'm pretty sure that's the cause I very often use
> Text.fontSizeMode: Text.Fit  because setting pixelSize to height of
> desired text size never worked correctly :)
> 
> tl;dr: Is it a bug?
> ___
> 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 Android Service

[Jason H]

I would not attribute this to Qt without a thorough investigation. My only use of serves on Android was a Qt app with a normal Android service. As I understand it, you can't have both Qt App and service in the same app. Something simple like a manifest error is more likely the issue, but without more detail, helping is impossible.

 

 

Sent: Friday, October 12, 2018 at 9:49 AM
From: "Mikhail Svetkin" 
To: denis.shien...@gmail.com
Cc: development@qt-project.org
Subject: Re: [Development] Qt Android Service


I have tried a year ago. It was ok, but unfortunately i don't remember version of Qt.
 




Best regards,
Mikhail



 


On Fri, 12 Oct 2018 at 15:45, Denis Shienkov  wrote:





Hi guys.

 

Does anybody tried to create and start the Android Service using Qt?

 

I tried this example:

 

* https://github.com/bbernhard/qtandroidservices_example ,

 

and also have read this reccomendations from KDAB:

 

* https://www.kdab.com/qt-android-create-android-service-using-qt/

 

But a service do not start at all.

 

I use Qt 5.11.2.

 

Is it possible at all, or it broken as usual in Qt?

 

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



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

Re: [Development] QML API Review

[Jason H]

Is this why in Qt Creator some very basic things and non basic things are 
underlined/don't autocomplete on various platforms?

Ex: (on iOS)
import QtQuick 2.11
import QtQuick.Window 2.11 // QML module not found(...)
import QtWebView 1.1   // QML module not found(...)
import QtMultimedia 5.9// QML module not found(...)
import QtSensors 5.11  // QML module not found(...)

I'd have thought by now that these modules would be found.

In addition, QtSensors will auto-complete, but Creator only offers up to 
version 5.9.

It's a similar situation on Android.

Would this fall under the API review?



> Sent: Friday, August 31, 2018 at 7:39 AM
> From: "Kai Koehne" 
> To: "development@qt-project.org" 
> Subject: [Development] QML API Review
>
> Hi,
> 
> In addition to the C++ API review that Edward has been pushing, we also need 
> to review new/changed QML API.
> 
> Most of our QML API is actually defined in C++, so one way to review them is 
> diffing the corresponding .h files; however, because they are private (in the 
> C++ sense), every module is free to place these files in different locations. 
> It also misses the information on how exactly the type is registered in the 
> end (think of qmlRegisterXXX).
> 
> Fortunately, we have another way to inspect QML API: The plugins.qmltypes 
> files that every plugin is supposed to ship alongside. The prime use of these 
> files is to make syntax highlighting and code completion in Qt Creator 
> possible. However, it turns out it's also a very concise way of reviewing new 
> API, so let's use it for that .
> 
> The .qmltypes files need to be updated manually. I've now run the update for 
> all the .qmltypes files I could find and upload the change for review (see 
> also https://bugreports.qt.io/browse/QTBUG-70264 and linked patches). I 
> suggest to use these patches as the basis for reviewing the QML API. 
> Different from C++, I suggest that if you're happy with the API, please +2 it 
> - The patch will actually be merged in the end.
> 
> Note that some the plugins.qmltypes files got updated in between, and 
> therefore the patches do not show the full diff to version 5.11. Other 
> plugins.qmltypes files didn't see an update in 5.11, something we should 
> really avoid in the future ☹ In these cases a separate review might be 
> necessary.
> 
> Anyhow, it turns out that most developers don't update the plugins.qmltypes 
> files, so I suggest to establish this as the new norm, and update them only 
> before the release, as part of the API review process.
> 
> An alternative would be to make sure that the .qmltypes files are up to date 
> directly before the API review, and include them as part of the C++ diff. 
> Anyhow, this would require us to _not_ instantly fix things in the .qmltypes 
> file when it gets updated, but first check in the plugins.qmltypes file as is 
> - something that can be difficult to accept. So maybe it's just easier to 
> have this as separate diffs.
> 
> Regards
> 
> Kai
> 
> PS: I intend to codify this 
> http://quips-qt-io.herokuapp.com/quip-0010-API-review.html , but first wanted 
> to establish a consensus.
> 
> --
> Kai Koehne, Senior Manager R | The Qt Company
> 
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
> HRB 144331 B
> 
> The Future is Written with Qt
> www.qtworldsummit.com
> 
> ___
> 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