Xchar test suite

I use these arrays to feed the input to Xchars, I am halfway through, it is a leisurely process. But notice the hierarchy.

1) Caller has t get a conn: NewConn Myconn;
2) Caller gets one or more windows and one or more GC, graphics contexts.
3) Caller then creates rects within windows and stuffs text into rects.  The rect is redrawn, one way or the other, when the caller puts text to rect. Not to difficult, or their is one thing, The caller has a:
DrawRect rect gc; , not shown. But it connects the GC to the rect an draws. The GC stays connect to rect until another DrawRect is made. Very simple, do it from the command line.

The system measures font sozes and sets line height, mostly.  The symbol table is fast, but limited to eight character names.  The system would make a great interface for font based strategy games of all sorts. When xcb wants a redraw of the screen, Xchars will just go though the symbol list and find rects within the redraw area. Thus it needs to retain the attached gc entry.

The xcb system is a good system, even under Wayland architecture, xcb is a still good interface to a rendering client.

char *t1[] ={"NewConn","Myconn"};
char *t2[] ={"NewWin","Myconn","Mywin"};
char *t3[] ={"NewGC","Myconn", "Mygc"};
char *t4[] ={"SetRGB","Myconn","Mygc","100","101","102"};
char *t5[] ={"NewRect","Mywin","Myrect","20","20","60","70"};
char *t6[] ={"PutStr","Myrect","HelloWorld"};

 I used a trick on xcb. I created a structure that held each of the major xcb_thing_t that I might need, froms canning the examples. Then I cutnpaste their example and replace the arguments with: my_xcb_creatcontex_checked(Box * b){}

So in their code when they had something like:
screen = data.iter, which I barely know, I replace with: b->screen=data.iter.

So, though I barely now the details, at least I am making the calls and collecting xcb things, thus learning the sequence of filling up a box of xcb things. Helped a lot, I am keeping it.  As the caller makes his calls into Xchars, it is filling its box A caller is fills the xcb box on a per connection basis, so I keep one box per connection.  The box will hold the last valid settings of for that connection, up to rect, then wins handle rects. Box don't do rects.

By the way:
 Here is an example of redneck programming at its finest. In China they would throw me in gcc jail for pulling this stunt. But there ain't no gcc warning machine beat me. I use he same names in structures as xcb examples, it is almost a search and substitute. But I have done this, gone through these graphics interfaces many times.

typedef union {
unsigned long l;
char * s;
void * vp;
EntryType * entry;
char txt[8];
xcb_font_t font;
xcb_screen_t *screen;
xchars_rect_t *rect;
xcb_window_t win;
xchars_gc_t gc;
xcb_connection_t *conn;
Box * box;
} Val;

Google bots self train

My search results look different than the search bot identifies my search words as a compact grammar graph, changes their significance the word matching.

That is what join is all about, at least my version of it. Distributed join machines pouring over text with refining word lists until the text is understood enough. My approach is to build it in at the sub layers, make eh tech available for everyone and Intel is on my side.

Xchars, new tech, starting to work

The new tech is he symbol table I stuck up front of old Xchars. Its helps a lot with maintaining proper xcb order of events. The caller need only remember their the name they gave for the new xcb variable.

I have NewCon and NewWin both works, again, from the command line. Rectangles are new, something that hold a block of text on the screen. Haven'r tested them yet. Nor have I text draw DrawText which requires a graphic context.

The hierarchy is enforced at the command line sequence, connect first, window next, rect where needed,m and so on. I can look in the symbol table and tell if the pre-requisites for a xcb cal are met.

This is a no brainer replacement for regular terminal emulation.

The new Xchars interface

I made it a bit hierarchical.

NewConn conn;       // Gets a connection, assigns it to name conn
NewGC conn gc;      // Gets a new gc names it gc if the given conn exists
NewWin conn win;  // As above
NewRect win rect;   // as above, a new rect depends on a valid win

SetColot gc color;   // color is an rgb value
SetFont gc font;      // font is a string
PutStr rect str;        // puts the string to rect,d eleting the previous string
WriteRect rect gc;  //  both rect and gc must be defined.
ClearRect rect gc;        // set rect to background color, deletes string.

You cannot put anything to screen without a valid gc and rect, there is no default gc. Gces are free floating, tied to screen->root. Al marking of text if via a rect. Both must be specified.

A lot of repetition in converting from symbol to xcb calls. But the set up for each call is less than ten lines.  The other side, the xcb interface is still a bit of spaghettit, but I am squashing that.

Nine API, simple, hierarchical, limited to strings  perfect architecture for a new power shell. Total line count will be under 500. Get this done, then look at capturing mouse and key strokes.  But interaction is simplified, I pass cursor processing back to clients. Xcharsshould run on a thread.

I posted a rough copy. This approach is clearly a winner to replace xtermios or ncurses. Built on xcb, it doesn't really need wayland.  Managing strings is fast, easily deleted and replaced. They are meant to be temporary, this is still a bit of emulating the old time press.  The keyboard and mouse IO will be a breeze, the polling loop already set up.   Console will do the default, just manage a command line rect, letting the loadable use the rest of a window, or creating their own..

We have them as young as 16 in Calizuela

Venezuelan Women "As Young As 14" Escape Socialism By Selling Sex, Hair And Breastmilk

A year of Gavin and we have a shot at the title.

Xchar, progress

I was interested in putting a symbol table on the font end of Xchars, and I did. There are four type of symbols, connections, windows, graphics contexts and rectangles. String are attached to rectangles, are not symbol managed.
Rects have to have windows which need connections.  Graphics contexts are ad hoc, and there is a default graphics context. Color and font can be set on any graphic context. Graphics context can be attached to rectangles and windows.

So the hierarchy is fairly simple and he construction of arguments to xcb is driven by the symbol table look ups.  The xcb utilities backing this up are cutnpaste spaghettit from the xcb tutorials.

GC commands look like

NewGC mygc color font;  // color and font optional
SetGC mygc color font;

and the usual:
NewWin, NewRect, PutString.   Rects are key, a string is attached to a rect,and it is rectangles that get drawn or filled. It seems to work, it is not automatic, but close to cutnpast. Makes using Xchar loadable fairly easy.

Silly me, I thought that was invented years ago.

20-something men invent underwear you can wear for weeks without washing

My Xchars version 2 plan

XZchars version one has the mutilities to open and write to a window, and I have the utility to change font or color.  So I keep all those utilities, and jus slip in a symbol table, fast and short, so callers can use plain text ids to reference variables. A mere additional 100 lines of code.  Currently all the utilities take argc and args format, not a problem. A simple reformat looks like:


args[*argc]=GetSym(args[*argc];  // Replace the args position with its symbol look up

So,  Xchars accepts plain text ids for string rectangles, connections, windows. Simplifies:

NewWind conn rect win;  //  conn and win all plain text ids. 

 rect give the window position and size. The rectangle structure holds identifies were a block of text goes.

So NewWin has linux format going in and linux format in the call to new_windows utility, the args just reformatted on input, like a macro expansion on input. They still retain univesal interface.

Mappingthe xcb functions

We like:

NewConn myconn;
NewWindow mywin myconn; // Standard linux command
StrOut mywin "Hello World" 1,2; // write text at char positions 1,2

The tokens, mywin and myconn have become symbol entries in Xchars, which has a simple and fast symbol table.  There exists a mechanical map that unfolds the script request into xcb calls, correctly. It can be constructed automatically, and I experimented with it.  I know how to defeat the gcc warning machine.   The symbol entry mywin points me to  a map and a connection. The map correctly constructs the call as:

PolyFill mypoly:  // becomes:

arg[0].polyfill(arg[1].conn,arg[2].drawable,arg[3].gc,i,arg[4].rect);

Say What? A text processing machine takes the proto.h file from xcb and creates these forms using unions. So the interface to xcb knows nothing except how to select argument types from a map. Most of the precmpile text processing can be cut paste and replace in a text editor.

I have sample typedefs doing this below the fold.  The text processing machine adds to the union and identifies the union selector. The c code all automatically generated, when said and done. The process drivenby the symbol table entries and precompiled mappings.

Xchars does not manage text blocks

A request to modify a text block overlaps, Xchars does not keep track.  A good thing, it keeps Xchars down to the bare minimum, obey the edict, just do a small part then chain all the small parts together under upper level syntax control. Xchars is mostly abut holding and modifying blocks of strings, a tiny database. It writes screen almost by happenstance, someone has to do it.   The entire system of loadables, all coordinating, become the compositor.  If you need charts, load a chart machine. Want a new window, grab one.  So give Xchars a pass through function, my plot.  Then I plan to experiment, via a second module, with xcb graphics, and I don't have the hassle of set up, I call: get_window at exec command in args format, and I get a window and can send pass throughs to xcb, hopefully.  Xchars is really the xcb interface, it just happens to carry a hundred lines of strings, and works a string write on behalf of clients.

All calls to xcb consist of a list of argument, length fixed, and some arguments are 32 bit, some 64 bit.  The mappings are simple to set up, an I have devious methods to defeat gcc and its warning machine. So I set up the fastest map from args to xcb.  Like two or three lines of code. I went hrough this in a previous post. 

Look, a world of snippets, organizable by high level syntax engines. Taking the hardware analogy a bit further, these snippets are devices that hang on the Bus, where console loop is Bus DMA controller. Args list are the copper traces. Good model.