Re: [Development] Proposal to include QtGamepad as an add-on module

[Mike Krus]

+1, will be useful for the tvOS remote!


Mike

On 25/01/2016 15:37, Agocs Laszlo wrote:

Hello,

The Qt Gamepad module has been living in a qt-labs repo (*) for some
time. I’d like to propose to upgrade it to an add-on module and include
it as a Tech Preview in Qt 5.7. This would also benefit other modules,
for instance Qt 3D has pending contributions for gamepad support via the
Qt Gamepad module.

As the maintainer I’m proposing Andy Nichols.

Best regards,

Laszlo

(*) http://code.qt.io/cgit/qt-labs/qtgamepad.git/



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




--
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44-1625-809908Mobile +44 7833 491941
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] tvOS port

[Hausmann Simon]

Awesome work :)



Simon


From: Development  on behalf of Mike Krus 

Sent: Monday, January 25, 2016 21:06
To: Qt Development Group
Subject: [Development] tvOS port

Hi

during the xmas break, I took "advantage" of the dreadful weather to 
investigate porting Qt5 (dev branch) to Apple's tvOS.

Due to tvOS being mostly built upon iOS, the initial work was quite straight 
forward, adding a new mkspec, a new configure option, a CONFIG variable (tvos), 
enabling and disabling things where appropriate.  [1]

Past the initial prototyping, most of the work has been focused on reducing the 
duplication in the build configuration, following initial feedback on gerrit. 
Have learned more about prf files than I ever wanted to know :)

Most relevant modules have been updated to build for tvOS, but with very 
limited testing.

Beyond testing, key challenge remaining is the user interaction. Due to the 
lack of direct touch, or even a mouse cursor, handling focus, mouse areas, etc, 
will require more careful work.

As always, feedback and suggestions will be greatly appreciated.


Mike


[1] pending changelists:
https://codereview.qt-project.org/144800
https://codereview.qt-project.org/145174
https://codereview.qt-project.org/145519

--
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44-1625-809908Mobile +44 7833 491941
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to include QtGamepad as an add-on module

[Knoll Lars]

And another +1 from me. 

Cheers,
Lars




On 26/01/16 08:42, "Development on behalf of Mike Krus" 
 wrote:

>+1, will be useful for the tvOS remote!
>
>
>Mike
>
>On 25/01/2016 15:37, Agocs Laszlo wrote:
>> Hello,
>>
>> The Qt Gamepad module has been living in a qt-labs repo (*) for some
>> time. I’d like to propose to upgrade it to an add-on module and include
>> it as a Tech Preview in Qt 5.7. This would also benefit other modules,
>> for instance Qt 3D has pending contributions for gamepad support via the
>> Qt Gamepad module.
>>
>> As the maintainer I’m proposing Andy Nichols.
>>
>> Best regards,
>>
>> Laszlo
>>
>> (*) http://code.qt.io/cgit/qt-labs/qtgamepad.git/
>>
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>
>
>-- 
>Mike Krus | mike.k...@kdab.com | Senior Software Engineer
>KDAB (UK) Ltd., a KDAB Group company
>Tel: UK Office +44-1625-809908Mobile +44 7833 491941
>KDAB - The Qt Experts
>___
>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] Proposal to include qtscxml as Qt add-on module

[Knoll Lars]

+1 for making it a TP in 5.7 and another +1 for Erik becoming the maintainer.

Cheers,
Lars



On 25/01/16 19:49, "Development on behalf of Turunen Tuukka" 
 wrote:

>
>+1
>
>State machine framework has been part of Qt for many years and there was also 
>some work earlier for scxml compatibility, which was never completed. SCXML is 
>an industry standard format, which can be exported from multiple different 
>tools.
>
>Yours,
>
>Tuukka
>
>> Blasche Alexander  kirjoitti 25.1.2016 
>> kello 16.55:
>> 
>> Hi,
>> 
>> As part of the renewed publishing process following the new KDE Free Qt 
>> foundation agreement,  we'd like to publish the source of the new Qt SCXML 
>> module.
>> 
>> I'd like to propose the module to be accepted as part of the Qt add-on 
>> modules. The module itself is brand new as well (target is a 5.7 TP). 
>> Initially it would have been part of our Qt Automotive effort. It permits 
>> the definition of state machines using SCXML and generates relevant Qt C++ 
>> state machines at compile time or runtime.
>> 
>> As maintainer I'd like to propose Erik Verbruggen.
>> 
>> --
>> Alex
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to include qtscxml as Qt add-on module

[Helio Chissini de Castro]

Hello

I'm just curious, is Qt project aiming for be a umbrella of libraries tied
to Qt release or this libraries like QtGamePad on other thread
should be more suitable to something like inqlude.org ( or similar ).


Just to clarify, as a distro packager too.

[]'s



On Tue, Jan 26, 2016 at 8:47 AM, Knoll Lars 
wrote:

> +1 for making it a TP in 5.7 and another +1 for Erik becoming the
> maintainer.
>
> Cheers,
> Lars
>
>
>
> On 25/01/16 19:49, "Development on behalf of Turunen Tuukka" <
> development-boun...@qt-project.org on behalf of
> tuukka.turu...@theqtcompany.com> wrote:
>
> >
> >+1
> >
> >State machine framework has been part of Qt for many years and there was
> also some work earlier for scxml compatibility, which was never completed.
> SCXML is an industry standard format, which can be exported from multiple
> different tools.
> >
> >Yours,
> >
> >Tuukka
> >
> >> Blasche Alexander  kirjoitti
> 25.1.2016 kello 16.55:
> >>
> >> Hi,
> >>
> >> As part of the renewed publishing process following the new KDE Free Qt
> foundation agreement,  we'd like to publish the source of the new Qt SCXML
> module.
> >>
> >> I'd like to propose the module to be accepted as part of the Qt add-on
> modules. The module itself is brand new as well (target is a 5.7 TP).
> Initially it would have been part of our Qt Automotive effort. It permits
> the definition of state machines using SCXML and generates relevant Qt C++
> state machines at compile time or runtime.
> >>
> >> As maintainer I'd like to propose Erik Verbruggen.
> >>
> >> --
> >> Alex
> >> ___
> >> Development mailing list
> >> Development@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> >___
> >Development mailing list
> >Development@qt-project.org
> >http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Jędrzej Nowacki]

On Friday 22 of January 2016 08:50:52 Thiago Macieira wrote:
> On Friday 22 January 2016 11:26:55 Bogdan Vatra wrote:
> > AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason
> > why  not start using them in Qt 6.0 ?
> 
> Yes. There's a couple of man-decades worth of work to make entire Qt thread-
> safe. Then there's the whole discussion about what to do in OOM situations
> and whether we can even reliably detect them, which I won't rehash here.
> 
> If you meant it restricted to a few classes, like containers, that's
> achievable within one year. If we decide to do that, to make it truly useful
> we probably should extend to all value-type classes, like QString and
> QNetworkProxy.

I agree, making Qt exception safe is close to impossible in the current 
situation. We could maybe go to basic level of exception safety by adding GC. 
I'm not sure if it is worth it. I like exceptions but Qt is not designed to 
use them.

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

[Development] Proposal to include qtscxml as Qt add-on module

[Blasche Alexander]

Hi,

As part of the renewed publishing process following the new KDE Free Qt 
foundation agreement,  we'd like to publish the source of the new Qt SCXML 
module.

I'd like to propose the module to be accepted as part of the Qt add-on modules. 
The module itself is brand new as well (target is a 5.7 TP). Initially it would 
have been part of our Qt Automotive effort. It permits the definition of state 
machines using SCXML and generates relevant Qt C++ state machines at compile 
time or runtime.

As maintainer I'd like to propose Erik Verbruggen.

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

Re: [Development] Stepping down as Windows Embedded Compact port maintainer

[Knoll Lars]

On 25/01/16 14:54, "Development on behalf of Giuseppe D'Angelo" 
 
wrote:

>Il 23/10/2015 22:19, Hausmann Simon ha scritto:
>> +1x2
>
>Howdy,
>
>was this nomination somehow lost in the process? 

Looks like it. Sorry for that. 
 

>I guess enough time has 
>passed to make Andreas both Approver and WinCE maintainer!

He was already listed as the maintainer, but was not in the approvers list in 
gerrit. Should be all fixed now.

Congratulations Andreas!

Cheers,
Lars


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

Re: [Development] Proposal to include qtscxml as Qt add-on module

[Turunen Tuukka]

+1

State machine framework has been part of Qt for many years and there was also 
some work earlier for scxml compatibility, which was never completed. SCXML is 
an industry standard format, which can be exported from multiple different 
tools.

Yours,

Tuukka

> Blasche Alexander  kirjoitti 25.1.2016 
> kello 16.55:
> 
> Hi,
> 
> As part of the renewed publishing process following the new KDE Free Qt 
> foundation agreement,  we'd like to publish the source of the new Qt SCXML 
> module.
> 
> I'd like to propose the module to be accepted as part of the Qt add-on 
> modules. The module itself is brand new as well (target is a 5.7 TP). 
> Initially it would have been part of our Qt Automotive effort. It permits the 
> definition of state machines using SCXML and generates relevant Qt C++ state 
> machines at compile time or runtime.
> 
> As maintainer I'd like to propose Erik Verbruggen.
> 
> --
> Alex
> ___
> 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] tvOS port

[Mike Krus]

Hi

during the xmas break, I took "advantage" of the dreadful weather to 
investigate porting Qt5 (dev branch) to Apple's tvOS.

Due to tvOS being mostly built upon iOS, the initial work was quite straight 
forward, adding a new mkspec, a new configure option, a CONFIG variable (tvos), 
enabling and disabling things where appropriate.  [1]

Past the initial prototyping, most of the work has been focused on reducing the 
duplication in the build configuration, following initial feedback on gerrit. 
Have learned more about prf files than I ever wanted to know :)

Most relevant modules have been updated to build for tvOS, but with very 
limited testing.

Beyond testing, key challenge remaining is the user interaction. Due to the 
lack of direct touch, or even a mouse cursor, handling focus, mouse areas, etc, 
will require more careful work.

As always, feedback and suggestions will be greatly appreciated.


Mike


[1] pending changelists:
https://codereview.qt-project.org/144800
https://codereview.qt-project.org/145174
https://codereview.qt-project.org/145519

-- 
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44-1625-809908Mobile +44 7833 491941
KDAB - The Qt Experts


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to include QtGamepad as an add-on module

[Bogdan Vatra]

+1

BogDan.
On Monday 25 January 2016 15:37:45 Agocs Laszlo wrote:
> Hello,
> 
> The Qt Gamepad module has been living in a qt-labs repo (*) for some time.
> I'd like to propose to upgrade it to an add-on module and include it as a
> Tech Preview in Qt 5.7. This would also benefit other modules, for instance
> Qt 3D has pending contributions for gamepad support via the Qt Gamepad
> module.
> 
> As the maintainer I'm proposing Andy Nichols.
> 
> Best regards,
> Laszlo
> 
> (*) http://code.qt.io/cgit/qt-labs/qtgamepad.git/

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

Re: [Development] Proposal to include QtGamepad as an add-on module

[Sean Harmer]

On 25/01/2016 15:37, Agocs Laszlo wrote:


Hello,

The Qt Gamepad module has been living in a qt-labs repo (*) for some 
time. I’d like to propose to upgrade it to an add-on module and 
include it as a Tech Preview in Qt 5.7. This would also benefit other 
modules, for instance Qt 3D has pending contributions for gamepad 
support via the Qt Gamepad module.




+1


As the maintainer I’m proposing Andy Nichols.



And another +1

Cheers,

Sean


--
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

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

Re: [Development] Proposal to include qtscxml as Qt add-on module

[Kevin Funk]

On Monday, January 25, 2016 02:55:27 PM Blasche Alexander wrote:
> Hi,
> 
> As part of the renewed publishing process following the new KDE Free Qt
> foundation agreement,  we'd like to publish the source of the new Qt SCXML
> module.
> 
> I'd like to propose the module to be accepted as part of the Qt add-on
> modules. The module itself is brand new as well (target is a 5.7 TP).
> Initially it would have been part of our Qt Automotive effort. It permits
> the definition of state machines using SCXML and generates relevant Qt C++
> state machines at compile time or runtime.
> 
> As maintainer I'd like to propose Erik Verbruggen.

+1

Nice to see the state machine framework moving forward (and being enhanced 
with additional tooling)

/me is interested in checking out the new Qt SCXML module!

Thanks,
Kevin

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

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Doc: Making it easier for devs to know if a class is supported on a given platform

[Smith Martin]

I suppose the default should be that a class is fully supported on all Qt 
platforms, so the qdoc command should be \notsupported with the list of not 
supported platforms.


\notsupported 


...could appear in a \class or a \fn or in a \qmltype or \qmlmethod.


martin



From: Development  on behalf of Sze Howe 
Koh 
Sent: Saturday, January 23, 2016 4:30 AM
To: development@qt-project.org
Subject: [Development] Doc: Making it easier for devs to know if a class is 
supported on a given platform

Hi all,

With the proliferation of supported platforms and add-on modules, we now have a 
situation where some classes are only useable on particular platforms. There've 
been cases where a developer sees a class in the Qt docs and thinks "Ooh, this 
is just what I need!", only to find out (after spending time studying examples 
and writing code) that the class can't be used on their platform of interest. 
[1]

It would be nice to help them find out earlier whether a class is available or 
not.

We currently have some documentation, e.g. http://doc.qt.io/qt-5/qtmodules.html 
lists "Target Platforms" for add-on modules. However, a user who finds the 
class ref via a search engine might miss this.
All Modules | Qt 5.5
doc.qt.io
If you use qmake to build your projects, the Qt Core and Qt GUI modules are 
included by default. To link only against Qt Core, add the following line to 
your .pro file:



One idea is to add a "Target Platforms" row in the class reference, below the 
"Header", "qmake", and "Inherits" rows. qdoc could populate this for each class 
based on info provided about the module.

However, we have a situation in Qt Multimedia where the module is broadly 
available, but particular features are not: 
https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends so Qt Multimedia is available 
on iOS but QAudioProbe is not.

The previous idea for an auto-populated "Target Platforms" row would be 
erroneous in this case. Perhaps we could have a per-class "\supports" qdoc 
command, or even manually type in a line saying "This class is (not) supported 
on _"? (I'm happy to spend time doing this, but it's not a very 
maintainable solution)

Any other thoughts/ideas? (I haven't thought through QML types yet)


Regards,
Sze-Howe

[1] http://forum.qt.io/topic/63110/list-of-video-formats-qt-supports/14?page=2
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Ziller Eike]

> On Jan 23, 2016, at 1:12 AM, Kevin Kofler  wrote:
> 
> Ziller Eike wrote:
>>> I would like that trend to continue. The likely next candidates are
>>> threads, futures and locks.
>> 
>> +1
> 
> I wonder why everyone so far agreed on that. So let me dissent: I think 
> having these things in Qt with Qt-style APIs is a good thing and I don't see 
> why we should discard our solution for the STL one. At most, where it makes 
> sense, we could wrap the STL stuff as we're doing with std::atomic.

The +1 statement above doesn’t mean that there is no room for convenience on 
top of the std features, and integrating them with Qt features like 
signals/slots.

E.g. std::future doesn’t support asynchronous result reporting (some thread has 
at some point to block for getting the result in the end), or progress 
reporting, something that the QFutureInterface, QFuture, QFutureWatcher triple 
provides. (Though, also only partially in Qt. We added more within Qt Creator, 
which was supposed to migrate to Qt but didn’t make it.)
That still means that any Qt solution to that should best only be convenience 
around std::future and std::thread and the async algorithms that will probably 
come to C++ at some point.
We will want to not block ourselves from coming C++ features like 
future.then(...) and so on.

> I find it much nicer and more readable if I can just write sort(v).
> 
> +1!
> 
> And I don't think ranges are the answer here. It's just another layer of 
> overengineered abstraction (as they will surely be implemented as a pair of 
> iterators in practice) when in 99+% of the cases you just want to operate on 
> the whole container anyway.
> 
>> Or "const List foos = transformed(myThings, ::foo);"
>> instead of "List foos; std::transform(myThings.begin(), myThings.end(),
>> std::back_inserter(foos), std::mem_fn(::foo));” (notice that “foos”
>> is also not const in the “pure" std version)
> 
> Wow, the STL version is horrible! std::back_inserter is particularly ugly, 
> and the usual misleading STL name (which suggests "backwards", when actually 
> it means "to the back", so when inserting multiple elements, forward) does 
> not help either.
> 
>> We started some experiments with convenience wrappers for std algorithms
>> for use in Qt Creator when we started requiring C++11:
>> http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h
> 
> Interesting. That could be a starting point for a QtAlgorithms successor.
> 
>>> why do they use C++ if they so hate it?
>> 
>> Maybe they don’t hate it, but still wished it had a less verbose API if
>> you don’t need the verbosity.
> 
> The funny thing is that only redundant boilerplate is verbose in the STL. 
> The stuff that matters, the API names, are horribly terse (e.g. "deque").
> 
> And I don't hate the C++ language, only its standard library. The language 
> is actually great, much better than Java or Python. So, since Qt lets me not 
> touch the STL with a 10-foot pole, I see no problem with using C++. (Qt is 
> also by far the best class library out there.)
> 
>Kevin Kofler
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
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

___
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] What kind of airplane we want to build?

[Ziller Eike]

> On Jan 23, 2016, at 1:47 AM, Thiago Macieira  
> wrote:
> 
> On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote:
>> I feel it's actually TOO rapidly changing. C++11 even threw out C
>> compatibility, not only by not adopting all C99 improvements (e.g. VLAs),
>> but also by subtly interpreting even as simple valid C90 code as "auto x =
>> 1.5;" in an incompatible way. (OK, that code is not valid C++98, but at
>> least a C++98 compiler would tell you what is wrong with it, C++11 just
>> silently gives it a different meaning.)
> 
> I disagree with you on all points here. C++ is *not* moving too fast. In some 
> areas, it's not moving even fast enough: where's the reflection support? 
> Meanwhile, discussions linger in the standards proposal mailing list about 
> how 
> many templates we need for parsing a string to integer.
> 
> Specifically on VLAs, the proposal was added to C++14, but dropped due to 
> disagreement. C++ would have implemented a subset of C99's requirement, but 
> not the controversial parts like taking a sizeof and getting the runtime size 
> and passing them as parameters. The less we talk about
>   void f(int n, char array[static n]);
> the better.
> 
> On auto, it's not a big loss. So what if it's incompatible between C and C++? 
> NO ONE writes "auto" anymore in C, since the only place where you can use it 
> are places where it's redundant. As for the case you showed, even C99 
> deprecated it.
> 
> I miss designated initialisers and that is a shame. When that comes around, 
> the discussion always goes on to talk about named parameters, which meets 
> stiff resistance in the committee.
> 
>> I consider the fix of the "have to write '> >' to close double templates"
>> issue as the most useful improvement in the entire C++11 standard.
> 
> Not variadic templates? Not constexpr? Not decltype? Not rvalue references?

Variadic templates + decltype + SFINAE/type_traits + universal references are 
able to reduce several thousand lines of very limited functionality, 
repetitive, unreadable QtConcurrent code, to probably something like a few 
hundred lines with more features and better behavior (e.g. unlimited arguments 
and argument types, movable types).
I'd see most of 
http://code.qt.io/cgit/qt/qtbase.git/tree/src/concurrent/qtconcurrentstoredfunctioncall.h
 and http://code.qt.io/cgit/qt/qtbase.git/tree/src/concurrent/qtconcurrentrun.h 
would just be gone.

> By the way, if you Google for "C++ most vexing", you'll see a problem that is 
> still not solved and probably won't be.
> 
>> Please do not make major changes to Qt that break all existing code, or even
>> replace it with something entirely different. It causes major pain. There
>> is useful software out there still stuck on Qt 3 years after Qt 4.0.0, and
>> the changes you suggest would be even much worse than the Qt 3 to 4
>> transition.
> 
> We will have to eventually break some things. Compatibility with old code has 
> kept QIODevice stuck in time, unable to move forward and implement important 
> things like zero-copy buffering.
> -- 
> 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

-- 
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

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

Re: [Development] Charts and DataVis Questions

[Rutledge Shawn]

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.

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.

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).

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 how the data looks, which I’ve been 
implementing (only on the CPU so far):

http://skemman.is/stream/get/1946/15343/37285/3/SS_MSthesis.pdf

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

[Development] HEADS UP: Qt 5.6.0 branching ongoing

[Heikkinen Jani]

‘5.6.0’ branch is now available, please start using it for the changes targeted 
to Qt5.6.0 release. 

We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be 
enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All 
new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on.

Target is to release Qt5.6.0 RC quite soon so please make sure all blockers 
will be fixed as soon as possible. Blocker list here: 
https://bugreports.qt.io/issues/?filter=17225 
Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 
5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize 
changes between RC and final.

And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 
bug fixes mostly, in some special cases p2 fixes might be ok as well).

Best regards,
Jani Heikkinen
Release Manager | The Qt Company

The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland
Email: jani.heikki...@theqtcompany.com | Mobile: + 358 50 48 73 735
www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject 
Facebook: www.facebook.com/qt

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

Re: [Development] HEADS UP: Qt 5.6.0 branching ongoing

[mark diener]

Jani:

I see the 5.6.0 RC blocker list.

But what about bugs like?

Using 5.6.0 Beta: https://bugreports.qt.io/browse/QTBUG-50374

What is the criterion for entry into the blocker list?

Only core code, not tools?

Thank you,

md


On Mon, Jan 25, 2016 at 5:39 AM, Heikkinen Jani
 wrote:
> ‘5.6.0’ branch is now available, please start using it for the changes 
> targeted to Qt5.6.0 release.
>
> We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be 
> enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All 
> new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on.
>
> Target is to release Qt5.6.0 RC quite soon so please make sure all blockers 
> will be fixed as soon as possible. Blocker list here: 
> https://bugreports.qt.io/issues/?filter=17225
> Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 
> 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize 
> changes between RC and final.
>
> And please remember: Do not add any 'nice to have' -changes in anymore (P0 & 
> P1 bug fixes mostly, in some special cases p2 fixes might be ok as well).
>
> Best regards,
> Jani Heikkinen
> Release Manager | The Qt Company
>
> The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland
> Email: jani.heikki...@theqtcompany.com | Mobile: + 358 50 48 73 735
> www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, 
> @Qtproject Facebook: www.facebook.com/qt
>
> ___
> 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