GUI: sensor status ON/OFF column superfluous now? - resolved

[Hamburger]

Hi,
I think the right column (ON/OFF) of the sensors is now no longer neccessary. The information displayed here is also shown via the (highlighted) checkbox item labels? So we could remove the ON/OFF column and free up some space in the GUI.

screenshot.jpeg

(30.08 KiB) Not downloaded yet

What do you think?

[Alexinparis]

Hi,
I think the right column (ON/OFF) of the sensors is now no longer neccessary. The information displayed here is also shown via the (highlighted) checkbox item labels? So we could remove the ON/OFF column and free up some space in the GUI.

screenshot.jpeg

What do you think?

I think it's a good idea

[Hamburger]

Ok. Will do soon.

[shikra]

I suppose it has some value - the checkboxes don't actually tell you if its working!
How about changing color of checkboxes - go green when enabled/active?

[guru_florida]

I suppose it has some value - the checkboxes don't actually tell you if its working!
How about changing color of checkboxes - go green when enabled/active?

That's what hamburger was implying with the red color coding of the checkbox headers in the screenshot. The checkboxes wont change color, but the rows heading will.

[Hamburger]

I suppose it has some value - the checkboxes don't actually tell you if its working!
How about changing color of checkboxes - go green when enabled/active?

That's what hamburger was implying with the red color coding of the checkbox headers in the screenshot. The checkboxes wont change color, but the rows heading will.

actually that color changing they already do. I did that to represent the status of the auxN switches some time ago.
After thisbeing available the ON/OFF column for the sensors does not give any extra information any more. Or if for some reason the ON/OFF status could be toggled by some other means besides the auxN then it could still be mapped into the background changing of the labels of the checkboxitems.

[shikra]

Sounds good to me. I never noticed the checkbox headers changing colour before.
Is better solution really as covers more status fields too.

Although I'm not a big GUI user apart from initial setup I do everything at the field with LCD

[Hamburger]

Although I'm not a big GUI user apart from initial setup I do everything at the field with LCD

same for me (big surprise?).

[Hamburger]

Ok. Will do soon.

done.
Needed some internal remapping of byte shifting in MWC for the modes (like armed) to factor those in into the checkbox statess' display more easily.
Works for armed, level, baro, mag for me; but please test this - I do not have GPS nor Camera.

[Alexinparis]

Hi,
that seems good.
note I won't take it for the 2.0 because it is incompatible with the current protocol for GPS:

Code: Select all

serialize8(accMode<<BOXACC|baroMode<<BOXBARO|magMode<<BOXMAG|GPSModeHome<<BOXGPSHOME|GPSModeHold<<BOXGPSHOLD|armed<<BOXARM); 

but for the version after, it will be clearer.

[Hamburger]

note I won't take it for the 2.0 because it is incompatible with the current protocol for GPS:

really this does matter for GPS? Or did you mean for some OSD?

but for the version after, it will be clearer.

ok. I do not mind too much about the official release. To me it is just some special snapshot of (probably) more public interest.
Only thing is I will continue a forward approach for development; so I will not unroll this change and I do not want to re-implement that at a later time.

[Alexinparis]

note I won't take it for the 2.0 because it is incompatible with the current protocol for GPS:

really this does matter for GPS? Or did you mean for some OSD?

It does matter for third part apps that relie on the 2.0 protocol (win GUI and rush OSD for instance)

but for the version after, it will be clearer.

ok. I do not mind too much about the official release. To me it is just some special snapshot of (probably) more public interest.
Only thing is I will continue a forward approach for development; so I will not unroll this change and I do not want to re-implement that at a later time.

ok, for me, it just means I will de correlate the main version from the _shared version until 2.0 is released. No need to unroll things in _shared.

[Hamburger]

It does matter for third part apps that relie on the 2.0 protocol (win GUI and rush OSD for instance)

Alex,
the way we have implemented the commands for now, it does require other programs to follow changes in MWii or become useless. For the time being this cannot be helped. the arduino hardware is too limited to include backwards compatibility implementations on the MWii side, so it will always have to be the other programs that need to catchup or become incompatible.

come to think of it, it might be better to change the M-command _before_ releasing 2.0. That way the protocol will not undergo a change right after 2.0 is released and thus making other programs that rely on M-command, become useless almost instantly after they have implemented compatibility to 2.0 release.

maybe as a first step we should implement an version-command in MWii, which responds by sending the version number of the protocol. We will simply need to increment this version whenever we change the M-command (or other). Then other programs can inquire protocol version and have parallel implementations for interpreting the different versions with backward compatibility, if they so choose. And we are more free to make changes to the protocol whenever neccessary.

my 0,02, yours to decide.

[kos]

M contains the version number ..

Code: Select all

   public DataMwiiConf(List<Integer> bytBuffer2) throws bufferErrorException {
    super();
    version = ( bytBuffer2.get(p++).intValue() & 0xff);
switch (version) {
case 201:
    // new protocol
  break;

default:
  // old impl
  break;
}

[Hamburger]

Yes. But it is a generic mwii version, not specific for protocol. If you think that already is good enough, ok.

[Alexinparis]

It does matter for third part apps that relie on the 2.0 protocol (win GUI and rush OSD for instance)

Alex,
the way we have implemented the commands for now, it does require other programs to follow changes in MWii or become useless. For the time being this cannot be helped. the arduino hardware is too limited to include backwards compatibility implementations on the MWii side, so it will always have to be the other programs that need to catchup or become incompatible.

come to think of it, it might be better to change the M-command _before_ releasing 2.0. That way the protocol will not undergo a change right after 2.0 is released and thus making other programs that rely on M-command, become useless almost instantly after they have implemented compatibility to 2.0 release.

maybe as a first step we should implement an version-command in MWii, which responds by sending the version number of the protocol. We will simply need to increment this version whenever we change the M-command (or other). Then other programs can inquire protocol version and have parallel implementations for interpreting the different versions with backward compatibility, if they so choose. And we are more free to make changes to the protocol whenever neccessary.

my 0,02, yours to decide.

Hi,
I think the Serial protocol would require some "fresh rebraining" not compatible with a quick fix approach and the imminent 2.0
I prefer to think about it after in order to be a generic as we can regarding version changes.