Ok. So exportxml and importxml belong in "core". Sources related to music file import/and export belong in "export" (isn't it too specific, as there is also importmusicxml too ?) Sources related to midi input belong in "input" Sources related to miscellaneous content that may be linked to a score belong in "source".
Am I right ? 2014-03-05 17:19 GMT+01:00 Richard Shann <[email protected]>: > On Wed, 2014-03-05 at 11:55 +0100, Eloi Rivard wrote: > > > I'm not at all convinced that classifying code by whether it is dealing > > > with files on a disk is a good way to go. Files containing stuff > derived > > > from the music you have created with Denemo is one thing, files that > > > contain stuff that you want to use to create a music score is quite a > > > different thing. > > > > You are right, actually dealing with import/export files is not the same > > that just loading a file as a "meta-data" to the score. Maybe a new > > directory is needed here. I am not sure how to call it. Do you think > > that "file" and "meta" are good names ? > > "export" I think is good for creating representations of the music in > formats that other programs can use. The name "source" could be ok for > code for reading-in data that the user will use for creating a score. (I > don't think "meta" is good here - that would be some sort of data about > the musical score, e.g. a file containing statistics about the number of > bars, or particular harmonic progressions ...) > > > > > > command: > > > > changenotehead.c chordops.c commandfuncs.c contexts.c > > > > fakechord.c figure.c graceops.c keyresponses.c lyric.c > > > > measureops.c objops.c processstaffname.c scorelayout.c > > > > > > scorelayout.c is part of printview.c and exportlilypond.c > > > also I see chordops.c here, there are also measureops.c scoreops.c IIRC > > > > scorelayout seem to edit the score directly, thus I think it should be > > kept in "commands", or maybe split > > Hmm, this is an example where the simple model breaks down. For most > uses scorelayout.c is just part of the generation of the LilyPond text; > it generates nothing that gets saved to disk in the myname.denemo file > that represents the score. But it also creates a gui for looking at the > structure of the LilyPond text, and if you choose to you can then use it > to add data to the score (that *will* be stored in myname.denemo), > namely, customised score layouts. > *However* I would not expend too much mental effort on this: I would > like to re-write all that stuff as it is not intuitive enough to pick up > and use easily as it is. > > > > > > > > > > scoreops.c selectops.c staffops.c tupletops.c > > > > changenotehead.h chordops.h commandfuncs.h contexts.h > > > > fakechord.h figure.h graceops.h keyresponses.h lyric.h > > > > measureops.h objops.h processstaffname.h scorelayout.h > > > > scoreops.h selectops.h staffops.h tupletops.h > > > > > > > > core: > > > > binreloc.c binreloc.h denemo_types.c external.c > external.h > > > > http.c http.h kbd-custom.c kbd-custom.h keyboard.c > > > > keyboard.h keymapio.c keymapio.h main.c prefops.c > > > > prefops.h twoints.h utils.c utils.h view.c > > > > > > > > display: > > > > accwidths.h calculatepositions.h > displayanimation.h > > > > drawbarline.c drawclefs.c drawdynamic.c drawfigure.c > > > > drawingprims.h drawlilydir.c drawnotes.c drawstemdir.c > > > > drawtuplets.c hairpin.h printview.c > > > > > > printview has nothing to do with drawing the Denemo display (main > > > window) it handles the typeset display and belongs with > exportlilypond.c > > > (badly named) which generates LilyPond syntax. > > > > Well, maybe a new directory is needed here too. I think "render" might > > be a good name for printview sources. > > "printview" gives a better idea of what is there, render would apply to > the Denemo display and indeed the drawing of dialogs etc. > > > How to call the Denemo display ? > > "display" may not be a good name, as it is not only about displaying but > > mainly about editing. > I was using the term only for the drawing of the display. It is true > that you look at the Denemo Display as you edit music (usually) and > technically the Denemo Display has the keyboard focus (so the > key-presses are being received by the GtkDrawingArea widget), but the > code called draw*.[ch] is just to do with drawing into that widget, for > which "display" is not a bad name. > > > > > > > displayanimation.c drawaccidentals.c draw.c > > > > drawcursor.c drawfakechord.c draw.h drawkey.c > > > > drawlyric.c drawselection.c drawtimesig.c hairpin.c > > > > notewidths.h printview.h slurs.h > > > > > > > > file: > > > > audiofile.c exportabc.c exportlilypond.c exportmidi.c > > > > exportxml.c file.c guidedimportmidi.c importmidi.c > > > > importmusicxml.c importxml.c print.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 screenshot.h > > > > > > as I say above, mixing stuff that is used to create a music score with > > > stuff that can be generated from a score once it is created seems a bad > > > idea. So guidedimportmidi and importmidi and screenshot belong in input > > > below. And the (badly named) exportxml.* is our fundamental > > > save-a-project-code for saving in denemo's own format. It doesn't sit > > > nicely along with exported things. > > > > You wish to separate import and export projects .denemo files (load and > > save actually) from import and export project in other formats > > (musicxml, lilypond, midi etc.) ? > yes > > I though we could regroup those > > sources that can "load and save music from/to a file, whatever format it > > uses". > we used to do that, but it leads to the expectation that the score can > be recovered from an exported file - e.g. people naively think that a > MIDI file would adequately represent the score. > > > > > This is a good question. Most of users are not computer experts, and > > just do not care about which format is used. They just want to "load or > > save some music". Gimp for instance try to privilege their own project > > format, but Libreoffice let you save documents in whatever format you > > want (without making any difference between load/save and > > import/export). > > > > How do you see things ? > > I think we are a more extreme case than either of those two, and those > two choose the right policy for their cases I think. Gimp needs to make > you aware that if you save as jpeg you will not be able to edit some > text you have in an image, and LibreOffice knows that you will still > have the actual words of your document if you save as .txt > By contrast if you save myname.denemo as MIDI and think you don't need > the myname.denemo any more you are in for a rude shock. You can hear > what it might sound like, but you have a lot of work to recreate a > musical score from the file. > > Richard > > > > > > > -- É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
