Full Quick Look Support.
Description
This pull request brings full Quick Look support. This means that now, any type of file compatible with Quick Look can be viewed within CodeEdit (such as videos).
Related Issues
- closes #1806
Checklist
- [x] I read and understood the contributing guide as well as the code of conduct
- [x] The issues this PR addresses are related to each other
- [x] My changes generate no new warnings
- [x] My code builds and runs on my machine
- [x] My changes are all related to the related issue above
- [x] I documented my code
Screenshots
Menu
Video
https://github.com/CodeEditApp/CodeEdit/assets/83844690/78291c2e-0c7a-472d-a2d3-ff69b2271b12
Update 1
Opened in code editor (left). Opened with Quick Look (right).
Update 2
Open As -> Source Code menu item is now enabled. When having a file opened with Quick Look, clicking this option will opened the file in the default CodeEdit editor.
https://github.com/CodeEditApp/CodeEdit/assets/83844690/b60f09b8-7291-43ca-80a1-5c1aa9b184dc
Great work! A few small things...
- I am not sure if opening QuickLook externally is necessary, it just adds another level to the menu which means more time to get to the end item selection.
- I think the eye icon on the tab is a bit much because it competes with the main icon.
@austincondiff
- I think the eye icon on the tab is a bit much because it competes with the main icon.
What about an option in the Settings window? So we can let the user decide.
I'd rather keep settings as concise as possible. Xcode doesn't include this, I'd like to follow suit if you wouldn't mind.
@activcoding This seems to be an issue with that way the conditional for showing Source Code works. if type.conforms(to: .sourceCode) doesn't appear to work for all text files, such as .md.
Should I go ahead and change it to if type.conforms(to: .text)? Or should the Source Code option always appear?
Running in a Playground the the following code for .sourceCode, we are able to see which extensions belong to that UTType.
- s
- c
- m
- swift
- cp
- cpp
- c++
- cc
- cxx
- mm
- h
- hh
- hp
- hpp
- hxx
- h++
- ipp
- applescript
- scpt
- js
- jscript
- javascript
- mjs
- sh
- pl
- pm
- py
- rb
- rbw
- php
- php3
- php4
- ph3
- ph4
- phtml
- pl
- pm
- py
- rb
- rbw
- php
- php3
- php4
- ph3
- ph4
- phtml
- make
- mak
- gmk
- mk
- applescript
- scpt
- js
- jscript
- javascript
- mjs
- sh
- pl
- pm
- py
- rb
- rbw
- php
- php3
- php4
- ph3
- ph4
- phtml
- pl
- pm
- py
- rb
- rbw
- php
- php3
- php4
- ph3
- ph4
- phtml
- make
- mak
- gmk
- mk
Do we need the Quick Look dropdown? It seems like an unnecessary step. Since it's only 2 options, we can just display those two as "Quick Look in Modal" or "Quick Look in Tab". Thoughts?
@FastestMolasses, Open In Modal ways removed as suggested by @austincondiff. See Removed Quick Look icon, removed Open In Modal option.
My previous comment highlights a current issue, and I’m waiting for a response on that so I can move forward with the edits.
Should I go ahead and change it to if type.conforms(to: .text)? Or should the Source Code option always appear?
My personal opinion is this is a text editor so editing text should be prioritized and should be default. I don't think we should allow only a specified set of file types to edit text. There will always be new and/or custom filetypes that we are not aware of that needs to be editable via text.
That said I think this option should be available where possible. Now I can see that potentially being problematic when dealing with images and videos where it is not possible to edit them in this way and if this is the case, disabling this option might be a good thing.
@CodeEditApp/maintainers thoughts on this?
Sorry about that. Had some conflicts with my fork but they're now fixed.
That said I think this option should be available where possible. Now I can see that potentially being problematic when dealing with images and videos where it is not possible to edit them in this way and if this is the case, disabling this option might be a good thing.
Text editting should be the priority.
Closing this for now as it no longer works with the current CodeFileDocument implementation. :(