[MonoDevelop] Design Time Properties for Custom Controls

[Andrew York]

Mr Gual,
I hope that I have not offended you as well, if I have I would ask what 
I can do to make things right. I was thinking that Monodevelop/Stetic 
has implemented most of what MS Visual Studio can do and I was hoping 
design time properties would work in a similar manner with Monodevelop.

Again if I said anything offensive an apology is there for the taking, I 
can't tell you how much I appreciate the work that has been done to 
bring .NET to Linux, Mac, etc.

Spoody Goon

Lluis Sanchez Gual wrote:
> El ds 18 de 07 de 2009 a les 21:32 +0200, en/na Matjaž Mihelič va
> escriure:
>   
>> On Sat, 2009-07-18 at 13:27 -0400, Andy York wrote:
>>     
>>> There has been a question that is very close to this one that was asked
>>> just a day or two ago, but I'm not sure if it is the same question or
>>> not. Please forgive me if I am asking the same question again.
>>>
>>> Using standard data types (string, bool, int, etc) for design time
>>> properties in custom controls in Monodevelop is easy, but I'm not sure
>>> how to use non-standard data types. For instance if I had an enum that
>>> looked like this:
>>>    
>>>     enum ImageSize
>>>     {
>>>         XLarge,
>>>         Large,
>>>         Medium,
>>>         Small,
>>>         XSmall,
>>>         None
>>>     }
>>>
>>>       
>> I would be interested in that to, but as I look into sources, stetic
>> never touches lib directly. Always over cecil, which is the biggest
>> design flaw any form editor could have.
>>     
>
> You are wrong, it is not a design flaw. Stetic can touch libs directly,
> although we are not doing it in MD for custom widgets.
>
>   
>> In this case none of property editors which aren't hardcoded are not
>> possible. No custom widget (beside the sucky ones combined in stetic,
>> and yes they do suck) can look like it should look during design time.
>> Nothing you code can be activated during design time.
>>
>> For now, I'm simply avoiding any usage of stetic as much as possible,
>> simply because it sucks as much as form editor could suck and because of
>> the fact I can work/rely more on hardcoded form.
>>     
>
> Matjaž, I feel offended by this comment, both as a developer and as a
> user of Stetic. That's a very unpolite way of talking about a form
> designer which is useful for many users. The fact that it is not useful
> for you doesn't make it useless for everybody.
>
>   
>> Make a custom widget
>> derived from DrawingArea, drop it into form. And it practically
>> disappears with height 0. And so on. Custom widgets and stetic is a big
>> NO GO. Now imagine having form populated with invisible widgets? I
>> rather write it hard way.
>>
>> Correct me if I'm wrong. You'll make me the happiest man alive if I am.
>>
>>     
>>> and we want the design time property to be set like this (or something
>>> like this):
>>>
>>>         private ImageSize _MyImageSize;
>>>         // this is where we want the design time property to be set
>>>         public ImageSize MyImageSize
>>>         {
>>>             set{_MyImageSize=value;}
>>>             get{return _MyImageSize;}
>>>         }
>>>
>>> How would we go about doing this, I know the answer is an easy one but I
>>> just can seem to find it even though I have searched quite a bit. I'm
>>> thinking that the same methods that would work for enums would work for
>>> classes but I'm not sure of that either.
>>>
>>>       
>> Solving enums would be easy (just hardcode generic Property Editor for
>> it, solving everything else is hard). Solve that and you achieved the
>> same as putting bandage on torn off limb. Form designer without ability
>> to impose new form designers? Well, reason enough to stay away from it
>> for me.
>>
>> Stetic should NOT be part of monodevelop or at least its AppDomain. It
>> should connect with remoting to it and designed to work in its own
>> window or connected with GtkSocket/GtkPlug to monodevelop window inside
>> monodevelop widget.
>>
>> It should always go down and restart on recompile with all project libs
>> loaded the hard way. Simply as that.
>>     
>
> Oh yeah, simply as that. If you have review the Stetic code you'll see
> that there is code using GtkSocket/GtkPlug, and code for running stetic
> in a separate process, which is not completed/enabled. I leave you
> wonder why, I don't feel like answering anything else from this mail.
>
>   
>> I tried to do some work on that part long ago, but car crash and time I
>> lost because of it had forced me into different needs and I simply
>> haven't got time to focus back (which I still feel a bit guilty about,
>> because I haven't kept my promises). But if you plan on working to fix
>> that. I can help. Although if I'd be in your place, I'd probably rather
>> design my own form editor, which doesn't start with flaws than try to
>> fix something which is utterly broken.
>>
>> Don't get me wrong. I LOVE monodevelop. Almost fanatically. I just hate
>> stetic which is the one part of monodevelop I'd be glad if I could get
>> rid of from my monodevelop like I can get rid of debugger.
>>
>> m.
>>
>>     
>>> Again I apologyze if this has already been asked.
>>> Spoody Goon
>>>
>>>
>>> _______________________________________________
>>> Monodevelop-list mailing list
>>> Monodevelop-list at lists.ximian.com
>>> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>>>       
>> _______________________________________________
>> Monodevelop-list mailing list
>> Monodevelop-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>>     
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20090720/9cec12cc/attachment.html