On Sun, Sep 8, 2013 at 3:06 AM, Aleix Pol wrote:
> Either that or not rushing into porting everything to QJob. Having it in a
> separate library would mean having QtCoreJobs, QtNetworkJobs, etc. Doesn't
> seem to be very flexible.
>
I also think it makes sense to have a separate playground modul
On Sat, Sep 7, 2013 at 2:20 AM, Thiago Macieira
wrote:
> 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 QNet
On sábado, 7 de setembro de 2013 20:34:20, Kurt Pattyn wrote:
> to my (limited) knowledge, I only know of the existence of
> qtbase/src/corelib/codecs/qutfcodec.cpp. Could you indicate where the other
> copies are?
qurlrecode.cpp
qjsonparser.cpp
qxmlstream.cpp
--
Thiago Macieira - thiago.macieir
Hi Thiago,
to my (limited) knowledge, I only know of the existence of
qtbase/src/corelib/codecs/qutfcodec.cpp.
Could you indicate where the other copies are?
Thanks
On 05 Sep 2013, at 19:05, development-requ...@qt-project.org wrote:
> From: Thiago Macieira
> Subject: Re: [Development] A bug o
On Sat, Sep 7, 2013 at 6:45 PM, Mark wrote:
> It would be cool if someone could push your patch in qtmultimedia
>
https://codereview.qt-project.org/#change,64894
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailma
On Sat, Sep 7, 2013 at 7:05 PM, Sergio Martins wrote:
> **
>
> On Saturday, September 07, 2013 05:25:56 PM Mark wrote:
>
> > Hi,
>
> >
>
> > While trying to update my Qt build i got this nasty unexpected error:
>
> > http://paste.kde.org/p7c51188c/
>
>
>
> Try http://bpaste.net/show/130243/ in qtm
On Saturday, September 07, 2013 05:25:56 PM Mark wrote:
> Hi,
>
> While trying to update my Qt build i got this nasty unexpected error:
> http://paste.kde.org/p7c51188c/
Try http://bpaste.net/show/130243/ in qtmultimedia.
Regards,
--
Join us in October at Qt Developer Days 2013 - https://devda
On sábado, 7 de setembro de 2013 16:35:22, Stefan Merettig wrote:
> need a sane approach for this anyway, and as you already stated, JSON
> would
> be a valid option here.
I'd rather not. Please extend the meta object format instead.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Softwar
On sábado, 7 de setembro de 2013 17:25:56, Mark wrote:
> While trying to update my Qt build i got this nasty unexpected error:
> http://paste.kde.org/p7c51188c/
>
> Or rather, two other folks from #kde-devel had that. While i recompiled i
> was welcomed by the same error.
Not a bug in Qt.
Look a
Hi,
While trying to update my Qt build i got this nasty unexpected error:
http://paste.kde.org/p7c51188c/
Or rather, two other folks from #kde-devel had that. While i recompiled i
was welcomed by the same error.
I was then advised to do:
git revert 8b7a8efe6
That would be this commit:
https://q
Hi again, (sorry for the delays, my internet connection is really
flaky)
I'd still hate to use QString::split(). But then I thought about your
suggestion to recycle the tag-column with a flag indicating the format
or something. As multiple Q_INFO annotations are allowed per 'object',
we
need a s
On Saturday 07 September 2013 00:55:26 Konstantin Ritt wrote:
> Simply can not ignore this thread :)
> Like Andre, I have written my own jobs implementation, too.
> And I completely agree that not having some kind of job manager makes QJob
> API of quite limited usefulness
I disagree. One can cho
On Friday 06 September 2013 22:22:20 Andre Somers wrote:
> . However, I'd hope the design would
> not limit itself to just event-driven jobs, if I understand correctly
> what that means. Some of my jobs are just heavy processing that require
> multi-threading.
That sounds more like QRunnable t
On Friday 06 September 2013 13:56:51 Matt Broadstone wrote:
> 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.
The current code is at
https://projects.kde.org/projects/kde/k
On Sat, 7 Sep 2013, Konstantin Ritt wrote:
one would probably prefer
[code]
job = someoperation(some parameters);
manager->enqueue(job);
[/code]
, where "someoperation" could be manager's registered job factory or QJob
sub-class, etc.
I am not sure why everyone prefers to have a "manager" ;
15 matches
Mail list logo