OmegaT version 4 adds some window menus in the search screens, enabling to insert source or target in the search field. The idea is not bad. But the problem with this approach is that for the replace window, they should have to duplicate the menus if the user wants to have the possibility to do something with the replace field as well. Considering the fact that our main search screen has up to 3 different text fields, such an approach would have been unacceptable. For that reason we use popup menus instead.
In the case of DGT-OmegaT, the main reason why to add this possibility is to use the pseudo-tags: as they are not present in the keyboard, it is impossible to type them. In the editor, the user adds it with a popup menu, so it was logical to do the same with the search screens:
During the implementation it became clear that it would be a good idea to re-use the code already written for the editor. That means, re-use the same popup menu constructor class, and then, to build the same kind of rules to build the popup menu based on integer to give the order. Most popup menu constructors may work the same way in the editor as in search screens. Not all popup menus can play both roles - editor popup can be linked to the segment at given position, while search popup is linked to a uniline text component. Actually the default menu (cut/copy/paste) and the tag inserter are implemented, others may be added in the future.
Add new comment