[00:00] <aquarius> not much documentation about .qmlproject files -- like, for example, does QtC only read projectname.qmlproject? Or can I create a second one and that gets read too? That'd be quite elegant.
[00:03] <dobey> if you have multiple qmlproject files, they would be treated as separate projects
[00:03] <dobey> ie, when you go to "open project" in qtc, you choose the .qmlproject file
[00:05] <dobey> i'm /still/ not quite sure what you're trying to do. if this is for the ucs thing, then the thing to do to make it work properly in both places, is to have your tool add stuff to the .qmlproject's importPaths, and ensure that the components get propertly isntalled into the respective lib/$arch directories, when the click gets built
[00:05] <aquarius> yep
[00:05] <aquarius> I agree.
[00:06] <dobey> or better, have your tool pull them into a lib/ structure, so you don't have to add all the separate import paths for each component and keep it updated (having arch-dependent paths in qmlproject file is not a great idea)
[00:07] <aquarius> that's the plan, roughly, yep
[00:07] <aquarius> I don't want to add arch-dependent paths to .qmlproject either, but I'm not sure it's avoidable.
[00:08] <aquarius> huh
[00:08] <aquarius> it already *has* arch-dependent paths in it.
[00:09] <aquarius>     importPaths: [ "." ,"/usr/bin","/usr/lib/x86_64-linux-gnu/qt5/qml" ]
[00:09] <aquarius> so I can't really go wrong with adding "./lib/x86_64-linux-gnu" to the end of that.
[00:09] <aquarius> anybody who commits .qmlproject to source control and then checks it out on a different machine with a different arch is *already* screwed.
[00:10] <dobey> oi
[00:10] <dobey> wtf is /usr/bin in there
[00:11] <dobey> oh well
[00:11] <dobey> i should probably go eat and look wantingly at more car parts or something
[00:11] <aquarius> right, that solves the problem for pure qml stuff, anyway
[00:11] <aquarius> I need to actually implement it :)
[00:11] <aquarius> next step: work out how to do this same thing for cmake and qmake based projects.
[00:11] <aquarius> and then I'm good.
[00:12] <aquarius> cheers, pal; that was helpful
[00:12] <dobey> add cmake/UbuntuCompoinentStore.cmake
[00:12] <dobey> :)
[00:13] <aquarius> I believe that's exactly the plan, but I'm not good with makefile stuff, so I shall look at that tomorrow :)
[04:25] <jmgallo55> hello everyone
[04:27] <jmgallo55> can anyone point me to a place for new developers using Ubuntu SDK?
[09:58] <aquarius> Elleo, ping about making an extension plugin :)
[10:10] <Elleo> aquarius: pong :)
[10:11] <aquarius> Elleo, do you have a clear idea in your head of how to build a QML Extension Plugin (http://doc.qt.io/qt-5/qtqml-tutorials-extending-qml-example.html#chapter-6-writing-an-extension-plugin) for all three architectures (arm, amd64, x86)?
[10:12] <aquarius> and if so, do you fancy spending a little time building a tiny one and setting it up as a downloadable component to my instructions that I can experiment with? :)
[10:15] <Elleo> aquarius: sure
[10:16] <aquarius> Elleo, cool. Invent a component of your choice; what it is is up to you :)
[10:16] <Elleo> aquarius: although, you can actually get something straight from the SDK to play with if you create a new app and choose "simple ui with c++ extension" iirc
[10:16] <aquarius> well.
[10:16] <Elleo> although it won't *just* be an extension
[10:16] <aquarius> I have done precisely that
[10:16] <aquarius> and I have a .so file which can run external commands
[10:16] <aquarius> and it can be included
[10:17] <aquarius> but I don't think it's just an extension
[10:17] <aquarius> and I think we should make binary component be extension plugins
[10:17] <Elleo> aquarius: the .so file will be just an extension (if it's based on the sdk template)
[10:17] <aquarius> oh, really?
[10:17] <Elleo> aquarius: but that template also includes an app and ui stuff that make use of the extension
[10:18] <Elleo> which is what I meant by it not being just an extension
[10:18] <aquarius> that's OK -- I can just pull the .so file out
[10:18] <Elleo> yeah
[10:18] <aquarius> which is what I've done, for testing
[10:18] <aquarius> but I agree with you that we ought to have a template which builds these things correctly
[10:18] <aquarius> and puts the compiled files in the correct place for the component store to recognise them
[10:18] <aquarius> I've decided on that stuff not
[10:18] <aquarius> now
[10:18] <aquarius> I think :)
[10:18] <Elleo> yeah
[10:19] <Elleo> I'm not especially familiar with qt creator's template stuff, but I don't mind helping to figure things out if needed
[10:19] <aquarius> I also know what to do to a pure qml project to make it import such a component from a lib/$arch location, hooray
[10:19] <aquarius> I do *not* know what to do for cmake or qmake projects to make them do the same
[10:19] <aquarius> if you do know, that'd be handy info :P
[10:20] <Elleo> afraid not
[10:20] <Elleo> I'd assumed it was all done automatically by some part of the runtime system
[10:20] <aquarius> I may have a bunch of questions for you about that in a bit, then :P
[10:20] <Elleo> rather than being related to the build system
[10:20] <Elleo> perhaps its setting an rpath on the binary?
[10:21] <Elleo> although it wouldn't be able to do that for pure qml stuff
[10:21] <aquarius> nope
[10:21] <Elleo> aha
[10:21] <aquarius> to make an extension plugin available to an app, you put it on the QML2_IMPORT_PATH
[10:22] <Elleo> just glanced at the cmake stuff for one of my projects
[10:22] <aquarius> this happens differently in Qt Creator and in actual deployedness on the phone
[10:22] <Elleo> and it has set(QT_IMPORTS_DIR "lib/${ARCH_TRIPLET}")
[10:22] <aquarius> on the phone, the apparmor wrapper sets QML2_IMPORT_PATH to include lib/$arch
[10:23] <aquarius> in QtC, for pure QML projects, projectname.qmlproject has importPaths set in it.
[10:23] <aquarius> I don't know how it's done for cmake or qmake projects in Qt Creator, though. In particular, QT_IMPORTS_DIR is for compiling, isn't it? Not for runtime inclusion of QML imports.
[10:24] <aquarius> although I may be wrong about that.
[10:24] <aquarius> if it's *already* the case, that's great :)
[10:25] <Elleo> not certain how that's used yet, just poking around a bit at the minute
[10:34] <Elleo> yeah, I'm not sure what's going on; I suspect prodding the SDK folks would produce better results though ;)
[10:40] <Elleo> that QT_IMPORTS_DIR setting is the only thing I can find in the cmake setup that seems in anyway relevant
[10:41] <Elleo> can't find anything much in the way of docs for it though
[10:42] <Elleo> I suspect it might just end up being used to determine where to install plugins
[10:47] <Elleo> aquarius: have to head out for a bit now, but will be around again this evening
[11:03] <aquarius> Elleo, cheers :)
[13:10] <Takagami> G'morning all...
[15:26] <Makalak> popey when is the new porting guide going up?
[15:41] <aquarius> Elleo, nik90_, aha, I can now install binary components in pure QML apps, and install QML components too. Hooray! End-to-end working tests :-)
[15:57] <nik90_> aquarius: wo that's fast!
[15:58] <aquarius> nik90_, not really, man; the original proposal was last February :)
[15:58] <nik90_> aquarius: well what you had in last feb was proposal + demo...now its working prototype work in the past few days
[15:58] <aquarius> nik90_, I'm pushing this stuff to a new branch in the component-store project; at some point when you have time, I'd like to bring you up to date on what I'm doing so you know and can give me thoughts
[15:59] <nik90_> sure
[15:59] <aquarius> when's good for you?
[15:59] <nik90_> aquarius: tonight, I will be out...does tomorrow sound good?
[15:59] <aquarius> it does. I have set aside this weekend to work on this stuff :)
[15:59] <nik90_> cool
[15:59] <nik90_> tomorrow I should be free for the whole day pretty much
[16:00] <nik90_> just ping me when you want to talk
[16:00] <aquarius> Still remaining to do are: correctly handle adding community components to qmake and cmake projects; handle adding curated components to projects (should be easy); document the whole world; deploy the server :)
[16:02] <aquarius> but I can, right now this second, create a new QML app with Ubuntu SDK, type "ucs install sil/GetHomeDir", and then add "import ubuntu_component_store.sil.GetHomeDir 1.0" to my QML file and get a new Launcher {} item which returns my home directory, which pure QML apps can't do.
[16:02] <aquarius> hooray!
[16:02] <aquarius> I think hooray, anyway :)
[16:03] <nik90_> sweet
[17:27] <aquarius> nik90_, am I right in thinking that curated components will only be pure QML?
[17:38] <aquarius> nik90_, on the assumption that that's true, one can now ucs install curated components. :)
[18:08] <nik90_> aquarius: yeah for now curated components will be pure QML since we don't have much people to review c++ components.
[18:21] <stu_> Is r58 the latest versino of  Ubuntu 15.04? I do not seem to get any updates after that, but that release is 16 days old...
[18:22] <stu_> Seems to be the latest entry in the cahnge log as well...
[18:50] <gcollura> stu_, I think the development is on hold due to christmas holidays :)
[18:54] <stu_> Ok, they certainly deserve some holidays -- I was mostly curious as to whether something changed (maybe need to update from where to update).  But looking around a bit more it is probably normal not to get any updates now.
[19:35] <ogra_> stu_, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-touch/ ... after the SDK team messed around with oxide the images are unbuildable since a few weeks now
[19:51] <Makalak> ogra_: these are the main images right, system.img?
[20:38] <ogra_> Makalak, this is the rootfs
[20:50] <julienrbt> https://twitter.com/imslavko/status/551477294137483266 lol :D
[20:50] <julienrbt> ops
[20:50] <julienrbt> sry
[20:58] <nhaines> ha!
[22:32] <Elleo> aquarius: awesome :)