[Monodevelop-devel] Brainstorming for 2.4 code quality

[Christian Hergert]

First and foremost, I'd like to see all the legacy code that is somewhat 
broken or need work to be useful to be moved somewhere like "attic".

I think making a list of common extension topics we can create a clear 
picture of what the API should look like.  It's pretty obvious where the 
pain points are when you try to follow a howto on adding a feature (even 
if a quick ad-hoc one).

I'd really like to be able to script a lot of my daily tasks in the IDE 
without writing an Addin (JavaScript or similar).  We could provide a 
small scripting environment with a simpler API that tries to cover the 
80% in a friendly way.

-- Christian

Lluis Sanchez Gual wrote:
> 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.
>
>
> _______________________________________________
> Monodevelop-devel-list mailing list
> Monodevelop-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list