Don't mind if I grouse on some basic topics?? (very long) - Xwindows

This is a discussion on Don't mind if I grouse on some basic topics?? (very long) - Xwindows ; I know as experienced programmers you really don't want to hear people gripe and moan about basic, indeed critical topics, but I just have to vent on this. I am a relatively experienced C programmer and having dipped my toe ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Don't mind if I grouse on some basic topics?? (very long)

  1. Don't mind if I grouse on some basic topics?? (very long)

    I know as experienced programmers you really don't want to hear people gripe
    and moan about basic, indeed critical topics, but I just have to vent on
    this. I am a relatively experienced C programmer and having dipped my toe
    in the water of X programming I just can't get my head around two very
    critical topics.

    What is an event? Having read multiple books on this subject, including the
    O'Reilly series (very good books I might add) none of the texts defined it
    clearly. As a greenhorn it was aggrevating how indirect the texts are on
    that subject. I don't have anything off the top of my head to demonstrate
    but at least let me articulate. Is an event anything that occurs on screen?
    Is it only actions precipitated by changes to a window or cursor? Is it
    only a distinct set of actions. Examples don't seem to really help, an
    actual definition does though.

    The second question involves the execution of code within an X framework.
    Under a normal piece of C code the compiler runs though the code in a linear
    fashion, jumping to functions as the code demands but it always completes
    commands within a set sequence. It ALWAYS complete the command before
    moving to the next command as well. To my very untrained eyes that isn't
    the case within X. With X it appears that the executable is waiting for
    certain external triggers or actions before executing code, and even then it
    doesn't appear to uniformly execute them. I do understand that graphics are
    buffered and whatnot - but do they HAVE to be buffered, what if you wanted
    to produce raw output unbuffered? I don't see any evidence that something
    like that is even remotely possible within X. That's why I see the
    difference between C code and X C code, in C the commands trigger one, two,
    three, four, exit. In X it's almost like it stacks the commands up then
    does them all simultaneously. Can that behavior be removed? Can it be
    altered reliably?

    I'm sorry to unload like that, I expect it to behave like C behaves, but it
    doesn't it. It drives me crazy because I use C syntax and C compilers to
    code it, but it doesn't execute like C!

    How about a code fragment to give me a way in. And I do apologize for
    dumping this on you.

    I won't include the whole thing, as X has an incredible amount of overhead.


    /****************************************/
    win=XCreateSimpleWindow(dpy, parent, 10, 10, 200, 200, 5, black, white);
    /* I can reliably create windows */
    XMapWindow(dpy, win);

    gc=XCreateGC(dpy, win, mask, &values);
    while(1)
    {
    XNextEvent(dpy, &event)
    switch(event.type)
    {
    case Expose: /* Whatever that means!!!*/
    draw_points();
    break;
    case ButtonPress: /*Click mouse and terminate program?????? */
    exit(1);
    default:
    break;
    }
    }

    void draw_points(void)
    {
    XDrawPoint(dpy, win, gc, 20, 20);
    sleep (1);
    XDrawPoint(dpy, win, gc, 40, 40);
    }


    Here is what I WANT this code to do. I would like to simply open a window
    and have the computer draw points, shapes, lines, colors on the screen. I
    don't need text, I don't need mouse interaction, I don't need a scrollbar.
    Open window and draw some points. To me this should be trivial stuff
    indeed. As a matter of fact I can't figure out what the heck XNextEvent is
    even doing for me. Why can't I just do without the whole while loop and
    call the draw_points function directly? But I can't, without it the points
    don't appear. To me this gets back to the whole idea of exposure events,
    buffering, and the differences between C code and X code.



  2. Re: Don't mind if I grouse on some basic topics?? (very long)

    Eigenvector wrote:
    > I know as experienced programmers you really don't want to hear people gripe
    > and moan about basic, indeed critical topics, but I just have to vent on
    > this. I am a relatively experienced C programmer and having dipped my toe
    > in the water of X programming I just can't get my head around two very
    > critical topics.
    >
    > What is an event? Having read multiple books on this subject, including the
    > O'Reilly series (very good books I might add) none of the texts defined it
    > clearly. As a greenhorn it was aggrevating how indirect the texts are on
    > that subject. I don't have anything off the top of my head to demonstrate
    > but at least let me articulate. Is an event anything that occurs on screen?
    > Is it only actions precipitated by changes to a window or cursor? Is it
    > only a distinct set of actions. Examples don't seem to really help, an
    > actual definition does though.


    An 'event' is the commonality between changes to input devices, and
    changes to windows NOT arising from the window itself. IOW anything that
    *might* require reaction from the application/ If you want a *rigorous*
    definition, the best place would be www.x.org and look in the definition
    of the X protocol.

    >
    > The second question involves the execution of code within an X framework.
    > Under a normal piece of C code the compiler runs though the code in a linear
    > fashion, jumping to functions as the code demands but it always completes
    > commands within a set sequence. It ALWAYS complete the command before
    > moving to the next command as well. To my very untrained eyes that isn't
    > the case within X. With X it appears that the executable is waiting for
    > certain external triggers or actions before executing code, and even then it
    > doesn't appear to uniformly execute them. I do understand that graphics are
    > buffered and whatnot - but do they HAVE to be buffered, what if you wanted
    > to produce raw output unbuffered? I don't see any evidence that something
    > like that is even remotely possible within X.


    Yes there is. It's called 'synchronous mode', see XSynchronize(). And
    yes, it tends to be *so* slow that asynchronous is the default. In that
    mode, its not that the commands are buffered, they are *sent* ASAP, but
    the client does not wait for the completion until it needs an event.

    > That's why I see the
    > difference between C code and X C code, in C the commands trigger one, two,
    > three, four, exit. In X it's almost like it stacks the commands up then
    > does them all simultaneously. Can that behavior be removed? Can it be
    > altered reliably?


    Yes, but it's definitely not recommended.

    >
    > I'm sorry to unload like that, I expect it to behave like C behaves, but it
    > doesn't it. It drives me crazy because I use C syntax and C compilers to
    > code it, but it doesn't execute like C!


    It's a client/server protocol. Dont try to bend it to your idea, it wont
    work.

    >
    > How about a code fragment to give me a way in. And I do apologize for
    > dumping this on you.
    >
    > I won't include the whole thing, as X has an incredible amount of overhead.
    >
    >
    > /****************************************/
    > win=XCreateSimpleWindow(dpy, parent, 10, 10, 200, 200, 5, black, white);
    > /* I can reliably create windows */
    > XMapWindow(dpy, win);
    >
    > gc=XCreateGC(dpy, win, mask, &values);
    > while(1)
    > {
    > XNextEvent(dpy, &event)
    > switch(event.type)
    > {
    > case Expose: /* Whatever that means!!!*/
    > draw_points();
    > break;
    > case ButtonPress: /*Click mouse and terminate program?????? */
    > exit(1);
    > default:
    > break;
    > }
    > }
    >
    > void draw_points(void)
    > {
    > XDrawPoint(dpy, win, gc, 20, 20);
    > sleep (1);
    > XDrawPoint(dpy, win, gc, 40, 40);
    > }
    >
    >
    > Here is what I WANT this code to do. I would like to simply open a window
    > and have the computer draw points, shapes, lines, colors on the screen. I
    > don't need text, I don't need mouse interaction, I don't need a scrollbar.
    > Open window and draw some points. To me this should be trivial stuff
    > indeed. As a matter of fact I can't figure out what the heck XNextEvent is
    > even doing for me.
    > Why can't I just do without the whole while loop and
    > call the draw_points function directly? But I can't, without it the points
    > don't appear. To me this gets back to the whole idea of exposure events,
    > buffering, and the differences between C code and X code.


    That's why you should use a toolkit (Motif or Gtk or QT). With that, you
    could draw just once in a pixmap, and put it in a label (using Motif).
    Be aware, though, that programs that draw often *do* have a callback for
    expose events (because the odds are that you dont draw the same thing
    all the time) and *do* some form of buffering.

    >
    >



    --
    Michel Bardiaux
    R&D Director
    T +32 [0] 2 790 29 41
    F +32 [0] 2 790 29 02
    E mailto:mbardiaux@mediaxim.be

    Mediaxim NV/SA
    Vorstlaan 191 Boulevard du Souverain
    Brussel 1160 Bruxelles
    http://www.mediaxim.com/

  3. Re: Don't mind if I grouse on some basic topics?? (very long)

    Eigenvector wrote:

    > What is an event? Having read multiple books on this subject, including
    > the O'Reilly series (very good books I might add) none of the texts
    > defined it
    > clearly.


    An event (loosely defined) is some change in the state of the windowing
    system that needs the application to respond in some way. The type of
    response depends on the event being handled.

    Some examples of events are:

    o Mouse activity (movement, button presses and releases, etc.)
    o The mouse cursor entering or leaving a window.
    o An obscured window becoming visible again.

    > Is an event anything that occurs on
    > screen?


    Mostly, but not always exclusively. X11 allows some non-screen events (the
    arrival of data on a socket, for example) to be tied to the X11 event
    handling mechanism.

    > Is it
    > only a distinct set of actions. Examples don't seem to really help, an
    > actual definition does though.


    The X11 system has a defined list of events that can be generated and
    handled. The X11 system is capable of handling some user defined events,
    but you won't care about those until you get a grip on the basic X11
    events.

    > In X it's almost like it stacks the commands up then
    > does them all simultaneously. Can that behavior be removed? Can it be
    > altered reliably?


    X does a certain amount of buffering to alleviate some network activity
    (keep in mind that X is a client/server system) and increase
    responsiveness. When X's buffer fills, or it determines that no further
    buffering is beneficial, it will flush all accumulated events to your
    program. This is a good thing, and removing this behavior would be bad for
    performance.

    > It drives me crazy because I use C syntax and C compilers to
    > code it, but it doesn't execute like C!


    Event driven programming is different in concept in some ways, but in
    reality is no different than procedural programming. The only difference
    is that the windowing system subsumes a lot of the work that you would
    normally have to do yourself. It looks different only because the grunt
    work is hidden from you (that is also a good thing).

    >
    > How about a code fragment to give me a way in. And I do apologize for
    > dumping this on you.
    >
    >
    > /****************************************/
    > win=XCreateSimpleWindow(dpy, parent, 10, 10, 200, 200, 5, black, white);
    > /* I can reliably create windows */
    > XMapWindow(dpy, win);
    >
    > gc=XCreateGC(dpy, win, mask, &values);
    > while(1)
    > {
    > XNextEvent(dpy, &event)
    > switch(event.type)
    > {
    > case Expose: /* Whatever that means!!!*/
    > draw_points();
    > break;
    > case ButtonPress: /*Click mouse and terminate program?????? */
    > exit(1);
    > default:
    > break;
    > }
    > }
    >
    > void draw_points(void)
    > {
    > XDrawPoint(dpy, win, gc, 20, 20);
    > sleep (1);
    > XDrawPoint(dpy, win, gc, 40, 40);
    > }
    >
    >



    > Here is what I WANT this code to do. I would like to simply open a window
    > and have the computer draw points, shapes, lines, colors on the screen. I
    > don't need text, I don't need mouse interaction, I don't need a scrollbar.
    > Open window and draw some points. To me this should be trivial stuff
    > indeed. As a matter of fact I can't figure out what the heck XNextEvent
    > is
    > even doing for me.


    By the very nature of graphical user interfaces, users can do things in any
    order. You have no guarantee that the user will move the mouse before
    clicking the button, for example. GUIs are asynchronous, and can deliver
    events to the application in any order.

    XNextEvent causes the program to wait for the next event to occur (and
    surrendering processor cycles to other programs until some event happens),
    and then delivers the event data to your program. The giant switch()
    statement you'll see in most X programs determines which event is being
    delivered, and delegates handling responsibilities accordingly.

    The Expose event type tells your program that the window is ready for user
    I/O operations (such a drawing and mouse activity), or that the window must
    be redrawn because a part of it was obscured but is now visible.

    > Why can't I just do without the whole while loop and
    > call the draw_points function directly?


    Because until the Expose event is generated, the window is not capable of
    accepting drawing commands.


  4. Re: Don't mind if I grouse on some basic topics?? (very long)


    "Tony O'Bryan" wrote in message
    news:al0Fg.1654$q63.1019@newssvr13.news.prodigy.co m...
    > Eigenvector wrote:
    >
    >> What is an event? Having read multiple books on this subject, including
    >> the O'Reilly series (very good books I might add) none of the texts
    >> defined it
    >> clearly.

    >
    > An event (loosely defined) is some change in the state of the windowing
    > system that needs the application to respond in some way. The type of
    > response depends on the event being handled.
    >
    > Some examples of events are:
    >
    > o Mouse activity (movement, button presses and releases, etc.)
    > o The mouse cursor entering or leaving a window.
    > o An obscured window becoming visible again.
    >
    >> Is an event anything that occurs on
    >> screen?

    >
    > Mostly, but not always exclusively. X11 allows some non-screen events
    > (the
    > arrival of data on a socket, for example) to be tied to the X11 event
    > handling mechanism.
    >
    >> Is it
    >> only a distinct set of actions. Examples don't seem to really help, an
    >> actual definition does though.

    >
    > The X11 system has a defined list of events that can be generated and
    > handled. The X11 system is capable of handling some user defined events,
    > but you won't care about those until you get a grip on the basic X11
    > events.
    >
    >> In X it's almost like it stacks the commands up then
    >> does them all simultaneously. Can that behavior be removed? Can it be
    >> altered reliably?

    >
    > X does a certain amount of buffering to alleviate some network activity
    > (keep in mind that X is a client/server system) and increase
    > responsiveness. When X's buffer fills, or it determines that no further
    > buffering is beneficial, it will flush all accumulated events to your
    > program. This is a good thing, and removing this behavior would be bad
    > for
    > performance.
    >
    >> It drives me crazy because I use C syntax and C compilers to
    >> code it, but it doesn't execute like C!

    >
    > Event driven programming is different in concept in some ways, but in
    > reality is no different than procedural programming. The only difference
    > is that the windowing system subsumes a lot of the work that you would
    > normally have to do yourself. It looks different only because the grunt
    > work is hidden from you (that is also a good thing).
    >
    >>
    >> How about a code fragment to give me a way in. And I do apologize for
    >> dumping this on you.
    >>
    >>
    >> /****************************************/
    >> win=XCreateSimpleWindow(dpy, parent, 10, 10, 200, 200, 5, black, white);
    >> /* I can reliably create windows */
    >> XMapWindow(dpy, win);
    >>
    >> gc=XCreateGC(dpy, win, mask, &values);
    >> while(1)
    >> {
    >> XNextEvent(dpy, &event)
    >> switch(event.type)
    >> {
    >> case Expose: /* Whatever that means!!!*/
    >> draw_points();
    >> break;
    >> case ButtonPress: /*Click mouse and terminate program?????? */
    >> exit(1);
    >> default:
    >> break;
    >> }
    >> }
    >>
    >> void draw_points(void)
    >> {
    >> XDrawPoint(dpy, win, gc, 20, 20);
    >> sleep (1);
    >> XDrawPoint(dpy, win, gc, 40, 40);
    >> }
    >>
    >>

    >
    >
    >> Here is what I WANT this code to do. I would like to simply open a
    >> window
    >> and have the computer draw points, shapes, lines, colors on the screen.
    >> I
    >> don't need text, I don't need mouse interaction, I don't need a
    >> scrollbar.
    >> Open window and draw some points. To me this should be trivial stuff
    >> indeed. As a matter of fact I can't figure out what the heck XNextEvent
    >> is
    >> even doing for me.

    >
    > By the very nature of graphical user interfaces, users can do things in
    > any
    > order. You have no guarantee that the user will move the mouse before
    > clicking the button, for example. GUIs are asynchronous, and can deliver
    > events to the application in any order.
    >
    > XNextEvent causes the program to wait for the next event to occur (and
    > surrendering processor cycles to other programs until some event happens),
    > and then delivers the event data to your program. The giant switch()
    > statement you'll see in most X programs determines which event is being
    > delivered, and delegates handling responsibilities accordingly.
    >
    > The Expose event type tells your program that the window is ready for user
    > I/O operations (such a drawing and mouse activity), or that the window
    > must
    > be redrawn because a part of it was obscured but is now visible.
    >
    >> Why can't I just do without the whole while loop and
    >> call the draw_points function directly?

    >
    > Because until the Expose event is generated, the window is not capable of
    > accepting drawing commands.
    >


    I do appreciate both of your very patient and indulgent responses.

    So may I ask a specific question. If you didn't care about mouse, keyboard,
    or user actions, what would be the most reliable, quickest and simplest way
    of drawing two lines, points, whatever on a simple window - with a 1 second
    pause in between?



  5. Re: Don't mind if I grouse on some basic topics?? (very long)


    "Eigenvector" wrote in message
    news:v6ednbcj_uiUYXnZnZ2dnUVZ_s2dnZ2d@comcast.com. ..
    >
    > "Tony O'Bryan" wrote in message
    > news:al0Fg.1654$q63.1019@newssvr13.news.prodigy.co m...
    >> Eigenvector wrote:
    >>
    >>> What is an event? Having read multiple books on this subject, including
    >>> the O'Reilly series (very good books I might add) none of the texts
    >>> defined it
    >>> clearly.

    >>
    >> An event (loosely defined) is some change in the state of the windowing
    >> system that needs the application to respond in some way. The type of
    >> response depends on the event being handled.
    >>
    >> Some examples of events are:
    >>
    >> o Mouse activity (movement, button presses and releases, etc.)
    >> o The mouse cursor entering or leaving a window.
    >> o An obscured window becoming visible again.
    >>
    >>> Is an event anything that occurs on
    >>> screen?

    >>
    >> Mostly, but not always exclusively. X11 allows some non-screen events
    >> (the
    >> arrival of data on a socket, for example) to be tied to the X11 event
    >> handling mechanism.
    >>
    >>> Is it
    >>> only a distinct set of actions. Examples don't seem to really help, an
    >>> actual definition does though.

    >>
    >> The X11 system has a defined list of events that can be generated and
    >> handled. The X11 system is capable of handling some user defined events,
    >> but you won't care about those until you get a grip on the basic X11
    >> events.
    >>
    >>> In X it's almost like it stacks the commands up then
    >>> does them all simultaneously. Can that behavior be removed? Can it be
    >>> altered reliably?

    >>
    >> X does a certain amount of buffering to alleviate some network activity
    >> (keep in mind that X is a client/server system) and increase
    >> responsiveness. When X's buffer fills, or it determines that no further
    >> buffering is beneficial, it will flush all accumulated events to your
    >> program. This is a good thing, and removing this behavior would be bad
    >> for
    >> performance.
    >>
    >>> It drives me crazy because I use C syntax and C compilers to
    >>> code it, but it doesn't execute like C!

    >>
    >> Event driven programming is different in concept in some ways, but in
    >> reality is no different than procedural programming. The only difference
    >> is that the windowing system subsumes a lot of the work that you would
    >> normally have to do yourself. It looks different only because the grunt
    >> work is hidden from you (that is also a good thing).
    >>
    >>>
    >>> How about a code fragment to give me a way in. And I do apologize for
    >>> dumping this on you.
    >>>
    >>>
    >>> /****************************************/
    >>> win=XCreateSimpleWindow(dpy, parent, 10, 10, 200, 200, 5, black, white);
    >>> /* I can reliably create windows */
    >>> XMapWindow(dpy, win);
    >>>
    >>> gc=XCreateGC(dpy, win, mask, &values);
    >>> while(1)
    >>> {
    >>> XNextEvent(dpy, &event)
    >>> switch(event.type)
    >>> {
    >>> case Expose: /* Whatever that means!!!*/
    >>> draw_points();
    >>> break;
    >>> case ButtonPress: /*Click mouse and terminate program?????? */
    >>> exit(1);
    >>> default:
    >>> break;
    >>> }
    >>> }
    >>>
    >>> void draw_points(void)
    >>> {
    >>> XDrawPoint(dpy, win, gc, 20, 20);
    >>> sleep (1);
    >>> XDrawPoint(dpy, win, gc, 40, 40);
    >>> }
    >>>
    >>>

    >>
    >>
    >>> Here is what I WANT this code to do. I would like to simply open a
    >>> window
    >>> and have the computer draw points, shapes, lines, colors on the screen.
    >>> I
    >>> don't need text, I don't need mouse interaction, I don't need a
    >>> scrollbar.
    >>> Open window and draw some points. To me this should be trivial stuff
    >>> indeed. As a matter of fact I can't figure out what the heck XNextEvent
    >>> is
    >>> even doing for me.

    >>
    >> By the very nature of graphical user interfaces, users can do things in
    >> any
    >> order. You have no guarantee that the user will move the mouse before
    >> clicking the button, for example. GUIs are asynchronous, and can deliver
    >> events to the application in any order.
    >>
    >> XNextEvent causes the program to wait for the next event to occur (and
    >> surrendering processor cycles to other programs until some event
    >> happens),
    >> and then delivers the event data to your program. The giant switch()
    >> statement you'll see in most X programs determines which event is being
    >> delivered, and delegates handling responsibilities accordingly.
    >>
    >> The Expose event type tells your program that the window is ready for
    >> user
    >> I/O operations (such a drawing and mouse activity), or that the window
    >> must
    >> be redrawn because a part of it was obscured but is now visible.
    >>
    >>> Why can't I just do without the whole while loop and
    >>> call the draw_points function directly?

    >>
    >> Because until the Expose event is generated, the window is not capable of
    >> accepting drawing commands.
    >>

    >
    > I do appreciate both of your very patient and indulgent responses.
    >
    > So may I ask a specific question. If you didn't care about mouse,
    > keyboard, or user actions, what would be the most reliable, quickest and
    > simplest way of drawing two lines, points, whatever on a simple window -
    > with a 1 second pause in between?


    As Michel already mentioned, the easiest way is to use a toolkit.
    X is much too low level for most programs.
    Using Motif, for example, you would create a toplevel window,
    add a managed DrawingArea widget to it, register a timeout proc,
    realize the toplevel widget, and then call XtAppMainLoop().
    You would do the drawing in the timeout proc. Something like this:


    /*
    * System include files
    */
    #include

    /*
    * X, Xt, and Motif include files
    */
    #include
    #include
    #include

    unsigned long interval = 1000; /* 1000 milliseconds */
    XtAppContext MyContext ;

    /*
    * Function prototypes
    */
    void DrawProc(XtPointer client_data,XtIntervalId *id);

    /*
    * Main program
    */
    int main(
    int argc, /* IN: Command line argument count */
    String argv[] /* IN: Command line arguments */
    )
    {
    Display *MyDisplay ;
    Widget wTopLevel, wDA;
    /*
    * --- Create the application shell ---
    */
    wTopLevel = XtOpenApplication( &MyContext, "drawing",
    NULL, 0, &argc, argv,
    NULL, applicationShellWidgetClass,
    NULL, 0 ) ;
    MyDisplay = XtDisplay( wTopLevel ) ;
    /*
    * --- Drawing area ---
    */
    wDA = XtVaCreateManagedWidget("drawing",
    xmDrawingAreaWidgetClass,
    wTopLevel,
    XmNwidth, 200,
    XmNheight, 200,
    NULL);
    /*
    * Register the timer to be called
    * after a specified interval
    */
    XtAppAddTimeOut(MyContext, interval, DrawProc, (XtPointer)wDA);

    /*
    * --- Display the shell ---
    */
    XtRealizeWidget( wTopLevel ) ;
    /*
    * --- Wait for things to happen
    */
    XtAppMainLoop( MyContext ) ;
    return( 0 ) ;
    }

    void DrawProc(
    /*
    * PURPOSE: To draw
    */
    XtPointer client_data,
    XtIntervalId *id
    )
    {
    static GC gc = None;
    Widget w = (Widget)client_data;
    Boolean again = True;

    printf( "DrawProc called\n");
    if ( gc == None ) {
    /*
    * Create a GC here to use for drawing
    */

    }

    /*
    * Draw the line here
    */


    /*
    * Re-register the timer to fire again
    */
    if ( again ) {
    XtAppAddTimeOut(MyContext, interval, DrawProc, NULL);
    }
    }

    --
    Fred L. Kleinschmidt
    Boeing Associate Technical Fellow
    Technical Architect, Software Reuse Project






  6. Re: Don't mind if I grouse on some basic topics?? (very long)

    Eigenvector wrote:

    > So may I ask a specific question. If you didn't care about mouse,
    > keyboard, or user actions, what would be the most reliable, quickest and
    > simplest way of drawing two lines, points, whatever on a simple window -
    > with a 1 second pause in between?


    That depends on whether you have to stay at the Xlib level, or if you have
    the option of choosing a higher level toolkit. If you have to stay at the
    Xlib level, then there's some extra work involved to get accurate
    asynchronous timers (sigaction() and the SIGALRM signal are the best
    choice).

    I'm partial to Qt for an easy to use higher level C++ GUI toolkit for my
    Free Software work. But for my proprietary software, I have written my own
    higher level C++ toolkit around Xlib (and several other low-level
    libraries). I implement timers with sigaction() and the SIGALRM signal.

    The simplest brute force method to draw a line between two points, once
    every second while staying at the Xlib level, is something like this (all
    pseudo-code):

    XOpenDisplay();
    XCreateWindow();
    do XNextEvent() until Expose event;

    main:

    XSetForegroundColor();
    XDrawLine();
    while XPending() is true, do XNextEvent();
    sleep(1);

    loop back to main:


  7. Re: Don't mind if I grouse on some basic topics?? (very long)


    "Tony O'Bryan" wrote in message
    news:kG5Gg.9550$%j7.488@newssvr29.news.prodigy.net ...
    > Eigenvector wrote:
    >
    >> So may I ask a specific question. If you didn't care about mouse,
    >> keyboard, or user actions, what would be the most reliable, quickest and
    >> simplest way of drawing two lines, points, whatever on a simple window -
    >> with a 1 second pause in between?

    >
    > That depends on whether you have to stay at the Xlib level, or if you have
    > the option of choosing a higher level toolkit. If you have to stay at the
    > Xlib level, then there's some extra work involved to get accurate
    > asynchronous timers (sigaction() and the SIGALRM signal are the best
    > choice).
    >
    > I'm partial to Qt for an easy to use higher level C++ GUI toolkit for my
    > Free Software work. But for my proprietary software, I have written my
    > own
    > higher level C++ toolkit around Xlib (and several other low-level
    > libraries). I implement timers with sigaction() and the SIGALRM signal.
    >
    > The simplest brute force method to draw a line between two points, once
    > every second while staying at the Xlib level, is something like this (all
    > pseudo-code):
    >
    > XOpenDisplay();
    > XCreateWindow();
    > do XNextEvent() until Expose event;
    >
    > main:
    >
    > XSetForegroundColor();
    > XDrawLine();
    > while XPending() is true, do XNextEvent();
    > sleep(1);
    >
    > loop back to main:
    >


    Excellent, thank you I'll give it a whirl on Monday when I get back in. I
    do have to stay within X11, sorry no Xt or Xm for me.

    I tried it on Friday without the XNextEvent call and simply used a
    XSynchronize call to remove the buffering, something my code won't need
    anyway.



  8. Re: Don't mind if I grouse on some basic topics?? (very long)

    Tony O'Bryan wrote:

    > XOpenDisplay();
    > XCreateWindow();


    OOps. I forgot to put XMapWindow(); here. The window will never generate
    an Expose event if it isn't mapped.

    > do XNextEvent() until Expose event;



  9. Re: Don't mind if I grouse on some basic topics?? (very long)

    Eigenvector wrote:
    > "Tony O'Bryan" wrote in message
    > news:kG5Gg.9550$%j7.488@newssvr29.news.prodigy.net ...
    >> Eigenvector wrote:
    >>
    >>> So may I ask a specific question. If you didn't care about mouse,
    >>> keyboard, or user actions, what would be the most reliable, quickest and
    >>> simplest way of drawing two lines, points, whatever on a simple window -
    >>> with a 1 second pause in between?

    >> That depends on whether you have to stay at the Xlib level, or if you have
    >> the option of choosing a higher level toolkit. If you have to stay at the
    >> Xlib level, then there's some extra work involved to get accurate
    >> asynchronous timers (sigaction() and the SIGALRM signal are the best
    >> choice).
    >>
    >> I'm partial to Qt for an easy to use higher level C++ GUI toolkit for my
    >> Free Software work. But for my proprietary software, I have written my
    >> own
    >> higher level C++ toolkit around Xlib (and several other low-level
    >> libraries). I implement timers with sigaction() and the SIGALRM signal.
    >>
    >> The simplest brute force method to draw a line between two points, once
    >> every second while staying at the Xlib level, is something like this (all
    >> pseudo-code):
    >>
    >> XOpenDisplay();
    >> XCreateWindow();
    >> do XNextEvent() until Expose event;
    >>
    >> main:
    >>
    >> XSetForegroundColor();
    >> XDrawLine();
    >> while XPending() is true, do XNextEvent();
    >> sleep(1);
    >>
    >> loop back to main:
    >>

    >
    > Excellent, thank you I'll give it a whirl on Monday when I get back in. I
    > do have to stay within X11, sorry no Xt or Xm for me.


    Why?

    >
    > I tried it on Friday without the XNextEvent call and simply used a
    > XSynchronize call to remove the buffering, something my code won't need
    > anyway.
    >
    >



    --
    Michel Bardiaux
    R&D Director
    T +32 [0] 2 790 29 41
    F +32 [0] 2 790 29 02
    E mailto:mbardiaux@mediaxim.be

    Mediaxim NV/SA
    Vorstlaan 191 Boulevard du Souverain
    Brussel 1160 Bruxelles
    http://www.mediaxim.com/

+ Reply to Thread