This question already has an answer here:
Use custom class as Q_PROPERTY
(1 answer)
Closed 5 months ago.
Is it possible to expose class as Q_PROPERTY?
(I know how to expose native variables.)
In my case, I want to handle chunk of data that change at the same time, and I want to render it at the same frame.
Is it possible?
Generally speaking, yes you can. As long as your custom class uses the Q_OBJECT or Q_GADGET macros, you can use Q_PROPERTY on this custom type.
For better understanding, have a look on this documentation: https://wiki.qt.io/How_to_Use_a_Custom_Class_in_C%2B%2B_Model_and_QML_View
Let's say you are implementing wrappers for QDir and QFileInfo and that you have implemented both Dir and FileInfo as QObjects. Then to return the FileInfo in a method your code would look like this:
FileInfo* Dir::fileInfo(const QString& fileName) const {
FileInfo* fileInfo = new FileInfo(fileName);
QQmlEngine::setObjectOwnership(fileInfo, QQmlEngine::JavaScriptOwnership);
return fileInfo;
}
What the above code snippet is doing is creating a new FileInfo QObject but if the reference count of this QObject falls to 0 then we're allowing the QML/JS engine privilege to garbage collect it when it needs to be. The code snippet doesn't show the qmlRegisterType (or their QML_ELEMENT equivalent) that you would need to register both FileInfo and Dir classes properly, but, I am assuming that you already know how to do this. Because it is a QObject the app can take a copy of this object and can inspect (i.e. reflection) all of its properties and methods at runtime. Intellisense is possible.
The above pattern would be similar to a property as well. I would probably do something like:
FileInfo* Dir::defaultFileInfo() {
if (!m_FileInfo) {
m_FileInfo = new FileInfo(this);
QQmlEngine::setObjectOwnership(m_FileInfo, QQmlEngine::CppOwnership);
}
return m_FileInfo;
}
The above code snippet indicates that the parent class will control the creation and destruction of the request object and that there will be at most one instance created and subsequent access to the property will return the same instance.
As to Q_GADGET. Technically, I would only return a Q_GADGET where you know the entire lifecycle of the object, for instance, in a signal where you want to conveniently provide access to your class and methods. The advantage of this is there is no delegation to the QML/JS engine of your object, nor is there any type register or memory management. This is useful for exposing structures, but, the caveat, is that access to this class is limited to the duration of the signal handler and there is no access allowed beyond this. It is up to the app to copy out any values it needs from the class.
I have been making my C++ functions callable from Qml by following the approach given in Qt documentation.
This require one of these conditions to be fulfilled :
Make the C++ function public and Q_INVOKABLE
or
Make the C++ function a public slot
This sometimes is not in sync with my class design. As in, the function which I want to be callable from Qml, is private according to my class design.
Q1. Can I make a function visible to Qml and still keep it private ?
Q2. Is it my design flaw to expect this kind of behavior ?
Well, if you do something private by design you consider that it's something to be used only within a class. Now you are now asking actually is how can I workaround my design. Obvious answer is - you can make a public wrapper in a class which will invoke your private method and publish this public wrapper into QML, but I would suggest to review design if you face such situation.
I have a class which derives from a QWidget and a model class. Based on my reading, I can't have the model class to derive from QObject.
class PageWidget : public QWidget,
public MyModelClass
{
...
};
the model class MyModelClass already have method to set properties such as setWidth(bool). It seems that I can't use those method directly as slots. If I declare:
QObject::connect(button, SIGNAl(dataChanged(bool)), this, SLOT(setWidth(bool)));
Qt complains at runtime that no slot setWidth(bool). I have to manually add each method into PageWidget, which simply calls the same method of MyModelClass.
Is there any way to bring base methods into slots without redeclaring every method?
QMetaObject (the Qt part that allow you to use slots) and multiple inheritance do not mix. You solution of creating "pass through" slots is a way of solving it. However, if you do not need to do the multiple inheritance, I wouldn't do it. Just from the look of things, it seems weird for a PageWidget to derive from both a Widget and a Model. It probably makes more sense to have it contain the model instead.
Can somebody please explain why do I create in qt public slots but not public signals?
Slots are normal functions, and can be public, private or protected.
Signals are always protected when eventually generated by the 'moc' program.
But note this (from some old Qt 4.7 docs):
Since slots are normal member functions, they follow the normal C++ rules when called directly. However, as slots, they can be invoked by any component, regardless of its access level, via a signal-slot connection. This means that a signal emitted from an instance of an arbitrary class can cause a private slot to be invoked in an instance of an unrelated class.
SLOTS are functions which can be public, private or protected.Functions are called from any where i.e with in the class or outside the class.But SIGNALSare like events and it should be emitted within the class or from the inherited class so SIGNALSare always protected.
This question is meant to apply to interfaces in general, but I'll use AS3/Flex for my language. It should be [mostly] obvious how to apply it in different languages.
If I create a base class, and it extends an interface, there is an explicit contract defined: for every method in the interface, the base class must implement said method.
This is easy enough. But I don't understand why you have the capacity to cast an interfaced instance back to its original base class. Of course, I've had to do this a few times (the example below is very close to the situation I'm struggling with), but that doesn't mean I understand it :^)
Here's a sample interface:
public interface IFooable extends IUIComponent {
function runFoo():void;
}
Let's say I create a base class, which extends VBox and implements the interface:
public class Foo extends VBox implements IFooable {
public Foo() {
super();
//stuff here to create Foo..blah blah
}
public function runFoo():void {
// do something to run foo
}
}
Now, the reason I used the interface, is because I want to guarantee "runFoo" is always implemented. It is a common piece of functionality all of my classes should have, regardless of how they implement it. Thus, my parent class (an Application) will instantiate Foo via its interface:
public function init():void {
var foo:IFooable = new Foo();
foo.percentHeight = 100; //works because of IUIComponent
}
But, if I want to add Foo to the Application container, I now have to cast it back to the base class (or to a different base class):
public function init():void {
var foo:IFooable = new Foo();
foo.percentHeight = 100;
addChild(foo as DisplayObject); //_have_ to cast, because addChild takes a 'DisplayObject' class type
//could also do this:
//addChild(foo as VBox);
}
Wasn't the original intention to hide the implementation of Foo? There is still an assumption that Foo is a DisplayObject. Unfortunately, being able to add the custom object to a container seems impossible without casting.
Am I missing something entirely? Is this really just a phenomenon in Flex/AS3? If you have a container in the base API of a language, and it only allows you to add children of a certain class type, how do you then abstract out implementation?
For the record, this question appears to ask if this sort of operation is possible, but it doesn't really address why it might be bad design (and how to fix it).
2nd Thought:
Abstract Classes:
As Matthew pointed out, abstract classes helps solve some of this: I could create a base abstract class which inherits from the DisplayObject (or, in my case, the VBox, since it is a child of DisplayObject), and have the base class implement the interface. Thus, any class which extends the abstract class would then be required to implement the methods therein.
Great idea -- but AS3 doesn't have abstract classes (to my knowledge, anyway).
So, I could create a base class which implements interface and extends the VBox, and inherit from it, and I could insert code in those methods which need to be extended; such code would throw an error if the base class is the executor. Unfortunately, this is run-time checking as opposed to compile-time enforcement.
It's still a solution, though.
Context:
Some context might help:
I have an application which can have any number of sub-containers. Each of these sub-containers will have their own respective configuration options, parameters, etc. The application itself, however, has a global ApplicationControlBar which will contain the entry-point Menu for accessing these configuration options. Therefore, whenever I add a sub-component to the main Application (via "addChild"), it will also "register" its own configuration options with the ApplicationControlBar menu. This keeps the knowledge of configurability with the containers themselves, yet allows for a more unified means of accessing them.
Thus, when I create each container, I want to instantiate them via their interface so I can guarantee they can register with the ApplicationControlBar. But when I add them to the application, they need to be the base class.
#James Ward, That's definitely something I wish was in the language, probably a interface IDisplayObject. That would solve a lot of issues in OOP display programing in AS3.
In regards the the original question, something I've used in the past, and have seen mentioned on www.as3dp.com is to include a getDisplay():DisplayObject method in the interface, which would typically return "this" by its implementor. It's less than ideal, but works.
#Matthew Flaschen, While we don't have Abstarct Classes native to AS3, common practice is to name the class with the word Abstract ie: AbstarctMyObject, and then just treat it like the abstarct objects in Java and other languages. Our want for true abstarct classes is something the Flash player team is well aware of, and we'll likly see it in the next version of the ActionScript language.
Okay, I'm anaswering generally, because you said, "Is this really just a phenomenon in Flex/AS3?".
In your init method, obviously you're always calling addChild with foo. That means foo must always be an instance of DisplayObject. You also want it to be an instance of IFooable (though it's not clear here why). Since DisplayObject is a class, you would consider using a subclass of DisplayObject (e.g. FooableDisplayObject), that implemented IFooable. In Java, this would the below. I'm not familiar with AS, but I think this shows there's not any general flaw in interfaces here.
interface IFooable
{
public void runFoo();
}
class DisplayObject
{
}
abstract class FooableDisplayObject extends DisplayObject implements IFooable
{
}
class Foo extends FooableDisplayObject
{
public void runFoo()
{
}
}
public void init()
{
FooableDisplayObject foo = new Foo();
foo.percentHeight = 100;
addChild(foo);
}
I think this is a place where Flex's/Flash's API is not correct. I think that addChild should take an interface not a class. However since that is not the case you have to cast it. Another option would be to monkey patch UIComponent so that it takes an interface or maybe add another method like addIChild(IUIComponent). But that's messy. So I recommend you file a bug.
Situation here is that it should be just the other way around for optimal practice... you shouldn't look to cast your interface to a displayobject but to have your instance already as a displayobject and then cast that to your interface to apply specific methods.
Let's say I have a baseclass Page and other subclasses Homepage, Contactpage and so on. Now you don't apply stuff to the baseclass as it's kind of abstract but you desing interfaces for your subclasses.
Let's say sub-pages implement for example an interface to deal with init, addedtostage, loader and whatever, and another one that deals with logic, and have eventually the base req to be manageble as displayobjects.
Getting to design the implementation.. one should just use an interface for specialized stuff and extend the subclass from where it mainly belongs to.. now a page has a 'base' meaning to be displayed (design wise.. the 'base'-class is a displayobject) but may require some specialization for which one builds an interface to cover that.
public class Page extends Sprite{...}
public interface IPageLoader{ function loadPage():void{}; function initPage():void{}; }
public class Homepage extends Page implements IPageLoader
{ function loadPage():void{/*do stuff*/}; function initPage():void{/*do stuff*/}; }
var currentpage:Page;
var currentpageLoader:IPageLoader;
currentpage = new Homepage;
currentpageLoader = currentpage as IPageLoader;
currentpageLoader.loadPage();
currentpageLoader.initPage();
addChild(currentpage);
Tween(currentpage, x, CENTER);