Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the app available as a desktop application #5

Closed
fedarko opened this issue Aug 9, 2017 · 12 comments
Closed

Make the app available as a desktop application #5

fedarko opened this issue Aug 9, 2017 · 12 comments
Assignees
Labels
highpriorityfeature vieweroptimization Optimizations for the viewer interface wontfix I may come back to these in the future, but for now I don't have the time

Comments

@fedarko
Copy link
Member

fedarko commented Aug 9, 2017

From @fedarko on July 22, 2016 18:7

Using cy.json(), node.js, and node-sqlite3 would allow assembly graphs to be viewed in Cytoscape.js or (with less support for certain Cytoscape.js-specific features -- see this) the desktop version of Cytoscape.

The upside of this is that we get the best of both worlds: the ability to view the graph in a browser (and, theoretically, host it on a website) and the ability to view the graph in desktop Cytoscape (which would make viewing huge graphs faster).

Note that I have pretty much no experience with desktop Cytoscape, and we'll probably have to tweak things to get this to work. (I think compound nodes, in particular, are only somewhat supported in desktop Cytoscape -- so I'll have to look into that.)

Copied from original issue: fedarko/MetagenomeScope#12

@fedarko
Copy link
Member Author

fedarko commented Aug 9, 2017

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

@fedarko
Copy link
Member Author

fedarko commented Aug 9, 2017

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
Copy link
Member Author

fedarko commented Aug 9, 2017

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 fedarko self-assigned this Aug 9, 2017
@fedarko fedarko added highpriorityfeature vieweroptimization Optimizations for the viewer interface labels Aug 9, 2017
@fedarko
Copy link
Member Author

fedarko commented Aug 9, 2017

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
Copy link
Member Author

fedarko commented Aug 9, 2017

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

fedarko added a commit that referenced this issue Aug 21, 2018
Finagling the regexes took some time, but the solution is relatively
flexible.
fedarko added a commit that referenced this issue Aug 21, 2018
Since Electron sets the window's icon differently. Also since we
don't have bubble.ico in the electron/ directory.
@fedarko
Copy link
Member Author

fedarko commented Aug 22, 2018

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
Copy link
Member Author

fedarko commented Aug 24, 2018

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
Copy link
Member Author

fedarko commented Sep 5, 2018

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
Copy link
Member Author

fedarko commented Sep 5, 2018

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
Copy link
Member Author

fedarko commented Sep 11, 2018

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
Copy link
Member Author

fedarko commented Sep 11, 2018

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 added a commit that referenced this issue Sep 6, 2019
SHEESH why did I write these in fish in the first place.
The bash script porting closes #149!

I ended up removing the very basic in-progress electron/ version,
because it added *a lot* of complexity to the minification process
-- and I'm not confident that it's actually useful to keep around,
until we go ahead with #5 and make it actually harness the node.js
library. If/when I get around to doing that, I think it'll require
the sort of changes that go beyond a few "sed" commands.

Also, I updated the copyright years in the minified attributions
(#150) -- need to actually change these throughout. Also I guess
we should include 2016 in this range? TBH I don't think we'd have
a problem with just "2016--".
@fedarko fedarko added the wontfix I may come back to these in the future, but for now I don't have the time label Dec 3, 2020
@fedarko
Copy link
Member Author

fedarko commented Dec 3, 2020

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

@fedarko fedarko closed this as completed Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
highpriorityfeature vieweroptimization Optimizations for the viewer interface wontfix I may come back to these in the future, but for now I don't have the time
Projects
None yet
Development

No branches or pull requests

1 participant