Aaron J. Seigo
aseigo at kde.org
Fri Mar 13 15:25:51 GMT 2009
On Friday 13 March 2009, Torsten Rahn wrote:
> On Thursday 12 March 2009 01:17:33 Aaron J. Seigo wrote:
> > seeing solutions in libplasma for this reason. still, i do agree that if
> > libplasma is a hammer, not everything is a nail. ;)
> I think what people would like to see is a stricter and clearer
> specification of the _scope_ of plasma. That specification should outline
> what intent of use is part of plasma's development focus and what is not.
fair enough. on the one hand, i understand what you're looking for and why.
on the other hand, i feel we have more than enough going on to take care of
(we really don't need more on our plate) and that not one single other
application in kde is asked to do this.
so if we go and fulfill this rather extraordinary request that will not
actually benefit the user experience in any way, it would be brilliant if you
could participate, utilize and help spread the results.
> Currently I feel that there is the danger that plasma develops out of its
> own scope and becomes a desktop-environment inside a desktop environment
> due to lack of focus on the core issues it tries to solve.
we have a very clear focus on the core issues we are trying to solve; that
others on this list who are involved with plasma can state those issues
but let's talk in *specifics* rather than vague generalizations and sweeping
here's the overview:
* libplasma is in kdelibs. it is there to:
* provide a set of classes for applications that are doing "widgets on
canvases" type things (where "widget" in this case means plasmoids, google
gadgets, that sort of thing).
* provide a common set of classes for things like query answers, svg
painting, workspace theming
the users of libplasma include plasma-desktop, plasma-overlay, krunner,
amarok, that nepomuk query app i can never remember the name of and hopefully
in the future others (e.g. plasma-mid).
it is a separate library so as not to drag this stuff into applications that
neither need to nor want to deal with such things. it is needed because Qt's
graphicsview stuff is both tedious to use in places (hello
QGraphicsProxyWIdget), does not offer KDE integration (e.g. kconfig) and does
not provide any sort of object model for widgets-on-canvases
* plasma-desktop is in kdebase-workspace. it is a desktop shell. it provides
panels and a desktop layer. it allows for some interesting and new concepts
such as multiple activities and (nearly) dialog-less workspace management
* the plugins in workspace/ provide a basic "desktopy" experience
* the plugins in kdeplasma-addons are neat additional things that people are
interested in having around but which aren't core to a basic "desktop
we also have:
* plasma-overlay so people can put widgets on their screensaver
* krunner for running commands and doing quick searches
* plasmoidviewer and plasmaengineexplorer to help making things a bit easier
we are currently working on:
* kwin integration points (with the kwin developers)
* plasmate, a simple widget creator (emphasis on "simple" and "widget")
* plasma-mid, a plasma shell for smaller devices
we have started design sketching on:
* plasma mediacenter, a fullscreen plasma view and accompanying containment
that would be optionally available as part of the plasma-desktop shell to
quickly browse and play media fullscreen (just like every other modern desktop
and gaming system out there has)
we continue to work on desktop technologies others simply haven't been willing
to touch or pay the attention to that they deserve including:
* fixing the system tray mess (we should have an improved mechanism by 4.3.0,
which will allow us to do things in the future like integrate system tray
entries into task bar entries where it makes sense to do so)
* harmonizing visual notifications
* making it realistic to use scripting languages in the desktop shell
.. and more.
> So where is the line between plasma and the desktop with its own apps
i'm not sure i understand this part of the question. what do you mean by
"plasma", "the desktop" and "own apps" here? hm.. let me take a stab at it
there is some functional overlap between some plasma widgets, such as the
video widget, and full apps like dragon or kaffeine. the overlap is trivial,
however: they both play video using phonon (for the kde4 versions anyways).
the use cases are rather different, however: dragon is a stand alone
application that one might use to play some videos, kaffeine is a bigger
management type app that lets one handle playlists and other such more
advanced concepts, the plasma video support allows widgets to embed bits of
video. at most, we will one day have a simple full screen media browser that
comes with plasma; to understand the difference there look at macos and its
media center app compared to the quicktime and itunes apps.
there are multiple use cases for video and some of them are well serviced by
dragon and kaffeine, but not all are. for instance: a youtube plasmoid might
be fun and interesting for people, so they can quickly view youtube videos in
so instead of seeing some sort of conflict, it would be much more accurate and
useful to see that it is a way to support of a broader array of use cases.
after all, it's a little silly to say "but we have dragon player!" when a user
says "i'd like to place this video on my desktop".
> and its own window management?
where does this "own window management" come from, exactly?
look, we have objects on a canvas. this has nothing to do, at all, with window
if you're talking about managing things like the krunner window, panels, the
calendar that pops up when you click on the clock, we should be honest here
and realize that kicker/kdesktop did exactly the same things there.
> And how do they relate to each other?
i don't understand this question.
> I also agree that the current situation of the activities vs. virtual
> desktops is really hard to understand for a user as it provides two very
> similar but orthogonal concepts
they are not similar at all, actually. the problem is two-fold, and both
related to the fact that it's a new concept:
a) we're still working on smoothing the user interaction elements around these
b) there's not enough documentation and available user education, and so many
are trying to figure them out on their own and failing (new concepts are not
easy to figure out without help)
oh, and i'd also note that for the majority of people out there, activities
are a completely non-issue as they just sit there and use their desktop still
without caring much about them. i hope this changes in the future, but it
won't until the two items above are dealt with.
this particular bit of your email also borders on "let's start a general bitch
fest about anything we don't like, understand or get about plasma and any code
around that project". if we want to talk about "what are the goals of plasma
and how does that relate to kde in general" let's do that. if we also want to
talk about activities, let's take that to plasma-devel and not make this
thread a useless bifurcating conversation of random opinion. fair enough?
> that are hard to map in the spatial memory
> of many users.
please don't throw around terms like "map in the spatial memory" unless you're
prepared to offer some actual evidence to the fact that we are talking about
spatial memory, mapping, etc. iow, let's not run down random rabbit holes
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel