Re: Design question: Picking event source

[Matthias Kaeppler <nospam digitalraid com>]

Antonio Coralles wrote:

> What kind of signals do you want your clients to catch ? What about
> providing your own signals ?
> Antonio

The signals I'm talking about are all Gtk+ signals. I also have my own 
signals, but it would be a waste of resources to redefine the ones which 
are already defined by gtkmm.

For illustration, one example would be the button_press_event signal.
Since the TreeView covers all the area of the ScrolledWindow (except the 
scrollbar), this event is fired by the TreeView, so the user would have 
to connect his handlers to the TreeView, but he isn't supposed to know 
that there's a TreeView working inside.
The ScrolledWindow also has this signal, but it's never fired, because 
mouse clicks are already caught on the TreeView layer.

Meanwhile I have thought of a possibilty to overcome this problem:
I could override (hide?) the method signal_button_press_event() of the 
ScrolledWindow, by simply returning 
tree_view.signal_button_press_event(), and such just delegate the signals.
However, I'm not sure if it's a good idea to that, because IIRC the 
signal_* methods are not declared virtual in the base classes, so my 
ScrolledWindow type would just hide the base class implementation 
instead of overriding them. If polymorphism should come into play, I'll 
run into problems.

For further illustration, here's some (pseudo-)code:

class MyWidget : public Gtk::ScrolledWindow {
   Gtk::TreeView m_view;
public:
   // I guess this definition hides
   // ScrolledWindow::signal_button_press_event()?
   Glib::SignalProxyN<...> signal_button_press_event() {
      return m_view.signal_button_press_event();
   }
};

This approach has two problems:
First, you can't separate anymore between mouse clicks in the window and 
in the treeview (which is in my case not too interesting).
Second, if someone should use objects of MyWidget through a base class 
pointer, the base class method is called, because I didn't override, but 
hide it. This would lead to strange behavior, since again no events will 
be fired.

--
Matthias Kaeppler