On Thursday 17 November 2011 00.14.23 Scott Kitterman wrote:
the best way to deal with it is not to consider it a fork of kdelibs
but the next version of kdelibs (that's what it is) and help out with
it
I'd be interested if I could, but learning C++ didn't make it to the topof
the TODO
On Wednesday 16 November 2011 19:07:51 Jaime wrote:
Hello,
Probably I've missed something, or what I propose is unpractical (or too
late), but here I go, anyway:
If the frameworks branch still depends on Qt 4,
Is it possible to have a public version of it once the
refactoring has been
On 11/17/2011 04:05 AM, Thomas Zander wrote:
On Thursday 17 November 2011 00.14.23 Scott Kitterman wrote:
the best way to deal with it is not to consider it a fork of kdelibs
but the next version of kdelibs (that's what it is) and help out with
it
I'd be interested if I could, but learning
I think this thread is indeed quite a dead end, but since you mentioned my
feature:
Thomas Zander wrote:
And I'm still not seeing anyone put in the in comparison tiny fraction of
time of porting the auto-download plasma thing to frameworks.
Let me clear up a few things:
* The problem isn't
On Tuesday, November 15, 2011 16:28:21 Scott Kitterman wrote:
On 11/15/2011 04:08 PM, Thomas L�bking wrote:
If one wants a feature in future KDE versions and such fork wouldn't
exist, one would not add it at all rather than to the frameworks?
Doesn't make any sense to me, sorry.
That's
On Wed, Nov 16, 2011 at 11:31 AM, Aaron J. Seigo ase...@kde.org wrote:
the best way to deal with it is not to consider it a fork of kdelibs but
the next version of kdelibs (that's what it is) and help out with it :)
another way of putting is: please don't fighting your own teammates (the
Hello,
Probably I've missed something, or what I propose is unpractical (or too
late), but here I go, anyway:
If the frameworks branch still depends on Qt 4,
Is it possible to have a public version of it once the
refactoring has been completed, but before it depends on Qt 5?
It could be used as a
On 11/16/2011 11:31 AM, Aaron J. Seigo wrote:
On Tuesday, November 15, 2011 16:28:21 Scott Kitterman wrote:
On 11/15/2011 04:08 PM, Thomas L�bking wrote:
If one wants a feature in future KDE versions and such fork wouldn't
exist, one would not add it at all rather than to the frameworks?
On 17.11.11 00:14:23, Scott Kitterman wrote:
On 11/16/2011 11:31 AM, Aaron J. Seigo wrote:
On Tuesday, November 15, 2011 16:28:21 Scott Kitterman wrote:
On 11/15/2011 04:08 PM, Thomas L�bking wrote:
If one wants a feature in future KDE versions and such fork wouldn't
exist, one would
On 11/15/2011 02:46 PM, Thomas Lübking wrote:
Am Tue, 15 Nov 2011 13:17:45 -0500
schrieb Scott Kittermank...@kitterman.com:
It is probably worth a discussion on packagers to share cross-distro
ideas about what kdelibs feature patches to ship with 4.8.
While Scott's suggestion to have a
Am Tue, 15 Nov 2011 15:20:44 -0500
schrieb Scott Kitterman k...@kitterman.com:
a) drain sources from KDE frameworks
Only if the people that would work on this would otherwise work on
KDE Frameworks. AFAIK, that's not the case.
If one wants a feature in future KDE versions and such fork
On Tuesday 15 November 2011, Thomas Lübking wrote:
Am Tue, 15 Nov 2011 15:20:44 -0500
schrieb Scott Kitterman k...@kitterman.com:
...
It's already happening, so the real question is how to minimize the
impact.
This is why i've posted this mail in the first place.
Minimizing the
On 11/15/2011 04:08 PM, Thomas Lübking wrote:
Am Tue, 15 Nov 2011 15:20:44 -0500
schrieb Scott Kittermank...@kitterman.com:
a) drain sources from KDE frameworks
Only if the people that would work on this would otherwise work on
KDE Frameworks. AFAIK, that's not the case.
If one wants a
On 11/15/2011 10:16 PM, Alexander Neundorf wrote:
Minimizing the impact means to align up- and downstream, ie. find
a way to provide features *now* w/o really opening kdelibs to new
features but at best accelerate frameworks development.
(as you probably read in the rest and unfortunately not
Hi all,
Perhaps as a solution to this, kdelibs master could have features
added to it, but only by a couple of gatekeepers who would
simultaneously ensure that the feature also lands in frameworks at the
same time? Obviously frameworks is going to be the future, however it
seems there are some
Am Tue, 15 Nov 2011 16:28:21 -0500
schrieb Scott Kitterman k...@kitterman.com:
Are there any examples of people who started working on the Frameworks port
because kdelibs 4.8 doesn't exist?
I don't know and that's still not the topic.
I didn't and do not suggest that developers who want
Thomas Lübking wrote:
And that is gonna happen in what way if it's not in any lib?
Static linking?! External lib? Problem solved?
Applications which are not part of KDE SC might end up just requiring a
patched kdelibs to even build.
Kevin Kofler
Am Tue, 15 Nov 2011 23:50:35 +0100
schrieb Kevin Kofler kevin.kof...@chello.at:
Thomas Lübking wrote:
And that is gonna happen in what way if it's not in any lib?
Static linking?! External lib? Problem solved?
Applications which are not part of KDE SC might end up just requiring
a
Thomas Lübking wrote:
Therefore my suggestion (if opening 4.x even as wrapper linking
frameworks is no option) would be to compile the features into the
application requiring it right now rather than forking a library
because you cannot alter it. (Don't forget: this is about covering the
time
19 matches
Mail list logo
