Standardize application identifier across platforms

[chuma]

Basic Information

• Platform (Mac, iOS, Android, Linux, etc): All
• Built from source? (yes/no): yes
  • If yes, source branch/revision ID: Any

Description of issue

Einstein builds do not use a consistent application identifier across target platforms. The current state of affairs as far as I can tell is:

• Android: com.newtonforever.Einstein
• OS X: com.kallisys.einstein
• iOS: com.stevenf.einstein
• Windows: no clue if there is such a thing
• Linux:
  • Currently, FLTK preferences are stored with vendor = "robowerk.com", appName = "einstein"
  • In my Linux-FLTK branch I have changed this to vendor = "kallisys.net", appName = "einstein"
  • In my Flatpak packages (being tested) I have been using net.kallisys.Einstein as the app-id

Expected behaviour

That the application's identifier be consistent across platforms as much as possible, within the identifier guidelines for each platform.

Recommendation

That we pick one domain name to act as the "vendor", and one word to act as the "product", and use those to create consistent app identifiers.

eg, if vendor = exampledomain.com and product = Einstein then com.exampledomain.Einstein would be the three-part app identifier for Android, OS X / iOS, and Linux.

[panicsteve]

A while back I purchased (but am not hosting anything at) einsteindev.com and am happy to offer it for anything related to the project, including this, if desired!

[chuma]

That's cool, and I think that would be a good use for it.

[MatthiasWM]

@panicsteve @chuma Steven, Victor, any interest in getting a website going? Or is that a waste of time, considering the low number of users we have? As for the ID, I really don't mind, but it should be a domain that we have access to (kallisys is IMHO not a good choice).

[pguyot]

@MatthiasWM I still pay for kallisys.net & kallisys.com and it's not going to end anytime soon. I can provide space and/or a subdomain redirect/hosting if you want to.

[panicsteve]

I still have einsteindev.com I believe, and would be happy to help get a website started. Let me see what I can do!

[MatthiasWM]

@pguyot Ah, Paul, great to hear from you! @panicsteve I am really horrible at doing web pages as you can see on my elektriktrick.com page. So, yes, it would be nice to have a somewhat professional page for Einstein, and I'd be happy to pay for someone "external" to do it (assuming we can maintain it later).

It should help new users to install the app and ROM despite the common attention span of 8 minutes max., and it should help existing users to get new versions of Einstein. Maybe some tips on integrating Einstein into the desktop and daily life, but no more.

It's a nice-to-have though, I guess. What do you guys think? Maybe a subject for next weekend.

[MatthiasWM]

@pguyot I have tried to make Einstein more maintainable by using FLTK on all desktop platforms. But that left a few features behind, like ObjC calls and AppleScript interfacing (TMonitor is coming back). Because there are som many changes, I put everything into the 'matt2020' branch and kept the HEAD untouched, also avoiding a Fork.

How would you like this to continue? It's your project, and I am mixing things up a lot, and I am not sure if you like it. Please let me know if my changes are not in the spirit of your project.

That said, there is some nice new stuff, like Newt that allows NS apps to call Einstein which can then call NS stuff in the running emulation again, read data structures, etc. . That brings me very close to an implementation of Toolbox within Einstein, and, if we want that, integrating DyneTK and Newt/64 into Einstein, providing huge parts of NTK right inside the app. What do you think?

[panicsteve]

Some random thoughts from me:

• It's cool that it can be built for all 3 platforms from one codebase using FLTK. Have to admit, that UI was pretty shocking to see on my Mac after what I'm used to Einstein looking like. :)

• Can your branch still build for iOS (and do we care?) -- we know it'll never be allowed on the App Store, but it still has some value for people who don't mind self-codesigning for their own devices.

• Although I don't think it's "going away" any time soon, all evidence suggests that Apple doesn't much care about future development of Objective-C. Everything new is Swift-focused. So I wouldn't worry too much about Obj-C bridging.

• Likewise for AppleScript. It's slowly dying, and I think it's eventually just going to go away in favor of some variant of "Siri Shortcuts".

• It's incredible that we can write new NewtonOS software in Basilisk and target Einstein as a development platform -- but I hope it doesn't become too much of a distraction of the long term goal of natively executing NewtonOS apps in a host-native way, without ARM simulation or Apple ROMs!

• I am, as always, happy to help with anything on the Apple platforms front. Whether that's sponsoring a Developer Program membership, assisting with codesigning and notarization, verifying that it runs on various devices and configurations.

• Like you, I also feel strongly that Paul should have the final decision on everything at this fork in the road before it goes much further. But, it is great work!

[INDIGI-CO-UK]

I'm happy to help with the website. I'm no programmer, but I'm testing Einstein on my PC, Mac, and iPad. I'm happy to help :)

[MatthiasWM]

1: yes, FLTK is 25 years old. The UI is not beautiful, but neither is Qt. It gets the job done, is rally easy to compile and learn, and it's tiny in comparison to any other UI library.

2: iOS should still compile.I can probably test that, and we might need to add the one or other #ifdef, but I try to not rip apart what we already have. HEAD still compiles just fine.

3: Nah, not worried about ObjC. I think the existing codebase of NewtonScript apps that use ObjC calls is extremely small if not zero.

4: Same for AppleScript. I mean, what's Einsteins user base now, and what's the maximum we could ever reach? It would be best to have a perfect mobile version for pen based Android and Linux tablets. The desktop stuff is for fun, maybe development (user base <5) but not for daily use.

5: Native Newton Script, hah, yeah. So I have played with newt/0 a few times, but never in-depth. When writing Einstein-Prefs I learned a tremendous amount on how NS works within NewtonOS, and I think that writing the framework to make Newton apps open a window and show controls is comparatively small. I have not looked into soups yet, but that can't be much more difficult either. What's missing is the ecosystem around all that. Pen input, HWR, internal apps, comms, etc. . All that can be written, but will it ever feel MessagePad'y? One thing I made sure: newt/64 will load and run 32 bit packages. So writing something for Einstein or even MessagePads will always run on newt/64 as well.

6: Yes, thank you. I have not put any effort into code signing etc. simply because I don't need that in daily life. If you could look into that, you would make launching the app for many non-expert users much easier!

7: Great. Nice that we agree on that. @pguyot , show us the path to enlightenment 😁

[MatthiasWM]

@INDIGI-CO-UK Cool, thanks. It should be an organized effort. I'd like to focus on the Einstein Release for the Newton Online Conference next week though. What do you need to get a page going? Who else can help? NewtonTalk?

[MatthiasWM]

@panicsteve Oh, and in Emulator/Screen/TFLScreenManager.cpp:195 I wrote 20 or so lines of code that are supposed to scale RGB data and transfer it into a window region. The code works, but it is not particularly fast. Can you take a look at that? Thanks!

[panicsteve]

I've set einsteindev.com back up with http(s) access!

I've also created a repository here: https://github.com/panicsteve/einsteindev.com

I can deploy this repository to the root of the live website with a simple 'git pull', so anyone who wants to is able to fork the repo, write some HTML, and submit a pull request. Hopefully this helps anyone who wants to contribute?

Matthias: I can certainly take a look at it!

[MatthiasWM]

Wheee! Cool!

[pguyot]

Thank you for everything you have done so far. I am especially excited by the integration of Einstein with development tools. Like @panicsteve I do prefer native interfaces, especially on the Mac, yet please feel free to go any route you would collectively judge pertinent.

[panicsteve]

@MatthiasWM I emailed you off GitHub, but in case you didn't get it, I'm not sure how to set up FLTK on my system so that it can be found by Einstein's cmake. Could you describe how/where you have it installed on your Mac?

[MatthiasWM]

Clone the newest version form GitHub: https://github.com/fltk/fltk . This is FLTK 1.4. In the first line of CMakeLists.txt, add the line set (CMAKE_OSX_DEPLOYMENT_TARGET 10.9) then mkdir build && cd build && mkdir Makefiles && cd Makefiles && cmake ../.. make sudo make install

That should be all that is needed. It installs itself in /usr/local/lib and include. Fluid, the UI editor, is needed to compile Einstein and should be in /usr/local/bin/fluid and in the PATH, so typing fluid into the shell should open it. Einstein should find all those resources via CMake.

[panicsteve]

Thanks!

With regard to codesigning on Mac, we have some options:

I already have a developer program subscription, and am likely to continue to have one in the future, since I have an app on the App Store. This means I can sign and notarize the app for distribution under Developer ID using my account without us needing to pay for a second subscription. The drawbacks (which are not huge) are:

1. The bundle identifier for the app will need the prefix "com.stevenf" (it would likely be "com.stevenf.Einstein" in full). Similarly, the app's metadata will indicate that it was signed by me. This doesn't bother me, but it might give some people the false impression that it was "my" project or that I developed Einstein by myself (which I would certainly refute, if asked). I don't know if that is a concern for anyone else here, but I just don't want to step on any toes.

2. It means that I would have to be the bottleneck for Mac builds. Matthias wouldn't be able to just do a build and release it, if we wanted a signed build. He'd have to post it somewhere, and I'd have to download it, perform the signing and notarization process, and then post it back. Definitely not as smooth.

Alternatively, we could set up a second developer program subscription, either under Matthias's name or as "einsteindev.com". That would resolve point 1 above, but not point 2. If Matthias wants me to take care of the signing, we would still need to send builds back and forth before release. Again, I don't mind, but I'd hate to slow down the pace of development by introducing friction with this requirement.

So, I guess the decision comes down to whether this is worth it. For now, you can still run an unsigned app on a Mac, but you have to be aware of the trick of choosing "Open" from the contextual menu, and also bypass a security warning that the app has not been reviewed for malware by Apple. As the app is not eligible for the App Store, those are the only two things that we accomplish by signing the app. (However, it is also entirely believable at Apple's current pace that someday it will simply not be possible to run unsigned applications.)

Anyone have any strong feelings?