App and data

[micmac]

Hi there

Could one envision a version of the OpenXTalk app that at its core, right from the beginning of the development process, was divided between app and data. All things taken care of with double-clicking documents to open app and all of that?

Mic

[richmond62]

I may be quite stupid, but I do not entirely understand what you mean for one, simple reason:

The IDE (i.e. OXT) is NOT a unified 'app' in the way that apps were in the days of MacOS 9: it consists of engines and files that work together to give the impression of a unifoed app (and you would find it almost impossible to find any contemporary computer program that consists of a single, monolithic file).

Now, OXT, if one unpacks it, contains quite a large number of files that ARE xTalk stacks. This means that the whole thing is extensible (which is a good thing) which is a good thing. This is a 'bad' thing insofar as, unless a stack is opened via the OPEN dialogue, OXT will find it difficult to work out whether the stack being opened is an external stack, or one of its own internal ones.

However, on MacOS, at least, this does not seem to be an undue problem:
-

Screenshot 2024-12-06 at 17.19.12.png (385.1 KiB) Viewed 1278 times

[OpenXTalkPaul]

I'm not sure what you mean by separating app and data.
On macOS apps always also have data included (at a minimum an info.plist) inside the .app bundle, the operating system obscures the fact that the .app is actually a folder that can have all sorts of files inside of it (which is a good thing from an end-user perspective).

[richmond62]

Actually what is not entirely clear is what the OP means by 'data' as everything on a computer is data, and that ancient distinction that MacOS 1 - 9 made between data and resources is surely defunct.

[micmac]

The oXT document we develop is what later become the app. And that app can only hold static data. So you then have to make the whole thing over to separate the data out in what eventually become a document of the app.

That process I would like was taken care of from the start.

Hope it is clear

Mic

[OpenXTalkPaul]

The oXT document we develop is what later become the app. And that app can only hold static data. So you then have to make the whole thing over to separate the data out in what eventually become a document of the app.

That process I would like was taken care of from the start.

Hope it is clear

Mic

That's not exactly accurate. What happens with Standalone Builder is that the document(s) (stack(s) ) are combined with Engine(s) for specific platforms and architectures, and any external code or extensions if used, to become separate app(s).

[OpenXTalkPaul]

I actually like the reverse idea of separating app and data, encapsulating all in one, including the xTalk interpreter embedded in the 'stack' along with embedding resources such as sounds, images, fonts, making it a self contained thing. Call it an app if you want, but like Richmond said, actually it is all data, even if that data is executable instructions.

I think HyperCard Simulator fits well with that idea because its small 300kb xTalk interpreter 'engine' can easily be embedded into its 'stack' format, which is actually a webpage (HTML). Then you have a 'standalone' that is an .html file that should be executable inside any modern (HTML5) web browser (even if there's no internet connection available!).

[richmond62]

Well, if by 'data' you mean data files that are not embedded in the main app:

I am extremely anti that as get my knickers in a right twist (see Scotsman and Kilts for that one ) when it comes down to relative paths and so on.

Ideally, as far as I am concerned, an 'app' (why do I dislike that word?) should be as monolithic as possible (weel, at least as far as the end-user is concerned).

[FourthWorld]

Ideally, as far as I am concerned, an 'app' (why do I dislike that word?) should be as monolithic as possible (weel, at least as far as the end-user is concerned).

Under the hood, there are many practical reasons to have things the user makes kept separate from the tool they use to make them.

But as a design principle for presenting user interfaces, you're in good company:

Steve Jobs famously felt that having to navigate directory trees to find files was cumbersome and unnecessary.

iOS embodies this perspective most completely, in which users are encouraged to think of using the device in terms of applications, and the application is expected to provide its own context-specific UI to access user document files.

This has influenced even desktop OS design, where we increasingly see apps provide a Start screen on launch with a list of documents to work with; the user doesn't have to remember where they put them.

This is reinforced for developers with the now-ubiquitous Documents folder, in which devs are expected to create a folder for things their users make, and have that folder as the default location for saving.

This ethos has been extended to even saving itself. Auto-save is now at least as common as manual save, and Apple goes even further to provide automatic versioning.

In fact, this file-system-free UX paradigm has been adopted so widely and for so long that the newest generation of computer users have no idea where their files are, and often cannot find them manually in the file manager.

Our generation has unexpected role of needing to explain how computers work to both our parents and our children.

https://futurism.com/the-byte/gen-z-kids-file-systems

[OpenXTalkPaul]

Our generation has unexpected role of needing to explain how computers work to both our parents and our children.

https://futurism.com/the-byte/gen-z-kids-file-systems

All too true... annoying as it can be for us. Difficult to not come off sounding like some uber-nerd-elitist when the person you're trying to explain to doesn't really give a rats @ss where their file actually is saved at!

[micmac]

Even if they do not know where the file with data is, there still has to be one.

Mic