Change background color in Linux Glk

I’m trying to change a window’s background color in a Linux application that uses the Glk library.

The library I’m using is glktermw-104.tar.gz downloaded from It compiles ok and I can run my application. But the window is white tekst on black background where I expected it to be white on blue. I’m pretty sure it’s not my code, because when I build the same application with Glk for Windows the background color change works. The readme for glktermw also indicates that not all stylehints may work.

I’m using the function glk_stylehint_set() with attribure stylehint_Backcolor, but with no visible result. To investigate this I called glk_style_measure() for stylehint_backcolor and it returns 0. According to the Glk spec that means it cannot find this attribute, which explains why it’s not changed.

Is there another way to change background and text colors? With the non-Glk version in Linux I send Ansi escape codes to change colors but that doesn’t seem to work with Glk.

I appreciate any help!

Not all Glk libraries support stylehint s. Glkterm and Remglk both do not currently support them. The other thing is that colors in Glk must be set before the window is opened:

Sorry for my late follow up, I haven’t worked on the Linux version for a while.

I have a function CreateGlkWindows() that kicks off the main story window and the status window above it.

[code]int CreateGlkWindows()
/* set styles text color, background color and bold font size for styles Normal, Alert and Note */

/* Open the main window. /
mainwin = glk_window_open(0, 0, 0, wintype_TextBuffer, 1);
if (!mainwin) {
failed to open. */

/* Set the current output stream to print to it. */

/* Open the status window above the main window. /
The status window is a text grid,three lines high. */
statuswin = glk_window_open(mainwin, winmethod_Above | winmethod_Fixed,
3, wintype_TextGrid, 0);

if (!statuswin) {
/* failed to open */

First thing it does is call SetGlkStyles()

[code]void SetGlkStyles()
/* set styles text color, background color and bold font size for styles Normal, Alert and Note */
glk_stylehint_set(wintype_TextBuffer, style_Normal, stylehint_TextColor, 0x00FFFFFF);
glk_stylehint_set(wintype_TextBuffer, style_Normal, stylehint_BackColor, 0x00000084);

glk_stylehint_set(wintype_TextBuffer, style_Alert, stylehint_TextColor, 0x00FFFFFF);
glk_stylehint_set(wintype_TextBuffer, style_Alert, stylehint_BackColor, 0x00000084);

glk_stylehint_set(wintype_TextBuffer, style_Note, stylehint_TextColor, 0x00FFFFFF);
glk_stylehint_set(wintype_TextBuffer, style_Note, stylehint_BackColor, 0x00000084);

glk_stylehint_set(wintype_TextBuffer, style_Alert, stylehint_Size, -1);

glk_stylehint_set(wintype_TextGrid, style_Normal, stylehint_TextColor, 0x00000084);
glk_stylehint_set(wintype_TextGrid, style_Normal, stylehint_BackColor, 0x00FFFFFF);

glk_stylehint_set(wintype_TextGrid, style_Alert, stylehint_TextColor, 0x00000084);
glk_stylehint_set(wintype_TextGrid, style_Alert, stylehint_BackColor, 0x00FFFFFF);

glk_stylehint_set(wintype_TextGrid, style_Note, stylehint_TextColor, 0x00000084);
glk_stylehint_set(wintype_TextGrid, style_Note, stylehint_BackColor, 0x00FFFFFF);

glk_stylehint_set(wintype_TextGrid, style_Normal, stylehint_Size, -1);
glk_stylehint_set(wintype_TextGrid, style_Note, stylehint_Size, -1);
glk_stylehint_set(wintype_TextGrid, style_Alert, stylehint_Size, -2);

glk_stylehint_set(wintype_TextBuffer, style_Input, stylehint_Weight, 0);

/* stylehints for user input representation */
glk_stylehint_set(wintype_TextBuffer, style_Input, stylehint_TextColor, 0x00FFFFFF);
glk_stylehint_set(wintype_TextBuffer, style_Input, stylehint_BackColor, 0x00000084);

So, given this same code does work in Windows, can we indeed say that stylehints are not implemented in the linux glkterm library?

If we are talking the same “glkterm”, here is the source code, and the comment says it ignores them (and the code for these methods looks empty like RemGlk which I have worked with more - and I did add a way for StyleHints to work) … tyle.c#L15 (on current line 15)

Now, the one thing I have picked up on is that graphics windows are supposed to support background colors in all implementations… and that is true of RemGlk (which added graphics windows in the past couple months). Some stories use ‘border windows’ that don’t actually have any images in them just to draw color rectangles. However, GlkTerm may by it’s nature not support graphics windows.

you could add code to glkterm. I’ve worked with Fizmo via ncursesw and it does support text color changes for Z-machine. But, it doesn’t try to be a Glk independent of Z-machine like GlkTerm is doing. ref:

I use glktermw-104.tar.gz that I downloaded from to make the library. I checked the file gtstyle.c and it’s the same as you pointed to on github. So the functions I’m calling do nothing.

I don’t know if I will be able to implement thee functions in gtstyle.c. I don’t need a Glk interpreter, only the Glk library because I integrate it with my own interpreter.

I ran into the same problems building a customer interpreter and wanting colors. Are you actually needing to run in a terminal? Or is more ‘normal’ graphics mode allowed - such as SDL / GTK / QT?

The most feature-complete Glk library for desktop Linux doesn’t seem to be released as a stand-alone library itself, and that’s the one in Gargoyle (GarGlk widget. But both of these “Glk” libs for Linux aren’t really “packaged” like CheapGlk/GlkTerm/RemGlk as portable Glk and more bundles of interpreters (an app). There are others floating around like NanoGlk that kind of got overlooked by multiple people (I tried to revive it a few months ago but really don’t have the C programming skills and people who expressed interest in developing SDL 2.0 Glk one year ago disappeared off the forum here).

If you are adapting a new interpreter to Glk and developing on Linux - I would consider checking out the latest GarGlk and making your new interpreter a parallel interpreter to the sixteen interpreters already in that code:

For sake of clarity on terminology, Glk is not an interpreter, it is only the presentation library. An app would be to bundle a Glk + Interpreter. But it’s kind of confusing around here because sometimes people call “apps” like Gargoyle as “interpreters”. In my own work, I am calling “interpreters” as “engines” (virtual machines) to make it more clear… as it took me considerable time to understand what was what.

I ended up with the terminal because I wrote my interpreter from scratch in plain C code. This was in the MS-DOS era. The only way I found to get it working on windows and Linux was by selecting Console Application in the IDE. Recently I wanted, like you, more flexibility on fonts, tekst and background color, split windows etc. Glk offered this, so I integrated it in my Interpreter. Something else would do as well, but I only have plain C code to integrate it with. I am going to check out your suggestions.

My mistake, I knew that. What I meant to say is that I do not need an interpreter with Glk functionality because my story files are not Z-code, but proprietary byte code. The GLK version of my interpreter is in fact the terminal version with the C printf() function calls replaced by Glk function calls.

You are on the right path, and Andrew Plotkin has done a ton of work to keep these things going in various flavors. Plain C code is exactly what a lot of these interpreters are written in, and adapting prtinf() to glk calls is how a lot of these previously independent apps converged into being bundled into Gargoyle over the decades.

As an example, look at how this 1986 C interpreter, AdvSys is integrated into Gargoyle and it’s Glk: … rps/advsys

Best wishes on your project!

I’m not sure if I understand everything. In the github project I see a folder ‘terps’ with subfolders for all kinds of interpreters. Do I understand correctly that in Gargoyle all these interpreters (or their Glk-enabled versions) have been compiled and that - based on story file format - Gargoyle selects the correct interpreter to play with?

Yes. And there are even competing ‘terps’ for the same ‘story file’, for example there are several that can run Z-machine and two for running Glulx (“Git” and “Glulxe” with “e” at the end). You can revise the .ini file to specify patterns of which ‘terp’ gets picked for a data file, look at the very bottom of this one for examples of it picking ‘frotz’ or ‘nitfol’ Z-machine interpreter based on the file extension: