A lot of it will depend on what you are using Qt for.
I used the Qt Solution for WinMigrate, which essentially (At a very high level)
makes sure the Qt event loop gets called when the MFC event loop is run.
Where I used it was to add Qt windows and Qt eventloop driven functionality
(QHttp befor
How can I reuse the MFC based GUI dll in a QT application?
2016-06-26 21:53 GMT+08:00 techabc :
> I need to call 300+ MFC extending DLL in a new QT 5.x application, if
> except winmigrate, whatthing else can do it?
>
___
Development mailing list
Develo
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 f
On quarta-feira, 20 de julho de 2016 21:21:48 PDT Konstantin Tokarev wrote:
> 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
And who do you think wrote QtSvg in the first
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
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 Win
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
n
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.
>
>>
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 f
> 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
On quarta-feira, 20 de julho de 2016 20:13:07 PDT Prav wrote:
> 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 Q
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
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 P
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
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 forc
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
> redund
> -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
> -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 ou
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 fl
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-
> 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
> 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 j
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 displ
> 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
>
> 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
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 (valu
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 par
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 j
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 det
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.
B
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.
We
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? Probab
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
> m
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 c
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 vali
39 matches
Mail list logo
