Thread: .Net FrontEnd

I've been following this thread off and on for several months. I was afraid it had gone dead.

Glad you hear you've made some significant progress.

What is your timeline right now as far as making this available for people to start working with it?

Looks awesome so far.

thanks for the interest. Im glad some people are interested. anyways, i'm hoping to release the interface sometime in the next month. I just need to finish up some basic testing, documentation, and a couple features.

Thanks for the idea.

I thought I'd tell a little about the skinning...
Im pretty much done with the skin engine and added a few more features which include:

1. At the top of each skin file a "required assembly" tag is required (similar to those "using" statements in a code file). This is because the engine is completely reflection based, so at the start of parsing the skin it creates a collection of all objects inheriting control in each assembly. This allows for you to add custom controls in your skin. So if you want to add Control123 thats in Controls.dll, just add that assembly to the required assemblies group and your done. Just call control123 like any other control and assign any property.

2. Also I was thinking, if people create their own controls to use in skins, they might have types of properties that require special processing to assign them. So the skin now has a collection of delegate references (SkinReaderTypes) which will convert the base string value from the xml file into whatever type necessary. Say you have a property that needs to hold some type of binary sound data, obviously you can't store that in the skin file, you could just write "sounddata.wav" for the value and then in your plugins constructor add a new SkinReaderType to the skin which will allow the skinreader to convert the file name into the sound data. I know there isn't any specific information here on how to do this, but I'm just giving you the idea. The skin reader already has all the basic skinreadertypes (int, long, float, double, Bitmap, Image, Color, Font, ANY enum, etc).

I've been investigating doing this exact project in C# for about a year now, and I even started prototyping a MediaPlayer app on DirectX 9, but just didn't have the time to dedicate to developing a full fledged app.

All of the other app's here are really well intentioned, and people did really great jobs with what they had to work with, but C# and the .Net platform have really opened up some great tools that I think could be used to make a great front end.

I can't wait to contribute to this project in some form or another. Whenever you're comfortable with releasing this project, I look forward to seeing it.

Thank you both for your interest in helping.

Dorgan... if you'd like to contribute you could start developing some of the plugins when the sdk is released, which should be pretty soon, as the base is pretty much done.

Originally Posted by zzachattack2

...All running plugins are inside a pluginhost. And every plugin inherits the Plugin class. So interacting with a plugin can be as simple as invoking a known member on a select plugin using reflection. Or... if you know the interface to a specific plugin, you can cast the select plugin to its known type and interact directly with it.
....

...to its known type at compiletime (=early binding) ? The "Intellisense" feature is a MUST IMHO. I don't want a Object.SetAttribute("Color","Red") ("How do I write VolumeMediaplayerDecreaseLevelPercentage ?" makes me ) - I want a Object.Color=Red ! (if I press . I.S. shows me Color, ....)
The type could be get from the .DLL assembly itself ...

So don't be shy - release some more pics/code - that we can answer

Originally Posted by zzachattack2

...The point of this post is to find out what other features you users, or developers would like from a program like this? Anything changed? Anything I may have left out to be added? Eventually i get around to creating a nice looking skin and display some screen shots. Thanks.

better

I would see your work as reply to "Programming Interface standardisation?". Then I would be on board too

Originally Posted by FMode

...to its known type at compiletime (=early binding) ? The "Intellisense" feature is a MUST IMHO. I don't want a Object.SetAttribute("Color","Red") ("How do I write VolumeMediaplayerDecreaseLevelPercentage ?" makes me ) - I want a Object.Color=Red ! (if I press . I.S. shows me Color, ....)
The type could be get from the .DLL assembly itself ...

So don't be shy - release some more pics/code - that we can answer

better

I would see your work as reply to "Programming Interface standardisation?". Then I would be on board too

Yes i mean it can be early binding, or not. For interacting with a known plugin, early binding is obviously the method of choice, but then again you need to include the assemblies containing that object, even if your plugin is only going to interact with another plugin just incase it exists.

Meaning lets say a plugin needs to mute the volume IF a media player plugin exists... it might be a little much to include the assembly containg the entire media player even if we don't know that the application has one... thats why both types have their benefits.