Mogre designer support. (PropertyGrid)

As i previously mentioned in "Mogre 1.6.2 Anouncment" thread there is some need to be able to edit Mogre types objects in a PropertyGrid. I have done some moves and prepared some useful classes to allow such a possibility.
My goal was to make TypeConverter and UITypeEditor that would present different functionality depending on underling object. In addition this functionality can be changed at run-time.
So after adding:

//This are kind of proxy classes
[EditorAttribute(typeof(ResolvableTypeEditor), typeof(System.Drawing.Design.UITypeEditor))]
[TypeConverter(typeof(ResolvableTypeConverter))]

to the underling objects (Type or Property) we can make use of our own Converters and Editors in a property grid.
I would like this two attributes to be added to all mogre types.

This Attributes contains static fields of type:

public interface ITypeConverterResolver
{
TypeConverter GetTypeConverter(ITypeDescriptorContext context);
}

public interface ITypeEditorResolver
{
UITypeEditor GetTypeEditor(ITypeDescriptorContext context);
}


This fields allows us to write and plug our own Resolvers.
As for now i have implemented simple Dictionary<Type,Type> Resolvers that gives us Type(Converter/Editor) depending on Type of parent object;

There are Quaternion ColourValue Vector3 Converters made by "lilljohan" <--- (I hope you don't mind ).
And some TypeEditors made by me.

Please add this somewhere to your code and Select this Object into PropertyGrid.

Matrix3 matrix3 = Matrix3.IDENTITY;
[EditorAttribute(typeof(ResolvableTypeEditor), typeof(System.Drawing.Design.UITypeEditor))]
[TypeConverter(typeof(ResolvableTypeConverter))]
public Matrix3 Matrix3
{
get { return matrix3; }
set { matrix3 = value; }
}

Matrix4 matrix4 = Matrix4.IDENTITY;
[EditorAttribute(typeof(ResolvableTypeEditor), typeof(System.Drawing.Design.UITypeEditor))]
[TypeConverter(typeof(ResolvableTypeConverter))]
public Matrix4 Matrix4
{
get { return matrix4; }
set { matrix4 = value; }
}

Quaternion quat = Quaternion.IDENTITY;
[EditorAttribute(typeof(ResolvableTypeEditor), typeof(System.Drawing.Design.UITypeEditor))]
[TypeConverter(typeof(ResolvableTypeConverter))]
public Quaternion Quat
{
get { return quat; }
set { quat = value; }
}


ColourValue colVal=new ColourValue()
[EditorAttribute(typeof(ResolvableTypeEditor), typeof(System.Drawing.Design.UITypeEditor))]
[TypeConverter(typeof(ResolvableTypeConverter))]
public ColourValue AmbientLight2
{
get { return colVal; }
set { colVal = value; }
}


It would be really helpful if you could add this on the source code of the custom C++/CLI classes and post a patch.
Let me know if you need more details.

I have made new VS solution.
You have just made me go into c++/CLI for the first time.
And I'm open for all the criticism .
And damn i wasted so much time when declaring Vector3 as Vector3^ and trying to figure out what is wrong . <-- I just had to cry a little.

It is packed attachment don't be surpriesed after unpacking (the ratio is 16%) 14MB ->89MB.
It's cuz I packed it with Mogre OgreMain libraries (multiple times).

It's compiled and build so you can run it or build it once again.

I'm investigating TypeDescriptionProvider maybe we will add only one Attribute and it will do it's magic for this and future additional attributes.
I could not upload it on a forum.

http://rapidshare.com/files/230723379/MogreTypesAttributes.rar.html <--- thay say it can be downloaded 10 times

Any more bits working with this? Type converters etc would be a great MOgre addition because it's a pain in the arse and I'm sure anyone working with MOgre probably has to do it over and over again. Plus MOgre doesn't help much in this regard.
btw the rapidshare *spit* link is dead

I have uploaded it again i hope it stays a little longer in here. If you know good free file hosting then give me a link.
http://www.speedyshare.com/files/21271137/MogreTypesAttributes.rar
(Don't forget to link it with Mogre )

It's dead but I hope for it to resurect.
I was going to give it a try with new Mogre 1.7 when it's ready.
(previously i was not taken seriously to much )

And support for Converters and Editors for types is very useful.

For example I could change my scene fog preferences and lights in game with a propertygrid, almost like in game editor .
To tell you the truth if types like Vector3 and Quaternions are "Attributed" you can even move your entities around.

Unfortunately I don't have a time until end of this month.

I have uploaded it again i hope it stays a little longer in here. If you know good free file hosting then give me a link.

Sourceforge ? , if you need to host it, i can upload it with the mogre file archives on sourceforge. ultimately, if you want to try to integrate it directly with the mogre source, i can give you access to the mogre svn.

I want to integrate it into Mogre.
But I'm rely short on time this month.
I will talk to you about this next one.

Hi

I am also interesting in implementing the PropertyGrid into my current project. If koirat hasn't got any further with it I'd be happy to have a go at implementing it into the Mogre source code myself. I've had plenty of experience with C# and a little experience with C++.NET.

I do wonder if there would be any performance issues with doing this, but it's probably not worth worrying about until it becomes an issue.

First I'll have to grab a copy of the source code from SVN and make sure I can get it to compile, then test the DLL with my project. Once I've done that I'll implement basic support for Vector3 and go from there.

no problem for me, perhaps try to contact koirat to avoid doing the same thing. Also, make sure that you use the 1.6 branch (in https://mogre.svn.sourceforge.net/svnro ... GRE-1.6.5/). the current trunk is 1.7 and doesn't compile atm.

perhaps try to contact koirat to avoid doing the same thing

Contacted. Hopefully he'll join back in the conversation.

Also, make sure that you use the 1.6 branch (in https://mogre.svn.sourceforge.net/svnro ... GRE-1.6.5/). the current trunk is 1.7 and doesn't compile atm.

Will do. I'm usually pretty busy myself and I'd imagine there's a fair bit of work to do just to get it compiling. I'll keep this thread updated with my progress.

I'm still alive and ready for work. .

I have read your message zafirus so allow me to answer it here. I would like to take part in making Mogre design support, especially that I made some progress with it, and I think that my method is rather flexible.
But it does not mean that it is not possible to make it with more people. I would say that it is even desirable considered amount of TypeConverters and TypeEditors (especially type editors [since it is time consuming] ) needed.

The method I'm using allows you to change TypeConverter/TypeEditor of type during run-time. I will post some more when I include it to Mogre, and add some comments to the code. So we can discus and improve it. I will do it as soon as i get Mogre Source.

As I said before and since it is almost 03 - 30 - 2010 i can now start to do something.

Where should i get Mogre source from. ? The link in the previous post kind of lack files, do i have to generate them ?.

I'm still alive and ready for work. .

Cool

The method I'm using allows you to change TypeConverter/TypeEditor of type during run-time.

I'm very interested to know how you did this?

Where should i get Mogre source from. ?

I spent a good 4 hours last night figuring out how to compile the source code for MOgre. It's not an easy task, but it's doable. I used this process (it's not perfect but seems to be the most up to date instructions):
viewtopic.php?f=8&t=10937#p63491 There are also some instructions on the wiki but they appear to be out of date.

Working with Managed C++.NET / CLI is pretty painful compared to C#. Not only is the syntax very different, the compile times really suck. So, what I've done today is create a tiny test project to "simulate" adding a TypeConverter to Vector3 in C++. It's pretty hacked togther but it shouldn't be too hard to figure out (see attached).

I almost done translation c# source to c++/CLI, tomorrow I will upload it and post there if anybody needs this.

[attachment=0]mogre_prop_grid.jpg[/attachment]

Last night I implented a Vector3 type converter in C++ / CLI and added it to the Mogre source code. Then I wrote a quick C# application to test. As you can see it works.

I've been thinking about koirat's implementation of a single class that handles all data types, and I think it may have some flaws (like only being able to have one resolver attached at a time). I'm sure there's a few ways to fix this but it might be better to have different implentations for each data type. For example:

Vector3Converter
QuaternionConverter
ColourValueConverter

Each of these can have a default behaviour provided by Mogre, but also have a public static member for a custom TypeConverter. In the code you can do this for example:

if(customTypeConverter == null)
{
// do the default
}
else
{
// call the custom implentation
customTypeConverter.ConvertTo(context, culture, value, destinationType);
}

This code is in C# but of course it would need to be translated to C++. It's just natural for me to type

As I said, I just ported all coirat's code to c++ )

As I said, I just ported all coirat's code to c++ )

Very nice, but does it work? Maybe I'm not looking at the lastest code but as far as I can tell it has an issue where the TypeConverterResolver can only be set to one custom class at a time.

So, lets say you created your own set of TypeConverter's for each of the Mogre data types as I mentioned in my last post. You wouldn't be able to use all of them at the same time like this:

ResolvableTypeConverter.TypeConverterResolver = new CustomVector3Converter();
ResolvableTypeConverter.TypeConverterResolver = new CustomQuaternionConverter();
ResolvableTypeConverter.TypeConverterResolver = new CustomColourValueConverter();

As you can see each time you set the static property it would override the last. What I'm proposing is that we have a default type converter for each type, more like this:

Vector3Converter.CustomResolver = new CustomVector3Converter();
QuaternionConverter.CustomResolver = new CustomQuaternionConverter();
ColourValueConverter.CustomResolver = new CustomColourValueConverter();

This way, you can choose to implement your own resolver, or just leave it to the default one. If you wanted to go back to the default resolver after you've already used your custom one, all you'd have to do is set them to null like this:

Vector3Converter.CustomResolver = null;
QuaternionConverter.CustomResolver = null;
ColourValueConverter.CustomResolver = null;

Also, to make things a little simpler, you could do away with the interfaces by simply making the static field a TypeConverter. So instead of this:

static ITypeConverterResolver typeConverterResolver = new TypeConverterResolver();

public static ITypeConverterResolver TypeConverterResolver
{
get { return ResolvableTypeConverter.typeConverterResolver; }
set { ResolvableTypeConverter.typeConverterResolver = value; }
}

You could change it to this:

static TypeConverter customResolver = null;

public static TypeConverter CustomResolver
{
get { return customResolver; }
set { customResolver = value; }
}

The reason this would work is because the TypeConverter class already does the same thing as the interfaces.

[edit]
Posted simultaneous with zafir post, after submit I saw his post. (And I'm going to take a few depth breath after this edit )

ResolvableTypeConverter.TypeConverterResolver <--- you dont set it with your converter object

you set it with ITypeConverterResolver. And that's the whole different story.

And what did you think that I posted a code without minimum knowledge about it's usability ?

I was looking forward to design support. I hope it will not end as a flame war.
[/edit]

@zarfius.
You made my blood boil a little.
It's true that this is not final implementation and "TypeConverterResolver" is almost the simplest posiible reslover of type "ITypeConverterResolver" (even this resolvers can be changed at run-time) But still I don't think you grasped my implementation at all. Btw did you compile and run it ?
Also how it can be wrong if my method can use your converters and much more converters ?
Also there was a reason in doing it so flexible.
Ogre got much more classes than Vector3 Quaternion ColourValue. Are you going to attribute all of them with your custom attributes ?
What I have done is a possibility to specify default converters/editors inside a resolver. You can automatically decorate all Mogre classes and be at easy.

Also i would like to point out one important thing, it's not only about converters, TypeEditors are also very very important.

Just take a look at the picture and see for yourself.

@Seregvan
You spared me the dirty work. I Appreciate it.
Did you compile/run it. Could you post your code.
I hope you are on my side

@zarfius.
You made my blood boil a little.

Sorry about that, wasn't my intention.

But still I don't think you grasped my implementation at all.

Yeh, I was a bit confused, but now that I've read your latest post and had another look at the code I understand now.

Also how it can be wrong if my method can use your converters and much more converters ?

I never said it was a bad idea, I just thought it had an issue that needed to be looked at. My mistake.

Btw did you compile and run it ?

Unfortunately, I couldn't download all of the attachments because of broken links. The one I did manage to download only had a bunch of classes in it which ment I would have to create a new project and add them in to compile and run. I must confess I was a bit lazy.

Ogre got much more classes than Vector3 Quaternion ColourValue. Are you going to attribute all of them with your custom attributes ?
What I have done is a possibility to specify default converters/editors inside a resolver. You can automatically decorate all Mogre classes and be at easy.
Also i would like to point out one important thing, it's not only about converters, TypeEditors are also very very important.

I was only uses those classes as examples. I think your method is a great idea and I really want to help complete it. I'm sorry that I didn't fully grasp the concept at first. I was just getting a little impatient and wanted to start testing things to make sure it was all going to work. I won't interfere with your contribution to the project, but at least I've learnt enough in the last 3 days get right in and start implementing the other TypeConverters and Editors.

there was not so hard, just four hours of boring rewriting

[attachment=1]cli_design.png[/attachment]

And yes, I embed it into Mogre, compiled and tested )

And there is the source code:

[attachment=0]MyMogreDesign.rar[/attachment]

And now let me explain how to embed it into Mogre. It's very easy. Just add my code to the Mogre project and for each class you want to be designed do the following:

For example, lets change the Vector3. Ok, open MogreVector3.h and add this line after all includes:

#include "MogreDesign.h"

Then, add this lines after all namespace usings:

using namespace MyDesignSupport;
using namespace MyDesignSupport::TypeConverters;
using namespace MyDesignSupport::TypeEditors;

then, add this before the class:

[EditorAttribute(ResolvableTypeEditor::typeid,UITypeEditor::typeid)]
[TypeConverterAttribute(ResolvableTypeConverter::typeid)]

so you have

[EditorAttribute(ResolvableTypeEditor::typeid,UITypeEditor::typeid)]
[TypeConverterAttribute(ResolvableTypeConverter::typeid)]
public value class Vector3 : IEquatable<Vector3>
....

And that's all! And then just use it

2koirat: Yes, I'm on your side Sorry, I made some little changes, so it can differs between your c# code and my cli variant )) I added ExpandableObjectConverter, so I can expand vectors to their components.

I changed Mogre's types too, added [Browsable(false)] almost for all the properties, because they are not interesting my users Also added properties for vector's, Quaternion's and Color components (X,Y,Z,W).

Good luck, hope this code will work

[edit]
If you will use my code outside Mogre, just delete

#include "MogreStableHeaders.h"

line in all *.cpp files. That is Mogre precompiled headers.

2koirat: And sorry for changing namespace name, just tested that with your code together, so there was a conflict )

And there is the source code:
MyMogreDesign.rar
my source files for MogreDesignSupport
(10.73 KiB) Downloaded 2 times

Very nice Seregvan. This was obviously the code I was missing. I fully understood how the resolver handles multiple types once I saw this:


converters = gcnew Dictionary<Type^, Type^>();
converters->Add(Quaternion::typeid, QuaternionConverter::typeid);
converters->Add(Vector2::typeid, Vector2Converter::typeid);
converters->Add(Vector3::typeid, Vector3Converter::typeid);
converters->Add(Vector4::typeid, Vector4Converter::typeid);
converters->Add(ColourValue::typeid, ColourConverter::typeid);


using namespace MyDesignSupport;

Of course, in the final implementation the namespace should probably be something like: Mogre::DesignSupport

Okay so the next question is, what other converters to we need?

dont know ) We have Vector2, Vector3, Vector4, Quaternion, Matrix3, Matrix4, ColourValue. I think that's all, there is nothing to add, but maybe I'm wrong

[edit]
Maybe it will be nice to add Ogre::Image viewer. Just like matrix editor, but with image view. But this is not necessary, just some "additional" stuff

We have Vector2, Vector3, Vector4, Quaternion, Matrix3, Matrix4, ColourValue. I think that's all, there is nothing to add, but maybe I'm wrong

Maybe Ray and Plane. I actually tend to agree that we don't need to do all that many, but that could be because my project doesn't require them (yet).

Ogre got much more classes than Vector3 Quaternion ColourValue. Are you going to attribute all of them with your custom attributes ?

I get the feeling koirat has more in mind? Perhaps he wants to include many more from the auto generated classes like Entity, Font, Light, Material, Mesh, Texture? I'm not sure how they would work exactly, but having a quick glance over all the classes in Ogre I don't think there would be all that many useful ones.

Unfortunately, for a really professional job we would need to go through and add [Browsable(false)] to many of the properties, and some descriptions would be nice too. The difficult part about that is when we regenerate the auto classes for a future version of MOgre we would loose all that work unless there's some way to preserve it.

Does the colour picker handle aplha values? There's another improvement that could be made.

A lot of progress has been made in the past few days. Good work

I think it's not necessary to implement Entity and etc. editors, but it's not so hard Just ExpandableConverters with Expandable objects ))
So, I think we will wait for koirat's opinion

[edit]

To implement color picker with alpha support we should write own color picker, but, it's not so hard

[edit2]

Just found some bugs, that should be solved: when selected a few objects of one type, any ColourValue properties (if their values are not equal) becomes null in PropertyGrid, so it crashes with nullptr exception. The same error occurs when trying to edit this 'null' value. So this situations should be resolved (as I can imagine, this bug occurs with every editable property type).

Nice, you even translated the editors. No surprise it took you 4 hours.
Also we can reconsider keeping editors/converters in an external library and only resolvers (or even only ResolvableTypeConverter/Editor // ITypeConverter/EditorResolver) include into Mogre code. That time you can change resolvers/converters/editors without recompiling mogre (you know how hellish versioning can be). Also writing in C# is easier/faster than c++/CLI.
I think that Gantz should make some statement about this as a step father of Mogre.
I'm personally voting for external library, it's just one additional library (usually you got a few of them already in ogre project) and not a mandatory one, you can run Mogre without it, it's just that it will lack design support at that time.

my thoughts:
1. Library is good, if no library - no desgin support, no errors.
2. there is a problem with the library - it will need all the types for the converters (Vector3, ...). Until now I used cyclic dependencies, but this is not good for some tools, for example Visual Assist and it only works with Framwork 3.5 +.

I'm ok with an external library, it will avoid risk of conflict when we will merge it to the trunk, and i will be easier to mogre user to add their changes if we stick with csharp.

i have add a branch based on 1.6.5 tag for mogredesign support. https://mogre.svn.sourceforge.net/svnroot/mogre/branches/Mogre_designer_support this way you will be able to "mess with" mogre code

about including generated classes (like entity), just modify autowrap to make it add attributes to the classes you want to enable at design time.
autowrap could be tricky to understand at first, so you can save it for later

@koirat, zarfius just pm me with your sourceforge account name if you want access to the mogre svn, i will add you to the project right away.

my thoughts:
1. Library is good, if no library - no desgin support, no errors.
2. there is a problem with the library - it will need all the types for the converters (Vector3, ...). Until now I used cyclic dependencies, but this is not good for some tools, for example Visual Assist and it only works with Framwork 3.5 +.

You will not need cyclic dependencies.It's not that we are not touching Mogre code at all.

I was thinking about something like this:
Mogre source should implement ResolvableTypeConverter/ResolvableTypeEditor and it's interfaces also DefaultResolverAttribute.
Then when somebody/propertyGrid is going to call for converter/editor, ResolvableTypeConverter should check if MogreDesignSupport.dll is present.
If it is not, it should do what it would do if no explicit attributes were used.
If it is present it should load this assembly and search for class that implements ITypeConverterResolver and got DefaultResolverAttribute <--- We will have to implement such an attribute. (It's in case of more than one resolver in an assembly) when only one is present it is default, also if no DefaultResolverAttribute is present we can take the first one found.
Than it creates this object (ITypeConverterResolver) and saves it at static field ResolvableTypeConverter.TypeConverterRersolver.

So only MogreDesignSupport.dll have to know about Mogre.dll. Mogre.dll don't know anything about MogreDesignSupport.dll except of, that it is using some clases/interfaces defined in Mogre.dll.


@Gantz
I will contact you ASAP, stand by

[edit]
How could i miss your post @Seregvan @zafirus i will check out this issues that you have found.
@Seregvan
Selecting like PropertyGrid.SelectedObjects ?

BTW I'm investigating TypeDescriptor/TypeDescriptorProvider right now and i will see if it can be of any use for us.

You can also implement AxisAlignedBox/ Rectangle / Sphere

The more advanced feature that I was thinking of was for example ability to set Fog via property grid, I have done it in my code, but this is not a trivial converter. Since you have to call SceneManager methods.
[/edit]

I think it's not necessary to implement Entity and etc. editors, but it's not so hard Just ExpandableConverters with Expandable objects ))
So, I think we will wait for koirat's opinion

[edit]

To implement color picker with alpha support we should write own color picker, but, it's not so hard

[edit2]

Just found some bugs, that should be solved: when selected a few objects of one type, any ColourValue properties (if their values are not equal) becomes null in PropertyGrid, so it crashes with nullptr exception. The same error occurs when trying to edit this 'null' value. So this situations should be resolved (as I can imagine, this bug occurs with every editable property type).

This bug occurs within UITypeEditors I have implemented.(ColorPicker / MatrixEditor)
So all properties that are not using Editors should work. For example Vector3 I have tested and it worked.

Take a look at this snippet from editor.

// Displays the UI for value selection.
public override object EditValue(System.ComponentModel.ITypeDescriptorContext context, System.IServiceProvider provider, object value)
{
if (value!=null && value.GetType() != typeof(ColourValue))
return value;


It's repaired. I'm checking if value is null.
It looks like value is set to null if you select multiple not equal objects. Previously it was trying to do GetType on null object.

I was thinking about putting more pressure on editors. Quaternions for example, who is going to edit them manually ? What we have to do is to create user-friendly form where you can set it also by euler angles, reverse it or rotate by some angle. When I started thinking about design support I got almost level editor in mind (I know it's overkill). But still PropertyGrid gives us so much power that it is hard to resist such a temptation.

PS. Guys you are just to fast . Hold your horses till i get svn access from Gantz

Yes, that was the error i recovered this exactly the same way But, there is one issue: if there will be non-ColourValue property with null value, it will return ColourValue object. But, of course, with the default using of theese editors it's impossible

So, about the editors: I will write Quaternion editor, I just need this at my work So, we writing on c#?

now I'm implementing cli support for loading DesignSupport.dll. It will be done soon

I have a great idea: all converters/editors solving will be done at runtime on loading (thanks for static variable TypeConverter), so, we can abstract from all Mogre code, all implementation will be done in MogreDesignSupport.dll, including assigning editors and converters to Mogre types, just like that:

[DesignSupportConverterUnitAttribute(typeof(Vector3))]
class Vector3Converter : ExpandableObjectConverter
{
...

So, we will point to Mogre types directly in dll, we won't need changing Mogre and type Attributes, it will be done automatically

Almost done, I will resolve some parser issues and share the code

Done

You just need to add theese files

[attachment=1]MogreDesignSupportEmbed.rar[/attachment]

Into Mogre project, nothing needs to be changed, just build.

Then, the cs project:

[attachment=0]MogreDesignSupportCS.rar[/attachment]

And that's all. Open CS project to see how to implement new editors. Nothing needs to be changed in Mogre. Any new converters and editors will be parsed and assigned automatically. Just don't forget to put MogreDesignSupport.dll near Mogre.dll.

So, we just need to add Mogre embed designer code files into Mogre project and it won't depends on Mogre version or any Mogre file changes.

Almost done, I will resolve some parser issues and share the code

We should really start putting all our changes back into the SVN that GantZ suggested earlier: https://mogre.svn.sourceforge.net/svnro ... er_support

I've been really busy today (you know, a real job and all that) but I've been reading the forum with excitement. It's great to see so many getting involved and the ideas are great. We should however put together a bit of a to-do list so that we avoid too much doubling up on work.

Here's a bit of a summary of things that have been suggested so far, we can use it as a bit of plan to figure out what needs to be done and who's going to do it. Feel free to add or change things if I've got it wrong.
- Create the external library project MogreDesignSupport.dll and add it to SVN
- Create the interfaces / classes in Mogre to connect to the external library
- User friendly controls for rotation, etc rather than editing Quaternions manually
- Implement Ray, Plane, AxisAlignedBox, Rectangle, Sphere if required.
- Update the auto genertation scripts to decorate all the classes, make them expandable objects at least
- A lot of properties don't make sense in the property grid, if we can set them to [Browsable(false)] perhaps.
- Decide on appropriate namespaces and places to put the code, e.g. Mogre::DesignSupport
- Create a test application with a property grid demonstrating what has been done and add it to the SVN.
- Allow the type converters and editors to be customised by the end user if they want or stick to the default ones.

UI Editors (just a couple of ideas off the top of my head to get the list started)
- Colour picker with alpha support
- Easy rotation control (e.g. common rotations, 45, 90, 180, around an axis)
- Image viewer
- Material picker
- Mesh picker

Personally, I wouldn't mind working on the colour picker with alpha support and I can help with testing and bug fixes whenever I find them. I'll probably be pretty busy during the easter break but I'll be watching closely and contributing what I can.

What is already done (maybe you skipped my last post):

- external library MogreDesignSupport.dll created.
- created connection code for Mogre to connect MogreDesignSupport.dll.
- all connection code have namespace Mogre::DesignSupport. There is no need to use it, but it's there

if user wants to create his own converter, he should change MogreDesignSupport plugin, or adding custom converters by pointing attributes to his own properties.

now I'm modifying embed Mogre designer code to handle user preloaders. Preloader is something like this:

public interface IDesignPreloader
{
void OnPreload();
}

so user can handle loading process and modify any class, property, etc...

class MyDesignPreloader : IDesignPreloader
{
public void OnPreload()
{
// changing, for example, Vector3.Length property, make it browser-invisble (adding attribute [Browsable(false)]
}
}

there can be any number of user classes, thoose implements IDesignPreloader. All user functions will be called. So, using this, we shouldn't change Mogre source code to change properties attributes and etc. The main point is to fully abstract from Mogre, no changes are needed. We can do everything in MogreDesignSupport.dll and if user don't want to user designer support, his Mogre classes will be clean, without any additional information.

@Seregvan
Judging by your work on this project it looks like you need this stuff badly. Do you have an svn access ?

I was so focused on fully automated process of using DesignSupport that I did not even think about manual loading. Anyway I think your idea is very good.

Things that I would changed are:

void MogreDesignLoader::LoadConvertersAndEditors()
As i assume this will be a part of Mogre.dll.
We do not need all of this inside there, we can just search DesignSupport for default Resolver (DefaultResolverAttribute I was talking about before). And Just create it. It can do all the dirty work you are doing in this method. Also we are not restricted with anything. And custom resolvers are more natural that way.
So DesignSupportConverterUnitAttribute this class is Resolver specific class. So it should not be inside mogre.dll.

If you look at the code of ITypeConverterResolver:

public interface ITypeConverterResolver
{
TypeConverter GetTypeConverter(ITypeDescriptorContext context);
}


You can see that it is not only about Type of converted object. Resolver that I made, based just on type is just the simplest usable it was meant for testing . ITypeDescriptorContext contains some nice data like "instance" or "propertydescriptor" that can be used when choosing editors.

@zarfius
I'm also aware that this project is out of control. It's because of Seregvan speed . But it should take more stable motion when the way Mogre handles DesignSupport (or DS handles Mogre) will be more sure.

ok... earlier I told about preloaders, so, let this code will be a preloader? It will be the same system for all loading and ResolverAttribute will not be the part of Mogre. There is nothing left with Mogre, just a preloader, which will handle MogreDesignSupport.dll preloaders, who will do all registration work and etc. What do you think?

[edit]

So, there will be just a preloader calling inside Mogre, nothing else. No converters, resolvers, etc. All this stuff will be in MogreDesignSupport. Loading will be done at OnPreload stage.

And don't worry about my speed It's only when the base code should be written


MogreDesignSupport.Loading(object obj)

I was not thinking a lot about this two below, but maybe we should reconsider it, in case somebody wanted to reload MogreDesignSupport.
MogreDesignSupport.Dispose()
MogreDesignSupport.IsDisposed


Should do just fine. If you ask why object obj, well just in case of multiple options.

could you explain your idea more deeply?

MogreDesignSupport.Loading(object obj)
(You want .Loading to be visible by Mogre I hope)

We can have multiple Resolvers or multiple "packs" of editors inside MogreDesignSuport in this case we can put some data into our Loading method that can determine what resolver to use. That is just an example. I just don't think we should close a possibility of sending data into our loader. It does not meen we have to use it right now.

Do I have to explain why I think we should add IDisposable interface to MogreDesignSupport ?

As I see, you want to have a Load function to parse resolvers, it will handle specified resolver and initialize it? You want let user to change resolver to his own? If that's true, there will be a default resolver and by default Mogre will load default resolver when program starts?

" As I see, you want to have a Load function to parse resolvers, it will handle specified resolver and initialize it? "

Load function should load MogreDesignerSupport it may parse for default or specified resolver or whatever the one who implements MogreDesignerSupport .Load wishes. Maybe the object you pass to Load function will be a resolver itself.

"You want let user to change resolver to his own?"
Yes this would be nice.

" If that's true, there will be a default resolver and by default Mogre will load default resolver when program starts? "
Yes/No. MogreDesignerSupport will load default resolver not Mogre. But I don't know what do you mean by program starts. As I'm assuming we will not load it without user knowledge? MogreDesignSupport.Load got to be called explicitly. ?

Yep, I thought Mogre will automatically load designer stuff if MogreDesignSupport.dll is present. I think if user placed this dll with Mogre.dll, he wants to load designer And there are no reason to do it manually.

"I think if user placed this dll with Mogre.dll, he wants to load designer And there are no reason to do it manually."
It will be present in Mogre SDK as I hope so you download all the stuff. it's the same as with ogre you usually download it with plugins not always needed.

"Yep, I thought Mogre will automatically load designer stuff if MogreDesignSupport.dll is present."
And how would you do that ?

If i want to use only Vector3 from Mogre I'm forced to load all the stuff ? (considered MogreDesignSuppport.dll is present)[and it will be]

And how would you do that ?

I did that

But, you are right, maybe user should Load it manually.

[edit]

As I discovered, we can add Attributes only to classes, we can't add them to Properties. So, I have no idea how to handle with Browsable attributes without changing Mogre classes

As I remember you can remove a property during
TypeConverter.GetProperties for example QuaternionConverter.GetProperties and filter what you don't need, without BrowsabeAttribute

So don't exhale your breath yet


"I did that"
Sorry my mistake.

You can do this during creation of MogreDesignerSupport that is initialized by default.
Did you do it like this ?

Also check if you can add attribs to structures. In the beginning i was investigating TypeDescriptorProviderAttribute it was almost perfect but did not supported structures. But you do it on types so it may not be the point.

[edit]
My mistake i have written TypeConverterProviderAttribute instead of TypeDescriptorProviderAttribute previously.
[/edit]

Yep, we can change properties in convertors, maybe So, what is your point? can you draw a scheme and structure of the result?

My point is that there is no need to cry that you can't handle BrowsableAttribute.

There are two situations:
1. User just want to use PropertyGrid without knowing what MogreDesignerSupport is, that time he just use what we give him and that's all. We gave it all without Browsable(false), it will be our default implemenation.

2. Second Situation is when user wants something extra like (for example) hiding some properities. That time he got to link his project with MogreDesignSupport.dll explicitly. And Create his own (resolver and converters) or (resolver or converters). We can of course create some base classes that will help create such a behavior, (for example base class for converter that will hide properties based by name or PropertyDescriptor).



Yes I would like to create something i just need some time to rethink all of this. Until now I was a little distracted by posting. It's hard to work on something when you know that it may change in 10 minutes. I will try to give you some info until tomorrow, after this I will be busy with Easter.

ok, waiting your thoughts

I don't have any graph or structure ready, since it took me so long to get to this point. So allow my code to speak for itself .

To make the long story short i decided to drop simple TypeDescriptor.AddAttribute instead I use TypeDescriptor.AddProvider.
In the end it looks like we will drop also TypeConverterResolver and TypeEditorResolver. That tasks we can do with a TypeDescriptionProvider-s.

I have thrown a lot of trash from this solution to fit upload limit on this forum, so it may be hard to compile. But good luck.

If you got any problem ask, I'm not writing more because I'm too tired

If nobody else is in the middle of it I'm ready to add these changes back to the SVN in the designer support branch but I'm a bit confused by the last few posts what actually needs to be done?

You can commit this, if you think it's good.
This is my latest code it's written in c#.
I did not translated it since c# is more natural to me and I wanted some comments from you guys before adding it to the Mogre.

I have added an attachment with this code and some example application (similar to previous one but with some changes).

If i got no response I will consider it accepted and commit it myself. (I'm talking about mogre.dll addition only)
MogreDesignSupport.dll is a different story. You may see some example in my example application .

Check out MogreDesign.cs in example application.

This should be in Mogre.dll:

//Mogre.DLL
public static class MogreDesignSupportLoader
{
// This static fields holds reference to the current loaded IMogreDesignSupport
static IMogreDesignSupport mogreDesignSupport;
public static IMogreDesignSupport MogreDesignSupport
{
get { return MogreDesignSupportLoader.mogreDesignSupport; }
}

public static bool IsInitialized
{
get{ return (mogreDesignSupport!=null); }
}

// There are three kinds of initialization

//Initialize() this one initialize first found default IMogreDesignSupport
public static void Initialize()
{
Initialize(null,null);
}

//Initialize(string name) this one initialize first IMogreDesignSupport whose attribute name field match name argument
public static void Initialize(string name)
{
Initialize(name, null);
}

//Initialize() this one initialize first IMogreDesignSupport whose attribute name field match
// but also take a parameter to Loading rutine of IMOgreDesignSupport
public static void Initialize(string name,object arg)
{
//if field is already initialized do nothing.
if (IsInitialized)
{
Console.WriteLine("Mogre Design Support already initialized.");
return;
}

// we will try to load the MogreDesignSupport.dll.
try
{
String dllPath = Path.GetDirectoryName(Assembly.GetCallingAssembly().Location);
Assembly ass = Assembly.LoadFile(dllPath + "\\MogreDesignSupport.dll");

Type[] types = ass.GetTypes();

foreach (Type type in types)
if (typeof(IMogreDesignSupport).IsAssignableFrom(type) &&
!type.IsInterface && (type.GetCustomAttributes(typeof(MogreDesignSupportAttribute), false).Length > 0))
{
MogreDesignSupportAttribute mdsa = type.GetCustomAttributes(typeof(MogreDesignSupportAttribute),false)[0] as MogreDesignSupportAttribute;

//name field of attribute does not match requested name so skip it
if (!string.IsNullOrEmpty(name) && mdsa.Name != name)
continue;

// if we do not use name to load, we check if its a default IMogreDesignSupport
// if it is not we skip it.
if (string.IsNullOrEmpty(name) && mdsa.IsDefault == false) continue;

IMogreDesignSupport imds = Activator.CreateInstance(type) as IMogreDesignSupport;
mogreDesignSupport = imds;
if (arg == null)
imds.Load();
else
imds.Load(arg);
break;
}

}
catch (Exception ex)
{
Console.WriteLine("Error parsing Assembly for converters: " + ex.Message);
}
}

//This one deinitialize MogreDesignSupport, after this we can load new MogreDesignSupport.
public static void Deinitialize()
{
if (!IsInitialized)
{
Console.WriteLine("Mogre Design Support was not initialized.");
return;
}

mogreDesignSupport.Unload();
mogreDesignSupport = null;
}
}

//Mogre.DLL
//This is a decoration attribute for IMogreDesignSupport, it tells us a name of IMogreDesignSupport
//and if it is a default IMogreDesignSupport to load. Usefull during Initialize() process.
public class MogreDesignSupportAttribute:Attribute
{
public string Name { get; protected set; }
public bool IsDefault { get; protected set; }

public MogreDesignSupportAttribute(string name):this(name,false){}

public MogreDesignSupportAttribute(string name,bool isDefault )
{
this.Name = name;
this.IsDefault = isDefault;
}
}

//Mogre.DLL
//It's an interface for MogreDesignSupport type of classes that reside in a MogreDesignSupport.DLL
public interface IMogreDesignSupport
{
// Two Load methods current MogreDesignSupport without any parameters and with parameter arg
void Load();
void Load(object arg);

void Unload();
void Unload(object arg);
}


For casual user magic starts after calling MogreDesignSupportLoader.Initialize() in a code, to initialize MogreDesignSupport.
After this loader search for default IMogreDesignSupport. If found it loads it. This was Mogre.DLL perspective.

MogreDesignSupport.dll perspective in my case looks like this. After loading MogreDesignSupport my implementation of IMogreDesignSupport, by the MogreDesignSupportLoader. It Starts to load it's IMogreDesignSupportPack. This packs adds TypeDescriptorProviders to TypeDescriptor.AddProvider . When doing it that way you can load/Unload this "packs" whenever you want, changing behavior of MogreDesignSupport that way.

I know, to many "Mogre" "Design" "Support" in my post, so it may not be very clear. But it is very easy after you grasp it.

Okay, so let me see if I understand this correctly.

These 3 classes / interfaces need to be converted to C++.NET and added to the Mogre.dll project:
- MogreDesignSupportLoader
- MogreDesignSupportAttribute
- IMogreDesignSupport

Do we need to add attributes to all of the classes in Mogre like you have done in the your your example? (I've changed FieldsEditor to ResolvableTypeEditor according to the comments in your code)


[EditorAttribute(ResolvableTypeEditor::typeid,UITypeEditor::typeid)]
[TypeConverterAttribute(ResolvableTypeConverter::typeid)]
value class MyStruct


If that's the case then I'll need to update the ones in the Custom folder (Vector3, Quaternion, etc) manually. Then update the script that auto generates the other classes as well.

Once this is all done and I've compiled a new version of Mogre.dll I should be able to take your MogreDesignSupport.dll and load it by calling MogreDesignSupportLoader.Initialize(). Once this works I could implement my own version of MogreDesignSupport.dll and load it instead?

These 3 classes / interfaces need to be converted to C++.NET and added to the Mogre.dll project:
- MogreDesignSupportLoader
- MogreDesignSupportAttribute
- IMogreDesignSupport


Yes.
I think this 3 classes are giving us some degree of flexibility.


Do we need to add attributes to all of the classes in Mogre like you have done in the your your example? (I've changed FieldsEditor to ResolvableTypeEditor according to the comments in your code)

No we do not have to add attributes to any of Mogre types. We "add" attributes at run time with use of TypeDescriptor.
I left FieldsEditor as an attribute because this implementation of ResolvableTypeEditor does not use FieldsEditor.


Once this is all done and I've compiled a new version of Mogre.dll I should be able to take your MogreDesignSupport.dll and load it by calling MogreDesignSupportLoader.Initialize(). Once this works I could implement my own version of MogreDesignSupport.dll and load it instead?


MogreDesignSupport.dll is using Mogre.dll so you will have to compile MogreDesignSupport.dll with new Mogre.dll. After all this classes:

MogreDesignSupportLoader
MogreDesignSupportAttribute
IMogreDesignSupport

Will be in Mogre.dll not in MogreDesignSupport.dll

Yes you can implement your own MogreDesignSupport.dll and most important your own implementation inherited from IMogreDesignSupport. You can do whatever you want inside it, even something completly unrelated with design support. It's just that there are limited ways of doing design support without decorating types in Mogre.dll. One of it is by TypeDescriptor.AddAttribute, it's nice and easy but you can't remove attribute once added (RemoveAttribute does not exists in this class).
Second by TypeDescriptor.AddProvider, this way you have more control and can "add" "remove" attributes from types (they are quoted because it's not exactly adding/removing), also this way you can hide some properties from PropertyGrid.
I have got an example of it in my implementation of MogreDesignSupport, the mechanism is working properly but it needs some tuning. This is why I was talking about adding stuff to Mogre.dll only.

Thanks. That makes it very clear.

Currently I'm at work so I can't do anything until tonight. Unless something else comes up (I have a 5 month old baby so you never know) I'll make these changes to the design support branch of MOgre.dll and commit the changes so others can use it. Once we are all working with the same code it'll be much easier IMO.

Once your happy with your implementation of MogreDesignSupport.dll it would be nice if we could add that project to the SVN as well for people who do not want to implement there own, or as an example of how to implement there own.

I'll make these changes to the design support branch of MOgre.dll and commit the changes so others can use it. Once we are all working with the same code it'll be much easier IMO.

Unfortunately I don't think I'm going to get around to finishing this anytime soon. If someone else wants to do it that's fine by me.

OK I will do it. I also finished MogreDesignSuport.

I translated it to c++/cli.

but my last thoughts about this stuff is that there is no point of adding it to Mogre at all.
After all the user got to Initialize it manually. Since it will be initialized manually we assume that the programmer know what he needs and then there is no reason to add any MogreDesignSupport code to the Mogre source. He can add reference to MogreDesignSupport.dll and initialize it there. I will prepare such a library and post it here. My vote is to consider it as an external add-on.

but my last thoughts about this stuff is that there is no point of adding it to Mogre at all.

You know, I was thinking the same thing at one point but I wasn't sure if I missed the reason it had to be added.

He can add reference to MogreDesignSupport.dll and initialize it there.

That seems like a more logical way to do it rather that have it look for the DLL in the current directory and it makes it very clear that Mogre doesn't provide designer support unless you need it for your project giving confidence that it won't slow down a game project with extra overhead.

I will prepare such a library and post it here. My vote is to consider it as an external add-on.

Looking forward to it. It could now become it's own open source project and reside in a different SVN on sourceforge and since it doesn't really care about what version of Mogre your using it should be easy to keep maintained.

It could now become it's own open source project and reside in a different SVN on sourceforge
why not keeping it in it's own directory in the mogre svn, like mogrenewt or mois ? The problem with addons is that there is no central repositories for them, so maintaining them is harder when the original creator is no longer working on them ( hydraxwrapper for example). Also, it's easier for people to have one place to check for addons, rather than having to search through forums to find where they can download addons source.

If the project grow larger, it will always be possible to move it to it's own repository, but right now, I just don't see a good reason.

why not keeping it in it's own directory in the mogre svn, like mogrenewt or mois ?


I was going to talk to you about this one. I still would like MogreDesignSupport to be a part of mogre SDK.

why not keeping it in it's own directory in the mogre svn, like mogrenewt or mois ?
I was going to talk to you about this one. I still would like MogreDesignSupport to be a part of mogre SDK.

I think both these points are good. The point I was trying to make it's good that MogreDesignSupport doesn't require a full recompile of Mogre to work.

The point I was trying to make it's good that MogreDesignSupport doesn't require a full recompile of Mogre to work.

I agree with that, since mogre is not especially easy to recompile, it's better to have a separated library.

On a side note, mogre 1.7 is near it first release (see mogre development thread), so the trunk will be fixed soon, and we will be able to add a new directory for design support. on a second step, there is plan to move to mercurial (since we rely on ogre source, it will be easier to use the same source control system), i will reorganise the directory structure of mogre and it addons then, and let you know when the switch will be made

It took some time but I was struggling with HardwareBuffer classes in my different project.

But going back to the MogreDesignSupport here is my latest code. Not tested with 1.7 but there should be no problems. What you have to do is to compile it with Mogre.dll. As an output you get MogreDesignSuppport.dll. There is also a test application. I'm awaiting your criticism .

Also i have got two questions about further development.

1. What should we do when property in an object inside property grid is null reference ? For example Matrix3 class.
We can skip it or create new Matrix3 class and allow to edit it.

2. Type converters and CultureInfo there are two approaches, one is to use what Ogre offers (all this parse methods) second is to use our own parsers that will take into account current culture settings. I'm talking mostly about " . " " , " problems for example 0.1 or 0,1 is 1/10.

Looking forward to taking a look at what you've done At the moment I'm a bit busy but I should get around to it in the next 48 hours or so.

But going back to the MogreDesignSupport here is my latest code. Not tested with 1.7 but there should be no problems. What you have to do is to compile it with Mogre.dll. As an output you get MogreDesignSuppport.dll. There is also a test application. I'm awaiting your criticism .

I'm very impressed how incredibly easy it was to get your code working. I managed to get design support in another project I'm working on. All I had to do was compile the MogreDesignSupport.dll, add a reference to it and call the Initialize() method.

Now for the criticism
- I noticed it takes a long time to load, and I traced the cause back to the method that applies the type descriptors to every class in Mogre. There are over 4000 of them
- In my project, a lot of the time I don't want objects to be expandable.

So, if you don't mind what I'd like to do is make it a bit more flexible in terms of what gets loaded and allow the TypeConverters to be a little more customised. What I mean by that is, make it optional to initialise the designer a different way. That way it'll keep the existing functionality as well.

1. What should we do when property in an object inside property grid is null reference ? For example Matrix3 class.
We can skip it or create new Matrix3 class and allow to edit it.

Well, if I understand you correctly, the ideal solution would be to leave it null but also allow the user to set it to a new Matrix3 class if they wish. The problem with automatically creating a new class is that it could break some code if it's expecting it to be null. I've done something similar in another project, it's a bit tricky to setup but the basic idea is to have a string that represents a null value e.g. "(null)" and allow the user to use a drop down combo to choose from a null value and a non-null value. Doing it this way works in my project, but it may need some rethinking for Matrix3 classes since they use a custom editor.

2. Type converters and CultureInfo there are two approaches, one is to use what Ogre offers (all this parse methods) second is to use our own parsers that will take into account current culture settings. I'm talking mostly about " . " " , " problems for example 0.1 or 0,1 is 1/10.

If you want to create your own parsers to handle different cultures I say go for it, however, I don't think it's a huge issue and I wouldn't worry about it too much unless you really need it.

When I was writing my own type converters for testing I added some extra functionality, for example typing "0" into a Vector3 would set it to "0 0 0".. or typing "1" would set it to "1 1 1". This is very handy for Scale values where your often setting all 3 values to the same thing. If we do end up creating custom parser's, this kind of functionality would be worth considering.

Now for the criticism
- I noticed it takes a long time to load, and I traced the cause back to the method that applies the type descriptors to every class in Mogre. There are over 4000 of them
- In my project, a lot of the time I don't want objects to be expandable.
After posting my code I was thinking that this method also include private/protected classes. It can improve performance to skip them.


So, if you don't mind what I'd like to do is make it a bit more flexible in terms of what gets loaded and allow the TypeConverters to be a little more customised. What I mean by that is, make it optional to initialise the designer a different way. That way it'll keep the existing functionality as well.

I was planning to add AddTypeAttributes/RemoveTypeAttributes method to it anyway. The code I posted is of course not final, but still usable.


1. What should we do when property in an object inside property grid is null reference ? For example Matrix3 class.
We can skip it or create new Matrix3 class and allow to edit it.

Well, if I understand you correctly, the ideal solution would be to leave it null but also allow the user to set it to a new Matrix3 class if they wish. The problem with automatically creating a new class is that it could break some code if it's expecting it to be null. I've done something similar in another project, it's a bit tricky to setup but the basic idea is to have a string that represents a null value e.g. "(null)" and allow the user to use a drop down combo to choose from a null value and a non-null value. Doing it this way works in my project, but it may need some rethinking for Matrix3 classes since they use a custom editor.

Yes we can add possibility to 'null' property inside TypeEditor. It's a good idea.



When I was writing my own type converters for testing I added some extra functionality, for example typing "0" into a Vector3 would set it to "0 0 0".. or typing "1" would set it to "1 1 1". This is very handy for Scale values where your often setting all 3 values to the same thing. If we do end up creating custom parser's, this kind of functionality would be worth considering.

Another great idea.

Great Well, the next handy step would be to add the project to SVN (alongside Mogre should do the trick) so we can merge changes together.

i will reorganise the directory structure of mogre and it addons then, and let you know when the switch will be made

@Zarifus Aren't we still waiting for some signals from Gantz ?

@Zarifus Aren't we still waiting for some signals from Gantz ?

Oh right, fair enough. No hurry. Plenty of other things we can do in the meantime. I'm sure we will hear from him soon.

about that, i have created a thread here about the switch, i think it's better to have the opinion of as much people as possible on this matter

OK I made my vote.
So now it is 100% on "Start a new repository with the latest trunk content".
This pool should be weighted, I did not do any addition to Mogre.dll so what can I know .

bump

I will update the announcement thread today, the mercurial repository is ready, so you will be able to use it for the property grid designer. i will pm everyone involved to give them access for the repository as commiter. in the meanwhile, assure yourselves that you have a bitbucket account.

The repo is located here : http://bitbucket.org/gantz/mogre/ , so you can have a look at what it have become

I have just added MogreDesignSupport to repository. There are some changes in directory structures.

Also:
-Added converters for Vector2 and Vector4
-Now all non public classes from Mogre are not added to TypeDescriptorProvider
-Ability to initialize all or only default types
-Added directory "ProxyClasses" inside is class called SceneManagerProxy this is an example class of proxy classes that might be useful. This one allows to set fog parameters via PropertyGrid.