Make the app available as a desktop application

[fedarko]

Make the app available as a desktop application

[fedarko]

See cytoscape/cytoscape.js#1018 -- this might actually be pretty well-supported, from the looks of it

[fedarko]

OK, here's the (a?) plan:

• We use node.js in conjunction with the .db file parser we write in JavaScript (aka that I'll finish tomorrow).
• However, instead of using sql.js, we use node-sqlite3 (which uses native SQLite, which means we have more usable space to process large .db files).
• We load the results of that into a headless (run using node.js) instance of Cytoscape.js, then we call cy.json() to export to a format that desktop Cytoscape can read.

This should work well! By running everything headlessly we avoid browser overhead, and by using node-sqlite3 we avoid the limitations of sql.js.

Alternatively we could export from the python script directly to desktop Cytoscape (by preparing JSON output [we could even add our own data fields that we could parse via a Cytoscape plugin], or by using the existing dot-app for Cytoscape to load .gv or .dot files).

[fedarko]

I was previously running into an error in which cy.json() generated circular JSON which couldn't be string-ified (i.e., couldn't be exported to desktop Cytoscape). I think I identified the source of this error: just reported it at cytoscape/cytoscape.js#1667, so hopefully that will be resolved.

UPDATE: Nope I'm dumb see commit message below

[fedarko]

Ok, so here's an idea. Things like Electron (https://electron.atom.io) can facilitate the creation of desktop apps from HTML/JS/etc code, right? And there's a tutorial available demonstrating that Cytoscape.js works ok with Electron.

So it should be feasible to use electron to create a desktop version of the viewer interface, but using node.js et al for certain things (e.g. node-sqlite3 in lieu of sql.js). I'm a bit fuzzy on the details here, but I'll do some more research on this soon. This could result in a fairly performant application, if done right.

[fedarko]

Alternatively, we could have collate.py just generate a .json file that could be loaded in desktop cytoscape. Look into that also.

[fedarko]

After commit 5b890ba, it should be feasible to modify certain spots in the JS code to function differently for the viewer interface's Electron application when performing operations where Node.js has native bindings (e.g. using node-sqlite3 instead of sql.js).

[fedarko]

Additional way we could do things differently: accept actual assembly graph files (GFA, GML, etc) in the viewer, and invoke the graph_collator script if those are passed? This would let users avoid the command-line stuff entirely.

[fedarko]

Could also leverage the desktop app status of this to enhance features like FASTA exporting/copying-to-clipboard/etc that are normally difficult or at least very limited in client-side apps. See Electron's clipboard API for more info

[fedarko]

apparently the Electron app supports using XML HTTP Requests to get demo files. Consider hooking it up to mgsc.umiacs.io's demo files? Or not, I guess, since the app isn't really "associated" with a hosted version of mgsc per se.

[fedarko]

For the FASTA stuff: add a button that lets the user upload (or even just specify the location of) a FASTA file. Also, add a FASTA option to the finishing output file type radio buttons that is enabled when the user links to a FASTA file for an assembly graph. If the user selects the FASTA export type for finishing, the JS creates the file (based on the contents of the FASTA file) and lets the user save it to their system as before. (Alternatively, the writing operation could be done automatically, if there isn't a good way to hold on to the file while the user selects a location. I gotta read up on the node.js file APIs.)

[fedarko]

Look into using something like electron-builder to expedite the building process.

For the time being, users can build and then run the electron app by cd'ing into the electron/directory of the repository and running npm install and then npm start. But it'd be ideal to make this process easier, esp. for users who might not want to mess around with command-line stuff.

[fedarko]

Closing because I am probably not going to have time for this for a while, and I don't think this is high-priority