GUI

FDR wrote:

Ok, I did something like this. We need a small proportional font. the system 5x7 is too wide. Currently the space needed between bars is too great just so the value can be shown.

The bars will automatically become 2 rows if the number of channels is > 8

The bargraph and trims are now configurable in config.ini

There is something missing again...

Changed channel numbering and the power indicator to have more contrast for colorblinds...

The ini doing the same thow: I had to change the modelname outline row to elsewhere to show up...

Which ini thing? I don't see any problem with the main page with the ini the way it was. I can't fix it if I can't see it

In the config.ini's font-modelname section the box_type was in a different line (une upper). When I removed the ; the outline didnt show up on the main page, only after I changed the line order.
This is the same behavior, abou which I wrote earlier: I had to move the whole font-timer section to make it work.
Try to move it down!

FDR wrote: In the config.ini's font-modelname section the box_type was in a different line (une upper). When I removed the ; the outline didnt show up on the main page, only after I changed the line order.
This is the same behavior, abou which I wrote earlier: I had to move the whole font-timer section to make it work.
Try to move it down!

Please show me a ini file that demonstrates this. I've played with it and can't reproduce what you are seeing.
of course if you uncomment the 'box_type=outline' you need to comment the 'box_type=center' below it as the last one wins. But I assume that isn't what you meant.

How can I rollback changes of a file in hg, if I don't want to commit and push it?

If you made a change and don't want to commit it, use 'hg revert'
If you already committed, but haven't pushed, you can sometimes do 'hg rollback' to uncommit the last changes (it doesn't delete them, just acts as if you never ran 'hg commit'

If you already pushed, or hg rollback doesn't work, you can use 'hg co -r <ver> <filename> to checkout a previous version of a file, and then re-commit it.

PhracturedBlue wrote: Please show me a ini file that demonstrates this. I've played with it and can't reproduce what you are seeing.
of course if you uncomment the 'box_type=outline' you need to comment the 'box_type=center' below it as the last one wins. But I assume that isn't what you meant.

Oops, the box_type might have been a mixup then, but the font-timer section was not, for sure!

I had a bad state checked in in the 0fed61653a6a version, which I corrected with the 364ffd7bec1e.
The timer and the voltage was not boxed after I added the font-title section...

FDR wrote: I had a bad state checked in in the 0fed61653a6a version, which I corrected with the 364ffd7bec1e.

0fed61653a6a does not include the fix I made

The fix was introduced in 20465642a645 which was a couple of revisions later. If you see it again, please let me know.

Also, try out the scrollbar on the mixer page (and make sure I didn't break the load/save page). I completely reworked the scrollbar code so it is more flexible, so hoefully there aren't too many more bugs.

Also: I'm off to bed. I need to get more sleep tonight than I did last night

OK, so it was just the doubled setting in the latter case...

PhracturedBlue wrote: Also, try out the scrollbar on the mixer page (and make sure I didn't break the load/save page). I completely reworked the scrollbar code so it is more flexible, so hoefully there aren't too many more bugs.

Very nice!
The program starts to look serious!

Back on topic:
On the mixer list you can't change page with the keyboard, because the cycling is limited to the visible buttons, and you can't reach the scrollbar with the keys (which is correct IMO).
Can you implement the auto scrolling I have described previously?
Plus it would be useful if the left/right worked too, certainly if we don't use it for changing pages anymore...
However the long up/down (and later left/right) press could work too to speed up the scrolling.

The model load/save page is worse, because there you can't reach the listbox with the keyboard at all.


When I first tried the new listbox, I dragged the position bar of the scrollbar to the end, and it worked! But after that I realized, that it is because I ended the long press on the arrow.
So the behavior of the controls now is like that: if you click the mouse anywhere outside the controls, and then drag it over a spinbutton or scrollbar arrow, it makes that control to do long steps...

One small crash:
On the model page if I change the protocol over J6Pro it crashes...

I have made the graphs on all mixer pages square to avoid distortion of the graphs, and made them clickable, which opens the curve editor.

FDR wrote: Back on topic:
On the mixer list you can't change page with the keyboard, because the cycling is limited to the visible buttons, and you can't reach the scrollbar with the keys (which is correct IMO).
Can you implement the auto scrolling I have described previously?
Plus it would be useful if the left/right worked too, certainly if we don't use it for changing pages anymore...
However the long up/down (and later left/right) press could work too to speed up the scrolling.

Give it a shot now. I completely reimplemented button handling to make it more configurable (and probably introduced a bunch of bugs)
As I've mentioned before, using left-right to get the selection is really hard.
However, long-press will now page down in widgets with scrollbars.
Making the widget scroll down one if you hit the end is also complicated, though probably doable, but I don't think we want to. It will be much slower to use than wrapping within the current page.

The model load/save page is worse, because there you can't reach the listbox with the keyboard at all.

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

When I first tried the new listbox, I dragged the position bar of the scrollbar to the end, and it worked! But after that I realized, that it is because I ended the long press on the arrow.
So the behavior of the controls now is like that: if you click the mouse anywhere outside the controls, and then drag it over a spinbutton or scrollbar arrow, it makes that control to do long steps...

if it is really annoying I can probably fix that.

One small crash:
On the model page if I change the protocol over J6Pro it crashes...

Fixed it

I have made the graphs on all mixer pages square to avoid distortion of the graphs, and made them clickable, which opens the curve editor.

looks good. i merged this stuff

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...

PhracturedBlue wrote: if it is really annoying I can probably fix that.

No need, because it won't occure in the tx, since we don't drag the pencil...


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!

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.

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.

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

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? When are the min/max values applied? What's the difference between these min/max and the ones on the mixer page? What does the safety selection does over enabling the safety value on that channel? Doesn't it supposed to be on on/off thing?



I think I will reorder the complex mixer page too to be more clear...

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...

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

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