Re: [XBoard-devel] new developer release out

[Tim Mann]

Oops, I meant to say that the web site implies Pango can work without GTK. But I don't know how true that is in practice with libraries that are packaged for Linux.

On Sun, Mar 13, 2016 at 4:24 PM, Tim Mann <address@hidden> wrote:

You can make the .o file dependent on the Makefile itself, or on whatever file sets the compiler and linker options. Most people don't do that because it ends up recompiling everything too often.

Pango's web site claims it can work without Cairo. How true that is in practice with libraries that packaged for Linux, I don't know.

http://www.pango.org/

On Sun, Mar 13, 2016 at 4:04 PM, <address@hidden> wrote:

Op Zo, 13 maart, 2016 11:27 pm schreef Arun Persaud:
>
> Could be because of the recent change in configure.ax? Before we always
> had GTK on, even if Xaw was chosen, so perhaps some more variables were
> set. Would have to look at it more closely, so this is just a guess.
>

Well, I expect it is an intrinsic limitation of the make process. It is
just nor smart enough to understand that when you make a change to
compiler or linker options, that also .c files that have not been changed
need to be recompiled.

>
> If we are not using cairo in the X version, we probably should move it
> the cairo call to gtk.
>

The Xaw version also depends on cairo for drawing, but it is cairopango
that causes the problem. I guess pango is something specific for GTK and
its fonts. The intention was that Xaw would use it too. So far drawing the
board has always been exactly the same in Xaw and GTK, and I don't see why
it should be different. It has nothing to do with the widget set, it just
draws on an intenal memory bitmap. But the problem was that the normalway
of rendering text on the board (for the coordinates) did only work for
simple ascii, and not for arbitrary UTF8 text. (So no Japanese kanji...)
This is how I ended up with pango.

But apparently pango is only available with GTK. I have no idea how I
could render kanji with cairo in the Xaw version then. So the proposed
change would remove this feature from the Xaw version.

>
> Guess the etc stuff is not a problem... I just started xboard (just to
> see if it runs from the tar-ball) and got the pieceImageDirectory warning.
> I was just wondering, if it is worthwhile to add something, so
> that xboard knows if we run a non-installed version and perhaps looks for
> missing items in the source directory... assuming it was started from the
> source directory. That way you might be able to run a test-version without
> installing it, which could be nice for developing?

Well, even during developing hardly anything ever changes in the files
that need to be installed. (Adding new piece images is one of the
exceptions, and I hardly ever do that.) So normally I indeed do not
install, and just run ./xboard in the tar ball. In the rare case I add new
components that need to be installed typing "sudo make install" is hardly
taxing.

A real problem was that new versions keep using the (non-installed) user
settings file of the previously run version. This used to crash an older
version after running a newer one that had more persistent options. But
making encounter of an unrecognized option in a settings file no longer a
fatal error (skipping to the next line is an acceptable recovery method)
made that bearable. Switching between Xaw and GTK builds was a problem
because they used totally different values for the same font options.
(X-fonts look like "*-*-*-*-*-helvetica-*-*-*", while GTK fonts looke like
"Sans Normal".) Seeing each other's font settings caused crashing. So I
built in some code to recognize font settings of the type that would cause
a crash, and ignore those. That means you lose your font settings when
running the other build. But when I want to avoid that I simply run as
"xboard -ini foo", which redirects saving to foo, so that the original
user settings file is protected from change. Or I immediately switch of
"save settings on exit" after startup.

H.G.