Bug 449240

Comment 1 Curtis Windatt 2014-10-30 16:00:55 EDT

Two possible approaches:
1) Use the existing delegatedUI for commands which allows third party content to be displayed in an iframe and the result returned to the editor.  As an example I hooked up the Google Picker delegated UI example into the hover for CSS.

2) Allow HTML content but sandbox it in an iframe.

Comment 2 Curtis Windatt 2014-10-30 16:07:50 EDT

Created attachment 248284 [details]
Screenshot of image picker in the tooltip

Comment 3 Curtis Windatt 2014-10-30 16:25:18 EDT

Created attachment 248285 [details]
Screenshot of linking to w3cschool page

Comment 4 Curtis Windatt 2014-10-30 16:45:25 EDT

Created attachment 248286 [details]
Screenshot of sandboxed html to display colour

Comment 5 Eric Moffatt 2014-10-31 13:33:11 EDT

Curtis, we've been talking about this. While we likely can't *directly* incorporate HTML directly from a plugin for security reasons we should be able to do something along the lines of a 'UIPlugin' (a more functional version of a 'delegated UI'). Since it's sandboxed in its own IFrame it should be safe but we'll likely have to do some figurin' to determine how the various bits communicate (i.e. how do you hook it up so that when the user picks a file you make the changes...).

Comment 6 Eric Moffatt 2014-10-31 13:52:47 EDT

BTW Curtis, I *love* the kind of thing that you're looking at ! Obviously some of these would be invoked through some key-binding rather than in a hover but the concepts are great.

Once we get a bit farther along we'll break the curent 'hover' code up so that the current hover capability is encapsulated as a 'flavor' of a new 'InfoPopup' concept. Then we can produce a parameterized command that takes the 'flavor' as its parameter. The various hover plugins would be filtered by 'flavor' with the result being built up as it currently is in tooltip.js.

We need an API like this:

constructInfoPopup(flavor) - Gathers up the info from the appropriate plugins and displays it using something like the current tooltip.

Then we can make a trivial command that just calls the above api with its 'flavor'.

A quick thought on this; we may want to be able to re-use the same keybinding for different cases. For example imagine a 'define value' command that allows you to select a file if you're over an image and also allows you to choose a color if you're over a color attribute...(sort of a content assist that isn't syntax based...;-).

Comment 7 Curtis Windatt 2014-11-05 13:16:50 EST

(In reply to Eric Moffatt from comment #5)
> Curtis, we've been talking about this. While we likely can't *directly*
> incorporate HTML directly from a plugin for security reasons we should be
> able to do something along the lines of a 'UIPlugin' (a more functional
> version of a 'delegated UI'). Since it's sandboxed in its own IFrame it
> should be safe but we'll likely have to do some figurin' to determine how
> the various bits communicate (i.e. how do you hook it up so that when the
> user picks a file you make the changes...).

This all comes down to how the delegated hover content can communicate with the editor.  The delegated UI from extension commands only allows it to provide new text content to the editor.  The editorPluginView does something similar but provides a textModel object with get/setText, replacing the entire file content.

On top of that Jump to Declaration would likely need the Selection service.  Refactoring would want to make multiple changes to the text (without rewriting the entire content).  Need to look at what your new quickfix code uses.

Comment 8 Eric Moffatt 2014-11-07 11:04:27 EST

Curtis, for me it's fine to replace the complete buffer and send it back. We should (if we aren't already)) be able to provide the UI Delegate with an 'editorContext' and then the pattern I use in QuickFixTest should work; you can create your own TextModel from the text provided by the editorContext, use it to parse / make changes and then dump the buffer back once you're done.

I don't think that the performance is an issue here since the data is actually being copied in the same process (it's a simple mem -> mem copy).

Comment 9 Silenio Quarti 2014-11-07 16:19:54 EST

> The editorPluginView does something similar but provides a textModel object > with get/setText, replacing the entire file content.

Note that the textModel provided in editorPluginView allows changing ranges of text the same way the editor context service does.

Comment 10 Curtis Windatt 2014-11-18 15:47:27 EST

http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=85b87c0e3eb892cdd1a2634afea4b1b20ffa16f4
This introduces support for two new data kinds 'html' and 'delegatedUI'.  HTML creates an iframe and embeds the provided content inside of it.  The delegatedUI requires that you provide a uriTemplate instead of content, same as the existing delegatedUI in editor commands.

This commit also includes cssHover.js with examples of using both content types.  However as they aren't polished, the hover service entry in WebToolsPlugin.js is commented out.

Note that the content types are not yet considered API.  I suspect we'll keep the HTML support, but delegatedUI is likely to be replaced with something that has more interaction with the editor and contributing plug-in.  There are also many UI tweaks needed in the tooltips to allow rich content to be usable (better positioning, resizing, border/margin changes).

Comment 11 Curtis Windatt 2014-11-28 14:05:14 EST

Closing as FIXED as we allow HTML and delegatedUI.  I will open a new bug for investigating the UIPlugin approach.