MonoDevelop vs SharpDevelop

[asbjornu]

Can't MonoDevelop and SharpDevelop unite forces and build one cross-
platform alternative to Visual Studio instead of scattering the
development resources out on two independent projects? This hurts MD
and SD just as much. All of the improvements in MD would be beneficial
to SD and vice versa.

[Sandy Armstrong]

I think SD has dependencies on Windows- or MS.NET-only libraries. For
them, it is probably not acceptable to be restricted to the features
available in Mono.

This is aside from the fact that they are each designed to fit into
their native platforms. I'm curious to see how Mac enthusiasts adapt
MD to fit better into OS X.

Sandy

[w3stfa11]

Can the Visual Studio 2008 shell be used to compile code using mono?
IronPython did it quite nicely. Obviously, this wouldn't be ideal for
mono since it's Windows only, non-free, and probably its project files
are not interoperable with MonoDevelop. But hey, I'm just wondering
because the Visual Studio shell undeniably rocks.

http://www.codeplex.com/IronPythonStudio



On Feb 8, 11:32 am, "Sandy Armstrong" <sanfordarmstr...@gmail.com>
wrote:

[Miguel de Icaza]

Hello,

Can the Visual Studio 2008 shell be used to compile code using mono?
IronPython did it quite nicely. Obviously, this wouldn't be ideal for
mono since it's Windows only, non-free, and probably its project files
are not interoperable with MonoDevelop. But hey, I'm just wondering
because the Visual Studio shell undeniably rocks.

Yes, you do not need anything special;   The binaries produced by Visual Studio already run with Mono.

But we have not done any work to integrate Stetic into Visual Studio, which is why there might be interest in getting it on Windows (in addition to the extended dogfooding)

[asbjornu]

On 8 Feb, 18:32, "Sandy Armstrong" <sanfordarmstr...@gmail.com> wrote:

> I think SD has dependencies on Windows- or MS.NET-only libraries.  For
> them, it is probably not acceptable to be restricted to the features
> available in Mono.

Hm, ok. Wouldn't it be possible to only have two separate builds,
then? You'd need that for targeting specific platform GUI frameworks
anyway. What specific Windows-only libraries are SD using?

> This is aside from the fact that they are each designed to fit into
> their native platforms.

From a GUI standpoint, I get this. What I'm interested in seeing
shared is the underlying codebase, with regards to code lexing,
parsing, compiling, syntax highlighting, intellisense, refactoring,
documentation, etc. I'm positive that the MD and SD codebases could be
harmonized and the GUIs made independent enough to be able to
accommodate both groups and platforms equally and satisfactory. It's
obviously not a simple task, but considering the extremely bright
minds working on both projects, I'd think it should be more a question
about "time" and "when" than about "if" and "how".

> I'm curious to see how Mac enthusiasts adapt MD to fit better into
> OS X.

If MD and SD shared the underlying codebase and had a more independent
GUI layer, this would be a matter of creating a new GUI layer
specifically for Cocoa. As you can see from the MD on OS X
screenshots, it looks rather bastardized with the menu bar inside the
application instead of top-aligned, etc. It's a great step in the
right direction, but without a special-tailored GUI, MD will probably
never look like a native OS X application.

-Asbjørn

[Michael Hutchinson]

On Feb 25, 7:24 am, asbjornu <asbjo...@gmail.com> wrote:
> On 8 Feb, 18:32, "Sandy Armstrong" <sanfordarmstr...@gmail.com> wrote:
>
> > I think SD has dependencies on Windows- or MS.NET-only libraries. For
> > them, it is probably not acceptable to be restricted to the features
> > available in Mono.
>
> Hm, ok. Wouldn't it be possible to only have two separate builds,
> then? You'd need that for targeting specific platform GUI frameworks
> anyway. What specific Windows-only libraries are SD using?

The difference between using System.Windows.Forms+System.Drawing and
GTK#+GDK# represents a huge change to the codebase. Maybe 30% of our
code -- maximum -- is cleanly GUI-free, and we've put some effort into
maintaining a GUI/non-GUI split where possible.

The bits we could in theory share are mostly difficult to coordinate
sharing, because any changes to non-GUI code would have to be
reflected in both sets of GUI code. All developers would have to be
completely familiar with both GTK# and SWF. It would make coding very
frustrating, always waiting for the developers of the other GUI.

> > This is aside from the fact that they are each designed to fit into
> > their native platforms.
>
> From a GUI standpoint, I get this. What I'm interested in seeing
> shared is the underlying codebase, with regards to code lexing,
> parsing, compiling, syntax highlighting, intellisense, refactoring,

We do use #Develop's NRefactory C# and VB.NET parser, and contribute
changes back. We're certainly interested in sharing components that
can be isolated like this.

> documentation, etc. I'm positive that the MD and SD codebases could be
> harmonized and the GUIs made independent enough to be able to
> accommodate both groups and platforms equally and satisfactory. It's
> obviously not a simple task, but considering the extremely bright
> minds working on both projects, I'd think it should be more a question
> about "time" and "when" than about "if" and "how".

I think you strongly underestimate the difficulties -- of isolating
enough of the non-GUI layer to make it worth sharing, maintaining two
GUI whenever this layer is changed, and of merging codebases that have
been independent for four years.

> > I'm curious to see how Mac enthusiasts adapt MD to fit better into
> > OS X.
>
> If MD and SD shared the underlying codebase and had a more independent
> GUI layer, this would be a matter of creating a new GUI layer
> specifically for Cocoa. As you can see from the MD on OS X
> screenshots, it looks rather bastardized with the menu bar inside the
> application instead of top-aligned, etc. It's a great step in the
> right direction, but without a special-tailored GUI, MD will probably
> never look like a native OS X application.

Geoff already has code to fix the menu bar. With a good GTK# theme, we
can at least make it feel comfortable, even if not native.

Michael

[Filipe Correia]

Hi,

On Feb 27, 5:19 pm, Michael Hutchinson <m.j.hutchin...@gmail.com>
wrote:

> I think you strongly underestimate the difficulties -- of isolating
> enough of the non-GUI layer to make it worth sharing, maintaining two
> GUI whenever this layer is changed, and of merging codebases that have
> been independent for four years.
>

I understand this, and although I am another that would very much like
to see SharpDevelop and MonoDevelop efforts being joined, I realize
the initial effort wouldn't probably pay off any time soon.

Having said that, the only thing that's keeping me to migrate to
monodevelop is the lack of integrated debugger (although i ear this is
pretty close[1]) and an integrated Windows.Forms designer (which i
remember being addressed on a previous soc project[2][3], but believe
is a very low priority at this time).

[1] http://tirania.org/blog/archive/2008/Mar-14.html
[2] http://groups.google.com/group/mono-soc-2007/web/windows-forms-designer
[3] http://arstechnica.com/journals/linux.ars/2007/08/25/linux-based-windows-forms-designer-for-mono

Cheers,
Filipe

[Miguel de Icaza]

Hello,

Having said that, the only thing that's keeping me to migrate to
monodevelop is the lack of integrated debugger (although i ear this is
pretty close[1]) and an integrated Windows.Forms designer (which i
remember being addressed on a previous soc project[2][3], but believe
is a very low priority at this time).

We are aware of the debugger issue, and we are working towards that.  Its the #1 priority at this point.

As for the Windows.Forms designer: its a lot harder to do with Mono, because on Windows, SharpDevelop ends up using a System provided designer, while we have to build it from scratch.

Miguel.=

[Filipe Correia]

Hello,

On Mar 25, 10:15 pm, "Miguel de Icaza" <miguel.de.ic...@gmail.com>
wrote:

> > Having said that, the only thing that's keeping me to migrate to
> > monodevelop is the lack of integrated debugger (although i ear this is
> > pretty close[1]) and an integrated Windows.Forms designer (which i
> > remember being addressed on a previous soc project[2][3], but believe
> > is a very low priority at this time).
>
> We are aware of the debugger issue, and we are working towards that. Its
> the #1 priority at this point.

I'm really looking forward to it :)

> As for the Windows.Forms designer: its a lot harder to do with Mono, because
> on Windows, SharpDevelop ends up using a System provided designer, while we
> have to build it from scratch.

I've just found out mono's wiki has a page tracking the progress on
the WinForms Designer[1]. Nice!

[1] http://mono-project.com/WinForms_Designer