Project

General

Profile

Actions

Feature #875

open

container to catch signals

Added by Boris Nagaev over 12 years ago. Updated over 12 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
Target version:
-
Start date:
06/27/2011
Due date:
% Done:

0%

Estimated time:

Description

Hello,

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()

Actions #1

Updated by Koen Deforche over 12 years ago

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

Hey,

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

Regards,

koen

Actions #2

Updated by Boris Nagaev over 12 years ago

Hello,

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.

Actions #3

Updated by Koen Deforche over 12 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 ?

Regards,

koen

Actions #4

Updated by Boris Nagaev over 12 years ago

Hello!

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?

Actions #5

Updated by Koen Deforche over 12 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.

Regards,

koen

Actions

Also available in: Atom PDF