latitude/longitude of center of map, scale of map (in mapblast style),height/width of image). In this file, relative and absolute paths areaccepted for maps.One principle of the map painting algorithm is that if no maps for agiven scale are available, maps of other scales are used as well andresized to fit the used scale (see\stdref{fig:SoftwareDesignOfTheGpstoolPackage-MapsOfDifferentScalesMayBeDisplayed}for an example).\image[1.0]{images/screenshot_diff_scales}{Maps of different scalesmay bedisplayed.}{}{fig:SoftwareDesignOfTheGpstoolPackage-MapsOfDifferentScalesMayBeDisplayed}The first attempt to draw the maps was the following: Find all mapsthat are visible and draw them in the order largest scale to smallestscale. So if there is a plan of the city Graz and a map of Europe, thecity plan is painted over the map of Europe.This algorithm scales very badly, as all maps are painted, even if theuser does not see the maps because of another map lying over the firstone.So an algorithm was developed that searches the smallest map to show,paint it, and find the rectangles on the screen that are not coveredby this map. For the remaining empty rectangles, the algorithm isrepeated until the screen is filled, or no more maps areavailable. This algorithm is implemented and documented in the\classname{org.dinopolis.gpstool.gui.util.VisibleImage} class.Maps are only painted, if their scale is not completely different tothe scale that is currently being used. This prevents the painting ofthe city plan, when the user wants to see western Europe, as the cityplan would be so small anyway. So if the current scale is 1:200000,only maps up to (e.g.!) 1:100000 are used, other (more detailed) maps,are not even considered to be painted! This factor is configurable.%----------------------------------------------------------------------%----------------------------------------------------------------------\subsubsection{Location Marker Layer}\label{SoftwareDesignOfTheGpstoolPackage-LocationMarkerLayer}The layer that displays location markers handles differentsources\footnote{interface\classname{org.dinopolis.gpstool.gui.layer.location.LocationMarkerSource}}of markers. They may be read from a file or from a relation databaseand provide \classname{LocationMarker} objects for a given area(limited by north, south, west, east latitude/longitude).Additionally the sources can be asked to apply a given filter, so onlylocation markers for one or more given categories should beretrieved. This Filter was designed to be independent of the source,so in the case of a relation database source it is translated into thecorrect SQL statements.%######################################################################\subsection{Debug}\label{SoftwareDesignOfTheGpstoolPackage-Debug}The \packagename{org.dinopolis} packages use the\classname{org.dinopolis.util.Debug} package for printing debugmessages. This package is similar to the \packagename{log4j} packageof the apache framework. It allows to define debug messages that areonly printed if the attached debug level is activated.The debug levels may be activated by using the appropriate API or byediting the debug properties file. For a detailed description of the\classname{Debug} class, please see the design document of the debugutility. %######################################################################%######################################################################\section{Plugins}\label{SoftwareDesignOfTheGpstoolPackage-Plugins}The GPSylon application supports different kinds of plugins. Theseplugins extend the functionality of the application. As there is aclearly and quite simple interface for plugins, the developement isquite simple and possible without the need to read and understand thesource of the rest of the application. Another advantage of pluginsis, that removing then makes the application smaller and probablyfaster. So big, fat computers may install and run all possibleplugins, whereas the old notebook that is used in the car for locationtracking just uses the plugins that are really needed. In the following, a short explanation of the different aspects ofplugin developement is given.%######################################################################\subsection{Types of Plugins}\label{SoftwareDesignOfTheGpstoolPackage-TypesOfPlugins}GPSylon supports different kinds of plugins for differentpurposes. Some are very special for a very small task (like saving thecontent of the map component to a file (screenshot)), others are verygeneral and influence the functionaltiy in a wider way (like adding alayer to the map component, some entries in the menu, and may react onmouse clicks and keys from the user). In general, all plugininterfaces (and helper interfaces) are in the package\packagename{org.dinopolis.gpstool.plugin}.\begin{itemize}\item The \interfacename{ReadTrackPlugin} is used to load tracks fromfiles.\item The \interfacename{WriteImagePlugin} is used to save a``screenshot'' from the map component to a file.\item The \interfacename{MouseModePlugin}: GPSylon supports differentmouse modes that react on mouse activities from the user (click, drag,etc.). The user may switch a mouse mode on or off (and there is alwaysonly one mouse mode active). An example for a mouse mode is navigation(zoom in out, pan the map, etc.). As the mouse modes are switched onor off by the user, they have to provide some information for an entryin the menu or a toolbar: name, icon, shortcut key, ...Additonally, a mouse mode may provide a layer that allows the mousemode to draw something on the map component. \item The \interfacename{GuiPlugin} is the most powerful plugin. It  has the possibility to add one or more entries in the menu of the  application. An example would be a window that provides information  about memory usage or a tachometer that shows lots of informations  from the gps device (speed, average, direction, etc.).Additionally, \interfacename{GuiPlugins} may provide one or more mousemodes to be able to react on mouse clicks on the map component. If a \interfacename{GuiPlugin} needs to draw anything on the mapcomponent, it may provide a \classname{Layer}.GPSylon uses the \classname{MapBean} class of the openmap library asthe central map component. This class uses \classname{Layer} objectsas layers.  Every layer is informed about changes of the projection(zoom in/out, move) in the\methodname{projectionChanged(com.bbn.openmap.proj.Projection)}method. The layer may paint some map details in the\methodname{paint(java.awt.Graphics)} or\methodname{paintComponent(java.awt.Graphics)} methods. Please, see\stdref{SoftwareDesignOfTheGpstoolPackage-Projection} for detailsabout projections.The \methodname{paint()} method should return as fast as possible, socomplicated calculations should not be done in this method but in abackground thread. The class\classname{org.dinopolis.gpstool.gui.BasicLayer} provides a frameworkthat calls a calculation method in a background thread(\classname{SwingWorker}). So the developer does not need to worryabout this!\item The \classname{MapRetrievalPlugin}: Used by the download mouse  mode to retrieve raster maps from various sources. The application  requests a raster map for a given location, size and scale. As  different map sources may provide only specific scales, the  \interfacename{MapRetrievalPlugin} has a method that has to return  the really used scale (may differ from the scale requested). All  scale values are given in mapblast units (as this was the first  server supported). E.g.\ 1000 is a very small scale (lots of  details), whereas 1000000 (one million) shows most of Europe.\end{itemize}The interface \interfacename{Plugin} is the base interface for allplugins that provide general information (like the name and version ofa plugin). This information may be used by a plugin manager or by aplugin downloader to find the latest version of a plugin.All plugins are instatiated and then initialized with a\interfacename{PluginSupport} object that provides interfaces for allimportant modules and componentes of GPSylon.Please see the javadoc documentation of the plugin interfaces andclasses for further details.%######################################################################\subsection{Loading of Plugins}\label{SoftwareDesignOfTheGpstoolPackage-LoadingOfPlugins}In this section the two mechanisms used to find and load plugins areexplained: \begin{itemize}\item Find the implementation classes of a given interface or baseclass. \item Load classes from jar files that are not in the classpath.\end{itemize}The first problem when using plugins is to find one or moreimplementations of a special java interface or base class. The normalclassloader does not provide this functionality, so the help of anexternal configuration is needed. Sun uses a file in the\texttt{META-INF/services} directory (in a jar file or elsewhere inthe classpath) for this purpose. This file is named like the interfaceor base class and contains the names of classes that implement thisinterface or base class.As an example, suppose there are two implementations of the interface\interfacename{org.dinopolis.gpstool.plugin.GuiPlugin}, namely theclasses \classname{foo.Bar} and \classname{bar.Foo}. So the file\texttt{META-INF/services/org.dinopolis.gpstool.plugin.GuiPlugin}contains two lines:\begin{verbatim}foo.Barbar.Foo\end{verbatim}Sun uses an internal class (in the package \packagename{sun.misc}) tofind the implementations (called \textit{services}). As the sun classis internal and may change in the future, its functionality was newlyimplemented. \classname{org.dinopolis.util.servicediscovery.ServiceDiscovery}retrieves the information in \texttt{META-INF/services} from one ormore classloaders and returns the names or faster the instances of theclasses of the given interface of base class.The \classname{ServiceDiscovery} uses the\methodname{getResources(String)} of the \classname{ClassLoader} tofind the files in the \texttt{META-INF/services} directory. This leads to the second problem of plugins: it cannot be guaranteedthat the classpath includes the plugin (jar). A good pluginarchitecture allows to find, load and use the jar files that containthe plugins in one or more directories. For this purpose, a special\classname{ClassLoader} was written that loads classes from jar fileslocated in one or more directories that may be given at runtime.This class loader is\classname{org.dinopolis.util.servicediscovery.RepositoryClassLoader}and in combination with the \classname{ServiceDiscovery} describedabove, it provides the wanted functionality: Find and loadimplementations of a given class and use jar files in one or moredirectories.%% list of acronyms%\addcontentsline{toc}{chapter}{\listacronymname}%\printglosstex(acr)%% ======================================== end document header%% ======================================== begin document body%% the document body following the Dino Documentation Rules.%% Please read the Dino Documentation Guidelines for structuring%% conventions, etc...%% ======================================== end document body%% glossary%\addcontentsline{toc}{chapter}{\glossaryname}%\printglosstex(glo)%% ======================================== begin references%\bibliographystyle{alpha}%\addcontentsline{toc}{chapter}{\bibname}%\bibliography{../../bibliography_entries} %% ======================================== end references%% end of document marker to be able to see if the document is%% complete when printed\documentend\end{document}