---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/#review1190
---
Please also add the { } around single line blocks (as per
On Feb. 4, 2011, 8:02 a.m., Pino Toscano wrote:
Please also add the { } around single line blocks (as per kdelibs coding
style).
Dawit Alemayehu wrote:
Lets us forget about such nitpicks, okay... If such unnecessary coding
styles were to be enforced, there would be so many lines
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/#review1199
---
Still the coding style issues to fix in the new code.
On Friday 04 February 2011, Thiago Macieira wrote:
Hmm... I don't get it. Isn't the database version saved in the database?
Why do we need to search the pkg-config file (which is a development
file!) to find out how to use the database?
If this is required, it sounds like shared-mime-info
On Feb. 4, 2011, 10:54 a.m., Pino Toscano wrote:
Still the coding style issues to fix in the new code.
Sorry, but I do not see that as an issue...
On Feb. 4, 2011, 10:54 a.m., Pino Toscano wrote:
kdecore/services/kmimetyperepository.cpp, lines 688-689
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 3:52 p.m.)
Review request for kdelibs and David
On Feb. 4, 2011, 8:02 a.m., Pino Toscano wrote:
Please also add the { } around single line blocks (as per kdelibs coding
style).
Dawit Alemayehu wrote:
Lets us forget about such nitpicks, okay... If such unnecessary coding
styles were to be enforced, there would be so many lines
- Original Message -
It
is when I have to unnecessarily type more than I have to. Seriously
this is getting to be annoying and I do not mean you personally. These
rigid and brittle coding styles. One project says no braces for single
line statements and another says the complete
On Friday 04 February 2011 17:05:07 Tom Albers wrote:
- Original Message -
It
is when I have to unnecessarily type more than I have to. Seriously
this is getting to be annoying and I do not mean you personally. These
rigid and brittle coding styles. One project says no braces
On 4 February 2011 17:05, Tom Albers t...@kde.org wrote:
- Original Message -
It
is when I have to unnecessarily type more than I have to. Seriously
this is getting to be annoying and I do not mean you personally. These
rigid and brittle coding styles. One project says no braces for
Em sexta-feira, 4 de fevereiro de 2011, às 05:24:26, Dawit A escreveu:
In the meantime, I've been discussing with Rémi about the issue and he's
not budging from his position that libraries shoul
never use Unix signals. To be
honest, he's right: Unix signals are meant to be used centrally
On Fri, Feb 04, 2011 at 05:41:16PM +0100, Thiago Macieira wrote:
This makes each process started spawn a new thread, which
will block on waitpid(2).
i have the vague notion that blocking/ignoring sigchld will prevent
wait*() from working on some systems. dunno where i got that from.
I'm
Em sexta-feira, 4 de fevereiro de 2011, às 18:05:09, Oswald Buddenhagen
escreveu:
On Fri, Feb 04, 2011 at 05:41:16PM +0100, Thiago Macieira wrote:
This makes each process started spawn a new thread, which
will block on waitpid(2).
i have the vague notion that blocking/ignoring sigchld will
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 6:22 p.m.)
Review request for kdelibs and David
On Friday, 4 de February de 2011 19:38:51 Oswald Buddenhagen wrote:
On Fri, Feb 04, 2011 at 06:28:10PM +0100, Thiago Macieira wrote:
Em sexta-feira, 4 de fevereiro de 2011, às 18:17:13, Thiago Macieira
escreveu:
I thought about that. My work on no-thread-until-pipes-close had
already
On Friday, 4 de February de 2011 14:06:58 Dawit A wrote:
BTW, there is one side issue I noticed in QProcess through this whole
process. Why does QProcess not exit immediately if I invoke kill or
terminate or even when it just timed out from waiting for the child
process ? IOW, why wait some
On Friday, 4 de February de 2011 16:35:32 Dawit A wrote:
Let us take out terminate from the equation. It is my mistake I
included it here because its documentation states that The process
may not exit as a result of calling this function. However, I really
do not understand why what you stated
On Fri, Feb 4, 2011 at 5:00 PM, Thiago Macieira thi...@kde.org wrote:
On Friday, 4 de February de 2011 16:35:32 Dawit A wrote:
Let us take out terminate from the equation. It is my mistake I
included it here because its documentation states that The process
may not exit as a result of calling
On Friday, 4 de February de 2011 19:28:06 Nicolás Alvarez wrote:
On 04/02/2011, Thiago Macieira thi...@kde.org wrote:
Ok, fair enough. Threading-after-pipes-closed is not an option then.
That leaves back again at square one:
- one thread per subprocess
OR
- SIGCHLD handler
On Friday, 4 de February de 2011 17:35:00 Dawit A wrote:
Ok, that sounds like unexpected behaviour. Has this been filed as a bug?
Not yet. I simply mentioned it here because you seem to be addressing
the issue that exposed this behavior, but I guess I can open a ticket
against Qt for this.
On Fri, Feb 04, 2011 at 04:35:32PM -0500, Dawit Alemayehu wrote:
The case of the kill is even more baffling to me because its
documentation clearly says Kills the current process, causing it to
exit immediately. So If I kill is invoked as such
process.kill();
what should a reasonable
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
Review request for kdelibs and David Faure.
Summary
---
The attached
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 3, 2011, 11:23 p.m.)
Review request for kdelibs and David
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 12:07 a.m.)
Review request for kdelibs and David
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 12:11 a.m.)
Review request for kdelibs and David
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100539/
---
(Updated Feb. 4, 2011, 1:29 a.m.)
Review request for kdelibs and David
Pino Toscano p...@kde.org writes:
kdecore/services/kmimetyperepository.cpp
http://git.reviewboard.kde.org/r/100539/#comment1002
I guess you should also add the /usr/local equivalent, and enclose both
in a
#ifdef Q_OS_UNIX
...
#endif
block
By the way, how welcome
On Thursday, 3 de February de 2011 22:44:56 Dawit Alemayehu wrote:
The attached patch is a workaround to the much discussed issue with VLC
hanging when opening a KDE file dialog. For the details about the causes of
this bug, see http://lists.kde.org/?t957244751r=1w=2 and the bug
report
28 matches
Mail list logo
