Re: [Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Sunday 24 January 2016 03:01:57 Kevin Kofler wrote:
> Marc Mutz wrote:
> > On Friday 22 January 2016 20:46:54 Marc Mutz wrote:
> >> Which one is faster? On a dual-core, probably QVector. On a 64-core
> >> processor,  probably std::vector.
> > 
> > Running attached test program (4 cores + 2-fold HT), I get these numbers:
>
> That's already 8 virtual cores. He wrote "on a dual-core". :-)

Not that I didn't post the code, so you could run the benchmark on your 
machine, or with numThreads hard-coded to 2...

QVector:

1: 111
2: 100
4: 111
8: 115
16: 139
32: 179
64: 204
128: 337
256: 644
512: 1287
1024: 2611
2048: 5020
4096: 10113

std::vector:

1: 63
2: 63
4: 65
8: 69
16: 119
32: 198
64: 264
128: 375
256: 735
512: 1385
1024: 2719
2048: 5545
4096: 10444

(numThread == 2, same box)

Copying is still not significantly slower than ref-counting, even for 4K 
elements.

And yes, this suprises even me, but since it perfectly matches my expecations, 
at least qualitatively, I won't spend more time trying to understand this. The 
code is there, I took great care to make it fair, now the CoW fanboys can 
explain this (or find a bug in the benchmark).

At least it seems as if the allocator has a very fast path for 
alloc/dealloc/alloc/dealloc/etc chains of a same-sized memory block.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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?

[Kevin Kofler]

Bogdan Vatra wrote:
> gcc -O2 and -O3 gives the worst/random/surprising results. On the other
> hand, clang (to my HUGE surprise) gives the most consistent results.

That doesn't surprise me all that much. I've seen REALLY strange 
benchmarking results from GCC-generated code. In particular, I had a program 
where I was trying to benchmark the win from parallelizing the code, and I 
found that the mere fact of adding -pthreads to the compiler flags, without 
actually doing ANY parallelization, was making the code FASTER. (If 
anything, it is expected to run slower, because of additional locks.)

Kevin Kofler

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:

> On Friday 22 January 2016 20:46:54 Marc Mutz wrote:
>> Which one is faster? On a dual-core, probably QVector. On a 64-core
>> processor,  probably std::vector.
> 
> Running attached test program (4 cores + 2-fold HT), I get these numbers:

That's already 8 virtual cores. He wrote "on a dual-core". :-)

Kevin Kofler

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

Re: [Development] Charts and DataVis Questions

[Sean Harmer]

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


Cheers,

Sean



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
this way:

void draw( const QPolygonF &points, QPaintDevice &paintDevice )
{
 QPainter painter( &paintDevice );
 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 &points, QPaintDevice &paintDevice )
{
 QPainter painter( &paintDevice );
 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 &points )
{
 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 &points )
{
 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] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Saturday 23 January 2016 19:22:34 Marc Mutz wrote:
> > template < class Container, class Compare >
> > void sort ( Container container, Compare compare)
> > {
> >
> >  sort(begin(container), end(container), compare);
> >
> > };
> >
> > 
> >
> > Something like that perhaps? Feel free to add as many as you think are
> > useful.
> 
> The problem is that these overloads quickly become ambiguous with existing 
> ones. So at a minimum, you need to have a special suffix (_all).Overloading
> on  concepts is needed to solve this properly.

Another way to do that is to have a special prefix of "q".
-- 
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

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

[Bogdan Vatra]

Hi,

As I promised, I did some benchmarks myself and I got some very surprising 
results.
The benchmark code is here: https://github.com/bog-dan-ro/exceptions_benchmark
The benchmark calls a function 10 times and this function trows an 
exception/return an error every x calls (x = 100; x*=10). The noexcept 
function tries to mimic Qt's way to handle errors.

The results on desktop (intel i7) are here:  https://paste.kde.org/pbdedo4mw
gcc -O2 and -O3 gives the worst/random/surprising results. On the other hand, 
clang (to my HUGE surprise) gives the most consistent results. Even more 
surprising is the fact that in most/some cases the exception code produced by 
clang is faster :O !

The results on nvidia shield X1 are here: https://paste.kde.org/pz1leberi
The results even more surprising (the percentages are bigger).

Regarding the size overhead, I tested Qt(base) with&without exceptions (rtti 
seems enabled already) and the difference is only ~1Mb (23673504 with 
exceptions and 22584408 without), but because it doesn't use try/catch 
(almost?) anywhere, the size difference is pretty small (~5%). Then I found the 
following paragraph on 
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html :
"Exception handling overhead can be measured in the size of the executable 
binary, and varies with the capabilities of the underlying operating system 
and specific configuration of the C++ compiler. On recent hardware with GNU 
system software of the same age, the combined code and data size overhead for 
enabling exception handling is around 7%. Of course, if code size is of 
singular concern than using the appropriate optimizer setting with exception 
handling enabled (ie, -Os -fexceptions) may save up to twice that, and 
preserve error checking."

So, if the size overhead of libstdc++ (which uses exceptions a LOT) is just 7% 
(+3.5% if we're using -Os), I'm pretty sure that Qt's overhead will be the 
same or even smaller.

Therefore, I see no reason not starting using exceptions in 6.0, or at least 
to think&discuss on this matter.

Cheers,
BogDan.

On Friday 22 January 2016 12:32:25 Bogdan Vatra wrote:
> On Friday 22 January 2016 10:55:34 Cristian Adam wrote:
> > On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz  wrote:
> > > I'm not sure about what outcome to expect, and I don't remember any
> > > numbers
> > > posted by anyone else, either.
> > 
> > From the David Stone's Writing Robust Code
> >  page 34:
> > 
> > Performance of exceptions when not thrown
> > ● Tested on gcc 4.9.2
> > ● Numbers relative to ignoring errors
> > ● With no destructors
> > 
> > – 12.8% overhead for exceptions
> > – 32.8% overhead for return codes
> > 
> > ● With destructors
> > 
> > – 6.3% overhead for exceptions
> > – 18.7% overhead for return codes
> 
> Hmm, so, using exceptions makes your code 12-20% faster. This is a good
> thing, right?. Most probably the binary size will be slightly bigger, let's
> see if it's 12-20% bigger (my hunch is that it will not be more than 5%
> bigger). I'll do some tests this weekend and I'll share with you the
> results.
> 
> > And page 35:
> > 
> > Performance of exceptions when thrown
> > ● Tested on gcc 4.9.2
> > ● Numbers relative to ignoring errors
> > ● With no destructors
> > 
> > – 900% overhead for exceptions
> > 
> > ● With destructors
> > 
> > – 750% overhead
> 
> As I said, exceptions are like *a life vest*, they should be used *only in
> critical situations* not everywhere.
> 
> Cheers,
> BogDan.
> 
> P.S. Android Alexandrescu has a nice video on this matter:
> https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandr
> escu-Systematic-Error-Handling-in-C
> 
> ___
> 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] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Saturday 23 January 2016 17:46:39 Andre Somers wrote:
> On 22-1-2016 22:51, Kevin Kofler wrote:
> > I'd already be happy with those that were (are, actually) already
> > there. I'd rather have 10-20 common algorithms with a convenient API
> > than 80+ obscure ones that force me to use iterators (especially the
> > boilerplate .begin() and .end() iterators that will be used in 99+% of
> > the cases – copy&paste programming sucks).
> 
> Please note that the algorithms in STD are by no means complete. You are
> stimulated to add your own that you find useful, either as
> specializations or combinations of what is already there, as
> implementations of known algorithms in literature or even completely new
> ones ("Publish! Become Famous! (Don't patent please.)" - Sean Parent).
> Stephanov has seen his original design of STL been significantly
> shortened to get it through the commission; the proposal included much
> more than what is in STD even now after the more recent additions.
> 
> So, by all means, add what you deem useful.
> 
> I certainly agree that having to write begin/end pairs for all
> algorithms is not nice. It is the most general way to specify them
> however, so I understand why they are like this. And it even makes sense
> for some of them (like find, where you can then call find again using
> the return value of the last call to get the next match). Even for sort
> there certainly are use cases for a pair of iterators instead of passing
> the whole container. Still, it would make perfect sense to create
> versions that take a whole container. I don't even think that that is
> hard to do...
> 
> template < class Container, class Compare >
> void sort ( Container container, Compare compare)
> {
>  sort(begin(container), end(container), compare);
> };
> 
> Something like that perhaps? Feel free to add as many as you think are
> useful.

The problem is that these overloads quickly become ambiguous with existing 
ones. So at a minimum, you need to have a special suffix (_all).Overloading on 
concepts is needed to solve this properly.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Andre Somers]

On 23-1-2016 17:39, Milian Wolff wrote:

On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote:

Marc Mutz wrote:

And this is where I stop taking you seriously, sorry. You can demand such
nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+
algorithms from the STL for Qt. Or play god deciding which are the ones
"no- one will ever need" or "should never use" - IYHO.

I'd already be happy with those that were (are, actually) already there. I'd
rather have 10-20 common algorithms with a convenient API than 80+ obscure
ones that force me to use iterators (especially the boilerplate .begin()
and .end() iterators that will be used in 99+% of the cases – copy&paste
programming sucks).

You should educate yourself by watching a few of Sean Parent's talks and it
will become clear that most of these "obscure ones" are actually very
applicable in many scenarios where you currently write handwritten loops which
are probably not as efficient and well-tested as the STL implementations. The
code also becomes more self-explaining by using algorithms.
I can certainly agree with that one! Google for No Raw Loops for 
instance. Also, there are a lot of classes by Stephanov online that are 
quite educational (A9 published a couple of series on YouTube). There is 
even one where Sean Parent comes to talk to Stephanovs class there. It 
is an extended version of the No Raw Loops talk you'll find elsewhere.


It pays off to familiarize yourself with these algorithms. You can use 
them more often than you think.


André


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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Andre Somers]

On 22-1-2016 22:51, Kevin Kofler wrote:
I'd already be happy with those that were (are, actually) already 
there. I'd rather have 10-20 common algorithms with a convenient API 
than 80+ obscure ones that force me to use iterators (especially the 
boilerplate .begin() and .end() iterators that will be used in 99+% of 
the cases – copy&paste programming sucks).


Please note that the algorithms in STD are by no means complete. You are 
stimulated to add your own that you find useful, either as 
specializations or combinations of what is already there, as 
implementations of known algorithms in literature or even completely new 
ones ("Publish! Become Famous! (Don't patent please.)" - Sean Parent). 
Stephanov has seen his original design of STL been significantly 
shortened to get it through the commission; the proposal included much 
more than what is in STD even now after the more recent additions.


So, by all means, add what you deem useful.

I certainly agree that having to write begin/end pairs for all 
algorithms is not nice. It is the most general way to specify them 
however, so I understand why they are like this. And it even makes sense 
for some of them (like find, where you can then call find again using 
the return value of the last call to get the next match). Even for sort 
there certainly are use cases for a pair of iterators instead of passing 
the whole container. Still, it would make perfect sense to create 
versions that take a whole container. I don't even think that that is 
hard to do...


template < class Container, class Compare >
void sort ( Container container, Compare compare)
{
sort(begin(container), end(container), compare);
};

Something like that perhaps? Feel free to add as many as you think are 
useful.


André

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

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Milian Wolff]

On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote:
> Marc Mutz wrote:
> > And this is where I stop taking you seriously, sorry. You can demand such
> > nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+
> > algorithms from the STL for Qt. Or play god deciding which are the ones
> > "no- one will ever need" or "should never use" - IYHO.
> 
> I'd already be happy with those that were (are, actually) already there. I'd
> rather have 10-20 common algorithms with a convenient API than 80+ obscure
> ones that force me to use iterators (especially the boilerplate .begin()
> and .end() iterators that will be used in 99+% of the cases – copy&paste
> programming sucks).

You should educate yourself by watching a few of Sean Parent's talks and it 
will become clear that most of these "obscure ones" are actually very 
applicable in many scenarios where you currently write handwritten loops which 
are probably not as efficient and well-tested as the STL implementations. The 
code also becomes more self-explaining by using algorithms.

And you do know that people are working on a STL v2 for ranges which 
invalidates all your "I hate iterators" complaints?

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
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] What kind of airplane we want to build?

[Milian Wolff]

On Freitag, 22. Januar 2016 16:47:38 CET Thiago Macieira wrote:
> On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote:

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

At least it is now work-arounded via the uniform initialization syntax.

Cheers
-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
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] What kind of airplane we want to build?

[charleyb123 .]

Thiago sayeth:

> ,
> But I have no plans on extending QAtomicInteger and QAtomicPointer further.
> There are a couple of missing features that will probably never be
> implemented:
>
>  * std::memory_order_consume and std::memory_order_cst
>  * GCC's extension for hidden lock elision
>  * compare_exchange_weak (doesn't affect Intel, so I don't care)
>  * weaker memory model for the failing compare_exchange's reload
>  * atomics on non-integral and non-pointer types, including larger types
>  * volatile support
>
> From my point of view, if you need to go further on atomics, you should
> just
> use std::atomic.
>
> We could introduce QAtomic which wraps the std::atomic API and adds the Qt-
> style names. Is it worth it?
>

That would have been handy for a previous project, as we had the same
codebase deploying to multiple architectures and we effectively had to do
that ourselves -- we preferred QAtomics (because of the better API), but
needed to wrap std::atomic for our deployment to one ARM platform.

So, we made our own wrapper atomic class with the Qt interface, but had an
#ifdef...#endif to wrap std::atomic for one platform.  Worked fine (it's
now a preferred pattern).


> > > 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/algor
> > > ithm.h
> > Interesting. That could be a starting point for a QtAlgorithms successor.
>
> Agreed. Instead of reimplementing , expanding them for
> convenience
> API.
>

Agree here also, and with other comments in the thread regarding
"not-much-love" for STL API choices/semantics.

IMHO:

(1) Most programmers don't even know about the STL algorithms.

(2) Most programmers have a hard time conceptualizing what the STL
algorithms are "supposed to do", even when looking right at them, after
they are correctly employed in working code.

(3) STL API conventions and volatility across versions are ... unfortunate.

(4) Due to 1-3, many informed programmers remain unconvinced of the value
of even bothering to increase STL algorithm adoption.  (I think this is
disappointing, but concede it to be a rational response by many teams.)

I really think the, "convenience API" is worth a *lot*.  Even just wrapping
 with Qt semantics is worth a ton.  Programmers would actually
*use* those, and *understand* those in code.

Recall that even in on the C++ committee, there is not universal support
for the ".begin(), .end()" where two parameters are required to iterate a
single container (e.g., web search for, "Iterators Must Go", Niebler's new
iterators work, proposals for future modified APIs for parallel-iteration
of container elements).

So, this would add another interesting motivation (and I'm seriously going
to, "get out the popcorn" to watch the events unfold as I listen to the
wailing and lamenting and gnashing-of-teeth as...)

(5) In the not-too-distant future, the existing STL iterators API may be
deprecated in favor of new iterator conventions.

That sure is a lot of code to migrate, and it would be nice to have a
convenience API to adopt.

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

Re: [Development] Charts and DataVis Questions

[Uwe Rathmann]

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.

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 
this way:

void draw( const QPolygonF &points, QPaintDevice &paintDevice )
{
QPainter painter( &paintDevice );
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 &points, QPaintDevice &paintDevice )
{
QPainter painter( &paintDevice );
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 &points )
{
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 &points )
{
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

Re: [Development] Fwd: A simple analysis of apps using qtbase's private headers

[Sune Vuorela]

On 2016-01-22, Lisandro Damián Nicanor Pérez Meyer  wrote:
> On Friday 22 January 2016 18:09:55 NIkolai Marchenko wrote:
>> Speaking of workarounds :
>> I have to use this ugly hack that depends on otherwise inaccessible c=
> ode to
>> update QPrintPreviewDialog
>>=20
>> //dia is a QPrintPreviewDialog
>> QPrintPreviewWidget* w =3D dia->findChild();
>> QMetaObject::invokeMethod(w, "updatePreview", Qt::QueuedConnection);
>>=20
>> can you please add "updatePreview" to the dialog's interface?
>
> Is there a bug for that?

Or even better. A gerrit submission.

/Sune

___
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

[Dominik Holland]

Hi,

how about doing the automatic population, but every class is able to
override this by using the "\supports" command.

Maybe it would be also possible to add an link in the Target Platforms
row to the platform overview page of that modules (here qtmultimedia
could document what's available on which platform)

Dominik

Am 23.01.16 um 04:30 schrieb Sze Howe Koh:
> 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.
> 
> 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
> 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development