title: Most elegant/safe/easy solution to store and edit (GUI) a directory-like tree structure?
body: <p>I've got a slightly tricky problem to solve; imagine this:</p>
  
  <p>One of my applications needs to make heavy use of scripting, so my idea was to provide the user a way to write script snippets and organize them in a directory-like tree structure. This is much like a source code directories with subdirectories and source files.</p>
  
  <p><strong>Data Classes/Storing</strong></p>
  
  <p>The first problem I come across is that I need to find a good way to store the whole tree structure (on the disk, and within the application at runtime). For this I had these ideas:</p>
  
  <ol>
  <li>Use a QObject derived class which can represent the tree using QObject's parent/child features. This way I don't have to worry about deleting those objects if they parents get deleted.</li>
  <li>Use a simple class which may contain a QList (without pointers) of children and a few properties which store the properties of each group/script.</li>
  <li>Use approach #2, but use pointers instead of static objects - this would avoid useless copying whenver I have to pass a group or part of a tree to a function, etc.</li>
  <li>Use a live backend to a SQLite (or similar) database, and query it at runtime. This would avoid loading the whole tree at once and keeping it in RAM.</li>
  <li>Use a flat file and directory structure on the file system; although I think this introduces more trouble than necessary because there is no way to store meta information about objects.</li>
  </ol>
  
  <p><strong>Editor</strong></p>
  
  <p>The next problem I come across is the fact that the user probably wants to edit the whole tree structure. He wants to click on a group or script, edit the script code and possibly Drag &amp; Drop directories and scripts around within the tree; thus changing the structure of the whole tree on the way.</p>
  
  <p>This raises the following problems:</p>
  
  <ol>
  <li>If the user closes the editor, it might be a good idea to provide him a "Do you want to save the changes?" dialog. Much like a text editor where you accidently typed something into an existing document, but you quit without saving the changes. - This would require that we edit a copy of the whole tree, and overwrite the existing tree within the application when needed.</li>
  <li>Allowing Drag &amp; Drop could be problematic...
  
  <ul>
  <li>... with the <em>storing approach #1</em>: currently no good way exists to change the order of children of QObjects. Also moving objects around at runtime while other parts of the program might access them is not a good idea.</li>
  <li>... this is easier with <em>storing approach #2</em>, since the whole tree is handled like a single value and there are no children I'd have to move and re-parent. Copying a part of the tree automatically copies all children and so on. Unfortunately this would mean a lot of overhead and loss in flexibility (I'd have to write the whole tree onto the disk again since I can't be sure what exactly changed).</li>
  </ul></li>
  </ol>
  
  <p>I'll probably update this question a little when more things come to my mind, but I'm really curious how other people solve this problem. Any suggestions and ideas are appreciated. :)</p>