kurzer Merker, wie manche Dinge strukturiert sind (muss nicht stimmen,
knnte ja veraltet sein und ich habs nicht gewartet...)
----------------------------------------------------------------------

  (int brennGesamtStatus) und der gesamte, "begleitete" Brennablauf:
  ------------------------------------------------------------------
  zur ersten Aktion (image simulation) wird brennGesamtStatus auf 1
  gesetzt, Slot beim Beenden ist natrlich untersucheMkisofsAusgabe.
  Dieses startet bei (brennGesamtStatus == 1) die wirkliche
  Imageerstellung und setzt brennGesamtStatus auf 2. Deren Ende-Slot 
  ist prozessEnde, was wieder bei brennGesamtStatus was besonderes
  macht, nmlich wieder abfragt, ob's weitergehen soll.
  Es wird brennGesamtStatus auf Null gesetzt und
  evtl. startBrennProzess aufgerufen.

  Diese Abfrage, ob und was bei den Slots gemacht werden soll, ist
  aber nicht in den Slotfunktionen selbst, sondern in burnCD_guided()
  untergebracht.




  Aufrufreihenfolge bei 'nem Drop:
  --------------------------------
     void Edit::DDDirektCB(KDNDDropZone* _dropzone)  ist der Qt-Slot
     void Edit::dropAktion(string dropped)
     void Edit::addedDrop(string src, string dst)
   Wenn aus dem eingebauten SimpleFileManager die Aktion kommt, wird
   DDDirektCB bersprungen


  virtuelle Verzeichnisse ohne Fllung
  ------------------------------------
  Wenn ein "virtuelles Verzeichnis angelegt wird, ohne dass es dafr eine "Fllung"
  gibt, gibt man als "src" "dummydir" an. 


 Aufrufzusammenhang bei "CreateImage", "CreateScript" und "BurnCDnow":
 ---------------------------------------------------------------------
  - createScript: createFinalScript
  - BurnCDnow: createFinalScript und dann das Script ausfhren.
  - createImage: createImageScript und dann das Script ausfhren.

  Die gesamte Entscheidung ber irgendwelche Dinge liegt also bei "int createFinalScript()".
  int createFinalScript():
   gibt nur den Brennbefehl oder durch pipe mit mkisofs den Brennbefehl.

