Cornelius Schumacher wrote:
Why be content with being a second-class citizen, when you can be first
class as well?
I don't think having a separate repo, release schedule, license and
development process makes a third party library a second class citizen. I'm
also not 100% certain that's what
Michael Jansen wrote:
The question is if anyone would be willing to do the work. Because it is
not sexy nor fun
I beg to differ :)
Well, I think getting to my version of the end state would be fun. Maybe
I'll start the project after MeeGo conf.
Aarons mail seems to be a restatement of many
Alexander Neundorf wrote:
On Saturday 30 October 2010, Stephen Kelly wrote:
Replying to John and Kevin here.
John Layt wrote:
Some excellent points, and it makes clear the sort of areas we need to
be
working on. Currently choosing to use kdelibs or any other KDE library
just
. To reply, visit:
http://svn.reviewboard.kde.org/r/6035/
---
(Updated 2010-12-03 16:37:47)
Review request for kdelibs and Stephen Kelly.
Summary
---
bug fix : add a forgotten method in KDescendantsProxyModel to forward
On 2010-12-03 18:43:50, Stephen Kelly wrote:
It wasn't so much forgotten as omitted because of complexity and weird UI.
Drops can be released directly on an item, or between two items.
If a drop on a kdescendantsproxymodel is released on an item it is
reasonably clear
Jaime wrote:
Hi,
I've run the kdelibs with the environment variable QT_FATAL_WARNINGS=1,
and the number of failed tests has grown in a noticeable way. (also with 2
crashes).
I guess that less Qt warnings usually means less unexpected crashes.
Therefore I suggest to add that
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6405/
---
(Updated Jan. 23, 2011, 1:24 p.m.)
Review request for kdelibs, Pino Toscano
is
exactly the same as the order in the template file?
Stephen Kelly wrote:
Yes.
Additionally, the output file contains the concatenated results from
multiple output files. I'm not certain if this is relevant to the question.
This should read
Additionally, the output file
Albert Astals Cid wrote:
* I'm not giving you EXTRACT_TEMPLATE_STRINGS, at most
EXTRACT_GRANTLEE_TEMPLATE_STRINGS if you want ;-)
That'll do :)
Will that be a problem? Can I coordinate that with someone?
With the KDE i18n coordinator (me)
Ok, the script is reviewed and
Subject:ABI breaking between kdelibs 4.5 and 4.6
Date: Tue, 8 Feb 2011 23:51:00 +0100
From: José Manuel Santamaría Lema panfa...@gmail.com
To: Stephen Kelly steve...@gmail.com
Hi,
while I was developing debian packages for KDE 4.6, I realized that a public
symbol was removed
Aaron J. Seigo wrote:
On Tuesday, February 1, 2011, Harri Porten wrote:
On Tue, 1 Feb 2011, Aaron J. Seigo wrote:
we could end up with a new kdelibs module that contains just the core
stuff such as kdecore, kdeui, kio .. there could be requirements in
there about allowable dependencies
Thiago Macieira wrote:
Q_GLOBAL_STATIC is not public API. Don't use it.
Would it be an option to make it public API by documenting it or is that out
of the question?
Christoph Feck wrote:
On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote:
KJob would be a Qt only library
? KJob is not a library, but a class in kdecore.
I should have been more clear I guess. When I wrote kjob there I meant a
library for asynchronous job execution containing
Alexander Neundorf wrote:
On Wednesday 09 February 2011, Stephen Kelly wrote:
Aaron J. Seigo wrote:
On Tuesday, February 1, 2011, Harri Porten wrote:
On Tue, 1 Feb 2011, Aaron J. Seigo wrote:
we could end up with a new kdelibs module that contains just the
core stuff such as kdecore
(Creating a new thread)
Albert Astals Cid wrote:
A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure:
You seem to be
challenging the idea that less internal dependencies in kdelibs is a good
thing, but I think that's for a separate thread anyway.
Not sure if Christoph does, but i
Dawit A wrote:
On Wed, Feb 9, 2011 at 3:29 PM, Stephen Kelly steve...@gmail.com wrote:
Christoph Feck wrote:
On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote:
KJob would be a Qt only library
? KJob is not a library, but a class in kdecore.
I should have been more clear I guess
Albert Astals Cid wrote:
KLineEdit is integrated with KDE, QLineEdit is not, we can discuss this
all you want, but not using KLineEdit gives your users a poorer user
experience.
Ok. I'm not sure what that integration is and why it's not possible to have
a KLineEdit that doesn't depend on
Thiago Macieira wrote:
It should have been in a qglobalstatic_p.h. We might even do that -- and
intentionally break applications that are abusing the API.
A quick grep says that would break akonadi, grantlee, qca, phonon, qxt and a
couple of places in KDE that use it already (presumably
Thiago Macieira wrote:
Well, first of all, Thiago is not the highest authority in Qt. You just
had my opinion, not of all people.
Sure. I'd call a 'no' from any troll a veto. The only repsonse I got was a
no on #qt-labs. That's the only way I have of reaching 'all people' until
open
Alexander Neundorf wrote:
Maybe something has to be done in git ?
(basically all tools which get introduced to KDE have a fixing/feature
addition phase initially ;-)
Alex
Yes, this issue comes up on the git mailing list from time to time.
Aaron J. Seigo wrote:
On Wednesday, February 9, 2011, Stephen Kelly wrote:
http://techbase.kde.org/Projects/KDELibsModifications
good to see people thinking about these things. however:
this page belongs on commuity.kde.org. it's already linked from here:
http://community.kde.org
Michael Pyne wrote:
On Thursday, February 10, 2011 16:35:20 Stephen Kelly wrote:
Thiago Macieira wrote:
On Thursday, 10 de February de 2011 21:08:05 Stephen Kelly wrote:
Thiago Macieira wrote:
It should have been in a qglobalstatic_p.h. We might even do that --
and intentionally break
Thiago Macieira wrote:
QBasicAtomicPointer is a base class of the public class QAtomicPointer.
I see. That does make it harder to remove anyway.
Alexander Neundorf wrote:
On Monday 14 February 2011, Stephen Kelly wrote:
Aaron J. Seigo wrote:
On Wednesday, February 9, 2011, Stephen Kelly wrote:
http://techbase.kde.org/Projects/KDELibsModifications
good to see people thinking about these things. however:
this page belongs
Alexander Neundorf wrote:
On Monday 14 February 2011, Stephen Kelly wrote:
Aaron J. Seigo wrote:
On Wednesday, February 9, 2011, Stephen Kelly wrote:
http://techbase.kde.org/Projects/KDELibsModifications
good to see people thinking about these things. however:
this page belongs
John Layt wrote:
Anyway, I've started a page to document such things at
http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there.
David Jarvie, could you add something to the KDateTime entry?
Cheers!
I added some links to time zone related bug reports. Surprisingly they
John Layt wrote:
On Monday 14 February 2011 22:35:13 Stephen Kelly wrote:
You might think in terms of how much a typical KDE application ends up
using, but I'm thinking in terms of how much a typical Qt application
ends up using. Gregory is not going to end up using KLocale KConfig
KDateTime
David Jarvie wrote:
Anyway, I've started a page to document such things at
http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there.
David Jarvie, could you add something to the KDateTime entry?
Done. I hope it contains enough explanation - if you think it needs more,
Aaron J. Seigo wrote:
On Tuesday, February 15, 2011, Stephen Kelly wrote:
http://steveire.com/kdelibs-modular.png
* It's broad at the base - Qt developers can pick and choose what they
want. There are less interdependencies - you can use the itemviews stuff
without also pulling in KLocale
Michael Pyne wrote:
People who are interested in ksslsocket will see the commits.
You're thinking of CommitFilter. I'm thinking of the kde-commits mailing
list (i.e. people who didn't *know* they were interested in ksslsocket
until they saw a strange commit).
I wasn't really. It's just as
Sorry, knode fails me again. Some keyboard shortcut must be too close to
ctrl+v for me...
Stephen Kelly wrote:
Either way is an assumption, but only one of these assumptions involves
deliberately discarding data. ;)
If noise is data, you would have a good point.
What specifically do you
Michael Jansen wrote:
mjansen might just have been following a 'never rebase public branches'
philosphy, but that really doesn't work for me. It was a complicated
feature requiring lots of refactoring.
Hehe ... as the one doing the code i would say it was more like
mjansen
Johannes Sixt wrote:
Am 2/16/2011 22:10, schrieb Stephen Kelly:
As one of the people asked to describe my idea of the workflow (which
should
focus on rebasing, not merging) I put write up here:
http://community.kde.org/20110213_GitWorkflowAgenda/StevesIdea
http://thread.gmane.org
Stefan Majewsky wrote:
On Wed, Feb 16, 2011 at 5:31 PM, Aaron J. Seigo ase...@kde.org wrote:
which begs the question: is KConfig (as ane exmple) platform or app
dev? fun conversations to be had and digging to be done :)
From my experience, KConfig is actually two things at once:
1.
Johannes Sixt wrote:
I'm tired aguing, so I'll leave it at that. Just one point (because I
don't want to be called silly):
Just for clarity I wasn't calling you silly :).
I think we're just victims of low-bandwidth communication.
All the best,
Steve.
David Faure wrote:
kdeui/itemviews/klistwidgetsearchline.cpp
http://git.reviewboard.kde.org/r/100709/#comment1353
topLeft.parent().isValid() || bottomRight.parent().isValid()
- David
Actually topLeft.parent() == bottomRight.parent(), so you only need one.
Marco Martin wrote:
Hi all,
in kdelibs there is since some time a branch called plasma/declarative
that contains a new little library, that depends at the moment on kdecore
and kdeui (probably is possible to make it depend only from kdecore) that
is meant to be used in QML applications.
see
Hi,
Distros are still shipping KDEPIM 4.4 with their next release along with
kde{,pim}libs 4.6.
I'm testing it and getting errors like
http://starsky.19inch.net/~jr/tmp/kmail1.png
and then this one in a dialog:
There have been repeated failed attempts to gain access to
a wallet. An
Hi,
= Executive Summary =
The new Shared Desktop Ontologies version 0.7 changes in a backwards
incompatible way compared to version 0.6. kdelibs master already depends on
SDO 0.7. kdepim-runtime master also now depends on SDO 0.7.
kdepim4.4 still builds, because it happens to not use the
Sebastian Trüg wrote:
First off: I think the system does work. IMHO I am not the only one only
thinking about these dates shortly before they arrive. Thus, the hard
freeze is there to have time to fix issues like these. But that is just
my personal opinion.
Yes, the freeze is there to
Sebastian Trüg wrote:
Like I already said: patching rcgen seems like the best solution to me
and that is so trivial I can have finished it today.
The beta tagging is due to happen today. As far as I know this hasn't been
addressed. Was it more complex than expected or you just didn't have
Ben Cooksley wrote:
Doesn't apply to KDE repositories, as performing a rebase involves a
force push, which initiates the damage prevention area of our hooks.
This triggers creation of a backup ref protecting the contents of
the old ref from being affected by a gc, and ensures they are always
On 05/20/2011 09:35 PM, Dirk Mueller wrote:
On Thursday 19 May 2011, Stephen Kelly wrote:
The beta tagging is due to happen today. As far as I know this hasn't been
addressed. Was it more complex than expected or you just didn't have time?
I propose that we revert the dependency bump and tell
Thiago Macieira thiago at kde.org writes:
so just to be painfully clear (it's a monday morning here, i worked
all weekend and i still have house packing to do, please excuse my
obtuseness ;): IF a refcoutning patch is offered which ties all window
visibility (setQuitOnLastWindowClosed,
Sune Vuorela wrote:
On 2011-06-04, ?? ?? kuzem...@mail.ru wrote:
Hello. I am using Gentoo on the Beagleboard-Xm.
When I try to compile kde-4.6.80, I stoped on the grantlee build phase.
This is a full log.
http://paste.ubuntu.com/618234
I don't remember how to
David Faure wrote:
On Tuesday 07 June 2011 01:43:44 David Faure wrote:
Once the 4.7 branch is created, the plan is to do the following:
- application developers can work in master as usual, no change there.
- we create a new branch in kdelibs (say, frameworks) for the work on
splitting
Good point well made.
I think what you propose makes a lot of sense.
On 8/7/11, Michael Jansen k...@michael-jansen.biz wrote:
It might make sense to unfreeze master.
$ git log --pretty=oneline master..
4f0d3e Remove KGlobal::locale warning for pure Qt applications
88836f add missing file
Stephen Kelly wrote:
After using kde4_add_library the macro generate_export_header should be
used.
kde4_add_library(itemmodels ...)
generate_export_header(itemmodels
DEPRECATED_NAME KDE_DEPRECATED
)
Just fyi, Instead of this, use only kf5_add_library. I've already ported
existing
Boudewijn Rempt wrote:
Lazy is good... When doing a pure Qt app with CMake, I actually use a copy
of all the KDE cmake extensions :-).
Which do you use? Do you also use them when creating libraries, not just
apps?
Hi,
I've just locally merged KDE/4.7 into frameworks. Before I push I want to
review the conflicts and their resolutions, and I expect other developers
would want to do the same.
The merge showed that some commits in 4.7 have not made it into frameworks.
We really should merge in that
Hi,
I've just locally merged KDE/4.7 into frameworks. Before I push I want
to review the conflicts and their resolutions, and I expect other
developers would want to do the same.
The merge showed that some commits in 4.7 have not made it into
frameworks. We really should merge in that direction,
Hi,
I merged the 4.7 branch into frameworks recently. Now it's easy to merge
again, so no need to cherry-pick when you fix things in 4.7. You can merge
instead.
Thanks,
Steve.
Alexander Neundorf wrote:
No branches should be prefixed with KDE; we consider that a reserved
name.
Nor topic should branches be numeric in nature (such as a version
number) as
those are reserved for actual release branches. (Sys admin at the
meeting indicated that it is likely
David Faure wrote:
On Friday 26 August 2011 12:04:29 Stephen Kelly wrote:
Hi,
I merged the 4.7 branch into frameworks recently. Now it's easy to merge
again, so no need to cherry-pick when you fix things in 4.7. You can
merge instead.
OK, how do I do that exactly? Commit in 4.7, fetch
Aaron J. Seigo wrote:
On Friday, August 26, 2011 13:50:51 Michael Jansen wrote:
That reminds me of my futile attempts to convince you guys of the need
for a daily is everything merged check that sends its results (if stuff
to merge is open) to kde-core-develop list.
write it and show
Chusslove Illich wrote:
[: Stephen Kelly :]
We don't have to make one commit on 4.7 == one merge into frameworks.
We can just delay the merge and do it once a day or week. No one is using
frameworks, so we just need to make sure the commits get in eventually or
before it becomes hard
Harald Sitter wrote:
On Sun, Sep 4, 2011 at 2:18 PM, Stefan Majewsky
stefan.majew...@googlemail.com wrote:
2. api.kde.org doesn't show QML elements.
Problem with this is that Doxygen does not support QML (yet anyway),
actually I would not know how to make this work in a sane manner
Hi,
If you use gitk and are working in a git repo with lots of merges between
branches, it can be overwhelming to see all the commits in branches which
have been merged in (eg, the commits in the 4.7 and active branches when
trying to look at the frameworks branch).
The way to see commits
Sent this too early. Meant to supply a link.
Stephen Kelly wrote:
Hi,
If you use gitk and are working in a git repo with lots of merges between
branches, it can be overwhelming to see all the commits in branches which
have been merged in (eg, the commits in the 4.7 and active branches
Albert Astals Cid wrote:
A Diumenge, 4 de setembre de 2011, Stephen Kelly vàreu escriure:
Harald Sitter wrote:
On Sun, Sep 4, 2011 at 2:18 PM, Stefan Majewsky
stefan.majew...@googlemail.com wrote:
2. api.kde.org doesn't show QML elements.
Problem with this is that Doxygen does
todd rme wrote:
What about adding qdoc support to doxygen?
-Todd
You would have to investigate if that's possible?
Are you volunteering? :)
We've just had a long discussion about the future of KIcon in APIs,
which led into a discussion about what we're doing in frameworks at
all and why.
Several people don't think refactoring kdelibs into independent
frameworks is a good thing. Do we need to decide if it's worth it?
I'm posting the
Hi,
I re-read the IRC log from the last email and noticed the recommendation of
and API review instead of meta-discussion, which I missed at the time.
That is probably a good recommendation. Posting the log was probably a bad
call on my part, and we can hopefully have a more useful
Sebastian Trüg wrote:
With the currently ongoing split of kdelibs and kde-runtime according to
KDE 5.0 frameworks Nepomuk has already partly been reorganized:
kdelibs/nepomuk and most parts of kde-runtime/nepomuk have been moved
into the new repository nepomuk-core. kdelibs master has
Alexander Neundorf wrote:
On Thursday, September 15, 2011 12:04:24 AM Stephen Kelly wrote:
Alexander Neundorf wrote:
On Tuesday, September 13, 2011 09:41:31 PM Stephen Kelly wrote:
Forwarding to kcd which is probably more appropriate.
Stephen Kelly wrote:
Hi,
KAuth became
Alexander Neundorf wrote:
We shouldn't expect from all our developers that they suddenly take
care of all that themselves.
Every KDE application I have seen has this boilerplate:
find_package(KDE4 REQUIRED)
include(KDE4Defaults)
include(MacroLibrary)
include(CheckIncludeFiles)
Why
Stephen Kelly wrote:
bunch of more times too, or they would use find_package(kdelibs 5.0)[1]
Ignore the [1]. I was going to put the note about targets below in a
footnote, but reconsidered.
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
p.m.)
Review request for kdelibs and Stephen Kelly.
Description
---
Crash guard for KSelectionProxyModelPrivate::removeRangeFromProxy()
occassionally I am encountering asserts or crashes in this method, so
this little crash guard avoids those situations
Diffs
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 will
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;
* it'd be nice to release KDE Frameworks 5.0 at Akademy
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 rhythm:
* Qt 5.0 feature freeze is upon us now;
* CMake 2.8.8
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:
* KAction/QAction stuff - Don't know what's needed. If QAction needs
new virtual method
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 you have a list of such small fixes?
No, I don't
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
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 to
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
branch looks far more
Dario Freddi wrote:
2012/2/19 Stephen Kelly steve...@gmail.com:
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
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 and the
Ben Cooksley wrote:
On Feb 20, 2012 7:12 AM, Stephen Kelly steve...@gmail.com wrote:
Dario Freddi wrote:
2012/2/19 Stephen Kelly steve...@gmail.com:
Stephen Kelly wrote:
Hi there,
I was reviewing the changes in the frameworks branch from yesterday.
Something I noticed
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://git.reviewboard.kde.org/r/104337
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.org/r/104337
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 enums are not named
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 Kelly wrote:
Mostly it looks fine
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
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, please
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 wrote:
Thanks for making this happen
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 wrote:
Thanks for making this happen
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
(as you can see from the log),
... actually I
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 fixed
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.
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, wheras press and hold shows a menu of the recent history.
Another use
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
KCapacityBar are the question of what to do
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 :)
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
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
don't know where this is documented. I expect
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, visit:
http://git.reviewboard.kde.org
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 build kdelibs? Checkout master
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.
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 anyway
deprecated in favour of the V8 based new
1 - 100 of 155 matches
Mail list logo
