NICE_Core/NOTES

## Wichtigere Sachen
*Für die generischen Klassen müssen wir uns etwas überlegen*. Die Implementationen müssen mit in die Header, aber wir können die Lib so "von außen" nicht benutzen, weil wir beim Kompilieren der Templates definitiv unser Buildsystem brauchen (die ganzen Makros, Libs...). Das macht eine Distribution von Binaries quasi unmöglich.

```
$ grep --include={*.h,*.tcc} -rnw ./ -e ".*def.*USELIB.*" | wc -l
185

```

Daher mein Vorschlag:

1. Wir schränken für jede betroffene Klasse die möglichen Instanzen ein und kompilieren alle davon explizit mit. Ein Beispiel habe ich in den Ordner "ignore" gepackt.
Vorteile:
	* Benutzer braucht nur noch die Header einzubinden und mit nice_core zu linken -> er muss nice_core nicht kompilieren, sondern kann einfach Binaries und Header installieren.
	* Je nach Lizenzen können wir einige Libraries statisch reinlinken, dabei fallen die nicht benutzten Funktionen raus und die Benutzer muss nicht einmal die sos der Abhängigkeiten installieren.
	* Wenn wir in der Implementierung eine weitere Abhängigkeit einbauen, machen wir dem Benutzer seinen Buildprozess nicht kaputt.
Nachteile:
	* Für Containertypen eher unbrauchbar.
	* Speicher?

## Buildsystem
-- WITH_QT OFF verhindert nicht das Kompilieren von libimagedisplay, die hängt aber von Qt ab.
?? NICE_USELIB_QT verwenden, um in ImageDisplay.h die QT-Header auszuschließen

-- Das Verzeichnis von GLUT ist für Windows hardcoded, sollte eigentlich Umgebungsvariable nutzen. 
?? Rausnehmen

-- WITH... sind Voreinstellungen in CMakeLists
?? In Abhängigkeit der gefundenen Libs setzen

-- Die Abhängigkeiten werden in nice-core/CMakeLists.txt gesucht, aber in nice-core/core/CMakeLists.txt werden unabhängig davon die Ergebnisse der find_package()-Aufrufe benutzt.
?? Wenn nice-core ohnehin nur aus "core" besteht, reicht vielleicht auch nur eine CMakeLists.txt. Dann können wir target_link_libraries aufrufen, nachdem wir eine Abhängigkeit gefunden haben. Alternativ: Wenn jedes Projekt seine eigenen Abhängigkeiten hat, dann kann auch jedes Projekt selbst danach suchen.

## Aufräumen
-- "Filter.h is obsolete" - hängt noch sehr viel davon ab?

## Bugs
-- Konstruktor von ImageT ruft string::substr mit falschen Parametern auf, wenn der Punkt im Dateinamen fehlt.