On Thu, 2010-09-30 at 15:32 -0700, Jim Nelson wrote: > Hello Stanislav, > > I've been thinking quite a bit about reorganizing the Shotwell code base, > mostly because (a) the number of files in a single directory is growing to > an unmanageable number, even for someone (like me) who knows the code base > in and out, and (b) to make it more approachable for outside contributors. > > I think you're bringing up some other points that are also worth > considering. To take them apart as separate questions: > > 1. Directory organization (which is what I've been thinking about) > 2. Source file naming conventions > 3. Class-per-file question (implied by #2) > 4. Namespaces (which I've been thinking about as well) > > To address each of these: > > 1. We're in agreement here, and looking over Rhythmbox's code, I see > parallels in what I've been pondering and how they sort things. This is > something I would definitely like to do with Shotwell's code base. > > 2. I'm seeing some variations on source file names depending on the project: > > * Rhythmbox uses a variant of the mechanism you're speaking of (i.e. > metadata/rb-metadata-common.c) > * The Vala compiler uses another (ccode/valaccodecomment.vala). > * Rygel uses Rhythmbox-style naming (ui/rygel-preferences-dialog.vala) > * F-Spot uses the C#/Java naming style (Imaging/JpegFile.cs) > * pitivi uses something similar, although not CamelCased > (ui/propertyeditor.py) > > Note that none of these strictly follow the GTK naming convention > (gtk/gtkbutton.c). > > What the above list tells me is that the jury is still out on an "official" > naming convention, especially in terms of non-C languages, with the one > exception that the filenames should be all lowercase (unless it's > Mono/C#/Java). > > You say that when valac runs it should look like a GNOME module written in > pure C. I'm not sure I agree with that. When you run valac in its default > mode, it deletes the .c files after compiling and linking. In a larger > project, yes, we keep them around to speed up compilation time (as well as > to examine them for debugging/performance reasons), but they are not useful > as "source" code -- no one should be editing them, and patching them > downstream would be dangerous territory. If we're going to rethink our > source naming convention, I feel it should be, above all else, consistent > and intuitive for Vala coders. I don't feel our naming should be a slave to > the .c files produced.
Totally agree. The naming should make it easy for Vala coders so that new contributors can find their way around easily. > > If I was using Vala to produce a GObject library, then yes, that's more > compelling. (When we produce header files for plug-ins, that would be a > place we think about it -- I'm just not sure we want to let our yet-to-be > coded plug-in architecture dictate filenames everywhere else.) Agreed too. Although, I'm curious: what would be the difference between an organisation that is easy for Vala coders and one that makes it easy for C coders? Also I suspect that any GObject library written in Vala should be usable as a Vala library so can't be too far from the standard Vala practice. > > 3. One thing that is true for GTK, Rhythmbox, Vala, and Rygel is a strict > one-class-per-file organization. There are hundreds of classes in Shotwell, > and I don't think putting each and every one in a separate file is doing a > service to developers. (For example, we have 34 Command subclasses for the > undo/redo system. Some are 13 lines long.) I do think many of our files > have grown too large and should be broken up to keep the chunks small. > We've done a good job keeping UI code away from implementation code, it's > just a matter of separating the files appropriately in directories. > Breaking up the files into smaller chunks makes a lot of sense too. One way to do it is to go for a one class per file organisation by default and have exceptions for cases where a set of classes actually make sense together. If I look at the F-Spot import code, it would make a lot of sense to have one file per class for the top level interfaces and core classes but group the database classes together so that each file includes the main table class plus all the related behaviour classes as they only make sense together. So when you decide to re-organise the code, please tell me and I'll re-organise the F-Spot import code accordingly. > > 4. Namespaces are something else I'm considering -- making each subdirectory > a namespace makes logical sense to me, and means the code reflects the > logical organization of the source files. Plus, there's a cool Vala feature > -- the "internal" keyword -- that we can start taking advantage of with > well-thought-out namespacing. Namespaces are a great feature. It's the default way that Java operates and my experience with Java is that it helps tremendously in making the code clearer, especially when the name space naming convention follows the directory structure and logical organisation of the files. My £0.02 Bruno _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
