2012/10/21 Richard Shann <[email protected]> > On Sat, 2012-10-20 at 18:57 +0200, Éloi Rivard wrote: > ... > > I joined you a patch that fix translation for the preference dialog. > > The only thing needed to make it work was to extract the gettext > > function call from the macros, so xgettext could parse every call. > ah! basically although the C-semantics are the same, the gettext string > extraction mechanism cannot cope with _() buried inside a macro. Hmm, so > we have to repeat the _() at every call, well, that is a small thing. > Thank you for clearing up my puzzlement about that. > > About my interests, I'd like to get some experience with graphical > > interfaces and ergonomics. Perhaps redesigning the preferences panel > > would be a good start ? I can finish french translation too, as it is > > quite incomplete. > Well, the preferences panel would allow you to familiarise yourself with > some gtk widgets and the gtk packing of widgets, but there is only a > very small scope for making a difference to Denemo for the user there. A > really significant improvement for Denemo would be to sort out > translating the keyboard/mouse shortcut names. > (You asked in a previous email why Denemo was so pharaonic with respect > to translations and I did not directly address that question then > because without knowing your background the chances were that I could > not have explained it. Since you wrote at the start of August I have > done a lot of work on translation.
That's great ! I think translation can give a lot more notoriety to this project ! > I have written a parser that takes > the current set of scripted commands - in xml format files - extracts > the scheme and puts it into files which xgettext can work on. I have > also written a compiler for the generation of labels and tooltips of the > scripted commands, so that those now appear compiled-in and hence can be > seen by xgettext - of course, if you generate a new command neither its > script nor its menu label/tooltip will be translatable, but then you > will probably write it in your native language :). It does mean there is > much clanking of machinery before we can make a release, but most of > Denemo has become translatable since you wrote in August. > > But this still leaves keyboard and mouse shortcuts. Again, Denemo is > unusual in not making use of GTK's built-in methods, and so not being > easy to translate. GTK deals only with keyboard shortcuts and assumes > that the keyboard is basically for entering text. Denemo allows the > mouse gestures as shortcuts, with names like PrsL for pressing the left > mouse button, RlsR for releasing the right mouse button etc. Denemo is > also unusual in allowing two-key shortcuts - so Del,M deletes a measure > while Del, Del deletes the object at the cursor. To support this Denemo > has to create the menu item labels with the shortcuts itself, and all > this is has to respond to the user changing shortcuts, or indeed a > script changing shortcuts. > > This does present a challenge for translation - not only do the names of > keys need translating ( comma -> virgule etc) but there are keys not > present on some keyboards, or not conveniently placed. This last problem > is probably best left until the set of commands is more complete, but > translating the key and mouse shortcut names could be tackled now, and > doing it would I think complete the translatability project.) > Sorry about the very long parenthesis () ... :) > I see. That does not seem impossible to do :) I'll try to have a look. > The overall graphical interface problems are something that need work as > you observed in your first email, for example if you have several songs > in your piece (Movements in Denemo terminology) they are not obvious - > not tabbed. Tackling these problems without having a fair amount of > experience using the program in at least a couple of the main ways of > using Denemo would not be a good idea. (I can think of three main ways > of using Denemo - one is for entering hundreds of bars of music which > has already been composed, another is composing with the program - > inserting, deleting changing rhythms, and finally there are methods for > those who are only doing a few bars of music - a fiddle tune, say - and > are happy to drag and drop individual notes onto the score regardless of > how slow it is, so long as they don't have to spend time learning > shortcuts before they can start). And maybe you can consider a fourth way to use denemo. Users doesn't write music at all, but just want to read existing partitions. That's the case for my brass band : musicians just play the partitions with Noteworthy, and play music over it. They are helped with what plays the software, and the moving cursor on the partition. > It would be quite easy to create a > nice-looking program which for serious use would be rather impractical, > and indeed I suspect that many of the hundreds of score-writing programs > out there come into this category. You can place a few notes and chords > on the page, but then you have to start dragging things around to avoid > collisions of text with slurs, and once you have more than a few pages > of music the problems are multiplying quickly. > I believe that a program such denemo can be at the same time efficient and intuitive and nice-looking. > Let me know your thoughts on all this - comments from others are welcome > too - I have rather slight experience with Finale, and very little with > any other score writing programs. > > Richard > > > Does every command need to appear in a menu ? If a command appears in a menu, we can expect it is because you can't execute more easily with the mouse. Considering that I think some commands does not belong to a menu, like those about cursor moving, as it is more efficient and intuitive to just click where you want the cursor to be. For example, there are two commands to create a slur : "begin slur" and "end slur". This is efficient for keyboard, but not intuitive for the mouse. A mouse-friendly way would be to just select what you want with mouse dragging, and have a button (or a menu entry) to create the whole slur. This reasoning is expandable to most of "begin/end" commands. Another example is "include something before" and "include something after" commands. A mouse user will just click where he wants to add something, and then click on a "add something there" button or menu entry. I think keyboard oriented commands shouldn't appear in menus, as menu and toolbars are graphical elements, that you use with the mouse. Considering all this menus should be clearer :D What do you think ? Éloi > > > > > Éloi > > > > 2012/10/20 Richard Shann <[email protected]> > > Hi Éloi > > > > It would be great to have more help with Denemo - there are > > many > > unfinished sub-projects in the code. > > I wonder if you would like to copy your email to the mailing > > list > > ([email protected]) as there will be people listening there > > that have > > ideas about what they would like to see progressing in Denemo. > > Here are a couple of things that I know of, one fairly simple > > and one > > which is much more open-ended. > > > > 1) The preferences dialog is largely not translatable. The > > code > > (prefdialog.c) uses macros to avoid repeating the same code > > for getting > > and setting the preferences. These take a string which is then > > wrapped > > with the function call _() (itself a macro for gettext() > > IIRC). > > For some reason this seems not to work. Either a better > > understanding, > > or running the compile stage with -E to see the pre-processor > > output is > > needed. And some straightforward method of checking that a > > string will > > be translatable (I can't trigger running Denemo with > > translations > > appearing, for some reason). > > > > 2) There is the start of code to allow people to transcribe > > music that > > is in audio form (that is: create notation for some music that > > they have > > a recording of). The code allows to open a recording (.ogg > > format, > > perhaps others) and then to synchronise empty measures with > > the music > > (by the user tapping the space bar at the start of each > > measure as > > Denemo plays the audio back). Each measure has its own tempo > > setting > > inserted so that when the notes are inserted into the measures > > they keep > > step with the music. When the score is played the audio is > > played in > > sync. > > This works, but only to some extent, discrepancies in timing > > being > > audible. At this stage in the development (as I only had a > > very old slow > > machine) I stopped work and have not got back to it. There is > > very > > little error reporting and the mixing of the audio and the > > MIDI is done > > simply by playing one in the left stereo channel the other in > > the > > right... > > > > One of the things you need to think about is what your > > personal > > interests and preferences are: some people enjoy tidying up - > > I have > > started towards making Denemo compile with -Wall, some files > > now pass > > that without warnings. And view.c is a horror story of > > multiple topics > > all stuffed into one file, it needs splitting into at least > > three. > > Others would be more interested in making the MIDI playback > > follow more > > of the indication in the score... > > I'll try and put these and other ideas onto the website. > > > > Best wishes > > > > Richard > > > > > > On Fri, 2012-10-19 at 19:41 +0200, Éloi Rivard wrote: > > > Hi, > > > My name is Éloi Rivard, I passed a master degree in software > > > engineering last year in Bordeaux (France). Currently I work > > as PHP > > > developer for a friend's company. I'd like to get involved > > in a FOSS > > > project and I though about denemo for several reasons. First > > I can > > > program in C, denemo can run on a GNOME environment, and I'm > > a > > > musician. I play clarinet and saxophone in a brass band, and > > guitar. > > > Sometimes I write some song for my band, so I already used a > > partition > > > editor like Noteworthy. > > > I can give you some help with code, but packaging and user > > interfaces > > > or even translation are also subjects I'm interested in. > > Even if I'm > > > not very experienced with packaging, user interfaces theory > > or GTK, I > > > would be glad to learn about them. > > > Do you know simple tasks I can do to get familiar with the > > code, as > > > gnome-love ones ? It is a bit difficult to find easy bugs in > > the huge > > > savannah list. > > > Let me know if I can be useful ! > > > > > > Éloi > > > > > > > > > > > > > > -- > > É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
