Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

Can't get the context menu of a binary file #7676

Closed
JeffryBooher opened this issue Apr 28, 2014 · 21 comments
Closed

Can't get the context menu of a binary file #7676

JeffryBooher opened this issue Apr 28, 2014 · 21 comments

Comments

@JeffryBooher
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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

a custom viewer seems like a lot of work.

@TomMalbran
Copy link
Contributor

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

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
Copy link
Contributor

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.

@njx njx added this to the Brackets 1.0 milestone May 7, 2014
@bchintx
Copy link
Contributor

bchintx commented May 7, 2014

Assigning to @TomMalbran

@peterflynn
Copy link
Member

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

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

@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
Copy link

Wikunia commented Jun 10, 2014

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

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

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
Copy link
Contributor

pthiess commented Aug 13, 2014

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

@ingorichter
Copy link
Contributor

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

@lkcampbell
Copy link
Contributor

@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
Copy link
Contributor

dangoor commented Sep 16, 2014

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
Copy link
Contributor

@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
Copy link
Contributor

dangoor commented Sep 26, 2014

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

@lkcampbell
Copy link
Contributor

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

@JeffryBooher JeffryBooher assigned JeffryBooher and unassigned dangoor Sep 26, 2014
@JeffryBooher
Copy link
Contributor Author

Confirmed Fixed. Closing

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

10 participants