Our application uses more than 1 shell and the user should be able to reposition them.
To implement a correct resizing behaviour we would need a resize-listener on the display. When i tried to open an feature-request i found out that this was already filed: https://bugs.eclipse.org/bugs/show_bug.cgi?id=201261
I wrote a comment to explain the situation and possible workarounds (and why the can't be implemented).https://bugs.eclipse.org/bugs/show_bug.cgi?id=201261#c4
Are there any workarounds we didn't think about yet or plans to implement this?

Hi Stefan,
I've reopened the bug 201261 and we will reconsider it for RAP 2.1.
Thanks,
Ivan

On 2/21/2013 2:11 PM, Stefan M wrote:
> Hi,
>
> Our application uses more than 1 shell and the user should be able to
> reposition them.
> To implement a correct resizing behaviour we would need a
> resize-listener on the display. When i tried to open an
> feature-request i found out that this was already filed:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201261
> I wrote a comment to explain the situation and possible workarounds
> (and why the can't be implemented).
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=201261#c4
> Are there any workarounds we didn't think about yet or plans to
> implement this?
>
> Best regards
>

Is there any good workaround? As it is a new feature it will be implemented in a new release, but we would need a workaround for 2.0.
We already tested a maximised shell in the background, but the problem was that it was able to get the focus, despite setting NO_FOCUS and attempts to supress the focus-events for this shell with clientscripting and event.doit=false.
Is there any way of preventing this shell from getting the focus?

I'm not sure if this is the same situation, but it sounds similar... we too have an application that needs to respond to changes in the browser size, so that the shell takes advantage as the user enlarges the browser. We also want it to work in a device's browser when the device is rotated (for example), so detection of display size changes is important.

Our solution is to use shell.FullScreen(true), and a resize listener on that shell.

Some of our designs have a minimum size too, so if the browser is too small to show the whole design, we want it scrollable... to achieve this, we have a ScrolledComposite which uses a layout that takes the WHOLE parent shell space, and then another Composite that takes the whole of the ScrolledComposite space, with the ScrolledComposite taking a min width/height according to our UI design.

So the structure is Display->Shell(with FullScreen)->ScrolledComposite->Composite->All the other widgets in the UI.

This seems to work very well in desktop browsers and on devices. The same code also works well for Tabris.

On resize of the FullScreen shell, we also resize the ScrolledComposite and its Composite on the fly.

I may seem a little overkill, but actually it is only introducing 2 additional levels in the structure with the 2 Composites, and is relatively easy to code for.

Sorry if this isn't appropriate for your situation, but thought I would share as it had similarities.

Hi Stefan,
We don't use a separate Shell for the fullScreen... only 1 Shell is 'primary' for us at a time, so we detect resize events on the fullScreen Shell, which actually contains our scrolled composite and widgets in that. Since this Shell is fullScreen, you cannot get focus on any other Shells that happen to be behind in the Z-order, although they are there. I'm not sure that our solution would work for Shells that are NOT fullScreen - suspect not. We do use a few of these, but they are subsidiary dialogs and confirmations most of the time, so don't necessarily need the same treatment. Any 2ndary dialogs like this always have a parent Shell (logically) which is fullScreen anyway, so we can still detect the display resize/rotate on the parent and do whatever we need to its children at the same time.
Hope that clarifies a little.
Best regards, John