664451 - Need to support partial viewports for Maemo virtual keyboard

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Florian Hänel [:heeen]]

Attachment: fixes vkb on maemo

when the virtual keyboard covers the bottom half of the screen, we need to support partial viewports to render only the upper (visible) part of the screen.

This patch introduces a viewportAnchor member to the OGL layer manager to faciliate this. Additionally we must take this into acdcount when doing scissor calls.

Also includes some Maemo widget transformation fixes.

Comment 1

[Florian Hänel [:heeen]]

Attachment: fix for all 4 rotations

Some more reasoning why we need this.
On Maemo/Meego as it stands, windows of a single application are composited through an already existing gl context that is owned by a MWindow, which should never be moved or resized. Instead, our child windows move within a virtual scene that is drawn *within* this GL context.
In most other windowing systems the gl context moves with the window that contains it, in Meego however, our child windows move within the context.
Until now we assumed that GL viewports are rooted at the bottom left corner with (0,0) when doing glScissor or glViewport calls. Now however, if we want to draw child windows, we need to take into account that the GL context root lies outside of our window widget.

As for the virtual keyboard: It is layered on top of our window and we want to resize our window and put it into the remaining space so all gui and content text fields remain accessible through the virtual keyboard. This requires the above mentioned changes to the viewport system.

Comment 2

[Florian Hänel [:heeen]]

:jrmuizel voiced some concerns on changing the viewport as I suggested. I investigated a bit more on the possibility of moving the gl context. You can move the top level widget on meego albeit quite unreliable. For example, using setGeometry will only resize the widget and after going into the task switcher and back it will have moved as well. It strikes me as something that you shouldn't do.
Another option is to embed the QGLWidget that provides the context within another QGLWidget. This works more reliable but adds another level of complexity and nested widgets. If we were to follow this path I'd suggest to ditch the MWindow/MGraphicsScene/MSceneWindow architecture altogether.

I'd apreciate it if Jeff could elaborate on why changing the viewport is a bad idea because I think for now this is a passable solution.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #2)
> I'd apreciate it if Jeff could elaborate on why changing the viewport is a
> bad idea because I think for now this is a passable solution.

The main problem is that it spreads the complexity for handling a situation that's unique to Meego to common files. I don't have a good alternate suggestion as I'm still trying to understand the architecture here.

As I understand it:
- We have gl context that is shared with other consumers like the VKB.
- We need to be careful not to stomp on other content that's been drawn into this gl context.

Can you point me to some documentation about the rules when drawing to this common context?

Comment 4

[Florian Hänel [:heeen]]

The VKB is not drawn in the same context. It is just that resizing the top-level window is not supposed to happen in Meego. Therefore the gl viewport is always the whole screen in size.
With the MeegoTouch stuff having landed things changed a bit again; It works almost completely correct: We resize the Tabchildren instead of the main window apparently. they are rendered correctly, but you can't pan up after having panned down. Also the form helper previous/next buttons are out of view, meybe because they are drawn in main-window coordinates instead of tabchild coordinates.

Comment 5

[Joe Drew (not getting mail)]

Florian, if you're still interested in fixing this (as Mozilla doesn't have a ton of interest in Maemo/Meego any more), please reopen this bug.