[MonoDevelop] Forms Designer in MonoDevelop

Wed Jan 20 23:12:51 EST 2010

What I was suggesting was to break the problem into two parts:

1) MonoDevelop needs a forms designer for Windows Forms
2) Mono needs more complete support for the designer classes

The impression I have been getting is that solving the first problem would
be much easier if decoupled from the second.  If this is correct,
MonoDevelop could have a working designer in the shorter term even if the
task of finishing the support in Mono takes longer.  It would just be
Windows only until task number two is done.

If you are saying that the SharpDevelop designer uses P/Invoke (DLLImport)
to access unmanaged libraries then I agree, porting the SharpDevelop
designer to MonoDevelop may be the wrong approach.  I would very much like
MonoDevelop to stay dedicated to being cross-platform.

If what you are saying is that the SharpDevelop designer relies on .NET
classes which are incomplete in Mono currently then I do not see why this
has to shoot down the idea of a designer in MonoDevelop so quickly.

I imagine that a good number of the people asking for or expecting to find a
forms designer in MonoDevelop are currently on the Windows platform. 
Running only on Windows for the moment would still be useful.

If I get some free time one of these days I could try to run the stand-alone
designer on .NET to get an indication of how well it works when the platform
support is there.  I could also poke around the designer in SharpDevelop to
see how easily it might be ripped out.  I just thought somebody more
knowlegable, like Mike perhaps, might be able to quickly tell me if breaking
the problem in two like this would actually make anything easier.

Justin

Petit Eric wrote:
> 
> I believe the problem will be the fact of sharpedevelop/VS wrap native
> code to provide winforms designer and so if this is implemented in
> monodevelop how this will live with other os than MS one ?
> 
> 2010/1/20 jmalcolm <malcolm.justin at gmail.com>:
>>
>> Mike, thank you for clarifying that the real work is in building in the
>> designer classes to Mono's Windows Forms support rather than on the forms
>> designer itself.  I have a question about this though.
>>
>> The MonoDevelop binaries distributed for Windows run on top of
>> Microsoft's
>> .NET 3.5 implementation.  Mono is not required to be installed and I do
>> not
>> believe that MonoDevelop would not use it even if it was.  The
>> multi-targeting ability of MonoDevelop means that applications can be
>> developed on top of Mono using MonoDevelop of course but MonoDevelop
>> itself
>> does not rely on Mono unless you go to the effort of explicitly building
>> it
>> on Mono from source.
>>
>> So, these designer classes that we are talking about are available to
>> MonoDevelop on Windows today.  MonoDevelop is running on top of the same
>> implementation that powers the SharpDevelop forms designer and I assume
>> the
>> Visual Studio one as well.
>>
>> How much work would it be to port the SharpDevelop designer to
>> MonoDevelop
>> if it was a Windows only feature?  Alternatively, how well would the
>> existing stand-alone designer work on the real .NET and how much work
>> would
>> it be to integrate it into MonoDevelop?  Would this be a better route
>> than
>> porting from SharpDevelop?
>>
>> Are people against the idea of a Windows only feature in MonoDevelop?*
>> Are
>> we worried about somehow undermining GTK#?
>>
>> It seems common to see questions like "I started my project on Visual
>> Studio
>> and would like to move to MonoDevelop.  How do I get the forms designer
>> to
>> work?"  My intuition is that many Windows developers interested in Mono
>> or a
>> cross-platform future start off this way.  Many seem to misunderstand
>> that
>> the lack of a forms designer does not mean that their projects will not
>> build or run on Mono.  I suspect that many would-be MonoDevelop/Mono
>> users
>> go away with the impression that MonoDevelop or Mono are just too
>> immature
>> to use at this point.
>>
>> Perhaps the lack of a forms designer is interfering more than we suspect
>> with the goal of attracting Windows developers to Mono, MonoDevelop, or
>> even
>> ultimately to Linux.
>>
>> Perhaps a working forms designer on Windows would create more interest in
>> advancing the state of the designer classes in Mono itself and bringing
>> the
>> forms designer to Linux, Solaris, and Mac.  These contributors might even
>> be
>> those that Mono/MonoDevelop fails to attract today.
>>
>> Perhaps not of course.
>>
>> I am certainly not questioning the priorities of the MonoDevelop
>> project**.
>> I respect that there may be bigger fish to fry.  That said, I do believe
>> that a forms designer in MonoDevelop would be  a great boon and wonder
>> how
>> big a project it would be if finishing the designer support classes in
>> Mono
>> itself was not a prerequisite.
>>
>> Long post I know.  My apologies for that.  And kudos to everyone working
>> on
>> MonoDevelop.  I really enjoy and appreciate your efforts.
>>
>> Justin
>>
>> * The debugger options in the Windows version of MonoDevelop are already
>> different I believe.
>>
>> ** For what it is worth... The majority of my work in MonoDevelop is
>> ASP.NET
>> deployed to Linux servers so I appreciate that there are other
>> priorities.
>> Also, I wrote my first GTK apps for Linux before I ever made a GUI app
>> for
>> Windows and I do like GTK#.  Interestingly though, the first app I ever
>> tried to write in MonoDevelop used Windows Forms.  I really wanted to
>> have a
>> single cross-platform executable with no installer so GTK# was not an
>> option.  I ended up discovering SharpDevelop and installed Windows on a
>> laptop just to use it.  I tried to come back to MonoDevelop but after a
>> while I found myself using SharpDevelop almost exclusively (even for my
>> ASP.NET and console projects).  My preference for Linux eventually
>> brought
>> me back to MonoDevelop and now I use it even when in Windows.  I still
>> have
>> to keep SharpDevelop around just to design the odd form (and TurtleSVN
>> too).
>> I would rather stick with MonoDevelop with Subversion built-in.  I find
>> that
>> doing GTK# GUI in code is not so bad but I would never do a Windows Forms
>> layout without a designer.
>>
>>
>> Mike Krüger wrote:
>>>
>>> Hi
>>>
>>>> That's sad...sorry for the ignorance, but how much work it is to
>>>> integrate the current mwf-designer stand alone app?, beside as far as I
>>>> know, sharpdevelop it have one, I know that it probably use .Net
>>>> services and clases that don't exist in mono or are not complete, but
>>>> each mono release is more feature compatible with .Net, so may be is
>>>> not
>>>> to much. I also know that if you think in a really feature complete,
>>>> stable, etc mwf-designer comparable with the VS.NET one is probably a
>>>> big task, but may be is more doable to think in a "basic" one, that it
>>>> can be even unstable (sorry, but we are all use to have unstable
>>>> "features" in MD, come on, what feature in MD it wait to be really
>>>> mature to be included?). That can bring the attention and jump from
>>>> there...I can even offer my help if some of the MD gurus and hopefully
>>>> the mwf-designer developer can give me a hand...
>>>
>>> Ok, my 2 cents (btw. I wrote the SharpDevelop forms designer):
>>>
>>> The SharpDevelop forms designer uses the windows.forms built-in forms
>>> designer infrastructure - that said it's not possible to translate it
>>> 1:1 to mono - even if the mono windows forms implementation is good -
>>> the designer infrastructure is something different.
>>>
>>> Doing a forms designer from "outside" without the help of the framework
>>> is almost not possible (we've tried that with sharpdevelop first) ... so
>>> implementing a forms designer for monodevelop would require much work on
>>> the mono windows forms implementation first (lluis already mentioned
>>> that). And believe me - this is *MUCH* work (but it's doable :)).
>>>
>>> I understand the need for a windows forms designer and I hope that we
>>> get one contributed by someone who has the time & patience to implement
>>> it. It's an open source project - we would like more people contributing
>>> to it.
>>>
>>> Personally I would like to see some improvements in stetic. Stetic could
>>> really need some love. Our current shedule for the next release doesn't
>>> include badly needed stetic improvements :(
>>>
>>> Regards
>>> Mike
>>>
>>> _______________________________________________
>>> Monodevelop-list mailing list
>>> Monodevelop-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Forms-Designer-in-MonoDevelop-tp27216992p27247135.html
>> Sent from the Mono - MonoDevelop IDE mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Monodevelop-list mailing list
>> Monodevelop-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>>
> 
> 
> 
> -- 
>  Cordially.
> 
> Deploy your softwares for all platforms and finally update them in 3
> clicks.
> Try now the OpenSource MonoOSC tool
> http://monoosc.sourceforge.net/
> http://download.opensuse.org/repositories/home:/surfzoid/
> http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu/
> http://download.opensuse.org/repositories/home:/surfzoid:/DebianUbuntu:/Mono/
> 
> windows take you more($), Linux give you more!!
> Political Power cannot be wisdom!
> 
>  Small Eric Quotations of the days:
> 
> ---------------------------------------------------------------------------
>  I have no special talents. I am only passionately curious
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
> 
> 

-- 
View this message in context: http://old.nabble.com/Forms-Designer-in-MonoDevelop-tp27216992p27252577.html
Sent from the Mono - MonoDevelop IDE mailing list archive at Nabble.com.