Posts made by enniom

@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

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

@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 Thanks for implementing the decimal point configuration on Chart axes in the latest GUIO update. Works PERFECTLY.

Ennio

@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

@kl3m3n Thank-you kl3m3n for taking the time to reply.

#2 === I will review and prepare a reply

#3 === The screen aspect ratio is set by:

@guis BGC:#FFFFFF ASR:0.5

The following screenshots were from a Plimpton Tablet and from a Samsung Galaxy - both initialized with the same set of GUIO commands.

The page displays perfectly on the Tablet, but when viewed on the Galaxy, one can see remnants of widgets from the prior page (on the left), and the next page on the right.

I would appreciate any suggestions.

#4 === I was setting up each of the 5 pages with an image, then scrolling through them as the widgets were being created for each of the 5 pages. However, the page was not being scrolled using the SCI:x command. This is why the symptoms appeared as I described. It is NOT an issue with GUIO.

|IML UID:pfds ACT:0 X:50 Y:50 W:90 H:100 HAW:0.0 LI:0 IPS:'image1.jpg,image2.jpg,image3.jpg,image4.jpg,image5.jpg'

@pfds LI:" ; var

Thanks
Enniom

@kl3m3n Thanks Kl3m3n.

Sorry for the piecemeal approach, but I just noticed something about serial Bluetooth (not BTLE) connections.

If more than 1 device has been paired and previously used, then the "Automatically (re)connect" feature does not reconnect to the previously used one. Rather, when GUI-O is launched, the screen showing the available connection is shown with all the devices "disconnected". The user must choose one of them, then the process of connecting and initializing continues flawlessly.

E

Hi Kl3m3n,

Some feedback from various tests, ideas, etc.

1. The new Bluetooth method and speed for connecting and reconnecting that’s been implemented works very well – thanks. That saves some frustration.

2. I’ve been using the Time Chart widget and found a few things to point out:
   a. Code;
   "|CH UID:ch22 YASC:0 VIS:1 X:65 Y:32 W:65 H:15 DRA:0 BGC:#000000 FGC:#FFFFFF CHT:0 CDTF:'HH:mm' BSZ:7200 FSZ:0.8 RAD:1.5 BTH:0 LT:0.2 XTC:8 XMA:5.0 YMA:3.0 YLO:1.5 YHI:5.0 YTC:9 VLP:1 DRAT:0.2 PZO:1 SHVL:0 CHN:'Values' SCI:1"

This chart will not show the y-axis with decimal points – only whole numbers. I don’t know if the decimal points were to be activated by VLP:1 as included in the definition?

b. If the definition is changed only by SHVL:1, then, if the y-values are greater than YHI, the graph is rescaled even though YASC:0. Maybe this override is needed to show the value at the right hand side of the Chart?

3. I understand from the Manual that the display properties needed to calculate the aspect ratio can be found using developer mode. It may be interesting to add a command that, after @init, the Android device can be polled to get the DPW and DPH values. This way, the uC can calculate the aspect ratio and set it to a value as part of the configuration.

[EDIT] Thinking more about this, it may be best to simply include the DPW/DPH values as part of the @init response. That is, something similar, for example, as the response to the RTC command: eg, @init 300:600. The uC can then choose to use or ignore the values in calculating the aspect ratio.

4. In cases where widgets are defined on each of the 5 pages (0-4), it seems that if a widget is defined for page 0 as VIS:1 SCI:0, then those widgets appear on all pages. I worked around the issue by first defining the widgets as VIS:0, then toggling them on by VIS:1 when page 0 is revisited. This does not happen for pages 1-4.

E

Thanks for taking the time to answer.

I'm pretty much doing as you say. My goal however was to modify the uC behavior using a data file that arrives in the Downloads folder.

Unfortunately, when GUI-O is running, I cannot find a way to move the file. If GUI- O is running, doing anything else loses the Bluetooth connection
E

What EXTF command structure would allow GUI-O to read/write TXT/CSV files to the DOWNLOAD folder?

E