Re: [Development] [API Change] New authentication method in QNetworkAccessManager

[Giuseppe D'Angelo]

On 10 March 2014 07:43, Kurt Pattyn  wrote:
> Is the documentation on the signal sslErrors() still correct then: "Note:
> You cannot use Qt::QueuedConnection when connecting to this signal, or
> calling QSslSocket::ignoreSslErrors() will have no effect." ?

I presume it's still correct in order to retain compatibility with Qt
4. The new pausing mechanism is opt-in: you need to call
setPauseMode(QAbstractSocket::PauseOnSslErrors) in order to make the
socket pause when emitting sslErrors(). Once that signal gets emitted,
the socket pauses and will not proceed further unless the user then
calls ignoreSslErrors() + resume() or so.

To me this mechanism seems flexible enough to be coupled with anything...

-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branches and time based releases

[Frederik Gladhorn]

Fredag 7. mars 2014 17.18.58 skrev Jan Kundrát:
> On Tuesday, 25 February 2014 20:12:57 CEST, Thiago Macieira wrote:
> > Also, I don't know of any project that has a CI-controlled integration.
> 
> OpenStack. Full documentation on their setup (which, btw, tests each and
> every commit separately) is available at http://ci.openstack.org/ .

Thanks for the pointer, quite interesting read indeed.
 
> With kind regards,
> Jan

-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [API Change] New authentication method in QNetworkAccessManager

[Kurt Pattyn]

> On 10 Mar 2014, at 08:37, "Giuseppe D'Angelo"  wrote:
> 
>> On 10 March 2014 07:43, Kurt Pattyn  wrote:
>> Is the documentation on the signal sslErrors() still correct then: "Note:
>> You cannot use Qt::QueuedConnection when connecting to this signal, or
>> calling QSslSocket::ignoreSslErrors() will have no effect." ?
> 
> I presume it's still correct in order to retain compatibility with Qt
> 4. The new pausing mechanism is opt-in: you need to call
> setPauseMode(QAbstractSocket::PauseOnSslErrors) in order to make the
> socket pause when emitting sslErrors(). Once that signal gets emitted,
> the socket pauses and will not proceed further unless the user then
> calls ignoreSslErrors() + resume() or so.

But we can use a QueuedConnection if the PauseMode is set to PauseOnSslErrors, 
or can't we?
> 
> To me this mechanism seems flexible enough to be coupled with anything...
> 
> -- 
> Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Bluetooth iOS

[Blasche Alexander]

Hi,

Sorry to disappoint, but to the best of my knowledge there is no ongoing port 
for iOS at this point in time.


--

Alex


From: development-bounces+alexander.blasche=digia@qt-project.org 
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
Pau Garcia i Quiles [pgqui...@elpauer.org]
Sent: Sunday, March 09, 2014 01:10
To: development@qt-project.org
Subject: [Development] Qt Bluetooth iOS

Hello,

Is anyone working on an iOS backend of Qt Bluetooth? I could use it but I 
cannot find any information at all.

--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QPA / QWindow / QPainter

[Agocs Laszlo]

> > I'm implementing a QPA plugin (now with 5.3 snapshot) and there's something
> > I do not understand: When I use native widgets, every widget creates a
> > QPlatformWindow, but only a toplevel window creates a
> > QPlatformBackingStore, which is the class which delivers the paintDevice
> > implementation.
> > 
> > Question: when a QWidget now creates a QPainter on it, how does my QPA
> > plugin know onto which QWindow it is currently acting, when there's only
> > one paintDevice/one backing store ?

Native child windows will work, yes. There is no difference from the 
backingstore's point of view. There is one backingstore (and so one instance of 
your QPlatformBackingStore implementation) per top-level and for each child 
window, native or non-native, painting happens in the same manner.

As for the painting step, QPA has almost nothing to do with it: you merely 
provide a QPaintDevice, the rest is up to the widgets. The QPA plugin has no 
knowledge or interest in what's happening in there. The interesting part is the 
flush that happens afterwards, and in flush() you will of course know which 
QWindow is being flushed.

Cheers,
Laszlo

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QPA / QWindow / QPainter

[Paul Olav Tvete]

On Monday 10 March 2014 09:20:14 Agocs Laszlo wrote:
> > > Question: when a QWidget now creates a QPainter on it, how does my QPA
> > > plugin know onto which QWindow it is currently acting, when there's only
> > > one paintDevice/one backing store ?

> As for the painting step, QPA has almost nothing to do with it: you merely
> provide a QPaintDevice, the rest is up to the widgets. The QPA plugin has
> no knowledge or interest in what's happening in there. The interesting part
> is the flush that happens afterwards, and in flush() you will of course
> know which QWindow is being flushed.

This functionality comes from early Qt 4 days, before non-native widgets were 
implemented. All widgets paint to the same backingstore, and then each widget 
gets its content from the part of the backingstore it covers.

This way we got the illusion of partially transparent widgets even if the 
underlying windowsystem did not support it. After non-native widgets (AKA 
"alien") were implemented, this feature is much less important, and we would 
probably not implement it like that today.

- Paul
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [API Change] New authentication method in QNetworkAccessManager

[Giuseppe D'Angelo]

On 10 March 2014 09:27, Kurt Pattyn  wrote:
> But we can use a QueuedConnection if the PauseMode is set to 
> PauseOnSslErrors, or can't we?

The idea is that you can. The socket will be paused and won't proceed
until a call to resume.

If the QueuedConnection usage comes from the idea of using multiple
threads, note that you still must call ignoreSslErrors / resume from
the QSslSocket thread.

-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FTP in Qt5

[Peter Hartmann]

On 03/08/2014 09:36 PM, Thiago Macieira wrote:
>> If someone, including the requesting party themselves, does such work, I’m
>> >sure there are reviewers / approvers ready to do the reviewing.
> Oh, sure. If someone supplied the rewrite, I'm sure we'd be happy to take it
> in. We might even help out a little.

I am not planning to do any work on FTP either as of now, but if 
somebody wants to implement something there, feel free to add me as a 
reviewer...

Peter

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] About having a cdash dashboard for Qt

[Sarajärvi Tony]

Hi

While in Berlin, I was asked if Qt couldn't have a dashboard to which anyone 
could append build and test results of Qt in different platform and compilers. 
Just like this one for CMake: http://open.cdash.org/index.php?project=CMake

Does anyone have any experience setting up a page like that?

And, before I can even start asking questions, I would like to hear your ideas 
around this subject. What are the things we should publish, take into account 
and all that. Or, do we even see this as something useful after all.

Regards,
-Tony

Tony Sarajärvi
CI Tech Lead
Digia, Qt

Digia Plc
Elektroniikkatie 10
FI-90590 Oulu

Email: tony.saraja...@digia.com
http://qt.digia.com
Qt Blog: http://blog.qt.digia.com/
Qt Facebook: www.facebook.com/qtcommercial
Qt Twitter: www.twitter.com/qtcommercial

--
PRIVACY AND CONFIDENTIALITY NOTICE
This message and any attachments are intended only for use by the named 
addressee and may contain privileged and/or confidential information. If you 
are not the named addressee you should not disseminate, copy or take any action 
in reliance on it. If you have received this message in error, please contact 
the sender immediately and delete the message and any attachments accompanying 
it. Digia Plc does not accept liability for any corruption, interception, 
amendment, tampering or viruses occurring to this message.
--

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QPA / QWindow / QPainter

[Martin Koller]

On Monday 10 March 2014 09:20:14 Agocs Laszlo wrote:
> > > I'm implementing a QPA plugin (now with 5.3 snapshot) and there's 
> > > something
> > > I do not understand: When I use native widgets, every widget creates a
> > > QPlatformWindow, but only a toplevel window creates a
> > > QPlatformBackingStore, which is the class which delivers the paintDevice
> > > implementation.
> > > 
> > > Question: when a QWidget now creates a QPainter on it, how does my QPA
> > > plugin know onto which QWindow it is currently acting, when there's only
> > > one paintDevice/one backing store ?
> 
> Native child windows will work, yes. There is no difference from the 
> backingstore's point of view. There is one backingstore (and so one instance 
> of your QPlatformBackingStore implementation) per top-level and for each 
> child window, native or non-native, painting happens in the same manner.

This is not clear. AFAIK there is only ONE QPlatformBackingStore per top level 
window but there is none for every native child widget - although Qt calls 
QPlatformIntegration::createPlatformWindow() for each native widget!
So I end up with the possibility to have one QPlatformWindow per widget but 
without a separate QPlatformBackingStore
(which I understand when you want to "blend" the alpha channels of widgets 
above each other)
but I still do have the problem that my QPaintEngine is called from different 
widgets but I can not differentiate them.

What I implement is kind of what was originally done on X11 - having ONLY the 
native widgets.
Something what Qt4 could do with -graphicssystem native (sending the separate 
paint operations over the network).
Is this simply no longer possible or what am I missing ?

> As for the painting step, QPA has almost nothing to do with it: you merely 
> provide a QPaintDevice, the rest is up to the widgets.

I provide the paint engine, so my QPA HAS something to do with the painting. 
What do I misunderstand here ?

> The QPA plugin has no knowledge or interest in what's happening in there. The 
> interesting part is the flush that happens afterwards, and in flush() you 
> will of course know which QWindow is being flushed.

I assume this only works when I want to transport pixmaps (already composed 
pixel areas), but what I want
to achieve is to send the single painting commands for the different widgets 
over the network which have
an equivalent on the client receiving the commands.
So in fact I do not need a backing store.
Is that still possible somehow ?

-- 
Best regards/Schöne Grüße

Martin

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QPA / QWindow / QPainter

[Agocs Laszlo]

Yes, one platform window for each native widget and one backingstore per top 
level window. (where the toplevel's backingstore is the common backingstore for 
all of its child widgets)

QPA (QPlatformBackingStore) does not know anything about paint devices, paint 
engines and such. It allows you to provide a paint device to the widget stack 
or whoever performs the painting, that's all. The returned paint device could 
be a QImage, an OpenGL framebuffer object, a custom device with a custom paint 
engine doing stuff that has nothing to do with painting, etc. It does not have 
to be something that holds the actual pixels. The platform plugin must provide 
a backing store implementation however. (unless it does not care about widgets)

To implement your remoting use case, there is most likely no need to complicate 
things with native widgets. It is exactly the same concept as generating HTML5 
canvas code or PDFs or anything else:

- Have a custom paint device that provides a custom paint engine which buffers 
the painting commands. Such a buffer will contain the drawing commands for all 
the children of a given toplevel.

- In the platform backingstore's flush send the commands over the network

Or is something, that would mandate the usage of native child widgets, missing 
from the picture here?

Best regards,
Laszlo


From: Martin Koller [kol...@aon.at]
Sent: Monday, March 10, 2014 1:14 PM
To: development@qt-project.org
Cc: Agocs Laszlo
Subject: Re: [Development] QPA / QWindow / QPainter

On Monday 10 March 2014 09:20:14 Agocs Laszlo wrote:
> > > I'm implementing a QPA plugin (now with 5.3 snapshot) and there's 
> > > something
> > > I do not understand: When I use native widgets, every widget creates a
> > > QPlatformWindow, but only a toplevel window creates a
> > > QPlatformBackingStore, which is the class which delivers the paintDevice
> > > implementation.
> > >
> > > Question: when a QWidget now creates a QPainter on it, how does my QPA
> > > plugin know onto which QWindow it is currently acting, when there's only
> > > one paintDevice/one backing store ?
>
> Native child windows will work, yes. There is no difference from the 
> backingstore's point of view. There is one backingstore (and so one instance 
> of your QPlatformBackingStore implementation) per top-level and for each 
> child window, native or non-native, painting happens in the same manner.

This is not clear. AFAIK there is only ONE QPlatformBackingStore per top level 
window but there is none for every native child widget - although Qt calls 
QPlatformIntegration::createPlatformWindow() for each native widget!
So I end up with the possibility to have one QPlatformWindow per widget but 
without a separate QPlatformBackingStore
(which I understand when you want to "blend" the alpha channels of widgets 
above each other)
but I still do have the problem that my QPaintEngine is called from different 
widgets but I can not differentiate them.

What I implement is kind of what was originally done on X11 - having ONLY the 
native widgets.
Something what Qt4 could do with -graphicssystem native (sending the separate 
paint operations over the network).
Is this simply no longer possible or what am I missing ?

> As for the painting step, QPA has almost nothing to do with it: you merely 
> provide a QPaintDevice, the rest is up to the widgets.

I provide the paint engine, so my QPA HAS something to do with the painting. 
What do I misunderstand here ?

> The QPA plugin has no knowledge or interest in what's happening in there. The 
> interesting part is the flush that happens afterwards, and in flush() you 
> will of course know which QWindow is being flushed.

I assume this only works when I want to transport pixmaps (already composed 
pixel areas), but what I want
to achieve is to send the single painting commands for the different widgets 
over the network which have
an equivalent on the client receiving the commands.
So in fact I do not need a backing store.
Is that still possible somehow ?

--
Best regards/Schöne Grüße

Martin

()  ascii ribbon campaign - against html e-mail
/\- against proprietary attachments


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] New snapshot build from Qt 4.8.6 available

[Salovaara Akseli]

Hi all,

New snapshot build from Qt 4.8.6 available: 
http://download.qt-project.org/snapshots/qt/4.8/2014-03-10_510/ 
Packages are built against sha1 0315971ee951e9abe7f288564ddf2e81aeed1fd8 "Qt 3 
Support: Prevent double deletion of QObjectPrivate::threadData in QSettings" 
(HEAD) and this build should also address MinGW4.8.2 installer related known 
issues from previous snapshot.

At least few additional commits are still needed before Qt 4.8.6 Release 
Candidate can be issued. Unfortunately CI 4.8 Mac OS X 10.6 configuration is 
currently broken (investigation ongoing) causing delay for the release process. 
Before CI 4.8 problems are solved please take this as possibility to thoroughly 
test currently available build in order to find possible regression & blocker 
issues for Qt 4.8.6 release. If such issues are found please report those to 
bugreports.qt-project.org and raise issue also on releas...@qt-project.org.

Br,
Akseli
--
Akseli Salovaara
Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] About having a cdash dashboard for Qt

[Stephen Kelly]

On Monday, March 10, 2014 10:24:08 Sarajärvi Tony wrote:

> Does anyone have any experience setting up a page like that?

You could ask Kitware about setting up a project on http://my.cdash.org/ . 
Several KDE project builds are submitted there already.

I'm intending to get something like that working for the cmake tests in 
isolation (not testing or reporting on the build of Qt itself).

 https://codereview.qt-project.org/#change,79527

As far as I know, communication with cdash is done with xml files. Such xml 
files are generated by ctest, which pulls, invokes cmake to build, uses 
information in the cmake files regarding tests and invokes the tests.

As ctest wouldn't be used with the Qt build/test, you'd have to add something 
to qmake/qbs to create suitable xml files and submit them to the dashboard. 
It's possible that ctest itself could be used for some stuff, like 
transmitting the xml files and using a CTestConfig.cmake file.

> And, before I can even start asking questions, I would like to hear your
> ideas around this subject.

I like the idea of a dashboard which can be submitted to from outside the CI 
system. Using cdash for that is probably possible, but you might want to 
investigate other options or jenkins plugins or something.

> What are the things we should publish, take into account and all that. 

OS, compiler versions, compile/link lines, test invocation commands return 
codes and outputs etc.

Thanks,

-- 
Join us at Qt Developer Days 2014 in Berlin! - https://devdays.kdab.com

Stephen Kelly  | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] About ALIAS in Q_PROPERTY

[mikhail.svet...@gmail.com]

Hello, I would like to clarify wherein the complexity 
(https://codereview.qt-project.org/#change,80412)?
Ready to listen to any suggestions and implement them.

-- 
Mikhail Svetkin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] About ALIAS in Q_PROPERTY

[Giuseppe D'Angelo]

Can you please explain what this feature is about, why do you think
it's useful, how it's supposed to be used, etc.?

On 10 March 2014 17:30, mikhail.svet...@gmail.com
 wrote:
> Hello, I would like to clarify wherein the complexity
> (https://codereview.qt-project.org/#change,80412)?
> Ready to listen to any suggestions and implement them.
>
> --
> Mikhail Svetkin
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QPA / QWindow / QPainter

[Martin Koller]

On Monday 10 March 2014 14:43:42 Agocs Laszlo wrote:
> Yes, one platform window for each native widget and one backingstore per top 
> level window. (where the toplevel's backingstore is the common backingstore 
> for all of its child widgets)
> 
> QPA (QPlatformBackingStore) does not know anything about paint devices, paint 
> engines and such. It allows you to provide a paint device to the widget stack 
> or whoever performs the painting, that's all. The returned paint device could 
> be a QImage, an OpenGL framebuffer object, a custom device with a custom 
> paint engine doing stuff that has nothing to do with painting, etc. It does 
> not have to be something that holds the actual pixels. The platform plugin 
> must provide a backing store implementation however. (unless it does not care 
> about widgets)
> 
> To implement your remoting use case, there is most likely no need to 
> complicate things with native widgets. It is exactly the same concept as 
> generating HTML5 canvas code or PDFs or anything else:
> 
> - Have a custom paint device that provides a custom paint engine which 
> buffers the painting commands. Such a buffer will contain the drawing 
> commands for all the children of a given toplevel.
> 
> - In the platform backingstore's flush send the commands over the network
> 
> Or is something, that would mandate the usage of native child widgets, 
> missing from the picture here?

yes, I was trying to keep the explanation simple.
In fact what I do is to remote the painting commands to a HTML5 canvas, but as 
some objects shall do blinking,
which I do not want to be done via a lot of redraws, I instead create SVG 
objects which shall be intermixed displayed
with what the canvas shows (that is: primitve objects like lines, circles are 
SVG, widgets are drawn
as usual). But to have a chance that the stacking order of the SVG objects and 
the widgets is still
correct, I wanted to create the native widgets as separate canvas objects so 
that they do stack with the SVG objects.

What I think I can do to solve it is to use a global event filter, catch the 
paint events of the widgets I want to
stack correctly and redirect QWidget::render() to a paint device which knows 
the window id ... or something like that.

-- 
Best regards/Schöne Grüße

Martin
A: Because it breaks the logical sequence of discussion
Q: Why is top posting bad?

()  ascii ribbon campaign - against html e-mail 
/\- against proprietary attachments

Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New snapshot build from Qt 4.8.6 available

[Jake Petroules]

Please ensure https://codereview.qt-project.org/#change,80277 makes it into
4.8.6; this fixes a very serious issue with QProcess on OS X 10.9.


On Mon, Mar 10, 2014 at 10:55 AM, Salovaara Akseli <
akseli.salova...@digia.com> wrote:

> Hi all,
>
> New snapshot build from Qt 4.8.6 available:
> http://download.qt-project.org/snapshots/qt/4.8/2014-03-10_510/
> Packages are built against sha1 0315971ee951e9abe7f288564ddf2e81aeed1fd8
> "Qt 3 Support: Prevent double deletion of QObjectPrivate::threadData in
> QSettings" (HEAD) and this build should also address MinGW4.8.2 installer
> related known issues from previous snapshot.
>
> At least few additional commits are still needed before Qt 4.8.6 Release
> Candidate can be issued. Unfortunately CI 4.8 Mac OS X 10.6 configuration
> is currently broken (investigation ongoing) causing delay for the release
> process. Before CI 4.8 problems are solved please take this as possibility
> to thoroughly test currently available build in order to find possible
> regression & blocker issues for Qt 4.8.6 release. If such issues are found
> please report those to bugreports.qt-project.org and raise issue also on
> releas...@qt-project.org.
>
> Br,
> Akseli
> --
> Akseli Salovaara
> Digia, Qt
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development