IMPROVED TRIM BARS

Hi all,

Long time ago I wanted to start helping with the development of deviation but until I got a 12S not found the time to do it.

Using deviation I always found the trim bars a bit annoying so I decided to modified them and improved them a bit.

The new bars that I made have: middle, quarter middle and eight marks.

Also the slider mark had been improved.

I attach here the code of the new _bargraph.c if Phractured wants to add it.

I would like to start helping with the development and improvement of the deviation gui with the permission of Phracture and all the other masters.

Hope that u like the change,

Cheers,

Lyndros

/*
This project is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

Deviation is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with Deviation. If not, see < www.gnu.org/licenses/ >.
*/

#define TRANSPARENT_BARGRAPH
#define TRIM_THICKNESS 6
#define TRIM_MARK 2
#define TRIM_MARGIN 1

u32 _bargraph_get_color(s32 val, struct guiBarGraph *graph, struct disp_bargraph *disp)
{
s32 center = (graph->max + graph->min) / 2;
return val > center
? disp->fg_color_pos
: val < center
? disp->fg_color_neg
: disp->fg_color_zero;
}
void _bargraph_trim_horizontal(int x, int y, int width, int height, s32 val, u32 color,
struct guiBarGraph *graph, struct disp_bargraph *disp, struct guiBox *box)
{
(void)box;
val = (TRIM_THICKNESS / 2) + (width - TRIM_THICKNESS) * (val - graph->min) / (graph->max - graph->min);
s16 xpos = graph->direction == TRIM_HORIZONTAL ? x + val : x + width - val;
if (Display.flags & TRIM_TRANSPARENT) {
GUI_DrawBackground(x, y, width, height);
} else {
LCD_FillRect(x, y, width, height, disp->bg_color);
}
//LCD_DrawFastHLine(x, y + height / 2, width, 0x0000); //Main axis

//Bar trim points
LCD_DrawFastVLine(x + 1 * width / 8, y, height / 2, disp->outline_color); // 1st trim point
LCD_DrawFastVLine(x + 2 * width / 8, y, 2 * height / 3, disp->outline_color); // 2nd trim point Middle
LCD_DrawFastVLine(x + 3 * width / 8, y, height / 2, disp->outline_color); // 3rd trim point
LCD_DrawFastVLine(x + 4 * width / 8, y, height, disp->outline_color); // 4th Center
LCD_DrawFastVLine(x + 5 * width / 8, y, height / 2, disp->outline_color); // 5th trim point
LCD_DrawFastVLine(x + 6 * width / 8, y, 2 * height / 3, disp->outline_color); // 6th trim point Middle
LCD_DrawFastVLine(x + 7 * width / 8, y, height / 2, disp->outline_color); // 7th trim point

// Main rectangle
LCD_FillRect(xpos - TRIM_THICKNESS / 2,
y + TRIM_MARGIN,
TRIM_THICKNESS, height - TRIM_MARGIN * 2, color);

// Marking rectangle
LCD_FillRect(xpos - TRIM_MARK / 2,
y + TRIM_MARGIN,
TRIM_MARK, height - TRIM_MARGIN * 4, disp->outline_color);
}
void _bargraph_trim_vertical(int x, int y, int width, int height, s32 val, u32 color,
struct guiBarGraph *graph, struct disp_bargraph *disp, struct guiBox *box)
{
(void)box;
val = (TRIM_THICKNESS / 2) + (height - TRIM_THICKNESS) * (val - graph->min) / (graph->max - graph->min);
if (Display.flags & TRIM_TRANSPARENT) {
GUI_DrawBackground(x, y, width, height);
} else {
LCD_FillRect(x, y, width, height, disp->bg_color);
}

//LCD_DrawFastVLine(x + width / 2, y, height, 0xFFFF); //Main axis
//Bar trim points
LCD_DrawFastHLine(x, y + 1 * height / 8, width / 2, disp->outline_color); // 1st trim point
LCD_DrawFastHLine(x, y + 2 * height / 8, 2 * width / 3, disp->outline_color); // 2nd trim point Middle
LCD_DrawFastHLine(x, y + 3 * height / 8, width / 2 , disp->outline_color); // 3rd trim point
LCD_DrawFastHLine(x, y + 4 * height / 8, width, disp->outline_color); // 4th Center
LCD_DrawFastHLine(x, y + 5 * height / 8, width / 2, disp->outline_color); // 5th trim point
LCD_DrawFastHLine(x, y + 6 * height / 8, 2 * width / 3, disp->outline_color); // 6th trim point Middle
LCD_DrawFastHLine(x, y + 7 * height / 8, width / 2, disp->outline_color); // 7th trim point
// Main rectangle
LCD_FillRect(x + TRIM_MARGIN,
y + (height - val) - TRIM_THICKNESS / 2,
width - TRIM_MARGIN * 2, TRIM_THICKNESS, color);

// Marking rectangle
LCD_FillRect(x + TRIM_MARGIN,
y + (height - val) - TRIM_MARK / 2,
width - TRIM_MARGIN * 4, TRIM_MARK, disp->outline_color);
}

Absolutely beautiful and very helpful.

Looks great. If you have the time, check in to getting a bit bucket account (free) and you can make your changes then submit them into PB's repo.

Looks great!

I'm still pondering whether to use the 3.0.0 nightlies (using Walkera stock FW for now for airplanes) or wait until PB releases a new version of Deviation, but I hope he'll include your improvement of the trim bars.

I like it.
But is there a mistake with the size of the white line in the middle of the mark? It has a little gap to the right / lower edge of the mark, but not to the left / top. I would have expectedinstead ofThanks for improving deviation. Pushing it to bitbucket will help PhracturedBlue to integrate it.

It was intended I wanted to do the bars looking a bit like the futaba 18mz. (see bar.jpg)

Anyhow I modified the horizontal bar just to see both designs.

The one that you like most I will try to uploaded to the repo.

Thanks

Ah, I see where your idea comes from. I don't know Futaba's gui but it looks quite good although the trim bars seem to be wider but shorter than they are in deviation.
But actually the slider and the value lines are both on the same edge of the trim bar. Futaba draws them at the opposite edge.
I would recommend to make some pictures of different realizations and ask the forum which is liked best.

I like the modified (second) exsample

Thanks,

rbe I already push it into the repository.

Also I made a new function to create a center dialog box independantly of the screen size and I update the dialogs.c calls. (I have a DEVO 12 and most of the dialog boxes appeared slightly to the left side).

I do not know if you have fully access to the repository.
Could you please check that both commits were properly made? (no password was require to upload anything)

I would like to continue developing some new stuff as I am remembering my C.

Cheers,

Hello Lyndros,

the centered dialog boxes are already implemented. Please take a look in my repository - I have created a pull request to deviation some time ago. There are some other improvements like allowing larger model icons...

PB's repository is write protected and I have not found any new commits. Where / how did you upload the sources?
The usual way would be to create your own bitbucket account (free for private use), clone PB's repository and use this as working directory. You can push in your repo whenever you want. If you want PB to integrate (some of) your changes you will create a pull request he can accept or deny.

Hi Rbe,

I just saw your solution to the centered dialog boxes. Instead of using offsets I am just making the computation of the new positions with a function as easy as this:

guiObject_t *GUI_CreateCenterDialog(guiDialog_t *dialog, u16 width, u16 height, const char *title,
const char *(*string_cb)(guiObject_t *obj, void *data),
void (*CallBack)(u8 state, void *data),
enum DialogType dgType, void *data)
{
// Calculate the positions to show the dialog center in the screen
u16 center_x = LCD_WIDTH / 2 - width / 2;
u16 center_y = LCD_HEIGHT / 2 - height / 2;

return GUI_CreateDialog(dialog, center_x, center_y, width, height, title, string_cb, CallBack, dgType, data);

};

The good point about this is that you forget about "magical" offsets but the problem is to "update" the references of the previous function (but not so much just 8 calls (dialogs.c)). Both are good solutions this is in my opinion is a little easier you always forget about offsets.

Also I have finally finished the bars that I wanted to make at first instance, here you can have a running example of my current source code. (see the attached picture, horizontal trim bar).

On the other hand this type of boxes and depth things require much more colors, so we would have to find a proper place to define all the colors.

Regarding your repo it seems that yours is more advanced than the one from PhracturedBlue, because I could not see some of your improvements in his repo.

Cheers and thanks for your support,

Lyndros

Hi Lyndros,
I created my repo as a copy of PB's official repo and made my changes. I sent him a pull request and he has thought about it, but needs more time to decide and pull my changes. This is why mine looks newer, but it is inofficial (and I do not want to fork deviation and maintain this...).

The way you implement a new function is good and from the point of software engineering it may be the better way, but it makes things more complicated. If you create a new function, you have to change all function calls for the old function to the new one (ok, there are not so much...). Or you integrate the call in the original function and don't win anything but complexity.
But you are right - both ways are ok and work well.
Your solution centers the dialogs on the screen while they are originally not centered in the original code (32 pixels at the top for the headline are left unused for the color screens).

To make things easier we could allow only dialog boxes which are centered (under the headline) and give up the coordinate parameters in the call... The correct centering must be done only in the GUI_CreateDialog().
Maybe in this case we would have to differentiate between the color screens (either 320x240 or 480x272) and the black&white screen (128x64), where the GUI_CreateDialog() is called with different parameters (usually "2, 5, LCD_WIDTH - 4, LCD_HEIGHT - 10") - also centered, but with different gaps at the edges.

FDR wrote:

Lyndros wrote: On the other hand this type of boxes and depth things require much more colors, so we would have to find a proper place to define all the colors.

I think, if you want richer lookfor the bars, in the long run using bitmaps as background is the way to go.
However that would make them fixed size, so then we should have quite a few bars with different sizes...

The colors are defined in the filesystem in media/config.ini. The default for the trims is actually:This would be the place to add more colors (e.g for the marks) or even a background image. Actually the trim bars have a fixed size so using an image does not limit us. But it will need many changes in the code (read the config, new objects/attributes to store the values, new drawing functions).

FDR wrote: For me they are just fine, but I often hear that people say deviation is ugly...

Ugly? What? Do you have names and addresses??

Ok, the gui still looks more constructed than designed. This is ok for me since I am not that big creative artist, more a constructor building things newly together...

It should be not too hard to integrate background pictures for boxes and trims, but the hard thing is the screen update method. Maybe drawing a picture is fast enough when updating one box' value but I don't know how it feels when a bigger amount of boxes are used that way (esp. a lot of telemetry values...).
But it sounds interesting; maybe I'll give it a try.
Lnydros, if you want too: create one (or better four for the different orientations - horizontal / vertical and marks at one / the other side) image and draw that image instead of the box and marks - the slider can be also taken from an image or drawn as it is now.

I know it is a matter of taste, but I like the way it looks now. Clean, efficient and no disturbing useless information. Yes, it is an engineering GUI and not a decorated Christmas tree. (And not even that ugly...)

But i tried although. Who likes it? I did not find flowers so fast...