Developer information

  • jlutz777

         Is there any guidance for new developers that want to jump in and try to solve bugs or add functionality?  I have tried a little but am pretty lost.  Part of it is due to the lack of commenting in the code; part of it is probably because I was not present during "design decisions," like the FauxThreads module; and part of it is due to my own lack of knowledge regarding Python and GTK.
         It'd also be nice to know the details of developer's workspaces (especially the originator, Mr. Hinkle).  I'd like to know, for example, what IDE I should use, what debugger, how should testing be done, how to test threading problems, how to check in changes, etc.  Any information would be nice.  In fact, if I can get enough information cobbled together, I'd be interested in creating a "Developer's guide" that others could use.  I know this leads to more info to keep up to date, but it should not be too bad once the framework is there.
         If a developer's guide already exists, excuse my ignorance and please point me to it.  I am in no way criticizing the code or the project.  It is a great program that I love using.  I want to get my friends and family to use it also.  Most of them use Windows, as do I for the time being, so I'd like to see if I can catch a few of those nasty bugs.


    • tom

      Hi -- there is no guide in existence, since no one but me has done any substantial work on the project. Of course, as you point out, it may be that if we can clean up the code and make it easier to dive in, we will get more help. (On the other hand, the overlap of people capable of helping with development and people interested in cooking is probably not all that big...)

      The best way to ask questions and get help regarding modules etc. is to use the mailing list -- I'll respond to questions pretty quickly there and that way questions and answered will be archived (this serves as some form of documentation in case you don't ever get around to creating a developer's guide).

      As you've noticed, the threading stuff is rather messy, mainly because the functionality that works on Linux doesn't work on windows, so we have a workaround that was thrown together to get Windows up and running. I don't recall the current state of that code -- it may be easy to rework the code everywhere so that the workaround is no longer necessary.

      As to my setup, I use emacs as my "IDE" if you want to call it that.

      the organization of the code in src/lib/ is as follows

      backends/ - methods for accessing database, all should be inherited from base class in
      importers/ - code for importing
      exporters/ - code for exporting (including printing)
      legacy_db/ - old code needed for updating from some older versions
      nutrition/ - code for parsing and displaying nutritional information

      Everything else is in src/lib/ itself. If I were about to begin reorganizing, the only thing I'm sure I'd do is put little "extras" convenience libraries into a separate extras/ folder -- there are a number of libraries that make working with GTK easier that could easily be moved out of the way to make the directory a bit less overwhelming.

      But for the most part, you'll be dealing only with a few files: - the main application - the recipe card interface - the recipe search view interface - the shopping interface - some gui-independent shopping-list code

      There is a src/tests/ directory that has the beginnings of some automated tests that you could look at for guidance. As to threading tests, there is a --debug-threading option, which simply starts a thread with a timer to tell you how many threads there are at a given moment.

      As to checking code in, once you've submitted a few useful patches, etc., and decide you want to work on the project, I'll be happy to give you access to check code in -- in the mean time, please just use the sourceforge bug-reporting/patches areas to submit your changes.