[Monodevelop-devel] Brainstorming for 2.4 code quality

Christian Hergert chris at dronelabs.com
Thu Sep 3 16:58:20 EDT 2009

I kept a few notes while implementing portions of the PyBinding.  These 
are in their raw form but I figured I'd attach them for the sake of 
having the information somewhere.

Some things also may have been fixed since I wrote these.  Please do not 
take any offense to any of the wording if my comments are on code you've 
written, all in all it was a quite pleasant experience :-)

-- Christian

Reusable REPL

We need a reusable REPL that languages can extend.  Perhaps the guts
from the "csharp>" REPL can be extracted and re-used.  Bonus points if
it can render using a modified Mono.TextEditor for highlighting.

Language Bindings

I'm not convinced that the language binding class is even needed.  All
it seems to do is aggregate different pieces together.  It also doesn't
provide a compeling way for multiple language bindings to implement the
same feature.  This may become an issue for an IronPython versus CPython


Michael mentioned that having the "Gimp" style interface would be nice
on OS X.  I agree.  I also think it would be nice on Linux.  I much
prefer the layout as long as the toolbars are "sticky" to the top of my

Docking Panels

This are *very* buggy in their current state.  We need a bug love day
focused on these since they are so critical to daily use.


XXX: Add information

Editor Extensions

Custom extensions for indentation control don't seem to have a well
defined model for implementation.  This may simply be a documentation

Code Completion

ProjectDom is highly .NET centric.  PyBinding conforms to this for in 
file parsing since it gives us persistence "for free".  But this is not 
suitable for indexing the system packages.  I would like this to be 
easily re-usable for writing other add-ins such as JavaScript, Ruby, or 
even SQL.

Currently, it is very tough to map python language concepts to things 
like IType, IMember, and such.  Even when conforming to that, features 
like tooltips are bound to using words like "Namespace" rather than 
"Module" or "Package".

I'd really like to be able to re-use the parser database rather than
managing my own with sqlite.

It might be nice to use compression within the database by default.  All
the information on the subject I've seen recently shows faster query 
times due to reduced I/O.  However, I haven't looked to seef if this is 
done already.

Mime Type's and Settings

I need a way of specifying the default settings for a mime-type.  I'm 
sure pretty much all non-c# languages need this.


Far too much of the UI window is wasted for non-coding.  The 
double-click tab feature is nice, but tabs themself are quite large. 
I'm quite aware this is caused by common gtk+ widget themes and icons 
included in buttons.

However, I think it is a worthwhile effort to see how we can work around
it.  A solid default pixmap theme could make things quite attactive. 
For example, QtCreator[1] is quite attactive on various platforms.


MonoDoc is possibly the worst documentation system I've ever used.  I
suggest we abandon it as an external dependency and build something in
process.  It should support:

  * .NET and non-.NET languages.
  * Indexing and Full-text like MonoDoc does.
  * Cross-referencing of documentation between languages so GtkWidget in
    C documentation can link to gtk.Widget python docs and Gtk.Widget
    .NET documentation.
  * Generated HTML documentation for viewing and ability to export to
    static files.
  * Add comments or update documentation.  This could be pushed to a
    collaborative system that mono/monodevelop could host for comments.
    That way, we continue to get the benefit of crowd-sourcing.


We need a bugzilla add-in that can hook with version control system. 
When I include a commit message that says "Fixes #123123" I expect it to 
send the patch to bugzilla and close the bug.

Build System

I find the build system to be a PITA to work with.  I personally build
from command line most of the time.  I don't understand why we need
configure scripts for various individual projects and such.  I certainly
don't mind the change to xbuild; it just needs to work.

We have svn, do we really need ChangeLog's anymore?  They waste space
and add one more layer of duplication of content.  We should simply
generate a master ChangeLog during "make dist" or similar.

MonoDevelop Shell

In Visual Studio and Eclipse fashion, it's time that the shell itself
become re-usable and re-distributable.  It would be nice if I was able 
to build a self contained PyBinding application that included only what 
it needed from MonoDevelop.

[1] http://qt.nokia.com/products/developer-tools/developer-tools

More information about the Monodevelop-devel-list mailing list