[kde-community] Applications in KDE Generation 5
Aaron J. Seigo
aseigo at kde.org
Thu Jan 16 10:42:43 UTC 2014
On Wednesday, January 15, 2014 21:47:17 John Layt wrote:
> It's time we talked about Applications. With the Frameworks and
Huzzah; thanks for starting this conversation
> * A number of our apps and utilities really have had their day and
> the existing apps and agree what needs dropping to Extragear or
there would be no Extragear, right? ;) And these apps may not be unmaintained,
only legacy. I write more about this below, however, so won’t go into it
> * There are a lot of high-quality utils, apps and libraries in
> move, but what else is there? Lets have a look and talk to their
> * Can we have a clearer split between Workspace and Application?
We’ve been working on it for ~6 years now :)
> Perhaps it's time we moved Workspace essential tools like KMix from
> being the responsibility of a module to being part of Workspaces?
> (i.e. don't move the NetworkManager plasmoid from Extragear into the
> Network module, move it to Workspaces).
For KMix and NetworkManager I think this makes a lot of sense.
> This ensures the Workspaces
> community have better visibility and control of they things they
> really need, especially if they split release cycles.
I would not word it in terms of control, as that might sound scary (and
rightfully so) to e.g. the KMix team. They should be able to work under their
own steam. It would certainly encourage all of those teams to *collaborate*
more with each other, however, and not worry as much about things like “how
does KMix work in GNOME Shell”.
The scoping of this needs to be done between the current (growing) Workspaces
community and the individual application teams. Guideline questions I’ve used
in the past for identifying a useful set of lines are:
* Is this an application that is commonly provided by bare-bones desktop envs?
(Yes: +1; both because it means it duplicates features in other envs but also
because it is probably *expected* to be there by users)
* Is this an application that requires a large number of assumptions about the
desktop env? (Yes : +1)
* Can you use the desktop env without it? (Maybe: +0.5, Not really: +1)
* Is this an application that has significant usage in other desktop envs
today? (No: +1)
So for kmix the answers might be: yes, no, no, maybe: 3.5 points
KDE NetworkManager: yes, yes, no, yes: 4 points
Dolphin: Yes, No, Maybe, Yes: 1.5 points
For KSnapshot: no, no, yes, yes: 0 points
It becomes more easy to pick which apps “belong” and which probably don’t
using these questions. It’s still a matter of judgement calls, but personally
I find those 4 questions helpful.
> * Do we need small utilities like KCalc as stand-alone apps, or do
> they belong in Workspaces, perhaps as Plasmoids? Where do we draw the
> line between them? And if there's both a Plasmoid and an App for
> something, which goes in the main release?
Plasmoids do not need to “belong to” the workspaces. There is an Application
FormFactor that plasmoids can use as a hint for when to implement a full
application UX and we have a stand-alone application shell. So KCalc could be
a plasmoid and be able to put literally anywhere (desktop layer, Plasma Active
grid view, panels, in the media center or as a stand-alone app) transaparently
to the user.
For ksnapshot does it make sense? not so much imho.
Would a plasmoid version of kcalc mean it has to belong to the workspaces? No.
It could easily live where it makes the most topical sense. This might be in a
“desktop essentials” group, but that may have a life of its own outside the
purview of the workspace development team / cycles / communication.
> * Application domain-specific libraries such as libkipi or libkcddb
> may now be better organised under Frameworks rather than their
> modules, where they could gain a wider user base and a clearer
> maintenance viability. Can we have a Frameworks category for non-api
> stable libraries?
Perhaps we should keep Frameworks its own thing: API stable libraries that
follow all the requirements of a framework and have a clear tier definition.
Other libs would live somewhere else without all these requirements. I don’t
know what that would be called :)
> * We have things like thumbnailers, kio slaves, dolphin plugins and
> strigi analyzers under each module, would these be better organised
> into meta-groups in Extragear so they're easier to find?
I think that’s a question for each dev team. The examples you give are really
an artifact of organizing all of this centrally and so having to create a
global taxonomy. Maybe dolphin would like to do a dolphin-addons similar to
plasma-addons, while some of the optional but highly useful kioslaves may go
into a workspace essentials group along with other workspace essential *apps*.
> * Can we create a "proper" KDE SDK? We have the SDK module which is
> really a mix of general development related apps and KDE-specific dev
> tools, and we have Examples, and we have a few other bits-and-pieces
> scattered around. Can we split the apps off to stand on their own
> repos in Extragear, and merge Examples and the other tools into SDK?
Examples is apparently being dismantled: examples live in each framework. It
would be a relatively simple matter, however, to pull them from each framework
into a release tarball with an appropriate script.
> * What "essential" apps or utilities are we now missing for a modern
> user? What do we need a "call-to-action" to try get people to work
> on? Lets make a list, not a long one though, just what is really
> really really essential.
IMHO this should happen well after we have everything that we have right now
sorted out and into the new release paradigm (whatever that might be)
> KDE's products. Applications are not *in* or *out* of a Software
> Collection, there is no distinction with Extragear apps, there are
> just KDE Applications. There should be no difference in the way we
This part of the proposal I really quite like :) It will also make a certain
Waldo Bastian, wherever he might be right now, smile....
> We can still have a regular KDE Applications
> Release, but it is then up to individual communities or applications
> to opt in to that release cycle, or to decide to release on their own
> cycle. Strong communities with a distinct identity in the wider FOSS
> world, like PIM or Games or Calligra, may find it better to have their
> own separate release cycles
For our users and downstreams, I agree with Albert that there is great value
in coordinated releases.
That doesn’t mean that all applications have to have the same *development*
cycle, just *release* cycles that match up. So if we have N month release
cycles, application teams should strive to make sure that their development
cycle fits as some reasonable multiple of that so that they hit the end of a
development cycle at the same time as everyone else at least once if not more
times per year.
So in a 6 month cycle, an app might choose a 1, 2, 3 or 6 months dev cycle and
still hit the Big Releases twice a year. In a 4 month cycle the options are
fewer: 1, 2, 4 being "perfect" with 3 months coinciding at least once per
calendar year (sometimes twice).
How great would it be if instead of have fewer apps in the Big Announcements
and Releases, we have *more* by offering such flexibility as part of our
institution. Then perhaps Calligra could also do a release and put out an
announcement in the same week as Frameworks, Workspaces and other apps.
This is a striving for balance between the competing and shared goals of
individual development teams and the larger community as a whole.
The idea of seeing development, release and promo cycles as complimentary but
not codependent will take effort to organize as it is not as simple as what we
do now. Once rolling, however, perhaps it can be made as simple to manage.
> and promo efforts, but I suspect most will
> stay with the regular release cycle.
We should probably strongly encourage a combined promo effort. Under such a
view, application promo would by their team would be supplementary to the main
messaging events rather than the other way around. We can stand to gain the
most promotionally by a few large impactful events each year rather than a
quiet hum in the background. The quiet hum keeps the feeling of motion,
however, so app promo is indeed important. It also allows application teams to
highlight specifics that may run counter to the “big messages”.
An example is an application which can be built without KDE Frameworks or is
trying to promote usage on Windows. Having this in the “big release” events
would send mixed messages: “Look how great KDE Frameworks is! Oh, but this app
is awesome because it can be built without them!”; “Plasma Desktop is amazing!
Now here are screenshots showing our apps running everywhere *but* Plasma
It would be very nice to see an “apps work everywhere” theme (e.g. outside of
Plasma Desktop) that runs independent of the big release announcements. this
would get all our messages across without them sounding like they conflict.
e.g. in June a Big KDE Release happens and we focus on how amazing everything
is in terms of how they work together. All screenshots would be taken using a
Plasma workspace, etc. One month later (e.g.) we do another combined Big
Announce (but not a release!) highlighting the applications running in
Windows, Mac, XFCE, GNOME Shell, Unity, etc. This might give the Windows team
some time to catch up as well and do additional testing / preparation post-
release (as one example).
IOW, promo need not be coupled so strongly to releases. It probably makes a
lot of sense to continue to do Big Announcements 1-2 times a year that are
coordinated with the biggest release schedules, so as to support those
releases, but those Big Announcements could also take in the recent releases
of other applications/libraries that weren’t part of the Big Release *and* the
promo could be planned in “echos” with the BIG Announcement followed by
thematic announcements (e.g. “Windows: check it!” or “Android apps!”) every N
With the increasing complexity of our offerings (Frameworks, Workspaces,
complex and important app suites like Kontact and Calligra) it may even make
sense to turn our big Release Announcement Day into an announcement *week*
where we stage a set of announcements sth like:
* Day 1: Dev tools (Frameworks, SDK, ..)
* Day 2: Workspaces and Essential Apps
* Days 3-5: Application Suites
In a way this is similar to how we do SC releases now: one big release every 6
months and a maintenance release every month.
> What then takes the place of the Software Collection? I'd propose a
> new collection of apps called KDE Essential Applications. This would
We really already have the beginning of this in the form of bits of
executables in kde-runtime, kdebase-apps and things in kde-workspace. So as
you said later in your email, this is perhaps not so radical a concept.
> It should also help with emphasising the
> separation between installing a single KDE app and having to use the
> entire Workspace and ecosystem. It may even attract more apps to be
> KDE hosted if they see it doesn't carry the old baggage of being part
> of the KDE Desktop Experience.
> new lifecycle metadata attribute that looks something like
> Experimental -> Incubator -> Stable -> Deprecated -> Unmaintained,
Not all applications pass through ‘deprecated’, and not all ‘deprecated’ apps
are without use, unstable or unmaintained. It sounds more like two different
lines to me:
Experimental (alpha) -> Incubation (beta) -> Stable (releases)
(this is a progression)
Active feature devel / maintenance only / unmaintained
(this is a state which an app may change from any one to any other over time)
“Deprecated” still doesn’t quite fit as it could be combined with any of the
above, so perhaps it is its own property, and it could probably even be
communicated implicitly by which module it appears in. Also, ‘legacy’ may
sound better and be a little more accurate than ‘deprecated’: KsCD and KPPP
have valid use cases with people engaging in those use cases .. but they are
not modern use cases and no longer exist as part of the typical usage. They
are use cases from yesteryear, or, legacy.
> with only Stable apps eligible to be included in the regular
> Applications release cycle.
What would be nice is if *all* stable apps were part of these epic releases.
Aaron J. Seigo
More information about the kde-community