Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [atf-dev] Re: Mozilla Perspective needs Problems

Hi Adam. The problem with Mozilla does not normally happen in eclipse. The most recently activated window is placed on the tabs bar and given focus. What I observed was Mozilla hidden on the list to the right. However, I now believe that this was caused by the class-not-found problem: probably the window was not given focus because the creation sequence failed. (I did solve this problem using -clean).

The whole Internet ... sorry I was obtuse, I meant the GEF, EMF list of course. Anytime you use a new tool there are problems. Getting to and over those problems requires some amount of perseverance, esp. given that you have no idea if the new tool is actually going to be a win. Throwing more roadblocks dramatically cuts down the early adopters. You already have built-in issues in having so many third party dependencies, but at least users understand and appreciate them. The rest will just block adoption and frankly the window of opportunity will close very fast for ATF.

Red error markers are standard eclipse and work great. But at this point in ATF your tooltip info is minimal "syntax error". The real error message is only shown on the "Problems" view, which is not visible in the Mozilla perspective. Yes of course users can customize, but only if they know the view exists and how to customize. And eclipse with WTP is so complex now its hard to figure out how. Better to give good defaults.

You asked for suggestions, so here is one: think smaller. The tools for Javascript development are in sad shape: being able to click on an error in the javascript console and end up on a source line in eclipse would be a huge productivity boost; integrating the debugger would awesome. Truly beyond the pale would be dependency analysis. Integrating with J2EE/GEF/EMF/ETC/BLAH isn't going to make anyone pick up ATF because none of that matters for Web 2.0 systems. Ok, some of it matters, or all of it matters some of the time, but the architecture of Web 2.0 systems will be so different that we will need to develop new tools.


At 06:58 PM 6/29/2006, you wrote:

We welcome your constructive criticism, but I think some of what you're seeing is standard Eclipse, such as the fact that our browser, a standard "editor", is just another tab on your screen, and if you have too many, they may be hard to manage. (if I understood your description correctly) Perhaps you're saying you'd prefer a pop-up window for a browser? It's something we've considered, but it's a practice very much frowned upon in Eclipse UI land, and frankly I don't even know how to implement it in the SWT.

As for the install, perhaps you can qualify what you mean by "the entire Internet"? Are you complaining about the fact that you have to be connected when doing an install? (Some have run into this unexpectedly and we should have documented it better?) Or are there just glitches in the install itself? (We've experienced these also) We would of course like to make the install more seamless. As for GEF, EMF, etc., these are prereqs of WTP, the project we base ourselves on, and are fairly standard Eclipse components. Orthogonal to AJAX, yes. It's an implementation "detail". I too appreciate that it seems a bit heavy.

Red error markers in the editor are handled pretty much in the standard Eclipse way. We thought it made sense to leverage existing mechanisms and UI paradigms rather than create new ones. This is a good thing for some users.

For the error you're seeing with the empty editor and the MozillaCloseListener thing, did you follow the instructions and do an "eclipse -clean"? (Yes, we too wish this were not necessary... and I hope it's not someday)

Anyhow, if there are specific things you can suggest, we'd be happy to consider them.

Adam Peller
IBM Emerging Internet Technologies

atf-dev mailing list

John J. Barton  email:  johnjbarton<at>

Back to the top