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 <dmmcintyr@...>
Linux fanatic, and certified Geek; registered Linux user #243621
Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/
|
