Re: Design question: Picking event source

[Antonio Coralles <noche suapie reflex at>]

Matthias Kaeppler wrote:

> 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

Hmm, I'm not really sure what functionalty your widget implements, but
if it is some kind of file-browser, why should anybody connect a
signal-handlers from the outside to your internal treeview ? Besides
[this is only my opinion and may be completly wrong as i'm not really
familiar with your problem], if the user of your class should not know
that there lives a tree view inside of it, he shouldn't care about it's
signals.