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. 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.) 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. 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. These are my thoughts today. Things are still jelling. If you (or anyone) would like to jump in with comments or suggestions, by all means. -- Jim On Tue, Sep 28, 2010 at 6:43 AM, Stanislav Nowak <[email protected]> wrote: > First of all I would like to thanks you for creating this application. I > was very excited when I firstly launch it. Gnome was missing feature > rich photo manager for long time and I must admit that I never liked > f-spot. > > I have some remark about source code. > Although Vala's syntax is very similar to Java or C# I think that > sourcefile organization should not follow Java or C# way as I felt it in > your project. In my opinion when you run valac over Vala project the > result should look like as gnome module written purely in c. > What does it mean for Shotwell? Please separate library and application > (UI) code to individual directories. For example like in Rhythmbox, they > have shell directory for UI, rhytmdb for data, widgets, sources and so > on. Leave one class per file. Follow gnome sourcefile name convention. > This is very often in format "directory-classname". In sourcefiles use > "namespace" keyword - it should save your work. For example file: > > \shotwelldb > shotwelldb-import.vala > > will include: > namespace Shotwelldb { > class Import : ... > //some code > } > > > I like the way that is used by Cannonical in their Unity project: > http://bazaar.launchpad.net/~unity-team/unity/trunk/files<http://bazaar.launchpad.net/%7Eunity-team/unity/trunk/files> > > > I know it's lot of boring labor. But I think I will help shotwell to fit > more in gnome environment and it should be more convenient for gnome > developer. Maybe its an good idea to try push project to gnome git - at > will gain more love and care :) > > There are only humble recommendations that I believe will help the > project to grow. For me is very difficult to orient in shotwells code > organization, mostly because library and application functions are mixed. > > I have some ideas about GUI and usability I will try to write them latter. > > Yours, > Stanislav Nowak > _______________________________________________ > Shotwell mailing list > [email protected] > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
