jjls first git commit ever! (svn changes since r793)

3 files changed, 65 insertions, 48 deletions

diff --git a/doc/LaTeX/devel/0300-pvs.tex b/doc/LaTeX/devel/0300-pvs.tex
index 329e03a..92b36f7 100644
--- a/doc/LaTeX/devel/0300-pvs.tex
+++ b/doc/LaTeX/devel/0300-pvs.tex
@@ -9,7 +9,7 @@ Generelles Konzept
 \subsection{Zuordnung von Konsole und Clients}
 \input{devel/0310-service-discovery}
 
-\subsection{Überblick über Aktivitäten auf Clients}
+\section{Überblick über Aktivitäten auf Clients}
 
 \subsection{Projektion an Alle}
 \index{Projektion}
@@ -52,7 +52,7 @@ als gelesen markiert durch das Drucken auf dem Knopf \textit{'OK'}.
 \textbf{Behandlung der Nachrichten im Server}
 \\
 \\
-Chat-Nachtichten werden von Server in der Klasse 'PVSConnectionManager' mittels der Methode 'onChat' behandelt. Dort wird aus der Nachrit den Empfänger
+Chat-Nachtichten werden von Server in der Klasse \texttt{PVSConnectionManager} mittels der Methode \texttt{onChat} behandelt. Dort wird aus der Nachrit den Empfänger
 und den Absender ausglesen und die Nachricht an beide versendet. So gilt das Empfangen eine eigene Nachricht als Bestätigung, dass die Nachricht ordentlich vom Server
 behandelt und versendet wurde. Das Gestalt von solchen Nachrichten sieht folgendermaßen aus
 
@@ -60,45 +60,47 @@ behandelt und versendet wurde. Das Gestalt von solchen Nachrichten sieht folgend
  PVSMSG
 \end{center}
 \begin{center}
-\begin{tabular}{l | l | p{4cm} | p{4cm}}
+\begin{tabular}{|l | p{3cm} | p{3cm} | p{3cm}|}
 \hline
 Type & Ident & Msg & sndID\\
 \hline
-PVSMESSAGE & <Username des Empfängers> & <Username des Absenders>:<Die eigentliche nachrich> & <Vom server zugewissene ID des Absenders>\\
+\texttt{PVSMESSAGE} & \texttt{<Username des Empfängers>} & \texttt{<<Username des Absenders>:<Die eigentliche nachrich>} & \texttt{<<Vom server zugewissene ID des Absenders>}\\
 \end{tabular}
 \end{center}
 
-Informationsnachrichten werden ausschließlich vom PVSManager versendet.Dies geschiet in der Klasse 'ConnectionList' mittels der Methode 'on\_Message'.
+Informationsnachrichten werden ausschließlich vom PVSManager versendet.Dies geschiet in der Klasse \texttt{ConnectionList} mittels der Methode \texttt{on\_Message}.
 
 \begin{center}
  PVSMSG
 \end{center}
 \begin{center}
-\begin{tabular}{l | l | p{4cm} | p{4cm}}
+\begin{tabular}{|l | l | p{6cm} | p{6cm}}
 \hline
 Type & Ident & Msg\\
 \hline
-PVSMESSAGE & BROADCAST & <Die eigentliche nachrich> \\
+\texttt{PVSMESSAGE} & \texttt{BROADCAST} & \texttt{<Die eigentliche nachrich>} \\
 \end{tabular}
 \end{center}
 
-Informationnachrichten können außerdem einen oder mehrere Clients sperren, wenn sie den Ident 'LOCKSTATION' enthalten. Sobald ein Client die Nachricht empfängt,
+Informationnachrichten können außerdem einen oder mehrere Clients sperren, wenn sie den Ident \texttt{LOCKSTATION} enthalten. Sobald ein Client die Nachricht empfängt,
 wird diese auf dem Bilschirm angezeigt und 10 Sekunden später wird der Client gesperrt.
 
 Abgesehen von der  Behandlung der Nachrichten muss sich der Server darum kümmern, dass jeder verbunde Client über alle nötige Informationionen verfügt damit er
 Nachrichten mit andren Clients austauschen kann. Dies wird folgendermaßen erledigt:
 \begin{itemize}
- \item \textbf{Einfügen eines Clients:} um die Verwaltung von Clients kümmert sich die Klasse 'PVSConnectionManager', in der die Methode 'onClientNew' für das Einfügen
+ \item \textbf{Einfügen eines Clients:} um die Verwaltung von Clients kümmert sich die Klasse \texttt{PVSConnectionManager}, in der die Methode \texttt{onClientNew} für das Einfügen
 von neuen Clients zuständigt ist. Sowald ein neuer Client in der Client-Liste des Servers eingefügt wird, wird an ihn die Liste aller im Server bereits angemeldete
-Clients geschickt. Dazu dient die Methode 'sendEventToClients'.
+Clients geschickt. Dazu dient die Methode \texttt{sendEventToClients}.
 
 Bis hier ist der neue Client noch unbekannt für den Rest der Nutzer. Der neuer Client wird erst bekannt gegeben sobald er vom Server einen Benutzername
 zugewissen bekommen hat. Da es sein kann, dass den Name, mit dem der neue Client sich beim Server anmelden wollte,
-bereits vergeben ist und muss unter Umständen verändert werden. Diese Zuweisung findet in der Methode  'onLoginUsername' statt,
-wo nicht nur alle andere Clients sondern auch der neue Client darüber informiert werden. Auch hier kümmert sich die Methoder 'sendEventToClients'
+bereits vergeben ist und muss unter Umständen verändert werden. Diese Zuweisung findet in der Methode  \texttt{onLoginUsername} statt,
+wo nicht nur alle andere Clients sondern auch der neue Client darüber informiert werden. Auch hier kümmert sich die Methoder \texttt{sendEventToClients}
 ums Vesenden der entsprechenden Informationen.
 
- \item \textbf{Entfernen eines Clients:} das Entfernen von Clients wird von der Methode 'onClientRemove' erledigt, wo analog wie
+ \item \textbf{Entfernen eines Clients:} das Entfernen von Clients wird von der Methode
+\\
+\texttt{onClientRemove} erledigt, wo analog wie
 Oben alle Clients darüber informiert werden. 
 \end{itemize}
 
@@ -108,26 +110,26 @@ Für dei Übermittlung solche Informationen werden Nachrichten mit folgenden Ges
  PVSMSG
 \end{center}
 \begin{center}
-\begin{tabular}{l | l | p{4cm} | p{4cm}}
+\begin{tabular}{|l | l | p{6cm} |}
 \hline
 Type & Ident & Msg\\
 \hline
-PVSMESSAGE & <Befehl> & <Benutzername>:<IP-Adresse> \\
+\texttt{PVSMESSAGE} & \texttt{<Befehl>} & \texttt{<Benutzername>:<IP-Adresse>} \\
 \end{tabular}
 \end{center}
 
 Es gibt drei unterschiedliche Befehle, die welche Änderung in der localen Client-Liste der Clients vorgenommen werden soll angeben.
 \begin{enumerate}
- \item 'clientToAdd'
-\item 'clientToRemove'
-\item 'assignedName'
+ \item \texttt{clientToAdd}
+\item \texttt{clientToRemove}
+\item \texttt{assignedName}
 \end{enumerate}
 
 Wie es bei Servern gewöhnt ist, werden alle relevante Ereignisse in Log-Dateien protokolliert. Ereignisse werden im Chat-Log mit folgendem
 Befehl eingetragen
 
 \begin{center}
-'ConsoleLog writeChat(<Beschreibung des Ereignisses>)'
+\texttt{ConsoleLog writeChat(<Beschreibung des Ereignisses>)}
 \end{center}
 
 \textbf{Chat-Interface der Steuerkonsole}
@@ -135,28 +137,28 @@ Befehl eingetragen
 \\
 So wie alle Clients ist der PVSManager auch ein Teilnehmer im Chat. Der PVSManager steht wie alle andere Teilnehmer auch in der Nutzer-Liste
 jedes Chat-Fenster und kann ebenfalls über private Nachrichten direkt angesprochen werden. Die Arbeitsweise dieser Chat-Interface ist sehr simple.
-Da sie sich im Server befindet, müssen einfach alle Ereignise (Nachrichten senden ist die einzige Ausnahme) von der Klasse 'PVSConnectionManager'
-an die Klasse 'MainWindow' weitergegeben werden. Dies kümmert sich darum, alle Informationen zu verarbeiten und diesein der Chat-Fenster der
+Da sie sich im Server befindet, müssen einfach alle Ereignise (Nachrichten senden ist die einzige Ausnahme) von der Klasse \texttt{PVSConnectionManager}
+an die Klasse \texttt{MainWindow} weitergegeben werden. Dies kümmert sich darum, alle Informationen zu verarbeiten und diesein der Chat-Fenster der
 Steuerkonsole anzuzeigen.
 
-Folgende Methoden der Klasse 'MainWindow' ermöglichen das Anzeigen einer empfangenen Nachricht im Chat-Fenster der Steuerkonsole und Änderungen (Clients einfügen
+Folgende Methoden der Klasse \texttt{MainWindow} ermöglichen das Anzeigen einer empfangenen Nachricht im Chat-Fenster der Steuerkonsole und Änderungen (Clients einfügen
 und entfernen) in der sowohl im Chat-Fenster als auch in der Steuerkonsole angezeigten Client-Liste.
 \\
 \\
-'receiveChatMsg(<Absender>, <Empfänger>, <Nachricht>)'
+\texttt{receiveChatMsg(<Absender>, <Empfänger>, <Nachricht>)}
 \\
-'removeConnection(*pvsClient)'
+\texttt{removeConnection(*pvsClient)}
 \\
-'addConnection(*pvsClient)'
+\texttt{addConnection(*pvsClient)}
 \\
 \\
-Alle diese Methoden werden im Gegensatz von der Methode 'sendChatMsg(PVSMsg myMsg)' von der Klasse 'PVSConnectionManager' aus ausgeführt. Da alle durchs
+Alle diese Methoden werden im Gegensatz von der Methode \texttt{sendChatMsg(PVSMsg myMsg)} von der Klasse \texttt{PVSConnectionManager} aus ausgeführt. Da alle durchs
 Netz empfangene Nachrichten müssen an die GUI-Weitergegeben werden. Beim Versenden von Nachrichten funktioniert es genau umgekehrt. Die Nachricht wird
-vom Nutzer in der GUI eingegeben und muss an die Klasse 'PVSConnectionManager' weitergeleitet werden, damit diese ins Netz gesendet wird. Darum kümmert
-sich die Methode in der Klasse 'MainWindow'
+vom Nutzer in der GUI eingegeben und muss an die Klasse \texttt{PVSConnectionManager} weitergeleitet werden, damit diese ins Netz gesendet wird. Darum kümmert
+sich die Methode in der Klasse \texttt{MainWindow}.
 \\
 \\
-'MainWindow::sendChatMsg(PVSMsg myMsg)'
+\texttt{MainWindow::sendChatMsg(PVSMsg myMsg)}
 \\
 \\
 \textbf{Chat-Clients}
@@ -166,11 +168,11 @@ So weit haben wir die Funtionsweisen des Servers im Bezug auf dem Chat kennengel
 Nun wird erläutert wie die einzelnen Clients die Nachrichten bearbeiten.
 \\
 \\
-Auf der Client-Seite in der Klasse 'PVSConnectionServer' werden alle Nachrichten des PVS-Protokolls empfangen und gefiltert (Siehe Methode 'handleClientMsg').
-Nachrichten mit dem Ident 'PVSMESSAGE' werden durch den Dispatcher direkt an die Klasse 'PVSChatClient' weitergeleitet, wo die Methode 'receive' feststellen wird,
+Auf der Client-Seite in der Klasse \texttt{PVSConnectionServer} werden alle Nachrichten des PVS-Protokolls empfangen und gefiltert (Siehe Methode \texttt{handleClientMsg}).
+Nachrichten mit dem Ident \texttt{PVSMESSAGE} werden durch den Dispatcher direkt an die Klasse \texttt{PVSChatClient} weitergeleitet, wo die Methode \texttt{receive} feststellen wird,
 ob es sich dabei um eine Gespräch-Nachricht oder eine Befehl-Nachricht handelt. Um es feststellen zu können, wird aus der empfangenen Nachricht ein PVSChatMsg-Objekt
-erzeugt (siehe Konstruktor 'PVSChatMsg::PVSChatMsg(PVSMsg pvsMsg)') und mittels der Methode 'isCommand' erfährt man ob es sich um einen Befehl handelt oder nicht.
-Falls ja leitet der Dispatche die Nachricht an die Stelle 'PVS::UpdateChatClients' sonst an die Stelle 'PVS::chat\_receive', wo die Änderungen in der Client-Liste
+erzeugt (siehe Konstruktor) und mittels der Methode \texttt{isCommand} erfährt man ob es sich um einen Befehl handelt oder nicht.
+Falls ja leitet der Dispatche die Nachricht an die Stelle \texttt{PVS::UpdateChatClients} sonst an die Stelle \texttt{PVS::chat\_receive}, wo die Änderungen in der Client-Liste
 vorgenommen werden oder die Gespräch-Nachricht der GUI abgegeben wird.
 
 
@@ -182,16 +184,17 @@ vorgenommen werden oder die Gespräch-Nachricht der GUI abgegeben wird.
 Im Zuge der Entwicklung des PVS wurde ein sehr einfaches Messagingprotokoll entwickelt.
 Die Nachrichten bzw. Messages bestehen dabei aus Header, Nachrichtentyp, Ident und dem eigentlichen Nachrichtentext. Die einzelnen Nachrichtenteile, welche bis auf den Header selbst definiert werden können, werden verknüpft und versendet. Es sind schon Nachrichtentypen vordefiniert, welche sich nur durch unterschiedliche Dispatcher unterscheiden.
 Bereits vorhandene Typen sind COMMAND, LOGIN, MESSAGE und UNKNOWN. Die Dispatcher (\_commandDispatcher, \_loginDispatcher und \_chatDispatcher) befinden sich im Client in der Klasse \texttt{ServerConnection}, in der Steuerkonsole in der Klasse \texttt{ClientConnection} bzw. \texttt{ListenServer}. Ein Ident wie z.B. Username, Befehl oder Beschreibung des Nachrichteninhalts dient zur Unterscheidung verschiedener Nachrichten mit demselben Nachrichtentyp, wobei die Nachricht dann den dem Ident entsprechenden Nachrichtentext enthält.
-Um eine Funktion zur Behandlung einer bestimmten Nachricht zu definieren, wird diese Funktion als Handler mit dem entsprechenden Dispatcher verknüpft. Im PVS-Client beispielsweise befindet sich der Dispatcher für Nachrichten vom Typ Command in der Klasse \texttt{pvsServerConnection}, daher wird in der Klasse \texttt{pvs} die Funktion \verb|void PVS::onCommand(PVSMsg cmdMessage)| wie folgt als Handler registriert: \verb|_pvsServerConnection->addCommandHandler("*", this, &PVS::onCommand)|. Erhält nun der Client eine Nachricht vom Typ COMMAND, so wird die Funktion onCommand mit dem entsprechenden Nachrichtenobjekt aufgerufen. Auf die eigentliche Nachricht kann dann über die Methoden \texttt{getIdent()} und \texttt{getMessage()} des Objektes zugegriffen werden. 
+Um eine Funktion zur Behandlung einer bestimmten Nachricht zu definieren, wird diese Funktion als Handler mit dem entsprechenden Dispatcher verknüpft. Im PVS-Client beispielsweise befindet sich der Dispatcher für Nachrichten vom Typ Command in der Klasse \texttt{pvsServerConnection}, daher wird in der Klasse \texttt{pvs} die Funktion \texttt{void PVS::onCommand(PVSMsg cmdMessage)} wie folgt als Handler registriert: 
+\texttt{\_pvsServerConnection->addCommandHandler("*", this, \&PVS::onCommand)}. Erhält nun der Client eine Nachricht vom Typ COMMAND, so wird die Funktion onCommand mit dem entsprechenden Nachrichtenobjekt aufgerufen. Auf die eigentliche Nachricht kann dann über die Methoden \texttt{getIdent()} und \texttt{getMessage()} des Objektes zugegriffen werden. 
 
 \subsection{PVS-Messages}
 \index{Message!PVS} \index{Message}
-Im Folgenden sind die Messages, die zwischen den einzelnen PVS Komponenenten ausgetauscht werden, aufgelistet.
+In Tabelle \ref{tab:messagelist} sind die Messages, die zwischen den einzelnen PVS Komponenenten ausgetauscht werden, aufgelistet.
 Der Nachrichtentyp gibt dabei an, welcher Dispatcher die Nachricht behandelt. 
 Der Ident einer Nachricht wird zur Verarbeitung einer empfangenen Nachricht in der aufzurufenden Funktion benötigt (Unterscheidung von anderen Nachrichten gleichen Typs).
 
+\begin{table}
 \begin{center}
-\small
 \begin{tabular}{l | l | p{2cm} | p{4cm}}
 \label{pvs-msg-liste}
 Nachrichtentyp & Nachrichten Ident & Inhalt & Beschreibung \\
@@ -204,7 +207,7 @@ PVSCOMMAND & UNLOCKSTATION &  & \\
 PVSLOGIN & USERNAME & username & Client Benutzername \\
 PVSLOGIN & PASSWORD & password & Serverpasswort \\
 PVSLOGIN & ID & id & \\
-PVSLOGIN & FAILED & "`Wrong Password"' & Wird bei falschem Passwort gesendet \\   "`
+PVSLOGIN & FAILED & "`Wrong Password"' & Wird bei falschem Passwort gesendet \\ 
 PVSCOMMAND & PORT & port & \\
 PVSCOMMAND & PASSWORD & password & VNC Passwort\\
 PVSCOMMAND & RWPASSWORD & rwpassword & Passwort für den Zugriff auf die Tastatur und Maus \\
@@ -219,4 +222,6 @@ PVSMESSAGE & clientToRemove & & Client entfernen (Chat)\\
 PVSMESSAGE & assignedName & & Festgelegter Name (Chat)\\
 \end{tabular}
 \end{center}
-
+\caption{Liste der PVS Messages}
+\label{tab:messagelist}
+\end{table} 
diff --git a/doc/LaTeX/devel/0400-pvs-console.tex b/doc/LaTeX/devel/0400-pvs-console.tex
index 495f52a..d9b1ca0 100644
--- a/doc/LaTeX/devel/0400-pvs-console.tex
+++ b/doc/LaTeX/devel/0400-pvs-console.tex
@@ -176,6 +176,6 @@ Soll ein Client als Ziel zu einer existierenden Projektion hinzugefügt werden,
 Zusätzlich zu den Verbindungsdaten werden Qualitätsoptionen zu der gesendeten Nachricht hinzugefügt. Die Qualitätsoption ist ein Integerwert 0,1 oder 2 wobei 0 der besten Qualität, 2 der schlechtesten Qualität entspricht. Dieser Wert wird an den Zielclient einer Projektion gesendet, welcher die Qualitätseinstellungen des VNC-Viewers entsprechend anpasst. Aktuell wird die Qualität immer auf 0 gesetzt, da noch die Einstellungsmöglichkeiten in der GUI fehlen.
 \subsection{Remote Help}
 
-Remote Help funktioniert analog zur Projektion, jedoch ist hier zu gewährleisten, dass jeweils nur ein Quellclient und ein Zielclient ausgewählt werden, da es nicht sinnvoll ist, Tastatur und Maus eines Clients von mehreren anderen Clients aus zu steuern. Anstelle des Passworts wird das RW-Passwort des Clients verwendet. Die Möglichkeit, die Maus und die Tastatur eines Clients zu steuern, ist mit dem verwendeten VNC-Server schon gegeben, für die Steuerkonsole ändert sich hier nichts, lediglich der VNC Viewer muss die Tastatureingaben und die Mausbewegung an den VNC Server weitergeben (siehe hierzu auch \ref{}.
+Remote Help funktioniert analog zur Projektion, jedoch ist hier zu gewährleisten, dass jeweils nur ein Quellclient und ein Zielclient ausgewählt werden, da es nicht sinnvoll ist, Tastatur und Maus eines Clients von mehreren anderen Clients aus zu steuern. Anstelle des Passworts wird das RW-Passwort des Clients verwendet. Die Möglichkeit, die Maus und die Tastatur eines Clients zu steuern, ist mit dem verwendeten VNC-Server schon gegeben, für die Steuerkonsole ändert sich hier nichts, lediglich der VNC Viewer muss die Tastatureingaben und die Mausbewegung an den VNC Server weitergeben (siehe hierzu auch \ref{pvsclient-remotehelp} Tastatur und Maussteuerung).
  
 
diff --git a/doc/LaTeX/devel/0500-pvs-client.tex b/doc/LaTeX/devel/0500-pvs-client.tex
index 9c0b572..bbca766 100644
--- a/doc/LaTeX/devel/0500-pvs-client.tex
+++ b/doc/LaTeX/devel/0500-pvs-client.tex
@@ -113,21 +113,23 @@ Es gibt zwei Arten von VNC Servern. Server, die eine laufende Sitzung bzw. ein v
 Motivation für den eigentlichen Vergleich ist die Integration mancher VNC Server in die Desktopumgebung. Hier müsste der x11vnc nicht extra installiert werden. Wichtig für den Einsatz im PVS ist vor allem die Unterstützung von Shared Modus, d.h. mehrere VNC Viewer können sich gleichzeitig mit dem VNC Server verbinden, und Forever Modus, d.h. der VNC Server wird nicht nach Trennung des letzten Clients beendet. Sicherheitsoptionen wie die Vergabe von Passwörtern und die Unterscheidung von RW und Viewonly Modus sind ebenso nicht zu vernachlässigen.
 
 \paragraph{Vino}
+\begin{sloppypar}
 ~\\
 Vino ist der VNC Server der Gnome Desktopumgebung.
 Er wird standardmäßig über die graphische Oberfläche \textbf{vino-preferences} konfiguriert. Über die Kommandozeile ist Vino entweder über \textbf{gconftool-2} oder über direktes editieren der Datei \\ 
 \textit{\~{}/.gconf/desktop/gnome/remote\_access/\%gconf.xml} konfigurierbar. 
 Parameter können nicht übergeben werden, was die Verwendbarkeit im PVS einschränkt.
-Vino benutzt standardmäßig den Port 5900, um auf eingehende Verbindungen zu warten. Dieser Port kann nur durch \\
-\small \texttt{gconftool-2 -s -t int /desktop/gnome/remote\_access/alternative\_port <portnumber>} bzw. das Einfügen von z.B. \\
-\small \verb|<entry name="alternative_port" mtime="1259858032" type="int" value="<portnumber>"/>| 
-in die entsprechende \%gconf.xml Datei geändert werden. Hierbei ist zu beachten, dass nicht überprüft wird, ob der entsprechende Port schon belegt ist. Dementsprechend wird auch kein anderer freier Port gewählt. %TODO Formulierung. 
+Vino benutzt standardmäßig den Port 5900, um auf eingehende Verbindungen zu warten. Dieser Port kann nur durch
+\texttt{gconftool-2 -s -t int \/desktop/gnome/remote\_access/alternative\_port <portnumber>} bzw. das Einfügen von z.B.
+\texttt{<entry name=``alternative\_port'' mtime=``1259858032'' type= ``int'' value=``<portnumber>''/>}
+in die entsprechende \%gconf.xml Datei geändert werden. Hierbei ist zu beachten, dass nicht überprüft wird, ob der entsprechende Port schon belegt ist. Dementsprechend wird auch kein anderer freier Port gewählt.
 Außerdem wird eine Änderung des Ports erst nach dem Neustart der grafischen Oberfläche aktiv.
 Vino unterstützt die Vergabe eines Passworts, welches base64 kodiert in der gconf Datei abgelegt wird. Ebenso kann man den Zugriff auf den Viewonly Modus beschränken. Unterschiedliche Passwörter für den RW Modus und den Viewonly Modus können jedoch nicht vergeben werden. Der Shared und Forever Modus sind standardmäßig aktiv.
+\end{sloppypar}
 
 \paragraph{Krfb}
 ~\\
-Krfb ist das Pendant zu Vino der KDE Desktopumgebung und kann entweder über eine Konfigurationsdatei oder über die grafische Oberfläche konfiguriert werden. Es kann entweder das Einladungssystem verwendet werden, bei dem eine Einladung mit einem Einmalpasswort generiert wird, oder man erlaubt uneingeladene Verbindungen und vergibt ein eigenes Passwort. Um Krfb über eine Konfigurationsdatei mit einem selbstgewählten Passwort für uneingeladene Verbindungen zu konfigurieren, erstellt man die Datei wie in \ref{pvs-client-krfbconfig} angegeben und übergibt sie an krfb mit \texttt{krfb --config <Pfad> } bzw überschreibt oder bearbeitet die eigentliche Konfigurationsdatei in \textit{~/.kde/share/config/krfbrc}.
+Krfb ist das Pendant zu Vino der KDE Desktopumgebung und kann entweder über eine Konfigurationsdatei oder über die grafische Oberfläche konfiguriert werden. Es kann entweder das Einladungssystem verwendet werden, bei dem eine Einladung mit einem Einmalpasswort generiert wird, oder man erlaubt uneingeladene Verbindungen und vergibt ein eigenes Passwort. Um Krfb über eine Konfigurationsdatei mit einem selbstgewählten Passwort für uneingeladene Verbindungen zu konfigurieren, erstellt man die Datei wie im folgenden angegeben und übergibt sie an krfb mit \texttt{krfb --config <Pfad> } bzw überschreibt oder bearbeitet die eigentliche Konfigurationsdatei in \textit{~/.kde/share/config/krfbrc}.
 %\label{pvs-client-krfbconfig}
 \begin{verbatim}
 [Security]
@@ -190,8 +192,11 @@ Um einen Mehrfachstart des VNC Servers zu verhindern, wird zunächst immer ein \
 Der VNC Viewer ist, wie in der \ref{pvsclient-datenstrom} Darstellung von VNC-Datenströmen beschrieben, implementiert.
 Die direkte Integration des Viewers im Gegensatz zum Einsatz eines externen VNC Servers bietet sich hier wegen der Integrationsmöglichkeiten in die GUI an (der VNC-Server ist GUI unabhängig). Jedoch muss der VNC-Viewer zur Unterstützung des RW-Modus des VNC-Servers noch verändert werden. 
 \subsection{Tastatur und Maussteuerung}
-Um die Maus- und Tastatureingaben an den VNC-Server weiterzuleiten, müssen zunächst die Eingaben in der Klasse \texttt{ClientVNCViewer} abgefangen und verarbeitet werden. Dies kann durch Überschreiben der geerbten Methode \texttt{event} erreicht werden \verb|bool ClientVNCViewer::event(QEvent *event)|. Hier kann durch \verb|event->type()| der Typ des Events herausgefunden werden.
+\label{pvsclient-remotehelp}
+\begin{sloppypar}
+Um die Maus- und Tastatureingaben an den VNC-Server weiterzuleiten, müssen zunächst die Eingaben in der Klasse \texttt{ClientVNCViewer} abgefangen und verarbeitet werden. Dies kann durch Überschreiben der geerbten Methode \texttt{event} erreicht werden \texttt{bool ClientVNCViewer::event(QEvent *event)}. Hier kann durch \texttt{event->type()} der Typ des Events herausgefunden werden.
 Zu behandelnde Eventtypen sind: 
+\end{sloppypar}
 
 \begin{itemize}
 \item QEvent:KeyPress - Eine Taste wurde gedrückt
@@ -215,17 +220,24 @@ Werte sind dabei:
 	\item 0xfd = mittlere Maustaste losgelassen
 	\item 0xfb = rechte Maustaste losgelassen
 \end{itemize}
-\texttt{KeyEvents} bestehen aus einem hexadezimalen Wert, der die Taste repräsentiert, und True oder False je nachdem, ob die Taste gedrückt wurde oder nicht. Die hexadezimalen Werte entsprechen den Werten in einem X Window System und können in der Headerdatei \texttt{<X11/keysymdef.h>} nachgeschlagen werden (siehe hierzu auch \url{http://www.realvnc.com/docs/rfbproto.pdf} - RFB Protokollspezifikation, Abschnitt KeyEvent). Beim Leeren der Queue werden die Methoden der rfbclient Klasse der libvnc Bibliothek \verb|SendPointerEvent(cl, _x, _y, _buttonMask)| und \verb|SendKeyEvent(cl, _key, _pressed)| mit den entsprechenden Werten aufgerufen (cl entspricht dabei einem Pointer auf die eigentliche rfbClient Instanz).
+\begin{sloppypar}
+\texttt{KeyEvents} bestehen aus einem hexadezimalen Wert, der die Taste repräsentiert, und True oder False je nachdem, ob die Taste gedrückt wurde oder nicht. Die hexadezimalen Werte entsprechen den Werten in einem X Window System und können in der Headerdatei \texttt{<X11/keysymdef.h>} nachgeschlagen werden (siehe hierzu auch \url{http://www.realvnc.com/docs/rfbproto.pdf} - RFB Protokollspezifikation, Abschnitt KeyEvent). Beim Leeren der Queue werden die Methoden der rfbclient Klasse der libvnc Bibliothek \texttt{SendPointerEvent(cl, \_x, \_y, \_buttonMask)} und \texttt{SendKeyEvent(cl, \_key, \_pressed)} mit den entsprechenden Werten aufgerufen (cl entspricht dabei einem Pointer auf die eigentliche rfbClient Instanz).
+\end{sloppypar}
 
 \section{Signalbehandlung}
 
+\begin{sloppypar}
 Um zu gewährleisten, dass bei einer Terminierung des PVS-Clients auch der gegebenenfalls gestartete VNC-Server gestoppt wird, werden Sigterm, Sighup, Sigquit und Sigint Signale abgefangen und weiterbehandelt.
 Um die Signale behandeln zu können, muss die C Bibliothek \texttt{signals.h} eingebunden werden und ein sigaction Objekt erstellt werden. Das Feld sa\_handler des sigaction Objektes gibt dabei die aufzurufende Funktion an (Pointer auf die Funktion). Diese Funktion (in der Klasse \texttt{pvs} die Funktion \texttt{signalHandler}) muss dabei vom Typ void sein und die Signalnummer als Parameter erwarten (\texttt{void PVS::signalHandler(int signal)}).
+\end{sloppypar}
+
 \begin{verbatim}
  struct sigaction act;
  act.sa_handler = &PVS::signalHandler;
 \end{verbatim} 
 
-Um Signale abfangen zu können, muss nun noch das sigaction Objekt durch \verb|sigaction(SIGTERM, &act, 0)| mit den entsprechenden Signalen (hier SIGTERM) verknüpft werden (muss für alle zu behandelnde Signale durchgeführt werden).
+\begin{sloppypar}
+Um Signale abfangen zu können, muss nun noch das sigaction Objekt durch \texttt{sigaction(SIGTERM, \&act, 0)} mit den entsprechenden Signalen (hier SIGTERM) verknüpft werden (muss für alle zu behandelnde Signale durchgeführt werden).
 Danach wird, sobald ein entsprechendes Signal erhalten wird, die Funktion aufgerufen und die Signalnummer übergeben. 
-Für alle Signale kann die gleiche Funktion aufgerufen werden, hier kann die Unterscheidung dann mittels der in \texttt{signal.h} vorhandenen Konstanten SIGHUP, SIGTERM, SIGQUIT usw. erfolgen. Zu beachten ist hierbei, dass ein SIGKILL nicht abgefangen werden kann.
\ No newline at end of file
+Für alle Signale kann die gleiche Funktion aufgerufen werden, hier kann die Unterscheidung dann mittels der in \texttt{signal.h} vorhandenen Konstanten SIGHUP, SIGTERM, SIGQUIT usw. erfolgen. Zu beachten ist hierbei, dass ein SIGKILL nicht abgefangen werden kann.
+\end{sloppypar}
\ No newline at end of file