DevHeads.net

proposal: remove KTextEditor interface from kdelibs repository

hi :)

since Ian already brought it up and suggested a separate thread for it, let me
do just that. we discussed this a bit on the release mailing list, but the
discussion really ought involve more people since it will impact us all.

the idea is this (and the Kate devs are just fine with it, btw):

* remove the KTextEditor interface from the kdelibs repository
* enable KTextEditor in the build for the kate git module
* introduce a FindKTextEditor.cmake to kdelibs/cmake/modules/ that looks for
the interface and directs people to the kate repo if it doesn't exist there
* make all KDE apps that use the KTextEditor interface use that

the reason for this is:

* the Kate team wants to develop all kate related code in one place and make
it easier for people to try out Kate from mainline (by not making people check
out kdelibs just for the kate pieces that are in there)

* it would be an interesting and useful experiment with modularization of
kdelibs for cases such as these, namely when a library is used by a number of
apps but is not "general purpose" like kdecore, kdeui, kio, etc. are.

potential caveats are that it makes it harder to build certain KDE apps
because now you need not only kdelibs, but kate. this is already true for
things that require libs in kde-support, kdepimlibs or kdegraphics, though.

thoughts?

Comments

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Michael Pyne at 01/31/2011 - 18:45

On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote:
This is more a package management concern, and while I do want to avoid having
hundreds of dependencies just to build a single KDE Platform application, I
don't think this is too difficult as long as we make it clear which
dependencies are actually in place for our packagers (e.g. kate/kwrite
requires KTextEditor from libktexteditor, etc.)

The concern that I have, on the other hand, is whether this can be done in a
source and binary compatible fashion. I just took a look at
kdelibs/interfaces/ktexteditor, and indeed there already exists a separate
libktexteditor (i.e. it's not directly part of e.g. libkdecore).

So given that it seems like it should easily be doable without breaking source
or binary compatibility my opinion is that moving the interface out should be
fine. It would be interesting to see if the various mobile development groups
have already done something like this in fact.

Regards,
- Michael Pyne

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Aaron J. Seigo at 01/31/2011 - 19:07

On Monday, January 31, 2011, Michael Pyne wrote:
indeed; i'm hoping one or more of the packagers will chime in at some point.

yes, it can. and i don't believe anything in kdelibs itself uses it.

they tend to strip out lots of things like this, yes. they also tend to do
things that aren't BC in other libraries in kdelibs to get their size down
further.

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Sune Vuorela at 02/01/2011 - 05:11

On 2011-02-01, Aaron J. Seigo < ... at kde dot org> wrote:
I have commented on the kate developers plans more than once, but people
just seems to bring it up over and over again. But no. Nothing has
changed in my perception of things.

So far, we as packagers have been told that applications can expect all
plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime
to be available, and segfault is a acceptable way of handling missing
things.

Application developers has made their *current* apps based on this, and
stuff will break by moving e.g. katepart out of kdelibs.

Now KTextEditor. KTextEditor is a public library in kdelibs. This means
that people can actually expect KTextEditor to be there when they do

find_package(KDE4 REQUIRED)

It also means that people who builds from source can do svn up / git
pull in kdelibs and install new requirements,make, make install and
still have all apps working.

I'm unsure why we wants to break the promises we made to the rest of the
world about the stability of our libraries.

(oh. and why should a kile/kdevelop/... user compile and install kate?)

/Sune
- who as a packager will have a hard time effectively undoing this work
in order to *keep* the compatibility. As a packager, I actually trust
KDE to live up to their promises.

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Aaron J. Seigo at 02/01/2011 - 12:49

On Tuesday, February 1, 2011, Sune Vuorela wrote:
to boil it down to its essence, then, the primary issue is that we have a
"black box" with various runtime plugins in it that applications may or may
not rely on.

perhaps we should think about being more clear in our runtime definitions and
stricter with requiring apps to advertise their runtime expectations, so that
we can go from having a huge pile of dependencies to just the requirements for
a given application.

there's also a conflict of interest between packaging and development going on
here. development needs/wants one thing, packaging needs/wants a different
thing. exploring ways to more clearly and cleanly create a working division
bewteen development and release management may be something for us to consider
as well.

(i'm thinking about the above mostly in the context of the upcoming Platform11
dev sprint in June .. gathering topics :)

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Sune Vuorela at 02/01/2011 - 12:59

On 2011-02-01, Aaron J. Seigo < ... at kde dot org> wrote:
I'm all for modularizing and being more clear, but it should not be done by
tearing out parts of kdelibs to see what happens.

Rather:
Identify how we want apps to communicate their runtime requirements.
Get apps to specify it using the communication way described above. This
is for all apps built on the KDE Platform, no matter if they resides in
git.kde.org, gitorious, launchpad or sourceforge.
Get packagers and others to test that things work
Break things apart at tarball generation. Test that things work
Break up repositories
Profit.

/Sune

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Christoph Cullmann at 02/01/2011 - 06:10

On Tuesday, February 01, 2011 11:11:08 am Sune Vuorela wrote:
Beside, kile users won't compile it, they will use the versions shipped with
the distro.

Beside: I am grateful for your work as packager and don't want to annoy you.

But really, the whole git moving only makes sense, if stuff that is related is
grouped. And no, beside using kdelibs stuff, katepart and co. is not really
related. And working over 3 repositories is a hassle. (you need to clone all,
thats slow on dialup, you need to send at most 3 patches, you need to fiddle
with CMake to build only the kate parts, if you want only to have katepart and
co. fresh and not all libs, ...)

I can understand that new dependencies are work, but I don't see the problem
in comparison to other dependencies which change the whole time.

To get new contributors for Kate, it is essential, that working on it is EASY.
And the current way is easy (<a href="http://kate-editor.org/get-it/" title="http://kate-editor.org/get-it/">http://kate-editor.org/get-it/</a>), the old not.

Greetings
Christoph

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Sune Vuorela at 02/01/2011 - 08:12

On 2011-02-01, Christoph Cullmann < ... at absint dot de> wrote:
It is bad, because the software is already out there. We cannot go out
and change dependencies for things already released.

And we don't know what software it is. KDE Software is in no way
'announcing' what plugins they requires. nor which they can optionally
use. So we have two ways of figuring out who needs to require katepart.
1) make nothing require katepart and wait for bug reports and play
whack-a-mole
2) read thru the sourcecode of all software built on KDE Platform

or just be on the safe side and pretend that katepart is still part of
kdelibs

Yes. you could rely that when kdelibs *compiled*, things worked. We are
shipping things built against 4.1 or 4.2 that are run against 4.4, 4.5
or 4.6.

/Sune

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Kevin Krammer at 02/01/2011 - 06:53

On Tuesday, 2011-02-01, Christoph Cullmann wrote:

It would require a new kdelibs package (the new one will no longer satisfy the
same needs) or require that the packagers extract the interface related things
from kate and add them as a dependency for the kdelibs meta package.

While it is SC/BC, it changes the contents of the kdelibs package.
Either packagers put in extra effort of extracting the now missing parts from
Kate and add them as dependencies to kdelibs or they create a new version of
kdelibs which no longer satisfies the dependency rules of all applications
packaged against the old one (or with even more effort adding the old kdelibs
package as an alternative for all program packages that do not use the runtime
dependency).

The difference is that new dependencies add things to kdelibs so they can only
be used by applications built against that new version. Removing a dependency
would mean you'd have to check all applications on whether they need the
removed dependency and explicitly add it to their dependency list.

Or do you mean kate would become an additional depencency of kdelibs (however
that would work)?

My guess is that there are different rules for removal of functionality than
there are for adding.
On source or binary level we can always add (non-virtual) functions but we
cannot remove any.

When we make kdelibs depend on something, we usually put quite some effort
into our layer to make sure we can change dependencies without changing
dependencies for apps built on kdelibs, e.g. make kdelibs depend on different
libraries for new Solid backend implementations without requiring new
dependency rules for all applications using Solid.

Cheers,
Kevin

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Alexander Neundorf at 02/01/2011 - 13:52

On Tuesday 01 February 2011, Kevin Krammer wrote:
This is about removing libktexteditor, installed currently by kdelibs, from
kdelibs, and moving it into the kate repository, right ?

This would be a source incompatible change.

find_package(KDE4 REQUIRED)
add_executable(Foo ${mySrcs})
target_link_libraries(Foo ${KDE4_KTEXTEDITOR_LIBS})

-> does not work anymore, because you cannot rely on that libktexteditor is
there if kdelibs has been found.

So, from my POV, this can't be done for KDE 4.x.y.

Alex

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Pino Toscano at 01/31/2011 - 19:18

Alle martedì 1 febbraio 2011, Aaron J. Seigo ha scritto:
khtml does (but we know very few people care about it).

Apart from that, this move is a bit of "suprise" for whoever compiles
kdelibs from sources, and gets no KTextEditor by default anymore (after
years and years). The same goes for the katepart, which means you now
have to install something additional, instead of relying on what kdelibs
provided for years? Looks like a bit of source compatibility breaking,
at least IMHO.

I don't think taking out random pieces of kdelibs piece-by-piece is
something useful to do over time: either you split the whole at once, or
you don't.

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Andreas Pakulat at 01/31/2011 - 19:57

On 01.02.11 01:18:58, Pino Toscano wrote:
Indeed the debugger does use it, that is a problem as it creates a
hen-egg-problem.

Thats nothing really new in KDE land, our SC constantly gets new
dependencies that one needs to fetch and build. With all the movements
to git various repositories already split themselves up (polkit, phonon)
and so far people seem to have been able to adjust to that. No idea
wether the 'promo' around such changes was the cause for that or wether
only packagers were affected as most people get the packages from their
distro, but I haven't seen huge fallout so far because of such changes.

As there's not even a clear idea of where to split kdelibs, this request
is just a different way of saying "don't do it". Not to mention the
amount of work necessary to do such a modularization at once.

Andreas

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Aaron J. Seigo at 01/31/2011 - 22:19

On Monday, January 31, 2011, Andreas Pakulat wrote:
erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no go
then ... hm.. looking at it, only khtml has a build-time dependency on it. if
the texteditor part isn't available (or the source of the crash even? :) what
does the debugger do at that point?

i should go hunt down ervin and find out where that nice kdelibs
interdependencies chart has gone to ...

exactly ... i think it would be wise for us to try it with something small and
non-critical first to discover what the challenges are and what issues arise
when doing so.

oh well, KTextEditor isn't an option,

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Alexander Neundorf at 02/01/2011 - 13:56

On Tuesday 01 February 2011, Aaron J. Seigo wrote:
You can also get the brand new cmake 2.8.4rc2
(<a href="http://www.cmake.org/files/v2.8/?C=M;O=D" title="http://www.cmake.org/files/v2.8/?C=M;O=D">http://www.cmake.org/files/v2.8/?C=M;O=D</a>), and try to run cmake with
the "--graphviz=filename.dot" argument.
This will produce a huge dot file with all (library) dependencies, and smaller
dot-files for each target, which show what they depend on.
This should also give you those dependencies.

Alex

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Ian Monroe at 02/01/2011 - 13:28

On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo < ... at kde dot org> wrote:
Should we give up so easily on this? The whole point of modularization
is to remove cross-module dependencies, just like KHTML depending on
KTextEditor. Ideally this sort of "sideways" dependency wouldn't
exist.

Actually splitting up repos is the easy and less interesting part overall.

Ian

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Albert Astals Cid at 02/01/2011 - 14:49

A Dimarts, 1 de febrer de 2011, Ian Monroe va escriure:
What is your ideal then? Writing KTextEditor in KHTML again since we can not
depend on it? Or using a worse component?

Albert

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Andreas Pakulat at 02/01/2011 - 15:32

On 01.02.11 19:49:10, Albert Astals Cid wrote:
No, the natural fix is to make the dependency chain proper, i.e. KTE
depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml
cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore.

Andreas

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Maksim Orlovich at 02/01/2011 - 16:20

On 2/1/11, Andreas Pakulat < ... at gmx dot de> wrote:

Funny, I would think the proper fix would be for people who put their
work into kdelibs to honor the requisite commitment to backwards
compatibility, rather than to punish other
libraries for doing the right thing in using existing facilities.

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Aaron J. Seigo at 02/01/2011 - 16:48

On Tuesday, February 1, 2011, Maksim Orlovich wrote:
it's not about punishing any library or individuals' work. if we modularize
kdelibs, then that means we may end up with a small set of interconnected
repositories with clear dependency chains. for instance...

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 between those libraries. we may even decide to split
things up into "dev framework" vs "platform target". (if this sounds like
"KDE5" sort of stuff .. well .. yes :)

then we'd have other pieces that have been put into kdelibs in the past that
maybe should live on as part of the KDE Platform (or whatever call it) but in
their own repositories. that could include the KTextEditor interface, perhaps
libplasma as well.

so in the case of something that uses KTextEditor and is part of kdelibs now,
it could still be part of the KDE Platform but be its own module with a dep on
corelibs+kate. which is really no different than it is right now, except
everything would be explicit and not in one single repository.

the big change here would be that applications that require different parts of
the KDE Platform might have to define which parts to include (e.g. KTextEditor
interface) rather than them being provided implicitly in one big chunk as it
is now.

the domino effect there would be altering CMakeLists.txt for apps that need
KTextEditor (for example) to explicitly include it. alternatively, we could
maintain a compatibility FindKDE4-style macro that would pull in all those
pieces. so apps that did nothing would still have the same build profile
without any modifications, just risk pulling in more libraries than they
really need as build requirements. a "virtual" kdelibs if you will. we sort of
have this already with kde-support, imho.

apps could then be updated as desired to more accurately note their needs,
bringing dependency definition into sharper definition. but most importantly,
new apps, or existing Qt apps, could then much more easily say "I just want
libkdecore" or "I just want libsolid" and get it.

there are a hell of a lot of details in between all those broad strokes. if we
start pondering them now, though, by the time we hit Randa in June we may be
in a very good position to have effective discussions that result in actual
decisions :)

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Harri Porten at 02/01/2011 - 17:13

Would that be really such a big change? We can certainly redefine a "new
kdelibs". But I think it will always be just another set where some
(sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is
just a very random example. Will we next have the same discussion about
KFileDialog? It uses KPushButton. Should we move out both to avoid
sideways dependencies?

What I want to say: we can always define what kdelibs comprises. It can be
small, it can be big. I don't see a technically perfect optimum, though.
At best we can strive for "reasonable".

Unless.... unless we find some real technical means to manage compile-time
and runtime-dependencies. Maybe even MS Windows can serve as an example of
a platform that has gone through all of this, is very extensible and at
the same time very much backward compatible? One part of the puzzle I can
think of a interfaces (pure .h files) that can be queried at runtime. In
one way or the other that has been excersised in KDE in the past already
(Corba, KParts, DCOP/D-Bus, KService etc.).

Harri.

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Aaron J. Seigo at 02/01/2011 - 17:27

On Tuesday, February 1, 2011, Harri Porten wrote:
agreed; and in the case of KFileDialog, i would expect it to be classified as
"platform target" and moved "higher" up the chain than the "dev frameworks".
and then there is no "sideways" dep between it and anything in libkdeui:
libkdeui would be dev framework, KFD would be platform target.

a more layered approach, iow.

the purpose of all this would be to create something that has a profile which
3rd party developers are more likely to take up. right now "all of kdelibs" is
too much and we're losing lots of potential developers. being able to cherry
pick just libsolid, e.g., would be a big win. kdelibs is better than it was in
kde3 times, but there's still some serious mashing going on between app dev
frameworks and platform target stuff (this is an insight i first heard from
thiago, btw; i take zero credit and/or blame for it ;)

we also need to ask ourselves how we can encourage packagers to split things
up better so that libsolid does come in its own binary package on a system ...
even if we include it in a larger source module. packagers do this with our
applications already, the challenge is in the sorts of things that sune is
bringing up .. and much of that is our policy (or lack thereof) surrounding
what "kdelibs" means and what implicit guarantees are provided to apps built
using it.

yeah, that could definitely be part of the solution to teasing out the runtime
dependencies ...

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Stephen Kelly at 02/09/2011 - 14:02

There is a wiki page for this stuff by the way. Feel free to review it or
add to it.

<a href="http://techbase.kde.org/Projects/KDELibsModifications" title="http://techbase.kde.org/Projects/KDELibsModifications">http://techbase.kde.org/Projects/KDELibsModifications</a>

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Alexander Neundorf at 02/09/2011 - 15:24

On Wednesday 09 February 2011, Stephen Kelly wrote:
From the page:

TODO kdelibs Merge kdesupport(which is all functional libraries) into
kdelibs

Sounds good. But kdesupport is not what it once was, stuff has been moved out
of it, e.g. phonon.
There are also other nice Qt-addon libraries, like probably most prominently
Qwt (<a href="http://qwt.sourceforge.net" title="http://qwt.sourceforge.net">http://qwt.sourceforge.net</a>) or maybe also Qxt
(<a href="http://dev.libqxt.org/libqxt/wiki/Home" title="http://dev.libqxt.org/libqxt/wiki/Home">http://dev.libqxt.org/libqxt/wiki/Home</a>).
Having a set of non-platform, basically Qt-extension libraries, like stuff in
kdesupport is, is not too different from those.
Maybe we could invite them (Qwt) to become part of the "KDE-powered Qt
extension libraries" ?

Alex

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Stephen Kelly at 02/09/2011 - 15:37

From a thread linked in the page :) :

Things have changed, as you said. I'm all for making something more
inclusive of the existing community of extensions to Qt if that's possible.
Evaluating whether some kde libraries can be made Qt only without kde
interdependencies needs to happen first though I think.

Qxt may also have the same problem KDE has.

<a href="http://libqxt.bitbucket.org/doc/tip/qxtapplication.html" title="http://libqxt.bitbucket.org/doc/tip/qxtapplication.html">http://libqxt.bitbucket.org/doc/tip/qxtapplication.html</a>

Do you have to use a QxtApplication to use some features of Qxt? Is that at
odds with KApplication? I have no idea. Does Qwt have something similar?

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Alexander Neundorf at 02/09/2011 - 15:42

On Wednesday 09 February 2011, Stephen Kelly wrote:
Ooops, sorry, didn't see that. Actually I heard from Qxt the first time just a
few weeks ago.

Yes. One question is where to draw a line.
E.g. for me (speaking as commercial developer) I'd be fine to have to link a
few more libraries, as long as they don't require to run some extra daemons
or something. So if there was some library which depends on Qt and some
library from the KDE non-platformy libs this would probbaly be fine with me.
IOW, I wouldn't want to have to start virtuoso to use some graphing widget ;-)

No, Qwt is really just a set of widgets.

Alex

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Alexander Neundorf at 02/01/2011 - 15:48

On Tuesday 01 February 2011, Andreas Pakulat wrote:
I agree.
Which would mean that khtml would depend on kate. Also the webkit part if it
uses the kate component. Which makes the build order harder to get right, as
Michael notes in the other thread.
Do we want that ?
Probably.
Can we have that for KDE 4.x.y ? I don't think so.

I can remember that a point of criticism about gnome was that it is hard to
get it built correctly with all the relatively small independent libs.
I think we are moving in that direction...
Are we aware of this and is this ok with us ?

Alex

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Aaron J. Seigo at 02/01/2011 - 16:52

On Tuesday, February 1, 2011, Alexander Neundorf wrote:
yes, i am aware of this; and no, i'm not personally ok with it :)

if this is to work, we absolutely must find solutions that ballance the
benefits of greater modularity with ease of build. there are many possible
answers (better build tools; keeping things within the same repositories but
with more modular builds within those repostories; relying on packaging
instead of upstream tarballs for the modularization) and lots of details to
get "right" (e.g. how to deal with dependencies pulled in at runtime via kde-
runtime)

i think it is innevitable that we will need to compromise in places to find
our optimal mix. it is not a trivial set of questions. we do not, however,
need to have an answer today. we have a Platform meeting in June, and we can
use the months leading up to that to play around with different scenarios,
tugging at the threads to find complications that arise (as we are doing in
this thread) and try to have a very good overall picture by the time that in
person meeting happens.

it's great that we are aware of and thinking about these knock-on effects.
it'll take longer than just charging headlong forward, but we will come out
with a good solid "KDE" solution as a result...

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Maksim Orlovich at 02/01/2011 - 10:43

Pop up an error message and abort execution, as it expects it to be
part of kdelibs.
Which is coincidentally very similar to what KTextEditor tutorials
suggest --- see
<a href="http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example" title="http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example">http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example</a>
(except it needs katepart in specific)

So, as far as I am concerned, this is an incompatible change. (Moving
to kdebase-runtime would be fine, of course).

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Friedrich W. H.... at 02/01/2011 - 12:38

Mardi, le 1 février 2011, à 16:43, Maksim Orlovich a écrit:
Uh, that is old-fashioned. Should instead ask the user whether she wants to
install the proper text editor module. Isn't there some simple standard api
for that these days?

Cheers
Friedrich

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Sune Vuorela at 02/01/2011 - 12:53

On 2011-02-01, Friedrich W. H. Kossebau < ... at kde dot org> wrote:
A simple standard api for what? installations of scripts and wallpapers
and stuff, sure. there is the ghns things.

For isntallation of compiled stuff, no. And I'm not sure there should be
such a thing.

/Sune

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Friedrich W. H.... at 02/01/2011 - 13:28

Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit:
Not something related to packagekit or similar? Eh, IMHO there should be
something like that if there isn't. With OBS and Co. compiled stuff is not
that much different, you just get a variant tailored to your (hardware)
profil. Can someone please empty my TODO list? :)

Hm. You don't agree that a user experience like
"Sorry, missing X to do Y. Would you like to get X now for that?"
is better than one à la
"Na, no way to do Y."?

Cheers
Friedrich

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Alexander Neundorf at 02/01/2011 - 13:42

On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote:
I think Lubos proposed something like this "recently", i.e. at some point last
year here on this list.

Alex

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Friedrich W. H.... at 02/01/2011 - 14:08

Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit:
Others have done now and then as well, e.g., ahem, me ;) here a few years ago:
<a href="http://markmail.org/message/xo2b4zw2ee6si6g2" title="http://markmail.org/message/xo2b4zw2ee6si6g2">http://markmail.org/message/xo2b4zw2ee6si6g2</a>

Oh, how cheap talk is :P

Cheers
Friedrich

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Alexander Neundorf at 02/01/2011 - 14:14

On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote:
I think this might be related:
<a href="http://www.kdedevelopers.org/node/4232" title="http://www.kdedevelopers.org/node/4232">http://www.kdedevelopers.org/node/4232</a>

Alex

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Friedrich W. H.... at 02/01/2011 - 14:41

Mardi, le 1 février 2011, à 20:14, Alexander Neundorf a écrit:
Oh, nice, missed that before, thanks for the pointer, Alex :)

Indeed, that is pretty related. Hm, might be an interesting GSoC task to merge
this with DrKonqi's debug packages loading, Phonon's new codec pulling and all
the other GHNS/OCS related stuff... so at some not to distant time the
KTextEditor example can be changed to code with a better user experience :)

Cheers
Friedrich

Re: proposal: remove KTextEditor interface from kdelibs reposito

By Sune Vuorela at 02/01/2011 - 13:39

On 2011-02-01, Friedrich W. H. Kossebau < ... at kde dot org> wrote:
Yes. since we can't assume the user has the right to install to the
system directory, and we shouldn't set up a complete development
environment for him.

/Sune