@enniom Why are you setting ASR to 0.5, if no device has 0.5 ratio? Which is your development device?

Kl3m3n

@enniom Also try installing this app:
https://play.google.com/store/apps/details?id=com.drhowdydoo.displayinfo&pcampaignid=web_share

You can check the various screen information.

@enniom

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.

EDITED

@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

@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

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

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