[Monodevelop-devel] Brainstorming for 2.4 code quality

[Mike Krüger]

Hi

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

But no core addin should re-create the 'attached view content' subsystem
itself. And thats what stetic did. If the subsystem isn't good enough it
should be extended. 

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

It's a nightmare to maintain. But if someone does it for mac - why not.

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

Yes templates should be on the redo list.

> * code templates. I'd like to have APIs for addins to add code
> templates.\
>
I think it's easy to do this.

> * 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 had problems with this too :)

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

MD docs are a good thing. But I would prefer good APIs in the first
place.

Regards
Mike