Fullscreen interfaces

[Nuno Pinheiro]

A Friday 13 March 2009 11:25:09, Marco Martin escreveu:
> 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.

+1
>
> 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)


+1 
example a themable dinamic chart in a monitor application.

>
> 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
> shell.
>
> Cheers,
> Marco Martin
>
> > 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.

I think we all are aware of that particular problem...

> > Regards,
> >
> > Torsten

-- 
Oxygen coordinator