Plug-in architecture: improvements

In this chapter, we speak not about new plugins, but about extensions made in the core of the code to enable creation of new plugins.

New plugin types

Editor popups

It is now possible to create plugin which adds entries in the editor's contextual (right click) menu. These plugins are singletons, but contrairly to other existing types, they need to get the editor in their constructor.

Actually this is not possible for such a plugin to set where it should be put in the menu: they will appear at the end, and when you use more than one plugin, you have no real guarantee about which one will come first in the list: you can play with jar names, but it may be not enough.

Dockable (experimental)

Such a plugin may be able to add a new sub-window inside the main "dockable" panel. Some such plugins have been tested but actually they can cause problems with the configuration registered in the uiLayout.xml, where the added window may not be registered.

Actually not used anymore, kept in the code in case it may be useful.

Translation memory   

Such plugins are designed to implement Teambase's Memory mode, but a sample is provided using an already known provider: MyMemory. Look here for a better description of why it is sometimes better to create translation memory plugins, rather than machine translation ones.

Project memory   

Such plugins are designed to implement Teambase's Project mode (which can be seen as an implementation of this RFE), but a sample is provided using RMI as an alternative. Such a plugin does not have an entry in plugin types, because it is project-dependant - more precisely, for each project it can have exactly zero or one instance (and this instance is not shared with other projects). Look here for a better description of these plugins.

Plugin as file descriptors   

Glossary or translation memory plugins may refer to resources which are divided into collections. And depending on which project you are translating, only a small part of these collections should be really relevant.

For that reason, these two kinds of plugins can be used either as singletons (i.e. as does actually OmegaT, where each plugin has exactly one instance) or using files in the respective directory (tm/ or glossaries/). You can have one or more files, depending on how many sub-collections you want to be connected with - if it implies connection to a database, it is up to the plugin to manage single connection when it is possible.

Note that project memory, just mentionned before, uses a similar mechanism but with a small difference: the descriptor file is unique, which is garantied by the fact that it is named omegat/project_save.properties ; only when used for cross-lingual concordance (tmx2source) you can have more than one instance of project memory plugin.

Improved editor markers

OmegaT 3.5 implemented a lazy loading of segments in editor, making it faster for very large files. But there is still a problem when a file, independantly from its size, contains very large segments.

Actually in OmegaT, markers for the active segment are 100 % refreshed (deleted and insterted again) each time the document is changed - so, on every key typing. If a lot of markers are activated, this can make the Swing GUI thread very slow.

To avoid that, we created a new interface named IFastMarker with two additionnal methods: given the document event which implies the change, these methods will say which marks should be removed and which new ones should be added. Now, for each marker, if it implements this interface, only the marks returned by these methods will be sent to the Swing thread for update. If not, the original algorithm is still used. This algorithm is only used for document changes, not for the thread which regularly refreshes markers in background.

Note for developpers of editor markers:  what makes really this algorithm faster is not the performance of the two methods themselves — they can even be slower than the original getEntryMarksForEntry. What makes the algorithm faster is that they do not return the full set of marks, but only those which may be added or removed. What is important is to return the smaller possible sets: thanks to this, the Swing thread has less work and is sooner capable of receiving next key events. This also saves some memory, since the marks list (which is not anymore a fixed array) will be updated, instead of creating a new one. As said here the white space marker is particularly affected, not because of the search itself, but because it returns a very long list of marks: returning only the modified ones is very efficient for this marker, if not for others.