[Monodevelop-devel] Brainstorming for 2.4 code quality

[Lluis Sanchez Gual]

El dl 31 de 08 de 2009 a les 13:19 +0200, en/na Mike Krüger va escriure:
> 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.

Yes, I agree on that this code can be improved. There is some leftover
code from #D that we are not really using. Some functionality currently
implemented in MD.Ide could be directly handled by our docking system.

> 
> - 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.
> 
> * Workbench: We've IWorkbench, Workbench (not implementing IWorkbench
> or inheriting DefaultWorkbench), DefaultWorkbench (not inheriting from
> Workbench). Easy to explain ?

IWorkbench and DefaultWorkbench (the layout abstraction) are #D
leftovers. They are internal, so they are not relevant to add-in
developers.

Workbench is the only public class.

> 
> * Language bindings:
> 
> - They provide parsers/refactories - but no ambiences ? 

Ambiences have their own extension points. Maybe we should do the same
for parsers and refactory providers? I don't know if it makes sense.

We should review the api and see how language bindings are currently
used. So for example, if we move the comment tag properties to syntax
modes, and parser/refactorer have their own extension points, there
isn't much left in ILanguageBinding. This code has evolved a lot since
it was designed, so maybe it can go away or it can be replaced by
something else.

> - They provide comment tags, but we get comment tags from the syntax
> modes.

I think we should get rid of those comment tag properties from
ILanguageBinding, and use only the info from syntax modes. However, they
are still being used when creating a new file to insert the license
header. We have to find a way of querying information from syntax modes
without having and instance of an editor.

> - 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!)

The mime-type system doesn't have information about which types are
source code files. We have per-mime-type formatting policies, but this
is unrelated.

> - Maybe they should be attached to a ProjectDom or ViewContent to allow
> easier access.

I don't think that's necessary. You can already get a language binding
from Project, and you can get a project from ProjectDom and ViewContent.

> 
> 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.

Our resources are limited, so we have to be careful about where we put
our development effort. We should focus on fixing, improving or
implementing features that users really need. Improving the API is part
of the work, but we have to find the right effort/benefit balance.

Lluis.