see above
src/platformtheme/kdeplatformsystemtrayicon.cpp
<https://git.reviewboard.kde.org/r/116075/#comment35729>
I see lambdas being using later on, in which case this looks like a
candidate for std::find_if() with a lambda predicate
- Kevin Krammer
On Feb. 26, 2014, 8:09 a.
,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
/diff/
Testing
---
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
ki18n then yes.
I checked the diagrams I was pointed at during the IRC meeting and it only had
ki18n and kjs as dependencies.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
<>
signature.asc
Description: This is a digitally signed messag
On Saturday, 2014-03-01, 15:37:05, David Faure wrote:
> On Saturday 01 March 2014 13:37:31 Kevin Krammer wrote:
> > On Saturday, 2014-03-01, 13:19:23, David Faure wrote:
> > > On Saturday 01 March 2014 12:12:37 KDE CI System wrote:
> > > > CMake Error at C
---
All previously existing tests continue to run :)
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
self-contain contribution to make sure
that as many frameworks as possible have good example programs.
Maybe even having tutorials on techbase.kde.org explaining the steps that were
necessary to create the examples.
CCing the frameworks development list.
Cheers,
Kevin
[1] https://dot.kde.or
n a new
version has been published and can be downloaded again.
Cheers,
Kevin
[1] https://leanpub.com/
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
_
Hi,
On Wednesday, 2014-03-19, 23:36:27, Harsh Kumar wrote:
> On 3/16/14, Kevin Krammer wrote:
> > One other thing that came to my mind is development of examples for
> > Frameworks
> > 5, see [1] and [2].
> >
> > Only a couple of the frameworks seem to hav
l if they're cross-platform or not. [1]
D-Bus does run on most platforms, at least on desktop.
There was a thread on the Qt development list a short while ago which
discussed enabling QtDBus by default in Windows and Mac builds.
Cheers,
Kevin
--
Kevin Krammer,
On Friday, 2014-03-28, 20:26:59, Boudewijn Rempt wrote:
> On Fri, 28 Mar 2014, Kevin Krammer wrote:
> > D-Bus does run on most platforms, at least on desktop.
> > There was a thread on the Qt development list a short while ago which
> > discussed enabling QtDBus by defau
On Friday, 2014-03-28, 20:55:02, Boudewijn Rempt wrote:
> On Fri, 28 Mar 2014, Kevin Krammer wrote:
> > The D-Bus session/user daemon is also something that needs to be treated
> > in a platform specific way as a dependency.
> > E.g. on Windows there could be a D-Bus instal
On Saturday, 2014-03-29, 01:21:24, Aleix Pol wrote:
> On Fri, Mar 28, 2014 at 9:14 PM, Kevin Krammer wrote:
> > I thought I was obvious that I was addressing the Aleix's concern about
> > portability of frameworks requiring D-Bus, but I must have failed at that.
> >
&g
only relevant for
KDE applications porting, right?
IMHO this would fit best in an explicit porting framework
src/lib/util/kdelibs4migration.cpp
<https://git.reviewboard.kde.org/r/117511/#comment38618>
initialize d to nullptr?
- Kevin Krammer
On April 12, 2014, 11:01 a.m., David
> On April 12, 2014, 11:12 a.m., Kevin Krammer wrote:
> > I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant
> > for KDE applications porting, right?
> > IMHO this would fit best in an explicit porting framework
>
> David Faure wrote:
>
> On April 12, 2014, 11:12 a.m., Kevin Krammer wrote:
> > I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant
> > for KDE applications porting, right?
> > IMHO this would fit best in an explicit porting framework
>
> David Faure wrote:
>
Do we have some logging categories for kdecoreaddons?
- Kevin Krammer
On April 22, 2014, 9:32 a.m., David Faure wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http
> On April 22, 2014, 9:50 a.m., Kevin Krammer wrote:
> > src/lib/util/kdelibs4migration.cpp, line 97
> > <https://git.reviewboard.kde.org/r/117511/diff/2/?file=267469#file267469line97>
> >
> > Also maybe just a personal taste, but I find it better to exp
gt; I don't want users to have to configure their search engines in 10 KDE apps
> one after the other by hand.
> A centralized configuration is much more convenient.
Hmm, what if KDE applications outside a KDE workspace are seen as separate
entities by users of those other workspaces?
Ch
(they didn't want them to be part of kdelibs already, so there must be
> reasons).
The libs were moved out of kdelibs at that time for different reasons, e.g.
gettting them packages separately for better dependency control.
Development follows the same policies as for kdelibs.
Cheers,
Kev
tps://git.reviewboard.kde.org/r/119895/#comment45446>
explicit
Just a general question: do we really want a porting class in core addons?
- Kevin Krammer
On Aug. 22, 2014, 9:05 vorm., Laurent Montel wrote:
>
> ---
> This is an automatica
e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119895/
> ---
>
> (Updated Aug. 22, 2014, 9:05 vorm.)
>
>
> Review request for KDE Frameworks, David Faure and Kevin Krammer.
>
>
> Repository: kcor
On Aug. 22, 2014, 9:39 vorm., Laurent Montel wrote:
> > Just a general question: do we really want a porting class in core addons?
>
> Laurent Montel wrote:
> Kdelibs4Migration is already in this addons.
> Where do you want to put it ? In which module ?
>
> Kevi
On Aug. 22, 2014, 9:39 vorm., Laurent Montel wrote:
> > Just a general question: do we really want a porting class in core addons?
>
> Laurent Montel wrote:
> Kdelibs4Migration is already in this addons.
> Where do you want to put it ? In which module ?
>
> Kevi
On Aug. 22, 2014, 9:39 vorm., Laurent Montel wrote:
> > Just a general question: do we really want a porting class in core addons?
>
> Laurent Montel wrote:
> Kdelibs4Migration is already in this addons.
> Where do you want to put it ? In which module ?
>
> Kevi
> ktnef
> kxmlrpcclient
> mailtransport
> microblog
> qgpgme
> syndication
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
___
>
> > This one looks like a dumping ground of random things. Maybe some of it
> > should move in other frameworks?
>
> Sergio can speak about it
>
> > > kholidays
> > > kimap
> > > kioslave
> >
> > Definitely not a framework. Are all
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119895/#review65352
---
Ship it!
Ship It!
- Kevin Krammer
On Aug. 22, 2014, 10:55
.
Some of the widgets are things like type data editors, which could be
separated such that all editing logic and data handling can be used in a C++
or QML context.
If the QML driven technology is not QtWidgets, then forcing a dependency might
not be appreciated.
Cheers,
Kevin
--
Kevin Kra
stuff, it would be good to bring it up-to-date and work
> through it progressively.
>
> We also have Akademy and the sprint scheduled for November (?) at
> which we could sit down and methodically work through the list of
> everything and figure out what to do.
I agree, it makes l
ke sure that hicolor is actually a proper
fallback as specified?
Applications already are more or less required to install their fallbacks in
hicolor, so the shared icons should be there as well, no?
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer men
On Wednesday, 2014-09-10, 23:43:15, Albert Astals Cid wrote:
> El Dimarts, 9 de setembre de 2014, a les 16:25:26, Kevin Krammer va
escriure:
> > On Sunday, 2014-09-07, 10:27:06, Albert Astals Cid wrote:
> > > So as I see it, there's three options:
> > > * Do noth
On Thursday, 2014-09-11, 09:33:23, Albert Astals Cid wrote:
> El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va
escriure:
> > The rule to always also install an application icon into Hicolor was meant
> > as an example of a general intent that Hicolor
On Thursday, 2014-09-11, 02:06:02, Albert Astals Cid wrote:
> El Dijous, 11 de setembre de 2014, a les 10:57:17, Kevin Krammer va
escriure:
> > On Thursday, 2014-09-11, 09:33:23, Albert Astals Cid wrote:
> > > El Dijous, 11 de setembre de 2014, a les 08:46:11, Kevin Krammer va
On Thursday, 2014-09-11, 15:29:13, Eike Hein wrote:
> On 11.09.2014 11:11, Kevin Krammer wrote:
> > From my point of view there is little use case of having a fallback if it
> > does>
> > not allow one to fall back to it.
>
> Check out the chat log for the idea
On Thursday, 2014-09-11, 15:40:14, Eike Hein wrote:
> On 11.09.2014 15:33, Kevin Krammer wrote:
> > Sounds interesting, but "checkout" where?
>
> In this thread, where I've posted it and encouraged reading
> it a few times :).
Ah :)
I thought you were referring
On Thursday, 2014-09-11, 15:53:57, Eike Hein wrote:
> On 11.09.2014 15:43, Kevin Krammer wrote:
> > Having a configurable fallback before the final fallback can't hurt, but
> > that doesn't solve the actual problem of hicolor being incomplete.
> > It is just a work
On Thursday, 2014-09-11, 17:05:43, Eike Hein wrote:
> On 11.09.2014 16:09, Kevin Krammer wrote:
> > Why would hicolor be distro/ISV specific?
>
> Because a hicolor theme everyone likes visually isn't going
> to happen. People will want to modify what's in that fall
On Thursday, 2014-09-11, 17:56:38, Eike Hein wrote:
> On 11.09.2014 17:22, Kevin Krammer wrote:
> > Hicolor is there for cases where the setup fails to provide any workspace
> > or distribution specific theme.
>
> Yes. So I'm thinking ahead and telling you how that
w.
Cheers,
Kevin
[1] https://gerrit.vesnicky.cesnet.cz/
[2] https://conf.kde.org/en/Akademy2014/public/events/140
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed me
inus the initialization) contained in one testcase method. Otherwise i
> would have to make signal/slot connections to member functions which is
> probably not something you want for testcases..
Wouldn't it also be possible to use QSignalSpy?
Cheers,
Kevin
--
Kevin Krammer, KDE devel
bs are candidates for becoming frameworks.
We had a discussion about that at the last sprint, but I seem to be unable to
find the discussion's notes.
>From what I remember I think that the frameworks branch is pretty up to date.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils develop
ty.
>
> The fix is probably just a matter of introducing a "void
> percentChanged(int)" signal, and emitting it wherever percent() is emitted.
No need, the percent property is not using the MEMBER option of the Q_PROPERY
macro, it is using the classic READ foll
Hi all,
you are probably not subscribed to kde-devel so you might have missed that
one:
http://lists.kde.org/?l=kde-devel&m=139021750622083&w=2
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: T
be viable.
I have to admit I totally lost the overview over the state of transition to
secret service, so that might be another unrelated framework.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer ment
is not reliably working across lists is reply in private
mail. For that to work repliably I've fallen back to using the mouse and
right-clicking the right address. Pretty annoying but some mailinglists seem
to have broken setups.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils
On Wednesday, 2014-01-29, 11:43:37, Martin Klapetek wrote:
> On Wed, Jan 29, 2014 at 11:23 AM, Kevin Krammer wrote:
> > I am subscribed to more than two dozend KDE mailinglist (and numerous
> > others).
> > I post to some of the regularily while some others only sporadica
s.
If you meant QtQuick, I agree :)
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
K
On Wednesday, 2014-01-29, 12:30:55, Martin Gräßlin wrote:
> On Wednesday 29 January 2014 11:23:31 Kevin Krammer wrote:
> > I am subscribed to more than two dozend KDE mailinglist (and numerous
> > others). I post to some of the regularily while some others only
> > sporadical
Which has a different problem since this sends mails to the other person
twice. Once directly and once through the list. IMHO it really sucks when that
happens, polluting *my* inbox when replying to my mails on a list.
Make sure you always remove the sender after you've hit reply-all for a lis
ast, want: I
> get the message in my inbox, but it doesn't have the headers that cause
> it to be filtered to the correct mailing list folder.
Exactly!
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Descriptio
threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
tell I did not change anything related to threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
ed test cases :)
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115485/#review49036
---
On Feb. 5, 2014, 4:08
> On Feb. 5, 2014, 3:51 p.m., Aurélien Gâteau wrote:
> > Wow, great work! I attempted doing this some time ago, and all I managed to
> > produce was two unit tests :). Looks good to me and works fine here. Just
> > two (really minor) nitpicks.
>
> Kevin
INUX)
return QL1S("Linux")
#else
return QL1S("Unix")
#endif
#elfi defined(Q_OS_WINDOWS)
return QL1S("Windows")
#else
return QL1S("Unknown")
#endif
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE use
On Friday, 2014-02-07, 09:51:27, Martin Gräßlin wrote:
> On Friday 07 February 2014 09:38:41 Kevin Krammer wrote:
> > On Friday, 2014-02-07, 08:53:54, Martin Gräßlin wrote:
> > > I'm wondering what to do about it. The best would be to use
> > > QGuiApplication::p
scripting requirements.
There is also a weird crash at test shutdown, in QThreadStorage. As far as I
can tell I did not change anything related to threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel
> On Feb. 5, 2014, 3:51 p.m., Aurélien Gâteau wrote:
> > Wow, great work! I attempted doing this some time ago, and all I managed to
> > produce was two unit tests :). Looks good to me and works fine here. Just
> > two (really minor) nitpicks.
>
> Kevin
crash at test shutdown, in QThreadStorage. As far as I
can tell I did not change anything related to threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde
w)?
good catch, thanks
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115485/#review49941
---
On Feb. 16, 201
ted e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115485/#review50376
---
On Feb. 16, 2014, 6:54 p.m., Kevin Krammer wrote:
>
> ---
> This is an automatically gen
7;t be
interleaved, but there always needs to be a thread that runs the event loop
for receiving and it is probably also the one that gets all replies and
incoming calls.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
ingList on fields that
are expected to be strings, but of course that is not always the same as the
original string.
If we want to be able to parse .desktop files without KConfig, we need a
desktop file parser.
The Razor-Qt and LxQt people might have one already.
Cheers,
Kevin
--
Kevin Krammer, KD
anscript.cpp c922e91
src/ktranscript_p.h f1cc132
Diff: https://git.reviewboard.kde.org/r/115936/diff/
Testing
---
All three tests run without failure
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
st.cpp PRE-CREATION
autotests/ktranscripttest.h 53f3ce0
autotests/ktranscripttest.cpp 78aecb4
src/ktranscript.cpp c922e91
src/ktranscript_p.h f1cc132
Diff: https://git.reviewboard.kde.org/r/115936/diff/
Testing
---
All three tests run without failure
Thanks,
Kev
test shutdown, in QThreadStorage. As far as I
can tell I did not change anything related to threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks
autotests/ktranscripttest.cpp 78aecb4
src/ktranscript.cpp c922e91
src/ktranscript_p.h f1cc132
Diff: https://git.reviewboard.kde.org/r/115936/diff/
Testing
---
All three tests run without failure
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailin
r the impression that translations always require the presence of a
QCoreApplication (or derived) instance. Qt's own tr() does.
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115485/
15936/diff/
Testing
---
All three tests run without failure
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
also a weird crash at test shutdown, in QThreadStorage. As far as I
can tell I did not change anything related to threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman
requirements.
There is also a weird crash at test shutdown, in QThreadStorage. As far as I
can tell I did not change anything related to threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https
.
There is also a weird crash at test shutdown, in QThreadStorage. As far as I
can tell I did not change anything related to threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org
't think I have a preference between the two. One breaks encapsulation
> badly, the other one carries the risk of API explosion later on (if we want
> to provide more control than just hiding).
My initial thought was to suggest doing the same as in the Qt4 version, i.e.
having a butto
On Sunday, 2014-02-23, 18:41:38, David Faure wrote:
> On Sunday 23 February 2014 14:17:29 Kevin Krammer wrote:
> > But usage of the button box already leaks, there are two protected
> > accessors to it.
>
> In which class? You lost me.
KPageDialog, base class of KConfigDi
there is an
accessor in QGuiApplication that returns a pointer to it.
Obviously the returned object and its functionality is platform specific, but
afterall its very purpose is to enable platform integration that goes beyond
the things that can be wrapped in an abstraction across multiple platform
/115979/diff/
Testing
---
Everything still builds and tests succeed.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
ki18n.yaml 9b601d5
src/ktranscript.cpp 4cdae75
Diff: https://git.reviewboard.kde.org/r/115979/diff/
Testing
---
Everything still builds and tests succeed.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel
https://git.reviewboard.kde.org/r/115983/diff/
Testing
---
All tests still run successfully
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
object is never
deleted during runtime.
So this just cleans up before process exit
- Kevin Krammer
On Feb. 23, 2014, 9:52 p.m., Kevin Krammer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit
object is never
deleted during runtime.
So this just cleans up before process exit
- Kevin Krammer
On Feb. 23, 2014, 9:52 p.m., Kevin Krammer wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit
11788== suppressed: 0 bytes in 0 blocks
Diffs
-
src/ktranscript.cpp 1ce0d1a
Diff: https://git.reviewboard.kde.org/r/115983/diff/
Testing
---
All tests still run successfully
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing lis
Both good catches. All in now
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115485/#review50535
---
On Feb. 2
f: https://git.reviewboard.kde.org/r/116030/diff/
Testing
---
All previously existing tests continue to run :)
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
de.org/r/116030/diff/
Testing
---
All previously existing tests continue to run :)
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
: kjsembed
Description
---
ki18n changed from tier 2 to tier 1.
kjsembed only depends on tier 1 now, becomes tier 2
Diffs
-
kjsembed.yaml 78c0a75
Diff: https://git.reviewboard.kde.org/r/116049/diff/
Testing
---
Thanks,
Kevin Krammer
---
ki18n changed from tier 2 to tier 1.
kpty only depends on tier 1 now, becomes tier 2
Diffs
-
kpty.yaml 78c0a75
Diff: https://git.reviewboard.kde.org/r/116050/diff/
Testing
---
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing
.
Repository: kunitconversion
Description
---
ki18n changed from tier 2 to tier 1.
kunitconversion only depends on tier 1 now, becomes tier 2
Diffs
-
kunitconversion.yaml 78c0a75
Diff: https://git.reviewboard.kde.org/r/116051/diff/
Testing
---
Thanks,
Kevin Krammer
2
Diffs
-
kjsembed.yaml 78c0a75
Diff: https://git.reviewboard.kde.org/r/116049/diff/
Testing
---
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde
://git.reviewboard.kde.org/r/116051/diff/
Testing
---
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
$XDG_CONFIG_DIRS.
> However, in this case it seems to be a simple set of user settings, not
> much point in system-wide settings for such things, so a plain text file
> would do, so QSettings will do too.
> So, OK for this one, but I really don't want to see all of KF5 ported to
ought to be done by either having an interface that can be implemented through
KConfig or by passing values as QVariant maps or hashes.
- Kevin Krammer
On Dec. 17, 2012, 9:15 p.m., Martin Tobias Holmedahl Sandsmark wrote:
>
> ---
>
> 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 b
> 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 b
cation to read from KConfig instead
- Kevin Krammer
On Dec. 27, 2012, 12:52 a.m., Martin Tobias Holmedahl Sandsmark wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visi
> On Dec. 27, 2012, 10:33 a.m., Kevin Krammer wrote:
> > I am a bit puzzled by the usage of QSettings for file I/O.
> >
> > My, rather limited, understanding of QSettings in Qt5 context is that is
> > mostly the same as in Qt4 and Qt4's version is AFA
On Thursday, 2012-12-27, Martin Tobias Holmedahl Sandsmark wrote:
> On Thu, Dec 27, 2012 at 12:18:21PM -0000, Kevin Krammer wrote:
> > Two levels are most likley the most common case because most systems do
> > not have any system administrator. Once you have admin customization
have i18n
functions that are not i18nc variants (i.e. require a comment)?
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
___
IMHO something like qpath sounds better. I don't think there is a lot of usage
of those special paths and even if there is any script would have to be
updated to the new executable name anyway.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, dev
1 - 100 of 121 matches
Mail list logo
