[Development] Qt Charts poor dynamic/resolution with OpenGL

[jeandet]

Hi All,

We are developing in my lab a scientific data plot/analysis software
using Qt Charts module. In order to plot quite large data-sets
(XYSeries) we enabled OpenGL which produce unexpected behavior. The
plots values are grouped by X values see here:
https://ao.lpp.polytechnique.fr/s/T2HcZDtrdL0DcDi
passwd:
-Plot0 with OpenGL
-Plot1 without OpenGL

We found that it was due to float conversion with OpenGL, as far as I
know we can't safely use doubles with OpenGL since not al GPU/drivers
support it(and it increase version requirement). So for now it really
limits plots quality since float has a 23+1 bits mantissa so +/-8M
relative dynamic.

For example data with X values representing seconds since epoch(1970)
would have to store:
(2016-1970)*365*24*60*60 = 1450656000 seconds ~2^31
This indeed doesn't fit in 23 bits, to store it in a float you will
need to truncate it and you would get something close to 3 minutes
resolution.
Here is a tool to see what append.
http://babbage.cs.qc.cuny.edu/IEEE-754.old/Decimal.html

It will also fail with  non uniform X values, packets of data with a
small dX spaced by bigger dX. For example 8kSps time series grouped in
packets of 1000 points with few minutes between each packets would
fail.

That said there seems to be solutions to make the situation better. 
I think that before plotting te data we should perform a coordinate
change to fit float dynamic.
This pipeline might be implemented like this?:

CPU:  -Data domain analysis (min, max, dynamic)
CPU:  -Produce a Temporary vector of visible data centered and reduced
CPU:  -Push Temporary vector to GPU
GPU:  -Generate Vertices with or without downsampling strategy
CPU:  -Build Axes from visible bounds in data coordinates

Note that this would also work without OpenGL and the downsampling
insanely increase performances. On QCustomPlot if we replace data
containers which are QMap by QVector you can plot more than 10M points
without problems.
Here is one example with 3M points with QCustomPlot and without OpenGL:
https://hephaistos.lpp.polytechnique.fr/data/QLop_new_Features2.webm

This would imply to store two coordinate systems for Data and View.
We are happy to discuss about that and contribute to the development if
we agree on a solution.
Anyway I would be happy to have any feedback on this.

Some readings:
http://blogs.agi.com/insight3d/index.php/2008/09/03/precisions-precisio
ns/
http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-prec
ision.html
http://www.urbanrobots.com/Blogs/WW/2006/01/solving-coordinate-precisio
n-problems.html


Best regards
Alexis Jeandet
Laboratory of Plasma Physics(LPP)
http://www.lpp.fr/?lang=en
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[jeandet]

Hello,

My two cents as a Qt user and occasional Meson contributor.

I have the feeling that a Qt build system will always force the users
to choose between another tool they know but where the Qt support might
not be the best and a Qt focused tool with a good Qt support but they
will have to deal with external libs and might suffer corner cases.

What I like with Meson is the fact that Qt support isn't that bad and I
can easily link any other non Qt lib plus ship them with wrapdb. Then
cross compiling is really easy. 
Then I don't know for Qbs but small features like enabling coverage
with one simple option are nice with Meson.

As Qt user I started with qmake, I enjoyed writing projects with qmake
then I switched to CMake to make easier usage of non Qt libs and
config. Finally I switched to Meson and won't go back to CMake. I'm not
sure I would switch to Qbs unless it gets less Qt focused.

I still miss the point of making a dedicated build system instead of
contributing to more general build systems like Meson or even CMake.

Le lundi 16 octobre 2017 à 15:46 +0300, Konstantin Tokarev a écrit :
> 
> 16.10.2017, 15:06, "Kevin Kofler" :
> > Tobias Hunger wrote:
> > >  I am still missing a comparison of qbs and *current* build
> > > system options.
> > >  All I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake
> > > nor cmake
> > >  is what qbs will be competing with by the time it is ready to be
> > > used in
> > >  earnest.
> > > 
> > >  So far we excluded most possible build systems on the grounds
> > > that they do
> > >  not support the mixed host/target builds we do. That requirement
> > > is going
> > >  away. So we have more options now. Just to name two: Bazel
> > > promises great
> > >  scalability and reliability, meson claims to be simple and fast.
> > > Even
> > >  CMake made a lot of progress since version 2.x.
> > 
> > This is the first time I hear of Bazel, so it cannot be that
> > popular. The
> > fact that it is written in Java also makes it a poor fit for Qt, as
> > it would
> > make Qt depend on the huge Java stack to build.
> 
> That tool is made by Google and tailored for Google internal needs.
> As we've learned
> with gyp, they don't mind to abandon their stuff next day when
> something more cool
> and more tailored comes out.
> 
> > 
> > Meson is, as far as I can tell (I had already looked at it a couple
> > times),
> > mostly a CMake clone written in Python. I fail to see how it is
> > conceptually
> > any different from (let alone better than) CMake. It is mainly
> > pushed by
> > GNOME developers who are fed up of stone-age autotools, but
> > apparently do
> > not want to use the same thing KDE uses (CMake) just because KDE
> > uses it.
The huge difference is the fact that it is a description langage, no
function no macro.
> 
> I have no real experience with Meson, but at least it has following
> advantages:
> 
> * Its language is typed(!), has native support for arrays(!), and
> functions/methods have
> first-class return values(!)
> * Its language has native support for properties, with syntax that
> really looks like
> properties in another languages
> * It is target-oriented from the start and is not so burdened by
> legacy ways of doing
> things wrong, which plague old CMake projects and confuse newcomers
> * It is written in scripting language, so it's easier to add (and
> possibly distribute) new
> functionality without getting it through upstream hands first.
> 
> That said, I totally dislike the idea of inventing restricted DSL
> language for build system
> instead of using general purpose language (like e.g. in QBS or
> Premake).
Not being Turing complete is a choice and makes it really clear at the
end. I don't know Qbs but looking the doc and the rules stuff seems
like Qbs allows functions.
> 
> > 
> > Kevin Kofler
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Getting build flags for platforms without pkg-config

[jeandet]

Le lundi 30 octobre 2017 à 19:11 +0300, Konstantin Tokarev a écrit :
> 
> 30.10.2017, 18:53, "Konstantin Tokarev" :
> > 30.10.2017, 18:43, "Thiago Macieira" :
> > >  On segunda-feira, 30 de outubro de 2017 08:27:02 PDT Konstantin
> > > Tokarev wrote:
> > > >   >> $ cmake --find-package -DNAME=Qt5Core -DCOMPILER_ID=GNU
> > > > -DLANGUAGE=CXX
> > > >   >> -DMODE=COMPILE
> > > >   >> -I/home/apol/devel/kde5/include/
> > > >   >> -I/home/apol/devel/kde5/include/QtCore
> > > >   >> -I/home/apol/devel/kde5/lib64//mkspecs/linux-g++
> > > >   >
> > > >   > -DQT_CORE_LIB is missing. Any volunteers to add it to the
> > > > cmake files?
> > > > 
> > > >   It is already set:
> > > 
> > >  If it's already set, why is it missing?
> > 
> > Apparently because cmake's imitation of pkg-config is half-assed.
> 
> So, it seems to me that the most reasonable way to support more build
> systems
> without duplicating data between them is to enhance pkg-config
> support. In fact,
> .pc files can be as rich as our .pri modules, containing extra data
> in custom
> variables, and build systems can rely on original pkg-config tool or
> parse .pc files
> directly (it's a simple declarative format, if variable substitutions
> are not used).
> 
> AFAIK there no technical reason why providing .pc files for MSVC and
> macOS
> frameworks would be impossible.
I agree, I would add that and even without pkg-config parsing pc files
seems more reasonable than parsing pri files.
> 
> > 
> > >  --
> > >  Thiago Macieira - thiago.macieira (AT) intel.com
> > >Software Architect - Intel Open Source Technology Center
> > > 
> > >  ___
> > >  Development mailing list
> > >  Development@qt-project.org
> > >  http://lists.qt-project.org/mailman/listinfo/development
> > 
> > --
> > Regards,
> > Konstantin
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Charts and DataVis Questions

[Alexis Jeandet]

Hi,

I have few naive questions about Charts and DataVis modules.

1) As I understand DataVis module is mainly a 3d data visualization
module while Charts is mainly a 1d data visualization module. Why not
merging them to a unique data visualization module?
In my lab scientists are interested in plotting 1d data in 3d or 2d
plots. For example in space Physics people might be interested in
plotting spacecraft electric potential vs time while looking particles
spectrograms vs time.

2) The OpenGL acceleration in Charts module is really impressive, but I
wonder why trying to draw big amount of points when the screen
resolution is limited and why not integrating a king of downsampling
algorithm as explained here:
http://skemman.is/stream/get/1946/15343/37285/3/SS_MSthesis.pdf
Or as implemented here:
https://gitlab.com/DerManu/QCustomPlot/blob/master/src/plottables/plott
able-graph.cpp#L1353
This would also reduce the memory usage of the graph.

In this question I assume that OpenGL acceleration is used to plot
bigger datasets I might be wrong.

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

Re: [Development] Charts and DataVis Questions

[Alexis Jeandet]

Le samedi 23 janvier 2016 à 12:45 +, Uwe Rathmann a écrit :
> Hi,
> 
> > The OpenGL acceleration in Charts module is really impressive ...
> 
> Unfortunately part of the truth is, that the performance of the
> software 
> renderer does not necessarily be that far behind.
The test I did with QCharts gave me something like 6x speedup.
> 
> An example: in a test program I'm creating a polygon of 1 points
> in 
> an area of 1000x1000 using (qAbs(random) % 1000) and then I'm drawing
> it 
My experience with polygons and Qt is that you will really increase
drawing performances if you divide them in smaller ones. I found that
the relation between the number of edges of a polygon and the drawing
time wasn't linear. With this naive algorithm I got good rendering
speedups:
https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/I
NSTRUMENTATION/kicadtools/files/b59e8f9f12322445df6df1e8fe1090ef7f6cafc
4/test/PCBView/pcbzone.cpp#L123
In your case I don't know since you draw it manually with drawPolyline.

Anyway my point isn't to make faster a the rendering of big datasets
but avoiding to draw them with some downsampling algorithms. Even if we
succeed to render 1 million of points smoothly it won't scale at 10M it
will suck a lot of memory for nothing.
> this way:
> 
> void draw( const QPolygonF , QPaintDevice  )
> {
> QPainter painter(  );
> painter.setPen( QPen( Qt::black, 2 ) );
> painter.drawPolyline( points );
> painter.end();
> }
> 
> 
> As I want to compare hardware vs. software renderer I'm using Qt 4.8
> with 
> X11 ( "native" ) as backend. Here drawing to a QImage uses the
> software 
> renderer, while drawing to a pixmap is usually hardware accelerated.
> 
> To make it comparable I'm converting the pixmap to an image, so that
> I 
> have the same input and the same output.  ( in case you are
> interested I 
> added the code at the end of this posting. )
> 
> O.k. this is what I see with Qt 4.8:
> 
> - Raster 735ms
> - X11 120ms
> 
> When doing the same with a Qt-5.6 beta:
> 
> - Raster 775ms
> - X11 775ms ( no surprise )
> 
> 
> Next I modified the draw method a bit:
> 
> void draw( const QPolygonF , QPaintDevice  )
> {
> QPainter painter(  );
> painter.setPen( QPen( Qt::black, 2 ) );
> 
> const int numPoints = 100;
> const int numChunks = points.size() / numPoints;
> for ( int i = 0; i < numChunks; i++ )
> {
> painter.drawPolyline( points.constData() + i * numPoints, 
> numPoints );
> }
> painter.end();
> }
> 
> ( of course this is not exactly the same as the pixels to join the
> chunks 
> at there ends are missing ).
> 
> Now the result is:
> 
> Raster ( Qt 4.8 ): 382ms
> Raster ( Qt 5.6 ): 403ms
> 
> When using a chunk size ( = numPoints ) of 10 I have:
> 
> Raster ( Qt 4.8 ): 192
> Raster ( Qt 5.6 ): 181
> X11( Qt 4.8 ):  93
> 
> In the end the implementation of a chart package is full of finding
> and 
> implementing workarounds and optimizations like this one - at least
> this 
> is my experience with being the maintainer of a chart package ( Qwt
> ) 
> over the years.
> 
> Uwe
> 
> --
> 
> 
> QImage renderRaster( const QPolygonF  )
> {
> QImage img( 1000, 1000, QImage::Format_RGB32 );
> img.fill( Qt::white );
> 
> QElapsedTimer timer;
> timer.start();
> 
> draw( points, img );
> 
> qDebug() << "Raster" << timer.elapsed();
> 
> return img;
> }
> 
> QImage renderX11( const QPolygonF  )
> {
> QPixmap pm( 1000, 1000 );
> pm.fill( Qt::white );
> 
> QElapsedTimer timer;
> timer.start();
> 
> draw( points, pm );
> 
> const QImage img = pm.toImage();
> qDebug() << "X11" << timer.elapsed();
> 
> return img;
> }
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Charts and DataVis Questions

[Alexis Jeandet]

Le lundi 25 janvier 2016 à 10:20 +, Rutledge Shawn a écrit :
> > On 23 Jan 2016, at 19:52, Sean Harmer  wrote:
> > 
> > On 23/01/2016 12:45, Uwe Rathmann wrote:
> > >  Hi,
> > > 
> > > > The OpenGL acceleration in Charts module is really impressive
> > > > ...
> > > Unfortunately part of the truth is, that the performance of the
> > > software
> > > renderer does not necessarily be that far behind.
> > Now try it against OpenGL with 100k points rendering to a 4k
> > screen. The difference between software and hardware will increase
> > with those parameters (up to some fill rate or vertex rate that the
> > hardware can handle).
> You especially don’t want to do antialiasing with the software
> renderer (been there done that: it was about 2008 and using AA when
> rendering a QPainterPath made it several times slower than without),
> whereas vertex antialiasing with OpenGL is doable.  QtCharts so far
> uses GL_LINES for the line graph, but AFAIK the only way to get
> antialiasing with that approach is to turn on multi-sampling, which
> performs well only on certain desktop graphics cards (line graphs are
> simple enough, but it wouldn’t be so great to turn on MSAA in the
> whole QtQuick scene if your app is complex and you expect it to be
> portable).  I’ve been working on an antialiasing line graph, outside
> of Qt Charts so far though.  It’s similar to
> qtdeclarative/examples/quick/scenegraph/graph but does mitering right
> in the vertex shader, and antialiasing by setting the transparency
> proportional to distance away from the virtual line, in the fragment
> shader.
> 
> And of course with GPU rendering you can have full-frame-rate
> dynamism, whether the data is actually changing that fast or you are
> interacting - zooming, panning, moving a time cursor to see the
> corresponding data point, etc.  My laptop can render 60FPS while
> keeping the CPU at its lowest clock rate.  Or maybe a raspberry pi
> would have sufficient power to run an oscilloscope display, with the
> trace so smooth that it looks like an analog scope; I haven’t tried
> that, but it would make a nice demo.
Yes not only, for embedded measurement there would be a lot of
users

> 

> 

> 
> Data modelling is another consideration.  I think the holy grail would be if 
> we could send the actual data to the GPU unmodified, and render it there.  
> Vertex AA requires generating duplicate vertices though, to be able to expand 
> them away from
>  the line, to give it thickness.  So, for speed (but not memory conservation) 
> we want to keep that array of vertices around, add new datapoints to one end 
> and remove old ones from the other - as opposed to generating vertices each 
> time we render one frame.
>   So it needs to have that kind of API, and you then should try to minimize 
> any additional copying: store the data how you like but manage the vertices 
> incrementally, or add each new sample to the vertex array and don’t bother 
> keeping your own copy.  So I tried
>  writing a data model which works that way: it stores the vertices on behalf 
> of the rendering code, without exposing them directly in the API.  Whereas 
> QLineSeries both stores data and renders it, as you can see in the example 
> with the use of the append() function.
>   So maybe it could be refactored so that you can instead implement a model 
> by subclassing an abstract base class, similar to the way that QListWidget is 
> a QListView with an internal model, whereas in non-trivial applications you 
> write your own QAIM and use
>  QListView and/or QML ListView.  But a time series is just one kind of data, 
> and only makes sense with certain types of visualization.  So we could follow 
> through and write abstract model classes for other kinds of data that can be 
> visualized, but this kind
>  of modelling amounts to making assumptions, which requires a lot of care to 
> keep it as widely applicable as possible.
Indeed, the openglseries example, sucks 1,6GB for  2x500 points
that makes around 160B per data point. Also the perfs are really bad
where QCustomPlot(modified to use QVectors) may be faster without
OpenGL.

> 

> 

> 
> Later I want to try using a geometry shader to expand the datapoints into 
> vertices.  That will be less portable though (won’t work on OpenGL ES).  But 
> maybe it would make zero-copy (on the CPU) visualization possible, as long as 
> you are OK to
>  model the data the way that the rendering code expects (a time-value struct, 
> just two floats or doubles per data point; or maybe two arrays, one for times 
> and one for values).
Doubles would be good when using epoch like times series with high
sampling rate.
> 

> 

> 
> My mitering shader has trouble with excessively high-frequency data, so 
> resampling is useful, to get the sample rate down to one sample per 
> horizontal pixel, or less.  There is some recent research on how to do that 
> while preserving the psychological
>  impression of 

Re: [Development] Qt Charts poor dynamic/resolution with OpenGL

[Jeandet Alexis]

Hi Uwe,
Le mardi 08 novembre 2016 à 15:06 +, Uwe Rathmann a écrit :
> On Tue, 08 Nov 2016 13:30:45 +0100, Jeandet Alexis wrote:
> 
> > Our goal is to improve QtCharts to be able to use it in our
> > scientific
> > softwares. So we need to improve the current dynamic with OpenGL
> > and/or
> > improve performances of non OpenGL plots.
> 
> Have you ever considered to use a 3rd party library like Qwt or 
> QCustomPlot. Both packages are available since years and focus on 
> scientific plots.
Indeed I do use QCP on others projects. I would say that QCP is really
nice, its downsampling method is efficient. For QWT I only checked in
the past and I had the feeling that by default you had to do many
things before you get a plot.
On QCP, the main drawbacks are the usage of QMap on pre 2.0 revisions,
the amalgamate on sources(insane for compiler).
We made the choice to use QtCharts for this new software because it is
a Qt module which reduce dependencies and its features are not that far
from what we want. 
We mainly focus on data browsing and plot interactions where QtCharts
appears to be good. That said QWT and QCP are still good candidates
too.
> 
> Being the maintainer of the Qwt package I'm some sort of a biased,
> but my 
> impression is, that the Qt Chart package has never reached a state
> being 
> even close to other solutions. And as I never saw anyone responding
> to 
> related questions on the mailing lists it also does not look like
> being a 
> very actively maintained module.
You are right but I want to give it a chance since it got opened
recently. I don't know why it got opened. I don't know if it is
considered as mature, is it just a toy? Is it abandoned by Digia/Qt?
Personally I don't know many data visualisation applications where
QtCharts would work as-is, as soon as you plot time stamped data you
may quickly fall in our trap.
On the other hand we can see activity on the repository.
So my hope is to get a decent and official Qt plotting module in the
future.
> 
> ciao,
> Uwe
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Charts poor dynamic/resolution with OpenGL

[Jeandet Alexis]

Hi Qt devs,

To continue on this topic, in my lab we plan to take an intern to work
on this. It would be a 6 month Master degree internship, starting
around February 2017. 
Does QtCharts maintainers/experts have some time to help us to advise
our intern?
It would just be for short discussions like is the new design Ok? Can
we modify this? Is QtCharts really doing this like this?...
Most of this questions would go through this list but if we can also do
few(2-3) call-conf it might be better.
Our goal is to improve QtCharts to be able to use it in our scientific
softwares. So we need to improve the current dynamic with OpenGL and/or
improve performances of non OpenGL plots.

Best regards,
Alexis.
Le mardi 19 juillet 2016 à 20:26 +0100, Sean Harmer a écrit :
> 
> On 19/07/2016 18:26, jeandet wrote:
> > Hi All,
> > 
> > We are developing in my lab a scientific data plot/analysis
> > software
> > using Qt Charts module. In order to plot quite large data-sets
> > (XYSeries) we enabled OpenGL which produce unexpected behavior. The
> > plots values are grouped by X values see here:
> > https://ao.lpp.polytechnique.fr/s/T2HcZDtrdL0DcDi
> > passwd:
> > -Plot0 with OpenGL
> > -Plot1 without OpenGL
> > 
> > We found that it was due to float conversion with OpenGL, as far as
> > I
> > know we can't safely use doubles with OpenGL since not al
> > GPU/drivers
> > support it(and it increase version requirement). So for now it
> > really
> > limits plots quality since float has a 23+1 bits mantissa so +/-8M
> > relative dynamic.
> > 
> > For example data with X values representing seconds since
> > epoch(1970)
> > would have to store:
> > (2016-1970)*365*24*60*60 = 1450656000 seconds ~2^31
> > This indeed doesn't fit in 23 bits, to store it in a float you will
> > need to truncate it and you would get something close to 3 minutes
> > resolution.
> > Here is a tool to see what append.
> > http://babbage.cs.qc.cuny.edu/IEEE-754.old/Decimal.html
> > 
> > It will also fail with  non uniform X values, packets of data with
> > a
> > small dX spaced by bigger dX. For example 8kSps time series grouped
> > in
> > packets of 1000 points with few minutes between each packets would
> > fail.
> > 
> > That said there seems to be solutions to make the situation better.
> > I think that before plotting te data we should perform a coordinate
> > change to fit float dynamic.
> > This pipeline might be implemented like this?:
> > 
> > CPU:  -Data domain analysis (min, max, dynamic)
> > CPU:  -Produce a Temporary vector of visible data centered and
> > reduced
> > CPU:  -Push Temporary vector to GPU
> > GPU:  -Generate Vertices with or without downsampling strategy
> > CPU:  -Build Axes from visible bounds in data coordinates
> 
> That's essentially the same strategy I've implemented in the past. I 
> don't know the code of Qt Charts or how easily this woudl fit into
> it 
> but as an approach I think it's sound.
> 
> Cheers,
> 
> Sean
> 
> > 
> > Note that this would also work without OpenGL and the downsampling
> > insanely increase performances. On QCustomPlot if we replace data
> > containers which are QMap by QVector you can plot more than 10M
> > points
> > without problems.
> > Here is one example with 3M points with QCustomPlot and without
> > OpenGL:
> > https://hephaistos.lpp.polytechnique.fr/data/QLop_new_Features2.web
> > m
> > 
> > This would imply to store two coordinate systems for Data and View.
> > We are happy to discuss about that and contribute to the
> > development if
> > we agree on a solution.
> > Anyway I would be happy to have any feedback on this.
> > 
> > Some readings:
> > http://blogs.agi.com/insight3d/index.php/2008/09/03/precisions-
> > precisio
> > ns/
> > http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-
> > prec
> > ision.html
> > http://www.urbanrobots.com/Blogs/WW/2006/01/solving-coordinate-
> > precisio
> > n-problems.html
> > 
> > 
> > Best regards
> > Alexis Jeandet
> > Laboratory of Plasma Physics(LPP)
> > http://www.lpp.fr/?lang=en
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> > 
> 
> ___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Future of QBS

[Jeandet Alexis]

Le mardi 17 octobre 2017 à 17:45 +0200, Giuseppe D'Angelo a écrit :
> I'm just going to ignore the bikeshedding on implementation details,
> and 
> go back to the main point of the thread, which was right here:
> 
> Il 13/10/2017 16:56, Sergio Martins ha scritto:
> > Please make something we can easily detach from the qt-project in
> > 10
> > years and have it's own ecosystem.
> > 
> > The qt-project isn't in the business of maintaining JavaScript
> > engines
> > or build systems, this model works now because TQC has manpower,
> > but if
> > something bad happens in 10 years, then it will be a maintenance
> > burden
> > and rot.
> > 
> > So IMHO, no updating QtScript with newer JavaScriptCore and no
> > adapting
> > the QML/V4 engine, go straight for pure JavaScriptCore/JerryScript
> > and
> > no linking to Qt.
> 
> This means, amongst other things:
> 
> * Get a proper website for qbs under qbs.io (the domain already
> exist, 
> but now it just redirects to the docs)
> * Host all the qbs-related resources there: mailing lists, 
> documentation, blogs, forums
> * For the end-user, remove all references to qbs as existing under
> the 
> Qt umbrella (for the developer _of_ qbs, then it's perhaps acceptable
> to 
> push patches to Qt's gerrit).
> 
> I'm firmly convinced that doing all of this is even more important
> than 
> whatever rant you might have about using JavaScript or LUA or some
> other 
> programming language.
> 
> 
> 
> (Small story: when I presented Qt Creator at CppCon last year,
> people's 
> reactions were always these two:
> 
> 1) "Oh, wait, it's a general purpose IDE? It's not just for building
> Qt 
> applications?"
You are right, but what is misleading I think is that some visible
features are for Qt(designer, QML...), then I'm not sure that it is
possible to build anything without qmake(-> without any kit). The fact
that non Qt users have to deal with Qt kits is really painfull. Except
this point, YES Qtc is a really awesome C/C++ IDE, locator, completion
and refactoring make it superior to many other IDEs. 
> 2) "Where's the download link?"
> 
> Needless to say, it's a marketing/political failure in both cases.)
> 
> 
> My 2 cents,
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Getting build flags for platforms without pkg-config

[Jeandet Alexis]

Hello,

Previously I asked about getting some defines from pkg-config, I pushed
some code on gerrit to fix that.

Now I would like to care about platforms where we don't use pkg-config, 
at first I thought that we could get compile flags from qmake but it
seems that no.
Did I miss something?
Would there be a way to get compile flags for a build system like
meson?

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

[Development] Re : Getting build flags for platforms without pkg-config

[Jeandet Alexis]

Le dimanche 29 octobre 2017 à 15:57 -0700, Thiago Macieira a écrit :
> On domingo, 29 de outubro de 2017 14:57:44 PDT Jeandet Alexis wrote:
> > Hello,
> > 
> > Previously I asked about getting some defines from pkg-config, I
> > pushed
> > some code on gerrit to fix that.
> > 
> > Now I would like to care about platforms where we don't use pkg-
> > config,
> > at first I thought that we could get compile flags from qmake but
> > it
> > seems that no.
> 
> You can get them from either qmake or cmake. The flags are saved
> there.
> 
> You should also reconsider and install pkg-config on those platforms.
> 
> > Did I miss something?
> > Would there be a way to get compile flags for a build system like
> > meson?
> 
> Either write a .pro file that prints or saves the flags, or read the 
> $$[QT_INSTALL_ARCHDATA]/mkspecs/modules/qt_lib_*.pri files.
> 
> Reading the files directly is officially looking into private API and
> we cannot 
> promise you that it will continue working. But I don't see how to do
> it 
> officially with qmake either.
I was affraid I would get this answer. How do you solve this issue with
QBS? Does qmake generate files for QBS on each Qt version or do you
hardcode stuff in QBS? 
This leads me to the conclusion that a kind of qt-pkg-config tool would
be nice. Or just expending qmake to provide this infromations.
> 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Getting defines from pkg-config for Qt modules

[Jeandet Alexis]

Hello,

I already asked this on IRC but I got no answer.
On Fedora and Ubuntu I can say that "pkg-config --cflags Qt5[any
module]" does only provides include flags and no defines such as
-DQT_CORE_LIB or -DQT_GUI_LIB.

As an example "pkg-config --cflags panelw" gives "-D_GNU_SOURCE
-D_DEFAULT_SOURCE "

So my questions are:
1) Is this normal/expected?
2) Why not providing this flags?
3) Does a patch to provides this flags would be accepted?

This would help to improve Qt support in Meson and I guess others build
systems using pkgconfig.

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

Re: [Development] Getting defines from pkg-config for Qt modules

[Jeandet Alexis]

Hello Konstantin,

Thank you for your answer.

I've never used waf, I might have a closer look into it.
After a quick check, it seems that by default it uses also pkg-config,
build/config.log from waf qt5 demo:

--
Checking for 'Qt5Scxml'
['/usr/bin/pkg-config', '--cflags', '--libs', 'Qt5Scxml']
out: -I/usr/include/qt5/QtScxml -I/usr/include/qt5
-I/usr/include/qt5/QtCore -I/usr/include/qt5/QtQml
-I/usr/include/qt5/QtNetwork -lQt5Scxml -lQt5Qml -lQt5Network
-lQt5Core 

yes
--

Then from its own tests:

--
See if Qt files compile with -fPIC
==>
#include 
int main(int argc, char **argv) {return 0;}

<==
[1/1] Compiling
build/.conf_check_95021cb6c5c41f7db87608502781c73b/test.cpp

['/usr/lib64/ccache/g++', '-fPIC', '-I/usr/include/qt5/QtCore', '-
I/usr/include/qt5', '-I/usr/include/qt5/QtWidgets', '-
I/usr/include/qt5/QtGui', '-DHAVE_QT5X11EXTRAS=1', '-DHA
VE_QT5TEST=1', '-DHAVE_QT53DRENDER=1', '-DHAVE_QT53DEXTRAS=1', '-
DHAVE_QT5OPENGL=1', '-DHAVE_QT53DQUICKRENDER=1', '-DHAVE_QT5SQL=1', '-
DHAVE_QT5XMLPATTERNS=1', '-DHAVE_QT5WEBEN
GINECORE=1', '-DHAVE_QT5POSITIONING=1', '-
DHAVE_QT5MULTIMEDIAWIDGETS=1', '-DHAVE_QT5QML=1', '-DHAVE_QT5QUICK=1',
'-DHAVE_QT5BLUETOOTH=1', '-DHAVE_QT5CORE=1', '-DHAVE_QT5SCRIPTT
OOLS=1', '-DHAVE_QT5WEBKITWIDGETS=1', '-DHAVE_QT5DATAVISUALIZATION=1',
'-DHAVE_QT5PRINTSUPPORT=1', '-DHAVE_QT5MULTIMEDIA=1', '-
DHAVE_QT5HELP=1', '-DHAVE_QT5XML=1', '-DHAVE_QT5S
VG=1', '-DHAVE_QT5WIDGETS=1', '-DHAVE_QT5GSTREAMERQUICK_1_0=1', '-
DHAVE_QT5CONCURRENT=1', '-DHAVE_QT5LOCATION=1', '-DHAVE_QT5DBUS=1', '-
DHAVE_QT5DESIGNER=1', '-DHAVE_QT5WEBSOCK
ETS=1', '-DHAVE_QT5WEBCHANNEL=1', '-DHAVE_QT5WEBKIT=1', '-
DHAVE_QT5SERIALPORT=1', '-DHAVE_QT5GSTREAMERUI_1_0=1', '-
DHAVE_QT53DLOGIC=1', '-DHAVE_QT5NFC=1', '-DHAVE_QT5GSTREAMERU
TILS_1_0=1', '-DHAVE_QT5WEBVIEW=1', '-DHAVE_QT5NETWORK=1', '-
DHAVE_QT5WAYLANDCOMPOSITOR=1', '-DHAVE_QT5GUI=1', '-
DHAVE_QT5GLIB_2_0=1', '-DHAVE_QT5SCRIPT=1', '-DHAVE_QT5QUICKCON
TROLS2=1', '-DHAVE_QT53DCORE=1', '-DHAVE_QT5GSTREAMER_1_0=1', '-
DHAVE_QT5QUICKWIDGETS=1', '-DHAVE_QT53DQUICKEXTRAS=1', '-
DHAVE_QT5GAMEPAD=1', '-DHAVE_QT5SENSORS=1', '-DHAVE_QT5
SERIALBUS=1', '-DHAVE_QT53DINPUT=1', '-DHAVE_QT53DQUICKINPUT=1', '-
DHAVE_QT5WAYLANDCLIENT=1', '-DHAVE_QT5SCXML=1', '-
DHAVE_QT5WEBENGINEWIDGETS=1', '-DHAVE_QT5CHARTS=1', '-DHAVE
_QT5QUICKTEST=1', '-DHAVE_QT5WEBENGINE=1', '-DHAVE_QT53DQUICK=1',
'../test.cpp', '-c', '-
o/home/jeandet/Documents/prog/waf/demos/qt5/build/.conf_check_95021cb6c
5c41f7db87608502
781c73b/testbuild/test.cpp.1.o']
yes
--

So at least by default it seems to behave like meson(no 
-DQT_CORE_LIB). But as you pointed out pkg-config isn't available on
all systems so improving it will only solve 50% of the problem.
This lead me to the conclusion that it would be nice to get be able to
query cflags from qmake (unless I missed something ans its already
possible)


Alexis.
Le jeudi 26 octobre 2017 à 21:37 +0300, Konstantin Tokarev a écrit :
> 
> 26.10.2017, 20:20, "Jeandet Alexis" <alexis.jean...@member.fsf.org>:
> > Hello,
> > 
> > I already asked this on IRC but I got no answer.
> > On Fedora and Ubuntu I can say that "pkg-config --cflags Qt5[any
> > module]" does only provides include flags and no defines such as
> > -DQT_CORE_LIB or -DQT_GUI_LIB.
> > 
> > As an example "pkg-config --cflags panelw" gives "-D_GNU_SOURCE
> > -D_DEFAULT_SOURCE "
> > 
> > So my questions are:
> > 1) Is this normal/expected?
> > 2) Why not providing this flags?
> 
> I think it would be correct to say that pkg-config support if a 3rd
> class citizen in Qt, after qmake and cmake
> It's not even supported on all platforms, e.g. on Windows with MSVC,
> or macOS when frameworks are built (default mode).
> 
> > 3) Does a patch to provides this flags would be accepted?
> 
> Sure, if it is implemented in a way that Ossi approves.
> 
> > 
> > This would help to improve Qt support in Meson and I guess others
> > build systems using pkgconfig.
> 
> It might be a better idea to support Qt without relying on pkg-
> config. Some 3rd party build systems do this, e.g. waf
> 
> > 
> > Best regards,
> > Alexis.
> > 
> > ,
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> -- 
> Regards,
> Konstantin___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Getting defines from pkg-config for Qt modules

[Jeandet Alexis]

Hello Thiago,
Le jeudi 26 octobre 2017 à 13:14 -0700, Thiago Macieira a écrit :
> On Thursday, 26 October 2017 10:09:49 PDT Jeandet Alexis wrote:
> > Hello,
> > 
> > I already asked this on IRC but I got no answer.
> > On Fedora and Ubuntu I can say that "pkg-config --cflags Qt5[any
> > module]" does only provides include flags and no defines such as
> > -DQT_CORE_LIB or -DQT_GUI_LIB.
> > 
> > As an example "pkg-config --cflags panelw" gives "-D_GNU_SOURCE
> > -D_DEFAULT_SOURCE "
> 
> panelw.pc is buggy
In fact I took the first one returning defines :) 
> 
> However, we should have -DQT_CORE_LIB in Qt5Core.pc. Please file an
> issue for 
> us.
> 
> > So my questions are:
> > 1) Is this normal/expected?
> > 2) Why not providing this flags?
> > 3) Does a patch to provides this flags would be accepted?
> 
> Yes, a patch adding QT_${uppercaselib}_LIB to each .pc would be
> accepted.
Awesome, thank you.
> ___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development