Add support for using ATP to host custom QML and related assets


Right now deploying custom QML at the Domain level seems to require hosting resources separately on an HTTP server…

Instead of doing that, I really think ATP URLs should “just work” for QML stuff too.

Back with QML and ATP no LOVE for my UI Homeboyz?@AlphaVersionD hit upon the need for example to reference QML Images over ATP.

Taken all the way, ATP should work for the OverlayWindow.source property and for any embedded QML references too (imports, Loaders, Images, WebEngineViews, etc.).

Also, relative paths should resolve naturally as part of any “parent” resource’s ATP directory mapping. That way, self-contained “QML apps” can be developed locally using a file:///subdir – and later be deployed (as-is) into virtual ATP folders.

Here is an example of what I mean by a self-contained “QML app”:

test.js …
// test.js -- Client Script

window = new OverlayWindow({
    width: 400,
    height: 200,
    title: 'Test',
    source: Script.resolvePath('test.qml')
test.qml …
// test.qml -- QML "dialog"

import QtQuick 2.0

Image {
    source: 'avatar.png' 
    anchors.fill: parent
avatar.png …

// avatar.png -- a (binary) image file

And here is one way it could work over ATP:

Given those three assets are uploaded into a directory called /ui:


When I use Ctrl+Shift+o to launch atp:/ui/test.js:


Then both the initial script and any relative resources would be loaded directly from the ATP server:


I realize that’s way simpler said then done, because I finally managed to get a rough solution working for it at the technical level. It would require a lot more TLC to clean up and ready into a pull request though.

So for now, I just wanted to consolidate the ideas alongside an example – and see how many (if any) are interested in this kind of advanced QML/ATP functionality yet :question:


How many?

Looks like BOTH of us Tim. :wink: Unfortunately QML (as stated many times by @ZappoMan) is formally “unsupported” feature of the code base.

I’m not calling bullsh*t but MOST of the HF UI for desktop is well… QML.

-mic dropped-


True - but if we need to replace it with something else… then it’s on us to replace all that UI… If we said QML was a supported feature of our content platform… then it would mean we have to support it “forever” (or at least a very long time)… these are two very different issues.

You can use QML if you want… but…

  1. We likely won’t prioritize bug fixes for it very high
  2. We can remove it on a whim and your content will break.

So - fair warning.


I DO like this statement; because basically you’ve done us the service of preventing pitfalls here. I hope you know I meant no ill-will with it.

I don’t own a Vive, but would expect the UI for it to be used with Oculus Touch as well. Can you quickly speak to that?

Thanks in advance.


our goal is that if you stick with our official APIs then you should be able to support all HMDs and hand controllers generically… this is challenge when you consider that each device will have different inputs. We’ve attempted to solve that problem by allowing you direct access to the hardware if you want, but also provide a generic layer on top of all of them that you can develop your UI to.


Maybe QML isn’t the right cup of tea here.

How about making it so ATP assets could be used directly from within HTML5 web views?

I’m thinking more about built-in strategies for Domain owners to deploy UI doohickeys in general (without any external web sever). That way, HiFi Sandbox would still be sufficient for hosting a Domain – even when the operator wanted to provide Guests with some custom affordances at the UI level.


With all due respect to you guys at the HF Engineering table (I’ve met most of you) I would sincerely appreciate a more specific recommendation. I’ve survived here by looking at your examples and your examples use QML. If QML is not the way forward I ask you as leaders to provide specific recommendations as guidance.

Should we begin a transition to Overlays? WebWindows? I’ll also be asking @james_hifi as a fellow javascript creator what techniques he would employ.

I think the root issue here is beyond that of QML, but rather, ATP and what hopes and dreams people like myself and @humbletim have in mind.