3 ms·

svg patterns: https://www.w3.org/TR/SVG/pservers.html https://www.w3.org/TR/SVG/pservers.html Not sure where svg vector-effect is (perhaps svg 1.2) but it loo

svg patterns: https://www.w3.org/TR/SVG/pservers.html https://www.w3.org/TR/SVG/pservers.html Not sure where svg vector-effect is (perhaps svg 1.2) but it looks like the value "non-scaling-stroke" is supported everywhere except IE. Also-- does Qt have an equivalent of devtools can ship with the app so that the state of the view can be queried, mutated, and REPL'd in the user's running instance?

jcelerier 9y ago
Gradients are supported, patterns not (yet) : https://blog.qt.io/blog/2017/07/07/let-there-be-shapes/ https://blog.qt.io/blog/2017/07/07/let-there-be-shapes/ > Also-- does Qt have an equivalent of devtools can ship with the app so that the state of the view can be queried, mutated, and REPL'd in the user's running instance? Depends. There is Gammaray which can connect to a Qt process (including remotely, quite useful for embedded) & where you can change properties of your objects on the fly : https://www.kdab.com/development-resources/qt-tools/gammaray/ https://www.kdab.com/development-resources/qt-tools/gammaray... For live reloading, it isn't proposed by default in shipped applications but there are many ways to do it : https://fr.slideshare.net/ICSinc/how-best-to-realize-a-runtime-reload-of-qml https://fr.slideshare.net/ICSinc/how-best-to-realize-a-runti.... The IDE nowadays does it for instance : http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creator-4-3/ http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat.... However, in my experience on live reloading (with QML, Unity3D and Python), it only works well with environments that don't interface to native code. Else it's way too easy to leave some state hanging in a bad way in a DLL (and then you get undebuggable crashes upon undebuggable crashes). Likewise, there is no REPL provided (since it's declarative in nature... there are no "instructions" being executed directly, only reactions to actions). But implementing your own takes a few lines. I wonder what its point would be though.
- jancsika 9y ago
  > However, in my experience on live reloading (with QML, Unity3D and Python), it only works well with environments that don't interface to native code. Else it's way too easy to leave some state hanging in a bad way in a DLL (and then you get undebuggable crashes upon undebuggable crashes). Live introspection/DOM mutation has been a life saver. For example, there was a strange change to the Gnu/Linux font stack that ended with fonts on Ubuntu 16.04 that measured significantly wider than on Windows, OSX, or even older Gnu/Linux distros. Seeing the computed value of the font in devtools gave us our first sanity check that indeed we were looking at the same font on all systems. Measuring the font by injecting a quick script into devtools showed the relevant symptom of the font stack discrepancy that we could then check for and workaround. (It also served as a check that the computed value above was indeed the correct one.) Interpreted frontend language meant pulling the code change and simply running again from the dev environment. (Admittedly a small benefit over recompiling, but a benefit nonetheless.) There's actually a decent counterexample of a similar set of problems in a separate branch of the software that uses the old Tk canvas interface. Since it has no (easy) introspection tools to gauge what's going on with the fonts, there was instead a 100+ message thread of people comparing screenshots and staring at zoomed-in pixel differences. > Likewise, there is no REPL provided (since it's declarative in nature... there are no "instructions" being executed directly, only reactions to actions). But implementing your own takes a few lines. I wonder what its point would be though. For one thing, it means not having to guess or predict which state might be relevant to a bug report. I can give a user a script to inject and then get back what the result is on their system. I've probably solved a handful of bugs this way, so it's definitely useful.

jcelerier 9y ago

Gradients are supported, patterns not (yet) : https://blog.qt.io/blog/2017/07/07/let-there-be-shapes/ https://blog.qt.io/blog/2017/07/07/let-there-be-shapes/ > Also-- does Qt have an equivalent of devtools can ship with the app so that the state of the view can be queried, mutated, and REPL'd in the user's running instance? Depends. There is Gammaray which can connect to a Qt process (including remotely, quite useful for embedded) & where you can change properties of your objects on the fly : https://www.kdab.com/development-resources/qt-tools/gammaray/ https://www.kdab.com/development-resources/qt-tools/gammaray... For live reloading, it isn't proposed by default in shipped applications but there are many ways to do it : https://fr.slideshare.net/ICSinc/how-best-to-realize-a-runtime-reload-of-qml https://fr.slideshare.net/ICSinc/how-best-to-realize-a-runti.... The IDE nowadays does it for instance : http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creator-4-3/ http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat.... However, in my experience on live reloading (with QML, Unity3D and Python), it only works well with environments that don't interface to native code. Else it's way too easy to leave some state hanging in a bad way in a DLL (and then you get undebuggable crashes upon undebuggable crashes). Likewise, there is no REPL provided (since it's declarative in nature... there are no "instructions" being executed directly, only reactions to actions). But implementing your own takes a few lines. I wonder what its point would be though.

jancsika 9y ago
> However, in my experience on live reloading (with QML, Unity3D and Python), it only works well with environments that don't interface to native code. Else it's way too easy to leave some state hanging in a bad way in a DLL (and then you get undebuggable crashes upon undebuggable crashes). Live introspection/DOM mutation has been a life saver. For example, there was a strange change to the Gnu/Linux font stack that ended with fonts on Ubuntu 16.04 that measured significantly wider than on Windows, OSX, or even older Gnu/Linux distros. Seeing the computed value of the font in devtools gave us our first sanity check that indeed we were looking at the same font on all systems. Measuring the font by injecting a quick script into devtools showed the relevant symptom of the font stack discrepancy that we could then check for and workaround. (It also served as a check that the computed value above was indeed the correct one.) Interpreted frontend language meant pulling the code change and simply running again from the dev environment. (Admittedly a small benefit over recompiling, but a benefit nonetheless.) There's actually a decent counterexample of a similar set of problems in a separate branch of the software that uses the old Tk canvas interface. Since it has no (easy) introspection tools to gauge what's going on with the fonts, there was instead a 100+ message thread of people comparing screenshots and staring at zoomed-in pixel differences. > Likewise, there is no REPL provided (since it's declarative in nature... there are no "instructions" being executed directly, only reactions to actions). But implementing your own takes a few lines. I wonder what its point would be though. For one thing, it means not having to guess or predict which state might be relevant to a bug report. I can give a user a script to inject and then get back what the result is on their system. I've probably solved a handful of bugs this way, so it's definitely useful.