tuningsoftware developers brainstorm on this page to avoid duplication of work and keep the design nice and maintainable
I find it likely that for the tuning and displaying software we need to maintain (hopefully just) 2 independent codebase for the low level stuff: GUI, comm (RS232, TCPIP) because of technology and resource usage reasons (large thanx to microsoft innovation and standards abuse.
Common infrastructure includes: (see OtherTuningSoftware/CommonInfrastructure)
To make the above (realistic) scenerio maintainable, we need to split as much of the logic to interpreted code (txt, xml or config files, whatever you call it), that only needs to be maintained once for all branches.
- detailed variable explanations. Actually, as we parse global.h struct config_t , we thought about having more information about those (comments) in parsable form. Just XForms didn't show up at that time somehow, and putting everything to inlined comments into the code was avoided.
- formulas for calculating real-world user input (maybe including broken nonmetric units) to ECM values
- inverse formulas for the other dir: ECM values => displayable units
- don't forget the packed variables (like bitfields)
- layout of the screens. I strongly believe that widget packing should not be wired into the binary (I mean maintenance should be common for all the branches: if it's packed to one file or not is a minor issue). This means that selecting another layout that matches the user's display resolution is just the matter of a config file, not effecting other parts of the system.
Low level stuff:
We try to shring it as far as possible.
Probably separate branches are reasonable for these:
- interpreter for the common infrastructure (see above)
- GUI
- comm
- RS232
- TCPIP (same protocol, but different wire implementation: see GenBoard/AdvancedComm)
platform for the main branch
I assume there will be at least another branch besides the main branch (eg. for loseCE machines maybe?).
For the main branch, Java would be a better platform than C or C++, because of development costs.
- java ensures many safety things that must be taken care by the programmer in C and C++, so less errors with less debugging
- superior development environment, see eclipse.org.
Java improved impressively in the last 9 years, and became the nicest option for most non-realtime tasks. However it still uses relatively much resources (that much resources available on most desktops an notebooks, and probably most PDA).
C# is not based on an industrial standard, and it's advantages don't come near it's disadvantages (if we think globally and long term). But a C# branch (for the low-level stuff of course) can still be maintained easier than a similar C solution. Whoever picks the task will choose.
This is not the place for programming languages holy-wars, we just want a better usable, maintainable tuning software with the minimal possible total work that covers most platforms.
Brainstorming - the rest of this page:
looks nice:
http://thinlet.sourceforge.net/overview.html
XForms: common layer for describing parameters
It's quite self-explanatory, that the data manipulation and the
GUI implementation must be decoupled to a large degree.
We already started it on the lowest level by naming config variables and arrays and tables that can be filled in several ways.
I found that XForms does the decoupling almost _exactly_ as we need.
There are implementations for all kinds of systems (including browsers and PDAs too).
It does not prevent us to make our full-featured widgets for some special platforms (java, GTK, win32) if we like.
Anyway, XForms should boost the tuningsoftware issue. Please think about it, and tell your ideas.
See also: