This document outlines the way dc_qt is structured and the way I want it to
be structured in the future.  However, it may be outdated, so if you really
want to add a feature and you're not sure where it fits in, send me an
e-mail.  craig dot howard at shadnet dot shad dot ca.

There are several main classes that do most of the work.

dc_main_window in dc_qt.cc pretty much runs the show.  It keeps track of a
couple lists, mainly the list of hubs.  It also has lists of the open
dialogs.  dc_main_window should contain code to open hubs, dialogs, etc and
mainly serve as a message passer (ie it connects signals and slots).  Most 
of the heavy code should go elsewhere.  

dctc_hub in dctc_hub.cc is the actual interface for all the sending and
receiving.  All GUI requests should go through dctc_hub.  There should be
no GUI specific stuff here.  All dctc commands are parsed here and
converted into a qt signal which can be handled by another object.

dctc_connection in dctc_connection.cc opens the socket with dctc and forks
the program.  All the _real_ backend stuff goes here.  dctc_hub should be
the only object that knows about dctc_connection.  It seems to work fine
right now, so I'm not planning on messing with it too much.

dc_parse in dc_parse.cc takes a string seperated by a character ie
aaa|bbb|ccc and treats the | as a separator.  The string passed in is
essentially treated as an array.  See just about anywhere in the code for
examples.  The qt3 version uses a built-in function that qt2 does not have.
The qt2 version works, but isn't too quick.

dc_hub in dc_hub.cc keeps track of the info of the open hubs.  It can load
a cached hub list from disk or the up-to-the-second list from the web.

dc_settings in dc_settings.cc stores the user settings.  I'm currently in
transistion from QStrings for each setting to an array of QStrings.  I'll
likely want to change to a map<QString, QString> in the future.

dc_user in dc_user.cc keeps track of a user.  

dc_file.cc and dirview.cc require a bit more explaination.  A dc_file is a
file anywhere in the hierarchy.  Directories are also files.  A dc_file
knows it's name, it's absoulte path and the name of it's root and whether
or not it is a directory.  There is also a link to it's parent.

dc_dir inherits dc_file and stores a list (actually a deque) of files in 
it's directory.  (Should it be a vector or a list?  I'm usually adding to
the end and rarely deleting, and I need random access.  I just convinced
myself it should be a vector, it's on the TODO list.)  The user can get a
pointer to a dc_file by calling get_file(QString) or get_file(int) (Note, I
hate this, how can I work around?)  rm_file functionality is there, but not
necessary for dc_qt.

On top of dc_file and dc_dir sit FileItem and Directory respectively.
These classes inherit from dc_file, dc_dir and QListViewItem.  These are
the objects that should be used within dc_qt.  (The names of these objects
should be changed to fit in with my naming scheme, I got them from a qt
example which I pretty much tore to shreds.)  

DirectoryView in dirview.cpp is the interface to the QListView control to be used
with FileItem and Directory.  FileDirView and SearchDirView implement this
interface.  SearchDirView adds files by taking a user and using that user
as the root.  

file_transfer is being implemented by me at this time.
