Re: [Development] [QtMultimedia] Still is supported, active?

2016-07-20 Thread Thiago Macieira 
On quinta-feira, 21 de julho de 2016 00:19:44 PDT Denis Shienkov wrote:
> It is strange for me, that is performed some "unclear" work there (which
> is improves nothing, but introduces a new bugs IMHO) instead of fixing
> of a *critical* bugs.

The one you linked to is P2 - Important. It's neither critical nor 
showstopper.

> Do you tests before release our module? I think - NOT!

Where's your proof?

> Concerning QtMM maintainer: he should at least let us to know to
> bug-tracker, that the concrete issue will been accepted or not (at least
> not to be silent there).

Bugs are fixed when they are fixed. You won't get any estimate before the 
developer actually starts fixing the issue. And even then, it may take months 
or more until it actually gets fixed.

> Otherwise there is an impression that I talk there to myself or to a
> blank wall.
> 
> Besides, I don't understand, how is it possible to skip such critical
> bug (and others critical bugs), and not to notice it.

It's not critical, according to whoever triaged it.

-- 
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] [QtMultimedia] Still is supported, active?

2016-07-20 Thread Denis Shienkov 

Hi Andy,

I periodically do watching for qt codereview status. So, your provided 
links has not effect for me (I'm do not surprised).


It is strange for me that the majority of these commits have no 
task-numbers, there is an impression, that bugs in a tracker are just 
ignored.


It is strange for me, that is performed some "unclear" work there (which 
is improves nothing, but introduces a new bugs IMHO) instead of fixing 
of a *critical* bugs.


Do you tests before release our module? I think - NOT!

Concerning QtMM maintainer: he should at least let us to know to 
bug-tracker, that the concrete issue will been accepted or not (at least 
not to be silent there).


Otherwise there is an impression that I talk there to myself or to a 
blank wall.


Besides, I don't understand, how is it possible to skip such critical 
bug (and others critical bugs), and not to notice it.


PS: I already repeatedly wrote to mailing-list concerning to QtMM 
status, but nothing changes. I think, nothing will change in future too.


BR,

Denis







20.07.2016 23:38, Andy Nichols пишет:


Hi Denis,


This type of mail in not constructive at all, and is not appropriate 
on this list.



You could propose your concerns about your bug on the bug tracker and 
this mailing list without the personal attacks on a Qt Project developer.



There is active development on the QtMultimedia module even now in the 
vacation season:


https://codereview.qt-project.org/#/q/project:qt/qtmultimedia,n,z


And your claim that the QtMultimedia maintainer Yoann is somehow not 
doing his job is dead wrong:


https://codereview.qt-project.org/#/q/owner:%22Yoann+Lopes%22,n,z


It's not right for you to try shame a fellow developer about someone 
on the public mailing list just because you are upset your bug is not 
being fixed.



Not cool.


Andy Nichols


*From:* Development 
 on behalf of 
Denis Shienkov 

*Sent:* Wednesday, July 20, 2016 10:16:37 PM
*To:* development@qt-project.org
*Subject:* [Development] [QtMultimedia] Still is supported, active?
Hi guys,

I write the angry letter concerning fixing of errors in QtMM the module.
Sorry, but I have no more patience to be silent.

This module contains a set of *critical* errors, some of which aren't
not fixed within 6 months. For example, currently
it is impossible to use QtMM > 5.6 in Windows for video playback, e.g:
https://bugreports.qt.io/browse/QTBUG-53019

This epic bug was introduces in 5.6 and above, though in 5.5.1 it works
"fine".

I had an impression that the maintainer of QtMM (Yoann Lopes) has become
deaf, has become blind, or just ignores any task in the bug tracker. WTF?

As I know he is working in Qt's company (at least from e-mail), receives
money
  for his work, but does nothing.. WTF?

WTF? If you don't support this module - then, please, remove away him to
devils, to hell.

Thanks for attension.

BR,
Denis

___
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] Revisiting high-DPI configuration options

2016-07-20 Thread Uwe Rathmann 
On Wed, 20 Jul 2016 10:44:16 -0700, Thiago Macieira wrote:

>> Why SVG support of QIcon can not cache rendered result? So re-rendering
>> will be as fast as for PNGs. Or you are saying about app startup time?
> 
> Startup.

When using SVGs you have to load/parse it into QSvgRenderer and later it 
needs to be replayed via QPainter in the size you need.

While the second step can't be avoided at runtime, it is possible to 
convert SVGs into something, that can be loaded significantly faster, at 
compile time.

I'm using an implementation based on this class: http://
qwt.sourceforge.net/class_qwt_graphic.html. This is a record/replay 
device for QPainter commands - like QPicture, but suitable for vector 
graphics. I added load/save methods ( not yet in SVN ) and then the 
compiler itself is 20 lines of code only.

When using such a concept with Qt Quick, better don't use standard Image 
classes as they are designed for raster graphics. Better write your own 
type of control for it - at least this is what I did.

Uwe


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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Konstantin Tokarev 


20.07.2016, 21:08, "Thiago Macieira" :
> On quarta-feira, 20 de julho de 2016 21:03:48 PDT Prav wrote:
>>  > Startup.
>>
>>  Approximately how many icons app have to have to see influence on app's
>>  startup?
>
> That depends on the complexity of your SVG icons and how powerful your CPU is.
>
>>  > I can't speak for business decisions. But however faster that engine is,
>>  > it'll still be orders of magnitude slower than PNG.
>>
>>  But scaling is a problem.
>
> Yes. It's a trade-off.

One could use SVG to C++ translator to trade CPU usage / startup time to code 
size (and probably feature set)

http://zrusin.blogspot.ru/2006/07/compiling-svg-to-c.html

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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Thiago Macieira 
On quarta-feira, 20 de julho de 2016 21:03:48 PDT Prav wrote:
> > Startup.
> 
> Approximately how many icons app have to have to see influence on app's
> startup?

That depends on the complexity of your SVG icons and how powerful your CPU is.

> > I can't speak for business decisions. But however faster that engine is,
> > it'll still be orders of magnitude slower than PNG.
> 
> But scaling is a problem.

Yes. It's a trade-off.

-- 
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] Revisiting high-DPI configuration options

2016-07-20 Thread Prav 
> Startup.

Approximately how many icons app have to have to see influence on app's startup?


>> Also there was idea in this thread earlier that SVG rendering can be done
>> much faster ... like in old Opera browser. Why Qt company cann't ask Opera
>> to share this part of old Presto engine? They decided to not use Presto
>> nowdays so no loses for them.

> I can't speak for business decisions. But however faster that engine is, it'll
> still be orders of magnitude slower than PNG.

But scaling is a problem.


>> But for people who really want raster images to be aplied ... may be it is
>> possible to add some method to QIcon which will store this specially
>> rastered QPixmap in icon and will render icon with this pixmap if icon size
>> is small. But I am sure most apps will be happy with just SVG rendering.
>> This is such a detailed work ... not sure that many apps creators will
>> decide this work as a high priority.

> As Morten said, Qt does not have a choice: we have to support both SVG and
> raster icons.

Agree. I am about details. If user can only select SVG OR PNG this is one way 
to support both icon formats.

I was trying to say that combined variant is imaginable and is interesting 
because can have benefits of both formats.

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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Konstantin Tokarev 


20.07.2016, 20:12, "Prav" :
> Hello, Everyone.
>
>>  That's one reason, but there are two more equally, if not more important:
>>  1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy
>>  applications suffer if they use it.
>
> Why SVG support of QIcon can not cache rendered result? So re-rendering will 
> be as fast as for PNGs.
> Or you are saying about app startup time?
>
> Also there was idea in this thread earlier that SVG rendering can be done 
> much faster ... like in old Opera browser.
> Why Qt company cann't ask Opera to share this part of old Presto engine? They 
> decided to not use Presto
> nowdays so no loses for them.

Is SVG engine of Opera really faster than that of WebKit?

>
>>  2) SVG icons designed for higher resolution, with a lot of details, look
>>  complex and polluted in lower resolutions. From past experience, icon 
>> artists
>>  prefer to render the SVG to a lower resolution and retouch them.
>
> This is a problem. But I do not see many such icons in Material-style. They 
> are mostly simple.
> So I would expect modern styled-apps will not have this problem massively.
>
> But for people who really want raster images to be aplied ... may be it is 
> possible to add some method
> to QIcon which will store this specially rastered QPixmap in icon and will 
> render icon with this
> pixmap if icon size is small. But I am sure most apps will be happy with just 
> SVG rendering.
> This is such a detailed work ... not sure that many apps creators will decide 
> this work as a high priority.
>
> ___
> 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] Revisiting high-DPI configuration options

2016-07-20 Thread Prav 
Hello, Everyone.

> That's one reason, but there are two more equally, if not more important:
> 1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy
> applications suffer if they use it.
Why SVG support of QIcon can not cache rendered result? So re-rendering will be 
as fast as for PNGs.
Or you are saying about app startup time?

Also there was idea in this thread earlier that SVG rendering can be done much 
faster ... like in old Opera browser.
Why Qt company cann't ask Opera to share this part of old Presto engine? They 
decided to not use Presto
nowdays so no loses for them.


> 2) SVG icons designed for higher resolution, with a lot of details, look
> complex and polluted in lower resolutions. From past experience, icon artists
> prefer to render the SVG to a lower resolution and retouch them.
This is a problem. But I do not see many such icons in Material-style. They are 
mostly simple.
So I would expect modern styled-apps will not have this problem massively.

But for people who really want raster images to be aplied ... may be it is 
possible to add some method
to QIcon which will store this specially rastered QPixmap in icon and will 
render icon with this
pixmap if icon size is small. But I am sure most apps will be happy with just 
SVG rendering.
This is such a detailed work ... not sure that many apps creators will decide 
this work as a high priority.

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

Re: [Development] Documenting 3rd party code Qt

2016-07-20 Thread Thiago Macieira 
On quarta-feira, 20 de julho de 2016 11:13:39 PDT Kai Koehne wrote:
> I had a look at SPDX, README.Chromium, debian/copyright (btw thanks for the
> pointer!). In the end I went for a custom format, because they all seem to
> not quite fit for our use case. Anyhow, it's easy to extend licensescanner
> to generate other formats, too.

What's missing from SPDX and have you tried to talk to them about adding the 
missing information?

-- 
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] Revisiting high-DPI configuration options

2016-07-20 Thread Thiago Macieira 
On quarta-feira, 20 de julho de 2016 13:03:03 PDT Prav wrote:
> SVG icons are not shown at all in static builds of Qt, but png icons are
> fine (both icons are taken from resorse file). Static and shred Qt 5.6.1
> build were done with same config settings except of cause "static".

Remember to force the inclusion of the svg icon plugin into your application.

-- 
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] Revisiting high-DPI configuration options

2016-07-20 Thread Thiago Macieira 
On quarta-feira, 20 de julho de 2016 09:12:53 PDT Edward Welbourne wrote:
> I am baffled that anyone does the _x2, etc., approach to icons any more,
> when most icons are indeed well-suited to SVG - in most cases, a tiny
> SVG, smaller (in file-size) than any one of the many icons it makes
> redundant, can do an excellent job of presenting the clear visual that
> the icon is supposed to provide.  Making many larger files seems to
> serve no purpose - other than letting web-or-UI designers bill their
> clients for large amounts of pointless make-work.
> 
> Then again, our SVG support is embarrassingly poor,

That's one reason, but there are two more equally, if not more important:

1) SVG rendering is orders of magnitude slower than PNG. Icon-heavy 
applications suffer if they use it.

2) SVG icons designed for higher resolution, with a lot of details, look 
complex and polluted in lower resolutions. From past experience, icon artists 
prefer to render the SVG to a lower resolution and retouch them.

-- 
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] Documenting 3rd party code Qt

2016-07-20 Thread Kai Koehne 


> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
> >  That might be helpful, although the current format lacks, for
> > example, per- entity copyright (yes, each contributor name).
> [...]
> I'm genuinely curious though why debian/copyright needs this on a file level.
> Do you know the reasons?

Actually re-reading " Example files paragraphs" from 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ :

> Files: *
> Copyright: 1975-2010 Ulla Upstream
> License: GPL-2+
>
> Files: debian/*
> Copyright: 2010 Daniela Debianizer
> License: GPL-2+
>
> Files: debian/patches/fancy-feature
> Copyright: 2010 Daniela Debianizer
> License: GPL-3+
> 
> Files: */*.1
> Copyright: 2010 Manuela Manpager
> License: GPL-2+
>
> [...]
> Since the license of the manual pages is the same as the other files in the 
> package, the last paragraph above could instead be combined with the first 
> paragraph, listing both copyright 
> statements in one Copyright field. Whether to combine paragraphs with the 
> same license is left to the discretion of the author of the debian/copyright 
> file.

If I got this right it says you can combine copyright lines from multiple files 
if the license is the same. So far we don't actually support differently 
licensed files in one json object (that's why e.g. 
https://codereview.qt-project.org/#/c/160970/11/src/3rdparty/angle/qt_attribution.json
 is split up in multiple objects). Hence I'm questioning whether we really need 
to support separating Copyright's per file.

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

Re: [Development] Documenting 3rd party code Qt

2016-07-20 Thread Kai Koehne 


> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Lisandro Damián Nicanor Pérez Meyer
> Sent: Wednesday, July 20, 2016 4:04 PM
> To: development@qt-project.org
> Subject: Re: [Development] Documenting 3rd party code Qt
> 
> On miércoles, 20 de julio de 2016 11:13:39 A. M. ART Kai Koehne wrote:
> > Hi,
> [snip]
> > # File Format
> >
> > I had a look at SPDX, README.Chromium, debian/copyright (btw thanks
> > for the pointer!).
> 
> My pleasure :)
> 
> > In the end I went for a custom format, because they all seem to not
> > quite fit for our use case. Anyhow, it's easy to extend licensescanner
> > to generate other formats, too.
> 
>  That might be helpful, although the current format lacks, for example, per-
> entity copyright (yes, each contributor name).
>
> I *know* this is a big burden because I have to do it :) But if this can be
> added, even if optional, we the ones who need this info can fill these details
> on each of our reviews.

It can easily get laborious, but I don't see why we shouldn't allow something 
like

"CopyrightFiles" : [
   { "*": "Copyright (c) 1920 Joe Doe", },
   { "special_file": "Copyright (c) 2040 Jane Roe" }
]

in the format, sure. 

I'm genuinely curious though why debian/copyright needs this on a file level.  
Do you know the reasons?

Regards

Kai

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

Re: [Development] Documenting 3rd party code Qt

2016-07-20 Thread Lisandro Damián Nicanor Pérez Meyer 
On miércoles, 20 de julio de 2016 11:13:39 A. M. ART Kai Koehne wrote:
> Hi,
[snip]
> # File Format
> 
> I had a look at SPDX, README.Chromium, debian/copyright (btw thanks for the
> pointer!).

My pleasure :)

> In the end I went for a custom format, because they all seem to
> not quite fit for our use case. Anyhow, it's easy to extend licensescanner
> to generate other formats, too.

 That might be helpful, although the current format lacks, for example, per-
entity copyright (yes, each contributor name).

I *know* this is a big burden because I have to do it :) But if this can be 
added, even if optional, we the ones who need this info can fill these details 
on each of our reviews.

Would that be a good compromise for you?

-- 
Si vives cada día de tu vida como si fuera el último,
algún día realmente tendrás razón.
  Steve Jobs

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


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

[Development] Boot to Qt Device problem.

2016-07-20 Thread Bahadır Can 
Hello Qt Developers Team,


I am currently working on a Sabre Automative Board with i.MX6Quad. I just 
started to use Qt Embedded .


I am following this guide :


http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html


I insterted a clean SD card to my device and run the flash boot to Qt Device. 
(with the option Sabre SD i.MX6Quad)


After installation of image finished. I inserted SD card  to Board and 
restarted the board but nothing happened. (Terminal and screen didn't work.)


I also tried it with a beaglebone black but got nothing on it too.


Am I missing any steps?


Thanks from now.


Bahadır

Preparing SABRE SD i.MX6Quad | Qt 5.7 for Device 
Creation
doc.qt.io
Take the following steps to prepare Freescale SABRE SD i.MX6Quad for Boot to 
Qt: Note: It is important that you repeat the steps in this section after you 
update Qt ...



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

Re: [Development] Boot to Qt Device problem.

2016-07-20 Thread Dominik Holland 
Hi,

Am 07/20/2016 um 03:41 PM schrieb Bahadır Can:
> Hello Qt Developers Team,
> 
> 
> I am currently working on a Sabre Automative Board with i.MX6Quad. I
> just started to use Qt Embedded . 
> 
> 
> I am following this guide :
> 
> 
> http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6sabresd.html
> 
> 
> I insterted a clean SD card to my device and run the flash boot to Qt
> Device. (with the option Sabre SD i.MX6Quad)
> 
> 
> After installation of image finished. I inserted SD card  to Board and
> restarted the board but nothing happened. (Terminal and screen didn't work.)

That could be related to an too old uboot version. It's probably a good
idea to update the uboot on the board using the instructions here:

http://doc.qt.io/QtForDeviceCreation/qtee-preparing-hardware-imx6.html

Dominik

> 
> 
> I also tried it with a beaglebone black but got nothing on it too. 
> 
> 
> Am I missing any steps?
> 
> 
> Thanks from now.
> 
> 
> Bahadır
> 
> Preparing SABRE SD i.MX6Quad | Qt 5.7 for Device Creation
> 
> doc.qt.io
> Take the following steps to prepare Freescale SABRE SD i.MX6Quad for
> Boot to Qt: Note: It is important that you repeat the steps in this
> section after you update Qt ...
> 
> 
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 

-- 
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holl...@pelagicore.com
www.pelagicore.com

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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Morten Sorvig 

> On 20 Jul 2016, at 14:51, André Somers  wrote:
> 
> 
> 
> Op 20/07/2016 om 14:23 schreef Morten Sorvig:
>>> On 19 Jul 2016, at 14:58, Shawn Rutledge  wrote:
>>> 
>>> 
>>> I agree that most apps should have a means of scaling.  Control-mousewheel 
>>> and control+/- are common on the desktop, so maybe it ought to be 
>>> universal.  So far we have browsers, image and drawing viewers and editors, 
>>> text editors (like Creator’s) and terminals which have the feature, but 
>>> many other applications don’t.
>> This would be a "document scaling” feature. Notice that the application UI
>> does not scale when using and control+/-. So this is orthogonal to the
>> current high-DPI support and can’t reuse that implementation.
>> 
>> 
> Not really. In the browser, the web content often is the real application the 
> user interacts with.
> 

I think this is a special case that does not invalidate the general point. The
browser UI still does not scale. But I agree, if you have application UI 
elements
in your document those should scale too.

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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Morten Sorvig 

> On 20 Jul 2016, at 14:52, Edward Welbourne  wrote:
> 
> Morten Sorvig said:
>> I’d like us to support both, were an icon/image with more pixels can
>> be designated as either “larger” (more content) or “higher resolution”
>> (more detail).
> 
> which is why SVG has to be the way to go - so you just specify the
> different levels of detail and let size be a display-time choice - else
> you'll end up with a quadratic explosion of different images,
> parameterised by detail-ness and by size.

Yes, as an application developer I will seriously consider using SVGs only. As
library developers we should support both approaches.

Morten



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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Edward Welbourne 
Morten Sorvig said:
> I’d like us to support both, were an icon/image with more pixels can
> be designated as either “larger” (more content) or “higher resolution”
> (more detail).

which is why SVG has to be the way to go - so you just specify the
different levels of detail and let size be a display-time choice - else
you'll end up with a quadratic explosion of different images,
parameterised by detail-ness and by size.

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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Morten Sorvig 

> On 20 Jul 2016, at 12:47, Edward Welbourne  wrote:
> 
> Michael Zanetti
> 
>> Well, in smaller icons you can have less details than in bigger icons,
>> so having multiple icons does make sense.
> 
> That's fair enough - but the thing that makes sense is having more and
> less detailed icons, not bigger and smaller ones.  Of course, you'll
> want to use the more detailed one for bigger uses and the less detailed
> for smaller uses, but each should cover a wide range of sizes cleanly.
> 

I’d like us to support both, were an icon/image with more pixels can be
designated as either “larger” (more content) or “higher resolution”
(more detail).

Morten

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

Re: [Development] Why is QVariant::data() \internal?

2016-07-20 Thread Olivier Goffart 
On Montag, 18. Juli 2016 23:15:22 CEST Konrad Rosenbaum wrote:
> Hi,
> 
> On Monday 18 July 2016 07:59:21 Jędrzej Nowacki wrote:
> > On Saturday 16 of July 2016 13:56:00 Konrad Rosenbaum wrote:
> > > I am currently interfacing two libraries that only have QVariant in
> > > common, most of the (value) types getting exchanged are either Qt
> > > containers or Q_GADGETs.
> > > 
> > > I was relatively quick to realize that I needed the QMetaType and
> > > QMetaObject of these objects, but it took me pretty long to find out
> > > that I can use QVariant::data() to get at the void* that I need to
> > > access properties and Q_INVOKABLEs.
> > > 
> > > Is there a particular reason that QVariant::data() is classified as
> > > \internal or would a documentation patch be accepted?
> > 
> > Mostly because it should not be needed.
> 
> I can see why it should not be needed in 95% of situations. But there is
> this tiny little fraction of cases in which QVariant is the only commonality
> between interfaces. Esp. if those interfaces are supposed to be generic,
> non-related and exchangeable.
> 
> I'd argue it is needed often enough to merit some documentation with a big
> fat warning for the other 95% of cases.
> 
> > Why can't you use https://doc.qt.io/qt-5/qvariant.html#value or
> > https://doc.qt.io/qt-5/qvariant.html#qvariant_cast ?
> 
> The library that is looking into the QVariant is a generic
> calculation/templating engine that uses QVariant to exchange data with
> whatever outside caller is using its services.
> 
> It does not know what kind of data types the calling code uses - all it can
> assume is that it gets property names to find the values it is really
> looking for. It does not even know why it is being used.
> 
> The data source may be the calling code or it may be a completely unrelated
> library.
> 
> Example:
> Lets assume the engine is configured to work on strings and it gets the
> formula {'I am ' + my1.name} and "my1" is configured to be a pointer to a
> QObject-derived class or a Q_GADGET. The formula itself will usually come
> from some kind of configuration (otherwise: what's the point!). What the
> library code does is parse the formula, delve into the QObject or gadget
> behind "my1" and retrieve the property "name".
> 
> For some use cases demanding that structured types are QObject is simply not
> feasible since the remainder of the use case may demand value logic (in my
> current specific case it represents data exchanged over the network).
> 
> Writing a formula parser is complex enough for me to definitely not wanting
> to tie it to one specific application - hence I do not want it to know the
> specific structured types - I want it to explore those types through some
> kind of reflection - turns out QMetaType/QMetaObject is a wonderful way of
> doing this.
> 

I think indeed, with the recent Q_GADGET change, there is indeed a reason to 
document QVariant::data/constData or QMetaType::IsGadget


-- 
Olivier

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

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

[Development] Documenting 3rd party code Qt

2016-07-20 Thread Kai Koehne 
Hi,

A while ago I proposed to generate 3rd party code attributions out of files 
that are right beside the code, instead of hand-editing 3rdparty.html in qtdoc. 
I've now a set of patches that are IMO worth to take a look at (also because FF 
for 5.8 is coming ;)

# Information Flow

Every 3rd party code in our repositories should get a 'qt_attribution.json' 
file containing metadata about the code. When the documentation of a module is 
built, a new tool 'licensescanner' is automatically run by qmake that scans the 
sources for qt_attribution.json files, and generates a .qdoc file with pages 
for every attribution it finds. An overview of the attributions is shown on 
each modules entry page. Finally, the current 3rdparty overview page should be 
automatically generated from all modules' attribution pages.

# File Format

I had a look at SPDX, README.Chromium, debian/copyright (btw thanks for the 
pointer!). In the end I went for a custom format, because they all seem to not 
quite fit for our use case. Anyhow, it's easy to extend licensescanner to 
generate other formats, too.

The current format is documented in  https://wiki.qt.io/Qt_attribution.json .

Real-life examples for qtbase can be found in 
https://codereview.qt-project.org/#/c/160970/ .

# QDoc Extension

To be able to document and structure the 3rd party content I introduced a new 
'attribution' attribute to qdoc's \page command, and added 
\generatelist{attributions}, \generatelist{annotatedattributions} commands.

# Patches

qttools patches (licensescanner, qdoc modifications): 
https://codereview.qt-project.org/#/q/status:open+project:qt/qttools+branch:dev+topic:3rdparty,n,z
qtbase patches (qt_attributions.json files, build integration, overview pages): 
https://codereview.qt-project.org/#/q/status:open+project:qt/qtbase+branch:dev+topic:3rdparty,n,z
qtdoc patch (for general overview page): 
https://codereview.qt-project.org/#/q/status:open+project:qt/qtdoc+branch:dev+topic:3rdparty,n,z

# FAQ

Q: Why do we need such an elaborate setup? Wouldn't it be easier to just write 
.qdoc files?

Keeping the 'documentation' close to the actual sources hopefully makes sure 
they're up to date and complete. Admittedly we could also just have .qdoc files 
right beside each code snipped, and include this one. In the future I'd like to 
extend the tool though so that attribution information (say HTML) for an app 
bundling Qt can be generated. The qt_attribution.json file could also be used 
as input to 3rd party code scanners popular in the industry, or used as a 
source for generating SPDX files ... Keeping the metadata outside of .qdoc 
makes this a lot easier.

Q: What about 3rd party code in tests/examples ...?

I think they should get a qt_attribution.json file too. We have to mark though 
what actually ends up in the Qt libs, and what only ends up in tests / build 
system / host tools ... I'm still contemplating how to best document this in 
the qt_attribution.json file.

Regards

Kai

-- 
Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. 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] leak in QMetaObject?

2016-07-20 Thread Edward Welbourne 
André Somers said:

> But then again, it is easier to optimize the rare-but-expensive case
> in the application code than doing something about a frequent action
> that is slower than it could be.

Indeed - when possible, this can give you the best of both worlds.
A judicious API addition to do a job in bulk can often be a big win.

> But: this reasoning is as much dependent on actual data on what the
> distribution of n is as the orignal statement that it does make sense.
> Hence my question on the availability of such data...

and with that I agree entirely :-)

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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Edward Welbourne 
Michael Zanetti

> Well, in smaller icons you can have less details than in bigger icons,
> so having multiple icons does make sense.

That's fair enough - but the thing that makes sense is having more and
less detailed icons, not bigger and smaller ones.  Of course, you'll
want to use the more detailed one for bigger uses and the less detailed
for smaller uses, but each should cover a wide range of sizes cleanly.

> Also rendering svg icons is
> slower than bitmaps so in some cases that won't work out either.

That means the SVG renderer isn't good enough.  I really wish we could
get hold of the team that implemented Opera's SVG engine in Presto - now
discarded in favour of Chrome - to do the job well: they wrote a good
engine that worked fast.

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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Prav 
Heello, Everyone!

> Then again, our SVG support is embarrassingly poor,
Exactly!
For example if you set SVG icon for button and then scale the app with 
something like QT_SCALE_FACTOR=2 before running the app ... icon will be 
bluered like this is not SVG!
With QT_SCALE_FACTOR=1 icon looks fine.
But fonts looks sharp for both QT_SCALE_FACTOR=1 and =2. Strange?
(Qt 5.6.1, Windows).

SVG icons are not shown at all in static builds of Qt, but png icons are fine 
(both icons are taken from resorse file). Static and shred Qt 5.6.1 build were 
done with same config settings except of cause "static".
Strange too.
(Qt 5.6.1, Windows).

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

Re: [Development] leak in QMetaObject?

2016-07-20 Thread André Somers 



Op 20/07/2016 om 11:39 schreef Edward Welbourne:

Op 20/07/2016 om 10:41 schreef Olivier Goffart:

The distribution does not matter. If it can be big, quadradic
complexity can be a blocker.

André Somers replied

Nonsense. There is no need to pessimize the frequent cases to cater
for avoiding a performance issue in an exceptional case.

Well, it depends ...

You've got some function, F, from number of connections to cost of any
given way of handling connections.  You've got some distribution P over
values n takes.  Your total cost is the sum of P(n).F(n) over that range
of values.  The big-O discussion is usually about how F varies; but what
actually matters is the sum of P(n).F(n). [...]

Yes, you are right of course.

But then again, it is easier to optimize the rare-but-expensive case in 
the application code than doing something about a frequent action that 
is slower than it could be. To stick to the concrete issue here: 
disconnecting a long list of connections using a loop is not very 
efficient if you do that one-by-one, Olivier pointed out you turn a O(N) 
into an O(N^2) if you then also do the clean-up. So you optize that to 
make sure that you can disconnect *all* connections for a given signal 
or slot instead, even if that means using an intermediary object or 
signal. If analysis shows that this case is slow, you spend a bit of 
time to optimize _that_ case. You cannot do the same for the many 
individual cases where there is maximum a handful of connections to any 
given signal or slot.


But: this reasoning is as much dependent on actual data on what the 
distribution of n is as the orignal statement that it does make sense. 
Hence my question on the availability of such data...


André

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

Re: [Development] leak in QMetaObject?

2016-07-20 Thread Edward Welbourne 
Op 20/07/2016 om 10:41 schreef Olivier Goffart:
>> The distribution does not matter. If it can be big, quadradic
>> complexity can be a blocker.

André Somers replied
> Nonsense. There is no need to pessimize the frequent cases to cater
> for avoiding a performance issue in an exceptional case.

Well, it depends ...

You've got some function, F, from number of connections to cost of any
given way of handling connections.  You've got some distribution P over
values n takes.  Your total cost is the sum of P(n).F(n) over that range
of values.  The big-O discussion is usually about how F varies; but what
actually matters is the sum of P(n).F(n).

If your distribution has a long tail (so sum(P(n); n > N) dies off
slowly as N grows) and F(n) grows fast, it is quite easy for
sum(P(n).F(n)) to be dominated by its contributions from large n, even
if they are rare, as long as there are enough of them to - when scaled
by their relatively huge F(n) - add up.

The frequency distribution P effectively acts like the constant of
proportionality that your big-O notation ignores; if that constant is
large for an O(n) algorithm but small for an O(n^2) algorithm, n has to
be large compared to the ratio between those two constants of
proportionality before O(n^2) is worse than O(n).  If one in a thousand
of your population has n ~ 1k then an O(n^2) algorithm has those costing
as much as all the (vastly more common) cases with n ~ 1.

So optimising for the rare case (which may indeed make the common case
more expensive) can indeed be worth it, because the rare case can end up
making a disproportionate contribution to your total costs.  You have to
know your distribution before you make up your mind about this - and
dumb statistics like mean and median are no substitute for the actual
distribution, for all that they're better than no data.  Long tails matter.

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

Re: [Development] Revisiting high-DPI configuration options

2016-07-20 Thread Michael Zanetti 


On 20.07.2016 11:12, Edward Welbourne wrote:
> Prav said:
>> Another problem will be with icons. They will scale bad. We are used
>> to make icons with versions like _x2, _x3 ... and what we going to do
>> if scale factor will be fractional? ... have icons versions like _1.1
>> _1.2 _1.3?  Probably we need to rethink why in the world we make so
>> many copies of one icon in compile time if we can make one SVG icon
>> which can be scaled to any size without loss of crispness in
>> runtime. Especially material design makes this easier because we
>> mostly see only contours in material design icons.  So the next step
>> for Qt can be supporting of SVG-icons as main and preferable way for
>> setting icons. In this case icons can be scaled clearly.
> 
> I am baffled that anyone does the _x2, etc., approach to icons any more,
> when most icons are indeed well-suited to SVG - in most cases, a tiny
> SVG, smaller (in file-size) than any one of the many icons it makes
> redundant, can do an excellent job of presenting the clear visual that
> the icon is supposed to provide.  Making many larger files seems to
> serve no purpose - other than letting web-or-UI designers bill their
> clients for large amounts of pointless make-work.

Well, in smaller icons you can have less details than in bigger icons,
so having multiple icons does make sense. Also rendering svg icons is
slower than bitmaps so in some cases that won't work out either.

What we do in ubuntu is to find the closes available icon that's larger
than the current ui scale and then scale it down. In case no larger one
is available we fall back to the closest available smaller one and scale
it up. And as I said before, we also use icon_x2.svg and icon_x3.svg for
different levels of details in the image.


> 
> Then again, our SVG support is embarrassingly poor,
> 
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 



signature.asc
Description: OpenPGP digital signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] leak in QMetaObject?

2016-07-20 Thread André Somers 



Op 20/07/2016 om 10:41 schreef Olivier Goffart:

On Mittwoch, 20. Juli 2016 10:01:26 CEST André Somers wrote:

Op 19/07/2016 om 18:06 schreef Olivier Goffart:

It is true that we could consider trying to clean the connection list
after
each signal emission if it is dirty.
We don't want to do it after each disconnect because this can turn a O(n)
algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it
for every disconnect, that n*O(n))

Did anyone ever measure in practice what the distribution in values for
n is here? My *guess* is that it won't be all that large. I expect a
distribution with a spike at n=1 or 2, and then a dropoff with a very
long tail, perhaps spiking at a bit larger number when using QML for all
the propertybindings going on. Big-O notation doesn't make a lot of
sense if the n is small, it only starts to have an impact if n grows.

The distribution does not matter. If it can be big, quadradic complexity can
be a blocker.
Nonsense. There is no need to pessimize the frequent cases to cater for 
avoiding a performance issue in an exceptional case. The test case 
presented is clearly not a normal usage pattern. Of course, if you can 
optimize the algorithmic complexity for the exceptional cases without 
affecting the performance for the cases where n is small, then by all 
means do just that. I also don't think it is up to Qt to try to mitigate 
wrong usage patterns like disconnecting many slots from a single signal 
in a loop.



I would be suprised if the impact of the list being a single-linked list
and thus having to skip through memory to get from node to node was not
bigger than any "big-O" benefits you gained from doing it this way in
the first place.

Maybe changing to a vector could be indeed beneficial. Note that it's not that
simple as the nodes are in two different linked list at the same time. And
this is used for efficient disconnect when a reciever is destroyed.
You know much more about this than I do of course, and perhaps a linked 
list _is_ the best data structure for this case.



On the other hand, you'd have to consider the likelyhood of another
connect hapening after a disconnect. If that is nearly 1, then sure,
that may be a good time to clean up. But if it is closer to 0 in reality...

It would still not be a leak since the used memory is bounded to O (maximum
amount of connection on that object at the same time)
No, it would not be a leak. I did not claim it was. It would still be 
wasted memory though that is kept for (way) longer than needed.


André

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

Re: [Development] leak in QMetaObject?

2016-07-20 Thread Olivier Goffart 
On Mittwoch, 20. Juli 2016 10:01:26 CEST André Somers wrote:
> Op 19/07/2016 om 18:06 schreef Olivier Goffart:
> > It is true that we could consider trying to clean the connection list
> > after
> > each signal emission if it is dirty.
> > We don't want to do it after each disconnect because this can turn a O(n)
> > algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it
> > for every disconnect, that n*O(n))
> 
> Did anyone ever measure in practice what the distribution in values for
> n is here? My *guess* is that it won't be all that large. I expect a
> distribution with a spike at n=1 or 2, and then a dropoff with a very
> long tail, perhaps spiking at a bit larger number when using QML for all
> the propertybindings going on. Big-O notation doesn't make a lot of
> sense if the n is small, it only starts to have an impact if n grows. 

The distribution does not matter. If it can be big, quadradic complexity can 
be a blocker.

> I would be suprised if the impact of the list being a single-linked list
> and thus having to skip through memory to get from node to node was not
> bigger than any "big-O" benefits you gained from doing it this way in
> the first place.

Maybe changing to a vector could be indeed beneficial. Note that it's not that 
simple as the nodes are in two different linked list at the same time. And 
this is used for efficient disconnect when a reciever is destroyed.

> On the other hand, you'd have to consider the likelyhood of another
> connect hapening after a disconnect. If that is nearly 1, then sure,
> that may be a good time to clean up. But if it is closer to 0 in reality...

It would still not be a leak since the used memory is bounded to O (maximum 
amount of connection on that object at the same time)

If you do:

 forever {
   QObject::connect(, ...);
 }

you have a leak because the amount of connection grow to infinity. but that's 
your fault.

If you do:

 forever {
   QObject::connect(, ...);
   QObject::disconnect(, ...);
 }

You have no leak. Sure, there will always be one unused node in the internal 
datastructure, but it is not a leak as the memory usage does not grow. 
And that node will be also removed when the object is destroyed.


So people have been memory profiling applications, and i don't think the 
amount of connection (and especially 'dead' connection) has been a problem.


In Thomas's example, the issue was that he made 1000's of connections, then 
disconnect them all, and the internal nodes are staying. But that should not 
be a problem as this fabricated example does not exist in practice.
For example, here is an example based on his that simulate this single shot 
connection.
http://paste.ofcode.org/Gb5y5GyzCcDVFvCgQRe3V7
This will run forever, and the memory usage should not grow.

-- 
Olivier

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

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

Re: [Development] leak in QMetaObject?

2016-07-20 Thread André Somers 



Op 19/07/2016 om 18:06 schreef Olivier Goffart:

On Donnerstag, 14. Juli 2016 17:45:58 CEST Thomas Senyk wrote:

On 14.07.2016 17:18, André Somers wrote:

Op 14/07/2016 om 17:10 schreef Olivier Goffart:

On Donnerstag, 14. Juli 2016 16:33:26 CEST Thomas Senyk wrote:

Hi,

I lately wanted to validate that a connecting to a lambda
will not leak the lambda object .. and found that more then that is
leaked.

Here is my example: http://paste.ofcode.org/36dmWCT8ddF6Zaqb9csKZNv

After the 10million connections are executed and disconnected (all of
them a successful), I assume a drop in memory consumption and more
importantly a drop of cpu load to close to 0%.

I see neither one nor the other. I see continues 100% consume with no
memory consumption drop what so ever.

I did a quick peak into QMetaObject::activate and it seems no clean up
happened .. the list returned in

list = >at(signal_index);
(line #3660 in 5.6 checkout from today)

seems rather long! (10million?)

However all "if (!c->receiver)" shows no receiver and therefor will
continue right away .. at least

Is this expected? A bug? ... I'm happy to fill a bug report, I just
wanted to get some feedback, maybe I'm just doing something wrong

The lambda object and its capture is destroyed by the call to

slotObj->destroyIfLastRef()

The internal data structre (QObjectPrivate::Connection) is deleted by
QObjectPrivate::cleanConnectionLists which is actually only called when
a new connection is made to this object.

I don't think there is a leak, but it is true that some memory is only
free'ed
when you add new connection or that the object is destroyed. (but the
lambda
object is destroyed right after the disconnection)

Then this:
http://paste.ofcode.org/37rxyitynhEqi5gira88hR9

should "fix" it? .. but I still see 100% cpu and same memory consumption?

As thiago says, your thing still does not work because when you connect from a
signal connected to the same object, the list is inUse and will not be
cleaned.

for (int i = 1; i <= 1000; i++) {
  // ... your code
}
QTimer::singleShot(200, // so it's after the last disconnect
   [] { QObject::disconnect(QObject::connect(t, ::timeout, []{})); });

So the connect happens after everything was disconnected.

In practice you probably don't need to use this workaround, unless you always
add new connection from a slot connected to a signal of the object you
continue to connect and disconnect to. Is that what you are doing?

It is true that we could consider trying to clean the connection list after
each signal emission if it is dirty.
We don't want to do it after each disconnect because this can turn a O(n)
algorithm into a O(n^2)   (cleaning the list is O(n), if we have to do it for
every disconnect, that n*O(n))

Did anyone ever measure in practice what the distribution in values for 
n is here? My *guess* is that it won't be all that large. I expect a 
distribution with a spike at n=1 or 2, and then a dropoff with a very 
long tail, perhaps spiking at a bit larger number when using QML for all 
the propertybindings going on. Big-O notation doesn't make a lot of 
sense if the n is small, it only starts to have an impact if n grows. I 
would be suprised if the impact of the list being a single-linked list 
and thus having to skip through memory to get from node to node was not 
bigger than any "big-O" benefits you gained from doing it this way in 
the first place.


On the other hand, you'd have to consider the likelyhood of another 
connect hapening after a disconnect. If that is nearly 1, then sure, 
that may be a good time to clean up. But if it is closer to 0 in reality...


Note that if you are worried of somebody disconnecting in a loop or 
something: simply make sure to have a fast path. A disconnect 
(ptrSender, 0, ptrReceiver, 0) obviously doesn't need a cleanup after 
every individual disconnect...


André

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