Hi Jacqueline, My reply is very long, so be warned. :-)
On 11/25/05, Jacqueline McNally <[EMAIL PROTECTED]> wrote: > Kohei Yoshida wrote: ... > > When I first start messing around with the code a few years ago, of > > course it was a lot harder than it is today to find the code I'm > > looking for. I had to read a lot of code (mostly of Calc) to get to > > understand the code structure, the naming conventions of files, > > variables, classes etc. > > How did you go about this? Did you dive into the code? Look for > technical documentation, or ask existing developers? All of the above. :) This is roughly what I did in the very beginning. First, since I was interested in the Calc code, I naturally went to the http://sc.openoffice.org/ page. In that page, there is a link to the page that describes how to create a new add-in function (http://sc.openoffice.org/addin_howto.html). So, I read that page, and started messing with the code under 'scaddin' module (when you download the entire source tree you'll find the directory named 'scaddin', which is what I refer to here) following the instructions given in that page. This module doesn't contain too much source code, so it's probably a good place to start just for a first timer to get a feel for the codebase. Once I had enough fun with the scaddin module, I moved on to the 'sc' module which contains Calc's main codebase. First thing I wanted to do was just to add a new function category. I thought initially that all I needed to do was to find an array of strings that contained the function category names, and add a new element based on my guess. So, I searched for all sources files that contained the word "Statistical" - one of the function category names. I then read several files that contained the word, and eventually found that the string array was located in sc/source/core/tool/addincol.cxx. I added a new category, modified a category count because I've just added a new category. The array definition also contained a comment next to each element like this: "Statistical", // ID_FUNCTION_GRP_STATISTIC So, I naturally thought that adding a new category would require defining a new associated constant somewhere in the source tree. I did a search, and found out that ID_FUNCTION_GRP_STATISTIC was defined in sc/inc/scfunc.hrc, and I add a new constant in that source file. The word "Statistical" also ocurred in sc/source/ui/formdlg/formdlgs.src. So I also added a new category name in here too just to be consistent with the other category names. I then re-compiled the sc module, and gladly found the new category I just added (hooray!) Anyway, this is what I did in the very first time to get myself hooked into the Calc code. I consider this a "hello world" equivalent for Calc hack. Very important to visually see what you've accomplished just to keep you motivated. Michael Meeks' famous hacker's guide helped a lot too. http://go-ooo.org/hackers-guide.html (now obsoleted due to wiki) Of course, Calc's core developers, especially Niklas and Eike, were always quick to answer my questions on the [EMAIL PROTECTED] mailing list. That also helped. But I must say that documentation for the core codebase was severely lacking. So, I had to do lots of code reading just to study the class/resource structure of Calc. > > Fast forward today, I am still not as experienced as some of our > > great contributers, but I can find a relevant code roughly about 10 > > minutes, and the searching process is not much of a pain. > > Is this because you have become more familiar with the area in which you > are interested? Yes. Or, is it something that you would be able to share with > other potential or new developers? Sure. I can only speak for my experience with the Calc code, but after having read more and more code, I started deciphering the nature of code organization within the 'sc' module. For instance, all view related code files were found in sc/source/ui/view, and all codes that deal with document object were found sc/source/core/data, sc/source/ui/*dlg for dialog related codes, and so on. Note that I don't claim to have visited all of Calc's codebase, but so far these mentioned areas are the areas I have visited most often. And once you know roughly where to find what type of source file, life becomes much easier. Even when you need to find code in a new, unvisited area, you'll find it quicker because you now know how to search the source tree (look for a right identifier!). Not to forget this site: http://go-ooo.org/lxr/ :-) Also, this may not apply to those who hack OO.o on a regular basis, but for someone like me who only has time to hack in the evenings or weekends, it was very important to document what I've read and done. It's amazing how quickly you forget what you read or did just two weekends ago. > > So, do I think the OO.o source is spaghetti? No. But I can see how > > newcomers might think that way because of the initial learning curve > > required to get comfortable with the code. > > Do you think the initial learning curve is peculiar to OpenOffice.org? I'm not really qualified to give you a definite answer to this since OO.o is my first open source project where I seriously dived into the code. So, please take my comment with a grain of salt. I would say "it depends". It's true that OO.o has a huge code base that no other open-source projects even come close. But the codebase is pretty well modularized that you can only read a fraction of the entire codebase to do what you want to do. Like in my case, all I need to deal with is 'sc', 'scaddin', and probably a little bit of 'svtools', 'svx' and 'sal'. On top of that, what I've done is mostly dealing with "fringe" cases, meaning that they were just isolated functionalities those modification involved only changing isolated area(s) - much easier than doing something that involves major refactoring of the codebase. So, for these types of changes, the difficulty is probably the same as other open-source projects of comparable size, or even smaller size. The optimization solver (http://kohei.us/ooo/solver/) is an exception, but since the solver is developed as a component using the API, I don't even have to deal with the core - it's a whole different story. OTOH, if you want to do some major code change that requires an intimate knowledge of class inheritance structure, method call stack etc., it may be harder than other open-source projects simply because of the amount of code you may need to deal with. But I just don't know this for sure since I haven't done anything of that magnitude yet. > > I was not, when I first showed up in this project. But I think I can > > count myself as one today (I hope). > > I spotted you on the list > http://wiki.services.openoffice.org/wiki/DomainDeveloper :) I'm still a half-baked developer, but I do my best not to break things. :-) Kohei -- Kohei Yoshida OpenOffice.org Calc contributor http://kohei.us/ooo/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
