translated by the usual
docbook workflow?
- Kevin Krammer
On Juli 12, 2015, 4 nachm., Scott Kitterman wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.
.
The notifications sent to the list would primarly serve as a provider of
activitiy overview and new frameworks becoming available.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally signe
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
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
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, 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, 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: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, 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, 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 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
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
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
.
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
---
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
>
> > 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
> 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.
___
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
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
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
(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
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
> 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
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 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:
>
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 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
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 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
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,
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
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.
_
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
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
---
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
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
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
/diff/
Testing
---
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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.
://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
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
.
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
---
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
: 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
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
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
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
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
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
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
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
/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
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
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
'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
.
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
> 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
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 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
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 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
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
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
threads though.
Thanks,
Kevin Krammer
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
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
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
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
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, 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
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
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
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
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
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
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
On Sunday, 2013-08-25, Valentin Rusu wrote:
> On 08/24/2013 02:32 PM, Kevin Krammer wrote:
> > On Saturday, 2013-08-24, Albert Astals Cid wrote:
> >> El Dissabte, 24 d'agost de 2013, a les 12:31:20, Valentin Rusu va
escriure:
> >>> * AFAIK, frameworks shoul
uld be put into consideration is whether the library/API
would work with any SecretService implementation or require kwalletd
specifically.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signature.asc
Description: This is a digitally sign
to use
> Sonnet::TextEditInstaller, only to drop it when QTextEdit gains the
> feature.
I think we will see things like that anyway, i.e. functionality available in
KDE Framworks becoming important enought to make it viable for Qt upstreaming.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xd
gt;
>
> I am personnaly in favor of B), but would like to hear others opinions.
I also think (B) is the cleaner approach.
Having spellchecking is a choice, the application developer has the best
knowledge about whether a text edit will be used for natural language input or
some code like
ilter to get
whatever context menu handling the text edit has configured?
- Kevin Krammer
On Aug. 6, 2013, 4:23 p.m., Aurélien Gâteau wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.revi
ttp://git.reviewboard.kde.org/r/111689/#comment27513>
if you create a QFileInfo object you can ask it for exits and use its
isAbsolute() check later on instead of assuming Unix paths in line 72
- Kevin Krammer
On Aug. 5, 2013, 11:29 p.m., Sebastian Kügler
ous choice anyway, so it shouldn't
be a problem to let the app developer use it. Making it easy to hook it up
with text input widgets would be a good feature in any case.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
signat
1 - 100 of 121 matches
Mail list logo