Well, drawing the display is one category for sure. And "backends" is
> not a good name for something that has to do with playing - the main > sort of backend in Denemo is not listed - the creation of the finished > score for printing, printview.c I guess. > > There are also the sourceaudio and source-something-I-forget-what that > open things you are using to create the score from - a pdf of a > manuscript, or an audio or midi track. > > And then there is the stuff (also "sources" of a sort) for getting MIDI > in and Audio In. > > Then why not: src/ - generated/ This one already exists - import/ Sources related to file import (midi, musicxml, .denemo) - export/ Sources related to file export (lilypond, midi, xml, tab, pdf, png etc.) - *audio*/ Sources related to audio backends (alsa, portmidi, portaudio, fluidsynth, jack etc.) - ui/ Sources related to dialogs (command center, preferences, dialogs, palettes etc.) - scripting/ Sources related to scheme and scheme callbacks - core/ Others general sources (utils, main, commands loading etc.) - *render*/ Sources related to printing (printview.c etc.) - *source*/ Sources related to music import (audio, midi, pdf, etc.) > > >What do you think ? > > Well, unless I learnt some new commands, it would slow up my work. When > I want to find which file has a function definition in it I type grep > functionname src/*.h (there is a horrible drawingprims.h which defeats > this :( ) and then I only have one place where I need to open the file > from. Are you using some IDE to do this sort of thing? If you *do* have > an IDE then I guess you never know where the files are anyway (?) > > Well I use Anjuta sometimes, Gedit some other times. What is your text editors ? Do you know ctags ? You also may want to play with a few grep options. Grep can recursively search in a directory (-R) and filter some file names (--include). For example, if you want to search "print" in .h files, just type: grep -R --include *.h print src You also may create an alias for this to go faster. Would your work still be slowed with that command ? Perhaps first might be rationalizing the distribution of code in the > files - commandfuncs.c is the worst offender, whoever created that was > thinking of organizing in the opposite way to the person who created > staffops.c measureops.c, lilydirectives.c etc. And I think view.c still > contains all the code to do with creating and following rhythmic > patterns (my fault that). And utils.c is another howler - at one time, > early on, it was being used for common elements of the display-drawing > code, but it more properly has stuff that various other departments of > the code might use. > I believe that dividing sources in several subdirectories is a good start actually. Directories reflect the architecture of the program. It would be easy to know that something is wrong if you find some "scripting" functions in the "import" directory for instance.
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
