diff --git a/docking-frames-common/guide/Transition.tex b/docking-frames-common/guide/Transition.tex index fc5b9822..7fa581d7 100644 --- a/docking-frames-common/guide/Transition.tex +++ b/docking-frames-common/guide/Transition.tex @@ -456,7 +456,7 @@ \subsubsection{Dockable with Tooltip} \subsubsection{ColorManager generalized} \begin{description} - \short \src{ColorManager} extends \src{UIProperties}, \src{ColorProvider} is replaced by \src{ColorBridge} which extends \\\src{UIBridge}, \src{DockColor} extends \src{UIValue}. \\\src{ColorManager.getProviderFor} is replaced by \\\src{UIProperties.getBridgeFor}. Bridges and Values are no longer connected though the class of the \src{UIValue} but by a \src{Path} object. These objects are much more flexibel than classes and not hard to understand. + \short \src{ColorManager} extends \src{UIProperties}, \src{ColorProvider} is replaced by \src{ColorBridge} which extends \\\src{UIBridge}, \src{DockColor} extends \src{UIValue}. \\\src{ColorManager.getProviderFor} is replaced by \\\src{UIProperties.getBridgeFor}. Bridges and Values are no longer connected though the class of the \src{UIValue} but by a \src{Path} object. These objects are much more flexible than classes and not hard to understand. \why This generalization will allow to use the \src{UIProperties} for other things than just colors. There are plans to use the same system for fonts as well. \clients Should replace \src{ColorProvider} by \src{UIBridge} \end{description} diff --git a/docking-frames-common/guide2/effects/chapter.tex b/docking-frames-common/guide2/effects/chapter.tex index 441ecb5c..46181aa2 100644 --- a/docking-frames-common/guide2/effects/chapter.tex +++ b/docking-frames-common/guide2/effects/chapter.tex @@ -30,7 +30,7 @@ \subsection{Font} \warningbox{Some \src{Components}, like the \src{JTabbedPane}, and some \src{LookAndFeel}s do not support custom fonts. In this case the settings are just ignored. } \subsection{Size} \label{sec:size} -Every \src{dockable} has a width and a height. Some \src{dockable}s are flexibel in their size, others would be better of with a constant size. There is a feature to lock the size and a feature to set a specific size. +Every \src{dockable} has a width and a height. Some \src{dockable}s are flexible in their size, others would be better of with a constant size. There is a feature to lock the size and a feature to set a specific size. \subsubsection{Lock the size} Every \src{AbstractCDockable} has the method \src{setResizeLocked}. If the size is locked then the framework will try not to change the size of the \src{dockable}. There are also methods to lock only the width or the height \linebreak (\src{setResizeLockedHorizontally} and \src{setResizeLockedVertically}). diff --git a/docking-frames-common/guide2/foundation/chapter.tex b/docking-frames-common/guide2/foundation/chapter.tex index 01ea07c9..15637b65 100644 --- a/docking-frames-common/guide2/foundation/chapter.tex +++ b/docking-frames-common/guide2/foundation/chapter.tex @@ -67,7 +67,7 @@ \subsubsection{Visibility} \paragraph{Logical visibility} A \src{dockable} is (logical) visible if it is either a child of a visible root-station or a registered root-station. With other words, logical visibility means that the \src{dockable} is somehow accessible to the user, it does not even imply that the user actually can see the \src{dockable} on the screen. Visibility can change through a set of events: \begin{itemize} - \item Obviosly, calling \src{setVisible} of \src{CDockable} will change the visibility. If possible, the location of a \src{CDockable} will remembered and reused. + \item Obviously, calling \src{setVisible} of \src{CDockable} will change the visibility. If possible, the location of a \src{CDockable} will remembered and reused. \item Adding a \src{CDockable} to a station makes the \src{CDockable} visible. This may happen for example if using a \src{CGrid} (see chapter \ref{sec:location}). \item The user may close a dockable by clicking onto a special close-button. Clients may call \src{setCloseable} to allow or deny a user closing the dockable. \end{itemize} diff --git a/docking-frames-common/guide2/locations/chapter.tex b/docking-frames-common/guide2/locations/chapter.tex index 09849069..7decc681 100644 --- a/docking-frames-common/guide2/locations/chapter.tex +++ b/docking-frames-common/guide2/locations/chapter.tex @@ -148,7 +148,7 @@ \subsection{The frameworks viewpoint} \label{sec:clocationmodemanager} \item And the \src{ChangeSet} can be used to store any \src{dockable} whose properties need an update. \end{itemize} -The \src{CLocationModeManager} and its supportive classes do more: they decide which buttons to show on \src{dockable}s, e.g. whether a ``minimize'' button is necessary. They decide what to if the user double-clicks on a title. They decide which element to maximize (the whole stack or just a single \src{dockable}). And they offer a lot of methods to query and change the current position of \src{dockable}s. +The \src{CLocationModeManager} and its supportive classes do more: they decide which buttons to show on \src{dockable}s, e.g. whether a ``minimize'' button is necessary. They decide what to do if the user double-clicks on a title. They decide which element to maximize (the whole stack or just a single \src{dockable}). And they offer a lot of methods to query and change the current position of \src{dockable}s. -\designbox{The whole mechanism around \src{CLocationModeManager} consists of roughly 50 classes and interfaces, some of them quite small, others quite large. It was introduced in version 1.0.8 as replacement of the outdated \src{StateManager}. Compared to the old mechanism the new one is much more complex and requires considerable more code. But it is also more flexibel, e.g. adding new implementations of \src{DockStation} or handling additional extended-modes was not possible with the old mechanism. } +\designbox{The whole mechanism around \src{CLocationModeManager} consists of roughly 50 classes and interfaces, some of them quite small, others quite large. It was introduced in version 1.0.8 as replacement of the outdated \src{StateManager}. Compared to the old mechanism the new one is much more complex and requires considerable more code. But it is also more flexible, e.g. adding new implementations of \src{DockStation} or handling additional extended-modes was not possible with the old mechanism. } diff --git a/docking-frames-core/changes.txt b/docking-frames-core/changes.txt index edb3b260..951db4c7 100644 --- a/docking-frames-core/changes.txt +++ b/docking-frames-core/changes.txt @@ -19,7 +19,7 @@ - Layout: BasicStationPaint now uses the highlight-background color of TextField to paint. That should look better with different look and feels. - Bugfix: SplitDockStation's compare-method now ensures that the station does not overlap other, smaller stations - Layout: New "Eclipse Theme", written by Janni Kovacs -- API: DockableDisplayer now tells whether a point lies inside its title or not. The drag n drop gets more flexibel this way +- API: DockableDisplayer now tells whether a point lies inside its title or not. The drag n drop gets more flexible this way - Bugfix: SecureScreenDockDialog throws NPE when closing - API: DockActionSource has now to implement Iterable - API: New DockActionSource "FilteredDockActionSource" diff --git a/docking-frames-core/changes.txt~ b/docking-frames-core/changes.txt~ index 5207a8b4..83e36e50 100644 --- a/docking-frames-core/changes.txt~ +++ b/docking-frames-core/changes.txt~ @@ -19,7 +19,7 @@ - Layout: BasicStationPaint now uses the highlight-background color of TextField to paint. That should look better with different look and feels. - Bugfix: SplitDockStation's compare-method now ensures that the station does not overlap other, smaller stations - Layout: New "Eclipse Theme", written by Janni Kovacs -- API: DockableDisplayer now tells whether a point lies inside its title or not. The drag n drop gets more flexibel this way +- API: DockableDisplayer now tells whether a point lies inside its title or not. The drag n drop gets more flexible this way - Bugfix: SecureScreenDockDialog throws NPE when closing - API: DockActionSource has now to implement Iterable - API: New DockActionSource "FilteredDockActionSource" diff --git a/docking-frames-core/guide2/dragNdrop/chapter.tex b/docking-frames-core/guide2/dragNdrop/chapter.tex index 922b4f32..197adb05 100644 --- a/docking-frames-core/guide2/dragNdrop/chapter.tex +++ b/docking-frames-core/guide2/dragNdrop/chapter.tex @@ -25,7 +25,7 @@ \subsubsection{DockElementRepresentative} \subsubsection{Remote control} Sometimes it is not possible to implement a \src{DockElementRepresentative}. Remote control of a relocator is an alternative for these cases. Remote control is realized by the \src{RemoteRelocator}. -A \src{RemoteRelocator} can be optained by calling \src{createRemote} of \linebreak \src{DockRelocator}. \src{RemoteRelocator} should be used in combination with a \linebreak \src{MouseListener} and a \src{MouseMotionListener}: +A \src{RemoteRelocator} can be obtained by calling \src{createRemote} of \linebreak \src{DockRelocator}. \src{RemoteRelocator} should be used in combination with a \linebreak \src{MouseListener} and a \src{MouseMotionListener}: \begin{itemize} \item \src{MouseListener.mousePressed} \textrightarrow \src{RemoteRelocator.init} \item \src{MouseMotionListener.mouseDragged} \textrightarrow \src{RemoteRelocator.drag} @@ -39,7 +39,7 @@ \subsubsection{Remote control} \item \src{BREAK\_CONSUMED}: the operation was canceled, the event was consumed. The caller should invoke \src{MouseEvent.consume}. \end{itemize} -\classbox{There is a second interface called \src{DirectRemoteRelocator}. Instances can be optained by calling \src{createDirectRemote} of \src{DockRelocator}. A \src{DirectRemoteRelocator} is basically the same as a \src{RemoteRelocator} but always assumes that the user pressed the correct button on the mouse. Its methods do not return a \src{Reaction} because the event would always be consumed anyway.} +\classbox{There is a second interface called \src{DirectRemoteRelocator}. Instances can be obtained by calling \src{createDirectRemote} of \src{DockRelocator}. A \src{DirectRemoteRelocator} is basically the same as a \src{RemoteRelocator} but always assumes that the user pressed the correct button on the mouse. Its methods do not return a \src{Reaction} because the event would always be consumed anyway.} \infobox{Clients can use several remote controls at the same time, they will cancel out each other if necessary. A \src{RemoteRelocator} can be used several times.}