Feature Request: VS.NET/Delphi Layout Manager Support

[willwise]

VS.NET and Delphi (Delphi was first to those to whom it matters) both support a very simple yet extremely powerful layout manager. IMHO it is the layout manager to end all layout managers.

Is there any chance you could implement this layout manager for Eclipse and your designer? Finally there would be a Java GUI development tool that could rival VS.NET or Delphi in terms of ease of use.

Thanks for considering this request.

William M. Wise

PS: If you need any additional information on how this layout manager works please fell free to contact me via email. I'd be happy to follow up by phone if it would help. Also, you can download trial versions of both packages (the VS.NET trial is online only I believe). If you're not sure what's so great about this type of layout manager I'd be happy to fill you in.

[admin]

Ah, William, I am glad to see you again.

Yes, I remember about additional layouts.
I will ask in SWT forum, what people think about adding new layout managers, may be they will suggest some more ideas.

[willwise]

I've made it my one-man crusade to pester every GUI designer project on this issue! In all honesty I think you will get no response from the Java community on this point or maybe just a "shrug of their shoulders". In all honesty, until I tried the VS.NET designer for a project at work I'd have been just as indifferent but now...it's so hard to go back to the confusing mish-mash of layout managers that Java affords versus.

Will

PS: Have I pestered you specifically before or did you see me post a similar message on some other list?

[admin]

I've made it my one-man crusade to pester every GUI designer project on this issue! In all honesty I think you will get no response from the Java community on this point or maybe just a "shrug of their shoulders". In all honesty, until I tried the VS.NET designer for a project at work I'd have been just as indifferent but now...it's so hard to go back to the confusing mish-mash of layout managers that Java affords versus.

Well, will see.
I don't have any problem with implementation, but this will make Designer less "standard SWT compatible" and produce complains from customers.

PS: Have I pestered you specifically before or did you see me post a similar message on some other list?

We discussed layout managers in e-mail.

[willwise]

You could certainly provide customers with a message that indicated that the use of the VS.NET/Delphi compatible layout manager results in the production of non-standard SWT code although if you released the source to the layout manager proper this would certainly allay their fears in regards to portability.

I think the big plus here would be that your product would differentiate itself in a positive way in the area of ease-of-use.

In fact I would make it a central point when marketing your product: "Forget about the myriad layout managers and confusion you are used to when developing SWT GUIs. With Advanced SWT GUI Designer you can choose to use our VS.NET and Delphi compatible layout manager which brings both power and simplicity to the visual GUI development process."

Basically, you could make a direct pitch to existing VS.NET and Delphi developers that want to make the switch to Java that their preferred paradigm for GUI development is available with your product. It may be non-standard from the limited market perspective of those currently developing GUIs with SWT but they can choose to ignore the new layour manager if they choose (I believe they won't once they get the "religion"). The larger market, however, (of VS.NET and Delphi developer) will not see this as a liability but as a way to use their existing skillset with your product.

Just my two-cents!

Will

[admin]

Ok, I understand your point.

We will consider implementation of requested layout in near future.
We just have right now a little more interesting tasks like ApplicationWindow and Eclipse view's support.

[willwise]

Please don't forget to add this feature. I feel so strongly that this is the "right" way to provide layout control that I just had to come back and pester you so as not to let this feature fall off the radar screen. And congratulations on making a commercial success of this plugin...it's a great accomplishment!

Will

[Eric Clayberg]

IMHO it is the layout manager to end all layout managers.

Must be pretty nice. What are its important characteristics?

If you're not sure what's so great about this type of layout manager I'd be happy to fill you in.

Please do. How does it compare to the SWT FormLayout layout manager, for example?

[willwise]

Thanks for the quick response!

Here are the important characteristics of Delphi's and VS.NET's (MS is always one to copy a good idea when they see it...) layout manager:

a) By default, emulates a null (or xy) layout manager's simplicity.

What this means is that you can drag a control from the tool palette and drop it anywhere on the form and you're done. Many simple applications that can define a static form size (like a simple dialog box) will use this layout since it's simple and effective. The downside to null layout is that the controls will not reposition or resize dynamically if the container's size changes.

Although this is the default behavior of the (let's call it delphi layout manager) delphi layout manager it actually achieves this by making controls have a default top, left anchor...

b) Very easy to make controls react intelligently to changes in a container's size.

In a nutshell what this type of layout manager does is allow the GUI designer to draw an interface using the simple XY/null layout approach and then, once it's laid out, rapidy turn it into a dynamic layout that resizes intelligently with the form or container to which it is bound.

The concept of anchors is what provides the power. Examine this diagram:

Top Anchor

Left Anchor [CONTROL] Right Anchor

Bottom Anchor

Each anchor can be turned on or off. Establishing a left anchor will cause the control to maintain it's x coordinate pixel position relative to the container's left edge. Likewise, establishing a right anchor will cause the control to maintain it's x coordinate pixel position relative to the container's right edge. If BOTH a left and right anchors are established then the control's width will expand with the expansion of the container's width.

The top and bottom anchors are in a similar relationship to one another with regard to the control's y coordinate pixel position and height.

The best way to check out how this works in practice is to download a trial version of either delphi or vs.net and give it a shot. I work on thick-client GUIs in VS.NET for my day job and Java for my hobby programming and I' ve never needed more than this layout manager provides on the VS.NET side of the fence and am constantly frustrated by the confusing array of layout managers on the Java side.

For the sake of Java users everywhere who are dangerously unaware of the power of this layout manager approach I implore you to spend some time examinging this layout manager and the benefits it provides.

If I can be of any additional assistence please don't hesitate to contact me via email at will@digitalelite.com.

Thanks for taking the time to read this request but I've been beating this war drum on a few Java IDE sites and there just seems to be no appreciation of the ease of use that VS.NET provides to programmers at the tool level, as opposed to the language level. I've personally seen VS.NET programmers take an interest in Java only to be turned off by having to wrap their heads around a plethora of layout managers that are completely unnecessary to get the job done.

Thanks again,

Will

PS: The VS.NET and Delphi layout managers also support the concept of "docking" but it's not nearly as useful as the anchoring concept as it's implemented in these products.

[willwise]

I just noticed that the diagram in the previous post is malformed. It should be diamond shaped.

Also, another quick suggestion (yes, another one, sorry...). The application I am currently developing in Java relies on the rich capabilities of the Java2D canvas. What would be ideal would be a way to wrap the Java2D canvas as an SWT canvas class. This class would render to the Java2D canvas and do a fast (probably hardware) blit to the SWT canvas. An example of this approach can be found at http://www.holongate.org which works but isn't as simple to use as it should be. Ideally you'd just drag the SWT canvas to the form like any other control and go from there.

<SOAPBOX>
If it sounds like I'm preaching simplicity it's because I am. Coming from the VB and VS.NET world I know that people are loathe to switch to tools that work differently and even less inclined to switch when they are harder to use than they should/need to be. MS treats it's developers like they are cash in the bank and that's exactly what they are. While Java tools are getting easier to use they must match or exceed VS.NET to have any hope of gaining market share at MS's expense.
</SOAPBOX>

That's a long rant for a Sunday afternoon...

Will

[Eric Clayberg]

That's for the explanation. To be honest, this sounds like a description of the SWT FormLayout layout manager (thus my earlier question as to how it compares). FormLayout, while the newest of the layout managers in SWT, traces its roots back more than a decade to IBM's VisualAge Smalltalk (VAST) IDE (where it was the only layout manager) and Unix Motif (from which OTI/IBM borrowed the idea).

We are working on adding FormLayout support to the Designer right now. We actually have more than a decade of experience with this layout manager as you can see in this flash demo of our WindowBuilder Pro for VAST product (which came out in 1994).

[willwise]

That's awesome.

That looks like it although the interface to the anchor (attachment) functionality makes it look more complex than the VS.NET interface. If possible, I'd suggest you implement the forms manager with a VS.NET/Delphi compatability mode and market this point. This might seem to make it markedly less powerful than the full forms layout manager but for some users (VS.NET/VB in particular) less will be more. IMHO the closer you can emulate VS.NET functionality (at least in a compatability mode) the more likely you are to attract these users.

This is indeed the best layout manager I've seen on Java so it looks like I'll soon be a customer. I'm champing at the bit to develop with SWT but I'm currently wedded to Java2D for my current project and swing comes with that territory.

Any plans to allow for generation of SWING interfaces using the same form manager?

Thanks again for the great feedback to my question btw!

Will

PS: I'll officially take you off my list of GUI designer projects to pester.

[Eric Clayberg]

That looks like it although the interface to the anchor (attachment) functionality makes it look more complex than the VS.NET interface.

Keep in mind that demo is of a tool written ten year ago. Also, 95% of the time, the user only needs to make one selection per widget (from the floating attachnment toolbar) to set the attachment styles for all four sides of a widget. The attachment dialog in that demo is only used for special cases and for previewing the results in the pair or thumbnail views.

In VAST, each widget side could take on one of five different attachment styles (none, fixed to left/top side, fixed to right/bottom side, relative/percentage, fixed to a widget). That results in ~625 diferent combinations. When you look closely at the situation, you realize that out of those 625 combinations, less than 20 of them account for more than 95% of the common cases. By capturing those on the floating toolbar (each image is meant to suggest the results), setting the attachments for a widget is generally a one-click operation.

Any plans to allow for generation of SWING interfaces using the same form manager?

Not right away. In our Swing support, we will concentrate on first supporting all of the standard layout managers. We may then branch off to supporting some of the custom ones provided by vendors other than Sun (JBuilder has a couple, for example). I imagine that someone, somewhere has created the equivalent of FormLayout for Swing at some point. If not, maybe we will do that as well.

[willwise]

It looks like JGoodies has designed something similar in it's (now open-sourced) FormLayout class. Here's a link:

http://www.jgoodies.com/freeware/forms/index.html

Hope this helps!

I certainly would still suggest firing up a copy of the VS.NET trial and trying it out.

I can't really compare to your product yet but it's absurdly simple and intuitive as implemented in VS.NET. As usual it's embrace and extend with MS...time to turn the tables on them I say.

http://msdn.microsoft.com/vstudio/produ ... fault.aspx

Will