On Tuesday, 9 de August de 2011 00:33:46 David Faure wrote:
> No no, I call wait after *terminate* ! Terminate is "almost instant
> termination", it kills the thread. So this does not wait for the DNS lookup
> to be finished, it only waits for terminate to call the cleanup callback,
> which should
(I reply to the list only, as it is not related to the request itself)
> And no, we definitely want no nested event loop. Anything else, but
> not that.
I agree 100%. When you see things like the same modal messagebox popping
up twice (so one is visible, and another one appears called from the
On Monday, August 08, 2011 18:44:40 Tomaz Canabrava wrote:
> Juk is an easy target, and in need of love.
Honestly I was going to recommend the same thing.
I don't agree that it's (all) easy (although there is certainly a lot of "low-
hanging fruit"), but it does have the advantage that I'm at lea
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
>
> David Faure wrote:
> (Sorry, flaky wifi lost the comment)
>
> I am very much against a nested event loop (QEventLoop::exec), it's a
> well-known fact nowadays that it creates unexpected re-entrancy and crashes.
>
> A
On Monday, 8 de August de 2011 15:28:45 Dawit A wrote:
> Yes. The uri filter plugins that are the primary users of this new
> function require a synchronous function call or they would all have to
> implement this syncing part individually for themselves.
Then let them do it.
--
Thiago Macieira
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102246/#review5525
---
If the proposed patch is unacceptable, I suggest adding a new me
Juk is an easy target, and in need of love.
On Mon, Aug 8, 2011 at 1:44 PM, Lydia Pintscher wrote:
> Heya folks :)
>
> I'm at the Desktop Summit and was asked by someone for a smallish
> project that he could hack on in KDE and that needs help. Ideally he'd
> like to start hacking on it tomorrow
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102258/
---
Review request for kdelibs and Frederik Gladhorn.
Summary
---
The pus
On Mon, Aug 8, 2011 at 3:56 PM, Thomas Zander wrote:
> On Monday 08 August 2011 21.28.45 Dawit A wrote:
>> On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander wrote:
>> > On Monday 08 August 2011 21.02.02 Dawit A wrote:
>> >> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
>> >> > On Monday 08 Au
On Monday 08 August 2011 21.28.45 Dawit A wrote:
> On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander wrote:
> > On Monday 08 August 2011 21.02.02 Dawit A wrote:
> >> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
> >> > On Monday 08 August 2011 18.35.13 Dawit A wrote:
> >> >> #2. The original f
> On July 20, 2011, 3:29 p.m., Peter Penz wrote:
> > Thanks for the update!
> >
> > >> would only make sense to push it to the 4.7 branch.
> > > What exactly do you mean by 'only'? Isn't 4.7 the branch just
> > > about to be released and which will be in all distros until sometime next
> > > ye
On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander wrote:
> On Monday 08 August 2011 21.02.02 Dawit A wrote:
>> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
>> > On Monday 08 August 2011 18.35.13 Dawit A wrote:
>> >> #2. The original functions in this class were non-blocking. It is only
>> >>
On Sunday 7 August 2011 08:58:46 Allen Winter wrote:
> On Sunday 07 August 2011 7:45:12 AM Stephen Kelly wrote:
> > I think maybe people didn't get the memo that there isn't going to be a
> > KDE 4.8?
> Huh? I am 100% against that plan.
>
> I can go along with saying that kdelibs is "done" at 4.7
On Monday 08 August 2011 21.02.02 Dawit A wrote:
> On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
> > On Monday 08 August 2011 18.35.13 Dawit A wrote:
> >> #2. The original functions in this class were non-blocking. It is only
> >> the new function I added that is a blocking call. And that i
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
>
> David Faure wrote:
> (Sorry, flaky wifi lost the comment)
>
> I am very much against a nested event loop (QEventLoop::exec), it's a
> well-known fact nowadays that it creates unexpected re-entrancy and crashes.
>
> A
On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander wrote:
> On Monday 08 August 2011 18.35.13 Dawit A wrote:
>> #2. The original functions in this class were non-blocking. It is only
>> the new function I added that is a blocking call. And that is required
>> because of the need for a timeout when doin
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102256/
---
Review request for kdelibs and David Faure.
Summary
---
Use the sugge
On Saturday, August 06, 2011 09:32:02 AM David Faure wrote:
..
> The next step is to backport the few bits of new api that went into master
> and that application developers started using, into the 4.7 branch of
> kdelibs. I'll work on that, but help is welcome too.
...
This plan seems to be contr
> On Aug. 7, 2011, 11:45 a.m., Thomas Zander wrote:
> > Hmm, did this get committed already?
> >
> > visually the change looks good to me, what do others think?
I was in favor of just committing it as there was no feedback (:
But I am 3 weeks on vacation now, so feel free to commit or I will do
On Monday 08 August 2011 18.35.13 Dawit A wrote:
> #2. The original functions in this class were non-blocking. It is only
> the new function I added that is a blocking call. And that is required
> because of the need for a timeout when doing name lookups from the
> urifilter plugins. Thos plugins p
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
>
> David Faure wrote:
> (Sorry, flaky wifi lost the comment)
>
> I am very much against a nested event loop (QEventLoop::exec), it's a
> well-known fact nowadays that it creates unexpected re-entrancy and crashes.
>
> A
Heya folks :)
I'm at the Desktop Summit and was asked by someone for a smallish
project that he could hack on in KDE and that needs help. Ideally he'd
like to start hacking on it tomorrow and work more on it over the next
couple of days during the workshops.
If you have nice ideas please let me kn
On Mon, Aug 8, 2011 at 11:25 AM, Thiago Macieira wrote:
> On Monday, 8 de August de 2011 14:25:13 David Faure wrote:
>> And since I just fixed the crash (missing wait() after terminate(), see
>> commit log), I don't think we need this change. However reusing threads
>> might be a good idea (separa
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102246/#review5517
---
> This change could alter the behaviour of some windows, if they
Hi,
I've just pushed an update to the frameworks branch in kdelibs.git. I moved
some classes from kdeui/itemviews to tier1/itemmodels/ and added them to the
buildsystem in a library.
Just for the need of starting somewhere I created a top-level directory
called tier1 to hold the library. As w
On Monday, 8 de August de 2011 14:25:13 David Faure wrote:
> And since I just fixed the crash (missing wait() after terminate(), see
> commit log), I don't think we need this change. However reusing threads
> might be a good idea (separate issue).
This could probably use a redesign. If this class
> On Aug. 8, 2011, 1:53 p.m., David Faure wrote:
> >
(Sorry, flaky wifi lost the comment)
I am very much against a nested event loop (QEventLoop::exec), it's a
well-known fact nowadays that it creates unexpected re-entrancy and crashes.
And since I just fixed the crash (missing wait() after t
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102238/#review5499
---
- David
On Aug. 7, 2011, 4:07 a.m., Dawit Alemayehu wrote:
>
> On Aug. 8, 2011, 9:20 a.m., Olivier Goffart wrote:
> > Looks like the sumilar issur in Qt:
> > https://bugreports.qt.nokia.com//browse/QTBUG-14499
> > We decided not to change the behaviour, but to update the documentation
> > instead.
This change could alter the behaviour of some windows, i
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102246/#review5492
---
Looks like the sumilar issur in Qt:
https://bugreports.qt.nokia
30 matches
Mail list logo
