Re: [Denemo-devel] New Binaries?

[Richard Shann]

First I'll clear up the bizarre behavior when you set the label
completely empty:

On Wed, 2015-06-17 at 10:06 -0500, Jeremiah Benham wrote:
> 
> When I ran this after deleting .denemo-* I got some interesting
> results. The first time and every subsequent time the label was NULL.
> It always return invalid utf8. I tried deleting the field completely
> leaving it blank. This rusted in label *not* being NULL. Then every
> time editing after that the label was always non NULL and it would not
> save anything I placed in the field after hitting ok. If I tried to
> edit the label the dialog box popped up empty. I put something in the
> field that would appear (incorrectly as usual) on the button but when
> I edit this again the dialog would be empty again. The utf-8
> validation check failed every single time except once when I used an
> official Apple font. It did return as valid utf-8 but still did not
> display correctly in the button or the dialog box when pasted. Each
> time I can see the intended font in the command line terminal output
> from the printf! 

What is happening here is that whatever text you give for the palette
button it first looks to see if there is a file of that name in the
pixmaps directory: find_denemo_file (DENEMO_DIR_PIXMAPS, newlabel);
the reason is, you can have buttons with images not GtkLabels.
fermata.svg is one such.

So if newlabel is an empty string the find_denemo_file
(DENEMO_DIR_PIXMAPS, newlabel) finds the pixmaps directory and the code
proceeds thinking it has an icon for this palette button. So that is a
bug. I've fixed this bug in git now.

So, for fixing this problem with the text labels on palettes we should
entirely ignore the case where the label starts non-null, we are only
interested in the case where it is set via

label = gtk_button_get_label (GTK_BUTTON(button));

which is where the button contains a GtkLabel with some text in it.

Your earlier email (with image of output) showed 

Is newlabel valid utf8 == 1

where newlabel held the treble clef glyph. I think the buggy situation
that results from returning a NULL string from the dialog has confused
things, because in the above email quote you say "The utf-8 validation
check failed every single time" ie you were getting invalid utf-8, but I
hope this isn't the normal case. Please re-test with the new git master.

I think what you will have is that when you paste a treble clef glyph
into the dialog it displays in the dialog badly and then is put into the
label and displays on the button badly. But it is in fact valid utf-8
being passed to the gtk_label_set_markup (), which is *not* complaining
about what it is getting as being invalid utf-8.

So I think we have it nailed down to the backend - after we have fed Gtk
with the correct string something converts it to UTF-16 and, unless it
is one of those characters that are the same (such as ASCII or the sharp
sign) then it fails to display it properly.

I now think that the libxml2 idea is very unlikely to be involved - it
uses the same routines to set the label markup as the hand editing.

So, either this is an unfixed bug in the Gtk/Pango stuff for the Mac or
the build of the Gtk libraries is not right (e.g. are there flags to say
what encoding the OS expects? and what has changed since before when it
worked?).

Richard