4.5 - Activities

[todd rme]

On Wed, Mar 10, 2010 at 12:55 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
>> If someone did this, would you accept the patch?  I described a
>
> sure; i'd recommend doing it as a proof-of-concept first in a new Containment
> plugin, so that it isn't bumping into existing layout code. it would make it
> easier to test and work on strategies.

I can do that, I think.

> for testing, i'd also recommend using something like plasmoidviewer: a simple
> one-window app that is a Plasma::View which loads a Corona and this new
> Containment. it could then have some controls on it to change the size of the
> window to different common screen resolutions (maybe a toolbar with some
> buttons?). this would allow easy testing, and shouldn't be more than a hundred
> or so LOC.

Wouldn't it be easier to just use a virtual machine and resize the
machine arbitrarily?  That way we don't have to depend on it matching
what are currently common resolutions (although with kwin it is easy
to make a virtual machine a specific resolution).

> there is a very real upper limit on what can be accomplish here, though,
> through simple rearrangement. going from 1900x1200 to 640x480 is an absurdity
> and with enough widgets to cover a good portion of the higher resolution it
> just won't be possible to fit them in the lower resolution.

Yes, the goal is to work with common use-cases, and you won't really
see 640x480 all that often nowadays.  There are corner-cases for which
there is probably no good solution, the goal is to make it as useful
as possible in as wide a variety of situations as possible.

> bouncing between two resolutions will similarly get annoying if it means
> constantly re-arranging the widgets (e.g.: you move from large res A to small
> res B, then you move around and resize some widgets, then go back to res A..
> what happens? if the positions/resolutions are saved per-containment-geometry
> then those moves will be lost. just one example of the difficulty here.)

As I said in the bugs.kde.org report I linked to, changes would be
converted back to be relative to the original screen resolution and
stored in that manner.

> perhaps a solution is to just hide or put into scrollable region widgets that
> don't fit well.

There are requests for a scrollable version of the desktop
containment, but I think that would be better as a separate
containment.

> or perhaps the desktop layout could use an anchor style layout with the ratio
> to the edges or other landmarks being used.

That would be a solution, but I think that would require much more
major changes, at least to the plasma configuration files.  I was
trying to come up with a solution that work would with existing plasma
configurations.

>> you can end up with many of your widgets mostly-off screen
>
> while this can happen with FolderView, i don't think this should be possible
> with DefaultDesktop.

I mis-spoke, "mostly" is incorrect, the word I meant to use is "much".
 For instance, if you have a folderview widget the height of the
screen, then go to a smaller screen, then part of your folderview
widget will be below the bottom of the screen.

-Todd