On Thu, Apr 25, 2013 at 03:11:25PM +0200, Martin Bříza wrote:
after fixing a bit in the $subj file I've realized it (in my opinion) should
be split into one abstract class with a factory handling the back-ends
provided by the current session managers such as ConsoleKit and
systemd-logind while
On April 26, 2013, 8:09 a.m., Kevin Krammer wrote:
I am wondering if it wouldnt't make more sense to have the PIM integration
as a separate lib, so that libkfbapi has a stable API and ABI at all times.
I like that idea. I'll update the review with it then :)
- Martin
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110083/
---
(Updated April 29, 2013, 11:17 a.m.)
Review request for kdelibs and
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110083/
---
(Updated April 29, 2013, 11:18 a.m.)
Review request for kdelibs and
Hi,
On Fri, 26 Apr 2013 23:30:43 +0200, Albert Astals Cid aa...@kde.org
wrote:
El Dijous, 25 d'abril de 2013, a les 15:11:25, Martin Briza va escriure:
after fixing a bit in the $subj
Which repo is that? Are we installing that file header?
The systemd support fix is now in master
On Mon, Apr 29, 2013 at 03:48:35PM +0200, Martin Briza wrote:
On Mon, 29 Apr 2013 09:17:15 +0200, Oswald Buddenhagen o...@kde.org wrote:
note that partial works (be it regressions or just a highly asymmetrical
code structure) will not be accepted. if you don't find somebody to do
the
Le Monday 29 April 2013 15:47:40 Martin Briza a écrit :
Hi,
On Fri, 26 Apr 2013 23:30:43 +0200, Albert Astals Cid aa...@kde.org
wrote:
El Dijous, 25 d'abril de 2013, a les 15:11:25, Martin Briza va escriure:
after fixing a bit in the $subj
Which repo is that? Are we installing that
Hey guys!
On the PIM mailing list was recently a post about excessive memory consumption
in a data structure which stores multiple shared data objects
(KABC::Addressee).
Looking at it, I noticed that all the shared data objects always allocate
their private data, even if it is potentially
On 2013-04-29, Milian Wolff m...@milianw.de wrote:
I do wonder though why QString has both, a shared_empty and a shared_null
object. A single one should suffice for most objects, no?
I'm pretty sure this is because QString can be empty and not null.
e.g. the difference between QString() the
On segunda-feira, 29 de abril de 2013 21.52.37, Milian Wolff wrote:
I.e.: In the ctors that construct an empty object do not call new
Private but instead (re-)use a static shared empty object created on the
stack - see shared_empty and shared_null in qstring.{cpp,h}.
You probably did not mean
On Monday 29 April 2013 15:16:29 Thiago Macieira wrote:
On segunda-feira, 29 de abril de 2013 21.52.37, Milian Wolff wrote:
I.e.: In the ctors that construct an empty object do not call new
Private but instead (re-)use a static shared empty object created on the
stack - see shared_empty and
On terça-feira, 30 de abril de 2013 01.01.36, Milian Wolff wrote:
Interestingly I can't find a case cases don't seem to be using
QSharedDataPointer, or am I missing something?
Right. None of them use QSharedDataPointer.
You can find uses of that in these changes I uploaded during the weekend:
12 matches
Mail list logo
