Re: [Development] Work on qDebug and friends - debug areas

2012-01-25 Thread Francesco R.(vivo) 
On Wednesday 25 January 2012 20:07:57 Thiago Macieira wrote:
> On Wednesday, 25 de January de 2012 18.28.18, Olivier Goffart wrote:
> > KDebug::registerArea needs a registery. That works for KDE, but I don't
> > know  if that is a good idea for Qt

don't know if it can be applied to all platform or even linux, but both 
binutils linkers (bfd and gold) support --build-id, which is already used by 
distributions.

it can be generally read from an elf file like this:
readelf -x .note.gnu.build-id /lib/modules/3.2.1/misc/vboxnetflt.ko \
| awk '$NF ~ /GNU/ { getline; printf $2$3$4$5; getline; print $2 }'

it require "--build-id" flag passed to the linker, or it can be computed by 
`debugedit` as extracted by the rpm tool.

the id would change even for the same object with whatever change of 
compilation tools or settings and it would not work under other OS, so I'm not 
suggesting this, just bringing it to your attention.

> TBH, I really don't want the default debugging system in Qt to rely on
> config files. We're removing QSettings dependency from QtCore, so there's
> nothing to use.

+1 

$ wc -l ~/.kde4/share/config/kdebugrc
2837 .kde4/share/config/kdebugrc

> A third-party plugin can have a configuration mechanism to use the areas
> that qDebug defines.

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

Re: [Development] Use make before you push and stage

2012-01-25 Thread marius.storm-olsen 
On 1/25/12 11:32 AM, "ext 
morten.sor...@nokia.com" 
mailto:morten.sor...@nokia.com>> wrote:
On Jan 25, 2012, at 10:47 AM, ext 
jiang.ji...@nokia.com wrote:

For somewhat big changes and refactor changes, it usually took many iterations
of compile/testing until they finally went in, because it's not always possible
for the developers to try all the different configurations on their development
machine. Would it make sense to setup a semi-final staging area to test that
kind of changes before we finally cherry-pick them to master? It should make
smaller changes integration smoother.

I like the idea, but let's not make the gerrit interface more complicated. 
Instead the CI system could test all changes that are uploaded, in parallel 
(and perhaps at off-peak hours to better use available capasity).

While that it would be awesome to have a system which could compile test each 
uploaded patch set, and preferably have the results available before developers 
would review them, I think it something that will not scale; at least not 
without a system which can guarantee proper incremental builds (ccache would be 
a hack, still waste lots of resources, and only works with GCC.)

Lets take a look at the current numbers:

In the last week (now-7 days) we have across all projects merged 592 uploaded 
patch sets. Lets assume that we stage 3 patch sets per integration round, and 
that they are all successful on the first try. That would give us 197 rounds in 
the CI system. A round in the CI system currently takes ~3h, although that does 
include running auto tests of course.

In the same time period, we uploaded 1461 patch sets, since most review tasks 
go through several revisions. To properly evaluate each uploaded patch set, we 
would need 4383h of processing time, equal to 182.63 days if processed in 
order. To scale it up to manage that in parallel within 1 day, we'd need 182 
more Mac machines, Linux boxes and Windows machines; and that's at the current 
contribution rate :)

Of course, there are things we can do to streamline it more, and make such a 
system more likely. So, first we drop running auto tests, just simply compile 
the code. We'd perhaps be down to ~1h on VMs; measured by the slowest platform 
in VMs. Let's also drop webkit in the compile, and perhaps reduce the compile 
time be down to 20min? Then we're down to 20.3 days of compilation.

Could we get there? Perhaps. But we would need quite a few compromising 
shortcuts to get there, I think :)

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

Re: [Development] Work on qDebug and friends - debug areas

2012-01-25 Thread Thiago Macieira 
On Wednesday, 25 de January de 2012 18.28.18, Olivier Goffart wrote:
> KDebug::registerArea needs a registery. That works for KDE, but I don't
> know  if that is a good idea for Qt

TBH, I really don't want the default debugging system in Qt to rely on config
files. We're removing QSettings dependency from QtCore, so there's nothing to
use.

A third-party plugin can have a configuration mechanism to use the areas that
qDebug defines.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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

Re: [Development] Work on qDebug and friends - debug areas

2012-01-25 Thread Olivier Goffart 
On Wednesday 25 January 2012 13:18:33 Thiago Macieira wrote:
> On Wednesday, 25 de January de 2012 14.28.04, kai.koe...@nokia.com wrote:
> > I guess the KDebug::registerArea David mentioned does pretty much that.
> > I
> > researched a bit whether you somehow can do hashing already on compile
> > time, but it seems not to be possible even with Cx11  If you're doing
> > something like qHash you most probably don't want to do it in  every
> > single qDebug line ...
> 
> Olivier managed to hash at compile-time with C++11 using constexpr.

But that was not what I meant.
I mean we can choose number with qHash or even qrand(), and then hardcode that 
number in the source code. 

class QPluginManagerPrivate { enum { DebugArea = 1546743 }; ... }; 
// number randomly chosen

qDebug(DebugArea) << "try to load" << plugin; //in QPluginManagerPrivate::load

QT_ENABLE_DEBUG=1546743 ./myapp
And because this is just a debug tool, looking up number in the code is good 
enough
(but if the number is, by convention, choosen with qHash, we could also do 
QT_ENABLE_DEBUG=plugins)


KDebug::registerArea needs a registery. That works for KDE, but I don't know 
if that is a good idea for Qt

But I just wanted to give one idea (which I think is good :-D).
If you want to implement a more complex solution, go for it :-)

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

Re: [Development] Work on qDebug and friends - debug areas

2012-01-25 Thread Thiago Macieira 
On Wednesday, 25 de January de 2012 14.28.04, kai.koe...@nokia.com wrote:
> I guess the KDebug::registerArea David mentioned does pretty much that. I
> researched a bit whether you somehow can do hashing already on compile
> time, but it seems not to be possible even with Cx11  If you're doing
> something like qHash you most probably don't want to do it in  every single
> qDebug line ...

Olivier managed to hash at compile-time with C++11 using constexpr.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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

Re: [Development] Work on qDebug and friends - debug areas

2012-01-25 Thread kai.koehne 
> -Original Message-
> From: ext Olivier Goffart [mailto:oliv...@woboq.com]
> Sent: Wednesday, January 25, 2012 2:03 PM
> To: development@qt-project.org
> Cc: Koehne Kai (Nokia-MP/Berlin)
> Subject: Re: [Development] Work on qDebug and friends - debug areas
> 
> On Tuesday 24 January 2012 11:03:11 kai.koe...@nokia.com wrote:
> > Hi,
> >
> > One of the things still missing in the current debugging framework is
> > to categorize messages by area: This would allow you to enable/disable e.g.
> > debug messages for only one part of your app ...
> >
> > KDE & kDebug
> >
> > Here debug categories are basically ints, which have to be registered
> > 'kdelibs/kdecore/kdebug.areas'. You can pass your specific as an
> > argument to kDebug(..) et al., but usually you just set a define
> > (KDE_DEFAULT_DEBUG_AREA).
> >
> > + comparing int's is fast
> > - one central registry needed for debug areas (no go for custom apps?)
> 
> May I suggest we use something like qHash("MyModule") And ignore the
> fact that there are collisions. (you only would loose a bit granularity in 
> rare
> occasions.)

I guess the KDebug::registerArea David mentioned does pretty much that. I 
researched a bit whether you somehow can do hashing already on compile time, 
but it seems not to be possible even with Cx11 :( If you're doing something 
like qHash you most probably don't want to do it in  every single qDebug line 
...

> 
> > Log4cxx ...
> >
> > Frameworks like log4cxx
> > (http://www.360doc.com/content/09/0508/23/36491_3425784.shtml) that
> are
> > modeled after log4j use free text to define areas. Also, the areas might be
> > nested, so that "MyModule " includes "MyModule.Part" semantically, and
> you
> > can do very fine grain adjustments on what exactly to log.
> >
> > + Lots of flexibility
> > - comparing strings is slow, chances that you mistype ...
> 
> you can reduce the mistype changes my using macro or static char*
> 
> How slow is it really, compared to the cost of streaming the different types
> to string and concatenating them?

Good question. Probably it's time to do some measurements :) 

> Also qDebug will get disabled in release, right?

No, that's not the case. I used to think that too, probably because of the term 
'debug'. You can define QT_NO_DEBUG_OUTPUT, QT_NO_WARNING_OUTPUT,  but that's 
AFAIK not done anywhere in a default Qt build.

Regards

Kai

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

Re: [Development] Work on qDebug and friends - debug areas

2012-01-25 Thread Olivier Goffart 
On Tuesday 24 January 2012 11:03:11 kai.koe...@nokia.com wrote:
> Hi,
> 
> One of the things still missing in the current debugging framework is to
> categorize messages by area: This would allow you to enable/disable e.g.
> debug messages for only one part of your app ...
> 
> KDE & kDebug
> 
> Here debug categories are basically ints, which have to be registered
> 'kdelibs/kdecore/kdebug.areas'. You can pass your specific as an argument
> to kDebug(..) et al., but usually you just set a define
> (KDE_DEFAULT_DEBUG_AREA).
> 
> + comparing int's is fast
> - one central registry needed for debug areas (no go for custom apps?)

May I suggest we use something like qHash("MyModule")
And ignore the fact that there are collisions. (you only would loose a bit 
granularity in rare occasions.)


> Log4cxx ...
> 
> Frameworks like log4cxx
> (http://www.360doc.com/content/09/0508/23/36491_3425784.shtml) that are
> modeled after log4j use free text to define areas. Also, the areas might be
> nested, so that "MyModule " includes "MyModule.Part" semantically, and you
> can do very fine grain adjustments on what exactly to log.
> 
> + Lots of flexibility
> - comparing strings is slow, chances that you mistype ...

you can reduce the mistype changes my using macro or static char*

How slow is it really, compared to the cost of streaming the different types 
to string and concatenating them?

Also qDebug will get disabled in release, right?


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

[Development] More qlogging discussions (was RE: Change I0a9b89c1: QtDebug: Include file, line, function information)

2012-01-25 Thread alex.blasche 
Bringing the discussion back to the mailing list

> -Original Message-
> From: ext David Faure [mailto:fa...@kde.org]
> On Wednesday 25 January 2012 06:54:09 kai.koe...@nokia.com wrote:
> > > I don't mind to implement the category in a QLogging add-on module.
> >
> > Hi Wolfgang,
> >
> > great to hear! However, don't you think adding categories will require
> some
> > support by qDebug() and friends?
> 
> Yes. I think categories/areas need an argument passed to qDebug, like
> 
> qDebug(area) << "foo";

 +1 from me. 

> On the other hand a separate add-on module with a custom message
> handler for
> configuring what happens to each area (on/off, stderr or file or syslog, 
> etc.) is
> probably a good idea. But that's in addition.
> 
> > might be acceptable too, after all we've been doing fine in the libs without
> > categories so far :)
> 
> For some definition of "fine". IMHO the current situation is very sub-optimal:
> qtbase code cannot have any qDebug() enabled anywhere, since there's no
> way to

David, I think you are still too polite ;). 


> turn on/off per-area, so they are all commented out or ifdef'ed out, so the
> only way to get some debugging out of Qt is to recompile it. Some parts of Qt
> have built their own solution on top, like export QDBUS_DEBUG=1... which
> shows
> that we are not doing so "fine", it would be much better to have a centralized
> solution for this, where e.g. qdbus could have debug statements compiled in,
> but which would be disabled at runtime by default, and the addon could
> provide
> a way (config file, plugin, GUI app, whatever) to enable them without
> recompiling Qt.
>
> A plugin would actually be a cool way of doing it; you install the addon which
> provides a plugin, loaded by qt apps on startup, it installs a different
> default message handler, which has support for areas/categories.
> (while the default handler in QtCore would just ignore that parameter).

My preference goes towards a mere config file. All other solutions have a much 
higher effort curve. You require toolchains (you may not even have that when 
support asks you) and the environment may not even support a GUI. Vi will 
always make it to the device.

I really have a hard time understanding why this has to be in a separate Qt 
module and not in QtCore .

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

Re: [Development] Work on qDebug and friends

2012-01-25 Thread André Somers 
Op 25-1-2012 8:33, kai.koe...@nokia.com schreef:
> True. As much as I think a logging framework under the Qt project 
> umbrella would be useful, there'll be also always projects who want to 
> implement their own one. But ideally they should be able to do this on 
> the common infrastructure in Qt Core. Regards Kai PS: I should 
> probably point out that I personally don't intend to come up with a 
> full logging framework any time soon, just because of lack of time :( 

If people start dreaming about a Qt-logging framework, then *please* 
first take a look at the many out there already. libQxt for one has 
something that I think works quite well, but there are others as well. 
No need to re-do everything from scratch, if you ask me.

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

Re: [Development] Use make before you push and stage

2012-01-25 Thread kai.koehne 
> -Original Message-
> From: development-bounces+kai.koehne=nokia@qt-project.org
> [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On
> Behalf Of Knoll Lars (Nokia-MP/Oslo)
> Sent: Wednesday, January 25, 2012 9:55 AM
> To: Hughes Bradley (Nokia-MP/Oslo); development@qt-project.org
> Subject: Re: [Development] Use make before you push and stage
> 
> [...]
> Another hint: configure with -no-pch if you can afford it, otherwise you might
> end up with missing includes causing breakage in the CI system. And if you do
> larger refactorings or touch headers in a bigger way also try to compile with 
> -
> qtnamespace Foo (yes, I'm guilty of not doing this as well).

Just use something else than 'Foo' . It breaks the compilation of some 
autotests having the struct Foo ;)

Regards

Kai

... who reconfigures Qt the n-th time for today 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] More flexible window orientation API

2012-01-25 Thread Alan Alpert 
On Tue, 17 Jan 2012 21:58:29 ext Samuel Rødal wrote:
> Hi,
> 
> we're working toward having a flexible yet simple API for window
> orientations. It's important that the QWindow orientation API is
> flexible enough to handle all use cases, whereas the APIs on top (in Qt
> components for instance) can offer some more convenience for application
> developers.
> 
> We've found that the current QWindow::setOrientation() API isn't
> sufficient to express all the different ways of doing orientation.
> Namely, it currently only allows you to tell the windowing system /
> compositor about how the contents of the window are rendered, and not
> how the window buffer itself should be interpreted. It's not always
> desirable to explicitly rotate the contents of the window, sometimes
> it's practical to be able to use a different buffer layout instead. As
> an example, a game being ported to a portrait device might still want to
> use a landscape buffer layout, if the game engine design makes it hard
> to rotate the rendered output to fit a portrait buffer layout. For a
> raster based game there are performance costs due to having to do a
> 90-degree rotation.
> 
> So we should support both approaches, having a way to hint to the
> compositor both the window orientation and the content orientation.

What happens if you set both? Or set one but query the other?

Examples: That landscape 2D game sets the window orientation, what if you 
query content orientation?

What if that game then gains it's own rotation, but bases it off landscape for 
portability? So it sets window orientation to landscape and content 
orientation to portrait?

And for completeness, a contrived application sets content orientation but is 
in a contrived window manager that only works off window orientation.

--
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use make before you push and stage

2012-01-25 Thread morten.sorvig 

On Jan 25, 2012, at 10:47 AM, ext 
jiang.ji...@nokia.com wrote:

For somewhat big changes and refactor changes, it usually took many iterations
of compile/testing until they finally went in, because it's not always possible
for the developers to try all the different configurations on their development
machine. Would it make sense to setup a semi-final staging area to test that
kind of changes before we finally cherry-pick them to master? It should make
smaller changes integration smoother.

I like the idea, but let's not make the gerrit interface more complicated. 
Instead the CI system could test all changes that are uploaded, in parallel 
(and perhaps at off-peak hours to better use available capasity).

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

Re: [Development] Drag and Drop events.

2012-01-25 Thread morten.sorvig 

On Jan 25, 2012, at 8:31 AM, ext 
andrew.den-ex...@nokia.com wrote:

Does anyone feel responsible for/have an interest in these?

We have a patch in progress to update the QPA dnd API: see 
http://codereview.qt-project.org/#change,8902 . This is mostly backend work.


I'd like to add an overloaded constructor to QDropEvent and  which takes values 
for the proposedAction and source properties as an alternative to the current 
method querying the values from a global instance of QDragManager.  Something 
along these lines of http://codereview.qt-project.org/14209 would allow me to 
remove some rather silly workarounds I have in QML for sending events within a 
canvas independently of QDrag and the windowing system in general.

Makes sense to me (though I have not looked at the dnd APIs in detail).

Morten



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

Re: [Development] Does someone have plans to start working on the OAuth integration?

2012-01-25 Thread Peter Hartmann 
On 01/25/2012 09:22 AM, ext tero.aij...@nokia.com wrote:
> ...Mentioned on the bug here:
> https://bugreports.qt.nokia.com//browse/QTBUG-6229
> Or has the work even been started already?
 >
 > In case not, does e.g. kqOAuth already work with Qt5?

It would be nice if we could have kQOauth ([1]) as an add-on module in 
Qt ([2]); I am in contact with the kqOAuth author and from what I can 
remember he liked the idea. I guess that this would be all it takes to 
make it work with Qt 5, but I have never verified that.

Also, talking about OAuth is a bit confusing because it comes in two 
versions: OAuth 1.0a, which you want to use with a 3rd party library 
like kQOAuth, and OAuth 2, which I believe is simple enough to do on top 
of QNetworkAccessManager. Both versions are currently in use, while I 
think new APIs tend to use OAuth 2 more.
Here some examples, I hope they are still up to date:

OAuth 1.0a: Twitter, Flickr, Dropbox
OAuth 2:Facebook, Youtube, Foursquare


Peter


[1] http://www.d-pointer.com/solutions/kqoauth/
[2] http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use make before you push and stage

2012-01-25 Thread Jedrzej Nowacki 
On Wednesday 25. January 2012 09.32.38 ext bradley.hug...@nokia.com wrote:
> Yesterday was a bit of a frustrating day. I had to stage a simple .pro-file
> change of mine 8, eight, times before it finally went in. All of the
> breakages throughout the day where build breakages. Many of them were in
> the autotests, but some where in the libraries themselves.
> 
> My request is simple: make sure you've configured with the
> -developer-build, don't use -nomake if you're going to be pushing changes
> to Gerrit for review, and don't forget to use your make tool before
> pushing. You will save yourself and your fellow cuties alot of
> frustration.
> 
> Thanks :)
> 
> --
> Bradley T. Hughes
> bradley.hug...@nokia.com

Hi,

Another nice hint is given by Simon. If you are doing a source 
incompatible or a difficult, low level change, try to compile Qt5, all modules, 
not just one or two of them.

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use make before you push and stage

2012-01-25 Thread jiang.jiang 
Hi,

On Jan 25, 2012, at 9:55 AM, ext lars.kn...@nokia.com wrote:
>> Yesterday was a bit of a frustrating day. I had to stage a simple
>> .pro-file change of mine 8, eight, times before it finally went in. All
>> of the breakages throughout the day where build breakages. Many of them
>> were in the autotests, but some where in the libraries themselves.
>> 
>> My request is simple: make sure you've configured with the
>> -developer-build, don't use -nomake if you're going to be pushing changes
>> to Gerrit for review, and don't forget to use your make tool before
>> pushing. You will save yourself and your fellow cuties alot of
>> frustration.
> 
> Another hint: configure with -no-pch if you can afford it, otherwise you
> might end up with missing includes causing breakage in the CI system. And
> if you do larger refactorings or touch headers in a bigger way also try to
> compile with -qtnamespace Foo (yes, I'm guilty of not doing this as well).

For somewhat big changes and refactor changes, it usually took many iterations
of compile/testing until they finally went in, because it's not always possible
for the developers to try all the different configurations on their development
machine. Would it make sense to setup a semi-final staging area to test that
kind of changes before we finally cherry-pick them to master? It should make
smaller changes integration smoother.

I have to apologize for broken integration several times myself, but I simply
don't have time/energy to maintain a Windows development machine. But I would
love to first cherry-pick my change into a testing area before trying to 
integrate
that into master.

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

Re: [Development] Use make before you push and stage

2012-01-25 Thread Laszlo Papp 
> Another hint: configure with -no-pch if you can afford it, otherwise you
> might end up with missing includes causing breakage in the CI system. And
> if you do larger refactorings or touch headers in a bigger way also try to
> compile with -qtnamespace Foo (yes, I'm guilty of not doing this as well).

Could you please collect all of the undocumented suggestions (if any),
and place them on a relevant wiki page? Thanks.

Best Regards,
Laszlo Papp
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use make before you push and stage

2012-01-25 Thread lars.knoll 
On 1/25/12 9:32 AM, "ext bradley.hug...@nokia.com"
 wrote:

>Yesterday was a bit of a frustrating day. I had to stage a simple
>.pro-file change of mine 8, eight, times before it finally went in. All
>of the breakages throughout the day where build breakages. Many of them
>were in the autotests, but some where in the libraries themselves.
>
>My request is simple: make sure you've configured with the
>-developer-build, don't use -nomake if you're going to be pushing changes
>to Gerrit for review, and don't forget to use your make tool before
>pushing. You will save yourself and your fellow cuties alot of
>frustration.

Another hint: configure with -no-pch if you can afford it, otherwise you
might end up with missing includes causing breakage in the CI system. And
if you do larger refactorings or touch headers in a bigger way also try to
compile with -qtnamespace Foo (yes, I'm guilty of not doing this as well).

Cheers,
Lars

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

[Development] Use make before you push and stage

2012-01-25 Thread bradley.hughes 
Yesterday was a bit of a frustrating day. I had to stage a simple .pro-file 
change of mine 8, eight, times before it finally went in. All of the breakages 
throughout the day where build breakages. Many of them were in the autotests, 
but some where in the libraries themselves.

My request is simple: make sure you've configured with the -developer-build, 
don't use -nomake if you're going to be pushing changes to Gerrit for review, 
and don't forget to use your make tool before pushing. You will save yourself 
and your fellow cuties alot of frustration.

Thanks :)

--
Bradley T. Hughes
bradley.hug...@nokia.com




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

[Development] Does someone have plans to start working on the OAuth integration?

2012-01-25 Thread Tero.Aijala 
...Mentioned on the bug here:
https://bugreports.qt.nokia.com//browse/QTBUG-6229
Or has the work even been started already?

In case not, does e.g. kqOAuth already work with Qt5?

Br,

Tero

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