We Keep Coding

Design a ContextMenu with a TreeView functionality

I want to design a ContextMenu with a TreeView functionality. I didnt found anything how can be done. I want to design a custom TableMenu (that button at the end of table header which can show hide the columns), using a treeView structure in ContextMenu, so the user can show/hide a group of columns, like 1-3, 4-6, and so on, or any kind of grouping, but still keeping the one by one show/hiding. The best way would be a tree structure, so if the user hides the parent all of its children are hidden and vice-versa.
Is there any possibility to adapt somehow the TreeView into ContextMenu?
I would like something like this with CheckBoxes for instance:
Each parent node would be an item that represents a group of columns, and each child would be a column.
P.S.
I know how to create and add a custom ContextMenu as tableMenu (I have got it from here : https://gist.github.com/Roland09/d92829cdf5e5fee6fee9) , I'm interested in how to set a tree structure to context menu instead of the list structure.
I also know that I can add the parent like a "simple" item to the context menu, then handle as a parent, but then I Have to implement every functionality of a TreeItem, but I prefer a much simpler way if it exists.

How to load a part of composite keeping others static?

I have a form in SWT where I have five different composites based on one parent composite.Each of the composite contains different widgets like a single textbox / a combo box / a combination of text and combo etc.
Now the problem is when I click on the button I want to change my third composite to carry a different widget keeping others static.Now I can't reload from the beginning as I want current values of the other widgets to be displayed.How can I fetch only that composite,dispose it and create a new widget in place of that.
Creating and hiding the widget is difficult to consider as it is dynamic to at what place we want to redraw.
Here is the snippet.
formComposite=new Composite(parentComposite,SWT.BORDER_SOLID);
formLayout=new GridLayout(5,false);
fromComposite.setLayout(formLayout)
item.create(formComposite) //Here item is the widget (combo/textbox/combination text/combo)
formComposite1=new Composite(parentComposite,SWT.BORDER_SOLID);
formLayout1=new GridLayout(5,false);
fromComposite1.setLayout(formLayout)
item1.create(formComposite1))
formComposite2=new Composite(parentComposite,SWT.BORDER_SOLID);
formLayout2=new GridLayout(5,false);
fromComposite2.setLayout(formLayout)
item2.create(formComposite2))
formComposite3=new Composite(parentComposite,SWT.BORDER_SOLID);
formLayout3=new GridLayout(5,false);
fromComposite3.setLayout(formLayout)
item3.create(formComposite3))
formComposite4=new Composite(parentComposite,SWT.BORDER_SOLID);
formLayout4=new GridLayout(5,false);
fromComposite4.setLayout(formLayout)
item4.create(formComposite4))
Now how can I replace item3 with a different item to be created keeping others static in their place?

Assuming you only have one child for each Composite you can just dispose of the existing control and add the new one and then redo the layout.
item.dispose();
item = new Combo(fromComposite, ... style);
formComposite.layout(true);
You may also have to call layout on the parentComposite.

you could do this by using Control.moveAbove() and Control.moveBelow() methods
// create item3replacement
item3replacement.moveAbove(item3);
item3.dispose();
// call layout on parent when all is done
otherwise you will need to write your own Layout to do so.
as you are using GridLayout this will be your starting point.
you need to add a value for an position to GridData and process this in the GridLayout

Magnolia - child component, or area that always contains 1 child component of a specific class

In a Magnolia/Blossom component, is it possible to define and render a child component of another type (or an Area that is defined to always contain exactly one component of a specific type, is prepopulated and has a clean author interface)?
e.g. I have a rich text component. I want to build another component that has an section within it that uses this rich text component. I could create an Area that has a maximum of 1 child components, and only allows this component type, but that would require the author to manually add it each time - plus the author interface is ugly*.
FWIW I'm using Magnolia 5.4.9, the Blossom module 3.1.3 and Thymeleaf 2.1.4.
*I have the following but this is what I'm trying to avoid - it contains 2 wrappers for a single component, plus a redundant 'maximum number of components reached' area

To avoid having editor to create instance of the component manually, you can use autogeneration.
To get rid of green bars in UI ... apart from writing all yourself inside of single component, you can try to examine element IDs to see if you can custom tweak CSS to hide it, but like it will not be possible.

How to create custom list widget?

I want to create custom widget, resembling MS File Explorer thumbnail file view or similar.
The questions are:
1) Should I use/extend Item class? It is not prohibited to extend this class, but simultaneously it is said, that custom SWT widgets are made either of Composite or Canvas. If I want to put image above it's caption, then I probably am to use Composite with table layout. This way I will be unable to extend Item. If I extend Item somehow, then when to decide, how to draw it?
2) Should I implement all input handlers? I.e. so that selection can be moved by keyboard and mouse, multiple selection with Ctrl etc. There is too many code. Can I reuse some premade code for this?

GWT: is it possible to check parent size BEFORE adding next child but AFTER CSS rules are applied to that child?

Imagine we have some parent container. We add children to it, one by one. Children widgets are placed according to some CSS: may be as block elements, may be as inline elements.
A question is:
Can we calculate the supposed parent height and width BEFORE adding next child and manage to insert "SHOW MORE" widget instead of adding next child?
I tried to add ResizeEvent handler to my container. It catches the event, but only at the very moment when child widget is added, but CSS rules are not applied yet! That means that ResizeEvent is caught when all the children widgets are placed one on top of another as block elements, but in fact they should be placed as inline elements. After ResizeEvent Handler runs CSS rules are applied and child-widgets are reordered as inline elements, but this is not causing new ResizeEvents to parent container, which height is small again..
So in fact I want to catch the moment of resizing of my parent container before it happens.. a kind of a "if you add this child - parent needs resize" or "if you add this child - parent size is bigger than ... px" trigger.
So is it possible to solve this task?

You need to wait for the browser to render the new widget before you measure its height:
// add widget to the container
Scheduler.get().scheduleDeferred(new ScheduledCommand() {
#Override
public void execute() {
// measure it here
});

You can do it using following technique:
Make a copy of your parent container. Attach it to the DOM somewhere. Make it invisible for users using some CSS tricks (z-index, margin-left: 10000px, ....) but do not use display:none.
Attach your child to this "invisible" parent first. Override Window.onAttach() for child. Calculate height and width.
Take a decision about what to insert into real parent (this child or "show more" link).
Move your child widget from invisible parent to real parent if necessary.
Hope there is another more simple way to do it.
Calculated height and width will be wrong if your child contain some images, because Window.onAttach() is called before the moment when all images are loaded.

Finally I have found a solution which is good for me:
I create a container with fixed size and an internal container which can spread inside it. The overflow of the top container is hidden. Thus, when I add next widget that cannot be displayed because it is out of the bounds of my top container - well, it is not displayed.. just because overflow is hidden.
The only thing that remains is to insert a "SHOW MORE" widget. To do it I calculate whether the last inserted widget bounds are out of the bounds of top container. I.e. whether the last inserted widget overflows top container, or not. If yes, I insert "SHOW MORE" widget in place if previous (the one before last) widget.
Thats it!