kde plasma workspace structure

[Aaron J. Seigo]

On Saturday, June 9, 2012 10:28:05 Martin Gräßlin wrote:
> On Saturday 09 June 2012 04:45:51 Aaron J. Seigo wrote:
> > * losing portability to non-Linux (and even specific Linux OSes)
> 
> something I would like to discuss in the light of workspace.
> 
> I think we all agree that we do neither target MS Windows nor OS X. (I know
> you can run plasma-desktop on Windows, but it's more a proof of concept than
> anything else).

the full workspace does not, that's correct. there's no real point to that.

> With other words: the non-Linux OSes do no longer support our minimum
> runtime requirements, where it starts to be questionable to go the
> additional way to keep portability possible (hello Sun Compiler).

solaris is dead. the BSDs (ironically ;) are not. not all hardware is 
supported under Linux sufficiently either and the software pipelines are not yet 
good enough on most configurations, meaning that we can't even rely on Linux to 
support these new runtime requirements you're inventing here.

yes, it is ultimately boring to not run off into the future we all know is 
coming as fast as we can. but at this point the cost is is very low to 
maintain the support we have for the non-composited case and that in turns 
maintains many happy users.

i said this last year, and probably the year before that as well, but it is 
unfortunately still absolutely true: the state of opengl on even Linux is not 
good enough (though it one day will be) and we have non-negligable numbers of 
users relying on Plasma Workspace to work on non-Linux systems.

btw, if we were to drop support for non-Linux OSes (besides losing the benefits 
keeping code portable usually has on the code base) you ought to be the one 
who goes, in person, to groups like PC BSD who are putting their time and 
money into that and tell them just how we don't give a fuck about them 
anymore.

this is an ivory tower we can ill afford to climb into.

> > i agree that it makes sense to drag kmix into kde-workspace since it
> > really
> > only makes sense in that scope. every other desktop has their own mixer,
> > right? so there's no reason for someone to use kmix elsewhere. (unlike,
> > say, digikam or gwenview.)
> 
> interesting, I would consider gwenview part of the workspace as I think an
> image viewer is nowadays one of the most essential applications a user
> needs.

'how essential is the application' is not the measuring stick we've been 
using, otherwise the web browser would be part of the workspace too. (far 
before an image viewer ever would be, in fact.)

it's a question of "is it something that the user starts explicitly to view / 
manipulate their information / data / etc.?" (there are a number of edge cases 
in that question, but you get the idea.)

the desktop shell, the command runner, the window manager and various other 
components are started on behalf of the user to make the system essentially 
usable.

system settings and similar applications are there to interact with the system 
itself, not to grant access (view/manipulate) the user's own information 
(files, contacts, websites, etc.)

if we go down the path of "what application is essential to the user" we'll be 
utterly screwed because:

* that changes over time

* that changes between use cases

* we want to give the user a clear frame for their applications and a way to 
distinguish cleanly between "this is my application i started" and "this is 
part of the system underneath" (the classic example are all the popup dialogs 
that we used to use for things like hardware events that looked exactly like 
an application's own dialogs: they would pop out of nowhere .. "where the #(*$ 
did that come from? what does it belong to?")

the useful grouping is "what is part of the system" (user's POV) and "what are 
my applications with my information in them"

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120609/82d572bf/attachment.sig>