[CLOSED] Whats the API for changing the editor view?

[core-ai-bot]

Issue by chrismatheson Wednesday Nov 13, 2013 at 20:53 GMT Originally opened as https://github.com/adobe/brackets/issues/5985

---

Hi,

I'm trying to write an extension that will change the editor into a custom view & then return after. somewhat similar to a modal expect not a modal.

I've found a few API's in the code but I've been waved off them as they are not 100% public yet.

Could someone look into this and let me know the blessed path for doing this kind of thing?

[core-ai-bot]

Comment by chrismatheson Wednesday Nov 13, 2013 at 20:54 GMT

---

large dump of convo with@peterflynn

[20:36:32] hey@pflynn playing about writing a new extension [20:36:52] whats the defacto standard test setup for extensions ? [20:36:54] Vader (~Electron@66.187.87.61) left IRC. (Remote host closed the connection) [20:37:03] all the ones I've looked at don't seem to include tests ? [20:37:21] Vader (~Electron@66.187.87.61) joined the channel. [20:37:38]@pflynn here are some docs: https://github.com/adobe/brackets/wiki/Extension-Unit-Tests [20:37:45] Matt (48180a75@gateway/web/freenode/ip.72.24.10.117) joined the channel. [20:38:08] Matt is now known as Guest36206 [20:38:45] Guest36206 (48180a75@gateway/web/freenode/ip.72.24.10.117) left IRC. (Client Quit) [20:39:14] awesome :) [20:39:36] and a mother one, hopefully quick, where would i look to get the current open file path ? [20:40:06] I'm using EditorManager.showCustomViewer and i need to cache the existing location so i can come pack to it :) [20:40:29] cos EditorManager.closeCustomViewer docent take me back to where i left :) [20:41:29]@pflynn oh -- might want to hold off on using that API just yet, as we haven't made it official [20:41:44]@pflynn it actually can't show anything other than the current 'image preview' viewer right now -- it's hardcoded [20:42:25] oh :P [20:42:28]@pflynn and I think closeCustomViewer() isn't normally an API you'd call directly [20:42:32] I've made my own viewer [20:42:38]@pflynn you want the FILECLOSE command [20:42:43]@pflynn hmm.. how are you getting it to show? [20:42:58] https://github.com/chrismatheson/brackets-package-viewer [20:43:10] prity simple just now, but hoping to beef it out :) [20:43:13] Gmac (~Gmac@pool-108-41-147-129.nycmny.fios.verizon.net) left IRC. (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [20:43:13] trishasalas (~trishasal@ip98-178-171-75.tu.ok.cox.net) joined the channel. [20:43:49] packageViewer.js exports the two functions required to build & render the view (altho i do rendering in build i think :P ) [20:44:09] I've linked it up to a sidebar button [20:44:27] which calls the open / close calls [20:44:33]@pflynn out of curiosity, what's it going to view? [20:44:53] I'm hopping to build a kind of 'fancy' read me & package.json viewer [20:45:30]@pflynn interesting... fyi there's a popular 'markdown preview' extension that might already cover what you want for readme type stuff [20:45:32] so when your in a dir it will traverse up looking for readme's and package.json/bower.json files and show a nice easy to read 'sumury [20:45:45]@pflynn the other caveat you should be aware of if that viewers are ONLY viewers -- they can't edit anything [20:45:59]@pflynn oh ok, that's an interesting [20:46:00] yeah i use md preview, i like it , but i want to re-use GH flavour MD which i think people are all familiar with [20:46:03]@pflynn interesting idea [20:46:16] plus if i run it thru the GH rendering API then i get links to GH for free ;) [20:46:36] issue / profile links etc [20:46:51]@pflynn might be worth filing a bug on the existing markdown extension for that too [20:46:56]@pflynn I know a lot of people use it [20:46:58] ill probably just start of with an ajax call but later ill try to include the GH node stuff and do it locally [20:47:24]@pflynn but for custom viewers... I tink you'll run into a bunch of problems since the APIs you're calling aren't really supposed to be called directly [20:47:28]@pflynn they should probably have an "_" prefix [20:47:37] @pflynn soon as i figure out a decent way of doing the render via GH ill do a PR for it and see what the author thinks :) [20:47:44]@pflynn cool! [20:48:02]@pflynn how about this: could you file a bug saying custom viewers aren't extensible, and then I'll see if we can get that improved for you next sprint? [20:48:09] ahhh, well it said 'public API' so figured it was kosher ;) but maybe not [20:48:25] what would be the next best thing to be able to 'take over' the editor view ? [20:48:31]@pflynn hmm.. where did it say "public"? [20:48:36] . . . . [20:48:39]@pflynn there's no supported way to do that yet, hence the bug [20:49:04] https://github.com/adobe/brackets/blob/master/src/editor/EditorManager.js#L990 [20:49:19]@pflynn ah ok, good point [20:49:35]@pflynn ok yeah, so can you file a bug? that whole API should be cleaned up so it's properly usable and not all confusing/misleading like it is now [20:49:53] :) like i said 1st time writing an extension so I'm not totally sure I'm doing it correctly

[core-ai-bot]

Comment by njx Monday Nov 18, 2013 at 19:17 GMT

---

Low pri to@couzteau to weigh in on whether this is something we could do relatively easily as a bug fix, or whether some more extensive restructuring would be required in order to make this a clean api. /cc@peterflynn for his opinion as well.

[core-ai-bot]

Comment by couzteau Saturday Jan 11, 2014 at 02:21 GMT

---

The API has evolved since this bug was filed. There is a new API called registerCustomViewer in EditorManager that allows to register customViewers from an extension. There is JSDoc to document the process.

Bottom line is that you'll want to associate you custom viewer with a file extension by registering it with EditorManager. Then When a file is open via the FILE_OPEN command Brackets knows that your extension can display that type of file. You might want to review the JSDoc on registerCustomViewer

Looking at the code of your (@chrismatheson) extension, I think there may be a twist. CustomViewers are supposed to be invoked via FILE_OPEN, not from a button in the toolbar. While that is an interesting idea, that's not how it was designed but I think it may be possible. Check out how DocumentCommandHandlers calls it.

I do expect some issues with how the project tree interacts with the custom viewer in that case as it's expecting the view to be a representation of a file in the project tree.

That said, not sure if there won't be pitfalls but I suggest you to come back if you have further questions.

[core-ai-bot]

Comment by couzteau Saturday Jan 11, 2014 at 02:23 GMT

---

That said. There may be sufficient documentation on the custom viewer related APIs. But I'm happy to take another look at it and I'm sure I'll find ways to improve it too. But if the docs are fine I think this bug may be closed.

[core-ai-bot]

Comment by chrismatheson Monday Jan 13, 2014 at 09:51 GMT

---

This is great, thanks for the help. Hopefully ill find some time soon to actually finish & publish my extension :smile:

[core-ai-bot]

Comment by peterflynn Monday Jan 13, 2014 at 21:28 GMT

---

@couzteau We should make showCustomViewer() and closeCustomViewer() have underscore prefixes -- everyone should just go through registerCustomViewer(), right? Reopening so we can do that API cleanup.

[core-ai-bot]

Comment by peterflynn Monday Jan 13, 2014 at 21:31 GMT

---

Re@chrismatheson's extension specifically: I think it can just register itself as a custom viewer and then call FILE_OPEN whenever it wants to view the special file type (e.g. on toolbar button click). However, if the file type should normally be shown as text and it's only going to show up as a static graphical preview at certain times (e.g. it shows as text when opened directly, but shows as preview when toolbar button clicked), then custom viewers aren't really the right solution. A bottom panel like in MarkdownPreview is the better choice in that situation.

[core-ai-bot]

Comment by chrismatheson Monday Jan 13, 2014 at 21:46 GMT

---

I would agree with everything should use the register custom viewer.

How do you think directories/folders could be registered? I know this is my specific use case.

On 13 Jan 2014, at 21:29, Peter Flynn notifications@github.com wrote:

@couzteau We should make showCustomViewer() and closeCustomViewer() have underscore prefixes -- everyone should just go through registerCustomViewer(), right? Reopening so we can do that API cleanup.

— Reply to this email directly or view it on GitHub.

[core-ai-bot]

Comment by couzteau Tuesday Jan 14, 2014 at 01:17 GMT

---

posted pull to prefix the functions mentioned by@peterflynn https://github.com/adobe/brackets/pull/6511

[core-ai-bot]

Comment by couzteau Tuesday Jan 14, 2014 at 01:23 GMT

---

I agree that the use case described doesn't fit the intended use case of the custom viewer well. The intended custom viewer use case will show a view by means of a custom viewer for a file that the code mirror editor cannot show, such as binary files. Registering a viewer means to associate the viewer with one or more file types by defining a language or mode for a number of file extensions.

PackageViewer wants to display a styled view of an aggregate of information from various files. Hence I don't think we have a good fit.

[core-ai-bot]

Comment by couzteau Monday Mar 17, 2014 at 21:30 GMT

---

@peterflynn There is asimple pull request up for this. It just renames the methods per your suggestion.

[core-ai-bot]

Comment by chrismatheson Monday Mar 17, 2014 at 21:42 GMT

---

Thanks for the help here guys, moved my extension to a Bottom panel instead, seems to be working well.

[core-ai-bot]

Comment by peterflynn Thursday Mar 20, 2014 at 23:43 GMT

---

The non-public APIs are now underscore-prefixed. Thanks for the cleanup@couzteau!