gistfile1.txt

[15:26:45] <aknight> kkoehne: so are you working on clang-win32 support?
[15:27:05] <peppe> mitchc: it's absolute, but still resolved relatively, so the scheme doesn't change
[15:27:22] <mitchc> peppe: huh?
[15:27:30] <sletta> its absolutly relative :)
[15:27:36] <mitchc> peppe: how can an absolute filesystem path be resolved relative to something?
[15:27:40] <peppe> mitchc: to put it in another way, ti would've loaded the same file even if your qml was in qrc:/foo/bar/main.qml
[15:27:54] <peppe> that's not a filesystem path, that's the path "part" of the URL
[15:28:30] <mitchc> peppe: Image { source: "/home/micurtis/dev/picture.png" } is a filesystem path
[15:28:33] <peppe> it's not
[15:28:39] <peppe> file:///home/... is a filesystem path
[15:28:39] <mitchc> peppe: ?
[15:29:12] <peppe> that's merely a path relative to your QML file, so it gets resolved in the same scheme, and it's absolute because it starts with a /
[15:29:28] <peppe> confused? yes. :( there's already enough magic going on with paths and URLs in QML...
[15:29:37] <mitchc> peppe: i am very confused
[15:30:51] <mitchc> peppe: i can understand it doing it relatively because it's missing some prefix... i mean, it's not intuitive at all, but i can understand it
[15:31:00] <mitchc> peppe: but prefixing qrc:// as well? that's odd
[15:31:44] <mitchc> peppe: i gotta document this weirdness
[15:31:57] <mitchc> the source documentation is a bit too simplistic
[15:32:28] <peppe> what do you mean? if it's relative, it's relative, therefore in the same scheme
[15:32:53] <mitchc> peppe: no, you're right, if it's using the same scheme, it makes sense to prepend the qrc://
[15:33:02] <mitchc> peppe: i just disagree with it doing it relatively in the first place
[15:33:17] <peppe> well, then how do you do it?
[15:33:45] <mitchc> peppe: well, see that it's an absolute path combined with the absence of a scheme and load it as an absolute file:// url
[15:35:14] <peppe> how do you load an absolute path in the current scheme?
[15:35:53] <mitchc> peppe: with a prefix that matches the scheme (qrc:// in the case of qrc)
[15:36:15] <mitchc> peppe: if i'm using qrc for my images, i *always* append qrc://
[15:36:39] <mitchc> prepend*
[15:37:10] <mitchc> peppe: i didn't even know you could leave qrc:// out until now
[15:37:58] <peppe> that's not the usecase I was talking about, though. if you simply want to load something relative to the URL of the current document, whichever scheme it's using
[15:38:32] <kkoehne> aknight: Nope
[15:38:49] <aknight> kkoehne: who is then? :-)
[15:39:00] <kkoehne> aknight: You? :)
[15:39:10] <kkoehne> aknight: I intend(ed) to
[15:39:34] <kkoehne> aknight: But haven't really come around to play with it much more than trying to compile qtbase, only to see it choking on the very first .cpp file
[15:39:44] <aknight> kkoehne: i've played around with it, but per lars' email i assumed someone was actually spending time/money on it
[15:39:45] <kkoehne> aknight: But I heard you had a patch somewhere to overcome this ...
[15:40:45] <aknight> kkoehne: i haven't touched it in a while, but there's a wip on my dashboard
[15:40:53] <lars> aknight: no currently, this is only my wishful thinking... ;-)
[15:41:47] <aknight> lars: fair enough :) i might have some time to work on it for 5.6
[15:42:01] <kkoehne> According to makalino they're also still using the MSVC linker ...
[15:42:13] <aknight> yes. so that's something that needs to be decided
[15:42:29] <aknight> also which make to use
[15:42:48] <lars> aknight: it would be great if we could get to a decent open toolchain on windows.
[15:43:07] <lars> but as long as they are still using the msvc linker, we still have that dependency :/
[15:43:14] <mitchc> peppe: heh, so you can even do Image { source: "picture.png" }, even if the image is in a qrc file?
[15:43:22] <mitchc> peppe: so you can
[15:43:33] <mitchc> peppe: that is odd.. has it always been like that?
[15:43:48] <peppe> can't say it for sure... but I'd say yes
[15:44:02] <peppe> what's the problem? why should that have a special "filesystem" meaning?
[15:44:46] <mitchc> peppe: because i had always assumed that an absence of a scheme prefix meant filesystem, obviously incorrectly
[15:44:56] <aknight> kkoehne: lars: i think ld can be used, eventually lld too. that's probably what we should aim for. that means mingw (or at least binutils + make) installed alongside clang
[15:46:15] <lars> aknight: is that possible? I thought clang produced msvc compatible binaries
[15:47:14] <aknight> lars: you can alternatively produce mingw compatible binaries.
[15:47:29] <lars> really? didn't know that.
[15:47:32] <lars> nice :)
[15:48:55] <aknight> imo the msvc binaries would be better (no dependency on libgcc) as long as lld could do the linking
[15:49:54] <seb_ow> Hello, I'm trying xdg-shell with qt/qtwayland 5.4; it works fine except that when closing the app using the "x" button, the app disappears but it doesn't exit. Any pointer on where to start investigating ? Maybe QWaylandCompositor ?
[15:50:28] <lars> aknight: yes, agree. the main issue is that we need a working linker.
[15:50:45] <mitchc> peppe: hmm, i see that it's already explained here http://doc.qt.io/qt-5/qml-url.html
[15:51:01] <kkoehne> fkleint: Interested? I'm not so much ;) https://bugreports.qt.io/browse/QTBUG-43877
[15:51:01] <qt_gerrit> QPrinter.setPaperSize crash app - https://bugreports.qt.io/browse/QTBUG-43877
[15:51:05] <lars> aknight: a toolchain without the gnu binutils purely based on llvm would probably be easier to manage
[15:51:41] <aknight> lars: definitely. http://lld.llvm.org/windows_support.html <-- progress looks pretty good here, but i haven't tried it in a while
[15:53:58] <lars> aknight: you're right. loks like we should be able to try it all on 32bit. and on 64bit we should be mostly ok as well, as we don't really use exceptions