Open lee-dohm opened 8 years ago
This sounds like fun, to be honest.
I'll have a crack once things have settled over at File-Icons.
@lee-dohm Should this necessarily be restricted to showing file-lists? For gzipped files (as described in #30), this should logically open the uncompressed file data instead.
Hmmmm ... that's interesting :thinking:
If we can:
I think it would be cool either way :+1:
How about this?
A decompressors
service returns a Promise that resolves either to an array or to a DOM element. An array is expected to contain objects which archive-view
uses to construct the final pane-item:
[
{ name: "root-1", type: "directory"},
{ name: "root-1/file.txt", type: "file"},
{ name: "root-2", type: "directory"},
{ name: "root-2/subdir", type: "directory"},
];
A DOM element is considered a "precomposed" pane-item, added to the current pane. This gives providers an opportunity to decompress and display any data, and solves #30. Having an optional secondary argument will also solve the problem of opening individual files inside the archive:
consumeDecompressors("/path/to/file.zip", "root-1/file.txt");
Maybe an additional "can you handle this file" method on the service object also? So that multiple packages can offer decompressors? Or would a decompressor's promise just resolve to undefined
if it doesn't handle that file type?
I'd prefer the former, as it's much clearer what a package can and can't open.
Makes sense to me :+1:
To make things easier, I'll wait for atom-space-pen-views
to be axed before starting, though.
To make things easier, I'll wait for atom-space-pen-views to be axed before starting, though.
JavaScript and Etch have arrived :)
I ran into this limitation today, and maybe a good baby step to make is to allow users to add file-type aliases that match up with already supported compression schemes. The main example that affects me would be mapping ".docx" to ".zip".
I don't know exactly how this would be implemented on your end but I can't imagine I high degree of difficulty since all the important pieces are already available and the "actual name" of a file should be irrelevant once you get below the pretty user interface that "expects" filename to behave a certain way. Seems loosely related to https://github.com/atom/node-ls-archive/pull/5
For more detail on my use case, I'm programmatically modifying/generating docx files and while debugging various issues I have to constantly rename the extension which gets cumbersome after awhile. I tried various hacks to get this working via the Atom init script to no avail.
Directly related to but more general than #49, since it moves the "config" work to the end user instead of adding more maintenance on your side.
This should follow the Behavior Services pattern to allow community packages to add support for other archive types to archive-view.