Feature #875

container to catch signals

Added by Boris Nagaev about 11 years ago. Updated almost 11 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



Here (#637) it was mentioned, that memory can be saved by using base container (with one signal) to catch events from all children and decode target. I think, it would be usefull, but it is not so easy to realize. It was proposed to write custom JavaScript to decode target, but it should also work in HTML version (and I do not know how).

Could you realize this widget, that had all signals (.clicked(), doubleClicked()...) and can provide target widget as signal argument?

It could be realized by modifying WInteractWidget to have second argument Widget* in all of its signals:

EventSignal< WMouseEvent, WWidget* > WInteractWidget::clicked()


Updated by Koen Deforche about 11 years ago

  • Status changed from New to Feedback
  • Assignee set to Koen Deforche


I like the suggestion. It would only work if JavaScript is available though. But I can see that this could still be useful ?




Updated by Boris Nagaev about 11 years ago


This could be useful even only with JavaScript.

What are the problems with with implementing this for HTML version too?

Wt sources digging is needed to explain it in details, but it seems possible: in HTML version, a click handler (server-side) could emit suitable signals of all parents. To avoid overhead, this can be done only for widget children existing at the moment when signal is connected.


Updated by Koen Deforche almost 11 years ago

Hey Starius,

In theory this would be possible, and perhaps indeed we should consider to support it.

But, in plain HTML, you can only react to button clicks. Therefore Wt will wrap elements in a button which have a click handler. But this does not work recursively: a button cannot be nested in a button. Thus, only 'leaf' widgets can have click handlers. The total space occupied by the union of all leafs is however not the same as the area occupied by their enclosing parents (e.g. padding, divs will automatically take full width, table cells, etc...). The behaviour would thus not be the same (but as a far as supporting non-JavaScript browsers, this is somewhat accepted for several other features in Wt too).

So, this could work somewhat: only WPushButton and WText widgets would get their events relayed to the parent. Perhaps this does fit with the use-case you had in mind ?




Updated by Boris Nagaev almost 11 years ago


So, for example WContainerWidget would be able to catch clicked() signal (using only one instance of WSignal) from all children (or grand-children, etc) of type WPushButton or WText? It would be great!

What about children of type WImage or WAnchor?


Updated by Koen Deforche almost 11 years ago

Hey Starius,

Yes. And I guess also from WImage and WAnchor, but I am not sure about side effects there.

It is not a trivial development since as it is now an ancestor container is not being informed when descendant widgets are added or removed to it, which would be needed to attach event listeners there (in the plain HTML case). Perhaps we should stage it in two phases, first Ajax and then plain HTML fallback.



Also available in: Atom PDF