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

Thomas Pfeiffer colomar at autistici.org
Fri Jan 17 12:00:15 UTC 2014

On 16.01.2014 22:24, Marco Martin wrote:
> On Thursday 16 January 2014 21:50:47 Thomas Pfeiffer wrote:
>> Is it just me, or does this idea sound like it's going in a similar
>> direction to the "Flows" Björn 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 any technology-centric perspective.
>> So, long story short, a big +1 from me!
> one thing tough...
> from this thread i'm gathering there seems to be the need as well of clearer
> distinction between applications and workspace, making also the applications
> to e able to be small, standalone, few dependencies entities.
> while an integrated workflow concept ties together way furtner applications
> and workspace, and applications between each other (maybe at the point you
> don't have a very defined concept of "application" anymore)
> they are both desiderable, but they seems quite in contrast each other.
> I'm sure I'm hitting a false dichotomy there, but not seeing a clear solution.
> does anybody does?

Just to be clear: Organizing applications in task/workflow-based sets is 
of course still a far cry from the task-centric UI vision we presented, 
and of course we'll still see standalone applications for the 
foreseeable future. Maybe they will co-exist with "Flow Components" or 
whatever why may call these building blocks, maybe an application can 
exist both as standalone and as part of a flow.

What I meant with my mail was that to me, sebas' idea indicated a change 
in the underlying mindset. The current modules seem mostly organized 
from _our_ perspective, based on things like using the same libraries or 
being done by the same group of people.
Bundling them together by what tasks users can accomplish with them 
seems way more useful to me from a user's perspective.

Take KDE Edu for example: Though all applications in that module *can* 
be used for educational purposes, people may use some of them (e.g. 
Marble or Cantor) in a non-educational context and may not even be aware 
that they were originally meant for educational purposes.
I, for one, have more than once tried to install marble on a machine 
with an Arch-based distro by typing pacman -S marble, wondering why the 
package could not be found. When I searched for marble, I was surprised 
that the package name was kdeedu-marble, because I use marble mainly for 
routing and thus am unaware that it's actually an educational application.
That does not mean I want to split the KDE Edu community apart, of 
course. They're working together wonderfully and nobody would want to 
change that. Still, we cannot assume that all users see all applications 
which this community creates as "educational applications" just because 
they were originally created as such.
People use Marble for routing, they use Cantor or KmPlot or Rocs in 
science, but they may all be used in educational settings as well. It 
all depends on the individual task.

That also means that, as sebas suggested, an application/package can be 
part of more than one set of applications. Of course, distributions can 
create meta packages any way they want, but since all distros I've tried 
offer meta packages for the current modules, it seems that packages 
welcome the categorization we offer them.

More information about the kde-community mailing list