[kde-community] KDE Essential Applications - was - Re: Applications in KDE Generation 5

Adriaan de Groot groot at kde.org
Thu Jan 16 11:15:05 UTC 2014

On Thursday 16 January 2014 11:56:08 Sebastian K├╝gler wrote:
> On Wednesday, January 15, 2014 23:46:29 Adriaan de Groot wrote:
> > On Wednesday 15 January 2014 23:13:11 Albert Astals Cid wrote:
> > > Besides how would you define this "KDE Essential Applications" group? I
> > > mean a  tarball? An XML file somewhere? Personally I find distros should
> > 
> > It's still nice to have some kind of grouping defined by the KDE release;
> > the  reason for that being that it's much easier to say "install kdegames"
> I'm not sure the current categorisation works very well here, for example
> installing kdegraphics gives you a whole bunch of graphics-related tools,
> but probably too many (and then some are missing, such as digikam), and
> workflows might still not be complete. (Underlying assumptions, the user
> wants to accomplish a task, not "run an application".)

Well-said. This is a topic in FreeBSD-packaging land right now, actually: how 
to make all the little KDE Applications visible (stuff pulled from extragear or 
third-party stuff that doesn't currently belong to one of the old-fashioned SVN 
module groupings). And, as you point out, digiKam is a natural for the "kde 
graphics" (well, is it?) grouping, even if it's not actually in that 

> A brainfart: rather than categorizing applications by their domain, maybe
> providing sets of apps for certain workflows or usecases, a vertical, rather
> than a horizontal integration, if you wish.

I like the idea, but fear for its practicality. Figuring out what the vertical 
is (pick a metier, ambacht or trade here -- say Photography) and which apps 
service it will take quite a bit of thinking. On the other hand, it might 
start something really nice: metaports, or software products (or whatever your 
distro + package manager calls it) that map to what people want to do .. oh, 
wait, you wrote that already:

> For example: a SOHO metapackage would ship Calligra Sheets and Words, Kraft,
> Kontact. A primary educational metapackage would ship edu apps suitable for
> a certain age. A "Tablet" metapackage would include Plasma Active's UI,
> Krita Sketch, and other touch-suitable apps, and so on. These metapackages
> could even cause configuration changes elsewhere, so installing a "hobby
> photographer" metapackage would add an Activity for this task in Plasma
> Desktop.
> These metapackages can of course overlap (as it's really just a dependency
> definition), but it would it make it easier to create coherent, yet complete
> systems, and be a way to reflect a clearer vision for apps and sets of apps
> towards the actual use-cases.

A distro could also evaluate the packages available, of course, and add cheese 
to "hobby photographer", replacing whatever (*is* there even an equivalent?) 
KDE has there, in order to provide the best-possible set of apps for that 

But I don't think that "Scuba-diving C++ programmer" is going to be a viable 
metapackage any time soon.


More information about the kde-community mailing list