3 ms·

Very nice. Looking at the source code http://gcompris.net/download/qt/src/gcompris-qt-0.95.tar.xz http://gcompris.net/download/qt/src/gcompris-qt-0.95.tar.xz I

Very nice. Looking at the source code http://gcompris.net/download/qt/src/gcompris-qt-0.95.tar.xz http://gcompris.net/download/qt/src/gcompris-qt-0.95.tar.xz I saw the tech stack is based on QT, so works cross platform. Very nice suite with each game described by concise format, e.g. addition activity is a 6-line file: import "../../core" import "../algebra_by/" Algebra { onStart: { operand.text = "+" } } and metadata here gcompris-qt-0.95/src/activities/algebra_plus/ActivityInfo.qml ActivityInfo { name: "algebra_plus/AlgebraPlus.qml" difficulty: 3 icon: "algebra_plus/algebra_plus.svg" author: "Bruno Coudoin <bruno.coudoin@gcompris.net>" title: qsTr("Addition of numbers") ... Interestingly in the case of Algebra, there seems to be some of the logic running in .js files. I didn't you you can have .js code in QT apps. Very cool! We normally assume to make an app truly cross-platform and reusable we have to use web technology, but this is a good example of a civilized GUI framework helping achieve something super clear and cross-platform.

ognarb 8y ago
If you are interested in qt quick app development, look at the kirigami [1] framework. Make it really easy to create convergent app. [1] https://www.kde.org/products/kirigami/ https://www.kde.org/products/kirigami/
sbuttgereit 8y ago
Actually, as part of my consultancy, I make a fairly substantial income from doing development work with the older (and technically deprecated) Qt scripting framework QtScript (https://doc.qt.io/qt-5/qtscript-index.html https://doc.qt.io/qt-5/qtscript-index.html), which is really just an ancient version of standard ECMAScript with Qt'isms and hooks added. I do ERP work and the ERP that I've been working with is Qt based and is extensible via QtScript. While I'd prefer to be 1) using a different scripting language, and 2) at least a more modern JavaScript flavor, given the nature of COTS ERP software I'll probably see a fair amount of work here for quite some time, albeit niche. The big problem I have these days is finding people sufficiently knowledgeable and willing to take overflow as projects exceed my availability. Old, obscure ECMAScript variants that aren't web focused aren't the draw they once were ;-) .... kinda feels like a less legit version of COBOL... but pays enough to keep me engaged with it.
- ec109685 8y ago
  Are there cross compilers that can take more modern JavaScript and transpile it down to the older version to make it more comfortable for developers?
  - sbuttgereit 8y ago
    The answer is: possibly. I've thought of toying with TypeScript, for example, in this way; some while ago (years) when I looked, it looked like it may well let me target the versions of ECMAScript that QtScript uses. I would expect to have to deal with some misses in that process, but it did look feasible. I ended up not pursuing this because, while I think it would make a much more sane development experience, I don't think I'd interest other more mainstream JavaScript devs (or aspirants) to make sojourns into ERP-land and at the same time I would likely write code much more difficult to understand for those few other people that work this niche as well; also, a substantial portion of the work (upwards of 60%) is in SQL and PL/SQL flavors... again a barrier to many JS devs. I feel I owe it to my clients to leave the code serviceable by those others that have experience working in this environment should I decide to stop doing this work (or they decide not to like me anymore :-) ). On balance, the cons of a transpiling approach outweigh the pros unless I was able to get our community to shift "best practice" to more modern standards; the ISV that produces the ERP is highly conservative, not terribly forward looking, and has a good case of "Not Invented Here" syndrome, and the other practitioners are not exactly the highest level developers... so at the end of the day I don't think I'd get any traction in mitigating the risks of such a change while only really achieving a little more comfort for myself. Good news for me is I do other stuff that this ERP developer thing... :-)

ognarb 8y ago

If you are interested in qt quick app development, look at the kirigami [1] framework. Make it really easy to create convergent app. [1] https://www.kde.org/products/kirigami/ https://www.kde.org/products/kirigami/

sbuttgereit 8y ago

Actually, as part of my consultancy, I make a fairly substantial income from doing development work with the older (and technically deprecated) Qt scripting framework QtScript (https://doc.qt.io/qt-5/qtscript-index.html https://doc.qt.io/qt-5/qtscript-index.html), which is really just an ancient version of standard ECMAScript with Qt'isms and hooks added. I do ERP work and the ERP that I've been working with is Qt based and is extensible via QtScript. While I'd prefer to be 1) using a different scripting language, and 2) at least a more modern JavaScript flavor, given the nature of COTS ERP software I'll probably see a fair amount of work here for quite some time, albeit niche. The big problem I have these days is finding people sufficiently knowledgeable and willing to take overflow as projects exceed my availability. Old, obscure ECMAScript variants that aren't web focused aren't the draw they once were ;-) .... kinda feels like a less legit version of COBOL... but pays enough to keep me engaged with it.

ec109685 8y ago
Are there cross compilers that can take more modern JavaScript and transpile it down to the older version to make it more comfortable for developers?
- sbuttgereit 8y ago
  The answer is: possibly. I've thought of toying with TypeScript, for example, in this way; some while ago (years) when I looked, it looked like it may well let me target the versions of ECMAScript that QtScript uses. I would expect to have to deal with some misses in that process, but it did look feasible. I ended up not pursuing this because, while I think it would make a much more sane development experience, I don't think I'd interest other more mainstream JavaScript devs (or aspirants) to make sojourns into ERP-land and at the same time I would likely write code much more difficult to understand for those few other people that work this niche as well; also, a substantial portion of the work (upwards of 60%) is in SQL and PL/SQL flavors... again a barrier to many JS devs. I feel I owe it to my clients to leave the code serviceable by those others that have experience working in this environment should I decide to stop doing this work (or they decide not to like me anymore :-) ). On balance, the cons of a transpiling approach outweigh the pros unless I was able to get our community to shift "best practice" to more modern standards; the ISV that produces the ERP is highly conservative, not terribly forward looking, and has a good case of "Not Invented Here" syndrome, and the other practitioners are not exactly the highest level developers... so at the end of the day I don't think I'd get any traction in mitigating the risks of such a change while only really achieving a little more comfort for myself. Good news for me is I do other stuff that this ERP developer thing... :-)