Community
Participate
Working Groups
Many clients are looking for a gridlayout similar to SWTs. You should be able to specify a number of columns, and have the children wrap from left-to-right inside the container based on their columnspan attribute.
I could give it a try. We have a very simple grid layout in our project - so I could implement more generic one.
I think that clients want the SWT behavior for familiarity, unless you can provide reasons why a different behavior is better.
Created attachment 14505 [details] Draw2D version of GridData
Created attachment 14506 [details] Draw2D GridLayout
Created attachment 14507 [details] An Example for Draw2D GridLayout
The above attachments are straight port from SWT to Draw2D of GridData and GridLayout, together with a GridLayoutExample, which is done in the style of the draw2d layout examples. I'm working on a more advanced GridLayoutExample2, to emulate the SWT GridLayout example, as it easliy allows for experimentation with individual GridData settings for Grid members.
Created attachment 14522 [details] GridLayout, GridData and GridLayoutExample Updates Files included in the attachment are GridLayout.java, GridData.java and GridLayoutExample.java The GridLayoutExample demonstrates dynamic creation of child Figure, as well as the selective modification of their layout GridData properties. You can also play with the Layouts overall properties, ie numColumns, margins and spacing
Created attachment 14523 [details] GridLayout, GridData and GridLayoutExample Updates
I just used the GridLayout for my GEF editor and found a small bug. If I put figures with borders in the layout the size is not calculated correctly. To fix the problem I put the following lines at the end of the GridLayout.layout(IFigure container, boolean move, etc.) method: ... Border border = container.getBorder(); if (border!=null) { totalDefaultHeight += border.getInsets(container).getHeight(); totalDefaultWidth += border.getInsets(container).getWidth(); } return new Dimension(totalDefaultWidth, totalDefaultHeight); }
Hi, will these classes be imported into Draw2d? Or are there any blockers? I also have a project using draw2d where we are using these classes, and would like to know the status of this.
This code will not make it into the 3.1 release. Several things are not quite integrated into the draw2d way of laying out. For example, the "flush cache" flag. Also, there are possible issues with borders and relative coordinate.
I'm probably on my own on this one but I think I'd like a GridLayout that is dissimilar to SWT's GridLayout. Normally when I think GridLayout I think of an HTML Table. If I set the width on a figure in a column I would expect it to be propagated to the other widgets in the same column. Basically I'd like to have a column to interact with. Then if a width is supplied via a hint to an individual widget it would size itself in the context of the column. For me the problems really start occuring when I start spanning rows/columns. The following code will create 3 columns but I want the figure that starts row 2 to span the width of the first 2 columns and for it to be truncated if necessary. In order to do this properly with the existing code I'd have to calculate the widths of each column, add them together, and set that on my spanning figure instead of it being a part of the behavior of the GridLayout. What happens is since the spanning figure is wider than the sum of the widths of the figures in the first row it creates blank space in the first row instead of truncating the spanning figure. Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); FigureCanvas canvas = new FigureCanvas(shell); Figure content = new Figure(); canvas.setContents(content); content.setLayoutManager(new GridLayout(3, false)); //Row 1 content.add(new Button("bunch of text in a button")); //$NON-NLS-1$ content.add(new Button("bunch of text in a button")); //$NON-NLS-1$ content.add(new Button("bunch of text in a button")); //$NON-NLS-1$ //Row 2 content.add(new Button("bunch of text in a button")); //$NON-NLS-1$ content.add(new Button("bunch of text in a button")); //$NON-NLS-1$ for (int i = 0; i < 5; i++) { GridData data = new GridData(); if (i == 3) { //Set Row 2 col 1 to span 2 cols data = new GridData(); data.horizontalSpan = 2; content.setConstraint((IFigure) content.getChildren().get(3), data); continue; } //Set all other cells to be 50 pixels. data = new GridData(); data.widthHint = 50; content.setConstraint((IFigure) content.getChildren().get(i), data ); } shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); I'm not complaining as I think the GridLayout provides value but I'm curious if others are looking for this type of functionality as well. I was thinking of mocking this up with the current code but wanted to make sure that there's no way possible to do this with the current code and if the ones in the know think that it would be impossible with the current code. Also I'd like to make the suggestion that when this code does become a part of the draw2d library that the default widths and spacing be set to 0. The SWT layouts are pretty inconsistent in this area and 5 seems arbitrary to me.
I ended up creating my own layout but wanted to point out a few places in the GridLayout algorithm that seem to provide good opportunities for optimization. 1. There's a loop at the beginning of the layout method that ensures that a GridData exists for all children. It seems like this could be moved into the main loop thus reducing one loop over all children. 2. There's a structure named 'grid' that is an in memory representation of the grid in the loop below the comment 'Build the grid'. It's reallocated every 4 iterations. This is done via System.arraycopy. A better guess at the size of this could be made initially before the loop by taking the size of the children and dividing by the amount of columns and then adding 1. This won't be exact but it will initialize the grid to at least the size that it would take for all the children to be laid out if they didn't have any horizontal or vertical spanning. I didn't get too far into the code but these were the intial things I saw.
The Draw2D GridLayout was originally done to be a Draw2D version of SWT's GridLayout. The code was pretty much a direct port of that layout manager, replicating it's coding style. And to this end, it served it's purpose. I was loath to optimize it before I could get it working and it's on the back burner at the moment. I do think there is a strong argument for a separate layout manager inspired by HTML Tables. Most people know and understand that layout paradigm very well, and it is used, I believe, to a lesser degree in the Forms API.
Grid Layout is important for Graphical Modeling Framework project. Currently we have two options: make this layout a part of GEF (more preferable for me) or copy layouting code into the GMF runtime part and make this layout a property of GMF (sounds strange since this is a generic layouting algorithm and should be a part of GEF like all the rest of graphical libraries had this functionality). Can somebody estimate the possibility to fix this request in next release? Even better – in next bugfix release. We have to alight GMF plans with GEF in this case.
Alex, could you attach a mockup of the layout you are trying to achieve. This would help prioritize this work by showing that it can not be done with the existing layouts.
Hi, The simplest and most common case is UML "folder" figure, requested in GMF news group a lot of times. Having requirement that it should be resizable and that the top-left part of the "folder" should in any case take half of the total width, this figure naturally targets some grid-based layout. Regards, Michael
A folder could be created using the BorderLayout, with the tab in the TOP position, and its figure might use left alignment and/or be partially transparent. I'm not saying we don't need GridLayout, we do! But, if the requirement is a folder or tabfolder, it might be a better use of time providing a reusable figure in GEF, than migrating a layout that is overkill for such a use case. The tricky part would be allowing customization of how the folder and tabs paint.
Hi, Sure, it is obviously possible to implement just-a-folder using border layout. It is the reason I wrote about <i>requirement that [...] the top-left part of the "folder" should in any case take half of the total width</i>. It was just a simplest case of ratio-based requirement I was able to imagine. I doubt it is possible to express any relation between width/heights of figure components using set of actually available layouts, and it seems to be the common task. Regards, Michael
So, taking into account last Michael’s explanation can somebody finally answer are these use-cases important for GEF or should we put this part of the code into GMF runtime (if GEF is not going to absorb this layout)?
I will add this as a plan item for GEF for 3.3.
Hi Team, There are a couple of things Asim needs to do to contribute this code to GEF: 1) The code must have the correct license and copyright statement. See http://www.eclipse.org/legal/copyrightandlicensenotice.php 2) Contribution Questionnaire: Prior to committing a significant contribution of content to an Eclipse Foundation project, the committer must fill out this questionnaire and submit it to the Eclipse Management Organization (EMO) for approval. In addition to the EMO, the relevant PMC must also provide a technical review and approval of the contribution. Follow the link to find out more about what we mean by "significant contribution". Bug fixes or minor enhancements do not require PMC or EMO approval. Asim, are you still out there to answer some questions for me so I can get the documentation started?
Anthony, Just let me know what you need answered and I'll get it answered. I'll also update the license and copyright statement headers once you get the answers you need.
Great Asim. I need to confirm that you wrote 100% of the code in this contribution. Then I need: Name Organisation Phone Number E-mail Thanks!
We need to ensure that when this code is committed that it contains the correct copyright notices and license statements. Specifically, the contribution as it has been received is apparently based on SWT code but yet the copyright notices from that code were removed. As a matter of etiquette not to mention a legal requirement of the EPL (no copyright notices should be removed), this should not happen. The original copyright and license notices should go back in and the copyright notice ("and others") and the contributors log should be updated to indicate the additional authors.
Created attachment 53414 [details] GridLayout files with EPL header The correct copyright notices and EPL headers have been added to GridData and GridLayout. One has been added to GridLayoutExample as well.
Hi again, I forgot to do some record keeping on this Bugzilla. I submitted the Contribution Questionnaire to the Eclipse Foundation on November 7 2006 with the information Asim has provided to me directly. I am told that there is a queue of 140 items at the foundation. 1) We need to look at our existing JUnits to see what we need to add for this new layout. 2) We have a FlowLayoutExample and ToolbarLayoutExample in the draw2d examples, we should create a similar GridLayoutExample. I do not think (1) and (2) should block this contribution. I will add (1) and (2) as new Bugzillas once we have the code aproved, but if anyone has any comments we should track them in this Bugzilla.
Received foundation approval and have committed to HEAD for 3.3. (In reply to comment #27) > 2) We have a FlowLayoutExample and ToolbarLayoutExample in the draw2d examples, > we should create a similar GridLayoutExample. The contribution did have an GridLayoutExample.
*** Bug 108964 has been marked as a duplicate of this bug. ***
