[MonoDevelop] Larger set of stetic patches

[Lluis Sanchez]

Hi,

> On Thu, 2006-06-29 at 17:57 +0200, Lluis Sanchez wrote:
> > Ok, so right now Stetic gets the information about widgets from an
> > objects.xml file embedded in the library. What you are proposing is to
> > read that information, or at least part of it, from the widget classes
> > using reflection. That's an important change in the model, so it needs
> > some thinking.
> > 
> 
> Agreed. I will explain later why my patch doesn't break anything and
> what you all missed.

I never said your patch breaks anything. What did I miss?

> 
> > There are at least two scenarios in which an xml description is
> > necessary and can't be replaced by reflection:
> > 
> >       * When we can't modify the widget library to add attributes.
> >         That's the case of gtk#.
> >       * When building a dll which implements both widgets and windows
> >         that contain instances of those widgets. The problem in this
> >         case is that we need to have the widget description before
> >         compiling, but we don't have a dll to reflect.
> > 
> 
> yep, and in the same time you're imposing this structure of yours on
> those who can't link on either stetic or monodevelop.

With those points I only wanted to show that the xml description model
needs to be supported, even if we add support for the attribute-based
description model. I don't know how this relates to linking to stetic or
monodevelop, but I'll keep reading.

> 
> My example is a clear cut case. Can't link against either monodevelop or
> stetic (linking against stetic would be pure consumption without one
> single gain in my case and I'm already cutting the red line, linking
> against monodevelop is impossible not only for the same reason as
> stetic, but also unclean license it comes with, the last I followed youmore
> still haven't finished all the #develop/monodevelop license war)

You may need to link to Stetic, but never to MonoDevelop. You'll need to
link to stetic to provide non-default behavior for editing, reading,
writing or code generation for the widget. I'm open to suggestions about
making those operations more smart and thus to avoid some cases in which
wrappers are needed. But I still don't see how this relates to the
description model.

BTW, notice that you can split your widget library in two: one that
implements the widgets and is completely unaware of stetic, and another
which links to stetic and implements design functionality only.


> 
> > So we still need to support the xml model, and I'm not sure it is a good
> > idea to provide another model for describing widgets. In any case I
> > don't think that mixing both models is good. A library should describe a
> > widget either using xml or reflection, but not a mix of both.
> > 
> 
> Mixing? That wouldn't be good, I agree. What you missed in my patch it
> is the fact that it isn't mixing, it is priority overriding.

Again, I didn't miss it. What we have to avoid is having widgets half
described using xml and the other half with attributes. Priority
overriding allows you to do it. Or a library which declares some widgets
using the toolbox attribute and some others in the xml file. This is
what I mean by mixing. This would be really confusing.

(snip)
> > 
> > If widgets still have to be specified in the export widget option panel,
> > what's the point of using [ToolboxItem]?
> > 
> 
> One simple answer. Monodevelop should automatically add
> ToolboxItem(true) to exported widgets.

That's true if we decide that MonoDevelop has to use by default the
attribute-based description model when creating custom widgets.

(snip)

> > > 
> > > 
> > > 
> > > 3. Correction to objects.xml for SpinButton, second itemgroup "Spin
> > > Button Properties" was not inheritable because it didn't provide name
> > 
> > Ok.
> > 
> 
> This patch still contains solution for this. My current patch is done
> according to http://svn.myrealbox.com/viewcvs/trunk/stetic/ which is 11
> days old and doesn't contain it?

contain what?

> 
> > > 
> > > 
> > > 
> > > 4. Real loading when specifying -lib:<somelibrary>, previous code was
> > > missing actual loading
> > 
> > Ok.
> > 
> 
> Again the cvs question

uh?

> 
> > > 
> > > 
> > > 
> > > 5. Added possibility for control to specify CreateWrappedInstance
> > > method, without this wrapped controls couldn't work without being
> > > referenced to stetic. This enables stetic to use base wrapper and use
> > > re
> > > classed widget. It basically enables for widgets to be fully
> > > functional
> > > without being referenced to stetic.
> > 
> > Can you give an example in which is this needed?
> > 
> 
> As I already said, for various reasons I can't reference against
> stetic/monodevelop.
> 
> Now, lets look at what monodevelop provides so far (don't get me wrong
> on this one, I might be bitchin' about stetic and monodevelop, but they
> are still tools of my preference, stetic because it is probably THE most
> wonderful form editor (but only as far as editing form and properties,
> functionally it has a long way to go) I've used so far and monodevelop
> because of its way it does/enables things to happen'. And it is my
> belief that saying something is good is not even nearly as good as
> saying where that great thing is bad).
> 
> - One can do control like you provided: by specifying "New Widget" and
> designing that control in stetic and source. All good and very nice. But
> this is only usable when one does complex controls, and completely and
> utterly stupid for sub classing them. It would mean you would have to
> provide every signal and every property to the BIN container stetic
> relates too. Now take a look on any site where free controls for any
> language are provided, what do you see more of subclassed or complex.
> Complex would account for less than 1%. Meaning New widget is functional
> but practically unused in real world. Now try specifying "New widget"
> and subclassing some widget type other than bin.

Ok, so you are mixing several concepts here. First of all, the "New
Widget" command provided by MonoDevelop is not only intended for
building widgets for a widget framework. It is intended for building
applications. It's an easy way of splitting a complex user interface in
smaller self-contained user interface elements. For example, a window
may have a notebook with 3 pages. Instead of writing the logic for
managing all 3 pages in the window class, you can create one custom
widget for each page, and handle page-specific code in each widget's
class. This makes the code more easy to understand and maintain. Notice
that in this case you'd be creating custom widgets which are only used
in one window. That's ok, because the goal here is not reusability, but
modularity. I know people don't usually implement this kind of widgets,
but I hope that making it so easy in Stetic encourages the use of this
model.

If you are building a reusable widget framework, you can implement
widgets either using the "New Widget" command and the designer, or by
just subclassing an existing widget. It's your choice. In any case, you
can export all those widgets in the objects.xml file (or using
attributes if we support it).

> 
> - stetic in monodevelop so far can't create widgets that are not loaded
> in. Basically, not-even one subclassed gtk control can't be used inside,
> unless monodevelop would load this library initially. Understandable
> problem, this is one of the .Net stupidities, how .Net works with loaded
> assemblies, you can't unload assembly, you can only unload AppDomain.

This is not stupidity. This is a very complex issue, which has a lot of
implications in the runtime, the JIT and the GC. And I can tell it for
sure because the possibility of unloading assemblies has been studied in
the past.

> And as far as I made a quick look in monodevelop insides you're using
> Cecil to avoid this fact. Well, as much as Cecil is great for coding, it
> is probably not so great on using them.
> 
> - another fact is that stetic makes its own way of doing, which makes it
> completely impossible to subclass for example simple RadioButton without
> referencing to libstetic. It is the way how wrappers work in stetic. If
> wrapper is not specified, stetic looks trough base classes where this
> custom control was derived from. If one of the base classes specified
> wrapper? It creates exactly that one, which creates base controls type
> widget instead of this controls type. Which result in stetic
> Exceptioning out on accessing properties that were not present in the
> base class. And being able to add properties is one of the common basic
> functionalities when one is subclassing smoe control type. So,... what
> does this patch provides? For controls functionality, nothing, but for
> wrappers, a lot. Wrapper can use right type of widget this way, but at
> the same time one doesn't need to link against stetic/monodevelop.

Wrappers have a reference to the original class descriptor, which has a
reference to the type, which means that wrappers already have access to
the real type. All information needed to create the correct widget is
there. If this information is not being used properly, that's a bug, not
a missing feature.

> 
> Ok, a lot of bitchin' from me:) but what am I doing with this? My plan
> is to make DBusified stetic (don't worry, it is a separate app derived
> from base stetic, which would need only one functionality to enable this
> possibility... (in my case, steticremote) ability to connect to Project
> signals, which would be more than adequate to make DBusified stetic, but
> at the same time not changing a single bit (except adding few lines
> where project is passing events to connected parties) of this one or the
> one in monodevelop) instead of hardcore one in monodevelop. This way
> stetic could load/reload/unload without bothering monodevelop (or any
> other controlling software), basically my way would enable in
> monodevelop (or in my case my own controlling software) to say "stetic
> load thislib, thatlib and thatproject", all would load and no
> constrictions would be posed. And since it would be its own separate
> entity, a lot more functionality (which now can't be) could be added to
> it. Remote stetic would mean that monodevelop wouldn't bog down stetic
> and stetic wouldn't bog down monodevelop. I'm after the "live"
> functionality here. Currently as it is stetic is more or less "dead"
> functional, anyone saying differently probably hasn't seen functional
> form editor in his life.

What's your plan for embedding in the MonoDevelop main window the Stetic
design area which is running in a different process? 

(I assume that you are not suggesting to move the design area to its own
top level design window, since that would mean that you've never seen a
functional integrated form editor in your life)

> 
> btw. My patch already provides/solves everything specified here, ok,
> everything but ability to connect to Project signals. I plan to this
> patch later today
> 
> > More comments inline...
> > 
> 
> ok, comments from me inside too

(snip)

> > >         
> > >         public abstract class ClassDescriptor
> > >         {
> > > +               public struct ToolboxItemDefinitions
> > > +               {
> > > +                       public string Name;
> > > +                       public string Category;
> > > +                       public string Description;
> > > +                       
> > > +                       public ToolboxItemDefinitions (string aName,
> > > string aCategory, string aDescription)
> > > +                       {
> > > +                               Name = aName;
> > > +                               Category = aCategory;
> > > +                               Description = aDescription;
> > > +                       }
> > > +               }
> > 
> > Why do you need this struct? class descriptors need a name, category and
> > description, doesn't matter if they have been described using attributes
> > or xml.
> > 
> 
> I wouldn't need this struct if I would mix both approaches, true. But
> since my approach is priority override, this struct provides:
> - much cleaner way to clean up after moving to attributes (that's if
> moving from objects.xml to attributes would occur) would be finished
> - cleaner code (I could make three string properties, but that would be
> much more confusing and complex to clean up after). It is the usual
> priority override way.

Maybe I miss-understood what you mean by "priority override". For me, it
means that, for example, you check for the [Description] attribute of a
widget class, and if you don't find it, you look for the description
attribute in the corresponding XML element. That is, class attributes
have priority over (and override) xml attributes. In any case, you only
need one "description" field, which will be filled with the value of the
class or the xml attribute, whatever you find. By adding support for
specifying descriptions in [Description] attributes, you only change the
way that information is obtained, but once you have it, nothing else
should need to change.

Lluis.