QtWaylandDev: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Convert ExpressionEngine section headers)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=QtWayland Development thoughts=
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}


Before making an official release of QtWayland, it needs an <span class="caps">API</span> review. Use this page to comment on things that could/should be done.
= QtWayland Development thoughts =
Before making an official release of QtWayland, it needs an API review. Use this page to comment on things that could/should be done.


==Things to do==
== Things to do ==


* <span class="caps">PIMPL</span>ize all public compositor classes so we can make a step toward BC releases
* PIMPLize all public compositor classes so we can make a step toward BC releases


==<span class="caps">API</span>s to add==
== APIs to add ==


* '''ping/pong public <span class="caps">API</span> (shell_surface::ping)'''
* '''ping/pong public API (shell_surface::ping)'''


The compositor should be able to check if a client stops responding. Considerations:
The compositor should be able to check if a client stops responding. Considerations:
'''''' Control how often compositor sends ping
'''''' Make ping() invokable from the compositor API
'''''' Add a pong[ed]() signal when the client pongs
'''''' Add a lastPong property that holds the timestamp
'''''' Add a convenience signal when last pong goes over a certain threshold


* Control how often compositor sends ping
* '''Better QML Property API'''
* Make ping() invokable from the compositor <span class="caps">API</span>
* Add a pong[ed]() signal when the client pongs
* Add a lastPong property that holds the timestamp
* Add a convenience signal when last pong goes over a certain threshold


* '''Better <span class="caps">QML</span> Property <span class="caps">API</span>'''
The generic property API is annoying to use, especially from QML. plfiorini has already started a fix for this: https://codereview.qt.io/#change,52123
'''''' Would it make more sense for the generic properties just to use QWindow instead? Then you could access any QProperty of QWindow.
'''''' How would the QML attached/grouped property look? QQmlPropertyMap or even a private QML support class should be used to make this as pretty as possible
<code>
WaylandSurfaceItem {
windowProperties { // Or just "properties"?
customProperty: "prop" // This?
property string x: "x" // Or this?
}
title: windowProperties.x // Make sure you can bind/update/etc.
}
</code>


The generic property <span class="caps">API</span> is annoying to use, especially from <span class="caps">QML</span>. plfiorini has already started a fix for this: https://codereview.qt.io/#change,52123
== APIs to remove ==
 
* Would it make more sense for the generic properties just to use QWindow instead? Then you could access any QProperty of QWindow.
* How would the <span class="caps">QML</span> attached/grouped property look? QQmlPropertyMap or even a private <span class="caps">QML</span> support class should be used to make this as pretty as possible<br />
 
==<span class="caps">API</span>s to remove==


* '''QWaylandSurfaceItem::clientRenderingEnabled'''
* '''QWaylandSurfaceItem::clientRenderingEnabled'''
Move all rendering-related details to the surface interface, not the item – after all, the surface can back more than one item; the item should not dictate things that can mess up other users of the surface. Also, this <span class="caps">API</span> was eclipsed by changes that mapped directly do the QWindow::Visibility <span class="caps">API</span>, so stopping client rendering can be done by setting the visibility to Hidden. This doesn’t necessarily equate to the original use case though, which was to force a QExposeEvent of 0×0 on the client (hence stopping damage + new frames to reach the compositor). Hiding the window client-side may have unacceptable side-effects, so consider how this can be improved.

Latest revision as of 16:21, 5 March 2015

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

QtWayland Development thoughts

Before making an official release of QtWayland, it needs an API review. Use this page to comment on things that could/should be done.

Things to do

  • PIMPLize all public compositor classes so we can make a step toward BC releases

APIs to add

  • ping/pong public API (shell_surface::ping)

The compositor should be able to check if a client stops responding. Considerations: ' Control how often compositor sends ping ' Make ping() invokable from the compositor API ' Add a pong[ed]() signal when the client pongs ' Add a lastPong property that holds the timestamp ' Add a convenience signal when last pong goes over a certain threshold

  • Better QML Property API

The generic property API is annoying to use, especially from QML. plfiorini has already started a fix for this: https://codereview.qt.io/#change,52123 ' Would it make more sense for the generic properties just to use QWindow instead? Then you could access any QProperty of QWindow. ' How would the QML attached/grouped property look? QQmlPropertyMap or even a private QML support class should be used to make this as pretty as possible

WaylandSurfaceItem {
 windowProperties { // Or just "properties"?
 customProperty: "prop" // This?
 property string x: "x" // Or this?
 }
 title: windowProperties.x // Make sure you can bind/update/etc.
}

APIs to remove

  • QWaylandSurfaceItem::clientRenderingEnabled