From partha1b at gmail.com  Fri Apr  1 04:20:39 2016
From: partha1b at gmail.com (Partha Bagchi)
Date: Thu, 31 Mar 2016 22:20:39 -0400
Subject: [Development] qtwebkit fails to build
In-Reply-To: <CAOW9c=_6VzrorsNApaGCJ9Tby5pYhBUGr7RPHG39A5p=b2=ezw@mail.gmail.com>
References: <CAOW9c=_6VzrorsNApaGCJ9Tby5pYhBUGr7RPHG39A5p=b2=ezw@mail.gmail.com>
Message-ID: <CAOW9c=-MGw_EO8gRWRt3ncsGF4STETcWqxE+G5smzqM8VZSxRw@mail.gmail.com>

[image: Mic Drop]
No suggestions at all? :(

I am stuck here and without Webkit, I cannot build digikam.


On Thu, Mar 31, 2016 at 2:25 PM, Partha Bagchi <partha1b at gmail.com> wrote:

> I seem to have hit another snag. Hoping someone can point to a solution.
> In my build process, I am getting the following error:
>
> mingw32-make[2]: Entering directory
> 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> ( test -e Makefile.WebCore.DerivedSources ||
> Z:/src/kde/qt5/qtbase/bin/qmake.exe
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/DerivedSources.pri -o
> Makefile.WebCore.DerivedSources ) && mingw32-make -f
> Makefile.WebCore.DerivedSources
> WARNING: Failure to find: generated/InternalSettingsGenerated.idl
> mingw32-make[3]: Entering directory
> 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> perl -IZ:/src/kde/qt5/qtwebkit/Source/WebCore/bindings/scripts
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl --tags
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathtags.in --attrs
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathattrs.in --extraDefines
> "UNICODE ENABLE_3D_RENDERING=1 ENABLE_ACCELERATED_2D_CANVAS=1 ENABLE_BLOB=1
> ENABLE_CANVAS_PATH=1 ENABLE_CHANNEL_MESSAGING=1
> ENABLE_CSS_BOX_DECORATION_BREAK=1 ENABLE_CSS_COMPOSITING=1
> ENABLE_CSS_EXCLUSIONS=1 ENABLE_CSS_FILTERS=1 ENABLE_CSS_IMAGE_SET=1
> ENABLE_CSS_REGIONS=1 ENABLE_CSS_SHAPES=1 ENABLE_CSS_STICKY_POSITION=1
> ENABLE_CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED=1 ENABLE_DATALIST_ELEMENT=1
> ENABLE_DETAILS_ELEMENT=1 ENABLE_DEVICE_ORIENTATION=1
> ENABLE_DOWNLOAD_ATTRIBUTE=1 ENABLE_FAST_MOBILE_SCROLLING=1 ENABLE_FILTERS=1
> ENABLE_FTPDIR=1 ENABLE_FULLSCREEN_API=1 ENABLE_GEOLOCATION=1
> ENABLE_GESTURE_EVENTS=1 ENABLE_ICONDATABASE=1 ENABLE_IFRAME_SEAMLESS=1
> ENABLE_INDEXED_DATABASE=1 ENABLE_INPUT_TYPE_COLOR=1 ENABLE_INSPECTOR=1
> ENABLE_INSPECTOR_SERVER=1 ENABLE_JAVASCRIPT_DEBUGGER=1
> ENABLE_LEGACY_NOTIFICATIONS=1 ENABLE_LEGACY_VIEWPORT_ADAPTION=1
> ENABLE_LEGACY_VENDOR_PREFIXES=1 ENABLE_LEGACY_WEB_AUDIO=1
> ENABLE_LINK_PREFETCH=1 ENABLE_METER_ELEMENT=1 ENABLE_MHTML=1
> ENABLE_NOTIFICATIONS=1 ENABLE_ORIENTATION_EVENTS=1
> ENABLE_PAGE_VISIBILITY_API=1 ENABLE_PROGRESS_ELEMENT=1
> ENABLE_RESOLUTION_MEDIA_QUERY=1 ENABLE_REQUEST_ANIMATION_FRAME=1
> ENABLE_SHARED_WORKERS=1 ENABLE_SMOOTH_SCROLLING=1 ENABLE_SQL_DATABASE=1
> ENABLE_SUBPIXEL_LAYOUT=1 ENABLE_SVG=1 ENABLE_SVG_FONTS=1
> ENABLE_TOUCH_ADJUSTMENT=1 ENABLE_TOUCH_EVENTS=1 ENABLE_VIDEO_TRACK=1
> ENABLE_VIEW_MODE_CSS_MEDIA=1 ENABLE_WEB_SOCKETS=1 ENABLE_WEB_TIMING=1
> ENABLE_WORKERS=1 ENABLE_XHR_TIMEOUT=1 WTF_USE_TILED_BACKING_STORE=1
> WTF_USE_CROSS_PLATFORM_CONTEXT_MENUS=1 HAVE_QTQUICK=1 HAVE_QTPRINTSUPPORT=1
> HAVE_QSTYLE=1 HAVE_QTTESTLIB=1 HAVE_QTPOSITIONING=1 HAVE_QTSENSORS=1
> WTF_USE_LIBXML2=1 ENABLE_XSLT=1 WTF_USE_ZLIB=1 WTF_USE_WEBP=1
> WTF_USE_LIBJPEG=1 WTF_USE_LIBPNG=1 ENABLE_NETSCAPE_PLUGIN_API=1
> PLUGIN_ARCHITECTURE_UNSUPPORTED=1 WTF_USE_3D_GRAPHICS=1 ENABLE_WEBGL=1
> ENABLE_VIDEO=1 WTF_USE_QT_MULTIMEDIA=1 HAVE_SQLITE3=1 ENABLE_TOUCH_SLIDER=1
> WTF_USE_LEVELDB=1 ENABLE_BATTERY_STATUS=0 ENABLE_CANVAS_PROXY=0
> ENABLE_CSP_NEXT=0 ENABLE_CSS_GRID_LAYOUT=0 ENABLE_CSS_HIERARCHIES=0
> ENABLE_CSS_IMAGE_ORIENTATION=0 ENABLE_CSS_IMAGE_RESOLUTION=0
> ENABLE_CSS_SHADERS=0 ENABLE_CSS_VARIABLES=0 ENABLE_CSS3_CONDITIONAL_RULES=0
> ENABLE_CSS3_TEXT=0 ENABLE_CSS3_TEXT_LINE_BREAK=0 ENABLE_DASHBOARD_SUPPORT=0
> ENABLE_DATAGRID=0 ENABLE_DATA_TRANSFER_ITEMS=0 ENABLE_DIRECTORY_UPLOAD=0
> ENABLE_FILE_SYSTEM=0 ENABLE_FONT_LOAD_EVENTS=0 ENABLE_GAMEPAD=0
> ENABLE_HIGH_DPI_CANVAS=0 ENABLE_INPUT_SPEECH=0 ENABLE_INPUT_TYPE_DATE=0
> ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE=0 ENABLE_INPUT_TYPE_DATETIMELOCAL=0
> ENABLE_INPUT_TYPE_MONTH=0 ENABLE_INPUT_TYPE_TIME=0 ENABLE_INPUT_TYPE_WEEK=0
> ENABLE_LEGACY_CSS_VENDOR_PREFIXES=0 ENABLE_MATHML=0 ENABLE_MEDIA_SOURCE=0
> ENABLE_MEDIA_STATISTICS=0 ENABLE_MEDIA_STREAM=0 ENABLE_MICRODATA=0
> ENABLE_MOUSE_CURSOR_SCALE=0 ENABLE_NAVIGATOR_CONTENT_UTILS=0
> ENABLE_NETWORK_INFO=0 ENABLE_NOSNIFF=0 ENABLE_PROXIMITY_EVENTS=0
> ENABLE_QUOTA=0 ENABLE_RESOURCE_TIMING=0 ENABLE_SCRIPTED_SPEECH=0
> ENABLE_SECCOMP_FILTERS=0 ENABLE_SHADOW_DOM=0 ENABLE_STYLE_SCOPED=0
> ENABLE_TEMPLATE_ELEMENT=0 ENABLE_TEXT_AUTOSIZING=0
> ENABLE_THREADED_HTML_PARSER=0 ENABLE_TOUCH_ICON_LOADING=0
> ENABLE_USER_TIMING=0 ENABLE_VIBRATION=0 ENABLE_WEB_AUDIO=0" --preprocessor
> "'Z:\src\kde\qt5\qtbase\bin\moc.exe' -E" --factory --wrapperFactory
> --outputDir generated
> Failed to open file: Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/
> mathtags.in at Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl
> line 306.
> Makefile.WebCore.DerivedSources:786: recipe for target
> 'generated/MathMLNames.cpp' failed
> mingw32-make[3]: *** [generated/MathMLNames.cpp] Error 9
> mingw32-make[3]: Leaving directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> Makefile.WebCore:36: recipe for target
> 'sub-DerivedSources-pri-make_first-ordered' failed
> mingw32-make[2]: *** [sub-DerivedSources-pri-make_first-ordered] Error 2
> mingw32-make[2]: Leaving directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> Makefile:218: recipe for target
> 'sub-Source-WebCore-WebCore-pro-make_first-ordered' failed
> mingw32-make[1]: *** [sub-Source-WebCore-WebCore-pro-make_first-ordered]
> Error 2
> mingw32-make[1]: Leaving directory 'Z:/src/kde/qt5/qtwebkit'
> Makefile:1074: recipe for target 'module-qtwebkit-make_first' failed
> mingw32-make: *** [module-qtwebkit-make_first] Error 2
>
> mathtags.in exists at the location specified, just not being opened.
>
> Grateful for any pointers!
>
> Thanks in advance,
> Partha
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160331/a95b3de3/attachment.html>

From Paul.Tvete at theqtcompany.com  Fri Apr  1 07:16:33 2016
From: Paul.Tvete at theqtcompany.com (Tvete Paul)
Date: Fri, 1 Apr 2016 05:16:33 +0000
Subject: [Development] Heads up! Fixing the build system on Windows
Message-ID: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>


As you may know, Lars is leading an effort to modularize the build
system. One of the big headaches we have is that Windows uses a completely
separate configure.exe, leading to a lot of duplicated effort.

With the latest announcement from Microsoft, everything changes. Now that
bash is natively supported, we will remove the ugly hack, and standardize on
using the configure script for all platforms. The requirement for
Windows 10 should not be a problem, since the upgrade is free anyway.

We are finalizing the changes now, and aim to go live from 5.6.1. As a bonus,
this should speed up the CI system for everyone, since we no longer have to
test the obsolete Windows versions.


From andrew.knight at intopalo.com  Fri Apr  1 07:47:20 2016
From: andrew.knight at intopalo.com (Andrew Knight)
Date: Fri, 1 Apr 2016 08:47:20 +0300
Subject: [Development] Heads up! Fixing the build system on Windows
In-Reply-To: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
References: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
Message-ID: <CAHsq-xphoti7de_niM7t-8NZ7AD-NsK-aJS9KsksPcp609kSZw@mail.gmail.com>

I totally applaud the initiative. Should we go a step further, and make
Windows 10 a requirement for building Qt for any platform? The OS ships on
most new PCs, and cross-compilers and sysroots for other platform targets
are pretty much ubiquitous nowadays. I realize there may be a slight
transition period getting all developers over to Windows 10 as their
primary development environment, but surely this won't take long now that
Microsoft has provided all the necessary tools to do so.

On 1 April 2016 at 08:16, Tvete Paul <Paul.Tvete at theqtcompany.com> wrote:

>
> As you may know, Lars is leading an effort to modularize the build
> system. One of the big headaches we have is that Windows uses a completely
> separate configure.exe, leading to a lot of duplicated effort.
>
> With the latest announcement from Microsoft, everything changes. Now that
> bash is natively supported, we will remove the ugly hack, and standardize
> on
> using the configure script for all platforms. The requirement for
> Windows 10 should not be a problem, since the upgrade is free anyway.
>
> We are finalizing the changes now, and aim to go live from 5.6.1. As a
> bonus,
> this should speed up the CI system for everyone, since we no longer have to
> test the obsolete Windows versions.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160401/cd38b37d/attachment.html>

From thiago.macieira at intel.com  Fri Apr  1 07:48:35 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 31 Mar 2016 22:48:35 -0700
Subject: [Development] Heads up! Fixing the build system on Windows
In-Reply-To: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
References: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
Message-ID: <1807262.K5YsaGzJ0H@tjmaciei-mobl4>

On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:
> The requirement for
> Windows 10 should not be a problem, since the upgrade is free anyway.

Oh, yes, it is. The problem is not the cost. The problem is the permission to 
use it. Many companies' IT departments are slow to validate a new OS on their 
networks and do not allow upgrading. I work for one such company.

Also remember the flame-war on the interest mailing list about requiring Perl 
to build Qt: conclusion was that many developers are simply not allowed to 
install anything (but they are allowed to build Qt).

So, no, this is probably a very bad idea for anything before 2018.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Fri Apr  1 07:49:33 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Thu, 31 Mar 2016 22:49:33 -0700
Subject: [Development] Heads up! Fixing the build system on Windows
In-Reply-To: <1807262.K5YsaGzJ0H@tjmaciei-mobl4>
References: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
	<1807262.K5YsaGzJ0H@tjmaciei-mobl4>
Message-ID: <5029706.Div9j2jFR3@tjmaciei-mobl4>

I want to point this out:

On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote:
> On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:

It's still March 31st.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From rolland at ghs.com  Fri Apr  1 08:22:42 2016
From: rolland at ghs.com (Rolland Dudemaine)
Date: Fri, 1 Apr 2016 08:22:42 +0200
Subject: [Development] gerrit : pointers to use it cleverly/efficiently?
In-Reply-To: <21164333.kbmRCzqGRv@tjmaciei-mobl4>
References: <1635019.vHF9KLjsb5@portia.local> <56FB8318.7000604@ghs.com>
	<21164333.kbmRCzqGRv@tjmaciei-mobl4>
Message-ID: <56FE13B2.9090206@ghs.com>


On 30/03/2016 18:04, Thiago Macieira wrote:
> On quarta-feira, 30 de março de 2016 09:41:12 PDT Rolland Dudemaine wrote:
>> git checkout -b temp origin/5.7
>> git cherry-pick first-commit-sha second-commit-sha (or just one of those)
>> git push gerrit HEAD:refs/for/5.7
>> git checkout 5.7
>> git branch -D temp
>>
>> But git-gpush as Thiago mentioned may be still far better...
> This is exactly what git gpush does, except that it does everything without 
> changing your checkout, which means you won't trigger a full rebuild-the-
> world. It has a few more features beyond that, including the ability to pass 
> reviewers in the command-line and handling of multiple patch groups in the 
> same branch, for those who are crazy to develop like I am.
>
> Sometimes, the cherry-picking without checkout fails. So you may have to do 
> the above anyway. If this happens often enough, like it does for me, I 
> recommend having a separate clone or git new-workdir, so you aren't forced to 
> rebuild the world.
>
Actually, git-gpush will update the whole history of changes that may be
on your checkout, not only the single one you're pushing. Just been
bitten by that this morning again, and that invalidates all your reviews
on gerrit.

Unless there is a magic I'm not aware of, the
temporary-branch-plus-cherry-pick is the only way to push a single
commit among a list of many.

--Rolland


From edward.welbourne at theqtcompany.com  Fri Apr  1 09:06:56 2016
From: edward.welbourne at theqtcompany.com (Welbourne Edward)
Date: Fri, 1 Apr 2016 07:06:56 +0000
Subject: [Development] gerrit : pointers to use it cleverly/efficiently?
In-Reply-To: <56FE13B2.9090206@ghs.com>
References: <1635019.vHF9KLjsb5@portia.local> <56FB8318.7000604@ghs.com>
	<21164333.kbmRCzqGRv@tjmaciei-mobl4>,<56FE13B2.9090206@ghs.com>
Message-ID: <VI1PR0201MB1568873E4D214D501D02630BFE9A0@VI1PR0201MB1568.eurprd02.prod.outlook.com>

Rolland Dudemaine said:
> Actually, git-gpush will update the whole history of changes that may
> be on your checkout, not only the single one you're pushing. Just been
> bitten by that this morning again, and that invalidates all your
> reviews on gerrit.

Well, any way of pushing is subject to that, yes.
The new commit can't arrive without all of its ancestors, that's a
feature of the git object model; and each of those ancestors has a
Commit-Id, so necessarily triggers an update to its review.

Not that this doesn't irritate me every time I trip over it ...

> Unless there is a magic I'm not aware of, the
> temporary-branch-plus-cherry-pick is the only way to push a single
> commit among a list of many.

That's probably inescapable, yes.

However, if there's a way to ask gerrit "here's a Commit-Id, please give
me the sha1 of its review's current patch set", then a script could
automate the

$ git checkout -b tmp $currentPSsha1^
$ git cherry-pick $newcommit
$ git push gerrit HEAD:refs/for/$branch

process.  I haven't played with gpush, so don't know if it knows how to
do that,

	Eddy.


From Lars.Knoll at theqtcompany.com  Fri Apr  1 09:12:04 2016
From: Lars.Knoll at theqtcompany.com (Knoll Lars)
Date: Fri, 1 Apr 2016 07:12:04 +0000
Subject: [Development] Changing definition of Qt meta macro to allow
 tools integration
In-Reply-To: <31066388.SzHpg1OhqY@tjmaciei-mobl4>
References: <2846913.44WYRE1kvo@finn> <1880440.IYmo2xS9RW@finn>
	<FC79F9CD-6488-4659-93EE-6B15F2F07840@theqtcompany.com>
	<31066388.SzHpg1OhqY@tjmaciei-mobl4>
Message-ID: <56CBB760-556C-4A26-A492-4000D898921D@theqtcompany.com>

On 31/03/16 20:33, "Development on behalf of Thiago Macieira" <development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of thiago.macieira at intel.com> wrote:



>On quinta-feira, 31 de março de 2016 08:01:54 PDT Knoll Lars wrote:
>> >Why would they need to deal with 5.6.0 specifically?  
>> >As you said in another mail, 5.6 is LTS, not 5.6.0
>> 
>> I’m with Olivier here. We will not support 5.6.0 in three years anymore.
>> What we will support is 5.6.x (x being the latest available patch level
>> release).
>
>This is a totally different definition of "support". Are you saying Qt Creator 
>will not be able to open projects linking to Qt 5.6.0 or older?

That’s not what I said. I see no reason why creator wouldn’t be able to open projects using older versions of Qt. But if we e.g. can’t autocomplete connections in those older projects I think that’s acceptable.

Cheers,
Lars

>
>> So it does make sense to put the patch into 5.6, if the creator team is
>> interested in using it.
>
>Sure, what is the team's opinion?
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

From Lars.Knoll at theqtcompany.com  Fri Apr  1 09:13:25 2016
From: Lars.Knoll at theqtcompany.com (Knoll Lars)
Date: Fri, 1 Apr 2016 07:13:25 +0000
Subject: [Development] Heads up! Fixing the build system on Windows
In-Reply-To: <5029706.Div9j2jFR3@tjmaciei-mobl4>
References: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
	<1807262.K5YsaGzJ0H@tjmaciei-mobl4> <5029706.Div9j2jFR3@tjmaciei-mobl4>
Message-ID: <C9B72D46-2781-4506-BC48-F4D50008AEF5@theqtcompany.com>

On 01/04/16 07:49, "Development on behalf of Thiago Macieira" <development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of thiago.macieira at intel.com> wrote:



>I want to point this out:
>
>On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote:
>> On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:
>
>It's still March 31st.

You’re just living in the wrong time zone ;-)

Cheers,
Lars


From andre at familiesomers.nl  Fri Apr  1 11:08:19 2016
From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=)
Date: Fri, 1 Apr 2016 11:08:19 +0200
Subject: [Development] Heads up! Fixing the build system on Windows
In-Reply-To: <5029706.Div9j2jFR3@tjmaciei-mobl4>
References: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
	<1807262.K5YsaGzJ0H@tjmaciei-mobl4> <5029706.Div9j2jFR3@tjmaciei-mobl4>
Message-ID: <56FE3A83.6050307@familiesomers.nl>



Op 01/04/2016 om 07:49 schreef Thiago Macieira:
> I want to point this out:
>
> On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote:
>> On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:
> It's still March 31st.
April Fools rules, #27: all jokes refer to the jokers' time zone.

André



From edward.welbourne at theqtcompany.com  Fri Apr  1 10:10:08 2016
From: edward.welbourne at theqtcompany.com (Welbourne Edward)
Date: Fri, 1 Apr 2016 08:10:08 +0000
Subject: [Development] Heads up! Fixing the build system on Windows
In-Reply-To: <C9B72D46-2781-4506-BC48-F4D50008AEF5@theqtcompany.com>
References: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
	<1807262.K5YsaGzJ0H@tjmaciei-mobl4>
	<5029706.Div9j2jFR3@tjmaciei-mobl4>,
	<C9B72D46-2781-4506-BC48-F4D50008AEF5@theqtcompany.com>
Message-ID: <VI1PR0201MB156862FA60058DD46D1F946FFE9A0@VI1PR0201MB1568.eurprd02.prod.outlook.com>

> On 01/04/16 07:49, Thiago Macieira wrote:
>> I want to point this out:
>>
>> On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote:
>>> On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:
>>
>> It's still March 31st.

Lars Knoll replied:
> You’re just living in the wrong time zone ;-)

Clearly we need a hastily-written RFC, to be published today if at all
possible, describing an extension to the e-mail protocol that ensures
delivery *after* some stipulated local-time, so that we can all (in
future years) include a suitable header in our early morning mails to
ensure they don't get *delivered* until the recipient considers the new
day to have begun.  That would avoid potential confusion of the kind
Thiago fell foul of, provided he uses a mailer implementing that RFC.

Since this RFC must, naturally, cope with arbitrary delivery times, it
shall need a section on what to do about DST transitions.  Fortunately,
this should be easy enough
 * for spring-forward, to be "after" any time in the elided interval is
   to be after the interval;
 * for fall-back, to be "after" a time in the repeated interval, we can
   conservatively insist on being after the second instance of it.
Other time-zone transitions should be treated analogously; I leave this
as an exercise for the reader (and am not volunteering to implement it).

	Eddy.


From Friedemann.Kleint at theqtcompany.com  Fri Apr  1 10:58:19 2016
From: Friedemann.Kleint at theqtcompany.com (Friedemann Kleint)
Date: Fri, 1 Apr 2016 10:58:19 +0200
Subject: [Development] Security bulletin: Deprecating QRect
In-Reply-To: <VI1PR0201MB1486763F55235F33EA1C8DEE8F890@VI1PR0201MB1486.eurprd02.prod.outlook.com>
References: <201603151407.29932.marc.mutz@kdab.com>
	<201603151543.46417.marc.mutz@kdab.com>
	<2862319B-A977-454D-8A29-09E1B976DA7D@digia.com>
	<201603151632.15111.marc.mutz@kdab.com>
	<VI1PR0201MB1486763F55235F33EA1C8DEE8F890@VI1PR0201MB1486.eurprd02.prod.outlook.com>
Message-ID: <56FE382B.2000902@theqtcompany.com>

Hi,

as discussed in the thread "Re: [Development] Fixing QRect::width() / 
height()", QRect can be misused to trigger undefined behaviour. This 
pattern has been observed in recent ransomware attacks using the new 
High DPI feature in Qt 5.6 to place windows at bottom right positions on 
High DPI screens inducing undefined behaviour. To fix this, the class 
QRect will be deprecated as of now in a patch release 5.6.0.1. The 
maintainers are kindly asked for a quick review of 
https://codereview.qt-project.org/154371 and the release team to prepare 
the patch release.

Regards,
Friedemann

-- 
Friedemann Kleint The Qt Company
  



From jkt at kde.org  Fri Apr  1 11:27:47 2016
From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=)
Date: Fri, 01 Apr 2016 11:27:47 +0200
Subject: [Development]
	=?iso-8859-1?q?gerrit_=3A_pointers_to_use_it_clever?=
	=?iso-8859-1?q?ly/efficiently=3F?=
In-Reply-To: <VI1PR0201MB1568873E4D214D501D02630BFE9A0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
References: <VI1PR0201MB1568873E4D214D501D02630BFE9A0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
Message-ID: <67e73f1a-1c8e-4ae6-8ac7-3604fa07d42c@kde.org>

On Friday, 1 April 2016 09:06:56 CEST, Welbourne Edward wrote:
> However, if there's a way to ask gerrit "here's a Commit-Id, please give
> me the sha1 of its review's current patch set"

You can extract this information from `ssh ... at gerrit gerrit query 
<ChangeId> --current-patch-set`. There are also REST end points with a 
similar functionality.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/


From Kai.Koehne at theqtcompany.com  Fri Apr  1 11:28:36 2016
From: Kai.Koehne at theqtcompany.com (Koehne Kai)
Date: Fri, 1 Apr 2016 09:28:36 +0000
Subject: [Development] qtwebkit fails to build
In-Reply-To: <CAOW9c=-MGw_EO8gRWRt3ncsGF4STETcWqxE+G5smzqM8VZSxRw@mail.gmail.com>
References: <CAOW9c=_6VzrorsNApaGCJ9Tby5pYhBUGr7RPHG39A5p=b2=ezw@mail.gmail.com>
	<CAOW9c=-MGw_EO8gRWRt3ncsGF4STETcWqxE+G5smzqM8VZSxRw@mail.gmail.com>
Message-ID: <DB3PR02MB234F89F63398161E4F63EEFE19A0@DB3PR02MB234.eurprd02.prod.outlook.com>

> -----Original Message-----
> [...]
> 	Failed to open file:
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathtags.in
> <http://mathtags.in>  at
> Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl
> <http://make_names.pl>  line 306.
> 	Makefile.WebCore.DerivedSources:786: recipe for target
> 'generated/MathMLNames.cpp' failed
> 	mingw32-make[3]: *** [generated/MathMLNames.cpp] Error 9
> 	mingw32-make[3]: Leaving directory
> 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> 	Makefile.WebCore:36: recipe for target 'sub-DerivedSources-pri-
> make_first-ordered' failed
> 	mingw32-make[2]: *** [sub-DerivedSources-pri-make_first-
> ordered] Error 2
> 	mingw32-make[2]: Leaving directory
> 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> 	Makefile:218: recipe for target 'sub-Source-WebCore-WebCore-pro-
> make_first-ordered' failed
> 	mingw32-make[1]: *** [sub-Source-WebCore-WebCore-pro-
> make_first-ordered] Error 2
> 	mingw32-make[1]: Leaving directory 'Z:/src/kde/qt5/qtwebkit'
> 	Makefile:1074: recipe for target 'module-qtwebkit-make_first'
> failed
> 	mingw32-make: *** [module-qtwebkit-make_first] Error 2
> 
> 	mathtags.in <http://mathtags.in>  exists at the location specified,
> just not being opened.

The call doesn't look wrong, and actually succeeds for me.

Maybe it's a defect of the perl version?  I'm using ActiveState Perl 5.16.3 (64 bit).  

You can also try to run the above command manually.

Finally, any online virus scanners active? ;)

Hope this helps,

Kai Koehne

From rjvbertin at gmail.com  Fri Apr  1 11:42:32 2016
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Fri, 01 Apr 2016 11:42:32 +0200
Subject: [Development] gerrit : pointers to use it cleverly/efficiently?
References: <1635019.vHF9KLjsb5@portia.local> <56FB8318.7000604@ghs.com>
	<21164333.kbmRCzqGRv@tjmaciei-mobl4> <56FE13B2.9090206@ghs.com>
	<VI1PR0201MB1568873E4D214D501D02630BFE9A0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
Message-ID: <20012097.db2oxm0hlz@patux.local>

Welbourne Edward wrote:

> Well, any way of pushing is subject to that, yes.
> The new commit can't arrive without all of its ancestors, that's a
> feature of the git object model; and each of those ancestors has a
> Commit-Id, so necessarily triggers an update to its review.
> 
> Not that this doesn't irritate me every time I trip over it ...

...

> 
>> Unless there is a magic I'm not aware of, the
>> temporary-branch-plus-cherry-pick is the only way to push a single
>> commit among a list of many.
> 
> That's probably inescapable, yes.

I haven't tried to "rebase" my mental models and parse everything that's been 
said, but it sure sounds a whole lot like my own gripes with gerrit's overhead 
for submitting a few simple(r) patches. Especially if you also want to maintain 
those for local builds on multiple hosts against a specific source version (think 
a file in debian/patches) rather than somehow exporting your local working copy 
with its subsequent commits to all those hosts.

Thinking aloud:

I may be old fashioned (aka a dinosaur) in this aspect, but I prefer seeing 
exactly which hunks of a set of changes (patchfile) require attention when 
updating, say, a patch conceived against v5.i to apply against v5.j. The larger 
the patch, the bigger the chance IMHO that you miss something crucial when 
automatic rebasing succeeds for all but a few hunks. I've seen it often enough 
for instance that a patch adds a line somewhere, and still applies when that 
change was already incorporated "upstream". That can lead to subtle regressions, 
depending on whether repeating the line (possibly multiple times) has side-
effects or not.

I suppose gerrit has the advantage (if advantage it is) of including the final 
commit message in the review process from the get go. It probably also means 
that final commit is done as a merge from the gerrit repo into the main repo 
rather than as a "manual" direct commit by the submitter - and I can see how 
that's an advantage. But it seems the one doesn't exclude the other.

Thiago mentioned how they cannot replace/upgrade gerrit for some reason. What 
might be possible is to maintain it only as a gateway for patches that have 
gotten the green light on whatever other review system that's deemed more 
powerful/modern/convenient to use.
FWIW, KDE is apparently transitioning to Phabricator - I don't yet have any 
experience with it so cannot comment on it one way or another.

> $ git checkout -b tmp $currentPSsha1^
> $ git cherry-pick $newcommit
> $ git push gerrit HEAD:refs/for/$branch

That really looks like updating your change set against a new remote version, 
and then uploading that new version for review ...

R.



From marc.mutz at kdab.com  Fri Apr  1 12:16:08 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Fri, 1 Apr 2016 12:16:08 +0200
Subject: [Development] gerrit : pointers to use it cleverly/efficiently?
In-Reply-To: <20012097.db2oxm0hlz@patux.local>
References: <1635019.vHF9KLjsb5@portia.local>
	<VI1PR0201MB1568873E4D214D501D02630BFE9A0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
	<20012097.db2oxm0hlz@patux.local>
Message-ID: <201604011216.08322.marc.mutz@kdab.com>

On Friday 01 April 2016 11:42:32 René J. V. Bertin wrote:
> I haven't tried to "rebase" my mental models and parse everything that's
> been  said, but it sure sounds a whole lot like my own gripes with
> gerrit's overhead

You may want to start here: http://hginit.com

Yes, it's about Mercurial, but it should re-educate you enough that you'll 
come to love git as much as every professional eventually does.

Fav Quote:

> It turns out that if you’ve been using Subversion, your brain is a little
> bit, um, how can I say this politely? You’re brain damaged

HTH,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From oswald.buddenhagen at theqtcompany.com  Fri Apr  1 12:56:23 2016
From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen)
Date: Fri, 1 Apr 2016 12:56:23 +0200
Subject: [Development] gerrit : pointers to use it cleverly/efficiently?
In-Reply-To: <56FE13B2.9090206@ghs.com>
References: <1635019.vHF9KLjsb5@portia.local> <56FB8318.7000604@ghs.com>
	<21164333.kbmRCzqGRv@tjmaciei-mobl4> <56FE13B2.9090206@ghs.com>
Message-ID: <20160401105623.GD19206@troll08.it.local>

On Fri, Apr 01, 2016 at 08:22:42AM +0200, Rolland Dudemaine wrote:
> 
> On 30/03/2016 18:04, Thiago Macieira wrote:
> > On quarta-feira, 30 de março de 2016 09:41:12 PDT Rolland Dudemaine wrote:
> >> But git-gpush as Thiago mentioned may be still far better...
> > This is exactly what git gpush does, except that it does everything without 
> > changing your checkout, which means you won't trigger a full rebuild-the-
> > world. It has a few more features beyond that, including the ability to pass 
> > reviewers in the command-line and handling of multiple patch groups in the 
> > same branch, for those who are crazy to develop like I am.
> >
> > Sometimes, the cherry-picking without checkout fails. So you may have to do 
> > the above anyway. If this happens often enough, like it does for me, I 
> > recommend having a separate clone or git new-workdir, so you aren't forced to 
> > rebuild the world.
> >
> Actually, git-gpush will update the whole history of changes that may be
> on your checkout, not only the single one you're pushing. Just been
> bitten by that this morning again, and that invalidates all your reviews
> on gerrit.
> 
> Unless there is a magic I'm not aware of, the
> temporary-branch-plus-cherry-pick is the only way to push a single
> commit among a list of many.
> 
thiago is talking about the advanced git-gpush that is work in progress.
you can check it out from my dashboard if you want. it's basically
production quality, but i still want to change the format of the state
files and don't feel like providing a migration path, so i'm not merging
it as-is.


From rjvbertin at gmail.com  Fri Apr  1 13:38:09 2016
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Fri, 01 Apr 2016 13:38:09 +0200
Subject: [Development] gerrit : pointers to use it cleverly/efficiently?
In-Reply-To: <201604011216.08322.marc.mutz@kdab.com>
References: <1635019.vHF9KLjsb5@portia.local> <20012097.db2oxm0hlz@patux.local>
	<201604011216.08322.marc.mutz@kdab.com>
Message-ID: <9100124.ygaFrxU3h4@portia.local>

On Friday April 01 2016 12:16:08 Marc Mutz wrote:

> You may want to start here: http://hginit.com
> 
> Yes, it's about Mercurial, but it should re-educate you enough that you'll 
> come to love git as much as every professional eventually does.

To put things straight: I don't hate git. I actually use it a lot, just a subset of its features and probably even those not to their fullest extent.

> > It turns out that if you’ve been using Subversion, your brain is a little
> > bit, um, how can I say this politely? You’re brain damaged

Well ... that's about just as funny and true as when a former supervisor called C++ an abomination (because different from his favourite, Modula-2) ;)

Since you mention Subversion: should I start loving git-svn just because I happen to be tapped into a couple of svn remotes? O:-)

R.


From markg85 at gmail.com  Fri Apr  1 13:49:22 2016
From: markg85 at gmail.com (Mark Gaiser)
Date: Fri, 1 Apr 2016 13:49:22 +0200
Subject: [Development] Security bulletin: Deprecating QRect
In-Reply-To: <56FE382B.2000902@theqtcompany.com>
References: <201603151407.29932.marc.mutz@kdab.com>
	<201603151543.46417.marc.mutz@kdab.com>
	<2862319B-A977-454D-8A29-09E1B976DA7D@digia.com>
	<201603151632.15111.marc.mutz@kdab.com>
	<VI1PR0201MB1486763F55235F33EA1C8DEE8F890@VI1PR0201MB1486.eurprd02.prod.outlook.com>
	<56FE382B.2000902@theqtcompany.com>
Message-ID: <CAPd6JnEfrhqmac7DSTP=iF8+PFeT6_jaFLeCmK9k9cb6rjpwzA@mail.gmail.com>

On Fri, Apr 1, 2016 at 10:58 AM, Friedemann Kleint <
Friedemann.Kleint at theqtcompany.com> wrote:

> Hi,
>
> as discussed in the thread "Re: [Development] Fixing QRect::width() /
> height()", QRect can be misused to trigger undefined behaviour. This
> pattern has been observed in recent ransomware attacks using the new High
> DPI feature in Qt 5.6 to place windows at bottom right positions on High
> DPI screens inducing undefined behaviour. To fix this, the class QRect will
> be deprecated as of now in a patch release 5.6.0.1. The maintainers are
> kindly asked for a quick review of
> https://codereview.qt-project.org/154371 and the release team to prepare
> the patch release.
>
> Regards,
> Friedemann
>
> --
> Friedemann Kleint The Qt Company
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

hehe, you nearly had me there.
April fools ;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160401/7c1d38cb/attachment.html>

From thiago.macieira at intel.com  Fri Apr  1 17:54:53 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 01 Apr 2016 08:54:53 -0700
Subject: [Development] Heads up! Fixing the build system on Windows
In-Reply-To: <C9B72D46-2781-4506-BC48-F4D50008AEF5@theqtcompany.com>
References: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
	<5029706.Div9j2jFR3@tjmaciei-mobl4>
	<C9B72D46-2781-4506-BC48-F4D50008AEF5@theqtcompany.com>
Message-ID: <5264371.dGmuJStkrY@tjmaciei-mobl4>

On sexta-feira, 1 de abril de 2016 07:13:25 PDT Knoll Lars wrote:
> >I want to point this out:
> >
> >On quinta-feira, 31 de março de 2016 22:48:35 PDT Thiago Macieira wrote:
> >
> >> On sexta-feira, 1 de abril de 2016 05:16:33 PDT Tvete Paul wrote:
> >
> >
> >It's still March 31st.
> 
> 
> You’re just living in the wrong time zone ;-)

Such jokes are not allowed while Anywhere on Earth is still not on April 1st. 
For more information on AoE

https://plus.google.com/+KaiKöhne/posts/XK6ENgLpK1o
https://en.wikipedia.org/wiki/Anywhere_on_Earth

(no, this is not an April Fools joke)
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From scott at towel42.com  Fri Apr  1 19:10:33 2016
From: scott at towel42.com (Scott Aron Bloom)
Date: Fri, 1 Apr 2016 17:10:33 +0000
Subject: [Development] Heads up! Fixing the build system on Windows
In-Reply-To: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
References: <DB3PR02MB011CBBF7A5AF7C4D73ADEBFFE9A0@DB3PR02MB011.eurprd02.prod.outlook.com>
Message-ID: <CY1PR10MB0170CA8AC76B7F3B5C089861A99A0@CY1PR10MB0170.namprd10.prod.outlook.com>

One thing that is not clear to me, what level of access the bash shell will have to the windows subsystem.  Apparently you will be able to run native linux applications inside the shell, but it is not clear if an X server will be made available, and what windows application will run under the bash shell.

As to the building on windows 10, one thing that I would recommend if you go down this path.   Have an option added to the cofnifuration to "package" the results into an installer.  Thus a company that hasn't migrated to Windows 10, can create a VM to do the build and install (which is common anyway) and package up their customer installer to deploy the installation inside their world

Scott

-----Original Message-----
From: Development [mailto:development-bounces+scott=towel42.com at qt-project.org] On Behalf Of Tvete Paul
Sent: Thursday, March 31, 2016 10:17 PM
To: development at qt-project.org
Subject: [Development] Heads up! Fixing the build system on Windows


As you may know, Lars is leading an effort to modularize the build system. One of the big headaches we have is that Windows uses a completely separate configure.exe, leading to a lot of duplicated effort.

With the latest announcement from Microsoft, everything changes. Now that bash is natively supported, we will remove the ugly hack, and standardize on using the configure script for all platforms. The requirement for Windows 10 should not be a problem, since the upgrade is free anyway.

We are finalizing the changes now, and aim to go live from 5.6.1. As a bonus, this should speed up the CI system for everyone, since we no longer have to test the obsolete Windows versions.
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From scott at towel42.com  Fri Apr  1 19:12:30 2016
From: scott at towel42.com (Scott Aron Bloom)
Date: Fri, 1 Apr 2016 17:12:30 +0000
Subject: [Development] QChart issues
Message-ID: <CY1PR10MB0170F10A2037F1232471395BA99A0@CY1PR10MB0170.namprd10.prod.outlook.com>

So, I have previously posted to interest@ and was told to post my questions to development at .  Having posted my QChart issues, to development and receiving no reply, I am assuming development@ is NOT the best place to post questions/issues with QChart.

So Ill ask to both areas, where is the best place?

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160401/4048e7b9/attachment.html>

From partha1b at gmail.com  Sat Apr  2 13:33:48 2016
From: partha1b at gmail.com (Partha Bagchi)
Date: Sat, 2 Apr 2016 07:33:48 -0400
Subject: [Development] qtwebkit fails to build
In-Reply-To: <DB3PR02MB234F89F63398161E4F63EEFE19A0@DB3PR02MB234.eurprd02.prod.outlook.com>
References: <CAOW9c=_6VzrorsNApaGCJ9Tby5pYhBUGr7RPHG39A5p=b2=ezw@mail.gmail.com>
	<CAOW9c=-MGw_EO8gRWRt3ncsGF4STETcWqxE+G5smzqM8VZSxRw@mail.gmail.com>
	<DB3PR02MB234F89F63398161E4F63EEFE19A0@DB3PR02MB234.eurprd02.prod.outlook.com>
Message-ID: <CAOW9c=-4ci5Hu63rnCTt3z+cfyex3Zurn00JjvFy9ziO8HLn8Q@mail.gmail.com>

On Fri, Apr 1, 2016 at 5:28 AM, Koehne Kai <Kai.Koehne at theqtcompany.com>
wrote:

> > -----Original Message-----
> > [...]
> >       Failed to open file:
> > Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathtags.in
> > <http://mathtags.in>  at
> > Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl
> > <http://make_names.pl>  line 306.
> >       Makefile.WebCore.DerivedSources:786: recipe for target
> > 'generated/MathMLNames.cpp' failed
> >       mingw32-make[3]: *** [generated/MathMLNames.cpp] Error 9
> >       mingw32-make[3]: Leaving directory
> > 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> >       Makefile.WebCore:36: recipe for target 'sub-DerivedSources-pri-
> > make_first-ordered' failed
> >       mingw32-make[2]: *** [sub-DerivedSources-pri-make_first-
> > ordered] Error 2
> >       mingw32-make[2]: Leaving directory
> > 'Z:/src/kde/qt5/qtwebkit/Source/WebCore'
> >       Makefile:218: recipe for target 'sub-Source-WebCore-WebCore-pro-
> > make_first-ordered' failed
> >       mingw32-make[1]: *** [sub-Source-WebCore-WebCore-pro-
> > make_first-ordered] Error 2
> >       mingw32-make[1]: Leaving directory 'Z:/src/kde/qt5/qtwebkit'
> >       Makefile:1074: recipe for target 'module-qtwebkit-make_first'
> > failed
> >       mingw32-make: *** [module-qtwebkit-make_first] Error 2
> >
> >       mathtags.in <http://mathtags.in>  exists at the location
> specified,
> > just not being opened.
>
> The call doesn't look wrong, and actually succeeds for me.
>
> Maybe it's a defect of the perl version?  I'm using ActiveState Perl
> 5.16.3 (64 bit).
>
I am using 5.18.2. However, I'll update to the latest version to see if
this makes a difference.

>
> You can also try to run the above command manually.
>
I did. No change. :(

>
> Finally, any online virus scanners active? ;)
>
Nope. :)

>
> Hope this helps,
>
> Kai Koehne
>

Thanks for responding. I really appreciate it!

I have a question. I am curious that it took 1 day to receive your
response. I got it this morning (US east coast) and Google says it was
posted 1 day ago. Also, I see other posts with the prefix [development]
while my posts don't have this.

What am I missing?

Thanks in advance,
Partha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160402/77fa1e07/attachment.html>

From annulen at yandex.ru  Sun Apr  3 16:17:06 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Sun, 03 Apr 2016 17:17:06 +0300
Subject: [Development] gerrit : pointers to use it cleverly/efficiently?
In-Reply-To: <9100124.ygaFrxU3h4@portia.local>
References: <1635019.vHF9KLjsb5@portia.local> <20012097.db2oxm0hlz@patux.local>
	<201604011216.08322.marc.mutz@kdab.com>
	<9100124.ygaFrxU3h4@portia.local>
Message-ID: <910861459693026@web9m.yandex.ru>



01.04.2016, 14:57, "René J.V. Bertin" <rjvbertin at gmail.com>:
> On Friday April 01 2016 12:16:08 Marc Mutz wrote:
>
>>  You may want to start here: http://hginit.com
>>
>>  Yes, it's about Mercurial, but it should re-educate you enough that you'll
>>  come to love git as much as every professional eventually does.
>
> To put things straight: I don't hate git. I actually use it a lot, just a subset of its features and probably even those not to their fullest extent.

In this case you should not hate Gerrit as well because its patch submission process runs solely on "git push" command

>
>>  > It turns out that if you’ve been using Subversion, your brain is a little
>>  > bit, um, how can I say this politely? You’re brain damaged
>
> Well ... that's about just as funny and true as when a former supervisor called C++ an abomination (because different from his favourite, Modula-2) ;)
>
> Since you mention Subversion: should I start loving git-svn just because I happen to be tapped into a couple of svn remotes? O:-)
>
> R.
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From rjvbertin at gmail.com  Mon Apr  4 11:31:36 2016
From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin)
Date: Mon, 04 Apr 2016 11:31:36 +0200
Subject: [Development] gerrit : using branches (was: pointers to use it
	cleverly/efficiently?)
References: <1635019.vHF9KLjsb5@portia.local>
	<VI1PR0201MB1568CCF6B9D1C3CED2B03B1FFE980@VI1PR0201MB1568.eurprd02.prod.outlook.com>
	<1885186.XDnYivrAq4@patux>
	<VI1PR0201MB1568FA7A0BB9864A34D5E312FE980@VI1PR0201MB1568.eurprd02.prod.outlook.com>
Message-ID: <7161389.ZVO13hC0Wa@patux.local>

Welbourne Edward wrote:


Hi,

>> What works well for me e.g. before doing a commit is what I think of
>> as manual rebasing: I remove my patches one way or another, git-pull,
>> and then reapply the patch(es).
> 
> That's pretty much exactly what
> 
> $ git pull -r
> 
> (a.k.a. --rebase) will do for you, automagically.  It might not play
> ideally with merges in all cases, but I'm guessing you don't have a
> surfeit of those.

Actually, it only does that after you committed your changes.

More often than not I don't because I need to be able to maintain patchfiles that 
apply against head or else a known commit (e.g. one that corresponds to a 
release). And I prefer to do that without having to remember to specify the 2 
commit hashes to be compared explicitly.

Now I suppose I could maintain and commit my changes in a personal topic branch 
if
- one can sync such a branch w.r.t. (rebase on) a specific commit from the 
original branch (i.e. not just against head)
- if there's a convenience command to obtain a complete diff of the topic 
branch's head against the current state of some other branch.

Apologies if I missed those from your earlier replies.

With "complete diff" I mean something like `git diff --no-ext-diff head -- .` 
though it may be that I only need those extra options to get newly added (but 
not committed) or deleted files included in the diff.

Thanks,
R.



From annulen at yandex.ru  Mon Apr  4 12:03:53 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Mon, 04 Apr 2016 13:03:53 +0300
Subject: [Development] gerrit : using branches (was: pointers to use it
	cleverly/efficiently?)
In-Reply-To: <7161389.ZVO13hC0Wa@patux.local>
References: <1635019.vHF9KLjsb5@portia.local>
	<VI1PR0201MB1568CCF6B9D1C3CED2B03B1FFE980@VI1PR0201MB1568.eurprd02.prod.outlook.com>
	<1885186.XDnYivrAq4@patux>
	<VI1PR0201MB1568FA7A0BB9864A34D5E312FE980@VI1PR0201MB1568.eurprd02.prod.outlook.com>
	<7161389.ZVO13hC0Wa@patux.local>
Message-ID: <9183301459764233@web26m.yandex.ru>



04.04.2016, 12:32, "René J. V. Bertin" <rjvbertin at gmail.com>:
> Welbourne Edward wrote:
>
> Hi,
>
>>>  What works well for me e.g. before doing a commit is what I think of
>>>  as manual rebasing: I remove my patches one way or another, git-pull,
>>>  and then reapply the patch(es).
>>
>>  That's pretty much exactly what
>>
>>  $ git pull -r
>>
>>  (a.k.a. --rebase) will do for you, automagically. It might not play
>>  ideally with merges in all cases, but I'm guessing you don't have a
>>  surfeit of those.
>
> Actually, it only does that after you committed your changes.
>
> More often than not I don't because I need to be able to maintain patchfiles that
> apply against head or else a known commit (e.g. one that corresponds to a
> release). And I prefer to do that without having to remember to specify the 2
> commit hashes to be compared explicitly.

In git you should use commits in branch instead of patchfiles.

If you need to produce actual patch files, you can always extract them with git format-patch.

>
> Now I suppose I could maintain and commit my changes in a personal topic branch
> if
> - one can sync such a branch w.r.t. (rebase on) a specific commit from the
> original branch (i.e. not just against head)
> - if there's a convenience command to obtain a complete diff of the topic
> branch's head against the current state of some other branch.
>
> Apologies if I missed those from your earlier replies.
>
> With "complete diff" I mean something like `git diff --no-ext-diff head -- .`
> though it may be that I only need those extra options to get newly added (but
> not committed) or deleted files included in the diff.
>
> Thanks,
> R.
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From edward.welbourne at theqtcompany.com  Mon Apr  4 12:25:16 2016
From: edward.welbourne at theqtcompany.com (Welbourne Edward)
Date: Mon, 4 Apr 2016 10:25:16 +0000
Subject: [Development] gerrit : using branches (was: pointers to use
	it	cleverly/efficiently?)
In-Reply-To: <7161389.ZVO13hC0Wa@patux.local>
References: <1635019.vHF9KLjsb5@portia.local>
	<VI1PR0201MB1568CCF6B9D1C3CED2B03B1FFE980@VI1PR0201MB1568.eurprd02.prod.outlook.com>
	<1885186.XDnYivrAq4@patux>
	<VI1PR0201MB1568FA7A0BB9864A34D5E312FE980@VI1PR0201MB1568.eurprd02.prod.outlook.com>,
	<7161389.ZVO13hC0Wa@patux.local>
Message-ID: <VI1PR0201MB1568328F1C6B9DA76E3DCEFBFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>

In response to:
>>> What works well for me e.g. before doing a commit is what I think of
>>> as manual rebasing: I remove my patches one way or another, git-pull,
>>> and then reapply the patch(es).

I offered:
>> That's pretty much exactly what
>>
>> $ git pull -r
>>
>> (a.k.a. --rebase) will do for you, automagically.  It might not play
>> ideally with merges in all cases, but I'm guessing you don't have a
>> surfeit of those.

René J. V. Bertin follows up with:
> Actually, it only does that after you committed your changes.

Indeed - most git actions presume a clean state.  You can, however, git
stash before such an operation, to save uncommitted local changes, and
git stash pop after to restore them.  So the above would become

$ git stash
$ git pull -r
$ git stash pop

> More often than not I don't because I need to be able to maintain
> patchfiles that apply against head or else a known commit (e.g. one
> that corresponds to a release). And I prefer to do that without having
> to remember to specify the 2 commit hashes to be compared explicitly.

When I have some patch I routinely need to apply, I commit it on a topic
branch (which gives the change a name and discourages git from garbage
collecting it) and then cherry-pick it onto whatever HEAD needs it (or a
temp branch off such a HEAD, or a detached HEAD, as appropriate).  I can
sporadically rebase the topic branch up whatever branch it's based on,
to move it past anything that introduces a conflict with it (resolving
that once).

> Now I suppose I could maintain and commit my changes in a personal topic branch
> if
> - one can sync such a branch w.r.t. (rebase on) a specific commit from the
> original branch (i.e. not just against head)

Yes, you can do that: you just need to know the specific commit's sha1,
then (with $patch as the patch-branch, $base as the original branch and
the specific sha1 as $specific):

$ git checkout $patch
$ git rebase --onto $specific $base

This takes every commit in $patch that's not in $base and replays it
starting from $specific, moving the $patch branch name to point at the
result.  (Of course, if you want to leave the $patch name where it is,
you can git checkout -b tmp $patch and use tmp in place of $patch, then
git branch -D tmp when you're done with it.)

> - if there's a convenience command to obtain a complete diff of the topic
> branch's head against the current state of some other branch.

Well, that'd just be: git diff $topic $other for the diff between two
tips of branches.  However, ...

> With "complete diff" I mean something like `git diff --no-ext-diff head -- .`
> though it may be that I only need those extra options to get newly added (but
> not committed) or deleted files included in the diff.

you seem to mean you want the diff between some $topic and the current
state of your work tree (rather than the last commit of the branch it's
on); that's just git diff $topic (with whatever other options you may
like, to taste).  If what you want is the diff between what you've
currently staged (with git add) and $topic, then throw in a --cached
option.

For three-way diffs between two commits and their most recent common
ancestor, you can use git diff $topic...$other, if you're comfortable
reading three-way diffs,

	Eddy.


From rjvbertin at gmail.com  Mon Apr  4 13:12:55 2016
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Mon, 04 Apr 2016 13:12:55 +0200
Subject: [Development] gerrit : using branches (was: pointers to use it
	cleverly/efficiently?)
In-Reply-To: <VI1PR0201MB1568328F1C6B9DA76E3DCEFBFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
References: <1635019.vHF9KLjsb5@portia.local> <7161389.ZVO13hC0Wa@patux.local>
	<VI1PR0201MB1568328F1C6B9DA76E3DCEFBFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
Message-ID: <1917793.j2KbfiTWLS@portia.local>

On Monday April 04 2016 10:25:16 Welbourne Edward wrote:

More very useful info, thanks!

> For three-way diffs between two commits and their most recent common
> ancestor, you can use git diff $topic...$other, if you're comfortable
> reading three-way diffs,

I could be - using a side-by-side visual tool ;) But don't think I'd need those most of the time.

> However, ...
> you seem to mean you want the diff between some $topic and the current
> state of your work tree (rather than the last commit of the branch it's
> on);

No, once I start using topic branches to "stash" my work there's no more need to accumulated unstaged changes, I suppose.

I'd still have to integrate this with my regular workflow though. Most of the time I'm using KDevelop nowadays, including its CVS features (like getting a diff on a single file or directory via the context menu, which I then use to copy/paste to my distribution patchfiles open in a different editor). That's really more geared towards unstaged changes from what I can tell.

I've seen graphical utilities that attempt to show the branch hierarchy in some kind of tree, but apparently miss from `git help branch` if it's possible to know the origin branch of a topic branch. Is it?

R.


From edward.welbourne at theqtcompany.com  Mon Apr  4 13:56:23 2016
From: edward.welbourne at theqtcompany.com (Welbourne Edward)
Date: Mon, 4 Apr 2016 11:56:23 +0000
Subject: [Development] gerrit : using branches (was: pointers to use it
 cleverly/efficiently?)
In-Reply-To: <1917793.j2KbfiTWLS@portia.local>
References: <1635019.vHF9KLjsb5@portia.local> <7161389.ZVO13hC0Wa@patux.local>
	<VI1PR0201MB1568328F1C6B9DA76E3DCEFBFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>,
	<1917793.j2KbfiTWLS@portia.local>
Message-ID: <VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>

René J.V. Bertin
> I've seen graphical utilities that attempt to show the branch
> hierarchy in some kind of tree,

You can even use: git log --graph
if you can cope with ASCII art ;-)

> but apparently miss from `git help branch` if it's possible to know
> the origin branch of a topic branch. Is it?

In some fundamental sense, git doesn't believe in a branch as anything
other than its current tip, with a directed graph of ancestor commits
stretching back from it.  It's important to understand that git doesn't
believe in any constraints on that directed graph other than being
acyclic (which causality suffices [0] to ensure, if all commits are done
with git tools).

Even when your revision graph is a strict tree, it can't tell which of
two branches was the "parent" and which the child; it only knows that
they have common histories past their last common ancestor - their
merge-base - if you have a strict tree, this isn't a merge, so it's
where one was branched off the other, but nothing about the merge-base
or any of its ancestors contains any hint as to which branch it was on
when it was committed.

When your history contains branching and merging - any acyclic directed
graph is permitted as a commit history - you can have two branches that
weave in and out of each other, thanks to cross-merging back and forth,
originating as branches off some entirely other branches that had done
the same, with some distant ancestor as merge-base.  If I give you the
graph of the resulting commit ancestry, with the current tips of some
branches labelled with their names, there's no way to tell which
branched off which other.  The branch names only exist at the tips.

[0] I imagine it would be possible, by hand-crafting, to build a cycle
in the object graph; but you'd need to ensure a consistent chain of
sha1s satisfying the necessary constraints.  I believe sha1 isn't broken
enough for us to yet know how to construct that (which amounts to trying
to concoct a new child commit with the same sha1 as one of its
ancestors, then removing the ancestor and substituting this child in its
place); if we did, I can imagine git getting quite upset if asked to
play with the result.

If I want to know what a branch is based on (and I carelessly didn't
include that in the name of the branch), I presume it's one of the usual
suspects (5.5, 5.6, 5.7, dev) and see which one has the closest ancestor
as git merge-base; or I pipe git shortlog 5.6...$branch | wc -l and
similar for each suspect base, to see which is shortest.  There's no way
to know what I branched off, but it's easy enough to work out which of a
given few branches is closest to a given tip.

	Eddy.


From rjvbertin at gmail.com  Mon Apr  4 14:49:34 2016
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Mon, 04 Apr 2016 14:49:34 +0200
Subject: [Development] gerrit : using branches (was: pointers to use it
	cleverly/efficiently?)
In-Reply-To: <VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
References: <1635019.vHF9KLjsb5@portia.local> <1917793.j2KbfiTWLS@portia.local>
	<VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
Message-ID: <1582533.LRt1gFfeIV@patux>

On Monday April 04 2016 11:56:23 Welbourne Edward wrote:

>You can even use: git log --graph
>if you can cope with ASCII art ;-)

As long as it doesn't include cows ;)

>merge-base - if you have a strict tree, this isn't a merge, so it's
>where one was branched off the other, but nothing about the merge-base
>or any of its ancestors contains any hint as to which branch it was on
>when it was committed.

In short, there's something like a table for each branch that tells what commits "belong" to that branch, but there's no way to obtain the branch from a given commit?


>suspects (5.5, 5.6, 5.7, dev) and see which one has the closest ancestor
>as git merge-base; or I pipe git shortlog 5.6...$branch | wc -l and

That looks like something not really trivial to capture in a script; you'd need to do `git merge-base $topic $branch` for all (remote) branches, and then check the returned commits against `git rev-list $topic` to see which comes first ... which might not even be correct under certain border cases.

Playing with it I get the impression that KDevelop does have a function to figure out parenthood; at least I now understand why it shows one of my 2 topic branches as a child of the other (both were created off the same commit).

R


From rjvbertin at gmail.com  Mon Apr  4 14:59:11 2016
From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin)
Date: Mon, 04 Apr 2016 14:59:11 +0200
Subject: [Development] gerrit : using branches (was: pointers to use it
	cleverly/efficiently?)
In-Reply-To: <VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
References: <1635019.vHF9KLjsb5@portia.local> <1917793.j2KbfiTWLS@portia.local>
	<VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
Message-ID: <6957412.VtvdcayqyO@patux>

Forgot - maybe a stupid question, but can you set up a topic branch to track a remote branch (and would that make sense)?

R


From edward.welbourne at theqtcompany.com  Mon Apr  4 17:12:33 2016
From: edward.welbourne at theqtcompany.com (Welbourne Edward)
Date: Mon, 4 Apr 2016 15:12:33 +0000
Subject: [Development] gerrit : using branches (was: pointers to use it
 cleverly/efficiently?)
In-Reply-To: <6957412.VtvdcayqyO@patux>
References: <1635019.vHF9KLjsb5@portia.local> <1917793.j2KbfiTWLS@portia.local>
	<VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>,
	<6957412.VtvdcayqyO@patux>
Message-ID: <VI1PR0201MB1568DE37E5130C2AE8BB7859FE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>

> Forgot - maybe a stupid question, but can you set up a topic branch to
> track a remote branch (and would that make sense)?

$ git checkout -b topic remote/branch

will, by default, set up topic so that, while it's checked out, git pull
fetches remote/branch to merge with it (or rebase it onto) and git push
sends HEAD to remote as an update to branch.  Note, however, that if you
have a local branch tracking remote/branch and use local branch instead
of remote/branch in your checkout, it'll do none of that set-up for you;
you'll need to git branch --set-upstream-to=remote/branch if that's what
you want; and, if you want to pull from remote/branch but push to
something else (e.g. remote/topic), you'll have to juggle with git
config (and I'm not actually sure what the details are).  See the man
page for git branch for details of setting what a branch tracks.

	Eddy.


From edward.welbourne at theqtcompany.com  Mon Apr  4 17:04:56 2016
From: edward.welbourne at theqtcompany.com (Welbourne Edward)
Date: Mon, 4 Apr 2016 15:04:56 +0000
Subject: [Development] gerrit : using branches (was: pointers to use it
 cleverly/efficiently?)
In-Reply-To: <1582533.LRt1gFfeIV@patux>
References: <1635019.vHF9KLjsb5@portia.local> <1917793.j2KbfiTWLS@portia.local>
	<VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>,
	<1582533.LRt1gFfeIV@patux>
Message-ID: <VI1PR0201MB1568B751A6DEF027D8FEC59FFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>

I mentioned:
>> merge-base - if you have a strict tree, this isn't a merge, so it's
>> where one was branched off the other, but nothing about the merge-base
>> or any of its ancestors contains any hint as to which branch it was on
>> when it was committed.

René J.V. Bertin replied:
> In short, there's something like a table for each branch that tells
> what commits "belong" to that branch, but there's no way to obtain the
> branch from a given commit?

There is no table.  Each commit is an object in a datastore, named by
its sha1.  The commit object contains information about the commit -
IIRC, the sha1 names of:
  * a "tree" object representing that commit's checked-out tree
  * one or (for a merge) more "parent" objects
along with the times and user info of authorship and commit; and the
commit message.  The "blob" for a commit is a simple text file packaging
this information; the sha1 that names the commit is the sha1 of the text
of this blob.

The .git/refs/heads directory contains files whose names are branches
and whose contents are sha1 IDs of commits.  When git looks at history,
it reads a branch's head file to get the current tip's sha1; it reads
the object with that sha1 to discover what the commit is; if it needs to
know history, it looks at the parent sha1(s) and finds the commit
objects named there and in the objects it thus ends up opening as it
traverses the directed graph of ancestry.  There is no database, no
table; just a filesystem [*], in which objects name other objects,
forming a directed acyclic graph of mutual references.

[*] technically, the object store ends up being a virtual filesystem, as
not all of the blobs are typically held on disk as separate files; many
of them get compressed together in a "pack file"; but this is just the
implementation of a virtual file system.  Pedagogically, git thinks it
just saves blobs as files to disk under .git/objects/: in practice, it's
usually more efficient than that.

In particular, although the refs/heads/ directory names some objects as
tips of branches, *nothing* in the git object store knows *anything*
about branches.  It only knows about commits, trees and files.  (Kinda.
It actually also knows about notes, signed tags and some other fun
meta-data - but nothing about branches.)  If you look at a commit
object, that object has no knowledge of being on any branch; it only
knows who its parents are, what tree object it describes and the user
info and times of its authorship and creation (these may be separate,
especially after cherry-picking or rebasing).  The nearest a commit gets
to knowing it's on any branch at all is the fact that it hasn't been
garbage-collected yet, so it must be an ancestor of some commit named by
some branch or (under refs/tags/) tag.  A commit doesn't even know what
other commits have it as a parent.

(When merging, the default commit message mentions the branches being
merged; so you could plausibly get some heuristics out of that.  All the
same, I can checkout -b a temp-branch from each branch, merge these,
then merge --ff-only each of the original branches to the resulting
merge point; the commit message shall name my temp-branches, yet the
result is clearly the result of merging the two branches I now have
pointing at that merge-point.  In any case, after a merge, I can git
commit --amend to change its commit message from the default.)

>> suspects (5.5, 5.6, 5.7, dev) and see which one has the closest
>> ancestor as git merge-base; or I pipe git shortlog 5.6...$branch | wc
>> -l and

> That looks like something not really trivial to capture in a script;

Indeed: git actually doesn't believe it's a meaningful question to ask.
I can move a branch name around arbitrarily, pointing it at the sha1 of
any commit in my object store, without making *any* changes to the
object store; only the file under .git/refs/heads/ changes.  You are
better off looking at your reflogs for information about what branched
off from where.

A branch is just a name that I'm temporarily giving to one commit while
preparing another, to which I'll soon move that name.  I sometimes
inadvertently make a bunch of commits on my local 5.6 (which I normally
keep shadowing a pristine origin/5.6); I could branch off a side-branch
while I'm doing that; sooner or later, I'll notice my mistake and do the

$ git branch local-changes
$ git reset --hard origin/5.6
$ git checkout local-changes

that gets my 5.6 back to where it's meant to be and gives a name to the
changes I'm working on.  If I forked off my side-branch from this set of
changes, several commits clear of where my 5.6 parted company with
origin/5.6 but before the tip at which I renamed the local development
to local-changes, do you think I branched my side-branch off from 5.6
(which might never again include the commit at which the side-branch set
off) or from local-changes (which didn't exist when I created the
side-branch) ?  From git's point of view the only thing that it's
interesting to say is that there's a merge-base prior to which
local-changes and the side-branch share common history; and this
merge-base is more recent than their common merge-base with origin/5.6.

> you'd need to do `git merge-base $topic $branch` for all (remote)
> branches, and then check the returned commits against `git rev-list
> $topic` to see which comes first ... which might not even be correct
> under certain border cases.

I am quite sure that any heuristic for guessing inter-branch ancestry
relations from the ancestry digraph of the object store shall go wrong
in plenty of ways.  You might want to use git merge-base --fork-point
rather than the plain merge-base as raw material for those heuristics;
but it'll still be error-prone.

> Playing with it I get the impression that KDevelop does have a
> function to figure out parenthood; at least I now understand why it
> shows one of my 2 topic branches as a child of the other (both were
> created off the same commit).

If you care about "forked off from" relationships among branches, I
encourage you to use a naming scheme for your branches that lets you
keep track of this.

	Eddy.


From thiago.macieira at intel.com  Mon Apr  4 18:10:49 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 04 Apr 2016 09:10:49 -0700
Subject: [Development] gerrit : using branches (was: pointers to use it
	cleverly/efficiently?)
In-Reply-To: <VI1PR0201MB1568328F1C6B9DA76E3DCEFBFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
References: <1635019.vHF9KLjsb5@portia.local> <7161389.ZVO13hC0Wa@patux.local>
	<VI1PR0201MB1568328F1C6B9DA76E3DCEFBFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
Message-ID: <3682082.Ht75SVI1YU@tjmaciei-mobl4>

On segunda-feira, 4 de abril de 2016 10:25:16 PDT Welbourne Edward wrote:
> $ git stash
> $ git pull -r
> $ git stash pop

Also:
$ git fetch
$ git rebase --autostash

It's exactly the same.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From frederik.gladhorn at theqtcompany.com  Tue Apr  5 14:08:36 2016
From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn)
Date: Tue, 5 Apr 2016 14:08:36 +0200
Subject: [Development] MSVC2012 in CI
In-Reply-To: <F9400714-92BD-4E01-8641-D32789F50F32@kdab.com>
References: <F9400714-92BD-4E01-8641-D32789F50F32@kdab.com>
Message-ID: <3108994.WkAvvHyZVt@frederik-thinkcentre-m93p>

On Sunday, March 20, 2016 12:07:01 PM Sean Harmer wrote:
> Hi,
> 
> Can MSVC 2012 configurations be removed from the CI please? My understanding
> is that this compiler was only kept around to support Windows EC but that
> this is now removed from 5.7.

I'd love to remove it, but it's blocked by https://bugreports.qt.io/browse/
QTBUG-51934
We cannot just remove test coverage without testing some of the features on 
more modern platforms.
In this case msvc 2012 is the platform where we test "DeveloperBuild, Release, 
QtNamespace, QtLibInfix" and I'd like to keep a windows build with these 
features. It seems to consistently fail on windows 10 though.
If there's not enough information in the bug, I'm happy to provide it. As long 
as that test keeps failing, we won't get rid of msvc 2012.

Cheers,
Frederik

> In particular this compiler is a blocker to
> using a using declaration such as:
> 
> template<typename T>
> using QNodeCreatedChangePtr = QSharedPointer<QNodeCreatedChange<T>>;
> 
> Kind regards,
> 
> Sean
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



From mwoehlke.floss at gmail.com  Tue Apr  5 18:04:35 2016
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Tue, 05 Apr 2016 12:04:35 -0400
Subject: [Development] gerrit : using branches
In-Reply-To: <1582533.LRt1gFfeIV@patux>
References: <1635019.vHF9KLjsb5@portia.local>
	<1917793.j2KbfiTWLS@portia.local>	<VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
	<1582533.LRt1gFfeIV@patux>
Message-ID: <ne0nmj$auj$1@ger.gmane.org>

On 2016-04-04 08:49, René J.V. Bertin wrote:
> [...] there's no way to obtain the branch from a given commit?

There is `git name-rev`, but it may or may not work or give you the
"best" answer. At least it should give you *a* branch name if a SHA is
the tip of a local branch. I'm not sure offhand what it does if multiple
branches name the same SHA¹, or how it works with tags or non-local
branches. Note that this can give answers like `master~2`, i.e. it can
in at least some cases name commits that *aren't* the tip of a branch.

(¹ You should at least get *a* name. I don't know if you'll get all
possible names, or if it will just pick one.)

You should also look at gitk, which will show you the graph, including
all names (tags as well as branches) of named SHA's. (The `--decorate`
option to `git log` does this also.)

-- 
Matthew



From jkt at kde.org  Tue Apr  5 21:58:53 2016
From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=)
Date: Tue, 05 Apr 2016 21:58:53 +0200
Subject: [Development] gerrit : using branches
In-Reply-To: <ne0nmj$auj$1@ger.gmane.org>
References: <1635019.vHF9KLjsb5@portia.local> <1917793.j2KbfiTWLS@portia.local>
	<VI1PR0201MB1568017BA4053E832A1CD5CCFE9D0@VI1PR0201MB1568.eurprd02.prod.outlook.com>
	<1582533.LRt1gFfeIV@patux> <ne0nmj$auj$1@ger.gmane.org>
Message-ID: <da70c148-8ccb-49ed-b2bf-9d831bd5061b@kde.org>

If you want to know the names of all branches which contain a given ref, 
there's also the `git branch --contains yourRef`.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/


From giuseppe.dangelo at kdab.com  Tue Apr  5 22:56:07 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Tue, 5 Apr 2016 22:56:07 +0200
Subject: [Development] QtQuick Call for Maintainer
In-Reply-To: <52D67DAD-94DF-433E-B4A4-6E17B7352C1B@theqtcompany.com>
References: <CALX7-s4H-iHOWFeLPRQr2TLTaRsUeoe-Jb=5Bez+aQ76jXKTrA@mail.gmail.com>
	<7811068.TYrtjBnhy4@frederik-thinkcentre-m93p>
	<CALX7-s4haig9pwwDEVxS6wK8u-oLEgdnedw+tV8uAcAxRE5f5A@mail.gmail.com>
	<52D67DAD-94DF-433E-B4A4-6E17B7352C1B@theqtcompany.com>
Message-ID: <57042667.6080302@kdab.com>

Il 10/03/2016 08:37, Knoll Lars ha scritto:
>> >
>> >Individually or together, +1 from me.
> Fully agree with what Alan is saying, so another +1 from me.

I guess it's time to do the honours then? :)

Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4068 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160405/a113eea2/attachment.bin>

From thiago.macieira at intel.com  Wed Apr  6 00:41:46 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 05 Apr 2016 15:41:46 -0700
Subject: [Development] QTBUG-52360: is ARMv5 still supported?
Message-ID: <17204890.D7mepRz2MG@tjmaciei-mobl4>

If it is, can someone try a regular toolchain for that platform with Qt 5.6 
and report whether QtCore links? I'd like a second opinion with a different 
toolchain than the reporter.

The question is: if you use <atomic> functionality, do you need an extra -l 
flag?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Lars.Knoll at theqtcompany.com  Wed Apr  6 07:55:35 2016
From: Lars.Knoll at theqtcompany.com (Knoll Lars)
Date: Wed, 6 Apr 2016 05:55:35 +0000
Subject: [Development] QtQuick Call for Maintainer
In-Reply-To: <57042667.6080302@kdab.com>
References: <CALX7-s4H-iHOWFeLPRQr2TLTaRsUeoe-Jb=5Bez+aQ76jXKTrA@mail.gmail.com>
	<7811068.TYrtjBnhy4@frederik-thinkcentre-m93p>
	<CALX7-s4haig9pwwDEVxS6wK8u-oLEgdnedw+tV8uAcAxRE5f5A@mail.gmail.com>
	<52D67DAD-94DF-433E-B4A4-6E17B7352C1B@theqtcompany.com>
	<57042667.6080302@kdab.com>
Message-ID: <C8EEB862-7A99-4857-9D91-3368BF3CF728@theqtcompany.com>

On 05/04/16 22:56, "Development on behalf of Giuseppe D'Angelo" <development-bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of giuseppe.dangelo at kdab.com> wrote:


>Il 10/03/2016 08:37, Knoll Lars ha scritto:
>>> >
>>> >Individually or together, +1 from me.
>> Fully agree with what Alan is saying, so another +1 from me.
>
>I guess it's time to do the honours then? :)

Indeed. I've edited the wiki and settings in codereview accordingly.

Congratulations Robin and Shawn!

Cheers,
Lars


From nospam at vuorela.dk  Wed Apr  6 08:24:12 2016
From: nospam at vuorela.dk (Sune Vuorela)
Date: Wed, 6 Apr 2016 06:24:12 +0000 (UTC)
Subject: [Development] QTBUG-52360: is ARMv5 still supported?
References: <17204890.D7mepRz2MG@tjmaciei-mobl4>
Message-ID: <ne2a2c$6pu$1@ger.gmane.org>

On 2016-04-05, Thiago Macieira <thiago.macieira at intel.com> wrote:
> If it is, can someone try a regular toolchain for that platform with Qt 5.6 
> and report whether QtCore links? I'd like a second opinion with a different 
> toolchain than the reporter.

looks like 5.6 is built in debian/experimental on armel (v4t/v5)

build log:

https://buildd.debian.org/status/fetch.php?pkg=qtbase-opensource-src&arch=armel&ver=5.6.0%2Bdfsg-2&stamp=1458264198

Toolchain package versions: binutils_2.26-6 dpkg-dev_1.18.4
g++-5_5.3.1-11 gcc-5_5.3.1-11 libc6-dev_2.22-3 libstdc++-5-dev_5.3.1-11
libstdc++6_5.3.1-11 linux-libc-dev_4.4.4-2

The current patch series is in debian is:
http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/patches?h=experimental

and mostly look like backports to me or otherwise irrelevant to this

The configure line is a bit .. convoluted .. but can be somehow seen here:

http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/rules?h=experimental

Doesn't look like it has anything special.

/Sune



From alexander.blasche at theqtcompany.com  Wed Apr  6 09:34:37 2016
From: alexander.blasche at theqtcompany.com (Blasche Alexander)
Date: Wed, 6 Apr 2016 07:34:37 +0000
Subject: [Development] MSVC2012 in CI
In-Reply-To: <3108994.WkAvvHyZVt@frederik-thinkcentre-m93p>
References: <F9400714-92BD-4E01-8641-D32789F50F32@kdab.com>
	<3108994.WkAvvHyZVt@frederik-thinkcentre-m93p>
Message-ID: <DB5PR0201MB1800D42172CD9124FA90E8E19E9F0@DB5PR0201MB1800.eurprd02.prod.outlook.com>

> -----Original Message-----
> From: Development [mailto:development-
> bounces+alexander.blasche=theqtcompany.com at qt-project.org] On Behalf Of


> On Sunday, March 20, 2016 12:07:01 PM Sean Harmer wrote:
> > Hi,
> >
> > Can MSVC 2012 configurations be removed from the CI please? My
> understanding
> > is that this compiler was only kept around to support Windows EC but that
> > this is now removed from 5.7.
> 
> I'd love to remove it, but it's blocked by https://bugreports.qt.io/browse/
> QTBUG-51934
> We cannot just remove test coverage without testing some of the features on
> more modern platforms.
> In this case msvc 2012 is the platform where we test "DeveloperBuild, Release,
> QtNamespace, QtLibInfix" and I'd like to keep a windows build with these
> features. It seems to consistently fail on windows 10 though.

The removal should not reduce test coverage under any case. Why don't we simply setup a new system that is MSVC2015 with the above features? You have to replace the MSVC 2012 test platform with a new compiler but the same config features anyway, no?

Or are you saying that the failure is MSVC 2012 specific...

--
Alex


From alexander.blasche at theqtcompany.com  Wed Apr  6 10:12:30 2016
From: alexander.blasche at theqtcompany.com (Blasche Alexander)
Date: Wed, 6 Apr 2016 08:12:30 +0000
Subject: [Development] MSVC2012 in CI
In-Reply-To: <DB5PR0201MB1800D42172CD9124FA90E8E19E9F0@DB5PR0201MB1800.eurprd02.prod.outlook.com>
References: <F9400714-92BD-4E01-8641-D32789F50F32@kdab.com>
	<3108994.WkAvvHyZVt@frederik-thinkcentre-m93p>,
	<DB5PR0201MB1800D42172CD9124FA90E8E19E9F0@DB5PR0201MB1800.eurprd02.prod.outlook.com>
Message-ID: <DB5PR0201MB1800A98365CF38E02FF5D6329E9F0@DB5PR0201MB1800.eurprd02.prod.outlook.com>

Nevermind. It is MSVC2015 where it fails. 

--
Alex

________________________________________
From: Development <development-bounces+alexander.blasche=theqtcompany.com at qt-project.org> on behalf of Blasche Alexander <alexander.blasche at theqtcompany.com>
Sent: Wednesday, April 6, 2016 09:34
To: Gladhorn Frederik; development at qt-project.org
Subject: Re: [Development] MSVC2012 in CI

> -----Original Message-----
> From: Development [mailto:development-
> bounces+alexander.blasche=theqtcompany.com at qt-project.org] On Behalf Of


> On Sunday, March 20, 2016 12:07:01 PM Sean Harmer wrote:
> > Hi,
> >
> > Can MSVC 2012 configurations be removed from the CI please? My
> understanding
> > is that this compiler was only kept around to support Windows EC but that
> > this is now removed from 5.7.
>
> I'd love to remove it, but it's blocked by https://bugreports.qt.io/browse/
> QTBUG-51934
> We cannot just remove test coverage without testing some of the features on
> more modern platforms.
> In this case msvc 2012 is the platform where we test "DeveloperBuild, Release,
> QtNamespace, QtLibInfix" and I'd like to keep a windows build with these
> features. It seems to consistently fail on windows 10 though.

The removal should not reduce test coverage under any case. Why don't we simply setup a new system that is MSVC2015 with the above features? You have to replace the MSVC 2012 test platform with a new compiler but the same config features anyway, no?

Or are you saying that the failure is MSVC 2012 specific...

--
Alex
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From thiago.macieira at intel.com  Wed Apr  6 17:31:07 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 06 Apr 2016 08:31:07 -0700
Subject: [Development] QTBUG-52360: is ARMv5 still supported?
In-Reply-To: <ne2a2c$6pu$1@ger.gmane.org>
References: <17204890.D7mepRz2MG@tjmaciei-mobl4> <ne2a2c$6pu$1@ger.gmane.org>
Message-ID: <6606023.g22M0vfiT6@tjmaciei-mobl4>

On quarta-feira, 6 de abril de 2016 06:24:12 PDT Sune Vuorela wrote:
> On 2016-04-05, Thiago Macieira <thiago.macieira at intel.com> wrote:
> > If it is, can someone try a regular toolchain for that platform with Qt
> > 5.6
> > and report whether QtCore links? I'd like a second opinion with a
> > different
> > toolchain than the reporter.
> 
> looks like 5.6 is built in debian/experimental on armel (v4t/v5)
> 
> build log:
> 
> https://buildd.debian.org/status/fetch.php?pkg=qtbase-opensource-src&arch=ar
> mel&ver=5.6.0%2Bdfsg-2&stamp=1458264198

More specifically, it shows that atomic64.cpp compiled without extra help:


64-bit std::atomic auto-detection... ()
make[2]: Entering directory '/«BUILDDIR»/qtbase-opensource-src-5.6.0+dfsg/
config.tests/common/atomic64'
g++ -c -pipe -O2 -std=gnu++0x -Wall -W -fPIC  -I. -I../../../mkspecs/linux-g++ 
-o atomic64.o atomic64.cpp
g++ -Wl,-O1 -o atomic64 atomic64.o    
make[2]: Leaving directory '/«BUILDDIR»/qtbase-opensource-src-5.6.0+dfsg/
config.tests/common/atomic64'
64-bit std::atomic enabled.

So I'm going to say that the problem is in QTBUG-52360's reporter's toolchain.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Friedemann.Kleint at theqtcompany.com  Thu Apr  7 14:41:03 2016
From: Friedemann.Kleint at theqtcompany.com (Friedemann Kleint)
Date: Thu, 7 Apr 2016 14:41:03 +0200
Subject: [Development] MSVC2012 in CI
In-Reply-To: <3108994.WkAvvHyZVt@frederik-thinkcentre-m93p>
References: <F9400714-92BD-4E01-8641-D32789F50F32@kdab.com>
	<3108994.WkAvvHyZVt@frederik-thinkcentre-m93p>
Message-ID: <5706555F.7040303@theqtcompany.com>

Hi,

 >I'd love to remove it, but it's blocked by 
https://bugreports.qt.io/browse/QTBUG-51934
 >We cannot just remove test coverage without testing some of the 
features on more modern platforms.

We blacklisted the test for the moment, so, we could switch to MSVC2015 now.

Regards,
Friedemann

-- 
Friedemann Kleint | The Qt Company




From kangjoni76 at gmail.com  Thu Apr  7 14:46:36 2016
From: kangjoni76 at gmail.com (kang joni)
Date: Thu, 7 Apr 2016 19:46:36 +0700
Subject: [Development] msvc15 debug/release build crash Qt56 with MT/MTd
	config option?
Message-ID: <CAOmy0w+Fgyn32+K156bkvQ6Vy8Gihj=r2v65c564JNygNho-SQ@mail.gmail.com>

I tried to build qtbase 56 using lastest monthly build msvc15 from
vcblog Microsoft, and got debug assertion in debug build. Was this
supported MT/MTd config option . thanks


From joerg.bornemann at theqtcompany.com  Thu Apr  7 14:52:59 2016
From: joerg.bornemann at theqtcompany.com (Joerg Bornemann)
Date: Thu, 7 Apr 2016 14:52:59 +0200
Subject: [Development] msvc15 debug/release build crash Qt56 with MT/MTd
 config option?
In-Reply-To: <CAOmy0w+Fgyn32+K156bkvQ6Vy8Gihj=r2v65c564JNygNho-SQ@mail.gmail.com>
References: <CAOmy0w+Fgyn32+K156bkvQ6Vy8Gihj=r2v65c564JNygNho-SQ@mail.gmail.com>
Message-ID: <5706582B.2080006@theqtcompany.com>

On 07/04/2016 14:46, kang joni wrote:

> I tried to build qtbase 56 using lastest monthly build msvc15 from
> vcblog Microsoft, and got debug assertion in debug build.

What exactly does assert? Is there an assert message?

 > Was this supported MT/MTd config option .

I do not understand this sentence.


BR,

Joerg


From kangjoni76 at gmail.com  Thu Apr  7 16:40:53 2016
From: kangjoni76 at gmail.com (kang joni)
Date: Thu, 7 Apr 2016 21:40:53 +0700
Subject: [Development] msvc15 debug/release build crash Qt56 with MT/MTd
 config option?
Message-ID: <CAOmy0wK9+bEbdikG0F_u7BbsLrV4ghHrciCPF4m=op4_v43fdg@mail.gmail.com>

Sorry before for my bad english, my point is that by modifying
mkspecs\common\msvc-desktop.conf to
use /MT or /MTd option in QMAKE_CFLAGS_RELEASE and QMAKE_CFLAGS_DEBUG.

You could reproduce this via nuget download to use lastest msvc build
using following command:
"nuget.exe install VisualCppTools -source
http://vcppdogfooding.azurewebsites.net/nuget/ -Prerelease"
And build simple pathstroke example

Attach 2 screenshots showing the problem.

Also this is my first time using qt mailing list. There is no reply
button or simple hint to use.
How hard is to reply simple message.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 65330 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160407/7e48203d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.png
Type: image/png
Size: 17255 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160407/7e48203d/attachment-0001.png>

From Kai.Koehne at theqtcompany.com  Thu Apr  7 17:14:11 2016
From: Kai.Koehne at theqtcompany.com (Koehne Kai)
Date: Thu, 7 Apr 2016 15:14:11 +0000
Subject: [Development] msvc15 debug/release build crash Qt56 with MT/MTd
 config option?
In-Reply-To: <CAOmy0wK9+bEbdikG0F_u7BbsLrV4ghHrciCPF4m=op4_v43fdg@mail.gmail.com>
References: <CAOmy0wK9+bEbdikG0F_u7BbsLrV4ghHrciCPF4m=op4_v43fdg@mail.gmail.com>
Message-ID: <DB3PR02MB234563317E2598B740D12BAE1900@DB3PR02MB234.eurprd02.prod.outlook.com>

> -----Original Message-----
> From: Development [mailto:development-
> Subject: Re: [Development] msvc15 debug/release build crash Qt56 with
> MT/MTd config option?
> 
> Sorry before for my bad english, my point is that by modifying
> mkspecs\common\msvc-desktop.conf to use /MT or /MTd option in
> QMAKE_CFLAGS_RELEASE and QMAKE_CFLAGS_DEBUG.

In general, you cannot mix C++ dll's compiled with different versions of /MT /MD /MTd /MDd. That is, _if_ you want to switch away from the default, you have to do the change in the mkspec and _then_ reconfigure/recompile Qt , and then your application. If you use other C++ libs the need to be compiled with the same flag (and Visual Studio compiler), too.

Hope this helps.
 
> Also this is my first time using qt mailing list. There is no reply button or
> simple hint to use.
> How hard is to reply simple message.

This is just a standard mailing list that most people read through their e-mail client. So replying is the same as replying to any other mail ...

Regards

Kai

From from at alumni.stanford.edu  Sat Apr  9 03:28:25 2016
From: from at alumni.stanford.edu (from at alumni.stanford.edu)
Date: Fri, 8 Apr 2016 18:28:25 -0700
Subject: [Development] Class unable to view Qt5 Linux app
Message-ID: <CANmG5NH9j7XKTqY+FvwvQet3wMnx_D9qJ=zG9O5ku7j7rN=SCQ@mail.gmail.com>

Dear Qt Developers,

I'm teach a class this quarter at Stanford where the main software package
we are using is a Qt5 Linux app running on RHEL 6. Students with Windows or
Linux laptops aren't having problems, but students with Macs are.

In particular, when the students try to do a copy, they get the error
message

QXcbClipboard::setMimeData: Cannot set X11 selection owner

and the copy doesn't work. When they quit the application, they get the
additional message

QApplication::qAppName: Please instantiate the QApplication object first

Do any of you have any ideas on how we could fix this? Not being able to
copy is a big disadvantage to code development.

Many thanks!

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160408/f91ea88e/attachment.html>

From tommy8927 at gmail.com  Sat Apr  9 03:57:24 2016
From: tommy8927 at gmail.com (Tom Kulaga)
Date: Sat, 09 Apr 2016 01:57:24 +0000
Subject: [Development] Vulkan
Message-ID: <CAMWfBPGXg_TuuRAaQLMXb9SZU6EVFrUJZKX45hPav+yKbcG=Bg@mail.gmail.com>

Hi All,

Is anyone actively working on vulkan integration? Or even a QVulkanWidget?
I saw that d3d12 had a preview widget so thought it was reasonable to ask.

If anyone isn't I'm keen to have a crack. In terms of implementation, is it
as naively simple as creating a new widget similar to the QOpenGLWidget
one, just to get a drawable canvas up and running? I believe that on Linux
a xcb_window_t is used for vulkan samples and deep in the QPA I saw it too.

I was wondering if for a novice like me this would be feasible to actually
do?

Does the whole rendering stack need to transfer over to vulkan?

Regards
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160409/550ceef4/attachment.html>

From thiago.macieira at intel.com  Sat Apr  9 04:04:19 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 08 Apr 2016 19:04:19 -0700
Subject: [Development] Class unable to view Qt5 Linux app
In-Reply-To: <CANmG5NH9j7XKTqY+FvwvQet3wMnx_D9qJ=zG9O5ku7j7rN=SCQ@mail.gmail.com>
References: <CANmG5NH9j7XKTqY+FvwvQet3wMnx_D9qJ=zG9O5ku7j7rN=SCQ@mail.gmail.com>
Message-ID: <1868643.Y9E2Ov5uvR@tjmaciei-mobl4>

On sexta-feira, 8 de abril de 2016 18:28:25 PDT from at alumni.stanford.edu 
wrote:
> Dear Qt Developers,
> 
> I'm teach a class this quarter at Stanford where the main software package
> we are using is a Qt5 Linux app running on RHEL 6. Students with Windows or
> Linux laptops aren't having problems, but students with Macs are.
> 
> In particular, when the students try to do a copy, they get the error
> message
> 
> QXcbClipboard::setMimeData: Cannot set X11 selection owner

Why are you running a Linux application on a Mac? Are you ssh'ing into the 
RHEL 6 server and forwarding the X11 connection?

If so, I'd say that the X server that you have on those Mac is rather 
defective. Instead, I'd recommend you compile the app for Mac and run locally, 
not on the server.

> and the copy doesn't work. When they quit the application, they get the
> additional message
> 
> QApplication::qAppName: Please instantiate the QApplication object first

We need a testcase for this.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From from at alumni.stanford.edu  Sat Apr  9 04:13:22 2016
From: from at alumni.stanford.edu (from at alumni.stanford.edu)
Date: Fri, 8 Apr 2016 19:13:22 -0700
Subject: [Development] Class unable to view Qt5 Linux app
Message-ID: <CANmG5NEUNv56J2ZC===kQnQ=2RrmYw31pWP_smrV0PGHcAD6sg@mail.gmail.com>

Thiago,

Thank you for your reply. We are running the Linux app on a Cray
supercomputer. We need this computational power for the problems we are
seeking to solve.

Yes, we are ssh'ing into the RHEL 6 sever and forwarding the X11 connection.

Our sys admin had to install Qt5 for us to use the app and said that he
found the installation difficult. Is there any advice you might have for
installing Qt5 to help fix this problem?

Many thanks,

Bill


On sexta-feira, 8 de abril de 2016 18:28:25 PDT from at alumni.stanford.edu
wrote:

Dear Qt Developers,

I'm teach a class this quarter at Stanford where the main software package
we are using is a Qt5 Linux app running on RHEL 6. Students with Windows or
Linux laptops aren't having problems, but students with Macs are.

In particular, when the students try to do a copy, they get the error
message

QXcbClipboard::setMimeData: Cannot set X11 selection owner


Why are you running a Linux application on a Mac? Are you ssh'ing into the
RHEL 6 server and forwarding the X11 connection?

If so, I'd say that the X server that you have on those Mac is rather
defective. Instead, I'd recommend you compile the app for Mac and run
locally,
not on the server.

and the copy doesn't work. When they quit the application, they get the
additional message

QApplication::qAppName: Please instantiate the QApplication object first


We need a testcase for this.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel Open Source Technology Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160408/1a811217/attachment.html>

From sean.harmer at kdab.com  Sat Apr  9 11:06:23 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 09 Apr 2016 10:06:23 +0100
Subject: [Development] Vulkan
In-Reply-To: <CAMWfBPGXg_TuuRAaQLMXb9SZU6EVFrUJZKX45hPav+yKbcG=Bg@mail.gmail.com>
References: <CAMWfBPGXg_TuuRAaQLMXb9SZU6EVFrUJZKX45hPav+yKbcG=Bg@mail.gmail.com>
Message-ID: <9801348.8xkQNTa2WE@titan>

On Saturday 09 April 2016 01:57:24 Tom Kulaga wrote:
> Hi All,
> 
> Is anyone actively working on vulkan integration? Or even a QVulkanWidget?
> I saw that d3d12 had a preview widget so thought it was reasonable to ask.
> 
> If anyone isn't I'm keen to have a crack. In terms of implementation, is it
> as naively simple as creating a new widget similar to the QOpenGLWidget
> one, just to get a drawable canvas up and running? I believe that on Linux
> a xcb_window_t is used for vulkan samples and deep in the QPA I saw it too.
> 
> I was wondering if for a novice like me this would be feasible to actually
> do?
> 
> Does the whole rendering stack need to transfer over to vulkan?

It all depends what level of integration you are after. Using a QWindow and 
using Vulkan with it doesn't require much. Making something equivalent to 
QOpenGLWidget is much more work as you have to worry about compositing 
QPainter content into the window too.

Making a Vulkan backend for Qt Quick 2 is also more work, considerably more 
work than much of the other low hanging fruits that could be used to improve 
performance there on the existing OpenGL backend. Although, like the D3D12 
backend it might give better results on windows (for Vulkan capable hardware).

Putting a Vulkan backend on Qt 3D is a very real possibility and one where 
Vulkan could potentially make a big impact. This is something I want to 
investigate later after we have done a stable release or two of Qt 3D. The 
good thing is that Qt 3D's architecture maps very well to Vulkan (by design).

Some IHV's provide drivers that have OpenGL/Vulkan interop in that you can use 
both Vulkan and OpenGL on the same surface which would be another interesting 
option if this support becomes widespread.

If you want to have a go, then certainly nobody is going to stop you and you 
may well get some help. We have some early proof of concept stuff we can look 
to tidy up and publish along these lines.

Cheers,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From mitch.curtis at theqtcompany.com  Sat Apr  9 15:02:36 2016
From: mitch.curtis at theqtcompany.com (Curtis Mitch)
Date: Sat, 9 Apr 2016 13:02:36 +0000
Subject: [Development] QColor and HSL's hue
Message-ID: <VI1PR0201MB1469A4F00753F682591AE76EF1920@VI1PR0201MB1469.eurprd02.prod.outlook.com>

Is there any technical reason (besides compatibility) why QColor::hslHueF() can't return a value between 0 and 1?

I see that other projects do this:

https://developer.mozilla.org/en/docs/Web/CSS/color_value#hsl()
https://github.com/bgrins/TinyColor/issues/12

If the colour being represented by QColour is black, QColor::hslHueF() will return -1:

http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/painting/qcolor.cpp#n1787

This makes it difficult to construct colours from the HSL getters of QColor (when making a HSL-based colour picker, for example); how would I work around the case of a negative hue?

From rdieter at math.unl.edu  Sat Apr  9 15:44:10 2016
From: rdieter at math.unl.edu (Rex Dieter)
Date: Sat, 09 Apr 2016 08:44:10 -0500
Subject: [Development] Qt 5.6.1 ETA?
Message-ID: <neb0vb$ott$1@ger.gmane.org>

Curious what plans or eta is for a Qt 5.6.1 release?

http://wiki.qt.io/Qt-5.6-release

doesn't mention it.

-- Rex



From tuukka.turunen at theqtcompany.com  Sat Apr  9 16:15:18 2016
From: tuukka.turunen at theqtcompany.com (Turunen Tuukka)
Date: Sat, 9 Apr 2016 14:15:18 +0000
Subject: [Development] Qt 5.6.1 ETA?
In-Reply-To: <neb0vb$ott$1@ger.gmane.org>
References: <neb0vb$ott$1@ger.gmane.org>
Message-ID: <28BACEC6-B15A-473D-A5CC-84F8CCCD81FA@theqtcompany.com>


It is in the works, but priority is to get Qt 5.7 Beta released. So probably towards end of April.

--
Tuukka

> Rex Dieter <rdieter at math.unl.edu> kirjoitti 9.4.2016 kello 16.44:
> 
> Curious what plans or eta is for a Qt 5.6.1 release?
> 
> http://wiki.qt.io/Qt-5.6-release
> 
> doesn't mention it.
> 
> -- Rex
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From laszlo.agocs at theqtcompany.com  Sat Apr  9 18:45:39 2016
From: laszlo.agocs at theqtcompany.com (Agocs Laszlo)
Date: Sat, 9 Apr 2016 16:45:39 +0000
Subject: [Development] Vulkan
In-Reply-To: <9801348.8xkQNTa2WE@titan>
References: <CAMWfBPGXg_TuuRAaQLMXb9SZU6EVFrUJZKX45hPav+yKbcG=Bg@mail.gmail.com>,
	<9801348.8xkQNTa2WE@titan>
Message-ID: <HE1PR0201MB1468DB1DBC7518A797C2041DFE920@HE1PR0201MB1468.eurprd02.prod.outlook.com>

Hi,

Sean's summary is perfect. If you are after integrating your Vulkan renderer into a non-Quick app, use a QWindow and QWidget::createWindowContainer, like the D3D12 samples did. All you need is a native window handle (e.g. a HWND on Windows which is exactly what QWindow::winId() will give you; on other platforms there are backend-specific means to acquire the native window via QPlatformNativeInterface).

Integrating Vulkan rendering into an OpenGL-based Qt Quick scene can be more complicated, so at first I would rather look at the (unfortunately vendor-specific) GL_NV_draw_vulkan_image extension. This, in combination with GL_KHR_vulkan_glsl, is likely the easiest way to get started and combine the two worlds.

Right now Qt Quick is undergoing certain changes to make it more modular, focusing on OpenGL, D3D, and the QPainter-based 2D Renderer for the time being. This will allow multiple backends in the future, instead of being tied to OpenGL (or the current iteration of the separate, somewhat hackish 2D renderer). There are a number of issues to be investigated still, but we expect most of the work to become available in Qt 5.8 and beyond.

However, it is important to note that a full-blown Vulkan (or Metal for that matter) backend for Qt Quick is not something that will be rushed, so I wouldn't expect much on that front short-term. The benefits of the new low-level APIs are expected to be fairly limited for the workloads typical user interfaces generate. (this naturally does not apply to Qt 3D)

Best regards,
Laszlo
________________________________________
From: Development <development-bounces+laszlo.agocs=theqtcompany.com at qt-project.org> on behalf of Sean Harmer <sean.harmer at kdab.com>
Sent: Saturday, April 9, 2016 11:06:23 AM
To: development at qt-project.org
Cc: Tom Kulaga
Subject: Re: [Development] Vulkan

On Saturday 09 April 2016 01:57:24 Tom Kulaga wrote:
> Hi All,
>
> Is anyone actively working on vulkan integration? Or even a QVulkanWidget?
> I saw that d3d12 had a preview widget so thought it was reasonable to ask.
>
> If anyone isn't I'm keen to have a crack. In terms of implementation, is it
> as naively simple as creating a new widget similar to the QOpenGLWidget
> one, just to get a drawable canvas up and running? I believe that on Linux
> a xcb_window_t is used for vulkan samples and deep in the QPA I saw it too.
>
> I was wondering if for a novice like me this would be feasible to actually
> do?
>
> Does the whole rendering stack need to transfer over to vulkan?

It all depends what level of integration you are after. Using a QWindow and
using Vulkan with it doesn't require much. Making something equivalent to
QOpenGLWidget is much more work as you have to worry about compositing
QPainter content into the window too.

Making a Vulkan backend for Qt Quick 2 is also more work, considerably more
work than much of the other low hanging fruits that could be used to improve
performance there on the existing OpenGL backend. Although, like the D3D12
backend it might give better results on windows (for Vulkan capable hardware).

Putting a Vulkan backend on Qt 3D is a very real possibility and one where
Vulkan could potentially make a big impact. This is something I want to
investigate later after we have done a stable release or two of Qt 3D. The
good thing is that Qt 3D's architecture maps very well to Vulkan (by design).

Some IHV's provide drivers that have OpenGL/Vulkan interop in that you can use
both Vulkan and OpenGL on the same surface which would be another interesting
option if this support becomes widespread.

If you want to have a go, then certainly nobody is going to stop you and you
may well get some help. We have some early proof of concept stuff we can look
to tidy up and publish along these lines.

Cheers,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From tommy8927 at gmail.com  Sun Apr 10 03:31:06 2016
From: tommy8927 at gmail.com (Tom Kulaga)
Date: Sun, 10 Apr 2016 01:31:06 +0000
Subject: [Development] Vulkan
In-Reply-To: <HE1PR0201MB1468DB1DBC7518A797C2041DFE920@HE1PR0201MB1468.eurprd02.prod.outlook.com>
References: <CAMWfBPGXg_TuuRAaQLMXb9SZU6EVFrUJZKX45hPav+yKbcG=Bg@mail.gmail.com>
	<9801348.8xkQNTa2WE@titan>
	<HE1PR0201MB1468DB1DBC7518A797C2041DFE920@HE1PR0201MB1468.eurprd02.prod.outlook.com>
Message-ID: <CAMWfBPE-jXfYgrRZu9a01evpqTuB1pq9TPAv386epXV5esXGow@mail.gmail.com>

Thanks guys for the detailed updates. I an appreciate any big sweeping
changes, aren't lite nor simple.

I was after using Vulkan (to learn the API) with a widgets interface for
now and going with the native window handle sounds simplest and best.

I'll give it a try (a D3D12 type vulkan widget) and see what I come up with
and if it's going to be of use to anyone I'll post it.

Thanks again

On Sun, 10 Apr 2016 02:45 Agocs Laszlo <laszlo.agocs at theqtcompany.com>
wrote:

> Hi,
>
> Sean's summary is perfect. If you are after integrating your Vulkan
> renderer into a non-Quick app, use a QWindow and
> QWidget::createWindowContainer, like the D3D12 samples did. All you need is
> a native window handle (e.g. a HWND on Windows which is exactly what
> QWindow::winId() will give you; on other platforms there are
> backend-specific means to acquire the native window via
> QPlatformNativeInterface).
>
> Integrating Vulkan rendering into an OpenGL-based Qt Quick scene can be
> more complicated, so at first I would rather look at the (unfortunately
> vendor-specific) GL_NV_draw_vulkan_image extension. This, in combination
> with GL_KHR_vulkan_glsl, is likely the easiest way to get started and
> combine the two worlds.
>
> Right now Qt Quick is undergoing certain changes to make it more modular,
> focusing on OpenGL, D3D, and the QPainter-based 2D Renderer for the time
> being. This will allow multiple backends in the future, instead of being
> tied to OpenGL (or the current iteration of the separate, somewhat hackish
> 2D renderer). There are a number of issues to be investigated still, but we
> expect most of the work to become available in Qt 5.8 and beyond.
>
> However, it is important to note that a full-blown Vulkan (or Metal for
> that matter) backend for Qt Quick is not something that will be rushed, so
> I wouldn't expect much on that front short-term. The benefits of the new
> low-level APIs are expected to be fairly limited for the workloads typical
> user interfaces generate. (this naturally does not apply to Qt 3D)
>
> Best regards,
> Laszlo
> ________________________________________
> From: Development <development-bounces+laszlo.agocs=
> theqtcompany.com at qt-project.org> on behalf of Sean Harmer <
> sean.harmer at kdab.com>
> Sent: Saturday, April 9, 2016 11:06:23 AM
> To: development at qt-project.org
> Cc: Tom Kulaga
> Subject: Re: [Development] Vulkan
>
> On Saturday 09 April 2016 01:57:24 Tom Kulaga wrote:
> > Hi All,
> >
> > Is anyone actively working on vulkan integration? Or even a
> QVulkanWidget?
> > I saw that d3d12 had a preview widget so thought it was reasonable to
> ask.
> >
> > If anyone isn't I'm keen to have a crack. In terms of implementation, is
> it
> > as naively simple as creating a new widget similar to the QOpenGLWidget
> > one, just to get a drawable canvas up and running? I believe that on
> Linux
> > a xcb_window_t is used for vulkan samples and deep in the QPA I saw it
> too.
> >
> > I was wondering if for a novice like me this would be feasible to
> actually
> > do?
> >
> > Does the whole rendering stack need to transfer over to vulkan?
>
> It all depends what level of integration you are after. Using a QWindow and
> using Vulkan with it doesn't require much. Making something equivalent to
> QOpenGLWidget is much more work as you have to worry about compositing
> QPainter content into the window too.
>
> Making a Vulkan backend for Qt Quick 2 is also more work, considerably more
> work than much of the other low hanging fruits that could be used to
> improve
> performance there on the existing OpenGL backend. Although, like the D3D12
> backend it might give better results on windows (for Vulkan capable
> hardware).
>
> Putting a Vulkan backend on Qt 3D is a very real possibility and one where
> Vulkan could potentially make a big impact. This is something I want to
> investigate later after we have done a stable release or two of Qt 3D. The
> good thing is that Qt 3D's architecture maps very well to Vulkan (by
> design).
>
> Some IHV's provide drivers that have OpenGL/Vulkan interop in that you can
> use
> both Vulkan and OpenGL on the same surface which would be another
> interesting
> option if this support becomes widespread.
>
> If you want to have a go, then certainly nobody is going to stop you and
> you
> may well get some help. We have some early proof of concept stuff we can
> look
> to tidy up and publish along these lines.
>
> Cheers,
>
> Sean
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160410/c01aeb4c/attachment.html>

From jasonsu at mail-central.com  Sun Apr 10 07:22:27 2016
From: jasonsu at mail-central.com (jasonsu at mail-central.com)
Date: Sat, 09 Apr 2016 22:22:27 -0700
Subject: [Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8 at
 least). Reproducible test case included.
Message-ID: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>

Use of Qt Keyboard shortcuts has been broken in Qt for years.

There are lots of bugs about it in Qt and KDE projects.

This one looks close to what I'm seeing,

	Can't assign keyboard shortcut with Meta modifiers
	https://bugreports.qt.io/browse/QTCREATORBUG-9846

This one got mentioned in a few KDE bugs

	Qt LineEdit incorrectly truncates "Password" dialog elements when entered with a KDE Custom Shortcut ...
	https://bugreports.qt.io/browse/QTBUG-24304

There are lots of others.

Anyway, the point is -- shortcuts don't work.

I have a reproducible test case. It's 100% reproducible on 4 machines.  Here anyway.

The Qt shortcuts fail only when used in Qt-based applications.
They work fine in NON-Qt apps (GTK, JAVE, etc).

I can't create a Qt account, can't add to any bug (not that I'm clear on which one).  Posting the testcase here.

I'm cc'ing to a couple of developer's named I saw in those bugs.  Maybe somebody will stick this in the right place.

-------------------------------------
on:
	/usr/bin/systemsettings5 -v
		systemsettings 5.6.2

exec:
	/usr/bin/systemsettings5

open:
	Configure Desktop
		Workspace
			Shortcuts
				Custom Shortcuts
					Configure Input Actions settings

in:
	'Name' pane

right-click:
	New
		Global Shortcut
			Send Keyboard Input

rename New action:
	TEST

select:
	TEST

in:
	'Trigger' Pane

click:
	Shortcut "None"

enter:
	Meta-Ctrl-Alt-L

click:
	Apply

in:
	'Action' Pane

enter:
	Shift+3:X

click:
	Apply

(1)
open:
	LibreOffice Writer v5.1.2.2.0 10m0(Build:2) document

press:
	Meta-Ctrl-Alt-L
	OUTPUT: "#X"

(2)
open:
	Eclipse Editor v4.6 (Build:I20160405-0800) document

press:
	Meta-Ctrl-Alt-L
	OUTPUT: "#X"

(3)
open:
	KDE Kate v15.12.3 document

press:
	Meta-Ctrl-Alt-L
	OUTPUT: (none); window flashes

(4)
open:
	QtCreator v3.6.0 (based on Qt 5.6.0) document

press:
	Meta-Ctrl-Alt-L
	OUTPUT: (none); window flashes
-------------------------------------

If someone knows a bug report that this'll get fixed at, pls post it there, and let us know here.

Jason


From thiago.macieira at intel.com  Sun Apr 10 09:14:01 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sun, 10 Apr 2016 00:14:01 -0700
Subject: [Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8
	at least). Reproducible test case included.
In-Reply-To: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>
References: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>
Message-ID: <5965708.yTG077uOzL@tjmaciei-mobl4>

On sábado, 9 de abril de 2016 22:22:27 PDT jasonsu at mail-central.com wrote:
> Use of Qt Keyboard shortcuts has been broken in Qt for years.
> 
> There are lots of bugs about it in Qt and KDE projects.
> 
> This one looks close to what I'm seeing,
> 
>         Can't assign keyboard shortcut with Meta modifiers
>         https://bugreports.qt.io/browse/QTCREATORBUG-9846
> 

> There are lots of others.
> 
> Anyway, the point is -- shortcuts don't work.

Yes, they do. Do you mean shortcuts with Meta?

There was a bug in 5.4 and 5.5 for shortcuts with Ctrl+Shift but it's fixed in 
5.6

> press:
>         Meta-Ctrl-Alt-L
>         OUTPUT: (none); window flashes

That has nothing to do with shortcuts. It appears that the way that khotkeysd 
sends keypresses isn't working in Creator. It's irrelevant what Creator does: 
the bug is in khotkeysd because it isn't sending the input in such a way that 
some applications can't ignore.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From jasonsu at mail-central.com  Sun Apr 10 17:33:15 2016
From: jasonsu at mail-central.com (jasonsu at mail-central.com)
Date: Sun, 10 Apr 2016 08:33:15 -0700
Subject: [Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8
 at least). Reproducible test case included.
In-Reply-To: <5965708.yTG077uOzL@tjmaciei-mobl4>
References: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>
	<5965708.yTG077uOzL@tjmaciei-mobl4>
Message-ID: <1460302395.3829070.574345649.7413EF92@webmail.messagingengine.com>



On Sun, Apr 10, 2016, at 12:14 AM, Thiago Macieira wrote:
> > press:
> >         Meta-Ctrl-Alt-L
> >         OUTPUT: (none); window flashes
> 
> That has nothing to do with shortcuts. It appears that the way that khotkeysd 
> sends keypresses isn't working in Creator. It's irrelevant what Creator does: 
> the bug is in khotkeysd because it isn't sending the input in such a way that 
> some applications can't ignore.

Great.  Sound like its something clear then.  It's khotkeys.  So, it's a KDE problem not Qt?

I've kept looking around, and as I said, there's lots of bugs reported about this stuff not working, including meta.  Some. of them blame khotkeys, some not  Some of them are old, some not.  I've no real idea why the problem is there, just that it is.  And looks like it has been for awhile.  So far, I didn't find a clear cause or solution.

What i DO find repeatedly is that KDE devs blame the problem squarely on Qt.

Shortcuts, if you need them, need the option for multi-key chords (like Meta-Ctrl-Alt) to avoid collisions with the scads of other, shorter combos that already exist.

Folks want a reproducible test case, So I gave one.

It's been that way for sice at least Qt 5.3 as far as Ive been able to test.

Folks want to know whether the latest versions of stuff fix the problem, so the reproducible test case uses the latest, stable versions my distro has.

"That has nothing to do with shortcuts."

TBH, I don't understand the semantics.  The Keyboard *Shortcuts* I create don't work.  But, If shortcuts-being-broken-when-using-meta is not the same as  shortcuts-being-broken, then - my bad.  Call it what it needs to be called.  I'm just trying to help with the test case.

Oh, and just to be clear.  This 'khotkeys' problem is not just in Creator, but all Qt-based apps .  Which I guess means for most of KDE.  That I've tried so far anyway.  In anything not-Qt, the hotkeys work just fine.

HTH.

Jason




From thiago.macieira at intel.com  Sun Apr 10 09:23:53 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sun, 10 Apr 2016 00:23:53 -0700
Subject: [Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8
	at least). Reproducible test case included.
In-Reply-To: <5965708.yTG077uOzL@tjmaciei-mobl4>
References: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>
	<5965708.yTG077uOzL@tjmaciei-mobl4>
Message-ID: <3912046.UWfBPtgkxK@tjmaciei-mobl4>

On domingo, 10 de abril de 2016 00:14:01 PDT Thiago Macieira wrote:
> > press:
> >         Meta-Ctrl-Alt-L
> >         OUTPUT: (none); window flashes
> 
> That has nothing to do with shortcuts. It appears that the way that
> khotkeysd  sends keypresses isn't working in Creator. It's irrelevant what
> Creator does: the bug is in khotkeysd because it isn't sending the input in
> such a way that some applications can't ignore.

According to qev, Qt 5 is seeing these events:

QKeyEvent(ShortcutOverride, Key_Control, ControlModifier)
QKeyEvent(KeyPress, Key_Control, ControlModifier)
QKeyEvent(ShortcutOverride, Key_Meta, ControlModifier|MetaModifier)
QKeyEvent(KeyPress, Key_Meta, ControlModifier|MetaModifier)
QKeyEvent(ShortcutOverride, Key_Alt, ControlModifier|AltModifier|MetaModifier)
QKeyEvent(KeyPress, Key_Alt, ControlModifier|AltModifier|MetaModifier)
QEvent(WindowDeactivate, 0x7ffe906ee2a0)
QEvent(ActivationChange, 0x7ffe906ee2e0)
QEvent(WindowActivate, 0x7ffe906ee2c0)
QEvent(ActivationChange, 0x7ffe906ee2e0)
QInputMethodQueryEvent(queries=0x101, {})
QKeyEvent(ShortcutOverride, Key_3, ShiftModifier, text="\u001B")
QKeyEvent(KeyPress, Key_3, ShiftModifier, text="\u001B")
QKeyEvent(KeyRelease, Key_3, ShiftModifier, text="\u001B")
QKeyEvent(ShortcutOverride, Key_X, text="\u0018")
QKeyEvent(KeyPress, Key_X, text="\u0018")
QKeyEvent(KeyRelease, Key_X, text="\u0018")
QKeyEvent(KeyRelease, Key_L, ControlModifier|AltModifier|MetaModifier, text="\f")
QKeyEvent(KeyRelease, Key_Alt, ControlModifier|MetaModifier)
QKeyEvent(KeyRelease, Key_Meta, ControlModifier)
QKeyEvent(KeyRelease, Key_Control)

As you can see, Qt did receive "Shift+3" and "X", but the text lookup returned 
the result for Ctrl+3 and Ctrl+X.

As I said, the failure is in khotkeys: it needs to send the events in such a 
way that the application can't tell the difference. Obviously, Qt 5 did.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From jasonsu at mail-central.com  Sun Apr 10 19:05:44 2016
From: jasonsu at mail-central.com (jasonsu at mail-central.com)
Date: Sun, 10 Apr 2016 10:05:44 -0700
Subject: [Development] KDE Custom Shortcuts broken,
 problem's id'd as in khotkeys (was: Qt Keyboard Shortcuts broken in
 Qt 5.6 (since 4.8 at least). Reproducible test case included.)
In-Reply-To: <3912046.UWfBPtgkxK@tjmaciei-mobl4>
References: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>
	<5965708.yTG077uOzL@tjmaciei-mobl4> <3912046.UWfBPtgkxK@tjmaciei-mobl4>
Message-ID: <1460307944.453292.574393313.27747EB1@webmail.messagingengine.com>

On Sun, Apr 10, 2016, at 12:23 AM, Thiago Macieira wrote:
> As I said, the failure is in khotkeys: it needs to send the events in such a 
> way that the application can't tell the difference. Obviously, Qt 5 did.

Ok, so it's definitely a khotkeys problem, in KDE, & nothing to do with Qt.

I'll move this over to the kde-devel list, so they can see your test detail and evidence it's their issue, not Qt.

Thanks!

--------------------

This issue started here

	Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8 at least). Reproducible test case included.
	http://lists.qt-project.org/pipermail/development/2016-April/025592.html

A Qt dev provided the detail that shows that it's a kde/kotkeys problem, not a Qt problem,

	"As you can see, Qt did receive "Shift+3" and "X", but the text lookup returned 
	the result for Ctrl+3 and Ctrl+X.

	As I said, the failure is in khotkeys: it needs to send the events in such a 
	way that the application can't tell the difference. Obviously, Qt 5 did."

Here's the testcase from the OP:

Note that the shortcuts fail only when used in Qt-based applications. They work fine in NON-Qt apps (GTK, JAVE, etc).

In addition to the info in original post, fyi I'm using

	khotkeys5-5.6.2-67.1.x86_64

TESTCASE:
-------------------------------------
on:
	/usr/bin/systemsettings5 -v
		systemsettings 5.6.2

exec:
	/usr/bin/systemsettings5

open:
	Configure Desktop
		Workspace
			Shortcuts
				Custom Shortcuts
					Configure Input Actions settings

in:
	'Name' pane

right-click:
	New
		Global Shortcut
			Send Keyboard Input

rename New action:
	TEST

select:
	TEST

in:
	'Trigger' Pane

click:
	Shortcut "None"

enter:
	Meta-Ctrl-Alt-L

click:
	Apply

in:
	'Action' Pane

enter:
	Shift+3:X

click:
	Apply

(1)
open:
	LibreOffice Writer v5.1.2.2.0 10m0(Build:2) document

press:
	Meta-Ctrl-Alt-L
	OUTPUT: "#X"

(2)
open:
	Eclipse Editor v4.6 (Build:I20160405-0800) document

press:
	Meta-Ctrl-Alt-L
	OUTPUT: "#X"

(3)
open:
	KDE Kate v15.12.3 document

press:
	Meta-Ctrl-Alt-L
	OUTPUT: (none); window flashes

(4)
open:
	QtCreator v3.6.0 (based on Qt 5.6.0) document

press:
	Meta-Ctrl-Alt-L
	OUTPUT: (none); window flashes
-------------------------------------

Jason


From from at alumni.stanford.edu  Sun Apr 10 19:19:09 2016
From: from at alumni.stanford.edu (from at alumni.stanford.edu)
Date: Sun, 10 Apr 2016 10:19:09 -0700
Subject: [Development] Installing Qt5 on RHEL 6
Message-ID: <CANmG5NH0WAA7WGBw1kkg59zByBicp18ttRKXM3Hvk_+xYZ0+WA@mail.gmail.com>

Dear Qt Developers,

We need to install Qt5 on RHEL 6 on a Cray supercomputer. We need it to run
apps on the computer and view results using X11 forwarding.

Our first attempt has not been successful. We we try to copy, we're getting
the error message:

QXcbClipboard::setMimeData: Cannot set X11 selection owner

and the copy doesn’t happen.

When we exit an app using Qt5 we get the additional error message:

QApplication::qAppName: Please instantiate the QApplication object first

Your advice would be much appreciated,

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160410/82c0a082/attachment.html>

From thiago.macieira at intel.com  Mon Apr 11 00:37:53 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sun, 10 Apr 2016 15:37:53 -0700
Subject: [Development] Installing Qt5 on RHEL 6
In-Reply-To: <CANmG5NH0WAA7WGBw1kkg59zByBicp18ttRKXM3Hvk_+xYZ0+WA@mail.gmail.com>
References: <CANmG5NH0WAA7WGBw1kkg59zByBicp18ttRKXM3Hvk_+xYZ0+WA@mail.gmail.com>
Message-ID: <1885780.DWmaqHLM4c@tjmaciei-mobl4>

On domingo, 10 de abril de 2016 10:19:09 PDT from at alumni.stanford.edu wrote:
> Dear Qt Developers,
> 
> We need to install Qt5 on RHEL 6 on a Cray supercomputer. We need it to run
> apps on the computer and view results using X11 forwarding.
> 
> Our first attempt has not been successful. We we try to copy, we're getting
> the error message:
> 
> QXcbClipboard::setMimeData: Cannot set X11 selection owner
> 
> and the copy doesn’t happen.

As I told you in the other email, the bug is in your X server.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From from at alumni.stanford.edu  Mon Apr 11 06:04:09 2016
From: from at alumni.stanford.edu (from at alumni.stanford.edu)
Date: Sun, 10 Apr 2016 21:04:09 -0700
Subject: [Development] Installing Qt5 on RHEL 6
Message-ID: <CANmG5NHx9Mo8J-sbJAmsG2inO__+fdHatobpCMu3F6KnUc7NXg@mail.gmail.com>

Thank you, Thiago

Is anyone on this list knowledgeable enough about X servers to suggest how
we could fix things so that Qt5 and X11 properly work together?

Many thanks,

Bill

On domingo, 10 de abril de 2016 10:19:09 PDT from at alumni.stanford.edu wrote:

Dear Qt Developers,

We need to install Qt5 on RHEL 6 on a Cray supercomputer. We need it to run
apps on the computer and view results using X11 forwarding.

Our first attempt has not been successful. We we try to copy, we're getting
the error message:

QXcbClipboard::setMimeData: Cannot set X11 selection owner

and the copy doesn’t happen.


As I told you in the other email, the bug is in your X server.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
 Software Architect - Intel Open Source Technology Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160410/75c55188/attachment.html>

From thiago.macieira at intel.com  Mon Apr 11 06:19:26 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sun, 10 Apr 2016 21:19:26 -0700
Subject: [Development] Installing Qt5 on RHEL 6
In-Reply-To: <CANmG5NHx9Mo8J-sbJAmsG2inO__+fdHatobpCMu3F6KnUc7NXg@mail.gmail.com>
References: <CANmG5NHx9Mo8J-sbJAmsG2inO__+fdHatobpCMu3F6KnUc7NXg@mail.gmail.com>
Message-ID: <12036866.Ko6EmPROOt@tjmaciei-mobl4>

On domingo, 10 de abril de 2016 21:04:09 PDT from at alumni.stanford.edu wrote:
> Thank you, Thiago
> 
> Is anyone on this list knowledgeable enough about X servers to suggest how
> we could fix things so that Qt5 and X11 properly work together?

Which X server are you running?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Eike.Ziller at theqtcompany.com  Mon Apr 11 09:20:52 2016
From: Eike.Ziller at theqtcompany.com (Ziller Eike)
Date: Mon, 11 Apr 2016 07:20:52 +0000
Subject: [Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8
 at least). Reproducible test case included.
In-Reply-To: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>
References: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>
Message-ID: <4290E127-B00E-4A11-AA55-320E9DE28DC7@theqtcompany.com>


> On Apr 10, 2016, at 7:22 AM, jasonsu at mail-central.com wrote:
> 
> Use of Qt Keyboard shortcuts has been broken in Qt for years.
> 
> There are lots of bugs about it in Qt and KDE projects.
> 
> This one looks close to what I'm seeing,
> 
> 	Can't assign keyboard shortcut with Meta modifiers
> 	https://bugreports.qt.io/browse/QTCREATORBUG-9846

This bug report is more about that you could not assign such a shortcut in Qt Creator to begin with.
That is a different problematic though. To check if Qt (Creator) in principle is able to handle a certain shortcut,
you should open Tools > Options > Environment > Keyboard in Qt Creator and assign a shortcut there
(e.g. by typing the Qt key sequence into the line edit for the shortcut “Ctrl+Meta+Alt+L”).

Br, Eike

> This one got mentioned in a few KDE bugs
> 
> 	Qt LineEdit incorrectly truncates "Password" dialog elements when entered with a KDE Custom Shortcut ...
> 	https://bugreports.qt.io/browse/QTBUG-24304
> 
> There are lots of others.
> 
> Anyway, the point is -- shortcuts don't work.
> 
> I have a reproducible test case. It's 100% reproducible on 4 machines.  Here anyway.
> 
> The Qt shortcuts fail only when used in Qt-based applications.
> They work fine in NON-Qt apps (GTK, JAVE, etc).
> 
> I can't create a Qt account, can't add to any bug (not that I'm clear on which one).  Posting the testcase here.
> 
> I'm cc'ing to a couple of developer's named I saw in those bugs.  Maybe somebody will stick this in the right place.
> 
> -------------------------------------
> on:
> 	/usr/bin/systemsettings5 -v
> 		systemsettings 5.6.2
> 
> exec:
> 	/usr/bin/systemsettings5
> 
> open:
> 	Configure Desktop
> 		Workspace
> 			Shortcuts
> 				Custom Shortcuts
> 					Configure Input Actions settings
> 
> in:
> 	'Name' pane
> 
> right-click:
> 	New
> 		Global Shortcut
> 			Send Keyboard Input
> 
> rename New action:
> 	TEST
> 
> select:
> 	TEST
> 
> in:
> 	'Trigger' Pane
> 
> click:
> 	Shortcut "None"
> 
> enter:
> 	Meta-Ctrl-Alt-L
> 
> click:
> 	Apply
> 
> in:
> 	'Action' Pane
> 
> enter:
> 	Shift+3:X
> 
> click:
> 	Apply
> 
> (1)
> open:
> 	LibreOffice Writer v5.1.2.2.0 10m0(Build:2) document
> 
> press:
> 	Meta-Ctrl-Alt-L
> 	OUTPUT: "#X"
> 
> (2)
> open:
> 	Eclipse Editor v4.6 (Build:I20160405-0800) document
> 
> press:
> 	Meta-Ctrl-Alt-L
> 	OUTPUT: "#X"
> 
> (3)
> open:
> 	KDE Kate v15.12.3 document
> 
> press:
> 	Meta-Ctrl-Alt-L
> 	OUTPUT: (none); window flashes
> 
> (4)
> open:
> 	QtCreator v3.6.0 (based on Qt 5.6.0) document
> 
> press:
> 	Meta-Ctrl-Alt-L
> 	OUTPUT: (none); window flashes
> -------------------------------------
> 
> If someone knows a bug report that this'll get fixed at, pls post it there, and let us know here.
> 
> Jason

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


From tero.kojo at theqtcompany.com  Mon Apr 11 10:13:32 2016
From: tero.kojo at theqtcompany.com (Kojo Tero)
Date: Mon, 11 Apr 2016 08:13:32 +0000
Subject: [Development] Wiki in read only state for acute fixes
Message-ID: <VI1PR0201MB1536142DA71A7293D2308FA58D940@VI1PR0201MB1536.eurprd02.prod.outlook.com>

Hello,

The Qt Wiki is going to read-only state due to a need to move the service immediately from its current server to a more stable set-up.
As you may have noticed, we have had recurring issues with the web services, the past weekend was particularly bad, so these changes are being done immediately.

Estimated time for the read-only state is between one and two hours.

Sorry for the inconvenience.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/d25bddd6/attachment.html>

From tero.kojo at theqtcompany.com  Mon Apr 11 12:02:44 2016
From: tero.kojo at theqtcompany.com (Kojo Tero)
Date: Mon, 11 Apr 2016 10:02:44 +0000
Subject: [Development] Wiki in read only state for acute fixes
In-Reply-To: <VI1PR0201MB1536142DA71A7293D2308FA58D940@VI1PR0201MB1536.eurprd02.prod.outlook.com>
References: <VI1PR0201MB1536142DA71A7293D2308FA58D940@VI1PR0201MB1536.eurprd02.prod.outlook.com>
Message-ID: <VI1PR0201MB15368DD39A91A823378558C38D940@VI1PR0201MB1536.eurprd02.prod.outlook.com>

The wiki is now returning to normal, as soon as the DNS changes propagate everywhere.

Thanks for your patience!

From: Development [mailto:development-bounces+tero.kojo=theqtcompany.com at qt-project.org] On Behalf Of Kojo Tero
Sent: maanantaina 11. huhtikuuta 2016 11.14
To: development at qt-project.org
Subject: [Development] Wiki in read only state for acute fixes

Hello,

The Qt Wiki is going to read-only state due to a need to move the service immediately from its current server to a more stable set-up.
As you may have noticed, we have had recurring issues with the web services, the past weekend was particularly bad, so these changes are being done immediately.

Estimated time for the read-only state is between one and two hours.

Sorry for the inconvenience.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/376f37eb/attachment.html>

From xbenlau at gmail.com  Mon Apr 11 12:38:36 2016
From: xbenlau at gmail.com (Ben Lau)
Date: Mon, 11 Apr 2016 18:38:36 +0800
Subject: [Development] The behaviour of Image / image provider are different
 from 5.5.1 to 5.6 in iOS
Message-ID: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>

Hi,

I am writing an image provider that read all the images to memory at
startup. And I found that the behaviour is different from 5.5.1 to 5.6 in
iOS. Seems that it is undocumented. I wonder is it an expected behaviour or
a bug?

That is the example project:
https://github.com/benlau/quickcross/tree/master/tests/imageprovider

That is the code of my image provider:

QImage QCImageProvider::requestImage(const QString &id, QSize *size,
const QSize &requestedSize)

{

    Q_UNUSED(requestedSize);


    QCImageLoader* loader = QCImageLoader::instance();

    QImage result;


    if (loader->contains(id)) {

        result = loader->image(id);

        *size = result.size();

    }


    return result;

}


Code to display image:


Image {

  id: image

  source: "image://arts/Lenna.png" // An 512x512 image

}


In Qt 5.5.1 with iPhone6, the property of image will be set to:


width: 512

height: 512

sourceSize: Qt.size(512,512)


However, in Qt 5.6 with iPhone6, it becomes:


width: 170.66666

height: 170.66666

sourceSize: Qt.size(512,512)


The display size of image is different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/54a216c9/attachment.html>

From ekke at ekkes-corner.org  Mon Apr 11 13:59:29 2016
From: ekke at ekkes-corner.org (ekke)
Date: Mon, 11 Apr 2016 13:59:29 +0200
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
Message-ID: <570B91A1.5080306@ekkes-corner.org>

Am 11.04.16 um 12:38 schrieb Ben Lau:
> Hi,
>
> I am writing an image provider that read all the images to memory at
> startup. And I found that the behaviour is different from 5.5.1 to 5.6
> in iOS. Seems that it is undocumented. I wonder is it an expected
> behaviour or a bug?
>
> That is the example project:
> https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>
> That is the code of my image provider:
>
> QImageQCImageProvider::requestImage(constQString&id,QSize*size,constQSize&requestedSize)
> {
> Q_UNUSED(requestedSize);
> QCImageLoader*loader=QCImageLoader::instance();
> QImageresult;
> if(loader->contains(id)){
> result=loader->image(id);
> *size=result.size();
> }
> returnresult;
> }
> Code to display image:
> Image {
>   id: image
>   source: "image://arts/Lenna.png" // An 512x512 image
> }
> In Qt 5.5.1 with iPhone6, the property of image will be set to:
> width: 512
> height: 512
> sourceSize: Qt.size(512,512)
> However, in Qt 5.6 with iPhone6, it becomes:
> width: 170.66666
> height: 170.66666
> sourceSize: Qt.size(512,512)
> The display size of image is different.
>
>
now from Qt 5.6 HighDPI is supported for all platforms.
iPhone has scaling factor 3

170.66666 * 3 = 512


ekke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/17cd2cc3/attachment.html>

From xbenlau at gmail.com  Mon Apr 11 14:07:13 2016
From: xbenlau at gmail.com (Ben Lau)
Date: Mon, 11 Apr 2016 20:07:13 +0800
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <570B91A1.5080306@ekkes-corner.org>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
	<570B91A1.5080306@ekkes-corner.org>
Message-ID: <CAAq4oL+_TYhuW=ewcELDuDo1YaaDbETLACwe5EFJ8kJQLGAoOg@mail.gmail.com>

On 11 April 2016 at 19:59, ekke <ekke at ekkes-corner.org> wrote:

> Am 11.04.16 um 12:38 schrieb Ben Lau:
>
> Hi,
>
> I am writing an image provider that read all the images to memory at
> startup. And I found that the behaviour is different from 5.5.1 to 5.6 in
> iOS. Seems that it is undocumented. I wonder is it an expected behaviour or
> a bug?
>
> That is the example project:
> https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>
> That is the code of my image provider:
>
> QImage QCImageProvider::requestImage(const QString &id, QSize *size, c
> onst QSize &requestedSize)
>
> {
>
>     Q_UNUSED(requestedSize);
>
>     QCImageLoader* loader = QCImageLoader::instance();
>
>     QImage result;
>
>     if (loader->contains(id)) {
>
>         result = loader->image(id);
>
>         *size = result.size();
>
>     }
>
>     return result;
>
> }
>
> Code to display image:
>
> Image {
>
>   id: image
>
>   source: "image://arts/Lenna.png" // An 512x512 image
>
> }
>
> In Qt 5.5.1 with iPhone6, the property of image will be set to:
>
> width: 512
>
> height: 512
>
> sourceSize: Qt.size(512,512)
>
> However, in Qt 5.6 with iPhone6, it becomes:
>
> width: 170.66666
>
> height: 170.66666
>
> sourceSize: Qt.size(512,512)
>
> The display size of image is different.
>
>
> now from Qt 5.6 HighDPI is supported for all platforms.
> iPhone has scaling factor 3
>
> 170.66666 * 3 = 512
>
>
> ekke
>
>
But Qt 5.5 on iOS also support HighDPI. Their result are different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/e50342c1/attachment.html>

From ekke at ekkes-corner.org  Mon Apr 11 14:19:32 2016
From: ekke at ekkes-corner.org (ekke)
Date: Mon, 11 Apr 2016 14:19:32 +0200
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <CAAq4oL+_TYhuW=ewcELDuDo1YaaDbETLACwe5EFJ8kJQLGAoOg@mail.gmail.com>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
	<570B91A1.5080306@ekkes-corner.org>
	<CAAq4oL+_TYhuW=ewcELDuDo1YaaDbETLACwe5EFJ8kJQLGAoOg@mail.gmail.com>
Message-ID: <570B9654.1030307@ekkes-corner.org>

Am 11.04.16 um 14:07 schrieb Ben Lau:
>
> On 11 April 2016 at 19:59, ekke <ekke at ekkes-corner.org
> <mailto:ekke at ekkes-corner.org>> wrote:
>
>     Am 11.04.16 um 12:38 schrieb Ben Lau:
>>     Hi,
>>
>>     I am writing an image provider that read all the images to memory
>>     at startup. And I found that the behaviour is different from
>>     5.5.1 to 5.6 in iOS. Seems that it is undocumented. I wonder is
>>     it an expected behaviour or a bug?
>>
>>     That is the example project:
>>     https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>>
>>     That is the code of my image provider:
>>
>>     QImageQCImageProvider::requestImage(constQString&id,QSize*size,c
>>     onstQSize&requestedSize)
>>     {
>>     Q_UNUSED(requestedSize);
>>     QCImageLoader*loader=QCImageLoader::instance();
>>     QImageresult;
>>     if(loader->contains(id)){
>>     result=loader->image(id);
>>     *size=result.size();
>>     }
>>     returnresult;
>>     }
>>     Code to display image:
>>     Image {
>>       id: image
>>       source: "image://arts/Lenna.png" // An 512x512 image
>>     }
>>     In Qt 5.5.1 with iPhone6, the property of image will be set to:
>>     width: 512
>>     height: 512
>>     sourceSize: Qt.size(512,512)
>>     However, in Qt 5.6 with iPhone6, it becomes:
>>     width: 170.66666
>>     height: 170.66666
>>     sourceSize: Qt.size(512,512)
>>     The display size of image is different.
>>
>>
>     now from Qt 5.6 HighDPI is supported for all platforms.
>     iPhone has scaling factor 3
>
>     170.66666 * 3 = 512
>
>
>     ekke
>
>
> But Qt 5.5 on iOS also support HighDPI. Their result are different.
>
>
have you tried to explicitely set

QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);


ekke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/e28ed73f/attachment.html>

From xbenlau at gmail.com  Mon Apr 11 14:28:06 2016
From: xbenlau at gmail.com (Ben Lau)
Date: Mon, 11 Apr 2016 20:28:06 +0800
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <570B9654.1030307@ekkes-corner.org>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
	<570B91A1.5080306@ekkes-corner.org>
	<CAAq4oL+_TYhuW=ewcELDuDo1YaaDbETLACwe5EFJ8kJQLGAoOg@mail.gmail.com>
	<570B9654.1030307@ekkes-corner.org>
Message-ID: <CAAq4oLLmkP8RU-QJt+H1GbbN0UYf8Xva5qDBgjHYQw=k0cjNkw@mail.gmail.com>

On 11 April 2016 at 20:19, ekke <ekke at ekkes-corner.org> wrote:

> Am 11.04.16 um 14:07 schrieb Ben Lau:
>
>
> On 11 April 2016 at 19:59, ekke <ekke at ekkes-corner.org> wrote:
>
>> Am 11.04.16 um 12:38 schrieb Ben Lau:
>>
>> Hi,
>>
>> I am writing an image provider that read all the images to memory at
>> startup. And I found that the behaviour is different from 5.5.1 to 5.6 in
>> iOS. Seems that it is undocumented. I wonder is it an expected behaviour or
>> a bug?
>>
>> That is the example project:
>> https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>>
>> That is the code of my image provider:
>>
>> QImage QCImageProvider::requestImage(const QString &id, QSize *size, c
>> onst QSize &requestedSize)
>>
>> {
>>
>>     Q_UNUSED(requestedSize);
>>
>>     QCImageLoader* loader = QCImageLoader::instance();
>>
>>     QImage result;
>>
>>     if (loader->contains(id)) {
>>
>>         result = loader->image(id);
>>
>>         *size = result.size();
>>
>>     }
>>
>>     return result;
>>
>> }
>>
>> Code to display image:
>>
>> Image {
>>
>>   id: image
>>
>>   source: "image://arts/Lenna.png" // An 512x512 image
>>
>> }
>>
>> In Qt 5.5.1 with iPhone6, the property of image will be set to:
>>
>> width: 512
>>
>> height: 512
>>
>> sourceSize: Qt.size(512,512)
>>
>> However, in Qt 5.6 with iPhone6, it becomes:
>>
>> width: 170.66666
>>
>> height: 170.66666
>>
>> sourceSize: Qt.size(512,512)
>>
>> The display size of image is different.
>>
>>
>> now from Qt 5.6 HighDPI is supported for all platforms.
>> iPhone has scaling factor 3
>>
>> 170.66666 * 3 = 512
>>
>>
>> ekke
>>
>>
> But Qt 5.5 on iOS also support HighDPI. Their result are different.
>
>
> have you tried to explicitely set
>
> QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
>
>
> ekke
>

I have tried to set / not-set this line. It don't make any different.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/d001ed46/attachment.html>

From fed.buti at gmail.com  Mon Apr 11 14:36:34 2016
From: fed.buti at gmail.com (Federico Buti)
Date: Mon, 11 Apr 2016 14:36:34 +0200
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <CAAq4oLLmkP8RU-QJt+H1GbbN0UYf8Xva5qDBgjHYQw=k0cjNkw@mail.gmail.com>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
	<570B91A1.5080306@ekkes-corner.org>
	<CAAq4oL+_TYhuW=ewcELDuDo1YaaDbETLACwe5EFJ8kJQLGAoOg@mail.gmail.com>
	<570B9654.1030307@ekkes-corner.org>
	<CAAq4oLLmkP8RU-QJt+H1GbbN0UYf8Xva5qDBgjHYQw=k0cjNkw@mail.gmail.com>
Message-ID: <CA++t_8M-MDN4d1pStpSfJjVkYJOwARuopH=nPUD0bHJ8zFvffA@mail.gmail.com>

Hi Ben,

I've solved the issue by multiplying width/height to
qApp->devicePixelRatio(). That should be 3 on iPhone 6 and should provide
the correct result.
I'm not sure if that's a bug or it is intended behaviour and I actually
didn't investigate the issue a lot since I was just testing stuff.

Hope someone else can confirm it's a bug or expected.

Cheers,
F.

On 11 April 2016 at 14:28, Ben Lau <xbenlau at gmail.com> wrote:

>
>
> On 11 April 2016 at 20:19, ekke <ekke at ekkes-corner.org> wrote:
>
>> Am 11.04.16 um 14:07 schrieb Ben Lau:
>>
>>
>> On 11 April 2016 at 19:59, ekke <ekke at ekkes-corner.org> wrote:
>>
>>> Am 11.04.16 um 12:38 schrieb Ben Lau:
>>>
>>> Hi,
>>>
>>> I am writing an image provider that read all the images to memory at
>>> startup. And I found that the behaviour is different from 5.5.1 to 5.6 in
>>> iOS. Seems that it is undocumented. I wonder is it an expected behaviour or
>>> a bug?
>>>
>>> That is the example project:
>>> https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>>>
>>> That is the code of my image provider:
>>>
>>> QImage QCImageProvider::requestImage(const QString &id, QSize *size, c
>>> onst QSize &requestedSize)
>>>
>>> {
>>>
>>>     Q_UNUSED(requestedSize);
>>>
>>>     QCImageLoader* loader = QCImageLoader::instance();
>>>
>>>     QImage result;
>>>
>>>     if (loader->contains(id)) {
>>>
>>>         result = loader->image(id);
>>>
>>>         *size = result.size();
>>>
>>>     }
>>>
>>>     return result;
>>>
>>> }
>>>
>>> Code to display image:
>>>
>>> Image {
>>>
>>>   id: image
>>>
>>>   source: "image://arts/Lenna.png" // An 512x512 image
>>>
>>> }
>>>
>>> In Qt 5.5.1 with iPhone6, the property of image will be set to:
>>>
>>> width: 512
>>>
>>> height: 512
>>>
>>> sourceSize: Qt.size(512,512)
>>>
>>> However, in Qt 5.6 with iPhone6, it becomes:
>>>
>>> width: 170.66666
>>>
>>> height: 170.66666
>>>
>>> sourceSize: Qt.size(512,512)
>>>
>>> The display size of image is different.
>>>
>>>
>>> now from Qt 5.6 HighDPI is supported for all platforms.
>>> iPhone has scaling factor 3
>>>
>>> 170.66666 * 3 = 512
>>>
>>>
>>> ekke
>>>
>>>
>> But Qt 5.5 on iOS also support HighDPI. Their result are different.
>>
>>
>> have you tried to explicitely set
>>
>> QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
>>
>>
>> ekke
>>
>
> I have tried to set / not-set this line. It don't make any different.
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/2fbd0d9d/attachment.html>

From jani.heikkinen at theqtcompany.com  Mon Apr 11 14:47:03 2016
From: jani.heikkinen at theqtcompany.com (Heikkinen Jani)
Date: Mon, 11 Apr 2016 12:47:03 +0000
Subject: [Development] Qt 5.7.0 beta snapshot available
Message-ID: <AM4PR02MB1410B58F3591DA30CCD62E89E4940@AM4PR02MB1410.eurprd02.prod.outlook.com>

Hi all,


We have new Qt 5.7.0 beta snapshot available


Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/407/

Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/389/

Src:http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/latest_src/ (Under mirroring)


Mac packages are still missing, retry is ongoing. Please test the packages & report your findings in Jira. We need good testing coverage now to see how close the beta we are. We are trying to get beta out as soon as possible and so on we need to know all beta blockers at the moment. So please make sure all beta beta blockers have '5.7.0 beta' in Fix Version(s) -field & so on visible in beta blocker list (https://bugreports.qt.io/issues/?filter=17576)


Windows and Linux packages are RTA smoke tested & seems to be pretty much OK.


Known issues from the packages:https://bugreports.qt.io/issues/?filter=17601


br,

Jani

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/036d4e90/attachment.html>

From ekke at ekkes-corner.org  Mon Apr 11 14:47:09 2016
From: ekke at ekkes-corner.org (ekke)
Date: Mon, 11 Apr 2016 14:47:09 +0200
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <CA++t_8M-MDN4d1pStpSfJjVkYJOwARuopH=nPUD0bHJ8zFvffA@mail.gmail.com>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
	<570B91A1.5080306@ekkes-corner.org>
	<CAAq4oL+_TYhuW=ewcELDuDo1YaaDbETLACwe5EFJ8kJQLGAoOg@mail.gmail.com>
	<570B9654.1030307@ekkes-corner.org>
	<CAAq4oLLmkP8RU-QJt+H1GbbN0UYf8Xva5qDBgjHYQw=k0cjNkw@mail.gmail.com>
	<CA++t_8M-MDN4d1pStpSfJjVkYJOwARuopH=nPUD0bHJ8zFvffA@mail.gmail.com>
Message-ID: <570B9CCD.1030704@ekkes-corner.org>

perhaps devicePixelRatio is 3.0 - this would have the effect to get 170.666
http://doc.qt.io/qt-5/qimage.html#setDevicePixelRatio

ekke
Am 11.04.16 um 14:36 schrieb Federico Buti:
> Hi Ben,
>
> I've solved the issue by multiplying width/height to
> qApp->devicePixelRatio(). That should be 3 on iPhone 6 and should
> provide the correct result.
> I'm not sure if that's a bug or it is intended behaviour and I
> actually didn't investigate the issue a lot since I was just testing
> stuff. 
>
> Hope someone else can confirm it's a bug or expected.
>
> Cheers,
> F.
>
> On 11 April 2016 at 14:28, Ben Lau <xbenlau at gmail.com
> <mailto:xbenlau at gmail.com>> wrote:
>
>
>
>     On 11 April 2016 at 20:19, ekke <ekke at ekkes-corner.org
>     <mailto:ekke at ekkes-corner.org>> wrote:
>
>         Am 11.04.16 um 14:07 schrieb Ben Lau:
>>
>>         On 11 April 2016 at 19:59, ekke <ekke at ekkes-corner.org
>>         <mailto:ekke at ekkes-corner.org>> wrote:
>>
>>             Am 11.04.16 um 12:38 schrieb Ben Lau:
>>>             Hi,
>>>
>>>             I am writing an image provider that read all the images
>>>             to memory at startup. And I found that the behaviour is
>>>             different from 5.5.1 to 5.6 in iOS. Seems that it is
>>>             undocumented. I wonder is it an expected behaviour or a bug?
>>>
>>>             That is the example project:
>>>             https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>>>
>>>             That is the code of my image provider:
>>>
>>>             QImageQCImageProvider::requestImage(constQString&id,QSize*size,c
>>>             onstQSize&requestedSize)
>>>             {
>>>             Q_UNUSED(requestedSize);
>>>             QCImageLoader*loader=QCImageLoader::instance();
>>>             QImageresult;
>>>             if(loader->contains(id)){
>>>             result=loader->image(id);
>>>             *size=result.size();
>>>             }
>>>             returnresult;
>>>             }
>>>             Code to display image:
>>>             Image {
>>>               id: image
>>>               source: "image://arts/Lenna.png" // An 512x512 image
>>>             }
>>>             In Qt 5.5.1 with iPhone6, the property of image will be set to:
>>>             width: 512
>>>             height: 512
>>>             sourceSize: Qt.size(512,512)
>>>             However, in Qt 5.6 with iPhone6, it becomes:
>>>             width: 170.66666
>>>             height: 170.66666
>>>             sourceSize: Qt.size(512,512)
>>>             The display size of image is different.
>>>
>>>
>>             now from Qt 5.6 HighDPI is supported for all platforms.
>>             iPhone has scaling factor 3
>>
>>             170.66666 * 3 = 512
>>
>>
>>             ekke
>>
>>
>>         But Qt 5.5 on iOS also support HighDPI. Their result are
>>         different.
>>
>>
>         have you tried to explicitely set
>
>         QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
>
>
>         ekke
>
>
>     I have tried to set / not-set this line. It don't make any different.
>
>
>     _______________________________________________
>     Development mailing list
>     Development at qt-project.org <mailto:Development at qt-project.org>
>     http://lists.qt-project.org/mailman/listinfo/development
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/34e09fd7/attachment.html>

From xbenlau at gmail.com  Mon Apr 11 14:51:46 2016
From: xbenlau at gmail.com (Ben Lau)
Date: Mon, 11 Apr 2016 20:51:46 +0800
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <570B9CCD.1030704@ekkes-corner.org>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
	<570B91A1.5080306@ekkes-corner.org>
	<CAAq4oL+_TYhuW=ewcELDuDo1YaaDbETLACwe5EFJ8kJQLGAoOg@mail.gmail.com>
	<570B9654.1030307@ekkes-corner.org>
	<CAAq4oLLmkP8RU-QJt+H1GbbN0UYf8Xva5qDBgjHYQw=k0cjNkw@mail.gmail.com>
	<CA++t_8M-MDN4d1pStpSfJjVkYJOwARuopH=nPUD0bHJ8zFvffA@mail.gmail.com>
	<570B9CCD.1030704@ekkes-corner.org>
Message-ID: <CAAq4oLJeq0Vn8Qsw3=LMxemd_b4n_BJS=fhwKs3yRXfZw3kEHw@mail.gmail.com>

Hi ekke,

I have tried. Image item will just ignore the devicePixelRatio set in
QImage.

Similar report: [QTBUG-38127] devicePixelRatio not supported by
QQmlImageProvider - Qt Bug Tracker
<https://bugreports.qt.io/browse/QTBUG-38127>


On 11 April 2016 at 20:47, ekke <ekke at ekkes-corner.org> wrote:

> perhaps devicePixelRatio is 3.0 - this would have the effect to get 170.666
> http://doc.qt.io/qt-5/qimage.html#setDevicePixelRatio
>
> ekke
> Am 11.04.16 um 14:36 schrieb Federico Buti:
>
> Hi Ben,
>
> I've solved the issue by multiplying width/height to
> qApp->devicePixelRatio(). That should be 3 on iPhone 6 and should provide
> the correct result.
> I'm not sure if that's a bug or it is intended behaviour and I actually
> didn't investigate the issue a lot since I was just testing stuff.
>
> Hope someone else can confirm it's a bug or expected.
>
> Cheers,
> F.
>
> On 11 April 2016 at 14:28, Ben Lau <xbenlau at gmail.com> wrote:
>
>>
>>
>> On 11 April 2016 at 20:19, ekke < <ekke at ekkes-corner.org>
>> ekke at ekkes-corner.org> wrote:
>>
>>> Am 11.04.16 um 14:07 schrieb Ben Lau:
>>>
>>>
>>> On 11 April 2016 at 19:59, ekke < <ekke at ekkes-corner.org>
>>> ekke at ekkes-corner.org> wrote:
>>>
>>>> Am 11.04.16 um 12:38 schrieb Ben Lau:
>>>>
>>>> Hi,
>>>>
>>>> I am writing an image provider that read all the images to memory at
>>>> startup. And I found that the behaviour is different from 5.5.1 to 5.6 in
>>>> iOS. Seems that it is undocumented. I wonder is it an expected behaviour or
>>>> a bug?
>>>>
>>>> That is the example project:
>>>> <https://github.com/benlau/quickcross/tree/master/tests/imageprovider>
>>>> https://github.com/benlau/quickcross/tree/master/tests/imageprovider
>>>>
>>>> That is the code of my image provider:
>>>>
>>>> QImage QCImageProvider::requestImage(const QString &id, QSize *size, <
>>>> /span>c
>>>> onst QSize &requestedSize)
>>>>
>>>> {
>>>>
>>>>     Q_UNUSED(requestedSize);
>>>>
>>>>     QCImageLoader* loader = QCImageLoader::instance();
>>>>
>>>>     QImage result;
>>>>
>>>>     if (loader->contains(id)) {
>>>>
>>>>         result = loader->image(id);
>>>>
>>>>         *size = result.size();
>>>>
>>>>     }
>>>>
>>>>     return result;
>>>>
>>>> }
>>>>
>>>> Code to display image:
>>>>
>>>> Image {
>>>>
>>>>   id: image
>>>>
>>>>   source: "image://arts/Lenna.png" // An 512x512 image
>>>>
>>>> }
>>>>
>>>> In Qt 5.5.1 with iPhone6, the property of image will be set to:
>>>>
>>>> width: 512
>>>>
>>>> height: 512
>>>>
>>>> sourceSize: Qt.size(512,512)
>>>>
>>>> However, in Qt 5.6 with iPhone6, it becomes:
>>>>
>>>> width: 170.66666
>>>>
>>>> height: 170.66666
>>>>
>>>> sourceSize: Qt.size(512,512)
>>>>
>>>> The display size of image is different.
>>>>
>>>>
>>>> now from Qt 5.6 HighDPI is supported for all platforms.
>>>> iPhone has scaling factor 3
>>>>
>>>> 170.66666 * 3 = 512
>>>>
>>>>
>>>> ekke
>>>>
>>>>
>>> But Qt 5.5 on iOS also support HighDPI. Their result are different.
>>>
>>>
>>> have you tried to explicitely set
>>>
>>> QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
>>>
>>>
>>> ekke
>>>
>>
>> I have tried to set / not-set this line. It don't make any different.
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/442b1b6c/attachment.html>

From frederik.gladhorn at theqtcompany.com  Mon Apr 11 16:50:18 2016
From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn)
Date: Mon, 11 Apr 2016 16:50:18 +0200
Subject: [Development] Qt 5.7.0 beta snapshot available - gtk 3 and
	packaging on RHEL 6
In-Reply-To: <AM4PR02MB1410B58F3591DA30CCD62E89E4940@AM4PR02MB1410.eurprd02.prod.outlook.com>
References: <AM4PR02MB1410B58F3591DA30CCD62E89E4940@AM4PR02MB1410.eurprd02.prod.outlook.com>
Message-ID: <2184572.tYyMDLlE42@frederik-thinkcentre-m93p>

Hello all,

for Linux packaging we currently use a Red Hat 6 which seemed like a good 
compromise at the time.

I have been pondering https://bugreports.qt.io/browse/QTBUG-52259 for a while 
and don't seem to reach a conclusion.
We had a contribution porting our gtk 2 theme to gtk 3 (thanks Dmitry!).
The question is how to proceed, from what I can tell, it's not trivial to get 
gtk3 built on rhel6.
For Linux distributions this is of course not a problem, but the Qt installer 
is currently built without any gtk plugin compiled.
In the future (Qt 5.8), I'd like to switch to rhel 7 as packaging platform, so 
this problem should go away.

For Qt 5.7, the options seem to be:
1.) ignore the problem and ship Qt packages in the installer without gtk theme
2.) revert the patch to have the gtk2 theme for one release longer and only 
have gtk3 with Qt 5.8
3.) package on rhel 7, but I'm told, we're already too late in the cycle

Any ideas appreciated. In general I have a hard time seeing how to cleanly 
create packages on Linux, unless we basically ship an entire distro (similar 
to Chrome and others)... I'd love to learn about good approaches, since 
packaging on something "old enough to run everywhere" and "new enough to allow 
all dependencies to be built" seems hard to achieve.

Sadly we don't have the resources to create native packages for each and every 
distro (we want to allow our users to use Qt on older releases of their 
favorite distro) and I'm not sure if packagers would be willing to help us get 
into a situation where it's easy to create packages for all relevant 
distributions, installing into custom prefixes and having a mix of versions.

So for the time being I have been convinced that creating the installers is 
valuable for many people on Linux, but I wonder if there's a way we can do 
better.

Cheers,
Frederik

PS: there are some more issues with old distros and packaging... gstreamer 
0.10 comes to mind, next to bluez dependencies.


On Monday, April 11, 2016 12:47:03 PM Heikkinen Jani wrote:
> Hi all,
> 
> 
> We have new Qt 5.7.0 beta snapshot available
> 
> 
> Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/407/
> 
> Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/389/
> 
> Src:http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/latest_src/ (Under
> mirroring)
> 
> 
> Mac packages are still missing, retry is ongoing. Please test the packages &
> report your findings in Jira. We need good testing coverage now to see how
> close the beta we are. We are trying to get beta out as soon as possible
> and so on we need to know all beta blockers at the moment. So please make
> sure all beta beta blockers have '5.7.0 beta' in Fix Version(s) -field & so
> on visible in beta blocker list
> (https://bugreports.qt.io/issues/?filter=17576)
> 
> 
> Windows and Linux packages are RTA smoke tested & seems to be pretty much
> OK.
> 
> 
> Known issues from the packages:https://bugreports.qt.io/issues/?filter=17601
> 
> 
> br,
> 
> Jani



From frederik.gladhorn at theqtcompany.com  Mon Apr 11 18:03:18 2016
From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn)
Date: Mon, 11 Apr 2016 18:03:18 +0200
Subject: [Development] MSVC2012 in CI
In-Reply-To: <5706555F.7040303@theqtcompany.com>
References: <F9400714-92BD-4E01-8641-D32789F50F32@kdab.com>
	<3108994.WkAvvHyZVt@frederik-thinkcentre-m93p>
	<5706555F.7040303@theqtcompany.com>
Message-ID: <2832260.3hdjy0CMN7@frederik-thinkcentre-m93p>

On Thursday, April 07, 2016 02:41:03 PM Friedemann Kleint wrote:
> Hi,
> 
>  >I'd love to remove it, but it's blocked by
> 
> https://bugreports.qt.io/browse/QTBUG-51934
> 
>  >We cannot just remove test coverage without testing some of the
> 
> features on more modern platforms.
> 
> We blacklisted the test for the moment, so, we could switch to MSVC2015 now.

I just tried, for me the blacklisting didn't do anything, even though I didn't 
see a typo, I get the same failure still.

I'll have a look on a machine where this is failing now.

Cheers,
Frederik

> 
> Regards,
> Friedemann



From frederik.gladhorn at theqtcompany.com  Mon Apr 11 18:15:25 2016
From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn)
Date: Mon, 11 Apr 2016 18:15:25 +0200
Subject: [Development] MSVC2012 in CI
In-Reply-To: <2832260.3hdjy0CMN7@frederik-thinkcentre-m93p>
References: <F9400714-92BD-4E01-8641-D32789F50F32@kdab.com>
	<5706555F.7040303@theqtcompany.com>
	<2832260.3hdjy0CMN7@frederik-thinkcentre-m93p>
Message-ID: <12817970.geEgRq4YEU@frederik-thinkcentre-m93p>

On Monday, April 11, 2016 06:03:18 PM Frederik Gladhorn wrote:
> On Thursday, April 07, 2016 02:41:03 PM Friedemann Kleint wrote:
> > Hi,
> > 
> >  >I'd love to remove it, but it's blocked by
> > 
> > https://bugreports.qt.io/browse/QTBUG-51934
> > 
> >  >We cannot just remove test coverage without testing some of the
> > 
> > features on more modern platforms.
> > 
> > We blacklisted the test for the moment, so, we could switch to MSVC2015
> > now.
> I just tried, for me the blacklisting didn't do anything, even though I
> didn't see a typo, I get the same failure still.
> 
> I'll have a look on a machine where this is failing now.

Silly me, the patch is in, but not integrated in qt5.git. So all looks good, 
but we'll have to get a qt5.git integration though to create future packages.

I see one more issue with the virtual keyboard, but I think we'll just switch 
over and fix this at the same time. It's one test failing at the moment.

Eventually all of these changes to virtual machines and how we build and test 
Qt and the configurations it's tested on should really end up in the "product" 
repository that is in qt5.git.

Cheers,
Frederik

> 
> Cheers,
> Frederik
> 
> > Regards,
> > Friedemann
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



From perezmeyer at gmail.com  Mon Apr 11 18:37:03 2016
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Mon, 11 Apr 2016 13:37:03 -0300
Subject: [Development] Qt 5.7.0 beta snapshot available - gtk 3 and
	packaging on RHEL 6
In-Reply-To: <2184572.tYyMDLlE42@frederik-thinkcentre-m93p>
References: <AM4PR02MB1410B58F3591DA30CCD62E89E4940@AM4PR02MB1410.eurprd02.prod.outlook.com>
	<2184572.tYyMDLlE42@frederik-thinkcentre-m93p>
Message-ID: <4210863.E4Rg9Zd13E@luna>

On Monday 11 April 2016 16:50:18 Frederik Gladhorn wrote:
> Hello all,
[snip] 
> For Qt 5.7, the options seem to be:
> 1.) ignore the problem and ship Qt packages in the installer without gtk
> theme 2.) revert the patch to have the gtk2 theme for one release longer
> and only have gtk3 with Qt 5.8
> 3.) package on rhel 7, but I'm told, we're already too late in the cycle
> 
> Any ideas appreciated. 

I'll leave the above unanswered because I think I'm not the right one for that 
question.

> In general I have a hard time seeing how to cleanly
> create packages on Linux, unless we basically ship an entire distro (similar
> to Chrome and others)... I'd love to learn about good approaches, since
> packaging on something "old enough to run everywhere" and "new enough to
> allow all dependencies to be built" seems hard to achieve.

I guess here that you are talking about "cleanness" with respect to 
dependencies. We distro maintainers normally know that this is not easily 
solvable except bundling half of them, which is in turn ugly.

It basically boils down to "one size does not fits all".

> Sadly we don't have the resources to create native packages for each and
> every distro (we want to allow our users to use Qt on older releases of
> their favorite distro) and I'm not sure if packagers would be willing to
> help us get into a situation where it's easy to create packages for all
> relevant distributions, installing into custom prefixes and having a mix of
> versions.

With my Debian maintainer hat on the most complicated thing would be to avoid 
conflicting with existing distro installations. qtchooser can help here tough.

One thing to have in mind: if a user gets qt by using the online 
installer/whatever method coming from you directly and sets it as default Qt 
installation it will have problems with distro apps that uses Qt's private 
headers.

> So for the time being I have been convinced that creating the installers is
> valuable for many people on Linux, but I wonder if there's a way we can do
> better.

I would really be interested here to have actual numbers. We in Debian can 
provide backports if the situation merits it. So far I only see one or two 
people asking us for Qt backports in a year. But maybe that doesn't reflects 
the real necessity for it.

Yes, I understand that here I'm proposing having distro-provided packages 
instead of getting the installations from you directly, but I think that's our 
job if there is really people interested in them out there.

It might be interesting to say that most of the request of having up-to-date 
Qt in stable (or old stable) Debian releases comes from people working at/for 
companies and not from other developers.

I'm of course possibly biased in my answers so *please* do not hesitate in 
asking/proposing other things, I might be missing the elephant in the room. If 
there is anything we can do to improve the situation for our users in a
win-win way then we need to consider it.

-- 
"So long, and thanks for all the fish!"
  The Hitchhickers guide to the Galaxy

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160411/79d5f8bf/attachment.sig>

From jasonsu at mail-central.com  Mon Apr 11 18:48:52 2016
From: jasonsu at mail-central.com (jasonsu at mail-central.com)
Date: Mon, 11 Apr 2016 09:48:52 -0700
Subject: [Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8
 at least). Reproducible test case included.
In-Reply-To: <4290E127-B00E-4A11-AA55-320E9DE28DC7@theqtcompany.com>
References: <1460265747.2915896.574093225.42A6D709@webmail.messagingengine.com>
	<4290E127-B00E-4A11-AA55-320E9DE28DC7@theqtcompany.com>
Message-ID: <1460393332.1541446.575417905.00395E2C@webmail.messagingengine.com>

On Mon, Apr 11, 2016, at 12:20 AM, Ziller Eike wrote:
> This bug report is more about that you could not assign such a shortcut in Qt Creator to begin with.
> That is a different problematic though. To check if Qt (Creator) in principle is able to handle a certain shortcut,
> you should open Tools > Options > Environment > Keyboard in Qt Creator and assign a shortcut there
> (e.g. by typing the Qt key sequence into the line edit for the shortcut “Ctrl+Meta+Alt+L”).

Thanks for pointing that out.

It seems 'my' report isn't going to get dealt with.  There's more interest in blaming somebody else, and discussing what isn't causing the problem, than acknowledging the reproducible problem, and deciding to fix it -- no matter where it originates.

TA

Jason


From mwoehlke.floss at gmail.com  Mon Apr 11 20:54:02 2016
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Mon, 11 Apr 2016 14:54:02 -0400
Subject: [Development] QColor and HSL's hue
In-Reply-To: <VI1PR0201MB1469A4F00753F682591AE76EF1920@VI1PR0201MB1469.eurprd02.prod.outlook.com>
References: <VI1PR0201MB1469A4F00753F682591AE76EF1920@VI1PR0201MB1469.eurprd02.prod.outlook.com>
Message-ID: <negrsa$kvj$1@ger.gmane.org>

On 2016-04-09 09:02, Curtis Mitch wrote:
> Is there any technical reason (besides compatibility) why QColor::hslHueF() can't return a value between 0 and 1?
> 
> If the colour being represented by QColour is black, QColor::hslHueF() will return -1:

I think there is a misunderstanding here... a negative value is an
"error". Specifically, you get a negative value for hue when the value
cannot be meaningful, because the color is fully desaturated (i.e. a
"perfect" shade of gray). Any value for hue for such colors is
necessarily going to be arbitrary. Qt happens to have made the choice
(which I think is a good one) to return a value that indicates this
clearly, rather than returning an arbitrary value from the normal range,
which might incorrectly imply that the value is meaningful.

> how would I work around the case of a negative hue?

Ideally, you should teach your application how to understand when the
hue is not meaningful and to behave in such cases in a reasonable
manner. Failing that, you could just map a negative value to an
arbitrary value in the normal range. (For example, you could always map
hue like `qMax(0, h)`.)

-- 
Matthew



From Lars.Knoll at theqtcompany.com  Mon Apr 11 22:34:44 2016
From: Lars.Knoll at theqtcompany.com (Knoll Lars)
Date: Mon, 11 Apr 2016 20:34:44 +0000
Subject: [Development] CI for Qt WebKit
In-Reply-To: <CA19DBF3-404D-4109-8387-CB77118D502C@theqtcompany.com>
References: <CA19DBF3-404D-4109-8387-CB77118D502C@theqtcompany.com>
Message-ID: <44C39B54-4633-48BE-BE16-7A78F434788E@theqtcompany.com>

Hi,



we’re planning on doing a slight adjustments to how Qt WebKit and other unsupported modules are CI tested for 5.7 and onwards. Basically, they will not be tested as part of qt5.git integrations anymore and thus won’t block releases. But they will stay CI controlled and will be compile tested on a regular basis so that we will get notified if something breaks. 

The reason is that they should not be in the way to getting our releases out. At the same time, having them tested in regular intervals will notify us when something breaks, and we can then work on fixing this without causing problems for our main releases.

Cheers,
Lars


From thiago.macieira at intel.com  Tue Apr 12 00:20:11 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Mon, 11 Apr 2016 15:20:11 -0700
Subject: [Development] CI for Qt WebKit
In-Reply-To: <44C39B54-4633-48BE-BE16-7A78F434788E@theqtcompany.com>
References: <CA19DBF3-404D-4109-8387-CB77118D502C@theqtcompany.com>
	<44C39B54-4633-48BE-BE16-7A78F434788E@theqtcompany.com>
Message-ID: <2633429.1024hN7qlE@tjmaciei-mobl4>

On segunda-feira, 11 de abril de 2016 20:34:44 PDT Knoll Lars wrote:
> The reason is that they should not be in the way to getting our releases
> out.

That's exactly the time that they should be in the way... We may break those 
modules temporarily, but not leave them broken at the time of the release.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From jani.heikkinen at theqtcompany.com  Tue Apr 12 08:46:18 2016
From: jani.heikkinen at theqtcompany.com (Heikkinen Jani)
Date: Tue, 12 Apr 2016 06:46:18 +0000
Subject: [Development] CI for Qt WebKit
In-Reply-To: <2633429.1024hN7qlE@tjmaciei-mobl4>
References: <CA19DBF3-404D-4109-8387-CB77118D502C@theqtcompany.com>
	<44C39B54-4633-48BE-BE16-7A78F434788E@theqtcompany.com>,
	<2633429.1024hN7qlE@tjmaciei-mobl4>
Message-ID: <AM4PR02MB1410BC306E3420448976E7E0E4950@AM4PR02MB1410.eurprd02.prod.outlook.com>

>>That's exactly the time that they should be in the way... We may break those
>>modules temporarily, but not leave them broken at the time of the release.

I disagree. If module is removed (obsolete in .gitmodules) that cannot delay the release: It is just insane. if there is some reason(s) for that then I think we shouldn't even remove the module at all. That kind of semi-removal is the worst case: We are playing it is removed but actually working like it is officially as a part of release/packages. It is confusing for us all and causes just this kind of unnecessary hassle :(

br,
jani

________________________________________
Lähettäjä: Development <development-bounces+jani.heikkinen=theqtcompany.com at qt-project.org> käyttäjän  puolestaThiago Macieira <thiago.macieira at intel.com>
Lähetetty: 12. huhtikuuta 2016 1:20
Vastaanottaja: development at qt-project.org
Aihe: Re: [Development] CI for Qt WebKit

On segunda-feira, 11 de abril de 2016 20:34:44 PDT Knoll Lars wrote:
> The reason is that they should not be in the way to getting our releases
> out.

That's exactly the time that they should be in the way... We may break those
modules temporarily, but not leave them broken at the time of the release.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From tuukka.turunen at theqtcompany.com  Tue Apr 12 08:51:36 2016
From: tuukka.turunen at theqtcompany.com (Turunen Tuukka)
Date: Tue, 12 Apr 2016 06:51:36 +0000
Subject: [Development] CI for Qt WebKit
In-Reply-To: <AM4PR02MB1410BC306E3420448976E7E0E4950@AM4PR02MB1410.eurprd02.prod.outlook.com>
References: <CA19DBF3-404D-4109-8387-CB77118D502C@theqtcompany.com>
	<44C39B54-4633-48BE-BE16-7A78F434788E@theqtcompany.com>,
	<2633429.1024hN7qlE@tjmaciei-mobl4>,
	<AM4PR02MB1410BC306E3420448976E7E0E4950@AM4PR02MB1410.eurprd02.prod.outlook.com>
Message-ID: <VI1PR02MB14068D3DF2EB5E02BE085B44F6950@VI1PR02MB1406.eurprd02.prod.outlook.com>




________________________________________
> Lähettäjä: Development <development-bounces+tuukka.turunen=theqtcompany.com at qt-project.org> käyttäjän  puolestaHeikkinen Jani <jani.heikkinen at theqtcompany.com>
> Lähetetty: 12. huhtikuuta 2016 9:46
> Vastaanottaja: Thiago Macieira; development at qt-project.org
> Aihe: Re: [Development] CI for Qt WebKit
>
>>>That's exactly the time that they should be in the way... We may break those
>>>modules temporarily, but not leave them broken at the time of the release.
>
>
> I disagree. If module is removed (obsolete in .gitmodules) that cannot delay the release: It is just insane. if there is some reason(s) for that then I think we shouldn't even remove the module at all. 
> That 
> kind of semi-removal is the worst case: We are playing it is removed but actually working like it is officially as a part of release/packages. It is confusing for us all and causes just this kind of unnecessary 
> hassle :(
>
> br,
> jani

+1

Exactly like Jani said, when some module is removed it does not matter for the release. 

If there is any issue with a released version of Qt, that can be fixed also after the release if someone needs to use such a removed module with that release of Qt.

Yours,

                   Tuukka
________________________________________
Lähettäjä: Development <development-bounces+jani.heikkinen=theqtcompany.com at qt-project.org> käyttäjän  puolestaThiago Macieira <thiago.macieira at intel.com>
Lähetetty: 12. huhtikuuta 2016 1:20
Vastaanottaja: development at qt-project.org
Aihe: Re: [Development] CI for Qt WebKit

On segunda-feira, 11 de abril de 2016 20:34:44 PDT Knoll Lars wrote:
> The reason is that they should not be in the way to getting our releases
> out.

That's exactly the time that they should be in the way... We may break those
modules temporarily, but not leave them broken at the time of the release.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From annulen at yandex.ru  Tue Apr 12 11:50:12 2016
From: annulen at yandex.ru (Konstantin Tokarev)
Date: Tue, 12 Apr 2016 12:50:12 +0300
Subject: [Development] CI for Qt WebKit
In-Reply-To: <44C39B54-4633-48BE-BE16-7A78F434788E@theqtcompany.com>
References: <CA19DBF3-404D-4109-8387-CB77118D502C@theqtcompany.com>
	<44C39B54-4633-48BE-BE16-7A78F434788E@theqtcompany.com>
Message-ID: <4763851460454612@web28h.yandex.ru>



11.04.2016, 23:34, "Knoll Lars" <lars.knoll at theqtcompany.com>:
> Hi,
>
> we’re planning on doing a slight adjustments to how Qt WebKit and other unsupported modules are CI tested for 5.7 and onwards. Basically, they will not be tested as part of qt5.git integrations anymore and thus won’t block releases.

Will CI continue to build patches before landing them?


> But they will stay CI controlled and will be compile tested on a regular basis so that we will get notified if something breaks.
>
> The reason is that they should not be in the way to getting our releases out. At the same time, having them tested in regular intervals will notify us when something breaks, and we can then work on fixing this without causing problems for our main releases.
>
> Cheers,
> Lars
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin


From frederic.marchal at wowtechnology.com  Tue Apr 12 12:09:26 2016
From: frederic.marchal at wowtechnology.com (=?ISO-8859-1?Q?Fr=E9d=E9ric?= Marchal)
Date: Tue, 12 Apr 2016 12:09:26 +0200
Subject: [Development] Possible infinite loop in QString::toLocal8bit?
Message-ID: <3198660.bdryxMOvk4@port-fma>

Hi,

I was looking at how QString::toLocal8bit works and, on Windows, it looks like 
it may enter an infinite loop.

If I got it right, QString::toLocal8Bit_helper calls QTextCodec::fromUnicode 
which, on Windows, calls QWindowsLocalCodec::convertFromUnicode in 
qwindowscodec.cpp.

In that function, if WideCharToMultiByte fails because the input string is not 
a valid unicode string, the function displays a qWarning where it helpfully 
output the offending string using QString::toLocal8bit!

If the string cannot be converted in the first place, it won't be possible to 
convert it a second time to display the warning message. Hence the infinite 
loop.

It looks to me like the string should be displayed using QString::toUtf8.

Am I right? Is it worth opening a QTBUG for this?

Frederic



From tuukka.turunen at theqtcompany.com  Tue Apr 12 12:30:51 2016
From: tuukka.turunen at theqtcompany.com (Turunen Tuukka)
Date: Tue, 12 Apr 2016 10:30:51 +0000
Subject: [Development] CI for Qt WebKit
In-Reply-To: <4763851460454612@web28h.yandex.ru>
References: <CA19DBF3-404D-4109-8387-CB77118D502C@theqtcompany.com>
	<44C39B54-4633-48BE-BE16-7A78F434788E@theqtcompany.com>
	<4763851460454612@web28h.yandex.ru>
Message-ID: <VI1PR02MB14067BD0256237D3D13F736EF6950@VI1PR02MB1406.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-
> bounces+tuukka.turunen=theqtcompany.com at qt-project.org] On Behalf Of
> Konstantin Tokarev
> Sent: tiistaina 12. huhtikuuta 2016 12.50
> To: Knoll Lars <Lars.Knoll at theqtcompany.com>; Qt development mailing list
> <development at qt-project.org>
> Subject: Re: [Development] CI for Qt WebKit
> 
> 
> 
> 11.04.2016, 23:34, "Knoll Lars" <lars.knoll at theqtcompany.com>:
> > Hi,
> >
> > we’re planning on doing a slight adjustments to how Qt WebKit and other
> unsupported modules are CI tested for 5.7 and onwards. Basically, they will
> not be tested as part of qt5.git integrations anymore and thus won’t block
> releases.
> 
> Will CI continue to build patches before landing them?
> 

Yes it will. What is changed is that webkit is no longer part of qt5.bit integration as it is no longer part on the release.

> 
> > But they will stay CI controlled and will be compile tested on a regular basis
> so that we will get notified if something breaks.
> >
> > The reason is that they should not be in the way to getting our releases
> out. At the same time, having them tested in regular intervals will notify us
> when something breaks, and we can then work on fixing this without causing
> problems for our main releases.
> >
> > Cheers,
> > Lars
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> --
> Regards,
> Konstantin
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

From jani.heikkinen at theqtcompany.com  Tue Apr 12 12:48:33 2016
From: jani.heikkinen at theqtcompany.com (Heikkinen Jani)
Date: Tue, 12 Apr 2016 10:48:33 +0000
Subject: [Development] Qt 5.7.0 beta snapshot available - gtk 3
	and	packaging on RHEL 6
In-Reply-To: <4210863.E4Rg9Zd13E@luna>
References: <AM4PR02MB1410B58F3591DA30CCD62E89E4940@AM4PR02MB1410.eurprd02.prod.outlook.com>
	<2184572.tYyMDLlE42@frederik-thinkcentre-m93p>,
	<4210863.E4Rg9Zd13E@luna>
Message-ID: <AM4PR02MB1410FDD3CCAF412E87957478E4950@AM4PR02MB1410.eurprd02.prod.outlook.com>

On Monday 11 April 2016 16:50:18 Frederik Gladhorn wrote:
> Hello all,
[snip]
> For Qt 5.7, the options seem to be:
> 1.) ignore the problem and ship Qt packages in the installer without gtk
> theme 2.) revert the patch to have the gtk2 theme for one release longer
> and only have gtk3 with Qt 5.8
> 3.) package on rhel 7, but I'm told, we're already too late in the cycle
>
> Any ideas appreciated.

1 or 2, As Frederik wrote it is too late for 3). 

I propose we just ship beta with 1) and if there isnt big complains use that option with 5.7. And if there is then just revert the patch between beta and RC

br,
Jani

________________________________________
Lähettäjä: Development <development-bounces+jani.heikkinen=theqtcompany.com at qt-project.org> käyttäjän  puolestaLisandro Damián Nicanor Pérez Meyer <perezmeyer at gmail.com>
Lähetetty: 11. huhtikuuta 2016 19:37
Vastaanottaja: development at qt-project.org; releasing
Aihe: Re: [Development] Qt 5.7.0 beta snapshot available - gtk 3 and    packaging on RHEL 6

On Monday 11 April 2016 16:50:18 Frederik Gladhorn wrote:
> Hello all,
[snip]
> For Qt 5.7, the options seem to be:
> 1.) ignore the problem and ship Qt packages in the installer without gtk
> theme 2.) revert the patch to have the gtk2 theme for one release longer
> and only have gtk3 with Qt 5.8
> 3.) package on rhel 7, but I'm told, we're already too late in the cycle
>
> Any ideas appreciated.

I'll leave the above unanswered because I think I'm not the right one for that
question.

> In general I have a hard time seeing how to cleanly
> create packages on Linux, unless we basically ship an entire distro (similar
> to Chrome and others)... I'd love to learn about good approaches, since
> packaging on something "old enough to run everywhere" and "new enough to
> allow all dependencies to be built" seems hard to achieve.

I guess here that you are talking about "cleanness" with respect to
dependencies. We distro maintainers normally know that this is not easily
solvable except bundling half of them, which is in turn ugly.

It basically boils down to "one size does not fits all".

> Sadly we don't have the resources to create native packages for each and
> every distro (we want to allow our users to use Qt on older releases of
> their favorite distro) and I'm not sure if packagers would be willing to
> help us get into a situation where it's easy to create packages for all
> relevant distributions, installing into custom prefixes and having a mix of
> versions.

With my Debian maintainer hat on the most complicated thing would be to avoid
conflicting with existing distro installations. qtchooser can help here tough.

One thing to have in mind: if a user gets qt by using the online
installer/whatever method coming from you directly and sets it as default Qt
installation it will have problems with distro apps that uses Qt's private
headers.

> So for the time being I have been convinced that creating the installers is
> valuable for many people on Linux, but I wonder if there's a way we can do
> better.

I would really be interested here to have actual numbers. We in Debian can
provide backports if the situation merits it. So far I only see one or two
people asking us for Qt backports in a year. But maybe that doesn't reflects
the real necessity for it.

Yes, I understand that here I'm proposing having distro-provided packages
instead of getting the installations from you directly, but I think that's our
job if there is really people interested in them out there.

It might be interesting to say that most of the request of having up-to-date
Qt in stable (or old stable) Debian releases comes from people working at/for
companies and not from other developers.

I'm of course possibly biased in my answers so *please* do not hesitate in
asking/proposing other things, I might be missing the elephant in the room. If
there is anything we can do to improve the situation for our users in a
win-win way then we need to consider it.

--
"So long, and thanks for all the fish!"
  The Hitchhickers guide to the Galaxy

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


From edward.welbourne at theqtcompany.com  Tue Apr 12 13:44:35 2016
From: edward.welbourne at theqtcompany.com (Welbourne Edward)
Date: Tue, 12 Apr 2016 11:44:35 +0000
Subject: [Development] Possible infinite loop in QString::toLocal8bit?
In-Reply-To: <3198660.bdryxMOvk4@port-fma>
References: <3198660.bdryxMOvk4@port-fma>
Message-ID: <HE1PR0201MB1563D1A115BD24F585AEA707FE950@HE1PR0201MB1563.eurprd02.prod.outlook.com>

Frédéric Marchal wrote:

> I was looking at how QString::toLocal8bit works and, on Windows, it
> looks like it may enter an infinite loop.
>
> If I got it right, QString::toLocal8Bit_helper calls
> QTextCodec::fromUnicode which, on Windows, calls
> QWindowsLocalCodec::convertFromUnicode in qwindowscodec.cpp.

Specifically, QWindowsLocalCodec::convertFromUnicode().

> In that function, if WideCharToMultiByte fails because the input
> string is not a valid unicode string, the function displays a qWarning
> where it helpfully output the offending string using
> QString::toLocal8bit!
>
> If the string cannot be converted in the first place, it won't be
> possible to convert it a second time to display the warning
> message. Hence the infinite loop.

Beautiful - well spotted.

> It looks to me like the string should be displayed using
> QString::toUtf8.

The qWarning's format string even claims it is in UTF-8.

> Am I right?

Yes, you are.

> Is it worth opening a QTBUG for this?

Doing so would help track the matter (I have a fix, but may struggle to
construct a test-case - if you have one, please do let me know, either
by e-mail or in the bug report), but is not crucial: I have a patch in
preparation, ready for review (but for a test-case),

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

	Eddy.


From Morten.Sorvig at theqtcompany.com  Tue Apr 12 15:02:03 2016
From: Morten.Sorvig at theqtcompany.com (Sorvig Morten)
Date: Tue, 12 Apr 2016 13:02:03 +0000
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
Message-ID: <B700D37B-F852-4EBD-B375-9CC42C78895B@digia.com>


> On 11 Apr 2016, at 12:38, Ben Lau <xbenlau at gmail.com> wrote:
> 
> Hi,
> 
> I am writing an image provider that read all the images to memory at startup. And I found that the behaviour is different from 5.5.1 to 5.6 in iOS. Seems that it is undocumented. I wonder is it an expected behaviour or a bug?

Hi, this is indeed a regression in 5.6. We have a fix ready if you want to
patch your local version of Qt:

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

Thanks for bringing it up!
Morten





From mardy at users.sourceforge.net  Tue Apr 12 22:34:03 2016
From: mardy at users.sourceforge.net (Alberto Mardegan)
Date: Tue, 12 Apr 2016 23:34:03 +0300
Subject: [Development] QDrag and mouse events to QML MouseArea
Message-ID: <570D5BBB.7080306@users.sourceforge.net>

Hi all!
  I wanted to try fixing this bug:

https://bugreports.qt.io/browse/QTBUG-49876

(in QML, the dragged item disappears during the drag and drop operation,
if the dragType is Drag.Automatic -- external drag)

First of all, after some investigation I wonder whether this is actually
a bug, or if we should just document that during an external
(inter-process) drag the QML item won't be dragged; if one wants to see
a QML item being dragged during an external drag, then that's
QTBUG-37366, which I'm attempting to fix here (reviews welcome, BTW):

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

So, the question is whether QTBUG-49876 is valid at all. And if it is
valid, how should it be fixed?

Maybe QSimpleDrag's eventFilter() could forward the mouse move events to
the QWindow, but I suspect that this might not play too well with
hovering; so, it should be done only when QDrag is explicitly asked to.
Also, QSimpleDrag is AFAIK used only in Linux and OS X, so there should
be a different implementation for Windows.

My suggestion is that the bug is invalid, and we document that when
initiating an external DnD operations the target item should be anchored
(so that it does not move at all) and that the new Drag.pixmapUrl
property can be used to provide a visual feedback.

Opinions welcome :-)

Ciao,
  Alberto


From xbenlau at gmail.com  Tue Apr 12 23:12:24 2016
From: xbenlau at gmail.com (Ben Lau)
Date: Wed, 13 Apr 2016 05:12:24 +0800
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <B700D37B-F852-4EBD-B375-9CC42C78895B@digia.com>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
	<B700D37B-F852-4EBD-B375-9CC42C78895B@digia.com>
Message-ID: <CAAq4oLKYVe_Y0DrTC55bqDSYtb4zTfs4fnDfdBZMvDms9mMovw@mail.gmail.com>

On 12 April 2016 at 21:02, Sorvig Morten <Morten.Sorvig at theqtcompany.com>
wrote:

>
> > On 11 Apr 2016, at 12:38, Ben Lau <xbenlau at gmail.com> wrote:
> >
> > Hi,
> >
> > I am writing an image provider that read all the images to memory at
> startup. And I found that the behaviour is different from 5.5.1 to 5.6 in
> iOS. Seems that it is undocumented. I wonder is it an expected behaviour or
> a bug?
>
> Hi, this is indeed a regression in 5.6. We have a fix ready if you want to
> patch your local version of Qt:
>
>         https://codereview.qt-project.org/#/c/155514
>
> Thanks for bringing it up!
> Morten


HI Sorvig,

It is great to hear that! Thx!

So the correct way for a image provider to fit in a High DPI environment is
to set the devicePixelRatio in the returned QImage?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160413/049f5d0f/attachment.html>

From gmaxera at gmail.com  Wed Apr 13 09:13:07 2016
From: gmaxera at gmail.com (Gianluca)
Date: Wed, 13 Apr 2016 08:13:07 +0100
Subject: [Development] Fwd: [Interest] Strange ordering problem with ComboBox
References: <CABQ4Km96Zo1+M0LFnkdz53Q-e-i7STYnrBkYKGoCX6F1V-sPjA@mail.gmail.com>
Message-ID: <D8425883-72E0-41B2-8293-3D5ED176EA34@gmail.com>

Ok, let’s try to forward to development mailing list and see if we need to fire a bug.


Inizio messaggio inoltrato:

> Da: Shantanu Tushar <shaan7in at gmail.com>
> Oggetto: Re: [Interest] Strange ordering problem with ComboBox
> Data: 13 aprile 2016 08:10:27 GMT+1
> A: Gian Maxera <gmaxera at gmail.com>
> Cc: interest <interest at qt-project.org>
> 
> I haven't experienced exactly the same, but I did experience that if I use a QSortFilterProxyModel as a model for ComboBox and the sort order changes, ComboBox doesn't update itself. (A ListView connected with the same model updates).
> 
> On Mon, Apr 11, 2016 at 3:06 PM, Gian Maxera <gmaxera at gmail.com> wrote:
> Hello,
> I’m using the ComboBox item of QML with more than two Items with a ListModel like that:
> 
> 	ComboBox {
> 		id: rateType
> 		anchors.horizontalCenter: parent.horizontalCenter
> 		width: parent.width*0.9
> 		Component.onCompleted: {
> 			if ( models.appointment.lead == null ) {
> 				rateType.currentIndex = 0
> 			} else if ( models.appointment.lead.type == 'contact' ) {
> 				rateType.currentIndex = 0
> 			} else if ( models.appointment.lead.type == 'brochure' ) {
> 				rateType.currentIndex = 1
> 			} else if ( models.appointment.lead.type == 'tentative' ) {
> 				rateType.currentIndex = 2
> 			} else if ( models.appointment.lead.type == 'definite' ) {
> 				rateType.currentIndex = 3
> 			}
> 		}
> 		model: 	ListModel {
> 			ListElement {
> 				leadType: 'contact'
> 				leadText: 'Contact only'
> 			}
> 			ListElement {
> 				leadType: 'brochure'
> 				leadText: 'Brochure request'
> 			}
> 			ListElement {
> 				leadType: 'tentative'
> 				leadText: 'Tentative lead'
> 			}
> 			ListElement {
> 				leadType: 'definite'
> 				leadText: 'Definite lead'
> 			}
> 		}
> 		textRole: "leadText"
> 
> But the popup menu appearing for select the option contain the elements into a different order than ListModel and when you select one of those the ComboBox select a different one. In such a way that it seems the index are correct but the labels of the popup menu are wrong.
> 
> Someone hits this error before ?
> 
> I’m using Qt 5.5 for now.
> 
> Ciao,
> Gianluca.
> 
> 
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
> 
> 
> 
> 
> -- 
> Shantanu Tushar    (UTC +0530)
> shantanu.io

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160413/570e60f3/attachment.html>

From Tobias.Hunger at theqtcompany.com  Wed Apr 13 10:06:59 2016
From: Tobias.Hunger at theqtcompany.com (Hunger Tobias)
Date: Wed, 13 Apr 2016 08:06:59 +0000
Subject: [Development] Nominating Marco Benelli for Approver status
Message-ID: <1460534818.25741.38.camel@theqtcompany.com>

Hello Qt Developers,

I hereby nominate Marco Benelli for Approver status. He has put in a lot of
effort to maintain the QML code inside Qt Creator over the recent month and in
fact is the default assignee for all bugs in that area of Qt Creator.

He did good work in his area and Qt Creator in general, so I think he has more
than deserved Approver status by now.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

From Eike.Ziller at theqtcompany.com  Wed Apr 13 10:20:40 2016
From: Eike.Ziller at theqtcompany.com (Ziller Eike)
Date: Wed, 13 Apr 2016 08:20:40 +0000
Subject: [Development] [Qt-creator] Nominating Marco Benelli for
	Approver status
In-Reply-To: <1460534818.25741.38.camel@theqtcompany.com>
References: <1460534818.25741.38.camel@theqtcompany.com>
Message-ID: <6B91B77E-2322-45A9-B6D5-23684213F1C3@theqtcompany.com>


> On Apr 13, 2016, at 10:06 AM, Hunger Tobias <Tobias.Hunger at theqtcompany.com> wrote:
> 
> Hello Qt Developers,
> 
> I hereby nominate Marco Benelli for Approver status. He has put in a lot of
> effort to maintain the QML code inside Qt Creator over the recent month and in

months

> fact is the default assignee for all bugs in that area of Qt Creator.
> 
> He did good work in his area and Qt Creator in general, so I think he has more
> than deserved Approver status by now.

+1

> -- 
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
> Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller, Principal Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


From jani.heikkinen at theqtcompany.com  Fri Apr 15 14:07:22 2016
From: jani.heikkinen at theqtcompany.com (Heikkinen Jani)
Date: Fri, 15 Apr 2016 12:07:22 +0000
Subject: [Development] Qt 5.7.0 beta packages available for testing
Message-ID: <AM4PR02MB1410D2C26B48CE4AF795C63AE4680@AM4PR02MB1410.eurprd02.prod.outlook.com>

Hi all,


We have Qt 5.7.0 beta packages available


Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/420/

Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/399/

Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/334/

src: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/latest_src/  <http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/latest_src/>  (mirroring ongoing)


These packages will be official Qt5.7 beta packages if nothing really serious found during testing so please test the packages & report all possible beta blockers immediately. Also please make sure all beta blockers (/proposals) have '5.7.0 Beta' in 'Fix version(s)' -field.


br,
Jani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160415/786b84ee/attachment.html>

From mitya57.ml at gmail.com  Sun Apr 17 15:14:51 2016
From: mitya57.ml at gmail.com (Dmitry Shachnev)
Date: Sun, 17 Apr 2016 16:14:51 +0300
Subject: [Development] Qt 5.7.0 beta snapshot available - gtk 3 and
 packaging on RHEL 6
In-Reply-To: <2184572.tYyMDLlE42@frederik-thinkcentre-m93p>
References: <AM4PR02MB1410B58F3591DA30CCD62E89E4940@AM4PR02MB1410.eurprd02.prod.outlook.com>
	<2184572.tYyMDLlE42@frederik-thinkcentre-m93p>
Message-ID: <20160417130916.GA24901@mitya57.me>

Hi Frederik, and sorry for the late response,

On Mon, Apr 11, 2016 at 04:50:18PM +0200, Frederik Gladhorn wrote:
> Hello all,
>
> for Linux packaging we currently use a Red Hat 6 which seemed like a good 
> compromise at the time.
>
> I have been pondering https://bugreports.qt.io/browse/QTBUG-52259 for a while 
> and don't seem to reach a conclusion.
> We had a contribution porting our gtk 2 theme to gtk 3 (thanks Dmitry!).
> The question is how to proceed, from what I can tell, it's not trivial to get 
> gtk3 built on rhel6.
> For Linux distributions this is of course not a problem, but the Qt installer 
> is currently built without any gtk plugin compiled.
> In the future (Qt 5.8), I'd like to switch to rhel 7 as packaging platform, so 
> this problem should go away.
>
> For Qt 5.7, the options seem to be:
> 1.) ignore the problem and ship Qt packages in the installer without gtk theme
> 2.) revert the patch to have the gtk2 theme for one release longer and only 
> have gtk3 with Qt 5.8
> 3.) package on rhel 7, but I'm told, we're already too late in the cycle
>
> Any ideas appreciated. In general I have a hard time seeing how to cleanly 
> create packages on Linux, unless we basically ship an entire distro (similar 
> to Chrome and others)... I'd love to learn about good approaches, since 
> packaging on something "old enough to run everywhere" and "new enough to allow 
> all dependencies to be built" seems hard to achieve.

The GTK+ platform theme is actually a plugin (the libqgtk2.so file). Maybe
it can be built and/or distributed separately?

The biggest issue with missing GTK+ theme one needs to be aware of is that
Qt won't be able to detect the system icon theme on some environments (as that
part is currently provided by the GTK+ theme).

--
Dmitry Shachnev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160417/cc3d25cc/attachment.sig>

From xbenlau at gmail.com  Sun Apr 17 15:34:05 2016
From: xbenlau at gmail.com (Ben Lau)
Date: Sun, 17 Apr 2016 21:34:05 +0800
Subject: [Development] The behaviour of Image / image provider are
 different from 5.5.1 to 5.6 in iOS
In-Reply-To: <CAAq4oLKYVe_Y0DrTC55bqDSYtb4zTfs4fnDfdBZMvDms9mMovw@mail.gmail.com>
References: <CAAq4oLLQfguLhBm63wK8NZZNofORK0AWm2XD+qPZvsqnW1wAwg@mail.gmail.com>
	<B700D37B-F852-4EBD-B375-9CC42C78895B@digia.com>
	<CAAq4oLKYVe_Y0DrTC55bqDSYtb4zTfs4fnDfdBZMvDms9mMovw@mail.gmail.com>
Message-ID: <CAAq4oLLyarPztQW88nMtFTdXepMxcWYNyUz9Fx2y-pyuYY=kMQ@mail.gmail.com>

Moreover, I think BorderImage also do not handle image from image provider
in high DPI mode correctly.

I have attach the screenshot captured in iPhone6 (devicePixelRatio == 3)

qrc://image/button2.png : That is correct

image://arts/button2 : The same image source, but the result is not correct.

Example code:
https://github.com/benlau/quickcross/blob/master/tests/imageprovider/main.qml




On 13 April 2016 at 05:12, Ben Lau <xbenlau at gmail.com> wrote:

>
>
> On 12 April 2016 at 21:02, Sorvig Morten <Morten.Sorvig at theqtcompany.com>
> wrote:
>
>>
>> > On 11 Apr 2016, at 12:38, Ben Lau <xbenlau at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > I am writing an image provider that read all the images to memory at
>> startup. And I found that the behaviour is different from 5.5.1 to 5.6 in
>> iOS. Seems that it is undocumented. I wonder is it an expected behaviour or
>> a bug?
>>
>> Hi, this is indeed a regression in 5.6. We have a fix ready if you want to
>> patch your local version of Qt:
>>
>>         https://codereview.qt-project.org/#/c/155514
>>
>> Thanks for bringing it up!
>> Morten
>
>
> HI Sorvig,
>
> It is great to hear that! Thx!
>
> So the correct way for a image provider to fit in a High DPI environment
> is to set the devicePixelRatio in the returned QImage?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160417/f06eb99f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2016-04-17 21.15.41.png
Type: image/png
Size: 212004 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160417/f06eb99f/attachment.png>

From sean.harmer at kdab.com  Mon Apr 18 11:54:41 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Mon, 18 Apr 2016 10:54:41 +0100
Subject: [Development] doc.qt.io certificate issues
Message-ID: <1696600.3u4A4CBVfh@cartman>

Hi,

It seems the certificate installed for the above site is incorrect. It reports 
itself to be for *.qtcloudapp.com.

Why do we keep having issues with certificates on Qt Project domains?

Cheers,

Sean
-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From rich at kde.org  Mon Apr 18 12:26:04 2016
From: rich at kde.org (Richard Moore)
Date: Mon, 18 Apr 2016 11:26:04 +0100
Subject: [Development] doc.qt.io certificate issues
In-Reply-To: <1696600.3u4A4CBVfh@cartman>
References: <1696600.3u4A4CBVfh@cartman>
Message-ID: <CAMp7mVtd6A3U2v0SDj707mEsgFgA1FGiye2xvr4dFMSvXG3wQA@mail.gmail.com>

On 18 April 2016 at 10:54, Sean Harmer <sean.harmer at kdab.com> wrote:

> Hi,
>
> It seems the certificate installed for the above site is incorrect. It
> reports
> itself to be for *.qtcloudapp.com.
>

​Yep, the cert is not valid for this domain. Also note that it expires in
approximately 1 month, so now would be an excellent time to get it updated.

Cheers

Rich.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160418/de4f6fde/attachment.html>

From olivier at woboq.com  Tue Apr 19 12:50:20 2016
From: olivier at woboq.com (Olivier Goffart)
Date: Tue, 19 Apr 2016 12:50:20 +0200
Subject: [Development] Qt-Project misrepresented on qt.io
Message-ID: <2482364.eDi5QLsHKE@finn>

Hi,

I feel that with the unification, there is less and less visibility of the Qt 
open source project:
The qt.io home page contains no information that Qt is open source and 
contains contributions from the community;
The "Developers" section, to which http://qt-project.org redirects, mostly 
contains information for developers using Qt, (and more than half seems to be 
marketing targeted for people not yet using Qt) and only a very small 
paragraph near the end seems somehow targeted to contributors;
Any links or aggregation to planetqt seems gone. Planet Qt is supposed to be 
an aggregation of the blogs of Qt contributors.

It was much better in 2015 where the developers page contained information for 
contributors
http://web.archive.org/web/20150723065217/http://www.qt.io/developers/

I think there should be a "Contributors" section from qt.io  where qt-
project.org would redirect. And which would have links useful for 
contributors, including links and aggregation of planet qt.

I acknowledge that The Qt Company is by far the biggest contributor to Qt. And 
that because of the CLA, they have no obligation whatsoever.
But I just feel it's not fair to hide the open source nature of Qt and the 
open source contribution completely from qt.io. When the unification was 
announced, it was said that the open source qt-project would continue to be 
represented, but i just feel it's no longer the case with the new website.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org



From sean.harmer at kdab.com  Tue Apr 19 14:41:54 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 19 Apr 2016 13:41:54 +0100
Subject: [Development] Qt-Project misrepresented on qt.io
In-Reply-To: <2482364.eDi5QLsHKE@finn>
References: <2482364.eDi5QLsHKE@finn>
Message-ID: <1527234.Cibt1qTh8K@cartman>

Hi,

On Tuesday 19 April 2016 12:50:20 Olivier Goffart wrote:
> I feel that with the unification, there is less and less visibility of the
> Qt open source project:
> The qt.io home page contains no information that Qt is open source and
> contains contributions from the community;
> The "Developers" section, to which http://qt-project.org redirects, mostly
> contains information for developers using Qt, (and more than half seems to
> be marketing targeted for people not yet using Qt) and only a very small
> paragraph near the end seems somehow targeted to contributors;
> Any links or aggregation to planetqt seems gone. Planet Qt is supposed to be
> an aggregation of the blogs of Qt contributors.
> 
> It was much better in 2015 where the developers page contained information
> for contributors
> http://web.archive.org/web/20150723065217/http://www.qt.io/developers/
> 
> I think there should be a "Contributors" section from qt.io  where qt-
> project.org would redirect. And which would have links useful for
> contributors, including links and aggregation of planet qt.
> 
> I acknowledge that The Qt Company is by far the biggest contributor to Qt.
> And that because of the CLA, they have no obligation whatsoever.
> But I just feel it's not fair to hide the open source nature of Qt and the
> open source contribution completely from qt.io. When the unification was
> announced, it was said that the open source qt-project would continue to be
> represented, but i just feel it's no longer the case with the new website.

I agree. It's important to make it clear that Qt can still be used under FOSS 
licenses for free, and that Qt contains a large proportion of code contributed 
by individuals and companies outside of The Qt Company:

http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png

By not making it easy for people to see that it is possible for them to 
contribute Qt and making it easy for them to get on board with the process we 
are harming the project. Having a guide to making your first contribution would 
be great, and perhaps having a support person available to help mentor new 
contributors would be nice.

Kind regards,

Sean
-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From tero.kojo at theqtcompany.com  Tue Apr 19 15:19:34 2016
From: tero.kojo at theqtcompany.com (Kojo Tero)
Date: Tue, 19 Apr 2016 13:19:34 +0000
Subject: [Development] Qt-Project misrepresented on qt.io
In-Reply-To: <1527234.Cibt1qTh8K@cartman>
References: <2482364.eDi5QLsHKE@finn> <1527234.Cibt1qTh8K@cartman>
Message-ID: <VI1PR0201MB15367BD381F7ABF6BA110F2C8D6C0@VI1PR0201MB1536.eurprd02.prod.outlook.com>

Hi,

Point taken. The open source side does need to be more clearly visible.

Currently the developer page is structured more toward the new user, with the idea that more experienced users will visit again and find more content, like the contribution guidelines.

So the improvement idea can be split in two parts:
- Provide a clearer path for potential contributors to get involved in Qt
- Make it more clear that Qt is available as open source

In practice the wiki does have a pretty good set of "how to contribute" pages, but a new user will not stumble upon them by accident. Making links to those from the developers page would probably help a lot. Also having the contribution guide in the wiki is beneficial from my point, as then anyone contributing can improve the guide.

The other side of the coin is crowding the developer page with information. A page about contributing might be a solution, or then a rethink of the developer page. The new brand style actually provides better tools for cleaner information presentation. I'll talk with a web developer about how to present the information and start trying things.

The other point on making the open source side more visible needs more thinking. It probably can be achieved partially on the developer page, but it needs wordings in many places.

Tero

-----Original Message-----
From: Development [mailto:development-bounces+tero.kojo=theqtcompany.com at qt-project.org] On Behalf Of Sean Harmer
Sent: tiistaina 19. huhtikuuta 2016 15.42
To: development at qt-project.org
Subject: Re: [Development] Qt-Project misrepresented on qt.io

Hi,

On Tuesday 19 April 2016 12:50:20 Olivier Goffart wrote:
> I feel that with the unification, there is less and less visibility of 
> the Qt open source project:
> The qt.io home page contains no information that Qt is open source and 
> contains contributions from the community; The "Developers" section, 
> to which http://qt-project.org redirects, mostly contains information 
> for developers using Qt, (and more than half seems to be marketing 
> targeted for people not yet using Qt) and only a very small paragraph 
> near the end seems somehow targeted to contributors; Any links or 
> aggregation to planetqt seems gone. Planet Qt is supposed to be an 
> aggregation of the blogs of Qt contributors.
> 
> It was much better in 2015 where the developers page contained 
> information for contributors 
> http://web.archive.org/web/20150723065217/http://www.qt.io/developers/
> 
> I think there should be a "Contributors" section from qt.io  where qt- 
> project.org would redirect. And which would have links useful for 
> contributors, including links and aggregation of planet qt.
> 
> I acknowledge that The Qt Company is by far the biggest contributor to Qt.
> And that because of the CLA, they have no obligation whatsoever.
> But I just feel it's not fair to hide the open source nature of Qt and 
> the open source contribution completely from qt.io. When the 
> unification was announced, it was said that the open source qt-project 
> would continue to be represented, but i just feel it's no longer the case with the new website.

I agree. It's important to make it clear that Qt can still be used under FOSS licenses for free, and that Qt contains a large proportion of code contributed by individuals and companies outside of The Qt Company:

http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png

By not making it easy for people to see that it is possible for them to contribute Qt and making it easy for them to get on board with the process we are harming the project. Having a guide to making your first contribution would be great, and perhaps having a support person available to help mentor new contributors would be nice.

Kind regards,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From sean.harmer at kdab.com  Tue Apr 19 15:47:37 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 19 Apr 2016 14:47:37 +0100
Subject: [Development] Qt-Project misrepresented on qt.io
In-Reply-To: <VI1PR0201MB15367BD381F7ABF6BA110F2C8D6C0@VI1PR0201MB1536.eurprd02.prod.outlook.com>
References: <2482364.eDi5QLsHKE@finn> <1527234.Cibt1qTh8K@cartman>
	<VI1PR0201MB15367BD381F7ABF6BA110F2C8D6C0@VI1PR0201MB1536.eurprd02.prod.outlook.com>
Message-ID: <1618146.mJWz25VA2x@cartman>

On Tuesday 19 April 2016 13:19:34 Kojo Tero wrote:
> Hi,
> 
> Point taken. The open source side does need to be more clearly visible.
> 
> Currently the developer page is structured more toward the new user, with
> the idea that more experienced users will visit again and find more
> content, like the contribution guidelines.
> 
> So the improvement idea can be split in two parts:
> - Provide a clearer path for potential contributors to get involved in Qt
> - Make it more clear that Qt is available as open source
> 
> In practice the wiki does have a pretty good set of "how to contribute"
> pages, but a new user will not stumble upon them by accident. Making links
> to those from the developers page would probably help a lot. Also having
> the contribution guide in the wiki is beneficial from my point, as then
> anyone contributing can improve the guide.
> 
> The other side of the coin is crowding the developer page with information.
> A page about contributing might be a solution, or then a rethink of the
> developer page. The new brand style actually provides better tools for
> cleaner information presentation. I'll talk with a web developer about how
> to present the information and start trying things.
> 
> The other point on making the open source side more visible needs more
> thinking. It probably can be achieved partially on the developer page, but
> it needs wordings in many places.

Thanks Tero, much appreciated.

Sean

> 
> Tero
> 
> -----Original Message-----
> From: Development
> [mailto:development-bounces+tero.kojo=theqtcompany.com at qt-project.org] On
> Behalf Of Sean Harmer Sent: tiistaina 19. huhtikuuta 2016 15.42
> To: development at qt-project.org
> Subject: Re: [Development] Qt-Project misrepresented on qt.io
> 
> Hi,
> 
> On Tuesday 19 April 2016 12:50:20 Olivier Goffart wrote:
> > I feel that with the unification, there is less and less visibility of
> > the Qt open source project:
> > The qt.io home page contains no information that Qt is open source and
> > contains contributions from the community; The "Developers" section,
> > to which http://qt-project.org redirects, mostly contains information
> > for developers using Qt, (and more than half seems to be marketing
> > targeted for people not yet using Qt) and only a very small paragraph
> > near the end seems somehow targeted to contributors; Any links or
> > aggregation to planetqt seems gone. Planet Qt is supposed to be an
> > aggregation of the blogs of Qt contributors.
> > 
> > It was much better in 2015 where the developers page contained
> > information for contributors
> > http://web.archive.org/web/20150723065217/http://www.qt.io/developers/
> > 
> > I think there should be a "Contributors" section from qt.io  where qt-
> > project.org would redirect. And which would have links useful for
> > contributors, including links and aggregation of planet qt.
> > 
> > I acknowledge that The Qt Company is by far the biggest contributor to Qt.
> > And that because of the CLA, they have no obligation whatsoever.
> > But I just feel it's not fair to hide the open source nature of Qt and
> > the open source contribution completely from qt.io. When the
> > unification was announced, it was said that the open source qt-project
> > would continue to be represented, but i just feel it's no longer the case
> > with the new website.
> I agree. It's important to make it clear that Qt can still be used under
> FOSS licenses for free, and that Qt contains a large proportion of code
> contributed by individuals and companies outside of The Qt Company:
> 
> http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.pn
> g
> 
> By not making it easy for people to see that it is possible for them to
> contribute Qt and making it easy for them to get on board with the process
> we are harming the project. Having a guide to making your first
> contribution would be great, and perhaps having a support person available
> to help mentor new contributors would be nice.
> 
> Kind regards,
> 
> Sean
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd,
> a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
> Mobile: +44 (0)7545 140604
> KDAB - Qt Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From nilesh.kokane05 at gmail.com  Tue Apr 19 18:05:24 2016
From: nilesh.kokane05 at gmail.com (Nilesh Kokane)
Date: Tue, 19 Apr 2016 21:35:24 +0530
Subject: [Development] Qt-Project misrepresented on qt.io
In-Reply-To: <VI1PR0201MB15367BD381F7ABF6BA110F2C8D6C0@VI1PR0201MB1536.eurprd02.prod.outlook.com>
References: <2482364.eDi5QLsHKE@finn> <1527234.Cibt1qTh8K@cartman>
	<VI1PR0201MB15367BD381F7ABF6BA110F2C8D6C0@VI1PR0201MB1536.eurprd02.prod.outlook.com>
Message-ID: <CAOZATazzimLGq9=9eaTDjKqgUiucDD=e8z0n872aO0EGJQB_pQ@mail.gmail.com>

On Apr 19, 2016 6:49 PM, "Kojo Tero" <tero.kojo at theqtcompany.com> wrote:
>
> Hi,
>
> Point taken. The open source side does need to be more clearly visible.
>
> Currently the developer page is structured more toward the new user, with
the idea that more experienced users will visit again and find more
content, like the contribution guidelines.
>
> So the improvement idea can be split in two parts:
> - Provide a clearer path for potential contributors to get involved in Qt
> - Make it more clear that Qt is available as open source
>
> In practice the wiki does have a pretty good set of "how to contribute"
pages, but a new user will not stumble upon them by accident. Making links
to those from the developers page would probably help a lot. Also having
the contribution guide in the wiki is beneficial from my point, as then
anyone contributing can improve the guide.

+1

> The other side of the coin is crowding the developer page with
information. A page about contributing might be a solution, or then a
rethink of the developer page. The new brand style actually provides better
tools for cleaner information presentation. I'll talk with a web developer
about how to present the information and start trying things.
>
> The other point on making the open source side more visible needs more
thinking. It probably can be achieved partially on the developer page, but
it needs wordings in many places.

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160419/b298b237/attachment.html>

From nassian at bitshift-dynamics.de  Tue Apr 19 19:45:33 2016
From: nassian at bitshift-dynamics.de (Alexander Nassian)
Date: Tue, 19 Apr 2016 19:45:33 +0200
Subject: [Development] Qt-Project misrepresented on qt.io
Message-ID: <80AA674F-1E51-47B0-B57E-08531AC5D61D@bitshift-dynamics.de>

I also see a growing trend at The Qt Company on trying to sell more commercial licenses by creating fear because of the opensource licenses. At any corner you hear „ohh, ohh that may not be legal to distribute, but just be sure buy a license“. This makes me kind of sad. I love Qt, I love commercial services and I love open source. Commercial support or additions to opensource projects should be sold by providing a benefit to the customer, not by creating fear.

Just my 2 cents,
Alexander Nassian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160419/9c120fbf/attachment.html>

From jani.heikkinen at qt.io  Wed Apr 20 12:32:57 2016
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 20 Apr 2016 10:32:57 +0000
Subject: [Development] Qt 5.7.0 beta packages available for testing
In-Reply-To: <AM3PR02MB1186081C4CEA13427E81413D9D6D0@AM3PR02MB1186.eurprd02.prod.outlook.com>
References: <AM4PR02MB1410D2C26B48CE4AF795C63AE4680@AM4PR02MB1410.eurprd02.prod.outlook.com>,
	<AM3PR02MB1186081C4CEA13427E81413D9D6D0@AM3PR02MB1186.eurprd02.prod.outlook.com>
Message-ID: <AM3PR02MB1186CA4879E8D9885E9F647F9D6D0@AM3PR02MB1186.eurprd02.prod.outlook.com>

Hi all,


Unfortunately we needed to update Beta packages once more :( New packages are now here:


Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/425/

Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/406/

Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/337/

src: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/latest_src/
<http://ci-files02-hki.ci.local/packages/jenkins/qt/5.7.0/installers/testing/>


Packages have updated QtCreator in (Qt 4.0.0 RC1 containing fix for QTCREATORBUG-16102) + some packaging side fixes (QTBUG-52599 + some minor ones as well) but no changes in qt content.


Packages are smoke tested by RTA & everything seems to be pretty much ok. See full list of RTA findings from https://bugreports.qt.io/issues/?filter=17601


Please update Qt 5.7.0 beta known issues page here (if needed): https://wiki.qt.io/Qt_5.7.0_Known_Issues


We are trying to release Beta tomorrow so please test the packages & inform us immediately if there is still something blocking the beta release.


br,

Jani




________________________________
From: Heikkinen Jani <jani.heikkinen at theqtcompany.com>
Sent: Friday, April 15, 2016 3:07 PM
To: development at qt-project.org
Subject: Qt 5.7.0 beta packages available for testing


Hi all,


We have Qt 5.7.0 beta packages available


Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/420/

Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/399/

Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/334/

src: http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/latest_src/  <http://download.qt.io/snapshots/qt/5.7/5.7.0-beta/latest_src/>  (mirroring ongoing)


These packages will be official Qt5.7 beta packages if nothing really serious found during testing so please test the packages & report all possible beta blockers immediately. Also please make sure all beta blockers (/proposals) have '5.7.0 Beta' in 'Fix version(s)' -field.


br,
Jani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160420/336e07df/attachment.html>

From announce at qt-project.org  Wed Apr 20 14:10:46 2016
From: announce at qt-project.org (List for announcements regarding Qt releases and development)
Date: Wed, 20 Apr 2016 12:10:46 +0000
Subject: [Development] [Announce] Qt Creator 4.0 RC1 released
Message-ID: <mailman.446.1461166438.4158.announce@qt-project.org>

We are happy to announce the release of Qt Creator 4.0 RC1 !

Read more: https://blog.qt.io/blog/2016/04/20/qt-creator-4-0-rc1-released/

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



_______________________________________________
Announce mailing list
Announce at qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce

From announce at qt-project.org  Thu Apr 21 12:06:08 2016
From: announce at qt-project.org (List for announcements regarding Qt releases and development)
Date: Thu, 21 Apr 2016 10:06:08 +0000
Subject: [Development] [Announce] Qt 5.7.0 Beta released
Message-ID: <mailman.472.1461233173.4158.announce@qt-project.org>

Hi all,


Qt 5.7.0 Beta is released today, see http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/


Big thanks for everyone involved!


br,

Jani


Jani Heikkinen
Release Manager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikkinen at qt.io
http://qt.io<http://qt.io/>


[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]<http://qt.io/>
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]<http://www.facebook.com/Qt>     [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] <http://www.twitter.com/qtproject>       [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] <https://www.linkedin.com/company/the-qt-company/>      [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] <https://plus.google.com/104580575722059274792>       [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] <https://www.youtube.com/QtStudios>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160421/d0a7ac8a/attachment.html>
-------------- next part --------------
_______________________________________________
Announce mailing list
Announce at qt-project.org
http://lists.qt-project.org/mailman/listinfo/announce

From md at rpzdesign.com  Thu Apr 21 15:08:21 2016
From: md at rpzdesign.com (md at rpzdesign.com)
Date: Thu, 21 Apr 2016 07:08:21 -0600
Subject: [Development] [Announce] Qt 5.7.0 Beta released
In-Reply-To: <mailman.472.1461233173.4158.announce@qt-project.org>
References: <mailman.472.1461233173.4158.announce@qt-project.org>
Message-ID: <5718D0C5.4000705@rpzdesign.com>

Jani & Tuuka:

There is a reference to the upcoming Qt Quick Compiler in 5.8 in the 5.7 beta announcment.

http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/

Where do we send input to the people in charge of making 5.8 design decisions?

Since it looks like this is going to a significant re-factor of the base code from 5.7, this is the moment to speak up.

I submit that there is a currently a dysfunctional design dependence between a 5.8 Qt Quick Compiler, the requirement of QMLDIR files for plugins,
the QR("") Internationalization pattern, and QQmlComponent C++ class.

The architecture is cumbersome if you have a project structure that deviates in any way from the classic QRC oriented resource files, you do a lot of work.

What I would like to see in 5.8 and beyond.

1)  QQmlComponent as the primary QML interface for C++ developers with the QtQuick Compiler optionally compiling loaded QML from a byte array and shipped to a customer in the form of downloadable Compiled QML!!!
2) QQmlComponent able to load definitions into the component cache to be used in qml "Import MyComponent 1.0"
3) Drop QMLDIR files entirely, they are really stupid.  They have no place in a dynamic loadable plugin/component architecture.
4) Allow plugins (either C++ or QML) to be loaded by C++ or QQmlComponent.LoadPlugin( array of plugin bytes!, not FILE or URL based!)
Right now I am forced to statically link my plugins into the executable for QML to see them and use them. Very clumsy.
5) Decouple the GUI/QML from NetworkResourceManager.  The NetworkResourceManager should be an optional component, not required for every project.
If you need to download QML using an URL, provide a bridge class to perform that.
6) International Support Decoupled (So I can use my own hooks instead of translation files in Qr(" ") usage pattern

I really think that if the architecture and cumulative design choices are reviewed, you can see a lot of legacy decisions that now can get factored out of the design
so there is cleanliness and a proper fit for the Qt Quick Compiler in relation to the other QML/C++ constructs.

Thanks for listening,

Marco










On 4/21/2016 4:06 AM, List for announcements regarding Qt releases and development wrote:
>
> Hi all,
>
>
> Qt 5.7.0 Beta is released today, see http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/
>
>
> Big thanks for everyone involved!
>
>
> br,
>
> Jani
>
>
> Jani Heikkinen
> ReleaseManager
>
> The Qt Company
> Elektroniikkatie 13
> 90590 Oulu Finland
> jani.heikkinen at qt.io
> http://qt.io <http://qt.io/>
>
>
> <http://qt.io/>
> <http://www.facebook.com/Qt> 	<http://www.twitter.com/qtproject> 	<https://www.linkedin.com/company/the-qt-company/> 	<https://plus.google.com/104580575722059274792> 	<https://www.youtube.com/QtStudios>
>
>
>
>
> _______________________________________________
> Announce mailing list
> Announce at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/announce
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160421/326287e5/attachment.html>

From andrewponomarenko at yandex.ru  Fri Apr 22 17:37:34 2016
From: andrewponomarenko at yandex.ru (Ponomarenko Andrey)
Date: Fri, 22 Apr 2016 18:37:34 +0300
Subject: [Development] Binary compatibility report for Qt 5.7.0 Beta
Message-ID: <8170671461339454@web20j.yandex.ru>

Hello,

The report on binary compatibility for Qt 5.7.0 Beta is ready: http://abi-laboratory.pro/tracker/timeline/qt/

Thank you.


From sean.harmer at kdab.com  Sat Apr 23 12:57:18 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 23 Apr 2016 11:57:18 +0100
Subject: [Development] CI failures
Message-ID: <571B550E.8010902@kdab.com>

Hi,

I've been trying to merge some changes to Qt 3D but have been getting 
failures in qtbase since yesterday. Is there something wrong or am I 
just being unlucky? I'm slightly confused as I thought the main benefit 
of the new CI was that it didn't need to build dependent modules or am I 
misunderstanding this?

Cheers,

Sean

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts



From sean.harmer at kdab.com  Sat Apr 23 13:03:18 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 23 Apr 2016 12:03:18 +0100
Subject: [Development] CI failures
In-Reply-To: <571B550E.8010902@kdab.com>
References: <571B550E.8010902@kdab.com>
Message-ID: <571B5676.7050305@kdab.com>

An example of the failure is at:

http://testresults.qt.io/logs/qt/qtbase/8586cccc071240a8eff6c5aa53a90010dae55193/WindowsWindows_7x86WindowsWindows_7x86Mingw53DebugAndRelease_Release_OpenGLDynamic/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

Specifically:

qwindowsfontenginedirectwrite.cpp: In member function 'QImage QWindowsFontEngineDirectWrite::imageForGlyph(glyph_t, QFixed, int, const QTransform&)':
qwindowsfontenginedirectwrite.cpp:581:22: error: 'DWRITE_E_NOCOLOR' was not declared in this scope
          HRESULT hr = DWRITE_E_NOCOLOR;


Cheers,

Sean

On 23/04/2016 11:57, Sean Harmer wrote:
> Hi,
>
> I've been trying to merge some changes to Qt 3D but have been getting 
> failures in qtbase since yesterday. Is there something wrong or am I 
> just being unlucky? I'm slightly confused as I thought the main 
> benefit of the new CI was that it didn't need to build dependent 
> modules or am I misunderstanding this?
>
> Cheers,
>
> Sean
>


-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts



From massimocallegari at yahoo.it  Sat Apr 23 13:06:26 2016
From: massimocallegari at yahoo.it (Massimo Callegari)
Date: Sat, 23 Apr 2016 11:06:26 +0000 (UTC)
Subject: [Development] CI failures
In-Reply-To: <571B5676.7050305@kdab.com>
References: <571B5676.7050305@kdab.com>
Message-ID: <307570493.1143998.1461409586538.JavaMail.yahoo@mail.yahoo.com>

I've had the very same issue on MSYS2 and I came up with a patch for upstream:https://github.com/Alexpux/mingw-w64/pull/1

I believe the issue involves only mingw based systems.

      Da: Sean Harmer <sean.harmer at kdab.com>
 A: development at qt-project.org 
 Inviato: Sabato 23 Aprile 2016 13:03
 Oggetto: Re: [Development] CI failures
   
An example of the failure is at:

http://testresults.qt.io/logs/qt/qtbase/8586cccc071240a8eff6c5aa53a90010dae55193/WindowsWindows_7x86WindowsWindows_7x86Mingw53DebugAndRelease_Release_OpenGLDynamic/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

Specifically:

qwindowsfontenginedirectwrite.cpp: In member function 'QImage QWindowsFontEngineDirectWrite::imageForGlyph(glyph_t, QFixed, int, const QTransform&)':
qwindowsfontenginedirectwrite.cpp:581:22: error: 'DWRITE_E_NOCOLOR' was not declared in this scope
          HRESULT hr = DWRITE_E_NOCOLOR;


Cheers,

Sean

On 23/04/2016 11:57, Sean Harmer wrote:
> Hi,
>
> I've been trying to merge some changes to Qt 3D but have been getting 
> failures in qtbase since yesterday. Is there something wrong or am I 
> just being unlucky? I'm slightly confused as I thought the main 
> benefit of the new CI was that it didn't need to build dependent 
> modules or am I misunderstanding this?
>
> Cheers,
>
> Sean
>


-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160423/4480ce49/attachment.html>

From Simon.Hausmann at qt.io  Sat Apr 23 13:11:38 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Sat, 23 Apr 2016 11:11:38 +0000
Subject: [Development] CI failures
In-Reply-To: <571B5676.7050305@kdab.com>
References: <571B550E.8010902@kdab.com>,<571B5676.7050305@kdab.com>
Message-ID: <DB4PR02MB054161D0A0F1667530FF92AA8C600@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,

Usually the CI system won't rebuild depending modules, but in this case no builds exist of qtbase. That is because MinGW 5.3 was added to the CI system - replacing MinGW 4.9 - maybe yesterday (I'm not sure exactly when) and qtbase doesn't compile with it.

I'll try to get access to a laptop and see if I can revert the changes.


Simon

________________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Sean Harmer <sean.harmer at kdab.com>
Sent: Saturday, April 23, 2016 1:03 PM
To: development at qt-project.org
Subject: Re: [Development] CI failures

An example of the failure is at:

http://testresults.qt.io/logs/qt/qtbase/8586cccc071240a8eff6c5aa53a90010dae55193/WindowsWindows_7x86WindowsWindows_7x86Mingw53DebugAndRelease_Release_OpenGLDynamic/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

Specifically:

qwindowsfontenginedirectwrite.cpp: In member function 'QImage QWindowsFontEngineDirectWrite::imageForGlyph(glyph_t, QFixed, int, const QTransform&)':
qwindowsfontenginedirectwrite.cpp:581:22: error: 'DWRITE_E_NOCOLOR' was not declared in this scope
          HRESULT hr = DWRITE_E_NOCOLOR;


Cheers,

Sean

On 23/04/2016 11:57, Sean Harmer wrote:
> Hi,
>
> I've been trying to merge some changes to Qt 3D but have been getting
> failures in qtbase since yesterday. Is there something wrong or am I
> just being unlucky? I'm slightly confused as I thought the main
> benefit of the new CI was that it didn't need to build dependent
> modules or am I misunderstanding this?
>
> Cheers,
>
> Sean
>


--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From Simon.Hausmann at qt.io  Sat Apr 23 13:17:15 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Sat, 23 Apr 2016 11:17:15 +0000
Subject: [Development] CI failures
In-Reply-To: <DB4PR02MB054161D0A0F1667530FF92AA8C600@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <571B550E.8010902@kdab.com>, <571B5676.7050305@kdab.com>,
	<DB4PR02MB054161D0A0F1667530FF92AA8C600@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <9a54430d-81cf-4a3a-8e23-7db0dbd18e41@qt.io>

Hi,

I have reverted the changes , I hope it works now.

Simon



From: Simon Hausmann
Sent: Apr 23, 2016 1:11 PM
To: Sean Harmer; development at qt-project.org
Subject: Re: [Development] CI failures

Hi,

Usually the CI system won't rebuild depending modules, but in this case no builds exist of qtbase. That is because MinGW 5.3 was added to the CI system - replacing MinGW 4.9 - maybe yesterday (I'm not sure exactly when) and qtbase doesn't compile with it.

I'll try to get access to a laptop and see if I can revert the changes.


Simon

________________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Sean Harmer <sean.harmer at kdab.com>
Sent: Saturday, April 23, 2016 1:03 PM
To: development at qt-project.org
Subject: Re: [Development] CI failures

An example of the failure is at:

http://testresults.qt.io/logs/qt/qtbase/8586cccc071240a8eff6c5aa53a90010dae55193/WindowsWindows_7x86WindowsWindows_7x86Mingw53DebugAndRelease_Release_OpenGLDynamic/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz

Specifically:

qwindowsfontenginedirectwrite.cpp: In member function 'QImage QWindowsFontEngineDirectWrite::imageForGlyph(glyph_t, QFixed, int, const QTransform&)':
qwindowsfontenginedirectwrite.cpp:581:22: error: 'DWRITE_E_NOCOLOR' was not declared in this scope
          HRESULT hr = DWRITE_E_NOCOLOR;


Cheers,

Sean

On 23/04/2016 11:57, Sean Harmer wrote:
> Hi,
>
> I've been trying to merge some changes to Qt 3D but have been getting
> failures in qtbase since yesterday. Is there something wrong or am I
> just being unlucky? I'm slightly confused as I thought the main
> benefit of the new CI was that it didn't need to build dependent
> modules or am I misunderstanding this?
>
> Cheers,
>
> Sean
>


--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160423/f0d7b4e3/attachment.html>

From sean.harmer at kdab.com  Sat Apr 23 13:40:13 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 23 Apr 2016 12:40:13 +0100
Subject: [Development] CI failures
In-Reply-To: <9a54430d-81cf-4a3a-8e23-7db0dbd18e41@qt.io>
References: <571B550E.8010902@kdab.com> <571B5676.7050305@kdab.com>
	<DB4PR02MB054161D0A0F1667530FF92AA8C600@DB4PR02MB0541.eurprd02.prod.outlook.com>
	<9a54430d-81cf-4a3a-8e23-7db0dbd18e41@qt.io>
Message-ID: <571B5F1D.4090402@kdab.com>



On 23/04/2016 12:17, Simon Hausmann wrote:
> Hi,
>
> I have reverted the changes , I hope it works now.

Thanks, Simon. Will give it another go.

Sean

>
> Simon
>
>
>
> *From:* Simon Hausmann
> *Sent:* Apr 23, 2016 1:11 PM
> *To:* Sean Harmer; development at qt-project.org
> *Subject:* Re: [Development] CI failures
>
> Hi,
>
> Usually the CI system won't rebuild depending modules, but in this 
> case no builds exist of qtbase. That is because MinGW 5.3 was added to 
> the CI system - replacing MinGW 4.9 - maybe yesterday (I'm not sure 
> exactly when) and qtbase doesn't compile with it.
>
> I'll try to get access to a laptop and see if I can revert the changes.
>
>
> Simon
>
> ________________________________________
> From: Development 
> <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of 
> Sean Harmer <sean.harmer at kdab.com>
> Sent: Saturday, April 23, 2016 1:03 PM
> To: development at qt-project.org
> Subject: Re: [Development] CI failures
>
> An example of the failure is at:
>
> http://testresults.qt.io/logs/qt/qtbase/8586cccc071240a8eff6c5aa53a90010dae55193/WindowsWindows_7x86WindowsWindows_7x86Mingw53DebugAndRelease_Release_OpenGLDynamic/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz
>
> Specifically:
>
> qwindowsfontenginedirectwrite.cpp: In member function 'QImage 
> QWindowsFontEngineDirectWrite::imageForGlyph(glyph_t, QFixed, int, 
> const QTransform&)':
> qwindowsfontenginedirectwrite.cpp:581:22: error: 'DWRITE_E_NOCOLOR' 
> was not declared in this scope
>           HRESULT hr = DWRITE_E_NOCOLOR;
>
>
> Cheers,
>
> Sean
>
> On 23/04/2016 11:57, Sean Harmer wrote:
> > Hi,
> >
> > I've been trying to merge some changes to Qt 3D but have been getting
> > failures in qtbase since yesterday. Is there something wrong or am I
> > just being unlucky? I'm slightly confused as I thought the main
> > benefit of the new CI was that it didn't need to build dependent
> > modules or am I misunderstanding this?
> >
> > Cheers,
> >
> > Sean
> >
>
>
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> KDAB (UK) Ltd, a KDAB Group company
> Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
> Mobile: +44 (0)7545 140604
> KDAB - Qt Experts
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160423/ec82c86d/attachment.html>

From kevin.kofler at chello.at  Sat Apr 23 14:41:49 2016
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Sat, 23 Apr 2016 14:41:49 +0200
Subject: [Development] Qt-Project misrepresented on qt.io
References: <2482364.eDi5QLsHKE@finn> <1527234.Cibt1qTh8K@cartman>
	<VI1PR0201MB15367BD381F7ABF6BA110F2C8D6C0@VI1PR0201MB1536.eurprd02.prod.outlook.com>
Message-ID: <nffqid$b2u$2@ger.gmane.org>

Kojo Tero wrote:
> The other side of the coin is crowding the developer page with
> information. A page about contributing might be a solution, or then a
> rethink of the developer page.

For the mailing lists, you make a very clear distinction between development 
WITH Qt and development OF Qt. So why not also make them separate pages on 
your web site?

        Kevin Kofler



From Tom.Isaacson at navico.com  Sun Apr 24 23:12:20 2016
From: Tom.Isaacson at navico.com (Tom Isaacson)
Date: Sun, 24 Apr 2016 21:12:20 +0000
Subject: [Development] QMovie no longer supports .mng
Message-ID: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>

I've just upgraded from Qt 5.5.1 to 5.6 using Visual Studio 2013 for 32-bit on Windows 7 and I've found that QMovie fails to load .mng files. Calling QMovie::supportedFormats() just returns "gif". Previously this was working fine.

Is this an intentional change? How can I get round it?

Thanks,

Tom Isaacson



From Jake.Petroules at qt.io  Mon Apr 25 00:59:29 2016
From: Jake.Petroules at qt.io (Jake Petroules)
Date: Sun, 24 Apr 2016 22:59:29 +0000
Subject: [Development] QMovie no longer supports .mng
In-Reply-To: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
Message-ID: <31DFE00D-A2E8-4D2D-A50A-DCE16B1C692A@qt.io>

The MNG and JPEG2000 plugins are no longer built by default on most platforms because upstream development has stalled and there are known security vulnerabilities. See https://codereview.qt-project.org/#/c/141429/

You can still build them manually if you really want them. Perhaps you could help port the JPEG2000 plugin to https://github.com/uclouvain/openjpeg

On Apr 24, 2016, at 2:12 PM, Tom Isaacson <Tom.Isaacson at navico.com<mailto:Tom.Isaacson at navico.com>> wrote:

I've just upgraded from Qt 5.5.1 to 5.6 using Visual Studio 2013 for 32-bit on Windows 7 and I've found that QMovie fails to load .mng files. Calling QMovie::supportedFormats() just returns "gif". Previously this was working fine.

Is this an intentional change? How can I get round it?

Thanks,

Tom Isaacson

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

--
Jake Petroules - jake.petroules at theqtcompany.com<mailto:jake.petroules at theqtcompany.com>
Consulting Services Engineer - The Qt Company
Qbs build system evangelist - qbs.io<http://qbs.io>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160424/46587542/attachment.html>

From Simon.Hausmann at qt.io  Mon Apr 25 10:31:06 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Mon, 25 Apr 2016 08:31:06 +0000
Subject: [Development] [Announce] Qt 5.7.0 Beta released
In-Reply-To: <5718D0C5.4000705@rpzdesign.com>
References: <mailman.472.1461233173.4158.announce@qt-project.org>,
	<5718D0C5.4000705@rpzdesign.com>
Message-ID: <DB4PR02MB0541E411E9A5F759E0577F618C620@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,


Thank you for your feedback.


Could you please elaborate what kind of changes you'd like to see to the QQmlComponent API? It is not clear to me what you mean by "compiling loaded QML from a byte array".


Similarly, could you please explain what you mean within loading definitions into the component cache? Are you referring to the ability to populate the component cache on application start up?

Regarding the qmldir files I conceptually agree that it would be nice to get rid of them, but it is not an easy task and not a task that I think of being of high priority (unless somebody convinces me otherwise). However one thing I would like to see as an initial step in the same direction would be to generate the content of the files automatically from meta-information for example in the build system. Such a step would potentially allow for replacing these files with a superior mechanism.

Could you please explain what you mean by an array of plugin bytes?

I also don't see a tight coupling between the QML engine and the network access manager. What coupling are you referring to? Is it the ability to compile the engine when the network access manager is disabled from the build?

Regarding internationalization support: I invite you to contribute the work towards allowing different mechanisms for translations. It would probably make most sense if you could attend the Qt conference to discuss the topic in person.


Simon

________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of md at rpzdesign.com <md at rpzdesign.com>
Sent: Thursday, April 21, 2016 3:08 PM
To: development at qt-project.org
Subject: Re: [Development] [Announce] Qt 5.7.0 Beta released

Jani & Tuuka:

There is a reference to the upcoming Qt Quick Compiler in 5.8 in the 5.7 beta announcment.

http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/
Qt 5.7 Beta Released - Qt Blog<http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/>
blog.qt.io
Qt 5.7 Beta is now released and available for your feedback. There is a lot to review – new modules, leveraging C++11 features, and the new unified product ...




Where do we send input to the people in charge of making 5.8 design decisions?

Since it looks like this is going to a significant re-factor of the base code from 5.7, this is the moment to speak up.

I submit that there is a currently a dysfunctional design dependence between a 5.8 Qt Quick Compiler, the requirement of QMLDIR files for plugins,
the QR("") Internationalization pattern, and QQmlComponent C++ class.

The architecture is cumbersome if you have a project structure that deviates in any way from the classic QRC oriented resource files, you do a lot of work.

What I would like to see in 5.8 and beyond.

1)  QQmlComponent as the primary QML interface for C++ developers with the QtQuick Compiler optionally compiling loaded QML from a byte array and shipped to a customer in the form of downloadable Compiled QML!!!
2) QQmlComponent able to load definitions into the component cache to be used in qml "Import MyComponent 1.0"
3) Drop QMLDIR files entirely, they are really stupid.  They have no place in a dynamic loadable plugin/component architecture.
4) Allow plugins (either C++ or QML) to be loaded by C++ or QQmlComponent.LoadPlugin( array of plugin bytes!, not FILE or URL based!)
Right now I am forced to statically link my plugins into the executable for QML to see them and use them. Very clumsy.
5) Decouple the GUI/QML from NetworkResourceManager.  The NetworkResourceManager should be an optional component, not required for every project.
If you need to download QML using an URL, provide a bridge class to perform that.
6) International Support Decoupled (So I can use my own hooks instead of translation files in Qr(" ") usage pattern

I really think that if the architecture and cumulative design choices are reviewed, you can see a lot of legacy decisions that now can get factored out of the design
so there is cleanliness and a proper fit for the Qt Quick Compiler in relation to the other QML/C++ constructs.

Thanks for listening,

Marco










On 4/21/2016 4:06 AM, List for announcements regarding Qt releases and development wrote:

Hi all,


Qt 5.7.0 Beta is released today, see <http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/> http://blog.qt.io/blog/2016/04/21/qt-5-7-beta-released/


Big thanks for everyone involved!


br,

Jani


Jani Heikkinen
Release Manager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikkinen at qt.io<mailto:jani.heikkinen at qt.io>
http://qt.io<http://qt.io/>


[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]<http://qt.io/>
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]<http://www.facebook.com/Qt>     [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] <http://www.twitter.com/qtproject>       [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] <https://www.linkedin.com/company/the-qt-company/>      [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] <https://plus.google.com/104580575722059274792>       [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] <https://www.youtube.com/QtStudios>




_______________________________________________
Announce mailing list
Announce at qt-project.org<mailto:Announce at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/announce




_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160425/b794460c/attachment.html>

From tero.kojo at qt.io  Mon Apr 25 12:35:33 2016
From: tero.kojo at qt.io (Tero Kojo)
Date: Mon, 25 Apr 2016 10:35:33 +0000
Subject: [Development] QtCon call for papers
Message-ID: <DB5PR02MB0758202CB240DBBC7919DEDEF4620@DB5PR02MB0758.eurprd02.prod.outlook.com>

Hello,

The call for papers for QtCon is open at:
https://qtcon.org/cfp

For the Qt project, QtCon replaces Qt Contributors' Summit for 2016, so please consider submitting your ideas which you would normally present at Qt Contributors' Summit to QtCon.

Even though the term used is Call for Papers, all forms of sessions are welcome; talks, open discussions, workshops, whatever you come up with.
When submitting ideas, please remember to tag your idea as a Qt topic.

The deadline for submissions is 15.5, but we do appreciate if you can make your submissions earlier, as it would help the topic evaluation.

Best regards,
Tero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160425/4da595be/attachment.html>

From md at rpzdesign.com  Mon Apr 25 14:52:50 2016
From: md at rpzdesign.com (md at rpzdesign.com)
Date: Mon, 25 Apr 2016 06:52:50 -0600
Subject: [Development] [Announce] Qt 5.7.0 Beta released
In-Reply-To: <DB4PR02MB0541E411E9A5F759E0577F618C620@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <mailman.472.1461233173.4158.announce@qt-project.org>
	<5718D0C5.4000705@rpzdesign.com>
	<DB4PR02MB0541E411E9A5F759E0577F618C620@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <571E1322.5090908@rpzdesign.com>

On 4/25/2016 2:31 AM, Simon Hausmann wrote:
>
> Hi,
>
>
> Thank you for your feedback.
>
>
> Could you please elaborate what kind of changes you'd like to see to the QQmlComponent API? It is not clear to me what you mean by "compiling loaded QML from a byte array".
>
>
> Similarly, could you please explain what you mean within loading definitions into the component cache? Are you referring to the ability to populate the component cache on application start up?
>
> Regarding the qmldir files I conceptually agree that it would be nice to get rid of them, but it is not an easy task and not a task that I think of being of high priority (unless somebody convinces me otherwise). However one thing I would like to see as an initial step in the same direction would be to generate the content of the files automatically from meta-information for example in the build system. Such a step would potentially allow for replacing these files with a superior mechanism.
>
> Could you please explain what you mean by an array of plugin bytes?
>
> I also don't see a tight coupling between the QML engine and the network access manager. What coupling are you referring to? Is it the ability to compile the engine when the network access manager is disabled from the build?
>
> Regarding internationalization support: I invite you to contribute the work towards allowing different mechanisms for translations. It would probably make most sense if you could attend the Qt conference to discuss the topic in person.
>
>
> Simon
>

Simon:

I have a bunch of comments to offer.

Regarding QQmlComponent, The best answer I can give is to suggest different API calls:

QQmlComponent.setData( Array of Human Readable QML Bytes )
QQmlComponent.BindImportName("import name","version major","version minor") -> Binds an import Name
QQmlComponent.BindLibary("import name", compiled QQuickItem dynamic library) -> Binds an import Name  (NO MORE PLUGINS! IOS shared library issues here)

QQmlEngine->CheckForImportCollisions( "import name","version major","version minor",QQmlComponent& gcomp)
QQmlEngine->LoadComponentIntoCache( "import name",bla-bla, QQmlComponent& gcomp)
QQmlEngine->UnloadLoadComponentFromCache( "import name",bla-bla)

Possible optimizations:

QQmlComponent.CompiletoByteArray() -> Output an array of "Compiled QML" bytecode + dynamic (5.8 QML Compiler but NOT to C++ class files, to bytecode)
QQmlComponent.LoadCompiledByteArray() -> Load a previously Compiled QML bytecode into the Component

filename.QML -> normal human readable QML
filename.QMC -> compiled qml byte file

Also, I think the day is fast coming where Qt Creator is no longer viable, only the C++ code will have developer value.

Already, you cannot debug QML and C++ on Xcode for simulator/Device.  There are severe limitations and the support is tepid at best. Why fight that battle?

Android Studio 2.x series will have integrated C++ NDK debugging along with acclerated Java debugging.

Why be content with KDAB 7 episode Jedi Knight series for Android & QT?  Make the jump to concentrate QT/Android development inside Android Studio 2.+

Microsoft has its own tools and deprecated Visual Studio 2010/12/13 Plugin and QT is scrambling to try to support Visual Studio 2015 with some sort of plugin replacement.

My recommendation is that Qt Creator resources be reduced massively to only support the Yocto embedded targets on linux.  The rest of the platforms should seek to work with native tooling.

Also, the Meta Object compiler needs review because when you open the Qt project in XCode, the metaobjects are major human readable problems
yet Xcode is the only environment that can actually debug QT C++ code on Simulator and Device. Not Qt Creator.    The generated projects need to have much cleaner code.

Internationalization should be an open hook that the Qr(" ") is re-factored to tap into. Then anybody could tap into the hook with their own internationalization mechnanism.  I would like to build the base library without the network manager, but I think there are too many links to the network manager header file in GUI.

I would love to come to a conference, but I am just way too busy and have a baby on the way, the wife will NEVER let me go to Europe to talk like a geek for 4 days.  Every spare dollar
is for domestic operations.

Cheers,

md


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160425/bf7f6f15/attachment.html>

From alexander.blasche at qt.io  Mon Apr 25 15:34:10 2016
From: alexander.blasche at qt.io (Alexander Blasche)
Date: Mon, 25 Apr 2016 13:34:10 +0000
Subject: [Development] Nominating Volker Krause for Approver status
In-Reply-To: <2490211.ScAIPsqEX2@frederik-thinkcentre-m93p>
References: <1837438.BeO96xjKmG@titan>,
	<2490211.ScAIPsqEX2@frederik-thinkcentre-m93p>
Message-ID: <AM3PR02MB02780E91FAFD54EA973733F6E7620@AM3PR02MB0278.eurprd02.prod.outlook.com>

Hi,

Volker has acquired the OG approver rights. Congratulations.

--
Alex

________________________________________
From: Development <development-bounces+alexander.blasche=theqtcompany.com at qt-project.org> on behalf of Frederik Gladhorn <frederik.gladhorn at theqtcompany.com>
Sent: Thursday, 31 March 2016 13:08
To: development at qt-project.org
Subject: Re: [Development] Nominating Volker Krause for Approver status

On Wednesday, March 30, 2016 09:34:40 AM Sean Harmer wrote:
> Hi All,
>
> I'd like to nominate Volker Krause for approver status. Volker is one of the
> main authors of GammaRay, is very active in the Qt Automotive sphere where
> he leads up KDAB's contributions, and has touched many parts all over Qt
> (including Qt 3D).
>
> His dashboard is at:
>
> https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z
>
> and reviews at:
>
> https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z
>
> Can I get a +1 please?

+1 from me as well :)

Greetings,
Frederik

>
> Cheers,
>
> Sean
>
> Disclaimer: I work at KDAB with Volker.
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From kangjoni76 at gmail.com  Mon Apr 25 17:13:52 2016
From: kangjoni76 at gmail.com (kang joni)
Date: Mon, 25 Apr 2016 22:13:52 +0700
Subject: [Development] qtcreator 4rc crash while creating any c++ new file
	on windows7
Message-ID: <CAOmy0wKu8pJM99QWoBinbZu73sb4zCKGFLhv8UicC7FxHbZaAA@mail.gmail.com>

I had building lastest git pull from github repo qtcreator master
branch today and suffering from crash using msvc2015 update2 32bit
build on windows 7 while creating new any c++ file in wizard dialog. I
had included debug build stack trace picture describing the problem.
1. first create or open c++ project file.
2. create any new c++ file using Ctrl+n wizard dialog
3. fill any c++ class name in next wizard towards exiting project,
click next and bump the crash happen.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 75361 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160425/4f4d3293/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.png
Type: image/png
Size: 76793 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160425/4f4d3293/attachment-0001.png>

From sean.harmer at kdab.com  Mon Apr 25 21:03:24 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Mon, 25 Apr 2016 20:03:24 +0100
Subject: [Development] Qt3D CI wedged
Message-ID: <1814491.GdRDj4H0vG@titan>

Hi All,

is someone around who could kill the current Qt 3D CI integration please? It's 
been going since lunchtime today and appears to be stuck.

Thanks in advance,

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From marc.mutz at kdab.com  Tue Apr 26 09:14:49 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Tue, 26 Apr 2016 09:14:49 +0200
Subject: [Development] Qt3D CI wedged
In-Reply-To: <1814491.GdRDj4H0vG@titan>
References: <1814491.GdRDj4H0vG@titan>
Message-ID: <201604260914.49887.marc.mutz@kdab.com>

On Monday 25 April 2016 21:03:24 Sean Harmer wrote:
> Hi All,
> 
> is someone around who could kill the current Qt 3D CI integration please?
> It's been going since lunchtime today and appears to be stuck.

Same for QtBase integrations: running since 14:13 yesterday.

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From tony.sarajarvi at qt.io  Tue Apr 26 09:15:47 2016
From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=)
Date: Tue, 26 Apr 2016 07:15:47 +0000
Subject: [Development] Qt3D CI wedged
In-Reply-To: <201604260914.49887.marc.mutz@kdab.com>
References: <1814491.GdRDj4H0vG@titan> <201604260914.49887.marc.mutz@kdab.com>
Message-ID: <VI1PR02MB1119837CA1DA6DB4FA92F47592630@VI1PR02MB1119.eurprd02.prod.outlook.com>

Hi,

We ran out of disk space on the CI master. Problem has been fixed now and things are being restarted.

-Tony


> -----Original Message-----
> From: Development [mailto:development-
> bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Marc Mutz
> Sent: 26. huhtikuuta 2016 10:15
> To: development at qt-project.org
> Subject: Re: [Development] Qt3D CI wedged
> 
> On Monday 25 April 2016 21:03:24 Sean Harmer wrote:
> > Hi All,
> >
> > is someone around who could kill the current Qt 3D CI integration please?
> > It's been going since lunchtime today and appears to be stuck.
> 
> Same for QtBase integrations: running since 14:13 yesterday.
> 
> --
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From sean.harmer at kdab.com  Tue Apr 26 09:29:22 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 26 Apr 2016 08:29:22 +0100
Subject: [Development] Qt3D CI wedged
In-Reply-To: <VI1PR02MB1119837CA1DA6DB4FA92F47592630@VI1PR02MB1119.eurprd02.prod.outlook.com>
References: <1814491.GdRDj4H0vG@titan> <201604260914.49887.marc.mutz@kdab.com>
	<VI1PR02MB1119837CA1DA6DB4FA92F47592630@VI1PR02MB1119.eurprd02.prod.outlook.com>
Message-ID: <2096004.hoF43uR0KT@cartman>

On Tuesday 26 April 2016 07:15:47 Tony Sarajärvi wrote:
> Hi,
> 
> We ran out of disk space on the CI master. Problem has been fixed now and
> things are being restarted.

Thanks. Don't worry about re-staging the Qt 3D changes though, I found a 
problem with them after staging that I've since fixed. Just waiting to be able 
to push them once the CI is unblocked.

Sean
-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From eskil.abrahamsen-blomfeldt at qt.io  Tue Apr 26 09:53:57 2016
From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt)
Date: Tue, 26 Apr 2016 09:53:57 +0200
Subject: [Development] CI failures
In-Reply-To: <DB4PR02MB054161D0A0F1667530FF92AA8C600@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <571B550E.8010902@kdab.com> <571B5676.7050305@kdab.com>
	<DB4PR02MB054161D0A0F1667530FF92AA8C600@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <571F1E95.8070808@qt.io>



Den 23.04.2016 13:11, skrev Simon Hausmann:
> Hi,
>
> Usually the CI system won't rebuild depending modules, but in this case no builds exist of qtbase. That is because MinGW 5.3 was added to the CI system - replacing MinGW 4.9 - maybe yesterday (I'm not sure exactly when) and qtbase doesn't compile with it.
>
> I'll try to get access to a laptop and see if I can revert the changes.

Hi,

MinGW 5.3 apparently includes some of the Directwrite 2 APIs, but not 
all, so my configure test would pass, but then the actual code would 
fail to compile. Friedemann has a patch here which fixes it:

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

-- 
Eskil Abrahamsen Blomfeldt
Senior Manager, Qt Graphics/Multimedia

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfeldt at qt.io
http://qt.io



From oleg.shalnev at gmail.com  Tue Apr 26 10:54:15 2016
From: oleg.shalnev at gmail.com (Oleg Shalnev)
Date: Tue, 26 Apr 2016 11:54:15 +0300
Subject: [Development] Qt 5.6 QTcpSocket WindowsXp32 mingw32 strange
 behavior of connected signal. After so many years of using Qt.
Message-ID: <CAKTypNC_P9-RK5z9Zu+++4sOV=rPGyY+_UEOrBpQaB+79xrkdA@mail.gmail.com>

Hi all!
I have no idea what's the (hell) is going on.
The simplest test...


SocketTest::SocketTest()

{

  mSocket=new QTcpSocket(this);

  QObject::connect(mSocket, SIGNAL(hostFound()), this, SLOT(onHostFound()));

  QObject::connect(mSocket, SIGNAL(connected()), this, SLOT(onConnected()));

  QObject::connect(mSocket, SIGNAL(error(QAbstractSocket::SocketError)),

                   this, SLOT(onError(QAbstractSocket::SocketError)));

}


void SocketTest::start()

{

  mSocket->connectToHost(QHostAddress("1.1.1.1"), 2000);

}


void SocketTest::onHostFound()

{

  qDebug()<<"OnHostFound"<<mSocket->state();

}


void SocketTest::onConnected()

{

  qDebug()<<"OnConnected"<<mSocket->state();

}


void SocketTest::onError(QAbstractSocket::SocketError Error)

{

  qDebug()<<"OnError"<<Error;

}


And socket is connected!!!

The problem is that socket connected and signal emmited.

Only then after couple of seconds program received error "Remote host closed"


On Linux and Android all ok.


Qt 5.5 5.6, WindowsXP_32, mingw32




-- 
Oleg Shalnev  (Kalpa Knowledge Integration Initiative)
----------------------------------------------
mailto: oleg at kalpa.ru
skype:  oleg_shalnev
cell    :  +79111603306
cell    :  +79187417217
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160426/952d7154/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.cpp
Type: text/x-c++src
Size: 192 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160426/952d7154/attachment.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sockettest.cpp
Type: text/x-c++src
Size: 788 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160426/952d7154/attachment-0001.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sockettest.h
Type: text/x-chdr
Size: 370 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160426/952d7154/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: снимок11.png
Type: image/png
Size: 9849 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160426/952d7154/attachment.png>

From Shawn.Rutledge at qt.io  Tue Apr 26 14:08:12 2016
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Tue, 26 Apr 2016 12:08:12 +0000
Subject: [Development] Exception to source compatibility: adding
 AA_CompressHighFrequencyEvents flag
Message-ID: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>

In 5.6.0, an event compression feature was added to the xcb platform plugin, to fix QTBUG-40889 and QTBUG-47069.  That is here: https://codereview.qt-project.org/#/c/126136/  Qt 4 had a similar feature, and then it was possible to turn it on or off, using widget attribute WA_NoX11EventCompression.  Using a widget attribute doesn’t make sense now, because you might not be using widgets, and the platform plugin isn’t necessarily aware of them even if you are.  This time the compression was done with no way to turn it off, and QTBUG-44964 was written up as a task to come up with a way to enable/disable the compression.  If the application does not handle high-frequency events (mouse movements and window moves/resizes) quickly enough, some events will be dropped.  So, sufficiently responsive applications shouldn’t experience any event compression.

This causes some trouble for drawing-tablet applications like Krita though.  It’s not right to compress move events from tablet devices by default, because the application may be using some complex brush-painting algorithm, but nevertheless the artist using it expects to get smooth brush strokes, not jagged piecewise ones.  So maybe the XCB plugin simply shouldn’t compress those; but then we’d have a behavior change in 5.6.1 relative to 5.6.0, and anyway the decision to compress or not doesn’t pay attention to which device it’s coming from, so far.  It might be possible though.

Personally I think event compression should be a cross-platform feature if we’re going to have it.  The event-pileup problem can happen also on Windows for example, but it seems that we never implemented event compression on any platform other than X11.  I’m not sure why.  But we don’t plan to do that in the 5.6 series, anyway.

https://codereview.qt-project.org/#/c/156755 makes it possible to turn off the compression feature by setting an env variable; that works OK, but it’s meant as a short-term hack: we know that we need proper public API eventually.  The question is whether we should be adding API in a patch release like 5.6.1.  Of course this time it’s an LTS release, so it seems reasonable to expect long-term solutions to problems like this, rather than short-term hacks.  And it was brought up that env variables are inherited by child processes, so if for some reason your paint program starts child processes, you might need to unset the env variable first.  And as usual, env variables which affect behavior in platform plugins need to be set before the QGuiApplication is created, because the platform plugin reads it at static-initialization time, when it is loaded.

https://codereview.qt-project.org/#/c/157011 adds an application attribute, 
AA_CompressHighFrequencyEvents, which is true by default on X11, and you can unset it to disable the compression.  The advantage of doing it this way is that you can control it dynamically: maybe you want to have compression only some of the time, depending on what the application is doing with the events.  But it requires an exception to the source compatibility rule: if you have used that flag in your application, then you won’t be able to compile it with 5.6.0 anymore.  (You could ifdef it though.)  Of course forward compatibility shouldn’t be a problem.  And even if we implement compression as a cross-platform feature eventually, we can still use that flag to enable/disable it.

I was told to request this exception on the mailing list, because we usually try to maintain source compatibility between releases.

So, any objections?


From Morten.Sorvig at qt.io  Tue Apr 26 14:30:48 2016
From: Morten.Sorvig at qt.io (Morten Sorvig)
Date: Tue, 26 Apr 2016 12:30:48 +0000
Subject: [Development] Exception to source compatibility: adding
 AA_CompressHighFrequencyEvents flag
In-Reply-To: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
Message-ID: <9B82771E-7E8B-44FB-AD55-15E6668335A2@qt.io>


> On 26 Apr 2016, at 14:08, Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:
> 
> Personally I think event compression should be a cross-platform feature if we’re going to have it.  The event-pileup problem can happen also on Windows for example, but it seems that we never implemented event compression on any platform other than X11.  I’m not sure why.  But we don’t plan to do that in the 5.6 series, anyway.

For OS X: My first thought is that we should let the OS compress events for us. Which it does, at least for wheel events. Event compression in Qt can then be a feature for those platforms that need it (implemented in cross-platform code), but not mandatory.

Cheers,
Morten

From dangelog at gmail.com  Tue Apr 26 14:55:50 2016
From: dangelog at gmail.com (Giuseppe D'Angelo)
Date: Tue, 26 Apr 2016 13:55:50 +0100
Subject: [Development] Exception to source compatibility: adding
 AA_CompressHighFrequencyEvents flag
In-Reply-To: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
Message-ID: <CAPm+cvh4s6jbgHsi0BTdW4aTG+HnQtB4jgCF1WL56YEq1AHvfw@mail.gmail.com>

On Tue, Apr 26, 2016 at 1:08 PM, Shawn Rutledge <Shawn.Rutledge at qt.io> wrote:
>
>
> I was told to request this exception on the mailing list, because we usually try to maintain source compatibility between releases.
>
> So, any objections?

(Having been the one asking for bringing the matter up to the ML): an
exception in this case can be agreeable. (Note that however these
exceptions may have an impact in the "current" release branch too,
that is, suppose that 5.7 was already released, a 5.6->5.7 merge would
then break compatibility there too.)

-- 
Giuseppe D'Angelo


From Simon.Hausmann at qt.io  Tue Apr 26 14:56:47 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Tue, 26 Apr 2016 12:56:47 +0000
Subject: [Development] Exception to source compatibility: adding
 AA_CompressHighFrequencyEvents flag
In-Reply-To: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
Message-ID: <DB4PR02MB0541FCEB8AA7990D974D26FB8C630@DB4PR02MB0541.eurprd02.prod.outlook.com>

Hi,

The way you describe the problem sounds like it is specific to tablet events on X-Windows. In my opinion a solution to the problem applied to the 5.6 branch of Qt
should also be limited to tablet events on X-Windows. Wouldn't it therefore be easiest to simply not do tablet event compression on X-Windows without any changes to the API?

The day somebody really wants event compression for tablet events, we can consider introducing new API perhaps in a new minor release.

Simon

________________________________________
From: Development <development-bounces+simon.hausmann=qt.io at qt-project.org> on behalf of Shawn Rutledge <Shawn.Rutledge at qt.io>
Sent: Tuesday, April 26, 2016 2:08 PM
To: development at qt-project.org
Subject: [Development] Exception to source compatibility: adding AA_CompressHighFrequencyEvents flag

In 5.6.0, an event compression feature was added to the xcb platform plugin, to fix QTBUG-40889 and QTBUG-47069.  That is here: https://codereview.qt-project.org/#/c/126136/  Qt 4 had a similar feature, and then it was possible to turn it on or off, using widget attribute WA_NoX11EventCompression.  Using a widget attribute doesn’t make sense now, because you might not be using widgets, and the platform plugin isn’t necessarily aware of them even if you are.  This time the compression was done with no way to turn it off, and QTBUG-44964 was written up as a task to come up with a way to enable/disable the compression.  If the application does not handle high-frequency events (mouse movements and window moves/resizes) quickly enough, some events will be dropped.  So, sufficiently responsive applications shouldn’t experience any event compression.

This causes some trouble for drawing-tablet applications like Krita though.  It’s not right to compress move events from tablet devices by default, because the application may be using some complex brush-painting algorithm, but nevertheless the artist using it expects to get smooth brush strokes, not jagged piecewise ones.  So maybe the XCB plugin simply shouldn’t compress those; but then we’d have a behavior change in 5.6.1 relative to 5.6.0, and anyway the decision to compress or not doesn’t pay attention to which device it’s coming from, so far.  It might be possible though.

Personally I think event compression should be a cross-platform feature if we’re going to have it.  The event-pileup problem can happen also on Windows for example, but it seems that we never implemented event compression on any platform other than X11.  I’m not sure why.  But we don’t plan to do that in the 5.6 series, anyway.

https://codereview.qt-project.org/#/c/156755 makes it possible to turn off the compression feature by setting an env variable; that works OK, but it’s meant as a short-term hack: we know that we need proper public API eventually.  The question is whether we should be adding API in a patch release like 5.6.1.  Of course this time it’s an LTS release, so it seems reasonable to expect long-term solutions to problems like this, rather than short-term hacks.  And it was brought up that env variables are inherited by child processes, so if for some reason your paint program starts child processes, you might need to unset the env variable first.  And as usual, env variables which affect behavior in platform plugins need to be set before the QGuiApplication is created, because the platform plugin reads it at static-initialization time, when it is loaded.

https://codereview.qt-project.org/#/c/157011 adds an application attribute,
AA_CompressHighFrequencyEvents, which is true by default on X11, and you can unset it to disable the compression.  The advantage of doing it this way is that you can control it dynamically: maybe you want to have compression only some of the time, depending on what the application is doing with the events.  But it requires an exception to the source compatibility rule: if you have used that flag in your application, then you won’t be able to compile it with 5.6.0 anymore.  (You could ifdef it though.)  Of course forward compatibility shouldn’t be a problem.  And even if we implement compression as a cross-platform feature eventually, we can still use that flag to enable/disable it.

I was told to request this exception on the mailing list, because we usually try to maintain source compatibility between releases.

So, any objections?

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From mwoehlke.floss at gmail.com  Tue Apr 26 16:02:46 2016
From: mwoehlke.floss at gmail.com (Matthew Woehlke)
Date: Tue, 26 Apr 2016 10:02:46 -0400
Subject: [Development] Exception to source compatibility: adding
 AA_CompressHighFrequencyEvents flag
In-Reply-To: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
Message-ID: <nfnse6$6jg$1@ger.gmane.org>

On 2016-04-26 08:08, Shawn Rutledge wrote:
> If the application does not handle high-frequency events (mouse 
> movements and window moves/resizes) quickly enough, some events will 
> be dropped.

Do you really mean dropped? Or do you mean merged? There is a HUGE
difference...

Please don't EVER simply discard input events (at least, not without
being specifically asked to do so); that is a form of data loss.

> https://codereview.qt-project.org/#/c/157011 adds an application
> attribute, AA_CompressHighFrequencyEvents, which is true by default
> on X11, and you can unset it to disable the compression. The
> advantage of doing it this way is that you can control it
> dynamically: maybe you want to have compression only some of the
> time, depending on what the application is doing with the events. But
> it requires an exception to the source compatibility rule: if you
> have used that flag in your application, then you won’t be able to
> compile it with 5.6.0 anymore.

Since when does SC mean that code written for version Y must compile
against version X (X < Y)? Usually it's only the other way around... Or
do I not understand what would break, here? (Is the problem just that
code written against 5.6.1 would not compile with 5.7.0?)

-- 
Matthew



From thiago.macieira at intel.com  Tue Apr 26 17:24:54 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Apr 2016 08:24:54 -0700
Subject: [Development] Qt 5.6 QTcpSocket WindowsXp32 mingw32 strange
	behavior of connected signal. After so many years of using Qt.
In-Reply-To: <CAKTypNC_P9-RK5z9Zu+++4sOV=rPGyY+_UEOrBpQaB+79xrkdA@mail.gmail.com>
References: <CAKTypNC_P9-RK5z9Zu+++4sOV=rPGyY+_UEOrBpQaB+79xrkdA@mail.gmail.com>
Message-ID: <1923335.t86sNIuWxH@tjmaciei-mobl4>

On terça-feira, 26 de abril de 2016 11:54:15 PDT Oleg Shalnev wrote:
> And socket is connected!!!
> 
> The problem is that socket connected and signal emmited.
> 
> Only then after couple of seconds program received error "Remote host
> closed"
> 
> 
> On Linux and Android all ok.
> 
> 
> Qt 5.5 5.6, WindowsXP_32, mingw32


Are you sure it's not some service on your Windows machine that tries to do 
content filtering?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Tue Apr 26 17:28:05 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Apr 2016 08:28:05 -0700
Subject: [Development] Exception to source compatibility: adding
	AA_CompressHighFrequencyEvents flag
In-Reply-To: <nfnse6$6jg$1@ger.gmane.org>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
	<nfnse6$6jg$1@ger.gmane.org>
Message-ID: <2357090.PYLiSIVQup@tjmaciei-mobl4>

On terça-feira, 26 de abril de 2016 10:02:46 PDT Matthew Woehlke wrote:
> Since when does SC mean that code written for version Y must compile
> against version X (X < Y)? Usually it's only the other way around... Or
> do I not understand what would break, here? (Is the problem just that
> code written against 5.6.1 would not compile with 5.7.0?)

We offer bi-directional source and binary compatibility inside the same minor 
version. Code written for 5.x.y also compiles and runs on 5.x.z, whichever 
values of y and z are.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From suy at badopi.org  Tue Apr 26 22:04:15 2016
From: suy at badopi.org (Alejandro Exojo)
Date: Tue, 26 Apr 2016 22:04:15 +0200
Subject: [Development] Exception to source compatibility: adding
	AA_CompressHighFrequencyEvents flag
In-Reply-To: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
Message-ID: <201604262204.16051.suy@badopi.org>

El Tuesday 26 April 2016, Shawn Rutledge escribió:
> Personally I think event compression should be a cross-platform feature if
> we’re going to have it.  The event-pileup problem can happen also on
> Windows for example, but it seems that we never implemented event
> compression on any platform other than X11.  I’m not sure why.  But we
> don’t plan to do that in the 5.6 series, anyway.

Are you thinking in a generic event compression feature, not only for input 
events? For example, I emit a signal with a "last value" parameter with a 
queued connection (or I just post the event manually), and the receiver can 
discard previous values that it did not have time to process because it was 
slower than the sender. That's not an input event, but it happens through the 
event system anyway.

Now I would think of reimplementing QCoreApplication::notify, but there is the 
warning about Qt6 change, and there is no way to access the already posted 
events (that I know of). There are some reports asking for the feature, BTW:

https://bugreports.qt.io/browse/QTBUG-2688
https://bugreports.qt.io/browse/QTBUG-44293

I suppose if notify() was "soft deprecated" there is not that much 
time/interest in doing this?

> I was told to request this exception on the mailing list, because we
> usually try to maintain source compatibility between releases.

This change being added doesn't worry me much (I don't think it will set my 
computer on fire), so I'm not opposing to it (honestly!) but I don't think the 
issue is source compatibility. It's adding features on already released 
branches. There is a process to ensure that code released has gone through a 
testing procedure. Adding this is bypassing it, while other much innocent 
changes have to wait.

Let me point at some examples, for illustration purposes:

A one line change that fixes QPalette::resolve. It's an obvious fix, but it 
wasn't unit tested, and it changes behaviour, so who knows what might break:

https://codereview.qt-project.org/148552

A microoptimization that looks entirely safe to everyone, but it's not 
critical, so it wasn't committed to the stable branch:

https://codereview.qt-project.org/138746

A simple setter/getter/member addition to QIcon and one line addition to the 
OS X platform plugin to make the system tray icons look properly on Yosemite 
and newer. It's trivial, but it was new API, so it could not go in the stable 
branch:

https://codereview.qt-project.org/115120

Again, honestly, I don't have an axe to grind. Two of this issues affected me, 
but not a lot, and it's already solved, so no big deal now. I'm just a bit 
confused when I see this differences in interpretation of the rules, because I 
don't know what to expect and what not.

Thanks.

-- 
Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2
http://barnacity.net/ | http://disperso.net


From kevin.kofler at chello.at  Wed Apr 27 01:11:28 2016
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 27 Apr 2016 01:11:28 +0200
Subject: [Development] QMovie no longer supports .mng
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
	<31DFE00D-A2E8-4D2D-A50A-DCE16B1C692A@qt.io>
Message-ID: <nfosj1$svi$1@ger.gmane.org>

Jake Petroules wrote:
> The MNG and JPEG2000 plugins are no longer built by default on most
> platforms because upstream development has stalled and there are known
> security vulnerabilities. See
> https://codereview.qt-project.org/#/c/141429/

For libmng, you bundle the ancient version 1.0.10 from 2009 (!). The current 
version is 2.0.3 from 2015:
https://sourceforge.net/projects/libmng/files/libmng-devel/
Despite the new major version number, qt5-qtimageformats compiles with no 
changes against that version.

For JPEG2000:

> You can still build them manually if you really want them. Perhaps you
> could help port the JPEG2000 plugin to
> https://github.com/uclouvain/openjpeg

That would be an option. But I would start by just getting the Jasper 
security fixes from a GNU/Linux distribution (e.g.:
http://pkgs.fedoraproject.org/cgit/rpms/jasper.git/tree/
) and applying them to your bundled copy.

        Kevin Kofler



From kevin.kofler at chello.at  Wed Apr 27 01:16:41 2016
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 27 Apr 2016 01:16:41 +0200
Subject: [Development] QMovie no longer supports .mng
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
	<31DFE00D-A2E8-4D2D-A50A-DCE16B1C692A@qt.io>
	<nfosj1$svi$1@ger.gmane.org>
Message-ID: <nfossp$svi$2@ger.gmane.org>

I wrote:
> For libmng, you bundle the ancient version 1.0.10 from 2009 (!).

Sorry, from 2007, even!

        Kevin Kofler



From thiago.macieira at intel.com  Wed Apr 27 01:31:18 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Apr 2016 16:31:18 -0700
Subject: [Development] QMovie no longer supports .mng
In-Reply-To: <nfosj1$svi$1@ger.gmane.org>
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
	<31DFE00D-A2E8-4D2D-A50A-DCE16B1C692A@qt.io>
	<nfosj1$svi$1@ger.gmane.org>
Message-ID: <1713978.axZZ0pXZNY@tjmaciei-mobl4>

On quarta-feira, 27 de abril de 2016 01:11:28 PDT Kevin Kofler wrote:
> Jake Petroules wrote:
> > The MNG and JPEG2000 plugins are no longer built by default on most
> > platforms because upstream development has stalled and there are known
> > security vulnerabilities. See
> > https://codereview.qt-project.org/#/c/141429/
> 
> For libmng, you bundle the ancient version 1.0.10 from 2009 (!). The current
> version is 2.0.3 from 2015:
> https://sourceforge.net/projects/libmng/files/libmng-devel/
> Despite the new major version number, qt5-qtimageformats compiles with no
> changes against that version.

Nice!

I wonder why the bundled copies are still present. The commit that disabled 
them was "Build MNG and Jpeg2000 plugins only if system libs found".

Deletion in https://codereview.qt-project.org/157156.

> For JPEG2000:
> > You can still build them manually if you really want them. Perhaps you
> > could help port the JPEG2000 plugin to
> > https://github.com/uclouvain/openjpeg
> 
> That would be an option. But I would start by just getting the Jasper
> security fixes from a GNU/Linux distribution (e.g.:
> http://pkgs.fedoraproject.org/cgit/rpms/jasper.git/tree/
> ) and applying them to your bundled copy.

Sorry, just deleting. That makes downloading and maintaining such a library 
SEP.

https://en.wikipedia.org/wiki/SEP_field

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



From kevin.kofler at chello.at  Wed Apr 27 01:39:38 2016
From: kevin.kofler at chello.at (Kevin Kofler)
Date: Wed, 27 Apr 2016 01:39:38 +0200
Subject: [Development] QMovie no longer supports .mng
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
	<31DFE00D-A2E8-4D2D-A50A-DCE16B1C692A@qt.io>
	<nfosj1$svi$1@ger.gmane.org> <1713978.axZZ0pXZNY@tjmaciei-mobl4>
Message-ID: <nfou7q$ck1$2@ger.gmane.org>

Thiago Macieira wrote:
> Sorry, just deleting. That makes downloading and maintaining such a
> library SEP.

As a distribution packager, I think that's a good plan. :-) The people on 
proprietary operating systems seem less happy about that, as evidenced by 
this thread. But that's not MY problem… ;-)

        Kevin Kofler



From thiago.macieira at intel.com  Wed Apr 27 01:47:40 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Apr 2016 16:47:40 -0700
Subject: [Development] QMovie no longer supports .mng
In-Reply-To: <nfou7q$ck1$2@ger.gmane.org>
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
	<1713978.axZZ0pXZNY@tjmaciei-mobl4> <nfou7q$ck1$2@ger.gmane.org>
Message-ID: <2757972.bbWl2Dp4Qs@tjmaciei-mobl4>

On quarta-feira, 27 de abril de 2016 01:39:38 PDT Kevin Kofler wrote:
> Thiago Macieira wrote:
> > Sorry, just deleting. That makes downloading and maintaining such a
> > library SEP.
> 
> As a distribution packager, I think that's a good plan. :-) The people on
> proprietary operating systems seem less happy about that, as evidenced by
> this thread. But that's not MY problem… ;-)

Indeed.

If we want the binaries to include the builds, we could include the DLLs for 
those libraries too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From perezmeyer at gmail.com  Wed Apr 27 01:51:30 2016
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Tue, 26 Apr 2016 20:51:30 -0300
Subject: [Development] Exception to source compatibility: adding
	AA_CompressHighFrequencyEvents flag
In-Reply-To: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
Message-ID: <6388222.PExiJNJCEp@luna>

Please correct me if I'm wrong: the feature which will break API was added in 
5.6.0, and we can say that most of the people out there are not using it.

Ideally API/ABI should not be broken without a SONAME change. If I had some 
Qt5 app using it already I would be forced to do a hack in our packaging: 
faking a SONAME change.

Now it just happens that we in Debian haven't pushed 5.6 to unstable yet (we 
are waiting for 5.6.1) so it's not a problem for us now. It will be if pushed 
with 5.6.2 instead of 5.6.1.

Of course I'm only speaking for us Debian, I don't know the impact on other 
distros.

-- 
Wiki participants are, by nature, a pedantic, ornery, and unreasonable bunch.
So there's a camaraderie here we seldom see outside of our professional
contacts.
  http://www.c2.com/cgi/wiki?WhyWikiWorks

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160426/51a7d01d/attachment.sig>

From thiago.macieira at intel.com  Wed Apr 27 02:09:14 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Tue, 26 Apr 2016 17:09:14 -0700
Subject: [Development] Exception to source compatibility: adding
	AA_CompressHighFrequencyEvents flag
In-Reply-To: <6388222.PExiJNJCEp@luna>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
	<6388222.PExiJNJCEp@luna>
Message-ID: <1904685.zXTP8L2qid@tjmaciei-mobl4>

On terça-feira, 26 de abril de 2016 20:51:30 PDT Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Please correct me if I'm wrong: the feature which will break API was added
> in 5.6.0, and we can say that most of the people out there are not using
> it.

No ABI breakage happened. There's a change in behaviour that most applications 
will want, but some don't. We're trying to figure out a way to allow those 
exceptions to revert to the old behaviour.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Jake.Petroules at qt.io  Wed Apr 27 04:10:09 2016
From: Jake.Petroules at qt.io (Jake Petroules)
Date: Wed, 27 Apr 2016 02:10:09 +0000
Subject: [Development] QMovie no longer supports .mng
In-Reply-To: <2757972.bbWl2Dp4Qs@tjmaciei-mobl4>
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
	<1713978.axZZ0pXZNY@tjmaciei-mobl4> <nfou7q$ck1$2@ger.gmane.org>
	<2757972.bbWl2Dp4Qs@tjmaciei-mobl4>
Message-ID: <2170C141-3166-44CC-A9ED-7AFE05342093@qt.io>

If we can simply update libmng and recompile against the new version then we should do so immediately!

On Apr 26, 2016, at 4:47 PM, Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> wrote:

On quarta-feira, 27 de abril de 2016 01:39:38 PDT Kevin Kofler wrote:
Thiago Macieira wrote:
Sorry, just deleting. That makes downloading and maintaining such a
library SEP.

As a distribution packager, I think that's a good plan. :-) The people on
proprietary operating systems seem less happy about that, as evidenced by
this thread. But that's not MY problem… ;-)

Indeed.

If we want the binaries to include the builds, we could include the DLLs for
those libraries too.

--
Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com>
 Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

--
Jake Petroules - jake.petroules at theqtcompany.com<mailto:jake.petroules at theqtcompany.com>
Consulting Services Engineer - The Qt Company
Qbs build system evangelist - qbs.io<http://qbs.io>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160427/d41837ff/attachment.html>

From perezmeyer at gmail.com  Wed Apr 27 04:40:34 2016
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Tue, 26 Apr 2016 23:40:34 -0300
Subject: [Development] cmath, abs(), qt5 and gcc6
Message-ID: <2233428.0B3OmRH3oh@luna>

Suppose this simple code:

#include <QPointF>
#include <cmath>

void Foo::bar() {

  QPointF refPos, newPos;

  /// They get some values.

  if( abs(refPos.x()-newPos.x()) > abs(refPos.y()-newPos.y()) ) {
    // Do something.
  }
}


With gcc6 I will get:

error: call of overloaded ‘abs(qreal)’ is ambiguous
             if( abs(refPos.x()-newPos.x()) > abs(refPos.y()-newPos.y()) ) {
                                          ^
In file included from /usr/include/c++/6/cstdlib:75:0,
                 from /usr/include/c++/6/bits/stl_algo.h:59,
                 from /usr/include/c++/6/algorithm:62,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:85,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qnamespace.h:37,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs.h:41,
                 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:40,
                 from /usr/include/x86_64-linux-gnu/qt5/QtGui/qclipboard.h:37,
                 from /usr/include/x86_64-linux-gnu/qt5/QtGui/QClipboard:1,
                 from /home/lisandro/damian/debian/propios/caneda/upstream/src/cgraphicsscene.cpp:21:
/usr/include/stdlib.h:774:12: note: candidate: int abs(int)
 extern int abs (int __x) __THROW __attribute__ ((__const__)) __wur;
            ^~~
Yes, the example code might be too simplistic, but I think it's enough to get
the idea.

I know I can easily solve this by replacing cmath's abs with QGlobal's qAbs(),
but I wonder if this is a bug in gcc6, in my code or Qt.

It might be worth to note that, according to
https://gcc.gnu.org/gcc-6/porting_to.html#math.h

  Header <math.h> changes

  The C++ library now provides its own <math.h> header that wraps the C
  library header of the same name. The C++ header defines additional overloads
  of some functions and ensures that all standard functions are defined as
  real functions and not as macros. Code which assumes that sin, cos, pow,
  isfinite etc. are macros may no longer compile.

Any hints?

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160426/1e646b38/attachment.sig>

From perezmeyer at gmail.com  Wed Apr 27 04:49:44 2016
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Tue, 26 Apr 2016 23:49:44 -0300
Subject: [Development] cmath, abs(), qt5 and gcc6
In-Reply-To: <2233428.0B3OmRH3oh@luna>
References: <2233428.0B3OmRH3oh@luna>
Message-ID: <4544708.fZV6tOQGut@luna>

pebcak, by using cmath code should be using the std namespace.

Sorry for the noise.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160426/61ca6f74/attachment.sig>

From Maurice.Kalinowski at qt.io  Wed Apr 27 06:14:12 2016
From: Maurice.Kalinowski at qt.io (Maurice Kalinowski)
Date: Wed, 27 Apr 2016 04:14:12 +0000
Subject: [Development] QMovie no longer supports .mng
In-Reply-To: <2757972.bbWl2Dp4Qs@tjmaciei-mobl4>
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
	<1713978.axZZ0pXZNY@tjmaciei-mobl4> <nfou7q$ck1$2@ger.gmane.org>
	<2757972.bbWl2Dp4Qs@tjmaciei-mobl4>
Message-ID: <DB4PR02MB17656E49A9A1FB390D01D6F95640@DB4PR02MB176.eurprd02.prod.outlook.com>

> > As a distribution packager, I think that's a good plan. :-) The people 
> > on proprietary operating systems seem less happy about that, as 
> > evidenced by this thread. But that's not MY problem… ;-)
>
> Indeed.
>
> If we want the binaries to include the builds, we could include the DLLs for those libraries too.

For all supported windows platforms? While we shrank the amount of Qt pre-built packages, there is still a larger amount of platforms/configurations we support and ask users to build from source. Stripping that away might be complicated.

Maurice 


From boud at valdyas.org  Wed Apr 27 08:50:48 2016
From: boud at valdyas.org (Boudewijn Rempt)
Date: Wed, 27 Apr 2016 08:50:48 +0200 (CEST)
Subject: [Development] Exception to source compatibility: adding
 AA_CompressHighFrequencyEvents flag
In-Reply-To: <6388222.PExiJNJCEp@luna>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
	<6388222.PExiJNJCEp@luna>
Message-ID: <alpine.LNX.2.00.1604270848050.29597@calcifer.valdyas.org>

On Tue, 26 Apr 2016, Lisandro Damián Nicanor Pérez Meyer wrote:

> Please correct me if I'm wrong: the feature which will break API was added in
> 5.6.0, and we can say that most of the people out there are not using it.
>
> Ideally API/ABI should not be broken without a SONAME change. If I had some
> Qt5 app using it already I would be forced to do a hack in our packaging:
> faking a SONAME change.
>
> Now it just happens that we in Debian haven't pushed 5.6 to unstable yet (we
> are waiting for 5.6.1) so it's not a problem for us now. It will be if pushed
> with 5.6.2 instead of 5.6.1.
>
> Of course I'm only speaking for us Debian, I don't know the impact on other
> distros.

As a Debian developer, you might also consider that you should never
ever package Krita 3 for Debian with a Qt 5.6 without this fix. You'd have
to carry the patch for Qt 5.6 or forego packaging Krita (and later on,
OpenToonz).

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

From jani.heikkinen at qt.io  Wed Apr 27 08:52:56 2016
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 27 Apr 2016 06:52:56 +0000
Subject: [Development] Heads up - 5.7 soft string freeze
Message-ID: <AM3PR02MB1186E808EAD9FACC339E53B69D640@AM3PR02MB1186.eurprd02.prod.outlook.com>

Hi all,


Qt 5.7 beta is out & work towards final release continues. One step on the way is String Freeze which is planned to happen 7th May 2016, see https://wiki.qt.io/Qt-5.7-release. So it is time to start keeping the translatable strings as it is and fix remaining important issues.



Br,

Jani



Jani Heikkinen
Release Manager

The Qt Company
Elektroniikkatie 13
90590 Oulu Finland
jani.heikkinen at qt.io
+358 50 4873735
http://qt.io<http://qt.io/>


[http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png]<http://qt.io/>
[http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png]<http://www.facebook.com/Qt>     [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] <http://www.twitter.com/qtproject>       [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] <https://www.linkedin.com/company/the-qt-company/>      [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] <https://plus.google.com/104580575722059274792>       [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] <https://www.youtube.com/QtStudios>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160427/88bd18c7/attachment.html>

From denis.shienkov at gmail.com  Wed Apr 27 11:37:26 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Wed, 27 Apr 2016 12:37:26 +0300
Subject: [Development] QtMultimedia && QML - hard performance regressions on
	Windows
Message-ID: <CAHtcb0zW7mc6fKZaJ+chyOYOmJwv+QBHg3vASemBDRmN-4VaJg@mail.gmail.com>

Hi developers.

I faced with a big problem with the video playback performance, when I try
to open the mp4 video file from any of QML video examples. I have a high
CPU loading (~40%) and the video is freezing and jerks. But the C++ media
player works satisfactory, more or less tolerably (on point 3 from the 1-5
points)...

It is impossible to use at all in QML, I face more and more with the
surprises of QtMultimedia, and disappointed more and more...

WTF ? What sense in QtMultimedia if it does not work as expected?

PS: I have created a bug: https://bugreports.qt.io/browse/QTBUG-53019

BR,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160427/b446b5ef/attachment.html>

From massimocallegari at yahoo.it  Wed Apr 27 12:28:01 2016
From: massimocallegari at yahoo.it (Massimo Callegari)
Date: Wed, 27 Apr 2016 10:28:01 +0000 (UTC)
Subject: [Development] QtMultimedia && QML - hard performance
 regressions on	Windows
In-Reply-To: <CAHtcb0zW7mc6fKZaJ+chyOYOmJwv+QBHg3vASemBDRmN-4VaJg@mail.gmail.com>
References: <CAHtcb0zW7mc6fKZaJ+chyOYOmJwv+QBHg3vASemBDRmN-4VaJg@mail.gmail.com>
Message-ID: <1191736113.4807591.1461752881167.JavaMail.yahoo@mail.yahoo.com>

Hey Denis, welcome to the "QtMultimedia lovers" club :)

Good luck with your remarks, most likely nobody will care. 
It seems that the primary role of QtMultimedia is to capture input video. All the rest doesn't matter.

I've opened a number of tickets and none of them have been solved:
https://bugreports.qt.io/browse/QTBUG-37004  (Feb 2014)
https://bugreports.qt.io/browse/QTBUG-37005  (Feb 2014)
https://bugreports.qt.io/browse/QTBUG-37882  (Mar 2014)
https://bugreports.qt.io/browse/QTBUG-42034  (Oct 2014)
https://bugreports.qt.io/browse/QTBUG-47284  (Jul 2015)

3 on 5 marked as P2.

I would also add a recent discovery of how non-cross platform QtMultimedia is.
The use case is starting a video in fullscreen on a second monitor (QtWidget way).
In Linux and OSX you have to do
m_videoWidget->setGeometry(rect);
m_videoWidget->setFullScreen(true);and on Windows
m_videoWidget->setFullScreen(true);
m_videoWidget->setGeometry(rect);

I didn't even open a ticket for that, cause I got tired to waste my time on this topic.


________________________________
Da: Denis Shienkov <denis.shienkov at gmail.com>
A: "development at qt-project.org" <development at qt-project.org> 
Inviato: Mercoledì 27 Aprile 2016 11:37
Oggetto: [Development] QtMultimedia && QML - hard performance regressions on    Windows



Hi developers.

I faced with a big problem with the video playback performance, when I 
try to open the mp4 video file from any of QML video examples. I have a high CPU loading (~40%) and the video is freezing and jerks. But the C++ media player works satisfactory, more or less tolerably (on point 3 from the 1-5 points)...

It is impossible to use at all in QML, I face more and more with the surprises of QtMultimedia, and disappointed more and more...  

WTF ? What sense in QtMultimedia if it does not work as expected?

PS: I have created a bug: https://bugreports.qt.io/browse/QTBUG-53019

BR,
Denis


_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


From sergio.martins at kdab.com  Wed Apr 27 13:10:17 2016
From: sergio.martins at kdab.com (Sergio Martins)
Date: Wed, 27 Apr 2016 12:10:17 +0100
Subject: [Development] QtMultimedia && QML - hard performance
	regressions on Windows
In-Reply-To: <CAHtcb0zW7mc6fKZaJ+chyOYOmJwv+QBHg3vASemBDRmN-4VaJg@mail.gmail.com>
References: <CAHtcb0zW7mc6fKZaJ+chyOYOmJwv+QBHg3vASemBDRmN-4VaJg@mail.gmail.com>
Message-ID: <5632730.Wopt07jdYB@desktop>

On Wednesday, 27 April 2016 12:37:26 WEST Denis Shienkov wrote:
> Hi developers.
> 
> I faced with a big problem with the video playback performance, when I try
> to open the mp4 video file from any of QML video examples. I have a high
> CPU loading (~40%) and the video is freezing and jerks. But the C++ media
> player works satisfactory, more or less tolerably (on point 3 from the 1-5
> points)...

I've seen something similar and solved it by changing codecs (installed k-lite 
codec pack)


Regards,
-- 
Sérgio Martins | sergio.martins at 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 Experts


From denis.shienkov at gmail.com  Wed Apr 27 14:17:49 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Wed, 27 Apr 2016 15:17:49 +0300
Subject: [Development] QtMultimedia && QML - hard performance
 regressions on Windows
In-Reply-To: <5632730.Wopt07jdYB@desktop>
References: <CAHtcb0zW7mc6fKZaJ+chyOYOmJwv+QBHg3vASemBDRmN-4VaJg@mail.gmail.com>
	<5632730.Wopt07jdYB@desktop>
Message-ID: <CAHtcb0yOzyzcikuSJJX96-qLUoFy1112WoMpy9r7pZiir+PW-g@mail.gmail.com>

> I've seen something similar and solved it by changing codecs (installed
k-lite
codec pack)

I have the K-Lite codec pack already installed (I'm sorry, if I haven't
mentioned it).

BR,
Denis

2016-04-27 14:10 GMT+03:00 Sergio Martins <sergio.martins at kdab.com>:

> On Wednesday, 27 April 2016 12:37:26 WEST Denis Shienkov wrote:
> > Hi developers.
> >
> > I faced with a big problem with the video playback performance, when I
> try
> > to open the mp4 video file from any of QML video examples. I have a high
> > CPU loading (~40%) and the video is freezing and jerks. But the C++ media
> > player works satisfactory, more or less tolerably (on point 3 from the
> 1-5
> > points)...
>
> I've seen something similar and solved it by changing codecs (installed
> k-lite
> codec pack)
>
>
> Regards,
> --
> Sérgio Martins | sergio.martins at 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 Experts
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160427/1fcdb5cb/attachment.html>

From mitch.curtis at qt.io  Wed Apr 27 14:56:54 2016
From: mitch.curtis at qt.io (Mitch Curtis)
Date: Wed, 27 Apr 2016 12:56:54 +0000
Subject: [Development] QtMultimedia && QML - hard performance
 regressions on	Windows
In-Reply-To: <1191736113.4807591.1461752881167.JavaMail.yahoo@mail.yahoo.com>
References: <CAHtcb0zW7mc6fKZaJ+chyOYOmJwv+QBHg3vASemBDRmN-4VaJg@mail.gmail.com>
	<1191736113.4807591.1461752881167.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <VI1PR02MB145439FA477BB6C9B97BC27288640@VI1PR02MB1454.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of Massimo Callegari via Development
> Sent: Wednesday, 27 April 2016 12:28 PM
> To: Denis Shienkov <denis.shienkov at gmail.com>; development at qt-project.org
> Subject: Re: [Development] QtMultimedia && QML - hard performance
> regressions on Windows
> 
> Hey Denis, welcome to the "QtMultimedia lovers" club :)
> 
> Good luck with your remarks, most likely nobody will care.
> It seems that the primary role of QtMultimedia is to capture input video.
> All the rest doesn't matter.
> 
> I've opened a number of tickets and none of them have been solved:
> https://bugreports.qt.io/browse/QTBUG-37004  (Feb 2014)
> https://bugreports.qt.io/browse/QTBUG-37005  (Feb 2014)
> https://bugreports.qt.io/browse/QTBUG-37882  (Mar 2014)
> https://bugreports.qt.io/browse/QTBUG-42034  (Oct 2014)
> https://bugreports.qt.io/browse/QTBUG-47284  (Jul 2015)
> 
> 3 on 5 marked as P2.
> 
> I would also add a recent discovery of how non-cross platform QtMultimedia
> is.
> The use case is starting a video in fullscreen on a second monitor
> (QtWidget way).
> In Linux and OSX you have to do
> m_videoWidget->setGeometry(rect);
> m_videoWidget->setFullScreen(true);and on Windows m_videoWidget-
> >setFullScreen(true);
> m_videoWidget->setGeometry(rect);
> 
> I didn't even open a ticket for that, cause I got tired to waste my time
> on this topic.

I didn't look at the other bugs, but QTBUG-37004 seems like it would pretty easy to contribute a fix yourself. Why waste your time and energy being outraged when you could be fixing it? Seems like a far more effective way of getting things fixed in an open source project. As said in the bug report, higher priority issues are being worked on.

> 
> ________________________________
> Da: Denis Shienkov <denis.shienkov at gmail.com>
> A: "development at qt-project.org" <development at qt-project.org>
> Inviato: Mercoledì 27 Aprile 2016 11:37
> Oggetto: [Development] QtMultimedia && QML - hard performance regressions
> on    Windows
> 
> 
> 
> Hi developers.
> 
> I faced with a big problem with the video playback performance, when I
> try to open the mp4 video file from any of QML video examples. I have a
> high CPU loading (~40%) and the video is freezing and jerks. But the C++
> media player works satisfactory, more or less tolerably (on point 3 from
> the 1-5 points)...
> 
> It is impossible to use at all in QML, I face more and more with the
> surprises of QtMultimedia, and disappointed more and more...
> 
> WTF ? What sense in QtMultimedia if it does not work as expected?
> 
> PS: I have created a bug: https://bugreports.qt.io/browse/QTBUG-53019
> 
> BR,
> Denis
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

From massimocallegari at yahoo.it  Wed Apr 27 15:44:44 2016
From: massimocallegari at yahoo.it (Massimo Callegari)
Date: Wed, 27 Apr 2016 13:44:44 +0000 (UTC)
Subject: [Development] QtMultimedia && QML - hard performance
 regressions on	Windows
In-Reply-To: <VI1PR02MB145439FA477BB6C9B97BC27288640@VI1PR02MB1454.eurprd02.prod.outlook.com>
References: <VI1PR02MB145439FA477BB6C9B97BC27288640@VI1PR02MB1454.eurprd02.prod.outlook.com>
Message-ID: <1096311274.5197761.1461764684824.JavaMail.yahoo@mail.yahoo.com>


________________________________
Da: Mitch Curtis <mitch.curtis at qt.io>
A: Massimo Callegari <massimocallegari at yahoo.it>; "development at qt-project.org" <development at qt-project.org> 
Inviato: Mercoledì 27 Aprile 2016 14:56
Oggetto: RE: [Development] QtMultimedia && QML - hard performance regressions on    Windows



>I didn't look at the other bugs, but QTBUG-37004 seems like it would pretty easy to contribute a fix yourself. 

I don't believe it is pretty easy, especially on Linux. 
OSX already returns a user friendly list of devices.
Windows cuts the devices names to 31 characters, cause it use APIs coming directly from the 90s.
Linux is the worst case instead, cause every possible ALSA device is returned, so if you have 2 sound cards it will return like 20 devices, most of which don't even work.
I believe users expect to see a list like what KDE/Gnome expose, so 4-5 devices total.
Plus I should be looking at the pulseaudio implementation as well, which I know nothing about.
In any case, it would require an internal change of the logic, most likely breaking backward compatibility, which is not something that I can decide.

> Why waste your time and energy being outraged when you could be fixing it? Seems like a far more effective way of getting things fixed in an open source project. 

Well, I believe reporting an issue is already a contribution to fixing it and while a "pretty easy" issue would take me 1 hour to be fixed, the overall effort to get it approved would be 100 hours. I already went through the process for a QtSerialPort method, and it was a hell of a journey. Especially working with Gerrit. Please excuse my limited GIT knowledge :(

> As said in the bug report, higher priority issues are being worked on.

Which one ?
And also...since 1-2 years ? Right...


I would rather appreciate much more if the Qt Company could start a sort of "bounty program", where users can place a few bucks for the resolution of specific issues.
There are more and more examples of this mechanism, like Kickstarter, Bountysource or even Stackoverflow.
I would be happy to participate to it for the most urgent issues affecting my projects.
I'm pretty sure there are a lot of open source projects raising donations, and small companies willing to spend some money on issues that are a priority for them.

Instead, it seems to me (and it's purely my mere assumption) that big bucks come from big companies and they have the full attention of the Qt developments.
Attention that don't go to all the rest of minor developers/projects/companies that are actually the largest user base of the Qt libraries.
If this is really the truth, it is pretty sad. Again, just my opinion.

> 
> ________________________________
> Da: Denis Shienkov <denis.shienkov at gmail.com>
> A: "development at qt-project.org" <development at qt-project.org>
> Inviato: Mercoledì 27 Aprile 2016 11:37
> Oggetto: [Development] QtMultimedia && QML - hard performance regressions
> on    Windows
> 
> 
> 
> Hi developers.
> 
> I faced with a big problem with the video playback performance, when I
> try to open the mp4 video file from any of QML video examples. I have a
> high CPU loading (~40%) and the video is freezing and jerks. But the C++
> media player works satisfactory, more or less tolerably (on point 3 from
> the 1-5 points)...
> 
> It is impossible to use at all in QML, I face more and more with the
> surprises of QtMultimedia, and disappointed more and more...
> 
> WTF ? What sense in QtMultimedia if it does not work as expected?
> 
> PS: I have created a bug: https://bugreports.qt.io/browse/QTBUG-53019
> 
> BR,
> Denis
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


From perezmeyer at gmail.com  Wed Apr 27 18:50:49 2016
From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer)
Date: Wed, 27 Apr 2016 13:50:49 -0300
Subject: [Development] Exception to source compatibility: adding
	AA_CompressHighFrequencyEvents flag
In-Reply-To: <alpine.LNX.2.00.1604270848050.29597@calcifer.valdyas.org>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
	<6388222.PExiJNJCEp@luna>
	<alpine.LNX.2.00.1604270848050.29597@calcifer.valdyas.org>
Message-ID: <2909350.m4g5lj7Q7E@tonks>

On Wednesday 27 April 2016 08:50:48 Boudewijn Rempt wrote:
[snip]
> As a Debian developer, you might also consider that you should never
> ever package Krita 3 for Debian with a Qt 5.6 without this fix. You'd have
> to carry the patch for Qt 5.6 or forego packaging Krita (and later on,
> OpenToonz).

The only Qt patches we accept are the ones ACKed by upstream (ie, someone from 
the Qt project) or the ones that are really debian-specific. Projects using Qt 
should use whatever the official Qt releases ship.

So backporting a merged fix is OK, but a patch to alter standard Qt behavior 
not yet accepted is not ok.


-- 
Geek Inside!

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160427/69682618/attachment.sig>

From thiago.macieira at intel.com  Wed Apr 27 09:51:23 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 27 Apr 2016 00:51:23 -0700
Subject: [Development] QMovie no longer supports .mng
In-Reply-To: <2170C141-3166-44CC-A9ED-7AFE05342093@qt.io>
References: <B36E81988B048A4FA3600EDE585F756BB87D9400@EXCH02-AKLNZ.MARINE.NET.INT>
	<2757972.bbWl2Dp4Qs@tjmaciei-mobl4>
	<2170C141-3166-44CC-A9ED-7AFE05342093@qt.io>
Message-ID: <3395760.iyXnz3ptYB@tjmaciei-mobl4>

On quarta-feira, 27 de abril de 2016 02:10:09 PDT Jake Petroules wrote:
> If we can simply update libmng and recompile against the new version then we
> should do so immediately!

I still vote for carrying fewer dependencies, especially those that try to 
read external files and may be used on untrusted files.

For each and every 3rdparty dependency we bundle or ship a binary for, we 
should have a security champion who follows security announcements for that 
3rd party source and updates our copy and binaries. Especially for the LTS 
release.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From boud at valdyas.org  Wed Apr 27 19:56:50 2016
From: boud at valdyas.org (Boudewijn Rempt)
Date: Wed, 27 Apr 2016 19:56:50 +0200 (CEST)
Subject: [Development] Exception to source compatibility: adding
 AA_CompressHighFrequencyEvents flag
In-Reply-To: <2909350.m4g5lj7Q7E@tonks>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
	<6388222.PExiJNJCEp@luna>
	<alpine.LNX.2.00.1604270848050.29597@calcifer.valdyas.org>
	<2909350.m4g5lj7Q7E@tonks>
Message-ID: <alpine.LNX.2.00.1604271955200.29597@calcifer.valdyas.org>

On Wed, 27 Apr 2016, Lisandro Damián Nicanor Pérez Meyer wrote:

> On Wednesday 27 April 2016 08:50:48 Boudewijn Rempt wrote:
> [snip]
>> As a Debian developer, you might also consider that you should never
>> ever package Krita 3 for Debian with a Qt 5.6 without this fix. You'd have
>> to carry the patch for Qt 5.6 or forego packaging Krita (and later on,
>> OpenToonz).
>
> The only Qt patches we accept are the ones ACKed by upstream (ie, someone from
> the Qt project) or the ones that are really debian-specific. Projects using Qt
> should use whatever the official Qt releases ship.
>
> So backporting a merged fix is OK, but a patch to alter standard Qt behavior
> not yet accepted is not ok.

Well, deciding upon your policy is certainly your prerogative.

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

From denis.shienkov at gmail.com  Thu Apr 28 20:24:45 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Thu, 28 Apr 2016 21:24:45 +0300
Subject: [Development] QtMultimedia && QML - hard performance
 regressions on Windows
In-Reply-To: <1096311274.5197761.1461764684824.JavaMail.yahoo@mail.yahoo.com>
References: <VI1PR02MB145439FA477BB6C9B97BC27288640@VI1PR02MB1454.eurprd02.prod.outlook.com>
	<1096311274.5197761.1461764684824.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <39f2a30f-08c7-c0b1-0825-3a473e70c955@gmail.com>

I'm currently have checked it with the Qt 5.5 and have no this 
problem... So, the regression was introduced in Qt 5.6...

So, Qt-developers, do you checks your code of QtMultimedia on 
regressions when you accept a patches, and before releasing? I do not 
understand, how is it possible to introduce this epic regression??? How 
is it possible to work for a salary and to make such bugs (and, please 
do not say that it is open source)?


27.04.2016 16:44, Massimo Callegari via Development пишет:
> ________________________________
> Da: Mitch Curtis <mitch.curtis at qt.io>
> A: Massimo Callegari <massimocallegari at yahoo.it>; "development at qt-project.org" <development at qt-project.org>
> Inviato: Mercoledì 27 Aprile 2016 14:56
> Oggetto: RE: [Development] QtMultimedia && QML - hard performance regressions on    Windows
>
>
>
>> I didn't look at the other bugs, but QTBUG-37004 seems like it would pretty easy to contribute a fix yourself.
> I don't believe it is pretty easy, especially on Linux.
> OSX already returns a user friendly list of devices.
> Windows cuts the devices names to 31 characters, cause it use APIs coming directly from the 90s.
> Linux is the worst case instead, cause every possible ALSA device is returned, so if you have 2 sound cards it will return like 20 devices, most of which don't even work.
> I believe users expect to see a list like what KDE/Gnome expose, so 4-5 devices total.
> Plus I should be looking at the pulseaudio implementation as well, which I know nothing about.
> In any case, it would require an internal change of the logic, most likely breaking backward compatibility, which is not something that I can decide.
>
>> Why waste your time and energy being outraged when you could be fixing it? Seems like a far more effective way of getting things fixed in an open source project.
> Well, I believe reporting an issue is already a contribution to fixing it and while a "pretty easy" issue would take me 1 hour to be fixed, the overall effort to get it approved would be 100 hours. I already went through the process for a QtSerialPort method, and it was a hell of a journey. Especially working with Gerrit. Please excuse my limited GIT knowledge :(
>
>> As said in the bug report, higher priority issues are being worked on.
> Which one ?
> And also...since 1-2 years ? Right...
>
>
> I would rather appreciate much more if the Qt Company could start a sort of "bounty program", where users can place a few bucks for the resolution of specific issues.
> There are more and more examples of this mechanism, like Kickstarter, Bountysource or even Stackoverflow.
> I would be happy to participate to it for the most urgent issues affecting my projects.
> I'm pretty sure there are a lot of open source projects raising donations, and small companies willing to spend some money on issues that are a priority for them.
>
> Instead, it seems to me (and it's purely my mere assumption) that big bucks come from big companies and they have the full attention of the Qt developments.
> Attention that don't go to all the rest of minor developers/projects/companies that are actually the largest user base of the Qt libraries.
> If this is really the truth, it is pretty sad. Again, just my opinion.
>
>> ________________________________
>> Da: Denis Shienkov <denis.shienkov at gmail.com>
>> A: "development at qt-project.org" <development at qt-project.org>
>> Inviato: Mercoledì 27 Aprile 2016 11:37
>> Oggetto: [Development] QtMultimedia && QML - hard performance regressions
>> on    Windows
>>
>>
>>
>> Hi developers.
>>
>> I faced with a big problem with the video playback performance, when I
>> try to open the mp4 video file from any of QML video examples. I have a
>> high CPU loading (~40%) and the video is freezing and jerks. But the C++
>> media player works satisfactory, more or less tolerably (on point 3 from
>> the 1-5 points)...
>>
>> It is impossible to use at all in QML, I face more and more with the
>> surprises of QtMultimedia, and disappointed more and more...
>>
>> WTF ? What sense in QtMultimedia if it does not work as expected?
>>
>> PS: I have created a bug: https://bugreports.qt.io/browse/QTBUG-53019
>>
>> BR,
>> Denis
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



From marc.mutz at kdab.com  Thu Apr 28 21:25:05 2016
From: marc.mutz at kdab.com (Marc Mutz)
Date: Thu, 28 Apr 2016 21:25:05 +0200
Subject: [Development] QtMultimedia && QML - hard performance
	regressions on Windows
In-Reply-To: <39f2a30f-08c7-c0b1-0825-3a473e70c955@gmail.com>
References: <VI1PR02MB145439FA477BB6C9B97BC27288640@VI1PR02MB1454.eurprd02.prod.outlook.com>
	<1096311274.5197761.1461764684824.JavaMail.yahoo@mail.yahoo.com>
	<39f2a30f-08c7-c0b1-0825-3a473e70c955@gmail.com>
Message-ID: <201604282125.06309.marc.mutz@kdab.com>

On Thursday 28 April 2016 20:24:45 Denis Shienkov wrote:
> I'm currently have checked it with the Qt 5.5 and have no this 
> problem... So, the regression was introduced in Qt 5.6...
> 
> So, Qt-developers, do you checks your code of QtMultimedia on 
> regressions when you accept a patches, and before releasing? I do not 
> understand, how is it possible to introduce this epic regression??? How 
> is it possible to work for a salary and to make such bugs (and, please 
> do not say that it is open source)?

git bisect start origin/5.6 origin/5.5

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts


From denis.shienkov at gmail.com  Fri Apr 29 10:51:00 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Fri, 29 Apr 2016 11:51:00 +0300
Subject: [Development] QtMultimedia && QML - hard performance
 regressions on Windows
In-Reply-To: <201604282125.06309.marc.mutz@kdab.com>
References: <VI1PR02MB145439FA477BB6C9B97BC27288640@VI1PR02MB1454.eurprd02.prod.outlook.com>
	<1096311274.5197761.1461764684824.JavaMail.yahoo@mail.yahoo.com>
	<39f2a30f-08c7-c0b1-0825-3a473e70c955@gmail.com>
	<201604282125.06309.marc.mutz@kdab.com>
Message-ID: <CAHtcb0wx3HTnKnbNjA4SVd64XRaCJcmVs1Y-4Y8k4XNs0D-S_w@mail.gmail.com>

I have checked it again on other PC and see following:

1) If I compile the QtMultiMedia from the 5.6 branch (self-compiled with
the Qt 5.6.0) and there are the same issue!!!

2) But if I use QtMultiMedia from the 5.5 branch (self-compiled with the Qt
5.6.0), then this issue does not exists!!!

PS: I have added this info to the bug-tracker too



2016-04-28 22:25 GMT+03:00 Marc Mutz <marc.mutz at kdab.com>:

> On Thursday 28 April 2016 20:24:45 Denis Shienkov wrote:
> > I'm currently have checked it with the Qt 5.5 and have no this
> > problem... So, the regression was introduced in Qt 5.6...
> >
> > So, Qt-developers, do you checks your code of QtMultimedia on
> > regressions when you accept a patches, and before releasing? I do not
> > understand, how is it possible to introduce this epic regression??? How
> > is it possible to work for a salary and to make such bugs (and, please
> > do not say that it is open source)?
>
> git bisect start origin/5.6 origin/5.5
>
> --
> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160429/f5b0b5e1/attachment.html>

From Shawn.Rutledge at qt.io  Fri Apr 29 15:52:33 2016
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Fri, 29 Apr 2016 13:52:33 +0000
Subject: [Development] Exception to source compatibility: adding
 AA_CompressHighFrequencyEvents flag
In-Reply-To: <DB4PR02MB0541FCEB8AA7990D974D26FB8C630@DB4PR02MB0541.eurprd02.prod.outlook.com>
References: <4CB416B3-2BFF-40D5-940A-4F8A0F52E8B3@qt.io>
	<DB4PR02MB0541FCEB8AA7990D974D26FB8C630@DB4PR02MB0541.eurprd02.prod.outlook.com>
Message-ID: <681955AB-73E9-45DE-A65F-C4EA9015FD4F@qt.io>


> On 26 Apr 2016, at 14:56, Simon Hausmann <Simon.Hausmann at qt.io> wrote:
> 
> Hi,
> 
> The way you describe the problem sounds like it is specific to tablet events on X-Windows. In my opinion a solution to the problem applied to the 5.6 branch of Qt
> should also be limited to tablet events on X-Windows. Wouldn't it therefore be easiest to simply not do tablet event compression on X-Windows without any changes to the API?

I had that idea early on, but somebody warned me that the disadvantage is having to dig into the event too much just to decide.  This decision is preliminary, before really handling the event, so it needs to be quick.  But the compression code already spends a little time, and detecting whether it’s a tablet event isn’t much more work.  Maybe we will solve the problem that way then.

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

> The day somebody really wants event compression for tablet events, we can consider introducing new API perhaps in a new minor release.

Yeah.  But we could still get https://codereview.qt-project.org/#/c/157011/ into 5.7, in case somebody wants to disable all event compression.



From denis.shienkov at gmail.com  Fri Apr 29 16:07:13 2016
From: denis.shienkov at gmail.com (Denis Shienkov)
Date: Fri, 29 Apr 2016 17:07:13 +0300
Subject: [Development] QtMultimedia && QML - hard performance
 regressions on Windows
In-Reply-To: <CAHtcb0wx3HTnKnbNjA4SVd64XRaCJcmVs1Y-4Y8k4XNs0D-S_w@mail.gmail.com>
References: <VI1PR02MB145439FA477BB6C9B97BC27288640@VI1PR02MB1454.eurprd02.prod.outlook.com>
	<1096311274.5197761.1461764684824.JavaMail.yahoo@mail.yahoo.com>
	<39f2a30f-08c7-c0b1-0825-3a473e70c955@gmail.com>
	<201604282125.06309.marc.mutz@kdab.com>
	<CAHtcb0wx3HTnKnbNjA4SVd64XRaCJcmVs1Y-4Y8k4XNs0D-S_w@mail.gmail.com>
Message-ID: <CAHtcb0xbkJq0p9aaZ64q63ArLs=Lij3s7r=Jp9SQDouXYqHNqg@mail.gmail.com>

Seems, the bug is in this two patches:

   - 36549dbe148055d6ecf98952b05b4ff2310fe491 - DirectShow: use the EVR in
   the renderer control.
   - c7397523e77578cf8f09ba3258791f68c34e2e5f - Windows: Improve EVR
   presenter.

I have added this info to bug-tracker...



2016-04-29 11:51 GMT+03:00 Denis Shienkov <denis.shienkov at gmail.com>:

> I have checked it again on other PC and see following:
>
> 1) If I compile the QtMultiMedia from the 5.6 branch (self-compiled with
> the Qt 5.6.0) and there are the same issue!!!
>
> 2) But if I use QtMultiMedia from the 5.5 branch (self-compiled with the
> Qt 5.6.0), then this issue does not exists!!!
>
> PS: I have added this info to the bug-tracker too
>
>
>
> 2016-04-28 22:25 GMT+03:00 Marc Mutz <marc.mutz at kdab.com>:
>
>> On Thursday 28 April 2016 20:24:45 Denis Shienkov wrote:
>> > I'm currently have checked it with the Qt 5.5 and have no this
>> > problem... So, the regression was introduced in Qt 5.6...
>> >
>> > So, Qt-developers, do you checks your code of QtMultimedia on
>> > regressions when you accept a patches, and before releasing? I do not
>> > understand, how is it possible to introduce this epic regression??? How
>> > is it possible to work for a salary and to make such bugs (and, please
>> > do not say that it is open source)?
>>
>> git bisect start origin/5.6 origin/5.5
>>
>> --
>> Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
>> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
>> Tel: +49-30-521325470
>> KDAB - Qt, C++ and OpenGL Experts
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160429/c9927a81/attachment.html>

From thiago.macieira at intel.com  Fri Apr 29 19:36:50 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Fri, 29 Apr 2016 10:36:50 -0700
Subject: [Development] Retiring libtiff too
Message-ID: <1529193.H9kQ9lu0gr@tjmaciei-mobl4>

See https://lists.clearlinux.org/pipermail/dev/2016-April/000290.html

This is yet another reason we have to stop bundling third party components, 
especially the image and movie formats.

So I recommend dropping the libtiff 3rdparty component and keep the plugin for 
when the system library is found. Our binaries should not include libqtiff.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From kde at carewolf.com  Fri Apr 29 21:14:17 2016
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Fri, 29 Apr 2016 21:14:17 +0200
Subject: [Development] Retiring libtiff too
In-Reply-To: <1529193.H9kQ9lu0gr@tjmaciei-mobl4>
References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4>
Message-ID: <201604292114.17468.kde@carewolf.com>

On Friday 29 April 2016, Thiago Macieira wrote:
> See https://lists.clearlinux.org/pipermail/dev/2016-April/000290.html
> 
> This is yet another reason we have to stop bundling third party components,
> especially the image and movie formats.
> 
> So I recommend dropping the libtiff 3rdparty component and keep the plugin
> for when the system library is found. Our binaries should not include
> libqtiff.
Do you have any citations for these issues? TIFF is a pretty important format 
being the raw format of many if not most digital cameras. It also isn't a web 
format so the vectors of potential attacks are limited 

`Allan


From jasonsu at mail-central.com  Fri Apr 29 23:00:57 2016
From: jasonsu at mail-central.com (jasonsu at mail-central.com)
Date: Fri, 29 Apr 2016 14:00:57 -0700
Subject: [Development] Qt Keyboard Shortcuts broken in Qt 5.6 (since 4.8
 at least). Reproducible test case included.
Message-ID: <1461963657.2321012.593805129.0D599958@webmail.messagingengine.com>

I was previously told on this list

	http://lists.qt-project.org/pipermail/development/2016-April/025595.html

that this bug is a KDE issue, not Qt.  So I moved it to KDE list.

A dev @ KDE then said it is NOT a KDE issue, but IS a Qt bug

    This is https://bugreports.qt.io/browse/QTBUG-48795
    Qt5 builds it's internal events as combination of (synthetic) keys and HW
    modifiers.

    That is *clearly* a fucking bug in Qt: either it ignores synthetic
    events (a regression compared to Qt4) or not, but just creating random
    events out of different sources should certainly not be intended.

Another KDE dev agreed, and opened this issue

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

Since then, after some daily pkg updates, I saw an improvement in the behavior of shortcuts.

I'm not going to chase the bouncing "it's not us" ball anymore. in case anyone's interested, I'm posting what I see here.

Here's a test showing that currently using shortcuts is still not 100%. 

  Trigger: Meta-Ctl-Alt-T
 
  Action           Expected Output    Actual Output    Status
  ---------------  -----------------  ---------------  --------
  1                1                  1                OK
  Shift+1          !                  !                OK
  1:1              11                 11               OK
  1:Shift+1        1!                 1!               OK
  Shift+1:Shift+1  !!                 !!               OK
  Shift+1:1        !1                 !!               WRONG

HTH.


From rich at kde.org  Sat Apr 30 12:22:37 2016
From: rich at kde.org (Richard Moore)
Date: Sat, 30 Apr 2016 11:22:37 +0100
Subject: [Development] Retiring libtiff too
In-Reply-To: <201604292114.17468.kde@carewolf.com>
References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4>
	<201604292114.17468.kde@carewolf.com>
Message-ID: <CAMp7mVsWb+Ng_yo9vxBahD667+FQwtQzr=MBJaCYoQ=aUMuHoA@mail.gmail.com>

On 29 April 2016 at 20:14, Allan Sandfeld Jensen <kde at carewolf.com> wrote:

> On Friday 29 April 2016, Thiago Macieira wrote:
> > See https://lists.clearlinux.org/pipermail/dev/2016-April/000290.html
> >
> > This is yet another reason we have to stop bundling third party
> components,
> > especially the image and movie formats.
> >
> > So I recommend dropping the libtiff 3rdparty component and keep the
> plugin
> > for when the system library is found. Our binaries should not include
> > libqtiff.
> Do you have any citations for these issues? TIFF is a pretty important
> format
> being the raw format of many if not most digital cameras. It also isn't a
> web
> format so the vectors of potential attacks are limited
>

​Isn't commonly used on the web, and can't be used on the web are
different. Do we have code that prevents such usage? I'm not aware we even
have an API to limit the set of image format plugins that would get loaded.

Cheers

Rich.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160430/a1c83040/attachment.html>

From sean.harmer at kdab.com  Sat Apr 30 21:26:20 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Sat, 30 Apr 2016 20:26:20 +0100
Subject: [Development] Qt CI reliability
Message-ID: <4166383.CnvrWBLNsi@titan>

Hi,

after yet another 5 hour wait just to be greeted with yet another random 
failure with no build logs I'm getting really tired of the poor reliability of 
the Qt CI system.

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

has been greeted with genuine failures, failures in qtdeclarative, 
qtxmlpatterns, multiple random failures in qt3d despite being a simple change 
which I suspect are due to issues on one or more CI nodes.

I appreciate the new CI is more efficient than the previous implementation but 
it still has a very high rate of failed integration attempts. For a piece of 
infrastructure that is critical to the Qt Project the CI system should have 
24x7 sysadmin support. I'm not expecting devs to be doing this. The Qt Company 
has sys admins supported by license fees yet we see example after example of 
the support being substandard. Certificates expiring, disks filling up, upgrades 
being performed to coincide with feature freezes, upgrades performed then 
going home for the weekend leaving systems in an unfit state.

Such long waits resulting in random failures is killing both productivity and 
motivation. This whole week seems to have been nothing other than an endless 
cycle of staging and re-staging. We're doing our best to get Qt 3D into shape 
for Qt 5.7 but this is being hamstrung by the infrastructure.

I don't understand how sysadmins can be caught out by disks filling up without 
them being notified. Why is there no server monitoring in place? Likewise for 
the numerous SSL certificate expirations over the last couple of years.

Now being in the same situation of seemingly endless failures over a holiday 
weekend, it seems my backlog will continue to get longer whilst my will power 
to dedicate my personal time to meeting the release deadline so that TQC 
sysadmins can go on their summer vacations wanes.

I would be very grateful if anybody happens to read this and is available to 
look at the current CI issues. Please can TQC management dedicate resources to 
sorting out the underlying resource shortages for administering the CI, 
putting on place some reliable server monitoring that actually gets acted upon 
and giving the project the system it should have.

Thank you and enjoy what is left of the holiday weekend.

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions


From thiago.macieira at intel.com  Sat Apr 30 19:54:25 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 30 Apr 2016 10:54:25 -0700
Subject: [Development] Retiring libtiff too
In-Reply-To: <CAMp7mVsWb+Ng_yo9vxBahD667+FQwtQzr=MBJaCYoQ=aUMuHoA@mail.gmail.com>
References: <1529193.H9kQ9lu0gr@tjmaciei-mobl4>
	<201604292114.17468.kde@carewolf.com>
	<CAMp7mVsWb+Ng_yo9vxBahD667+FQwtQzr=MBJaCYoQ=aUMuHoA@mail.gmail.com>
Message-ID: <3568262.7vdFVilEmy@tjmaciei-mobl4>

On sábado, 30 de abril de 2016 11:22:37 PDT Richard Moore wrote:
> ​Isn't commonly used on the web, and can't be used on the web are
> different. Do we have code that prevents such usage? I'm not aware we even
> have an API to limit the set of image format plugins that would get loaded.

You may remember the the original iPhone and iPod could get jailbroken by 
opening a .tiff image in the browser. That would execute an exploit and 
install and installer application. That was before the iTunes App Store.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center