(almost) Pretty drawers with QML

I spent the last couple of days getting to grips to QML for integration into my project. I’ve written a fairly neat drawer widget (with an accompanying drawer chest) for containing further widgets. The code is, as usual, on my github repository, along with the accompanying images used to render the tabs.

The aim was to produce a container (the drawer) that worked as part of a set that could be opened and closed by clicking on the tab. Only one container should be open at a time and the transitions should be pretty and informative. Running the code in qmlviewer gives good results that achieve pretty much what I was after:

qmlviewer -opengl drawer_demo.qml

yielding the image at the top of this post.

The problem I’ve encountered is when I try to use that qml view inside a QDeclarativeView (the subject of previous posts), instantiated from within Python. This code, drawer_test.py, is included in my github repository as well, and the code should just run (assuming the dependencies are installed correctly). The code is intended to just load drawer_demo.qml within a QDeclarativeView, and so I would have hoped that it would be identical to using qmlviewer.

Three problems are apparent – one glaring and the other two more subtle. A screenshot is shown below:



The glaring problem is the image transparency failing to work, being filled with black. This is visible most obviously on the scrawled face, which should show the orange rectangle behind it, but also on the images used to make the tabs. The transparency is working on some level as evidenced by:

The first subtle problem is the scene being a couple of pixels smaller than expected, so the object disappear off the side. This is apparent on closer examination of the bottom right corner (the full top corner of the tab is not visible):

Also apparent here is a one pixel wide grey border – the total reduction in size is 2 pixels in both dimensions. The QDeclarativeView object is resized when the its container widget is resized, with dimensions given by the parent. I suppose this could be the problem, but I can’t see anything that defines the QDeclarativeView to have a border around it. Indeed, the top level QML widget is supposed to fill the QDeclarativeView exactly, as dictated by the call to self.qml_view.setResizeMode(QDeclarativeView.SizeRootObjectToView).

The final problem is only visible when the drawer set is reduced width so as not to fill the whole width of the window. This can be done by setting the anchors.leftMargin and anchors.rightMargin within the DrawerChest object of drawer_demo.qml to be something other than zero. Despite (apparently) the dimensions within the defining QML document being set to be identical, the tab is a pixel smaller than the rest of the expanded drawer. This problem is present with the document being loaded by qmlviewer as well as from within python. The following picture highlights what I mean:

with the upper corner zoomed in:

This problem is not always visible. With certain window sizes, the edges line up nicely.

I’m really pleased with QML as a concept, but these problems are starting to get frustrating…

Edit: Following a comment on the QML mailing list, I’ve added a simpler test case to the github repository. This didn’t have the 1 pixel wide border problem, which I’ve fixed in the more full test case (I say more full because the version I originally wrote was a closer match to how I’m using it in practice, allowing for arbitrary drawing to the OpenGL background). This was apparently down to QGraphicsView acquiring a style that automatically adds a border. Its a simple fix with: self.setStyleSheet(‘QGraphicsView { border-style: none; }’) within __init__ for GraphicsView.

The problem with the image having a black background is apparently down to a driver bug. It seems to work fine on my laptop.

Advertisements

About Henry Gomersall

I'm a engineer wanting to make things actually useful. I'm someone that wants to drive technology and ideas to be helpful for everyone. I'm someone that realises the disconnect between technology and utility and I hope to correct that...
This entry was posted in Programming. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s