[Monodevelop-devel] Brainstorming for 2.4 code quality
mkrueger at novell.com
Tue Sep 1 12:27:34 EDT 2009
> > * 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
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
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
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
More information about the Monodevelop-devel-list