Closed GoogleCodeExporter closed 9 years ago
No problem. My concern is that I have seen too many times people using the same
switch for both trainer function and instant trim function. Then I thought it
would be better to have these switches configured in the same screen so that
they know what they do.
My idea was to remove this TrimSw from the model setup screen, right! But I can
leave it as it is, you decide!
No problem for the "Trims to Offsets". It's somewhere in my workspace.
Only reports then, could be quick. Let-me know what you would like to see here!
Bertrand.
Original comment by bson...@gmail.com
on 4 Oct 2011 at 8:10
Ah yes I remember now about the same switch for multiple things issue. It is a
valid point. Hmmm. I'll sleep on it.
Cam, are you reading this? Care to venture an opinion?
In the past, we have tended to sort of 'catch' ourselves doing the task of
trying to prevent others doing silly things and realised that the project
shouldn't suffer for the sake of silly things people haven't actually done yet.
(If you get my meaning.) My thinking now, before I sleep, is tending that way.
Comments welcomed.
Original comment by gru...@gmail.com
on 4 Oct 2011 at 9:56
Ok then, it seems urgent to wait a little bit :)
Bertrand.
Original comment by bson...@gmail.com
on 4 Oct 2011 at 10:03
Yes indeed. We must hurry up and wait, quickly and we must wait without further
delay! :P
I really cant decide. On the one hand, I really want to have the trainer switch
assignment on the trainer screen. On the other hand, it is too easy to forget
that instant trim is configured and try to use the trainer function. Also,
trainer activation should be a model set-up decision, not global.
I thought of all kinds of complex ways to try and protect users from accidental
double-assignment. Nothing much seems practical.
It simply remains that Instant Trim is a very, very dangerous function. That
and only that is the real problem here. I really don't like that just one
dangerous function forces us to make the rest of the project difficult to
understand.
My preference would have been to move the trainer switches back to the TRAINER
screen and leave Instant Trim in Function Switches. Since Instant Trim is the
dangerous function, it should be that function that takes on the responsibility
to be safer, if it can. Therefore, Instant Trim should examine the Trainer
Switches and if it is assigned to the same switch as any of the trainer
assignments, it should NOT activate. Perhaps it could have a little '!' appear
next to its switch assignment, too? But no, this doesn't really work because ..
This is still problematic, because the TRAINER stuff is in the global set-up
menus, not model menus. Clearly, the activation of trainer or not should be on
a per model basis, not global -- but the actual configuration of the PPM_IN
system probably should still be global. So once again, we arrive back at having
trainer activation in the per model Function Switches menu.
Bottom line? I guess it has to stay how it is now -- but mostly because trainer
activation needs to be per model, much less because of anything to do with the
very dangerous Instant Trim function.
Original comment by gru...@gmail.com
on 4 Oct 2011 at 9:36
TrimSw removed to be consistent with current state.
Trims2Offsets needs to be reported back.
Original comment by bson...@gmail.com
on 7 Oct 2011 at 5:29
Trims2Offsets re-added. Shouldn't we open a new issue to avoid mixing
everything between stable and future release?
Original comment by bson...@gmail.com
on 10 Oct 2011 at 9:51
Yes -- always. But this was needed for stable release, because there's people
here waiting for it who use that feature! (Much to my disgust. :P)
This issue is finished with. Quoting from above ...
"Bottom line? I guess it has to stay how it is now -- but mostly because
trainer activation needs to be per model, much less because of anything to do
with the very dangerous Instant Trim function."
Original comment by gru...@gmail.com
on 10 Oct 2011 at 9:12
It was already per-model you know, remember the traineron bit in the model
structure.
Original comment by bson...@gmail.com
on 10 Oct 2011 at 9:25
Yes, I realised that later on in the above text, I believe. That's why it made
so much sense to keep things as they were.
Original comment by gru...@gmail.com
on 10 Oct 2011 at 9:56
Original issue reported on code.google.com by
gru...@gmail.com
on 4 Oct 2011 at 8:00