Underlying compatibility issue with QObject names
-
So basically what you are saying is that I will need to duplicate string data in order to access Qt objects by name.
Not necessarily. You can just not use the built in QObject
objectNameproperty and provide your own with whatever type you like e.g.class MyQObjectSubclass : public QObject { Q_OBJECT Q_PROPERTY(QLatin1String Name READ name WRITE setName NOTIFY nameChanged) public: inline QLatin1String name() const { return name_; } signals: void nameChanged() const; public slots: inline void setName(const QLatin1String& name) { name_ = name; nameChanged(); } private: QLatin1String name_; }; -
Well that kind of defeats the purpose and is effectively what I just said I would need to do. The purpose is to use the objectName property without wasting extra memory with duplicate string data.
-
Sorry but I don't follow. There's nothing duplicated in the code I gave. You can use
name().data()to pass it intoconst char*expecting APIs. There's no duplication or conversion here. -
Isn't there already a name for the object? objectName() already contains data (a QString). So creating another "name" variable means that there are two strings where I only want one. Unless you are replacing the objectName string. Basically that means there are two different variables that will contain the same string. One in char format and one in wide char format.
-
There is a QString property called objectName, but no one is forcing you to use it. Just leave it empty. Unused string has a size of a single pointer so it's not a big deal. Just use another property in the format you want like i proposed.
-
While it is true that Qt covers a lot of ground one ground it does not cover is graphics engines. It allows use of OpenGL but OpenGL is not in and of itself a graphics engine. My application needs to implement and expand a graphics engine AND host a scripting language interface that allows access to objects both in Qt and the graphics engine. This is why I need an object interface and an object manager that can access object names through a single function from both libraries. I am currently using the Irrlicht engine though I have entertained the idea of OGRE as well. Both of these use string types that allow me to access a const char* to get at the their data while Qt does not. So basically what you are saying is that I will need to duplicate string data in order to access Qt objects by name.
@primem0ver said in Underlying compatibility issue with QObject names:
While it is true that Qt covers a lot of ground one ground it does not cover is graphics engines.
The Qt3D module would beg to differ.
I have entertained the idea of OGRE as well.
The good thing about OGRE is that it's opensource and there it ends. The API is badly designed and the examples are outdated. To top that the documentation is ... pretty thin.
-
@primem0ver said in Underlying compatibility issue with QObject names:
While it is true that Qt covers a lot of ground one ground it does not cover is graphics engines.
The Qt3D module would beg to differ.
I have entertained the idea of OGRE as well.
The good thing about OGRE is that it's opensource and there it ends. The API is badly designed and the examples are outdated. To top that the documentation is ... pretty thin.
This post is deleted! -
@primem0ver said in Underlying compatibility issue with QObject names:
While it is true that Qt covers a lot of ground one ground it does not cover is graphics engines.
The Qt3D module would beg to differ.
I have entertained the idea of OGRE as well.
The good thing about OGRE is that it's opensource and there it ends. The API is badly designed and the examples are outdated. To top that the documentation is ... pretty thin.
@kshegunov
Hmm... well if it performs anything like your 2d graphics engine I want nothing to do with it. Honestly, it looks fairly meager compared to Irrlicht anyway which is what I plan on using. There also doesn't seem to be any built in scene UI support either which is an absolute must. I agree that Ogre 3D made some weird design choices which is why I eventually decided on Irrlicht. -
Hi
Just as a note. Did you ever test unreal engine ?
https://www.unrealengine.com/what-is-unreal-engine-4 -
@kshegunov
Hmm... well if it performs anything like your 2d graphics engine I want nothing to do with it. Honestly, it looks fairly meager compared to Irrlicht anyway which is what I plan on using. There also doesn't seem to be any built in scene UI support either which is an absolute must. I agree that Ogre 3D made some weird design choices which is why I eventually decided on Irrlicht.@primem0ver said in Underlying compatibility issue with QObject names:
Hmm... well if it performs anything like your 2d graphics engine I want nothing to do with it.
I don't have a 2D graphics engine, so I have no idea what you're talking about.
Honestly, it looks fairly meager compared to Irrlicht anyway which is what I plan on using. There also doesn't seem to be any built in scene UI support either which is an absolute must.
If you mean Qt3D, there's no scene at all, the scene is defined by the root entity.
-
@primem0ver said in Underlying compatibility issue with QObject names:
Hmm... well if it performs anything like your 2d graphics engine I want nothing to do with it.
I don't have a 2D graphics engine, so I have no idea what you're talking about.
Honestly, it looks fairly meager compared to Irrlicht anyway which is what I plan on using. There also doesn't seem to be any built in scene UI support either which is an absolute must.
If you mean Qt3D, there's no scene at all, the scene is defined by the root entity.
"Your..." as in Qt's 2D graphics engine. I am talking about the QGraphicsView. That is essentially a 2D graphics engine and it is horrendously slow.
Scene... um... the scene is the collection of objects that is rendered. That is a basic 3D concept. Some 3D API's have scene managers but regardless; the basic issue is that Qt3D doesn't seem to have built in support for 2D widgets/HUD controls for a scene which are a very important aspect of the application I am building.
I looked into a bunch of 3D engines before deciding on Irrlicht. I don't remember much about the difference between Unreal and Unity but I decided they were both not really useful in my project. I need a very portable, very source code oriented and expandable engine. I am not building a game and the user interface for the application is not meant to be created by the engine (though 2D user controls are a big part of what I need). On the contrary, the 3D engine is supposed to be hosted inside a control (widget in qt terminology). There are some other things I need that don't appear easy to do in the engine because it is too high level. Procedural meshes are a very large part of the graphics engine I need to develop.
