Re: a wishlist [Re: getting things moving]

  • From: Tor <tor@xxxxxxxxxxxxxxx>
  • To: wilyfans@xxxxxxxxxxxxx
  • Date: Fri, 1 Aug 2003 18:20:21 +0200

On 2003-08-01 CE ozan s yigit wrote,
> The reason libXg is around is that it replicates the (earlier) plan9
> graphics API under X. this was thought to be important at one time, and
> it allowed many thousands of vi and emacs-sick programmers to switch to
> sam, and made wily possible. I realise it is showing its age, but 
> more than one program (some not distributed) depend on it. If that API
> needs to be scrapped, I would be interested in the new plan9 graphics API.
> Are you suggesting that those improvements cannot be done under an API
> ( that closely resembles
> it, and it has to be completely scrapped? I'm not worried about changing
> wily (and a number of other programs) I just not sure if a brand-new API
> (admittedly you have not given a specification so i'm making some
> assumptions) is really justified.

I have not used the plan9 graphics library, but from what I've seen of
the API it is designed around the assumption that all graphics
operations are non-local. This is a bit problematic when dealing with fonts
and bitmap images, should we emulate a client-server solution and still do
everything locally, basically embedding a graphics server?

Anyway, the API would be fairly small. Here's a quick draft of what
I was thinking of:

Window *openwindow(void)
void closewindow(Window *)
void nextevent(Window *, Event *)

Font *openfont(char *)
void closefont(Font *)

void updatewindow(Window *, Rect r)
void drawrect(Window *, Rect r, Color c)
void drawtext(Window *, Font *f, int x, int y, Rune *text, int n, Color c)
int textwidth(Font *f, Rune *text, int n)

enum { DOWN, MOVE, UP };
enum { SHOW, HIDE, RESIZE };

struct Mouseevent { int what, x, y, b; }
struct Textevent { Rune *text; int n; }
struct Windowevent { int what, w, h; }
struct Event {
        int tag;
        union { Mouseevent m; Textevent t; Windowevent w; } u;

nextevent wraps the X11 event loop.
It handles Expose events by blitting the double buffer, and
updatewindow forces an update, such as when a frame has changed.

The amount of code needed is not much, and implementing it is fairly
straight forward. The biggest amount of time will probably be going through
wily and libframe and replacing the drawing code to use this new API.

> I cc'ed this message to russ cox to see what the situation is with the 
> plan9 graphics library under different platforms; i know some pieces have
> been running under windows and X, and it is a matter of time before acme
> is available under linux and windows using probably a variant of libXg.

Does the appearance of acme for non-plan9 platforms deprecate the
raison d'être for wily? Is this a real 'threat' or just a pipe dream?

> | I am willing to spend some time on this, but only if it will be part of
> | the mainline wily distribution. Let me know what you think.
> I think before you do any work, I need to find out what we can get out
> of plan9 guys. If they have already done the work, and provides us with
> the facilities we need for wily, the problem is more or less solved.


55.7N 13.2E

Other related posts: