Re: [Development] High-dpi Qt best practices

On 10.10.2012, at 16:56, Olivier Goffart wrote: What is wrong with this alternative: All the API stays always in pixel (QIcon, QWidget::geometry, ...) QCoreApplication::setAttribute(Qt::AA_MacHighDPI) (should it maybe be even be set by default?) Setting it as default would make it impossible

Re: [Development] No recent commit in qt5 git?

Thiago Macieira said: > On quarta-feira, 10 de outubro de 2012 15.01.56, Stephen Chu wrote: > > The last commit in was a week ago. Is > > it frozen for release? > > No. It's blocked on failing tests. Help fix them and it will go in sooner :-) > To elaborate ... y

Re: [Development] No recent commit in qt5 git?

On 11/10/12 05:01, Stephen Chu wrote: > I think I can bring qtbase to head for that. But last time I did it, I > had to wipe my whole Qt5 repo to get back to qt5 current. Maybe I will > have better luck this time. :) In 99.999% of cases, if you remove your git repo to fix a problem, you're doing

Re: [Development] No recent commit in qt5 git?

On 10/10/12 3:59 PM, Thiago Macieira wrote: > On quarta-feira, 10 de outubro de 2012 15.01.56, Stephen Chu wrote: >> The last commit in was a week ago. Is >> it frozen for release? > > No. It's blocked on failing tests. Help fix them and it will go in sooner :-) I

Re: [Development] Un-messifying Qt Quick

On quarta-feira, 10 de outubro de 2012 18.23.49, Knoll Lars wrote: > I am against making QML2 a subdirectory of imports (ie. option a1). So > either a separate directory, or we keep the QML 1 modules in a > subdirectory. Both are ok for me. cf the layout proposal: lib/qt5/imports-> Qt Q

Re: [Development] No recent commit in qt5 git?

On quarta-feira, 10 de outubro de 2012 15.01.56, Stephen Chu wrote: > The last commit in was a week ago. Is > it frozen for release? No. It's blocked on failing tests. Help fix them and it will go in sooner :-) > I just saw

Re: [Development] No recent commit in qt5 git?

Hi Stephen On Wed, Oct 10, 2012 at 4:01 PM, Stephen Chu wrote: > The last commit in was a week ago. Is > it frozen for release? > > I just saw has been > merged and wanted to try it but can't since it's not in Qt 5

[Development] No recent commit in qt5 git?

The last commit in was a week ago. Is it frozen for release? I just saw has been merged and wanted to try it but can't since it's not in Qt 5 yet. I think I can bring qtbase to head for that. But last time I did

Re: [Development] Un-messifying Qt Quick

On Oct 10, 2012, at 7:53 PM, Thiago Macieira wrote: > On segunda-feira, 24 de setembro de 2012 15.07.06, Thiago Macieira wrote: >> import $prefix/imports $prefix/imports >> $prefix/imports >> QtQuick 1.[01] QtQuick 1.[01] QtQuick 2.0 > > H

Re: [Development] QThread usage/guidance

> -Original Message- > From: Giuseppe D'Angelo [mailto:dange...@gmail.com] > Sent: Wednesday, October 10, 2012 12:46 PM > To: Tony Van Eerd > Cc: Sze Howe Koh; development@qt-project.org > Subject: Re: [Development] QThread usage/guidance > > On 10 October 2012 16:00, Tony Van Eerd wrote:

Re: [Development] Un-messifying Qt Quick

On segunda-feira, 24 de setembro de 2012 15.07.06, Thiago Macieira wrote: > import $prefix/imports $prefix/imports > $prefix/imports > QtQuick 1.[01] QtQuick 1.[01] QtQuick 2.0 Hmm... Qt Quick 1 in Qt 5 supports installing its files in a sub

Re: [Development] QThread usage/guidance

On 10 October 2012 18:20, Olivier Goffart wrote: > > If you connect to an object living in the finishing thread, it will be a > direct conection. And obviously instead of reading > connect(thread, SIGNAL(finished()), worker, SLOT(deleteLater())); I read > connect(thread, SIGNAL(finished()), th

Re: [Development] Is overriding an existing virtual method 'BC' in Qt 4?

On quarta-feira, 10 de outubro de 2012 19.13.33, Marc Mutz wrote: > In short: https://bugreports.qt-project.org/browse/QTBUG-13230 is a WontFix > for Qt 4. Agreed. > > > Now, what's the forward-compatibility policy on the 4.8 branch? > > > > Any program compiled with Qt 4.8.x will run with Qt 4

Re: [Development] Co-installation & library naming rules

On quarta-feira, 10 de outubro de 2012 18.03.31, Oswald Buddenhagen wrote: > On Sun, Sep 23, 2012 at 08:30:31PM +0200, Erik van Pienbroek wrote: > > why not solve the problem at the level where it's supposed to be > > fixed, upstream? > > i disagree with your premise. ;) > the whole proposal addre

Re: [Development] Qt 5 file hierarchy

On quarta-feira, 10 de outubro de 2012 18.04.18, Oswald Buddenhagen wrote: > On Fri, Sep 21, 2012 at 06:01:28PM +0200, Thiago Macieira wrote: > > As for mkspecs, I believe they should be in share, since they are > > technically- speaking arch-independent. > > except for qconfig.pri, which spoils t

Re: [Development] QThread usage/guidance

On Wednesday 10 October 2012 17:45:51 Giuseppe D'Angelo wrote: > On 10 October 2012 16:00, Tony Van Eerd wrote: > > I don't have any use cases, but I can't imagine the example recommendation > > of > > > > connect(thread, SIGNAL(finished()), worker, SLOT(deleteLater())); > > > > working as expec

Re: [Development] Is overriding an existing virtual method 'BC' in Qt 4?

On Tuesday October 9 2012, Thiago Macieira wrote: > 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

Re: [Development] Qt 5 file hierarchy

On 21 Sep 2012, at 6:01 PM, ext Thiago Macieira wrote: > pkgconfig/ - versioned .pc files > qt5/ - arch-specific support files: > bin/ or libexec/ >- executables not run by the user, like syncqt, lrelease, > lupdate > imports/ >

Re: [Development] QThread usage/guidance

On 10 October 2012 16:00, Tony Van Eerd wrote: > I don't have any use cases, but I can't imagine the example recommendation > of > > connect(thread, SIGNAL(finished()), worker, SLOT(deleteLater())); > > working as expected unless deleteLater() happens on the same thread as > finished(), via a dire

Re: [Development] QThread usage/guidance

> -Original Message- > From: Olivier Goffart [mailto:oliv...@woboq.com] > > > So I'd like to understand how it works. Maybe that means looking > more at > > the code than the docs. But the code can change - the real > "contract" is > > in the docs. > > Depends of the point of view... To

Re: [Development] Qt 5 file hierarchy

On Fri, Sep 21, 2012 at 06:01:28PM +0200, Thiago Macieira wrote: > As for mkspecs, I believe they should be in share, since they are technically- > speaking arch-independent. > except for qconfig.pri, which spoils the whole party. ___ Development mailing

Re: [Development] Co-installation & library naming rules

On Sun, Sep 23, 2012 at 08:30:31PM +0200, Erik van Pienbroek wrote: > why not solve the problem at the level where it's supposed to be > fixed, upstream? > i disagree with your premise. ;) the whole proposal addresses only one specific issue: conflicts between major qt versions. like it or not, th

Re: [Development] RFC: Qt Security Policy

On quarta-feira, 10 de outubro de 2012 16.06.43, Richard Moore wrote: > It was discussed with the Gerrit people, there's a response from them > in the comments where they discuss how they handle the same issue for > security holes in gerrit itself. Short version is that they have a > second private

Re: [Development] RFC: Qt Security Policy

I suggest git-send-email to the security list. I've used email (git-send-email) based patch review in low traffic projects and found it to work really really well. Simon -- Sendt fra min Nokia N909.10.12 18:59 skrev Richard Moore: On 9 October 2012 09:21, Marc Mutz wrote: > Hi Rich, > > Thanks

Re: [Development] QThread usage/guidance

On Wednesday 10 October 2012 15:00:15 Tony Van Eerd wrote: > I don't have any use cases, but I can't imagine the example recommendation > of > > connect(thread, SIGNAL(finished()), worker, SLOT(deleteLater())); > > working as expected unless deleteLater() happens on the same thread as > finished(

Re: [Development] High-dpi Qt best practices

On 10 Oct 2012, at 4:56 PM, Olivier Goffart wrote: > What is wrong with this alternative: > > All the API stays always in pixel (QIcon, QWidget::geometry, ...) > > QCoreApplication::setAttribute(Qt::AA_MacHighDPI) > (should it maybe be even be set by default?) > > If that is set, everything i

Re: [Development] RFC: Qt Security Policy

On 10 October 2012 14:02, Konstantin Tokarev wrote: > > > 09.10.2012, 20:59, "Richard Moore" : >> 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:

Re: [Development] QThread usage/guidance

I don't have any use cases, but I can't imagine the example recommendation of connect(thread, SIGNAL(finished()), worker, SLOT(deleteLater())); working as expected unless deleteLater() happens on the same thread as finished(), via a direct call. So AutoConnection 'happens to work' because of a

Re: [Development] High-dpi Qt best practices

What is wrong with this alternative: All the API stays always in pixel (QIcon, QWidget::geometry, ...) QCoreApplication::setAttribute(Qt::AA_MacHighDPI) (should it maybe be even be set by default?) If that is set, everything is in pixel, but the default font size is twice as big, the mac style

[Development] Fwd: Re: Module maintainer's explicit approval required for Qt 5 inclusion

Lars apparently sent to me directly and I forgot to ask him to resend here. This is important to all. -- Forwarded message -- Subject: Re: [Development] Module maintainer's explicit approval required for Qt 5 inclusion Date: terça-feira, 9 de outubro de 2012, 07.05.26 From: Kno

Re: [Development] QTcpSocket, QLocalSocket, common-use-model?

On quarta-feira, 10 de outubro de 2012 11.03.21, Kevin Krammer wrote: > Not related to performance, but often the main reason to use techniques > such as QLocalSocket is better access control. > Any process (running as any user) on the machine can attempt a connect to a > TCP socket on the loopba

Re: [Development] QFontMetrics and QScriptLine height calculation

QAccessibleTextInterface::characterRect() is supposed to return the bounding box, so if it's one pixel too high or something it's not something I would worry about. The test could therefore be relaxed a bit. It should also be improved so that it doesn't just verify the size (it currently simpl

Re: [Development] RFC: Qt Security Policy

09.10.2012, 20:59, "Richard Moore" : > 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

Re: [Development] RFC: Qt Security Policy

On 10 Oct 2012, at 13:25, d3fault wrote: > On Wed, Oct 10, 2012 at 2:34 AM, Ziller Eike wrote: >>> -CVE/CERT aka private/exclusive notifications go to some email address >>> that only core security team has access to: >>> security-priv...@qt-project.org or something >> >> in the proposal that

Re: [Development] RFC: Qt Security Policy

On Wed, Oct 10, 2012 at 2:34 AM, Ziller Eike wrote: >> -CVE/CERT aka private/exclusive notifications go to some email address >> that only core security team has access to: >> security-priv...@qt-project.org or something > > in the proposal that is secur...@qt-project.org > Yes, but it is a priva

Re: [Development] High-dpi Qt best practices

On Oct 9, 2012, at 1:55 PM, Christoph Feck wrote: > 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 patc

Re: [Development] RFC: Qt Security Policy

On 10 Oct 2012, at 11:18, d3fault wrote: > Oh right this is where I'm supposed to disagree or object or > something... See: > http://lists.qt-project.org/pipermail/development/2012-October/006892.html > > tl;dr: I object on the grounds that behind closed doors security is > not only a waste of

Re: [Development] RFC: Qt Security Policy

Oh right this is where I'm supposed to disagree or object or something... See: http://lists.qt-project.org/pipermail/development/2012-October/006892.html tl;dr: I object on the grounds that behind closed doors security is not only a waste of time, it also hurts Qt _users_. Do This: -CVE/CERT ak

Re: [Development] Integration system problems

On Wed, Oct 10, 2012 at 12:59 AM, Thomas McGuire wrote: > Hi, > > On Tuesday 09 October 2012 13:28:01 Peter Varga wrote: >> 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 i

Re: [Development] QTcpSocket, QLocalSocket, common-use-model?

On Monday, 2012-10-08, 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? (...i

Re: [Development] Integration system problems

Hi, On Tuesday 09 October 2012 13:28:01 Peter Varga wrote: > 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. There seems to be another problem with