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
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
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
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
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
> 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
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
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
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
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
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
>
> -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
> -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
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
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 :
>
>
>
> 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
> 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
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
> 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
>
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
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
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
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
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.
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
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.
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?
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
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
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
31 matches
Mail list logo