[MonoDevelop] Fatwa: bring the XCode error/warning reporting to MonoDevelop.
m.j.hutchinson at gmail.com
Thu Oct 15 00:58:45 EDT 2009
On Wed, Oct 14, 2009 at 1:42 PM, Miguel de Icaza
<miguel.de.icaza at gmail.com> wrote:
> Hello guys,
> Fatwa: to implement the XCode Message Bubbles system for Warning/Error
> reporting in MonoDevelop.
> When I am not using a 56 inch monitor, the usability of the
> error/warning window is terrible: it takes a lot of valuable space.
> I understand that lacking any guidance, we went with the VisualStudio
> like solution where a pad pops up that shows the error list and we cycle
> through those with a hot key.
> I am loving MonoDevelop, but it needs a few tune ups like this to make
> my experience glorious. And this is coming from a hard-core Emacs
> The XCode folks actually found a great solution. Instead of taking up
> the screen with the pad, they show a tooltip on the status bar showing the
> number of warnings and error with two small cute icons. XXX <warning
> icon> YYY <error icon> clicking on either one will show the error/warning
> But after a build, XCode will jump right to the first error/warning, and
> will add a couple of visuals to your editor:
> On the right side: the warning or error icon, including the message for the
> error. If the message does not fit on the screen, the bubble shows below
> the current line; If it fits partially, the bubble wraps around.
> On the left side: the warning or error icon, clicking on this icon would
> toggle displaying the bubble.
It may be a good idea to implement "message bubbles" (that's what
Xcode calls them), but we need to refine the design for MD rather than
blindly copying. I'm sure there are subtleties in their approach that
are not immediately obvious and may take time to find and fix. In
addition, the wrap/ellipsis behavior is complex and IMO likely to
regress the text editor. As we're a couple of weeks away from 2.2,
this will have to be a post-2.2 feature, so let's discuss how we can
get this right, while we wait for 2.2 final to branch.
Some things to think about and discuss before implementing:
* The wrap/ellipsise behaviour in Xcode is complex. Sometimes Xcode
wraps the message onto the *next* line (that still has text on it, and
Xcode has a rendering bug when you type on that line), sometimes it
wraps it onto a "new" line, sometimes it ellipsises, sometimes a
mixture. Tuning this behaviour could be difficult.
* Xcode has a View->Message Bubbles menu for toggling on/off the
various kinds of bubbles - warnings, errors, static analysis warnings.
* There needs to be some kind of logic for deciding when to hide the
bubbles (maybe a short while after the line or an adjacent line has
been altered) or they will stick around and get in the way. Of course,
the aforementioned menu could be used to bring them back.
* Xcode puts error/warning icons in the left margin/gutter that can be
clicked to toggle the bubbles on/off.
* The error pad is obviously necessary to show you where the errors
are outside of the current document, else you would have to scroll
through all your files (or know the hotkeys) to find bubbles. So the
pad is still the primary place for new users to *find* the errors.
* How should bubble rendering interact with breakpoint markers or the
current line highlight marker?
* Does the purpose of bubbles conflict with the squiggly underlines
for on-the-fly syntax errors? Should we still use squiggly underlines
for all on-the-fly errors (e.g. spelling, syntax, etc) and save
bubbles for compile-time errors?
* We've discussed getting rid of the status bar, or making it more
subtle (like Google Chrome's popup status bar) since it's currently
mostly redundant and wastes space. Will adding more things
(warning/error counts) to the status bar make the problem worse by
making it harder to get rid of the status bar, or solve that problem
by making it less redundant?
* VS also doesn't pop up the build/error pads unless the build fails -
it simply shows the build progress in the status bar - and people have
been asking for MD to copy this for a while.
More information about the Monodevelop-list