Hi, Dne 1.10.2010 00:32, Jim Nelson napsal(a): > > 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. Great :) > > > > 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. I'm sorry I make myself very unclear at point. All I wanted to say is that from my point of view is Vala some kind of syntactic sugar to C and gobject library. I only mean to propose to stay with C+goblect conventions as much as possible and prefer them over Java/C#/Mone conventions. I agree with all statements that you have written here.
> > > > 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.) Maybe you are using too much classes in shotwell -- just kidding :) It's very common to create separate class for every domain of functionality in Java/C#/Mono. But it is't that common in C+GObject world. There are 3 reasons that comes to my mind: I. In C there are no classes and functionality is provided by functions organized in files according to their domain. C+GObject inherited this usage. II. Writing new class in GObject requires lots of dull work. This is not problem in Vala :) III. Maybe there are some performance issues. Allocating new class is expensive. As for your example I would create separate directory and let each class to have it's own file. To have single file for each class should not be problem if the files are well organized in directories. 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. Great -- the code reogranization should go very smooth. Maybe I would consider to prepeare some testsuits. > > 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. > > Agree on that. > > 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 > > Stanislav Nowak > > > > 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
