I'm working on adding support for autocomplete to the D bundle. I'm using the Ruby method "TextMate::UI.complete" to display the completion result. This UI supports displaying images in the list of the results, first it took me a while to figure out that the images needs to be registered using the dialog command.
Now the question is why is this necessary? I looked in the source code for the dialog command and it looks like the register action/sub command creates NSImages of the given paths. I was thinking that the "popup" dialog command could automatically register the images.
As far as I know it's not possible to automatically execute a bundle command ones, so the completion command needs to register the images every time because it doesn't know if the images have already been registered.
On 13 Jul 2016, at 11:30, Jacob Carlborg wrote:
Now the question is why is this necessary? I looked in the source code for the dialog command and it looks like the register action/sub command creates NSImages of the given paths. I was thinking that the "popup" dialog command could automatically register the images.
The idea with the image registration is that you register a dictionary with _name_ → _path_ pairs and in your pop-up description you use the symbolic names.
The advantage of this is that we will only create one `NSImage` per path and the popup menu definition can be simpler, i.e. using `symbol` instead of `/Users/«name»/Library/Application Support/TextMate/Managed/Bundles/«some bundle».tmbundle/Support/symbol.pdf` for every single menu item.
Though regarding the former, the command could be updated to automatically “register” any image provided as a full path (possibly with its hash value to facilitate re-use of images).
On 2016-07-14 13:52, Allan Odgaard wrote:
The idea with the image registration is that you register a dictionary with /name/ → /path/ pairs and in your pop-up description you use the symbolic names.
The advantage of this is that we will only create one |NSImage| per path and the popup menu definition can be simpler, i.e. using |symbol| instead of |/Users/«name»/Library/Application Support/TextMate/Managed/Bundles/«some bundle».tmbundle/Support/symbol.pdf| for every single menu item.
I find it hard to see how that's simpler. Rather I think it's more complicated, because you need to:
1. Make a separate call to the dialog command. This is not documented, at least not in the documentation for the popup Ruby method. The tests don't t even do this and in general look outdated. There's also no Ruby interface for this, as far as I can see. Well actually, the "complete" method does document the ":images" option to be a hash of image names to paths but it doesn't use that option at all, adding even more to the confusion
2. Setup the mapping of a symbolic name to a path
3. There also seems to be a risk of having conflicting names between different bundles and possible the application itself
When it comes to efficiency the register command already caches the NSImage objects using NSImage.setName/imageNamed, as far as I can see. So if the popup command just contained the same code as the register command the problem would be solved :). It would also make the dialog command simpler because the register command could be removed.
The only reason I see why a register command would be useful is to be able to call it once to register the images. But it's not possible to automatically run a command only once, as far as I know. Commands don't have state (unless you want to read/write to a file) so you can't check if you already registered the images.
(sorry for the rant).
On 14 Jul 2016, at 21:33, Jacob Carlborg wrote:
- Make a separate call to the dialog command. This is not documented,
at least not in the documentation for the popup Ruby method.
Making a 1:1 copy of the DIALOG API in ruby has never been my desire, in fact, I personally prefer to use DIALOG directly, even from ruby, as DIALOG itself provides a stable and straightforward API.
The ruby wrappers was born back when the first version of the Dialog plug-in was written, which had a more complex API, so back then, there was justification, but not really with v2 of the Dialog plug-in.
Unfortunately once things have been added to the support library, it is extremely difficult to remove, because it is effectively public API.
- Setup the mapping of a symbolic name to a path
Don’t you need some sort of mapping? Or does your completion code deal in absolute paths to images when it classifies the candidates for the completion menu?
- There also seems to be a risk of having conflicting names between
different bundles and possible the application itself
This was intended, similar to how we provide Warning, Note, Error, etc. for the gutter, it would not be unlikely to provide constant, variable, method, classMethod, etc. as standard images for the pop-up.
When it comes to efficiency the register command already caches the NSImage objects […]
Yes, the register command adds the image to the cache using their symbolic names, and the pop-up menu definition uses the symbolic names to reference the images.
But this indirection is what you are arguing for removing, so I don’t get this part.
It would also make the dialog command simpler because the register command could be removed.
The register command was also intended to be usable before loading nibs (with images).
(sorry for the rant).
As I said: _the command could be updated to automatically “register” any image provided as a full path (possibly with its hash value to facilitate re-use of images)_ so while you felt it necessary to rant is beyond me.
On 2016-07-15 09:58, Allan Odgaard wrote:
Don’t you need some sort of mapping? Or does your completion code deal in absolute paths to images when it classifies the candidates for the completion menu?
Yes, I need to map the result from the completion tool a path, but with the current API it's necessary to map a symbolic name to a path as well. That means to sets of mappings.
Yes, the register command adds the image to the cache using their symbolic names, and the pop-up menu definition uses the symbolic names to reference the images.
But this indirection is what you are arguing for removing, so I don’t get this part.
I was thinking of just using the full path as the key.
It would also make the dialog command simpler because the register command could be removed.The register command was also intended to be usable before loading nibs (with images).
(sorry for the rant).As I said: /the command could be updated to automatically “register” any image provided as a full path (possibly with its hash value to facilitate re-use of images)/ so while you felt it necessary to rant is beyond me.
For some reason I though you were referring to the register command. That's my mistake, I apologize.
-
Allan Odgaard -
Jacob Carlborg