Window thumbnail and Javascript

[Marco Martin]

On Monday 03 January 2011, Martin Gräßlin wrote:
> On Monday 03 January 2011 10:33:34 Marco Martin wrote:
> > On Sunday 02 January 2011, Martin Gräßlin wrote:
> > > On Sunday 02 January 2011 17:33:25 Aaron J. Seigo wrote:
> > > > On Saturday, January 1, 2011, Martin Gräßlin wrote:
> > > > > Last but not least I do not see why we would need rotated
> > > > > thumbnails.
> > > > 
> > > > if kwin paints the thumbnail (as opposed to handing over an image
> > > > that the application itself then paints) then if the target on which
> > > > the thumbnail should be painted on is rotated on the screen, the
> > > > thumbnail would also need to be painted rotated.
> > > 
> > > Let me rephrase: why would we need a rotated area with thumbnails? I
> > > just think showing rotated thumbnails is useless.
> > > 
> > > FYI: rotating a window is trivial in kwin - built in feature of the
> > > rendering pipeline. The difficult part would be IMHO the X atom and
> > > calculating the correct aspect in the thumbnail effect. Currently we
> > > use a high-level API call for that.
> > 
> > well, for instance meego hanset doesn't support xrandr resolution
> > rotating at all...
> 
> Please tell me you are joking :-(

unfortunately, not

> > what it does is rotating the qgraphicsview (meaning also that in portait
> > applications will be slower),
> > all for the sake of having the cool iphone-ish rotation animation :p
> 
> I hope they have X Input Redirection. With that we could do the rotation in
> the compositor and don't touch the apps at all. Including more awesome
> animations than what you can get with qgraphicsview or iOS ;-)
yeah, that would be way better

what sucks is that we probably want to support running apps on that platform 
(really, have to) so well, yeahh...


for kwin wouldn't be a problem because when we run our own workspace there it 
could work "in the right way"(tm)

Cheers,
Marco Martin