On the GTKmm first documentation example and on the more complex clock example, they are inhering the public Gtk::DrawingArea
to build they application.
#ifndef GTKMM_EXAMPLE_MYAREA_H
#define GTKMM_EXAMPLE_MYAREA_H
#include <gtkmm/drawingarea.h>
class MyArea : public Gtk::DrawingArea
{
public:
MyArea();
virtual ~MyArea();
protected:
//Override default signal handler:
bool on_draw(const Cairo::RefPtr<Cairo::Context>& cr) override;
};
#endif // GTKMM_EXAMPLE_MYAREA_H
Is possible to use the DrawingArea
by composition, instead of inheriting it and overriding the on_draw
virtual method?
I would like to do so, to not mix my methods/attributes with the DrawingArea
methods inherited from the base class Gtk::DrawingArea
. Therefore, when I am accessing something, I know explicitly I am using something on my creation, because there are only my stuff on my class definition. While by inheriting stuff from Gtk::DrawingArea
, I cannot be sure whether it is my stuff or Gtk::DrawingArea
stuff, unless I know everything which is defined on Gtk::DrawingArea
.
Short answer: no (at least for what seem to be your concern), it was not designed this way.
Longer answer:
I would like to do so, to not mix my methods/attributes with the DrawingArea methods inherited from the base class Gtk::DrawingArea.
Public inheritance vs composition should not, in my opinion, be chosen over such criteria because they have a very clear conceptual meaning. A child class publicly inheriting from a base class means (most of the time, see below) that the two classes have a is-a
relationship. Composition means a has-a
relationship.
So to answer your question, you should ask yourself what exactly is the relationship between the two classes (your own and Gtk::DrawingArea
). Is your class some kind of drawing area? If so I would suggest public inheritance. Does your class have (or contain) a drawing area? In that case I would suggest composition.
If you violate these concepts you will almost certainly end up with hard to use and inconsistent classes and differentiating between which method is from which class will be the least of your concern.
Finally, note that there is a lot more than what is written here on inheritance and some exceptions exist. See this post for a more in depth discussion.
Hope this helps!