+1
martin
From: Development on behalf of Randall
O'Reilly
Sent: Friday, December 04, 2015 8:35 AM
To: Marc Mutz
Cc: development@qt-project.org
Subject: Re: [Development] RFC: more liberal 'auto' rules?
This debate between the std:: lib and wider C++ co
> On Dec 4, 2015, at 00:05, Benjamin TERRIER wrote:
>
> Hi everyone,
>
> This message follows an exchange I've had with Thiago on a bug report:
>https://bugreports.qt.io/browse/QTBUG-49749
>
>
> In the current state, QMetaObject::connectSlotsByName() tries to find,
> for each slot named "
On Thursday 3. December 2015 18:00:15 Thiago Macieira wrote:
> On Friday 04 December 2015 00:27:09 Olivier Goffart wrote:
> > I don't think it will break too many applications because anyone who was
> > relying on the order of instentiation for that has just its application
> > working out of pure
Due to some hardware migration mailing list services will experience a short
downtime during the weekend.
Apologies for any delays caused in mail delivery.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/lis
This debate between the std:: lib and wider C++ community vs. the Qt traditions
seems never-ending :) At the risk of perpetuating the inevitable flame war, my
perspective is well captured in this article:
http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/
C++ is WAY too complex of a la
On Friday 04 December 2015 02:56:11 Thiago Macieira wrote:
> On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
> > That depends on how big the remainder is. I argue that we're relevant
> > enough that our own direction is big enough to be of relevance.
>
> That didn't come out right. R
On Friday 04 December 2015 00:27:09 Olivier Goffart wrote:
> I don't think it will break too many applications because anyone who was
> relying on the order of instentiation for that has just its application
> working out of pure luck. (And i'm pretty sure that your proposal is always
> the intende
On Thursday 03 December 2015 14:14:19 Thiago Macieira wrote:
> That depends on how big the remainder is. I argue that we're relevant
> enough that our own direction is big enough to be of relevance.
That didn't come out right. Rephrasing:
Qt has enough market share by itself that we can choose o
On Friday 4. December 2015 00:05:19 Benjamin TERRIER wrote:
> Hi everyone,
>
> This message follows an exchange I've had with Thiago on a bug report:
> https://bugreports.qt.io/browse/QTBUG-49749
>
>
> In the current state, QMetaObject::connectSlotsByName() tries to find,
> for each slot nam
Hi everyone,
This message follows an exchange I've had with Thiago on a bug report:
https://bugreports.qt.io/browse/QTBUG-49749
In the current state, QMetaObject::connectSlotsByName() tries to find,
for each slot named "on__" in a given
object,
a child object named " and connect the signal t
On Thursday 03 December 2015 21:15:42 Bubke Marco wrote:
> On December 3, 2015 19:06:17 Thiago Macieira
wrote:
> > On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> >> The remainder of the C++ world is moving towards an "always auto" scheme.
> >> We don't need to go there, but I'd at least
On December 3, 2015 19:06:17 Thiago Macieira wrote:
> On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
>> The remainder of the C++ world is moving towards an "always auto" scheme. We
>> don't need to go there, but I'd at least like to propose, for new code and
>> as a drive-by, the *requ
El Friday 27 November 2015, Bauer, Christian escribió:
> Our (simplified) problem is: this function does not return a value but
> feeds an asynchronous pipeline. When the pipeline processing is done it
> will call promise.SetResult(); promise.reportResult();
> and only then the future should be not
El Thursday 03 December 2015, Mark De Wit escribió:
> Building from source would be an option, I guess. We have done it in the
> past, but the build process / flags (for distribution) is not sufficiently
> well documented, and starting with 5.5.1 we were excited to be able to use
> official binari
On 2015-12-03 13:02, Thiago Macieira wrote:
> On 2015-12-03 13:49, Marc Mutz wrote:
> I'd at least like to propose, for new code and as
>> a drive-by, the *required* use of auto for:
>>
>> - all loop variables (both index and iterators)
>> the reason being that spelling out the name is usually
On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> The remainder of the C++ world is moving towards an "always auto" scheme. We
> don't need to go there, but I'd at least like to propose, for new code and
> as a drive-by, the *required* use of auto for:
The remainder of the C++ world is no i
Hi,
The wiki[1] currently contains some rules for how to use automatic type
deduction for variables (Q_C_AUTO_TYPE) that are very restrictive.
[1] I get an ERROR: state not found when trying to log in, btw.
And pointless.
The remainder of the C++ world is moving towards an "always auto" scheme
On Thursday 03 December 2015 18:13:58 Konstantin Tokarev wrote:
> > Instead, you should build this:
> > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-o
> > pensource-src-5.5.1.zip
> > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit->
> > > openso
03.12.2015, 18:05, "Thiago Macieira" :
> On Thursday 03 December 2015 15:54:42 Konstantin Tokarev wrote:
>> > Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are
>> > also
>> > QtWebKit 5.6.0 sources in git, they are just not part of the official
>> > release.
>> Why not a
On Thursday 03 December 2015 15:54:42 Konstantin Tokarev wrote:
> > Besides being possible to use QtWebKit from 5.5 with Qt 5.6, there are
> > also
> > QtWebKit 5.6.0 sources in git, they are just not part of the official
> > release.
> Why not at least package its sources them same way as are sour
There is QPdfWriter at least which is a paint device, so you could use that for
generating PDFs as that is available iOS from what I can see.
Andy
From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
Edward Sutton
Sent: 3. desember 2015 15:09
To: Mark De Wit
Cc: developmen
Will Qt 5.6 have alternative methods to export HTML to PDF that support major
platforms of Android, iOS, Linux, OS X, and Windows?
On iOS a Qt developer must resort to native code to generate PDF files.
Unfortunately Qt 5.5 PDF export is dependent on QPrinter which is not supported
on iOS. Whi
Thanks for all the feedback everyone.
We are excited about the 5.6 release because we are looking closely at the new
Qt3D module, as well as migrating to VS 2015. Sadly, PDF export of HTML
content is a critical feature for our product (in general I'm happy to move to
WebEngine, but we cannot r
03.12.2015, 15:41, "Allan Sandfeld Jensen" :
> On Thursday 03 December 2015, Mark De Wit wrote:
>> Hi all,
>>
>> QtWebEngine does not yet have feature parity with QtWebkit. For instance,
>> print support (especially export to PDF) is a critical requirement for my
>> use of Webkit. This missin
On Thursday 03 December 2015, Mark De Wit wrote:
> Hi all,
>
> QtWebEngine does not yet have feature parity with QtWebkit. For instance,
> print support (especially export to PDF) is a critical requirement for my
> use of Webkit. This missing feature prevents me from migrating to
> WebEngine.
>
Hi Mark,
If you need to use Qt Webkit, then it is probably better to stay with Qt 5.5.
There is nothing that makes Qt 5.5 bad overnight, if it works for you now. Qt
WebEngine is in many aspects already much better in features than Qt Webkit. Qt
WebEngine is also better maintained, and does rec
Op 03/12/2015 om 12:18 schreef Mark De Wit:
Hi all,
QtWebEngine does not yet have feature parity with QtWebkit. For
instance, print support (especially export to PDF) is a critical
requirement for my use of Webkit. This missing feature prevents me
from migrating to WebEngine.
Removing
Hi all,
QtWebEngine does not yet have feature parity with QtWebkit. For instance,
print support (especially export to PDF) is a critical requirement for my use
of Webkit. This missing feature prevents me from migrating to WebEngine.
Removing webkit from the official distribution will prevent
28 matches
Mail list logo
