[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: 4.5 - Activities
From:       todd rme <toddrme2178 () gmail ! com>
Date:       2010-03-10 18:14:17
Message-ID: 6524e4801003101014t3306802em4a4b2860517895b9 () mail ! gmail ! com
[Download RAW message or body]

On Wed, Mar 10, 2010 at 12:55 PM, Aaron J. Seigo <aseigo@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
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[prev in list] [next in list] [prev in thread] [next in thread]