UBports Robot Logo UBports Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Plarde
    3. Topics
    P
    Offline
    • Profile
    • Following 0
    • Followers 0
    • Topics 9
    • Posts 25
    • Groups 0

    Topics

    • P

      SDL in the base system?

      Watching Ignoring Scheduled Pinned Locked Moved OS sdl system
      2
      0 Votes
      2 Posts
      256 Views
      AppLeeA
      Hi @Plarde Thanks for your contribution. And you're right, it's important to discuss such matter. I don't know how involved you already are in the system development. I'll make the assumption that you're more an app developer from the argument you made. So I don't want to go too deep as this is a topic that I don't master. One argument that can be made against it is that it will make the system image grow even larger when it's already too large for some devices. So the current situation is that such library/framework have to be packaged within the click. I guess the clickable template with already included SDL is a very good idea and should help developers wishing to use SDL tremendously as not many people are familiar with clicks and it can be cumbersome to build a simple app... I'll let other people prove me wrong or go deeper in the explanations. Kindly yours.
    • P

      Get app name and hook at runtime

      Watching Ignoring Scheduled Pinned Locked Moved App Development
      2
      0 Votes
      2 Posts
      185 Views
      developerbaymanD
      @Plarde Yes, it is possible — though not entirely straightforward — to infer some runtime information like the app's name and the hook that launched it on Ubuntu Touch, particularly if the app is deployed as a click package. Here’s a breakdown of your goals and possible solutions: Goal: Get the App ID or Name from Manifest In Ubuntu Touch click packages, metadata is defined in a manifest.json file, which contains fields like: { "name": "appname.yourname", "version": "1.0.0", "framework": "ubuntu-sdk-20.04", ... } How to get this at runtime? At runtime, this data isn’t directly exposed via traditional environment variables like APP_NAME. However: Environment Variables Available at Runtime: The AppArmor profile and the Ubuntu Touch application launch mechanism set a number of environment variables, including: APP_ID: Often the full app name like appname.yourname APP_PATH: The full installation path to the app APP_BIN: The binary or hook name You can access these using C/C++/SDL via getenv("APP_ID"), etc. Goal: Get the Hook Name (i.e., the launcher binary name) Click packages specify "hooks" (executables, wrappers, or scripts) in the manifest.json under "hooks": "hooks": { "myhook": { "apparmor": "myhook.apparmor", "desktop": "myhook.desktop" } } How to get the hook at runtime? There’s no standard variable like APP_HOOK, but you can infer it from: argv[0] or /proc/self/exe: #include <unistd.h> #include <limits.h> char path[PATH_MAX]; ssize_t len = readlink("/proc/self/exe", path, sizeof(path)-1); if (len != -1) { path[len] = '\0'; printf("Executable Path: %s\n", path); } Then extract the final component to get the executable name — likely the hook. Summary of Techniques What You Want How to Get It App ID (from manifest) getenv("APP_ID") or getenv("APP_NAME") (test both) App Install Path getenv("APP_PATH") Executable Name / Hook Use argv[0] or resolve /proc/self/exe Manifest Contents Parse /opt/click.ubuntu.com/<appid>/manifest.json manually Bonus: Parsing the Manifest Programmatically If you want full manifest access: #include <stdio.h> #include <stdlib.h> #include <json-c/json.h> void print_manifest_field(const char* field) { const char* appid = getenv("APP_ID"); if (!appid) return; char manifest_path[512]; snprintf(manifest_path, sizeof(manifest_path), "/opt/click.ubuntu.com/%s/current/manifest.json", appid); FILE* file = fopen(manifest_path, "r"); if (!file) return; struct json_object *parsed_json; parsed_json = json_object_from_file(manifest_path); if (parsed_json) { struct json_object *value; if (json_object_object_get_ex(parsed_json, field, &value)) { printf("%s: %s\n", field, json_object_get_string(value)); } json_object_put(parsed_json); } fclose(file); } ️ Caveats These variables are set by the Ubuntu Touch application launcher, so they only exist in the app context. Hook names are not exported as a separate variable unless the launcher sets one explicitly. SDL3 libraries should allow injection or configuration of these values from the hosting application (e.g., via init). Final Advice for SDL3 Porting Since SDL3 is a library and shouldn't hardcode values: Consider requiring the host app to pass APP_ID and HOOK_NAME to SDL3 during initialization. You could fallback to the environment and /proc/self/exe as a best-effort fallback. Let me know if you want a ready-made SDL3-compatible utility wrapper function for this.
    • P

      Expose more Wayland features?

      Watching Ignoring Scheduled Pinned Locked Moved Lomiri (was Unity8)
      3
      0 Votes
      3 Posts
      360 Views
      alan_gA
      As kugiigi says, Ubuntu Touch is using an obsolete version of Mir (1.8) with dated Wayland support. Also, most of the Wayland support in Lomiri comes from Mir (the rest comes from Mir's support for "custom" Wayland extensions). The consequence of that is that there's no much prospect of improving the Wayland support in Ubuntu Touch without first updating it to use the current version of Mir. The good news is that is work currently going on to get Lomiri working with the current version (2.20) of Mir. As of today this works on the machines of the developers involved and is close to landing in both the Debian and Fedora archives. However, it will still take significant time to get the rest of Ubuntu Touch migrated over to this newer stack. That is probably the task that can most benefit from help at present. After all that is completed, it should be possible for Ubuntu Touch to track the current version of Mir, and Wayland support will follow Mir. It is also possible to contribute to Mir's Wayland support, but that won't help Ubuntu Touch at present.
    • P

      Annotate - app to annotate PDF files

      Watching Ignoring Scheduled Pinned Locked Moved App Development
      19
      9 Votes
      19 Posts
      2k Views
      P
      @hlbkv Noted! I won't make any promises about the timeframe, but I'll do that when I get a chance
    • P

      Recommendations to announce a new app

      Watching Ignoring Scheduled Pinned Locked Moved App Development
      4
      0 Votes
      4 Posts
      329 Views
      P
      Thanks! Seems like announcing it here is the best idea. I'll upload my app in a few moments, and I'll start a thread here!
    • P

      Content Hub from webapp

      Watching Ignoring Scheduled Pinned Locked Moved Solved App Development webapp content-hub
      6
      0 Votes
      6 Posts
      363 Views
      AppLeeA
      @Plarde I'm glad it worked. Sure, I understand it's easier to start with a basis you master. I personally forced myself to use pure QML as much as I can to teach me how it works. And we have people that can help as well as good example to borrow some code. Thanks for your contribution, it's always appreciated. People usually agree that we need more native apps for Ubuntu Touch.
    • P

      Scaling for non-QT app

      Watching Ignoring Scheduled Pinned Locked Moved App Development scaling
      1
      0 Votes
      1 Posts
      188 Views
      No one has replied
    • P

      Wayland scaling for non-QT apps

      Watching Ignoring Scheduled Pinned Locked Moved OS scaling sdl wayland
      1
      0 Votes
      1 Posts
      232 Views
      No one has replied
    • P

      SDL support on Focal with Clickable

      Watching Ignoring Scheduled Pinned Locked Moved App Development
      13
      0 Votes
      13 Posts
      905 Views
      arubislanderA
      @developerbayman We are happy for your love. But I fear it might not be mutual for long if you flood the forum with your idea of what would take UT to the next level, if it means making it more like Rhino or Droidian. People can only take so much of, what becomes to them, badgering. Listen, I appreciate your enthusiasm, I truly do. But as a project we have been through this back and forth ad nauseam, if not with you, with others. And really, we have no desire of being another Droidian. If what you say is true, that opening up and becoming more "linuxy" would bring in a flood of new applications (and I would like to add the qualifier) that work as well on a small screen as on larger screens, do we already see this effect with e.g. Droidian? And even if there were an influx of apps on those platforms, such applications could theoretically be repackaged as clicks and made available for UT too. Someone just needs to want it badly enough to make it happen. Futhermore, clicks are not the issue that is 'holding the OS back', old libraries are. Many of the latest linux mobile apps require newer libraries than are available on 20.04. Updating UT to 24.04, a work that is already in progress, is a huge undertaking, and that isn't necessarily because of the peculiarities of UT that seem to trip you up the most. It is very much the Linux and Open Source way to repackage Open Source apps to 'exotic' formats, see snaps, and Nix packages. NixOS's packaging choice is not stopping it from being the current darling of the Linux hipster community. Finally I would like you to consider if it is not possible that the reason this Community is much more pleasant, in your estimation, than others for similar projects, might just be due to the way UT is set up. This OS targets a different type of user than does Droidian for instance, that makes the make up of the community different. If we became another Droidian in the software area, chances are huge, we would also become another Droidian community-wise. Then you would have also lost the one-thing you appreciate most about this project.