Page 8 of 25 FirstFirst 123456789101112131415161718 ... LastLast
Results 71 to 80 of 241

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

  1. #71
    Variable Bitrate
    Join Date
    Nov 2007
    Posts
    303
    You take your basic tasks and break them up into priorities. Then work only on those priorites. As new ideas come in you reorganize the priorites. Then on top of that we do sprints. Where you take the priority items and work only at that top priority for that week, month or what ever tiem frame.
    Yeah, that's what I was getting at. It seems to me like the quickest route to building something that people will start using, which in turn is the best way to keep the project alive and growing.

  2. #72
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    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

  3. #73
    Maximum Bitrate ws6vert's Avatar
    Join Date
    Sep 2008
    Location
    Baton Rouge
    Posts
    523
    like where this is going, will be keeping an eye on it, as well as adding any comments that I can to help out.

  4. #74
    Maximum Bitrate pRoFiT's Avatar
    Join Date
    Apr 2005
    Location
    Fresno, CA
    Posts
    798
    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

    And its scrum not scrim. And part ot scrum is to devide the work up amongst a team depending on there skill set.
    Um, I guess this is where you put something witty.WITTY

    My Web site, in the design stage. http://home.comcast.net/~cstrachn

    Modified RRSkinEditor http://www.mp3car.com/vbulletin/rr-skins/65723-rrskineditor-bugs-fixes-comments-current-progress-outdated.html

  5. #75
    Newbie zsombi05's Avatar
    Join Date
    May 2009
    Posts
    9

    Soft

    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

  6. #76
    Variable Bitrate TeamRSX's Avatar
    Join Date
    Nov 2007
    Location
    Ottawa, Ontario
    Posts
    227
    subscribed. looks good. If work quiets down i may be able to chim in... Looking forward to the progress.

  7. #77
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    Quote Originally Posted by pRoFiT View Post
    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.

  8. #78
    Raw Wave
    Auto Apps:loading...
    justchat_1's Avatar
    Join Date
    Jul 2008
    Location
    Boston, Ma or NY,NY
    Posts
    2,359
    For anyone interested - i've started documenting the plugin interfaces.

    General description of how plugins work with the framework as well as some specifics for supported functions, etc.:
    http://sourceforge.net/apps/mediawik...?title=Plugins

    Feedback is welcome - theres a pretty good chance it wont be perfect till i've gone over it a few more times.

  9. #79
    Variable Bitrate
    Join Date
    Nov 2007
    Posts
    303
    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.

  10. #80
    Variable Bitrate
    Join Date
    Nov 2007
    Posts
    303
    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.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •