Re: [Denemo-devel] Involvement

[Richard Shann]

On Sun, 2012-10-28 at 19:52 +0100, Éloi Rivard wrote:
> 
> 
> 2012/10/28 Richard Shann <address@hidden>
>         On Sun, 2012-10-28 at 12:20 +0100, Éloi Rivard wrote:
>         > An efficient way to discover and find commands could simply
>         to sort
>         > them in categories. I made a mockup of a "command manager"
>         with a
>         > simpler interface than the current one.
>         >
>         
>         > Images intégrées 1
>         >
>         > You can see command groups on the left. Let's imagine a
>         command can
>         > appear in several group, with a tag mechanism for instance.
>         The "Lorem
>         > Ipsum" is the selected command description.
>         >
>         > The top toolbar contains several items. The command set list
>         shows all
>         > the sets reachable by the program (users and system ones)
>         plus a
>         > special entry "Create a new command set". The first button
>         allows you
>         > to save the set, the second one to load the default set. The
>         third
>         > button is the current "find" one: user type a shortcut and
>         the
>         > corresponding command is found. The search bar allows you to
>         search in
>         > the commands (let's say name and description) instantly.
>         >
>         > With such a system, beginners will be able to find a command
>         as they
>         > are sorted and have explicit names, and experienced users
>         will be able
>         > to find a command by typing its name directly or with its
>         shortcut.
>         >
>         > What do you think ?
>         
>         
>         This sounds generally on the right lines. Three general
>         comments:
>         
>              1. It would be important to generate the data to populate
>         this
>                 command manager automatically, otherwise it will get
>         out-of-date
>                 as Denemo progresses and will not be trusted by users
>         (like the
>                 manual). This is slightly messy because, for
>         historical reasons,
>                 we have built-in and scripted commands. However they
>         are all
>                 seen at one point during start-up, and so the
>         generation of the
>                 data could be done there (either at runtime or done by
>         the
>                 developers before making a release). Some work would
>         need to be
>                 done to classify scripted commands (eg tag them by the
>         groups
>                 they belong to).  
> 
> Scripted commands are stored in XML files that already have some meta
> data fields (author etc.). An XML field "tag" for instance should be
> OK for this ?
Sure, something would be needed to retro-fit tags to existing commands,
and to get tags during the command creation routines (at the moment the
command name, label, tooltip and menu location are requested when you
create a command). As well as the on-disk storage the in-memory storage
would need augmenting of course. The built-in commands are generated
rather bizarrely by a program utils/generate_source.c, which has a large
array cutted-and-pasted from the early source code of Denemo when all
commands were built in. This program generates the source code that
creates GtkActions, menu entries, scheme callbacks etc.
One minor point is that we might perhaps call these tags "keywords" as
the word tag is already in use inside Denemo for something else.

I am not able to finish this email just now - it has been a couple of
days waiting here for me to get a chance (something needs to be said
about the scalability, as the number of commands in LilyPond is
enormous), but I'll send this now as a first installment. (In the other
thread, the topic of including information about whether the command
should appear on the user's button bars/palettes has come up)

Richard


>  
>              2. "Command Groups" - there are several ways of grouping
>         commands -
>                 earlier in Denemo's history we had two complete menu
>         systems,
>                 one by action (create, delete, move, edit,
>         show_properties, ...)
>                 and the other by object (score, movement, staff ...),
>         with
>                 commands appearing in both. Using tags instead the
>         user could
>                 select one or more tags and the command list would
>         change
>                 accordingly. 
> 
> A tabbed group list should solve this. You choose some tags/groups to
> be displayed in an "action" tab (create, delete etc.) and put the rest
> in a "categories" tab.
>  
> 
>              3.  "Command Sets" - currently these correspond to files
>                 with .shortcuts suffix. These determine whether a
>         command is
>                 hidden from the menu system and what shortcuts if any
>         it has. As
>                 long as your new command manager was very
>         conspicuously
>                 available I think it would be ok to have both
>         shortcuts and
>                 "hidden" set on one command. Which is where the
>         discussion
>                 started - why have a menu item for "move cursor
>         right". This is
>                 missing from your mock-up I think - a check-button for
>         whether
>                 the item should be in the menus or not.
>         
> 
> An issue in Denemo currently is that menus have an informative purpose
> more than a action purpose. Some entries are just here to let the user
> know that they exist (like indeed "move cursor to the right"). Now if
> the "informative" function is carried by this command manager, some
> menus entry should be disabled by default, making some menus a bit
> clearer.
> 
> Here is an updated mockup:
> Images intégrées 2
>  
>         I think these ideas will benefit from comments from others too
>         if they
>         can spare the time. This would be a great improvement in
>         usability.
>         
>         Richard 
>         
>         
>         
> Éloi 
> 
>         >
>         > 2012/10/27 Richard Shann <address@hidden>
>         >         On Thu, 2012-10-25 at 19:10 +0200, Éloi Rivard
>         wrote:
>         >
>         >         > 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.
>         >
>         >
>         >         Denemo would need more work on the MIDI generation
>         to make
>         >         this
>         >         attractive - the MIDI playback is there just to
>         check (by ear)
>         >         that the
>         >         notes are correct. Even this is incomplete - it does
>         not play
>         >         grace
>         >         notes.
>         >         There will be other possible uses for Denemo -
>         particularly
>         >         music
>         >         analysis (we have a routine that checks a
>         composition for
>         >         consecutives
>         >         already), and I hope people will develop these. I
>         was thinking
>         >         about
>         >         things that Denemo could be recommended for right
>         now. Right
>         >         now it is
>         >         strongest at entering music quickly, accurately, and
>         >         musically, and
>         >         delivering a high quality printed score without
>         manual tweaks
>         >         to the
>         >         appearance (thanks to LilyPond). I don't know how it
>         compares
>         >         with other
>         >         programs for playing along with the playback...
>         >
>         >         Richard
>         >
>         >
>         >
>         >
>         >
>         >
>         >
>         > --
>         > Éloi Rivard - address@hidden
>         >
>         > « On perd plus à être indécis qu'à se tromper. »
>         >
>         
>         
>         
> 
> 
> 
> -- 
> Éloi Rivard - address@hidden
>         
> « On perd plus à être indécis qu'à se tromper. »
>