Kl3m3n

re: your previous question:

Using GUIO initialization command:   @guis BGC:#FFFFFF ASR:0.50 WBE:0

                                                    "Remnants" Visible?
Plimpton Tablet P8PRO      800x1280       0.625              N
Sumsung Galaxy S6          1440x2560      0.562              N

LG V60 ThinQ               1080x2460      0.439              Y
Sumsung Galaxy A03S        720x1600       0.45               Y
OnePlus 7TPRO              1440x3120      0.461              Y

Enniom

You can check the various screen information.

Addition to previous response:

Can you tell me, which device you have (the problematic one where the widgets are partially off-screen)? I assume that the dpi value is different than the one used by GUI-O. I think if the exact dpi is used, your widgets would not render off-screen.

Ignore the WBE parameter, since it is actually of no practical use...

I will add the dpi reporting to "developer mode" in the next release.

Regards.

@enniom Hi!

I will take a look at this thoroughly tomorrow - today, I am too tired... It was a long day

Just a quick note - dealing with devices with different sizes is a bit tricky. Note that you cannot rely on raw pixel sizes when calculating the positions, due to different screen density of devices.

For example, you can have two devices with the same raw pixel sizes (e.g., 1920x1080), but their densities can differ. This means that e.g., a square with 100x100 pixels will have different physical size on both devices.
So, the calculations need to be based on physical screen size. You need dpi (dots per inch) value to calculate the actual screen size. Android reports the dpi value in "buckets" (120, 160, 240, 320, etc.), which can be different from actual dpi value of the device. This means that calculated physical screen size is not exact (I could use exact values, but some Android devices have problems reporting this exact values, so this is unreliable). I believe this introduces errors in positioning and scaling.

Furthermore, you generally don't need original screen sizes if you use percentages for positioning and sizing on another device. The aspect ratio ensures that widget ratio is preserved. Using the physical screen size ensures widgets are within the visible area.

Best regards,
Kl3m3n

I will apologize for the start if this post is incorrect in some way. You have been dealing with GUI-O for a long time and are exceedingly more familiar with the inner workings then I am.

I would like to tackle the issue of widget location/positioning in Android Devices having different pixel sizes using my initial gut reaction and instinct.

Let's assume that we know the pixel sizes of 2 devices and are faced with the problem of relocating widgets from one device to the other while simultaneously trying to keep a similar appearance.

More likely than not, I would use the approach depicted in the diagram below. That is, first dividing both screens into quadrants, then moving widgets one quadrant at a time.

This approach (on the surface) appears to be mathematically correct - although I cannot test it within the GUIO environment to prove its accuracy.

However, the existing "@guis" command does not appear to have facilities to set the OLD device pixel count, only the original device ASR can be specified. For this scenario, the mathematics need to be changed somewhat. Specifically, since the original device DPW/DPH values are not known, they need to be estimated using the new, current device pixel count. Then an estimate - for example - can be made for the original device DPW/DPH using the new device DPH and the original device ASR. From these values, the new locations on the new device can be calculated.

Again, I cannot test this approach within the GUIO environment, but appears to be mathematically correct.

[Footnote: the original device pixel count estimating procedure could also be based on the new device DPW instead of DPH. The calculations for the movement within each quadrant would be similar.]

Lastly, a thought for your consideration. It may be useful to provide the programmers writing code for GUIO with the ability to specify either the base/original device ASR, OR, the original device DPWO:xxx and DPHO:yyy. GUIO could then perform the more-simplistic calculations while using the known original layout.

Enniom

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

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.

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

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

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

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

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

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

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

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

link text

Enniom

Enniom

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

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.

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