See the discussion starting here and continuing below for more information on this proposal. (This post was deliberately kept short, because SF currently does not allow ticket creation posts to be edited.)
As discussed at the link above, KeePass currently looks in the system registry for the information it uses to populate the menu that appears when right-clicking on a URL. However, the Windows facility that caused third-party programs to register themselves at this location only existed in Windows XP and Vista; Windows 7, 8, and 10 have no use for this list of programs. Therefore, it is likely that future programs may neglect to register their programs here - so these programs may therefore get excluded from the KeePass menu (unless the user resorts to hand-editing the information in the registry).
In addition, the original intent of this registry section was to enumerate the browsers installed on the system, but KeePass can be and has been used in conjunction with many other types of programs besides browsers. Listing only browsers in the KeePass submenu seems unnecessarily restrictive.
Therefore, I propose adding a customizable facility to KeePass that would allow the user to specify which programs should appear in this menu. The automatic appropriation of whatever registry entries already exist would be retained as a default initial configuration, but the user should be able to add other entries (including non-browser programs) to this list, and also able to remove entries for browsers that are installed, but rarely get used.
This could also lead to a generalization of the placeholder system for program paths; each entry in the list could be associated with a short identifier, which could then be used to specify a particular program in several entries without needing to hard-code the name or path to the program in those entries, so that a single configuration change would automatically change the program used by all similarly coded entries:
cmd://{PATH:MyPuTTY} myserver.mycompany.com
This could continue to allow use of the existing browser placeholders as synonyms:
Existing Placeholder
Proposed Replacement
{INTERNETEXPLORER}
{PATH:IE}
{FIREFOX}
{PATH:FIREFOX}
{OPERA}
{PATH:OPERA}
{GOOGLECHROME}
{PATH:CHROME}
{SAFARI}
{PATH:SAFARI}
The synonyms themselves could be predefined and nonremovable, while still allowing the user to specify null contents for them in order to remove them from the menus.
Last edit: T. Bug Reporter 2016-06-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since the URL arguments have to be constructed to be compatible with the helper application anyway, it may make more sense to implement non-browser helper apps using a Workspace URL override in 'Tools>Integration>URL Overrides(button, lower right)'. There already is a built-in PuTTy based override for the ssh protocol. The user could create a custom general purpose PuTTy override e.g.
My primary goal with this feature request is to increase the customizability of the Open With menu. I only mentioned changes to the placeholder system as a possible extension to this concept. While I do find the existing system of pseudoprotocols to be something of a kludge, I didn't mean to suggest that it wasn't adequate for its intended purpose.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Its not exactly clear to me how generalization improves the situation, though a limited ability to customize the browsers listed in the drop-down might benefit users and the developer alike by adding some flexibility, and by removing the burden of updating the list items based on user requests.
Presumably your customization proposal will entail user creation and saving of a definitions similar to override definitions, except that it would produce a menu item that is not associated with a protocol label. Since the same elements of the override (with the exception of the protocol label) need to be defined for a menu item, I don't see how the definition creation process would be more convenient than the override creation process, and it is not likely to be any more user accessible since creating menu items is not an everyday task.
A protocol serves the same function as a file extension. It associates a application to an argument list that is stored in the URL field.
Your proposal assumes there is no need to make this association, presumably because the user can select the protocol that matches the arguments in the entry's URL field from a menu drop-down. It seems to me it is a lot to expect that a user will remember these associations long after they first "created" (in the user's mind). It becomes more complicated for the user if they have defined several similar but different definitions e.g. in the putty example, a user might want to create separate definitions for ssh & loading saved profiles. Adding an association, using a protocol label, at the same time as the entry's URL field is populated seems to me to be far more reliable and just as convenient.
Programmatic association of an argument list with an application would also difficult to generalize because a given argument list may not be sufficient to identify the associated app. The KeePass URL list does something basic along these line, as evidenced by the fact that if the selected entry does not contain an appropriate URL, the URL drop-down list is grayed out. However, this process might be as simple as checking the protocol label listed in the URL field. It might be more sophisticated, but discriminating between URL, and not URL, is a much easier task than associating argument lists with a application.
While one might imagine some other association method it is almost certainly going to be more complex than defining a protocol name in an URL override.
Another reason to eschew generalization is that it adds considerable complexity, but in a password manager only a small fraction of entry URL fields are expected to be populated with non-URLs.
It does seem like it would be advantageous to users if they could define the browsers that appear in drop-down list. They would be free to define obscure browsers that they prefer, and eliminate installed browsers that they never use but for some reason don't want to uninstall. It would also reduce the burden on the developer since he would not longer need to entertain proposals to add this or that browser to the drop-down. I have no idea whether that is enough of a benefit to justify the time investment to add the such a feature.
Last edit: wellread1 2016-07-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see any benefit in the {PATH:APP} placeholder. If you want the path you should be able to use TXReplace.
I do agree that additional items on the Open URL menu would provide additional flexibility, but having a separate system to add them means added complexity of comfiguration, as wellread pointed out. Why not have a check box to add user defined protocols to the menu, then all the config is in one place.
cheers, Paul
Last edit: Paul 2016-07-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Wow. You guys seem to be overthinking this, way, way beyond my actual intent. I'd have no problem with combining my desired menu configuration with the existing pseudoprotocol definition dialog, as long as it gives me the ability to add or remove items from the "Open With" menu the way Dominik's registry editing suggestion would, but without having to actually edit the registry.
In fact, when I first came up with this, I had forgotten that the pseudoprotocol definition dialog already existed - or rather, I had failed to recognize it as a way to specify a particular helper app to use for a given URL. To me, a protocol is intended to specify how a program is expected to access a given resource, not which program should be used to access the resource. In my mind (and having a history of using FTP and even Gopher sites occasionally), programs are not protocol-specific, the same way that true protocols such as HTTP and HTTPS aren't program-specific.
Last edit: T. Bug Reporter 2016-07-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Be wary of being sidetracked by terminology and missing the meaning. The KeePass developer is more precise than either of us, and uses the more accurate terms Override and Scheme rather than protocol when referring to overrides. A override scheme is also not a pseudoprotocol or a kludge.
The KeePass Workspace override scheme allows the user to define a one line override that defines the program to be invoked and its arguments. The user also assigns a scheme label much like the protocol label used in a standard URL. This is a simple, concise, flexible, reliable mechanism that makes use of a familiar paradigm.
Your digression into complicated generalization strategies suggested to me that you might have overlooked the excellent built-in Workspace override capability. Which apparently you had.
Last edit: wellread1 2016-07-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A override scheme is also not a pseudoprotocol or a kludge.
At the risk of offending you and/or Dominik, I have to say that this had me thinking, "If it looks like a duck and quacks like a duck..."
This is a simple, concise, flexible, reliable mechanism that makes use of a familiar paradigm.
The paradigm may be familiar, but it still strikes me as less appropriate than other paradigms that might have been chosen to model this functionality against. But enough about that; clearly, this is a problem solely with my own mental model for these functions. I also clearly can't be counted on to come up with a workable method for integrating configuration of the Open With menu into the existing model, so I'd appreciate seeing what other people have to say on that aspect (which, I'll point out again, is really the only aspect of this discussion that I have any vested interest in.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To rephrase once again: The official URI specification encompasses far too many possibilities for my widdle bwain to handle, and the "URL" concept that I (and, I thought, most others) had formulated over the years is deliberately left undefined in the spec - probably to allow for such a fluid understanding of the concept.
Can we move on?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, I meant a way to change the meaning of e.g. "{FIREFOX}" in substitutions; my understanding is that URL Overrides can only change the way "http:" is interpreted - or add interpretations for things like "http-special:".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As discussed at the link above, KeePass currently looks in the system registry for the information it uses to populate the menu that appears when right-clicking on a URL. However, the Windows facility that caused third-party programs to register themselves at this location only existed in Windows XP and Vista; Windows 7, 8, and 10 have no use for this list of programs. Therefore, it is likely that future programs may neglect to register their programs here - so these programs may therefore get excluded from the KeePass menu (unless the user resorts to hand-editing the information in the registry).
In addition, the original intent of this registry section was to enumerate the browsers installed on the system, but KeePass can be and has been used in conjunction with many other types of programs besides browsers. Listing only browsers in the KeePass submenu seems unnecessarily restrictive.
Therefore, I propose adding a customizable facility to KeePass that would allow the user to specify which programs should appear in this menu. The automatic appropriation of whatever registry entries already exist would be retained as a default initial configuration, but the user should be able to add other entries (including non-browser programs) to this list, and also able to remove entries for browsers that are installed, but rarely get used.
This could also lead to a generalization of the placeholder system for program paths; each entry in the list could be associated with a short identifier, which could then be used to specify a particular program in several entries without needing to hard-code the name or path to the program in those entries, so that a single configuration change would automatically change the program used by all similarly coded entries:
cmd://{PATH:MyPuTTY} myserver.mycompany.com
This could continue to allow use of the existing browser placeholders as synonyms:
The synonyms themselves could be predefined and nonremovable, while still allowing the user to specify null contents for them in order to remove them from the menus.
Last edit: T. Bug Reporter 2016-06-30
Since the URL arguments have to be constructed to be compatible with the helper application anyway, it may make more sense to implement non-browser helper apps using a Workspace URL override in 'Tools>Integration>URL Overrides(button, lower right)'. There already is a built-in PuTTy based override for the ssh protocol. The user could create a custom general purpose PuTTy override e.g.
With this override one could enter the "putty" protocol and whatever putty command line arguments you wished to pass into the entry's URL field e.g.:
Last edit: wellread1 2016-06-30
My primary goal with this feature request is to increase the customizability of the Open With menu. I only mentioned changes to the placeholder system as a possible extension to this concept. While I do find the existing system of pseudoprotocols to be something of a kludge, I didn't mean to suggest that it wasn't adequate for its intended purpose.
Its not exactly clear to me how generalization improves the situation, though a limited ability to customize the browsers listed in the drop-down might benefit users and the developer alike by adding some flexibility, and by removing the burden of updating the list items based on user requests.
Presumably your customization proposal will entail user creation and saving of a definitions similar to override definitions, except that it would produce a menu item that is not associated with a protocol label. Since the same elements of the override (with the exception of the protocol label) need to be defined for a menu item, I don't see how the definition creation process would be more convenient than the override creation process, and it is not likely to be any more user accessible since creating menu items is not an everyday task.
A protocol serves the same function as a file extension. It associates a application to an argument list that is stored in the URL field.
Your proposal assumes there is no need to make this association, presumably because the user can select the protocol that matches the arguments in the entry's URL field from a menu drop-down. It seems to me it is a lot to expect that a user will remember these associations long after they first "created" (in the user's mind). It becomes more complicated for the user if they have defined several similar but different definitions e.g. in the putty example, a user might want to create separate definitions for ssh & loading saved profiles. Adding an association, using a protocol label, at the same time as the entry's URL field is populated seems to me to be far more reliable and just as convenient.
Programmatic association of an argument list with an application would also difficult to generalize because a given argument list may not be sufficient to identify the associated app. The KeePass URL list does something basic along these line, as evidenced by the fact that if the selected entry does not contain an appropriate URL, the URL drop-down list is grayed out. However, this process might be as simple as checking the protocol label listed in the URL field. It might be more sophisticated, but discriminating between URL, and not URL, is a much easier task than associating argument lists with a application.
While one might imagine some other association method it is almost certainly going to be more complex than defining a protocol name in an URL override.
Another reason to eschew generalization is that it adds considerable complexity, but in a password manager only a small fraction of entry URL fields are expected to be populated with non-URLs.
It does seem like it would be advantageous to users if they could define the browsers that appear in drop-down list. They would be free to define obscure browsers that they prefer, and eliminate installed browsers that they never use but for some reason don't want to uninstall. It would also reduce the burden on the developer since he would not longer need to entertain proposals to add this or that browser to the drop-down. I have no idea whether that is enough of a benefit to justify the time investment to add the such a feature.
Last edit: wellread1 2016-07-01
Also I don't see how {PATH:MyPuTTY} is any different than an override. Here "MyPuTTY" is the psuedo protocol.
I don't see any benefit in the {PATH:APP} placeholder. If you want the path you should be able to use TXReplace.
I do agree that additional items on the Open URL menu would provide additional flexibility, but having a separate system to add them means added complexity of comfiguration, as wellread pointed out. Why not have a check box to add user defined protocols to the menu, then all the config is in one place.
cheers, Paul
Last edit: Paul 2016-07-01
Wow. You guys seem to be overthinking this, way, way beyond my actual intent. I'd have no problem with combining my desired menu configuration with the existing pseudoprotocol definition dialog, as long as it gives me the ability to add or remove items from the "Open With" menu the way Dominik's registry editing suggestion would, but without having to actually edit the registry.
In fact, when I first came up with this, I had forgotten that the pseudoprotocol definition dialog already existed - or rather, I had failed to recognize it as a way to specify a particular helper app to use for a given URL. To me, a protocol is intended to specify how a program is expected to access a given resource, not which program should be used to access the resource. In my mind (and having a history of using FTP and even Gopher sites occasionally), programs are not protocol-specific, the same way that true protocols such as HTTP and HTTPS aren't program-specific.
Last edit: T. Bug Reporter 2016-07-01
Be wary of being sidetracked by terminology and missing the meaning. The KeePass developer is more precise than either of us, and uses the more accurate terms Override and Scheme rather than protocol when referring to overrides. A override scheme is also not a pseudoprotocol or a kludge.
The KeePass Workspace override scheme allows the user to define a one line override that defines the program to be invoked and its arguments. The user also assigns a scheme label much like the protocol label used in a standard URL. This is a simple, concise, flexible, reliable mechanism that makes use of a familiar paradigm.
Your digression into complicated generalization strategies suggested to me that you might have overlooked the excellent built-in Workspace override capability. Which apparently you had.
Last edit: wellread1 2016-07-01
At the risk of offending you and/or Dominik, I have to say that this had me thinking, "If it looks like a duck and quacks like a duck..."
The paradigm may be familiar, but it still strikes me as less appropriate than other paradigms that might have been chosen to model this functionality against. But enough about that; clearly, this is a problem solely with my own mental model for these functions. I also clearly can't be counted on to come up with a workable method for integrating configuration of the Open With menu into the existing model, so I'd appreciate seeing what other people have to say on that aspect (which, I'll point out again, is really the only aspect of this discussion that I have any vested interest in.)
You might find this article useful https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
To rephrase once again: The official URI specification encompasses far too many possibilities for my widdle bwain to handle, and the "URL" concept that I (and, I thought, most others) had formulated over the years is deliberately left undefined in the spec - probably to allow for such a fluid understanding of the concept.
Can we move on?
If options like the one described here exist in KeePass V1, why can't we get similar options in V2?
Already there.
Tools > Options > Integration > URL Overrides.
cheers, Paul
No, I meant a way to change the meaning of e.g. "{FIREFOX}" in substitutions; my understanding is that URL Overrides can only change the way "http:" is interpreted - or add interpretations for things like "http-special:".
Cross reference to new discussion along these lines