[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: [kde-community] KDE Essential Applications - was - Re: Applications in KDE Generation 5
From:       Thomas Pfeiffer <colomar () autistici ! org>
Date:       2014-01-16 20:50:47
Message-ID: 1833315.3NIe4a3L28 () lenovo
[Download RAW message or body]

On Thursday 16 January 2014 11:56:08 Sebastian K=FCgler 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 sho=
uld
> > > be smart enough to decide which apps they want to ship by default and
> > > which not.
> > =

> > It's still nice to have some kind of grouping defined by the KDE releas=
e;
> > the  reason for that being that it's much easier to say "install kdegam=
es"
> > than "install khangman and kgoldrunner and ktiktaktoe and ksnap and lts=
kat
> > and ..." and if "kdegames" -- or "kdeessentials" -- refers to the same
> > name
> > across distro's, that's good for migrating users. You really don't want=
 a
> > (non-smart) distro saying "Oh, we didn't think kmix was essential" .
> > =

> > If there's a list of "these 38 repositories / tarballs are the essentia=
ls
> > this  time around" then that at least is a strong indication that that's
> > what upstream (i.e. us as KDE) wants.
> =

> 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".)
> =

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

> For example: a SOHO metapackage would ship Calligra Sheets and Words, Kra=
ft,
> Kontact. A primary educational metapackage would ship edu apps suitable f=
or
> 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 compl=
ete
> systems, and be a way to reflect a clearer vision for apps and sets of ap=
ps
> towards the actual use-cases.
> =

> Just an idea...

Is it just me, or does this idea sound like it's going in a similar directi=
on =

to the "Flows" Bj=F6rn and I talked about at Akademy? ;)
Tasks/workflows is really what we should be thinking about, because that's =
the =

user's perspective, and thus much more likely to be helpful to users than a=
ny =

technology-centric perspective.
So, long story short, a big +1 from me!

_______________________________________________
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community
[prev in list] [next in list] [prev in thread] [next in thread]