Support for toolkits or declares for OS specific functionality

aosborne

It would be super cool if Objo could use external toolkits or declares for OS-specific functionality, like https://www.chilkatsoft.com. I guess an SDK is somewhere on the wishlist.

Garry

Yes it's on the roadmap. It's being tracked under this feedback issue: https://feedback.objo.dev/feature/60

aosborne

Garry, if and when you get a chance I'd love to know your thoughts in this space.

bgrommes

Garry Yes it's on the roadmap. It's being tracked under this feedback issue: https://feedback.objo.dev/feature/60

Garry, it's unclear to me from the wording whether this is only a way to improve distribution of open or closed source Objo modules or if it's a planned ABI for calling into C / .NET libraries as has been discussed in the past. Or both. It'd be helpful if you could clarify that (or split it into two issues if appropriate.

Garry

Thanks for your patience on this everyone. It's a fair question, and the answer is a good one: yes, it's planned, the architecture is fully designed, and the first stage of it has already shipped.

The short version: Objo will get a package and extension platform, built in deliberate stages. It covers the three things people keep asking for: sharing Objo libraries as installable packages, calling into C# (and later C/C++) libraries from Objo apps, and eventually installable IDE extensions. The foundation - IDE Scripts, which let you automate Studio itself with Objo code - is already shippingin current Studio releases, and the typed automation layer underneath it is exactly the foundation the rest of the platform builds on.

To answer the question above about whether this is about distribution or an ABI: it's both. The plan is one package system with a shared envelope (identity, versioning, discovery), but two distinct trust models:

Objo source packages - third-party Objo libraries, resolved to exact immutable versions and embedded in your solution so it stays self-contained. Same trust as your own source.
Runtime bridge packages - a versioned ABI through which a package exposes a C# library (first) or a C/C++ library (later) to your application. These have full application-process trust and load into the app host that runs your program, never into Studio itself.

For C# developers specifically, the plan is a proper SDK. You'd annotate your classes with attributes (think [ObjoClass], [ObjoSharedMethod]), a source generator produces the registration glue plus an API metadata file, and Studio can then type-check and autocomplete your library without ever loading the assembly. Published apps carry the exact locked assets, so they keep working standalone on machines without Studio.

On declares: I've deliberately decided against an unrestricted Declare-style statement in the initial platform. A raw declare looks simple, but it pushes calling conventions, library search paths, memory ownership, callbacks, architecture selection, code signing, and crash diagnostics onto every Objo developer. A wrapped package centralises those hard parts and lets Studio reject an incompatible library before you ever run. For something like Chilkat (native libraries shipping for many platforms) the shape is a native runtime package declaring its per-platform binaries, which is exactly what the C ABI stage covers. I wouldn't hold your breath for Chilkat themselves to ship an Objo package, but the point of the bridge is that you or anyone in the community could wrap a library like that without waiting for me to add features to the standard library.

Honest status: scripting is shipped; packages and the runtime bridges are designed but implementation hasn't started, and I won't promise dates. The public tracking item is Support third party packages - votes and comments there on what you'd want first (source sharing versus the C# bridge) genuinely help me sequence the work.

aosborne

This is all a bit foreign to me, but if you did the c# bridge, then would things like chilkat and gembox be back on the table because they support c#?

bgrommes

Garry votes and comments there on what you'd want first

Is there a way to leave comments on support tickets beyond upvoting, or would one just post something here and reference the ticket URL? I don't see a way to "comment there". But then I can look right at something at not see it sometimes. That's why my wife has to find things for me, lol.

bgrommes

aosborne This is all a bit foreign to me, but if you did the c# bridge, then would things like chilkat and gembox be back on the table because they support c#?

Good question. I can see a C# library having to use particular decorations / attributes to expose C# classes as if they were native Objo, but I would want to be able to call any pre-existing C# library ideally. Not sure if this is feasible because if the library returns a type that Objo doesn't have (e.g., Int32 or char) then either those would automatically widen to Integer or you would have to define some sort of shim to define how it's converted to what. Ideally I guess there'd be a default and a way to tweak it, such as converting a char to Integer code point vs String.

Garry

Let me try it in plainer terms, because the honest answer is "yes for one of those two, and eventually yes for the other" - and the difference between them is a nice illustration of how the bridge works.

The key thing about the C# bridge is that the library being wrapped doesn't need to know Objo exists. Someone - me, you, or anyone in the community - writes a small wrapper package that says "here's this C# library, and here are the parts of it I want Objo apps to see." So the question is never "does the vendor support Objo?" It's "what is the library made of?"

By that test:

GemBox comes back on the table with the C# bridge itself. Their components (Spreadsheet, Document, Pdf and so on) are 100% managed C# - plain .NET assemblies - which is exactly what the first bridge stage loads. Nobody at GemBox has to do anything.
Chilkat is the sneakier one. They do offer a C# edition, but it isn't pure C#: it's a C#-looking wrapper around a native core, which is why they ship separate builds for each platform and each of 32-bit/64-bit. A library like that needs the stage after the C# bridge - the one that handles native libraries and their per-platform binaries. That stage is designed and on the list; it just deliberately comes second.

In both cases the wrapper is written against their existing C# API, so you're not waiting on Chilkat or GemBox to ship anything Objo-related. The only other thing that still applies is their own licence terms, since both are commercial products.

Garry

bgrommes No comment feature (yet). I had to build Feedback myself so I could add it in theory. For the time being, just referencing the URL (which is stable / permanent) in the forum is probably easiest.

bgrommes

Garry Chilkat is the sneakier one. They do offer a C# edition, but it isn't pure C#: it's a C#-looking wrapper around a native core, which is why they ship separate builds for each platform and each of 32-bit/64-bit. A library like that needs the stage after the C# bridge - the one that handles native libraries and their per-platform binaries. That stage is designed and on the list; it just deliberately comes second.

So to be clear -- Chilkat could indeed be called because it provides the .NET wrapper; the native core could not be called directly / without the wrapper because that's another layer of support that comes later. Correct?

Garry

@aosborne - close, but it's actually the other way round, and the distinction is worth nailing down.

Chilkat's C# wrapper isn't usable without its native core - the wrapper is a thin skin that immediately calls into the native code, which is why the two always ship together. So during the C#-bridge-only stage, neither half of Chilkat is callable: the wrapper looks managed, but it can't stand on its own. It's when the native stage arrives that Chilkat comes back on the table.

One nice wrinkle when it does: Chilkat also ships plain C/C++ libraries - including a C API that mirrors their C++ classes - so a wrapper author could skip their .NET layer entirely and talk to the native side directly. And the package system will be deliberately strict here: a package that turns up with native files it didn't declare gets rejected up front, rather than half-loading and falling over later on some customer's machine.

@bgrommes - good news on your first point: those two things aren't in tension. The attributes live in a small wrapper project that you write against the library, not in the library itself. So yes, any pre-existing managed C# library is fair game - no vendor source or cooperation needed, though if it's your own code you can annotate it directly. What Objo apps see is your wrapper's surface.

On type conversion, your instinct matches the design. The obvious cases get sensible defaults (C# int to Integer, string to String), and where a type is ambiguous - your char example is exactly right - the wrapper says what it means: you expose the member with the Objo type you intend and do the conversion inside the wrapper. The initial set of supported mappings will be deliberately conservative and grow based on what real packages turn out to need.

Just to clarify though - most of this work is in my spec doc - I have not coded it yet.

bgrommes

Garry So during the C#-bridge-only stage, neither half of Chilkat is callable: the wrapper looks managed, but it can't stand on its own.

So Objo would know this -- how? Because it would want to package the assets and not all of them are a .NET assembly? I would (doubtless, naively) think that the only point of contact is the .NET assembly but I guess if there's DLLs or dylibs or other dependencies that have to exist in a particular place, for publishing purposes that's more involved, is that the issue? Because I'm not sure how the later ABI phase would solve that other than if you called, e.g., Chilkat's C interface directly and that consisted of a single physical asset that would have just been a dependency of the .NET version. But then that could in turn have other dependencies of its own that would not necessarily be discoverable.

Personally I'd be okay with calling Chilkat's .NET library assuming it was a full wrapper and then being responsible for properly situating any other dependencies myself in some installer hook.

Garry

You're asking exactly the right question, and the answer comes down to: packages declare, they don't discover.

A package isn't "a folder with a DLL in it" - it's an archive whose manifest lists every asset it ships, per platform, with hashes. That's how the Chilkat situation outs itself, whichever way a wrapper author tries to play it:

If they include Chilkat's native files alongside the assembly, those are native assets, and a C#-bridge package has no way to declare them - the package is invalid up front.
If they omit them, nothing stops the package from building, but it now only works on machines that happen to have the native library somewhere the OS loader can find it. First run on a clean machine fails, with diagnostics naming the package responsible.
Even the sneaky case (native code smuggled inside the .NET assembly) gives itself away, because such an assembly isn't platform-neutral, so it can't sit in the "any CPU" slot; it has to be declared per-architecture.

Your instinct about the ABI phase is right: it doesn't solve this by discovering dependencies, because that isn't solvable in general. It solves it by refusing to guess. A native package's manifest declares every supported platform, the entry library, and every required native dependency; sidecar libraries that aren't declared simply aren't loaded; and if the exact architecture you're targeting is missing an asset, you get a compatibility error before Run or Publish - not a loader error on your customer's machine. Transitive dependencies are the wrapper author's job to chase down, once, in one place, on behalf of everyone who then installs the package. (Vendors like Chilkat do keep the native side close to self-contained - they even ship separate libstdc++/libc++ variants on Linux - but the design doesn't lean on vendors being tidy.)

And your installer-hook offer is genuinely appreciated, because it's the honest DIY version of a declare. The problem is that it's only ever a machine-state solution: it works on exactly the machines where your installer ran correctly and nothing has changed since. The design deliberately never loads libraries from ambient search paths, published apps are self-contained, and native libraries participate in platform code signing (macOS signs nested dylibs as part of the app, for instance). Once native packages exist, though, the hook isn't forbidden - it's obsolete. Declaring those dylibs in the package once means staging, hashing, signing, and exact-architecture checks all happen automatically at Publish, which is strictly less work than maintaining installer hooks per platform.

All still at the design stage, to be clear - but this is precisely one of the problems the package model was drawn up to prevent.

aosborne

Hey Garry, I just wanted to revisit this. You mentioned making a comment on the feedback system about which of the options you proposed helps best. I've looked at the feedback system (https://feedback.objo.dev/feature/60), and I can't see where to make a comment. So just for clarity, my vote would be for the C# bridge first. Once that's in place, the scope of what's possible with Objo widens enormously — being able to wrap and use libraries like GemBox would be a game-changer for the kinds of apps I want to build.

bgrommes

aosborne my vote would be for the C# bridge first

Same here. It seems like the most bang for the buck, and I know C# well.

You're correct that there's no comment feature on feedback items, apart from upvoting.

Garry

See this post: https://forum.objo.dev/d/1228-c-plugins-are-coming-to-objo-studio

Enjoy 🙂

aosborne

Thank you.