> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote:
> > IMHO this is wrong.
> > Not code wise but conceptual. As far as I understand QSettings is basically
> > deprecated, it is just not official marked as such because there is no
> > replacement. This would be porting away from a fully functi
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote:
> > IMHO this is wrong.
> > Not code wise but conceptual. As far as I understand QSettings is basically
> > deprecated, it is just not official marked as such because there is no
> > replacement. This would be porting away from a fully functi
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote:
> > IMHO this is wrong.
> > Not code wise but conceptual. As far as I understand QSettings is basically
> > deprecated, it is just not official marked as such because there is no
> > replacement. This would be porting away from a fully functi
On Monday 17 December 2012 14:47:11 David Faure wrote:
> Now that all modules have a KDE/4.10 branch, kdelibs can use again the same
> workflow as the other modules: 4.10 for the 4.10.x series, and master for
> the 4.11.x series. This will create less confusion than a frozen master and
> a differen
> On Dec. 17, 2012, 10:38 p.m., Kevin Krammer wrote:
> > IMHO this is wrong.
> > Not code wise but conceptual. As far as I understand QSettings is basically
> > deprecated, it is just not official marked as such because there is no
> > replacement. This would be porting away from a fully functi
Just a quick note that the proposals deadline for the C++Now 2013
conference has been extended to January 5th:
http://cppnow.org/2013-call-for-submissions/
C++Now is the largest general C++ conference, that is, it is not specific
to any library/framework or compiler vendor. C++Now has three track
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107716/#review23658
---
Looks good (I'll try a full kde recompile with it, to see if it
On Thursday 06 December 2012 12:17:08 Diggory Hardy wrote:
> So you're suggesting that we (or someone) should somehow bring all
> implementations in line with an updated spec? How would one go about doing
> this? My aim was to make what KDE does more robust in the face of differing
> implementation
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107412/#review23680
---
According to the trojita discussion on kde-core-devel, we don't
On Thursday 13 December 2012 21:50:29 Chusslove Illich wrote:
> >> [: David Faure :]
> >> If it handles this correctly (so that tr() works at runtime), this is
> >> good news then, it sounds like we can drop the weird
> >> QCoreApp::translate("", "text") in KF5.
> >
> > [: Jan Kundrát :]
> > I can
On Tuesday, 18 December 2012 16:15:15 CEST, David Faure wrote:
It just means that l10n will have to run lconvert during make install, in
order to install .qm files (compiled from .ts files), rather
than .mo files, for
these frameworks which use tr() and not i18n().
In Trojita, the lconvert &&
> On Dec. 18, 2012, 10:59 a.m., David Faure wrote:
> > Looks good (I'll try a full kde recompile with it, to see if it breaks
> > anything).
> >
> > An addition to the kconfig_compiler unittests is missing, though, could you
> > add that?
> >
Sure makes sense and can do, I just couldn't find
On Tuesday 18 December 2012, Albert Astals Cid wrote:
> El Dilluns, 17 de desembre de 2012, a les 18:37:59, Alexander Neundorf va
>
> escriure:
> > On Sunday 16 December 2012, Antonis Tsiapaliokas wrote:
> > > Hello,
> > >
> > > > Attached, can somebody give it a try ?
> > > >
> > > > Alex
> > >
Well that is not entirely correct. We can definitely implement support for
private mode in the cookiejar itself easily. There are a couple of
approaches we can take. The difficult part has always been how to handle
the "private session" cookies in the cookie management dialogs. Anyhow, I
promised t
14 matches
Mail list logo
