General Update
- It was very easy to start working on the project.
- Built the QBS project with Qt 5.15 (6.3 had issues with a legacy dependency
based on QtScript)
- Tested it with LD_PRELOAD=/Path/To/File.so
Responding to Иван Комиссаров"Maybe Object (or Gadget/smth else since JS has
“object” type already) as it is not a generic Item used in other items would be
better."
Object{} makes sense. I had been using Class{} in my code, although that
seems a bit misleading. Ill make a small list of things that come to mind:
- Object
- Class
- Item
- Gadget
- Schema
- Nest
- Struct
- Sub
Responding to Michael
Syntax:
property MyItem prop
That is an absolutely excellent idea. I prefer this the most because it allows
us to create psuedo-types. Presuming MyItem would be imported, I see only one
small drawback, in that it would also require a seperate file for even small
classifications [That might be neccessary for compilation however]. That would
end up polluting the import section, although probably not in the main
project/product file.
property var feed: Item {
I also agree that this seems to be the most sensible syntax. id: or name: seems
redundant, and makes checking for map key conflicts a bit more complex.
Encapsulation:
"Access into nested items isnt explicitly supported in QML"
Hard to know what you mean exactly, because you can set properties of nested
items. Could you give an example of what is explicitly prohibited?
"If I understand correctly, your items are just typesafe JSObjects"
Sadly I am a bit vague on exactly what is going on in the backend in qbs,
whether that is literal or pseudo javascript being used. Items appear to have a
QMap with Pointers to:
> class Value; // base class
> using ValuePtr = std::shared_ptr<Value>;
> using ValueConstPtr = std::shared_ptr<const Value>;
>
> class ItemValue;
> using ItemValuePtr = std::shared_ptr<ItemValue>;
> using ItemValueConstPtr = std::shared_ptr<const ItemValue>;
>
> class JSSourceValue;
> using JSSourceValuePtr = std::shared_ptr<JSSourceValue>;
> using JSSourceValueConstPtr = std::shared_ptr<const JSSourceValue>;
>
> class VariantValue;
> using VariantValuePtr = std::shared_ptr<VariantValue>;
> using VariantValueConstPtr = std::shared_ptr<const VariantValue>;
When I tested in qbs, I could only produce JSSourceValues though, so maybe? But
when I look at the class, I am not seeing how the source code it stores is
being interprted.
Devils Advocate
"Why has no one needed this in QML thus far?"
That is a very good question. Thank you for asking.
I do not have a perfect answer, because while I have worked on about half a
dozen qml projects, that was around 2016.
From what I remember, QML is far more flexible, with Item{} being its generic
container that can be used in anything.
QBS on the other hand is incredibly static with its items, and so while I can
make my own Probe with its own properties, I can not make a Probe within a
Probe, and so even if I wanted to say set a sub property, it just is not
possible. QML on the other hand can set properties of nested items, I think you
just have to be a bit cognisant of compilation order.
Parser Will Need Work
True and probably a fair bit, but I consider that an afterthought. The parser
has to be fixed either way since its borrowed and a bit misleading.
Thoughts on Existing QBS Code
- The code in general is fairly great quality.
- It conforms to what I have seen in general from formal Qt code, so no
surprises there.
- I do tend to think though that Qt's internal code is a bit messy and which
makes it unweildly ( Better than a lot of projects though )
- And so grasping the internal structure of the API is quite difficult.
- As I have been editting the code, I have been rearranging functions. While I
am unlikely to include that formatting in a patch, if I do share my code, just
a bit of a heads up on the crazy diff. A lot of that is just formatting and
style so I can better grasp the structure.
What are you vague on? [ Spitballing here - Feel free to ignore ]
- Why would the item pool use `std::vector<Item *> m_items;` instead of a QList
( Or QVector ) ? I imagine it was a performance consideration, but it always
puzzles me to see stdlib in most qt code.
- Should Project and Product remain the only top level Items? Or would there be
reason to let GenericItem{} do so also? I am thinking to keep it as is.
- There are three Values -- Item, JSSource, and Variant. I have only been able
to create JSSource when making a qbs file. What are the other two used for?
That is it for now. Thank you for your feedback.
Sent with [Proton Mail](https://proton.me/) secure email._______________________________________________
Qbs mailing list
Qbs@qt-project.org
https://lists.qt-project.org/listinfo/qbs
