Re: [Denemo-devel] problems with 1.1.2

[Bric]

On 02/12/2014 07:52 AM, Richard Shann wrote:
> On Wed, 2014-02-12 at 06:20 -0500, Bric wrote:
> > I figured I should move this out to a new thread. (WAS:  "duration,
> > rhythm, metronome, etc., for MIDI-input?")
> >
> > I compiled denemo version 1.1.2, seemingly OK.  After updating my glib
> > (downloaded glib 2.39.4 source, compiled and installed it)
> >
> > But then there were issues big and small(er):
> >
> > (1) Denemo is segfault-ing when edit preferences, although, on first
> > run, I think it was NOT segfault-ing.  I was able to uncheck "Highlight
> > the cursor", click OK, and it didn't segfault at that point.
> at which point does it segfault?

When I invoke the Edit -> Preferences dialog and click "OK".  It happens 
when I don't change anything and click "OK".  It also happens when I 
change something and click "OK".  In the latter case, the change I make 
is effected (apparently, just before segfault-ing) and is seen in the 
next session.


> >    (BTW:
> > Hallelujah! end of forced scroll animation!  BIG BIG help.
> well, it sounds like you haven't fixed the drawing problem on your
> machine - how does it get on running gimp for instance?

I don't think I made myself understood.  I am jumping for joy over NOT 
HAVING the animation, finally.  I am happy! no need to change anything 
in this respect, now :-).  It's NOT animating anymore — neither the 
cursor, nor the scroller.  Thank you for that accommodation!

(I omitted the words "This is a..." in "This is a BIG BIG help")


> >   Thanks)
> >
> > (2) Contrary to what I was told in previous threads about copying my
> > .denemo-xxx/actions/actions/Default.commands and
> > .denemo-xxx/actions/Default.shortcuts :   copying just
> > "Default.shortcuts" is not enough to preserve all the laboriously
> > developed shortcuts.  One must apparently copy the Default.commands file
> > as well.  In a previous thread Richard or someone else warns against
> > copying over "Default.commands", saying that would mess up the command
> > set.  But if I don't copy it over I lose my shortcuts!
> You should not need to do this any more. When you started the new
> version (provided you had not externally created a directory
> called .denemo-1.1.2 before launching the new Denemo) you get a dialog
> offering to keep your settings.

I'll tinker with that some more.  I'm sort of confused; let me 
experiment and report back.

> What you can do in your circumstance is to copy Default.commands from
> the new distribution and Default.shortcuts from your
> old .denemo-xxx/actions directory. That should make all the commands
> available while keeping your shortcuts.
>
> > (3) Typeset music failing to render a file that is rendered fine by my
> > old (current) denemo 1.0.9
> This is usually caused by old LilyPond syntax that Denemo used to add
> for default beaming that 1.0.9 added to files by default. Execute the
> Score->Typesetter->Use Normal Beam Endings command to fix this. (If you
> haven't got Default.commands from the distribution, you will need to get
> that first as that menu is changed since 1.0.9 I suspect).

Hmm... I do have the "Use Normal Beam Endings" command in the menu, I 
click on it, it SEEMS to help (the error watermark seems to go away), i 
edit the score, see my edits rendered in the typeset window, I save the 
file, close denemo, re-open denemo and — Oops! — the typeset error 
message is back.  I've done this cycle, like, four times. Same result.

> > (4) More of a warning than issue, really:  Denemo xml files tend not be
> > backwards-compatible.  So, when I opened in 1.1.2 a pre-existing
> > *.denemo file generated/saved in 1.0.9, and FOOLISHLY re-saved it in
> > 1.1.2, I couldn't open it in 1.0.9 anymore.  Fortunately, apparently,
> > all I had to do was change the line
> >
> > <score xmlns="http://denemo.org/xmlns/Denemo"; version="7">
> >
> > to
> >
> > <score xmlns="http://denemo.org/xmlns/Denemo"; version="6">
> >
> > and that appears to have fixed the problem, this particular time.
> That would not work in general, but may give you something useful.
> Software generally isn't written to open yet-to-be-invented file
> formats, for obvious reasons, so 1.0.9 will not read the newer 1.1.2
> format.

Like I said, this is more of a warning (to me and to others, I guess)... 
I realize denemo is hardly at fault here... except maybe there could be 
a courtesy, fool-proof pop-up warning alerting that "If you are to save 
the current, older-version file", you won't be able to open it in the 
older versions of denemo. "

I simply lost focus and forgot about this phenomenon. (An alert would 
have reminded me)