[Monodevelop-devel] Brainstorming for 2.4 code quality

[Michael Hutchinson]

On Mon, Aug 31, 2009 at 7:19 AM, Mike Krüger<mkrueger at novell.com> wrote:
> Hi
>
> We should make monodevelop easier understandable & extendable.
>
> I think we should do some brain storming about stuff that we encounter
> during our daily work with the source code. I begin with the
> view/pad/workbench/language binding system.
>
> * The way it's used it's not build for.
>
> - For example the workspace window should wrap the gui the view content
> is displayed in (for example tab page or window) - therefore it should
> be a DockItem directly. It should contain a collection of view contents
> (for example text editor/forms designer) - but stetic doesn't use this,
> it does it's own. I don't know if the subviews are currently used.

The ASP.NET designer uses a subview. There used to be an subview for
previews of HTML docs in MD.IDE, but AFAIK it was removed during
deGPLification.

> - The Layout abstraction was for enabling other layout managers.
> SharpDevelop had a floating layout (think of gimp layout) and a tabbed
> layout (called sdi) - later I got rid of the floating layout, because
> maintaining layouts is error prone. Now we don't need the abstraction
> anymore.

Well, a floating layout would be useful for the Mac, if anyone cares
to implement it.

> * Workbench: We've IWorkbench, Workbench (not implementing IWorkbench
> or inheriting DefaultWorkbench), DefaultWorkbench (not inheriting from
> Workbench). Easy to explain ?

Nop, eit's a mess.

> * Language bindings:
>
> - They provide parsers/refactories - but no ambiences ?
> - They provide comment tags, but we get comment tags from the syntax
> modes.
> - They bind to a 'language' and can ask if a file is a source code file
> ore not - they're not using our newer mime type system (inconsistent!)

Agreed.

> - Maybe they should be attached to a ProjectDom or ViewContent to allow
> easier access.
>
> When 2.2 is released we should put some effort on building a better
> framework people can work with. I would like that everybody looks out
> for possible code issues. At first not finding solutions, only
> collecting possible issues. When we've time and collected enough we can
> go over to design work.
>
> We can need some input from anyone who implemented an addin for
> monodevelop. The core team works too long with the code base. Therefore
> we're used to it and don't see most possible issues.

True. I think that in particular people implementing non-.NET language
bindings are having problems with some of our .NET-centric APIs. Maybe
we should solicit opinions from them.

There are some areas that I would like to overhaul too:

* file/project templating system: I've really been stressing it,
particularly with ASP.NET / ASP.NET MVC templates, and it makes a lot
of things difficult.

* new file/project dialog: these have poor usability and organization.

* code templates. I'd like to have APIs for addins to add code templates.\

* There are many places in the project system where a "configuration"
string is passed around and it's unclear whether it's a project
configuration (and should be looked up with GetConfiguration) or a
solution configuration (and the project configuration should be looked
up with GetActiveConfiguration).. This API really needs usability
improvements.

I would also really like to do a full gendarme run against MD and
review the results. Maybe this will catch some bugs or API issues. Of
course, it would help if the CodeAnalysis addin were complete...

It would also be very useful to improve the MD docs. I think there's a
good case to be made for using XML documentation -- see my previous
email on the topic.

-- 
Michael Hutchinson
http://mjhutchinson.com