EchoStudio3 Beta2 Status Update (with screenshot)

tliebeck's picture

I've been working intensively on the next beta of EchoStudio3 as of late. The original plan was to make beta2 a mild upgrade from beta1 and send it out shortly after Echo3's recent beta8. That's changed a bit. EchoStudio3 beta2 is now a very significant release, with much of the feature list for EchoStudio 3.0 having been pushed into it.

Notable features include...

The style sheet editor has been redesigned to display list of styles within a hierarchy, rather than showing all styles at once. The previous strategy had issues when large numbers of styles were present, as well as ensuring newly added styles were placed on screen. In all, I thought it was a bit confusing. The new approach lets you sort styles by either name or style type.

Another big item going into beta2 is undo/redo (multiple-level) for both the form editor and style sheet editor. The form editor bit is almost complete, but I still need to add the same (very similar) functionality to the stylesheet item.

Additionally I'm looking into packaging EchoStudio as an Eclipse feature with an update site, as the current "old style" deployment/installation strategy leaves much to be desired.

The overall goal is to make EchoStudio *much* more refined and pleasant to use. I may or may not put up a test release here before the beta.

tliebeck's picture

(No subject)

a.schild's picture

Very good idea about showing

Very good idea about showing the styles as a tree.

Make sure it works on OSX and non Echo based Apps setups

Tod,

great to hear that EchoStudio is getting a face lift!

There are a number of issues that need to be fixed as follows:
1) Pasting text into an edit field e.g. label text doesn't work properly- the pasted text ends up in the source code. (this may be a OSX issue)
2) The preview doesn't always work - especially if you are using a project setup that is slightly different to a default Echo app e.g. we're using the maven (m2) plugin. We had a thread about these issues before (http://echo.nextapp.com/site/node/5821). We'd be happy to test any version to see if we can fix these problems as they are very annoying
3)Would it be possible to explicitly state the classpath for scanning for components? - currently the editor scans the projects class path.

Cheers
Eddie

tliebeck's picture

#1 is solved, by a fairly

#1 is solved, by a fairly fundamental change to the Form Editor: it's no longer directly coupled to a Java editor. In 3.0b2, you'll open ".form" files to see the form editor, and the ".java" files will bring up the standard-issue Java editor. Changes in the form editor will still be immediately reflected in the Java editor when it's open. One way to think of it is that the "source/form" tabs which were contained inside the form editor are now simply top level tabs in the main Eclipse multi-document interface. This obviously cures all cut/paste issues as described in #1.

Component scanning has been improved. We now specifically find the JDK in use and eliminate it from the classpath, which increases performance considerably versus 3.0b1 (it's near instant on a new project). That said, if you have a bunch of project dependencies, it might still be slow. Do you think a preference to only scan the current project make things better? An ideal solution might be to only scan projects that have Echo on their classpaths...think that can be done but not sure if there would be any issues. Will look into it.

Will certainly work with you on second item. Still think I need to add code to ensure ECHOSTUDIO_HOME is always set. The "variable initializer" (or whatever the Eclipse term is for the thing that's supposed to ensure those are set) doesn't always seem to cut it.

Great... sounds like a big improvement

#1 fixed is great as it was a pain in the ... :)
#2 I think you can basically assume that most people won't have a standard echo app layout - i.e. lots of people use mvn and the m2 plugin. Currently, EchoStudio is very sensitive to the project setup - I would have though that the plugin should be independent of the project's classpath except for rendering components found on the classpath - in that case the editor should give a clear error: Class "X" not found - are you sure you have it on your classpath?
We'd be very willing testers as we're using ES a lot at the moment on OSX and XP so we can certainly do lots of testing - so let me know how we can help to resolve the issues

#3 Hmm... probably only scanning the classpath of the project should be enough as you need to have the components on the classpath in order for it to compile. Currently all projects in the workspace are scanned? Is that correct?

Some other ideas for improvements:
#4 If you encounter a problem during scanning then please log the class that caused the problem to the Error log - e.g. a class without a default ctor or missing class. During scanning the classes are flashed on the screen but it's impossible to read them - and trying to figure out which class caused the problem is not easy.
#5 It would be nice to have a slightly different display of the components found e.g a table instead of a tree where you can sort by package, classname, type etc as I often find you have to do a lot of scrolling to find the correct component.

tliebeck's picture

Another update..I've been

Another update..I've been working fairly non-stop on this. Almost there.

Form and StyleSheet editors have full undo/redo support. Form and StyleSheet editor UI overhauls are done. Additionally added the capability to display style properties in the component property editor (they appear in a different color, and the feature can be disabled if you like). There are literally dozens of other improvements as well.

I have a couple more bugs to clear out, but the big remaining challenge is the structural/distribution update, i.e., making the product into an Eclipse feature and providing an update site. I currently have it completely torn apart to do this, and am hoping to provide better support for swapping in your own Echo version. This is a bit tricky to do given that bits of EchoStudio depend on Echo as well.