KTouch

[Aaron J. Seigo]

On Tuesday, May 15, 2012 12:37:52 Laszlo Papp wrote:
> > Albert is talking about the *reality* of things: as the KDE Platform is
> > designed from a technical perspective, kde-runtime is a dependency for all
> > kde applications. full stop. don't pass Go. don't collect $200. that's
> > just how it is. things break when kde-runtime is not installed.
> 
> None of the applications aforementioned, I have worked on, break, and
> as such: it is better to have this way than adding an unnecessary
> extra dependency, if I do not otherwise need the functionality of that
> addition.

a) i guarantee you there are things that will not work from kdelibs without it 
right now

b) on KDE's direction, packagers do not treate it (for above reasons) as an 
optional dependency

you can get "lucky" by only using certain classes from kdelibs, but there are 
no guarantees to that. anything there can change at any time.

> If kde-runtime had been hard dependency, and nothing would have worked
> without that, this should have been marked as hard dependency. I still
> stick by that, as for certain cases including our previous projects,
> this is something that we could avoid.

please re-read what i wrote in my first email. you are essentially restating 
the "desire to have fewer dependencies" case and i answered with what a proper 
solution is.

> > Laszlo is reflecting the *desire* of many application developers, which is
> > to have a more "ala cart" approach where instead of having one big
> > kde-runtime (and one big kdelibs) things are broken out ("atomized",
> > "modularized", take your pick :) so that only the requirements of a
> > specific application are there.
> It is not just a desire. That is the reality for the applications I
> have worked on with KDE4.

please show me a Linux distribution that does not treat kde-runtime as a hard 
dependency for use of kdelibs.

is it possible to change this? yes. as you've found out, the dependency is not 
accurate in all cases, and is probably innacurate to some degree in all cases 
(since it is unlikely that any one app uses everything in kde-runtime). but 
right now, the way the dependencies are mapped and tested and how development 
rules work in kdelibs, this is currently neither supported nor in practice 
possible (unless you are just fine with random things breaking randomly under 
your application)
 
> > and for the "our desire is to not have kde-runtime" viewpoint, that is
> > something we wish to achieve with Frameworks 5. please support that
> > effort.
> 
> I have been trying to. However, I am mostly on the Qt5 integration
> front, not UI components.

working on Qt5 integration is part of what needs doing. in turn, that will 
help us get to erasing kde-runtime as a monolithic dependency. and will get us 
to where you want to be in the future. e.g. with Frameworks 5 the plasma 
components (and the various QML bits in kdelibs as well) will end up as one 
small, self-contained package with minimal library dependencies under that.

this doesn't change the current state of things, and it is not a reason to 
then poorly advise people to stay clear of using the Plasma Components now.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20120515/c29b6321/attachment.sig>