It has always supported it. It's just not used that much.
--
Sent from my Nokia N9
On 5/11/12 3:50 ext Girish Ramakrishnan wrote:
AFAIK, Installing with INSTALL_ROOT is known not to work with Qt5's
"modular" projects.
BTW, does windows even support make install? Has it started supported
it these
AFAIK, Installing with INSTALL_ROOT is known not to work with Qt5's
"modular" projects.
BTW, does windows even support make install? Has it started supported
it these days?
Girish
On Thu, May 10, 2012 at 5:02 PM, Loaden wrote:
> Not work for "nmake install INSTALL_ROOT=...", missed 'qba' header
Not work for "nmake install INSTALL_ROOT=...", missed 'qba' headers in
QtGui.
> progressmanager_win.cpp
> Header is deprecated. Please include
> instead.
> ..\..\..\..\Qt5\qtbase\include\QtGui\QPlatformNativeInterface(8) : fatal
> error C1083: Cannot open include file: 'qpa/qplatformnativeinterf
On Tue, May 8, 2012 at 5:31 PM, Girish Ramakrishnan
wrote:
> On Tuesday, May 8, 2012, Girish Ramakrishnan wrote:
>> Hi,
>>
>> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
>> wrote:
>>> The change landed. For some reason, the ci is failing compile in all
>>> other modules. Works locally wi
On Tue, May 8, 2012 at 4:22 PM, Rohan McGovern wrote:
> Girish Ramakrishnan said:
>> Hi,
>>
>> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
>> wrote:
>> > The change landed. For some reason, the ci is failing compile in all
>> > other modules. Works locally with shadow builds but not on CI
On Tuesday, May 8, 2012, Girish Ramakrishnan
forwardbias.in > wrote:
> Hi,
>
> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
> forwardbias.in >
wrote:
>> The change landed. For some reason, the ci is failing compile in all
>> other modules. Works locally with shadow builds but not on CI. I a
Girish Ramakrishnan said:
> Hi,
>
> On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
> wrote:
> > The change landed. For some reason, the ci is failing compile in all
> > other modules. Works locally with shadow builds but not on CI. I am on
> > it.
> >
>
> Fix is integrating: https://coderev
Hi,
On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan
wrote:
> The change landed. For some reason, the ci is failing compile in all
> other modules. Works locally with shadow builds but not on CI. I am on
> it.
>
Fix is integrating: https://codereview.qt-project.org/#change,25570.
Sorry for bl
On Fri, May 4, 2012 at 8:20 AM, Girish Ramakrishnan
wrote:
> On Fri, Apr 20, 2012 at 7:16 AM, Girish Ramakrishnan
> wrote:
>> 2012/4/20 Stephen Kelly :
>>> On Friday, April 20, 2012 07:35:39 lars.kn...@nokia.com wrote:
>>>
Proposal sounds ok to me as well. If someone still has concerns, plea
On Fri, Apr 20, 2012 at 7:16 AM, Girish Ramakrishnan
wrote:
> 2012/4/20 Stephen Kelly :
>> On Friday, April 20, 2012 07:35:39 lars.kn...@nokia.com wrote:
>>
>>> Proposal sounds ok to me as well. If someone still has concerns, please
>>
>>> speak up.
>>
>>
>> I lost track of what the proposal curre
2012/4/20 Stephen Kelly :
> On Friday, April 20, 2012 07:35:39 lars.kn...@nokia.com wrote:
>
>> Proposal sounds ok to me as well. If someone still has concerns, please
>
>> speak up.
>
>
> I lost track of what the proposal currently is. Could it be restated?
1. We drop _qpa completely. So, it woul
On Friday, April 20, 2012 07:35:39 lars.kn...@nokia.com wrote:
> Proposal sounds ok to me as well. If someone still has concerns, please
> speak up.
>
I lost track of what the proposal currently is. Could it be restated?
--
Stephen Kelly | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a K
Proposal sounds ok to me as well. If someone still has concerns, please
speak up.
Cheers,
Lars
On 4/20/12 9:02 AM, "ext Samuel Rødal" wrote:
>On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote:
>> Hi,
>>
>> On Wed, Apr 18, 2012 at 3:28 AM, wrote:
>>> Still the QPA headers are sort of a di
On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote:
> Hi,
>
> On Wed, Apr 18, 2012 at 3:28 AM, wrote:
>> Still the QPA headers are sort of a different beast from private headers.
>> While I don't want to promise anything on them yet (I think we might want
>> to keep SC and BC for them in patc
On Thursday 19 April 2012 14:45:29 ext Girish Ramakrishnan wrote:
> Paul did say on irc this proposal sounds 'better', but I am not sure
> that means I have his +2. Is this any better? (read: compromise)
At least it means that I am withdrawing my -1 :)
- Paul
_
On quinta-feira, 19 de abril de 2012 05.45.29, Girish Ramakrishnan wrote:
> Hi Guys,
>
> On Wed, Apr 18, 2012 at 7:03 AM, Girish Ramakrishnan
>
> wrote:
> > Since there's been no proposal, here's an alternate proposal:
> > 1. We drop _qpa completely. So, it would become qplatformbackingstore.h
> >
Hi Guys,
On Wed, Apr 18, 2012 at 7:03 AM, Girish Ramakrishnan
wrote:
>
> Since there's been no proposal, here's an alternate proposal:
> 1. We drop _qpa completely. So, it would become qplatformbackingstore.h
> 2. We teach syncqt that qplatform* is special and we move them all to
> a special qpa/
the current _qpa situation is legacy and makes working with the code
more painful. It will never be less painful to address than right now
and I am really glad you have undertaken this Kamikaze initiative on
our behalf.
I am also glad you are going through the code busy cleaning up these
internal
On Wed, Apr 18, 2012 at 12:36 PM, Richard Moore wrote:
> On 18 April 2012 15:18, wrote:
>> Just for my mental state of mind: will these classes then be documented as
>> normal classes, or \internal, or do we need something special for them
>> still?
>
> I'd say we still want something special fo
On 18 April 2012 15:18, wrote:
> Just for my mental state of mind: will these classes then be documented as
> normal classes, or \internal, or do we need something special for them
> still?
I'd say we still want something special for them. We want these
classes to be documented somewhere (even i
On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote:
> Hi,
>
...
> What follows is an OT/rant and not relevant to the discussion as such:
> 'plugin' usually refers to things add capabilities to an existing
> thing. qpa plugins are not really plugins, they are the thing itself.
> Without qpa plugi
On Wednesday 18 April 2012 16:18:09 ext casper.vandonde...@nokia.com wrote:
> Just for my mental state of mind: will these classes then be documented as
> normal classes, or \internal, or do we need something special for them
> still?
They should not be documented as normal classes. \internal is f
Hi,
On 4/18/12 4:03 PM, "ext Girish Ramakrishnan"
wrote:
>Since there's been no proposal, here's an alternate proposal:
>1. We drop _qpa completely. So, it would become qplatformbackingstore.h
>2. We teach syncqt that qplatform* is special and we move them all to
>a special qpa/ directory. So, i
Hi,
On Wed, Apr 18, 2012 at 3:28 AM, wrote:
> Still the QPA headers are sort of a different beast from private headers.
> While I don't want to promise anything on them yet (I think we might want
> to keep SC and BC for them in patch level releases), they are supposed to
> be used by third parti
On 4/17/12 9:58 PM, "ext Thiago Macieira"
wrote:
>On terça-feira, 17 de abril de 2012 15.37.35,
>marius.storm-ol...@nokia.com
>wrote:
>> Yes, it does.
>> And for the case of QPA, we have said that we don't want to promise BC,
>>but
>> we haven't said that we will go around breaking SC for every p
On terça-feira, 17 de abril de 2012 15.37.35, marius.storm-ol...@nokia.com
wrote:
> Yes, it does.
> And for the case of QPA, we have said that we don't want to promise BC, but
> we haven't said that we will go around breaking SC for every patch release.
> (And we shouldn't, since SC breakage uses q
ius.storm-olsen=nokia@qt-project.org] On
Behalf Of ext Stephen Kelly
Sent: Tuesday, April 17, 2012 10:27 AM
To: development@qt-project.org
Subject: Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tuesday, April 17, 2012 15:05:49
marius.storm-ol...@nokia.com<mailto:marius.sto
On Tuesday, April 17, 2012 15:05:49 marius.storm-ol...@nokia.com wrote:
> Well, that breaks SC for existing projects, which have been ok with the
> missing BC. So you want to improve by promising BC by breaking SC?
_p also means SC is not maintained.
Thanks,
--
Stephen Kelly | Software Enginee
> -Original Message-
> From: ext Girish Ramakrishnan [mailto:gir...@forwardbias.in]
> On Tue, Apr 17, 2012 at 4:03 AM, wrote:
> > On 17/04/2012 03:34, ext Paul Olav Tvete wrote:
> >> On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote:
> >>> As per the previous discuss, I rena
Hi Marius,
On Tue, Apr 17, 2012 at 4:03 AM, wrote:
> On 17/04/2012 03:34, ext Paul Olav Tvete wrote:
>> On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote:
>>> As per the previous discuss, I renamed all the _qpa.h to _p.h with
>>> a couple of helper scripts
>>
>> I just added the fo
Hi Paul,
On Tue, Apr 17, 2012 at 1:34 AM, Paul Olav Tvete wrote:
> On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote:
>> As per the previous discuss, I renamed all the _qpa.h to _p.h with a
>> couple of helper scripts
>
> I just added the following "-1" comment on gerrit:
>
> I do n
On terça-feira, 17 de abril de 2012 10.34.33, Paul Olav Tvete wrote:
> I do not agree with this change. We have made a difference between public
> API and plugin API, and this is different from private implementation
> detail.
And during the previous discussion, I questioned that difference. No o
On terça-feira, 17 de abril de 2012 07.41.26, jason.mcdon...@nokia.com wrote:
> > On Tue, Apr 17, 2012 at 4:12 AM, Girish Ramakrishnan
wrote:
> > > 1. qtestlib ends up exposing qpa api and thus testcases might end up
> > > being binary incompatible - This should be fixed in
> >
> > AFAIK qtestlib
On 17/04/2012 03:34, ext Paul Olav Tvete wrote:
> On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote:
>> As per the previous discuss, I renamed all the _qpa.h to _p.h with
>> a couple of helper scripts
>
> I just added the following "-1" comment on gerrit:
>
> I do not agree with this
On Apr 17, 2012, at 10:34 AM, ext Paul Olav Tvete wrote:
> On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote:
>> As per the previous discuss, I renamed all the _qpa.h to _p.h with a
>> couple of helper scripts
>
> I just added the following "-1" comment on gerrit:
>
> I do not a
On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote:
> As per the previous discuss, I renamed all the _qpa.h to _p.h with a
> couple of helper scripts
I just added the following "-1" comment on gerrit:
I do not agree with this change. We have made a difference between public API
an
> On Tue, Apr 17, 2012 at 4:12 AM, Girish Ramakrishnan
> wrote:
> > 1. qtestlib ends up exposing qpa api and thus testcases might end up
> > being binary incompatible - This should be fixed in
>
> AFAIK qtestlib doesn't promise binary compatibility (see e.g.
> http://qt.gitorious.org/qt/qtqa/comm
Hi Robin,
On Mon, Apr 16, 2012 at 11:12 PM, Robin Burchell wrote:
> On Tue, Apr 17, 2012 at 4:12 AM, Girish Ramakrishnan
> wrote:
>> 1. qtestlib ends up exposing qpa api and thus testcases might end up
>> being binary incompatible - This should be fixed in
>
> AFAIK qtestlib doesn't promise bina
On Tue, Apr 17, 2012 at 4:12 AM, Girish Ramakrishnan
wrote:
> 1. qtestlib ends up exposing qpa api and thus testcases might end up
> being binary incompatible - This should be fixed in
AFAIK qtestlib doesn't promise binary compatibility (see e.g.
http://qt.gitorious.org/qt/qtqa/commit/0a67286dcc3
On Mon, Apr 16, 2012 at 6:57 PM, Girish Ramakrishnan
wrote:
> Hi,
> If you are a module maintainer, please check the patches below and
> provide comments.
>
> As per the previous discuss, I renamed all the _qpa.h to _p.h with a
> couple of helper scripts - one script renamed the files and another
Hi,
If you are a module maintainer, please check the patches below and
provide comments.
As per the previous discuss, I renamed all the _qpa.h to _p.h with a
couple of helper scripts - one script renamed the files and another
fixed the includes. Practically all the hardwork was done by my trusty
41 matches
Mail list logo
