xrandr

[Aaron J. Seigo]

On Saturday 07 June 2008, Michael Rudolph wrote:
> On Saturday 07 June 2008 14:42:17 Marco Martin wrote:
> > On Saturday 07 June 2008, Aaron J. Seigo wrote:
> > > hi all
> > >
> > > so i committed a bunch of fixes for responding to xrandr changes.
> > > it seems to work again, with panels adjusting their sizes and what
> > > not properly.
> > >
> > > there are some outstanding issues left, and i'm getting lied to by
> > > my graphics driver and/or Qt pretty badly at times right now (like
> > > it telling me that there's a screen 1 that's changing size when
> > > screen 1 does not actually exist, nor did it when plasma started)
> >
> > hmm, thihs is probably something we can't do nothing about that,
> > right? :(
> >
> > > the big remaining issue is going from a full screen panel on a
> > > large res, to a smaller res, then back to a larger res.
> > >
> > > what happens is that in the larger res (call it R(0)) we have a
> > > panel 100% width. in the lower res (R(1)) the panel is smashed down
> > > to the right size. so far so good.
> > >
> > > but on return to R(0) we no longer know at that point in time what
> > > R(1) was! i think we're going to need to keep the last seen screen
> > > geometry in PanelView.
> > >
> > > Marco: i'd like to chat various solutions over with you, since
> > > you've been working on resize and what not of late.
> >
> > hmm, don't know if i like keeping the ratios, if i have configured a
> > size don't know if i would like it should be automatically changed,
> > also because if i configure a certain size less than 100% it's
> > probably more related to the size and number of the applets than on
> > how the screen is big. now probably it's natural to keep the size
> > 100% because it basically means it was not configured and becoming
> > not 100% would be weird?
> > but that said i also don't know what could feel more natural, i only
> > know in every way we do there will always be bug reports that asks
> > the exact opposite, quite inevitable :)
> >
> > i only feel that keeping the ratio between screen and panels would
> > collide a bit with the growing/maximum/minimum sizing, beside being a
> > bit more complicate.
> > i would be for caring only about 100% in this way (only tought about
> > it don't know if it'll work)
> > the being 100% or not is kept by a bool valued that is updated when
> > the user move the sliders but not when the screen res changes or the
> > panel changes screen, so if a panel becomes 100% because of
> > resolution change and then it changes again it won't grow back to
> > 100%
> > of course there always will be messing with settings/annoyances when
> > the resolution decreases but don't see how to avoid them that much.
> > if ratios are to be kept everything should be kept to make it work
> > decently, size, max and min size and offset, i think it's a bit
> > overkill...
> >
> > Cheers,
> > Marco Martin
>
> Hello everyone,
>
> since Plasma is already pretty much resolution independent, wouldn't it
> be rather obvious to save all panel measurements in relation to the
> screen's resolution, as percentages?

not really. ratios are a one time calc (so you're not saving much of 
anything), are prone to rounding issues and you need to use pixel values for 
the screen in the end anyways.

it also then becomes very tempting to use %s for the widgets inside the 
containments as well, and that way lies madness (having dealt with exactly 
such a system in kicker). much easier is storing pixel values everywhere and 
just converting as-needed.

and even then, ratios do not solve the hardest of problems such as what should 
be the behaviour of a panel that takes up 1000 out of 1280 pixels, then switch 
to a smaller res (say ... 800), then back to 1280? ratios don't help a thing 
here and this is really where the interesting challenge is.

> And then scale the panel (even its
> height) with the screen (resolution) on which it is displayed.

this would be rather surprising for many users (particularly the height)

> Since there is a creative director now, I'm sure he will jump in soon,

this actually isn't an art issue as much as it is a coding and usability 
issue, but input from everyone is very welcome.

> Perhaps we will find a sensible solution, if we start to think of the
> problem in terms of the projected meaning of a panel in the plasma
> workspace in, say, 4.2, 4.3 or even later?

not sure what you mean by this? perhaps you could explain a bit more?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080607/9b5a6ee1/attachment.pgp