notmart at gmail.com
Fri Mar 13 11:25:09 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.
i think there a really different scope between plasma and libplasma
the plasma-destop in workspace is well, a workspace, so not a broader scope
than kicker+kdesktop, to some extent.
we do want to make other components of workspace to look like that, to have a
good unified look, not for some evil conquering plans, forinstance the new
alt+tab effect in kwin looks really really good now.
libplasma it's well, in kdelibs.
so it's not something that shouldn't exit from tight workspace boundaries, we
hope it will got used just because be are confident that is a good library
that can do a good service to the app developers that are interested in.
it's a thing that can be useful if an app want to have little simple plugins
even scripted so intallable also with ghns, they don't have to use the same
theme as the desktop shell and can even use the native look for some widgets.
A little bit as amarok does, yes it's still not perfect, there are still bugs
from both our and their part, but i think that's a really good use.
another random use case that pops into my mind could be the following:
for instance if an app has the tipical area of the document and wants to have
some ui inside the document (for whatever reason) it could well use a
plasmoid, since in that area it's not perceived as mandatory having the look
of the rest of the app (don't recall any complaining that html pages don't
follow the system color settings)
that said, we don't want to force anybody to use it, it's just another library
in kdelibs that sits here as a service to who wants to use it, there will be
more and less adapt uses and some misuses, but this is normal.
In the end i really think that makes sense that its not 'just' a desktop
> That doesn't mean that innovation and "abuse" should be forbidden.
> However a general document that would outline the intended focus and intent
> of plasma would be quite useful.
> 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.
> So where is the line between plasma and the desktop with its own apps and
> its own window management? And how do they relate to each other?
> 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 that are hard to map in the spatial memory
> of many users. So either there needs to happen a lot of integration between
> both to make it more clear to the user as to how both concepts relate to
> each other. Or the whole concept needs some conceptual refactoring to make
> it more simple to understand.
More information about the kde-core-devel