[MonoDevelop] Planning MonoDevelop 1.0

[Lluis Sanchez]

El dc 22 de 11 del 2006 a les 22:05 -0500, en/na Scott Ellington va
escriure:
> On Thu, 2006-11-23 at 00:28 +0100, Lluis Sanchez wrote:
> >       * Debugger: I know a lot of people will ask for this, but I fear
> >         the debugger won't be ready by our code freeze date. We can
> >         release it later on as a separate add-in.
> > 
> 
> I would consider holding off 1.0 until the debugger is ready.

That's certainly a possibility. The problem is that there is no specific
date for releasing the debugger, and we probably won't be able to start
working on the add-in until that release. So it might delay MD 1.0 for
several months. Let's keep an eye on the debugger to see if we can
include it, but I think MD has enough functionality right now to justify
a 1.0 release, even without the debugger.

> 
> >       * Documentation browser: The Monodoc integration more or less
> >         works, but there are some known crashes. However I still believe
> >         that showing Monodoc in an external window would be more
> >         practical that the current integrated view. The integrated
> >         documentation tree is not really useful, we don't have search or
> >         an index integrated.
> > 
> 
> I don't think I would remove functionality.  If people like it they can
> use it.

I think it is ok to remove a functionality if it does not provide the
minimum level of functionality expected by users. In any case it's not
about removing, but about changing how it works. When pressing F1
instead of opening the help window integrated in MD it would open
Monodoc.

> 
> >       * Welcome page: It looks ok to me.
> 
> One thing I thought of was adding a news section which would display the
> Mono RSS feed.  That would be pretty cool.
> 
> >       * Autotools: There are several features I'd like to support for MD
> >         1.0: 
> >               * Support integration with existing Makefiles. That is, if
> >                 somebody has a project with complex build rules which
> >                 can't be emulated by MD, just make it possible to
> >                 delegate the entire build process to Make, and still be
> >                 able to launch the build from inside MD. About modifying
> >                 the Makefile in MD, I think supporting adding/removing
> >                 files would be enough for now. 
> 
> I assume you mean on deploy to tarball.  

No, I mean be able to integrate with existing hand made Makefiles. That
is:
* In a project, be able to specify the Makefile and target that have to
be used for building the project. When clicking on Build, MD would run
that Makefile.
* Keep the Makefile and the MD project in sync. I think keeping the file
list in sync would be enough. One possible way of doing it is to be able
to configure in the project the Makefile var that contains the file
list, and when saving the project update that var.

This feature is not related to the Makefile generation engine, but since
it's about dealing with makefiles it makes sense to implement it in this
add-in.

> That wouldn't be too hard.
> Just add a setting which prevents the overwriting of the current
> autotools files.
> 
> >               * We need to find a solution for file templates (.in
> >                 files). MD uses some of them. We need to support them in
> >                 the MD build model if we want to be able to completely
> >                 build MD using MD. 
> 
> yes that is a tough one.  I think you have to actually build it into the
> MD project functionality.  

Yeah, we would need to integrate it in the project model. That means be
able to specify variables in projects and combines and then file
templates that consume those variables.

> I think the better solution would be to find
> another way to do what you were doing with templates.
> 
> >               * There may be other missing features needed for
> >                 self-hosting MD. 
> 
> likely.
> 
> >               * It would be nice to support generating a tarball without
> >                 having to pollute the project directory with autotools
> >                 files. 
> 
> yes it would.
> 
> > As you can see that's a lot of work. I think we should prioritize
> > working on features related with development GNOME desktop applications
> > (which has been the main goal of MD anyway).
> 
> The other things are the freedesktop *.desktop entries and MIME types
> (as mentioned at http://www.monodevelop.com/Autotools ) which pertain
> directly to developing GNOME applications.  We had discussed abstracting
> this stuff into a DesktopTools addin, but I have recently started a new
> job and have had little energies for additional coding.

Yep, I think all this should be independent from the Autotools add-in.
I'll think about it.

Thanks for the feedback!
Lluis.