Bill,
this is corrected now:
http://download.froglogic.com/public/qt5-squishcoco-report/QtBase/source_543.html#line467
Regards
Am 08.10.2012 um 12:26 schrieb Sébastien Fricker :
> Thanks Bill,
> this is effectively not correct, the lines should be marks as executed.
> Let me have a deeper look on
On quarta-feira, 10 de outubro de 2012 10.11.59, pengliang wrote:
> QSqlError(0, "QODBC3: Unable to connect", "[unixODBC][Driver Manager]Data
> source name not found, and no default driver specified")
>
>
>
> But I found QODBC is available driver:
>
> "QSQLITE"
>
> "QMYSQL3"
>
> "QMYSQL"
>
>
On Wed, Oct 10, 2012 at 1:20 AM, Tony Van Eerd wrote:
> Speaking of docs, should the docs for the started() and finished() signals
> note which thread these signals are sent from? ie finished(), even in
> http://doc-snapshot.qt-project.org/5.0/qthread.html#finished and I think
> in https://coder
On Tue, Oct 9, 2012 at 4:49 PM, Giuseppe D'Angelo wrote:
> On 9 October 2012 03:56, Sze Howe Koh wrote:
> > That's a great idea! Is there a way to see a list of all doc notes
> > available?
>
> Not yet , https://bugreports.qt-project.org/browse/QTWEBSITE-471 .
> You could start by http://qt-proje
Hi list,
I have compiled libqsqlodbc.so on redhat64bit successfully.
When I run the snippets bellow some error message occurred.
QString Dsn = QString::fromLocal8Bit("Driver={sql
server};server=172.2.2.2;database=Live;uid=an;pwd=an;");
QSqlDatabase::addDatabase("QODBC");
Error
Peter Varga said:
> Hi all,
>
> I've noticed that merging patches into QtDeclarative repository doesn't
> really work, see https://codereview.qt-project.org/#change,36116
> I suppose that the problem is in the integration system. The build log
> of my last attempt says
>
> HEAD is now at ae9859f
On 9 October 2012 17:59, Thiago Macieira wrote:
> The question is only whether there's more overhead in kernel mode. A quick
> check over the cubicle wall here answers that there is a little overhead more
> with TCP, since it must still verify the netfilter rules (think iptables).
You should take
On terça-feira, 9 de outubro de 2012 19.53.06, Sorvig Morten wrote:
> Thiago:
> >On terça-feira, 9 de outubro de 2012 09.46.37, Sorvig Morten wrote:
> >> I'm re-defining it to be the size in points. I think this intuitive, you
> >> are asking QIcon::pixmap() for pixmap suitable for covering this ma
On Oct 9, 2012, at 1:53 PM, Olivier Goffart
wrote:
>
This is a behaviour change that breaks existing code (in applications and
in Qt), so it's opt-in via QT_HIDPI_AWARE.
>
> I don't think having opt in like that is a good idea. It will be a mess when
> you mix different libraries o
Thiago:
>On terça-feira, 9 de outubro de 2012 09.46.37, Sorvig Morten wrote:
>> I'm re-defining it to be the size in points. I think this intuitive, you are
>> asking QIcon::pixmap() for pixmap suitable for covering this many units on
>> screen - not for a pixmap of a specific size.
>
> When you wr
> -Original Message-
> From: development-bounces+tvaneerd=rim@qt-project.org
> [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf
> Of Kevin Krammer
> >
> > This mailing list is not really for question on how to use Qt. You
> should
> > use the interest mailing-list
On 9 October 2012 08:58, Ziller Eike wrote:
>
> On 9 Oct 2012, at 01:07, Giuseppe D'Angelo wrote:
>
>> Hi Richard,
>>
>> many thanks for the insightful mail.
>>
>> On 8 October 2012 22:49, Richard Moore wrote:
>>
>> […]
>
>>> == What Happens When an Issue is Reported? ==
>>>
>>> * security@ shou
On 9 October 2012 09:21, Marc Mutz wrote:
> Hi Rich,
>
> Thanks for taking the time to write this up. I have but one question:
>
> On Monday October 8 2012, Richard Moore wrote:
>> * Where possible packagers should be informed directly of which SHA1s they
>>should cherry pick in order to get
On terça-feira, 9 de outubro de 2012 17.27.52, Joerg Bornemann wrote:
> On 09/10/2012 15:12, Giuseppe D'Angelo wrote:
> >> There's AFAIK no "short cut" for pure localhost TCP
> >> connections.
> >
> > There are. For instance, checksums are not computed nor checked for
> > packets travelling through
On terça-feira, 9 de outubro de 2012 18.19.19, Marc Mutz wrote:
> > It would still break forward compatibility. Assume you do the change in
> > 5.0.1, and an app gets compiled against 5.0.1 using the new symbol (by not
> > reimplementing it in a derived class, or explicitly calling it). Your app
>
On Tuesday October 9 2012, Knoll Lars wrote:
> On Oct 9, 2012, at 12:31 PM, Marc Mutz wrote:
> > On Wednesday September 26 2012, Thiago Macieira wrote:
> >> But note that there's one stricter requirement: the forwards
> >> compatibility that applies within a patch series. Adding this new
> >> virt
09.10.2012, 01:23, "Charley Bay" :
> Does the "MyLocalSocketOrTcpSocket" class seem stupid, or should I
> just use "QTcpSocket" all the time?
You can create your socket-enabled class as template taking either
QTcpSocket or QLocalSocket, since APIs are mostly the same.
--
Regards,
Konstantin
__
On 09/10/2012 15:12, Giuseppe D'Angelo wrote:
>> There's AFAIK no "short cut" for pure localhost TCP
>> connections.
>
> There are. For instance, checksums are not computed nor checked for
> packets travelling through the loopback interface.
But there's still more overhead (e.g. context switches)
On terça-feira, 9 de outubro de 2012 14.42.32, Knoll Lars wrote:
> > What you're asking for is an intermediate base between QAbstractSocket
> > and
> > QIODevice, but I'm not sure how much it's worth. What methods from
> > QAbstractSocket do you need which are also common (same signature)
> > betwe
On Oct 9, 2012, at 4:32 PM, Thiago Macieira wrote:
> On terça-feira, 9 de outubro de 2012 14.12.16, Giuseppe D'Angelo wrote:
>> On 9 October 2012 13:03, Joerg Bornemann wrote:
>>> There's AFAIK no "short cut" for pure localhost TCP
>>> connections.
>>
>> There are. For instance, checksums are
On terça-feira, 9 de outubro de 2012 09.46.37, Sorvig Morten wrote:
> I'm re-defining it to be the size in points. I think this intuitive, you are
> asking QIcon::pixmap() for pixmap suitable for covering this many units on
> screen - not for a pixmap of a specific size.
When you write the documen
On terça-feira, 9 de outubro de 2012 14.12.16, Giuseppe D'Angelo wrote:
> On 9 October 2012 13:03, Joerg Bornemann wrote:
> > There's AFAIK no "short cut" for pure localhost TCP
> > connections.
>
> There are. For instance, checksums are not computed nor checked for
> packets travelling through th
On terça-feira, 9 de outubro de 2012 12.31.23, Marc Mutz wrote:
> On Wednesday September 26 2012, Thiago Macieira wrote:
> > But note that there's one stricter requirement: the forwards compatibility
> > that applies within a patch series. Adding this new virtual within the
> > same
> > patch serie
On 9 October 2012 13:03, Joerg Bornemann wrote:
> There's AFAIK no "short cut" for pure localhost TCP
> connections.
There are. For instance, checksums are not computed nor checked for
packets travelling through the loopback interface.
Cheers,
--
Giuseppe D'Angelo
__
On 10/09/2012 01:53 PM, Olivier Goffart wrote:
> On Tuesday 09 October 2012 10:50:26 Sorvig Morten wrote:
>> On Oct 9, 2012, at 12:21 PM, Olivier Goffart
>> Pixmaps and images _always_ have exactly QPixmap::size() pixels.
>>
>>> Maybe we can introduce QSizePt
>>> Code would look like
>>> QPixmap p
On 08/10/2012 23:23, Charley Bay wrote:
> QUESTION: If you logically need a "network-socket" (LAN or WAN, but
> sometimes accidentally on the same-computer), is there a *performance*
> issue (or any reasonable design preference) where QLocalSocket would
> be "preferable" to a QTcpSocket? (..
On Tuesday 09 October 2012 10:37:50 Sorvig Morten wrote:
> While preparing an upcoming blog entry I've collected some best
> practices regarding raster graphics (QImage and QPixmap). These
> apply to internal Qt development as well. The patch is still
> pending so they are open for discussion.
>Fr
On Tuesday 09 October 2012 10:50:26 Sorvig Morten wrote:
> On Oct 9, 2012, at 12:21 PM, Olivier Goffart
>
> wrote:
> > On Tuesday 09 October 2012 09:46:37 Sorvig Morten wrote:
> >> On Oct 9, 2012, at 11:32 AM, Olivier Goffart
> >>
> >> wrote:
> >>> But QSize is already the size in pixel.
> >>>
Hi all,
I've noticed that merging patches into QtDeclarative repository doesn't
really work, see https://codereview.qt-project.org/#change,36116
I suppose that the problem is in the integration system. The build log
of my last attempt says
HEAD is now at ae9859f crash fix in designersupport
Initi
On Wednesday September 26 2012, Thiago Macieira wrote:
> But note that there's one stricter requirement: the forwards compatibility
> that applies within a patch series. Adding this new virtual within the same
> patch series means a new, public symbol, which could get used in
> applications.
What
On Tuesday 09 October 2012 09:46:37 Sorvig Morten wrote:
> On Oct 9, 2012, at 11:32 AM, Olivier Goffart
>
> wrote:
> > But QSize is already the size in pixel.
> > Or do you mean that QIcon::pixmap could return a pixmap that is larger
> > than
> > the given QSize, scaled with some magic heuristic
On Tuesday 09 October 2012 03:01 PM, Sorvig Morten wrote:
> On Oct 9, 2012, at 10:59 AM, Pritam
> wrote:
>> Forgive my ignorance, but I didn't understand. AFAIK most of Qt API is
>> in pixels. Do you mean after this patch, one should treat all API as points?
> No problem, the concepts are new an
On 8 Oct 2012, at 14:58, Simon Hausmann wrote:
> On Friday, September 21, 2012 05:24:16 PM Thiago Macieira wrote:
>> On sexta-feira, 21 de setembro de 2012 16.47.11, Thiago Macieira wrote:
>>> Include the major version number (5) in all library base names, like on
>>> Windows, on all platforms.
On Oct 9, 2012, at 11:31 AM, Ziller Eike
wrote:
>
> Afaik setting environment variables is prohibited / not working e.g. on iOS,
> so it would be good to have additional means to achieve this.
Yes, right now it only controls QIcon::pixmap() and if that is all it will end
up doing we might as
On Oct 9, 2012, at 11:32 AM, Olivier Goffart
wrote:
> But QSize is already the size in pixel.
> Or do you mean that QIcon::pixmap could return a pixmap that is larger than
> the given QSize, scaled with some magic heuristics. That is not really
> intuitive. (and violate the current documentati
On Tuesday 09 October 2012 14:29:39 Pritam wrote:
> On Tuesday 09 October 2012 02:07 PM, Sorvig Morten wrote:
> > While preparing an upcoming blog entry I've collected some best practices
> > regarding raster graphics (QImage and QPixmap). These apply to internal
> > Qt development as well. The pat
On Oct 9, 2012, at 10:59 AM, Pritam
wrote:
> Forgive my ignorance, but I didn't understand. AFAIK most of Qt API is
> in pixels. Do you mean after this patch, one should treat all API as points?
No problem, the concepts are new and I'm still figuring out how they apply to
Qt and how to best pr
On 9 Oct 2012, at 10:59, Pritam wrote:
> On Tuesday 09 October 2012 02:07 PM, Sorvig Morten wrote:
>> While preparing an upcoming blog entry I've collected some best practices
>> regarding raster graphics (QImage and QPixmap). These apply to internal Qt
>> development as well. The patch is sti
On 9/10/12 5:17 PM, Simon Hausmann wrote:
> On Tuesday, October 09, 2012 09:07:10 AM Lincoln Ramsay wrote:
>> On 08/10/12 22:58, Simon Hausmann wrote:
>>> Now this has some ugly implications, everyone will have to change the way
>>> they develop with Qt 5. In this context we have another interestin
On Tuesday 09 October 2012 02:07 PM, Sorvig Morten wrote:
> While preparing an upcoming blog entry I've collected some best practices
> regarding raster graphics (QImage and QPixmap). These apply to internal Qt
> development as well. The patch is still pending so they are open for
> discussion.
On 9 October 2012 03:56, Sze Howe Koh wrote:
> That's a great idea! Is there a way to see a list of all doc notes
> available?
Not yet , https://bugreports.qt-project.org/browse/QTWEBSITE-471 .
You could start by http://qt-project.org/doc/all_notes_rss , then for
each author pick the docnotes the
While preparing an upcoming blog entry I've collected some best practices
regarding raster graphics (QImage and QPixmap). These apply to internal Qt
development as well. The patch is still pending so they are open for discussion.
(I use image and pixmap interchangeably here, most points apply to
On 10/09/2012 01:07 AM, Giuseppe D'Angelo wrote:
> (...)
>> * Security issues should not be reported via the normal
>> bugreports.qt-project.org tracker, but should instead be sent to
>> security at qt-project.org.
>
> This requires advertising such address properly, on the main
> qt-proj
Hi Rich,
Thanks for taking the time to write this up. I have but one question:
On Monday October 8 2012, Richard Moore wrote:
> * Where possible packagers should be informed directly of which SHA1s they
> should cherry pick in order to get a security fix.
What process do you recommend to pre
Hi Rich,
thanks for putting this together. I like the proposal. It's lightweight, but
will IMO cover our needs.
On Oct 9, 2012, at 1:07 AM, Giuseppe D'Angelo wrote:
> Hi Richard,
>
> many thanks for the insightful mail.
>
> On 8 October 2012 22:49, Richard Moore wrote:
>
>> = Proposed Secu
On 9 Oct 2012, at 01:07, Giuseppe D'Angelo wrote:
> Hi Richard,
>
> many thanks for the insightful mail.
>
> On 8 October 2012 22:49, Richard Moore wrote:
>
> […]
>> == What Happens When an Issue is Reported? ==
>>
>> * security@ should be sent to a 'core security' team of developers who n
On Tuesday, October 09, 2012 09:07:10 AM Lincoln Ramsay wrote:
> On 08/10/12 22:58, Simon Hausmann wrote:
> > Now this has some ugly implications, everyone will have to change the way
> > they develop with Qt 5. In this context we have another interesting
> > artifact: People who have been developi
47 matches
Mail list logo
