denemo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] Scheme extraction


From: Richard Shann
Subject: Re: [Denemo-devel] Scheme extraction
Date: Thu, 20 Jun 2013 12:21:46 +0100

On Thu, 2013-06-20 at 12:17 +0100, Richard Shann wrote:
> On Thu, 2013-06-20 at 13:17 +0200, Éloi Rivard wrote:
> > Note that there are several advantages in this separation :
> > 
> > - It deletes the scheme extraction step for translation, and make the
> > whole denemo build process simpler
> > 
> > - When the script is lazily loaded, no more XML is parsed
> > 
> > - You can open scheme scripts with an external editor if you want.
> 
> Indeed you can open them in the scheme window :)

I mean you can open and save using the File menu of the scheme window,
instead of using right-click->Get Script.

We are (and have been) missing the ability to edit the label and tooltip
from inside Denemo, that was part of my original idea, that users could
make a note on how to use a command once they had found it... and change
the label if they use a different name for something (anacrusis, pickup
upbeat was the classic case, I ended up putting all three in the label)

Richard



> 
> Richard
> 
> 
> > 
> > 
> > 
> > 2013/6/20 Éloi Rivard <address@hidden>
> >         I plan to re-think how menus are located. Replicating the
> >         menus hierarchy in the file system seem dirty to me. Location
> >         should rather be a metadata of the commands. I would be the
> >         right time to tackle the menu translatability.
> >         
> >         Is ok if I merge scm to master ?
> >         
> >         
> >         2013/6/20 Richard Shann <address@hidden>
> >                 On Thu, 2013-06-20 at 09:51 +0200, Éloi Rivard wrote:
> >                 > On the "scm" branch I extracted scheme scripts from
> >                 xml. Could you
> >                 > please test ?
> >                 
> >                 
> >                 This seems good - I managed to get it in a tangle with
> >                 languages - with
> >                 LANG and LANGUAGE set to different things I created a
> >                 new command in a
> >                 sub-directory. Two subdirectories appeared, one with
> >                 translated name, in
> >                 one only the .xml file was present, in the other
> >                 both .scm and .xml were
> >                 present. This is a pretty obscure area - once I had
> >                 both LANG and
> >                 LANGUAGE pointing to italian all worked ok.
> >                 I haven't tried testing whether this branch generates
> >                 translatable
> >                 strings etc.
> >                 
> >                 Richard
> >                 
> >                 
> >                 
> >                 >
> >                 >
> >                 >
> >                 > 2013/6/12 Richard Shann <address@hidden>
> >                 >         On Wed, 2013-06-12 at 11:55 +0200, Éloi
> >                 Rivard wrote:
> >                 >         > In keyboard.c line 274 you can see this :
> >                 >         >         if ((merge & DENEMO_INTERACTIVE)
> >                 && (merge &
> >                 >         DENEMO_MERGING)
> >                 >         >         && new_command)
> >                 >         > The merge value is an integer, but when
> >                 you look at the call
> >                 >         graph you
> >                 >         > can see that it comes from a boolean in
> >                 load_xml_keymap
> >                 >         > ( load_xml_keymap (gchar * filename,
> >                 gboolean
> >                 >         interactive) ). So merge
> >                 >         > value is always 0 or 1. That makes (merge
> >                 &
> >                 >         DENEMO_INTERACTIVE) always
> >                 >         > false, and the whole if block useless.
> >                 >         >
> >                 >         > This block just displays some test. Should
> >                 we keep it?
> >                 >
> >                 >
> >                 >         Yes, this is badly broken now.
> >                 DENEMO_MERGING is no longer
> >                 >         being set at
> >                 >         all, this code was set up in 2009 to tell
> >                 the user when he had
> >                 >         successfully added a command (using "More"
> >                 from the
> >                 >         right-click on a
> >                 >         menu item).
> >                 >         It is not crucial and as it is not working
> >                 it can go. Adding
> >                 >         commands
> >                 >         via More Commands on the right click menu is
> >                 working (though,
> >                 >         at least
> >                 >         in gtk2 the menu drawing gets a bit manked
> >                 up after adding the
> >                 >         menu item
> >                 >         and needs refreshing).
> >                 >
> >                 >         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. »
> >         
> > 
> > 
> > 
> > -- 
> > Éloi Rivard - address@hidden
> >         
> > « On perd plus à être indécis qu'à se tromper. »
> > 
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]