Merge branch 'master' of ssh://git.openslx.org/pvs

7 files changed, 131 insertions, 58 deletions

diff --git a/doc/LaTeX/bilder/processlist.png b/doc/LaTeX/bilder/processlist.png
new file mode 100644
index 0000000..c2e09af
--- /dev/null
+++ b/doc/LaTeX/bilder/processlist.png
diff --git a/doc/LaTeX/bilder/runprocess.png b/doc/LaTeX/bilder/runprocess.png
new file mode 100644
index 0000000..7b2f6bd
--- /dev/null
+++ b/doc/LaTeX/bilder/runprocess.png
diff --git a/doc/LaTeX/devel/0300-pvs.tex b/doc/LaTeX/devel/0300-pvs.tex
index 4978571..0060a63 100644
--- a/doc/LaTeX/devel/0300-pvs.tex
+++ b/doc/LaTeX/devel/0300-pvs.tex
@@ -1,10 +1,11 @@
 \chapter{Aufbau und Funktionsweise des PVS}
 \index{Aufbau} \index{Funktionsweise} \index{Konzept}
 
-Generelles Konzept
+Der Pool Video Switch ist als verteilte Netzwerkapplikation angelegt, die sich aus einer speziellen Steuerkonsole und damit gesteuerten Clients zusammensetzt. Diese kommunizieren untereinander einerseits über ein spezielles Message-Protokoll, verwenden andererseits für bestimmte Aufgaben, wie die Übertragung von Bildinhalten oder Dateien weitere Protokolle wie VNC oder Multicast-IP.
 
 \section{Einzelne Komponenten}
 \index{Komponenten}
+Die Steuerkonsole wird durch das Programm pvsmgr, das Client-Backend durch pvs und das Client-Frontend durch pvsgui repräsentiert.
 
 \subsection{Zuordnung von Konsole und Clients}
 \input{devel/0310-service-discovery}
@@ -393,6 +394,27 @@ in Präprozessorbedingungen geschehen.
 Eine API-Referenz zur libpvsinput (Stand: 4.~November~2010) findet sich im Projektwiki
 unter \url{http://lab.openslx.org/projects/pvs/wiki/RemoteKeyMouse}.
 
+\section{Prozesse fernsteuern}
+\index{Prozesse fernsteuern}
+
+\subsection{Prozesse starten}
+\index{Prozesse!starten} \index{starten} 
+Das ferngesteuerte Starten von Prozessen funktioniert durch den einfachen Versand eines PVSCOMMAND mit dem dem Ident STARTPROCESS an den Client, der Inhalt des PVSCOMMAND ist in diesem Fall ein durch den Dozenten angegebener Prozess. Der Client versucht diesen Prozess lokal zu starten.\\
+Sollte hierbei ein Fehler auftreten schickt der Client dem Manager ein PVSCOMMAND mit Ident PROCESSES, der Inhalt besteht dann aus der Nachricht START ERROR und einer Zahl, die die Art des Fehlers angibt.\\
+Die Fehlermeldung wird zusammen mit der Information über die Art des Fehlers (Fehlender Prozess/nicht genug Rechte, Crash, Timeout, Read Error, Write Error, Unbekannter Fehler) im Log angezeigt.
+
+\subsection{Prozesse beenden}
+\index{Prozesse!beenden} \index{beenden} 
+Das ferngesteuerte Beenden von Prozessen funktioniert analog zum Starten durch den Versand eines PVSCOMMAND mit dem dem Ident KILLPROCESS an den Client, hier gibt der Inhalt die lokale PID, des zu beendenden Prozesses an.\\
+Auch hier schickt der Client dem Manager bei einem Fehler ein PVSCOMMAND mit Ident PROCESSES, der Inhalt besteht dann aus der Nachricht STOP ERROR und einer Zahl, die die Art des Fehlers angibt.\\
+Auch hier wird die Fehlermeldung zusammen mit der Information über die Art des Fehlers (Fehlender Prozess/nicht genug Rechte, Crash, Timeout, Read Error, Write Error, Unbekannter Fehler) im Log angezeigt.
+
+\subsection{Prozesseliste anzeigen}
+\index{Prozesse!anzeigen} \index{anzeigen} 
+Hier sendet der Manager dem Client ein PVSCOMMAND mit Ident SHOWPROCESSES. Das PVSCOMMAND mit Ident SHOW und Inhalt clear lässt den Client seine Prozessliste leeren.\\
+Anschließend wird der Inhalt von \textit{/proc/} auf dem Client ausgelesen, ist kein Inhalt vorhanden wird ein PVSCOMMAND mit Ident PROCESSES und Nachricht SHOW ERROR gesendet. Sonst werden sämtliche Ordner in \textit{/proc/}  die nur aus Zahlen bestehen durchlaufen. Es wird die Datei \textit{status}  ausgelesen um den Namen des Prozesses und die UID des Besitzers zu erhalten. Ist die UID nicht identisch mit der UID des Client wird dieser Prozess verworfen, somit ist sichergestellt, dass nur Prozesse angezeigt werden, bei denen auch tatsächlich die Berechtigung vorhanden ist sie zu beenden. Ist dies der Fall wird außerdem noch ein Teil der Datei \textit{cmdline} ausgelesen. Der Client sendet daraufhin ein PVSCOMMAND mit Ident SHOW und Inhalt PID<\#>Name<\#>cmdline und füllt somit seinen Prozessvektor auf. Ist \textit{/proc} komplett abgearbeitet wird ein PVSCOMMAND mit Ident SHOW und Inhalt finished abgesendet, dies löst ein erneuetes lesen der Prozessliste Managerseitig aus:\\
+Hier wird zu beginn die Prozessliste des Client gelöscht und der Prozessvektor des Clients gelesen. Für jeden Eintrag der Art PID<\#>Name<\#>cmdline wird eine neue Zeile in der Prozessliste geschrieben und PID, Name und cmdline in die jeweiligen Zellen geschrieben.
+
 \section{Netzwerkkommunikation}
 \index{Netzwerkkommunikation}
 
@@ -421,6 +443,9 @@ PVSCOMMAND & UNPROJECT &  & \\
 PVSCOMMAND & LOCKSTATION &  & \\
 PVSCOMMAND & LOCKSTATION & Message & Client mit Nachricht sperren \\
 PVSCOMMAND & UNLOCKSTATION &  & \\
+PVSCOMMAND & STARTPROCESS & process & gibt Prozessnamen an der auf Client gestartet werden soll\\
+PVSCOMMAND & KILLPROCESS & PID & gibt ProzessID an von Prozess der auf Client beendet werden soll\\
+PVSCOMMAND & SHOWPROCESSES &   & weist den Client an seine Prozesse auszulesen und den Prozessvektor zu füllen\\
 PVSLOGIN & USERNAME & username & Client Benutzername \\
 PVSLOGIN & PASSWORD & password & Serverpasswort \\
 PVSLOGIN & ID & id & \\
@@ -435,14 +460,31 @@ PVSCOMMAND & VNCREQUEST &  & \\
 PVSCOMMAND & VNCSRVRESULT & result code & Der Rückgabewert des pvs-vncsrv Skripts \\
 PVSCOMMAND & MCASTFTANNOUNCE & sender transferID basename size port & Ankündigung eines Multicast-Transfer \\
 PVSCOMMAND & MCASTFTRETRY & sender transferID & Rückmeldung: Konfiguration des Multicast-Empfängers fehlgeschlagen, bitte auf anderem Port noch einmal versuchen \\
+\end{tabular}
+\end{center}
+\caption{Liste der PVS Messages}
+\label{tab:messagelist}
+\end{table} 
+
+\begin{table}
+\begin{center}
+\begin{tabular}{l | l | p{2cm} | p{4cm}}
+\label{pvs-msg-liste}
+Nachrichtentyp & Nachrichten Ident & Inhalt & Beschreibung \\
+\hline
 PVSCOMMAND & MCASTFTCONFIG & blob & Multicast-Konfiguration aus dem angehängten Binärblob neu laden \\
 PVSCOMMAND & INPUTEVENT & Base64-kodierte InputEvent-Struktur & Fernsteuerung \\
+PVSCOMMAND & PROCESSES & START ERROR errorlevel & errorlevel gibt an, welcher Fehler beim Starten eines Prozesses aufgetreten ist \\
+PVSCOMMAND & PROCESSES & STOP ERROR errorlevel & errorlevel gibt an, welcher Fehler beim Beenden eines Prozesses aufgetreten ist \\
+PVSCOMMAND & PROCESSES & SHOW ERROR & gibt an, dass beim Anzeigen der Prozessliste ein Fehler aufgetreten ist \\
+PVSCOMMAND & PROCESSES & SHOW clear & weist Client an den Prozessvektor zu leeren \\
+PVSCOMMAND & PROCESSES & SHOW finished & weist Manager an, Prozessliste neu zu füllen \\
 PVSMESSAGE & BROADCAST & MESSAGE &\\
 PVSMESSAGE & clientToAdd & & Client hinzufügen (Chat)\\
 PVSMESSAGE & clientToRemove & & Client entfernen (Chat)\\
 PVSMESSAGE & assignedName & & Festgelegter Name (Chat)\\
 \end{tabular}
 \end{center}
-\caption{Liste der PVS Messages}
+\caption{Liste der PVS Messages (Fortsetzung}
 \label{tab:messagelist}
 \end{table} 
diff --git a/doc/LaTeX/devel/0400-pvs-console.tex b/doc/LaTeX/devel/0400-pvs-console.tex
index d9b1ca0..78574b2 100644
--- a/doc/LaTeX/devel/0400-pvs-console.tex
+++ b/doc/LaTeX/devel/0400-pvs-console.tex
@@ -1,25 +1,24 @@
 \chapter{PVS-Steuerkonsole}
 
 Die Steuerkonsole ist das Hauptquartier des \textbf{Pool Video Switch}. Sie wird auf der Dozentmaschine oder
-einer geeigneten weiteren Maschine ausgef{\"u}hrt und sie ist für die Steuerung der Clients-Maschine zuständig.
+einer geeigneten weiteren Maschine ausgeführt und sie ist für die Steuerung der Clients-Maschine zuständig.
 Alleine diese Rolle der Steuerkonsole setzt schon voraus, dass das GUI so benutzerfreundlich aufgebaut werden soll,
 dass diese Aufgabe vereinfacht wird.~\\
 
-Wir werden uns in den n{\"a}chsten Punkten auf den technischen Aufbau der Steuerkonsole fokussieren.
+Wir werden uns in den nächsten Punkten auf den technischen Aufbau der Steuerkonsole fokussieren.
 Wir werden als erstes  die Auswahl von Qt zum Aufbau des Server-GUI, dann werden wir die GUI Server-Konsole vorstellen und zum
 Schluss werden wir die Beziehung Server-Client unter die Lupe nehmen.
 
 \section{pvsmgr in Qt}
-Das Server-GUI wurde erstmal in GTK/Gnome implementiert. Dank der Flexibilit{\"a}t, die von Qt erm{\"o}glicht wird, wurde die komplette
-Anwendung in Qt umgeschrieben. Qt ist ein UI Framework und ermöglicht die Implementierung von Anwendungen, die unter Linux (Unix),
-Windows, mobile und  eingebettete Systemen ausf{\"u}hrbar sind. Wir werden also den pvs-Manager(Server-GUI) komplett in Qt umschreiben und mit
-zus{\"a}tzlichen Features gestalten.
+Das Server-GUI wurde in der ersten Version in GTK/Gnome implementiert. Dank der Flexibilität, die von Qt ermöglicht wird, wurde die komplette
+Anwendung in Qt umgeschrieben. Qt ist ein User Interface Framework und ermöglicht die Implementierung von Anwendungen, die unter Linux (Unix), Windows, mobile und  eingebettete Systemen ausführbar sind.
 
 \section{GUI Server-Konsole}
 Hier sollte die Hauptsteuerung des PVS abgewickelt werden.
-\subsection{Die Architektur}
-Es wird u.a. m{\"o}glich sein, Funktionen auszuführen wie: die Frame der einzelnen Clients ansehen, ein Profil anlegen,
-Screenshot aufnehmen, ein (Un)Projektion ausf{\"u}hren, eine Nachricht an Clients verschicken, usw... Die Grundstruktur
+
+\subsection{Architektur}
+Es wird u.a. möglich sein, Funktionen auszuführen wie: die Frame der einzelnen Clients ansehen, ein Profil anlegen,
+Screenshot aufnehmen, ein (Un)Projektion ausführen, eine Nachricht an Clients verschicken, usw... Die Grundstruktur
 des pvsmgr wird in der Abbildung \ref{fig:pvsmgr} illustriert. Das Bild zeigt uns das Hauptfenster (\textit{MainWindow})
 der Anwendung und seine unterschiedlichen Komponenten:~\\ ~\\ ~\\  ~\\  ~\\ 
 \begin{figure}[h]
@@ -30,48 +29,48 @@ der Anwendung und seine unterschiedlichen Komponenten:~\\ ~\\ ~\\  ~\\  ~\\
 \end{figure}
 \textbf{MainWindow}~\\
 Die Klasse MainWindow wird vom QMainWindow abgeleitet; das ist der Parent an der Spitze der Hierachie;
-Sie zu zerst{\"o}ren, bedeutet ein automatisches
+Sie zu zerstören, bedeutet ein automatisches
 Schließen der einzelnen Komponente, also der gesammten Anwendung. Alle anderen Komponenten bauen auf ihr auf.
-Die Abbildung \ref{fig:mainwindow} zeigt ihr Abh{\"a}ngigkeitsdiagramm.
+Die Abbildung \ref{fig:mainwindow} zeigt ihr Abhängigkeitsdiagramm.
 ~\\
 Alle andere Komponenten (Klasse) der Anwendung haben die Klasse MainWindow als Parent. Qt verwaltet eine Struktur der
-Art \textit{parent-child} Beziehung, so dass wenn ein Parent zerst{\"o}rt wird, werden alle seine Kinder (\textit{child})
-automatisch mit zers{\"o}rt; Das ist der sogenannte \textit{Domino-Effekt}.
+Art \textit{parent-child} Beziehung, so dass wenn ein Parent zerstört wird, werden alle seine Kinder (\textit{child})
+automatisch mit zersört; Das ist der sogenannte \textit{Domino-Effekt}.
 ~\\
 \begin{figure}[h]
 	\centering
 		\includegraphics[width=0.80\textwidth]{bilder/mainwindow.png}
-	\caption{Abh{\"a}ngigkeitsdiagram: MainWindow}
+	\caption{Abhängigkeitsdiagram: MainWindow}
 	\label{fig:mainwindow}
 \end{figure}
-~\\
+
 
 \textbf{Menubar}~\\
-Diese Klasse enth{\"a}lt eine Liste von \textit{pull-down}-Menu und QMainWindow speichert diese im QMenuBar. Die Klasse
-wird also vom QMenuBar abgeleitet. Die gespeicherten Men{\"u}s enthalten jeweils die Menu-Items, die nichts anderes als \textit{QAction} sind.
+Diese Klasse enthält eine Liste von \textit{pull-down}-Menu und QMainWindow speichert diese im QMenuBar. Die Klasse
+wird also vom QMenuBar abgeleitet. Die gespeicherten Menüs enthalten jeweils die Menu-Items, die nichts anderes als \textit{QAction} sind.
 Beim Betätigen einer Aktion (Menü-Item) wird ein korrespondiertes \textit{SIGNAL} gesendet, wir verbinden dann dieses zu einem \textit{SLOTS},
 wie hier gezeigt wird \textit{connect(actionCreate-profile, SIGNAL(triggered()), MainWindow, SLOT(createProfile()))}; Also beim Clicken auf das Menü-Item
 "File->Profile manager" wird das Signal \textit{triggered()} gesendet, das automatisch das Slot \textit{createProfile()} aufruft. Genau dieses Prinzip
-wird auch auf die Aktionen im Toolbar angewandt. ~\\
+wird auch auf die Aktionen im Toolbar angewandt.
 
 \textbf{Toolbar}~\\
-Die Klasse wird vom QToolBatr abgeleitet und enth{\"a}lt eine Liste von Aktionen, die man unmittelbar auf die gesamten
-oder die ausgew{\"a}hlten Clients in der ConnectionList anwenden kann. ~\\  ~\\
+Die Klasse wird vom QToolBatr abgeleitet und enthält eine Liste von Aktionen, die man unmittelbar auf die gesamten
+oder die ausgewählten Clients in der ConnectionList anwenden kann. ~\\  ~\\
 
 \textbf{ConnectionList}~\\
-Sie enth{\"a}lt die Liste der verbundenen Clients. Sie ist vom QTableView abgeleitet. Die vorhandenen Clients in der Liste k{\"o}nnen
-in unterschiedlichen Bezeichnungen angezeigt werden. Es ist also m{\"o}glich die Clients unter verschiedenen Sichten anzuzeigen.
-Die Clients k{\"o}nnen mit Name, IP-Adresse oder Username angezeigt werden. Wir entnehmen also, dass das QTableView genauer gesehen
-3 Spalten enth{\"a}lt, von denen nur eins davon immer sichtbar wird. Dieses Geschehen l{\"a}sst sich ganz trivial ausführen.
- Man soll lediglich daf{\"u}r sorgen, dass wenn eine Spalte angezeigt wird, sollen die 2 anderen ausgeblendet werden.
+Sie enthält die Liste der verbundenen Clients. Sie ist vom QTableView abgeleitet. Die vorhandenen Clients in der Liste können
+in unterschiedlichen Bezeichnungen angezeigt werden. Es ist also möglich die Clients unter verschiedenen Sichten anzuzeigen.
+Die Clients können mit Name, IP-Adresse oder Username angezeigt werden. Wir entnehmen also, dass das QTableView genauer gesehen
+3 Spalten enthält, von denen nur eins davon immer sichtbar wird. Dieses Geschehen lässt sich ganz trivial ausführen.
+ Man soll lediglich dafür sorgen, dass wenn eine Spalte angezeigt wird, sollen die 2 anderen ausgeblendet werden.
 Das QTableView steht zu diesem Zweck die Methode \textit{setColumnHidden(int column, bool hidden)} zur Verfügung, wobei \textit{column}
  die betroffene Spaltenummer (die erste Spalte hat den Index 0) ist und \textit{hidden} legt dann fest, ob die Spalte
 ein-(\textit{true}) oder ausgeblendet(\textit{false}) bleiben soll. Angesichts des angewandten Selection-Model
  (\textit{QItemSelectionModel}) ist es möglich mehrere Clients (\textit{QAbstractItemView::ExtendedSelection}) aufzufassen und
-die entsprechenden verfügbaren Aktionen aus dem Tollbar oder der ContexMenu auszuf{\"u}hren.~\\
+die entsprechenden verfügbaren Aktionen aus dem Tollbar oder der ContexMenu auszuführen.~\\
 
 \textbf{ConnectionWindow}~\\
-Die Klasse ist wie der zentrale Widget der Anwendung. Sie ist vom QWidget abgeleitet und enth{\"a}lt die Frame der
+Die Klasse ist wie der zentrale Widget der Anwendung. Sie ist vom QWidget abgeleitet und enthält die Frame der
 jeweiligen verbundenen Clients. Klarerweise hat diese Komponente die MainWindow-Klasse als Parent.~\\
 
 \textbf{ConsoleLog}~\\
@@ -84,15 +83,15 @@ Die richtig konfigurierten Clients werden mit dem pvs-Server verbunden und werde
 
 \subsubsection{Clientliste-Ansicht}
 Diese Sicht ist eine Liste, die aus einem \textit{QTableview}-Object abgeleitet wird. Die Client-Liste ist definiert
-durch die ConnectionList-Klasse die Abbildung \ref{fig:connectionlist} zeigt uns die Abh{\"a}ngigkeitsdiagramm dieser Klasse.
+durch die ConnectionList-Klasse die Abbildung \ref{fig:connectionlist} zeigt uns die Abhängigkeitsdiagramm dieser Klasse.
 \begin{figure}[h]
 	\centering
 		\includegraphics[width=0.80\textwidth]{bilder/ConnectionList.png}
-	\caption{Abh{\"a}ngigkeitsdiagramm der ConnectionList-Klasse}
+	\caption{Abhängigkeitsdiagramm der ConnectionList-Klasse}
 	\label{fig:ConnectionList}
 \end{figure}
 
-Die Tabelle enth{\"a}lt 3 Spalten, von denen nur eine angezeigt werden kann. Mit Hilfe passender Tastenkombinationen
+Die Tabelle enthält 3 Spalten, von denen nur eine angezeigt werden kann. Mit Hilfe passender Tastenkombinationen
 können die anderen Spalten angezeigt werden. Die Spalten enthalten jeweils den Name der Clients, seine IP-Adresse und seinen Username. Außerdem
 haben wir hier ein Kontextmenü per Überschreibung der Methode \textit{mouseReleaseEvent(QMouseEvent * e)} aus der Mutter-Klasse (QTableView)
 zur Verfügung gestellt. Das Kontextmenü ist hier im Grunde ein Popup-Menü, das Menü-Item enthält. Diese Menü-Items sind nichts anderes als Actionen
@@ -102,7 +101,7 @@ Von der jeweiligen Clients in der ConnectionList wollen wir jetzt die entspreche
 
 \subsubsection{VNC-Ansicht}
 
-Die zweite Anzeigem{\"o}glichkeit, die vom Server angeboten wird ist die Anzeige der VNC-Verbindung zwischen
+Die zweite Anzeigemöglichkeit, die vom Server angeboten wird ist die Anzeige der VNC-Verbindung zwischen
 Client und Server. Genauer gesagt, auf dem pvsmgr kann der Dozent jeder Zeit nachvollziehen, was auf der Client-Maschine
 passiert, dies wird vom rfb (Remote Frame Buffer) ermöglicht. Zu dem jeweiligen Client wird vom Manager ein \textit{VNCClientThread()} initialisiert
 und in dieser Klasse wird der rfb-Client instanziiert. Die Klasse\textit{VNCClientThread()} wird vom QThread abgeleitet, somit wird eine kontinuierliche
@@ -114,7 +113,7 @@ Quality zu starten und danach dem Client diesen neuen Thread wieder zuzuordnen.~
 \begin{figure}[h]
 	\centering
 		\includegraphics[width=0.80\textwidth]{bilder/connectionframe.png}
-	\caption{Abh{\"a}ngigkeitsdiagramm der ConnectionFrame-Klasse}
+	\caption{Abhängigkeitsdiagramm der ConnectionFrame-Klasse}
 	\label{fig:Connectionframe}
 \end{figure}
 Die VNC-Ströme werden in der ConnectionFrame-Klasse verwaltet. Die ConnectionFrame ist vom QGroupBox abgeleitet. Die Abbildung \ref{connectionframe}
@@ -128,39 +127,37 @@ annähen, in dem wir dieser Aushandlung diese Verbindung betrachten. Allerdings
 \subsection{Client-Seite}
 
 Wir wollen davon ausgehen, dass im Subnetz, indem sich die Client-Maschine befindet, bereits ein pvsmgr gestartet wurde.
- Die Abwicklung auf dem server werden wir im n{\"a}chsten Punkt erl{\"a}utern. Nach dem Start eines Server sendet dieser eine
-Broadcast-Nachricht, die von allen verf{\"u}gbaren Client erhalten wird. Erh{\"a}lt ein Client diese Nachricht, dann weiß er,
-dass ein Server gerade am laufen ist. Anschließend f{\"u}gt der Client diesen Server in seiner Server-Liste hinzu.
+ Die Abwicklung auf dem server werden wir im nächsten Punkt erläutern. Nach dem Start eines Server sendet dieser eine
+Broadcast-Nachricht, die von allen verfügbaren Client erhalten wird. Erhält ein Client diese Nachricht, dann weiß er,
+dass ein Server gerade am laufen ist. Anschließend fügt der Client diesen Server in seiner Server-Liste hinzu.
 Wird es eine von einen anderen Server gesendetete Broadcast-Nachricht empfangen, wird ebenfalls den entsprechenden
 Server in die Server-Liste des Client hinzugenommen.
-Der Client verf{\"u}gt also {\"u}ber eine Liste von potentiellen Server, mit denen er eine PVS-Verbindung aufbauen kann, die dann schließlich
+Der Client verfügt also über eine Liste von potentiellen Server, mit denen er eine PVS-Verbindung aufbauen kann, die dann schließlich
 eine VNC-Verbindung wird und erst dann kann die Remote Frame Buffer initialisiert werden. Verläuft diese Initiliasierung erfolgreich, wird bei dem Server
 der VNC-Frame angezeigt.
-Aus seiner Server-Liste kann der Client freiwillig den Server ausw{\"a}hlen, mit dem er sich verbinden m{\"o}chte. Allerdings
+Aus seiner Server-Liste kann der Client freiwillig den Server auswählen, mit dem er sich verbinden möchte. Allerdings
 erfolgt die eigentliche Verbindung zwischen Server und Client erst, nachdem der Client das vom Dozent gesetzte Passwort
-richtig eingegeben hat. Beim Start des Server wird vom System ein zuf{\"a}lliges Passwort generiert und der Dozent soll dieses den Client
+richtig eingegeben hat. Beim Start des Server wird vom System ein zufälliges Passwort generiert und der Dozent soll dieses den Client
 im Raum bekanntgegeben, so dass ein anderer Client, der im Nebenraum steht und auch die Server-Broadcast-Nachricht erhalten hat,
-keine M{\"0}glichkeit hat, mit diesem Server eine Verbindung aufbauen zu k{\"o}nnen.
+keine M{\"0}glichkeit hat, mit diesem Server eine Verbindung aufbauen zu können.
 %Die genaue Spezifikation der Abwicklung der Verbindung zwischen und Client  und Server kann in ServAppTech und in Service-Discovery entnommen werden.
 Also nun hat ein Client das richtige Passwort eingeben und die Verbindung mit dem Server konnte erfolgreich aufgebaut werden. An dieser Stelle wollen
 wir noch betonen, dass der Dozent selbst entscheiden kann, ob ein Passwort zum Verbindungsaufbau mit dem PVS-Server vom Client aus eingegeben werden
 soll oder nicht. Dafür wird eine Checkbox  auf dem pvsmgr-GUI eingebaut, die beim Ankreuzen per SIGNAL-SLOT die Funktion
-\textit{PVSConnectionManager::getManager()->setNeedPassword(bool needed)} aufruft, wobei mit \textit{needed=TRUE} wird ein Passwort ben{\"o}tigt. \\
-Nun wollen wir erl{\"a}utern wie der Server mit einer bestehenden Verbindung umgeht.~\\
+\textit{PVSConnectionManager::getManager()->setNeedPassword(bool needed)} aufruft, wobei mit \textit{needed=TRUE} wird ein Passwort benötigt. \\
+Nun wollen wir erläutern wie der Server mit einer bestehenden Verbindung umgeht.~\\
 
 \subsection{Server-Seite}
 
-Wir hatten schon erw{\"a}hnt, dass der Server 2 Ansichtsmöglichkeiten zur Annzeige eines verbundenen Client verf{\"u}gt.
+Wir hatten schon erwähnt, dass der Server 2 Ansichtsmöglichkeiten zur Annzeige eines verbundenen Client verfügt.
 Nachdem ein Client mit dem Server eine Verbindung erfolgreich aufgebaut hat, wird fast zeitgleich erstmal der Client
 links in der Connection-Liste angezeigt und dann wird eine VNC-Verbindung zwischen Client und Server so aufgebaut, dass auf der rechten
 Seite (\textit{Connectionwindow}) das Client-Frame angezeigt werden kann. Jeder Frame wird so beschriftet,
-dass es jeder Zeit m{\"o}glich wird, aus einem Client in der Liste (links) den entsprechenden Frame (recht) anzuordnen.\\
+dass es jeder Zeit möglich wird, aus einem Client in der Liste (links) den entsprechenden Frame (recht) anzuordnen.\\
 
-Somit hat der Server einen besseren {\"U}berblick {\"u}ber die gesamten vorhandenen Verbindungen. Der Server kann also jegliche verf{\"u}gbare
- Aktion ausf{\"u}hren. Der Betreiber (der Dozent) des pvsmgr verf{\"u}gt {\"u}ber eine zweite Maschine, die an einen Beamer angeschlossen
-wird und auf dieser Maschine l{\"a}uft ein PVS-Client. Dieser Client wird als \textit{Superclient} bezeichnet
-und verf{\"u}gt dementsprechend gegen{\"u}ber anderen Clients über einen Sonderstatus. Z.B: bei einer LockAll-Aktion wird er nicht
-gesperrt und dabei muss geachtet werden, dass ein auf dem Superclient projektierter Client auch nicht gesperrt wird.\\
+Somit hat der Server einen besseren {\"U}berblick über die gesamten vorhandenen Verbindungen. Der Server kann also jegliche verfügbare
+ Aktion ausführen. Der Betreiber (der Dozent) des pvsmgr verfügt über eine zweite Maschine, die an einen Beamer angeschlossen
+wird und auf dieser Maschine läuft ein PVS-Client. Dieser Client wird als \textit{Superclient} bezeichnet und verfügt dementsprechend gegenüber anderen Clients über einen Sonderstatus. Z.B: bei einer LockAll-Aktion wird er nicht gesperrt und dabei muss geachtet werden, dass ein auf dem Superclient projektierter Client auch nicht gesperrt wird.
 
 \section{Verbindungsverwaltung und Projektion}
 
@@ -176,6 +173,4 @@ 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{pvsclient-remotehelp} Tastatur und Maussteuerung).
- 
-
+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).
\ No newline at end of file
diff --git a/doc/LaTeX/intro/0000-chapter.tex b/doc/LaTeX/intro/0000-chapter.tex
index 6b3319b..c3c5efe 100644
--- a/doc/LaTeX/intro/0000-chapter.tex
+++ b/doc/LaTeX/intro/0000-chapter.tex
@@ -2,13 +2,13 @@
 \label{einleitung}
 \index{Einleitung} \index{Video Switch} \index{Laptop} \index{VGA} \index{DVI} \index{Klassenraum} \index{Student Control Panel} \index{Idee}
 
-Video-Switches für Klassenräume sind schon seit langem auf dem Markt: Sie setzen typischerweise auf eine Hardware-Lösung, die das Verlegen von vielen Metern Kabel bei dadurch erzwungener statischer Anordnung der Rechner verlangt. Sie sind nicht nur aufgrund des Einsatzes spezieller Hardware relativ teuer, sondern unflexibel bei technischen Weiterentwicklungen: Höhere Bildschirmauflösungen oder der Wechsel vom VGA auf den DVI oder PS2 auf den USB-Stecker sind nur durch einen Komplettaustausch oder unangenehme Kompromisse zu haben. Ziemlich ungeeignet erweisen sich hardware-basierte Lösungen beim Einsatz mobiler Geräte wie Laptops. Zudem erschweren sie die Veränderung der ursprünglichen Aufstellung der Maschinen und schaffen damit ungünstige Bedingungen für neue didaktische Konzepte.
+Video-Switches für Klassenräume sind schon seit langem auf dem Markt: Sie setzen typischerweise auf eine Hardware-Lösung, die das Verlegen von vielen Metern Kabel bei dadurch erzwungener statischer Anordnung der Rechner verlangt. Sie sind nicht nur aufgrund des Einsatzes spezieller Hardware relativ teuer, sondern unflexibel bei technischen Weiterentwicklungen: Höhere Bildschirmauflösungen oder der Wechsel vom VGA- auf den DVI-Connector bzw. Display-Port oder die Ablösung von PS2 durch USB sind nur durch einen Komplettaustausch oder unangenehme Kompromisse zu haben. Ziemlich ungeeignet erweisen sich hardware-basierte Lösungen beim Einsatz mobiler Geräte wie Laptops. Generell erschweren sie die Veränderung der ursprünglichen Aufstellung der Maschinen und schaffen damit ungünstige Bedingungen für neue didaktische Konzepte.
 \begin{figure}[h]
 \center
 \includegraphics[width=11.5cm]{bilder/studentctlpanel.png}
 \caption{Student Control Panel des Edubuntu-Pakets, welches im Umfeld von Linux-Terminalservern eingesetzt werden kann.\label{uscp}}
 \end{figure}
-Neben den Hardware-basierten Varianten existieren inzwischen eine Reihe von Software-Produkten. Leider bieten sie keine optimalen Lösungen: Neben oft exorbitanten Lizenzkosten, die oft mit einem didaktisch und konzeptionell fragwürdigen Feature-Set begründet werden, orientieren sie sich an einem einzigen auf den Schulungs-PCs festinstalliertem Betriebssystem. Oft stehen sie nur für ausgewählte Microsoft-Betriebssysteme zur Verfügung und können damit nicht dem Anspruch einer breiten und allgemeinen universitären Umgebung entsprechen. Zudem kommen regelmäßige, typischerweise kostenpflichtige Produkt-Updates hinzu, denen sich nur begrenzt ausweichen läßt.
+Neben den Hardware-basierten Varianten existieren inzwischen eine Reihe von Software-Produkten. Leider bieten sie keine optimalen Lösungen: Neben typischerweise exorbitanten Lizenzkosten, die oft mit einem didaktisch und konzeptionell fragwürdigen Feature-Set begründet werden, orientieren sie sich an einem einzigen auf den Schulungs-PCs festinstalliertem Betriebssystem. Oft stehen die Produkte nur für ausgewählte Microsoft-Betriebssysteme zur Verfügung und können damit nicht dem Anspruch einer breit angelegten Umgebung entsprechen, wie sie in Universitäten, Bildungseinrichtungen aber auch durchaus in Schulen vorzufinden ist. Zudem kommen regelmäßige, typischerweise kostenpflichtige Produkt-Updates hinzu, denen sich nur begrenzt ausweichen läßt.
 
 Dem soll ein eigener Ansatz entgegengesetzt werden, der die eingangs genannten Beschränkungen aufhebt und dem Anspruch einer modernen universitären computer-gestützten Lehre entgegenkommt. Das Projekt soll stufenweise von einer einfachen Basislösung in Rückmeldung mit den Lehrenden weiterentwickelt werden. Ein Open-Source-Ansatz gewährleistet zudem eine größere Nachhaltigkeit. Selbst bei einer Projekteinstellung können andere auf den Code weiterhin zurückgreifen und damit einerseits bestehende Installationen aktualisieren und andererseits eigene Entwicklungen schneller vorantreiben.
 
diff --git a/doc/LaTeX/intro/0100-funktionen.tex b/doc/LaTeX/intro/0100-funktionen.tex
index 0dbac13..47799e4 100644
--- a/doc/LaTeX/intro/0100-funktionen.tex
+++ b/doc/LaTeX/intro/0100-funktionen.tex
@@ -10,7 +10,7 @@ In der verfügbaren Version wurden eine Reihe von Features realisiert. Hierzu zÃ
 \begin{figure}[h]
 \center
 \includegraphics[width=11.5cm]{bilder/studentctlpanel.png}
-\caption{Student Control Panel des Edubuntu-Pakets, welches im Umfeld von Linux-Terminalservern eingesetzt werden kann.\label{uscp}}
+\caption{Die Steuerkonsole des Pool Video Switches in ihrer Hauptansicht. Diese grafische Applikation sollte sinnvollerweise auf einem eigenen Desktop oder komplett eigenen Rechner laufen.\label{uscp}}
 \end{figure}
 Bei der Realisierung wurde einerseits auf die Absicherung der Steuerverbindungen und andererseits auf die Aspekte des Datenschutzes geachtet. Anders als bei vergleichbaren Produkten liegt in der Standardinstallation die Kontrolle bei den Teilnehmern.
 
diff --git a/doc/LaTeX/user/0001-chapter.tex b/doc/LaTeX/user/0001-chapter.tex
index 200ffa5..3e1c42d 100644
--- a/doc/LaTeX/user/0001-chapter.tex
+++ b/doc/LaTeX/user/0001-chapter.tex
@@ -56,7 +56,7 @@ Auf dem Bild \ref{fig:pvsdummy} kann man verbundene Clients (\textit{Nicht dummy
 befindet sich die korrespondierte IP-Adresse. Der grüne Punkt ganz rechts im Gegenteil zum dummy-Frame zeigt, dass der Client gerade Online ist.\\
 Für die Verbundene Clients besteht die Möglichkeit die VNC-Quality (HIGH, MEDIUM oder LOW) jeder Zeit einzustellen. Mit \textit{Set Password} kann der Manager ganz bequem
 festlegen, ob die Clients zur Verbindung mit dem pvsmgr ein von System generiertes Passwort eingeben müssen oder nicht. Auf dem Toolbar werden weitere Funktionen wie:
-Screeshots aufnehmen, Chat mit dem einzelnen Client starten oder alle Clients auf einem Klick zu blockieren. Das Blockieren der Clients schließt natürlich der Dozent-Rechner
+Screeshots aufnehmen, Chat mit dem einzelnen Client starten, ferngesteuert auf den markierten Clients Prozesse starten, eine Prozessliste zu öffnen in der die Prozesse sämtlicher verbundenen Clients angezeigt werden oder alle Clients auf einem Klick zu blockieren. Das Blockieren der Clients schließt natürlich der Dozent-Rechner
 aus. Der Dozent-Rechner hebt sich von einem anderer verbundenen Machine durch den Rot-Blau Zeichnen neben dem grünen Punkt hervor.
 \\
 Befindet sich die Maus über einem VNC-Frame, so ist über dem Bildschirminhalt eine Reihe von
@@ -93,8 +93,44 @@ es erscheint dann ein Menü, aus dem die gewünschte Aktion ausgewählt werden k
 {\em Vorsicht:} Die Steuerkonsole fragt vor der Ausführung einer Aktion nicht noch einmal
 nach.
 \\ \\
-Im letzten Punkt dieser Abschnitt wollen wir die vorhandenen Tastenkürzel vorstellen.
+\subsection{Remote Prozesse starten}
+\label{Prozesse starten}
+Über den Button aus der Abbildung \ref{png:Prozessestarten} kann der Dialog um Prozesse ferngesteuert zu starten geöffnet werden. Es muss mindestens ein Client ausgewählt werden, auf dem der eingegebene Prozess gestartet werden soll. Der Dialog (Abbildung \ref{png:Prozessestarten}) bietet folgende Funktionen:\\
+\begin{enumerate}
+ \item Diese Liste bietet den Dozenten die Möglichkeit sich bestimmte Prozesse abzuspeichern und bequem aufzurufen. Prozesse werden grundsätzlich nur mit Beschreibung abgespeichert, fehlt entweder die Beschreibung oder der Prozess selbst wird der Eintrag nichtmehr gespeichert.\\
+ Ein Klick auf die Liste fügt den ausgewählten Prozess in das Textfeld ein. Mit Doppelklick auf ein Feld der Liste kann dieses Element editiert werden, so sind sowohl die Beschreibung, als auch der Prozess editierbar. Um einen Eintrag zu löschen reicht es dessen Prozess oder Beschreibung zu entfernen und mit einem Klick auf Speichern zu übernehmen. Der Speichern-Button fügt automatisch eine leere Zeile an das Ende der Liste an, um weitere Priozesse abspeichern zu können.
+ \item Prozesse die in diesem Textfeld eingetragen sind werden mit einem Klick auf Start nach einer erneuten Abfrage auf dem Client gestartet, Änderungen an der Liste werden dabei gespeichert, der Dialog geschlossen. Ein Klick auf Abbrechen schließt den Dialog ohne die Prozessliste erneut zu speichern und ohne den Prozess zu starten.
+\end{enumerate}
+Schlägt das ferngesteuerte Starten fehl wird dies in den Logdateien angezeigt.
+\begin{figure}[h]
+  \centering
+    \includegraphics[scale=0.6]{bilder/runprocess.png}
+  \caption{Dialog um Prozesse ferngesteuert zu starten und zugehöriger Button links}
+  \label{png:Prozessestarten}
+\end{figure}
+
+\subsection{Remote Prozessliste anzeigen}
+\label{Prozessliste}
+Hier ein Überblick über die Prozessliste (Siehe Abbildung \ref{png:Prozessliste}). Die Prozessliste kann über die Toolbar in der PVS Steuerkonsole über den Button aus der Abbildung \ref{png:Prozessliste} angezeigt werden. 
+\begin{enumerate}
+ \item Anzeige der Tabs - hier wird für jeden verbundenen Client ein neuer Reiter erstellt, ein Klick auf den Reiter aktiviert die Anzeige für diesen Client. Die Prozessliste wird daraufhin aktualisiert.
+ \item Prozessliste - Hier werden die Prozesse des gewählten Clients angezeigt, in den Spalten stehen die ProzessID, der Name und die Commandline. Die Prozessliste wird alle 5 Sekunden aktualisiert, ausser es ist mindestens eine Zeile markiert. Es können mehrere Zeilen markiert werden, sie müssen nicht zusammenhängen.
+ \item Buttons Refresh und Stop process - mit Refresh wird die Liste aktualisiert, unabhängig davon, ob Zeilen markiert wurden. Ein Klick auf Stop process beendet die markierten Prozesse nach einer erneuten Abfrage.
+ \item Start Process - Ein eingegebener Prozess wird auf dem aktuellen Client gestartet.
+\end{enumerate}
+Mit einem Klick auf Close werden die Prozesslisten geschlossen.
+\begin{figure}[h]
+  \centering
+    \includegraphics[scale=0.5]{bilder/processlist.png}
+  \caption{Prozessliste und zugehöriger Button links}
+  \label{png:Prozessliste}
+\end{figure}
+\\
+
+
+
 
+Im letzten Punkt dieses Abschnitts wollen wir die vorhandenen Tastenkürzel vorstellen.
 \subsection{Tastenkürzel für PVS-Server}
 \label{Taste}
 Einige schlaue Tastenkombinationen sollen die Ausnutzung der PVS-Konsole erleichten.