[Development] Suggested method to distribute QML library
hi all,
I am developing a library with set of QML components . It will be shared on
Github. I would expect people use it via `git submodule` instead of coping
those QML files to their source tree and install to QML module path.
As now the default project created by QT Creator uses resource file to
manage QML files. I would like to provide a resource file to let user to
include and get the library works. That should also simplify the software
build and installation process.
However, QT Creator can not recognise the import path with qrc schema.
The syntax highlighting and auto completion do not work.
For example,
import qrc:/mylib
MyLibComponent {
}
QT Creator will put a underline in MyLibComponent . But it could be
compiled and executed.
Any suggested method to solve this problem / distribute a QML library , so
that user can bundle the library inside their app easily?
Thank for any advise.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method.
2014-09-04 12:44 GMT+03:00 Richard Moore r...@kde.org:
On 4 September 2014 10:29, Allan Sandfeld Jensen k...@carewolf.com wrote:
On Thursday 04 September 2014, Richard Moore wrote:
On 3 September 2014 20:25, Thiago Macieira thiago.macie...@intel.com
wrote:
How is it represented in HTML5?
Just do it the same way.
I'm a little unsure that I understood. Could you please clarify what
did you mean by represented in HTML5?
XMLHttpRequests have existed in JavaScript and HTML5 for years. How do
they do
this?
I actually looked at the specs (both level 1 and level 2) the other day
and
OPTIONS * isn't mentioned at all.
At least in WebKit, it is an allowed method for open(), eg.
xhr.open('OPTIONS',..)
Yeah, the spec mentions OPTIONS, just not the special case of sending an
OPTIONS * request.
Rich.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Thank you everybody for your responses!
According to w3c XMLHttpRequest class does not support OPTIONS * request.
Most likely it will not be supported soon.
Please see mailing list thread by using the following link for more
details:
http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0457.html
Do you mind to leave OPTIONS * request behind until it is available in
w3c specification?
There is one more thing. Should we care about cross-origin resource sharing
protocol? If I got it right, XMLHttpeRequset should perform OPTIONS
preflight request before real cors request. Please see links below for more
details:
http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0
Does it make sense to have separate method for OPTIONS request in
QNetworkAccessManager if it is the case (like for get or post)?
--
Best regards, Valery
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method.
On 09/06/2014 01:19 PM, Валерий Котов wrote: There is one more thing. Should we care about cross-origin resource sharing protocol? If I got it right, XMLHttpeRequset should perform OPTIONS preflight request before real cors request. Please see links below for more details: http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 Does it make sense to have separate method for OPTIONS request in QNetworkAccessManager if it is the case (like for get or post)? From the docs: * QML's XMLHttpRequest http://qt-project.org/doc/qt-5/qtqml-javascript-qmlglobalobject.html#xmlhttprequest does not enforce the same origin policy. = you don't care about cross origin requests, much less preflighting. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt::WA_PaintOnScreen Changes
On Sat, Aug 23, 2014 at 12:40 PM, David Narvaez david.narv...@computer.org wrote: I was ready to create my bug report with sample code etc, and came across https://bugreports.qt-project.org/browse/QTBUG-26358 which seems to be related because I was able to confirm paintEvent is not called with this flag set. Could somebody take a quick look at that report and tell me if I should add to that report or create a new one? I am just wondering since the bug report is quite old. Ping? David E. Narvaez ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
