[Monodevelop-devel] Brainstorming for 2.4 code quality
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 :-)
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.
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
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
Custom extensions for indentation control don't seem to have a well
defined model for implementation. This may simply be a documentation
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
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
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 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
* Generated HTML documentation for viewing and ability to export to
* 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.
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.
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.
More information about the Monodevelop-devel-list