On 05/03/2022 18:16, Ben Cooksley wrote:
On Sun, Mar 6, 2022 at 6:00 AM Stephen Kelly wrote:
On 26/02/2022 10:38, Volker Krause wrote:
> On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote:
>> Hello,
>>
>> The Qt 5 based Grantlee librarie
On 26/02/2022 10:38, Volker Krause wrote:
On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote:
Hello,
The Qt 5 based Grantlee libraries were depended on by some KDE applications.
For Qt 6, I've created a separate repo for KTextTemplate for one of the
Grantlee libraries. The
Hello,
The Qt 5 based Grantlee libraries were depended on by some KDE applications.
For Qt 6, I've created a separate repo for KTextTemplate for one of the
Grantlee libraries. The other library is separate and can be dealt with
separately.
Currently the code lives here:
https://github.com
On 30/12/2019 10:55, Christoph Cullmann wrote:
Hi,
With my KTextEditor hat on: KF6:TextDocument implies somehow a link
to QTextDocument or KF6:TextEditor, which both is incorrect, right?
QTextDocument is exactly what it's about, which makes the name
KF6::TextDocument fully appropriate and c
On 30/12/2019 08:55, Dominik Haumann wrote:
Hi,
Stephen Kelly mailto:steve...@gmail.com>> schrieb
am So., 29. Dez. 2019, 15:03:
On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote:
> Why are you proposing to do a step back instead to the old
state, which
&
On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote:
Why are you proposing to do a step back instead to the old state, which
everyone including you considered not that satisfying?
Because it's a temporary situation. We still have a way forward in KF6
(which will open in a few months).
Gen
On 22/12/2019 16:08, Stephen Kelly wrote:
On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
Perhaps joining the "Release Service" (formerly known as "KDE
Applications")
is a better place then, it also contains a set of libraries already.
That would serve the purpos
On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote:
Perhaps joining the "Release Service" (formerly known as "KDE Applications")
is a better place then, it also contains a set of libraries already.
That would serve the purpose of having releases happening regularly.
The goals of making Gran
On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote:
Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
I've pushed a few commits to make it depend on ECM etc.
Once the review period is finished it c
On 21/12/2019 21:33, Volker Krause wrote:
* Attracting external components and having them opt to move under the
Frameworks umbrella is a sign that we are doing things right IMHO. So let's
make this easy for people and avoid scaring off their users by forcing a
larger migration on them when joi
On 08/12/2019 10:12, laurent Montel wrote:
Le dimanche 8 décembre 2019, 10:52:19 CET Volker Krause a écrit :
Hi,
very happy to see Grantlee "coming home" :)
Technically I think it's largely in line with Frameworks requirements
already, and it has been reliably powering e.g. KMail's message v
Hello,
I have been developing Grantlee for over 10 years with contributions
from a community of others mostly connected with KDE.
https://github.com/steveire/grantlee
I have not been able to maintain a reasonable release cadence of
Grantlee in the last few years (last release 3 years ago)
Albert Astals Cid wrote:
> El divendres, 8 d’abril de 2016, a les 0:29:57 CEST, Stephen Kelly va
> escriure:
>> Albert Astals Cid wrote:
>> > So my suggestion would be renaming pykde5.git to pykf5.git, and that
>> > means *only* KDE Frameworks 5 bindings would go
Albert Astals Cid wrote:
> So my suggestion would be renaming pykde5.git to pykf5.git, and that means
> *only* KDE Frameworks 5 bindings would go in there, any other repo that
> wants to provide python bindings (say okular, marble or krita) should do
> somewhere else, ideally their own repo so the
Dominik Haumann wrote:
> I still see QStringLiteral fixes from time to time on the commit
> mailing list. Given MSVC 2015 Community Edition is available
> just like v2013, and it seems to work I believe that committing
> such fixes does not make sense, in fact, it often makes code
> worse.
If the
> On Aug. 19, 2015, 6:06 p.m., Stephen Kelly wrote:
> > This patch is not correct.
> >
> > What repo were you trying to build? Add cmake_minimum_required(VERSION
> > 2.8.9) there.
>
> Stephen Kelly wrote:
> Why did this review go quiet? Did you pull
> On Aug. 19, 2015, 6:06 p.m., Stephen Kelly wrote:
> > This patch is not correct.
> >
> > What repo were you trying to build? Add cmake_minimum_required(VERSION
> > 2.8.9) there.
Why did this review go quiet? Did you pull and realize that line was already
th
> On Aug. 19, 2015, 6:03 p.m., Jeremy Whiting wrote:
> > Ship It!
Don't ship it :).
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124824/#review84061
build? Add cmake_minimum_required(VERSION 2.8.9)
there.
- Stephen Kelly
On Aug. 19, 2015, 5:41 p.m., René J.V. Bertin wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.
Lisandro Damián Nicanor Pérez Meyer wrote:
>> Fair enough. One of them starts in [0], but there was another thread in
>> which even Lars participated. So far I haven't been able to find it, I'll
>> keep trying.
>>
> Found the other one!
FYI, if you provide a gmane link, you provide the whole thr
28/03/15 03:48, Alex Merry wrote:
>> On Wednesday 25 March 2015 22:35:24 Stephen Kelly wrote:
>>> Hello,
>>>
>>> ECM release numbers are in sync with KF5 release numbers, except for the
>>> major component.
>>>
>>> This means that if you
On 03/16/2015 05:28 PM, Ivan Čukić wrote:
> From www.gitorious.org
>> System notice: Gitorious is being acquired by GitLab and
>> gitorious.org will shut down end of May. Please import your
>> repositories to
> We still have a few projects on there. One notable being Grantlee (at
> least, my kdesrc
On 03/16/2015 05:28 PM, Ivan Čukić wrote:
> From www.gitorious.org
>> System notice: Gitorious is being acquired by GitLab and
>> gitorious.org will shut down end of May. Please import your
>> repositories to
> We still have a few projects on there. One notable being Grantlee (at
> least, my kdesrc
On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote:
> I am also not sure yet, if
> a cross-moc is required or whether a native moc binary can be re-used.
> It's one of the open questions that I still have, and need to
> investigate the actual code generator / code generated.
Even if the code genera
On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote:
>> > 2) Why does the package creation result in broken cmake files generated
>> > from the Qt tarball?
> The package creation does not result in broken cmake files generated
> from the Qt tarball.
Great.
> It's just there is no clean way to over
Harald Sitter wrote:
> xnox was nice enough to look into this in detail and identified the
> problem as having a much smaller scope than I had originally thought.
1) What is the problem?
2) Why does the package creation result in broken cmake files generated from
the Qt tarball?
Thanks,
Stev
Alexander Neundorf wrote:
> Hi,
>
> for very happy personal reasons (since Tuesday, named David :-) )
Awesome, congratulations!
Steve.
tier2/kjobwidgets/src/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113503/#comment30904>
Indent.
- Stephen Kelly
On Oct. 30, 2013, 10:08 a.m., Sune Vuorela wrote:
>
> ---
> This is an automatically generated e-mail.
Git commit 804d35394c3667ae4e9fe20321b6365cd8467e7d by Stephen Kelly.
Committed on 18/10/2013 at 15:33.
Pushed by skelly into branch 'KDE/4.11'.
Only create and install man pages if using CMake < 3.0
CMake documentation changes in CMake 3.0.0 such that running
cmake --help-cust
> On Oct. 7, 2013, 9:35 a.m., Stephen Kelly wrote:
> > src/plasma/CMakeLists.txt, line 173
> > <http://git.reviewboard.kde.org/r/113139/diff/1/?file=199605#file199605line173>
> >
> > The if-else shouldn't be needed. INSTALL_INTERFACE should already c
ul as it seems camelcase headers are
> installed by KF5::plasma into include/KDE/Plasma/
Odd. I tried to add this dir, but seem to have hit a bug I'll look into. Patch
looks good for now I think, thanks!
- Stephen Kelly
On Oct. 7, 2013, 8:13 a.m., Be
/plasma/CMakeLists.txt
<http://git.reviewboard.kde.org/r/113139/#comment30269>
The if-else shouldn't be needed. INSTALL_INTERFACE should already check if
${INCLUDE_INSTALL_DIR} is absolute.
- Stephen Kelly
On Oct. 7, 2013, 8:13 a.m., Ben Coo
Sebastian Kügler wrote:
> We're planning to merge the frameworks-scratch branch of kde-workspace
> into master next Monday.
I tried building the branch. It requires qimageblitz, which I didn't see a
Qt 5 version for, and soprano which has a non-building qt5_port branch.
Do you have local workin
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112756/#review40705
---
Ship it!
Ship It!
- Stephen Kelly
On Sept. 16, 2013, 1:56
Alexander Neundorf wrote:
> It looks like it is related to using imported targets in try_compile():
>
> -- Enabling c++0x support for unordered map
> CMake Error at cmTryCompileExec236800853Targets.cmake:96 (add_library):
> add_library cannot create imported target "Qt4::QtGui" because another
>
Aurélien Gâteau wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111953/
> ---
>
> (Updated Aug. 14, 2013, 7:30 a.m.)
>
>
> Review reque
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111953/#review37748
---
Ship it!
Ship It!
- Stephen Kelly
On Aug. 14, 2013, 7:30
of them use this
class.
kdeui/itemviews/klinkitemselectionmodel.cpp
<http://git.reviewboard.kde.org/r/111953/#comment27688>
Excess whitespace.
- Stephen Kelly
On Aug. 8, 2013, 8:15 p.m., Aurélien Gâteau wrote:
>
> ---
Kevin Ottens wrote:
>> So, if this target/variable task is deferred until CMake 2.8.13 can be
>> used, the variables don't have to be used even in an intermediate state.
>
> I see, but when is 2.8.13 supposed to be released? I'd rather have us move
> forward.
2.8.12 will be released in a few wee
Kevin Ottens wrote:
> Once the splitting will be done I'm not so sure it's better than using
> directly the namespaced target names. The reason being that variables are
> really a pain with cmake... I mean if you mistakenly use a variable name
> which doesn't exist it's just expanded to nothing. Ta
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/58/#review34939
---
Ship it!
Ship It!
- Stephen Kelly
On June 21, 2013, 10:45
David Faure wrote:
> On Monday 20 May 2013 11:53:18 Alexander Neundorf wrote:
>> there was a review request for a find-module for libusb1 here a few days
>> ago, which we have already in e-c-m, but he can't use it because it is
>> not released
>
> Could we maybe release a first version of ECM wi
Stephen Kelly wrote:
> Ben Cooksley wrote:
>
>> Hi Alex,
>>
>> Can someone more familiar with the CMake community please inform them
>> of this regression?
>
>
>
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46742/focus=46776
I have
Ben Cooksley wrote:
> Hi Alex,
>
> Can someone more familiar with the CMake community please inform them
> of this regression?
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/46742/focus=46776
Alexander Neundorf wrote:
> there was a review request for a find-module for libusb1 here a few days
> ago, which we have already in e-c-m, but he can't use it because it is not
> released
Then it should probably be put into kdelibs/cmake for KDE4?
> On the cmake list somebody was asking for a c
Alexander Neundorf wrote:
> On Thursday 16 May 2013, Stephen Kelly wrote:
>> Kevin Ottens wrote:
>> >> Beside that, I would like if we could do a release of
>> >> extra-cmake-modules as soon as possible, so other projects, KDE and
>> >> non-KDE can st
3 not python2)
> >
> > However all this discussion isn't related to Arch itself: I think that
> > binaries with specific version takes precedence, don't they?
>
> Stephen Kelly wrote:
> No, you also need to account for self-built Qt, which will also r
> On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote:
> > "I was quite clear: "qmake" must point by default to Qt 4 if Qt 4 present."
> > While qtchooser sounds like a great solution to handle this, it only adds
> > more confusion from a packager view: we cannot have N differents
> > configura
Sebastian Kügler wrote:
>> What do you need it for, exactly?
>
> To find out where Qt will look for QtQuick2 imports (that's
> $ARCHDATADIR/qml, defaulting to $PREFIX/qml, which leads to /usr/qml).
>
> I'd like to be able to install Plasma QtQuick2 imports into a path where
> they'll actually be
Sebastian Kügler wrote:
> On Sunday, February 10, 2013 14:33:49 Thiago Macieira wrote:
>> On domingo, 10 de fevereiro de 2013 21.22.05, Sebastian Kügler wrote:
>> > Apparently not. I've looked at where the example imports from the Qt
>> > codebase install these things, and that is indeed $PREFIX/q
Thiago Macieira wrote:
> On sábado, 29 de dezembro de 2012 22.58.49, Kevin Ottens wrote:
>> On Saturday 29 December 2012 11:06:30 David Faure wrote:
>> > Well, for frameworks that intend to be "as close to Qt as possible"
>> > they should do the same (for the convenience of developers who don't
>>
Kevin Ottens wrote:
> We should push to use the class name only includes I think.
I agree.
We have a buildsystem that is good enough that we can specify the
directories to look for the 'class name' headers in, and it is in the
buildsystem that that stuff belongs.
See the kinds of practical
Christoph Feck wrote:
> On Sunday 11 November 2012 12:00:05 Pino Toscano wrote:
>> Hi,
>>
>> somehow the master branch of kde-workspace has been merged in the
>> KDE/4.9 branch, with obvious consequences.
>> Can anyone please fix this mess?
>>
>> Thanks,
>
> Uh oh, I think I did "git reset orig
Christoph Feck wrote:
> Hi,
>
> my git foo is limited, but if I interpret http://ompldr.org/vZzZxaw
> correctly, then somehow master got merged into KDE/4.9 branch,
> meaning, for example, that Alex's commits to depend on cmake 2.8.8 are
> now in KDE/4.9 branch.
>
> I suggest to not to commit to
Alexander Neundorf wrote:
> On Monday 01 October 2012, David Faure wrote:
>> On Monday 01 October 2012 09:53:22 Stephen Kelly wrote:
>> > Instead, I say we should do a 'pain free' update to 2.8.7 now, and an
>> > update to 2.8.11 later.
>>
>> Yes
Alexander Neundorf wrote:
> On Monday 01 October 2012, David Faure wrote:
>> On Monday 01 October 2012 09:53:22 Stephen Kelly wrote:
>> > Instead, I say we should do a 'pain free' update to 2.8.7 now, and an
>> > update to 2.8.11 later.
>>
>> Yes
David Faure wrote:
> If we (=someone) make a frameworks branch for kactivities, it should be
> quite simple to port that away from kdecore (I suppose it was mostly using
> KPluginLoader, which has now moved to the kservice framework). So this
> might just be a matter of updating a few CMakeLists.t
--- Forwarded message (begin)
Subject: Digia acquisition closed
From: Knoll Lars
Date: Tue, 18 Sep 2012 11:19:42 +
Newsgroup: gmane.comp.lib.qt.devel
Hi everybody,
I wanted to let you all know that the acquisition of Qt by Digia has been
completed yesterday. Many Trolls in Osl
Hi there,
I learned recently that central parts of KDE Platform 4 are depending on
C++11 features:
http://ivan.fomentgroup.org/blog/2012/08/02/module-giveaway-sessions-and-
activities-updated/
Using C++11 features in central parts of KDE Platform 4 effectively means
that a C++11 compiler is n
cmake generate
export header stuff in frameworks and use the new macro in the copy. The copy
can be removed when we depend on a later version of CMake.
- Stephen Kelly
On July 5, 2012, 1:09 p.m., Patrick Spendrin wrote:
>
> ---
>
Alexander Neundorf wrote:
> Ah, right.
> Can you put a copy of FindLibLZMA.cmake into tier1/karchive/cmake/ ?
> (it will be in cmake 2.8.9)
> Then we don't need the CMAKE_MODULE_PATH from kdelibs anymore, and
> karchive is more standalone.
>
Or we can bump the dependency to 2.8.9 when the RC 1 co
Dirk Mueller wrote:
> On Tuesday 05 June 2012, Albert Astals Cid wrote:
>
>> On May 19, Dawit Alemayehu commited a change that uses
>> QSslConfiguration::testSslOption that is only available in Qt 4.8
>>
>> This means that both kdelibs 4.8.4 and kdelibs 4.9 now depend in Qt 4.8
>> instead Qt 4.7
Dominik Haumann wrote:
> On Friday, 25. May 2012 21:42:50 Stephen Kelly wrote:
>> Christoph Cullmann wrote:
>> > Still, a fix for QtScript would be the nicest solution or a port to the
>> > "new" engine provided in Qt5, as I understood, there QtScript is anyw
Christoph Cullmann wrote:
>> On Friday, May 25, 2012 11:14:17 Dominik Haumann wrote:
>> > So it's probably non-trivial to create this patch (haven't looked
>> > into
>> > it, though), a dead end as it's Qt4, and unclear, whether such a
>> > patch
>> > would be accepted at all in the Qt 4.x line, g
Sebastian Trüg wrote:
> On 05/16/2012 08:23 PM, Vishesh Handa wrote:
>> What about kdelibs/nepomuk/utils/* and the other ui stuff?
>>
>> Or since those are just APIs they can wait.
>
> I say let's postpone them, they are still in kdelibs.
>
Just so there's no surprises later: all nepomuk stuff
Alexander Neundorf wrote:
> It would be just *great* if you could put this on techbase.kde.org :-)
I'd suggest you just copy it into wherever you would look for it. Mostly
it's not kde specific anyway. It's just about knowing how to use git.
Thanks,
Steve.
> On May 2, 2012, 11:43 a.m., Stephen Kelly wrote:
> > Please do not submit this. It is out of date. You are probably using
> > qt5.git which is way out of date. This is not needed anymore.
>
> Alexander Richardson wrote:
> Ok. How do I get a Qt 5 with which I can
using qt5.git
which is way out of date. This is not needed anymore.
- Stephen Kelly
On May 1, 2012, 11:28 p.m., Alexander Richardson wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visi
Alexander Neundorf wrote:
> On Sunday 29 April 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > git is a powerful tool, and you can use it in many different ways. It
>> > needs to be easy to find out how git is intended to be used in KDE. I
>> > do
Alexander Neundorf wrote:
> git is a powerful tool, and you can use it in many different ways. It
> needs to be easy to find out how git is intended to be used in KDE. I
> don't know where this is documented. I expect this on techbase.
It is indeed not on techbase as far as I can see too.
Do you
Hugo Pereira Da Costa wrote:
> On 04/19/2012 11:27 AM, Stephen Kelly wrote:
>>>>> Would it be possible to remove the use of KColorScheme from these
>>>>> widgets in general?
> In my oppinion, yes.
Good enough for me, thanks :)
Hi, can anyone who knows about styles/KColorScheme comment on this?
Thanks,
Stephen Kelly wrote:
> Kevin Ottens wrote:
>> On Wednesday 11 April 2012 23:34:18 Stephen Kelly wrote:
>>> [...]
>>> At the center of the questions of what to do with KUrlLabel and
>>&
Kevin Krammer wrote:
> On Friday, 2012-04-06, Stephen Kelly wrote:
>> Eike Hein wrote:
>> > On 04/06/2012 01:08 PM, Richard Moore wrote:
>> >> It's for things like a browser's back button where a click moves you
>> >> back, wher
Hi there,
I'm trying to figure out why KPushButton has a feature of a 'delayed' menu.
Why would applications need that? What problems does it solve? Can the
problem be solved in Qt?
Thanks,
Steve.
Dario Freddi wrote:
> gitk indeed has a screwy visualization in there.
You conclusion that the tool is screwy is interesting for a few reasons.
Maybe some day you'll reconsider it.
>> More importantly though, you seem to have broken the frameworks branch.
>
> True, sorry about that. This is fix
Now I'm confused.
>> Stephen Kelly wrote:
>> It was rebased onto some relatively recent commit, but not the tip of
>> the branch.
You disagreed with what I said:
> - Given that the branch was rebased on top of the last frameworks' commit
> On March 30, 2012, 1:14 p.m., Dario Freddi wrote:
> > April is upon us. If no objections arise in the time being, these changes
> > will be merged on Sunday, after which I'll ask Kevin to move KAuth back to
> > tier2/ for prime time.
>
> Stephen Kelly wro
> On March 30, 2012, 1:14 p.m., Dario Freddi wrote:
> > April is upon us. If no objections arise in the time being, these changes
> > will be merged on Sunday, after which I'll ask Kevin to move KAuth back to
> > tier2/ for prime time.
>
> Stephen Kelly wro
> On March 30, 2012, 1:14 p.m., Dario Freddi wrote:
> > April is upon us. If no objections arise in the time being, these changes
> > will be merged on Sunday, after which I'll ask Kevin to move KAuth back to
> > tier2/ for prime time.
>
> Stephen Kelly wro
> On March 30, 2012, 1:14 p.m., Dario Freddi wrote:
> > April is upon us. If no objections arise in the time being, these changes
> > will be merged on Sunday, after which I'll ask Kevin to move KAuth back to
> > tier2/ for prime time.
Thanks for making this happen! :)
Instead of merging, ple
> On March 21, 2012, 8:54 p.m., Alexander Neundorf wrote:
> > I did not yet have time to look through the git branch...
> >
> > So, kauth, we have a bunch of cmake macros related to this in
> > kdelibs/cmake/KDE4Macros.cmake, right ?
> > What about them ?
They are already in ${CMAKE_SOURCE_DIR
> On March 18, 2012, 11:04 p.m., Stephen Kelly wrote:
> > Nice, thanks and sorry for the noise, and thanks for making the branch.
>
> Dario Freddi wrote:
> Np, hope you'll be able to have a quick look at it as well, it would be
> great :)
>
> Stephen Ke
> On March 18, 2012, 11:04 p.m., Stephen Kelly wrote:
> > Nice, thanks and sorry for the noise, and thanks for making the branch.
>
> Dario Freddi wrote:
> Np, hope you'll be able to have a quick look at it as well, it would be
> great :)
Mostly it looks fine.
the branch.
- Stephen Kelly
On March 18, 2012, 10:25 p.m., Dario Freddi wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.
ou investigate how much the removed API is used?
- Stephen Kelly
On March 18, 2012, 10:25 p.m., Dario Freddi wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://gi
Ben Cooksley wrote:
> On Feb 20, 2012 7:12 AM, "Stephen Kelly" wrote:
>>
>> Dario Freddi wrote:
>>
>> > 2012/2/19 Stephen Kelly :
>> >> Stephen Kelly wrote:
>> >>
>> >>>
>> >>> Hi there,
>> >&g
Laszlo Papp wrote:
>> Is there already something like that ?
>
> There is already something here:
>
http://community.kde.org/Frameworks/Git_Workflow#Local_branches_are_always_rebased.2C_remote_branches_never
>
> Might be a good idea to extend it with "git config
> branch.autosetuprebase always"
Dario Freddi wrote:
> 2012/2/19 Stephen Kelly :
>> Stephen Kelly wrote:
>>
>>>
>>> Hi there,
>>>
>>> I was reviewing the changes in the frameworks branch from yesterday.
>>> Something I noticed was that there are a lot of merge commi
Stephen Kelly wrote:
>
> Hi there,
>
> I was reviewing the changes in the frameworks branch from yesterday.
> Something I noticed was that there are a lot of merge commits that don't
> need to exist.
Ugh. Yet more of this just appeared... Recent history in the frameworks
Matt Williams wrote:
>> * Use gitk --all to see what would happen if you push. You should never
>> have to create merge commits. If you do, then please clean it up before
>> pushing.
>
> Yes, I realised after the fact that I had created one of these so
> sorry about that. I've already now switched
Hi there,
I was reviewing the changes in the frameworks branch from yesterday.
Something I noticed was that there are a lot of merge commits that don't
need to exist.
Please use `gitk` to see them.
The unneeded merge commits actually make it harder to follow frameworks for
me. It breaks thin
Thiago Macieira wrote:
> On Monday, 23 de January de 2012 09.58.46, Stephen Kelly wrote:
>> If it does belong to the garbage bin, we should consider getting some
>> stuff into the existing class - making toLower() built into the scheme()
>> etc.
>>
>> Do yo
Thiago Macieira wrote:
> On Saturday, 21 de January de 2012 16.17.38, Stephen Kelly wrote:
>> * Thiagos stuff - I don't know.
>
> Thiago's stuff is:
>
> - new atomics (wasn't a KDE request): done, just waiting for integration
> because of stupid stuff
Thiago Macieira wrote:
> On Sunday, 22 de January de 2012 12.08.57, Stephen Kelly wrote:
>> Valentin Rusu wrote:
>> > Stephen Kelly wrote:
>> >> Kevin Ottens wrote:
>> >>> There's three main reasons for this rhythm:
>> >> * KAct
Kevin Ottens wrote:
> On Saturday 21 January 2012 20:49:40 Stephen Kelly wrote:
>> Kevin Ottens wrote:
>> > On Saturday 21 January 2012 16:17:38 Stephen Kelly wrote:
>> >> Kevin Ottens wrote:
>> >> > There's three main reasons for this rhyth
Valentin Rusu wrote:
> Stephen Kelly wrote:
>
>> Kevin Ottens wrote:
>>> There's three main reasons for this rhythm:
>
>> * KAction/QAction stuff - Don't know what's needed. If QAction needs new
>> virtual method that would need to be deter
Kevin Ottens wrote:
> On Saturday 21 January 2012 16:17:38 Stephen Kelly wrote:
>> Kevin Ottens wrote:
>> > There's three main reasons for this rhythm:
>> > * Qt 5.0 feature freeze is upon us now;
>> > * CMake 2.8.8 will be released in April;
>>
Kevin Ottens wrote:
> There's three main reasons for this rhythm:
> * Qt 5.0 feature freeze is upon us now;
> * CMake 2.8.8 will be released in April;
> * it'd be nice to release KDE Frameworks 5.0 at Akademy[*].
You mean 'some of the frameworks'? They won't all be done by then. More
stuff wil
---
>> This is an automatically generated e-mail. To reply, visit:
>> http://git.reviewboard.kde.org/r/103421/
>> -------
>>
>> (Updated Dec. 15, 2011, 8:54 p.m.)
>>
>>
>> Review request for kdelibs and Stephen Kelly.
>>
>>
>>
Alexander Neundorf wrote:
>>
>> That leaves enable_final and setting LINK_INTERFACE_LIBRARIES to empty.
>> I'm
>
> Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted.
> By default, all libraries a target is linked agaonst are in the
> LINK_INTERFACE, which leads to unnecessary d
1 - 100 of 198 matches
Mail list logo
