cheetah.txt

   1 Architecture notes
   2
   3 Programming language. probably c/c++ and Objective C for OS-X. Or alternatively a language with a good c interface like lua.
   4
   5 Git functions. These can be done in a (somewhat) platform independent way by forking/spawning them. This is the way the current git-cheetah project does these things. PATH, location of binaries and syscall differ by platform, can be configured at compile-time.
   6
   7 GUI dialogs. These can be implemented using a platform independent toolset like wxWidgets, this safes the effort of porting the GUI for each platform. It should look and feel native on windows, GNOME and KDE.
   8
   9 File manager bindings. These are the most platform specific parts of the program, and will have to separated from the rest of the program by the means of interfaces (the java type) and #ifdef declarations.
  10
  11 GNOME: Nautilus can be extended through libnautilus-extension or alternatively make a Bonobo/CORBA component. libnautilus is sparsely documented, so other extensions like the archive manager can be used as reference. There is also a possibility of doing this with scripting but this offers less control and interaction.
  12
  13 KDE: Dolphin can be extended through servicemenus in combination with D-Cop components. Servicemenu are well documented extensions, the only problem may be the flexibility of this solution.
  14
  15 See http://developer.kde.org/documentation/tutorials/dot/servicemenus.html
  16
  17 Windows: The Windows shell can be extended by writing a COM object to interface with it. A large part of this work has already been done by the current owner of the cheetah project. It is basically writing a shell extension handler (http://msdn2.microsoft.com/en-us/library/bb776797(VS.85).aspx). Documentation is abundant and clear so this task is doable. Vista API changes may be a problem in this case.
  18
  19 The most time will probably be spend on the platform-specific file manager bindings and a proper GUI.