Might want to name solution.json something else

einhugur

You may want to name solution.json something else so we have something to click on that launches Objo.

For example then Visual Studio .sln files are actually XML but they dont have the file ending .xml since then you could not double click it in Windows to launch Visual Studio.

So basically you could have it still json but with some file ending that launches Objo Studio.

Garry

Good point, thanks.

I agree that users should have something obvious they can double-click/open-with to launch Objo Studio. The slight wrinkle is that solution.json is not really intended to be the user-facing solution file. It is the internal manifest inside the optional .objosln folder package, which exists mainly for Git/VCS-friendly projects. Keeping that file as JSON is useful for editors, diffs, GitHub, and external tooling.

For normal use, the openable file is MyApp.objo. For VCS-friendly projects, the openable thing should be the MyApp.objosln package/folder, with solution.json remaining an implementation detail inside it.

So I think the right fix is probably not renaming solution.json, but making sure Objo Studio registers the right file/package associations:

.objo opens in Objo Studio.
.objosln packages/folders open in Objo Studio where the platform supports that.
solution.json can still be accepted by the Open dialog/CLI as a convenience.

That gives the double-click behaviour without losing the benefits of the manifest being plain JSON.

einhugur

I don't think there is a concept of a package thing on Windows ?

Garry

Yes, you’re right. I'm living in a macOS bubble here aren't I? 😄

For cross-platform behaviour, .objosln should be a real file associated with Objo Studio, so users can double-click it on macOS, Windows, and Linux. The file can still contain JSON internally, just like many project formats use XML/JSON/text without exposing that in the extension.

So the better model probably is:

.objo = single-file packaged project.
.objosln = VCS-friendly solution file, associated with Objo Studio.
The solution’s source files/assets live beside it in normal folders.
Studio and the CLI should open either the .objosln file directly or the containing folder (macOS) as a convenience.

That probably means solution.json should either go away or become an internal implementation detail only if we have a strong reason to keep it. For user-facing VCS solutions, .objosln is the right launch target.

I'm going to look into this now.

Garry

I’ve changed the VCS-friendly solution format so .objosln is now a real file, not just a folder extension. For new VCS solutions, Studio will create:

MyApp/
- MyApp.objosln
- Projects/
- Shared/
- .objo/

The MyApp.objosln file is the solution manifest and can be associated with Objo Studio on macOS, Windows, and Linux, so it can be double-clicked/opened-with on all platforms.

Existing VCS solutions that use the old layout still open. When saved, Studio migrates them in place by writing a .objosln manifest inside the existing folder and removing the old solution.json.

Thanks for catching this before the format became too established.

https://feedback.objo.dev/feature/411