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

@kl3m3n .
Hi Kl3m3m,

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

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

Hello Kl3m3n,

I started a new thread - since the discussion items are different.

#1 - One minor improvement on the Time Chart with SHVL:1 would be to move the values to the outside and right of the chart directly right of the line/last value. For example (not all values are shown in the example):

In this way, the values do not obscure the latest points on the chart and one can see the latest trend in the data.

#2 - The application uses these commands to exit the GUIO App:

@clh
@quitapp

The GUIO App appears to then exist "in the background". That is, the last view is available when "swiping up" on the screen of the Android Device.

Then, if the GUIO App is run again, something strange happens. The screenshot and video below illustrate the observations.

Allow a few seconds for the video to load. <<<<< Video with GUIO in Background >>>>>

This problem does not happen if, after swiping up, the GUIO App is fully closed from "running in the background". In that case, GUIO performs perfectly.

Some additional details:
-The connection is made with serial Bluetooth @ 115,200 baudrate,
-each of the 5 pages is first loaded with an image.jpeg, then widgets are placed around and on top of it.
-[Edit] While I can't be certain, it appears to be more likely that this problem occurs if the GUIO App is restarted within less than 1 minute after the "@quitapp" command is executed.
-[Edit1] You may also notice the "remnants" from the neighboring pages. In this case, the WBE:1 command was not used since the pages became distorted to the point of not being useful. (Please refer to my earlier post describing this issue.) The layout will be reconfigured at a later date.
-[Edit2] The uC-based application uses interrupt-driven DMA transfers to the UART connected to the serial Bluetooth to update the GUI-O page displays. It is possible one or more Bluetooth transmissions might occur after issuing the "@quitapp" command.

This problem can be somewhat frustrating - especially during the app development stage when exiting, reprogramming the uC firmware, and re-launching happens quickly and more often - and the problem can only be prevented by swiping closed the GUIO App when it appears to be running in the background.

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