Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 397548

Summary:	[client] Provide bounds getter and resize event on Composite wrapper
Product:	[RT] RAP	Reporter:	Tim Buschtoens <tbuschto>
Component:	RWT	Assignee:	Project Inbox <rap-inbox>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P2	CC:	tbuschto
Version:	2.0
Target Milestone:	2.0 RC1
Hardware:	All
OS:	All
Whiteboard:

Description Tim Buschtoens

2013-01-07 05:59:04 EST

Currently the public client API includes a wrapper/proxy for Composite widgets with one method "append( element )". For custom widget development it is often necessary to also know the (inner) size of the composite, and to get informed when it changes.

Providing getSize might not suffice, as the composite might have a border that needs to be substracted. In Java we would use "getClientArea", but that would need to respect the padding, which is unkown on the client.

Regarding the event, this would require a new API to add/remove listener. Here we should keep in mind that we might want to merge the ClientScripting API with the public client API. 

I would propose Composite#addListener( type, listener ), where type could be a string (like jQuery/qooxdoo) and/or a number (like SWT/Clientscripting, using constants). The listener could be a function and/or object, like in DOM:
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener
(Having context might be useful if one doesn't like closures, and might also be supported in CS one day.)

An Event object is currently not required, but could be provided later.

Comment 1 Ralf Sternberg

2013-01-07 07:03:42 EST

+1 for add/removeListener as suggested, except that I don't like event type numbers. If we provide constants (where?), those constants could be strings as well, couldn't they?

I guess a getClientArea method is exactly what we should provide, what about synchronizing this information with the client for Canvas and Composite?

Comment 2 Tim Buschtoens

2013-01-07 08:41:41 EST

(In reply to comment #1)
> +1 for add/removeListener as suggested, except that I don't like event type
> numbers. If we provide constants (where?), those constants could be strings
> as well, couldn't they?

My only concern is that we have this generic Event object in ClientScripting (EventProxy.js) which has a "type" member which is a number (using the SWT object constants). If we would want use this Event object later, what would the value of "type" be?

> I guess a getClientArea method is exactly what we should provide, what about
> synchronizing this information with the client for Canvas and Composite?

Should be doable.

Comment 3 Ralf Sternberg

2013-01-07 09:21:14 EST

I forgot that we have those constants in clientscripting/SWT.js already. Anyway, considering the constants as public API doesn't mean that their values are fix as well. What about changing them to strings? We don't have to copy the bad parts of SWT.

Comment 4 Tim Buschtoens

2013-01-08 04:49:47 EST

Fixed with commit a40e099062751b7bfd6d8e23791cf12b84e1b0e4 using Stings for the event type.