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 repository. > 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 vertical. But I don't think that "Scuba-diving C++ programmer" is going to be a viable metapackage any time soon. [ade] _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community