Some issues and possible improvements

[enniom]

@kl3m3n Hi kl3m3n,

Going back to item #2 in the initial post....

Now using the Beta version v1.0.88 downloaded on November 24, I have not been fully able to replicate the issue discussed in the first post. However, in part, some aspects of the issue remain. Specifically, this code snippet shows it:

"|CH UID:ch20 YASC:0 VIS:1 X:50 Y:78 W:94 H:19 DRA:0 BGC:#000000 FGC:#FFFFFF CHT:0 CDTF:'HH:mm' BSZ:10800 FSZ:0.8 RAD:1.5 BTH:0 LT:0.2 XTC:12 XMA:5 YMA:3.0 YLO:0 YHI:7000 YTC:7 VLP:0 DRAT:0.2 PZO:1 SHVL:1 CHN:'All Values' SCI:0"

while True:   #pseudo code
    Y = time.seconds * 100
    "@ch20 PLI:'pl1' PLC:'#FE642E' YP:'" + Str(y) + "'" 

    time.sleep(250)    # 250  milliseconds

    Y = Y + 1000
    "@ch20 PLI:'pl2' PLC:'#FACC2E' YP:'" + Str(y) + "'"

    time.sleep(250)    # 250  milliseconds
                   
    Y = Y + 1000
    "@ch20 PLI:'pl3' PLC:'#C8FE2E' YP:'" + Str(y) + "'"

Observations:
As the Chart is first populated with values, there appears to be a "flash" of the SHVL:1 values. Then, as the Chart progresses, ultimately it seems the SHVL:1 values are limited to 2 characters.

Enniom

[kl3m3n]

@enniom Thanks for the minimal example, I will try it.

Best regards,
Kl3m3n

[kl3m3n]

@enniom Hi.

I tried your example, but I am unable to see the issue? Can you please explain what does "flash" of the SHVL:1 values mean? You are talking about the values on the Y axis and the last value?

Best regards,
Kl3m3n

[enniom]

@kl3m3n Yes.

What I see is the SHVL:1 values written on the last value at the start of the chart and the x axis increment is large. With each new value, it seems they move forward until the x axis increment becomes small and the values are only shown at the far right. More importantly though, is that when the value is over 99 only the first 2 characters are displayed - not all 4.

[enniom]

I tried to take some photos that show the two issues. The flashing one is difficult to catch in a photo but can be seen while watching.

[kl3m3n]

@enniom Hi.

Ok, I see now. The labels are not entirely visible.

Can you try setting the YASC:1 and see if the issue persists?

BR,
Kl3m3n

[enniom]

@kl3m3n Yes, all digits are fully visible with YASC:1 and SHVL:1. This has been one of the issues all along since when the chart is first stated, the values are zero(0) thus creating a large scale for the Y-axis. The chart is not useful with that format.

Enniom

[enniom]

@kl3m3n If you can follow this link, the video will show the "flashing" issue. The video is about 40MB and takes 30 seconds or so to load.

link text

Enniom

[kl3m3n]

@enniom Thanks, I can see this "flashing".

Since you are using the time chart, you should send all the data points simultaneously in one message, so that the drawing of data points is synchronized.

A simple example:
@ch1 PLI:"id0,id1" PLC:"#ff0000,#0000ff" XP:"0.0,0.0" YP:"10.3,20.4"

Can you try this and see if the issue persists?

Meanwhile, I will fix the labels showing only partially...

Best regards,
Kl3mn3

[enniom]

@kl3m3n Thanks for the hint.

Yes, this suggestion can be adopted in this case and does eliminate the "flashing". However, waiting to plot Y values in one command compromises the purpose of "real-time" plotting and charting.

Enniom

[kl3m3n]

@enniom Hi.

Generally, time chart updates should occur at predefined (fixed) interval to avoid synchronization issues. New values should be added in one operation to maintain temporal alignment. I will add this note to the manual!

If you need asynchronous plotting, switch to XY chart type. I think that should work without "flashing".

Best regards,
Kl3m3n

[enniom]

@kl3m3n THANK-YOU Kl3m3n. I will try using a XY chart.

One favor though, I do not know how to send "time" values to a XY chart and have the X-axis tick marks show up in the form "12:34:56". Any help would be appreciated.

Enniom

[kl3m3n]

@enniom Hi.

XY chart does not support time on X axis... You can use index-based approach.

But, I would suggest that you synchronize the data using time chart. I argue that it does not matter if you send the same value multiple times.

For example, if you have three variables / values... On initialization, set all three values based on your measurements. Then send each new measured value along with two "old" values (they are actually not old, they just haven't been re-measured yet) in the same message.

This is how you synchronize the data and keep the time chart while still maintaining valid values.

Does this make sense?

Best regards,
Kl3m3n

[enniom]

@kl3m3n Got it. The XY chart will not work in this case.

I do understand your recommendation to use the Time Chart and aggregate new values with older ones. That is, send all when a newest one is added. This will provide a "real-time stamp" on the new value and simply carry the values of the old ones which have not changed.

I will do some experiments with this approach.

Enniom

[kl3m3n]

@enniom Exactly

[kl3m3n]

@enniom said in Some issues and possible improvements:

@kl3m3n thanks for looking into this issue.

Yes, each page has "remnants" - more specifically it is generally those defined - for example - at position X:90 W:20 or X:10 W:20. In the case of this application, the goal was to squeeze 4-6 charts per page and put them at the left or right page boundary so that the image and real-time data can be shown in the center.

Secondly, the widgets at these positions may not be fully shown in the page they are defined. To be more clear, in this case they are fully shown in the Tablet view but may be cut off slightly at the left or right in the Galaxy view.

Enniom

Hi,

GUI-O version 1.0.89 is being released. Additionally to the chart labels fix, this version introduces a new parameter: widgets bounding (WBE, which can be enabled / disabled via @guis WBE: command - it is disabled by default. Please see the updated manual).

Enabling this ensures the widget is never off-screen as GUI-O application internally moves the widgets in-view. This can be useful when developing for various screen sizes. Note that the widgets' sizes remain the same, only the position is updated. So, if your widgets are too close together, they might overlap.

You can try this approach on your tablet and phone.

Best regards,
Kl3m3n

[enniom]

@kl3m3n Hi Kl3m3n. Thank-you for implementing the WBE function. It certainly eliminates the widget "remnants" from neighboring pages.

However, there may be some unintended consequences. Tests were performed on these devices:

#Plimpton Tablet P8PRO      800x1280       0.625
#Sumsung Galaxy S6          1440x2560      0.562
#Sumsung Galaxy A03S        720x1600       0.45
#LG V60 ThinQ               1080x2460      0.439
#OnePlus 7TPRO              1440x3120      0.461

using pages which were aligned to an ASR = 0.50 then using the GUIO initialization command:

@guis BGC:#FFFFFF ASR:0.50 WBE:1

The results appear to be that for devices having an ASR > 0.50, the widgets were moved such that all their right edges were aligned:

For devices having an ASR < 0.50, the widgets were moved up from the bottom - mostly overlapping other widgets at those locations:

It seems the point was to use WBE:1 to accommodate unknown device ASRs and make universally similar screens. However, it is difficult to use the WBE command to solve this problem.

Enniom

[kl3m3n]

@enniom Hi!

Yes, I see. I will need to implement some additional global scaling of the widgets when repositioning them.

I cannot implement a widget collision detector, since "collisions" are legal in GUI-O. Currently, I see scaling as the only option...

I will let you know.

Regards,
Kl3m3n

[enniom]

@kl3m3n Thank-you Kl3m3n for your continued support.

Some additional thoughts.....

With regard to scaling, the command WBE:1 could be used to adjust all widget sizes and locations by mathematically rescaling them using the base ASR (0.50 in this case) and the DPH/DPW of the target device. This was the original approach I was considering and the reason for asking GUI-O to send those values to the uC (refer to my first post in this thread).

The problem with my approach however, is that the calculations would be done by the uC and consume much of the available RAM and Flash memory. This approach would be limited to only a select group of uCs. If the rescaling can be done within GUI-O, this problem will be eliminated.

On a less serious nature, I can see for example, a widget defined and shown in the shape of a square, may not be so once mathematically reshaped for the new ASR.

A second possible approach might be to use SVG - Scalable Vector Graphics as used for websites/webpages. At this time however, I do not know whether this approach is possible within GUI-O, but I would guess something like it is already being used to render *. jpg, *.bmp and *.png files.

Hope this helps. Enniom.

[kl3m3n]

@enniom Hi.

GUI-O already scales based on the "reference / base" aspect ratio. That is why it is advisable to specify the aspect ratio of the development device if one develops for different screen sizes.

Basically, the device independent pixels are used in the calculations, but the ratio of the widgets must be maintained. If GUI-O would not account for this, you would get all widgets on different devices with "corrupted" aspect ratio.

In some cases, the scaled canvas extends beyond current device size, which makes the widgets go off-screen. Possibly due to device reporting inaccurate screen size, I don't know. I will double check my equations.

The scaling equations are (pseudo code):

REF_RATIO = REF_DPW / REF_DPH  (ASR)

// INITIALLY SCALE BASED ON HEIGHT
DPH_E = DPH
DPW_E = DPH * REF_RATIO

// FALLBACK TO SCALE BASED ON WIDTH
if (DPW_E > DPW) {
 DPW_E = DPW
 DPH_E = DPW_E / REF_RATIO
}

// OFFSET
DPW_O = (DPW - DPW_E) / 2
DPH_O = (DPH - DPH_E) / 2

//  WIDGET POSITION
X = ((DPW_E * X_%) / 100) + DPW_O
Y = ((DPH_E * Y_%) / 100) + DPH_O

//  WIDGET SIZE
W = (DPW_E * W_%) / 100
H = (DPH_E * H_%) / 100

Note that almost all widgets are custom made by painting directly on the canvas. This makes the widgets more flexible and modular. If replacing with SVG, this would be very difficult.

Best regards
Kl3m3n