Op 19-4-2012 8:18, Robin Burchell schreef:
> On Thu, Apr 19, 2012 at 8:11 AM, Girish Ramakrishnan
> wrote:
>> As for a blog, why is there no qt-project blog? It would be great to
>> have people blogging about Qt development related stuff.
> presumably because it's a bit hard to define who gets ac
On Thu, Apr 19, 2012 at 8:11 AM, Girish Ramakrishnan
wrote:
> As for a blog, why is there no qt-project blog? It would be great to
> have people blogging about Qt development related stuff.
presumably because it's a bit hard to define who gets access to that, etc.
there is planetqt, which is als
Hi,
On Wed, Apr 18, 2012 at 10:56 PM, Girish Ramakrishnan
wrote:
> Hi Alan,
>
> On Mon, Apr 16, 2012 at 7:09 PM, Alan Alpert wrote:
>> Hi,
>>
>> I'm a little worried that the position of QML in Qt5 is not entirely clear.
>> It's a great new technology, but that "new" part means that realisticall
Hi Alan,
On Mon, Apr 16, 2012 at 7:09 PM, Alan Alpert wrote:
> Hi,
>
> I'm a little worried that the position of QML in Qt5 is not entirely clear.
> It's a great new technology, but that "new" part means that realistically it
> will not take over everything, everywhere, immediately upon the relea
Hi,
About qtpim issues, I can reproduce the issue and I confirm that the
qorganizer tests are quite flacky :-/
I am explicitly now looping in a few organizer folks who might help
understanding what's going on in there.
I am also planning to give a look as well during today...so let's stay in
touch
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
qtsensors and qtlocation merged (thanks Friedemann).
qtsystems needs a fix in qtbase
(https://codereview.qt-project.org/#change,23709) before we can try to restage
https://codereview.qt-project.org/#change,21847 and friends.
qtpim is failing several tests because of assumptions on QHash element
> From: Pekka Vuorela
> To: BogDan
> Cc: Samuel Rødal ; "development@qt-project.org"
>
> Sent: Tuesday, April 17, 2012 5:12 PM
> Subject: Re: [Development] QPlatformInputContext needs more informations
>
> On Mon, 2012-04-16 at 09:23 -0700, ext BogDan wrote:
>> > From: Pekka Vuorela
>> > T
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
Hi Shane,
On Tue, Apr 17, 2012 at 5:10 AM, wrote:
> Simple question, do we want the qt/ namespace to be for essentials only, or
> also for addons.
> e.g. should the path to an addon be:
> ssh://codereview.qt-project.org:29418/qt/qtftp
> or
> ssh://codereview.qt-project.org:29418/qtaddon/qtftp
>
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
qtdeclarative/api_changes got merged, and now several others after that.
qtpim, qtsensors and qtsystems still remaining (merge attempts are all
in progress).
Best regards,
Kent
Den 18. april 2012 00:29, skrev ext Donald Carr:
> yetch, and again, sorry Kent
>
> Were I but a beautiful woman, I
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 Apr 17, 2012, at 1:28 PM, ext Alberto Mardegan wrote:
> On 04/17/2012 01:36 PM, morten.sor...@nokia.com wrote:
>> Desktop Compoents are not going to be a part of the Qt 5.0 release, but we'd
>> still like to get it up to speed and open up for contributions through
>> gerrit.
>>
>> Task: htt
18 matches
Mail list logo
