Future Tuning Software User Feature Wish List (UI stuff)

Free Open Source Software project discussion forum. Post your Free Open Source software projects here!
Post Reply
deviousKA
QFP80 - Contributor
Posts: 43
Joined: Tue Apr 01, 2008 10:36 pm
Location: Id, USA
Contact:

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by deviousKA »

After some googling I found mono seems to have some bugs with buffering, but couldnt really find any concrete info on latest mono version.

If you have the source open or want to try, remove the set_DoubleBuffered boolean that is causing the error and add these two lines after InitializeComponent(), in Form1.

this.SetStyle(ControlStyles.OptimizedDoubleBuffer, true);
this.SetStyle(ControlStyles.AllPaintingInWmPaint, true);

This works as an alternative to regular double buffering in windows, and found some hints that some may be using it with mono.

Source attached with optimizeddoublebuffer and better commenting also.
Attachments
GabesGDI+example2.zip
(59.77 KiB) Downloaded 727 times
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by Fred »

My mono version on the EEE is far from the newest, so that could be part of it. I could and may try it later on my deb unstable box and see if that is better as that is always bleeding edge :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: FreeEMS-Tuner Development Diary - Comments

Post by jharvey »

Some other features to add to the wish list,

-- real time point on the 3D graph, so that when your connected and running, or when you looking at the recorded log, it shows where in the table you are at.
-- buttons and tool bars that can be change or modified, For example if you want RPM and fuel, most other tunning software will waste space by keeping the other feed back on the screen. Perhaps some standard tool bars that can't be modified beyond turning on and off, then allowing for custom tool bars so you can get exactly the features you are looking for.
-- Some kind of a tolerances table. Setting up a typical table that shows typical min and max values. That way when davebmw, or a newbie like myself tries to tune it, I know how close to the typical limits I'm tuning against.
-- Different themes, say black with red text and buttons for night time, Something bright with high contrasting graph lines and text for laptops in the sun, and than normal warm and fuzzy for when you're programing at your leisure.
-- I don't think any software is complete with out easter eggs or some kind of bloat for the hell of it. Perhaps we could add http://www.zetcode.com/wxpython/thetetrisgame/ for fun.
-- 2D slice of the 3D graph, Perhaps the tolerance could be visible on the 2D showing min and max, as well as your selection at that point.
-- I see the top bar reads [name] [version] [build], perhaps it would be nice if it also included [time] and some other data up there.
-- I see version and build date at the bottom as well, does it need to be in two places?
-- Perhaps a diag option, that collects some information like OS, Python versions, ect. Such that when someone pops up saying they are having problem XYZ, here's my diag file. We then know their software base.
-- Can we move the "exit it out" at least a bit away from the every day use buttons. I know we've all said damn when we went to maximize or min the screen and the mouse wondered, causing us to self destruct. I've seen a KDE theme that put the X in the left instead of the right, however that might make this soft stick out a bit. Windows standard is to put the fun park next to the waste dump, so perhaps we should simply improve on this by adding a gap between X and the other buttons.
-- Perhaps a navigation bar on the side that can be expanded or clasped on command. Maybe a pull down will work well for this. Something that will remind you where you are in the software. Something that might look like this, but better.
  • normal use
    • sensor display (RPM, temp, ect)
    • 3D table display
    • tunning input display
  • diag
    • serial test / log
    • generate diag list
    • error codes / warning codes
  • settings
    • GUI settings / themes
    • comm settings
    • FreeEMS settings
  • stress relief (tetris)
Of course I don't want to over look the typical stuff, like sensor graphs, real time displays, logging, ect. The above really shows flash, more than functionality. So focusing on functionallity is definatly higher priority, the above it really just extras and planning.

Perhaps I should post the above here

http://www.diyefi.org/forum/viewtopic.p ... &sk=t&sd=a
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS-Tuner Development Diary - Comments

Post by Fred »

jharvey wrote:-- Some kind of a tolerances table. Setting up a typical table that shows typical min and max values. That way when davebmw, or a newbie like myself tries to tune it, I know how close to the typical limits I'm tuning against.
This will cause more trouble than it is worth. Some engines legitimately need 50 degrees timing, and others will explode at 25. Additionally, tip 120RON into the 25 degree engine and it becomes 35 degrees... if a noob trusts an indicator and it is wrong they will blow it. Finally, having 10 degrees timing based on the indicator when you should have 30 can do significant damage too!!!
jharvey wrote:-- I see the top bar reads [name] [version] [build], perhaps it would be nice if it also included [time] and some other data up there.
-- I see version and build date at the bottom as well, does it need to be in two places?
I was going to say that the top should read the firmware version that is being used too, and perhaps it should, but then again, perhaps it should just be as it is and the lower one (that I hadn't seen at all lol) should read the firmware version? I do think the firmware version should be obvious though. I think the following in the title bar :

"FreeEMS-Tuner 0.0.1 - FreeEMS Vanilla 0.0.17 pre-alpha"

Would be best and to reclaim that lower area for something else by removing the widget. This must be obtained from the device that is connected. The interface version should also be obtained and the interfaces range in the configuration/setup stuff should have to match or the app should refuse to work. If it has multiple configs available it could ask if you want to switch assuming it is available. You should note that multiple versions could and will share the same interface version, so what is displayed and how the app works are separate. I'll double post this in the comments thread for that app :-)
-- Can we move the "exit it out" at least a bit away from the every day use buttons. I know we've all said damn when we went to maximize or min the screen and the mouse wondered, causing us to self destruct. I've seen a KDE theme that put the X in the left instead of the right, however that might make this soft stick out a bit. Windows standard is to put the fun park next to the waste dump, so perhaps we should simply improve on this by adding a gap between X and the other buttons.
If I understand you correctly this is absolutely nothing to do with the application at all. What I guess you want is a "are you sure you want to exit, noob" dialog when you try to do that. The app IS aware of the close box. It just sends a signal to the app and the app handles it...
Perhaps I should post the above here

http://www.diyefi.org/forum/viewtopic.p ... &sk=t&sd=a
Done, if there were specifics to Aaron's tool, move or recreate them in the new thread I created here :

http://www.diyefi.org/forum/viewtopic.php?f=43&t=493

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: FreeEMS-Tuner Development Diary - Comments

Post by jharvey »

Fred wrote:If I understand you correctly this is absolutely nothing to do with the application at all. What I guess you want is a "are you sure you want to exit, noob" dialog when you try to do that. The app IS aware of the close box. It just sends a signal to the app and the app handles it...
I'm not a fan of the double exit technique. More mouse clicks and garbage as far as I'm concerned. I like the little X in the corner, but don't like how close it is to the min and max buttons. I believe this is standard for wxWidgets, but also seem to recall you can choose not to use that one, then create your own allowing you to change it up.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by Fred »

Whether I use double exit or not depends on how important the app is. I have double exit for firefox on for many tabs and off for a single tab. I have it on for eclipse and off for pidgin etc. This could/should be made configurable, however no-ones application can control the presence of my close and max/min boxs in a normal window frame environment.

However, this raises another question, why waste space on window frames at all? Why not render to a frame-less window? At that point the app designer has total control of the placement of all buttons and controls and the windowing environment has very little control. The max and min could be stashed in a menu and the close be the only thing exposed in the corner. I suspect you would have significant opposition to the frameless idea though. I would like it sometimes and loath it others, so that would need to be on/off able too. More work :-)

I'll say this though, if you are working on something important, be careful with what you do! Also, if you just close the app while tuning it won't erase the data in the devices RAM unless you also power it down. In this case, just reboot the app and you are exactly where you started with no loss.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by Fred »

On another note as inspired by the last posts ramblings, burning down to flash...

Should it be explicit? IE, only burn the bits you say to when you say to from their locations in the gui?
On a timer? IE, regularly at 30 second / 5 minute / 30 minute intervals?
Doable by dialog box with a display that shows what has and has not been burned down and check boxs saying which from those to burn down if you should push burn instead of cancel?
All of the above configurably?

Something to consider.

Another thing : When some flash only values are adjusted the device will not use them without a reset/reboot/reinit. If these values are changed something VERY obvious should displayed to let the user know. I would suggest that the entire background colour changes to red or something similarly blunt and obvious. Perhaps an obvious button could be added to the UI that asks to be reset or in the case of other changed data not being burned down yet to burn first and then reset.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
WTDeuce
QFP80 - Contributor
Posts: 40
Joined: Thu Sep 04, 2008 1:54 pm

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by WTDeuce »

Try MegaTunix (if you have MS1 it does everything, its not working with MS2 yet or at least not MS2Extra). Much better than MegaTune.

Some things id like to see:

What someone else mentioned, VE and Ignition tables open at the same time.

While MegaLogViewer is licensed, sometime similar to it for view logs is a must IMHO. Being able to have a full screen graph of all the variables, and the trail live file is awsome.

Obviously the ability to backup the entire configuration of the EMS is important, but at some point I think a handy feature to have in the tuning software would be a "Config Library" of some sort. Nothing fancy, just a basic interface which lets you organize the config files and make notes about them. I save configs regularly while tuning and testing, and its sometimes hard to make notes of what youve done via the file name. This should probably be integrated with the Project/Car interface if there is going to be one (tuning multiple cars with FreeEMS, and multiple configs for each one). And also possibly integrating datalogs into the car/project interface, like the config files so that you can make notes about the datalog and have it linked to the config file and such. The final extension of this is that its all just some directories so that it can be backed up and files can be used without the tuning software, and lastly a way to import other files (wideband logs or whatever).

Not high priority but full offline tuning, ie opening a config backup, making changes to almost anything, then saving it as another file to be burned. I doubt many people will need this, this mostly stems from my job in which I travel and tinker with maps and configs as im sitting on an airplane. MegaTune is a little funky with this ive found.

MegaTunix style tooth and trigger logger/display!!!!!!!!! To me this is one of the best features of MegaTunix even though I cant use with my MS2Extra yet.

A way to rename datalog fields thats portable/linked to the config and/or logfile itself somehow. Example, if theres a bunch of spare or generic or free inputs on FreeEMS and one is used for Oil Pressure, and another for Fuel Pressure, and a third for Oil Temp, it would be nice to be able to label those inputs as such so that it shows up in the datalog somehow.

Configurable gauges! If youre having gauges I dont mean like MegaTunix where they all look like AutoMeter gauges or whatever, just not like MegaTune where youre stuck with 2x4 dials. I have a widescreen hires laptop so thats the root of my desire to have 2x6 gauges or however many.

This might be a taller order, but complete app portability. Copy folder somewhere else and it runs, even off a USB key maybe.... Then again, this is because I have two laptops :p
WTDeuce
QFP80 - Contributor
Posts: 40
Joined: Thu Sep 04, 2008 1:54 pm

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by WTDeuce »

Oh and complete indication of what illuminated indicator means what.... By this im referring to "bit 7" and "bit 8" from MegaSquirt world.
WTDeuce
QFP80 - Contributor
Posts: 40
Joined: Thu Sep 04, 2008 1:54 pm

Re: Future Tuning Software User Feature Wish List (UI stuff)

Post by WTDeuce »

And last idea for now, support for big memory usage early on.... Im a whore for opening 25MB datalogs in MegaLogViewer :lol2: RAM is cheap afterall.
Post Reply