---
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:
---
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, 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
---
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
On Mon, Aug 8, 2011 at 11:25 AM, Thiago Macieira thi...@kde.org 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
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
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.
And since I
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
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 it
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
---
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
On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander zan...@kde.org 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
On Monday 08 August 2011 21.02.02 Dawit A wrote:
On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander zan...@kde.org 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
On Monday 08 August 2011 21.28.45 Dawit A wrote:
On Mon, Aug 8, 2011 at 3:20 PM, Thomas Zander zan...@kde.org wrote:
On Monday 08 August 2011 21.02.02 Dawit A wrote:
On Mon, Aug 8, 2011 at 2:31 PM, Thomas Zander zan...@kde.org wrote:
On Monday 08 August 2011 18.35.13 Dawit A wrote:
#2.
---
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
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 -
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 least
On Monday, 8 de August de 2011 03:18:29 Christoph Feck wrote:
How exactly the massif tool needs to be used to analyze/improve our
KDE applications is beyond this mail; someone else might add that
information.
While not ideal, this works already:
valgrind --tool=massif appname
--
Thiago
On Monday, 8 de August de 2011 01:40:03 Marko Käning wrote:
messagebus53 0.0 0.0 2435472712 ?? Ss5:58PM 0:00.01
/opt/clean-slate/bin/dbus-daemon --system --nofork
Compare the prefix of this installation to that of the socket you're connecting
to. I'm guessing that this
On Aug 8, 2011, at 8:51 AM, Thiago Macieira wrote:
Compare the prefix of this installation to that of the socket you're
connecting
to. I'm guessing that this daemon has its socket somewhere else.
I recommend you just recompile any and all D-Bus installations and tell them
ALL to place
On Monday, 8 de August de 2011 09:09:53 Marko Käning wrote:
markos-imac:~ marko$ /opt/clean-slate/bin/dbus-daemon --nofork --session
Failed to start message bus: launch_msg(CheckIn) IPC failure: Operation
not permitted
I end up with the same stuff. :-(
See, all this, although these
On Aug 8, 2011, at 10:13 AM, Thiago Macieira wrote:
The session daemon doesn't use the same socket as the system daemon. You're
never supposed to launch the session daemon manually -- use dbus-launch for
it.
Oh, I see.
On Mac OS X, you may have launchd integration. Use that.
Well, I do, but
On Monday 08 August 2011 08:49:05 Thiago Macieira wrote:
On Monday, 8 de August de 2011 03:18:29 Christoph Feck wrote:
How exactly the massif tool needs to be used to analyze/improve
our KDE applications is beyond this mail; someone else might add
that information.
While not ideal, this
23 matches
Mail list logo
