Support `SWT.VIRTUAL` for `Composite`

[SyntevoAlex]

In SWT, Composite is very often used as layout container - that is, the user's needs typically are

• Be able to .setVisible() multiple Controls at once
• Be able to group a few controls under some Layout

However, the actual OS control is not needed:

• Background is not set (or set only to match parent)
• SWT.Paint etc is not handled
• Mouse events etc are not handled

There is a number of downsides of actually creating a control:

• Resizing main window is typically slow and blinks quite a bit
• Blinking can be defeated with double buffering, but this makes it more CPU and memory intensive
• Resizing slowness has no sound solutions currently.
• Further, with double buffering, painting overall is more CPU and memory intensive In our software, one of the most used Controls is on 18th level of nesting. This means a lot of temporary OS painting surfaces to paint entire hierarchy.

There are more exotic issues as well:

• Windows seems to have an undocumented limit of 49 nesting levels for Controls.
• See #246 where too many nesting levels caused StackOverflowError when pressing Alt (which is recursively passed to parents).
• In a recent case from our user, N0vaDesktop.exe program goes crazy already with 18 nesting levels and slows down entire system. It does this by repeatedly and recursively inspecting child windows, which causes Windows kernel-side lock to be too busy, which affects all other programs.

The suggestion is to implement something like SWT.VIRTUAL style for Composite, where

• It would still behave as layout container
• It will no longer create an OS control (that is, its children will be connected to next non-virtual-Composite parent instead of Composite itself).

According to my idea, SWT users will use SWT.VIRTUAL manually in each place where they're good with "thin layout container" behavior.

[tmssngr]

I already have tried to reduce the level of nesting a little bit and created nestable layouts. However, recently I've discovered a problem that still is on my todo-list to be fixed: radio buttons that are inside the same composite with other controls, e.g. checkboxes, magically are moved to the end of the tab list. This can be reproduced in SmartGit's preferences dialog, pages "Commands", "User interface" or - even worse - "Standard window" (which contains 2 radio button groups).

[vogella]

Such a feature would be awesome @SyntevoAlex

I have a client who uses tons of Composites just for layouting his widgets and as this client has tons of widgets he runs into no more handlers exceptions. Having a Composite without an underlying widget only for layouting would be great.

[laeubi]

If composites are only created for Layout purpose, then this could maybe easier handled by a layout manager, I'm already working on another layout manager at the moment (not finished yet) but found that this is often a better approach as the "classic" SWT LayoutMangers are often hard to use. If you want to switch visibility for multiple items at once, maybe an ControlGroup class would be more suitable, where one can not only switch visibility, but maybe even enablement of multiple items at once and can add/remove items, e.g.

ControlGroup group = new ControlGroup(control1, control2, control3, ...);
group.setVisible(false);

But without an example what layout / managing requirements are there is a bit hard to guess, using Composite for that seem to me very risky as it has many tasks (e.g. what should be happen for listeners? Parent relative computations) and so on...

[tmssngr]

I already have tried to reduce the level of nesting a little bit and created nestable layouts. However, recently I've discovered a problem that still is on my todo-list to be fixed: radio buttons that are inside the same composite with other controls, e.g. checkboxes, magically are moved to the end of the tab list. This can be reproduced in SmartGit's preferences dialog, pages "Commands", "User interface" or - even worse - "Standard window" (which contains 2 radio button groups).

See https://github.com/eclipse-platform/eclipse.platform.swt/issues/634

[SyntevoAlex]

I see that both @laeubi and @tmssngr prefer Layout approach instead of virtual Composite.

I understand and agree that implementing it in Composite may have some bugs. Still, I think that it's an approach that allows to adjust old code much more easily. Where it fails, code could be left as is or switched to Layout approach.

Either way, I was instructed to not spend time developing the Composite approach.