On Wednesday 02 August 2006 11:01 am, Chris Cannam wrote: > Any comments on this one? For a while I've been sitting on a script that > reshuffles the code in the gui/ directory of a Rosegarden tree into a set > of subdirectories, each with a potentially large set of source files that > in most cases have only one class per file.
That's an interesting idea. I needed an enum to keep two different combo indices and their associated meaning as track/segment parameters straight, and I did a header with just that one little bit of nothing in it. It seemed somewhat wasteful, but also somehow proper to set out this one odd little enum as something entirely separate unto itself. It seems I was catching the edge of a new wave of thinking with that move. I wonder, though. How unwieldy is this going to become with the includes? It seems the number of includes is going to have to increase exponentially. OTOH, it will be immediately apparent why you included thusandsuch.h. > It doesn't actually produce a buildable tree at the moment, but it does > produce something that could be used as the basis for one. If checked in > on a branch, it could probably be turned into a buildable tree within a few > days by a few of us working on different bits of tedious stuff at the same > time. Yerk. Tedious stuff sounds right. A really ugly marathon cleaning up all the things we can't script around. But only done once, and more maintainable code ever after. On the subject of more maintainable, we really ought to have a code documentation marathon too. I probably comment too damn much, but the rest of you don't remotely comment enough. There are reams of code without a comment in sight, as if it was all written with no expectation that anyone would ever have to revisit it. > pixmaps, styles, library, testfiles.) The directory structure is very much > a first guess, with some directories (application, general) basically just > holding stuff I couldn't decide where to put. Ultimately the code-holding > directories might want to go on the same level as base, sound and sequencer > (or would they?), and the data-holding directories might want to go in a > different parent directory (or would they?). I think yes on the data, maybe not on all these others. It seems like an awful lot of directories immediately under rosegarden/ to go that route, and it would seem to de-emphasize the logical importance of base/, sequencer/, and sound/ as being the hierarchical underpinnings of all the other bits that are built on top of that foundation, losing the importance of base/, in particular, to just another in a sea of directories. Probably the usual KDE thing would be to put all of this under rosegarden/rosegarden, and the sequencer under rosegarden/rosegardensequencer I think I might put sound under base/ too. It looks like the only real reason it isn't in base/ already is because it uses QT, right? Maybe it's time to admit that the QT restriction in base/ is silly, and abolish it. Anyway, the structure you came up with looks broadly right to me otherwise. I haven't analyzed it particle for particle, but it seems logical overall. > One potential problem is the loss of history information in separating out > files. You're just trying to steal all the glory for yourself now that I'm getting close to having more code to my credit than what of Rich's is still left (after you stole most of his credit by refactoring things.) :D > We could consider splitting files by repeatedly doing an "svn copy" > from the original file and then cutting bits out of the copies (svn copy > apparently duplicates the history). That would retain everything, but with > an enormous amount of duplication -- I don't know whether Subversion would > actually duplicate the data, but it might confuse the developer > nonetheless. It all sounds like more of a pain in the ass than it could possibly be worth to me, my glib comment above notwithstanding. > Needless to say I'm not proposing this for before 1.3, but I wouldn't mind > getting some comments on it while so many developers appear to be awake. One other thing, I haven't looked at her code either, but Michelle apparently has a big gob of something coming as soon as she gets back around, and works out how to patch without running all our code through a reformatter. I've already made her future job harder with my changes to the TPB and such, and it seems likely all of that code will wind up going into the bit bucket in disgust if we pull this stunt before her guitar tab stuff gets merged in. I don't want to put us in a position where we have to do something like accepting a patch that changes all our formatting around, but I do think what she's working on is probably worth trying to find some middle ground, and not being totally inconsiderate of the fact that this ball is in play. Assuming she's not already totally pissed off because none of us would look at her badly formatted patch. -- D. Michael 'Silvan' McIntyre ---- Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
