Re: [Development] WebView for Android on track for Qt 5.2?
On 09/05/2013 06:18 PM, Cornelius Hald wrote: Hi guys, what is the state of WebView (QQ2) for Android? Is it still planed for Qt 5.2? Is there a branch to track somewhere? The bug report suggests that instead of using QtWebKit a wrapper around the Android-WebView is now planned. https://bugreports.qt-project.org/browse/QTBUG-32093 Anything I could help you with? Hi, I've talked to the team working on the web engine in Qt in Digia, and right now there are no resources to do work on this in Digia unfortunately. It might be possible to do something specifically for Android, but it would be a lot nicer to have a cross-platform solution like the web engine guys initially planned, and I think this is needed for iOS as well. I'll talk to the iOS team here, but I don't think it sounds feasible that this will be done in the one and a half weeks we have left before the Qt 5.2 feature freeze. Sorry :( -- Eskil ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
I also very much like the idea of sticking the conversion functions right into the respective classes in QtCore and QtGui. At least QtWinExtras still has lots of helper methods that do not fall into this category, though. All that Windows specific window blurring, peeking, colorization etc. stuff will remain in QtWinExtras, and I'd still prefer QtWin as the namespace for those methods. So my original question still remains valid - can we rename the QtPlatformExtras namespaces to QtPlatform? Friedemann already prepared the first step for QtWinExtras: https://codereview.qt-project.org/#change,64803. -- J-P Nurmi On Sep 4, 2013, at 2:35 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: Yes yes a thousand times yes! On 9/3/13 14:41 , Sorvig Morten wrote: I think the advantages of having these functions available in QtCore/Gui outweighs the risk of customers accidentally using platform-dependent code. Maintenance will be easier since there is less code duplication. Morten On Sep 2, 2013, at 11:38 PM, Joseph Crowell joseph.w.crow...@gmail.com wrote: Most of the functionality was already in Qt 4 and was moved out for Qt 5 because of maintenance issues and different code for different platforms exposed to the customer. On 02/09/2013 10:35 PM, Sorvig Morten wrote: I agree the Extra looks superfluous. In fact I'd like to go a bit further and suggest we don't have platform extras at all and instead integrate the functionality into Qt: - Conversion functions for types in QtCore to QtCore - Conversion functions for types in QtGui to QtGui - Widgets to QtWidgets - Non-trivial implementation to the platform plugin - etc. I've prepared a set of patches showing how (for parts of QtMacExtras): https://codereview.qt-project.org/64342 https://codereview.qt-project.org/64343 https://codereview.qt-project.org/64344 https://codereview.qt-project.org/64345 https://codereview.qt-project.org/64346 Notes: - The platform extras will continue to exist as research playgrounds. - This approach works for platforms that has an Q_OS #define - The function header is named qmacfunctions.h, the namespace is QMac - We can now use the public NSString conversion functions in QtCore when implementing rest of Qt. - Conversion functions in QtCore And Gui can be used without bringing in QtMacExtras and its widgets dependency One case is still unsolved: classes that wrap native UI elements but are neither widgets nor Qt Quick Items. (Mac native tool bar and windows task bar for example). A possible solution could be to add the implementation to the platform plugin and add public API in QtWidgets and Qt Quick Controls. QMacNativeWidget and QMacCocoaViewContainer are done this way now, and are basically API wrappers around the implementation in QCococaWindow. Morten On Aug 30, 2013, at 3:27 PM, Jake Petroules jake.petrou...@petroules.com wrote: +1 from me for doing it everywhere, including in the library names. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@digia.com wrote: Hi all, While we still have a chance to tweak things before releasing 5.2, I'd like to re-open the discussion about platform extras naming. Short version: Could we rename the QtMacExtras QtWinExtras namespaces to just QtMac QtWin? (QtX11Extras namespace doesn't exist, at least yet) Long version: The current status: - Classes: QPlatformFoo - QX11Info (*) - QMacNativeWidget, ... - QWinTaskbarButton, ... (*) The only thing in QtX11Extras - already released in Qt 5.1. - Stand-alone function namespaces: QtPlatformExtras::toType() - QtWinExtras::toHBITMAP(), ... - QtMacExtras::toCGImageRef(), ... I'm not entirely happy with how the current stand-alone function namespaces look in application code. I would find it prettier if we dropped the Extras part from the namespace names. IMHO that would still remain distinctive enough, just making it look more professional and... convenient to type. :) if (QtWinExtras::isCompositionEnabled()) // ... vs. if (QtWin::isCompositionEnabled()) // ... Open questions: - What about the headers? - Could #include QtMacExtras/qmacfoo.h also become QtMac/qmacfoo.h? - QX11Extras/QX11Info was already released - so it would have to remain as a compatibility header if we chose the latter - What about the lib names? Should we keep them intact? - QtWinExtras.dll vs. QtWin.dll, or QtMacExtras.framework vs. QtMac.framework is not necessarily an improvement - The lib names are IMHO not that important, because users rarely have to care. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Drop the qt-components ML
Hi, I'd like to request dropping the Qt-components mailing list. The name is outdated and confusing now that we have Qt Quick Controls. The list has almost no traffic anymore and the rare questions it gets these days tend to be completely unrelated to the former qt-components and thus belong to inter...@qt-project.org. Dropping the list has been already discussed and generally agreed on qt-components: http://lists.qt-project.org/pipermail/qt-components/2013-August/000323.html. PS. If we drop the ML, could we still keep the archives, please? -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Drop the qt-components ML
On Fri, Sep 6, 2013 at 11:49 AM, Nurmi J-P jpnu...@digia.com wrote: Hi, I'd like to request dropping the Qt-components mailing list. The name is outdated and confusing now that we have Qt Quick Controls. The list has almost no traffic anymore and the rare questions it gets these days tend to be completely unrelated to the former qt-components and thus belong to inter...@qt-project.org. Dropping the list has been already discussed and generally agreed on qt-components: http://lists.qt-project.org/pipermail/qt-components/2013-August/000323.html . IMO, this should have been already dropped a while ago, so I agree. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
I agree, QtWin::foo looks much better. We can rename the QtMacExtras namespace as well. What about the module name itself? Would we still say import QtWinExtras and #include QtWinExtras/QWinFunctions? Morten On Sep 6, 2013, at 11:49 AM, Nurmi J-P jpnu...@digia.com wrote: I also very much like the idea of sticking the conversion functions right into the respective classes in QtCore and QtGui. At least QtWinExtras still has lots of helper methods that do not fall into this category, though. All that Windows specific window blurring, peeking, colorization etc. stuff will remain in QtWinExtras, and I'd still prefer QtWin as the namespace for those methods. So my original question still remains valid - can we rename the QtPlatformExtras namespaces to QtPlatform? Friedemann already prepared the first step for QtWinExtras: https://codereview.qt-project.org/#change,64803. -- J-P Nurmi On Sep 4, 2013, at 2:35 PM, Tor Arne Vestbø tor.arne.ves...@digia.com wrote: Yes yes a thousand times yes! On 9/3/13 14:41 , Sorvig Morten wrote: I think the advantages of having these functions available in QtCore/Gui outweighs the risk of customers accidentally using platform-dependent code. Maintenance will be easier since there is less code duplication. Morten On Sep 2, 2013, at 11:38 PM, Joseph Crowell joseph.w.crow...@gmail.com wrote: Most of the functionality was already in Qt 4 and was moved out for Qt 5 because of maintenance issues and different code for different platforms exposed to the customer. On 02/09/2013 10:35 PM, Sorvig Morten wrote: I agree the Extra looks superfluous. In fact I'd like to go a bit further and suggest we don't have platform extras at all and instead integrate the functionality into Qt: - Conversion functions for types in QtCore to QtCore - Conversion functions for types in QtGui to QtGui - Widgets to QtWidgets - Non-trivial implementation to the platform plugin - etc. I've prepared a set of patches showing how (for parts of QtMacExtras): https://codereview.qt-project.org/64342 https://codereview.qt-project.org/64343 https://codereview.qt-project.org/64344 https://codereview.qt-project.org/64345 https://codereview.qt-project.org/64346 Notes: - The platform extras will continue to exist as research playgrounds. - This approach works for platforms that has an Q_OS #define - The function header is named qmacfunctions.h, the namespace is QMac - We can now use the public NSString conversion functions in QtCore when implementing rest of Qt. - Conversion functions in QtCore And Gui can be used without bringing in QtMacExtras and its widgets dependency One case is still unsolved: classes that wrap native UI elements but are neither widgets nor Qt Quick Items. (Mac native tool bar and windows task bar for example). A possible solution could be to add the implementation to the platform plugin and add public API in QtWidgets and Qt Quick Controls. QMacNativeWidget and QMacCocoaViewContainer are done this way now, and are basically API wrappers around the implementation in QCococaWindow. Morten On Aug 30, 2013, at 3:27 PM, Jake Petroules jake.petrou...@petroules.com wrote: +1 from me for doing it everywhere, including in the library names. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@digia.com wrote: Hi all, While we still have a chance to tweak things before releasing 5.2, I'd like to re-open the discussion about platform extras naming. Short version: Could we rename the QtMacExtras QtWinExtras namespaces to just QtMac QtWin? (QtX11Extras namespace doesn't exist, at least yet) Long version: The current status: - Classes: QPlatformFoo - QX11Info (*) - QMacNativeWidget, ... - QWinTaskbarButton, ... (*) The only thing in QtX11Extras - already released in Qt 5.1. - Stand-alone function namespaces: QtPlatformExtras::toType() - QtWinExtras::toHBITMAP(), ... - QtMacExtras::toCGImageRef(), ... I'm not entirely happy with how the current stand-alone function namespaces look in application code. I would find it prettier if we dropped the Extras part from the namespace names. IMHO that would still remain distinctive enough, just making it look more professional and... convenient to type. :) if (QtWinExtras::isCompositionEnabled()) // ... vs. if (QtWin::isCompositionEnabled()) // ... Open questions: - What about the headers? - Could #include QtMacExtras/qmacfoo.h also become QtMac/qmacfoo.h? - QX11Extras/QX11Info was already released - so it would have to remain as a compatibility header if we chose the latter - What about the lib names? Should we keep them intact? - QtWinExtras.dll vs. QtWin.dll, or QtMacExtras.framework vs. QtMac.framework is not necessarily an improvement -
Re: [Development] WebView for Android on track for Qt 5.2?
On Fri, 2013-09-06 at 10:41 +0200, Eskil Abrahamsen Blomfeldt wrote: On 09/05/2013 06:18 PM, Cornelius Hald wrote: Hi guys, what is the state of WebView (QQ2) for Android? Is it still planed for Qt 5.2? Is there a branch to track somewhere? The bug report suggests that instead of using QtWebKit a wrapper around the Android-WebView is now planned. https://bugreports.qt-project.org/browse/QTBUG-32093 Anything I could help you with? Hi, I've talked to the team working on the web engine in Qt in Digia, and right now there are no resources to do work on this in Digia unfortunately. It might be possible to do something specifically for Android, but it would be a lot nicer to have a cross-platform solution like the web engine guys initially planned, and I think this is needed for iOS as well. I'll talk to the iOS team here, but I don't think it sounds feasible that this will be done in the one and a half weeks we have left before the Qt 5.2 feature freeze. Sorry :( -- Eskil Hi Eskil, thank you for your fast reply. Of course that wasn't the answer I was hoping for but at least I can be sure now. I have two projects running on Windows and Linux. Both I should port to Android as soon as possible. Are there any known workarounds? Like using the Android WebView and rendering it into a GL texture that could be used with QQ2? I only need output. No input or interaction. I will research my options but would be very grateful for any hints and tips. Also it would be great to know for what Qt version it is planned to have a working WebView on Android. Thanks! Conny ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A QtCore class for event-driven jobs
Op 6-9-2013 19:56, Matt Broadstone schreef:
On Fri, Sep 6, 2013 at 1:52 PM, David Faure david.fa...@kdab.com
mailto:david.fa...@kdab.com wrote:
I would like to propose the inclusion of a QJob class in QtCore,
based on
years of experience with KIO::Job and KJob.
The idea is to encapsulate an event driven asynchronous operation
into a job
class. Example use cases:
- a network download with QNetworkAccessManager.
- operations (command+reply) over a QLocalSocket or QTcpSocket
(like akonadi).
- long async dbus calls (special case of the previous line)
- long tasks executed by external processes (e.g. make from an
IDE, unrar
from an archive program)
...
At the core, QJob is really just a class with start() and kill(),
calling pure
virtual methods doStart() and doKill(), and signals, most
importantly the
result(QJob *) signal.
The expected use case is:
void SomeClass::methodWithAsynchronousJobCall()
{
QJob* job = someoperation(some parameters);
connect(job, SIGNAL(result(QJob*)),
this, SLOT(handleResult(QJob*)));
job-start(); // or it could just autostart, which I actually
prefer...
}
(other connects, specific to the job)
And handleResult is usually at least:
void SomeClass::handleResult( QJob *job )
{
if (job-error()) {
// handle error
} else {
// handle succesful job completion, if needed
}
}
But it can and should also have the following features:
* error code, error text
* suspend/resume with doSuspend/doResume virtual methods
* capabilities Killable and Suspendable, to avoid trying these on
jobs that
don't support them
* kill(Quietly) vs kill(EmitResult), for the app's convenience
* a finished signal that is emitted with both types of killing,
for things
like progress dialogs
* auto-deletion (on by default, can be turned off)
* synchronous exec() using a QEventLoop, with a big fat huge
warning about not
using that in GUI apps (ideally only to be used in unittests or
separate
threads).
* more standard signals for progress info, messages, warnings..
The whole point of standardizing such signals is that it allows
generic GUIs
to be built on top, so that your app or your desktop can show the
progress of
multiple concurrent jobs, of different types (file download, CD
burning, mail
checking, etc. etc.)
Finally, for the benefit of job implementors, QJob would support
sub-jobs.
The job implementation would choose when to create these subjobs
(all at once
initially, to have them run in parallel, or one after the other,
for sequence
of operations). KDE currently does that in a subclass
(KCompositeJob) but
Thiago and I (and kio, and akonadi) agree that it's better to have
it all in
one class instead.
We also have a standard interface for error handling so that all
jobs from a
given framework can have their error handled the same way, but
thinking about
it, that part could stay separate, at least for now.
Well, that's it. So why this email? Because Thiago asked me to,
and to gather
some support. I plan to make a merge request for Qt 5.2.
Thiago asked more specifically:
* API-wise, can't this be merged with QFuture?
- no, because QFuture encapsulates a value, with blocking methods
for getting
the value, even available as casting-to-the-value. If we imagine a
QFuture
that wraps a QJob, and the blocking method calling exec(), we'd
have a lot
more nested event loops than is good for the health of our programs.
On the other hand, QJob would not be related to any value. It's
really a
QObject that informs of progress via signals.
* relation to QRunnable?
A runnable is also some sort of job, but the implementation is
completely
different: a runnable is one sync method, while a qjob is all
signals/slots
based, with start() returning immediately. So one can't be used
like the
other, a given task implementation is either a blocking task for a
thread with
no event loop (QRunnable) or an async task that can actually be
used in any
thread with an event loop.
* relation to QNetworkReply?
If that one didn't exist yet, we'd definitely write it as a QJob
subclass. So
instead, I propose to wrap QNetworkReply into a QNetworkJob or
something, in
order to offer the QJob interface for QNAM requests. On one hand
this doesn't
have to go in at the same time as QJob itself, but OTOH it could
be a real-
world testcase for it, proving its usefulness and correctness...
Any other questions?
+1, or more if possible :)
Is this code up somewhere already for early review? This is very much
needed in Qt imho, I imagine it's
Re: [Development] A QtCore class for event-driven jobs
On Fri, Sep 6, 2013 at 1:52 PM, David Faure david.fa...@kdab.com wrote:
I would like to propose the inclusion of a QJob class in QtCore, based on
years of experience with KIO::Job and KJob.
The idea is to encapsulate an event driven asynchronous operation into a
job
class. Example use cases:
- a network download with QNetworkAccessManager.
- operations (command+reply) over a QLocalSocket or QTcpSocket (like
akonadi).
- long async dbus calls (special case of the previous line)
- long tasks executed by external processes (e.g. make from an IDE,
unrar
from an archive program)
...
At the core, QJob is really just a class with start() and kill(), calling
pure
virtual methods doStart() and doKill(), and signals, most importantly the
result(QJob *) signal.
The expected use case is:
void SomeClass::methodWithAsynchronousJobCall()
{
QJob* job = someoperation(some parameters);
connect(job, SIGNAL(result(QJob*)),
this, SLOT(handleResult(QJob*)));
job-start(); // or it could just autostart, which I actually prefer...
}
(other connects, specific to the job)
And handleResult is usually at least:
void SomeClass::handleResult( QJob *job )
{
if (job-error()) {
// handle error
} else {
// handle succesful job completion, if needed
}
}
But it can and should also have the following features:
* error code, error text
* suspend/resume with doSuspend/doResume virtual methods
* capabilities Killable and Suspendable, to avoid trying these on jobs that
don't support them
* kill(Quietly) vs kill(EmitResult), for the app's convenience
* a finished signal that is emitted with both types of killing, for things
like progress dialogs
* auto-deletion (on by default, can be turned off)
* synchronous exec() using a QEventLoop, with a big fat huge warning about
not
using that in GUI apps (ideally only to be used in unittests or separate
threads).
* more standard signals for progress info, messages, warnings..
The whole point of standardizing such signals is that it allows generic
GUIs
to be built on top, so that your app or your desktop can show the progress
of
multiple concurrent jobs, of different types (file download, CD burning,
mail
checking, etc. etc.)
Finally, for the benefit of job implementors, QJob would support sub-jobs.
The job implementation would choose when to create these subjobs (all at
once
initially, to have them run in parallel, or one after the other, for
sequence
of operations). KDE currently does that in a subclass (KCompositeJob) but
Thiago and I (and kio, and akonadi) agree that it's better to have it all
in
one class instead.
We also have a standard interface for error handling so that all jobs from
a
given framework can have their error handled the same way, but thinking
about
it, that part could stay separate, at least for now.
Well, that's it. So why this email? Because Thiago asked me to, and to
gather
some support. I plan to make a merge request for Qt 5.2.
Thiago asked more specifically:
* API-wise, can't this be merged with QFuture?
- no, because QFuture encapsulates a value, with blocking methods for
getting
the value, even available as casting-to-the-value. If we imagine a QFuture
that wraps a QJob, and the blocking method calling exec(), we'd have a lot
more nested event loops than is good for the health of our programs.
On the other hand, QJob would not be related to any value. It's really a
QObject that informs of progress via signals.
* relation to QRunnable?
A runnable is also some sort of job, but the implementation is completely
different: a runnable is one sync method, while a qjob is all signals/slots
based, with start() returning immediately. So one can't be used like the
other, a given task implementation is either a blocking task for a thread
with
no event loop (QRunnable) or an async task that can actually be used in any
thread with an event loop.
* relation to QNetworkReply?
If that one didn't exist yet, we'd definitely write it as a QJob subclass.
So
instead, I propose to wrap QNetworkReply into a QNetworkJob or something,
in
order to offer the QJob interface for QNAM requests. On one hand this
doesn't
have to go in at the same time as QJob itself, but OTOH it could be a real-
world testcase for it, proving its usefulness and correctness...
Any other questions?
+1, or more if possible :)
Is this code up somewhere already for early review? This is very much
needed in Qt imho, I imagine it's one of those patterns that people roll
themselves in many cases.
Matt
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
[Development] A QtCore class for event-driven jobs
I would like to propose the inclusion of a QJob class in QtCore, based on
years of experience with KIO::Job and KJob.
The idea is to encapsulate an event driven asynchronous operation into a job
class. Example use cases:
- a network download with QNetworkAccessManager.
- operations (command+reply) over a QLocalSocket or QTcpSocket (like akonadi).
- long async dbus calls (special case of the previous line)
- long tasks executed by external processes (e.g. make from an IDE, unrar
from an archive program)
...
At the core, QJob is really just a class with start() and kill(), calling pure
virtual methods doStart() and doKill(), and signals, most importantly the
result(QJob *) signal.
The expected use case is:
void SomeClass::methodWithAsynchronousJobCall()
{
QJob* job = someoperation(some parameters);
connect(job, SIGNAL(result(QJob*)),
this, SLOT(handleResult(QJob*)));
job-start(); // or it could just autostart, which I actually prefer...
}
(other connects, specific to the job)
And handleResult is usually at least:
void SomeClass::handleResult( QJob *job )
{
if (job-error()) {
// handle error
} else {
// handle succesful job completion, if needed
}
}
But it can and should also have the following features:
* error code, error text
* suspend/resume with doSuspend/doResume virtual methods
* capabilities Killable and Suspendable, to avoid trying these on jobs that
don't support them
* kill(Quietly) vs kill(EmitResult), for the app's convenience
* a finished signal that is emitted with both types of killing, for things
like progress dialogs
* auto-deletion (on by default, can be turned off)
* synchronous exec() using a QEventLoop, with a big fat huge warning about not
using that in GUI apps (ideally only to be used in unittests or separate
threads).
* more standard signals for progress info, messages, warnings..
The whole point of standardizing such signals is that it allows generic GUIs
to be built on top, so that your app or your desktop can show the progress of
multiple concurrent jobs, of different types (file download, CD burning, mail
checking, etc. etc.)
Finally, for the benefit of job implementors, QJob would support sub-jobs.
The job implementation would choose when to create these subjobs (all at once
initially, to have them run in parallel, or one after the other, for sequence
of operations). KDE currently does that in a subclass (KCompositeJob) but
Thiago and I (and kio, and akonadi) agree that it's better to have it all in
one class instead.
We also have a standard interface for error handling so that all jobs from a
given framework can have their error handled the same way, but thinking about
it, that part could stay separate, at least for now.
Well, that's it. So why this email? Because Thiago asked me to, and to gather
some support. I plan to make a merge request for Qt 5.2.
Thiago asked more specifically:
* API-wise, can't this be merged with QFuture?
- no, because QFuture encapsulates a value, with blocking methods for getting
the value, even available as casting-to-the-value. If we imagine a QFuture
that wraps a QJob, and the blocking method calling exec(), we'd have a lot
more nested event loops than is good for the health of our programs.
On the other hand, QJob would not be related to any value. It's really a
QObject that informs of progress via signals.
* relation to QRunnable?
A runnable is also some sort of job, but the implementation is completely
different: a runnable is one sync method, while a qjob is all signals/slots
based, with start() returning immediately. So one can't be used like the
other, a given task implementation is either a blocking task for a thread with
no event loop (QRunnable) or an async task that can actually be used in any
thread with an event loop.
* relation to QNetworkReply?
If that one didn't exist yet, we'd definitely write it as a QJob subclass. So
instead, I propose to wrap QNetworkReply into a QNetworkJob or something, in
order to offer the QJob interface for QNAM requests. On one hand this doesn't
have to go in at the same time as QJob itself, but OTOH it could be a real-
world testcase for it, proving its usefulness and correctness...
Any other questions?
--
David Faure | david.fa...@kdab.com | Managing Director KDAB France
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A QtCore class for event-driven jobs
On sexta-feira, 6 de setembro de 2013 19:52:47, David Faure wrote: * relation to QNetworkReply? If that one didn't exist yet, we'd definitely write it as a QJob subclass. So instead, I propose to wrap QNetworkReply into a QNetworkJob or something, in order to offer the QJob interface for QNAM requests. On one hand this doesn't have to go in at the same time as QJob itself, but OTOH it could be a real- world testcase for it, proving its usefulness and correctness... Any other questions? What if we put the QJob class and convenience derived classes like QNetworkRequestJob, QProcessJob, QThreadJob, etc. in one new library. This library could be extended later with more job types. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] A QtCore class for event-driven jobs
I think it is a good idea to introduce a playground module until we have the API clean and stable, and then we might want to include it right into QtCore. Regards, Konstantin 2013/9/7 Thiago Macieira thiago.macie...@intel.com On sexta-feira, 6 de setembro de 2013 19:52:47, David Faure wrote: * relation to QNetworkReply? If that one didn't exist yet, we'd definitely write it as a QJob subclass. So instead, I propose to wrap QNetworkReply into a QNetworkJob or something, in order to offer the QJob interface for QNAM requests. On one hand this doesn't have to go in at the same time as QJob itself, but OTOH it could be a real- world testcase for it, proving its usefulness and correctness... Any other questions? What if we put the QJob class and convenience derived classes like QNetworkRequestJob, QProcessJob, QThreadJob, etc. in one new library. This library could be extended later with more job types. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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
