[Development] Bit of help for QtWayland on a Raspberry Pi

[Pier Luigi Fiorini]

2015-11-05 10:46 GMT+01:00 Massimo Callegari <massimocallegari at yahoo.it>:

> >>> Indeed they aren't on GL windows. The goal with decorations is to move
> >>> them to subsurfaces and just draw them with SHM, so we don't need to
> >>> do hacks for GL windows like we do in the wayland-egl
> >>> hardwareintegration.
> >>
> >> So what's the whole point of having a compositor if you cannot do
> anything on windows ?
> >
> > What do you mean? You don't need decorations to interact with windows,
> > though they are surely useful.
>
> I mean from the user interaction perspective.
> Let's leave the compositing of multiple applications aside for a moment.
> Normally, a QtWidget application makes use of modal/non-modal windows to
> represent sub-areas of the software (e.g. configurations, preview, status,
> etc)
> If a window doesn't have the OK/Cancel buttons, then you need a window
> decoration to close it.
> Also, it might be necessary to move a sub-window around the screen to see
> what happened in the main window. There you need a title bar to get a grip
> to the window.
> Eventually QML has the same needs when using the Window item.
>
> In general, the point is that with QPA plugins like eglfs, linuxfb and
> wayland it is impossible to use Qt application in some cases.
> That was not the case with QWS, which provided a simple windowing system
> out of the box.
>
> I think it should be somehow considered to reintroduce QWS on top of QPA.
> So QPA plugins would be in charge of purely handling the
> hardware/protocols abstraction and QWS would be an optional layer adding
> the missing pieces to make an application usable on certain QPA (basically
> when the OS doesn't provide a window manager)
>


Window management is available with QtWayland, the client side decoration
is missing only with the brcm hw integration as explained earlier by Giulio.


>
>
> >> Can windows+decorations be treated like GL textures as part of the same
> GL window ?
> >
> > Yes, that's what the wayland-egl plugin does, but as i said it's an
> > hack that nobody bothered to port to brcm, because it fiddles with the
> > GL context state, and that's a thing applications don't usually like.
> > The subsurface approach will fix this problem, i may have something
> > working in a few days.
>
> That would be great news for my use case !
> If you want, I have a user on Gerrit, and in case I can make some tests on
> brcm-eglfs. Just add me to reviewers when the changeset is somehow usable.
>
> Thanks !
> Massimo
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Out of the box experience
http://hawaiios.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20151105/088a828b/attachment.html>