nanogui: Thread: first experiments: problems

Hi all,

I am experimenting with nano-X on my development environment first, which
is the following:

- Ubuntu 8.04, on a VMWare virtual machine
- gcc 4.2.3
- zlib: 1.2.3.3

Building microwin on X went ok, after two small, superficial code changes.
I wasn't able to compile flnx samples, kept getting things like:

----------------------------
    g++ -I.. -O2 -Wall -Wno-return-type  -DNANO_X
-I/home/jorge/LCD/microwindows-latest/src/include
-DNANOXFOLDER='"/home/jorge/LCD/microwindows-latest/src/bin"' -DPDA
cube.cxx -L../lib -lfltk -lnano-X -DNANO_X=1 -L/usr/local/lib   
-L/home/jorge/LCD/microwindows-latest/src/lib -lnano-X -lm -o cube
    ../lib/libfltk.a(Fl.o): In function `Fl_Window::flush()':
    Fl.cxx:(.text+0x38c): undefined reference to `fl_clip_region(int)'
    ../lib/libfltk.a(Fl_arg.o): In function `Fl::arg(int, char**, int&)':
    Fl_arg.cxx:(.text+0x129): undefined reference to `XParseGeometry'
    ../lib/libfltk.a(Fl_arg.o): In function `Fl_Window::show(int, char**)':
    Fl_arg.cxx:(.text+0x4a5): undefined reference to `XParseGeometry'
    Fl_arg.cxx:(.text+0x5f9): undefined reference to `XChangeProperty'
    ../lib/libfltk.a(Fl_get_system_colors.o): In function
`getsyscolor(char const*, void (*)(unsigned char, unsigned char,
unsigned char))':
    Fl_get_system_colors.cxx:(.text+0x31): undefined reference to
`XParseColor'
-----------------------

Why does that happen? Anyway, I used fltk-1.1.9 (latest stable release) on
top of nxlib. Everything went ok in the build. By means of LD_LIBRARY_PATH
I was able to test fltk samples both with and without microwin. I tested
four builds of microwin, obtained by varying two parameters: (i) version -
microwin-0.19 versus the more recent snapshot available via ftp - and (ii)
HAVE_PCFGZ_SUPPORT. Here is what I observed:

1 - I could see no difference between versions, except when running Fluid
itself on nano-X, which does not work well anyway, but looks worse on
0.19;
2 - no windows could be resized nor moved, which is possible without nano-X;
3 - on nano-X, the samples respond to the keyboard, but in a completely
wrong manner. For example, when typing text in a textbox, characters do
appear, but obeying a messed-up keyboard map;
4 - when HAVE_PCFGZ_SUPPORT=Y, nano-X dies in fltk-1.1.9 sample "tile"
with the following messages:

----------------
   createfont: (height == 0) found builtin font System (0)
   createfont: (height == 0) found builtin font System (0)
   fnt_createfont: /usr/share/fonts/X11/100dpi/helvR12-ISO8859-1.pcf.gz,0
not found
   Segmentation fault
----------------

5 - when HAVE_PCFGZ_SUPPORT=n, nano-X works, but it seems that the font
cannot be loaded. As a result, text is written in just one size, while the
application originally specifies various sizes. Here are the messages
nano-X generates:

-----------------
   createfont: (height == 0) found builtin font System (0)
   createfont: (height == 0) found builtin font System (0)
   fnt_createfont: /usr/share/fonts/X11/100dpi/helvR12-ISO8859-1.pcf.gz,0
not found
   pcf_createfont: /usr/share/fonts/X11/100dpi/helvR12-ISO8859-1.pcf.gz,0
not found
   Nano-X-Freetype2: Can't load font from file
"/usr/share/fonts/X11/100dpi/helvR12-ISO8859-1.pcf.gz.ttf" - 1
   freetype2_createfont:
/usr/share/fonts/X11/100dpi/helvR12-ISO8859-1.pcf.gz,0 not found
   createfont: no font found, returning NULL
   fnt_createfont: /usr/share/fonts/X11/100dpi/helvR10-ISO8859-1.pcf.gz,0
not found
   pcf_createfont: /usr/share/fonts/X11/100dpi/helvR10-ISO8859-1.pcf.gz,0
not found
   Nano-X-Freetype2: Can't load font from file
"/usr/share/fonts/X11/100dpi/helvR10-ISO8859-1.pcf.gz.ttf" - 1
   freetype2_createfont:
/usr/share/fonts/X11/100dpi/helvR10-ISO8859-1.pcf.gz,0 not found
   createfont: no font found, returning NULL
   fnt_createfont: /usr/share/fonts/X11/100dpi/helvR24-ISO8859-1.pcf.gz,0
not found
   pcf_createfont: /usr/share/fonts/X11/100dpi/helvR24-ISO8859-1.pcf.gz,0
not found
   Nano-X-Freetype2: Can't load font from file
"/usr/share/fonts/X11/100dpi/helvR24-ISO8859-1.pcf.gz.ttf" - 1
   freetype2_createfont:
/usr/share/fonts/X11/100dpi/helvR24-ISO8859-1.pcf.gz,0 not found
   createfont: no font found, returning NULL
----------------

Thanks in advance for any pointers.

Cheers,

Jorge M. Pelizzoni.
ICMC - Universidade de São Paulo

:    Fl_get_system_colors.cxx:(.text+0x31): undefined reference to
: `XParseColor'
: -----------------------
:
: Why does that happen?

These usually happen because the above X11 library entrypoints
(XParseColor) aren't defined in NXLIB.  The stubs.c
file is useful in these cases.  However, in this particular case,
there's a library issue, since XParseColor is implemented in
NXLIB.

: 2 - no windows could be resized nor moved, which is possible without 
nano-X;

This is a nanowm window manager issue, since nano-X itself, like X11,
doesn't deal with window resize requests from the user directly.


: 3 - on nano-X, the samples respond to the keyboard, but in a completely
: wrong manner. For example, when typing text in a textbox, characters do
: appear, but obeying a messed-up keyboard map;

The keyboard map may need to be changed in NXLIB.  NXLIB
is forced to use an X11 style scancode oriented keymap,
which may be incorrect for your system.  Make sure you're
running TTYSCAN=Y in nano-X config.



: 4 - when HAVE_PCFGZ_SUPPORT=Y, nano-X dies in fltk-1.1.9 sample "tile"
: with the following messages:
:
: ----------------
:   createfont: (height == 0) found builtin font System (0)
:   createfont: (height == 0) found builtin font System (0)
:   fnt_createfont: /usr/share/fonts/X11/100dpi/helvR12-ISO8859-1.pcf.gz,0
: not found
:   Segmentation fault

Are you running a big-endian system?  This is likely a bug in the
nano-X PCF font subdriver.  They should be fixed in the
CVS source version, also available as a snapshot from the ftp site.





: ----------------
:
: 5 - when HAVE_PCFGZ_SUPPORT=n, nano-X works, but it seems that the font
: cannot be loaded. As a result, text is written in just one size, while the
: application originally specifies various sizes.

That's normal, as the .pcf files requested by fltk/nxlib aren't
loaded as the PCF driver is missing.

Regards,

Greg 

First of all, let me thank all of you for your very useful replies. Now
answering Greg's  message specifically:

Greg Haerr wrote:
> These usually happen because the above X11 library entrypoints
> (XParseColor) aren't defined in NXLIB.  The stubs.c
> file is useful in these cases.  However, in this particular case,
there's a library issue, since XParseColor is implemented in
> NXLIB.
>

However, this happens when I try to use flnx, not nxlib. Where can I find
stubs.c?

> : 2 - no windows could be resized nor moved, which is possible without
nano-X;
>
> This is a nanowm window manager issue, since nano-X itself, like X11,
doesn't deal with window resize requests from the user directly.

Sorry, my bad! I didn't know nanowm even existed :o) Everything works fine
now as regards moving and resizing.

>
> The keyboard map may need to be changed in NXLIB.  NXLIB
> is forced to use an X11 style scancode oriented keymap,
> which may be incorrect for your system.  Make sure you're
> running TTYSCAN=Y in nano-X config.

You mean TTYKBD=Y, right? Both TTYKBD=Y and SCANKBD=Y are set. I also tried
TTYKBD=Y and SCANKBD=N. By the way, what do they mean? Are they mutually
exclusive?

Anyway, nothing worked out. How can I change the keymap? I tried modifying
nxlib/keysymdef.h to no success...

>
> :   fnt_createfont:
/usr/share/fonts/X11/100dpi/helvR12-ISO8859-1.pcf.gz,0
> : not found
> :   Segmentation fault
>
> Are you running a big-endian system?

Nope.

> This is likely a bug in the nano-X > PCF font subdriver.  They should be
fixed in the
> CVS source version, also available as a snapshot from the ftp site.

I am using the snapshot and the problem persists. HAVE_PCFGZ_SUPPORT=Y
makes Nano-X segfault in that test case.

Thanks again for everything.

Cheers,

Jorge.

> > These usually happen because the above X11 library entrypoints
> > (XParseColor) aren't defined in NXLIB.  The stubs.c
> > file is useful in these cases.  However, in this particular case,
> there's a library issue, since XParseColor is implemented in
> > NXLIB.
> >
>
> However, this happens when I try to use flnx, not nxlib. Where can I find
> stubs.c?

Oh.  FLNX has nothing to do with NXLIB, it calls nano-X directly.
I don't recommend using FLNX, its very old, and limited to a
very old version of FLTK.

stubs.c is in NXLIB, but that's not an issue here since you're not using it.

> > The keyboard map may need to be changed in NXLIB.  NXLIB
> > is forced to use an X11 style scancode oriented keymap,
> > which may be incorrect for your system.  Make sure you're
> > running TTYSCAN=Y in nano-X config.
>
> You mean TTYKBD=Y, right? Both TTYKBD=Y and SCANKBD=Y are set. I also
tried
> TTYKBD=Y and SCANKBD=N. By the way, what do they mean? Are they mutually
> exclusive?

They are mutually exclusive.  Set only SCANKBD=Y, that will configure
nano-X to return scancodes, which X11 requires.  TTYKBD is
an ASCII only very basic kbd driver.


>
> Anyway, nothing worked out. How can I change the keymap? I tried modifying
> nxlib/keysymdef.h to no success...

Likely cause you're not running SCANKBD.  You may need to
look into the scancodes returned by nano-X in a debug session.


> I am using the snapshot and the problem persists. HAVE_PCFGZ_SUPPORT=Y
> makes Nano-X segfault in that test case.

We'll need a stack backtrace in order to debug.  I've received many
different, incompatible patches for the PCF driver.  Perhaps uncompress
the fonts and just run PCF_SUPPORT to see whether its related
to compression.

Regards,

Greg