On Mon, Apr 30, 2001 at 10:42:44AM +0100, Jim Hague wrote:
> However - and the reason I thought I'd chip in, as I'm not sure it emerged
> clearly from Crossfire's summary of the possibilities - you need to be prepared
> to shift your programming mind around a bit. I speak as one who also made the
> transition from various BASICs(*) and other PC console graphics libraries
> to windowing systems - X and Windows, in my case.
>
> The crucial difference is the switch to event-driven programming.
>
> BASIC programs with graphics tend to go something along the lines of:
>
> Select graphics mode
> Draw screen
> Wait for user to type command
> Draw modified screen
> Wait
> Draw
> Wait - user gives exit command
> Exit
>
> X programs, on the other hand, are more along the lines of
>
> Initialise
> Create main window
> Call toolkit event loop
> Exit
>
> Paint event:
> Draw screen
Thanks for chipping in here.
I've been programming for over twenty years myself, and have
been able to avoid the switch from imperative non-window
graphics coding to GUI coding by moving to GUI-free embedded
work. Naturally, there are more and more cases where I'd love
to whack a graph or diagram of something up in a window, but I
just don't know where to start.
I'm pretty sure that I understand the event model of doing
things. It's not that dissimilar to interrupt handler code in
my embedded work.
The thing that's making me balk at first is understanding where
the events are coming from, and under what circumstances they
will arrive.
I haven't found a good introductory text or "reference" manual
page that describes that. Do you know of any? Most of the
"toolkit" things describe ever more complicated structures of
buttons and menus, but what I want to know is lines and points
of various colours, within a region of a specific size.
For example: years ago I wrote a nice simulation of "diffusion
limited aggregation", wich is a fractal thing that ends up
drawing a pretty picture that looks a bit like coral or dust
clumps. I wrote it in imperative style in VAX Fortran, with
output to a Tektronix colour terminal. Yes, I wrote all of the
escape sequences by hand, with the terminal manual open in front
of me: no graphics libraries here.
I dug out the source for this the other day, and have translated
the guts (the bits that determine which pixels should be on, and
in what colour) into C, but can't figure out how to produce the
output. You see: the original version used the fact that the
terminal could eat pixel updates at a certain rate to produce a
sort-of animation of the growth of the picture. If I do the X
thing the "obvious" way (well, the way that seemed most obvious
from the Xlib man pages), I'd just do the whole picture creation
to an off-screen pixmap, and then issue some sort of "display
me" command, which might get the image up, but wouldn't be as
much fun.
If I use the "paint" or whatever event to draw the first pixel,
what has to happen to make another redraw event happen
immediately after, to draw the next pixel?
If I use the "paint" or "expose" or whatever event to draw
the whole thing, will it actually appear on the screen,
pixel-by-pixel? If the drawing process takes a significant
amount of time (minutes to hours), won't my failure to return
from the first "paint" event block up whatever mechanism X uses
to handle events on other windows?
Sorry for downloading like this. Please feel free to ignore me:
it's not a particularly important problem. If there is a good
book (or PDF or web page) that covers these issues in a tutorial
rather than reference fashion, I'd really appreciate it, and I
suspect that the original poster might too.
--
Andrew
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
