Posts made by kl3m3n

@AndrejK Hi!

Please see:

https://forum.gui-o.com/topic/60/assign-a-number-to-ni-through-a-variable/2?_=1736064840303

and

https://forum.gui-o.com/topic/225/how-to-display-a-float-number-via-bluetooth/6?_=1736064823080

Does this help?

Best regards,
Kl3m3n

@gammda Fixed in v1.0.91.

Best regards,
Kl3m3n

@gammda Hi.

I will check this ASAP. Can you please send me the label initialization?

Best regards,
Kl3m3n

@enniom Hi!

#1 - I agree with your suggestion. In the next release, the numbers will be displayed outside the actual chart area, live you've suggested.

#2 - This is strange - in your video I see GUI-O is receiving invalid characters (ABV%).
After you quit the application with the command, you then open GUI-O from "recent apps" and what do you do next? Your video does not show this. Do you connect to the device manually or you use auto-connection feature to re-connect automatically?

Can you try quitting only when all Bluetooth transmissions are complete and Bluetooth is disconnected?

Best regards,
Kl3m3n

@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

@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 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 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 Thanks for the minimal example, I will try it.

Best regards,
Kl3m3n

@mathieu Hi!

I have sent the initialization code to your e-mail (I have included your full commands there, but not here on the forum).

Basically, the commands are sent in a non-blocking fashion one-by one:

#include <BLEDevice.h>
#include <BLEServer.h>
#include <BLEUtils.h>
#include <BLE2902.h>

#include <pgmspace.h>

const char* const commands[] PROGMEM = {   
    "|LB UID:lb0 X:20 Y:10\r\n",
    ...
    ...
    ...
};

const size_t numCommands = sizeof(commands) / sizeof(commands[0]);

namespace uuid {
  static const char *SERVICE_UUID = "6E400001-B5A3-F393-E0A9-E50E24DCCA9E";
  static const char *RX_CHARACTERISTIC_UUID = "6E400002-B5A3-F393-E0A9-E50E24DCCA9E";
  static const char *TX_CHARACTERISTIC_UUID = "6E400003-B5A3-F393-E0A9-E50E24DCCA9E";
} // namespace uuid

// forward declare parser for incoming messages
void parseGuioMsg(const String &msg);

// setup done flag
bool setupDone = false;

// init active flag
bool initActive = false;
// send command period in msec
static const unsigned long sendCommandPeriod = 50;

// custom handling of server callbacks
class CustomBLEServerCallbacks: public BLEServerCallbacks {
    void onConnect(BLEServer* pServer) {
      Serial.println("Connected!");
    };
    void onDisconnect(BLEServer* pServer) {
      Serial.println("Disconnected!");

      // fix provided by BM
      // restart advertising after disconnect, otherwise GUI-O cannot re-connect
      if(setupDone) {
        // restart advertising on disconnect
        delay(500);
        pServer->startAdvertising(); 
      }
    }
};

// custom handling of characteristic callbacks
class CustomBLECharacteristicCallbacks: public BLECharacteristicCallbacks {
  void onWrite(BLECharacteristic *pCharacteristic) {
    std::string msg = pCharacteristic->getValue();
    
    // parse message string
    parseGuioMsg(String(msg.c_str()));
  }      
};

// global ptr
BLECharacteristic *pTxCharacteristic;

void setup() {
  // debug output
  Serial.begin(115200);

  // create device
  BLEDevice::init("BasicBLE_NUS");
  // create server and register callback
  BLEServer *pServer = BLEDevice::createServer();
  pServer->setCallbacks(new CustomBLEServerCallbacks());
  // create service
  BLEService *pService = pServer->createService(uuid::SERVICE_UUID);

  // crate Tx characteristic and add descriptor
  pTxCharacteristic = pService->createCharacteristic(uuid::TX_CHARACTERISTIC_UUID, BLECharacteristic::PROPERTY_NOTIFY);
  pTxCharacteristic->addDescriptor(new BLE2902());
  
  // crate Rx characteristic and register callback
  BLECharacteristic *pRxCharacteristic = pService->createCharacteristic(uuid::RX_CHARACTERISTIC_UUID, BLECharacteristic::PROPERTY_WRITE | BLECharacteristic::PROPERTY_WRITE_NR);
  pRxCharacteristic->setCallbacks(new CustomBLECharacteristicCallbacks());

  // start the service and start advertising
  pService->start();
  pServer->getAdvertising()->start();

  // setup done flag
  setupDone = true;
}

void loop() {
    static size_t currentCommandIndex = 0;
    static unsigned long lastCommandTime = 0;

    if (initActive) {
      if (currentCommandIndex < numCommands) {
        if (millis() - lastCommandTime > sendCommandPeriod) {
            lastCommandTime = millis();

            // retrieve and send the command
            char commandBuffer[256];
            strcpy_P(commandBuffer, (char*)pgm_read_ptr(&commands[currentCommandIndex]));
            sendMsg(commandBuffer);

            Serial.print("Sending: ");
            Serial.println(commandBuffer);
            
            currentCommandIndex++;
        }
      }
      else {
        initActive = false;
        // hide loading screen
        sendMsg("@hls\r\n");
      }
    }  
}

/***************************/
/* IMPLEMENT YOUR GUI HERE */
/***************************/
void sendMsg(const String &msg) {
  pTxCharacteristic->setValue(std::string(msg.c_str()));
  pTxCharacteristic->notify();
  delay(50);
}

void parseGuioMsg(const String &msg) {
  if(msg.startsWith("@init")) {
    Serial.println("GUI-O app is requesting INITIALIZATION!");

    // clear screen and set background
    sendMsg("@cls\r\n");
    sendMsg("@guis BGC:#FFFFFF\r\n");
    sendMsg("|SORI UID:sori2 HID:sori ORI:2 SEN:0\r\n");

    // wait for orientation change (alternatively catch GUI-O screen orientation change event...)
    delay(500); 

    // show loading screen
    sendMsg("@sls\r\n");
    
    initActive = true;
  }    
}

Can you please test it and see if it works for you?

You can try extending sendCommandPeriod if you have any issues... Also you can comment out the @sls and @hls commands to see exactly what is going on...

Best regards,
Kl3m3n

@enniom No problem

Thank you for the feedback. I will notify you when I solve the issue regarding the widgets on different screens.

Best regards,
Kl3m3n