Re: [Development] Qt 6.2.6 LTS Commercial released

[Albert Astals Cid]

El dimecres, 28 de setembre de 2022, a les 21:23:57 (CEST), Lorn Potter va 
escriure:
> On 27/9/2022 9:28 pm, Konstantin Ritt wrote:
> > Please stop announcing this kind of updates through the development
> > mailing list!
> 
> Please do *not* stop sending releasing information emails on this list.
> I kinda like knowing about them.
> 
> Release information, regardless of open source or commercial licensing,
> is relevant to Qt development, even if you are an open source purist
> and/or understand the realities of the software industry.

If you want to learn about release announcements of Qt, you should subscribe 
to the list that precisely is about release announcements of Qt.

https://lists.qt-project.org/listinfo/announce

Best Regards,
  Albert



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

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

[Albert Astals Cid]

El dissabte, 24 de setembre de 2022, a les 12:45:00 (CEST), Tor Arne Vestbø va 
escriure:
> > On 23 Sep 2022, at 19:21+02:00, Gaurav Guleria 
> > wrote:
 
> > As far as I know, the CUPS is currently implemented in Qt at two different
> > places: src/plugins/printsupport/cups/ and directly within the dialog
> > src/printsupport/dialogs/qprintdialog_unix.cpp. By implementing CPDB
> > support as a plugin, does it mean that we create a similar
> > src/plugins/printsupport/cpdb which uses CPDB to enumerate printers
> > instead of CUPS? If so, what about the unix print dialog, don't we need
> > to add the CPDB code there too (#if QT_CONFIG(cpdb) ... #endif
> > constructs, just like CUPS)?
> 
> The QCupsJobWidget is documented as "a widget to add to QPrintDialog to
> enable extra CUPS options such as Job Scheduling, Job Priority or Job
> Billing”, so I don’t think having any CPDB specific code in the UNIX print
> dialog is required as a first step to bring a CPDB print backend up.
 
> Once we get to that point we can look at possibly adding new API for the
> print engines to deal with the needs of QCupsJobWidget and the like, so
> that we don’t need CUPS/CPDB specifics in the dialog code.

The "problem" is not QCupsJobWidget, but the print dialog itself.

qprintdialog_unix.cpp and qpagesetupdialog_unix.cpp are full of
  #if QT_CONFIG(cups)

IMHO for now the same solution of adding ifdefs should be accepted for CPDB.

Ideally in the future an abstraction so that those ifdefs are not needed 
should be introduced, but I have the feeling that asking that abstraction to 
be added now is a bit of "asking too much".

Cheers,
  Albert

 > Cheers,
> Tor Arne
> 
> 
> > 
> > On 9/19/22 21:59, Tor Arne Vestbø wrote:
> > 
> >> 
> >> 
> >>> On 19 Sep 2022, at 18:21, Till Kamppeter 
> >>> wrote:
> >>> 
> >>> On 19/09/2022 15:43, Tor Arne Vestbø wrote:
> >>> 
> > First is to create a new Qt print backend, what, instead of
> > communicating directly with CUPS, communicates with the CPDB
> > backends. It is some kind of "middle end", on one end being a Qt
> > print backend and on the other end being a CPDB frontend.''
 
>  This sounds like a good first step. It doesn’t involve any of the GUI
>  bits, just the enumeration and communication with the various
>  CPDB-exposed printers.
 Since the QtPrintSupport module doesn’t depend
>  on DBUS today (AFAIK), the CPDB print backend should be a plugin. 
> >>> 
> >>> OK, Gaurav so you should be able to provide the CPDB support as a plugin
> >>> (Tor, is this a Qt print backend like the one for CUPS for example?).
>> 
> >> Correct. Note that for Qt 6, some of the print engines that were
> >> previously plugins were moved into the QtPrintSupport library directly,
> >> such as the macOS print engine, but the interface for enumerating these
> >> from Qt’s point of view is still as print engine “plugins”. The CUPS
> >> engine is a fully standalone plugin, so it’s a good basis for the CPDB
> >> work.
 
> >> Cheers,
> >> Tor Arne
> >> 
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development




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

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

[Albert Astals Cid]

El dilluns, 19 de setembre de 2022, a les 14:59:46 (CEST), Shawn Rutledge va 
escriure:
> On 2022 Sep 19, at 12:38, Till Kamppeter
> mailto:till.kamppe...@gmail.com>> wrote:
 
> On 16/09/2022 08:32, Shawn Rutledge wrote:
> But Qt has its own D-Bus implementation, so we tend to prefer using that,
> rather than using some external library that uses some other library that
> talks to D-Bus.  But if you really want to use the library, maybe /that/
> could be a reason to do dynamic loading?
 
> A re-implementation of the frontend part of CPDB with Qt's D-Bus
> implementation to overcome the need of two different libraries for D-Bus
> access in the whole Qt print dialog would lead to a maintenance overhead.
> Any change in the D-Bus interface in the original OpenPrinting
> implementation needs to get reflected in the Qt implementation.
 
> Yes, but do you think it needs any changes?  It’s been a few years.  The
> D-Bus interface is a kind of contract, usually you want to be sure you got
> that right.
 
> We still don’t have a print dialog in Qt Quick Dialogs, and I think we need
> to add one within the next couple of years (if we get around to defining
> how printing is supposed to work; I have a reasonable idea for that, I
> think, but nobody has implemented anything like that AFAIK).  So we do need
> a nice interface, suited to implementing that kind of dialog.
 
> And what is the print dialog we see opened by Qt/KDE apps then? Where does
> it come from?
 
> Have you seen a Qt Quick print dialog?  Most likely it’s still only widget
> applications that have printing functionality, and use QPrintDialog or the
> one that’s described here:
> https://techbase.kde.org/Development/Tutorials/Printing_Print_Dialog  But I
> don’t know for sure.

There has not been a KDE print dialog for decades at this point that tutorial 
is KDE 4 and it still basically gave you a regular QPrintDialog with 
potentially some custom tabs.

https://invent.kde.org/unmaintained/kdelibs/-/blob/KDE/4.14/kdeui/dialogs/kdeprintdialog.cpp#L44

Cheers,
  Akbert


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

Re: [Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released

[Albert Astals Cid]

El dijous, 8 de setembre de 2022, a les 23:23:00 (CEST), Thiago Macieira va 
escriure:
> On Thursday, 8 September 2022 14:06:24 PDT Albert Astals Cid wrote:
> > Should we restore those symbols or just accept that Qt 6 broke BC a year
> > ago and no one realized so why bring the symbols back?
> 
> The commit message says
> 
> Remove the dead code for blocking methods from QtConcurrent
> 
> After 79fd1cb2c631b6084bf10874205d27f5b53c907a the methods for running
> QtConcurrent algorithms in the blocking mode aren't used anymore. Since
> ThreadEngineBase and ThreadEngineStarter classes aren't meant to be used
> externally, it should be fine to remove startBlocking() methods now.
> 
> ThreadEngineBase is used only by ThreadEngine, plus its static
> ThreadEngineBase::threadPool is used by IterateKernel::forThreadFunction().
> But ThreadEngine is a template class deriving from ThreadEngineBase, and
> IterateKernel is a template class deriving from ThreadEngine and that is in
> turn a base class for a lot of other classes.
> 
> Therefore, ThreadEngineBase is used by user code, only indirectly.
> 
> So the question is whether the removed function was ever callable in
> QtConcurrent from 6.0 to 6.3. The commit this commit refers to landed in
> 6.0. So if the commit message is correct, then there's no problem in Qt 6,
> because if something still called this function, it would have broken in
> this commit.
> 
> According to the Git log, 1bf75f2a661c05c7f1126187310d7df3f9704af5 is the
> only commit since Git tag v6.0.0 that touches a line that mentions
> "startBlocking". Therefore, there is no BC problem in Qt 6.

Oh, sorry for the noise.

I did not realize 1bf75f2a661c05c7f1126187310d7df3f9704af5 and 
79fd1cb2c631b6084bf10874205d27f5b53c907a where so apart in time.

"Good", then the only issue is in Qt 5.15.6

I've reverted the patch removing those functions in the KDE Qt Patch 
collection to restore BC,  those that care about BC are welcome to use it.

Cheers,
  Albert


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

[Development] Binary incompatible change in QtConcurrent - was - Re: Qt 5.15.6 Opensource released

[Albert Astals Cid]

El dimecres, 7 de setembre de 2022, a les 14:16:23 (CEST), Tarja Sundqvist va 
escriure:
> Hi all,
> 
> 
> 
> we have released Qt 5.15.6 opensource today:
> 
> 
> 
>   *   release note:
> https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.6/release-note.
> md *   source packages in download.qt.io:
>  *   https://download.qt.io/official_releases/qt/5.15/5.15.6/
>  *  
> https://download.qt.io/official_releases/QtForPython/pyside2/PySide2-5.15.6
> -src/ *   Git: clone the release with the tag v5.15.6-lts-lgpl
> 

This Qt release comes with a binary incompatible change in this commit
   
https://code.qt.io/cgit/qt/qtbase.git/commit/src/concurrent?h=v5.15.6-lts-lgpl=4d6752e8d2ed9d303befe7adf7f6e4b6ba16bbb9

Example of that symbol being used in the wild

$ nm -D -C /usr/lib/qt/plugins/ktexteditor/kateprojectplugin.so | grep -i 
startBlocking
 U QtConcurrent::ThreadEngineBase::startBlocking()@Qt_5

This is due to the code calling QtConcurrent::blockingMap and blockingMap using 
startBlocking from a template.

This binary incompatible change also existed in the Qt 6.3 release in the shape 
of commit 1bf75f2a661c05c7f1126187310d7df3f9704af5

I guess there's no one using Qt 6.x that cares about Binary Compatibility so it 
wasn't found.

Should we restore those symbols or just accept that Qt 6 broke BC a year ago 
and no one realized so why bring the symbols back?

Cheers,
  Albert

> 
> Best regards
> 
> Tarja Sundqvist
> 
> Release manager




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

Re: [Development] [Announce] Security advisory: Freetype in Qt

[Albert Astals Cid]

El divendres, 19 d’agost de 2022, a les 18:13:15 (CEST), Volker Hilsheimer va 
escriure:
> > On 19 Aug 2022, at 16:28, Albert Astals Cid  wrote:
> > In case you don't understand what i am speaking about, i mean the Qt 5.15
> > patch corresponding to
> > https://code.qt.io/cgit/qt/qtbase.git/commit/src/3rdparty/freetype?id=cfa
> > 631e0fb5d78aac80cb580eb092fafa1cd9a8f which you didn't mark as Pick-to:
> > 5.15 but from reading the CVE-2022-27404-27405-27406-qtbase-5.15.diff
> > patch it's clear you did.
> 
> 
> There is no patch that upgrades the freetype version 2.10.1 that is bundled
> with Qt 5.15.5 to freetype 2.12.1.
 
> Someone has to sit down and cherry-pick
> https://codereview.qt-project.org/c/qt/qtbase/+/422316 down to the publicly
> available Qt 5.15 branch. This can perhaps skip over the intermediate
> upgrade to freetype 2.10.4. I’ve attached Liang's patch that upgraded
> freetype from 2.10.1 to 2.10.4 in the Qt 5.15 branch, so whoever wants to
> pick this up can see if that helps with creating a consolidated patch.
 
> I assume that the Qt5 patch collection infrastructure that the KDE community
> maintains is exactly designed for making such a consolidated patch
> available and rebasing it e.g. 5.15.6 when that becomes available.
 
> Chances are that I simply didn’t understand that you have basically been
> asking and waiting for the 5.15 version of
> cfa631e0fb5d78aac80cb580eb092fafa1cd9a8f. Apologies if that signal got lost
> in the duststorm of this email thread.

Yes, i wanted the cfa631e0fb5d78aac80cb580eb092fafa1cd9a8f version of 5.15. I 
now realize no special "version" of that patch is needed since that patch 
applies and builds fine in 5.15 already.

So as a summary anyone that finds themselves that they can't apply 
https://download.qt.io/official_releases/qt/5.15/CVE-2022-27404-27405-27406-qtbase-5.15.diff
 to their Qt 5.15 they just need to apply 
https://code.qt.io/cgit/qt/qtbase.git/commit/src/3rdparty/freetype?id=cfa631e0fb5d78aac80cb580eb092fafa1cd9a8f
 first and all will be good.

Cheers,
  Albert

 
> Volker
> 
> 
> 




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

Re: [Development] [Announce] Security advisory: Freetype in Qt

[Albert Astals Cid]

El divendres, 19 d’agost de 2022, a les 11:35:51 (CEST), Volker Hilsheimer va 
escriure:
> Back from holidays, following up on the open points from this thread after
> discussing within The Qt Company:
>
> [snip] 
> 
> The agreement with KDE is that the exact version of Qt that was released as
> commercial LTS is made available as a source-only package, with one year
> delay. 

Calling it "an agreement" is a mischaracterization as if KDE thought that was 
good idea. 

We think it's a terrible idea that has undoubtedly worsened the reputation of 
Qt both between its users and its developers (as we predicted) and I sincerely 
doubt you sold enough licenses to recoup all the development work TQC had to do 
to create all those private branches you use, if at all i would expect a loss 
in licenses since projects started moving away from Qt to other libraries that 
don't punish their users.

The Qt Company is only doing those releases 12 month later releases because it 
is the bare minimum mandated by the KDE Free Qt Foundation contract.

> So, the Qt 5.15.6 source package in September will be exactly what
> customers got as Qt 5.15.6, including a bundled freetype with
> vulnerabilities.

It makes me super sad that the Qt Project maintainer can say that the latest 
available version of one of its products (Qt5) has a known exploitable 
vulnerability and pretend all is good.

Even worse when those patches to fix that vulneravility exist and would cost 5 
minutes for you to put online, but still refuse to provide them to punish us 
for using your product.

In case you don't understand what i am speaking about, i mean the Qt 5.15 patch 
corresponding to 
https://code.qt.io/cgit/qt/qtbase.git/commit/src/3rdparty/freetype?id=cfa631e0fb5d78aac80cb580eb092fafa1cd9a8f
which you didn't mark as Pick-to: 5.15 but from reading the 
CVE-2022-27404-27405-27406-qtbase-5.15.diff patch it's clear you did.

> This might make little sense, but it makes little sense to make a 5.15.6
> that is different either, or a 5.15.6.2 with some patches applied. 

Nobody is asking you to release a 5.15.6.2 version, we are just asking you to 
provide a security patch that applies.

> People
> can clone 5.15.6 from git, and people download and build software against
> old versions of Qt all day long, accepting that security patches or
> critical fixes might be missing.

Ah yes, the "everyone jumped from the bridge so i did too" excuse... 

Also please do not conflate security patches together with critical fixes.  

There's very little room for "critical fixes" that can be applied to Qt 5.15 
it's been released for years, used in lots of places for lots of people and 
generally "it works", people generally can live without "those fixes".

Security issues on the other side are corner case scenarios and usually mean 
some very nefarious things can happen, so yes people need them. 

> Since the LGPL source package of Qt 5.15.6 need to be configured and built
> explicitly anyway, follow Thiago’s recommendation to use system libraries
> whenever possible.

And when not possible, you will get exploited :)

INSERT DOG IN HOUSE ON FIRE MEME

Albert 

> 
> 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] [Announce] Security advisory: Freetype in Qt

[Albert Astals Cid]

El dijous, 28 de juliol de 2022, a les 18:13:02 (CEST), Volker Hilsheimer va 
escriure:
> The agreement is that KDE maintains patches like this for Qt 5 so that they
> are available on top of the branches that are available to the Open Source
> community.
 
> https://dot.kde.org/2021/04/06/announcing-kdes-qt-5-patch-collection
> 
> This might require back-porting relevant patches from the LTS branch, to
> which relevant people from the KDE community should have access. 

The only patch we (KDE people) have is the one that was published with the 
advisory (the one that that that doesn't apply to the 5.15.6 sources).

Not sure which other patches you expect us to have access to, but we don't.

Cheers,
  Albert


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

Re: [Development] [Announce] Security advisory: Freetype in Qt

[Albert Astals Cid]

El dimecres, 27 de juliol de 2022, a les 14:00:50 (CEST), List for 
announcements regarding Qt releases and development va escriure:
> Hi,
> 
> There have been three vulnerabilities found in FreeType recently and they
> have been assigned the CVE ids CVE-2022-27404, CVE-2022-27405,
> CVE-2022-27406. This has been fixed in the latest version of FreeType –
> v2.12.1


> 5.15:
> https://download.qt.io/official_releases/qt/5.15/CVE-2022-27404-27405-27406
> -qtbase-5.15.diff 

This patch doesn't seem to apply over the v5.15.5-lts-lgpl tag for me, can 
someone please double check in case I'm doing something wrong?

Best Regards,
  Albert

> Kind regards,
> Andy
> --
> Andy Shaw
> The Qt Company
> 
> ___
> Announce mailing list
> annou...@qt-project.org
> https://lists.qt-project.org/listinfo/announce




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

Re: [Development] "*|All Files" as filter for QFileDialog

[Albert Astals Cid]

El diumenge, 26 de juny de 2022, a les 11:07:17 (CEST), Volker Hilsheimer va 
escriure:
> > On 26 Jun 2022, at 02:28, Marius P  wrote:
> > 
> > Hello,
> > 
> > From what I can see, "*|All Files" does not work as filter for QFileDialog
> > if using the Qt file open dialog, not the KDE file open dialog. I am on
> > Kubuntu 22.04. The file open dialog says that I have  zero files in the
> > directory.
 Screenshot
> > https://drive.google.com/file/d/1AW3cMtEggfniVI0jNtR3Fx6iMBidLa-W E.g.
> > https://invent.kde.org/multimedia/kmplayer/-/merge_requests/2 The Qt
> > documentation says that the syntax "*|All Files"is invalid. E.g.
> > https://doc.qt.io/qt-5/qfiledialog.html#getOpenFileNames 
> > Question: should the non KDE, Qt file open dialog support a syntax like
> > "*|All Files"? Or should I fix more than 12 KDE apps?
 
> > Thanks.
> 
> 
> Odd, would be interesting to understand how KFileDialog ended up with a
> different filter syntax than Qt (where I don’t think it’s ever been
> anything else than what it is today).
 
> But I see no reason why Qt couldn’t support the filter syntax documented for
> KFileDialog [1]

Honestly I don't think this makes sense.

Using KFileWidget syntax (KFileDialog is deprecated since lots of years) on a 
QFileDialog is just wrong and the code should be fixed.

Cheers,
  Albert

> other than that it introduces a bit of complexity to the
> code. I suppose we could detect a ‘|’ or '\n’ in the filter string and then
> implement a different splitting logic in qt_make_filter_list. As long as
> the QStringList returned from that function is the same for either syntax,
> the rest of the Qt code an integration with native dialogs shouldn’t
> require any changes.
 
> Feel free to propose a patch for that.
> 
> Volker
> 
> [1]
> https://api.kde.org/legacy/pykde-4.2-api/kio/KFileDialog.html#obj3064034764
> 
 
> ___
> 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 Chief Maintainer

[Albert Astals Cid]

El divendres, 17 de juny de 2022, a les 10:32:15 (CEST), Lars Knoll va 
escriure:
> Hi everbody,
> 
> The voting period for the new Chief Maintainer has ended yesterday. I’m
> really happy to say that we have elected a new Chief Maintainer.
 
> Before getting to the results, I’d like to thank both candidates for
> stepping up and their willingness to take over the role.
 
> The vote ended with 24 votes for Volker and 18 for Allan.
> 
> You can see the results of the vote at
> https://governancevoting.qt-project.org/voting and also check there that
> your own vote was registered correctly.
 
> We will also publish a slightly longer blog post on Monday to make the
> change more widely known.
 
> 
> This means Volker Hilsheimer will be our new Chief Maintainer.
> Congratulations!

Congratulations to Volker! 

And thanks to Allan for running :)

Cheers,
  Albert
 
> Volker, I would like to wish you good luck with leading the project. I know
> that the Qt project is going to be in very good hands with you.
 
> Finally, I’d like to thank you all for supporting me as the (old) Chief
> Maintainer throughout the years. It’s been an honour to lead the Qt Project
> since we established it in 2011.
 
> 
> Cheers,
> Lars
> 




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

[Development] Can my name sorting be fixed in the release notes?

[Albert Astals Cid]

Speaking about
https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/6.3.0/release-note.md 

It sorts me by my second surname (Cid) instead of by my first surname (Astals).

Is this something that can be fixed without being super complicated?

It's not super important but it would make me feel a bit happier :)

Cheers,
  Albert

P.S: https://en.wikipedia.org/wiki/Surname#Spanish-speaking_world


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

Re: [Development] Chief Maintainer election

[Albert Astals Cid via Development]

El dijous, 2 de juny de 2022, a les 11:46:45 (CEST), Lars Knoll va escriure:
> Hi all,
> 
> The nomination period for the Qt Chief Maintainer election ended yesterday
> night.
 
> I’m very happy to say that we have two excellent candidates for the position
> with Allan and Volker. Both have been working with Qt for many years and
> know it extremely well. I am certain that whoever of the two will get
> elected will be doing a very good job, so I know already now that Qt will
> be in very good hands moving forward.
 
> But since not all of you might know Volker and Allan very well, I’ve asked
> them to send an email presenting themselves and what they consider
> important for Qt and the role of the Chief Maintainer moving forward. So
> you will get a bit more of an impression from them during the day.
 
> Elections will run from 3rd of June (starting at midnight CEST), until the
> end of the 16th of June (23:59 CEST). Everybody that is part of the
> Maintainer group on Gerrit
> (https://codereview.qt-project.org/admin/groups/a60ed457f6e3833c81023c72743
> ba73c7e23fb09,members) is eligible to cast a vote.

I don't want to argue with who can cast a vote or not, but there is a bit of 
discrepancy between 
  https://wiki.qt.io/Maintainers
that is said to be the authoritative list of maintainers in 
  http://quips-qt-io.herokuapp.com/quip-0002.html
and 
  
https://codereview.qt-project.org/admin/groups/a60ed457f6e3833c81023c72743ba73c7e23fb09,members

It would be good if such discrepancy did not exist :)

Cheers,
  Albert
 
> Daniel will follow up with more details on how to cast your vote a bit later
> today.
 
> With that, I’d like to wish both candidates good luck, and am very much
> looking forward to see who will become our new Chief Maintainer.
 
> Cheers,
> Lars
> 


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Albert Astals Cid]

El dimarts, 15 de febrer de 2022, a les 19:58:05 (CET), Andreas Aardal Hanssen 
va escriure:
> On Tue, Feb 15, 2022, at 19:46, Thiago Macieira wrote:
> > On Tuesday, 15 February 2022 09:34:35 PST Marc Mutz wrote:
> > > 6.2 is an LTS release, is it not?
> > 
> > Not from my point of view, it isn't.
> 
> *cough* *cough*
> 
> Can this be commented officially by the chief maintainer?

Not the chief maintainer but it should be relatively trivial to understand that 
The Qt Project does not do LTS releases, The Qt Company has a soft fork of some 
branches that they call LTS releases. [1]

People belonging to The Qt Project (like Thiago, me and countless others) but 
not to the The Qt Company can't contribute to that so called "LTS release" 
soft-fork [2].

Cheers,
  Albert

P.S: Let me be clear even if this should be obvious, this is *my* opinion not 
any of the multiple groups I may be associated with either by being a volunteer 
in their organizations or by being a past, present or future employee.

[1] I'm not disagreeing with their right to do so.

[2]: Before you say "you could if you sign a few more NDAs and stuff", realize 
that by saying that you would be agreeing that normal The Qt Project people 
can't contribute to those LTS releases and only those that sign extra papers 
can.


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

Re: [Development] Qt 6.2.2 Released

[Albert Astals Cid via Development]

El dimecres, 1 de desembre de 2021, a les 13:48:57 (CET), Jani Heikkinen va 
escriure:
> Hi all!
> 
> We have released Qt 6.2.2 today, see
> https://www.qt.io/blog/qt-6.2.2-released

Should https://wiki.qt.io/MinGW be updated to point to the new and shiny mingw 
used in Qt 6.2.2?

Cheers,
  Albert

> Big thanks to everyone involved!
> 
> br,
> Jani Heikkinen
> Release Manager
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

[Development] Implementing small SVG 1.1 features (as opposed to SVG Tiny 1.2)

[Albert Astals Cid via Development]

Hello, 

I understand that the current QtSVG support is clearly stated to be SVG Tiny 
1.2

We have some clients that would like to add some rendering features from the 
non Tiny variant.

For example supporting x,y attributes in tspan. This would help fixing the 
rendering of the attached SVG (compare inkscape where it's vertical text vs 
QtSVG where it's not).

Implementing support for this doesn't seem like it should be "super hard" 
(famous last words) and would help rendering some SVG files that are out there 
in the wild.

I know this would be confusing as to being able to document exactly what QtSVG 
supports, but it seems to me that if we allow bit by bit small improvements we 
could eventually end up with more of the SVG specification supported, since it 
seems unlikely that someone will have the time to work on a "mega merge 
request" which implements all of the specification.

What do you think? 

Should we allow some small features outside of the declared SVG Tiny 1.2 
support?

Best Regards,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Do we need version tags in released src packages?

[Albert Astals Cid via Development]

El divendres, 13 d’agost de 2021, a les 11:06:07 (CEST), Jani Heikkinen va 
escriure:
> Hi,
> 
> > -Original Message-
> > From: Edward Welbourne 
> > Sent: perjantai 13. elokuuta 2021 10.43
> > To: Jani Heikkinen 
> > Cc: Albert Astals Cid ; development@qt-
> > project.org
> > Subject: Re: [Development] Do we need version tags in released src
> > packages?
> > 
> > El divendres, 13 d’agost de 2021, a les 9:17:16 (CEST), Jani Heikkinen va
> > 
> > escriure:
> > >> We are planning to simplify our packaging and releasing scripts and
> > >> one thing which would simplify our scripts is removal of version tag
> > >> parsing for src (and example) packages. So the question is if we can
> > >> remove version tag (-alpha, -beta1 etc) from our src and exmple
> > 
> > packages?
> > 
> > Albert Astals Cid (13 August 2021 09:26) replied:
> > > Does this mean that alpha/beta packages would have exactly the same
> > > filename as the final packages?
> 
> That was my proposal

It seems a bad idea to have files with the same name and the different contents.

It can lead to all kind of confusion in which you download something, then 
"download the same file" 5 days later and it has a different shasum and you 
wonder if the mirror you downloaded something was hacked or if your computer is 
hacked or what happened.

Sure you can argue that the file is in a different parent folder, but for a 
link like 
   
https://download.qt.io/official_releases/qt/6.1/6.1.2/submodules/qtcharts-everywhere-src-6.1.2.tar.xz
can you sincerely tell me you look at the full URL? 

I will look at the domain name to see it is not super fishy and at the 
filename, the internet has told us that the rest is just "internal storage" 
decisions by the people serving the file.

Cheers,
  Albert

> 
> > and, more generally, what would the practical consequences of your
> > proposed change be ?  What would Qt-users (or indeed anyone aside from
> > our packaging team) see changed ?
> > 
> > Eddy.
> 
> Only release packages would change; no changes to files in git
> 
> * Standalone src packages in
> https://download.qt.io/development_releases/qt/6.3/6.3.0-beta1/single/
> would be  qt-everywhere-src-6.3.0.zip instead of 
> qt-everywhere-src-6.3.0-beta1.zip. And main folder in the archive wouldn't
> contain 'beta1' either
> 
> * Submodule specific src packages in
> https://download.qt.io/development_releases/qt/6.3/6.3.0-beta1/submodules/
> would be qt-everywhere-src-6.3.0.zip instead of
> qt-everywhere-src-6.3.0-beta1.zip. And main folder in the
> archive wouldn't contain 'beta1' either
> 
> There is no effect to installation done by online installer; in the
> installation there isn't version tag shown at all currently either.
> 
> br,
> Jani


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Do we need version tags in released src packages?

[Albert Astals Cid via Development]

El divendres, 13 d’agost de 2021, a les 9:17:16 (CEST), Jani Heikkinen va 
escriure:
> Hi!
> 
> We are planning to simplify our packaging and releasing scripts and one
> thing which would simplify our scripts is removal of version tag parsing
> for src (and example) packages. So the question is if we can remove version
> tag (-alpha, -beta1 etc) from our src and exmple packages?

Does this mean that alpha/beta packages would have exactly the same filename as 
the final packages?

Cheers,
  Albert

> 
> In my opinion we don't need those; packages are always released in proper
> release folder (like
> https://download.qt.io/development_releases/qt/6.2/6.2.0-beta2/) and so on
> it should be quite obvious in which pre-release packages belongs to.
> Official release are already without any version tag so removing those from
> development releases shouldn't matter either. But does someone disagree and
> if yes why?
> 
> br,
> Jani Heikkinen
> Release Manager
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 13:25:45 CEST, Lars Knoll va 
escriure:
> > On 18 Sep 2020, at 11:23, Albert Astals Cid via Development
> >  wrote:
 
> > El divendres, 18 de setembre de 2020, a les 11:00:23 CEST, André Somers va
> > 
 escriure:
> > 
> >> On 18-09-2020 09:12, Albert Astals Cid via Development wrote:
> >> 
> >>> El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago
> >>> Macieira
> >>> va> 
> >>> escriure:
> >>> 
> >>>> On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> >>>> 
> >>>>> Hi!
> >>>>> 
> >>>>> There was a discussion about the decision to deprecate (remove?)
> >>>>> QVariant
> >>>>> comparison (<,>) in Qt6 completely.
> >>>>> 
> >>>>> Has anything changed for Qt6 (especially regarding comparison of
> >>>>> equal
> >>>>> and/or convertible types)? Is the complete deprecation still the
> >>>>> latest
> >>>>> decision?
> >>>> 
> >>>> 
> >>>> Yes, it's changed; no, it's not deprecation.
> >>>> 
> >>>> What's been removed is the conversion. Aside from the numeric types,
> >>>> comparing two variants of different types will always result in false.
> >>>> If
> >>>> you want to compare across types, convert one to the other's type or to
> >>>> a
> >>>> common third type. You know what data you put in there and you should
> >>>> know
> >>>> what conversions can be lossy or not.
> >>> 
> >>> 
> >>> But i don't what data someone else put it in a QVariant.
> >>> 
> >>> The fact that QAbstractItemModelPrivate::isVariantLessThan exists
> >>> should
> >>> be
> >>> proof enough that you can't expect my class to know what someone else
> >>> put
> >>> inside a QVariant, i mean that's basically the defining feature of
> >>> QVariant "it can hold random things for you".
> >>> 
> >>> 
> >>>  Is the official Qt position that we should all "copy"
> >>> 
> >>> 
> >>> QAbstractItemModelPrivate::isVariantLessThan into our item model
> >>> classes
> >>> that need sorting?
> >> 
> >> 
> >> How often do you really have items of different QVariant types in a
> >> single column and and role in a model?
> > 
> > 
> > Probably not often, but that means adding new API to classes forcing users
> > of 
 those classes to specify either a single type for each role/column
> > (so the comparison can be done internally in the class) or a comparer
> > function for each role/column and offloading the comparison back to the
> > user, makes things a bit annoying.
> > 
> > 
> >> 
> >> From what I understand, in Qt 6 you can still compare QVariants if they
> >> contain the same type - be that a user type or not - for both equality
> >> and lessThan provided the type in QVariant supports such comparisons.
> >> Right?
> 
> > 
> > There's no lessThan in Qt6 for QVariant, so no, you can't do that [unless
> > you 
 unbox the data from the QVariant, but then you're not comparing
> > QVariants anymore :)].
> 
> 
> I’m not really in favour of adding an operator<() to QVariant again, as it
> would need to provide some decent ordering, and that would probably cause
> conflicts with operator=() that does somewhat loose comparisons for numeric
> types.
 
> But we could provide a compare() method similar to QMetaType. I don’t think
> we can provide total ordering here as some types stored in a QVariant do
> not provide comparison operators, but we could basically provide the same
> as QMetaType:
 
> std::optional QVariant::compare(const QVariant );
> 
> Would that be good enough?

I think that would solve some (probably even most) of the pain, yes :)

Cheers,
  Albert

> 
> Cheers,
> Lars
> 
> 
> 
> > Cheers,
> > 
> >  Albert
> > 
> > 
> > 
> >> 
> >> André
> >> 
> >> 
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> https://lists.qt-project.org/listinfo/development
> > 
> > 
> > 
> > -- 
> > Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> > Klarälvdalens Datakonsult AB, a KDAB Group company
> > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> > KDAB - The Qt, C++ and OpenGL Experts
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> 


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 11:00:23 CEST, André Somers va 
escriure:
> On 18-09-2020 09:12, Albert Astals Cid via Development wrote:
> > El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira
> > va> 
> > escriure:
> >> On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> >>> Hi!
> >>> 
> >>> There was a discussion about the decision to deprecate (remove?)
> >>> QVariant
> >>> comparison (<,>) in Qt6 completely.
> >>> 
> >>> Has anything changed for Qt6 (especially regarding comparison of equal
> >>> and/or convertible types)? Is the complete deprecation still the latest
> >>> decision?
> >> 
> >> Yes, it's changed; no, it's not deprecation.
> >> 
> >> What's been removed is the conversion. Aside from the numeric types,
> >> comparing two variants of different types will always result in false. If
> >> you want to compare across types, convert one to the other's type or to a
> >> common third type. You know what data you put in there and you should
> >> know
> >> what conversions can be lossy or not.
> > 
> > But i don't what data someone else put it in a QVariant.
> > 
> > The fact that QAbstractItemModelPrivate::isVariantLessThan exists should
> > be
> > proof enough that you can't expect my class to know what someone else put
> > inside a QVariant, i mean that's basically the defining feature of
> > QVariant "it can hold random things for you".
> > 
> >   Is the official Qt position that we should all "copy"
> > 
> > QAbstractItemModelPrivate::isVariantLessThan into our item model classes
> > that need sorting?
> 
> How often do you really have items of different QVariant types in a
> single column and and role in a model?

Probably not often, but that means adding new API to classes forcing users of 
those classes to specify either a single type for each role/column (so the 
comparison can be done internally in the class) or a comparer function for 
each role/column and offloading the comparison back to the user, makes things a 
bit annoying.

> 
>  From what I understand, in Qt 6 you can still compare QVariants if they
> contain the same type - be that a user type or not - for both equality
> and lessThan provided the type in QVariant supports such comparisons. Right?

There's no lessThan in Qt6 for QVariant, so no, you can't do that [unless you 
unbox the data from the QVariant, but then you're not comparing QVariants 
anymore :)].

Cheers,
  Albert

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


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 10:37:36 CEST, Lars Knoll va 
escriure:
> > On 18 Sep 2020, at 10:28, Albert Astals Cid 
> > wrote:
 
> > El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va
> > escriure:
> 
> >> Sorting and equality are two different things. QVariant has never
> >> supported
 a lessThan operator.
> > 
> > 
> > Yes, it has
> > 
> > https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h
> > =5.15#n467
> 
> You’re right. I thought it didn’t support that.
> 
> What is it you need? Just some total ordering of variants? The method you
> mentioned in QAbstractItemModel also only does ordering for some types,
> otherwise falling back to strings.

We have a few generic item models and proxy models that implement sorting, 
they did so by using operator< of QVariant.

I want a way to be able to do the same in Qt6 in a way that ideally doesn't 
involve having to copy the QAbstractItemModelPrivate::isVariantLessThan code.

But i'll understand if you say "it is how it is, either copy 
QAbstractItemModelPrivate::isVariantLessThan or force the users of your 
generic item model classes to provide their own QVariant lessThan operator".

It's not the end of the world, but it's one of those things that was 
convenient in Qt5 and seems it will not be as convenient in Qt6.

Maybe making QAbstractItemModelPrivate::isVariantLessThan public and clearly 
defining what it was would be good enough (i mean if it is good enough for 
QAbstractItemModel it could be enough for most of the other implementations).

Best Regards,
  Albert

 
> Cheers,
> Lars
> 
> 
> > 
> > Cheers,
> > 
> >  Albert
> > 
> > 
> > 
> >> Cheers,
> >> Lars
> >> 
> >> 
> >> Cheers,
> >> Albert
> >> 
> >> --
> >> Albert Astals Cid |
> >> albert.astals@kdab.com<mailto:albert.astals@kdab.com> | Senior
> >> Software Engineer
> > 
> > Klarälvdalens Datakonsult AB, a KDAB Group company
> > 
> >> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> >> KDAB - The Qt, C++ and OpenGL Experts
> >> 
> >> ___
> >> Development mailing list
> >> Development@qt-project.org<mailto:Development@qt-project.org>
> >> https://lists.qt-project.org/listinfo/development
> >> 
> > 
> > 
> > 
> > -- 
> > Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> > Klarälvdalens Datakonsult AB, a KDAB Group company
> > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> > KDAB - The Qt, C++ and OpenGL Experts
> > 
> 
> 


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va 
escriure:
> Sorting and equality are two different things. QVariant has never supported
> a lessThan operator.

Yes, it has

https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h=5.15#n467

Cheers,
  Albert
 
> Cheers,
> Lars
> 
> 
> Cheers,
>  Albert
> 
> --
> Albert Astals Cid |
> albert.astals@kdab.com<mailto:albert.astals@kdab.com> | Senior
> Software Engineer
 Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org<mailto:Development@qt-project.org>
> https://lists.qt-project.org/listinfo/development
> 


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] QVariant comparison in Qt6

[Albert Astals Cid via Development]

El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va 
escriure:
> On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> > Hi!
> > 
> > There was a discussion about the decision to deprecate (remove?) QVariant
> > comparison (<,>) in Qt6 completely.
> > 
> > Has anything changed for Qt6 (especially regarding comparison of equal
> > and/or convertible types)? Is the complete deprecation still the latest
> > decision?
> 
> Yes, it's changed; no, it's not deprecation.
> 
> What's been removed is the conversion. Aside from the numeric types,
> comparing two variants of different types will always result in false. If
> you want to compare across types, convert one to the other's type or to a
> common third type. You know what data you put in there and you should know
> what conversions can be lossy or not.

But i don't what data someone else put it in a QVariant.

The fact that QAbstractItemModelPrivate::isVariantLessThan exists should be 
proof enough that you can't expect my class to know what someone else put 
inside a QVariant, i mean that's basically the defining feature of QVariant "it 
can hold random things for you".

 Is the official Qt position that we should all "copy" 
QAbstractItemModelPrivate::isVariantLessThan into our item model classes that 
need sorting?

Cheers,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] First Qt6.0.0 Snaphot available

[Albert Astals Cid via Development]

El dilluns, 15 de juny de 2020, a les 14:06:00 CEST, Jani Heikkinen va 
escriure:
> Hi Everyone,
> 
> We have published first Qt6.0.0 snapshot today, see more info from Tuukka's
> blog post: https://www.qt.io/blog/first-qt-6.0-snapshot-available
> 
> Qt 6.0.0 snapshot can be found from 'Preview' category in Qt online
> installer/Maintenance tool. This snapshot is based on quite old content but
> we are planning to do silent updates occasionally so please also check
> updates now and then.

The Linux packages are "incomplete"
  libQt6Core.so.6.0.0 is linked against libdouble-conversion.so.1 
  libQt6Gui.so.6.0.0 is linked against libpng15.so.15 
but neither of them are shipped

So unless you're using the old RedHat that the binary packages have been built 
against, the binary packages are not very useful.

You already ship libicu* so i guess you have a way of shipping non Qt libs 
that are actually needed for the binary package to be actually binary/
standalone.

Cheers,
  Albert

> 
> br,
> Jani Heikkinen
> Release Manager
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

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

[Albert Astals Cid via Development]

El dijous, 23 d’abril de 2020, a les 10:27:15 CEST, Simon Hausmann va 
escriure:
> Hi Dmitriy,
> 
> No, this is not an April's Foolk joke.
> 
> Previous discussions were largely centred around the implementations and
> bringing them together. With this thread my concern is the API and the
> churn our users would have to apply to their code base in order to use Qt 5
> and Qt 6.

People would still need to have different code, i.e. they would need to use 
QVector in Qt5 (as QList is "bad") and QList in Qt6 (as QVector would be 
deprecated).

Cheers,
  Albert

> 
> 
> Simon
> 
> From: Dmitriy Purgin 
> Sent: Thursday, April 23, 2020 9:53
> To: Simon Hausmann 
> Cc: development@qt-project.org 
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> 
> Hi Simon,
> 
> I hope it's not a belated April's Fool joke? As far as I can remember, for
> the past few years, one would read everywhere to switch to QVector from
> QList because of this and that, and to choose QVector as the default choice
> container instead of QList like it was back in the days. I can't give the
> exact references but that's just the feeling I get from reading the docs
> and the Qt mailing lists.
> 
> Cheers
> Dmitriy
> 
> On Thu, Apr 23, 2020 at 9:45 AM Simon Hausmann
> mailto:simon.hausm...@qt.io>> wrote: Hi,
> 
> In dev we've had QVector being an alias for QList for a while now. For the
> 6.0 release this particular topic (QList/QVector) suggests two goals (among
> others):
> 
> (1) Use the same type throughout the public API of Qt.
> 
> (2) Make it easy for our users to maintain a code base that works with
> Qt 5 and 6.
> 
> 
> In the light of those two goals, I think we should keep using QList as the
> type in the public API. I don't think we should do a search and replace
> activity and switch to QVector. In the light of that, I would like to
> propose simply deprecating QVector and stick to QList everywhere.
> 
> 
> What do you think?
> 
> 
> Simon
> _______________
> Development mailing list
> Development@qt-project.org<mailto:Development@qt-project.org>
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

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

[Albert Astals Cid via Development]

El dijous, 23 d’abril de 2020, a les 10:23:21 CEST, Simon Hausmann va 
escriure:
> Hi,
> 
> Yes, apologies, QList is an alias for QVector. I propose to switch that
> around.

But keeping which implementation?

I.e. it's not clear if you are suggesting to make 
   Qt6 QList == Qt5 QVector and deprecate Qt6 QVector
or
   Qt6 QList == Qt5 QList and deprecate Qt6 QVector

Cheers,
  Albert

> 
> 
> Simon
> 
> 
> From: Development  on behalf of Albert
> Astals Cid via Development  Sent: Thursday,
> April 23, 2020 10:16
> To: development@qt-project.org 
> Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> 
> El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va 
escriure:
> > Hi,
> > 
> > In dev we've had QVector being an alias for QList for a while now.
> 
> It's the other way around, isn't it?
> 
> corelib/tools/qcontainerfwd.h:
> template using QList = QVector;
> 
> Cheers,
>   Albert
> 
> --
> Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

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

[Albert Astals Cid via Development]

El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> Hi,
> 
> In dev we've had QVector being an alias for QList for a while now. 

It's the other way around, isn't it?

corelib/tools/qcontainerfwd.h:
template using QList = QVector;

Cheers,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

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

[Albert Astals Cid via Development]

El dijous, 23 d’abril de 2020, a les 9:43:33 CEST, Simon Hausmann va escriure:
> Hi,
> 
> In dev we've had QVector being an alias for QList for a while now. For the
> 6.0 release this particular topic (QList/QVector) suggests two goals (among
> others):
> 
> (1) Use the same type throughout the public API of Qt.
> 
> (2) Make it easy for our users to maintain a code base that works with
> Qt 5 and 6.
> 
> 
> In the light of those two goals, I think we should keep using QList as the
> type in the public API. I don't think we should do a search and replace
> activity and switch to QVector. In the light of that, I would like to
> propose simply deprecating QVector and stick to QList everywhere.
> 
> 
> What do you think?

As taught in Computer Science/Engineering courses:
 * QList is not a list
 * QVector is a vector

Compating to std:: types:
 * QList is not comparable to a std::list
 * QVector is comparable to a std::vector

Personally i think it makes sense to keep the QVector name.

Cheers,
  Albert

> 
> 
> Simon


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Changes to Qt offering

[Albert Astals Cid via Development]

El dilluns, 27 de gener de 2020, a les 15:34:44 CET, Lars Knoll va escriure:
> 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
> 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.

Can someone on the release team confirm there was a public discussion about the 
Qt Project not doing LTS releases anymore?

Otherwise it seems the Open Governance was a bit side tracked and The Qt 
Company unilaterally decided to stop doing some releases.

Cheers,
  Albert 

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


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Updating/changing "default" branch for qtbase repository

[Albert Astals Cid via Development]

El dilluns, 16 de setembre de 2019, a les 13:22:22 CEST, Frederik Gladhorn va 
escriure:
> On mandag 16. september 2019 12:22:06 CEST Edward Welbourne wrote:
> > Albert Astals Cid (16 September 2019 11:33) wrote:
> > > If i do
> > > 
> > >   git clone ssh://myu...@codereview.qt-project.org/qt/qtbase
> > > 
> > > I get branch 5.12
> > > 
> > > Given that 5.12 is now on cherry-pick mode (AFAIK) would it make more
> > > sense to default to branch 5.13?
> > 
> > We have a history of setting a release branch (stable, I think; perhaps
> > LTS) as the default branch in our repositories.  This means that anyone
> > who mirrors our repositories gets that as their default branch (unless /
> > until they update it).  I don't see this as a good choice: getting dev
> > on the branches that have it would make more sense.
> > 
> > IIUC, the rationale for the present practice is that we want to make it
> > easier for folk who send us fixes.  I honestly doubt we'd suffer harm by
> > having fixes sent to us on dev a bit more often (and other changes, that
> > *do* belong on dev, being sent first to another branch would surely
> > happen less often); reviewers can surely help the contributor get it
> > onto the right branch, if there's a good reason why dev isn't good
> > enough.
> > 
> > ... now, where have I met this discussion recently ?
> > I'm quite sure I have, but can't remember where ...
> 
> I also had a chat about this recently and the Gerrit admins in general don't
> really fell like constantly changing the default branch, so I'd be much in
> favor of just moving all default branches to dev.

Same here, i think dev makes sense too, but didn't want to propose something 
so radical myself ^_^

Cheers,
  Albert

> 
> In my opinion we should mostly care about the dev branch, since that's where
> all future development needs to happen. Moving changes back into older
> releases can of course be important, but that's not what most people should
> have to worry about.
> 
> Cheers,
> Frederik
> 
> > Eddy.
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] 5.14 API change reviews

[Albert Astals Cid via Development]

El dilluns, 26 d’agost de 2019, a les 18:14:01 CEST, Edward Welbourne va 
escriure:
> Hi all,
> 
> As some have clearly noticed unprompted, I've now posted the first
> drafts of the 5.14 API change reviews [0], in accordance with QUIP 10
> [1].  Please file bugs in Jira for any changes you object to and link
> those bugs to QTBUG-77839 [2], blocking it.  Please tag any changes you
> make to fix issues noticed in review, either with Fixes: for such a bug
> report or with a Task-number: QTBUG-77839 footer.


How hard would be for those diffs to include the documentation (in the .cpp 
side).

This way it would be easier to catch that for example that the 
QWebSocketServer::setHandshakeTimeout function that according to 
https://codereview.qt-project.org/c/qt/qtwebsockets/+/271724 
is new in 5.14 does not include the \since marker

Cheers,
  Albert

> 
> As ever, remember that these reviews filter out lots of trivial changes,
> so check the actual 5.14 (and, where relevant, 5.13.1) sources if in
> doubt about what's really there.  The boring changes filtered out of
> qtbase totalled more than twice the residue presented for review.
> 
> [0]
> https://codereview.qt-project.org/q/topic:%2522api-change%2522+status:open
> [1] https://quips-qt-io.herokuapp.com/quip-0010-API-review.html
> [2] https://bugreports.qt.io/browse/QTBUG-77839
> 
> Feature freeze has happened, so please make no changes to 5.14's public
> APIs other than fixes in response to these reviews.
> 
> If you know a module has had material changes requiring an update to the
> review, please either read the commit message (it says how to update it)
> or drop me a line,
> 
>   Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

[Development] Dropping sqlite2 plugin for Qt6/cmake port

[Albert Astals Cid via Development]

While trying to get more src/plugins/sqldrivers/ code built with CMake i 
realized that there is no FindSQLite2.cmake in cmake and we would have to 
create/maintain our own.

Then i realized that the latest release of sqlite2 was on 2005 and thought 
maybe we can just drop it?

So I'm proposing to drop src/plugins/sqldrivers/sqlite2/ from Qt6/cmake port 
of Qt.

Opinions?

Best Regards,
  Albert

P.S: sqlite3 code is already building fine in the cmake port

-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] QML preprocessor

[Albert Astals Cid via Development]

El diumenge, 17 de març de 2019, a les 13:34:09 CET, Alberto Mardegan va 
escriure:
> Hi there!
>   When developing a QML module for the greater public one wants to
> provide a source package that can be built on multiple Qt versions.
> However, QML's lack of a preprocessor makes this rather cumbersome.
> 
> Suppose that my module needs to provide an element like this:
> 
> 
> import QtQuick 2.10
> 
> Item {
> ...
> Flickable {
> boundsMovement: Flickable.StopAtBounds
> ...
> }
> }
> 
> 
> If I wanted to make this available to users of Qt 5.9 and older, I'd
> need to ship another file, instead, importing QtQuick 2.9 and removing
> that "boundsMovement" property.
> 
> Keeping two or more copies of the same file and installing the proper
> one depending on the Qt version is certainly doable, but it carries a
> considerable maintenance cost.
> 
> I've personally decided to keep a single copy of each QML file but use
> different git branches; however, this also has its maintenance costs and
> makes things harder for people using the project, in that they need to
> checkout the right branch of the project, otherwise it won't work on
> their machines.
> 
> Has this problem been recognized and discussed before? 

We have fixed this problem in some places by using a Loader that changes the 
source on loading error

MyItem.qml code (which is what users of the code are supposed to use would be)
Item
{
Loader { 
source: "MyItemForQuick210.qml" 
onStatusChanged: if (loader.status == Loader.Error) source = 
"MyItemForQuick26.qml"
}
}

Not real code so may not "compile", but you should get the idea.

It's not awesome but for our use-case it worked.

Cheers,
  Albert

> Would a QML
> preprocessor be a viable option?
> I understand that this is not a problem for Qt itself, and it's a minor
> problem for app developers; however, developing a portable QML module
> depending on QtQuick is nearly impossible due to this, unless one agrees
> to settle on a certain old version of Qt and renounce to all the goodies
> that were added in later versions.
> 
> Ciao,
>   Alberto
> _______
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Submitting Qt to oss-fuzz

[Albert Astals Cid via Development]

El divendres, 31 d’agost de 2018, a les 11:24:58 CEST, Robert Löhning va 
escriure:
> Hi everybody,
> 
> yes I did. So far I have been working on getting Qt into a better shape
> for fuzzing at all, resulting in [1].
> 
> This prepares a Qt build for being fuzz tested with clang's libFuzzer,
> the tool that Google also uses in oss-fuzz. The fuzzer I used for
> testing my setup already found a crash.
> 
> What I have so far:
> - fuzzing Qt with libFuzzer locally, using [1]
> - AFAICS collected all the needed "OK"s to enter Qt [2]
> 
> What I don't have so far:
> - create the pull request for [2], wanted to do this now-ish
> - Everything that comes after registering the project like:
>- setting up build/run on Google's servers
>- finding out what kind of dashboard I'll get there
> 
> I would appreciate if I might use the scripts you posted, Albert, or if
> we could work on this together.

Feel free to merge my github branch into your github branch :)

Cheers,
  Albert

> 
> Cheers,
> Robert
> 
> [1] https://codereview.qt-project.org/236937/
> [2] https://github.com/google/oss-fuzz/compare/master...rlohning:master
> 
> Am 30.08.2018 um 21:27 schrieb Lars Knoll:
> > Hi Albert,
> > 
> > Nice! Robert has been working on exactly the same thing lately. I think it
> > would be good if you guys coordinated the effort :)
> > 
> > It would be ideal, if we could somehow get those mails forwarded to the
> > security mailing list. I wonder whether we could do that with a special
> > mail account that forwards to the security mailing list.
> > 
> > Cheers,
> > Lars
> > 
> >> On 30 Aug 2018, at 20:42, Albert Astals Cid via Development
> >>  wrote:
> >> 
> >> oss-fuzz is an online fuzzing service run by Google.
> >> 
> >> They test daily the code base and run fuzzying over it, maintaining a
> >> list of open and closed bugs.
> >> 
> >> As example you can see one of the poppler issues i fixed at
> >> 
> >> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382
> >> 
> >> Everything is done automatically by a bot, except my "This is fixed by"
> >> comment, but that's just there for historical reasons, it's not really
> >> needed.
> >> 
> >> Found bugs are sent to a list of trusted address and kept private for 90
> >> days, then if not fixed then they become public.
> >> 
> >> Fixed bugs become public 30 days after being fixed.
> >> 
> >> I have made a qimage fuzzer that uses libpng test files as seed corpus.
> >> 
> >> You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz
> >> 
> >> Adding support for Qt is "relatively simple" see
> >> https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8
> >> a6a44b1cd679bf356e6e6ed3f
> >> 
> >> I made a local test run of the undefined sanitizer and it found
> >> https://paste.kde.org/prkox41mx
> >> in a few seconds, so "it works"
> >> 
> >> If you want to test it locally you can do
> >> 
> >> python infra/helper.py build_fuzzers --sanitizer undefined qt
> >> python infra/helper.py run_fuzzer qt qimage_fuzzer
> >> 
> >> for the undefined sanitizer and
> >> 
> >> python infra/helper.py build_fuzzers --sanitizer address qt
> >> python infra/helper.py run_fuzzer qt qimage_fuzzer
> >> 
> >> Unfortunately I have not been able to compile with the memory sanitizer
> >> enabled yet.
> >> 
> >> The most important thing before submitting this upstream is changing the
> >> list of trusted addresses the private bugs get sent to.
> >> 
> >> To have something written i've used my email address but i guess at least
> >> i should add eirik.aavitsl...@qt.io (listed as QImage maintainer) there
> >> too? Anyone else?
> >> 
> >> I am not sure how the email address thing works, but i think they need to
> >> be "google account" activated, whatever that means, so we can't use
> >> secur...@qt-project.org. On poppler i'm using my @gmail.com address and
> >> not my @kde.org address since it was just easier.
> >> 
> >> Comments?
> >> 
> >> Cheers,
> >> 
> >>   Albert
> >> 
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Submitting Qt to oss-fuzz

[Albert Astals Cid via Development]

El divendres, 31 d’agost de 2018, a les 11:31:16 CEST, Robert Löhning va 
escriure:
> Am 30.08.2018 um 21:30 schrieb Albert Astals Cid via Development:
> > El dijous, 30 d’agost de 2018, a les 8:59:40 CEST, André Pönitz va 
escriure:
> >> On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via
> >> 
> >> Development wrote:
> >>> I made a local test run of the undefined sanitizer and it found
> >>> https://paste.kde.org/prkox41mx in a few seconds, so "it works"
> >>> 
> >>> If you want to test it locally you can do python infra/helper.py
> >>> build_fuzzers --sanitizer undefined qt python infra/helper.py
> >>> run_fuzzer qt qimage_fuzzer for the undefined sanitizer and
> >>> python infra/helper.py build_fuzzers --sanitizer address qt
> >>> python infra/helper.py run_fuzzer qt qimage_fuzzer
> >>> 
> >>> Unfortunately I have not been able to compile with the memory
> >>> sanitizer enabled yet.
> >>> 
> >>> The most important thing before submitting this upstream is
> >>> changing the list of trusted addresses the private bugs get sent
> >>> to.
> >>> 
> >>> To have something written i've used my email address but i guess
> >>> at least i should add eirik.aavitsl...@qt.io (listed as QImage
> >>> maintainer) there too? Anyone else?  I am not sure how the email
> >>> address thing works, but i think they need to be "google account"
> >>> activated, whatever that means, so we can't use
> >>> secur...@qt-project.org.
> >> 
> >> That would be the natural choice.
> >> 
> >>> On  poppler i'm using my @gmail.com address and not my @kde.org address
> >>> since it was just easier.
> >>> 
> >>> Comments?
> >> 
> >> We are not taking about an innovative approach to coerce people
> >> into using Google services, right?
> > 
> > Maybe :D
> > 
> > Not really sure how it works, we can try submitting it with security@qt-
> > project.org and see what happens, but first i'd like confirmation from
> > them
> > that they'll look at the errors and confirmation from "the project" that
> > it's a good idea to do this.
> 
> Hi,
> 
> I was planning to do it the other way round: I registered a GMail
> address for this sole purpose and will manually forward what comes in
> there to the security list whenever needed. Of course I'd then try to
> automate this as far as possible.

That works for me if it works for the project :)

Cheers,
  Albert

> 
> Cheers,
> Robert
> 
> > Cheers,
> > 
> >Albert
> >> 
> >> Andre'
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Submitting Qt to oss-fuzz

[Albert Astals Cid via Development]

El divendres, 31 d’agost de 2018, a les 10:27:08 CEST, Edward Welbourne va 
escriure:
> Albert Astals Cid (30 August 2018 20:42) wrote:
> > oss-fuzz is an online fuzzing service run by Google.
> 
> Sounds useful.
> 
> > They test daily the code base and run fuzzying over it, maintaining a
> > list of open and closed bugs.
> > 
> > Found bugs are sent to a list of trusted address and kept private for
> > 90 days, then if not fixed then they become public.
> > 
> > Fixed bugs become public 30 days after being fixed.
> 
> By "fixed" do they mean "we have told them we've fixed it" or "we've
> released all currently releasing branches of Qt with fixes" ?

Fixed means "the daily bot has run again and it has found that what was wrong 
before is now fine"

> I'm
> guessing it's closer to the former than the latter.  So we have a month
> from fixing it, or perhaps from releasing *one* branch with a fix,
> within which to also release all our other live branches.  That sounds
> like it may stress our release processes.  So we have a quarter year in
> which to find a fix, then we need to orchestrate releases across all
> branches within a month; and this happens for each and every issue
> found.  That schedule is fine for Chromium, which doesn't support old
> versions or care about backwards-compatibility, but may be a poor fit
> for our more conservative processes.
> 
> So it would be better to run this *ourselves*, if we can, so that the Qt
> community has more control over how and when the results get to be
> published.

This is scarily close to the security by obscurity argument ;)

"what if we have an horrible bug, we fix it, it becomes public in 30 days and 
we've not been able yet to put out a release?"

My answer to that is, you had an horrible bug, it's fixed, that is a great 
thing, so just put and advisory out with the patch if we can't get a release 
out.

> 
> > If you want to test it locally you can do
> > 
> > python infra/helper.py build_fuzzers --sanitizer undefined qt
> > python infra/helper.py run_fuzzer qt qimage_fuzzer
> > 
> > for the undefined sanitizer and
> > 
> > python infra/helper.py build_fuzzers --sanitizer address qt
> > python infra/helper.py run_fuzzer qt qimage_fuzzer
> 
> So it *can* be used locally, without giving Google yet more power ...
> Good to know.

But you lose the daily bot runs and the free hardware. I am not sure, but i 
think the bot part is not actually free software, though i may be wrong. Also 
when i run it, it stops at the first found issue, i guess there may be a 
parameter to have it continue since the bot will find N issues in a given day.

Cheers,
  Albert

> 
>   Eddy.


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Submitting Qt to oss-fuzz

[Albert Astals Cid via Development]

El dijous, 30 d’agost de 2018, a les 20:42:11 CEST, Albert Astals Cid via 
Development va escriure:
> Unfortunately I have not been able to compile with the memory sanitizer
> enabled yet.

Done :) 

https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/b4f28e7dc5e4b936166cda1be36c3bde6b62c53d

Found https://paste.kde.org/ptyi8utax in under a minute.

Cheers,
  Albert

> 
> Cheers,
>   Albert


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Submitting Qt to oss-fuzz

[Albert Astals Cid via Development]

El dijous, 30 d’agost de 2018, a les 8:59:40 CEST, André Pönitz va escriure:
> On Thu, Aug 30, 2018 at 08:42:11PM +0200, Albert Astals Cid via
> 
> Development wrote:
> > I made a local test run of the undefined sanitizer and it found
> > https://paste.kde.org/prkox41mx in a few seconds, so "it works"
> > 
> > If you want to test it locally you can do python infra/helper.py
> > build_fuzzers --sanitizer undefined qt python infra/helper.py
> > run_fuzzer qt qimage_fuzzer for the undefined sanitizer and
> > python infra/helper.py build_fuzzers --sanitizer address qt
> > python infra/helper.py run_fuzzer qt qimage_fuzzer
> > 
> > Unfortunately I have not been able to compile with the memory
> > sanitizer enabled yet.
> > 
> > The most important thing before submitting this upstream is
> > changing the list of trusted addresses the private bugs get sent
> > to.
> > 
> > To have something written i've used my email address but i guess
> > at least i should add eirik.aavitsl...@qt.io (listed as QImage
> > maintainer) there too? Anyone else?  I am not sure how the email
> > address thing works, but i think they need to be "google account"
> > activated, whatever that means, so we can't use
> > secur...@qt-project.org.
> 
> That would be the natural choice.
> 
> > On  poppler i'm using my @gmail.com address and not my @kde.org address
> > since it was just easier.
> > 
> > Comments?
> 
> We are not taking about an innovative approach to coerce people
> into using Google services, right?

Maybe :D

Not really sure how it works, we can try submitting it with security@qt-
project.org and see what happens, but first i'd like confirmation from them 
that they'll look at the errors and confirmation from "the project" that it's 
a good idea to do this.

Cheers,
  Albert

> 
> Andre'


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

[Development] Submitting Qt to oss-fuzz

[Albert Astals Cid via Development]

oss-fuzz is an online fuzzing service run by Google. 

They test daily the code base and run fuzzying over it, maintaining a list of 
open and closed bugs.

As example you can see one of the poppler issues i fixed at 
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382

Everything is done automatically by a bot, except my "This is fixed by" 
comment, but that's just there for historical reasons, it's not really needed.

Found bugs are sent to a list of trusted address and kept private for 90 days, 
then if not fixed then they become public. 

Fixed bugs become public 30 days after being fixed.

I have made a qimage fuzzer that uses libpng test files as seed corpus. 

You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz

Adding support for Qt is "relatively simple" see 
https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8a6a44b1cd679bf356e6e6ed3f

I made a local test run of the undefined sanitizer and it found 
https://paste.kde.org/prkox41mx
in a few seconds, so "it works"

If you want to test it locally you can do
python infra/helper.py build_fuzzers --sanitizer undefined qt
python infra/helper.py run_fuzzer qt qimage_fuzzer
for the undefined sanitizer and
python infra/helper.py build_fuzzers --sanitizer address qt
python infra/helper.py run_fuzzer qt qimage_fuzzer

Unfortunately I have not been able to compile with the memory sanitizer enabled 
yet.

The most important thing before submitting this upstream is changing the list 
of trusted addresses the private bugs get sent to.

To have something written i've used my email address but i guess at least i 
should add eirik.aavitsl...@qt.io (listed as QImage maintainer) there too? 
Anyone else? 

I am not sure how the email address thing works, but i think they need to be 
"google account" activated, whatever that means, so we can't use 
secur...@qt-project.org. On poppler i'm using my @gmail.com address and not my 
@kde.org address since it was just easier.

Comments?

Cheers,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Google Summer of Code 2018

[Albert Astals Cid]

El divendres, 20 d’abril de 2018, a les 11:23:51 CEST, Mohammed Nafees va 
escriure:
> I am sorry if the tone of my email sounds rude. I have no say as
> to what an organisation chooses to do. I have not listed anything to show
> that I am the best candidate they could have chosen. I know there are much
> better candidates out there. My main focus for the email was the way the
> project was selected - a coin flip. I think there should have been a better
> way to select / reject a project and that the project proposal should've
> been taken into account as well.

As said I'm not involved in the selection process, but if you've been told a 
coin flip was used as selection process, logic says it's because both project 
proposals were evaluated and deemed to be as good as the other, and given one 
had to be chosen, coin flip was the fairest method.

Best Regards,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Google Summer of Code 2018

[Albert Astals Cid]

El divendres, 20 d’abril de 2018, a les 5:29:21 CEST, Mohammed Nafees va 
escriure:
> Hello,
> 
> 
> 
> I am Mohammed Nafees, a 2nd year CS student at the University of Waterloo
> and I had applied to GSoC 2018 for The Qt Project to work on porting Qt to
> IncludeOS. Earlier today I was notified that my project has not been
> selected by the mentors as one of the projects for GSoC 2018. I  was
> notified that there were 2 slots given and one was selected for Qt Creator
> related project and the other was selected for Qt, in general. My project
> was for Qt and the selection process between me and another project was a
> coin flip. I find this criterion of selection absolutely ridiculous, I'm
> sorry.
> 
> 
> 
> First of all, organisations can ask Google to increase their number of
> slots. There was especially a date set just for that in the timeline.
> Secondly, I was the one to notify on the IRC channel that the Ideas URL for
> the organisation in GSoC's website was wrong. I helped change it to the
> actual one. I am a Qt veteran and have been using it for the past 5+ years.
> I am a former Google Code-in champion and a GSoC 2017 alumnus. I have the
> right to be disappointed because I was the one overjoyed about seeing The
> Qt Project in this year's GSoC.
> 
> 
> 
> I am highly disappointed by how you have rejected my project based on a coin
> flip. I was looking forward to work for my favorite toolkit so much so that
> I did not apply to any other organisation.

I understand you are disappointed, but you should understand this email 
reflects poorly on you and if i was involved in the GSOC organization it would 
make you lose points for next year.

How do you know the organization didn't ask for an increase of slots and 
Google simply refused?

Then you list all your "merits" as a way of saying "no way the other person 
was as good as me", that's a severe lack of self awareness, we all think we're 
good at something, yet for the most part, the world is full of people that are 
better than us at that very same thing.

As said i understand frustation when you're not selected, but this is not the 
email you should have written. 

The email you should have written is something along the lines of "how can 
improve for next year so my proposal is stronger and then not a coin flip is 
needed?".

Cheers,
  Albert

P.S: I'm not involved in GSOC for Qt.


> 
> 
> 
> Nafees.



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

Re: [Development] Rendering only items that are visible in Qt Quick

[Albert Astals Cid]

El divendres, 23 de març de 2018, a les 14:44:03 CET, Mitch Curtis va 
escriure:
> I'd like to get some discussion going around this:
> 
> https://bugreports.qt.io/browse/QTBUG-67274
> 
> As I understand it, clipping (the "clip" property) doesn't prevent items
> that aren't visible (in the sense of being out of the viewport, not the
> "visible" property) from actually being rendered.
> 
> It would be useful if we had a way to do this with minimal effort from the
> user. I'm thinking of a e.g. a property or flag in QQuickItem that, when
> set, would cause the scenegraph to use the shape (could start off as just
> being a bounding rect) of child items to determine whether or not that item
> is visible with regards to its parents bounding rect. That way, any regular
> old item can benefit from it easily.
> 
> Does anyone else have ideas about this?

The culled property of QQuickItemPrivate makes things be skipped for 
rendering, so you could add something like 
QQuickItemPrivate::setChildrenCulled that used the geometries of children to 
set it's culled property.

The problem is that this can get relatively inefficient if those geometries 
change (animations, etc) since you have to recalculate the culled property for 
every single change so given how supposedly fast graphics are at clipping you 
may be better of just using clipping?

Cheers,
  Albert

> 
> Comments about how it will never work and I should feel bad for suggesting
> it?
> 
> Far superior alternatives?
> 
> Please, share your thoughts! :D
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Integrating Common Print Dialog project into Qt

[Albert Astals Cid]

El dijous, 21 de desembre de 2017, a les 10:33:53 CET, Rithvik Patibandla va 
escriure:
> > On 21-Dec-2017, at 2:52 PM, Albert Astals Cid <albert.astals@kdab.com>
> > wrote:
> > 
> > I see a big-ish problem that is that it uses QtQuick so it can't really go
> > into qtbase where the current printing dialog lives, so if this was to be
> > accepted the printing module would need to split off from qtbase (no idea
> > if that is planned or not).
> 
> This has been one of our main concerns too. At the time of project planning,
> we were thinking more about QML support because of the missing printing
> support within QML. However, if it is not possible to split the dialog off
> qtbase, we could probably redo the QML part and write the UI using QWidget
> instead but that would be our last option.
> > Looking at the code Advanced.qml seems to be collection of items that
> > really don't do anything at all?
> 
> The CUPS backend API doesn’t support all of these options yet. So we just
> put up dummy dropdown and we’ll add backend functions to them as soon as
> the API supports it.

In my opinion showing the user something that does nothing is bad usability 
and the way to make everyone very unhappy.

Best Regards,
  Albert

> 
> Thanks,
> Rithvik


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts


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

Re: [Development] Integrating Common Print Dialog project into Qt

[Albert Astals Cid]

El dijous, 21 de desembre de 2017, a les 10:14:14 CET, Rithvik Patibandla va 
escriure:
> Hi

Hi

> This summer, OpenPrinting [1] has created a Common Print Dialog project via
> the Google Summer of Code (2017) program to improve the experience of
> printing in Linux systems with a modern UI and backend APIs that will be
> maintained by the OpenPrinting org (the idea can be found here [2]). I am
> one of the students who worked on this project. For the UI, we decided to
> build one using Qt 5. Although, the dialog started as an application to
> ship with individual distributions, we changed course and instead built a
> print dialog API which can be used by application developers to include the
> dialog in their applications.  We wish to integrate this dialog API into Qt
> so that any application built using Qt can use this dialog to include
> support for printing. The code for the dialog can be found here [3]. We
> request the Qt developers to review the code and help us in integrating the
> dialog into Qt. The build instructions are given in the README file and
> screenshots of the dialog will be uploaded very soon.

I see a big-ish problem that is that it uses QtQuick so it can't really go 
into qtbase where the current printing dialog lives, so if this was to be 
accepted the printing module would need to split off from qtbase (no idea if 
that is planned or not).

Looking at the code Advanced.qml seems to be collection of items that really 
don't do anything at all?

Cheers,
  Albert

> 
> Thanks,
> Rithvik
> 
> [1] https://wiki.linuxfoundation.org/openprinting/start
> <https://wiki.linuxfoundation.org/openprinting/start> [2]
> https://wiki.linuxfoundation.org/gsoc/google-summer-code-2017-openprinting-> 
> projects
> <https://wiki.linuxfoundation.org/gsoc/google-summer-code-2017-openprinting
> -projects> [3] https://github.com/rithvikp1998/common-print-dialog
> <https://github.com/rithvikp1998/common-print-dialog>


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts


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

Re: [Development] QT printing via CUPS (advanced printing dalog box missing)

[Albert Astals Cid]

El dilluns, 4 de desembre de 2017, a les 15:16:16 CET, Albert Astals Cid va 
escriure:
> El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va
> 
> escriure:
> > On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote:
> > > This bug has been reported on QT ( see
> > > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a
> > > year and half now, the bug status is still *reported* and the resolution
> > > *unknown*.
> > > 
> > > I am sorry to post this information here, but we are many users affected
> > > by this bug and we are desperate because we don't have any feed back
> > > from QT. Is there anybody working on it ?
> > 
> > No, there is not.
> > 
> > The module is currently orphan, with no maintainer.
> 
> Reviews more than welcome
> 
> https://codereview.qt-project.org/#/c/213391/
> https://codereview.qt-project.org/#/c/213390/
> https://codereview.qt-project.org/#/c/213389/
> https://codereview.qt-project.org/#/c/213388/
> https://codereview.qt-project.org/#/c/213387/
> https://codereview.qt-project.org/#/c/213386/
> https://codereview.qt-project.org/#/c/213385/
> https://codereview.qt-project.org/#/c/213384/
> https://codereview.qt-project.org/#/c/213383/

and some more (more regarding to default values than to the advanced tabs 
itself)

https://codereview.qt-project.org/#/c/213483/
https://codereview.qt-project.org/#/c/213575/
https://codereview.qt-project.org/#/c/213580/
https://codereview.qt-project.org/#/c/213589/
https://codereview.qt-project.org/#/c/213598/
https://codereview.qt-project.org/#/c/213661/
https://codereview.qt-project.org/#/c/213677/

Cheers,
  Albert

> 
> Cheers,
>   Albert


-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT printing via CUPS (advanced printing dalog box missing)

[Albert Astals Cid]

El dilluns, 20 de novembre de 2017, a les 23:45:18 CET, Thiago Macieira va 
escriure:
> On segunda-feira, 20 de novembro de 2017 14:01:25 PST GMAIL wrote:
> > This bug has been reported on QT ( see
> > https://bugreports.qt.io/browse/QTBUG-54464) on *June 2016*. Almost a
> > year and half now, the bug status is still *reported* and the resolution
> > *unknown*.
> > 
> > I am sorry to post this information here, but we are many users affected
> > by this bug and we are desperate because we don't have any feed back
> > from QT. Is there anybody working on it ?
> 
> No, there is not.
> 
> The module is currently orphan, with no maintainer.

Reviews more than welcome

https://codereview.qt-project.org/#/c/213391/
https://codereview.qt-project.org/#/c/213390/
https://codereview.qt-project.org/#/c/213389/
https://codereview.qt-project.org/#/c/213388/
https://codereview.qt-project.org/#/c/213387/
https://codereview.qt-project.org/#/c/213386/
https://codereview.qt-project.org/#/c/213385/
https://codereview.qt-project.org/#/c/213384/
https://codereview.qt-project.org/#/c/213383/

Cheers,
  Albert

-- 
Albert Astals Cid | albert.astals@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Image and PreserveAspectCrop

[Albert Astals Cid]

On Tue, Aug 2, 2016 at 1:56 PM, Gunnar Sletta <gun...@sletta.org> wrote:
> Hi,
>
> I think the most sensible solution is to handle this inside the image 
> provder. When I've seen this problem previously, it has was solved using a 
> custom image provider for local files, but as you say, when the resources are 
> scattered across the local and network alike, then you want the default 
> internals to handle it correctly.
>
> So I agree with you that "Solution" is the way forward, rather than A or B :)
>
> I suspect the behavioural change won't be that big a deal, as it will in fact 
> show up only as a slightly sharper image.
>
> A bit unfortunate that we have to add a V2 version of the image provider, 
> though. Would be nice if we could extend what is already there somehow. 
> However you end up solving it, it needs to be a bit more flexible than what 
> you do in the > proposed patch, as you also have to cover PreserveAspectFit.

I don't understand what needs to be done regarding PreserveAspectFit.
Isn't that the default mode of operation?

> Perhaps using some flags as the last parameter there instead of a bool so we 
> keep it open to add other states later on without having to introduce a new 
> class.
>
> cheers,
> Gunnar
>
>
>> On 02 Aug 2016, at 09:11, Albert Astals Cid <albert.ast...@canonical.com> 
>> wrote:
>>
>> Ping anyone?
>>
>> On Mon, Jul 18, 2016 at 10:24 AM, Albert Astals Cid
>> <albert.ast...@canonical.com> wrote:
>>> There is a problem when trying to optimally[*] show an Image with
>>> PreserveAspectCrop fillMode.
>>> [*]optimally => as best looking as possible while using as litte
>>> memory as possible
>>>
>>> You can see that problem in the screenshot at http://i.imgur.com/LSSlFEB.png
>>> that corresponds with the code at http://paste.ubuntu.com/19480453/
>>>
>>> As you can see when displaying a landscape (width > height) image in a
>>> square Image Item the optimal way
>>> is to set the source size height only, but if the image is portrait
>>> (height > width) then the optimal way
>>> is to set the source size width only.
>>>
>>> The requirement my program has is to have the best rendering quality
>>> and memory usage for Image Items using PreserveAspectCrop.
>>> Image sources are totally arbitrary, they can be from disk, from the
>>> internet or even from QQuickImageProviders
>>> (since we are plugin based and plugins can bring their own 
>>> QQuickImageProvider)
>>>
>>> This can be fixed in several ways.
>>>
>>> Workaround A
>>> **
>>> Changing the Image Item source size comparing the aspect ratio of the
>>> image file with the one Image Item.
>>>
>>> You can see an implementation of that workaround at
>>> http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Dash/CroppedImageMinimumSourceSize.qml
>>>
>>> The problem with this workaround is that half of the times you end up
>>> loading the image a second time.
>>> This means extra CPU and potentially network usage.
>>>
>>>
>>>
>>> Workaround B
>>> **
>>> Implementing your own image provider that does compare the aspect
>>> ratios before loading the image.
>>>
>>> You can see a partial implementation of this workaround at
>>> https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSizeProvider/+merge/300176
>>>
>>> There are two problems with this workaround:
>>> * You end up implementing quite a bit of duplicated functionality
>>> from qquickpixmapcache.cpp
>>> * For the chained image providers (i.e. the original source was an
>>> image provider url) you
>>>   still have to query the image provider twice half of the times
>>>
>>>
>>>
>>> Solution
>>> 
>>> Implementing the change in QtQuick internals so that when
>>> PreserveAspectCrop fillMode is used
>>> together with a sourceSize that has both width and height it does
>>> return the optimal image
>>>
>>> You can see a work in progress implementation of this solution at
>>> https://codereview.qt-project.org/#/c/165299/
>>> And how the previews could would look at
>>> http://i.imgur.com/NRoXNzy.png (notice how the last column now is good
>>> in both cases)
>>>
>>> There are two issues with this solution:
>>> * It's a small behaviour change (but in my opinion for the better)
>>> * Needs new api for the QQuickImageProvider to be able to implement
>>> it, so we either need the proposed
>>>   QQuickImageProviderV2 or with a new "bool
>>> shouldPreserveAspectRatioCrop(url, requestSize)" getter in the
>>>   existing QQuickImageProvider API
>>>
>>>
>>>
>>> All in all I think the solution i propose for QtQuick is acceptable
>>> but i would like some agreeing that is fine adding new API before
>>> finishing the patch.
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Image and PreserveAspectCrop

[Albert Astals Cid]

Ping anyone?

On Mon, Jul 18, 2016 at 10:24 AM, Albert Astals Cid
<albert.ast...@canonical.com> wrote:
> There is a problem when trying to optimally[*] show an Image with
> PreserveAspectCrop fillMode.
> [*]optimally => as best looking as possible while using as litte
> memory as possible
>
> You can see that problem in the screenshot at http://i.imgur.com/LSSlFEB.png
> that corresponds with the code at http://paste.ubuntu.com/19480453/
>
> As you can see when displaying a landscape (width > height) image in a
> square Image Item the optimal way
> is to set the source size height only, but if the image is portrait
> (height > width) then the optimal way
> is to set the source size width only.
>
> The requirement my program has is to have the best rendering quality
> and memory usage for Image Items using PreserveAspectCrop.
> Image sources are totally arbitrary, they can be from disk, from the
> internet or even from QQuickImageProviders
> (since we are plugin based and plugins can bring their own 
> QQuickImageProvider)
>
> This can be fixed in several ways.
>
> Workaround A
> **
> Changing the Image Item source size comparing the aspect ratio of the
> image file with the one Image Item.
>
> You can see an implementation of that workaround at
> http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Dash/CroppedImageMinimumSourceSize.qml
>
> The problem with this workaround is that half of the times you end up
> loading the image a second time.
> This means extra CPU and potentially network usage.
>
>
>
> Workaround B
> **
> Implementing your own image provider that does compare the aspect
> ratios before loading the image.
>
> You can see a partial implementation of this workaround at
> https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSizeProvider/+merge/300176
>
> There are two problems with this workaround:
>  * You end up implementing quite a bit of duplicated functionality
> from qquickpixmapcache.cpp
>  * For the chained image providers (i.e. the original source was an
> image provider url) you
>still have to query the image provider twice half of the times
>
>
>
> Solution
> 
> Implementing the change in QtQuick internals so that when
> PreserveAspectCrop fillMode is used
> together with a sourceSize that has both width and height it does
> return the optimal image
>
> You can see a work in progress implementation of this solution at
> https://codereview.qt-project.org/#/c/165299/
> And how the previews could would look at
> http://i.imgur.com/NRoXNzy.png (notice how the last column now is good
> in both cases)
>
> There are two issues with this solution:
>  * It's a small behaviour change (but in my opinion for the better)
>  * Needs new api for the QQuickImageProvider to be able to implement
> it, so we either need the proposed
>QQuickImageProviderV2 or with a new "bool
> shouldPreserveAspectRatioCrop(url, requestSize)" getter in the
>existing QQuickImageProvider API
>
>
>
> All in all I think the solution i propose for QtQuick is acceptable
> but i would like some agreeing that is fine adding new API before
> finishing the patch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QLockFile] Whether it is reasonable to use 0644 permission ?

[Albert Astals Cid]

FWIW this is slightly related to https://bugreports.qt.io/browse/QTBUG-53570

On Wed, Jul 27, 2016 at 9:31 AM, Denis Shienkov
 wrote:
>> and let the umask determine which bits to exclude.
>
> what do you mean here? why we need to use umask, and why we need to exclude
> bits?
>
>
> 27.07.2016 10:01, Thiago Macieira пишет:
>>
>> On quarta-feira, 27 de julho de 2016 09:49:14 PDT Denis Shienkov wrote:
>>>
>>> Why just do not use 0666 permissions for this?
>>
>> We should use 0666 and let the umask determine which bits to exclude.
>>
>
> ___
> 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] Image and PreserveAspectCrop

[Albert Astals Cid]

There is a problem when trying to optimally[*] show an Image with
PreserveAspectCrop fillMode.
[*]optimally => as best looking as possible while using as litte
memory as possible

You can see that problem in the screenshot at http://i.imgur.com/LSSlFEB.png
that corresponds with the code at http://paste.ubuntu.com/19480453/

As you can see when displaying a landscape (width > height) image in a
square Image Item the optimal way
is to set the source size height only, but if the image is portrait
(height > width) then the optimal way
is to set the source size width only.

The requirement my program has is to have the best rendering quality
and memory usage for Image Items using PreserveAspectCrop.
Image sources are totally arbitrary, they can be from disk, from the
internet or even from QQuickImageProviders
(since we are plugin based and plugins can bring their own QQuickImageProvider)

This can be fixed in several ways.

Workaround A
**
Changing the Image Item source size comparing the aspect ratio of the
image file with the one Image Item.

You can see an implementation of that workaround at
http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Dash/CroppedImageMinimumSourceSize.qml

The problem with this workaround is that half of the times you end up
loading the image a second time.
This means extra CPU and potentially network usage.



Workaround B
**
Implementing your own image provider that does compare the aspect
ratios before loading the image.

You can see a partial implementation of this workaround at
https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSizeProvider/+merge/300176

There are two problems with this workaround:
 * You end up implementing quite a bit of duplicated functionality
from qquickpixmapcache.cpp
 * For the chained image providers (i.e. the original source was an
image provider url) you
   still have to query the image provider twice half of the times



Solution

Implementing the change in QtQuick internals so that when
PreserveAspectCrop fillMode is used
together with a sourceSize that has both width and height it does
return the optimal image

You can see a work in progress implementation of this solution at
https://codereview.qt-project.org/#/c/165299/
And how the previews could would look at
http://i.imgur.com/NRoXNzy.png (notice how the last column now is good
in both cases)

There are two issues with this solution:
 * It's a small behaviour change (but in my opinion for the better)
 * Needs new api for the QQuickImageProvider to be able to implement
it, so we either need the proposed
   QQuickImageProviderV2 or with a new "bool
shouldPreserveAspectRatioCrop(url, requestSize)" getter in the
   existing QQuickImageProvider API



All in all I think the solution i propose for QtQuick is acceptable
but i would like some agreeing that is fine adding new API before
finishing the patch.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Heads up for Qt Bug Report & Code Review users

[Albert Astals Cid]

On Tue, Dec 22, 2015 at 11:37 AM, Jokiniva Jukka
 wrote:
>
>
> On 21/12/15 12:52, "Giuseppe D'Angelo"  wrote:
>
>>Hi,
>>
>>On Mon, Dec 21, 2015 at 9:48 AM, Jokiniva Jukka
>> wrote:
>>> · If you don¹t already have Qt credentials, all you need to do
>>>is
>>> register at https://login.qt.io/register* using the same email address
>>>you
>>> currently use for Bug Tracker and Code Review. If you want to change to
>>>a
>>> different email address for your unified login credentials, you should
>>>first
>>> update the email address in Bug Tracker** to ensure the logins will be
>>> merged.
>>
>>What happens if one does not have a Qt Account on login.qt.io, but
>>only a Jira/Gerrit account? Will a Qt Account be created
>>automatically?
>
> Qt Account won¹t be created automatically. If you don¹t have one, you need
> to register at https://login.qt.io/register

Any reason the password i have for gerrit and the bug tracker is not
good enough anymore?

Cheers,
  Albert

>
> ‹Jukka
>
> ___
> 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 5.6.0 header diff: QtQuick.diff

[Albert Astals Cid]

On Fri, Sep 18, 2015 at 10:59 AM, Knoll Lars
<lars.kn...@theqtcompany.com> wrote:
>
>
> On 18/09/15 10:55, "Albert Astals Cid" <albert.ast...@canonical.com> wrote:
>
>>On Fri, Sep 18, 2015 at 10:39 AM, Knoll Lars
>><lars.kn...@theqtcompany.com> wrote:
>>> On 18/09/15 09:59, "Albert Astals Cid" <albert.ast...@canonical.com>
>>>wrote:
>>>
>>>>On Fri, Sep 18, 2015 at 9:36 AM, Knoll Lars
>>>><lars.kn...@theqtcompany.com>
>>>>wrote:
>>>>> New properties:
>>>>>
>>>>> QQuickFramebufferObject::mirrorVertically, looks ok
>>>>> QQuickPaintedItem::textureSize, not ok. It’s not versioned.
>>>>>
>>>>> New methods:
>>>>>
>>>>> * QQuickTextureFactory *textureFactoryForImage(const QImage ),
>>>>>docs
>>>>> not ok IMO.
>>>>
>>>>What's would you add to the docs?
>>>
>>> The docs say “Returns a QQuickTextureFactory holding given the image.”.
>>
>>So should i move "the" in front of "given" ?
>
> That solves the parse error, yes :)
>>
>>> For me that’s a parse error ;-)
>>> It also doesn’t describe when and how you’re supposed to use the method.
>>
>>QQuickImageResponse::textureFactory says you can use that function
>>when you need it to do exacly what it says, get a QQuickTextureFactory
>>holding a QImage.
>>
>>If you prefer i can also reference QQuickImageResponse::textureFactory
>>from textureFactoryForImage but it can (and is) also used in other
>>places (at least internally, not sure if from a Qt user point of view
>>would make sense in any other place).
>
> Adding that reference would probably help from a Qt user POV.

https://codereview.qt-project.org/#/c/125994/

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

Re: [Development] Qt 5.6.0 header diff: QtQuick.diff

[Albert Astals Cid]

On Fri, Sep 18, 2015 at 10:10 AM, André Somers <an...@familiesomers.nl> wrote:
> Op 18-9-2015 om 09:59 schreef Albert Astals Cid:
>>
>>> New classes:
>>>
>>> * QQuickImageResponse
>>>
>>> Isn’t this class missing some way to get the status of the response? It
>>> only has an errorString() method, but no simple way to query whether it
>>> was successful or not when finished() gets emitted.
>> The docu says that "An empty string means no error.".
>>
>>
> Isn't that inconsistent with similar API's in Qt that do keep the error
> message separate from the error status?

It is indeed a bit inconsistent, but on the other hand what we usually
have is a enum that defines the error type and then errorString
function that basically translates that enum to a string. In this case
there's no enum possible so it would mean making the people that
reimplement this class have to implement both a success() and a
errorString() function.

So it would be http://paste.ubuntu.com/12447071/

Also realize this is not a class the developer consumes but a class
the developer implements, so the fewer things we give him to make a
mistake/inconsistent (like returnning an errorString while success
returns true) the better.

Where the m_success bool is basically just a !errorstring.isEmpty()

Maybe what we can do is add a non virtual bool success() const that
just returns !errorstring.isEmpty()? Not that it would add much since
the only place this would be used is in
QQuickPixmapReader::asyncResponseFinished and would mean changing

   if (!response->errorString().isEmpty()) {
   error = QQuickPixmapReply::Loading;
   errorString = response->errorString();
   } else {
   t = response->textureFactory();
   }

to

   if (!response->success()) {
   error = QQuickPixmapReply::Loading;
   errorString = response->errorString();
   } else {
   t = response->textureFactory();
   }

But anyway if you really want it changed i won't oppose.

Cheers,
  Albert

>
> André
>
> ___
> 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 5.6.0 header diff: QtQuick.diff

[Albert Astals Cid]

On Fri, Sep 18, 2015 at 10:39 AM, Knoll Lars
<lars.kn...@theqtcompany.com> wrote:
> On 18/09/15 09:59, "Albert Astals Cid" <albert.ast...@canonical.com> wrote:
>
>>On Fri, Sep 18, 2015 at 9:36 AM, Knoll Lars <lars.kn...@theqtcompany.com>
>>wrote:
>>> New properties:
>>>
>>> QQuickFramebufferObject::mirrorVertically, looks ok
>>> QQuickPaintedItem::textureSize, not ok. It’s not versioned.
>>>
>>> New methods:
>>>
>>> * QQuickTextureFactory *textureFactoryForImage(const QImage ),
>>>docs
>>> not ok IMO.
>>
>>What's would you add to the docs?
>
> The docs say “Returns a QQuickTextureFactory holding given the image.”.

So should i move "the" in front of "given" ?

> For me that’s a parse error ;-)
> It also doesn’t describe when and how you’re supposed to use the method.

QQuickImageResponse::textureFactory says you can use that function
when you need it to do exacly what it says, get a QQuickTextureFactory
holding a QImage.

If you prefer i can also reference QQuickImageResponse::textureFactory
from textureFactoryForImage but it can (and is) also used in other
places (at least internally, not sure if from a Qt user point of view
would make sense in any other place).

Salut,
  Albert

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

Re: [Development] Qt 5.6.0 header diff: QtQuick.diff

[Albert Astals Cid]

On Fri, Sep 18, 2015 at 9:36 AM, Knoll Lars  wrote:
> New properties:
>
> QQuickFramebufferObject::mirrorVertically, looks ok
> QQuickPaintedItem::textureSize, not ok. It’s not versioned.
>
> New methods:
>
> * QQuickTextureFactory *textureFactoryForImage(const QImage ), docs
> not ok IMO.

What's would you add to the docs?

>
> New classes:
>
> * QQuickImageResponse
>
> Isn’t this class missing some way to get the status of the response? It
> only has an errorString() method, but no simple way to query whether it
> was successful or not when finished() gets emitted.

The docu says that "An empty string means no error.".

Cheers,
  Albert


>
> * QQuickAsyncImageProvider, looks ok.
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of Qt Quick 1 in Qt 5

[Albert Astals Cid]

On Fri, May 8, 2015 at 3:53 PM, Frederik Gladhorn
frederik.gladh...@theqtcompany.com wrote:
 On Friday, May 08, 2015 02:44:53 PM André Somers wrote:
 Frederik Gladhorn schreef op 8-5-2015 om 14:39:
  Hi,
 
  I think the dust has settled quite a bit and the declarative module is
  becoming better by the day. We have seen it evolve and the new Java Script
  engine is running smoothly (and actively worked on, sadly it will have one
  known crasher in the 5.5 beta release which has been fixed in the mean
  time, so it should be good for everyone with the 5.5 RC).
 
  One question is if there is any reason to maintain Qt Quick 1 in the
  future. It adds burden on maintenance, needs to be patched regularly to
  move with changes in qtbase etc.
 
  Since KDE moved over the Plasma desktop to Qt Quick 2 (on which I'm
  writing
  this email), I feel confident that the time has come to move everyone
  over.
  For the no opengl acceleration use case, we provide the Qt Quick 2D
  Renderer as backend.
  (https://blog.qt.io/blog/2015/01/22/introducing-the-qt-quick-2d-renderer/
  )
 
  In short, is there any reason not to remove Qt Quick 1 from Qt 5.6?

 Yes, there are reasons. Qt Quick 1 is the entrancepoint to moving your
 Qt 4 Application to Qt 5.


 Absolutely. But you can migrate to Qt 5.5 which has Qt Quick 1 support and
 later to 5.6 and onwards.

Not if you're using the Qt that comes with your Linux distribution
(not sure how common that is, i know i am).

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

Re: [Development] [Mac] tst_qquickwindow::testWindowVisibilityOrder() regression

[Albert Astals Cid]

What commit is supposed to fix? Or are you saying it's fixed in 5.5?
Because that's obviously not enough since we still need to release
5.4.2

On Thu, Mar 26, 2015 at 9:21 AM, Pocheptsov Timur
timur.pochept...@theqtcompany.com wrote:
 Yes, it's fixed?

 
 From: Aaron McCarthy mccarthy.aa...@gmail.com
 Sent: Thursday, March 26, 2015 6:38 AM
 To: development@qt-project.org
 Cc: Pocheptsov Timur; Albert Astals Cid
 Subject: Re: [Development] [Mac] 
 tst_qquickwindow::testWindowVisibilityOrder()  regression

 On Thu, 19 Mar 2015 10:00:37 Pocheptsov Timur wrote:
 For me this test fails with 5.4 and passes with 5.5, so something was fixed
 :) (the test code is the same, of course).

 Has there been any progress on this? I haven't seen any relevant commits in
 either qtbase or qtdeclarative. This failure is also blocking one of my
 changes from integrating.

 Cheers,

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

[Development] [Mac] tst_qquickwindow::testWindowVisibilityOrder() regression

[Albert Astals Cid]

It seems tst_qquickwindow::testWindowVisibilityOrder() has regressed
in the 5.4 branch (either because of qtdeclarative or qtbase changes)
and is not letting changes to the branch integrate.

I've run it locally here (linux) and get no failure, so it may be Mac
specific since it always seem to fail in the Mac builder.

Can anyone with a Mac please have a look?

http://testresults.qt.io/ci/QtDeclarative_5.4_Integration/build_00605/macx-clang_developer-build_qtnamespace_OSX_10.7/log.txt.gz

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

Re: [Development] Problem loading plugins with gcc 4.9.2

[Albert Astals Cid]

Yes, same issue.

Reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309

Would be great if someone could verify i didn't say lots of silly things

On Wed, Mar 4, 2015 at 11:19 AM, Rutledge Shawn
shawn.rutle...@theqtcompany.com wrote:

 On Mar 3, 2015, at 14:55, Sergio Martins sergio.mart...@kdab.com wrote:

 Hi,



 So that you don't waste time pulling your hair out: plugin loading is broken
 with gcc 4.9.2



 There's some clash between global static QFactoryLoader instances.
 Reproduced on Archlinux (and on Fedora by jpnurmi).


 I run Arch, and the main problem the last couple of weeks has been that I
 have to export QT_QPA_PLATFORM_PLUGIN_PATH or it will say that it can’t find
 the platform plugins.  Is that the same problem?

 Oh and jpeg loading broke too.


 ___
 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] Problem loading plugins with gcc 4.9.2

[Albert Astals Cid]

And Ubuntu, i've had this issue for a long time and i thought i was
the only one and thus only renamed all the loaders in the .cpp files
and went on with it :D

On Tue, Mar 3, 2015 at 2:55 PM, Sergio Martins sergio.mart...@kdab.com wrote:
 Hi,



 So that you don't waste time pulling your hair out: plugin loading is broken
 with gcc 4.9.2



 There's some clash between global static QFactoryLoader instances.

 Reproduced on Archlinux (and on Fedora by jpnurmi).





 Regards,

 --

 Sérgio Martins | sergio.mart...@kdab.com | Software Engineer

 Klarälvdalens Datakonsult AB, a KDAB Group company

 Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)

 KDAB - Qt Experts - Platform-independent software solutions


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

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

Re: [Development] QConfig update.

[Albert Astals Cid]

Please do not assert on the library, you're going to make everyone's
program crasheable by just editing a file by hand.

On Tue, Oct 14, 2014 at 7:06 PM, Milian Wolff milian.wo...@kdab.com wrote:

 On Tuesday 14 October 2014 13:44:30 Tomaz Canabrava wrote:
  On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff milian.wo...@kdab.com
 wrote:
   On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote:
People, I'v read everything on the other two e-mails and I'v changed
  
   quite
  
a few things here and again I ask for some advice.
   
What I'v done:
   
QConfig / QConfigGroup / QConfigWatcher combo classes, to be used
 from
  
   the
  
user
QConfigIniBackend, to be used internally.
   
QConfig:
   uses a 'global' QHashQString, QConfigIniBackend for different
 files
  
   in
  
a way that we don't destruct the info when the object is destroyed,
 but
reuses the JSON information stored, and parse it to the config
 object.
   
it has a QConfigGroup 'global' value that can be acced directly via
.setValue and .value
  
   Why the global state? A QConfig should be valid for a single file and
   constructed on-demand. If you want to share stuff and keep it open,
 adding
   something like a KSharedConfig might be a good idea. But again, that is
   something that could/should be built on-top of QConfig (imo).
 
  so I don't need to open a config file and parse it every time the user
  created a QConfig object.

 Then provide a QSharedConfig or let the user store the QConfig himself, if
 it
 turns out to be a performance-bottleneck for him. If you add global state
 to
 QConfig, you'll need synchronization or otherwise you are doomed in a
 multithreaded application.

 Also: If you add a cheap JSON cache, is it really worth to optimize at all?

 Furthermore: If you keep the QConfig in memory all the time, you'll
 probably
 end up duplicating the stuff as soon as you add the fancy high-level
 interface
 on-top. QConfig will operate on JSON after all and you'll incur a
 conversion
 penalty whenever you read a value from it. The high-level interface should
 (hopefully) read the values once and store it internally in the proper
 type.
 If you don't do this and always read from QConfig, you'll end up with
 issues
 in this pattern:

 void HighLevelConfig::setFoo(quint64 foo)
 {
   if (foo == m_foo) {
 return;
   }
   m_foo = foo;
   emit fooChanged(foo);
 }

 If this would read from QConfig, instead of directly comparing to the
 quint64
 m_foo member, you'll get rounding errors etc. pp. This, the more I think
 about it, is actually a big issue with a JSON cache in general. .ini does
 not
 have that issue as the byte-array gets interpreted based on the type you
 pass
 along (a kind of duck-typing). It might mean that you'll have to store
 everything as a string in JSON to prevent a loss of data when storing e.g.
 std::limitsquint64::max() (note: JSON only knows double). But storing
 everything as a string looses the difference between

 foo=1

 and

 foo=1

 Afaik this issue has not yet been discussed, has it?

QConfig and QConfigGroup *does not* support setting a default value
 on
  
   the
  
getter, I know that this is used in a lot of places but this can
 cause
inconsistencies:
   
Main.cpp
   
QConfig c;
c.value(window-width, 800);
   
MainWindow.cpp
c.value(window-width, 1200);
   
so we must create a better way for that. for now, I simply removed
 the
possibility for that, we can only do
   
c.value(window-width);
  
   And how do you check whether window-width was read or not? What do you
   return
   on error? A default-constructed value? What type does the value have
 for
   that
   matter?
  
   Imo, this makes this API extremely inconvenient. Yes it's possible to
 do
   an
   error, but that is life. You should only add such error-prevention
 stuff
   into
   the high-level schema stuff, not into QConfig itself.
  
   Without the ability to provide a default value, one can never figure
 out
   whether `c.value(some-int) == 0` means the value could not be read
 and a
   default should be used, or whether the value is 0.
 
  Since I wanted to add schema-validation on the low level stuff, this
  wouldn't be an issue,
  'value couldn't be read' would cause an assert.
  but I can postpone this for later.

 Most applications, (all KDE applications btw), would then assert.
 Initially,
 no configuration file is available after all.

 And again: Please do not overdesign QConfig. KISS! Add fancy
 schema-validation
 and stuff on-top of that. Don't remove something as essential as reading a
 setting with a default value fallback mechanism!

 Bye
 --
 Milian Wolff | milian.wo...@kdab.com | Software Engineer
 KDAB (Deutschland) GmbHCo KG, a KDAB Group company
 Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
 KDAB - Qt Experts - Platform-independent software solutions

 ___
 

Re: [Development] QOptional

[Albert Astals Cid]

On Thursday 21 August 2014 09:50:04 Poenitz Andre wrote:
 Hausmann Simon wrote:
  On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote:
   Of course, i can:)
   
   bool ok;
   const int value = string.toInt(ok);
   if (ok)
   
   qDebug()  value is  value;
   
   // 
   const auto value = string.toInt();
   if (value)
   
   qDebug()  value is  *value;
  
  To be honest: I find the bool ok variant much easier to read.
  if (value) on an auto variable can mean so many things. In the
  above example you could very easily think: Ah, toInt returns an int,
  so the type of value is probably int, so if (value) checks if it's
  non-zero.
 So the ugliness of the traditional code is essentially hidden
 by the use of 'auto' in contexts where the type is not obvious
 to the casual reader.
 
 Another can of worms. In practice this would end up often
 enough with
 
bool ok;
const int value = string.toInt(ok);
if (ok)
qDebug()  value is  value;
 
 vs
 
   const QOptionalint value = string.toInt();
   if (value)
  qDebug()  value is  *value;
 
 which is as cluttered as before in my eyes.

+1

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

Re: [Development] Qt 5.3 header diff: QtLocation

[Albert Astals Cid]

On Tuesday 22 April 2014 17:49:17 Thiago Macieira wrote:
 Em qua 23 abr 2014, às 10:28:51, Aaron McCarthy escreveu:
  On Tue, 22 Apr 2014 14:12:46 Thiago Macieira wrote:
   http://macieira.org/~thiago/qt-5.3/QtLocation.diff
  
  This is fine. Qt Location is not part of the 5.3 release.
 
 Indeed.
 
 However, Ubuntu did ship it in previous releases.
 
 http://packages.ubuntu.com/raring/libqt5location5
 
 Albert, please let people inside Canonical and the Ubuntu dev teams that
 QtLocation has a few binary incompatible changes now

Thanks for the heads-up I will.

Cheers,
  Albert

 
 The script did not produce a header diff for Qt3D because it's not tagged.
 but I can bet there are BIC changes there too.

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

Re: [Development] Bug fixes to Stable or Dev branch?

[Albert Astals Cid]

On Wednesday 05 February 2014 17:45:35 Turunen Tuukka wrote:
 Hi,
 
 Regarding Qt 5.2.2 - let's see how well 5.2.1 is received. We have now 1,5
 months shorter cycle than the usual 6 months for Qt 5.3. I agree that it
 was a long wait between 5.1.1 and 5.2.0.

FWIW with my Canonical hat we would appreciate a 5.2.x release with 
https://bugreports.qt-project.org/browse/QTBUG-36430 and 
https://bugreports.qt-project.org/browse/QTBUG-36289 fixed. We can distro-
patch but having it in an official release makes it easier for everyone.

Cheers,
  Albert

 
 Yours,
 
 Tuukka
 
 Lähettäjä: development-bounces+tuukka.turunen=digia@qt-project.org
 [development-bounces+tuukka.turunen=digia@qt-project.org]
 k#228;ytt#228;j#228;n Gladhorn Frederik [frederik.gladh...@digia.com]
 puolesta Lähetetty: 5. helmikuuta 2014 17:46
 Vastaanottaja: development@qt-project.org
 Aihe: Re: [Development] Bug fixes to Stable or Dev branch?
 
 We have the branch model to make it easy to choose the right branch, usually
 without worrying about the releases too much.
 
 Normal bug fixes go always to stable.
 Stable is guaranteed to be merged into dev before the next release, so
 you'll never have to worry, no patch gets lost.
 
 Show stoppers just before the release might have to go into the release
 branch, this should really be the exception.
 
 Sometimes a bug is less critical and/or involves huge changes, these may
 have to go into the dev branch pending the approvers and your judgement.
 
 By the way, I heard quite a few requests for more patch releases, maybe we
 should aim for 5.2.2 with hopefully only stability improvements.
 
 Greetings,
 Frederik
 
 
 From: development-bounces+frederik.gladhorn=digia@qt-project.org
 [development-bounces+frederik.gladhorn=digia@qt-project.org] on behalf
 of Giuseppe D'Angelo [dange...@gmail.com] Sent: Wednesday, February 05,
 2014 4:19 PM
 To: jl...@kde.org
 Cc: development@qt-project.org
 Subject: Re: [Development] Bug fixes to Stable or Dev branch?
 
 On 5 February 2014 15:55, John Layt jl...@kde.org wrote:
  Hi,
  
  I've seeing contradictory advice on Gerrit as to which branch to push bug-
  fixes to, some say there will be no 5.2.2 so to use dev instead, others
  say to keep using stable in case there is.  What is the current
  official policy?
  
  Oh, and please remember when making such decisions to clearly communicate
  them to this list, not everyone is in the office or on IRC.
 
 The policy didn't change, see Where to push a change?
 
 http://qt-project.org/wiki/Branch-Guidelines
 
 It doesn't matter that 5.2.2 is not planned. If the change qualifies
 for stable, push it to stable.
 
 --
 Giuseppe D'Angelo
 ___
 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

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

Re: [Development] http://qt-project.org/wiki/Qt521-KnownIssues

[Albert Astals Cid]

On Tuesday 28 January 2014 09:52:48 Heikkinen Jani wrote:
 Hi all,
 
 Qt 5.2.1 release is coming soon. Here is a link to the known issues page.
 Please add needed issues there.

The V4 register allocator is broken in X86, but it was already broken in 5.2.0 
so it may not make sense to mention it there.

Cheers,
  Albert

https://bugreports.qt-project.org/browse/QTBUG-36430
https://bugreports.qt-project.org/browse/QTBUG-36289

 
 Br,
 Jani
 
 --
 Jani Heikkinen
 Release Manager

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

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Albert Astals Cid]

On Friday 08 November 2013 14:18:24 Rutledge Shawn wrote:
 On 8 Nov 2013, at 9:59 AM, Mikkel Krautz wrote:
  That's how I'm imagining it working as well.  No 3rdparty source tree
  needs to be bundled (it isn't bundled in qt-solutions either, at the
  moment) - but link against the JasPer lib if it's present on the
  system, or JASPER_CFLAGS and JASPER_LIBS are specified to configure
  (or however we want it to function).
 
 Why should it use jasper instead of OpenJPEG?  I'm not familiar with either
 one but wikipedia seems to say OpenJPEG implements more of the spec.

And it's actually has an active upstream, while Jasper doesn't seem to be 
maintained at all.

Cheers,
  Albert

 
 ___
 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] Some QIcon::fromTheme() enhancements

[Albert Astals Cid]

On Friday 23 August 2013 07:50:56 Olivier Goffart wrote:
 On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote:
  On 22.08.2013 21:51, Thiago Macieira wrote:
   On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki wrote:
   I have patches (linked in the bug) to amend this, and I would like to
   get some feedback on them.
   
   Hello Antti
   
   If you can, please upload the patches to codereview.qt-project.org. It's
   easier to discuss them there.
  
  Either I was not clear enough or I have misunderstood something, but the
  links to the patches in codereview.qt-project.org are in that bug report.
  :)
 Thanks for the patch, I will have a look.
 However, the patches do not fix a regression, neither a P1 bug, so they
 should go to the 'dev' branch instead of the 'stable' branch.

This is weird

https://codereview.qt-project.org/#change,63593
approved by you is linked to a P3

https://codereview.qt-project.org/#change,63496
is also linked to a P3

https://codereview.qt-project.org/#change,63535
is also linked to a P3

https://codereview.qt-project.org/#change,63413
is linked to a P2

https://codereview.qt-project.org/#change,63595
is not linked to any bug

https://codereview.qt-project.org/#change,62408
is also not linked to any bug

https://codereview.qt-project.org/#change,62948
is linked to a bug without categorization

Also i don't understand that P1 rule for stable, what's the rationale to not 
fixing bugs in stable? That's what stable branch is for, no?

I could understand P1 rule for release, but for stable, what if i fix a 
small bug (which I understand won't be categorized as P1), why should people 
wait for the fix of that small bug for Qt 5.2 instead of 5.1.x?

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

Re: [Development] Some QIcon::fromTheme() enhancements

[Albert Astals Cid]

On Friday 23 August 2013 09:48:26 Simon Hausmann wrote:
 On Friday 23. August 2013 09.24.54 Albert Astals Cid wrote:
  On Friday 23 August 2013 07:50:56 Olivier Goffart wrote:
   On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote:
On 22.08.2013 21:51, Thiago Macieira wrote:
 On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki
 
 wrote:
 I have patches (linked in the bug) to amend this, and I would like
 to
 get some feedback on them.
 
 Hello Antti
 
 If you can, please upload the patches to codereview.qt-project.org.
 It's
 easier to discuss them there.

Either I was not clear enough or I have misunderstood something, but
the
links to the patches in codereview.qt-project.org are in that bug
report.

:)
   
   Thanks for the patch, I will have a look.
   However, the patches do not fix a regression, neither a P1 bug, so they
   should go to the 'dev' branch instead of the 'stable' branch.
  
  This is weird
  
  https://codereview.qt-project.org/#change,63593
  approved by you is linked to a P3
  
  https://codereview.qt-project.org/#change,63496
  is also linked to a P3
  
  https://codereview.qt-project.org/#change,63535
  is also linked to a P3
  
  https://codereview.qt-project.org/#change,63413
  is linked to a P2
  
  https://codereview.qt-project.org/#change,63595
  is not linked to any bug
  
  https://codereview.qt-project.org/#change,62408
  is also not linked to any bug
  
  https://codereview.qt-project.org/#change,62948
  is linked to a bug without categorization
 
 Seriously? Three of those are documentation fixes (so P1 or not doesn't make
 sense). Incorrect device pixel ratio can cause severe misrendering on
 retina displays, so I'd say it's pretty easy to argue that it should be
 fixed in patch release. The second last is a build issue that Olivier had
 nothing to do with and that in Joerg's opinion was important enough to fix
 in the next patch release. The QString fix you could argue fixes data
 corruption. And I think similarly it's easy to talk about the pop-up
 location fix.
 
 Instead of trying to attack other changes or Olivier's judgement as
 approver, I think it would be much better to explain why it is important
 that the icon fixes should go into a patch release. 

Honestly, I don't have any stake at the icon fixes, I don't even know if they 
are right, don't assume I'm here because of my @canonical.com address i share 
with Antti.

 Make a good case for
 the patch, respond with arguments. And if you don't succeed in convincing
 Olivier, then there are other approvers that might be willing to review
 this. (I can think of one off the top of my head)

Please let's not resort to stop attacking people as a way to stop people 
disagreeing.

I'm just wondering why he writes only P1 for stable when it's clear this 
rule is not being applied by just reading the first page of 
https://codereview.qt-project.org/#q,status:open+project:qt/qtbase+branch:stable,n,z

I don't mind if he says These are new features so they need to go into dev, 
but I'm sorry this is not a P1 so can't go into stable does not sound to me 
as a valid reason.

To me something either it is a bug and has to be fixed ASAP or it is a feature 
and can wait. Of course I'm new here so if we have a policy on why we delay 
fixing bugs I'd be happy to be pointed to it.

Cheers,
  Albert

 
 FWIW I personally think the icon theme fixes are worth it, but I'm not the
 one who should be making that case.
 
 
 Simon
 
  Also i don't understand that P1 rule for stable, what's the rationale to
  not fixing bugs in stable? That's what stable branch is for, no?
  
  I could understand P1 rule for release, but for stable, what if i fix a
  small bug (which I understand won't be categorized as P1), why should
  people wait for the fix of that small bug for Qt 5.2 instead of 5.1.x?
  
  Cheers,
  
Albert
  
  ___
  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] Some QIcon::fromTheme() enhancements

[Albert Astals Cid]

On Friday 23 August 2013 10:24:01 Simon Hausmann wrote:
 On Friday 23. August 2013 10.04.35 Albert Astals Cid wrote:
  On Friday 23 August 2013 09:48:26 Simon Hausmann wrote:
   On Friday 23. August 2013 09.24.54 Albert Astals Cid wrote:
On Friday 23 August 2013 07:50:56 Olivier Goffart wrote:
 On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote:
  On 22.08.2013 21:51, Thiago Macieira wrote:
   On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki
   
   wrote:
   I have patches (linked in the bug) to amend this, and I would
   like
   to
   get some feedback on them.
   
   Hello Antti
   
   If you can, please upload the patches to
   codereview.qt-project.org.
   It's
   easier to discuss them there.
  
  Either I was not clear enough or I have misunderstood something,
  but
  the
  links to the patches in codereview.qt-project.org are in that bug
  report.
  
  :)
 
 Thanks for the patch, I will have a look.
 However, the patches do not fix a regression, neither a P1 bug, so
 they
 should go to the 'dev' branch instead of the 'stable' branch.

This is weird

https://codereview.qt-project.org/#change,63593
approved by you is linked to a P3

https://codereview.qt-project.org/#change,63496
is also linked to a P3

https://codereview.qt-project.org/#change,63535
is also linked to a P3

https://codereview.qt-project.org/#change,63413
is linked to a P2

https://codereview.qt-project.org/#change,63595
is not linked to any bug

https://codereview.qt-project.org/#change,62408
is also not linked to any bug

https://codereview.qt-project.org/#change,62948
is linked to a bug without categorization
   
   Seriously? Three of those are documentation fixes (so P1 or not doesn't
   make sense). Incorrect device pixel ratio can cause severe misrendering
   on retina displays, so I'd say it's pretty easy to argue that it should
   be fixed in patch release. The second last is a build issue that Olivier
   had nothing to do with and that in Joerg's opinion was important enough
   to fix in the next patch release. The QString fix you could argue fixes
   data corruption. And I think similarly it's easy to talk about the
   pop-up
   location fix.
   
   Instead of trying to attack other changes or Olivier's judgement as
   approver, I think it would be much better to explain why it is important
   that the icon fixes should go into a patch release.
  
  Honestly, I don't have any stake at the icon fixes, I don't even know if
  they are right, don't assume I'm here because of my @canonical.com address
  i share with Antti.
 
 Ok, I won't make that assumption :)
 
   Make a good case for
   the patch, respond with arguments. And if you don't succeed in
   convincing
   Olivier, then there are other approvers that might be willing to review
   this. (I can think of one off the top of my head)
  
  Please let's not resort to stop attacking people as a way to stop people
  disagreeing.
  
  I'm just wondering why he writes only P1 for stable when it's clear this
  rule is not being applied by just reading the first page of
  https://codereview.qt-project.org/#q,status:open+project:qt/qtbase+branch:
  st able,n,z
  
  I don't mind if he says These are new features so they need to go into
  dev, but I'm sorry this is not a P1 so can't go into stable does not
  sound to me as a valid reason.
  
  To me something either it is a bug and has to be fixed ASAP or it is a
  feature and can wait. Of course I'm new here so if we have a policy on why
  we delay fixing bugs I'd be happy to be pointed to it.
 
 I think the main reason for being hesitant with fixing a certain bug in
 stable is the risk it introduces to cause other bigger behavioural changes
 or regressions themselves. It is indeed a question of severity, not every
 bug affects the same amount of users, not every bug causes the same amount
 of damage. In Qt we made that mistake a few times as well. Do you remember
 the numerous patch releases in the earlier Qt 4 days? Sometimes we were
 quite relaxed about putting bugfixes into a patch release just to find that
 it caused a regression itself and we needed another patch release as follow
 up to fix regressions in a patch release (urgh). That's one of the reasons
 I can think of why people tend to be a bit more hesitant and not put every
 bug fix straight into a patch release.

Sorry but this touches too much inner stuff, let's delay it a bit so we have 
more time/people to test/review it.

That's also a very valid reason for me to put stuff into dev.

I was only saying that I found the only P1 in stable reason a not so good 
reason given the track record of stuff that ends up in stable.

Cheers,
  Albert

 
 
 Simon

___
Development mailing list
Development@qt

[Development] Controlling a QtQuick ListView using its contentY shall be supported or not?

[Albert Astals Cid]

TLDR: Controlling a ListView using its contentY doesn't work and we have a use 
case that needs it. I am volunteering to code the solution to make it work but 
the question is what solution the Qt project wants :-)


THE PROBLEM
Our design team wants a ListView with Header that behaves in a different way 
than the current Header component of ListView does. They want that if you 
scroll up when the Header is hidden the first thing that happens is that the 
header shows and then when the Header has been totally shown the list 
scrolling happens.


THE SOLUTION
A Flickable that controls the contentY of a ListView and the height of the 
Header
  flickable_control_listview_without_sections.qml
And it works :-) but...


THE PROBLEM #2
We want to have section headers in that listview and adding section headers 
makes lots of things go weird, you can see the problem in
   flickable_control_listview.qml
either by scrolling up when the list is at the top or by scrolling to the 
bottom and then pressing 1 to scroll up. The contentY of the list will not be 
at its expected location.


THE SOLUTION #2
I can workaround this by doing crazy things like on the listview 
onContentYChanged check if it is changing to the value I set it and if not 
fixing it (fixes the jittering going up from the top)
and by remembering the last originY when pressing the 1 to go to the top
   flickable_control_listview_workaround.qml
I consider the changes between flickable_control_listview_workaround.qml and 
flickable_control_listview.qml a huge hack and something that should not be 
needed, but we could live with that


THE PROBLEM #3
We also want to have items with different sizes in the listview
   flickable_control_listview_workaround_different_sizes.qml
If you go to the end and then press 1 to scrol to the top you'll see that my 
workaround for the baseOriginY fails


THE PROBLEM #4
We also want to have problems if the list view contains complex loaders, 
haven't had time to create a simple test case for it


THE REAL SOLUTION?
We would like the code from flickable_control_listview_without_sections.qml to 
work on all the cases (sections, differently sized items, loader, etc) but we 
have been told that Using contentY to control a listview is unsupported

We are hoping that this use case may make you change your opinion on that 
statement and accept patches that makes the code in 
flickable_control_listview_without_sections.qml (or something along the lines) 
work in all the other situations.

In case you keep the statement that noone should use contentY to control 
listviews (why not make it read-only?) we see two solutions:

1) Add to ListView a enum that switches between the current Header 
hiding/showing behaviour and the one we want. Would you guys be interested in 
that feature to be merged upstream?

2) Reimplement our own ListView based on a Flickable so that it has the 
features we need. This is the solution we prefer the least since it would 
involve a lot of code duplication

So what's your opinion, how should we implement the wanted behaviour with the 
current QtQuick items?

Thanks,
  Albert
import QtQuick 2.0

Item {
width: 300
height: 400

function clamp(value, min, max) {
if (min = max) {
return Math.max(min, Math.min(max, value))
} else {
// swap min/max if min  max
return clamp(value, max, min)
}
}

focus: true
Keys.onPressed: {
if (event.key == Qt.Key_1) {
flicker.contentY = 0
}
}


ListModel {
id: animalsModel
ListElement { name: Parrot; size: Small }
ListElement { name: Guinea pig; size: Small }
ListElement { name: Mouse; size: Small }
ListElement { name: Sparrow; size: Small }
ListElement { name: Dog; size: Medium }
ListElement { name: Cat; size: Medium }
ListElement { name: Dolphin; size: Medium }
ListElement { name: Seal; size: Medium }
ListElement { name: Elephant; size: Large }
ListElement { name: Blue whale; size: Large }
ListElement { name: Rhino; size: Large }
ListElement { name: Ostrich; size: Large }
ListElement { name: Sperm whale; size: Large }
ListElement { name: Giraffe; size: Large }
ListElement { name: Parrot; size: Small }
ListElement { name: Guinea pig; size: Small }
ListElement { name: Mouse; size: Small }
ListElement { name: Sparrow; size: Small }
ListElement { name: Dog; size: Medium }
ListElement { name: Cat; size: Medium }
ListElement { name: Dolphin; size: Medium }
ListElement { name: Seal; size: Medium }
ListElement { name: Elephant; size: Large }
ListElement { name: Blue whale; size: Large }
ListElement { name: Rhino; size: Large }
ListElement { name: Ostrich; size: Large }
ListElement { name: Sperm whale; size: Large }
ListElement { name: