GUI

FDR wrote: Do you like the green selection more then the red?
It's good on the header part, but almost unvisible lower...

I am red/green colorblind. I can barely see the red highlighting. I'd prefer white or yellow. The color I chose (cyan?) is visible on mostpages. Another thing I could do would be to allow you to configure the thickness of the highlight which would probably help.

FDR wrote: I've found a strange shortcoming: the keyboard doesn't work with the keyboard!

Yeah, I know about that. It is on my todo list. Here we definitely need to use left/right/up/down, but that is pretty easy to do.

FDR wrote:

PhracturedBlue wrote: I haven't added keyboard support to the listbox widget yet, but the scrollbar on the listbox should respond to long-press now.

Yes it mix things up, because we use up/down for stepping throw the controls, but on the listbox that would supposed to change rows...

Yes. I think it will be odd, but I'm not sure what to do about it. I don't think having the interface change would be a good idea. I do have one other thought:

We could swap the left/right and up/down buttons everywhere (so left/right stepped through widgets. We'd then need to draw the spinbox with up/down button on the ends. Then it would make sense to use up/down everywhere to modify the widget. I think this is probablythe best option

I was in the process of modifying the button.c and gui.h myself, but I was not ready, so I undid all my changes to get yours. Is there a way to rollback all changes in a file with hg to avoid need to merge?
I tried to do an image button (aka icon). But don't do it yet, I wish to try myself!

well, you can either use 'hg revert' or if you've already committed, you can do:
hg diff -r <prev ver>
then make sure that is going to do what you want, then
hg diff -r <prev ver> | patch -R -p2
(do that from the 'deviation/src' dir)
which will revert a commit mostly (not the images though)

Wow, woke up early!

PhracturedBlue wrote:

FDR wrote: Yes it mix things up, because we use up/down for stepping throw the controls, but on the listbox that would supposed to change rows...

Yes. I think it will be odd, but I'm not sure what to do about it. I don't think having the interface change would be a good idea. I do have one other thought:

We could swap the left/right and up/down buttons everywhere (so left/right stepped through widgets. We'd then need to draw the spinbox with up/down button on the ends. Then it would make sense to use up/down everywhere to modify the widget. I think this is probablythe best option

Actually that would be, how a real spinbutton works, it's just because of the touch screen that we have the spinning buttons on the two ends of it, to make it easier to click on them.
But it will look odd for sure!

The other option could be that both left/right and up/down change controls (after that they are not used for switching pages), but on a spinbutton left/right changes value while up/down leaves the control, on the listbox however up/down changes row and the left/right leaves the control. Standing on a button both left/right and up/down would leave the button.
But it would be confusing, I guess...

I don't know from left-handed/right-handed point of view, which is better...

PhracturedBlue wrote:

FDR wrote: Do you like the green selection more then the red?
It's good on the header part, but almost unvisible lower...

I am red/green colorblind. I can barely see the red highlighting. I'd prefer white or yellow. The color I chose (cyan?) is visible on mostpages. Another thing I could do would be to allow you to configure the thickness of the highlight which would probably help.

Now it is pure green.
Thicker border would help for sure!

If you are there, would you change the 140. row of the mixer_curves.c to return "1" by default. I have missed to change that...

FDR wrote: A few more bugs:
1. Stepping to the end in the trim- and trim+ spinbuttons of the trim page crashes too, like the protocol did.

fixed

2. On the curve editor if you select the more than 3 point curve to edit, and step to the last point in the point selection box, then change the curve type back to a fewer points one, then the point selection stays outside of the new boundaries.

fixed

3. A small one: you can set the min limit higher than the max limit...

fixed

EDIT: ...and I would put the Flysky protocol to the end, since it needs a different RF module if I understand well. I know it doesn't compile in, if it isn't asked for, but even so...

fixed

FDR wrote: If you are there, would you change the 140. row of the mixer_curves.c to return "1" by default. I have missed to change that...

fixed

Thanks, that was quick!

FDR wrote: Actually I don't really understand the channel setup page. What's the difference between setting it reversed, or inverting the channel source in the mixer?

On the channel page it is equivalent to the classic 'channel reverse'. the value is reversed right before sending it to the rx. On the mixer page, you are reversing the input (before any transformations). In complex mixers this will not have the same result

When are the min/max values applied? What's the difference between these min/max and the ones on the mixer page?

The mixer limits are applied for each mixer. The channel limits are applied right before sending to the tx. At the moment it is not possible to actually get values above -100-to-100, so the +/-125 aren't actually useful.

What does the safety selection does over enabling the safety value on that channel? Doesn't it supposed to be on on/off thing?

The safety value says 'when this switch is set, the channel value is <value>'

PhracturedBlue wrote:

What does the safety selection does over enabling the safety value on that channel? Doesn't it supposed to be on on/off thing?

The safety value says 'when this switch is set, the channel value is <value>'

So is this not the fail-safe value, which plays role, when the receiver looses signal?

FDR wrote: Wow, woke up early!

nah, this is pretty typical for me.

PhracturedBlue wrote: We could swap the left/right and up/down buttons everywhere (so left/right stepped through widgets. We'd then need to draw the spinbox with up/down button on the ends. Then it would make sense to use up/down everywhere to modify the widget. I think this is probablythe best option

Actually that would be, how a real spinbutton works, it's just because of the touch screen that we have the spinning buttons on the two ends of it, to make it easier to click on them.
But it will look odd for sure!

The problem with it is that it doesn't work if we have a spinbutton and scrollbar on the same page, since we would use long-press down for both...I dunno what to do.

The other option could be that both left/right and up/down change controls (after that they are not used for switching pages), but on a spinbutton left/right changes value while up/down leaves the control, on the listbox however up/down changes row and the left/right leaves the control. Standing on a button both left/right and up/down would leave the button.
But it would be confusing, I guess...

I think it will be annoying, because there is no single right answer to scroll hrough all widgets, you'd be scrolling along with 'right' until you hit a spin value, then you'd start changing its value...oops.

FDR wrote:

PhracturedBlue wrote:

What does the safety selection does over enabling the safety value on that channel? Doesn't it supposed to be on on/off thing?

The safety value says 'when this switch is set, the channel value is <value>'

So is this not the fail-safe value, which plays role, when the receiver looses signal?

No, I haven't enabled that yet. It is on my to-do list for today. It will go on the channel page too.

PhracturedBlue wrote:

FDR wrote: So is this not the fail-safe value, which plays role, when the receiver looses signal?

No, I haven't enabled that yet. It is on my to-do list for today. It will go on the channel page too.

I see. So behind the scenes it is just another replace mode mixer with a constant value, that kicks in when that switch is on...

PhracturedBlue wrote:

The other option could be that both left/right and up/down change controls (after that they are not used for switching pages), but on a spinbutton left/right changes value while up/down leaves the control, on the listbox however up/down changes row and the left/right leaves the control. Standing on a button both left/right and up/down would leave the button.
But it would be confusing, I guess...

I think it will be annoying, because there is no single right answer to scroll hrough all widgets, you'd be scrolling along with 'right' until you hit a spin value, then you'd start changing its value...oops.

There is a solution for it, but is complicates it even more:
If the scolling was only for the selection (thin boxed), and you should enter each control to actually edit the value (thick boxed), then everything would work right as expected, but it would be cumbersome...

PhracturedBlue wrote:

FDR wrote: So is this not the fail-safe value, which plays role, when the receiver looses signal?

No, I haven't enabled that yet. It is on my to-do list for today. It will go on the channel page too.

Will that be the first protocol dependent function?
Will you disable it if the protocol doesn't support it?
(For example the WK2401 doesn't have it for sure...)

FDR wrote:

PhracturedBlue wrote:

FDR wrote: So is this not the fail-safe value, which plays role, when the receiver looses signal?

No, I haven't enabled that yet. It is on my to-do list for today. It will go on the channel page too.

Will that be the first protocol dependent function?
Will you disable it if the protocol doesn't support it?
(For example the WK2401 doesn't have it for sure...)

I haven't decided. It would probably make it easier for the user if I did, but on the other hand, you should really know the capabilities of your model as to whether it will work. For instance, the 2402D doesn't send failsafe packets, but they are supported by the DEVO protocol. I have no idea if a 4ch DEVO Rx will respect them or not.

FDR wrote:

PhracturedBlue wrote:

The other option could be that both left/right and up/down change controls (after that they are not used for switching pages), but on a spinbutton left/right changes value while up/down leaves the control, on the listbox however up/down changes row and the left/right leaves the control. Standing on a button both left/right and up/down would leave the button.
But it would be confusing, I guess...

I think it will be annoying, because there is no single right answer to scroll hrough all widgets, you'd be scrolling along with 'right' until you hit a spin value, then you'd start changing its value...oops.

There is a solution for it, but is complicates it even more:
If the scolling was only for the selection (thin boxed), and you should enter each control to actually edit the value (thick boxed), then everything would work right as expected, but it would be cumbersome...

A hybrid solution is that the listbox woks like a popup or drop-down combobox. You'd need to select it to change its value, and while changing the value, you can't do anything else. It is (basically what you describe but only for the listbox). It would make more sense if there was no ok/cancel button (like the keyboard) but that would be somewhat annoying to use.

PhracturedBlue wrote: I haven't decided. It would probably make it easier for the user if I did, but on the other hand, you should really know the capabilities of your model as to whether it will work. For instance, the 2402D doesn't send failsafe packets, but they are supported by the DEVO protocol. I have no idea if a 4ch DEVO Rx will respect them or not.

I think there is no such thing as a simple 4ch devo rx.
They should support it.

I was only talking about the protocols, which is quite exact if it supports or not.

One thing to note: It was quite annoying in the original fw, that sometimes there were disabled controls, but you did not know why.
But it was just the case of wrong documentation, I think...

PhracturedBlue wrote: A hybrid solution is that the listbox woks like a popup or drop-down combobox. You'd need to select it to change its value, and while changing the value, you can't do anything else. It is (basically what you describe but only for the listbox). It would make more sense if there was no ok/cancel button (like the keyboard) but that would be somewhat annoying to use.

Well, better then nothing...