Can't get the context menu of a binary file

[JeffryBooher]

WHen right clicking on files that cannot be opened by brackets,
You get a "file cannot be opened" alert and then you cannot do other things to the file
such as rename, delete or "show in finder"

[lkcampbell]

@JeffryBooher, I'm thinking this issue may be at least a partial duplicate of #4690. It stresses what I believe is the most critical piece of the issue though. What are your thoughts?

[TomMalbran]

En easy fix for this is to add a Custom Viewer for the audio and binary languages and try to change the language of a file that was not on the list but couldn't be opened to binary. The Custom Viewer could just show basic info on the file and maybe some message, and maybe an icon.

If we do that, we won't have any issue with showing the file on a right click.

[JeffryBooher]

a custom viewer seems like a lot of work.

[TomMalbran]

It is not really that complex. Is just an html file with like 10 lines of code and like 50 lines of JavaScript. It will just show basic information, so it won't be as complex as the images viewer. My fonts viewer is more complex than this and the JavaScript file is about 100 lines of codes with lots of comments.

It will also make it a lot better experience than showing a popup when selecting a binary file.

[JeffryBooher]

I said "seems-like" :) and I meant "for me". It does raise a few questions though. I'm guessing it works sort of like images do so they aren't in the working set. This will eventually change as we plan to do split view with things in the working set that aren't necessarily editable. Let me take a look at your fonts viewer I'm thinking we would definitely like to fix #4690 as you suggested but this may be something to ponder.

[TomMalbran]

I don't think that it would be a bad idea to place the binary files with their custom viewers in the working set. It might be better to just treat those files as normal files. This will fix this, but is mostly a fix for #7608.

Issue #4690 should be fixed since is not only an problem for binary files, but also for huge minified files, that will still open but take a long time.

[bchintx]

Assigning to @TomMalbran

[peterflynn]

@TomMalbran One tricky part is that custom viewers are currently keyed off of LanguageManager language id, which in turn is driven by file extensions alone. But we probably want to write this in such a way that it works for all binary files, not just the ones we explicitly put in our list of known-binary file extensions. Ditto for non-UTF-8 files, which have the same problem (e.g. see #8083) and which will have the same extension as an existing plain text language. The "view factory" idea that's coming as part of split views may give us an easier path to solving these issues cleanly, though...

@JeffryBooher It seems like the 'in working set' bit gets solved for free with the split view work, so hopefully that's a non-issue here soon.

[peterflynn]

Note: I've closed #8083, which is describing the same exact problem except for non-UTF-8 files -- which are effectively the same as binary files from Brackets's standpoint. We should try to fix both cases together.

[JeffryBooher]

@peterflynn I think that comes at the end with Images in the working set but I agree and we should probably add that the the test plan.

[Wikunia]

My question is why is it important that brackets can open the file? It would be faster to only open the context menu without opening the file. If I want to rename the file it's unnecessary to wait until the file is shown.

[peterflynn]

@Wikunia That's tracked by #4690. It is a little tricky since it's not something that the "jsTree" widget officially supports -- so we'd have to hack around it or migrate to a different UI widget. The last comment in #4690 has some notes on the former, while this forum thread has some discussion of the latter option.

[peterflynn]

Note: this maybe be obsoleted soon since #4690 is slated for a fix in the near term. It could still be cool to show a custom viewer with basic file stats when the file is explicitly left-click selected (instead of an error modal as today), but it'd probably a lower-priority 'move to backlog' at that point...

[pthiess]

@dangoor reassigning since Kevin is working on the file tree story.

[ingorichter]

This is fixed with the new file tree/ProjectManager implementation. FBNC.

[lkcampbell]

@ingorichter, is the Project Manager implementation in the master yet? Because I still see this problem and I am using the latest dev master right now.

[dangoor]

It's on a branch still

On Monday, September 15, 2014, Lance Campbell notifications@github.com
wrote:

@ingorichter https://github.com/ingorichter, is the Project Manager
implementation in the master yet? Because I still see this problem and I am
using the latest dev master right now.

—
Reply to this email directly or view it on GitHub
#7676 (comment).

[ingorichter]

@lkcampbell the new ProjectManager implementation landed in master beginning of this week. Would you mind having a look if this issue is now resolved for you?

[dangoor]

I'm setting this FBNC because this has landed in master.

[lkcampbell]

@ingorichter yeah, it works great for me, thanks, but this issue was opened by @JeffryBooher so he should probably confirm and close.

[JeffryBooher]

Confirmed Fixed. Closing