Looking Forward to EiffelStudio 6.1

There's always something interesting in the works here at Eiffel Software but not everyone wants to use betas or worse yet the features are not yet available in any beta. Such is the case for a new tool called the Errors and Warnings Tool. It doesn't take much to think about what this tool's actual function is but it's a necessary and long overdue addition to EiffelStudio.

A number of users have posted feature requests single-line errors or terse errors but there are an equal number of users on the flip side that would be mortified to loose verboseness. We listened to both sides and came up with a solution - to give everyone what the want, without adding to the mountain of preferences there already exists.

I'm posting a little information about the new tool so you can get a glimpse of what to expect in future editions of EiffelStudio. The tool deserves a mention not only because of the new, cleaner UI but the new underlying framework "Griffin".

A Quick Look

The tools is more than a simple composition of the existing Errors Tool and Warnings Tool, it actually hosts many features other IDEs lack in similar tools. It can display all errors and warnings in a single list, provides basic and advanced filtering of content and provide quick access to an error/warning context.

The Errors and Warnings Tool isn't currently available in any interim release so for now you'll have to suffice with eye candy.

So here it is, working inside my version of EiffelStudio.

Shows there are warnings and errors but warnings are not visible because the '1 Warning' button has been toggled. This is an example of the basic filtering. Note that the error is expanded to show both the terse and verbose error information.

Show both errors and warnings with a quick tool-tip instead of expanding the error.

Like everything in EiffelStudio the errors, group, class and features can be picked an dropped anywhere. Even the tooltips can be picked and dropped. Alternatively you can CTRL+RIGHT CLICK on a contextual item open that item according to the set editor preference. More lazily you can simply double-left click on the item to take you to the error directly using the same editor preference as CTRL+RIGHT CLICK. Could you need any more ways to show an error/warning's context?!

The images show errors coming from an EiffelStudio compilation, denoted by the compilation icon in the second column. In the future we'll be providing different errors and warnings from different places from within EiffelStudio. All errors are completely managed independently of each other or an be logically grouped so when a tool is closed it takes all of it's post errors and warnings with it, if the error and warning information is only applicable when the tool is visible.

This is by no means a final representation of the UI, we're just starting. There are filters to add, better single-line errors to create and UI tweaks. As I said earlier the tool is worth a mention because of the underlying core that makes this tool possible. It's a new proof of concept framework for EiffelStudio called "Griffin". Griffin is in it's infancy but I hope to see it expand with every release of EiffelStudio.

Once the tool is available inside EiffelStudio, Griffin will be available for you to look at and use if you so desire.

What's Griffin?

Griffin is the new live service-based mechanism inside EiffelStudio. It's actually based on a framework I developed during the EiffelStudio 6.0 release cycle. It's a simple way of abstracting implementation into proffered services. Once proffered services can be attained by any arbitrary part of EiffelStudio, as long as it has access to a service provider.

Because of the abstraction service allow completely disparate parts of a system communicated with each other in a more free for all fashion. Currently, for the editor to communicate with the debugger the editor has to know how the debugger works. If the debugger changes it interface the editor has to be update. Breaking interfaces are not the only problem, for the editor to communicate with the debugger the developer has to delve into the debugger's code to find out how it works, what needs to be initialized, etc. Griffin imposes simpler interfaces that expose only necessary functionality so it's much easier to work with. Then what happens if we completely change the debugger and introduce a whole host of new classes to interact with? A maintenance nightmare, that's what!

Ease of use is just one of the goals of Griffin. The framework is service based to all consumers of a service are aware that the service may not be available. Querying for a service from a service provider doesn't guarantee a client will actually get it, although it's unlikely. Respecting the nature of services, a service-based feature developed late in a release cycle that has to be removed to meet the deadline can be removed. Removal of a service is as simple as not registering the service, effective by commenting a single line of code. As a case example; the Errors and Warnings Tool is base on a service call the Event List Service', used to log events inside EiffelStudio. If for some reason the event list service is removed at the last minute all the tools that log to the event list and all the tools that receive notifications from it still function, albeit with limited functionality.

The true highlight of the framework is actually implementing all services using [almost] full deferred classes. With the implementation deferred and clean interfaces EiffelStudio can be broken into components. Breaking the environment down into components or modules makes it easier for other tools to interact with each other and, paves the way to an external extension mechanism.

That's all I'm going to say about Griffin right now as I'll post more details on a blog/tutorial later.

Look for the tool in the next coming weeks.