[DRAFT] Try new multi-platform approach

[fortuna]

This is an attempt to do multi-platform in a way that the caller doesn't need to know a library has different implementations based on the platform. It removes the need for a gigantic Platform class and simplifies the code.

I wanted an approach that makes the IDE happy, and this seems to accomplish that (versus renaming or generating files, for example).

I was hoping to have Webpack remove the unused code. However, it doesn't seem to be removing the Electron code when outline.WEB_PLATFORM === 'cordova'.

Any ideas on how else I could do this?

I'm thinking of perhaps having clipboard.ts be a symlink to one of clipboard_{cordova|electron}.ts. The symlink could be created at build time. Perhaps we have some build code that whenever it sees files like ..ts is removes the platform suffix. But that would make the IDE unhappy. Or perhaps we have preprocessing marks in the files to remove/keep sections of it.

[jyyi1]

Or we can do something similar to #ifdef in C, for example, this webpack plugin or gulp-preprocess or gulp-strip-code.

[fortuna]

@bemasc cordova-electron is lacking documentation and doesn't seem to be well supported. I didn't find how to create a plugin for Electron (or the browser, for FWIW). I only found this: https://cordova.apache.org/docs/en/10.x/guide/platforms/electron/index.html#plugins.

[daniellacosse]

@bemasc cordova-electron is lacking documentation and doesn't seem to be well supported. I didn't find how to create a plugin for Electron (or the browser, for FWIW). I only found this: https://cordova.apache.org/docs/en/10.x/guide/platforms/electron/index.html#plugins.

oh man, that's upsetting, especially since cordova-osx and cordova-windows are apparently deprecated in favor of it:

[daniellacosse]

@bemasc cordova-electron is lacking documentation and doesn't seem to be well supported. I didn't find how to create a plugin for Electron (or the browser, for FWIW). I only found this: https://cordova.apache.org/docs/en/10.x/guide/platforms/electron/index.html#plugins.

oh man, that's upsetting, especially since cordova-osx and cordova-windows are apparently deprecated in favor of it:

in other news, i found this - https://github.com/capacitor-community/electron

[fortuna]

Thinking about Electron, one issue is that we still need to write native code, and it adds a layer of indirection. We would have to have Node.js bindings for the native code. Our osx app would get more complicated, I believe. Currently it shares a lot with iOS.

In any case, the code has diverged so much that it's hard to migrate anyway. We need to have a unified IPC interface from the browser perspective first, before we can consider migrating. By having multi-platform libraries that looks the same to caller regardless of the platform, it makes it easier for us to incrementally migrate the implementations.

[daniellacosse]

Thinking about Electron, one issue is that we still need to write native code, and it adds a layer of indirection. We would have to have Node.js bindings for the native code. Our osx app would get more complicated, I believe. Currently it shares a lot with iOS.

In any case, the code has diverged so much that it's hard to migrate anyway. We need to have a unified IPC interface from the browser perspective first, before we can consider migrating. By having multi-platform libraries that looks the same to caller regardless of the platform, it makes it easier for us to incrementally migrate the implementations.

Totally agree. Love this direction. We'll need to figure things out either way, given the situation.

[daniellacosse]

Thinking about Electron, one issue is that we still need to write native code, and it adds a layer of indirection. We would have to have Node.js bindings for the native code. Our osx app would get more complicated, I believe. Currently it shares a lot with iOS. In any case, the code has diverged so much that it's hard to migrate anyway. We need to have a unified IPC interface from the browser perspective first, before we can consider migrating. By having multi-platform libraries that looks the same to caller regardless of the platform, it makes it easier for us to incrementally migrate the implementations.

Totally agree. Love this direction. We'll need to figure things out either way, given the situation.

Honestly, to avoid getting into this situation again, I wouldn't be opposed to rolling native "wrapper apps" for each platform that just execute the IPC calls the browser makes.