Thread: An Open Source, Fast and Modular, C# Front End

NSFW: While yea that may be a good way to keep people interested in the project - it would be a step backward. I would be writing code that would never be used in the final project.

malcom2073: yes that was more in line with the plan. While its intended as a legacy feature (not the ideal way to design a plugin) application embedding will be possible with a single function.

Hessian: While our project goals seem to be different we are in need of developers if you are interested.

pRoFiT: I too have had to use it at work so i'm well aware of it. There is a task list in my head but it would probably be of more use if its written down. I wasn't saying scrum didn't apply as much as not in the traditional sense. In larger companies they handle multiple items simultaneously and prioritize each sub task for their item.

In open source we have (hopefully) multiple developers and while feature x may be priority 1 if we don't have someone who can code feature x but they can code feature y which ranks 3 - then feature y comes first. At times we may be able to do items 1,2 and 3 at the same time.

That said heres the roadmap (/priority list) - and it's on the wiki too:
1) Design the openGL rendering engine and create the basic control set (which well be expanded later) - panel, button, label, text box, image
2) Design the basic plugin system for High-Level Plugins
3) Design a hard coded main screen and begin performance testing
4) Build up the rest of the framework - OS Detection, basic tools, networking, database
5) First pass at the Low-Level Plugins
6) Expand control set - Checkbox, option box, Drop Down, List Box, Image List, Progress Bar, Embedded Application
7) Second pass at Low-Level Plugins
8) All Hardcoded modules moved to high level plugins
9) Skin Support
10) Rinse and repeat

like where this is going, will be keeping an eye on it, as well as adding any comments that I can to help out.

It is psoible to be written a soft what works with a simple serial kkl obd connector??what works with Op-com AB-COM..!!!....???to have gauges ang graphs THX

subscribed. looks good. If work quiets down i may be able to chim in... Looking forward to the progress.

Originally Posted by pRoFiT

Okay so just incase i somehow get free time to develop...This is in C#? .net 3.5? stuido 2008? So i can get the right programming environment installed. My pc crashed recently so i dont want to install vb6, studio 2000,2003,2005,2008 if i dont need to

Yea vs2008, .net 3.5

I hate having to upgrade each set of files when working on projects so I figure we might as well start with the newest.

Have you considered an event-based API for plugins? It would make it easier to extend the API without recompiling any of the plugins, because you'd just be adding messages that get passed to existing functions, not changing any functions. I picture some events would go to every plugin, every time, and some events going only to the "foreground" plugin. Kinda similar to the Windows GUI event system.

The drawback is that it becomes possible for two plugins to handle the same event in conflicting ways, but I figure that's mostly a plugin bug (or config problem with the plugins) if two plugins can't play nice together. You could give the event system a way to exclude certain plugins from receiving certain events as a way to work around that.

This paves the way for "micro plugins" that just handle a couple of events to provide simple features.

It just occurred to me that a front end core could consist only of an event system, a plugin loader, and a set of APIs for shared resources: audio, (mixing and exclusive use when appropriate) display (skinning), phone, etc.