Since no one has spoken up, that means we have the official Qt 5.0 release list.
It will include the following Git repositories:
qtbase
qtwebkit
qtquick1
qtdeclarative
qttools
qtwebkit
qtactiveqt
qtmultimedia
qtimageformats
On sexta-feira, 12 de outubro de 2012 07.27.51, Marc Mutz wrote:
> Hi,
>
> I was wondering whether we should stop using the pattern of declaring
> _q_privateSlots() in favour of connecting to functors or functions directly.
Makes sense, except that it's of inconvenient use:
- lambdas: can't use
Hi,
I was wondering whether we should stop using the pattern of declaring
_q_privateSlots() in favour of connecting to functors or functions directly.
Rationale:
R1. the _q_ prefix is just a convention, the slot can still be called through
the meta-object and still can be reimplemented in more
On sexta-feira, 12 de outubro de 2012 10.01.03, Lincoln Ramsay wrote:
> On 12/10/12 09:18, Thiago Macieira wrote:
> > The only tools that need renaming are the tools that are run by users but
> > are tied to a specific library version. That's basically qmake.
> >
> > If we had a generic build tool
On 12/10/12 09:18, Thiago Macieira wrote:
> The only tools that need renaming are the tools that are run by users but are
> tied to a specific library version. That's basically qmake.
>
> If we had a generic build tool that worked with multiple Qt versions (like
> cmake), we wouldn't need to do it.
On 11/10/12 15:06, BRM wrote:
> - Original Message -
>
>> From: Sorvig Morten
>> Subject: Re: [Development] Behavior change: A sane and consistent QPainter
>> coordinate system in Qt 5
>>
>>
>> On Oct 11, 2012, at 1:57 PM, Samuel Rødal
>> wrote:
>>>
>>> It's unfortunate to potentially ca
On quinta-feira, 11 de outubro de 2012 18.44.39, Stephen Chu wrote:
> I just installed mingw-build 4.7.2 on Windows 7 64-bit. I then
> configured Qt 5 this way:
>
> configure -developer-build -opensource -confirm-license -nomake tests
> -nomake examples -c++11
>
>
> The built libraries are in 64
On quinta-feira, 11 de outubro de 2012 14.02.11, shane.kea...@accenture.com
wrote:
> Libproxy performance is unknown, I've only done functional testing.
I'd rather not use libproxy until we're certain we can tell it which JS
library to use. It needs to be one of ours, not webkit-gtk or mozjs.
-
On quinta-feira, 11 de outubro de 2012 21.09.24, Oswald Buddenhagen wrote:
> On Thu, Oct 11, 2012 at 11:54:28AM -0700, Thiago Macieira wrote:
> > I'd simply version the libraries.
>
> yes. me too. i wouldn't rename them, though. ;)
>
> > We already do that on Windows too, for example.
>
> only b
On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen wrote:
> On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote:
> > Considering all the changes I am proposing do NOT harm any of the
> > people that build from sources,
>
> they *do* harm. i positively do *not* want to
I just installed mingw-build 4.7.2 on Windows 7 64-bit. I then
configured Qt 5 this way:
configure -developer-build -opensource -confirm-license -nomake tests
-nomake examples -c++11
The built libraries are in 64-bit. How do I configure Qt 5 to build
32-bit libs?
Thanks.
On Thu, 11 Oct 2012 14:33:30 +, Verbruggen Erik wrote:
>> I have personally never seen an actual use case where a cosmetic pen
>> makes sense, but I assume there are reasons for having i so anyone
>> creating an explicit QPen(Qt::black, 0.0) should get a 1.0 pixel thick
>> line regardless of
Hi,
I have tryed last beta 2 snapshot for windows and there is always no debug
version of qml 2 import ... so It's impossible to debug an application that
use qml.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailma
On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote:
> Considering all the changes I am proposing do NOT harm any of the
> people that build from sources,
>
they *do* harm. i positively do *not* want to use qmake-qt5 just because
it's the least evil for linux package users.
> Other tha
On Thu, Oct 11, 2012 at 11:54:28AM -0700, Thiago Macieira wrote:
> I'd simply version the libraries.
>
yes. me too. i wouldn't rename them, though. ;)
> We already do that on Windows too, for example.
>
only because windows has no built-in support for versioning dlls.
and fwiw, what qmake does is
I filed a bug ~ 8 months ago for a reproducible problem's that's been
around since at least Qt v4.7.4, and continues in Qt v4.8.3.
In the OP, and recently, I've included procedure to reproduce &
screenshots.
Here's the bug:
15/Feb/12 6:35 PM
https://bugreports.qt-project.org/bro
On quinta-feira, 11 de outubro de 2012 12.00.41, Marcus D. Hanwell wrote:
> If there is a general agreement that this is needed then it would seem
> that doing this in the context of the Qt project is the ideal
> solution. This would also reduce the amount of work required as there
> is already an
On quinta-feira, 11 de outubro de 2012 17.46.11, Oswald Buddenhagen wrote:
> > The other thing is, we still need to rename the libraries. Otherwise, we
> > can't install both sets of *.so files to /usr/lib.
>
> that's simply not a relevant concern. production libraries can be
> co-installed just
On Thursday October 11 2012, Stephen Chu wrote:
> I am wondering if this is the result of switching qtbase to master
> instead of staying wiht qt5.
>
> When I call this on a Mac:
>
> QMessageBox::warning(NULL, "", "warning!");
>
> The dialog shows up but clicking at the OK button doesn't dism
I am wondering if this is the result of switching qtbase to master
instead of staying wiht qt5.
When I call this on a Mac:
QMessageBox::warning(NULL, "", "warning!");
The dialog shows up but clicking at the OK button doesn't dismiss it.
And QMessageBox code is taking 100% of a core spi
On Thu, Oct 11, 2012 at 11:46 AM, Oswald Buddenhagen
wrote:
> On Thu, Oct 11, 2012 at 02:59:03PM +0200, Simon Hausmann wrote:
>> On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote:
>> > not all people have agreed on it. the linux distro centric camp (which
>> > has a disproportiona
On Thu, Oct 11, 2012 at 02:59:03PM +0200, Simon Hausmann wrote:
> On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote:
> > not all people have agreed on it. the linux distro centric camp (which
> > has a disproportionate representation in this channel) has agreed on it.
> > which is
On Thu, Oct 11, 2012 at 11:48:26AM +, Sorvig Morten wrote:
> [...] In general, I think this is something we'll see again. Platforms
> change under our feet and we need to adapt. Apple and Microsoft do not
> put OS updates on hold because we are working on a major release. The
> fact that Qt oft
On Thu, 11 Oct 2012, Thomas McGuire wrote:
> Could we maybe simple get rid of object freezing, and not freeze the global
> object?
> What would the consequences of that be, anything bad? I am the opinion that if
> the user wants to override the "console" object, let him. Maybe there were
> other r
On quinta-feira, 11 de outubro de 2012 11.48.26, Sorvig Morten wrote:
> > The above is much more than adding a symbol as an artifact of a change.
> > It's whole new API and features. It should not go into 4.8.
>
> I think we need to take a second look at the 4.8 submit policy.
>
> I'd like to ma
On quinta-feira, 11 de outubro de 2012 12.01.51, Oswald Buddenhagen wrote:
> fwiw, the default mkspec links would need to go to lib, too, obviously.
True.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: T
On quinta-feira, 11 de outubro de 2012 11.45.27, Oswald Buddenhagen wrote:
> > Indeed. But their output affects a lot of people, including the majority
> > of future Qt contributors,
> >
> >
>
> that's not relevant, because if those 20 people do a good job, the
> millions using the packages will
> IMHO #4 gives the best out-of-the-box experience.
>
> Is there a way to do the blocking winapi call in a thread on app start-
> up maybe?
Doesn't help if the first thing an application wants to do is download
something from the network.
It would only help because of the workaround we already ha
On Oct 11, 2012, at 10:58, Bache-Wiig Jens wrote:
> This issue came up while preparing some code to be High-dpi aware but it is
> really a completely separate issue.
> While I previously supported the idea that cosmetic pens should be two pixels
> wide by default on HDPI screens, I think we sho
- Original Message -
> From: Sorvig Morten
> Subject: Re: [Development] Behavior change: A sane and consistent QPainter
> coordinate system in Qt 5
>
>
> On Oct 11, 2012, at 1:57 PM, Samuel Rødal
> wrote:
>>
>> It's unfortunate to potentially cause some extra trouble for a subset
>
IMHO #4 gives the best out-of-the-box experience.
Is there a way to do the blocking winapi call in a thread on app start-up maybe?
How do other apps (i.e. Chrome) handle this without blocking the user
experience?
Simon
--
Sendt fra min Nokia N911.10.12 15:12 skrev Peter Hartmann:
Hello,
I r
Hi,
the QML engine "freezes" the global JS object. This is apparently(?) to
prevent accidental writes to the global object. For those who don't know, the
global object in JS provides objects and properties available in global scope,
such as "console" (for console.log) or "qsTr".
Now, it turned
> -Original Message-
> From: development-bounces+shane.kearns=accenture@qt-project.org
> [mailto:development-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of Peter Hartmann
> Sent: 11 October 2012 14:12
> To: development@qt-project.org
> Subject: [Development] QtNetwork
Hello,
I remember this has been discussed before, but yet again: How about
using the system proxy by default, at least on some platforms or by
configure switch? Right now every app developer has to call
QNetworkProxyFactory::setUseSystemConfiguration(true) in his code to use
the system proxies
On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote:
[...]
> > > nope, sorry, the version-based namespacing simply does not belong into
> > > upstream. it's a problem specific to FHS, and should be addressed by
> > > those concerned with it.
> >
> > It belongs in Qt and people have
On Oct 11, 2012, at 10:58 AM, Bache-Wiig Jens wrote:
>
> I have personally never seen an actual use case where a cosmetic pen makes
> sense, but I assume there are reasons for having i so anyone creating an
> explicit QPen(Qt::black, 0.0) should get a 1.0 pixel thick line regardless of
> sca
On Oct 11, 2012, at 1:57 PM, Samuel Rødal
wrote:
>
> It's unfortunate to potentially cause some extra trouble for a subset of
> existing applications that wish to port to Qt 5, but weighed against the
> utter embarrassment of the current fill rules I think we need this change.
+1 from me fo
While we're on the topic of pixels,
in Qt 4 we in effect have two coordinate systems. The antialiased
coordinate system where (0, 0) corresponds to the top left corner of the
top left pixel, and the aliased coordinate system where (0, 0)
corresponds to the center of the top left pixel. That mea
On Oct 10, 2012, at 7:46 PM, Thiago Macieira wrote:
>> nterpreted as good reasons to have a 4.9 release
>
> Exceptions given on a case-by-case basis.
>
> The above is much more than adding a symbol as an artifact of a change. It's
> whole new API and features. It should not go into 4.8.
I thi
On Wed, Oct 10, 2012 at 10:39:35AM -0700, Thiago Macieira wrote:
> 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
> > > technicall
On Wed, Oct 10, 2012 at 10:44:30AM -0700, Thiago Macieira wrote:
> On quarta-feira, 10 de outubro de 2012 18.03.31, Oswald Buddenhagen wrote:
> > which translates to some 20 people in the world who even
> > need to think about properly solving it.
>
> Indeed. But their output affects a lot of peop
This issue came up while preparing some code to be High-dpi aware but it is
really a completely separate issue.
While I previously supported the idea that cosmetic pens should be two pixels
wide by default on HDPI screens, I think we should take it one step further as
the real issue is caused by
On 10/11/2012 10:16 AM, Sorvig Morten wrote:
>
> On Oct 11, 2012, at 9:36 AM, Samuel Rødal
> wrote:
>
>> On 10/11/2012 08:23 AM, Ziller Eike wrote:
>>>
>>> On 10.10.2012, at 16:56, Olivier Goffart wrote:
>>>
>>> If you'd now be able to change the unit in Qt to "pixel metrics" for
>>> certain wid
On Oct 11, 2012, at 9:36 AM, Samuel Rødal
wrote:
> On 10/11/2012 08:23 AM, Ziller Eike wrote:
>>
>> On 10.10.2012, at 16:56, Olivier Goffart wrote:
>>
>> If you'd now be able to change the unit in Qt to "pixel metrics" for
>> certain widgets (and optionally sub widgets) where you really want
>
> The only thing is about QPen. should we draw lines twice as large? that is
> bascically what QPen::isCosmetic is for
Absolutely. The problem is that for some reason we have cosmetic as the default.
In practice people hardly use cosmetic pens for what it was designed for, it is
imply treate
On 10/11/2012 08:23 AM, Ziller Eike wrote:
>
> On 10.10.2012, at 16:56, Olivier Goffart wrote:
>
> If you'd now be able to change the unit in Qt to "pixel metrics" for
> certain widgets (and optionally sub widgets) where you really want to
> take advantage of each and every pixel in e.g. painting c
46 matches
Mail list logo
