You can see it in the "subdirs" branch if you want.
2014-02-28 20:51 GMT+01:00 Éloi Rivard <[email protected]>: > I made a try at home, tell me if there is something you think is not in > the right place: > > [azmeuk@herbi ~/dev/denemo/src]$ ls * > Makefile.am Makefile.in pathconfig.h > > *audio*: > alsabackend.c audiointerface.c dummybackend.h fluid.c > jackbackend.h midi.c pitchentry.h playback.c > portaudiobackend.h portmidibackend.c portmidiutil.h > alsabackend.h audiointerface.h eventqueue.c fluid.h > jackutil.c midi.h pitchrecog.c playback.h > portaudioutil.c portmidibackend.h ringbuffer.c > audio.h dummybackend.c eventqueue.h jackbackend.c > jackutil.h pitchentry.c pitchrecog.h portaudiobackend.c > portaudioutil.h portmidiutil.c ringbuffer.h > > *command*: > barline.c bookmarks.c changenotehead.c chordops.c commandfuncs.c > contexts.c dynamic.c fakechord.c figure.c graceops.c keyresponses.c > lyric.c measureops.c objops.c scoreops.c selectops.c staffops.c > tupletops.c > barline.h bookmarks.h changenotehead.h chordops.h commandfuncs.h > contexts.h dynamic.h fakechord.h figure.h graceops.h keyresponses.h > lyric.h measureops.h objops.h scoreops.h selectops.h staffops.h > tupletops.h > > *core*: > binreloc.c denemo_types.c external.h http.h > instrumentname.h kbd-custom.c keyboard.c keymapio.c main.c > parseinstruments.h prefops.h utils.c > binreloc.h external.c http.c instrumentname.c > instruments.xml kbd-custom.h keyboard.h keymapio.h parseinstruments.c > prefops.c twoints.h utils.h > > *generated*: > entries.h register_commands.h scheme_cb.h scheme.h xml.fragment > > *io*: > audiofile.c exportabc.c exportlilypond.c exportmidi.c exportxml.c > file.c guidedimportmidi.c importmidi.c importmusicxml.c importxml.c > print.c processstaffname.c screenshot.c xmldefs.h > audiofile.h exportabc.h exportlilypond.h exportmidi.h exportxml.h > file.h guidedimportmidi.h importmidi.h importmusicxml.h importxml.h > print.h processstaffname.h screenshot.h > > *render*: > accwidths.h displayanimation.c drawbarline.c drawcursor.c > drawfigure.c drawkey.c drawnotes.c drawtimesig.c > hairpin.h notewidths.h slurs.c > calculatepositions.c displayanimation.h draw.c drawdynamic.c > draw.h drawlilydir.c drawselection.c drawtuplets.c > moveviewport.c printview.c slurs.h > calculatepositions.h drawaccidentals.c drawclefs.c drawfakechord.c > drawingprims.h drawlyric.c drawstemdir.c hairpin.c > moveviewport.h printview.h > > *scripting*: > lilydirectives.c lilydirectives.h scheme-callbacks.c > scheme-callbacks.h scheme-identifiers.c scheme-identifiers.h > > *source*: > audiocapture.c audiocapture.h sourceaudio.c sourceaudio.h source.c > source.h > > *ui*: > clefdialog.c help.c kbd-interface.c keysigdialog.c mousing.c > mwidthdialog.c palettes.h palettestorage.h playbackprops.h > scorelayout.c scoreprops.c texteditors.c timedialog.c view.c > dialogs.h help.h kbd-interface.h keysigdialog.h mousing.h > palettes.c palettestorage.c playbackprops.c prefdialog.c > scorelayout.h staffpropdialog.c texteditors.h tomeasuredialog.c view.h > [azmeuk@herbi ~/dev/denemo/src]$ > > > 2014-02-28 11:16 GMT+01:00 Éloi Rivard <[email protected]>: > > 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. >> > > > > -- > Éloi Rivard - [email protected] > > « On perd plus à être indécis qu'à se tromper. » > -- Éloi Rivard - [email protected] « On perd plus à être indécis qu'à se tromper. »
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
