68k NilApp: Classic Mac Application Engine

[nilobject]

I'm developing an application framework for my own personal use.
One iteration of the framework I have developed using REALbasic 5.5(and it should be easily ported to REALbasic 3.5 for system 7 support).
I'm curious if my work might be useful for anyone in the community.
The general concept is providing access to code via data. Ie. Creating menus, windows, sockets, etc via a JSON file, database, console, etc.
I'm currently working on the application engine that utilises the framework. One example I can show is creating menus:

This shows appending menu items to the Apple menu. The JSON for this would be similar to this:

{ "nil_app": { "menu_bar": { "menus": { "apple": { "items": { "about": { "text": "About…", "action": "NilAppAbout", "visible": true, "enabled": true }, "preferences": { "text": "Preferences…", "action": "NilAppPreferences", "shortcut": ",", "visible": true, "enabled": true } } } } } } }

The goal of the application is to have a user interface for creating and editing the data.
Any comments are appreciated. Thanks

 

[nilobject]

I was thinking of trying to mimic the MacOS X menu bar. Maybe the "about" and "Preferences" items should be in the application menu. I don't really like that MacOS X still has a "File" and "Edit" menu. Shouldn't it be in the application menu?

 

[robin-fo]

Interesting (and very modern) approach to create an Application. Is this all happening during runtime or do you translate the structure into Resources? Can you already estimate the performance impact compared to a „traditional“ design?

 

[nilobject]

Interesting (and very modern) approach to create an Application. Is this all happening during runtime or do you translate the structure into Resources? Can you already estimate the performance impact compared to a „traditional“ design?

Cheers.
Interpretation of the data is at runtime.
I can't see any performance impacts. It's very similar to how resource forks work. ie. store data on disk, cache in ram when needed. So the common performance issues of disk speed and RAM size apply. REALbasic apps also inherently tend to have a large disk and RAM footprint. It's just useful for rapid prototyping. I develop the ANSI C version in parallel.

 

[nilobject]

I back-ported a JSON parsing and serialising module for Real Studio, for use with REALbasic.

https://macintoshgarden.org/apps/realbasicstudio-json-plugin

 

[nilobject]

Merry Christmas, everybody

 

[nilobject]

I'm currently designing how data could be stored on disk. The idea is that users will be able to view the data structure using the Finder and create/modify values using their preferred editors. I have a few concepts, i'll try to illustrate. Any contributions are welcomed.

1. JSON
This idea is to break up JSON blocks(ie whatever is in curly brackets{}) into separate files. Then represent JSON blocks that don't contain any values(ie int, str, bool, etc) as folders.
Disadvantages: data has to be stored as ascii text. ie binary data should be hashed

2. Binary
This idea still uses directories like JSON blocks, but stores the values as binary. This is my preferred option due to it being easy for me to read/write binary with code, however, end users might not appreciate it(ie. if you just want to modify a 5 to a 6 would require an editor like HexEdit.

 

[Patrick]

isn't the entire point of JSON is to be human readable?
Also i feel like it would limit the editors users could use. or apps one might use. (which might only support text)

Maybe what you are really trying to create is BSON ?

would it be hard to create both ?

 

[nilobject]

isn't the entire point of JSON is to be human readable?

It's an Object Notation, so not specifically human readable, but serialised data.

Also i feel like it would limit the editors users could use. or apps one might use. (which might only support text)

JSON would limit the editors or binary?

Maybe what you are really trying to create is BSON ?

Not really. I don't care if the int is a int32, int64, uint32, uint64, etc.

would it be hard to create both ?

Not particularly. I'm designing it using generic interfaces, so a data store can be anything. Directories on disk, resource forks, data bases, REST API, etc, etc.

Thanks for you reply. I don't have anyone to bounce ideas off of, so this is very helpful and appreciated.

 

[fogWraith]

In a whole, I really like the idea and can already see some uses for it personally.
Especially in creating small useful knick-knacks when working on the OS 9 machine

 

[nilobject]

Thanks, fogWraith.
I've posted a request over at the garden.

https://macintoshgarden.org/forum/nilapp-architecture-and-design

 

[fogWraith]

Thanks, fogWraith.
I've posted a request over at the garden.

https://macintoshgarden.org/forum/nilapp-architecture-and-design

In the far, far, very distant past ... there was a project that was fairly dynamic (client/server), it allowed creating routes to pages that could be populated with images, text, files etc ... the client (native mac) would parse the data and build the ui from that.

I'll see if I have it stored somewhere, and perhaps there may be some ideas that could be pulled from that if that sounds interesting.

 

[nilobject]

I'll see if I have it stored somewhere, and perhaps there may be some ideas that could be pulled from that if that sounds interesting.

Any software like that sounds interesting, thanks. I take huge inspiration from HyperCard.

 

[nilobject]

The application is now threaded. This allows dynamically updating the user interface. eg. A menu title or window name can display the time.
Menu actions now work. Selecting "Quit" now quits the app, selecting "About..." now opens the about window.
Windows can now be created, though I can't change the "frame" after instantiation.

Notice the key names are starting to get confusing. ie there is an action called about and a window called about. Perhaps action keys should be more verbose. Maybe "show_about_window" for the action.

 

[Patrick]

It's an Object Notation, so not specifically human readable, but serialised data.

JSON

www.json.org

>JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.

its the first sentence. there. and its that way in wikipedia.
..
But i'm not an expert in it. I was just pointing out that the idea that json is human readable isn't something i made up. I got it from what i consider authorities.


I don't mind either way. but as somebody who has to work with json everyday in my day job. its always been human readable. nice being able to modify using vim. for example.

but maybe thats a different situation then what you are going with here.

re:editors. i think i was just trying to point out that these two things are in contention with each other

The idea is that users will be able to view the data structure using the Finder and create/modify values using their preferred editors

and

if you just want to modify a 5 to a 6 would require an editor like HexEdit.

If we have to use HexEdit or another binary editor we can't use our preferred editors.

...

i'm replying because i find your project interesting.... but i understand that i'm not the main audience. and so i may not have enough context around this to fully grok what you are trying to do.

 

[nilobject]

Thanks, Patrick, for your interest and patience. I probably sound contradictive, but that is definitely not my intention. Apologies due, where needed.

JSON

www.json.org

>JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.
its the first sentence. there. and its that way in wikipedia.
..
But i'm not an expert in it. I was just pointing out that the idea that json is human readable isn't something i made up. I got it from what i consider authorities.
I don't mind either way. but as somebody who has to work with json everyday in my day job. its always been human readable. nice being able to modify using vim. for example.
but maybe thats a different situation then what you are going with here.

Yep, that's what I'm thinking, too. Depends on your definition of "human readable".

re:editors. i think i was just trying to point out that these two things are in contention with each other
and
If we have to use HexEdit or another binary editor we can't use our preferred editors.

HexEdit was just an example of a program which can read and modify the data fork of a file. Many are available. I believe plain text is just a stream of ascii written as bytes, so TextEdit could be considered as a specialised editor for binary data.
In my examples I only showed storing of "values". I didn't show storing of files. Files will be stored as their original. They can be edited using a preferred editor.
Something like this:

i'm replying because i find your project interesting.... but i understand that i'm not the main audience. and so i may not have enough context around this to fully grok what you are trying to do.

All good. I'm very happy to read and reply to all responses.
Thanks again.

 

[Patrick]

I believe plain text is just a stream of ascii written as bytes, so TextEdit could be considered as a specialised editor for binary data.

sure. but i woudn't want to use TextEdit to edit binary data. for one, not everything is printable. i'm sure i've corrupted some files that way.

interesting. .. separate not connected questions.

are you trying to implement something like Mac OS X app bundles?

are you trying to replace the resource fork?


If you are going to do binary data in json ... why is that easier and/or better than using resedit (on resource forks)?
...

have you heard of Andy Hertzfeld's Servant ? i've read about it but never tried it. among other things. it combined the Finder and resource editor into one.
and it seemed similar to what you are trying here.

 

[nilobject]

are you trying to implement something like Mac OS X app bundles?

I "borrow" ideas from many systems. Apple often comes up with interesting solutions, but they are Apple solutions, meaning they don't translate to other systems easily. eg. it's almost impossible to do something like an app bundle(opening an app by opening a "folder") on windows.

are you trying to replace the resource fork?

No, but as with the previous question, resource forks are a very interesting idea that I borrow from.
In my mind, a resource fork, a data fork, a database, a folder structure, a JSON file, a REST API, etc, etc, is just the same thing. I want to provide easy access to that data. A nice GUI.

If you are going to do binary data in json ... why is that easier and/or better than using resedit (on resource forks)?

It's not. I just need somewhere to store binary blobs. If a user gets a blob and gives it to my app, how should it store it on disk? It can't be resource forks because it won't work on other systems. The mac versions of the app will be able to read and write resource forks, but the core of the app needs to store it in a non-proprietary format.

have you heard of Andy Hertzfeld's Servant ? i've read about it but never tried it. among other things. it combined the Finder and resource editor into one.
and it seemed similar to what you are trying here.

Yeah, Hertzfeld is literally "one of us". What a boss.
I've tried to categorise or genrelise what I'm making. I can't do it. The idea is so generic.

The conversation in my head goes:
"I want access to the data on my computer".
"Use your Operating System"
"My Operating System does not know how to read the data the way i want it to"
"Use an App"
"The app keeps updating and changing and so does my OS and now I need to maintain a 20 year old machine just to run one function"
"lol just use facebook and tik tok and pay for a subscription to listen to music"
"What? Why can't I just do what I want?"
"MONEY!!!"
"oh"

 

[Patrick]

OH i think I got it now. maybe...

i think i got stuck on teh resource fork thing. because you were showing manipulating the menu's via it.
But you are trying to be a lot more generic then that.


I love everything about this project. its quintessential tinkering.