I'm trying to learn X11. It's very hard to me, because I don't have experience with window applications on Linux.
I wrote some simple code and I can't resolve this not visible text problem.
Everything is working good probably, when I was trying to draw rectangle with DrawRectangle function it was working.
Here is the code:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <X11/Xlib.h>
int main()
{
Display* myDisplay;
Window myWindow;
int myScreen;
GC myGC;
XEvent myEvent;
unsigned long black, white;
char* hello = "Hello world!";
XFontStruct* myFont;
if((myDisplay = XOpenDisplay(NULL)) == NULL)
{
puts("Error in conneting to X Server!");
return -1;
}
myScreen = DefaultScreen(myDisplay);
black = BlackPixel(myDisplay, myScreen);
white = WhitePixel(myDisplay, myScreen);
myWindow = XCreateSimpleWindow(myDisplay, RootWindow(myDisplay, myScreen), 0, 0, 640, 320, 5, black, white);
XSelectInput(myDisplay, myWindow, ExposureMask);
XClearWindow(myDisplay, myWindow);
XMapWindow(myDisplay, myWindow);
myGC = XCreateGC(myDisplay, myWindow, 0, 0);
XSetForeground(myDisplay, myGC, black);
XSetBackground(myDisplay, myGC, white);
myFont = XLoadQueryFont(myDisplay, "-Misc-Fixed-Medium-R-Normal--7-70-75-75-C-50-ISO10646-1");
XSetFont(myDisplay, myGC, myFont->fid);
while(1)
{
XNextEvent(myDisplay, &myEvent);
if(myEvent.type == Expose)
{
XClearWindow(myDisplay, myWindow);
// HERE I DONT KNOW WHY IT DOESNT WORK!
XDrawString(myDisplay, myWindow, myGC, 0, 0, hello, strlen(hello));
}
}
XFreeGC(myDisplay, myGC);
XDestroyWindow(myDisplay, myWindow);
XCloseDisplay(myDisplay);
return 0;
}
Thank you for help!
Your font path argument to XLoadQueryFont is wrong (on my Linux/Debian desktop). Check with the xlsfonts command the right ones (they are all lowercases).
With
myFont = XLoadQueryFont
(myDisplay,
"-misc-fixed-medium-r-normal--9-90-75-75-c-60-iso10646-1");
it could work better. Try also with "lucidasanstypewriter-bold-14"
And most importantly the coordinates passed to XDrawString are wrong. Remember that they are the coordinates of the baseline of your text. And x=0, y=0 is the top left corner of the window, and y is growing downwards and x is growing to the right. Hence your text is drawn off-window, above its top. So y should be positive and more than the font height.
Try
XDrawString (myDisplay, myWindow, myGC, 15, 20, hello,
strlen (hello));
As I commented, you need to handle a lot more events.
I don't have experience with window applications on Linux.
And to learn about GUI programming, I strongly recommend first using some toolkit like GTK or Qt or perhaps SDL.
Raw X11 programming is too hard (and by the time you'll learn it is will be obsolete, e.g. by Wayland), in particular because an X11 application needs to be ICCCM & EWMH compliant. Notice that the entire X11 documentation requires nearly ten thousand pages.
See also https://tronche.com/gui/x/xlib/
BTW, most Linux GUI applications are drawing pixmap client side and sending it to the X11 server. Read about compositing window managers. Drawing requests like XDrawString are no more used anymore in practice. Recent font related libraries like libfontconfig, libXft, etc are working on the client side.
Related
I am trying to learn how to use Cairo 2D drawing library with xlib surfaces.
I wrote a little test program that allows creating multiple windows. Each function may have a custom paint() function that is called regularly to add some graphics content to the window, or redraw it completely if desired. There is also an option to define mouse and key listener. The main routine checks for X events (to delegate them to mouse and key listener) and for timeout for periodic call of those paint() functions.
I tried with the 1.14.6 version of Cairo (that is currently available as package in Ubuntu 16.04), and the latest 1.15.12, but the results are the same.
The expected behavior of this demo is to open 3 windows. One will have random rectangles being added, another one random texts, and the third random circles.
In addition, clicking into windows should produce lines (connecting to mouse click, or randomly), and using arrow keys should draw a red line in the window with circles.
The circles and text seem to show up regularly as expected. All three windows should have white background, but two of them are black. And the worst, the window with rectangles does not get updated much (and it does not matter if it is the first window created or not, it is always the rectangles that do not show up properly).
They are only shown when the focus changes to or from that window - then the remaining rectangles that should have been drawn meanwhile suddenly appear.
I am calling cairo_surface_flush() on the surface of each window after adding any content, but that does not help. I also tried posting XEvents to that window of various kind (such as focus), they arrive, but rectangles do not show up.
Furthermore, even though drawing lines with mouse works fine, drawing line with key arrows suffers from the same problem - it is drawn, but not shown properly.
I am obviously wrong in some of my assumptions about what this library can do, but I am not sure where.
It seems that there are some two competing versions of drawing being shown, since it happens sometimes that one or two rectangles, or pieces of the red line are flashing. Some kind of strange buffering, caching?
It may just be some bug in my program, I do not know.
Another observation - the black background is because drawing white background happens before the window is shown, and thus those cairo_paint calls are somehow discarded. I do not know how to make the window appear earlier, it seems it appears only after some later changes on the screen.
I am stuck on this after a couple of desperate days, could you help me out at least in part, please?
The program is here: test_cairo.c
An example screenshot (with a broken red line drawn by keys, and rectangles not showing up properly): test_cairo.png
To compile (on Ubuntu 16.04 or similar system):
gcc -o test_cairo test_cairo.c -I/usr/include/cairo -lX11 -lcairo
X11 does not retain window content for you. When you get an Expose event, you have to repaint the area described by that event completely.
All three windows should have white background, but two of them are black.
You create your window with XCreateSimpleWindow, so their background attribute is set to black. The X11 server will fill exposed areas with black for you before sending an expose event. Since you do not tell cairo to draw a white background, the black stays.
Try this:
--- test_cairo.c.orig 2018-07-28 09:53:10.000000000 +0200
+++ test_cairo.c 2018-07-29 10:52:43.268867754 +0200
## -63,6 +63,7 ## static gui_mouse_callback mouse_callback
static cairo_t *windows[MAX_GUI_WINDOWS_COUNT];
static cairo_surface_t *surfaces[MAX_GUI_WINDOWS_COUNT];
+static cairo_surface_t *real_surfaces[MAX_GUI_WINDOWS_COUNT];
static Window x11windows[MAX_GUI_WINDOWS_COUNT];
static char *window_names[MAX_GUI_WINDOWS_COUNT];
## -79,7 +80,12 ## long long usec()
void repaint_window(int window_handle)
{
draw_callbacks[window_handle](windows[window_handle]);
- cairo_surface_flush(surfaces[window_handle]);
+
+ cairo_t *cr = cairo_create(real_surfaces[window_handle]);
+ cairo_set_source_surface(cr, surfaces[window_handle], 0, 0);
+ cairo_paint(cr);
+ cairo_destroy(cr);
+ cairo_surface_flush(real_surfaces[window_handle]);
}
int gui_cairo_check_event(int *xclick, int *yclick, int *win)
## -149,7 +155,6 ## void draw_windows_title(int window_handl
sprintf(fullname, "Mikes - %d - [%s]", window_handle, context_names[current_context]);
else
sprintf(fullname, "Mikes - %s - [%s]", window_names[window_handle], context_names[current_context]);
- cairo_surface_flush(surfaces[window_handle]);
XStoreName(dsp, x11windows[window_handle], fullname);
}
## -179,20 +184,17 ## int gui_open_window(gui_draw_callback pa
}
if (window_handle < 0) return -1;
- surfaces[window_handle] = gui_cairo_create_x11_surface(&width, &height, window_handle);
+ real_surfaces[window_handle] = gui_cairo_create_x11_surface(&width, &height, window_handle);
+ surfaces[window_handle] = cairo_surface_create_similar(real_surfaces[window_handle], CAIRO_CONTENT_COLOR, width, height);
windows[window_handle] = cairo_create(surfaces[window_handle]);
mouse_callbacks[window_handle] = 0;
draw_callbacks[window_handle] = paint;
window_update_periods[window_handle] = update_period_in_ms;
window_names[window_handle] = 0;
-
- cairo_surface_flush(surfaces[window_handle]);
cairo_set_source_rgb(windows[window_handle], 1, 1, 1);
cairo_paint(windows[window_handle]);
-
- cairo_surface_flush(surfaces[window_handle]);
draw_callbacks[window_handle](windows[window_handle]);
## -201,7 +203,6 ## int gui_open_window(gui_draw_callback pa
else next_window_update[window_handle] = 0;
draw_windows_title(window_handle);
- cairo_surface_flush(surfaces[window_handle]);
window_in_use[window_handle] = 1;
return window_handle;
## -213,6 +214,7 ## void gui_close_window(int window_handle)
cairo_destroy(windows[window_handle]);
cairo_surface_destroy(surfaces[window_handle]);
+ cairo_surface_destroy(real_surfaces[window_handle]);
window_in_use[window_handle] = 0;
int no_more_windows = 1;
for (int i = 0; i < MAX_GUI_WINDOWS_COUNT; i++)
How do I get a bright white background with black text on it in ncurses, similar to the title-bar in nano? All I can seem to achieve despite following the advice in another question (which has to do with getting bright white text on a black background, the opposite of what I want to achieve), is an ugly beige-colored background.
Images:
GNU nano's titlebar, what I want.
What I get with the program below. (Build with gcc -lncursesw -I/usr/include minimal_example.c)
#include <locale.h>
#include <ncurses.h>
int main() {
setlocale(LC_ALL, "");
// Initialize curses library
initscr();
// Enable colors
start_color();
// Attempt recommendation in https://stackoverflow.com/questions/1896162/how-to-get-a-brightwhite-color-in-ncurses and other places on the web
use_default_colors();
// Make the COLOR_PAIR 0xFF refer to a white foreground, black background window.
// Using -1 will not work in my case, because I want the opposite of the default (black text on white bg), not the default (white text on black bg).
init_pair(0xFF, COLOR_BLACK, COLOR_WHITE);
refresh();
// Get our term height and width.
int x;
int y;
// & not required because this is a macro
getmaxyx(stdscr, y, x);
// Create a new window.
// TODO: Resize the window when the term resizes.
WINDOW *window = newwin(y,x,0,0);
// Try some other attributes recommended online, no dice. Putting this after the call to wbkgd() just makes the text look strange, does not change the background.
wattron(window,A_BOLD|A_STANDOUT);
// Set window color.
wbkgd(window, COLOR_PAIR(0xff));
// Draw a nice box around the window.
box(window, 0, 0);
// Write some text.
mvwprintw(window, 1, 1, "背景:不白");
wrefresh(window);
// Wait for keypress to exit.
getch();
// De-initialize ncurses.
endwin();
return 0;
}
I thought that perhaps there was something wrong with my terminal configuration (termite), but I was able to reproduce the problem in xfce4-terminal and xterm, both using the default configurations. The only way to fix this is to set my color7 and color15 to the same color as foreground, which obviously I do not want to do because that is non-standard and I want to distribute the larger application this code is used in.
(xfce4-terminal with the bug)
My recommendation is to define the bright colors (9 to 15) if there are at least 16 colors and can_change_color() returns true. Otherwise fall back to non-bright colors:
#include <stdlib.h>
#include <locale.h>
#include <ncurses.h>
#define PAIR_BW 1
#define BRIGHT_WHITE 15
int main(void) {
int rows, cols;
setlocale(LC_ALL, "");
initscr();
start_color();
use_default_colors();
if (can_change_color() && COLORS >= 16)
init_color(BRIGHT_WHITE, 1000,1000,1000);
if (COLORS >= 16) {
init_pair(PAIR_BW, COLOR_BLACK, BRIGHT_WHITE);
} else {
init_pair(PAIR_BW, COLOR_BLACK, COLOR_WHITE);
}
refresh();
getmaxyx(stdscr, rows, cols);
WINDOW *window = newwin(rows,cols,0,0);
wbkgd(window, COLOR_PAIR(PAIR_BW));
box(window, 0, 0);
mvwprintw(window, 1, 1, "背景:不白");
wrefresh(window);
getch();
endwin();
return EXIT_SUCCESS;
}
This is tested to work in Gnome Terminal 3.18.3 and XTerm 322, and it should work in all color-capable terminals if using ncursesw (although on some weird ones you might still get the non-bright-white background).
Colors in terminal emulators are a bit of a mess. Your problem is that that gray background really is "white" according to your terminal! Check out this table on Wikipedia. See how gray-looking the "White" row is across all the different terminal emulators? What you really want is "bright white", which is beyond the 8 initial colors. The problem is that, according to curses:
Some terminals support more than the eight (8) “ANSI” colors. There
are no standard names for those additional colors.
So you just have to use them by number and hope that everyone's terminal conforms to the tables on Wikipedia (I think most do).
init_pair(0xFF, COLOR_BLACK, COLORS > 15 ? 15 : COLOR_WHITE);
That's all you need, so you can get rid of all that other use_default_colors and A_BOLD stuff.
Old answer:
The curs_color manual says
Note that setting an implicit background color via a color pair affects only character cells that a character write operation explicitly touches.
...
The A_BLINK attribute should in theory cause the background to go bright.
Indeed, if you just change
wbkgd(window, COLOR_PAIR(0xff) | A_BLINK);
You get a bright white background, but only in areas where text was drawn (including the window border). I'm not sure how to get the same effect over the entire window background, but hopefully this can get you started.
This change (assuming TERM=xterm-256color) does what was asked:
> diff -u foo.c foo2.c
--- foo.c 2017-10-06 15:59:56.000000000 -0400
+++ foo2.c 2017-10-06 16:10:11.893529758 -0400
## -7,10 +7,9 ##
initscr();
// Enable colors
start_color();
- // Attempt recommendation in https://stackoverflow.com/questions/1896162/how-to-get-a-brightwhite-color-in-ncurses and other places on the web
- use_default_colors();
- // Make the COLOR_PAIR 0xFF refer to a white foreground, black background window.
- // Using -1 will not work in my case, because I want the opposite of the default (black text on white bg), not the default (white text on black bg).
+ // redefine colors, using the initc capability in TERM=xterm-256color
+ init_color(COLOR_BLACK, 0, 0, 0);
+ init_color(COLOR_WHITE, 999, 999, 999);
init_pair(0xFF, COLOR_BLACK, COLOR_WHITE);
refresh();
// Get our term height and width.
But nano doesn't do that. You might find it helpful to read its source-code, to see that it solves the problem by using the terminal's default colors.
I've been programming a small text adventure game using SDL2 recently and have come across an issue with line wrapping. I am using TTF_RenderText_Blended_Wrapped() to render my strings, and this gives me some nicely wrapped lines. But The line height is an issue, the lines seem squished together, and letters like 'jqg' overlap with letters like 'tli'.
Does anyone know if there is a way to change the line height? TTF_RenderText_Blended_Wrapped() still isn't even in the documentation for SDL_ttf. Should I just write my own text wrapping function?
The font size is 16pt, styling is TTF_STYLE_BOLD, and the font can be found here. The code below should reproduce the error, there is almost no error checking though, use at your own risk. Here is the output of the code:
#include <stdio.h>
#include <SDL2/SDL.h>
#include <SDL2/SDL_ttf.h>
int main(int argc, char *argv[]) {
SDL_Window *gui;
SDL_Surface *screen, *text;
SDL_Event ev;
TTF_Font *font;
int running = 1;
const char *SAMPLETEXT = "This is an example of my problem, for most lines it works fine, albeit it looks a bit tight. But for any letters that \"hang\" below the line, there is a chance of overlapping with the letters below. This isn\'t the end of the world, but I think it makes for rather cluttered text.\n\nNotice the p and k on line 1/2, and the g/t on 2/3 and 3/4.";
// init SDL/TTF
SDL_Init(SDL_INIT_EVERYTHING);
TTF_Init();
// Open and set up font
font = TTF_OpenFont("Anonymous.ttf", 16);
if(font == NULL) {
fprintf(stderr, "Error: font could not be opened.\n");
return 0;
}
TTF_SetFontStyle(font, TTF_STYLE_BOLD);
// Create GUI
gui = SDL_CreateWindow("Example", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
640, 480, SDL_WINDOW_SHOWN);
// Grab GUI surface
screen = SDL_GetWindowSurface(gui);
// Clear screen black
SDL_FillRect(screen, NULL, 0);
// Draw some text to screen
SDL_Color color = {0xff, 0xff, 0xff, 0xff};
text = TTF_RenderText_Blended_Wrapped(font, SAMPLETEXT, color, screen->w);
SDL_BlitSurface(text, NULL, screen, NULL);
while(running) { // Main loop
while(SDL_PollEvent(&ev)) {
switch(ev.type){
case SDL_QUIT:
running = 0;
break;
}
}
SDL_UpdateWindowSurface(gui); // Refresh window
SDL_Delay(20); // Delay loop
}
// Destroy resources and quit
TTF_CloseFont(font);
TTF_Quit();
SDL_FreeSurface(text);
SDL_DestroyWindow(gui);
SDL_Quit();
return 0;
}
The easiest solution is to find a font that doesn't have that issue. The FreeMono font has more spacing:
From looking at the source code for TTF_RenderUTF8_Blended_Wrapped, which is called by TTF_RenderText_Blended_Wrapped, there is no configurable way to set the spacing between the lines. See const int lineSpace = 2; on line 1893.
However, even though lineSpace is set to 2, it is not being used when computing the address of each pixel to render. This is effectively setting the line spacing to 0. I reported this as a bug in the SDL_ttf library: https://bugzilla.libsdl.org/show_bug.cgi?id=3679
I was able to fix the issue in SDL_ttf 2.0.14 with the following change:
--- a/SDL_ttf.c Fri Jan 27 17:54:34 2017 -0800
+++ b/SDL_ttf.c Thu Jun 22 16:54:38 2017 -0700
## -1996,7 +1996,7 ##
return(NULL);
}
- rowSize = textbuf->pitch/4 * height;
+ rowSize = textbuf->pitch/4 * (height + lineSpace);
/* Adding bound checking to avoid all kinds of memory corruption errors
that may occur. */
With the above patch applied, your example program shows the correct line spacing with the Anonymous font:
I want to create 2 windows in linux that I'll later draw in from a separate thread. I currently have a non-deterministic bug where the second window that I create sometimes doesn't get created (no errors though).
Here is the code.
static void create_x_window(Display *display, Window *win, int width, int height)
{
int screen_num = DefaultScreen(display);
unsigned long background = WhitePixel(display, screen_num);
unsigned long border = BlackPixel(display, screen_num);
*win = XCreateSimpleWindow(display, DefaultRootWindow(display), /* display, parent */
0,0, /* x, y */
width, height, /* width, height */
2, border, /* border width & colour */
background); /* background colour */
XSelectInput(display, *win, ButtonPressMask|StructureNotifyMask);
XMapWindow(display, *win);
}
int main(void) {
XInitThreads(); // prevent threaded XIO errors
local_display = XOpenDisplay(":0.0");
Window self_win, remote_win;
XEvent self_event, remote_event;
create_x_window(local_display, &remote_win, 640,480);
// this line flushes buffer and blocks so that the window doesn't crash for a reason i dont know yet
XNextEvent(local_display, &remote_event);
create_x_window(local_display, &self_win, 320, 240);
// this line flushes buffer and blocks so that the window doesn't crash for a reason i dont know yet
XNextEvent(local_display, &self_event);
while (1) {
}
return 0;
}
I don't really care for capturing input in the windows, but I found a tutorial that had XSelectInput and XNextEvent (in an event loop) and I was having trouble making this work without either.
It's not a bug, it's a feature. You left out the event loop.
Although you cleverly called XNextEvent twice, the X protocol is asynchronous so the server may still be setting up the actual window while you call XNextEvent, so there is nothing to do.
Tutorial here.
I recently started using Dev C++ 4.9.9.2 to experiment with graphics program in C(thanks to this tutorial). But for some reason setbkcolor() does absolutely nothing. Here's the code...
#include <stdio.h>
#include <graphics.h>
#include <conio.h>
int main()
{
initwindow(800,600);
setbkcolor(GREEN); //FAILED. also tried "setbkcolor(2);"
while ( !kbhit() ){}
return 0;
}
Here's the Output:
I am using Windows 7 Professional. Is this something to do with the Operating System?
The documentation says in the Windows notes part:
Also, only future drawing will use the new background color (anything currently drawn in the old background color will stay in the old color). Calling setbkcolor(0) will change the background color to the current color at index [0] of the palette (rather than always changing the background to black).
You have misunderstood the goal of the function.
since the window is drawn before even setting the background color.
use cleardevice() after setting the background color to recreate the screen.
#include<stdio.h>
#include<graphics.h>
int main()
{
int gd = DETECT, gm;
initgraph(&gd, &gm, "");
setbkcolor(GREEN);
cleardevice();
getch();
closegraph();
return 0;
}