Re: [Denemo-devel] problems with 1.1.2

[Jeremiah Benham]

On Feb 12, 2014 10:47 AM, "Bric" <address@hidden> wrote:
>
> 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.
>

I experience the same thing with the mac build.

>
>
>>>    (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?

Just out of curiosity... Do you have hardware graphic acceleration? I believe the command to find out is:
glxinfo
It will say so in the first few lines of output.

Jeremiah

>
>
> 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)
>
>
>
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel