[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-17 12:00:15
Message-ID: 52D91B4F.2020502 () autistici ! org
[Download RAW message or body]

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=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 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 clea=
rer
> distinction between applications and workspace, making also the applicati=
ons
> to e able to be small, standalone, few dependencies entities.
> while an integrated workflow concept ties together way furtner applicatio=
ns
> 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 solu=
tion.
> 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.
_______________________________________________
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]