Fullscreen interfaces

[Aaron J. Seigo]

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 
demonstrates that. 

but let's talk in *specifics* rather than vague generalizations and sweeping 
hand gestures.

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 
experience"

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 
(testing wise)


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 
anyways:

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 
their desktop.

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 
management. period.

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 
here.

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090313/7946104e/attachment.sig>