Re: [Interest] FLex / Bison and QT4 4.8.1 Win32 interaction

[Bob Hood]

On 7/7/2016 8:26 PM, william.croc...@analog.com wrote:

On 07/07/2016 08:01 PM, Fabio Giovagnini wrote:

Thanks Frank. So you suggest to build from the sources. I' try. Thanks again



I suggest you just take the weekend and write your own
parser and lexical analysis, void of Flex and Bison.
I did and I have never looked back.

:-)



And, whereas, I pretty much founded a career on them, so to each his own.  ;)

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] FLex / Bison and QT4 4.8.1 Win32 interaction

[william.croc...@analog.com]

On 07/07/2016 08:01 PM, Fabio Giovagnini wrote:

Thanks Frank. So you suggest to build from the sources. I' try. Thanks again



I suggest you just take the weekend and write your own
parser and lexical analysis, void of Flex and Bison.
I did and I have never looked back.

:-)

Bill


Il 07/lug/2016 17:40, "K. Frank" > ha scritto:

Ciao Fabio!

On Thu, Jul 7, 2016 at 7:19 AM, Fabio Giovagnini > wrote:
>  Ciao to all.
>  I have an application linux native based on:
>  1) qt4 (4.8.1)
>  3) lex/bison
>
>  Under Ubuntu 14.04 and prevoius everithing ok.
>
>  Under Windows, I cannot find lex/bison support.
>  I have to say that I installed only QT SDK (w/ MinGW support)
>  Any suggestion will be really appreciated.

Windows does not come with built-in flex / bison support, nor
does mingw, nor (to the best of my knowledge) does Qt. (This
is true of a lot of unix-world libraries that are nearly universal
on various flavors of unix.)

I would expect (but don't know for a fact) that you could find a
third-party port of flex / bison to windows that you could then
use for your Qt / flex / bison project. In general, you would be
best off if you found a port built with the same compiler as your
Qt project (apparently mingw). One way to insure this would be
to build it yourself. If you're careful and know what your doing
you can sometimes get away with using c libraries compiled with
a different compiler (For example, the ms system calls were not
compile with mingw and you can call into those.), but it's likely to
be more bother trying to mix compilers than compiling something
like flex / bison yourself.

>  Thanks
>  Fabio


Happy Parsing!


K. Frank
___
Interest mailing list
Interest@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/interest



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] FLex / Bison and QT4 4.8.1 Win32 interaction

[Fabio Giovagnini]

Thanks Frank. So you suggest to build from the sources. I' try. Thanks again
Il 07/lug/2016 17:40, "K. Frank"  ha scritto:

> Ciao Fabio!
>
> On Thu, Jul 7, 2016 at 7:19 AM, Fabio Giovagnini  wrote:
> > Ciao to all.
> > I have an application linux native based on:
> > 1) qt4 (4.8.1)
> > 3) lex/bison
> >
> > Under Ubuntu 14.04 and prevoius everithing ok.
> >
> > Under Windows, I cannot find lex/bison support.
> > I have to say that I installed only QT SDK (w/ MinGW support)
> > Any suggestion will be really appreciated.
>
> Windows does not come with built-in flex / bison support, nor
> does mingw, nor (to the best of my knowledge) does Qt.  (This
> is true of a lot of unix-world libraries that are nearly universal
> on various flavors of unix.)
>
> I would expect (but don't know for a fact) that you could find a
> third-party port of flex / bison to windows that you could then
> use for your Qt / flex / bison project.  In general, you would be
> best off if you found a port built with the same compiler as your
> Qt project (apparently mingw).  One way to insure this would be
> to build it yourself.  If you're careful and know what your doing
> you can sometimes get away with using c libraries compiled with
> a different compiler (For example, the ms system calls were not
> compile with mingw and you can call into those.), but it's likely to
> be more bother trying to mix compilers than compiling something
> like flex / bison yourself.
>
> > Thanks
> > Fabio
>
>
> Happy Parsing!
>
>
> K. Frank
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Creating Qt Quick controls from C++

[Xavier Bigand]

I think that our approche can be wrong, maybe you don't need to be able to
access to the QtQuick components from the C++. The best is to follow the
philosophy of QtQuick with the property bindings. You can expose variables
(properties) from your c++ to the QML and let the QML interact with them.
In QML you have everything to build the GUI dynamically, property bindings,
loaders,...
The c++ code have just to emit a signal when the property value changed,
and your GUI will be updated depending of your conditions in the property
bindings on the QML side.

We use that to create a custom GUI, that can be adapted to every screen
size (from mobile to desktop) be able to change GUI skins, language,...
without restarting the application. It's a major time development win,
because we can emulate the GUI we have on phone on desktop without
restarting the application (we simply change the c++ property that give us
the device type),...

And because we can't use the design due to the c++ dependencies, we add the
QML hot reloading when files are changing.


If you are looking to change our GUI library, removing our actual c++
dedicated to the interface creation shouldn't much harder than refactoring
it to fit the new API.


QtQuick is made to works with property binding, that it is not supported on
the c++ side by Qt. The only thing you can create on c++ side is new item
types by derived some existing.


2016-07-07 23:52 GMT+02:00 Rob Allan :

> I'm part of a team that is looking at migrating an existing Windows C++
> app to Qt. The first decision is whether to use Widgets or Qt Quick. Since
> Qt Quick is newer, shinier, faster, etc, that seems like the obvious
> choice. However, for reasons that I won't go into here, the vast majority
> of forms in our app are built dynamically in code. This kind of approach
> seems easy enough with Widgets, but looks like it could be difficult, or
> even infeasible, with Qt Quick. That's because the preferred way of
> creating Qt Quick layouts is using QML, and while there is an object model
> backing that, my impression is that this object model is not designed to
> support heavy-duty creation and manipulation of layout elements. For
> example, while QQuickItem is documented, none of its derived classes are,
> and I believe their interfaces may be private - so the only way to
> manipulate items is using a generic "setProperty" syntax. And while there
> are a few articles around that talk about accessing the Qt Quick model from
> C++, such as this one [
> http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c],
> they tend to use snippets of QML to get the job done in a rather hacky way,
> and make various comments about the perils and pitfalls of trying to
> manipulate the model from code.
>
> I can't help comparing this with two other popular layout frameworks:
> WPF/XAML, and Android/AXML. In both of these worlds, the markup language
> and the "code-behind" class hierarchy of UI elements are absolutely
> equivalent 1st class citizens. Anything you can do in XAML, you can also do
> in the C# code-behind, whether it be creating controls, changing their
> properties, altering layouts, etc. Likewise in Android/AXML, I can (if I
> choose) create FrameLayouts, RelativeLayouts, TextViews, etc in code, and
> arrange them and manipulate them any way I like, as an alternative to
> creating an AXML designer layout.
>
> It seems very unfortunate that Qt Quick doesn't take this approach, and
> that the "code-behind" experience is so limited.
>
> Am I missing something here? Assuming I'm not, are there any plans to make
> the Qt Quick class model more "open", with full documentation and public
> interfaces for all relevant properties and methods?
>
> Thanks,
> Rob
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>


-- 
Xavier
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Creating Qt Quick controls from C++

[Rob Allan]

I'm part of a team that is looking at migrating an existing Windows C++ app
to Qt. The first decision is whether to use Widgets or Qt Quick. Since Qt
Quick is newer, shinier, faster, etc, that seems like the obvious choice.
However, for reasons that I won't go into here, the vast majority of forms
in our app are built dynamically in code. This kind of approach seems easy
enough with Widgets, but looks like it could be difficult, or even
infeasible, with Qt Quick. That's because the preferred way of creating Qt
Quick layouts is using QML, and while there is an object model backing
that, my impression is that this object model is not designed to support
heavy-duty creation and manipulation of layout elements. For example, while
QQuickItem is documented, none of its derived classes are, and I believe
their interfaces may be private - so the only way to manipulate items is
using a generic "setProperty" syntax. And while there are a few articles
around that talk about accessing the Qt Quick model from C++, such as this
one [
http://stackoverflow.com/questions/31890372/add-objects-to-qml-layout-from-c],
they tend to use snippets of QML to get the job done in a rather hacky way,
and make various comments about the perils and pitfalls of trying to
manipulate the model from code.

I can't help comparing this with two other popular layout frameworks:
WPF/XAML, and Android/AXML. In both of these worlds, the markup language
and the "code-behind" class hierarchy of UI elements are absolutely
equivalent 1st class citizens. Anything you can do in XAML, you can also do
in the C# code-behind, whether it be creating controls, changing their
properties, altering layouts, etc. Likewise in Android/AXML, I can (if I
choose) create FrameLayouts, RelativeLayouts, TextViews, etc in code, and
arrange them and manipulate them any way I like, as an alternative to
creating an AXML designer layout.

It seems very unfortunate that Qt Quick doesn't take this approach, and
that the "code-behind" experience is so limited.

Am I missing something here? Assuming I'm not, are there any plans to make
the Qt Quick class model more "open", with full documentation and public
interfaces for all relevant properties and methods?

Thanks,
Rob
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [CMake] [ANNOUNCE] CMake 3.6.0 available for download

[Konstantin Podsvirov]

It may be interesting to users of QtIFW.

07.07.2016, 20:12, "Robert Maynard" :
> I am proud to announce that CMake 3.6.0 is now available for download at:
> https://cmake.org/download/
>
> Documentation is available at:
> https://cmake.org/cmake/help/v3.6
>
> Release notes appear below and are also published at
> https://cmake.org/cmake/help/v3.6/release/3.6.html
...
> CPack
...
> * The "CPackIFW" module gained a new "cpack_ifw_update_repository()"
> command to update a QtIFW-specific repository from a remote
> repository.

You can use this method to update repositories (see the documentation: 
http://doc.qt.io/qtinstallerframework/ifw-updates.html#changing-repositories), 
but you don't need to add items to Updates.xml hands - CPack "IFW" generator 
will do the job for you.

...
> Changes made since CMake 3.6.0-rc4:
...
> Konstantin Podsvirov (1):
> CPackIFW: Fix attributes for Promoting Updates repository replacement

Work on this topic allowed us to find and resolve the bug (see: 
https://bugreports.qt.io/browse/QTIFW-873).

--
Regards,
Konstantin Podsvirov
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] qtcreator, find scope, and git grep

[Alan Ezust]

Playing around with QtCreator 4.0.3, and I noticed I can choose to use
"git grep" for searching through files if the "Scope:" is set to "Files in
file system", which is nice.

But why, if I set the "scope" to 'Project "MyProjectName"', does the "Use
Git Grep" choice disappear from the form?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Help with Qt 5.6.1-1 32-bit build errors

[Bob Hood]

Bingo!  That appears to have been the problem.  Just like the report, I too 
was using jom, and when I changed my expert-knowledge build script to force 
nmake for static builds, it breezed through the 32-bit static release build 
with no problems.  Why this wasn't encountered with 64-bit static I don't 
know, but it certainly appears to have been the exact problem preventing the 
32-bit static build from completing.


Thanks so much, Mike.  :)


On 7/7/2016 10:10 AM, Mike Chinander wrote:
Looks like it could be related to this bug report: 
https://bugreports.qt.io/browse/QTBUG-53393


Did you try re-running nmake/jom after you got this error?

On Thu, Jul 7, 2016 at 10:57 AM, Bob Hood >wrote:


I'm trying to build Qt 5.6.1-1 32-bit licensed static using Visual
Studio 2013.  I am configuring with the following command:

configure -commercial -confirm-license -static -prefix
Q:\Qt\5.6.1\32_static -mp -release -nomake examples -no-qml-debug
-no-compile-examples -nomake tests -opengl desktop

I have successfully built 64-bit versions, static and DLL, licensed and
open source, with similar config commands just prior to attempting the
32-bit builds.  At some point in the 32-bit build, I'm getting:

LINK : fatal error LNK1181: cannot open input file
'D:\Qt\build\32_static\qtimageformats\plugins\imageformats\qwebp.lib'

I read that the webkit had been removed from the 5.6 distribution (I'm
using the source tarballs), but it looks like there's some kind of
dependency upon it anyway.  I configured the 64-bit builds with ICU, but
I did not with 32-bit because we don't want the webkit builds in the
32-bit static.  I tried adding the '-skip qtwebkit' command (which works
fine for prior Qt versions), but then I get the different build error:

Attempting to skip non-existent module qtwebkit.
Error: File Makefile doesn't exist.

Removing '-skip qtwebkit' from the config line leads me to the link
error with the image format plug-in.

Do I now need to provide ICU to the 32-bit builds even though we
/aren't/building the webkit module, or is there some new means of
disabling the webkit as part of that type of build?I'd appreciate any
insights here.


___
Interest mailing list
Interest@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

[Sean Harmer]

Hi,

On 07/07/2016 07:47, Uwe Rathmann wrote:

On Wed, 06 Jul 2016 18:10:37 +, J-P Nurmi wrote:


Interesting choice. I would have done the exact opposite. Application
logic in C++ and UI declaration in QML.


Well this is actually not a choice - we  did it in QML and ended up with
a disappointing performance, because of QML. And we did it exactly like
you recommend - we simply have a lot of UI.


So what were the results of profiling? CPU usage caused by 
animations/batching, something else? GPU? Bandwidth? Lock contention? 
Any test cases to help others profile it?





Declaring fluid animated UIs in
QML is a joy, writing animations in C++ is not so.


In case of the animations QML offers a compact syntax to access a library
of C++ classes mostly setting up a QPropertyAnimation. Using similar ( or
even the same ) classes from C++ is not uncomfortable either.

My experience so far is, that using Qt/Quick from C++ does not have to be
that different from writing a widget application: creating controls,
setting up signal/slot connections and arranging them into layouts.

The graphic stack behind is irrelevant for the vast majority of the
application code and I disagree with Thiago, that it is not possible to
implement controls with a similar API as their widget counterparts.


That's not true. The CPU just isn't capable of doing lots of blending on 
the number of pixels available on typical displays these days. So it 
depends entirely upon the type of UI you are trying to construct. For 
widget type UIs then yes you should be fine with either tech. Add in 
lots of animations, transparency effects, colour grading effects etc and 
you will very quickly hit limitations of CPU raster based painting.


I'm not saying Qt Quick is perfect. This is why I am asking above about 
what bottleneck you experienced so that we can investigate fixing it.


It's perfectly possible to provide C++ apis, we do this in Qt 3D. It was 
just chosen to not do this for Qt Quick thus far.


Cheers,

Sean



Uwe


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



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

Re: [Interest] [Qt3D] Frustum culling

[Sean Harmer]

Hi,

On 07/07/2016 09:46, Émeric MASCHINO wrote:

Hi,

2016-07-01 17:37 GMT+02:00 Sean Harmer :

Hi,





Frustum culling is simple once you have the bounding volumes for entities and
the planes forming the view frustum. These are computed elsewhere to where the
culling is actually performed. The culling is currently performed at:

http://code.qt.io/cgit/qt/qt3d.git/tree/src/render/backend/renderview.cpp#n541


Well, unless I'm missing the point, I only see m_frustumCulling member
variable with setter/getter. But that's all: nobody seems to care
about the status of this member variable, nor if it was set when a
QFrustumCulling instance was found in a RenderView's frame path. Or
maybe is it because you're in the process of rewriting things for more
parallelism as you told?


Yeah, the change I linked to has already been merged, so that code has 
now changed and all is done within the frustum culling job.





We are actually in the process of parallelising much more of the work that Qt
3D does on the backend. So shortly this will be done in a separate job:

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


As a side note, how jobs then "interface" themselve in the rendering process?


The Renderer is responsible for instantiating suitable jobs and setting 
up the dependencies between them. In this case the renderer creates a 
job to perform the world transform updates, then update the bounding 
volume hierarchy. Once this is done the renderer performs a frustum 
culling job (if enabled in the framegraph) using the data from the 
previous jobs and the planes defining the frustum of the currently 
selected camera (also from the framegraph).


Other kinds of filtering can also take place such as limiting entities 
to a subset of defined layers. This is done in yet another job.


Much of this logic is controlled by the frame graph visitor:

http://code.qt.io/cgit/qt/qt3d.git/tree/src/render/framegraph/framegraphvisitor.cpp#n139

Cheers,

Sean




Hope this helps,


Yes, thanks :-)

 Émeric
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QtPlugins statically linked not loading

[David Faure]

On lundi 1 juin 2015 18:18:07 CEST Nuno Santos wrote:
> #ifdef Q_OS_WINDOWS
> #include 
> Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
> #endif

Old mail, but for the record:
surely the issue was that the correct #define is Q_OS_WIN32, not Q_OS_WINDOWS 
(this never existed).

-- 
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt Experts

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Bug reproduction needed!

[Etienne Sandré-Chardonnal]

Thanks to all, this will be fixed in Qt 5.6.2

Another bug reproduction needed :
https://bugreports.qt.io/browse/QTBUG-54561

I get a cropped windows explorer icon with 5.6, and a correct icon with 5.4.
The test is Windows only as it requires "C:\Windows\explorer.exe"

Thanks!

2016-06-12 15:49 GMT+02:00 Dilshod Mukhtarov :

> On 10.06.2016 22:48, Etienne Sandré-Chardonnal wrote:
>
> I forgot to mention, could you send your qt version? I am seeing this on
> qt 5.4.2
>
> Thanks,
>
> Etienne
>
> The bug is reproducible for me.
>
> Qt: 5.7.0-rc, 64 bit
> MSVC2015 update 1
> Windows 10 64bit
>
> I attached two screenshots: before and after switch user
>
> --
> With the best regards,
> Dilshod
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Help with Qt 5.6.1-1 32-bit build errors

[Mike Chinander]

Looks like it could be related to this bug report:
https://bugreports.qt.io/browse/QTBUG-53393

Did you try re-running nmake/jom after you got this error?

On Thu, Jul 7, 2016 at 10:57 AM, Bob Hood  wrote:

> I'm trying to build Qt 5.6.1-1 32-bit licensed static using Visual Studio
> 2013.  I am configuring with the following command:
>
> configure -commercial -confirm-license -static -prefix
> Q:\Qt\5.6.1\32_static -mp -release -nomake examples -no-qml-debug
> -no-compile-examples -nomake tests -opengl desktop
>
> I have successfully built 64-bit versions, static and DLL, licensed and
> open source, with similar config commands just prior to attempting the
> 32-bit builds.  At some point in the 32-bit build, I'm getting:
>
> LINK : fatal error LNK1181: cannot open input file
> 'D:\Qt\build\32_static\qtimageformats\plugins\imageformats\qwebp.lib'
>
> I read that the webkit had been removed from the 5.6 distribution (I'm
> using the source tarballs), but it looks like there's some kind of
> dependency upon it anyway.  I configured the 64-bit builds with ICU, but I
> did not with 32-bit because we don't want the webkit builds in the 32-bit
> static.  I tried adding the '-skip qtwebkit' command (which works fine for
> prior Qt versions), but then I get the different build error:
>
> Attempting to skip non-existent module qtwebkit.
> Error: File Makefile doesn't exist.
>
> Removing '-skip qtwebkit' from the config line leads me to the link error
> with the image format plug-in.
>
> Do I now need to provide ICU to the 32-bit builds even though we *aren't*
> building the webkit module, or is there some new means of disabling the
> webkit as part of that type of build?  I'd appreciate any insights here.
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Help with Qt 5.6.1-1 32-bit build errors

[Thiago Macieira]

On quinta-feira, 7 de julho de 2016 09:57:22 PDT Bob Hood wrote:
> At some point in the 32-bit build, I'm getting:
> 
> LINK : fatal error LNK1181: cannot open input file
> 'D:\Qt\build\32_static\qtimageformats\plugins\imageformats\qwebp.lib'

There'sp robably more information further up. This message alone isn't enough.

Was this a linker error while trying to create qwebp.lib? Or was it by trying 
to use it? If it's trying to use it, did the compilation of the webp plugin 
fail? What was the error?

In other words: what was the *first* compilation or linker error?

> Do I now need to provide ICU to the 32-bit builds even though we /aren't/
> building the webkit module, or is there some new means of disabling the
> webkit as part of that type of build?I'd appreciate any insights here.

ICU is a good idea, even without WebKit.

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

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Help with Qt 5.6.1-1 32-bit build errors

[Konstantin Tokarev]

07.07.2016, 18:57, "Bob Hood" :
> I'm trying to build Qt 5.6.1-1 32-bit licensed static using Visual Studio 
> 2013.  I am configuring with the following command:
>> configure -commercial -confirm-license -static -prefix Q:\Qt\5.6.1\32_static 
>> -mp -release -nomake examples -no-qml-debug -no-compile-examples -nomake 
>> tests -opengl desktop
> I have successfully built 64-bit versions, static and DLL, licensed and open 
> source, with similar config commands just prior to attempting the 32-bit 
> builds.  At some point in the 32-bit build, I'm getting:
>> LINK : fatal error LNK1181: cannot open input file 
>> 'D:\Qt\build\32_static\qtimageformats\plugins\imageformats\qwebp.lib'
> I read that the webkit had been removed from the 5.6 distribution (I'm using 
> the source tarballs), but it looks like there's some kind of dependency upon 
> it anyway.

How did you infer that QtWebKit is involved here? qwebp.lib is WebP imageformat 
plugin.

>  I configured the 64-bit builds with ICU, but I did not with 32-bit because 
>we don't want the webkit builds in the 32-bit static.

FYI, since 5.6.1 it is possible to build QtWebKit against Qt configured without 
ICU (though you still need ICU itself to build it).

>  I tried adding the '-skip qtwebkit' command (which works fine for prior Qt 
>versions), but then I get the different build error:
>> Attempting to skip non-existent module qtwebkit.
>> Error: File Makefile doesn't exist.
> Removing '-skip qtwebkit' from the config line leads me to the link error 
> with the image format plug-in.
>
> Do I now need to provide ICU to the 32-bit builds even though we aren't 
> building the webkit module, or is there some new means of disabling the 
> webkit as part of that type of build?  I'd appreciate any insights here.
>
> ,
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest


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

[Interest] Help with Qt 5.6.1-1 32-bit build errors

[Bob Hood]

I'm trying to build Qt 5.6.1-1 32-bit licensed static using Visual Studio 
2013.  I am configuring with the following command:


   configure -commercial -confirm-license -static -prefix
   Q:\Qt\5.6.1\32_static -mp -release -nomake examples -no-qml-debug
   -no-compile-examples -nomake tests -opengl desktop

I have successfully built 64-bit versions, static and DLL, licensed and open 
source, with similar config commands just prior to attempting the 32-bit 
builds.  At some point in the 32-bit build, I'm getting:


   LINK : fatal error LNK1181: cannot open input file
   'D:\Qt\build\32_static\qtimageformats\plugins\imageformats\qwebp.lib'

I read that the webkit had been removed from the 5.6 distribution (I'm using 
the source tarballs), but it looks like there's some kind of dependency upon 
it anyway.  I configured the 64-bit builds with ICU, but I did not with 32-bit 
because we don't want the webkit builds in the 32-bit static.  I tried adding 
the '-skip qtwebkit' command (which works fine for prior Qt versions), but 
then I get the different build error:


   Attempting to skip non-existent module qtwebkit.
   Error: File Makefile doesn't exist.

Removing '-skip qtwebkit' from the config line leads me to the link error with 
the image format plug-in.


Do I now need to provide ICU to the 32-bit builds even though we /aren't/ 
building the webkit module, or is there some new means of disabling the webkit 
as part of that type of build?I'd appreciate any insights here.


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] FLex / Bison and QT4 4.8.1 Win32 interaction

[K. Frank]

Ciao Fabio!

On Thu, Jul 7, 2016 at 7:19 AM, Fabio Giovagnini  wrote:
> Ciao to all.
> I have an application linux native based on:
> 1) qt4 (4.8.1)
> 3) lex/bison
>
> Under Ubuntu 14.04 and prevoius everithing ok.
>
> Under Windows, I cannot find lex/bison support.
> I have to say that I installed only QT SDK (w/ MinGW support)
> Any suggestion will be really appreciated.

Windows does not come with built-in flex / bison support, nor
does mingw, nor (to the best of my knowledge) does Qt.  (This
is true of a lot of unix-world libraries that are nearly universal
on various flavors of unix.)

I would expect (but don't know for a fact) that you could find a
third-party port of flex / bison to windows that you could then
use for your Qt / flex / bison project.  In general, you would be
best off if you found a port built with the same compiler as your
Qt project (apparently mingw).  One way to insure this would be
to build it yourself.  If you're careful and know what your doing
you can sometimes get away with using c libraries compiled with
a different compiler (For example, the ms system calls were not
compile with mingw and you can call into those.), but it's likely to
be more bother trying to mix compilers than compiling something
like flex / bison yourself.

> Thanks
> Fabio


Happy Parsing!


K. Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt conflict with libjpeg-turbo between 5.4 and 5.6

[Etienne Sandré-Chardonnal]

Thanks for your help!

Etienne

2016-07-07 9:46 GMT+02:00 Allan Sandfeld Jensen :

> On Wednesday 06 July 2016, Etienne Sandré-Chardonnal wrote:
> > Hi,
> >
> > I use libjpeg-turbo in my app for some time now.
> >
> > Since I switched to Qt 5.6 (from Qt 5.4), reading any Jpeg image with
> > QPixmap crashes the app.
> >
> > Is this a lib conflict? I linked with both Qt and libjpeg-turbo
> statically.
> > Could changing either to dynamic link solve the problem?
> >
> > Thanks!
>
> libjpeg-turbo hasn't implemented everything libjpeg has (if I remember
> correctly it has implemented libjpeg v8 but not libjpeg v9) , and Qt will
> use
> some of the libjpeg features libjpeg-turbo is missing if build against
> libjpeg. So as Konstantin said; you must use the same library version when
> building Qt and your application.
>
> `Allan
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Shabby QtQuick Window resize behavior on Windows

[Nils Jeisecke via Interest]

Hi list,

Please have a look at this (stunning) video as an illustration of my issue:

https://youtu.be/I3ENphe19qc

It shows the current (Qt 5.8 / dev) application window resize behavior
of a QtQuick based application (gallery example) vs. a QtWidget
(mainwindow example) based one.

This is on Windows7 with ANGLE. The screen capture was done with
Windows running inside VMWare Fusion, but the effect is just as bad on
a native Windows notebook with some average Intel mobile graphic
chipset.

On OS X resizing is much smoother, apart from some flicker now and
then. Haven’t checked X11.

Is there any hope for improvement?

Nils
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] FLex / Bison and QT4 4.8.1 Win32 interaction

[Fabio Giovagnini]

Ciao to all.
I have an application linux native based on:
1) qt4 (4.8.1)
3) lex/bison

Under Ubuntu 14.04 and prevoius everithing ok.

Under Windows, I cannot find lex/bison support.
I have to say that I installed only QT SDK (w/ MinGW support)
Any suggestion will be really appreciated.

Thanks
Fabio
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] [Qt3D] Frustum culling

[Émeric MASCHINO]

Hi,

2016-07-01 17:37 GMT+02:00 Sean Harmer :
> Hi,



> Frustum culling is simple once you have the bounding volumes for entities and
> the planes forming the view frustum. These are computed elsewhere to where the
> culling is actually performed. The culling is currently performed at:
>
> http://code.qt.io/cgit/qt/qt3d.git/tree/src/render/backend/renderview.cpp#n541

Well, unless I'm missing the point, I only see m_frustumCulling member
variable with setter/getter. But that's all: nobody seems to care
about the status of this member variable, nor if it was set when a
QFrustumCulling instance was found in a RenderView's frame path. Or
maybe is it because you're in the process of rewriting things for more
parallelism as you told?

> We are actually in the process of parallelising much more of the work that Qt
> 3D does on the backend. So shortly this will be done in a separate job:
>
> https://codereview.qt-project.org/#/c/159300/

As a side note, how jobs then "interface" themselve in the rendering process?

> Hope this helps,

Yes, thanks :-)

 Émeric
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt conflict with libjpeg-turbo between 5.4 and 5.6

[Allan Sandfeld Jensen]

On Wednesday 06 July 2016, Etienne Sandré-Chardonnal wrote:
> Hi,
> 
> I use libjpeg-turbo in my app for some time now.
> 
> Since I switched to Qt 5.6 (from Qt 5.4), reading any Jpeg image with
> QPixmap crashes the app.
> 
> Is this a lib conflict? I linked with both Qt and libjpeg-turbo statically.
> Could changing either to dynamic link solve the problem?
> 
> Thanks!

libjpeg-turbo hasn't implemented everything libjpeg has (if I remember 
correctly it has implemented libjpeg v8 but not libjpeg v9) , and Qt will use 
some of the libjpeg features libjpeg-turbo is missing if build against 
libjpeg. So as Konstantin said; you must use the same library version when 
building Qt and your application.

`Allan
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] how to install qt enterprise using command line only?

[Ch'Gans]

On 7 July 2016 at 19:05, Ben Lau  wrote:
>
>
> On 7 July 2016 at 12:42, Thiago Macieira  wrote:
>>
>> On quinta-feira, 7 de julho de 2016 10:29:43 PDT Лагнер, Сергей wrote:
>> > Does not work as well
>> >
>> > ~/Downloads$ ./qt-enterprise-linux-x64-android-5.6.1-1.run -platform
>> > minimal
>> > Unknown option: p, l, a, t, f, o, r, m
>>
>> Looks like the installer eats the options that QGuiApplication needs. Try
>> this
>> instead:
>>
>> export QT_QPA_PLATFORM=minimal

There's an "offscreen" one as well that works on Linux/MacOS/Widnows,
I use it for automated tests on a headless system.

Chris

>>
>
> I have tested this method on a VM without X. It works.
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] how to install qt enterprise using command line only?

[Ben Lau]

On 7 July 2016 at 12:42, Thiago Macieira  wrote:

> On quinta-feira, 7 de julho de 2016 10:29:43 PDT Лагнер, Сергей wrote:
> > Does not work as well
> >
> > ~/Downloads$ ./qt-enterprise-linux-x64-android-5.6.1-1.run -platform
> minimal
> > Unknown option: p, l, a, t, f, o, r, m
>
> Looks like the installer eats the options that QGuiApplication needs. Try
> this
> instead:
>
> export QT_QPA_PLATFORM=minimal
>
>
I have tested this method on a VM without X. It works.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

[Uwe Rathmann]

On Wed, 06 Jul 2016 18:10:37 +, J-P Nurmi wrote:

> Interesting choice. I would have done the exact opposite. Application
> logic in C++ and UI declaration in QML.

Well this is actually not a choice - we  did it in QML and ended up with 
a disappointing performance, because of QML. And we did it exactly like 
you recommend - we simply have a lot of UI.

> Declaring fluid animated UIs in
> QML is a joy, writing animations in C++ is not so.

In case of the animations QML offers a compact syntax to access a library 
of C++ classes mostly setting up a QPropertyAnimation. Using similar ( or 
even the same ) classes from C++ is not uncomfortable either.

My experience so far is, that using Qt/Quick from C++ does not have to be 
that different from writing a widget application: creating controls, 
setting up signal/slot connections and arranging them into layouts.

The graphic stack behind is irrelevant for the vast majority of the 
application code and I disagree with Thiago, that it is not possible to 
implement controls with a similar API as their widget counterparts.

Uwe


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Utilizing the GPU, how to start?

[André Somers]

Op 06/07/2016 om 21:17 schreef André Pönitz:

On Wed, Jul 06, 2016 at 08:34:44AM +0200, André Somers wrote:

Note that even if you define your GUI in QML, you can still do
everything else in C++. The QML doesn't have to be much more than what
you already have as .ui files now, and they are not C++ either are
they?

I keep hearing "If done well, QML is no worse that .ui", but why would
that matter to me? Most of my widgets are done in code, refactoring
typically "just works", and it's typically less(!) lines than doing the
same thing in QML.

I did not mention better or worse. It's different, and it is what you 
need to use to make full use of the GPU. If that is not needed for your 
usecase, widgets may suit your needs better. Great! There is nothing 
wrong with widgets if you ask me, and I think that there is still plenty 
of room for development there even if the official status is "done". But 
it is never going to be as performant graphically as Quick 2 is. As long 
as you ('all) are aware of its limitations, it's still a great and 
mature technology.


André
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest