From lahaye@users.sourceforge.net Fri Jun 13 00:56:37 2003 From: lahaye@users.sourceforge.net (Rob Lahaye) Date: Fri, 13 Jun 2003 08:56:37 +0900 Subject: [XForms] Re: New xforms list server In-Reply-To: <3EE8D3C2.8050003@bob.usuhs.mil> References: <3EE8D3C2.8050003@bob.usuhs.mil> Message-ID: <3EE91335.6030403@users.sourceforge.net> Robert Williams wrote: > > To subscribers of the xforms list > > > I've finally moved the xforms list to > a fast machine running mailman. There may > be a few adjustments that I have to make, > but if you recieve this, it appears to work. > > Bob Williams > xforms list maintainer Notice that the 2002 archive still collects current messages; and we are already half way 2003! Can you break it up and add the 2003 messages to a new 2003 tree ? Regards, Rob. From ldm@risc4.numis.nwu.edu Mon Jun 16 14:21:42 2003 From: ldm@risc4.numis.nwu.edu (L. D. Marks) Date: Mon, 16 Jun 2003 08:21:42 -0500 (CDT) Subject: [XForms] Libraries, configure etc Message-ID: Two questions: Do the compiled libraries exist anywhere, or have they now gone. Has anyone converted to Imake structure to a configure (i.e. autoconf/automake) one? I am not that familiar with image, but know that configure can be arranged to determine enough about the system to make compilation seamless. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm@risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From angus.leeming@btopenworld.com Tue Jun 17 01:17:39 2003 From: angus.leeming@btopenworld.com (Angus Leeming) Date: Tue, 17 Jun 2003 00:17:39 +0000 Subject: [XForms] Libraries, configure etc In-Reply-To: References: Message-ID: <200306170017.39950.angus.leeming@btopenworld.com> On Monday 16 June 2003 11:12 pm, you wrote: > We are about to release some code which uses libforms. > If a tgz file is available with a standard configure, > we can use this otherwise we may need to write our > way around including libforms. Can you make one > available? Why not grab a copy of the cvs repository, following the instructions on the web page I posted to you and thereafter: $ ./autogen.sh $ ./configure your_options $ make dist which should generate your desired tar.gz file. Regards, Angus From nicolas.castagne@imag.fr Wed Jun 18 12:54:15 2003 From: nicolas.castagne@imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Wed, 18 Jun 2003 13:54:15 +0200 Subject: [XForms] Threads and OpenGL --- again ! ;-) Message-ID: <958998B0-A183-11D7-B36A-000393C76CA6@imag.fr> --Apple-Mail-15-320643941 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi all, I have worked again a bit on a small demo program running a gl CANVAS drawn through a THREAD. You will find attached the sources. ----- I - description of the program The code assumes: 1) that each thread has its own current GLXContext 2) that concurrent calls to glXMakeCurrent and glXSwapBuffer can be made, provided the context used for each one is possessed by the calling thread. The program shows in a form two canvas with a rotating cube. The main process creates and display the form. The "MainCanvas" and its GLXcontext are created by the Main Proces. The "MainCanvas" drawn through an idle callback. The ThreadCanvas is created by the Thread and drawn by it. Its GLXcontext is also created by the thread, through the call to fl_add_object(Form, ThreadCanvas). A communication process ensures that Expose Events on the "ThreadCanvas" (handled by the XForms main loop in the Main Process) are communicated to the Thread. As an evidence, this communication process could be improved. However, it is not the problem today. ----- II - results and problem When rendering is made in DIRECT mode, every thing runs correctly on every SGI engine I was able to test. The call to XinitThread() even does not seem to be necessary. On the contrary, the program ALWAYS CRASHES when rendering is made through the X Server. This happens in two cases: 1) when the constant DIRECT, at the beginning of the sources, is set to 0; 2) when distant execution is performed (direct rendering is then impossible). The error messages I get from the X server are various. Mainly : X Error of failed request: GLXBadContextTag Major opcode of failed request: 146 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 667 Current serial number in output stream: 681 or : X Error of failed request: GLXBadContextTag Major opcode of failed request: 146 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 651 Current serial number in output stream: 656 Note that the GLXBadContextTag error is not well documented. As an example, it does not appear in the GL man pages. I don't really understand what it means. ----- II - help ! ;-) I have worked quite a lot around the problem, trying various solutions... But without success. It would be really helpful if one of you could have a look on the problem: Numerous mails concerning threads and GLcanvas have been posted for the past years on the list, but never a definitive answer. As a matter of fact, it could be of interest to : 1) propose a valid small demo program within the XForms examples. 2) by the end, add to the library an API for threaded Gl canvas. I may work on these points... But i need help today ! You may help in different ways : 1) trying to compile and run my program on other platforms, to see what happens; 2) debugging my program, showing what is wrong; 2) sending other pieces of code with threaded Glcanvas that run properly, what ever the rendering mode is, so that I could make the previous jobs on my own. Thx in advance ! Nicolas --Apple-Mail-15-320643941 Content-Disposition: attachment Content-Type: multipart/appledouble; boundary=Apple-Mail-16-320643942 --Apple-Mail-16-320643942 Content-Disposition: attachment; filename=ThreadGL.c Content-Transfer-Encoding: base64 Content-Type: application/applefile; name="ThreadGL.c" AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAJAAAAMgAAAAoAAAADAAAAPAAAAAoAAAAAAAAA AAEAVGhyZWFkR0wuYw== --Apple-Mail-16-320643942 Content-Disposition: attachment; filename=ThreadGL.c Content-Transfer-Encoding: 7bit Content-Type: text/plain; x-mac-creator=0; x-unix-mode=0755; x-mac-type=0; name="ThreadGL.c" /* * This demo implements two GL canvas * drawing a rotating cube and a thread. * * The first canvas is drawn by the main process * through an idle callback. * The second canvas is drawn by the thread. * * N Castagne, june 2002 * nicolas.castagne@imag.fr */ /* * Compiled on SGI octane syst. 6.4 with Xforms release 0.89 and glX release 1.3 *with : cc ThreadGL.c -o ThreadGL -O2 -g -xansi -n32 -L/usr/lib32 -L$HOME/XFORMS_089_N32/FORMS -lforms -L/usr/X11/lib -lpthread -lGL -lGLU -lXext -lX11 -lm -I$HOME/XFORMS_089_N32/FORMS -I. * */ #include #include "forms.h" #include #include #include #include /* CONVENTIONS : - the name of the procedures called by the main process begin with Main - the name of the procedures called by the thread begin with Thread - the name of the procedures called by the two processes begin with Both - the name of the global variables relative to the main process begin with Main - the name of the global variables relative to thread begin with Thread - the name of the global variables relative to the two processes begin with Both */ #define DEBUG 0 /* 1 if outputs is needed */ #define DIRECT 1 /* 1 if direct rendering is wished for the canvas 0 if rendering is to be performed through the X server */ /* NOTE : in case of a distant execution, rendering is always not direct */ /* NOTE : with this implementation, non-direct rendering always generates a GLXBadContextTag error Why ? That is the question ! */ typedef struct { FL_FORM *Form; FL_OBJECT *GoBtn; /* PUSH button that runs the rotation */ FL_OBJECT *MainCanvas; } FORM_T; FORM_T *Form; /* the form */ FL_OBJECT *ThreadCanvas; /* the canvas (created and added by the thread) */ pthread_mutex_t DrawOnMutex = PTHREAD_MUTEX_INITIALIZER; /* DrawOnMutex is owned by the thread while it draws. It is owned by the main process when roation of the cube is off*/ int DrawOnMutexLocked = 0 ; /* 1 if the main process locked the mutex DrawOnMutex Needed to avoid double lock of the mutex */ int ExposeEvent = 0 ; /* ExposeEvent is used to comunicate Expose events to the thread */ /* ExposeEvent = 0 => no expose event currently handled (value 0 is set by the main process when expose is complet ExposeEvent = 1 => expose requested (value 1 is set by the main process) ExposeEvent = 2 => the threads has performed the expose (value 2 is set by the thread) */ /* NOTE : with this implementation, expose events will stop the main process until it is performed by the thread */ /* NOTE : The use of such a flag is quite a bad choice, since both processes spin awaiting complection of the expose event... Should be replaced with an array of mutexes or semaphores. The communication process for expose events should be improved */ long MainComptRot = 0; /* the number of rotation perfomed on the main process' cube*/ long ThreadComptRot = 0; /* the number of rotation perfomed on the thread's cube*/ pthread_mutex_t ThreadComptRotMutex = PTHREAD_MUTEX_INITIALIZER; /* Mutex to avoid concurrent accesses to the variable ThreadComptRot */ /*******************************************************************************/ /* Properties procedures for the canvas */ /*******************************************************************************/ /* redefinition of the Xforms procedure for canvas properties */ static int Thread_glx_init(FL_OBJECT * ob); static int Thread_glx_activate(FL_OBJECT * ob); static int Thread_glx_cleanup(FL_OBJECT * ob); static int Main_glx_init(FL_OBJECT * ob); static int Main_glx_activate(FL_OBJECT * ob); static int Main_glx_cleanup(FL_OBJECT * ob); /***************************************************************/ /* procedures called with both processes */ /***************************************************************/ void BothDrawCube(float t); void BothDrawCanvas(FL_OBJECT *TheCanvas, int NbRot, GLfloat r, GLfloat g, GLfloat b); int BothExposeCanvas(FL_OBJECT *ob, int w, int h); void BothWaitABit(int); /***************************************************************/ /* procedures executed only within the thread */ /***************************************************************/ void ThreadAddCanvas(); void * TheThread(void *data); /* the thread itself */ /***************************************************************/ /* procedures executed only within the main process */ /***************************************************************/ void MainExitBtn_cb(FL_OBJECT *ob, long data); void MainGoBtn_cb(FL_OBJECT *ob, long data); void MainInitBtn_cb(FL_OBJECT *ob, long data); FORM_T *MainCreateForm(void); int BothExposeHandler(FL_OBJECT *ob, Window win, int win_width, int win_height, XEvent *xev, void *user_data); void MainRqstExposeOnThreadCanvas(void); int MainDrawOn_idle(XEvent *xev, void *userData); /**********************************************************************************************/ /**********************************************************************************************/ /*******************************************************************************/ /* Properties for the canvas */ /*******************************************************************************/ /* Because the main process must not activate the canvas, we need to redefine the glx_activate procedure (glcanvas.c) with fl_modify_canvas_prop( FL_OBJECT, init, activate, cleanup) . To that aim, we need the three procedures glx_init, glx_activate and glx_cleanup */ #define MAXATTRIB 34 typedef struct { XVisualInfo *xvinfo; GLXContext context; int direct; int glconfig[MAXATTRIB]; } CSPEC; #define GLPROP(ob) ((CSPEC *)(ob->c_vdata)) /* NOTE : The GLXContext of the ThreadCanvas should be created within the thread. Thread_glx_init should then be called by the thread, not by XForms... As far as I know, in this implementation, Thread_glx_init is called whenthe ThreadCanvas is added to the form, i.e. in the fl_add_object(Form, ThreadCanvas) procedure called within ThreadAddCanvas() by the thread. It should be correct, then... */ static int Thread_glx_init(FL_OBJECT * ob) { XVisualInfo *vi; GLXContext context; /* query for openGL capabilities */ if (!glXQueryExtension(fl_display, 0, 0)) { fprintf(stderr, "GLCanvas: OpenGL not supported\n"); return -1; } if (!(vi = glXChooseVisual(fl_display, fl_screen, GLPROP(ob)->glconfig))) { /* if can't get a visual, quit */ fprintf(stderr, "GLCanvas: Can't get visual\n"); return -1; } /* change canvas defaults */ fl_set_canvas_visual(ob, vi->visual); fl_set_canvas_depth(ob, vi->depth); fl_set_canvas_colormap(ob, fl_create_colormap(vi, 1)); GLPROP(ob)->direct = DIRECT ; /* DIRECT : see top of the file*/ context = glXCreateContext(fl_display, vi, None, GLPROP(ob)->direct); if (!context) { fprintf(stderr, "Can't create GLX context!\n"); return -1; } /* under some conditions, the parent of the gl canvas might go away, leaving the old context and vi hanging. */ Thread_glx_cleanup(ob); GLPROP(ob)->context = context; GLPROP(ob)->xvinfo = vi; return 0; } /* this procedure was not changed */ /* This routine is called after a valid window is created. It simply * binds the OpenGL context to the canvas window */ static int Thread_glx_activate(FL_OBJECT * ob) { /* original XFORMS call : */ /* glXMakeCurrent(fl_display, FL_ObjWin(ob), GLPROP(ob)->context); */ /* no activation is perfomed at all... to avoid an activation of the thread's canvas by the main process (glx_activate2 is automatically called by the XFORMS main loop when the canvas window is created ) */ return 0; } /* this procedure was not changed */ /* * cleanup is called before destroying the window. Might be called * more than once */ static int Thread_glx_cleanup(FL_OBJECT * ob) { if (GLPROP(ob)->context) { glXDestroyContext(fl_display, GLPROP(ob)->context); XFree(GLPROP(ob)->xvinfo); GLPROP(ob)->context = 0; GLPROP(ob)->xvinfo = 0; } return 0; } static int Main_glx_init(FL_OBJECT * ob) { XVisualInfo *vi; GLXContext context; /* query for openGL capabilities */ if (!glXQueryExtension(fl_display, 0, 0)) { fprintf(stderr, "GLCanvas: OpenGL not supported\n"); return -1; } if (!(vi = glXChooseVisual(fl_display, fl_screen, GLPROP(ob)->glconfig))) { /* if can't get a visual, quit */ fprintf(stderr, "GLCanvas: Can't get visual\n"); return -1; } /* change canvas defaults */ fl_set_canvas_visual(ob, vi->visual); fl_set_canvas_depth(ob, vi->depth); fl_set_canvas_colormap(ob, fl_create_colormap(vi, 1)); GLPROP(ob)->direct = DIRECT ; context = glXCreateContext(fl_display, vi, None, GLPROP(ob)->direct); if (!context) { fprintf(stderr, "Can't create GLX context!\n"); return -1; } /* under some conditions, the parent of the gl canvas might go away, leaving the old context and vi hanging. */ Thread_glx_cleanup(ob); GLPROP(ob)->context = context; GLPROP(ob)->xvinfo = vi; /* printf("******************************INIT\n"); */ return 0; } /* this procedure was not changed */ /* This routine is called after a valid window is created. It simply * binds the OpenGL context to the canvas window */ static int Main_glx_activate(FL_OBJECT * ob) { glXMakeCurrent(fl_display, FL_ObjWin(ob), GLPROP(ob)->context); return 0; } /* this procedure was not changed */ /* * cleanup is called before destroying the window. Might be called * more than once */ static int Main_glx_cleanup(FL_OBJECT * ob) { if (GLPROP(ob)->context) { glXDestroyContext(fl_display, GLPROP(ob)->context); XFree(GLPROP(ob)->xvinfo); GLPROP(ob)->context = 0; GLPROP(ob)->xvinfo = 0; } return 0; } /**********************************************************************************************/ /**********************************************************************************************/ /***************************************************************/ /* procedures executed by the two processes */ /* for drawing the two canvas */ /***************************************************************/ /* draw a cube of size t A GL context must be valid */ void BothDrawCube(float t){ /* Front */ glBegin(GL_QUADS); glNormal3f( 0, 0, 1); glVertex3f(-t/2, t/2, t/2); glVertex3f( t/2, t/2, t/2); glVertex3f( t/2,-t/2, t/2); glVertex3f(-t/2,-t/2, t/2); glEnd(); /* Top */ glBegin(GL_QUADS); glNormal3f( 0, 1, 0); glVertex3f(-t/2, t/2, t/2); glVertex3f( t/2, t/2, t/2); glVertex3f( t/2, t/2,-t/2); glVertex3f(-t/2, t/2,-t/2); glEnd(); /* Right */ glBegin(GL_QUADS); glNormal3f( 1, 0, 0); glVertex3f( t/2, t/2, t/2); glVertex3f( t/2, t/2,-t/2); glVertex3f( t/2,-t/2,-t/2); glVertex3f( t/2,-t/2, t/2); glEnd(); /* Bottom */ glBegin(GL_QUADS); glNormal3f( 0, -1, 0); glVertex3f( t/2,-t/2, t/2); glVertex3f( t/2,-t/2,-t/2); glVertex3f(-t/2,-t/2,-t/2); glVertex3f(-t/2,-t/2, t/2); glEnd(); /* Left */ glBegin(GL_QUADS); glNormal3f( -1, 0, 0); glVertex3f(-t/2,-t/2,-t/2); glVertex3f(-t/2,-t/2, t/2); glVertex3f(-t/2, t/2, t/2); glVertex3f(-t/2, t/2,-t/2); glEnd(); /* Rear */ glBegin(GL_QUADS); glNormal3f( 0, 0, -1); glVertex3f(-t/2, t/2,-t/2); glVertex3f( t/2, t/2,-t/2); glVertex3f( t/2,-t/2,-t/2); glVertex3f(-t/2,-t/2,-t/2); glEnd(); } /* draw a cube on TheCanvas*/ void BothDrawCanvas(FL_OBJECT *TheCanvas, int NbRot, GLfloat r, GLfloat g, GLfloat b){ #if DEBUG printf("BothDrawCanvas avant make c %x win %d context %d\n", TheCanvas, FL_ObjWin(TheCanvas), GLPROP(TheCanvas)->context); fflush(stdout); #endif /* note : since each thread has a single GLcanvas if is not necessary to call glXMakeCurrent each time. However, it is much safer in case of a future more complex implementation */ glXMakeCurrent(fl_display, FL_ObjWin(TheCanvas), GLPROP(TheCanvas)->context); glClearColor(r,g,b, 0.0); glClear(GL_DEPTH_BUFFER_BIT|GL_COLOR_BUFFER_BIT); glLoadIdentity(); glColor3f(1.0,0.0,0.0); glRotatef(1.3*NbRot, 1,0,0); glRotatef(1.3*NbRot, 0,1,0); glRotatef(2.0*NbRot, 0,0,1); BothDrawCube(2); glXSwapBuffers(fl_display, fl_get_canvas_id(TheCanvas)); } /* performs exposure, given the size of the specified canvas */ int BothExposeCanvas(FL_OBJECT *ob, int w, int h){ #if DEBUG printf("BothExposeCanvas avant make c %x win %d context %d\n", ob , FL_ObjWin(ob), GLPROP(ob)->context); fflush(stdout); #endif /* note : since each thread has a single GLcanvas if is not necessary to call glXMakeCurrent each time. However, it is much safer in case of a future more complex implementation */ glXMakeCurrent(fl_display, FL_ObjWin(ob), GLPROP(ob)->context); glViewport(0,0,w,h); glEnable(GL_LIGHTING); glEnable(GL_LIGHT0); glEnable(GL_DEPTH_TEST); glMatrixMode(GL_PROJECTION); glLoadIdentity(); gluPerspective(60.0, ((GLfloat)w)/(GLfloat)h, 1.0, 100.0); gluLookAt(0,0,10,0,0,0,0,1,0); glMatrixMode(GL_MODELVIEW); glLoadIdentity(); return(1); } /**********************************************************************************************/ /**********************************************************************************************/ /***************************************************************/ /* "tool"procedures called by the two processes */ /***************************************************************/ /* blocks the calling process HowMuch ms */ void BothWaitABit(int HowMuch){ struct timeval sleepTime; sleepTime.tv_sec = HowMuch /1000; sleepTime.tv_usec = (HowMuch%1000) * 1000; select(0, NULL, NULL, NULL, &sleepTime); } /**********************************************************************************************/ /**********************************************************************************************/ /***************************************************************/ /* procedures executed only by the Thread */ /***************************************************************/ /* called by the thread */ /* adds a glcanvas to the form Form->Form*/ void ThreadAddCanvas(){ FL_OBJECT *obj ; ThreadCanvas = obj = fl_create_glcanvas(FL_NORMAL_CANVAS, 100, 50, 395, 395 ,""); fl_modify_canvas_prop(obj, Thread_glx_init, Thread_glx_activate, Thread_glx_cleanup); fl_set_object_gravity(obj, FL_NorthWest, FL_SouthEast); fl_add_canvas_handler(obj, Expose, BothExposeHandler , NULL); fl_add_object(Form->Form, ThreadCanvas); } /* the thread itself*/ void * TheThread(void *data) { /* The canvas must be created by the thread since some GL variables (such as contexts) are not shared between threads*/ ThreadAddCanvas(); while(1) { /* should the thread draw ?*/ /* Check the mutex !*/ pthread_mutex_lock(&DrawOnMutex) ; /* in case of an Expose Event, ExposeEvent is non zero*/ if(ExposeEvent){ if(ExposeEvent == 1){ /* indicate that the ExposeEvent is gonna be performed */ ExposeEvent = 2 ; /* perform the expose */ BothExposeCanvas(ThreadCanvas, ThreadCanvas->w, ThreadCanvas->h); /* draw without moving the cube*/ { long Rot; pthread_mutex_lock(&ThreadComptRotMutex); Rot = ThreadComptRot; pthread_mutex_unlock(&ThreadComptRotMutex); BothDrawCanvas(ThreadCanvas, Rot, 0.5, 0.0, 0.2); } } /* if ExposeEvent == 2, the thread loops doing nothing. It waits the completion of the MainRqstExposeOnThreadCanvas procedure by the Main process */ } else { /* move the cube and draw */ long Rot; pthread_mutex_lock(&ThreadComptRotMutex); Rot = ThreadComptRot++; pthread_mutex_unlock(&ThreadComptRotMutex); BothDrawCanvas(ThreadCanvas, Rot, 0.5, 0.0, 0.2); } pthread_mutex_unlock(&DrawOnMutex); } } /**********************************************************************************************/ /**********************************************************************************************/ /***************************************************************/ /* Communication Main -> Thread */ /***************************************************************/ /* procedure called in case of an expose event */ /* asks the threads to call ThreadExposeCanvas and waits till completion */ /* The communication process between the main process and the thread should be improved */ void MainRqstExposeOnThreadCanvas(void) { ExposeEvent = 1 ; /* allow drawing (in case the thread was stoped )*/ if(DrawOnMutexLocked){ pthread_mutex_unlock(&DrawOnMutex); DrawOnMutexLocked = 0 ; } /* wait the completion of exposure by the thread */ while(ExposeEvent != 2) { /* wait a bit to avoid wasting CPU time */ BothWaitABit(10); } /* should we stop the thread ? */ if(! fl_get_button(Form->GoBtn)){ pthread_mutex_lock(&DrawOnMutex); DrawOnMutexLocked = 1 ; } /* end of the expose event */ ExposeEvent = 0; } /**********************************************************************************************/ /**********************************************************************************************/ /***************************************************************/ /* procedures executed only within the main process */ /***************************************************************/ /* Expose handler Always called by the main process Concerns for the two canvas */ int BothExposeHandler(FL_OBJECT *ob, Window win, int win_width, int win_height, XEvent *xev, void *user_data){ #if DEBUG printf("BothExposeHandler %x\n", ob); fflush(stdout); #endif if(ob == Form->MainCanvas){ BothExposeCanvas(ob, win_width, win_height); BothDrawCanvas(ob, MainComptRot, 0.1, 0.1, 0.5); } else if(ob == ThreadCanvas){ MainRqstExposeOnThreadCanvas(); } return 0 ; } /* creation of the form */ FORM_T *MainCreateForm(void){ FL_OBJECT *obj; FORM_T *fdui = (FORM_T *) fl_calloc(1, sizeof(*fdui)); fdui->Form = fl_bgn_form(FL_FLAT_BOX, 900, 480); fl_add_box(FL_FLAT_BOX, 0, 0, 900, 480, ""); fdui->GoBtn = obj = fl_add_button(FL_PUSH_BUTTON,5,50,90,50,"Go !"); fl_set_object_lalign(obj, FL_ALIGN_CENTER); fl_set_object_callback(obj,MainGoBtn_cb,0); fl_set_object_gravity(obj,FL_NorthWest, FL_NorthWest); obj = fl_add_button(FL_NORMAL_BUTTON,5,120,90,50,"Init !"); fl_set_object_lalign(obj, FL_ALIGN_CENTER); fl_set_object_callback(obj,MainInitBtn_cb,0); fl_set_object_gravity(obj,FL_NorthWest, FL_NorthWest); obj = fl_add_button(FL_NORMAL_BUTTON,5,400,90,50,"Exit !"); fl_set_object_lalign(obj, FL_ALIGN_CENTER); fl_set_object_callback(obj,MainExitBtn_cb,0); fl_set_object_gravity(obj,FL_SouthWest, FL_SouthWest); fl_end_form(); fdui->MainCanvas = obj = fl_create_glcanvas(FL_NORMAL_CANVAS,500,50,395,395,""); fl_add_canvas_handler(obj, Expose, BothExposeHandler , NULL); fl_set_object_gravity(obj,FL_NorthWest, FL_SouthWest); fl_modify_canvas_prop(obj, Main_glx_init, Main_glx_activate, Main_glx_cleanup); fl_add_object(fdui->Form, obj); return fdui; } /***************************************************************/ /* Callback procedures */ /***************************************************************/ /* idle callback called when rotation is on */ /* draws the canvas of the Main process */ int MainDrawOn_idle(XEvent *xev, void *userData){ char chaine[256]; MainComptRot ++; BothDrawCanvas(Form->MainCanvas, MainComptRot, 0.1, 0.1, 0.5); return 1; } /* start rotating the cubes on the two canvas*/ void MainGoBtn_cb(FL_OBJECT *ob, long data){ if(fl_get_button(ob)){ fl_set_object_label(ob, "Stop !"); if(DrawOnMutexLocked){ pthread_mutex_unlock(&DrawOnMutex); DrawOnMutexLocked = 0 ; fl_set_idle_callback(MainDrawOn_idle, NULL); } } else{ fl_set_object_label(ob, "Go !"); pthread_mutex_lock(&DrawOnMutex); DrawOnMutexLocked = 1 ; fl_set_idle_callback(NULL, NULL); } } /* start rotating the cubes on the two canvas*/ void MainInitBtn_cb(FL_OBJECT *ob, long data){ MainComptRot = 0 ; pthread_mutex_lock(&ThreadComptRotMutex); ThreadComptRot = 0 ; pthread_mutex_unlock(&ThreadComptRotMutex); MainRqstExposeOnThreadCanvas(); BothDrawCanvas(Form->MainCanvas, MainComptRot, 0.1, 0.1, 0.5); } void MainExitBtn_cb(FL_OBJECT *ob, long data){ exit(0); } /***************************************************************/ /* Main procedure */ /***************************************************************/ int main(int argc, char *argv[]){ /* INIT XForms */ fl_initialize(&argc, argv, "Thread", 0, 0); /*as far as I tested, XInitThreads is not really necessary here... */ if(XInitThreads() == 0){ if(fl_show_question("XInitThreads() is not supported on this machine\n\ The program may not work !\n\ Continue?", FL_PLACE_CENTER) == 0) exit(-1); } /* create the form */ Form = MainCreateForm(); fl_set_form_minsize(Form->Form, 900, 450); fl_set_form_maxsize(Form->Form, 900, 900); /* show the form */ fl_show_form(Form->Form,FL_PLACE_CENTER|FL_FREE_SIZE,FL_FULLBORDER,argv[0]); /* block the rotation of the canvas */ fl_set_button(Form->GoBtn, 0); pthread_mutex_lock(&DrawOnMutex); DrawOnMutexLocked =1; { pthread_attr_t t_Attr; pthread_t TheThreadId; pthread_attr_init(&t_Attr); /* create the thread. The thread will 1) create the canvas, 2) declare a handler for Expose events, which will be executed by the main process 3) add it to the form 4) wait for drawing */ pthread_create(&TheThreadId, &t_Attr, TheThread, NULL); pthread_attr_destroy(&t_Attr); } /* make sure the thread is created and added the canvas : wait a bit */ BothWaitABit(200); while(fl_check_forms()); #if DEBUG printf(" ********* MainCanvas adress %x\n", Form->MainCanvas); printf(" ********* ThreadCanvas adress %x\n", ThreadCanvas); #endif /* main loop */ while(1) { fl_check_forms(); } } --Apple-Mail-16-320643942-- --Apple-Mail-15-320643941 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed ------------------------------------------------------------------------=20= -------------------------- Nicolas CASTAGNE Chercheur, IR de l'ACROE/ICA, Association pour la Cr=E9ation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Cr=E9ation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------=20= -------------------------- --Apple-Mail-15-320643941-- From ldm at risc4.numis.nwu.edu Mon Jun 16 19:19:49 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Thu Jun 19 11:04:08 2003 Subject: [XForms] Libraries, configure etc In-Reply-To: <200306170017.39950.angus.leeming@btopenworld.com> Message-ID: I will....if I have time before I leave on Saturday to teach at a school in Moscow where I will be using the software On Tue, 17 Jun 2003, Angus Leeming wrote: > On Monday 16 June 2003 11:12 pm, you wrote: > > We are about to release some code which uses libforms. > > If a tgz file is available with a standard configure, > > we can use this otherwise we may need to write our > > way around including libforms. Can you make one > > available? > > Why not grab a copy of the cvs repository, following the instructions on the > web page I posted to you and thereafter: > > $ ./autogen.sh > $ ./configure your_options > $ make dist > > which should generate your desired tar.gz file. > > Regards, > Angus > > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm@risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From nicolas.castagne at imag.fr Thu Jun 19 19:05:22 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Thu Jun 19 12:01:57 2003 Subject: [XForms] Formbrowser : adjusting the size of the forms Message-ID: Hy all ! As you know, formbrowsers may need some improvments. For example, an adjustement of the vertical scrollbar (position, size) is needed in case of a call to fl_set_form_size() on one of the forms added to the formbrowser. Does any one actually work on this question ? Shall I have a look on it ? Who could answer to some question I have concerning the best way to solve these problems ? Thx, Nicolas From Mickael.Le.Coz at ifremer.fr Fri Jun 27 11:45:14 2003 From: Mickael.Le.Coz at ifremer.fr (Mickael LE COZ) Date: Fri Jun 27 09:15:01 2003 Subject: [XForms] installation on cygwin emulator Message-ID: <3EFC041A.D4C30C0F@ifremer.fr> Hello, I have untar the "xforms-1.0.tar.gz" file in he X11r6 directory; So when I type ,in the Cygwin/XFree86 rl : xmkmkf >> mv -f Makefile Makefile.bak >>imake -DUseInstalled -I/usr/X11R6/lib/X11/config >>/tmp/IIf.004357:92: unterminated #if conditional >>imake: Exit code 1. >> Stop. and when I type : make Makefiles or make install >>Makefile:11: *** missing operator. Stop Here is the Makefile: # 1 "Imakefile.c" # 1 "/usr/X11R6/lib/X11/config/Imake.tmpl" 1 XCOMM ---------------------------------------------------------------------- XCOMM Makefile generated from "Imake.tmpl" and XCOMM $Xorg: Imake.tmpl,v 1.4 2000/08/17 19:41:46 cpqbld Exp $ XCOMM XCOMM XCOMM XCOMM XCOMM $XFree86: xc/config/cf/Imake.tmpl,v 3.114 2001/11/08 02:09:06 tsi Exp $ XCOMM ---------------------------------------------------------------------- What is the problem? thank you for your help, Micka?l. From nicolas.castagne at imag.fr Fri Jun 27 16:55:13 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri Jun 27 09:51:48 2003 Subject: [XForms] OpenGL and Threads- again Message-ID: This mail is addressed to those that use OpenGL within XForms. I have had no answer concerning my last message, but I really think the subject of threads and openGL is of interest for the XForms community..... My aim concerning this question is to add a small demo to the XForms demo programs. So, let's play again ! ------- You will find enclosed a short program which implements a GLCanvas drawn by a thread. This program is stable with direct rendering. However, it is not stable on my IRIX system in case of rendering through the X sever, especially in case of a distant execution. -> Could some of you try to compile this program and run it locally and on a distant machine ? 10 min. work ! ------- The next part of the message is addressed to those who have successfully implemented a GLCanvas drawn by a thread. Did you tried non-direct rendering on these canvas ? If it runs properly, it would be very helpful if you could have a look to my code and give advices ! Thx , Nicolas From nicolas.castagne at imag.fr Fri Jun 27 17:36:55 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri Jun 27 10:33:40 2003 Subject: [XForms] OpenGL and Threads- again In-Reply-To: Message-ID: Sure it is better with the attachement... Thx for testing ! Nicolas -------------- next part -------------- Skipped content of type multipart/appledouble-------------- next part -------------- Le vendredi, 27 jun 2003, à 15:55 Europe/Paris, Nicolas Castagné a écrit : > To subscribers of the xforms list > > > This mail is addressed to those that use OpenGL within XForms. > > I have had no answer concerning my last message, but I really think > the subject of threads and openGL is of interest for the XForms > community..... > My aim concerning this question is to add a small demo to the XForms > demo programs. > > So, let's play again ! > > ------- > > You will find enclosed a short program which implements a GLCanvas > drawn by a thread. > > This program is stable with direct rendering. However, it is not > stable on my IRIX system in case of rendering through the X sever, > especially in case of a distant execution. > > -> Could some of you try to compile this program and run it locally > and on a distant machine ? 10 min. work ! > > ------- > > The next part of the message is addressed to those who have > successfully implemented a GLCanvas drawn by a thread. > > Did you tried non-direct rendering on these canvas ? > If it runs properly, it would be very helpful if you could have a > look to my code and give advices ! > > > Thx , > > Nicolas > > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request@bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > From Jean-Marc.Lasgouttes at inria.fr Fri Jun 27 17:46:14 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 27 10:46:23 2003 Subject: [XForms] installation on cygwin emulator In-Reply-To: <3EFC041A.D4C30C0F@ifremer.fr> (Mickael LE's message of "Fri, 27 Jun 2003 10:45:14 +0200") References: <3EFC041A.D4C30C0F@ifremer.fr> Message-ID: >>>>> "Mickael" == Mickael LE COZ writes: Mickael> To subscribers of the xforms list Hello, Mickael> I have untar the "xforms-1.0.tar.gz" file in he X11r6 Mickael> directory; So when I type ,in the Cygwin/XFree86 rl : xmkmkf Did you try 'xmkmf -a'? JMarc From nicolas.castagne at imag.fr Fri Jun 27 21:57:00 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri Jun 27 14:53:35 2003 Subject: Fwd: [XForms] OpenGL and Threads- again Message-ID: <220DA38B-A8D1-11D7-8814-000393C76CA6@imag.fr> Hi all, Thx for trying David. I decided to fwd your mail on the mail list (see below), since it may be of interest for other. The behaviour you obtained is somehow the one I get on octane - appart the fact SGi octane is a bit slower ;-) The questions then are : 1) is multithreading correctly supported by OpenGL in case of non-direct rendering ? 2) if so, where is the fault in my program ? Wish some of you may answer ! Once again, I would ask those who have already implemented a 'multithreaded' GL canvas under XForms to test their program with non-direct rendering (Canvas's direct field set to 0 or distant execution). Thx, Nicolas D?but du message r?exp?di? : > De: David Scriven > Date: Ven 27 jun 2003 20:42:26 Europe/Paris > ?: "Nicolas_Castagn?" > Objet: R?p : [XForms] OpenGL and Threads- again > > Hi Nicolas, > > I tried your program on a platform running RedHat 9 with XFree86 4.3.0 > on an NVIDIA Ti 4200 (NVIDIA supply their own drivers and GL libraries) > > 1. With DIRECT = 1 the program ran fine although the rate in the > left hand window was so fast that the cube was blurred. The rate > in the right window was much slower. > > 2. With DIRECT = 0 the program still worked, BUT, the program would > not respond to the buttons once Go! was pressed and the cube on > the right did not move. In addition, when I covered and then uncovered > the window, the right hand screen was not redrawn (ie it remained > black). In addition I got messages like: > Xlib: unexpected async reply (sequence 0x288ad)! > > 3,. In light of the above I didn't try remote execution. > > I compiled the program with > > gcc ThreadGL.c -o ThreadGL -I /usr/X11R6/include -O2 -L/usr/X11R6/lib > -lforms -lformsGL -lpthread -lGL -lGLU > > using gcc ver 3.2.2 > > I'll try and look through your code this weekend if I get a chance. > > DS > > : > To subscribers of the xforms list >> >> >> This mail is addressed to those that use OpenGL within XForms. >> >> I have had no answer concerning my last message, but I really think >> the subject of threads and openGL is of interest for the XForms >> community..... >> My aim concerning this question is to add a small demo to the XForms >> >> demo programs. >> >> So, let's play again ! >> >> ------- >> >> You will find enclosed a short program which implements a GLCanvas >> drawn by a thread. >> >> This program is stable with direct rendering. However, it is not >> stable on my IRIX system in case of rendering through the X sever, >> especially in case of a distant execution. >> >> -> Could some of you try to compile this program and run it locally >> and on a distant machine ? 10 min. work ! >> >> ------- >> >> The next part of the message is addressed to those who have >> successfully implemented a GLCanvas drawn by a thread. >> >> Did you tried non-direct rendering on these canvas ? >> If it runs properly, it would be very helpful if you could have a >> look >> to my code and give advices ! >> >> >> Thx , >> >> Nicolas >> >> >> _______________________________________________ >> To unsubscribe, send the message "unsubscribe" to >> xforms-request@bob.usuhs.mil or see: >> http://cweblog.usuhs.mil/mailman/listinfo/xforms >> XForms Home Page: http://world.std.com/~xforms >> List Archive: http://bob.usuhs.mil/pipermail/xforms and >> http://bob.usuhs.mil/mailserv/list-archives/ >> Development: http://savannah.nongnu.org/files/?group=xforms > > ______________________________________________________________________ > Post your free ad now! http://personals.yahoo.ca > From ddembrow at nlxcorp.com Mon Jun 30 16:43:39 2003 From: ddembrow at nlxcorp.com (ddembrow@nlxcorp.com) Date: Mon Jun 30 16:18:13 2003 Subject: [XForms] Next xforms release inquiry Message-ID: Are there any plans to release another version of xforms including the latest modifications as a stable release beyond 1.0 rc5? From Jean-Marc.Lasgouttes at inria.fr Tue Jul 1 11:24:21 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Jul 1 04:24:26 2003 Subject: [XForms] Next xforms release inquiry In-Reply-To: (ddembrow@nlxcorp.com's message of "Mon, 30 Jun 2003 15:43:39 -0400") References: Message-ID: >>>>> "ddembrow" == ddembrow writes: ddembrow> Are there any plans to ddembrow> release another version of xforms including the latest ddembrow> modifications as a stable release beyond 1.0 rc5? The latest released version is actually 1.0, available here https://savannah.nongnu.org/files/?group=xforms In the cvs available from there https://savannah.nongnu.org/cvs/?group=xforms you will find what is going to become 1.1.0. It contains several bug fixes, and support for autoconf-based build. This is the part that is not finished yet. Hope this helps. JMarc From davidwriter at yahoo.com Sun Jul 6 18:00:08 2003 From: davidwriter at yahoo.com (David Scriven) Date: Sun Jul 6 17:00:12 2003 Subject: [XForms] Timing in XForms In-Reply-To: <200306070213.h572D0004065@pc18.math.umbc.edu> Message-ID: <20030706210008.99028.qmail@web41213.mail.yahoo.com> When XForms was originally developed, in the mid 1980's, machines were much slower than they are today, so I suspect the designers had to make a compromise between CPU cycles and response. In XForms there are two critical values that are set : TIMER_RES, which is 50 ms (and can be partly reset by fl_set_idle_delta), and the number of FL_STEP events that are swallowed before the system responds (l 1977-78 of forms.c) /* Handle FL_STEP. Every 10 events. This will reduce cpu usage */ if ((++auto_cnt % 10) == 0) This latter statement clearly will slow down the way in which XForms responds and probably explains the effect I have noticed on my machines; that XForms programs speed up when the mouse is moved. My query is whether the settings in XForms are appropriate to today's fast machines and whether these settings could be dynamically changed to suit the machine that XForms is running on. What I would have in mind is a routine inside fl_initialize that detects the real clock precision and clock speed and sets the values for TIMER_RES, and steps swallowed, dynamically. XForms is extremely complex and such changes might have unforseen side effects (T.C., your comments?), but I think it might be worth thinking about. DS ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From jac at casurgica.com Fri Jul 11 00:33:25 2003 From: jac at casurgica.com (jac@casurgica.com) Date: Thu Jul 10 23:33:32 2003 Subject: [XForms] fl_get_object_component In-Reply-To: <20030706210008.99028.qmail@web41213.mail.yahoo.com> References: <200306070213.h572D0004065@pc18.math.umbc.edu> <20030706210008.99028.qmail@web41213.mail.yahoo.com> Message-ID: <39941.69.3.42.242.1057894405@sun-qmail17.laserlink.net> Does anybody know where I can find a list of all the objects that have component objects that can be retrieved with fl_get_object_component(), and of what those component objects are? J. Cipriani From jac at casurgica.com Fri Jul 11 22:48:00 2003 From: jac at casurgica.com (jac@casurgica.com) Date: Fri Jul 11 21:48:07 2003 Subject: [XForms] A tip for using secret inputs. In-Reply-To: <20030706210008.99028.qmail@web41213.mail.yahoo.com> References: <200306070213.h572D0004065@pc18.math.umbc.edu> <20030706210008.99028.qmail@web41213.mail.yahoo.com> Message-ID: <46119.69.3.42.242.1057974480@sun-qmail12.laserlink.net> The SECRET_INPUT is completely unusable. However, you can turn a NORMAL_INPUT into somewhat of a secret input box like so: fl_set_input_color(MyInput, MyInput->col2, MyCaretColor); Where "MyInput" is your NORMAL_INPUT (an FL_OBJEC T*), and MyCaretColor is whatever color you want the caret to be. It makes the text "invisible" by setting the text color to the input's background color. It makes the highlight invisible, too, though, but its still better than the SECRET_INPUT. I only tried that on a form with one input box, though, so the text might become visible when the box loses focus. I dunno. J. Cipriani From rostamian at umbc.edu Sat Jul 12 12:33:00 2003 From: rostamian at umbc.edu (Rouben Rostamian) Date: Sat Jul 12 11:33:03 2003 Subject: [XForms] question about resizing forms Message-ID: <200307121533.h6CFX0jO005951@pc18.math.umbc.edu> I want to set up a form which can be resized only in discrete steps. E.g., in interactive resizing, the form's width and height may only change in multiples of 10 pixels. How do I do this in xforms? -- Rouben Rostamian From jac at casurgica.com Fri Jul 18 12:56:06 2003 From: jac at casurgica.com (jac@casurgica.com) Date: Fri Jul 18 11:56:12 2003 Subject: [XForms] BUGFIX: Tab control fixed, working secret inputs, fixed focus and resize problems, etc, etc... Message-ID: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Use GTK. From drriddle at qwest.net Fri Jul 18 20:09:33 2003 From: drriddle at qwest.net (Reed Riddle) Date: Fri Jul 18 20:09:42 2003 Subject: [XForms] BUGFIX: Tab control fixed, working secret inputs, fixed focus and resize problems, etc, etc... In-Reply-To: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Message-ID: <467B5611-B97D-11D7-AB01-003065E23D38@qwest.net> On Friday, July 18, 2003, at 10:56 AM, jac@casurgica.com wrote: > To subscribers of the xforms list > > > Use GTK. Awww, but that would be like giving up! :) When I started building my application, I looked at GTK. It didn't look like it had a plotting element nearly as flexible as the xyplot that Xforms has (and I even had to add a small patch to that to do what I wanted). I also could understand the callback code much better; the GTK interface builder put all kinds of crap in there, while it hardly took me any time at all to figure out Xforms. Oh, and I had never built a GUI before. It's possible that GTK is better now, and that it might be easy for me to switch my code over, but why go to all the trouble when what I have now works well enough? Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle@qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From Jean-Marc.Lasgouttes at inria.fr Thu Jul 31 19:24:54 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Jul 31 12:25:08 2003 Subject: [XForms] [PATCH] simplifying local.h: the trivial bits Message-ID: The attached patch does the easy part in the job of getting rid of local.h. Angus, could you please double check that it makes sense and apply? In what remains, there are checks for xenix, vms, lynx and sunos 4. I'd be happy to get rid of those. From what I can see, only sunos4 had a xforms 0.89 build, so the others would not be missed (I could not even find xenix). Thoughts? JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: local.diff Type: text/x-patch Size: 5836 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030731/fb6de625/local.bin From Jean-Marc.Lasgouttes at inria.fr Thu Jul 31 19:36:28 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Jul 31 12:36:33 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200307311732.59411.leeming@lyx.org> (Angus Leeming's message of "Thu, 31 Jul 2003 17:32:59 +0000") References: <200307311732.59411.leeming@lyx.org> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Thursday 31 July 2003 4:24 pm, Jean-Marc Lasgouttes wrote: >> The attached patch does the easy part in the job of getting rid of >> local.h. Angus, could you please double check that it makes sense >> and apply? >> >> In what remains, there are checks for xenix, vms, lynx and sunos 4. >> I'd be happy to get rid of those. From what I can see, only sunos4 >> had a xforms 0.89 build, so the others would not be missed (I could >> not even find xenix). >> >> Thoughts? Angus> Fantastic effort. The logic here seems to be inverted though. Angus> Am I right? Yes, it should be #ifdef HAVE_USLEEP also, there is a problem with line 83 of signal.c, where dec cc does not like my code. I have to leave now, I'll have a look tomorrow. JMarc From angus.leeming at btopenworld.com Thu Jul 31 18:38:41 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Jul 31 12:38:05 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: Message-ID: <200307311732.59411.leeming@lyx.org> On Thursday 31 July 2003 4:24 pm, Jean-Marc Lasgouttes wrote: > The attached patch does the easy part in the job of getting rid of > local.h. Angus, could you please double check that it makes sense and > apply? > > In what remains, there are checks for xenix, vms, lynx and sunos 4. > I'd be happy to get rid of those. From what I can see, only sunos4 had > a xforms 0.89 build, so the others would not be missed (I could not > even find xenix). > > Thoughts? Fantastic effort. The logic here seems to be inverted though. Am I right? -#if !defined(DONT_HAVE_USLEEP) +#if !defined(HAVE_USLEEP) Angus From myaconis at nycap.rr.com Thu Jul 31 12:49:00 2003 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Thu Jul 31 15:50:04 2003 Subject: [XForms] Form imaging problems References: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Message-ID: <006301c3577b$499ebe80$6501a8c0@dimensionxp> For some reason the first time I display a form it doesn't image properly. The attached images show what it looks like. The window consists of approximately 50 forms, a main form, a scrollable form, and 40+ row forms whos objects are added to the scrollable form which is then attached to the main form via a form browser. Any suggestions or help would be much appreciated. (The good.png image shows how the form should look. The bad.png image shows how it looks when it is first displayed.) -------------- next part -------------- z'??mj?Zr?????+???t??y???x????? ???J,???8???z?????????V???+?m???????&?_??????????k?j?Zr?????M7???????????v??-------------- next part -------------- A non-text attachment was scrubbed... Name: good.png Type: image/png Size: 34424 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030731/ae087b2f/good.png From drriddle at qwest.net Thu Jul 31 22:20:45 2003 From: drriddle at qwest.net (Reed Riddle) Date: Thu Jul 31 22:20:49 2003 Subject: [XForms] Form imaging problems In-Reply-To: <006301c3577b$499ebe80$6501a8c0@dimensionxp> Message-ID: Try freezing the form, then building it, filling in the data, etc, and then unfreeze the form when everything is loaded. I see this sometimes, but that's usually before I get around to adding the freezing/unfreezing cycle when I do something to the form. Reed On Thursday, July 31, 2003, at 10:49 AM, Matthew Yaconis wrote: > To subscribers of the xforms list > > > For some reason the first time I display a form it doesn't image > properly. > The attached images show what it looks like. The window consists of > approximately 50 forms, a main form, a scrollable form, and 40+ row > forms > whos objects are added to the scrollable form which is then attached > to the > main form via a form browser. > > Any suggestions or help would be much appreciated. (The good.png image > shows how the form should look. The bad.png image shows how it looks > when > it is first displayed.) > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request@bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle@qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From myaconis at nycap.rr.com Fri Aug 1 11:22:04 2003 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Fri Aug 1 10:22:03 2003 Subject: [XForms] Odd menu field behavior Message-ID: <004401c35838$491d5da0$6501a8c0@dimensionxp> I have a menu object that I generate an FL_PUP_ENTRY structure for from data retrieved from a mysql database. I don't do anything particularly special with this menu object but for some reason the fl_get_menu function returns a "0" (zero) randomly when selections are made off of the list. Does anyone have any idea why fl_get_menu might return a 0 when called within the object's callback routine? The callback routine goes like this: ... callback_routine (...) { choice = fl_get_menu( ob ); ... generic_routine_for_handling(ob, ...); } The generic_routine_for_handling also calls fl_get_menu. Thanks for the help on the last question as well! From eisfuchs at tigress.com Fri Aug 1 18:15:45 2003 From: eisfuchs at tigress.com (Eisfuchs) Date: Fri Aug 1 11:15:51 2003 Subject: [XForms] Unsubscribe and help not working Message-ID: <200308011715.45725.eisfuchs@tigress.com> Hi! I'm trying to unsubscribe from the list but everytime I get errors back. I send an eMail with Subject: unsubscribe and empty body or unsubscribe in the body. Even the help command does not work. Can someone help me? > The original message was received at Fri, 1 Aug 2003 11:01:01 -0400 > from mail.yatho.de [213.200.97.76] > > ----- The following addresses had permanent fatal errors ----- > "|/var/mailman//mail/mailman mailcmd xforms" > (reason: 6) > (expanded from: ) > > ----- Transcript of session follows ----- > Illegal command: mailcmd > 554 5.3.0 unknown mailer error 6 Final-Recipient: RFC822; xforms-request@bob.usuhs.mil X-Actual-Recipient: X-Unix; |/var/mailman//mail/mailman mailcmd xforms Action: failed Status: 5.0.0 Diagnostic-Code: X-Unix; 6 Last-Attempt-Date: Fri, 1 Aug 2003 11:14:46 -0400 -- Eisfuchs, from Germany. From angus.leeming at btopenworld.com Fri Aug 1 17:37:01 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Aug 1 11:36:27 2003 Subject: [XForms] Unsubscribe and help not working In-Reply-To: <200308011715.45725.eisfuchs@tigress.com> References: <200308011715.45725.eisfuchs@tigress.com> Message-ID: <200308011637.01891.angus.leeming@btopenworld.com> On Friday 01 August 2003 3:15 pm, Eisfuchs wrote: > To subscribers of the xforms list > > > Hi! > > I'm trying to unsubscribe from the list but everytime I get errors back. > I send an eMail with Subject: unsubscribe and empty body or unsubscribe in > the body. Even the help command does not work. Can someone help me? And what happens if you follow the prescription in the footer to this mail? [snip] To unsubscribe, send the message "unsubscribe" to xforms-request@bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms Angus From angus.leeming at btopenworld.com Wed Aug 6 18:53:22 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Aug 6 12:53:28 2003 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: <200308061753.22818.angus.leeming@btopenworld.com> On Wednesday 06 August 2003 4:01 pm, L. D. Marks wrote: > In browser.h the definitions: > > FL_EXPORT void fl_set_browser_vscrollbar( > FL_OBJECT *ob, > int on > ); > > FL_EXPORT void fl_set_browser_hscrollbar( > FL_OBJECT *ob, > int on > ); > > are incompatible with at least some C++ where "on" > is predefined. Ouch! Your compiler is brain dead. What are you using? Does it have any other problems with the library? Regards, Angus From angus.leeming at btopenworld.com Thu Aug 7 10:35:20 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Aug 7 04:35:29 2003 Subject: [XForms] Libraries: broken libtool.m4 In-Reply-To: References: Message-ID: <200308070935.20490.angus.leeming@btopenworld.com> On Wednesday 06 August 2003 10:59 pm, L. D. Marks wrote: > The version of libtool.m4 that you have in acinclude.m4 > appears to be broken on an HPUX 10.20 (works under linux); > after removing it the standard version picked up by > autoconf/automake & friends works fine. Hi, Laurence. Could you tell us what version of autoconf/automake you are using? From psg at debian.org Tue Sep 2 16:28:31 2003 From: psg at debian.org (Peter S Galbraith) Date: Tue Sep 2 15:28:45 2003 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030411130538.61277.qmail@web13403.mail.yahoo.com> References: <20030411130538.61277.qmail@web13403.mail.yahoo.com> Message-ID: <20030902192832.F003738F37@mixing.qc.dfo.ca> T.C. Zhao wrote: > All I need to do is boot up my old linux box and recover the doc and send it. > Will do this sometime in April (I've been travelling, and am sending this > email from Tokyo). > -TC Hi T.C., I really hate to keep nagging you like this. :-) You meant to release the sources of the XForms manual last April but never got around to it. This is a reminder. Also, please avoid using the GNU Free Documentation License (GFDL) since it not a free software license and therefore cannot be included in the Debian distribution. Using the GPL would be fine. I'm writing now because while the Debian GNU/Linux distribution doesn't make a release as often as it should, a freeze is due shortly for a Christmas release. The current packaging of the XForms manual has this license: No part of this document may be reproduced, in any form or by any means, without permission from the authors. Permission to produce hardcopies in its entirety for private use is granted. This lacks the permission to us to _distribute_ the manual so I'll pull the package from Debian's non-free archive soon, before the upcoming release. But instead of removing the package, it would be great to get the manual sources under a free license and move the package to Debian's main archive. Hopefully you will find time to do this. Otherwise I can always re-create the Debian package at a later time when it is released under a free license. Thanks for your time! -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From ldm at risc4.numis.nwu.edu Wed Aug 6 17:02:02 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed Sep 3 08:45:21 2003 Subject: [XForms] Libraries: small C++ bug In-Reply-To: <200306170017.39950.angus.leeming@btopenworld.com> Message-ID: In browser.h the definitions: FL_EXPORT void fl_set_browser_vscrollbar( FL_OBJECT *ob, int on ); FL_EXPORT void fl_set_browser_hscrollbar( FL_OBJECT *ob, int on ); are incompatible with at least some C++ where "on" is predefined. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm@risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From ldm at risc4.numis.nwu.edu Thu Aug 7 00:00:25 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed Sep 3 08:45:22 2003 Subject: [XForms] Libraries: broken libtool.m4 In-Reply-To: Message-ID: The version of libtool.m4 that you have in acinclude.m4 appears to be broken on an HPUX 10.20 (works under linux); after removing it the standard version picked up by autoconf/automake & friends works fine. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm@risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From Jean-Marc.Lasgouttes at inria.fr Wed Sep 3 19:37:01 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Sep 3 12:37:19 2003 Subject: [XForms] Re: xforms configuration In-Reply-To: <200309031619.56049.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 3 Sep 2003 16:19:56 +0000") References: <200309031619.56049.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs Angus> and has made some changes, attached. Below is his summary of Angus> what he's done, but I think it can be simply summarised as Angus> Why do we ship these files in the config directory: Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh Angus> They are all parts of the autoconf/libtool code. Why not allow Angus> the user to use the versions that come with their versions of Angus> the autotools? Because a user of xforms is not required to have any of the autotools installed (unless when using cvs, of course). I think that we have to ship all these files, except possibly libtools.m4. However, I think that we must sync this file with ltmain.sh, so even this one is needed. The right thing to do is to upgrade libtool files to the latest version (our libtool.m5 is from 2001, it seems). The choice is libtool 1.4.2 from october 2002 or 1.5 from last month. I do not know whether 1.5 can cause problems. depcomp comes probably with automake, and the config.* from autoconf. All we have to do is upgrade from recent versions. Angus> 1) Removed the "on", since it does not seem to be needed. This is of course a solution, but how does 'on' appear on this system? Is this a preprocessor define in some system header? This would be _very_ bad... Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems. Fine, we probably do not need this one. But I do not think it makes any difference, since we do not rely anywhere on the HAVE_MALLOC macro. Laurence, did it really cause a problem? Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the Angus> version I was using it was not being set. I'll have to check this one. Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and Angus> let automake/autoconf/libtool handle all this. Your version did Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5 I think we should just upgrade the versions we have (after making sure that libtool 1.5 requirements are not too high). Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" Probably OK. Angus> 6) Added a few files needed by make dist (e.g. README, I can't Angus> remember them all). Good idea. Angus> 7) I also did some stuff for our own purposes, primarily Angus> removed pixmap.c so no extra libraries are needed and removed Angus> the checks for them, turned off sharing by default, restricted Angus> the build/dist to the library and removed some of your Angus> informational output at the end of the build. FYI, it works Angus> fine, and is setup so our code will compile forms if it does Angus> not find a working copy already existing on the computer. This should be investigated... Thanks for the input Laurence. JMarc From angus.leeming at btopenworld.com Wed Sep 3 17:19:56 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Sep 3 12:59:56 2003 Subject: [XForms] xforms configuration Message-ID: <200309031619.56049.angus.leeming@btopenworld.com> Jean-Marc, Laurence Marks has been trying to compile xforms cvs and has made some changes, attached. Below is his summary of what he's done, but I think it can be simply summarised as Why do we ship these files in the config directory: config.guess config.sub depcomp libtool.m4 ltmain.sh They are all parts of the autoconf/libtool code. Why not allow the user to use the versions that come with their versions of the autotools? Angus Laurence's 'ChangeLog' follows: I did quite a few additional hacks on your configure, testing it on HP,SGI,SUN,cgwin with both native & gcc compilers. The major changes are (I think): 1) Removed the "on", since it does not seem to be needed. 2) Removed AC_FUNC_MALLOC since it is broken on many systems. 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the version I was using it was not being set. 4) Removed the libtool stuff that you had in acinclude.m4, and let automake/autoconf/libtool handle all this. Your version did not work with automake-1.7, autoconf-2.57, libtool-1.5 5) Added (slight overkill, but AC_PATH_XTRA does not work the way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" 6) Added a few files needed by make dist (e.g. README, I can't remember them all). 7) I also did some stuff for our own purposes, primarily removed pixmap.c so no extra libraries are needed and removed the checks for them, turned off sharing by default, restricted the build/dist to the library and removed some of your informational output at the end of the build. FYI, it works fine, and is setup so our code will compile forms if it does not find a working copy already existing on the computer. -------------- next part -------------- A non-text attachment was scrubbed... Name: marks.diff.gz Type: application/x-gzip Size: 67335 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030903/84e1704e/marks.diff.bin From larsbj at lyx.org Thu Sep 4 00:44:50 2003 From: larsbj at lyx.org (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: Wed Sep 3 17:45:15 2003 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: "L. D. Marks" writes: | To subscribers of the xforms list > > | In browser.h the definitions: > | FL_EXPORT void fl_set_browser_vscrollbar( | FL_OBJECT *ob, | int on | ); > | FL_EXPORT void fl_set_browser_hscrollbar( | FL_OBJECT *ob, | int on | ); > | are incompatible with at least some C++ where "on" | is predefined. Predefined as what? This is certainly not Standard C++. Can you should where/how you get that error? (and the error itself) -- Lgb From larsbj at lyx.org Thu Sep 4 01:53:03 2003 From: larsbj at lyx.org (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: Wed Sep 3 18:53:08 2003 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: "L. D. Marks" writes: | I did a little more checking, and it looks like our code was defining | "on" itself, and since this was in an include that came before forms.h | this created problems. (We probably should not be using "on" - maybe | you might want to think about "forms_on" to be more robust. The | earlier forms header files did not have the "on" defined.) What stops you from polluting the global namespace with a macro/define called forms_on? (and using forms_on in xforms give away the wrong meaning of the parameter... and removing it from the function declaration makes it impossible to see what this int is) It is your code that is in error, not xforms. -- Lgb From Holly.Yeh at grc.nasa.gov Thu Sep 4 11:53:32 2003 From: Holly.Yeh at grc.nasa.gov (Holly Yeh) Date: Thu Sep 4 10:53:51 2003 Subject: [XForms] Making XForms Multi-Threaded Message-ID: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> Hi, We are planning on making XForms multi-threaded. If anyone has any planning or been working on the issue, Please let us know. Thank you very much! Holly Yeh. From angus.leeming at btopenworld.com Thu Sep 4 17:08:46 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Sep 4 11:08:52 2003 Subject: [XForms] Making XForms Multi-Threaded In-Reply-To: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> Message-ID: <200309041608.46270.angus.leeming@btopenworld.com> On Thursday 04 September 2003 2:53 pm, Holly Yeh wrote: > To subscribers of the xforms list > > > Hi, > We are planning on making XForms multi-threaded. If anyone has any > planning or been working on the issue, Please let us know. > Thank you very much! > > Holly Yeh. Hello, Holly. that sounds great. However, I wonder if you might not find FLTK (Fast Light ToolKit http://www.fltk.org) fits your needs already. Yeah, yeah, I know. I'm the guy fronting xforms, not fltk. Nonetheless, and without wanting to appear disloyal to xforms, FLTK has an active developer community (which IMO counts for a lot), it has multithreaded support already and, perhaps most importantly, it has an xforms -> fltk converter so porting your app might well be painless. http://www.fltk.org/documentation.php/doc-1.1/forms.html#15_1 Kind regards, Angus From ldm at risc4.numis.nwu.edu Wed Sep 3 12:45:22 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Thu Sep 4 12:51:34 2003 Subject: [XForms] Re: xforms configuration In-Reply-To: Message-ID: On Wed, 3 Sep 2003, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs > Angus> and has made some changes, attached. Below is his summary of > Angus> what he's done, but I think it can be simply summarised as > > Angus> Why do we ship these files in the config directory: > Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh > > Angus> They are all parts of the autoconf/libtool code. Why not allow > Angus> the user to use the versions that come with their versions of > Angus> the autotools? > > Because a user of xforms is not required to have any of the autotools > installed (unless when using cvs, of course). > > I think that we have to ship all these files, except possibly > libtools.m4. However, I think that we must sync this file with > ltmain.sh, so even this one is needed. > > The right thing to do is to upgrade libtool files to the latest > version (our libtool.m5 is from 2001, it seems). The choice is libtool > 1.4.2 from october 2002 or 1.5 from last month. I do not know whether > 1.5 can cause problems. In the version that was in the cvs, the libtool stuff was in acinclude.m4 so cancelled my more current version of libtool etc. I removed it from acinclude.m4 -- you do need to ship a viable version. > > depcomp comes probably with automake, and the config.* from autoconf. > All we have to do is upgrade from recent versions. > > Angus> 1) Removed the "on", since it does not seem to be needed. > > This is of course a solution, but how does 'on' appear on this system? > Is this a preprocessor define in some system header? This would be > _very_ bad... If I remember right, "on" was defined in g++. The header was fine with gcc, died with g++. > > Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems. > > Fine, we probably do not need this one. But I do not think it makes > any difference, since we do not rely anywhere on the HAVE_MALLOC > macro. Laurence, did it really cause a problem? Yes. If it did not find a GNU malloc it redefined it to rpl_malloc and you then had to link this in otherwise you would have an undefined symbol. > > Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the > Angus> version I was using it was not being set. > > I'll have to check this one. > > Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and > Angus> let automake/autoconf/libtool handle all this. Your version did > Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5 > > I think we should just upgrade the versions we have (after making sure > that libtool 1.5 requirements are not too high). > > Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the > Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) > Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 > Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" > > Probably OK. > > Angus> 6) Added a few files needed by make dist (e.g. README, I can't > Angus> remember them all). > > Good idea. > > Angus> 7) I also did some stuff for our own purposes, primarily > Angus> removed pixmap.c so no extra libraries are needed and removed > Angus> the checks for them, turned off sharing by default, restricted > Angus> the build/dist to the library and removed some of your > Angus> informational output at the end of the build. FYI, it works > Angus> fine, and is setup so our code will compile forms if it does > Angus> not find a working copy already existing on the computer. > > This should be investigated... > > Thanks for the input Laurence. > > JMarc > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm@risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From ldm at risc4.numis.nwu.edu Wed Sep 3 18:33:20 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Thu Sep 4 12:51:35 2003 Subject: [XForms] Libraries: small C++ bug In-Reply-To: Message-ID: I did a little more checking, and it looks like our code was defining "on" itself, and since this was in an include that came before forms.h this created problems. (We probably should not be using "on" - maybe you might want to think about "forms_on" to be more robust. The earlier forms header files did not have the "on" defined.) On Wed, 3 Sep 2003, [iso-8859-1] Lars Gullik Bjønnes wrote: > "L. D. Marks" writes: > > | To subscribers of the xforms list > > > > > | In browser.h the definitions: > > > | FL_EXPORT void fl_set_browser_vscrollbar( > | FL_OBJECT *ob, > | int on > | ); > > > | FL_EXPORT void fl_set_browser_hscrollbar( > | FL_OBJECT *ob, > | int on > | ); > > > | are incompatible with at least some C++ where "on" > | is predefined. > > Predefined as what? > This is certainly not Standard C++. > > Can you should where/how you get that error? > (and the error itself) > > -- > Lgb > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm@risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From jac4 at andrew.cmu.edu Thu Sep 4 00:39:03 2003 From: jac4 at andrew.cmu.edu (jason) Date: Thu Sep 4 12:51:35 2003 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: > | I did a little more checking, and it looks like our code was defining > | "on" itself, and since this was in an include that came before forms.h > | this created problems. (We probably should not be using "on" - maybe > | you might want to think about "forms_on" to be more robust. The > | earlier forms header files did not have the "on" defined.) > > What stops you from polluting the global namespace with a macro/define > called forms_on? (and using forms_on in xforms give away the wrong > meaning of the parameter... and removing it from the function > declaration makes it impossible to see what this int is) > > It is your code that is in error, not xforms. Yeah I'm going to have to agree with him on that one. There is no "on" in any of the standard C++ headers, afaik. Additionally, having a macro defined as "on" is not specific to C++... things could be messed up the same way if everything was in C. From angus.leeming at btopenworld.com Thu Sep 4 18:57:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Sep 4 12:56:58 2003 Subject: [XForms] Making XForms Multi-Threaded In-Reply-To: <5.1.1.5.2.20030904124900.01884068@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> <5.1.1.5.2.20030904124900.01884068@popserve.grc.nasa.gov> Message-ID: <200309041757.02703.angus.leeming@btopenworld.com> On Thursday 04 September 2003 4:50 pm, Holly Yeh wrote: > Hi Angus, > Thank you for your input, Is fltk supported on tru64 Unix? > > Holly Yeh. I don't know, Holly. I've never used it in anger. But it's open source, has mailing lists of its own and took about 5 mins to compile the source. I don't suppose it'd take long for you to try it out, now would it? Comes with lots of documentation and test programs too... Best regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Sep 5 16:44:29 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Sep 5 10:27:25 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: (Jean-Marc Lasgouttes's message of "Thu, 31 Jul 2003 18:36:28 +0200") References: <200307311732.59411.leeming@lyx.org> Message-ID: >>>>> "Jean-Marc" == Jean-Marc Lasgouttes writes: Angus> Fantastic effort. The logic here seems to be inverted though. Angus> Am I right? Jean-Marc> Yes, it should be #ifdef HAVE_USLEEP Jean-Marc> also, there is a problem with line 83 of signal.c, where Jean-Marc> dec cc does not like my code. I have to leave now, I'll Jean-Marc> have a look tomorrow. I finally finished this a bit and added a few things. Angus, could you commit this after review? JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: local2.diff Type: text/x-patch Size: 7382 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030905/44db0cb7/local2.bin From tc_zhao at yahoo.com Mon Sep 8 09:48:38 2003 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Mon Sep 8 11:48:46 2003 Subject: [XForms] Re: XForms: Documentation In-Reply-To: <20030902192832.F003738F37@mixing.qc.dfo.ca> Message-ID: <20030908154838.51918.qmail@web13407.mail.yahoo.com> Sorry for the delay and thanks for the info. GPL it is. I am currently travelling and will be back home end of September. Expect the free manual in October sometime. -TC --- Peter S Galbraith wrote: > To subscribers of the xforms list > > > T.C. Zhao wrote: > > > All I need to do is boot up my old linux box and recover the doc and send > it. > > Will do this sometime in April (I've been travelling, and am sending this > > email from Tokyo). > > -TC > > Hi T.C., > > I really hate to keep nagging you like this. :-) > > You meant to release the sources of the XForms manual last April but > never got around to it. This is a reminder. Also, please avoid using > the GNU Free Documentation License (GFDL) since it not a free software > license and therefore cannot be included in the Debian distribution. > Using the GPL would be fine. > > I'm writing now because while the Debian GNU/Linux distribution doesn't > make a release as often as it should, a freeze is due shortly for a > Christmas release. The current packaging of the XForms manual has this > license: > > No part of this document may be reproduced, in any form or by any > means, without permission from the authors. Permission to produce > hardcopies in its entirety for private use is granted. > > This lacks the permission to us to _distribute_ the manual so I'll pull > the package from Debian's non-free archive soon, before the upcoming > release. But instead of removing the package, it would be great to get > the manual sources under a free license and move the package to Debian's > main archive. Hopefully you will find time to do this. Otherwise I can > always re-create the Debian package at a later time when it is released > under a free license. > > Thanks for your time! > -- > Peter S. Galbraith, Debian Developer > http://people.debian.org/~psg > GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request@bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From psg at debian.org Mon Sep 8 12:57:53 2003 From: psg at debian.org (Peter S Galbraith) Date: Mon Sep 8 11:58:09 2003 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030908154838.51918.qmail@web13407.mail.yahoo.com> References: <20030908154838.51918.qmail@web13407.mail.yahoo.com> Message-ID: <20030908155753.3FB3238F7E@mixing.qc.dfo.ca> T.C. Zhao wrote: > > Sorry for the delay and thanks for the info. GPL it is. > > I am currently travelling and will be back home end of September. Expect the > free manual in October sometime. > > -TC Thanks TC! Would you also mind replying to this message (and CC the mailing list for the public record) and give permission to Debian to distribute the current version of the manual in its non-free archive and mirrors, e.g. http://packages.debian.org/unstable/doc/libforms-doc.html This would gives us the required permission not present in the current license. Thanks again! -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From angus.leeming at btopenworld.com Tue Sep 9 02:04:13 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Sep 8 20:06:01 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: Message-ID: <200309090051.14280.leeming@lyx.org> On Friday 05 September 2003 1:44 pm, Jean-Marc Lasgouttes wrote: > Angus> Fantastic effort. The logic here seems to be inverted though. > Angus> Am I right? > > Jean-Marc> Yes, it should be #ifdef HAVE_USLEEP > > Jean-Marc> also, there is a problem with line 83 of signal.c, where > Jean-Marc> dec cc does not like my code. I have to leave now, I'll > Jean-Marc> have a look tomorrow. > > I finally finished this a bit and added a few things. Angus, could you > commit this after review? > > JMarc Many thaks for doing this Jean-Marc. It is now committed. Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 12:18:41 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Sep 9 05:18:48 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309090051.14280.leeming@lyx.org> (Angus Leeming's message of "Tue, 9 Sep 2003 01:04:13 +0000") References: <200309090051.14280.leeming@lyx.org> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Many thaks for doing this Jean-Marc. It is now committed. Angus You forgot the Changelog entry. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: chglog.diff Type: text/x-patch Size: 1075 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030909/51b7308c/chglog.bin From angus.leeming at btopenworld.com Tue Sep 9 11:43:05 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Sep 9 05:42:58 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: <200309090051.14280.leeming@lyx.org> Message-ID: <200309091043.05489.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: JMarc> Angus> Many thaks for doing this Jean-Marc. It is now committed. Angus JMarc> You forgot the Changelog entry. No I didn't, but I'll admit that my subsequent commit with a date of 23 May is confusing (and wrong). I've fixed that. Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 13:16:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Sep 9 06:16:24 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309091043.05489.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 10:43:05 +0000") References: <200309090051.14280.leeming@lyx.org> <200309091043.05489.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: JMarc> Angus> Many thaks for doing this Jean-Marc. It is now JMarc> committed. Angus You forgot the Changelog entry. Angus> No I didn't, but I'll admit that my subsequent commit with a Angus> date of 23 May is confusing (and wrong). I've fixed that. You're right, it is cvs update that got confused actually. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 13:47:37 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Sep 9 06:51:42 2003 Subject: [XForms] [PATCH] Enable optional building of demos/ directory Message-ID: The following patch adds an --enable-demos flag to configure Angus, please apply if it works OK for you. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-patch Size: 2257 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030909/2173d3a5/demos.bin From angus.leeming at btopenworld.com Tue Sep 9 13:46:50 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Sep 9 07:46:44 2003 Subject: [XForms] Re: [PATCH] Enable optional building of demos/ directory In-Reply-To: References: Message-ID: <200309091246.50358.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 10:47 am, Jean-Marc Lasgouttes wrote: > The following patch adds an --enable-demos flag to configure > > Angus, please apply if it works OK for you. Oh, JMarc, you beauty! Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 15:22:32 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Sep 9 08:22:40 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309091245.11255.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 12:45:11 +0000") References: <200309091043.05489.angus.leeming@btopenworld.com> <200309091245.11255.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Let's try and make a road plan for a 1.1 release. I guess we Angus> should address the problems with the autotools that Laurence Angus> Marks described. Yes. I have not looked at that seriously yet. One thing I noticed is that we lack an INSTALL file (to be taken from autoconf). The file Copyright should maybe be included in some other file (and the reference to COPYING changed to COPYING.LIB). The copyrights should be changed to include at least you (and me) (also in lib/version.c). Angus> Here I have Red Hat 8 which comes with automake 1.6.3, autoconf Angus> 2.53 and libtool 1.4.2. We should probably pick something newer... Angus> I find that if I remove depcomp and the config.*, then Angus> automake, autoconf shove in new versions. Great. However, if I Angus> remove libtool.m4 and run libtoolize, I do do not get a new Angus> version of libtool.m4. I guess, therefore that it is no longer Angus> needed? The libtool documentation says: When you invoke the libtoolize program (see section 5.4.1 Invoking libtoolize), it will tell you where to find a definition of AC_PROG_LIBTOOL. If you use Automake, the aclocal program will automatically add AC_PROG_LIBTOOL support to your configure script. Nevertheless, it is advisable to include a copy of `libtool.m4' in `acinclude.m4', so that, even if `aclocal.m4' and `configure' are rebuilt for any reason, the appropriate libtool macros will be used. The alternative is to hope the user will have a compatible version of `libtool.m4' installed and accessible for aclocal. This may lead to weird errors when versions don't match. So we should keep a libtool.m4. Angus> Here is the patch. Wa d'ya think? Angus I'd say let's refine it a bit first. Angus> NB, reading on the web, it appears that others have added Angus> libtoolize to autogen.sh Angus> http://mail.gnome.org/archives/gtk-devel-list/2002-September/msg00015.html If you look at the autoconf repository, you will even find out that the have special makefile targets to update all these files automatically from the gnu ftp site. I am not sure whether we want to go to such extreme methods, though. JMarc From tc_zhao at yahoo.com Tue Sep 9 08:07:59 2003 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Tue Sep 9 10:08:13 2003 Subject: [XForms] Re: XForms: Documentation In-Reply-To: <20030908155753.3FB3238F7E@mixing.qc.dfo.ca> Message-ID: <20030909140759.33379.qmail@web13406.mail.yahoo.com> Hi Peter, Please feel free to include the current manual in the Debian distribution. For the public record, I am granting the rights to all linux distributors to distribute all versions of xforms manual without fee in all electronic formats (.tex,.psf, .ps, .html) with the requirement that the distributed versions retain the copyright notice and version number. -TC --- Peter S Galbraith wrote: > T.C. Zhao wrote: > > > > > Sorry for the delay and thanks for the info. GPL it is. > > > > I am currently travelling and will be back home end of September. Expect > the > > free manual in October sometime. > > > > -TC > > Thanks TC! > > Would you also mind replying to this message (and CC the mailing list > for the public record) and give permission to Debian to distribute the > current version of the manual in its non-free archive and mirrors, e.g. > > http://packages.debian.org/unstable/doc/libforms-doc.html > > This would gives us the required permission not present in the current > license. > > Thanks again! > -- > Peter S. Galbraith, Debian Developer > http://people.debian.org/~psg > GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From psg at debian.org Tue Sep 9 11:21:36 2003 From: psg at debian.org (Peter S Galbraith) Date: Tue Sep 9 10:21:47 2003 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030909140759.33379.qmail@web13406.mail.yahoo.com> References: <20030909140759.33379.qmail@web13406.mail.yahoo.com> Message-ID: <20030909142136.C3CEB39205@mixing.qc.dfo.ca> T.C. Zhao wrote: > Hi Peter, > > Please feel free to include the current manual in the Debian distribution. > > For the public record, I am granting the rights to all linux distributors to > distribute all versions of xforms manual without fee in all electronic > formats (.tex,.psf, .ps, .html) with the requirement that the distributed > versions retain the copyright notice and version number. > > -TC Many thanks T.C. ! This is exactly what I needed until the free release. :-) Peter -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 18:02:53 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Sep 9 11:03:07 2003 Subject: [XForms] [PATCH] Simplify configure.ac Message-ID: The following patch removes tests that are as far as I can see not used. I tried to check carefully what the side effects of the various autoconf macros are. The idea is to keep all tests that already exist in some form in xforms 1.0. Angus, please double check and apply (note that the ChangeLog chunk will not apply after my other patch, since this is against unpatched HEAD; I'll redo the patch if there is a problem). Something that still has to be done is implement --disable-gl to avoid building libformsGL when not relevant. It should not be too difficult to make a test to autodetect this. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: conf.diff Type: text/x-patch Size: 3945 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030909/0a0cb9c4/conf.bin From angus.leeming at btopenworld.com Tue Sep 9 18:16:10 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Sep 9 12:16:07 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: References: Message-ID: <200309091716.10189.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 3:02 pm, Jean-Marc Lasgouttes wrote: > The following patch removes tests that are as far as I can see not > used. I tried to check carefully what the side effects of the various > autoconf macros are. The idea is to keep all tests that already exist > in some form in xforms 1.0. > Angus, please double check and apply (note that the ChangeLog chunk > will not apply after my other patch, since this is against unpatched > HEAD; I'll redo the patch if there is a problem). Well, it works for me it all looks reasonable and, as I think of you as the whizz in these things anyway, that's good enough for me. I applied it. Many thanks. > Something that still has to be done is implement --disable-gl to avoid > building libformsGL when not relevant. It should not be too difficult > to make a test to autodetect this. Good idea. Actually, shouldn't that be --enable-gl (defaults to 'no'), identical to you little test for --enable-demos? Of course, it would actually do some testing if the answer were 'yes'. Angus From wd4nmq at comcast.net Tue Sep 9 15:49:22 2003 From: wd4nmq at comcast.net (Jeff Pierce) Date: Tue Sep 9 14:39:02 2003 Subject: [XForms] Windows with transparent background and no border. Message-ID: <3F5E20B2.6030502@comcast.net> Is it possible at all under X windows to have a non-rectangular window like under MS Windows? The call under MS is AddRectToRgn(). Where you have a mask that is treated like chroma mixing, ie green screen, in movies/tv. Then the portions of the underlying desktop will show through and key presses in those areas will not go to the app, but to whatever is underneath it. I know that xfornms does not support this. But, does anybody knoe of a way to do it using any other X frameworks? -- Jeff, wd4nmq wd4nmq@comcast.net http://mywebpages.comcast.net/wd4nmq From Jean-Marc.Lasgouttes at inria.fr Wed Sep 10 15:56:25 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Sep 10 08:56:32 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <200309091716.10189.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 17:16:10 +0000") References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> Something that still has to be done is implement --disable-gl to >> avoid building libformsGL when not relevant. It should not be too >> difficult to make a test to autodetect this. Angus> Good idea. Actually, shouldn't that be --enable-gl (defaults to Angus> 'no'), identical to you little test for --enable-demos? Of Angus> course, it would actually do some testing if the answer were Angus> 'yes'. See attached patch. The code only builds the gl/ subdir if GL/glx.h is found. You can add an explicit --disable-gl to avoid building. I also simplified the code for --enable-demos. BTW, what should we do about the xforms rpm? Building it with gl support would mean that applications like LyX would depend on GL support, which is stupid. An alternative would be to make separate xforms and xforms-gl rpms, but this is a bit heavy IMO. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: gl.diff Type: text/x-patch Size: 2739 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030910/58819f35/gl.bin From angus.leeming at btopenworld.com Tue Sep 9 13:45:11 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Sep 10 10:55:58 2003 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: <200309091043.05489.angus.leeming@btopenworld.com> Message-ID: <200309091245.11255.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 10:16 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > Angus> To subscribers of the xforms list > Angus> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: > JMarc> Angus> Many thaks for doing this Jean-Marc. It is now > JMarc> committed. Angus You forgot the Changelog entry. > > Angus> No I didn't, but I'll admit that my subsequent commit with a > Angus> date of 23 May is confusing (and wrong). I've fixed that. > > You're right, it is cvs update that got confused actually. Let's try and make a road plan for a 1.1 release. I guess we should address the problems with the autotools that Laurence Marks described. > The right thing to do is to upgrade libtool files to the latest > version (our libtool.m5 is from 2001, it seems). The choice is libtool > 1.4.2 from october 2002 or 1.5 from last month. I do not know whether > 1.5 can cause problems. > depcomp comes probably with automake, and the config.* from autoconf. > All we have to do is upgrade from recent versions. Here I have Red Hat 8 which comes with automake 1.6.3, autoconf 2.53 and libtool 1.4.2. I find that if I remove depcomp and the config.*, then automake, autoconf shove in new versions. Great. However, if I remove libtool.m4 and run libtoolize, I do do not get a new version of libtool.m4. I guess, therefore that it is no longer needed? Certainly, I can confirm that everything works for me. Here is the patch. Wa d'ya think? Angus NB, reading on the web, it appears that others have added libtoolize to autogen.sh http://mail.gnome.org/archives/gtk-devel-list/2002-September/msg00015.html Should we do so?-------------- next part -------------- A non-text attachment was scrubbed... Name: updatetools.diff.bz2 Type: application/x-bzip2 Size: 57977 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20030909/4721bc35/updatetools.diff.bin From angus.leeming at btopenworld.com Wed Sep 10 17:56:42 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Sep 10 11:56:43 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: <200309101656.42201.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 12:56 pm, Jean-Marc Lasgouttes wrote: > >> Something that still has to be done is implement --disable-gl to > >> avoid building libformsGL when not relevant. It should not be too > >> difficult to make a test to autodetect this. > > Angus> Good idea. Actually, shouldn't that be --enable-gl (defaults to > Angus> 'no'), identical to you little test for --enable-demos? Of > Angus> course, it would actually do some testing if the answer were > Angus> 'yes'. > > See attached patch. The code only builds the gl/ subdir if GL/glx.h is > found. You can add an explicit --disable-gl to avoid building. > > I also simplified the code for --enable-demos. Thanks for this. > BTW, what should we do about the xforms rpm? Building it with gl > support would mean that applications like LyX would depend on GL > support, which is stupid. An alternative would be to make separate > xforms and xforms-gl rpms, but this is a bit heavy IMO. Heavy or not, it is the right thing to do. In fact, being brutal about this, we should have separate rpms for each library, xforms, xforms-image and xforms-gl. Moreover, fdesign and fd2ps are developer tools. They should go, therefore, in the xforms-devel rpm. Angus From psg at debian.org Wed Sep 10 14:02:48 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed Sep 10 13:02:59 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Jean-Marc Lasgouttes References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: <20030910170249.0137A38F37@mixing.qc.dfo.ca> Jean-Marc Lasgouttes wrote: > support would mean that applications like LyX would depend on GL > support, which is stupid. An alternative would be to make separate > xforms and xforms-gl rpms, but this is a bit heavy IMO. This is what I do for Debian anyway: http://packages.debian.org/unstable/libs/libforms1.html http://packages.debian.org/unstable/libs/libformsgl1.html http://packages.debian.org/unstable/libdevel/libforms-dev.html http://packages.debian.org/unstable/devel/libformsgl-dev.html http://packages.debian.org/unstable/devel/libforms-bin.html Peter From angus.leeming at btopenworld.com Wed Sep 10 19:09:03 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Sep 10 13:08:59 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910170249.0137A38F37@mixing.qc.dfo.ca> References: <20030910170249.0137A38F37@mixing.qc.dfo.ca> Message-ID: <200309101809.03546.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:02 pm, Peter S Galbraith wrote: > To subscribers of the xforms list > > Jean-Marc Lasgouttes wrote: > > support would mean that applications like LyX would depend on GL > > support, which is stupid. An alternative would be to make separate > > xforms and xforms-gl rpms, but this is a bit heavy IMO. > > This is what I do for Debian anyway: > > http://packages.debian.org/unstable/libs/libforms1.html > http://packages.debian.org/unstable/libs/libformsgl1.html > http://packages.debian.org/unstable/libdevel/libforms-dev.html > http://packages.debian.org/unstable/devel/libformsgl-dev.html > http://packages.debian.org/unstable/devel/libforms-bin.html Any reason why you don't split up xforms and xforms-image? Is making dep packages automatically just a case of adding the correct Makefile target and leaving the computer to do its stuff? If so, feel free to submit a patch. Angus From psg at debian.org Wed Sep 10 14:25:38 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed Sep 10 13:25:45 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Angus Leeming <200309101809.03546.angus.leeming@btopenworld.com> References: <20030910170249.0137A38F37@mixing.qc.dfo.ca> <200309101809.03546.angus.leeming@btopenworld.com> Message-ID: <20030910172538.4755438F37@mixing.qc.dfo.ca> Angus Leeming wrote: > On Wednesday 10 September 2003 5:02 pm, Peter S Galbraith wrote: > > To subscribers of the xforms list > > > > Jean-Marc Lasgouttes wrote: > > > support would mean that applications like LyX would depend on GL > > > support, which is stupid. An alternative would be to make separate > > > xforms and xforms-gl rpms, but this is a bit heavy IMO. > > > > This is what I do for Debian anyway: > > > > http://packages.debian.org/unstable/libs/libforms1.html > > http://packages.debian.org/unstable/libs/libformsgl1.html > > http://packages.debian.org/unstable/libdevel/libforms-dev.html > > http://packages.debian.org/unstable/devel/libformsgl-dev.html > > http://packages.debian.org/unstable/devel/libforms-bin.html > > Any reason why you don't split up xforms and xforms-image? Only because the image library didn't cause the added depencies to be too onerous. Most users already have installed the packages for libjpeg, libtiff and libXpm. OpenGL is another story, so I bundled it separately. > Is making dep packages automatically just a case of adding the correct > Makefile target and leaving the computer to do its stuff? If so, feel > free to submit a patch. Making Debian packages involves a debian/ directory. See http://ftp.debian.org/debian/pool/main/libf/libforms1/libforms1_1.0-4.diff.gz for what I add/change from the original tar ball. It's not a huge deal for me to keep this separate and apply it after your release, and I suppose having an outdated debian directory can sometimes cause problems. I include it in CVS for projects that I'm heavily involved with (gri and MH-E) and have CVS access, and don't do it in the majority of my packages (because I don't track CVS as much as would be required). Making the actual packages also involves doing it on a Debian system, of course, since specific tools are required to calculate dependencies and certain helper packages are invoked. Peter From psg at debian.org Wed Sep 10 14:38:27 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed Sep 10 13:38:33 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Angus Leeming <200309101834.25195.angus.leeming@btopenworld.com> References: <200309101809.03546.angus.leeming@btopenworld.com> <20030910172538.4755438F37@mixing.qc.dfo.ca> <200309101834.25195.angus.leeming@btopenworld.com> Message-ID: <20030910173827.8971A38F37@mixing.qc.dfo.ca> Angus Leeming wrote: > On Wednesday 10 September 2003 5:25 pm, Peter S Galbraith wrote: > > Making Debian packages involves a debian/ directory. See > > http://ftp.debian.org/d[snip...]/libforms1_1.0-4.diff.gz > > Cool! I didn't know you'd done that! I'll have a look at some stage. You didn't know is was packaged? > > Making the actual packages also involves doing it on a Debian system, > > of course, since specific tools are required to calculate dependencies > > and certain helper packages are invoked. > > Sure. But then that is true also of rpmdist. Yeah, I added that as an afterthought. It did seem fairly obvious. I just wanted to make sure. :-) Peter From angus.leeming at btopenworld.com Wed Sep 10 19:34:25 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Sep 12 09:28:01 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910172538.4755438F37@mixing.qc.dfo.ca> References: <200309101809.03546.angus.leeming@btopenworld.com> <20030910172538.4755438F37@mixing.qc.dfo.ca> Message-ID: <200309101834.25195.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:25 pm, Peter S Galbraith wrote: > Making Debian packages involves a debian/ directory. See > http://ftp.debian.org/d[snip...]/libforms1_1.0-4.diff.gz Cool! I didn't know you'd done that! I'll have a look at some stage. > Making the actual packages also involves doing it on a Debian system, > of course, since specific tools are required to calculate dependencies > and certain helper packages are invoked. Sure. But then that is true also of rpmdist. This is from Makefile.am in the top level dir. rpmdist: dist if [ -z "`type -path rpmbuild`" ]; \ then \ RPMBUILD=rpm; \ else \ RPMBUILD=rpmbuild; \ fi; $$RPMBUILD -ta $(PACKAGE)-$(VERSION).tar.gz ; saved_status=$$?; \ exit $$saved_status Regards, Angus From angus.leeming at btopenworld.com Wed Sep 10 19:44:23 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sun Sep 14 09:18:12 2003 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910173827.8971A38F37@mixing.qc.dfo.ca> References: <200309101834.25195.angus.leeming@btopenworld.com> <20030910173827.8971A38F37@mixing.qc.dfo.ca> Message-ID: <200309101844.23539.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:38 pm, Peter S Galbraith wrote: > You didn't know is was packaged? Let's just say that my ignorance is boundless. Angus From vs85 at cornell.edu Mon Sep 15 18:11:38 2003 From: vs85 at cornell.edu (Veera) Date: Mon Sep 15 20:08:05 2003 Subject: [XForms] XForms installation Message-ID: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> Hi, I have some problems when i was trying to install xforms on cygwin(latest version 1.5.4 with XFREE86). First I unzipped the xforms.1.0.tar file. then typed xmkmf -a. This command went through well. After that when i typed 'make' the program stops and gives this error message: make[1]: *** No rule to make target `../lib/libforms.a', needed by `fd2ps.exe'. Stop. make[1]: Leaving directory `/usr/x11r6/xforms-1.0/fd2ps' make: *** [all] Error 2 I have already installed the xpm library. Is it a problem due to bad xpm installation? I tried installing the binary version bxforms.089. Again the demos don't run and it gives an fl_initialise error (unable to open). Can someone please tell me the steps for installing xforms on cygwin and making the demos work. thanks Veera From angus.leeming at btopenworld.com Tue Sep 16 10:01:13 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Sep 16 04:01:04 2003 Subject: [XForms] XForms installation In-Reply-To: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> References: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> Message-ID: <200309160901.13982.angus.leeming@btopenworld.com> On Monday 15 September 2003 9:11 pm, Veera wrote: > Hi, > > I have some problems when i was trying to install xforms on cygwin(latest > version 1.5.4 with XFREE86). First I unzipped the xforms.1.0.tar file. then > typed xmkmf -a. This command went through well. After that when i typed > 'make' the program stops and gives this error message: > > make[1]: *** No rule to make target `../lib/libforms.a', needed by > `fd2ps.exe'. Stop. > make[1]: Leaving directory `/usr/x11r6/xforms-1.0/fd2ps' > make: *** [all] Error 2 > > Can someone please tell me the steps for installing xforms on cygwin and > making the demos work. This is going to sound kludgy, but... Go into the lib subdirectory and type $ make $ make install (as root) Thereafter, fd2ps should be able to find the libforms.a/.so files fine when you return to the top level directory and type $ make Alternatively, and perhaps less kludgily, set your LD_LIBRARY_PATH variable to include the path to the generated libforms.a/.so files. Angus From ldm at risc4.numis.nwu.edu Tue Sep 23 20:21:32 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Tue Sep 23 20:21:36 2003 Subject: [XForms] Redhat 9.0 libforms.a incompatibility Message-ID: I just upgraded my system to Redhat 9.0, and it appears that there are some incompatibilties between the include file definitions (in my version anyway) and the version of libforms.a that they are shipping. (I deleted their version and just installed one I compiled, but you might want to decide how to deal with this in a general way.) ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm@risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From davidwriter at yahoo.com Wed Sep 24 15:25:50 2003 From: davidwriter at yahoo.com (David Scriven) Date: Wed Sep 24 14:25:55 2003 Subject: [XForms] Redhat 9.0 libforms.a incompatibility In-Reply-To: Message-ID: <20030924182550.70945.qmail@web41214.mail.yahoo.com> As far as I know Red Hat has not shipped xforms since version 7.2. The problems that you were having with the (presumably old) libforms.a are not unique to xforms. Static linking was changed in RH 9 and most old archives had to be recompiled otherwise you get errors. You can check the archive of this list to see what the errors were. DS --- "L. D. Marks" wrote: > To subscribers of the xforms list > > > I just upgraded my system to Redhat 9.0, and it appears > that there are some incompatibilties between the include > file definitions (in my version anyway) and the version > of libforms.a that they are shipping. (I deleted their > version and just installed one I compiled, but you might > want to decide how to deal with this in a general > way.) > > ----------------------------------------------- > Laurence Marks > Department of Materials Science and Engineering > MSE Rm 2036 Cook Hall > 2225 N Campus Drive > Northwestern University > Evanston, IL 60201, USA > Tel: (847) 491-3996 Fax: (847) 491-7820 > mailto:ldm@risc4.numis.nwu.edu > http://www.numis.nwu.edu > ----------------------------------------------- > > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request@bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From dstrang at chartermi.net Fri Oct 3 05:07:50 2003 From: dstrang at chartermi.net (David Strang) Date: Fri Oct 3 04:08:58 2003 Subject: [XForms] Hello - Just a test. Message-ID: <000901c38985$7055e940$6401a8c0@athlon> Hello. Regards, Dave Strang From angus.leeming at btopenworld.com Fri Oct 3 10:45:54 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Oct 3 04:45:36 2003 Subject: [XForms] Hello - Just a test. In-Reply-To: <000901c38985$7055e940$6401a8c0@athlon> References: <000901c38985$7055e940$6401a8c0@athlon> Message-ID: <200310030945.54699.angus.leeming@btopenworld.com> On Friday 03 October 2003 8:07 am, David Strang wrote: > Hello. Hello, David. Quiet here, isn't it? Angus From ddembrow at nlxcorp.com Fri Oct 3 06:40:59 2003 From: ddembrow at nlxcorp.com (ddembrow@nlxcorp.com) Date: Fri Oct 3 05:39:20 2003 Subject: [XForms] xforms patch Message-ID: I have attached diff patch files for fselect.c and tabfolder.c source. Could a developer look at what is changed, and add it to the development Xforms source? The fselect_patch allows for a borderless form. This allows the use of the file selector goodie in an application which uses nothing but fixed size/borderless forms. The tabfolder_patch corrects the form position when using bottom tab folders. Without the patch the form selected with a bottom tab is place below the tab - for a full screen display the form simply disappears out of the viewing area. Thanks, ---d.dembrow NLX Corporation Phone: (703) 234-2100 FAX: (703) 234-2101 email: ddembrow@nlxcorp.com (See attached file: fselect_patch)(See attached file: tabfolder_patch) -------------- next part -------------- A non-text attachment was scrubbed... Name: fselect_patch Type: application/octet-stream Size: 390 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031003/ad06a891/fselect_patch.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: tabfolder_patch Type: application/octet-stream Size: 997 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031003/ad06a891/tabfolder_patch.obj From angus.leeming at btopenworld.com Fri Oct 3 12:08:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Oct 3 06:08:10 2003 Subject: [XForms] xforms patch In-Reply-To: References: Message-ID: <200310031108.26360.angus.leeming@btopenworld.com> On Friday 03 October 2003 9:40 am, ddembrow@nlxcorp.com wrote: > I have attached diff patch files for fselect.c and tabfolder.c source. > Could a developer look at what is changed, and add it to the > development Xforms source? Many thanks for this. > The fselect_patch allows for a borderless form. This allows the > use of the file selector goodie in an application which uses nothing > but fixed size/borderless forms. The restriction does seem entirely arbitrary. I'll apply this one happily. > The tabfolder_patch corrects the form position when usingbottom > tab folders. Without the patch the form selected with a bottom tab > is place below the tab - for a full screen display the form simply > disappears out of the viewing area. Excellent. I'll apply this too. Incidentally, what's your name? Adding this to the ChangeLog seems a little impersonal ;-) 2003-10-03 * lib/fselect.c: remove the arbitrary restriction on the display of borderless forms. * lib/tabfolder.c: display the tab forms correctly when using bottom tab folders. From dstrang at chartermi.net Fri Oct 3 15:32:11 2003 From: dstrang at chartermi.net (David Strang) Date: Fri Oct 3 14:33:20 2003 Subject: [XForms] Looking for advice Message-ID: <001101c389dc$a8fa6b20$6401a8c0@athlon> I have been a original Forms user for about ten years with an SGI. The Xforms libraries seem to be the logical extension for Xwindows. Though I am not new to Linux, getting Xforms to build under Linux has been troublesome for me and obtaining proper information even more so. Could I get some advice on what version of Linux (Redhat x.x/Mandrake x.x/etc.) best supports what version of Xforms. I tried Redhat 9.0 and got all kind of errors due to the new gcc compiler (3.2) and Mandrake 9.0 supplied the base libraries which I installed but couldn't get the source tools built. How do I get a fully working Xforms environment ? Regards, Dave Strang dstrang@chartermi.net From GalbraithP at dfo-mpo.gc.ca Fri Oct 3 15:40:06 2003 From: GalbraithP at dfo-mpo.gc.ca (Peter S Galbraith) Date: Fri Oct 3 14:40:11 2003 Subject: [XForms] Looking for advice In-Reply-To: Message from "David Strang" <001101c389dc$a8fa6b20$6401a8c0@athlon> References: <001101c389dc$a8fa6b20$6401a8c0@athlon> Message-ID: <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> David Strang wrote: > Though I am not new to Linux, getting Xforms to build under Linux has > been troublesome for me and obtaining proper information even more so. > > Could I get some advice on what version of Linux (Redhat x.x/Mandrake > x.x/etc.) best supports > what version of Xforms. I tried Redhat 9.0 and got all kind of errors due to > the new gcc compiler (3.2) > and Mandrake 9.0 supplied the base libraries which I installed but couldn't > get the source tools built. > > How do I get a fully working Xforms environment ? It's packaged under Debian if that helps. You could install Debian via Knoppix and then install XForms from Debian. Peter From angus.leeming at btopenworld.com Sat Oct 4 18:20:39 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat Oct 4 12:20:19 2003 Subject: [XForms] Looking for advice In-Reply-To: <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> References: <001101c389dc$a8fa6b20$6401a8c0@athlon> <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> Message-ID: <200310041720.39284.angus.leeming@btopenworld.com> On Friday 03 October 2003 6:40 pm, Peter S Galbraith wrote: > > How do I get a fully working Xforms environment ? > > It's packaged under Debian if that helps. You could install Debian via > Knoppix and then install XForms from Debian. There are also rpms available at ftp://ftp.lyx.org/pub/lyx/contrib/libforms-devel-1.0-release.i386.rpm ftp://ftp.lyx.org/pub/lyx/contrib/libforms-1.0-release.i386.rpm Angus From hiller at mpia-hd.mpg.de Fri Oct 10 16:41:41 2003 From: hiller at mpia-hd.mpg.de (Ulrich Hiller) Date: Fri Oct 10 09:41:46 2003 Subject: [XForms] problems installing on solaris Message-ID: <200310101341.h9ADffR02830@mpisrv.mpia-hd.mpg.de> Hello, we want to install xforms 1.0 on sun sloaris 7 and solaris 9. It fails during the make procedure with the following error message: rm -f libflimage.so.1.0~ LD_RUN_PATH=/systools/misc/xforms/lib /usr/ccs/bin/ld -o libflimage.so.1.0~ -G - z text -M mapfile -h libflimage.so.1.0 image.o image_bmp.o image_combine.o im age_convolve.o image_crop.o image_disp.o image_fits.o image_genesis.o image _gif.o image_gzip.o image_io_filter.o image_jpeg.o image_jquant.o image_mar ker.o image_png.o image_pnm.o image_postscript.o image_proc.o image_replace .o image_rotate.o image_scale.o image_sgi.o image_text.o image_tiff.o imag e_type.o image_warp.o image_xbm.o image_xpm.o image_xwd.o postscript.o ps_ core.o ps_draw.o ps_text.o rgb_db.o matrix.o -L/systools/misc/xforms/lib -l Xext -lX11 -L/usr/local/lib -L../lib -lforms -L/systools/lib -ljpeg -L/systo ols/lib -ltiff Text relocation remains referenced against symbol offset in file 0x28 image_png.o 0x30 image_png.o 0x34 image_png.o 0x38 image_png.o 0x4 image.o [........here are many lines of the same kind..............] jpeg_destroy_compress 0x2b8 image_jpeg.o jpeg_CreateCompress 0x88 image_jpeg.o jpeg_stdio_dest 0x98 image_jpeg.o jpeg_set_defaults 0xf0 image_jpeg.o jpeg_set_quality 0x108 image_jpeg.o jpeg_write_marker 0x140 image_jpeg.o jpeg_write_scanlines 0x284 image_jpeg.o jpeg_finish_compress 0x2a0 image_jpeg.o ld: fatal: relocations remain against allocatable but non-writable sections *** Error code 1 make: Fatal error: Command failed for target `libflimage.so.1.0' Current working directory /disk-b/hiller/xforms-1.0/image making all in ./fdesign... rm -f fdesign LD_RUN_PATH=/systools/misc/xforms/lib cc -o fdesign -g -Xc -xF -xcg92 -L/sys tools/misc/xforms/lib fd_attribs.o fd_control.o fd_fake.o fd_file.o fd_forms .o fd_groups.o fd_help.o fd_initforms.o fd_main.o fd_names.o fd_objects.o fd_pallette.o fd_printC.o fd_rubber.o fd_select.o fd_spec.o fd_super.o fd _util.o sp_browser.o sp_button.o sp_choice.o sp_counter.o sp_dial.o sp_fre eobj.o sp_menu.o sp_pixmap.o sp_positioner.o sp_scrollbar.o sp_slider.o sp _twheel.o sp_xyplot.o -lXext -lX11 -static -L../lib -lforms -L/systools/lib -lXpm -dynamic -lm cc: Warning: illegal option -dynamic cc: -a conflicts with -dy. *** Error code 1 make: Fatal error: Command failed for target `fdesign' Current working directory /disk-b/hiller/xforms-1.0/fdesign making all in ./fd2ps... rm -f fd2ps LD_RUN_PATH=/usr/openwin/lib cc -o fd2ps -g -Xc -xF -xcg92 -L/usr/openwin/li b align.o fd2ps.o flsupport.o image2ps.o load.o papers.o pscol.o psdraw.o psobj.o pstext.o readxpm.o sys.o version.o xbmtops.o xpmtops.o -lXext -lX11 -Bstatic -L../image -lflimage -L../lib -lforms -Bdynamic -lm ild: (argument error) can't find library argument :: -lflimage *** Error code 8 make: Fatal error: Command failed for target `fd2ps' Current working directory /disk-b/hiller/xforms-1.0/fd2ps gmake: *** [all] Error 1 I think the main error is the relocation error (which is propably the reason why libflimage.so is not created). Thnaks in advance for your help. Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg Germany phone +49 6221 528238 fax +49 6221 528246 email hiller@mpia.de PS: For your information: Imakefile looks like this: /* Configuration -- see 00README for details */ /* Fairly important stuff */ #define OptimizationLevel -O4 #define DoWall NO #define BuildShared YES #define StaticLink YES #define BuildGL NO /* Less Important or System Specific */ #define HaveStrerror YES #define HaveSnprintf YES #define HaveFloatH YES #define DoOptimize YES #define BuildDemos NO #define DebugSymbols YES /* * You should only define this if you're running a 64 bit compile * environment on Solaris. */ #define Solaris64Bit NO /* Out in the Tall Weeds */ #define InstallNonstandard YES #define XFormsNonstandardInstallDir /systools/misc/xforms #define NonstandardXpm YES #define XpmIncLoc /systools/include #define XpmLibLoc /systools/lib #define NonstandardTiff YES #define TiffIncLoc /systools/include #define TiffLibLoc /systools/lib #define NonstandardJpeg YES #define JpegIncLoc /systools/include #define JpegLibLoc /systools/lib [the rest was not changed] From sian at sleitch.nildram.co.uk Sun Nov 2 18:09:17 2003 From: sian at sleitch.nildram.co.uk (Sian Leitch) Date: Sun Nov 2 13:29:17 2003 Subject: [XForms] Re: XForms: Future xforms development In-Reply-To: <20021210183511.61780.qmail@web41210.mail.yahoo.com> References: <200212101700.gBAH0SF04956@ncmir.ucsd.edu> <20021210183511.61780.qmail@web41210.mail.yahoo.com> Message-ID: <20031102180917.GD1248@sleitch.nildram.co.uk> On Tue, Dec 10, 2002 at 01:35:11PM -0500, David Scriven wrote: > # To subscribers of the xforms list from David Scriven : > > I suspect that the reason that Angus is not > getting any feedback is that there are very few > of us actively developing under XForms, so you > are not getting the 'critical mass' that drives > development. > > There are all sorts of reasons for this - for > example Red Hat dropped XForms from its > PowerTools because it was not open source (is > there some way to encourage them to add it to > their distro now that it is Open Source?) Also > 0.89 was quite buggy, and its > functionality/reliability varied from platform to > platform and that turned a lot of people off. > > Secondly, if I knew nothing about XForms and > wanted to get started I would probably end up on > the XForms home page, which is horribly out of > date, has broken links and links to 0.89, but > none to version 1. > > My point is that if we want XForms to survive we > have to attract users. We have to make it easy to > for new users to get the software and the > documentation so that they can be up and running > quickly. Well, here is one lurker who is actively developing using Xforms. I am currently designing the Home Finance Program (`hfp') and look forward to using `fdesign' once the filter for Algol 68 is completed (`fdtow68'). Meanwhile, I have written some test progs for various ideas. Regards -- Sian Leitch Software Engineer specialising in Algol 68 Algol 68 for Linux is available from and -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031102/a9c09f7f/attachment.bin From drriddle at qwest.net Wed Nov 5 21:41:54 2003 From: drriddle at qwest.net (Reed Riddle) Date: Wed Nov 5 22:41:58 2003 Subject: [XForms] Problem compiling with Mac OS X Message-ID: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Howdy folks, I'm trying to compile the library under OS X, and I keep running into the following errors when I run the configure script: ** Cannot find xpm.h. Please check that the Xpm library is correctly installed on your system. ** Cannot find libjpeg. Please check that the jpeg library is correctly installed on your system. I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in /sw/lib). I know that the X libraries aren't being seen at all when I compile, as all kinds of errors come up related to X. I also know how to set Linux so that it will find where you have libraries (using ldconfig), but I can't find any information like that for OS X. And, I can't figure out what to change in the configuration files to force it to see the library directories. No, I'm not frustrated... :) Anything that can point me in the right direction to get this to work will be greatly appreciated. Thanks! Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle@qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From Todd.Denniston at ssa.crane.navy.mil Thu Nov 6 09:00:19 2003 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu Nov 6 09:00:58 2003 Subject: [XForms] Problem compiling with Mac OS X References: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Message-ID: <3FAA53F3.CBE9476A@ssa.crane.navy.mil> Reed Riddle wrote: > > To subscribers of the xforms list > > Howdy folks, > > I'm trying to compile the library under OS X, and I keep running into > the following errors when I run the configure script: > > ** Cannot find xpm.h. Please check that the Xpm library > is correctly installed on your system. > > ** Cannot find libjpeg. Please check that the jpeg library > is correctly installed on your system. > > I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in /sw/lib). > I know that the X libraries aren't being seen at all when I compile, > as all kinds of errors come up related to X. I also know how to set > Linux so that it will find where you have libraries (using ldconfig), > but I can't find any information like that for OS X. And, I can't > figure out what to change in the configuration files to force it to see > the library directories. > > No, I'm not frustrated... :) Anything that can point me in the right > direction to get this to work will be greatly appreciated. Thanks! > > Reed > Sometimes configure will actually use the 'with-extra...' options --with-extra-lib specify extra library directory --with-extra-inc specify extra include directory though my results with them have been sporadic in other library compiles (LessTif), BTW please report on whether they work for you with xforms, if they don't perhaps someone can fix them. if that does not work try exporting `LIBS=-L/sw/lib` & `INCLUDES=-I/usr/X11R6/lib/X11/` and redo the configure/make After compilation you may have to define `export LD_LIBRARY_PATH=/sw/lib` before running the app, until you can figure out what OS X/BSD's options are for setting default library directories. (Sorry, I have not messed with BSD yet) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From Jean-Marc.Lasgouttes at inria.fr Thu Nov 6 15:13:24 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 6 09:13:45 2003 Subject: [XForms] Problem compiling with Mac OS X In-Reply-To: <3FAA53F3.CBE9476A@ssa.crane.navy.mil> (Todd Denniston's message of "Thu, 06 Nov 2003 09:00:19 -0500") References: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> <3FAA53F3.CBE9476A@ssa.crane.navy.mil> Message-ID: >>>>> "Todd" == Todd Denniston writes: >> I know that the X libraries aren't being seen at all when >> I compile, as all kinds of errors come up related to X. Is xmkmf in you PATH? JMarc From dstrang at chartermi.net Mon Nov 10 02:40:51 2003 From: dstrang at chartermi.net (David Strang) Date: Mon Nov 10 02:39:57 2003 Subject: [XForms] Mesa/GL demos Message-ID: <000701c3a75d$f84822a0$6401a8c0@athlon24> Hi: I installed the 1.0 version of the Forms library and everything compiled fine with the replacement of the Imakefile (thanks). What do I need to do to get the Mesa/GL demos (gl, glwin) compiled? I'm running Mandrake 9.1 and it looks like I have the shared Mesa 5.0-3 libraries. The 01README mentions using the gl.c from the demos directory (../FORMS/gl.c ??) and recompiling the libform.* . Also, link libGL.a to libMesaGL.a . I couldn't find a libMesaGL.a . Seems I need a little housekeeping here to resolve the Mesa/GL references in gl.c . Help is appreciated. Regards, Dave Strang From nicolas.castagne at imag.fr Mon Nov 10 10:56:35 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Mon Nov 10 04:53:49 2003 Subject: [XForms] Problem compiling with Mac OS X In-Reply-To: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Message-ID: <2BADD5B7-1364-11D8-BEAF-000393C76CA6@imag.fr> Hi all, Here is the report of the uses I made of XForms on Mac-OS-X last week. I also encountered a few problems with compiling the library. After a few trial, I would encourage MacOS X developpers to use the software tool FINK which is available at http://fink.sourceforge.net/ Fink takes into account the specificities of Mac OS X, which is finally not so much a standard linux (sic), to maintain your environment for software development. Especially, Fink is able to 1) scan your Mac OS X system and show which libraries are installed ; 2) download, compile and instal open source libraries ; especially, it will download any library needed to compile a specific package, if it is not yet installed ; 3) keep up to date your packages, since the download locations of almost every library is known by the software. For example, Fink was able to 1) download 2) compile 3) install automatically the XForms library and ALL the necessary packages, including XPM and OpenGL and 4) recompile all my XForms-Based software in 4 hours... Much better than getting crazy with the syntax of Makefiles, is not it? ;-) All the best, Nicolas Le jeudi, 6 nov 2003, ? 04:41 Europe/Paris, Reed Riddle a ?crit : > To subscribers of the xforms list > > > Howdy folks, > > I'm trying to compile the library under OS X, and I keep running into > the following errors when I run the configure script: > > ** Cannot find xpm.h. Please check that the Xpm library > is correctly installed on your system. > > ** Cannot find libjpeg. Please check that the jpeg library > is correctly installed on your system. > > I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in > /sw/lib). I know that the X libraries aren't being seen at all when I > compile, as all kinds of errors come up related to X. I also know how > to set Linux so that it will find where you have libraries (using > ldconfig), but I can't find any information like that for OS X. And, > I can't figure out what to change in the configuration files to force > it to see the library directories. > > No, I'm not frustrated... :) Anything that can point me in the right > direction to get this to work will be greatly appreciated. Thanks! > > Reed > > ---------------------------------------------------------------------- > Dr. Reed L. Riddle > Associate Director of Whole Earth Telescope Operations > Iowa State University Department of Physics & Astronomy > Email: drriddle@qwest.net > Homepage: http://www3.iitap.iastate.edu/~riddle/ > > "This life has been a test. If it had been an actual life, you would > have received actual instructions on where to go and what to do." > -- Angela Chase, "My so-called life" > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request@bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > > ------------------------------------------------------------------------ -------------------------- Dr Nicolas CASTAGNE Researcher, IR de l'ACROE / ICA, Association pour la Cr?ation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Cr?ation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------ -------------------------- From Jean-Marc.Lasgouttes at inria.fr Tue Nov 18 16:30:28 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Nov 18 15:38:48 2003 Subject: [XForms] [PATCH] update the autotools files. Message-ID: Here is a small patch updating the config/ files to what I found on rh9, namely: ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36) autoconf (GNU Autoconf) 2.57 automake (GNU automake) 1.6.3 The update was done more or less by hand. It still seems to work... I also append an INSTALL file taken from autoconf. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: config.diff.gz Type: application/octet-stream Size: 52923 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031118/13162586/config.diff.obj -------------- next part -------------- Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002 Free Software Foundation, Inc. This file is free documentation; the Free Software Foundation gives unlimited permission to copy, distribute and modify it. Basic Installation ================== These are generic installation instructions. The `configure' shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a `Makefile' in each directory of the package. It may also create one or more `.h' files containing system-dependent definitions. Finally, it creates a shell script `config.status' that you can run in the future to recreate the current configuration, and a file `config.log' containing compiler output (useful mainly for debugging `configure'). It can also use an optional file (typically called `config.cache' and enabled with `--cache-file=config.cache' or simply `-C') that saves the results of its tests to speed up reconfiguring. (Caching is disabled by default to prevent problems with accidental use of stale cache files.) If you need to do unusual things to compile the package, please try to figure out how `configure' could check whether to do them, and mail diffs or instructions to the address given in the `README' so they can be considered for the next release. If you are using the cache, and at some point `config.cache' contains results you don't want to keep, you may remove or edit it. The file `configure.ac' (or `configure.in') is used to create `configure' by a program called `autoconf'. You only need `configure.ac' if you want to change it or regenerate `configure' using a newer version of `autoconf'. The simplest way to compile this package is: 1. `cd' to the directory containing the package's source code and type `./configure' to configure the package for your system. If you're using `csh' on an old version of System V, you might need to type `sh ./configure' instead to prevent `csh' from trying to execute `configure' itself. Running `configure' takes awhile. While running, it prints some messages telling which features it is checking for. 2. Type `make' to compile the package. 3. Optionally, type `make check' to run any self-tests that come with the package. 4. Type `make install' to install the programs and any data files and documentation. 5. You can remove the program binaries and object files from the source code directory by typing `make clean'. To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'. There is also a `make maintainer-clean' target, but that is intended mainly for the package's developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution. Compilers and Options ===================== Some systems require unusual options for compilation or linking that the `configure' script does not know about. Run `./configure --help' for details on some of the pertinent environment variables. You can give `configure' initial values for configuration parameters by setting variables in the command line or in the environment. Here is an example: ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix *Note Defining Variables::, for more details. Compiling For Multiple Architectures ==================================== You can compile the package for more than one kind of computer at the same time, by placing the object files for each architecture in their own directory. To do this, you must use a version of `make' that supports the `VPATH' variable, such as GNU `make'. `cd' to the directory where you want the object files and executables to go and run the `configure' script. `configure' automatically checks for the source code in the directory that `configure' is in and in `..'. If you have to use a `make' that does not support the `VPATH' variable, you have to compile the package for one architecture at a time in the source code directory. After you have installed the package for one architecture, use `make distclean' before reconfiguring for another architecture. Installation Names ================== By default, `make install' will install the package's files in `/usr/local/bin', `/usr/local/man', etc. You can specify an installation prefix other than `/usr/local' by giving `configure' the option `--prefix=PATH'. You can specify separate installation prefixes for architecture-specific files and architecture-independent files. If you give `configure' the option `--exec-prefix=PATH', the package will use PATH as the prefix for installing programs and libraries. Documentation and other data files will still use the regular prefix. In addition, if you use an unusual directory layout you can give options like `--bindir=PATH' to specify different values for particular kinds of files. Run `configure --help' for a list of the directories you can set and what kinds of files go in them. If the package supports it, you can cause programs to be installed with an extra prefix or suffix on their names by giving `configure' the option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'. Optional Features ================= Some packages pay attention to `--enable-FEATURE' options to `configure', where FEATURE indicates an optional part of the package. They may also pay attention to `--with-PACKAGE' options, where PACKAGE is something like `gnu-as' or `x' (for the X Window System). The `README' should mention any `--enable-' and `--with-' options that the package recognizes. For packages that use the X Window System, `configure' can usually find the X include and library files automatically, but if it doesn't, you can use the `configure' options `--x-includes=DIR' and `--x-libraries=DIR' to specify their locations. Specifying the System Type ========================== There may be some features `configure' cannot figure out automatically, but needs to determine by the type of machine the package will run on. Usually, assuming the package is built to be run on the _same_ architectures, `configure' can figure that out, but if it prints a message saying it cannot guess the machine type, give it the `--build=TYPE' option. TYPE can either be a short name for the system type, such as `sun4', or a canonical name which has the form: CPU-COMPANY-SYSTEM where SYSTEM can have one of these forms: OS KERNEL-OS See the file `config.sub' for the possible values of each field. If `config.sub' isn't included in this package, then this package doesn't need to know the machine type. If you are _building_ compiler tools for cross-compiling, you should use the `--target=TYPE' option to select the type of system they will produce code for. If you want to _use_ a cross compiler, that generates code for a platform different from the build platform, you should specify the "host" platform (i.e., that on which the generated programs will eventually be run) with `--host=TYPE'. Sharing Defaults ================ If you want to set default values for `configure' scripts to share, you can create a site shell script called `config.site' that gives default values for variables like `CC', `cache_file', and `prefix'. `configure' looks for `PREFIX/share/config.site' if it exists, then `PREFIX/etc/config.site' if it exists. Or, you can set the `CONFIG_SITE' environment variable to the location of the site script. A warning: not all `configure' scripts look for a site script. Defining Variables ================== Variables not defined in a site shell script can be set in the environment passed to `configure'. However, some packages may run configure again during the build, and the customized values of these variables may be lost. In order to avoid this problem, you should set them in the `configure' command line, using `VAR=value'. For example: ./configure CC=/usr/local2/bin/gcc will cause the specified gcc to be used as the C compiler (unless it is overridden in the site shell script). `configure' Invocation ====================== `configure' recognizes the following options to control how it operates. `--help' `-h' Print a summary of the options to `configure', and exit. `--version' `-V' Print the version of Autoconf used to generate the `configure' script, and exit. `--cache-file=FILE' Enable the cache: use and save the results of the tests in FILE, traditionally `config.cache'. FILE defaults to `/dev/null' to disable caching. `--config-cache' `-C' Alias for `--cache-file=config.cache'. `--quiet' `--silent' `-q' Do not print messages saying which checks are being made. To suppress all normal output, redirect it to `/dev/null' (any error messages will still be shown). `--srcdir=DIR' Look for the package's source code in directory DIR. Usually `configure' can determine that directory automatically. `configure' also accepts some other, not widely useful, options. Run `configure --help' for more details. From angus.leeming at btopenworld.com Tue Nov 18 22:43:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Nov 18 17:43:08 2003 Subject: [XForms] [PATCH] update the autotools files. In-Reply-To: References: Message-ID: <200311182243.24688.angus.leeming@btopenworld.com> On Tuesday 18 November 2003 3:30 pm, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > Here is a small patch updating the config/ files to what I found on > rh9 Thanks JMarc. They're in... Angus From msz at astrouw.edu.pl Wed Nov 19 11:56:06 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed Nov 19 05:56:16 2003 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: <200305301057.43750.angus.leeming@btopenworld.com> Message-ID: <20031119105606.GA1903@astrouw.edu.pl> Hi XFormers, I'd like to know what the current status of "file selector double-click" bug is? There were a couple of messages regarding this in May, starting with a patch proposed by Mike Heffner, but the discussion that followed raised some doubts. It ended with following message from Mike: > However, we still have the same problem that the callback is never getting > a ButtonPress event. ;-( > > This weekend I'll try rewriting the file selector's callback using the > fl_set_browser_dblclick_callback(). It seems that might be a much easier > way of approaching this. Mike, did you try the rewrite? If no, is Mike's patch included in any (CVS maybe) version of code? I have some heavily-used XForms apps dating back to ver. 0.88 and I'd like very much to rebuild them with 1.0 (also because of problems with static libraries under RedHat 9) but all users here are quite used to double-clicking in file selector. The problems started already in 0.89 and, sadly, have propagated into 1.0. regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 12:11:46 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Nov 19 06:11:50 2003 Subject: [XForms] Mesa/GL demos In-Reply-To: <000701c3a75d$f84822a0$6401a8c0@athlon24> (David Strang's message of "Mon, 10 Nov 2003 02:40:51 -0500") References: <000701c3a75d$f84822a0$6401a8c0@athlon24> Message-ID: >>>>> "David" == David Strang writes: David> To subscribers of the xforms list Hi: David> I installed the 1.0 version of the Forms library and everything David> compiled fine with the replacement of the Imakefile (thanks). David> What do I need to do to get the Mesa/GL demos (gl, glwin) David> compiled? David> I'm running Mandrake 9.1 and it looks like I have the shared David> Mesa 5.0-3 libraries. David> The 01README mentions using the gl.c from the demos directory David> (../FORMS/gl.c ??) and recompiling the libform.* . Also, link David> libGL.a to libMesaGL.a . David> I couldn't find a libMesaGL.a . The .a library should be in the Mesa-devel package (or whatever it's called). You can probably link to libMesaGL.so with a -lMesaGL directive. David> Seems I need a little housekeeping here to resolve the Mesa/GL David> references in gl.c . What would be insteresting is to know whether it works better in xforms cvs where we have switched to autoconf. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 12:45:03 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Nov 19 06:45:09 2003 Subject: [XForms] Re: XForms: Towards xforms 1.1 In-Reply-To: <200305212241.04744.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 21 May 2003 22:41:04 +0000") References: <200305212241.04744.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: [OK, this was 6 months ago, but I am cleaning my mailbox...] Angus> I think that NT lib/OS2 os2move.cmd gl/canvas.h are all Angus> redundant (the latter is almost identical to glcanvas.h and Angus> appears to be a historical anachronism. It has certainly never Angus> been installed). Angus> Would anybody object if I removed them? Please remove them. Also, I think lib/Readme should be removed (check first...). Do gl demos still work? (I do not have gl stuff installed here to check...). Also, could you update the NEWS file? We will probably need at least a prerelease of 1.1. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 12:49:23 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Nov 19 06:49:28 2003 Subject: [XForms] [PATCH] Various stuff Message-ID: This patch updates README somewhat, makes ure that the X11 include path is used to search for xpm.h (should I do the same for jpeg and/or gl?), and fixes small things. Please apply. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: stuff.diff Type: text/x-patch Size: 6171 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031119/ac02f299/stuff.bin From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 15:38:51 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Nov 19 09:39:00 2003 Subject: [XForms] [PATCH] Various stuff In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 19 Nov 2003 12:49:23 +0100") References: Message-ID: >>>>> "Jean-Marc" == Jean-Marc Lasgouttes writes: Jean-Marc> To subscribers of the xforms list This patch updates README Jean-Marc> somewhat, makes ure that the X11 include path is used to Jean-Marc> search for xpm.h (should I do the same for jpeg and/or Jean-Marc> gl?), and fixes small things. Jean-Marc> Please apply. Well, I decided to have a look whether I could use my write access on cvs. Guess what? It just worked ! JMarc From angus.leeming at btopenworld.com Wed Nov 19 21:58:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Nov 19 16:57:45 2003 Subject: [XForms] [PATCH] Various stuff In-Reply-To: References: Message-ID: <200311192158.02931.angus.leeming@btopenworld.com> On Wednesday 19 November 2003 2:38 pm, Jean-Marc Lasgouttes wrote: > Jean-Marc> This patch updates README somewhat, > Jean-Marc> makes ure that the X11 include path is used to > Jean-Marc> search for xpm.h (should I do the same for jpeg > Jean-Marc> and/or gl?), and fixes small things. > > Jean-Marc> Please apply. > > Well, I decided to have a look whether I could use my write access on > cvs. Guess what? It just worked ! So starts the slippery slope towards responsibility ;-) Many thanks for doing this. Angus From angus.leeming at btopenworld.com Wed Nov 19 22:49:16 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Nov 19 17:49:02 2003 Subject: [XForms] Re: XForms: Towards xforms 1.1 In-Reply-To: References: <200305212241.04744.angus.leeming@btopenworld.com> Message-ID: <200311192249.16531.angus.leeming@btopenworld.com> On Wednesday 19 November 2003 11:45 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > [OK, this was 6 months ago, but I am cleaning my mailbox...] > > Angus> I think that NT lib/OS2 os2move.cmd gl/canvas.h are all > Angus> redundant (the latter is almost identical to glcanvas.h and > Angus> appears to be a historical anachronism. It has certainly never > Angus> been installed). > > Angus> Would anybody object if I removed them? > > Please remove them. Done. Is README.OS2 now redundant too? > Also, I think lib/Readme should be removed (check first...). Checked and then removed. > Do gl demos still work? (I do not have gl stuff installed > here to check...). > > Also, could you update the NEWS file? Hmmm. Yes. This will take some effort but I'll put it on my todo list. > We will probably need at least a prerelease of 1.1. Definitely. Angus From angus.leeming at btopenworld.com Wed Nov 19 23:06:17 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Nov 19 18:05:58 2003 Subject: [XForms] Towards a warning-free compilation. Message-ID: <200311192306.17228.angus.leeming@btopenworld.com> I have been trying to reduce the number of warnings when compiling xforms with CFLAGS='-O2 -W -Wall -Wno-unused-parameter -pedantic' That's about as strict as C will allow. There are currently two main groups of warning messages: 'uninitialized variable' (almost all in the declaration of arrays) and 'comparison between signed and unsigned'. Attached is a tentative patch that removes all of the 'uninitialized variable' warnings. I say tentative because xforms tends to use macros such as #define NV(a) (#a,a) to simplify such initializations. Eg: #define NV(a) #a,a static FL_IMAP fl_imap[FL_MAX_COLS] = { {NV(FL_BLACK), 0, 0, 0, 0, 0}, {NV(FL_WHITE), 255, 255, 255, 0, 0}, I have squashed the warnings in the case above by adding the final ', 0, 0' to the decalrations, but I could arguably achieve the same end by extending the definition of the NV macro to: #define NV(a,r,g,b) ({#a,a,r,g,b,0,0}) static FL_IMAP fl_imap[FL_MAX_COLS] = { NV(FL_BLACK, 0, 0, 0), NV(FL_WHITE, 255, 255, 255), Given that NV exists already, would it not be more elegant to do things the second way? I also attach the log of the remaining_warnings and a little sed script that I used to strip most everything but the warnings out from the make log file. $ make > make.log 2>&1 $ sed -f striplog.sed make.log > remaining_warnings.txt You'll see that there are also a couple of warnings about inconsistent declarations in there too... Regards, Angus -------------- next part -------------- /^depfile/d /^depmode/d /^gcc/d /^source/d /^\/bin\/sh/d /^make\[[123]\]/d /^Making all/d /^cp -p/d /^creating/d /^(cd/d /^rm -f/d /^mv -f/d /^ar cru/d /^mkdir/d /^echo timestamp/d /^config.status/d /^cd/d /^make/d -------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦z·¦j)âž ®x§‚Ëq¶ ÓÊ—š¦™bq«b¢ñƒ8©J,Þמ{o+^°7¬rz-jö¢•¦åyJå†Ûiÿöènë.†É¢—úb¥êæj)Åú+šÏÚ¶Öœ†g§¶ÏöÓMõ×_ï¯\wÍÛþ·¦j)âž ®x§‚Ëqµ¸§-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦z)â¶&¥‹6­Š‰Ý‰÷àÍ<©yªi–'¶*'ÿ3Š”¢ÍîõófòµëzÇ'¢Ö¯j)ZnW”®Xm¶Ÿÿn†î²èlš)¦*^®f¢—ü_¢¹¬ý«miÈfz{lÿm4ß]u÷þúõÇ|Ý¿âž+bjX³jب؟}¸§ From tristan at mpegtv.com Wed Nov 19 17:53:36 2003 From: tristan at mpegtv.com (Tristan Savatier) Date: Wed Nov 19 20:53:39 2003 Subject: [XForms] Towards a warning-free compilation. References: <200311192306.17228.angus.leeming@btopenworld.com> Message-ID: <029501c3af09$1ce8c850$0100a8c0@milk> > I have squashed the warnings in the case above by adding the final ', 0, 0' Normally, any partially initialized global or static structure will be padded with zeros. I think it also applies to arrays (?). so the compiler warnings about 'uninitialized variable' would seem bogus to me... From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 10:20:52 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 20 04:20:59 2003 Subject: [XForms] [PATCH] Various stuff In-Reply-To: <200311192158.02931.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 19 Nov 2003 21:58:02 +0000") References: <200311192158.02931.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> So starts the slippery slope towards responsibility ;-) Many Angus> thanks for doing this. Angus Well, we _have_ to get this thing going at least until we can deliver a working autotools-based version. JMarc From angus.leeming at btopenworld.com Thu Nov 20 10:04:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 20 05:03:45 2003 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: <029501c3af09$1ce8c850$0100a8c0@milk> References: <200311192306.17228.angus.leeming@btopenworld.com> <029501c3af09$1ce8c850$0100a8c0@milk> Message-ID: <200311201002.50320.angus.leeming@btopenworld.com> On Thursday 20 November 2003 1:53 am, Tristan Savatier wrote: > > I have squashed the warnings in the case above by adding the final ', 0, > Normally, any partially initialized global or static structure will be > padded with zeros. I think it also applies to arrays (?). > so the compiler warnings about 'uninitialized variable' would seem bogus to > me... Maybe, but the fact remains that bogus warnings make it harder to see real warnings. If we can squash warnings (with no run-time effect) then we should. Angus From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 11:30:55 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 20 05:31:00 2003 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: <200311201002.50320.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 20 Nov 2003 10:04:02 +0000") References: <200311192306.17228.angus.leeming@btopenworld.com> <029501c3af09$1ce8c850$0100a8c0@milk> <200311201002.50320.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> so the compiler warnings about 'uninitialized variable' would seem >> bogus to me... Angus> Maybe, but the fact remains that bogus warnings make it harder Angus> to see real warnings. If we can squash warnings (with no Angus> run-time effect) then we should. Yes. And I think that the patch that you posted is good enough in this regard. JMarc From angus.leeming at btopenworld.com Thu Nov 20 10:49:30 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 20 05:49:17 2003 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: References: <200311192306.17228.angus.leeming@btopenworld.com> <200311201002.50320.angus.leeming@btopenworld.com> Message-ID: <200311201049.30448.angus.leeming@btopenworld.com> On Thursday 20 November 2003 10:30 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > >> > >> so the compiler warnings about 'uninitialized variable' would seem > >> bogus to me... > > Angus> Maybe, but the fact remains that bogus warnings make it harder > Angus> to see real warnings. If we can squash warnings (with no > Angus> run-time effect) then we should. > > Yes. And I think that the patch that you posted is good enough in this > regard. Me too. It's in. Angus From angus.leeming at btopenworld.com Thu Nov 20 12:49:29 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 20 07:49:14 2003 Subject: [XForms] [PATCH]: squashing all remaining warnings Message-ID: <200311201249.29064.angus.leeming@btopenworld.com> Attached is a patch to squash all the remaining warnings when compiling with CFLAGS='-W -Wall -Wno-unused-parameter'. All these warnings are 'comparison of signed and unsigned'. I have been pretty careful here and when unsure have erred on the side of caution, casting the unsigned var to signed. Much of the time though I have felt that going the other way was fine (ie, casting the signed var to unsigned). I would value it if someone would take the time to verify that I haven't fubar-ed here. Regards, Angus -------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦zÈ ç]‰÷àÍ<©yªi–'¶*'ÿ3Š”¢Íîõ߶òµëzÇ'¢Ö¯j)ZnW”®Xm¶Ÿÿn†î²èlš)¦*^®f¢—ü_¢¹¬ý«miÈfz{lÿm4ß]vÓý;å¶öçoìŠ ÞuØŸ}¸§ From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 14:49:48 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 20 08:49:55 2003 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: <200311201249.29064.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 20 Nov 2003 12:49:29 +0000") References: <200311201249.29064.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Attached is a patch to squash Angus> all the remaining warnings when compiling with CFLAGS='-W -Wall Angus> -Wno-unused-parameter'. All these warnings are 'comparison of Angus> signed and unsigned'. Angus> I have been pretty careful here and when unsure have erred on Angus> the side of caution, casting the unsigned var to signed. Much Angus> of the time though I have felt that going the other way was Angus> fine (ie, casting the signed var to unsigned). And did you find any real problem in the process? Angus> I would value it if someone would take the time to verify that Angus> I haven't fubar-ed here. I took a quick look at the patch and it looks like checking each and every of these is a long process. I won't have time to do it. So if you are confident, just apply the patch. Otherwise, we'll have to live with the warnings :) JMarc From angus.leeming at btopenworld.com Fri Nov 21 09:15:55 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Nov 21 04:15:36 2003 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: References: <200311201249.29064.angus.leeming@btopenworld.com> Message-ID: <200311210915.55314.angus.leeming@btopenworld.com> On Thursday 20 November 2003 1:49 pm, Jean-Marc Lasgouttes wrote: > Angus> I would value it if someone would take the time to verify that > Angus> I haven't fubar-ed here. > > I took a quick look at the patch and it looks like checking each and > every of these is a long process. I won't have time to do it. > > So if you are confident, just apply the patch. Otherwise, we'll have > to live with the warnings :) Maybe I'll do it a bit at a time. Adding bugs for the sake of squashing warnings seems like a poor trade off to me ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 10:23:13 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Nov 21 04:23:18 2003 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: <200311210915.55314.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 21 Nov 2003 09:15:55 +0000") References: <200311201249.29064.angus.leeming@btopenworld.com> <200311210915.55314.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Maybe I'll do it a bit at a time. Adding bugs for the sake of Angus> squashing warnings seems like a poor trade off to me ;-) Definitely :) JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 11:53:37 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Nov 21 05:53:49 2003 Subject: [XForms] [PATCH] squash more warnings Message-ID: I tried to ask dec cc what it thought about xforms' source. To this end I used the "-w0 -check" options (which amount to some kind of lint according to the docs). Then I removed a lot of irrelevant warnings by using option "-msg_disable strctpadding,ignorecallval,valuepres,falloffend". I turns out that it diagnosed several uses of unexisting macros, which are fixed by the patch below. I also attach the list of remaining warnings. In this list the only warning that worries me are the ones about RETSIGTYPE (that I do not know how to solve and that we do have to solve). Also, I cannot do anything about usleep because there is no header that defines it (is this thing supposed to be sadard?). I'll apply the patch. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: warnings.diff Type: text/x-patch Size: 4787 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031121/6949fbf8/warnings.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mk.log Type: application/octet-stream Size: 5422 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031121/6949fbf8/mk.obj From angus.leeming at btopenworld.com Fri Nov 21 13:28:33 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Nov 21 08:28:18 2003 Subject: [XForms] Enabling the building of the demo GL programs Message-ID: <200311211328.33037.angus.leeming@btopenworld.com> Ok, I squashed those warnings about the comparison of signed and unsigned vars that I deemed to be safe to squash. The remaining few can wait till I have more energy ;-) Attached is a patch to enable the building of the demo GL programs. Comments? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-diff Size: 2305 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031121/c6ab75bc/demos.bin From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 15:08:17 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Nov 21 10:48:46 2003 Subject: [XForms] Enabling the building of the demo GL programs In-Reply-To: <200311211328.33037.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 21 Nov 2003 13:28:33 +0000") References: <200311211328.33037.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Ok, I squashed those warnings Angus> about the comparison of signed and unsigned vars that I deemed Angus> to be safe to squash. The remaining few can wait till I have Angus> more energy ;-) Good move. Angus> Attached is a patch to enable the building of the demo GL Angus> programs. Angus> Comments? Looks reasonable. JMarc From msz at astrouw.edu.pl Sun Nov 23 16:35:48 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Sun Nov 23 10:35:58 2003 Subject: [XForms] problem with autoconf in RH9 Message-ID: <20031123153548.GA18821@astrouw.edu.pl> Hi, I've just downloaded the source from CVS depository, using: cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms co . Contrary to what I found in the INSTALL file, the downloaded tree lacks 'configure' script so I ran "autoconf". Unfortunately, it failed saying: >autoconf configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:14: error: possibly undefined macro: AM_MAINTAINER_MODE configure.ac:17: error: possibly undefined macro: AM_INIT_AUTOMAKE configure.ac:29: error: possibly undefined macro: AM_CONDITIONAL configure.ac:52: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:53: error: possibly undefined macro: AM_PROG_LIBTOOL The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, autoconf-2.57-3, libtool-1.4.3-5. Any ideas, hints? regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From drriddle at qwest.net Sun Nov 23 15:22:07 2003 From: drriddle at qwest.net (Reed Riddle) Date: Sun Nov 23 16:22:11 2003 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> I just installed this yesterday on a RedHat 9, with the CVS version, and everything worked just fine. It's a standard RedHat install, nothing modified. Have you changed anything in the system settings, or added/updated any software? Reed On Sunday, November 23, 2003, at 09:35 AM, Michal Szymanski wrote: > To subscribers of the xforms list > > > Hi, > > I've just downloaded the source from CVS depository, using: > > cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms login > cvs -z3 -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms co . > > Contrary to what I found in the INSTALL file, the downloaded tree lacks > 'configure' script so I ran "autoconf". Unfortunately, it failed > saying: > >> autoconf > configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.ac:14: error: possibly undefined macro: AM_MAINTAINER_MODE > configure.ac:17: error: possibly undefined macro: AM_INIT_AUTOMAKE > configure.ac:29: error: possibly undefined macro: AM_CONDITIONAL > configure.ac:52: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL > configure.ac:53: error: possibly undefined macro: AM_PROG_LIBTOOL > > The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, > autoconf-2.57-3, libtool-1.4.3-5. > > Any ideas, hints? > > regards, Michal. > > -- > Michal Szymanski (msz@astrouw.edu.pl) > Warsaw University Observatory, Warszawa, POLAND > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request@bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > > ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle@qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From msz at astrouw.edu.pl Mon Nov 24 08:49:44 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon Nov 24 02:49:56 2003 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> References: <20031123153548.GA18821@astrouw.edu.pl> <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> Message-ID: <20031124074944.GA829@astrouw.edu.pl> On Sun, Nov 23, 2003 at 03:22:07PM -0600, Reed Riddle wrote: > I just installed this yesterday on a RedHat 9, with the CVS version, > and everything worked just fine. It's a standard RedHat install, > nothing modified. Have you changed anything in the system settings, or > added/updated any software? > >The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, > >autoconf-2.57-3, libtool-1.4.3-5. Well, the system *IS* updated, following RH errata. Could you please check your versions of the RPMs given above? regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Mon Nov 24 10:30:59 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon Nov 24 04:31:04 2003 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031123153548.GA18821@astrouw.edu.pl> (Michal Szymanski's message of "Sun, 23 Nov 2003 16:35:48 +0100") References: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> I've just downloaded the source from CVS depository, using: Michal> cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms Michal> login cvs -z3 Michal> -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms co . Michal> Contrary to what I found in the INSTALL file, the downloaded Michal> tree lacks 'configure' script so I ran "autoconf". Try to run ./autogen.sh instead. JMarc From msz at astrouw.edu.pl Mon Nov 24 16:29:57 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon Nov 24 11:28:05 2003 Subject: [XForms] JPEG/EXIF support? Message-ID: <20031124152956.GA2504@astrouw.edu.pl> Hi, It seems that JPEG support in XForms 1.0 is only for "standard", JFIF format. I have plenty of JPEG/EXIF "extended" format images from digital camera which I'd like very much to display using XForms. Now, unfortunately, I'm getting messages like: In OpenImage [image.c 224] Guad22.jpg: Unknown image format Is there a simpler way to get them loaded properly than to write my own routines and use "flimage_add_format()"? I mean like using newer JPEG library? regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Mon Nov 24 17:41:04 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon Nov 24 11:41:10 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031124152956.GA2504@astrouw.edu.pl> (Michal Szymanski's message of "Mon, 24 Nov 2003 16:29:57 +0100") References: <20031124152956.GA2504@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> It seems that JPEG support in XForms 1.0 is only for Michal> "standard", JFIF format. I have plenty of JPEG/EXIF "extended" Michal> format images from digital camera which I'd like very much to Michal> display using XForms. Now, unfortunately, I'm getting messages Michal> like: Michal> In OpenImage [image.c 224] Guad22.jpg: Unknown image format Where is this JPEG/EXIF thing described? JMarc From msz at astrouw.edu.pl Mon Nov 24 18:28:21 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon Nov 24 12:28:29 2003 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: References: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: <20031124172821.GA9534@astrouw.edu.pl> On Mon, Nov 24, 2003 at 10:30:59AM +0100, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > > >>>>> "Michal" == Michal Szymanski writes: > > Michal> To subscribers of the xforms list Hi, > > Michal> I've just downloaded the source from CVS depository, using: > > Michal> cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms > Michal> login cvs -z3 > Michal> -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms co . > > Michal> Contrary to what I found in the INSTALL file, the downloaded > Michal> tree lacks 'configure' script so I ran "autoconf". > > Try to run ./autogen.sh instead. Thanks, it worked. I guess it might be worth putting into INSTALL file which now is somewhat misleading. regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From msz at astrouw.edu.pl Mon Nov 24 19:07:06 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon Nov 24 13:08:49 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: References: <20031124152956.GA2504@astrouw.edu.pl> Message-ID: <20031124180705.GB9534@astrouw.edu.pl> On Mon, Nov 24, 2003 at 05:41:04PM +0100, Jean-Marc Lasgouttes wrote: > >>>>> "Michal" == Michal Szymanski writes: > > Michal> To subscribers of the xforms list Hi, > > Michal> It seems that JPEG support in XForms 1.0 is only for > Michal> "standard", JFIF format. I have plenty of JPEG/EXIF "extended" > Michal> format images from digital camera which I'd like very much to > Michal> display using XForms. Now, unfortunately, I'm getting messages > Michal> like: > > Michal> In OpenImage [image.c 224] Guad22.jpg: Unknown image format > > Where is this JPEG/EXIF thing described? A quick search on the net resulted in following: EXIF stands for Exchangeable Image File Format, and is a standard for storing interchange information in image files, especially those using JPEG compression. Most digital cameras now use the EXIF format. The format is part of the DCF standard created by JEIDA to encourage interoperability between imaging devices. >From what I could quickly find, EXIF data in a JPEG file is stored in an application segment APP1. It seems that JPEG standard supports such segments - I'm not sure why the JPEG code in XForms can't deal with such images (if they really conform to JPEG standard, as it seems). Links: http://www.exif.org/ and links therein, of which one is particularly good: http://park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Mon Nov 24 19:51:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Nov 24 14:51:04 2003 Subject: [XForms] Getting rid of auto-generated files... Message-ID: <200311241951.26091.angus.leeming@btopenworld.com> It would be nice if we could get rid of at least some of the .[ch] files generated from .fd datasets. We store .fd files and their associated .[ch] files in the following directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, the .[ch] files in the first two directories would have to remain. (We cannot generate the .[ch] files until fdesign has bee created.) However, it strikes me that the .[ch] files in the remaining directories could all be generated on the fly, just as we do in LyX. Personally, I think that this would be much more elegant. Thoughts? Angus From xforms2 at vjet.demon.co.uk Mon Nov 24 23:43:41 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Mon Nov 24 18:44:57 2003 Subject: [XForms] JPEG/EXIF support? Message-ID: <200311242343.hAONhf36001050@vjet.demon.co.uk> Hi, > It seems that JPEG support in XForms 1.0 is only for "standard", JFIF > format. I have plenty of JPEG/EXIF "extended" format images from digital > camera which I'd like very much to display using XForms. > Now, unfortunately, I'm getting messages like: > > In OpenImage [image.c 224] Guad22.jpg: Unknown image format A long time ago I did a patch to improve some stuff in the image handling.. It got lost in the move to 1.0 But I can read images off my camera so it may solve your problem too.. Patch is at http://www.vjet.demon.co.uk/xforms/image.patch It probably needs massaging to work on the latest CVS. It fixes a bug in flimage_dup() , one in image rotate, and makes jpeg + gif reading better. These patches are applied to my 1.0 rpms too (http://www.vjet.demon.co.uk/xforms) HTHs Cheers Clive From mheffner at vt.edu Tue Nov 25 09:27:24 2003 From: mheffner at vt.edu (Mike Heffner) Date: Tue Nov 25 09:33:14 2003 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <20031119105606.GA1903@astrouw.edu.pl> Message-ID: On 19-Nov-2003 Michal Szymanski wrote: > To subscribers of the xforms list > >> >> This weekend I'll try rewriting the file selector's callback using the >> fl_set_browser_dblclick_callback(). It seems that might be a much >> easier >> way of approaching this. > > Mike, did you try the rewrite? Nope, unfortunately life got in the way. :) I should have some free time this week to look at it again. Cheers, Mike -- Mike Heffner From angus.leeming at btopenworld.com Tue Nov 25 21:09:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Nov 25 16:09:07 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311242343.hAONhf36001050@vjet.demon.co.uk> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> Message-ID: <200311252109.26767.angus.leeming@btopenworld.com> On Monday 24 November 2003 11:43 pm, Clive A Stubbings wrote: > A long time ago I did a patch to improve some stuff in the image > handling.. It got lost in the move to 1.0 > > But I can read images off my camera so it may solve your problem too.. > Patch is at http://www.vjet.demon.co.uk/xforms/image.patch Got it. > It probably needs massaging to work on the latest CVS. It fixes a bug in > flimage_dup() , I'm not going to apply this without some discussion. Feel free to explain the rationale. > one in image rotate. I don't see the need for this. See the comment immediately preceeding your patched code. In cvs at least. /* * Now coerce it into +/- 180. */ > and makes jpeg + gif reading better. I've applied both these parts to my local tree, albeit with some re-factoring to get rid of the goto and some signed-unsigned comparson warnings. Could you check to see that all is still as you intended (attached). If you could cast your eye over the ChangeLog entry and maybe rename 'flush_buffer' to something that makes sense to you, that'd be great too... Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: clive.diff Type: text/x-diff Size: 3888 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031125/dead5e72/clive.bin From angus.leeming at btopenworld.com Tue Nov 25 22:56:45 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Nov 25 17:56:22 2003 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311241951.26091.angus.leeming@btopenworld.com> References: <200311241951.26091.angus.leeming@btopenworld.com> Message-ID: <200311252256.45141.angus.leeming@btopenworld.com> On Monday 24 November 2003 7:51 pm, Angus Leeming wrote: > To subscribers of the xforms list > > > It would be nice if we could get rid of at least some of the .[ch] files > generated from .fd datasets. > > We store .fd files and their associated .[ch] files in the following > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, > the .[ch] files in the first two directories would have to remain. (We > cannot generate the .[ch] files until fdesign has bee created.) However, it > strikes me that the .[ch] files in the remaining directories could all be > generated on the fly, just as we do in LyX. > > Personally, I think that this would be much more elegant. Thoughts? Ok, I'm stuck ;-) Jean-Marc, I wonder if you might help... Attached are the changes I've made to demos/Makefile.am. This is proof of concept code and, indeed, works fine. However, I have no idea how to turn it into robust code :-( The problem lies with the block below which generates .[ch] files from a .fd file. Note that I am running this conversion from $build_dir/demos whilst the .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do not want to generate a static library in the fd directory because I want to be able to build individual demo files if I so choose. Here's the troublesome (but working) block: %.c: %.fd ../fdesign/fdesign (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign -convert `basename $<`; \ mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.) Line 1. All is Ok. The generated .c file depends on the .fd file and on the existence of the fdesign binary. %.c: %.fd ../fdesign/fdesign Lines 2,3. The problems. It appears that fdesign must be run from the directory containing the .fd file. That means I lose track of the fdesign binary and then must move the generated .[ch] files into the $builddir tree (if $srcdir != $builddir). Any ideas? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos_makefile.am Type: text/x-diff Size: 1081 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031125/bd54bf1f/demos_makefile.bin From msz at astrouw.edu.pl Wed Nov 26 09:26:09 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed Nov 26 03:26:15 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311252109.26767.angus.leeming@btopenworld.com> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> Message-ID: <20031126082609.GA9882@astrouw.edu.pl> On Tue, Nov 25, 2003 at 09:09:26PM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > On Monday 24 November 2003 11:43 pm, Clive A Stubbings wrote: > > A long time ago I did a patch to improve some stuff in the image > > handling.. It got lost in the move to 1.0 > > > > But I can read images off my camera so it may solve your problem too.. > > Patch is at http://www.vjet.demon.co.uk/xforms/image.patch > > Got it. > > > It probably needs massaging to work on the latest CVS. It fixes a bug in > > flimage_dup() , > > I'm not going to apply this without some discussion. Feel free to explain the > rationale. Hi, I did not go into details but downloaded Clive's patched versions of the 1.0 libs and indeed, my application started to read JPEG/EXIF images from my digital camera without any modification, just relinking. So I'd strongely vote for including the patch(es) into XForms. regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Wed Nov 26 10:43:16 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Nov 26 05:42:56 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031126082609.GA9882@astrouw.edu.pl> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> <20031126082609.GA9882@astrouw.edu.pl> Message-ID: <200311261043.16110.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 8:26 am, Michal Szymanski wrote: > Hi, > > I did not go into details but downloaded Clive's patched versions of the > 1.0 libs and indeed, my application started to read JPEG/EXIF images > from my digital camera without any modification, just relinking. So I'd > strongely vote for including the patch(es) into XForms. Could you revert Clive's patch and try the one I appended in my original reply to his posting? This patch contains the jpeg and gif enhancements and I am more than happy to merge it into the xforms sources. Angus From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 12:54:12 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Nov 26 06:54:18 2003 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311252256.45141.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 25 Nov 2003 22:56:45 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. So we could maybe take a look at fixing fdesign, since we have control on it :) Another solution would be to have a Makefile.am in the fd/ directories, maybe. Sorry, I do not have much time to think about it right now. I think this is something that we could leave for after 1.1. I'd like to concentrate on this first. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 14:37:15 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Nov 26 08:37:26 2003 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 26 Nov 2003 12:54:12 +0100") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: >>>>> "Jean-Marc" == Jean-Marc Lasgouttes writes: Jean-Marc> To subscribers of the xforms list >>>>> "Angus" == Angus Leeming writes: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. Jean-Marc> So we could maybe take a look at fixing fdesign, since we Jean-Marc> have control on it :) The following patch fixes fdesign -convert for me. My problem was that I have a "." in my homedir name (/afs/inria.fr/...). Does it help you? Could you re-read the patch to make sure I did not make a mistake? I think using filename instead of fname is the right thing to do here. With this patch applied, I get the following diff on a sample fd file. So the difference is: 1/ the LGPL notice is gone. Is this a big problem? 2/ we have -#include "include/forms.h" +#include "forms.h" I think this will be solved by using -I$(top_srcdir}/lib/include in INCLUDES. Note also that fdesign now adds +/** Header file generated with fdesign on Wed Nov 26 14:25:19 2003.**/ but only to the header (not the .c file). We should probably remove this altogether, since it creates useless diffs. What do you think? JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-patch Size: 1726 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031126/d3e34718/fdesign.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: fddiff.diff Type: text/x-patch Size: 2840 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031126/d3e34718/fddiff.bin From angus.leeming at btopenworld.com Wed Nov 26 13:49:43 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Nov 26 08:49:23 2003 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> Message-ID: <200311261349.43597.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 1:37 pm, Jean-Marc Lasgouttes wrote: > Angus> Lines 2,3. The problems. It appears that fdesign must be run > Angus> from the directory containing the .fd file. > > Jean-Marc> So we could maybe take a look at fixing fdesign, since we > Jean-Marc> have control on it :) > > The following patch fixes fdesign -convert for me. My problem was that > I have a "." in my homedir name (/afs/inria.fr/...). Does it help you? If it works for you, then I expect that it will work for me. I'll try it out this evening. > Could you re-read the patch to make sure I did not make a mistake? I > think using filename instead of fname is the right thing to do here. > > With this patch applied, I get the following diff on a sample fd file. > So the difference is: > > 1/ the LGPL notice is gone. Is this a big problem? No. These are generated files. If we really, really want an LGPL notice, the place to put it is in the .fd file. In turn that means enabling fdesign to handle comments in its .fd files. Something for the future, maybe, but not something to worry about now. > 2/ we have > -#include "include/forms.h" > +#include "forms.h" > I think this will be solved by using -I$(top_srcdir}/lib/include in > INCLUDES. Sure. > Note also that fdesign now adds > +/** Header file generated with fdesign on Wed Nov 26 14:25:19 2003.**/ > but only to the header (not the .c file). We should probably remove > this altogether, since it creates useless diffs. Agreed. > What do you think? I think that I like it when you claim to be 'too busy to think' ;-) Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 14:55:57 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Nov 26 08:56:05 2003 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311261349.43597.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 13:49:43 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 1:37 pm, Jean-Marc Lasgouttes wrote: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. >> Jean-Marc> So we could maybe take a look at fixing fdesign, since we Jean-Marc> have control on it :) >> The following patch fixes fdesign -convert for me. My problem was >> that I have a "." in my homedir name (/afs/inria.fr/...). Does it >> help you? Angus> If it works for you, then I expect that it will work for me. Angus> I'll try it out this evening. I'm not sure because my problem was really a "." in path. I did not see one in your path names. >> What do you think? Angus> I think that I like it when you claim to be 'too busy to think' Angus> ;-) Regards, Angus I was pointing at your convoluted makefile rules. Note that I did not propose to fix them :) The fdesign problem, OTOH is definitely a bug that should be fixed before 1.1. JMarc From angus.leeming at btopenworld.com Wed Nov 26 14:08:29 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Nov 26 09:08:08 2003 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> Message-ID: <200311261408.29034.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 1:55 pm, Jean-Marc Lasgouttes wrote: > The fdesign problem, OTOH is definitely a bug that should be fixed > before 1.1. The little wrapper script, attached, gives us the functionality that I think that fdesign should have. Usage: $ sh fdesign2c The only problem with the script is in the lst line: # If ${SRCDIR} != ${DESTDIR} then # move the generated .[ch] files to ${DESTDIR}. mv -f `basename ${FDFILE} .fd`.[ch] ${DESTDIR} I have no idea how to test that ${SRCDIR} != ${DESTDIR}. Consequently, I get errors: mv: `butttypes_gui.c' and `/home/angus/xforms/xforms/build/demos/../../demos/fd/butttypes_gui.c' are the same file mv: `butttypes_gui.h' and `/home/angus/xforms/xforms/build/demos/../../demos/fd/butttypes_gui.h' are the same file Any ideas? Angus ps, once this is working, then modifying Makefile.am is a snip. Equally, it should provide the template to modify fdesign itself. I'd imagine using fdesign as $ fdesign -convert A -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign2c Type: application/x-shellscript Size: 1216 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031126/ea9449d5/fdesign2c.bin From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 15:16:03 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Nov 26 09:16:10 2003 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311261408.29034.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 14:08:29 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> <200311261408.29034.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 1:55 pm, Jean-Marc Lasgouttes wrote: >> The fdesign problem, OTOH is definitely a bug that should be fixed >> before 1.1. Angus> The little wrapper script, attached, gives us the functionality Angus> that I think that fdesign should have. Angus> Usage: $ sh fdesign2c Angus> With my fix, fdesign is able to output .[ch] files in the directory where the .fd file was. Isn't it really good enough for now? Angus> ps, once this is working, then modifying Makefile.am is a snip. Angus> Equally, it should provide the template to modify fdesign Angus> itself. I'd imagine using fdesign as $ fdesign -convert Angus> Why would the Makefile.am not work with the fixed fdesign? Because you do not want the .[ch] files to appear in the source directory, but the build directory? JMarc From angus.leeming at btopenworld.com Wed Nov 26 14:21:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Nov 26 09:21:04 2003 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261408.29034.angus.leeming@btopenworld.com> Message-ID: <200311261421.26649.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 2:16 pm, Jean-Marc Lasgouttes wrote: > Angus> ps, once this is working, then modifying Makefile.am is a snip. > Angus> Equally, it should provide the template to modify fdesign > Angus> itself. I'd imagine using fdesign as $ fdesign -convert > Angus> > > Why would the Makefile.am not work with the fixed fdesign? Because you > do not want the .[ch] files to appear in the source directory, but the > build directory? Correct. However, I will indeed try and make things work with your patched fdesign too. Angus From Todd.Denniston at ssa.crane.navy.mil Wed Nov 26 09:21:47 2003 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Wed Nov 26 09:23:11 2003 Subject: [XForms] Getting rid of auto-generated files... References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: <3FC4B6FB.B727860E@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > ------------------------------------------------------------------------ > On Monday 24 November 2003 7:51 pm, Angus Leeming wrote: > > To subscribers of the xforms list > > > > > > It would be nice if we could get rid of at least some of the .[ch] files > > generated from .fd datasets. > > > > We store .fd files and their associated .[ch] files in the following > > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, > > the .[ch] files in the first two directories would have to remain. (We > > cannot generate the .[ch] files until fdesign has bee created.) However, it > > strikes me that the .[ch] files in the remaining directories could all be > > generated on the fly, just as we do in LyX. > > > > Personally, I think that this would be much more elegant. Thoughts? > > Ok, I'm stuck ;-) > > Jean-Marc, I wonder if you might help... Attached are the changes I've made to > demos/Makefile.am. This is proof of concept code and, indeed, works fine. > However, I have no idea how to turn it into robust code :-( > > The problem lies with the block below which generates .[ch] files from a .fd > file. Note that I am running this conversion from $build_dir/demos whilst the > .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do > not want to generate a static library in the fd directory because I want to > be able to build individual demo files if I so choose. > > Here's the troublesome (but working) block: > > %.c: %.fd ../fdesign/fdesign > (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign > -convert `basename $<`; \ > mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.) > > Line 1. All is Ok. The generated .c file depends on the .fd file and on the > existence of the fdesign binary. > %.c: %.fd ../fdesign/fdesign > > Lines 2,3. The problems. It appears that fdesign must be run from the > directory containing the .fd file. That means I lose track of the fdesign > binary and then must move the generated .[ch] files into the $builddir tree > (if $srcdir != $builddir). > > Any ideas? > Angus Actually, fdesign does not need to be ran from the directory containing the .fd file. You can pass it the path to the .fd, as in `fdesign -convert $<`, however fdesign as built now will make the .[ch] files in the same directory as the .fd file. perhaps you can/should use the gnu-make extension of vpath's, i.e., have the following added to the beginning of the demo's directory Makefile: vpath %.h . vpath %.c . vpath %.h ./fd vpath %.c ./fd vpath %.fd ./fd at least when vpath is available. a fallback, for non gnu makes, might be to make a rule that causes a `cp -p *.fd .` to occur if any file is newer in the fd directory than say the 'fdscopied' file, i.e., make fdscopied depend on all .fd files in the fd directory. Ugly but I am pretty sure I have used it in the past with other recalcitrant programs. At a later time it would be nice to have an option to pass to fdesign to either force it to output in the current working directory, or another specified output directory. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From angus.leeming at btopenworld.com Wed Nov 26 14:32:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Nov 26 09:31:58 2003 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <3FC4B6FB.B727860E@ssa.crane.navy.mil> References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> <3FC4B6FB.B727860E@ssa.crane.navy.mil> Message-ID: <200311261432.19460.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 2:21 pm, Todd Denniston wrote: Hi, Todd. > Actually, fdesign does not need to be ran from the directory containing > the .fd file. > You can pass it the path to the .fd, as in `fdesign -convert $<`, > however fdesign as built now will make the .[ch] files in the same > directory as the .fd file. Jean-Marc says that this works only so long as the path to the .fd file does not contain any '.'. See his patch. > perhaps you can/should use the gnu-make extension of vpath's, i.e., have > the following added to the beginning of the demo's directory Makefile: Hacks to work round a broken fdesign. Let's fix fdesign instead. > At a later time it would be nice to have an option to pass to fdesign to > either force it to output in the current working directory, or another > specified output directory. $ fdesign -d -convert ../foo/bar/your_file.fd That's what I'd like to get working. Angus From tacorner at chello.at Wed Nov 26 17:10:04 2003 From: tacorner at chello.at (tacorner@chello.at) Date: Wed Nov 26 11:18:29 2003 Subject: [XForms] Font selector widget Message-ID: I am thinking about writing a font selection widget for xfmail using xforms. Does such a thing exist in xforms itself or another xforms applications? Any suggestions? Tom Corner --------------------------------------------------- |\/\/\___/\/\/| Carol Anne Corner & \____ o o ____/ Thomas Corner ) ( 26-Nov-2003 17:06:59 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --------------------------------------------------- From msz at astrouw.edu.pl Wed Nov 26 23:06:24 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed Nov 26 17:06:35 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311261043.16110.angus.leeming@btopenworld.com> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> <20031126082609.GA9882@astrouw.edu.pl> <200311261043.16110.angus.leeming@btopenworld.com> Message-ID: <20031126220624.GA11680@astrouw.edu.pl> On Wed, Nov 26, 2003 at 10:43:16AM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > On Wednesday 26 November 2003 8:26 am, Michal Szymanski wrote: > > Hi, > > > > I did not go into details but downloaded Clive's patched versions of the > > 1.0 libs and indeed, my application started to read JPEG/EXIF images > > from my digital camera without any modification, just relinking. So I'd > > strongely vote for including the patch(es) into XForms. > > Could you revert Clive's patch and try the one I appended in my original reply > to his posting? This patch contains the jpeg and gif enhancements and I am > more than happy to merge it into the xforms sources. I've applied your version of Clive's patch to my home CVS source tree. The Changelog patch got rejected but both "image" patches succeeded. And my application reading images can now read JPEG/EXIF files taken from my digital camera. regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From xforms2 at vjet.demon.co.uk Thu Nov 27 02:27:21 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Wed Nov 26 21:29:23 2003 Subject: [XForms] Re: JPEG/EXIF support? Message-ID: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> Thanks Angus, > > It probably needs massaging to work on the latest CVS. It fixes a bug in > > flimage_dup() , > > I'm not going to apply this without some discussion. Feel free to explain the > rationale. Well, its a while ago, but if memory serves, I found that if I dup'd an image then later free'd both copies I got a crash. The crash was because the first free also closed the files and the second one tried to do the same again, but the fp's were no longer valid. There needs to be only one reference to the fp.. Either it goes in a shared struct that both 'images' point to, or only one image can be associated with the file. I'm not sure that 2 'images' and one file really makes sense anyway. FWIW: I duped the image because I wanted to have the original and a processed copy, so I made a dup and then processed it.. When I'd finished with both images I free'd both.. Seemed reasonable to me. > > > one in image rotate. > > I don't see the need for this. See the comment immediately preceeding your > patched code. In cvs at least. > /* > * Now coerce it into +/- 180. > */ You're right - this one was broken in the 1.0 candidates and fixed in 1.0.. (Sorry..) > > > and makes jpeg + gif reading better. > > I've applied both these parts to my local tree, albeit with some re-factoring > to get rid of the goto and some signed-unsigned comparson warnings. Could you > check to see that all is still as you intended (attached). If you could cast > your eye over the ChangeLog entry and maybe rename 'flush_buffer' to > something that makes sense to you, that'd be great too... Had a fair look at it - seems OK on paper. flush_buffer is fine. The function flushes completed lines from the working buffer. (If you don't like the goto, with hindsight, an else might have been better ;-) Cheers Clive From tacorner at chello.at Thu Nov 27 09:05:52 2003 From: tacorner at chello.at (tacorner@chello.at) Date: Thu Nov 27 03:05:47 2003 Subject: [XForms] xforms cvs access Message-ID: Another question: Is it possible to get read-only access to the xforms cvs? Thanks, Tom Corner --------------------------------------------------- |\/\/\___/\/\/| Carol Anne Corner & \____ o o ____/ Thomas Corner tacorner@chello.at ) ( 27-Nov-2003 09:04:25 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --------------------------------------------------- From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 10:54:05 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 27 04:54:11 2003 Subject: [XForms] xforms cvs access In-Reply-To: (tacorner@chello.at's message of "Thu, 27 Nov 2003 09:05:52 +0100 (CET)") References: Message-ID: >>>>> "tacorner" == tacorner writes: tacorner> To subscribers of the xforms list Another question: Is it tacorner> possible to get read-only access to the xforms cvs? Yes. Look here: https://savannah.nongnu.org/cvs/?group=xforms JMarc From angus.leeming at btopenworld.com Thu Nov 27 10:22:42 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 05:22:19 2003 Subject: [XForms] xforms cvs access In-Reply-To: References: Message-ID: <200311271022.42662.angus.leeming@btopenworld.com> On Thursday 27 November 2003 8:05 am, tacorner@chello.at wrote: Hi, Tom > Another question: Is it possible to get read-only access to the xforms > cvs? Certainly. See http://savannah.nongnu.org/cvs/?group=xforms In summary cvs -d :pserver:anoncvs@subversions.gnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs@savannah.nongnu.org:/cvsroot/xforms co xforms Thereafter, shove this in .cvsrc in your home directory: diff -upN rdiff -upN update -dP and "cvs up" should keep you up-to-date. Regards, Angus From angus.leeming at btopenworld.com Thu Nov 27 10:23:41 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 05:23:17 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031126220624.GA11680@astrouw.edu.pl> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311261043.16110.angus.leeming@btopenworld.com> <20031126220624.GA11680@astrouw.edu.pl> Message-ID: <200311271023.41446.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 10:06 pm, Michal Szymanski wrote: > > Could you revert Clive's patch and try the one I appended in my original > > reply to his posting? This patch contains the jpeg and gif enhancements > > and I am more than happy to merge it into the xforms sources. > > I've applied your version of Clive's patch to my home CVS source tree. > The Changelog patch got rejected but both "image" patches succeeded. And > my application reading images can now read JPEG/EXIF files taken from my > digital camera. Then I shall commit it. Many thanks to you both, Angus From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 11:40:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 27 05:40:24 2003 Subject: [XForms] Font selector widget In-Reply-To: (tacorner@chello.at's message of "Wed, 26 Nov 2003 17:10:04 +0100 (CET)") References: Message-ID: >>>>> "tacorner" == tacorner writes: tacorner> To subscribers of the xforms list I am thinking about tacorner> writing a font selection widget for xfmail using xforms. tacorner> Does such a thing exist in xforms itself or another xforms tacorner> applications? Any suggestions? I do not know of any... However, an idea would be to try to track the version 2.x of xfce (www.xfce.org) which is a desktop environment (like cde). Versions 1.x and 2.x where based on xforms (whence the name) and I would expect that there is a lot of xforms code to take from there (including a font chooser, maybe). [Later] I have now tracked down a copy: http://www-rocq.inria.fr/~lasgoutt/xfce-2.4.0.tar.gz Unfortunately, there does not seem to be a font chooser in it. However it may be worth looking if there some reusable widgets in the code (the license is not GPL-compatible, but I would be surprised if the author did not allow for a license change on such an old software). JMarc From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 12:32:05 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 27 06:32:10 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311271023.41446.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 10:23:41 +0000") References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311261043.16110.angus.leeming@btopenworld.com> <20031126220624.GA11680@astrouw.edu.pl> <200311271023.41446.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 10:06 pm, Michal Szymanski wrote: >> > Could you revert Clive's patch and try the one I appended in my >> original > reply to his posting? This patch contains the jpeg and >> gif enhancements > and I am more than happy to merge it into the >> xforms sources. >> >> I've applied your version of Clive's patch to my home CVS source >> tree. The Changelog patch got rejected but both "image" patches >> succeeded. And my application reading images can now read JPEG/EXIF >> files taken from my digital camera. Angus> Then I shall commit it. Many thanks to you both, Angus tru64 cc does not think that this code is OK: cc -std1 -DHAVE_CONFIG_H -I. -I../../xforms/image -I../lib -DMAKING_FORMS -I../lib -I../../xforms/lib -I/afs/rocq/home/preval/common/include -I/usr/local/include -g -c -MD ../../xforms/image/image_gif.c -DPIC -o .libs/image_gif.lo cc: Warning: ../../xforms/image/image_gif.c, line 672: The scalar variable "incode" is fetched but not initialized. (uninit1) flush_buffer(im, incode); -------------------------^ Indeed, if I read process_lzw_code correctly, the variable incode is not always initialized. Since I do not understand what it stands for, I cannot propose a fix, but obviously this needs to be fixed in some way. JMarc From angus.leeming at btopenworld.com Thu Nov 27 11:49:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 06:49:12 2003 Subject: [XForms] Re: JPEG/EXIF support? In-Reply-To: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> References: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> Message-ID: <200311271149.24457.angus.leeming@btopenworld.com> On Thursday 27 November 2003 2:27 am, Clive A Stubbings wrote: > > > It fixes a bug in flimage_dup() , > > > > I'm not going to apply this without some discussion. Feel free to explain > > the rationale. > > Well, its a while ago, but if memory serves, I found that if I dup'd an > image then later free'd both copies I got a crash. The crash was because > the first free also closed the files and the second one tried to do the > same again, but the fp's were no longer valid. > > There needs to be only one reference to the fp.. Either it goes in a > shared struct that both 'images' point to, or only one image can be > associated with the file. I'm not sure that 2 'images' and one file > really makes sense anyway. > > FWIW: I duped the image because I wanted to have the original and a > processed copy, so I made a dup and then processed it.. When I'd > finished with both images I free'd both.. Seemed reasonable to me. And to me too. I do something similar in LyX. Here are the relvant parts of my wrapper class. My question to you is, "why doesn't this trigger the crash"? If I make two copies of the image and then invoke flimage_free in the destructor, why don't I run into your problem? class xformsImage { public: xformsImage(): image_(0) {} xformsImage(xformsImage const & other) : image_(0) { if (other.image_) { image_ = flimage_dup(other.image_); image_->u_vdata = this; } } ~xformsImage() { if (image_) flimage_free(image_); } private: /// The xforms container. FL_IMAGE * image_; }; Ahhhhhhh. Because I use a callback function to monitor the loading process and explicitly close the FILE pointers when loading is complete. void xformsImage::statusCB(string const & status_message) { if (status_message.empty()) return; if (prefixIs(status_message, "Done Reading")) { if (image_) flimage_close(image_); finishedLoading(true); } } Anyway, I see the need for your patch or for something like it. Perhaps it would be better to not copy the file pointers in flimage_dup in the first place? Hmmmmmmmm. flimage_dup does NOT copy the FILE pointers. The only place that they are set is in identify_image which in turn is invoked only by flimage_open (in turn invoked by flimage_load). The point is that flimage_dup does not invoke any of these routines. Conclusion: I don't see the need for the patch. No doubt I've got my logic wrong somewhere, so I'd be grateful if you'd have a look at the current xforms sources too... > > > and makes jpeg + gif reading better. > > > > I've applied both these parts to my local tree, albeit with some > > re-factoring to get rid of the goto and some signed-unsigned comparson > > warnings. Could you check to see that all is still as you intended > > (attached). If you could cast your eye over the ChangeLog entry and maybe > > rename 'flush_buffer' to something that makes sense to you, that'd be > > great too... > > Had a fair look at it - seems OK on paper. flush_buffer is fine. The > function flushes completed lines from the working buffer. And Michal says it works, so I have committed it. Many thanks for the patch. > (If you don't like the goto, with hindsight, an else might have been better > ;-) Let's just say I have a pathological hatred of 'goto'. Something to do with maintaining some old Fortran66 code. Regards, Angus From angus.leeming at btopenworld.com Thu Nov 27 12:00:59 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 07:00:41 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311271023.41446.angus.leeming@btopenworld.com> Message-ID: <200311271200.59974.angus.leeming@btopenworld.com> On Thursday 27 November 2003 11:32 am, Jean-Marc Lasgouttes wrote: > Angus> Then I shall commit it. Many thanks to you both, Angus > > tru64 cc does not think that this code is OK: > > cc -std1 -DHAVE_CONFIG_H -I. -I../../xforms/image -I../lib -DMAKING_FORMS > -I../lib -I../../xforms/lib -I/afs/rocq/home/preval/common/include > -I/usr/local/include -g -c -MD ../../xforms/image/image_gif.c -DPIC -o > .libs/image_gif.lo cc: Warning: ../../xforms/image/image_gif.c, line 672: > The scalar variable "incode" is fetched but not initialized. (uninit1) > flush_buffer(im, incode); > -------------------------^ > > Indeed, if I read process_lzw_code correctly, the variable incode is > not always initialized. Since I do not understand what it stands for, > I cannot propose a fix, but obviously this needs to be fixed in some > way. Reading the code again static void flush_buffer(FL_IMAGE * im, int incode) { int i; incode = lbuf - lhead; ... Ie, the first thing that is done in flush_buffer is set incode. So, we have two options: * do not pass incode to the routine and have a local variable instead * pass a pointer to incode. Since the variable incode in process_lzw_code is not static and flush_buffer is the last thing called before returning from process_lzw_code, I think that the first option is sufficient. See attached patch. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: image_giff.diff Type: text/x-diff Size: 1028 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031127/99303652/image_giff.bin From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 13:56:17 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 27 07:56:23 2003 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311271200.59974.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 12:00:59 +0000") References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311271023.41446.angus.leeming@btopenworld.com> <200311271200.59974.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Ie, the first thing that is done in flush_buffer is set incode. Angus> So, we have two options: * do not pass incode to the routine Angus> and have a local variable instead * pass a pointer to incode. Angus> Since the variable incode in process_lzw_code is not static and Angus> flush_buffer is the last thing called before returning from Angus> process_lzw_code, I think that the first option is sufficient. Angus> See attached patch. You are right. JMarc From angus.leeming at btopenworld.com Thu Nov 27 15:23:00 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 10:22:36 2003 Subject: [XForms] NEWS update Message-ID: <200311271523.00688.angus.leeming@btopenworld.com> As requested... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: news.diff Type: text/x-diff Size: 1451 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031127/d2c2afb8/news.bin From angus.leeming at btopenworld.com Wed Nov 26 16:42:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 11:01:24 2003 Subject: [XForms] Adding '-dir ' to fdesign Message-ID: <200311261642.19472.angus.leeming@btopenworld.com> See attached. The patch also contains JMarc's changes to fd_forms.c. The only bit I'm unsure about are the initializations in static FL_CMD_OPT fd_cmdopt[] and in static FL_resource fdres[] The rest seems pretty straightforward. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 6372 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031126/3880bca1/fdesign.bin From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 17:08:14 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Nov 27 11:08:18 2003 Subject: [XForms] Adding '-dir ' to fdesign In-Reply-To: <200311261642.19472.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 16:42:19 +0000") References: <200311261642.19472.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list See attached. The patch also Angus> contains JMarc's changes to fd_forms.c. Wow. This one needed 23 hours to appear... JMarc From angus.leeming at btopenworld.com Thu Nov 27 16:26:57 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 11:27:02 2003 Subject: [XForms] Re: [Xforms-cvs] xforms/fdesign fd_forms.c fd_main.c fd_main.h f... In-Reply-To: References: Message-ID: <200311271626.57490.angus.leeming@btopenworld.com> On Thursday 27 November 2003 3:41 pm, Jean-Marc Lasgouttes wrote: > Angus> Log message: Give fdesign a -dir option. > > I see you've been busy... Well, not sooooooo busy. > +static char const * > +filename_only(char const * filename) > +{ > + char const * ptr = filename + strlen(filename) - 1; > + for (; ptr >= filename; --ptr) { > + if (*ptr == '/') > + return ptr+1; > + } > + return ptr; > +} > + > > Can't you use strrchr() here? Yup. Thanks. Like this? static char const * filename_only(char const * filename) { char const * ptr = strrchr(filename, '/'); if (ptr) return ptr+1; return filename; } > What happens with the external convertors? They get passed '-dir '. > You should also document the new switch in fdesign man page. Granted. Angus From angus.leeming at btopenworld.com Thu Nov 27 18:15:55 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 13:16:03 2003 Subject: [XForms] Re: [Xforms-cvs] xforms/fdesign fd_forms.c fd_main.c fd_main.h f... In-Reply-To: <200311271626.57490.angus.leeming@btopenworld.com> References: <200311271626.57490.angus.leeming@btopenworld.com> Message-ID: <200311271815.55461.angus.leeming@btopenworld.com> On Thursday 27 November 2003 4:26 pm, Angus Leeming wrote: > > Can't you use strrchr() here? > Yup. Thanks. Like this? [snip...] > > You should also document the new switch in fdesign man page. > Granted. Patch attached, FYI. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 2080 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031127/21408007/fdesign.bin From angus.leeming at btopenworld.com Thu Nov 27 21:24:57 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 16:25:00 2003 Subject: [XForms] Getting rid of generated files Message-ID: <200311272124.57343.angus.leeming@btopenworld.com> Attached is a patch that uses the new -dir option of fdesign to get rid of demos/fd/button_gui.[ch] from the cvs repository. I've checked that all works fine from a 'make distdir' tree as well. Indeed, almost all of the .[ch] files in demos/fd can be removed in the same manner. The only ones that must remain are fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. Fdesign does not have the ability currently to #include user-specifed files. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-diff Size: 7226 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031127/4e33e2b5/demos.bin From angus.leeming at btopenworld.com Thu Nov 27 22:24:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 17:24:29 2003 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272124.57343.angus.leeming@btopenworld.com> References: <200311272124.57343.angus.leeming@btopenworld.com> Message-ID: <200311272224.19706.angus.leeming@btopenworld.com> On Thursday 27 November 2003 9:24 pm, Angus Leeming wrote: > To subscribers of the xforms list > Indeed, almost all of the .[ch] files in demos/fd can be removed > in the same manner. The only ones that must remain are > fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend > on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. > Fdesign does not have the ability currently to #include user-specifed files. Actually, it transpires that I can remove these files too. The trick is to ensure that fd/ibrowser_gui.c is not compiled on its own, but rather that it is #included by ibrowser.c. (This trick was much-used in the demos dir; I have retained it only for the compilation of ibrowser.c and itest.c.) Angus From angus.leeming at btopenworld.com Thu Nov 27 22:31:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Nov 27 17:31:26 2003 Subject: [XForms] Towards xforms 1.1 Message-ID: <200311272231.24152.angus.leeming@btopenworld.com> Ok, Jean-Marc. I think that we're getting closer, don't you? What else do you have on your to-do list? Regards, Angus From xforms2 at vjet.demon.co.uk Fri Nov 28 01:37:31 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Thu Nov 27 20:41:44 2003 Subject: [XForms] Re: JPEG/EXIF support? Message-ID: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> Hi Angus, I built the original fix a long time ago, possibly on one of the really early open releases. It is always possible that it has been subsequently fixed elsewhere. The old flimage_dup did FL_IMAGE * flimage_dup_(FL_IMAGE * sim, int pix) { ... FL_IMAGE *im = flimage_alloc(); ... memcpy(im, sim, sizeof(*im)); Which seems a bit iffy.. I've just checked - thats is also how it is in 1.0. Can you check the current version? Cheers Clive > On Thursday 27 November 2003 2:27 am, Clive A Stubbings wrote: > > > > It fixes a bug in flimage_dup() , > > > > > > I'm not going to apply this without some discussion. Feel free to explain > > > the rationale. > > > > Well, its a while ago, but if memory serves, I found that if I dup'd an > > image then later free'd both copies I got a crash. The crash was because > > the first free also closed the files and the second one tried to do the > > same again, but the fp's were no longer valid. > > > > There needs to be only one reference to the fp.. Either it goes in a > > shared struct that both 'images' point to, or only one image can be > > associated with the file. I'm not sure that 2 'images' and one file > > really makes sense anyway. > > > > FWIW: I duped the image because I wanted to have the original and a > > processed copy, so I made a dup and then processed it.. When I'd > > finished with both images I free'd both.. Seemed reasonable to me. > > And to me too. I do something similar in LyX. Here are the relvant parts of my > wrapper class. My question to you is, "why doesn't this trigger the crash"? > If I make two copies of the image and then invoke flimage_free in the > destructor, why don't I run into your problem? > > class xformsImage { > public: > xformsImage(): image_(0) {} > xformsImage(xformsImage const & other) : image_(0) { > if (other.image_) { > image_ = flimage_dup(other.image_); > image_->u_vdata = this; > } > } > > ~xformsImage() { > if (image_) > flimage_free(image_); > } > private: > /// The xforms container. > FL_IMAGE * image_; > }; > > Ahhhhhhh. Because I use a callback function to monitor the loading process and > explicitly close the FILE pointers when loading is complete. > > void xformsImage::statusCB(string const & status_message) > { > if (status_message.empty()) > return; > > if (prefixIs(status_message, "Done Reading")) { > if (image_) > flimage_close(image_); > finishedLoading(true); > } > } > > Anyway, I see the need for your patch or for something like it. > > Perhaps it would be better to not copy the file pointers in flimage_dup in the > first place? Hmmmmmmmm. flimage_dup does NOT copy the FILE pointers. The only > place that they are set is in identify_image which in turn is invoked only by > flimage_open (in turn invoked by flimage_load). The point is that flimage_dup > does not invoke any of these routines. > > Conclusion: I don't see the need for the patch. > No doubt I've got my logic wrong somewhere, so I'd be grateful if you'd have a > look at the current xforms sources too... > > > > > > > and makes jpeg + gif reading better. > > > > > > I've applied both these parts to my local tree, albeit with some > > > re-factoring to get rid of the goto and some signed-unsigned comparson > > > warnings. Could you check to see that all is still as you intended > > > (attached). If you could cast your eye over the ChangeLog entry and maybe > > > rename 'flush_buffer' to something that makes sense to you, that'd be > > > great too... > > > > Had a fair look at it - seems OK on paper. flush_buffer is fine. The > > function flushes completed lines from the working buffer. > > And Michal says it works, so I have committed it. Many thanks for the patch. > > > (If you don't like the goto, with hindsight, an else might have been better > > ;-) > > Let's just say I have a pathological hatred of 'goto'. Something to do with > maintaining some old Fortran66 code. > > Regards, > Angus > > From angus.leeming at btopenworld.com Fri Nov 28 09:16:22 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Nov 28 04:16:27 2003 Subject: [XForms] Re: JPEG/EXIF support? In-Reply-To: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> References: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> Message-ID: <200311280916.22028.angus.leeming@btopenworld.com> On Friday 28 November 2003 1:37 am, Clive A Stubbings wrote: > Hi Angus, > > I built the original fix a long time ago, possibly on one of the really > early open releases. It is always possible that it has been subsequently > fixed elsewhere. > > The old flimage_dup did > > FL_IMAGE * > flimage_dup_(FL_IMAGE * sim, int pix) > { > ... > FL_IMAGE *im = flimage_alloc(); > ... > memcpy(im, sim, sizeof(*im)); > > > Which seems a bit iffy.. I've just checked - thats is also how it is > in 1.0. Can you check the current version? Sigh! Yes, it still does. However, it goes on: memcpy(im, sim, sizeof(*im)); /* reset all pointers */ im->red = im->green = im->blue = im->alpha = 0; im->red_lut = im->green_lut = im->blue_lut = im->alpha_lut = 0; im->gray = 0; im->ci = 0; im->red16 = im->green16 = im->blue16 = im->alpha16 = 0; im->packed = 0; im->wlut = 0; im->llut[0] = im->llut[1] = im->llut[2] = 0; im->extra_io_info = 0; im->info = 0; There are actually a heap more pointers that these defined in the struct, but I guess that it's here that we should reset the fpin and fpout pointers, no? Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 18:15:43 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Nov 28 12:15:51 2003 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272224.19706.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:24:19 +0000") References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Thursday 27 November 2003 9:24 pm, Angus Leeming wrote: >> To subscribers of the xforms list >> Indeed, almost all of the .[ch] files in demos/fd can be removed in >> the same manner. The only ones that must remain are >> fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend >> on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. >> Fdesign does not have the ability currently to #include >> user-specifed files. Angus> Actually, it transpires that I can remove these files too. The Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on Angus> its own, but rather that it is #included by ibrowser.c. (This Angus> trick was much-used in the demos dir; I have retained it only Angus> for the compilation of ibrowser.c and itest.c.) Excellent. From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 18:15:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Nov 28 12:19:59 2003 Subject: [XForms] Towards xforms 1.1 In-Reply-To: <200311272231.24152.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:31:24 +0000") References: <200311272231.24152.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Ok, Jean-Marc. I think that Angus> we're getting closer, don't you? What else do you have on your Angus> to-do list? In no particular order: - We've got to decide on a version number. I suggest something like 1.0.90. The m4 code needs to be changed probably, as we seem to have two notions of current version in configure.ac. - we may need to support dlls under windows (but this can maybe wait for next version). The key is to use AC_LIBTOOL_WIN32_DLL: Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with __declspec(dllexport) and imported with __declspec(dllimport). If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts. This macro must be called before AC_PROG_LIBTOOL, and provision must be made to pass `-no-undefined' to libtool in link mode from the package Makefile. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols really are defined at link time! Actually, I do not know whether xforms 1.0 did build as dll for cygwin. - I still have a problem to fix for proper handling of RETSIGTYPE in lib/signal.c. I did not find any clear solution in other programs... Maybe a little bit of autoconf magic will suffice. - we need to update README a little bit more (there is a duplicated part...) - besides the standard installation instructions in INSTALL, should we document things like --enable-demos --enable-gl and friends? JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 18:17:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Nov 28 12:25:46 2003 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031124172821.GA9534@astrouw.edu.pl> (Michal Szymanski's message of "Mon, 24 Nov 2003 18:28:21 +0100") References: <20031123153548.GA18821@astrouw.edu.pl> <20031124172821.GA9534@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: >> Try to run ./autogen.sh instead. Michal> Thanks, it worked. I guess it might be worth putting into Michal> INSTALL file which now is somewhat misleading. I think the right thing to do is to have a README-cvs file which is in cvs (and gives the info) but is not distributed... JMarc From angus.leeming at btopenworld.com Fri Nov 28 17:32:35 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Nov 28 12:32:39 2003 Subject: [XForms] Towards xforms 1.1 In-Reply-To: References: <200311272231.24152.angus.leeming@btopenworld.com> Message-ID: <200311281732.35512.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:15 pm, Jean-Marc Lasgouttes wrote: > Angus> To subscribers of the xforms list Ok, Jean-Marc. I think that > Angus> we're getting closer, don't you? What else do you have on your > Angus> to-do list? > > In no particular order: > > - We've got to decide on a version number. I suggest something like > 1.0.90. Ok. > The m4 code needs to be changed probably, as we seem to have > two notions of current version in configure.ac. Is this the difference between the 'release' version and the 'indication of the binary compatibility of the libraries' version thingy that confused us way back when? Is there no place that we can ask for advice? Someone must understand this stuff. > - we may need to support dlls under windows (but this can maybe wait > for next version). I don't know about you, but I think of this release as the 'autotools' release. Would be nice therefore if we finished it off before release and never had to worry about any of this crap ever again... > - we need to update README a little bit more (there is a duplicated > part...) I'll have a go. > - besides the standard installation instructions in INSTALL, should we > document things like --enable-demos --enable-gl and friends? Yes. Where would it go? In INSTALL, or is that simply the generic stuff. Incidentally, (now that I have repaired your breakage of 'make rpmdist' ;-P), would it make sense to create an xforms-demos src rpm. I guess that there is little point creating a binary of same... Hmmm, I'm not sure that would work, since the Makefile assumes that fdesign is to be found in ../fdesign/fdesign. Let's leave that then ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 18:28:13 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Nov 28 12:36:00 2003 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272224.19706.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:24:19 +0000") References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Actually, it transpires that I can remove these files too. The Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on Angus> its own, but rather that it is #included by ibrowser.c. (This Angus> trick was much-used in the demos dir; I have retained it only Angus> for the compilation of ibrowser.c and itest.c.) Unfortunately, it does not work here. Why? JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: mk.log Type: application/octet-stream Size: 6447 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20031128/424be7d7/mk.obj From angus.leeming at btopenworld.com Fri Nov 28 17:45:56 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Nov 28 12:46:00 2003 Subject: [XForms] Getting rid of generated files In-Reply-To: References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: <200311281745.56835.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:28 pm, Jean-Marc Lasgouttes wrote: > Angus> Actually, it transpires that I can remove these files too. The > Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on > Angus> its own, but rather that it is #included by ibrowser.c. (This > Angus> trick was much-used in the demos dir; I have retained it only > Angus> for the compilation of ibrowser.c and itest.c.) > > Unfortunately, it does not work here. Why? Genuinely no problems here. Question: where is FL_NORMAL_FORMBROWSER defined? Answer lib/include/forms.h Here the first 5 lines of formbrowser_gui.c are: /* Form definition file generated with fdesign. */ #include "forms.h" #include #include "formbrowser_gui.h" Ie, I don't see why it is failing. I'm a bit upset about the subsequent warnings about two many initializers too... Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 18:38:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Nov 28 12:48:34 2003 Subject: [XForms] Towards xforms 1.1 In-Reply-To: <200311281732.35512.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 Nov 2003 17:32:35 +0000") References: <200311272231.24152.angus.leeming@btopenworld.com> <200311281732.35512.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I don't know about you, but I think of this release as the Angus> 'autotools' release. Would be nice therefore if we finished it Angus> off before release and never had to worry about any of this Angus> crap ever again... Then we need to get Kayvan to test it, but we could maybe release 1.0.90 and implement libtol support from there. >> - besides the standard installation instructions in INSTALL, should >> we document things like --enable-demos --enable-gl and friends? Angus> Yes. Where would it go? In INSTALL, or is that simply the Angus> generic stuff. I do not know. INSTALL is supposed (in GNU world) to come straight from autoconf (I do not know why). I do not know what is the gnuly correct place. Angus> Incidentally, (now that I have repaired your breakage of 'make Angus> rpmdist' ;-P), would it make sense to create an xforms-demos Angus> src rpm. I guess that there is little point creating a binary Angus> of same... Hmmm, I'm not sure that would work, since the Angus> Makefile assumes that fdesign is to be found in Angus> ../fdesign/fdesign. Yes, the sources are not so large. JMarc PS: We should also get the docs on the web page. Also, should we have a document ``how to adapt your application to 1.1'', or is everything just supposed to work magically? From angus.leeming at btopenworld.com Fri Nov 28 17:55:18 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Nov 28 12:55:27 2003 Subject: [XForms] Towards xforms 1.1 In-Reply-To: References: <200311272231.24152.angus.leeming@btopenworld.com> <200311281732.35512.angus.leeming@btopenworld.com> Message-ID: <200311281755.18644.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:38 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> I don't know about you, but I think of this release as the > Angus> 'autotools' release. Would be nice therefore if we finished it > Angus> off before release and never had to worry about any of this > Angus> crap ever again... > > Then we need to get Kayvan to test it, but we could maybe release > 1.0.90 and implement libtol support from there. Ok. > >> - besides the standard installation instructions in INSTALL, should > >> we document things like --enable-demos --enable-gl and friends? > > Angus> Yes. Where would it go? In INSTALL, or is that simply the > Angus> generic stuff. > > I do not know. INSTALL is supposed (in GNU world) to come straight > from autoconf (I do not know why). I do not know what is the gnuly > correct place. Who to ask? > PS: We should also get the docs on the web page. Also, should we have > a document ``how to adapt your application to 1.1'', or is everything > just supposed to work magically? We have been promised these docs since the day xforms 1.0 was released. I really don't know what the problem is :-( Once we get them, it would make sense to invest some time in a homepage on savannah. Angus From angus.leeming at btopenworld.com Sat Nov 29 18:22:36 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat Nov 29 13:22:44 2003 Subject: [XForms] Re: [Xforms-cvs] First time CVS download. In-Reply-To: <3FC8DBA2.108@omensys.ca> References: <3FC8DBA2.108@omensys.ca> Message-ID: <200311291822.36936.angus.leeming@btopenworld.com> On Saturday 29 November 2003 5:47 pm, Serge B Bromow wrote: > I just tried to download the CVS tree for the first time to a RH7.3 OS. > There seems to be missing files. i.e "forms.h" and more. Generated from the smaller header files in lib/include. > Here is the script I used to retrieve the files and the output from the > script. The script looks Ok. Personally I would have $ ./autogen.sh $ mkdir build && cd build $ ../configure --enable-demos --enable-maintainer-mode $ make > Needless to say, "./configure" na d "make" fail. [snip most of the script output...] Using autoconf (GNU Autoconf) 2.58 Well, that certainly isn't part of RH7.3 ;-) Generate acinclude.m4... done. Building macros... . done. Building config header template... . /usr/bin/m4: configure.in: No such file or directory Ahhhh. We don't support the old version of autoconf (2.13 and below) that use configure.in. Instead, we require you to use autoconf 2.52 or above that uses configure.ac. The fact that your autoconf is searching for configure.in does not square with the message above saying that you are using autoconf 2.58. Jean-Marc, you're the autotools expert around here. Any ideas? > Am I missing something? Any thoughts? > > Serge Angus (cross-posting this to the xforms maiing list to ensure we get JMarc's attention.) From serge at omensys.ca Sat Nov 29 12:32:54 2003 From: serge at omensys.ca (Serge B Bromow) Date: Sun Nov 30 12:53:33 2003 Subject: [XForms] CVS Update Message-ID: <3FC8D846.1050305@omensys.ca> I just tried to download the CVS tree for the first time to a RH7.3 OS. There seem to be missing files. i.e "forms.h" and more. Here is the script I used to retrieve to file and the output from the script. Am I missing something? Any thoughts? Serge ----------------------- Script cd /home/serge rm -rf xforms cvs -d:pserver:anoncvs@savannah.nongnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs@savannah.nongnu.org:/cvsroot/xforms co xforms cd xforms ./autogen.sh ./configure make ----------- Output [serge@daph serge]$ ./getxforms \Logging in to :pserver:anoncvs@savannah.nongnu.org:2401/cvsroot/xforms CVS password: cvs server: Updating xforms U xforms/.cvsignore U xforms/COPYING.LIB U xforms/ChangeLog U xforms/Copyright U xforms/INSTALL U xforms/Makefile.am U xforms/NEWS U xforms/README U xforms/README.OS2 U xforms/autogen.sh U xforms/configure.ac U xforms/xforms.spec.in cvs server: Updating xforms/NT U xforms/NT/libxforms.dsp U xforms/NT/xformsAll.dsw cvs server: Updating xforms/X11 cvs server: Updating xforms/config U xforms/config/.cvsignore U xforms/config/Makefile.am U xforms/config/common.am U xforms/config/config.guess U xforms/config/config.sub U xforms/config/cygwin.m4 U xforms/config/depcomp U xforms/config/libtool.m4 U xforms/config/ltmain.sh U xforms/config/xformsinclude.m4 cvs server: Updating xforms/demos U xforms/demos/.cvsignore U xforms/demos/01Readme U xforms/demos/Makefile.am U xforms/demos/arrowbutton.c U xforms/demos/bm1.xbm U xforms/demos/bm2.xbm U xforms/demos/borderwidth.c U xforms/demos/boxtype.c U xforms/demos/browserall.c U xforms/demos/browserop.c U xforms/demos/buttonall.c U xforms/demos/butttypes.c U xforms/demos/canvas.c U xforms/demos/chartall.c U xforms/demos/chartstrip.c U xforms/demos/choice.c U xforms/demos/colbrowser.c U xforms/demos/colsel.c U xforms/demos/colsel1.c U xforms/demos/counter.c U xforms/demos/crab.xpm U xforms/demos/crab45.xpm U xforms/demos/crab_tran.xpm U xforms/demos/crossbut.c U xforms/demos/crossbut.h U xforms/demos/cursor.c U xforms/demos/demo.c U xforms/demos/demo.menu U xforms/demos/demo05.c U xforms/demos/demo06.c U xforms/demos/demo27.c U xforms/demos/demo33.c U xforms/demos/demotest.c U xforms/demos/demotest2.c U xforms/demos/demotest3.c U xforms/demos/dirlist.c U xforms/demos/fbrowse.c U xforms/demos/fbrowse1.c U xforms/demos/fdial.c U xforms/demos/flclock.c U xforms/demos/folder.c U xforms/demos/fonts.c U xforms/demos/formbrowser.c U xforms/demos/free1.c U xforms/demos/freedraw.c U xforms/demos/freedraw_leak.c U xforms/demos/gl.c U xforms/demos/glwin.c U xforms/demos/goodies.c U xforms/demos/group.c U xforms/demos/ibrowser.c U xforms/demos/iconify.c U xforms/demos/iconvert.1 U xforms/demos/iconvert.c U xforms/demos/inputall.c U xforms/demos/invslider.c U xforms/demos/itest.c U xforms/demos/lalign.c U xforms/demos/ldial.c U xforms/demos/ll.c U xforms/demos/longlabel.c U xforms/demos/menu.c U xforms/demos/menubar.c U xforms/demos/minput.c U xforms/demos/minput2.c U xforms/demos/multilabel.c U xforms/demos/ndial.c U xforms/demos/newbutton.c U xforms/demos/newmail.xbm U xforms/demos/nnn.c U xforms/demos/nomail.xbm U xforms/demos/objinactive.c U xforms/demos/objpos.c U xforms/demos/objreturn.c U xforms/demos/picture.xbm U xforms/demos/pmbrowse.c U xforms/demos/popup.c U xforms/demos/porsche.xpm U xforms/demos/positioner.c U xforms/demos/positionerXOR.c U xforms/demos/preemptive.c U xforms/demos/pup.c U xforms/demos/pushbutton.c U xforms/demos/pushme.c U xforms/demos/rescale.c U xforms/demos/scrollbar.c U xforms/demos/secretinput.c U xforms/demos/sld_radio.c U xforms/demos/sldinactive.c U xforms/demos/sldsize.c U xforms/demos/sliderall.c U xforms/demos/srs.xbm U xforms/demos/strsize.c U xforms/demos/symbols.c U xforms/demos/test.ps U xforms/demos/test.xpm U xforms/demos/thumb.c U xforms/demos/thumbwheel.c U xforms/demos/timer.c U xforms/demos/timer.h U xforms/demos/timer2.c U xforms/demos/timerprec.c U xforms/demos/touchbutton.c U xforms/demos/wwwl.c U xforms/demos/xconq.xpm U xforms/demos/xterm.xpm U xforms/demos/xyover U xforms/demos/xyplotactive.c U xforms/demos/xyplotall.c U xforms/demos/xyplotover.c U xforms/demos/yesno.c U xforms/demos/yesno_cb.c cvs server: Updating xforms/demos/fd U xforms/demos/fd/.cvsignore U xforms/demos/fd/Makefile.am U xforms/demos/fd/buttons_gui.fd U xforms/demos/fd/butttypes_gui.fd U xforms/demos/fd/dim_porsche.xpm U xforms/demos/fd/fbtest_gui.fd U xforms/demos/fd/folder_gui.fd U xforms/demos/fd/formbrowser_gui.fd U xforms/demos/fd/ibrowser_gui.fd U xforms/demos/fd/inputall_gui.fd U xforms/demos/fd/is_gui.fd U xforms/demos/fd/pmbrowse_gui.fd U xforms/demos/fd/porsche.xpm U xforms/demos/fd/scrollbar_gui.fd U xforms/demos/fd/twheel_gui.fd cvs server: Updating xforms/exports cvs server: Updating xforms/fd2ps U xforms/fd2ps/.cvsignore U xforms/fd2ps/Change U xforms/fd2ps/Makefile.am U xforms/fd2ps/Readme U xforms/fd2ps/align.c U xforms/fd2ps/fd2ps.c U xforms/fd2ps/fd2ps.h U xforms/fd2ps/fd2ps.man U xforms/fd2ps/flsupport.c U xforms/fd2ps/global.h U xforms/fd2ps/image2ps.c U xforms/fd2ps/load.c U xforms/fd2ps/papers.c U xforms/fd2ps/pscol.c U xforms/fd2ps/psdraw.c U xforms/fd2ps/psobj.c U xforms/fd2ps/pstext.c U xforms/fd2ps/readxpm.c U xforms/fd2ps/sys.c U xforms/fd2ps/version.c U xforms/fd2ps/xbmtops.c U xforms/fd2ps/xpmtops.c cvs server: Updating xforms/fd2ps/test U xforms/fd2ps/test/.cvsignore U xforms/fd2ps/test/Makefile.am U xforms/fd2ps/test/all.fd U xforms/fd2ps/test/allcmm.fd U xforms/fd2ps/test/allpoint.fd U xforms/fd2ps/test/bm1.xbm U xforms/fd2ps/test/buttons.fd U xforms/fd2ps/test/crab.xpm U xforms/fd2ps/test/dial.fd U xforms/fd2ps/test/fd_logo.xpm U xforms/fd2ps/test/folder_gui.fd U xforms/fd2ps/test/junk.fd U xforms/fd2ps/test/parameter.xpm U xforms/fd2ps/test/picture.xbm U xforms/fd2ps/test/sym.fd U xforms/fd2ps/test/xconq.xpm cvs server: Updating xforms/fdesign U xforms/fdesign/.cvsignore U xforms/fdesign/Change U xforms/fdesign/Makefile.am U xforms/fdesign/Readme U xforms/fdesign/fd_attribs.c U xforms/fdesign/fd_control.c U xforms/fdesign/fd_fake.c U xforms/fdesign/fd_file.c U xforms/fdesign/fd_forms.c U xforms/fdesign/fd_groups.c U xforms/fdesign/fd_help.c U xforms/fdesign/fd_help.h U xforms/fdesign/fd_initforms.c U xforms/fdesign/fd_main.c U xforms/fdesign/fd_main.h U xforms/fdesign/fd_names.c U xforms/fdesign/fd_objects.c U xforms/fdesign/fd_pallette.c U xforms/fdesign/fd_printC.c U xforms/fdesign/fd_rubber.c U xforms/fdesign/fd_select.c U xforms/fdesign/fd_spec.c U xforms/fdesign/fd_spec.h U xforms/fdesign/fd_super.c U xforms/fdesign/fd_util.c U xforms/fdesign/fdesign.man U xforms/fdesign/sp_browser.c U xforms/fdesign/sp_button.c U xforms/fdesign/sp_choice.c U xforms/fdesign/sp_counter.c U xforms/fdesign/sp_dial.c U xforms/fdesign/sp_freeobj.c U xforms/fdesign/sp_menu.c U xforms/fdesign/sp_pixmap.c U xforms/fdesign/sp_positioner.c U xforms/fdesign/sp_scrollbar.c U xforms/fdesign/sp_slider.c U xforms/fdesign/sp_twheel.c U xforms/fdesign/sp_xyplot.c U xforms/fdesign/viewforms.c U xforms/fdesign/viewforms.fd U xforms/fdesign/viewforms.h U xforms/fdesign/viewforms_main.c U xforms/fdesign/xpm.h cvs server: Updating xforms/fdesign/fd U xforms/fdesign/fd/.cvsignore U xforms/fdesign/fd/Makefile.am U xforms/fdesign/fd/pallette.c U xforms/fdesign/fd/pallette.fd U xforms/fdesign/fd/pallette.h U xforms/fdesign/fd/ui_attrib.c U xforms/fdesign/fd/ui_attrib.fd U xforms/fdesign/fd/ui_attrib.h U xforms/fdesign/fd/ui_objs.c U xforms/fdesign/fd/ui_objs.fd U xforms/fdesign/fd/ui_objs.h U xforms/fdesign/fd/ui_theforms.c U xforms/fdesign/fd/ui_theforms.fd U xforms/fdesign/fd/ui_theforms.h cvs server: Updating xforms/fdesign/fd4test U xforms/fdesign/fd4test/.cvsignore U xforms/fdesign/fd4test/Makefile.am U xforms/fdesign/fd4test/inittest.fd U xforms/fdesign/fd4test/testfd.fd cvs server: Updating xforms/fdesign/notes U xforms/fdesign/notes/.cvsignore U xforms/fdesign/notes/Makefile.am U xforms/fdesign/notes/spec_algo cvs server: Updating xforms/fdesign/spec U xforms/fdesign/spec/.cvsignore U xforms/fdesign/spec/Makefile.am U xforms/fdesign/spec/browser_spec.c U xforms/fdesign/spec/browser_spec.fd U xforms/fdesign/spec/browser_spec.h U xforms/fdesign/spec/button_spec.c U xforms/fdesign/spec/button_spec.fd U xforms/fdesign/spec/button_spec.h U xforms/fdesign/spec/choice_spec.c U xforms/fdesign/spec/choice_spec.fd U xforms/fdesign/spec/choice_spec.h U xforms/fdesign/spec/counter_spec.c U xforms/fdesign/spec/counter_spec.fd U xforms/fdesign/spec/counter_spec.h U xforms/fdesign/spec/dial_spec.c U xforms/fdesign/spec/dial_spec.fd U xforms/fdesign/spec/dial_spec.h U xforms/fdesign/spec/free_spec.c U xforms/fdesign/spec/free_spec.fd U xforms/fdesign/spec/free_spec.h U xforms/fdesign/spec/freeobj_spec.c U xforms/fdesign/spec/freeobj_spec.fd U xforms/fdesign/spec/freeobj_spec.h U xforms/fdesign/spec/menu_spec.c U xforms/fdesign/spec/menu_spec.fd U xforms/fdesign/spec/menu_spec.h U xforms/fdesign/spec/pixmap_spec.c U xforms/fdesign/spec/pixmap_spec.fd U xforms/fdesign/spec/pixmap_spec.h U xforms/fdesign/spec/positioner_spec.c U xforms/fdesign/spec/positioner_spec.fd U xforms/fdesign/spec/positioner_spec.h U xforms/fdesign/spec/scrollbar_spec.c U xforms/fdesign/spec/scrollbar_spec.fd U xforms/fdesign/spec/scrollbar_spec.h U xforms/fdesign/spec/slider_spec.c U xforms/fdesign/spec/slider_spec.fd U xforms/fdesign/spec/slider_spec.h U xforms/fdesign/spec/twheel_spec.c U xforms/fdesign/spec/twheel_spec.fd U xforms/fdesign/spec/twheel_spec.h U xforms/fdesign/spec/xyplot_spec.c U xforms/fdesign/spec/xyplot_spec.fd U xforms/fdesign/spec/xyplot_spec.h cvs server: Updating xforms/fdesign/xpm U xforms/fdesign/xpm/.cvsignore U xforms/fdesign/xpm/Makefile.am U xforms/fdesign/xpm/allbutton.fd U xforms/fdesign/xpm/bm1.xbm U xforms/fdesign/xpm/bottom.xbm U xforms/fdesign/xpm/box.xpm U xforms/fdesign/xpm/br.xpm U xforms/fdesign/xpm/butt.xpm U xforms/fdesign/xpm/chart.xpm U xforms/fdesign/xpm/check.xpm U xforms/fdesign/xpm/choice.fd U xforms/fdesign/xpm/choice.xpm U xforms/fdesign/xpm/clock.xpm U xforms/fdesign/xpm/cnt.xpm U xforms/fdesign/xpm/crab.xpm U xforms/fdesign/xpm/crab_focus.xpm U xforms/fdesign/xpm/dial.xpm U xforms/fdesign/xpm/fd_logo.xpm U xforms/fdesign/xpm/frame.xpm U xforms/fdesign/xpm/glcan.xpm U xforms/fdesign/xpm/hcenter.xbm U xforms/fdesign/xpm/left.xbm U xforms/fdesign/xpm/lightb.xpm U xforms/fdesign/xpm/menu.xpm U xforms/fdesign/xpm/misc.fd U xforms/fdesign/xpm/nomail.xbm U xforms/fdesign/xpm/picture.xbm U xforms/fdesign/xpm/picture1.xbm U xforms/fdesign/xpm/porsche.xpm U xforms/fdesign/xpm/pos.xpm U xforms/fdesign/xpm/r3dbut.xpm U xforms/fdesign/xpm/right.xbm U xforms/fdesign/xpm/roundb.xpm U xforms/fdesign/xpm/scb.xpm U xforms/fdesign/xpm/sld.xpm U xforms/fdesign/xpm/static.fd U xforms/fdesign/xpm/tab.xpm U xforms/fdesign/xpm/text.xpm U xforms/fdesign/xpm/timer.xpm U xforms/fdesign/xpm/top.xbm U xforms/fdesign/xpm/twheel.xpm U xforms/fdesign/xpm/val.fd U xforms/fdesign/xpm/vals.xpm U xforms/fdesign/xpm/vcenter.xbm U xforms/fdesign/xpm/xconq.xpm U xforms/fdesign/xpm/xconq1.xpm U xforms/fdesign/xpm/xyplot.xpm cvs server: Updating xforms/gl U xforms/gl/.cvsignore U xforms/gl/Makefile.am U xforms/gl/glcanvas.c U xforms/gl/glcanvas.h cvs server: Updating xforms/image U xforms/image/.cvsignore U xforms/image/Makefile.am U xforms/image/flimage.h U xforms/image/flimage_int.h U xforms/image/image.c U xforms/image/image_bmp.c U xforms/image/image_combine.c U xforms/image/image_convolve.c U xforms/image/image_crop.c U xforms/image/image_disp.c U xforms/image/image_fits.c U xforms/image/image_genesis.c U xforms/image/image_gif.c U xforms/image/image_gzip.c U xforms/image/image_io_filter.c U xforms/image/image_jpeg.c U xforms/image/image_jquant.c U xforms/image/image_marker.c U xforms/image/image_oquant.c U xforms/image/image_png.c U xforms/image/image_pnm.c U xforms/image/image_postscript.c U xforms/image/image_proc.c U xforms/image/image_replace.c U xforms/image/image_rotate.c U xforms/image/image_scale.c U xforms/image/image_sgi.c U xforms/image/image_text.c U xforms/image/image_tiff.c U xforms/image/image_type.c U xforms/image/image_warp.c U xforms/image/image_xbm.c U xforms/image/image_xpm.c U xforms/image/image_xwd.c U xforms/image/matrix.c U xforms/image/postscript.c U xforms/image/ps_core.c U xforms/image/ps_draw.c U xforms/image/ps_text.c U xforms/image/rgb_db.c cvs server: Updating xforms/lib U xforms/lib/.cvsignore U xforms/lib/Change U xforms/lib/Makefile.am U xforms/lib/align.c U xforms/lib/appwin.c U xforms/lib/asyn_io.c U xforms/lib/be.c U xforms/lib/bitmap.c U xforms/lib/box.c U xforms/lib/browser.c U xforms/lib/button.c U xforms/lib/canvas.c U xforms/lib/chart.c U xforms/lib/checkbut.c U xforms/lib/child.c U xforms/lib/choice.c U xforms/lib/clipboard.c U xforms/lib/clock.c U xforms/lib/cmd_br.c U xforms/lib/colsel.c U xforms/lib/combo.c U xforms/lib/counter.c U xforms/lib/cursor.c U xforms/lib/dial.c U xforms/lib/dirent_vms.h U xforms/lib/display.c U xforms/lib/dmalloc.h U xforms/lib/errmsg.c U xforms/lib/events.c U xforms/lib/extern.h U xforms/lib/flcolor.c U xforms/lib/fldraw.c U xforms/lib/flinternal.h U xforms/lib/flresource.c U xforms/lib/flsnprintf.c U xforms/lib/flvisual.c U xforms/lib/fonts.c U xforms/lib/formbrowser.c U xforms/lib/forms.c U xforms/lib/frame.c U xforms/lib/free.c U xforms/lib/fselect.c U xforms/lib/global.h U xforms/lib/goodie_alert.c U xforms/lib/goodie_choice.c U xforms/lib/goodie_input.c U xforms/lib/goodie_msg.c U xforms/lib/goodie_salert.c U xforms/lib/goodie_sinput.c U xforms/lib/goodie_yesno.c U xforms/lib/goodies.c U xforms/lib/input.c U xforms/lib/interpol.c U xforms/lib/keyboard.c U xforms/lib/labelbut.c U xforms/lib/lframe.c U xforms/lib/lightbut.c U xforms/lib/listdir.c U xforms/lib/local.h U xforms/lib/menu.c U xforms/lib/n2a.c U xforms/lib/objects.c U xforms/lib/oneliner.c U xforms/lib/pixmap.c U xforms/lib/positioner.c U xforms/lib/read2lsbf.c U xforms/lib/read2msbf.c U xforms/lib/read4lsb.c U xforms/lib/read4msb.c U xforms/lib/readint.c U xforms/lib/round3d.c U xforms/lib/roundbut.c U xforms/lib/scrollbar.c U xforms/lib/scrollbut.c U xforms/lib/signal.c U xforms/lib/simu.c U xforms/lib/sldraw.c U xforms/lib/slider.c U xforms/lib/space.c U xforms/lib/spline.c U xforms/lib/strdup.c U xforms/lib/symbols.c U xforms/lib/sysdep.c U xforms/lib/tabfolder.c U xforms/lib/text.c U xforms/lib/textbox.c U xforms/lib/thumbwheel.c U xforms/lib/timeout.c U xforms/lib/timer.c U xforms/lib/tooltip.c U xforms/lib/ulib.h U xforms/lib/util.c U xforms/lib/valuator.c U xforms/lib/version.c U xforms/lib/vms_readdir.c U xforms/lib/vn_pair.c U xforms/lib/vstrcat.c U xforms/lib/win.c U xforms/lib/xdraw.c U xforms/lib/xforms.man U xforms/lib/xpopup.c U xforms/lib/xsupport.c U xforms/lib/xtext.c U xforms/lib/xyplot.c cvs server: Updating xforms/lib/OS2 cvs server: Updating xforms/lib/bitmaps U xforms/lib/bitmaps/.cvsignore U xforms/lib/bitmaps/Makefile.am U xforms/lib/bitmaps/plaid.xpm U xforms/lib/bitmaps/q.xbm U xforms/lib/bitmaps/warn.xbm cvs server: Updating xforms/lib/fd U xforms/lib/fd/.cvsignore U xforms/lib/fd/Makefile.am U xforms/lib/fd/cmdbr.c U xforms/lib/fd/cmdbr.fd U xforms/lib/fd/cmdbr.h U xforms/lib/fd/ginput.c U xforms/lib/fd/ginput.fd U xforms/lib/fd/ginput.h U xforms/lib/fd/micntl.c U xforms/lib/fd/micntl.fd U xforms/lib/fd/micntl.h cvs server: Updating xforms/lib/include U xforms/lib/include/.cvsignore U xforms/lib/include/AAA.h.in U xforms/lib/include/Basic.h U xforms/lib/include/Makefile.am U xforms/lib/include/XBasic.h U xforms/lib/include/bitmap.h U xforms/lib/include/box.h U xforms/lib/include/browser.h U xforms/lib/include/button.h U xforms/lib/include/canvas.h U xforms/lib/include/chart.h U xforms/lib/include/choice.h U xforms/lib/include/clipbd.h U xforms/lib/include/clock.h U xforms/lib/include/counter.h U xforms/lib/include/cursor.h U xforms/lib/include/dial.h U xforms/lib/include/filesys.h U xforms/lib/include/flps.h U xforms/lib/include/formbrowser.h U xforms/lib/include/frame.h U xforms/lib/include/free.h U xforms/lib/include/goodies.h U xforms/lib/include/input.h U xforms/lib/include/menu.h U xforms/lib/include/menubar.h U xforms/lib/include/popup.h U xforms/lib/include/positioner.h U xforms/lib/include/scrollbar.h U xforms/lib/include/slider.h U xforms/lib/include/tabfolder.h U xforms/lib/include/text.h U xforms/lib/include/thumbwheel.h U xforms/lib/include/timer.h U xforms/lib/include/xyplot.h U xforms/lib/include/zzz.h cvs server: Updating xforms/lib/private U xforms/lib/private/.cvsignore U xforms/lib/private/Makefile.am U xforms/lib/private/flsnprintf.h U xforms/lib/private/pbrowser.h U xforms/lib/private/pcanvas.h U xforms/lib/private/pchoice.h U xforms/lib/private/pcounter.h U xforms/lib/private/pdial.h U xforms/lib/private/pflps.h U xforms/lib/private/pformbrowser.h U xforms/lib/private/pmenu.h U xforms/lib/private/ppositioner.h U xforms/lib/private/pscrollbar.h U xforms/lib/private/pslider.h U xforms/lib/private/ptextbox.h U xforms/lib/private/ptwheel.h U xforms/lib/private/pvaluator.h U xforms/lib/private/pxyplot.h U xforms/lib/private/textbox.h cvs server: Updating xforms/snp cvs server: Updating xforms/snp/sparc-sun-sunos Using autoconf (GNU Autoconf) 2.58 Generate acinclude.m4... done. Building macros... . done. Building config header template... . /usr/bin/m4: configure.in: No such file or directory done. Building Makefile templates... . automake: configure.ac: installing `config/install-sh' automake: configure.ac: installing `config/mkinstalldirs' automake: configure.ac: installing `config/missing' configure.ac: 6: required file `./[lib/config.h].in' not found configure.ac: 6: required file `./[lib/stamp-h.in' not found lib/include/Makefile.am:3: invalid variable `nodist_include_HEADERS' fdesign/Makefile.am:19: variable `LIBS' not defined fd2ps/Makefile.am:19: variable `LIBS' not defined demos/Makefile.am:168: variable `LIBS' not defined demos/Makefile.am:172: variable `LIBS' not defined demos/Makefile.am:180: variable `LIBS' not defined demos/Makefile.am:187: variable `LIBS' not defined demos/Makefile.am:199: variable `LIBS' not defined demos/Makefile.am:207: variable `LIBS' not defined demos/Makefile.am:260: variable `LIBS' not defined demos/Makefile.am:225: invalid unused variable name: `nodist_pmbrowse_SOURCES' demos/Makefile.am:160: invalid unused variable name: `nodist_formbrowser_SOURCES' demos/Makefile.am:192: invalid unused variable name: `nodist_inputall_SOURCES' demos/Makefile.am:250: invalid unused variable name: `nodist_thumbwheel_SOURCES'demos/Makefile.am:154: invalid unused variable name: `nodist_folder_SOURCES' demos/Makefile.am:238: invalid unused variable name: `nodist_scrollbar_SOURCES' demos/Makefile.am:138: invalid unused variable name: `nodist_demotest_SOURCES' demos/Makefile.am:145: invalid unused variable name: `nodist_dirlist_SOURCES' demos/Makefile.am:115: invalid unused variable name: `nodist_buttonall_SOURCES' demos/Makefile.am:106: invalid unused variable name: `AM_LDFLAGS' demos/Makefile.am:119: invalid unused variable name: `nodist_butttypes_SOURCES' done. Building configure... . done. run "./configure ; make" From mheffner at vt.edu Tue Dec 2 19:16:15 2003 From: mheffner at vt.edu (Mike Heffner) Date: Tue Dec 2 19:16:36 2003 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <20031119105606.GA1903@astrouw.edu.pl> Message-ID: Michal, Try the attached patch. This appears to work and is much simpler than the current version, but I'll have to look further into the xforms event handling code to see whether this causes a race condition. Anyone know? Mike On 19-Nov-2003 Michal Szymanski wrote: | To subscribers of the xforms list | | | Hi XFormers, | | I'd like to know what the current status of "file selector double-click" | bug is? There were a couple of messages regarding this in May, starting | with a patch proposed by Mike Heffner, but the discussion that followed | raised some doubts. It ended with following message from Mike: | |> However, we still have the same problem that the callback is never |> getting |> a ButtonPress event. ;-( |> |> This weekend I'll try rewriting the file selector's callback using the |> fl_set_browser_dblclick_callback(). It seems that might be a much |> easier |> way of approaching this. | | Mike, did you try the rewrite? | | If no, is Mike's patch included in any (CVS maybe) version of code? | | I have some heavily-used XForms apps dating back to ver. 0.88 and I'd | like very much to rebuild them with 1.0 (also because of problems with | static libraries under RedHat 9) but all users here are quite used to | double-clicking in file selector. The problems started already in 0.89 | and, sadly, have propagated into 1.0. | | regards, Michal. | -- Mike Heffner -------------- next part -------------- --- lib/fselect.c Sat Jun 1 18:09:38 2002 +++ /home/spock/fselect.c Tue Dec 2 19:06:46 2003 @@ -308,24 +308,18 @@ } return 0; } + #else -/* - * A file is selected from the browser. - * generate ready if valid selection (e.g. double-clicked) - * Note that if a call back is defined, never generate ready - */ + static void -select_cb(FL_OBJECT * ob, long arg) +select_cb(FL_OBJECT *ob, long isdblclick) { int dir; char seltext[FL_PATH_MAX]; - static int lastline = -1, clicked; - int dblclick, thisline; + int thisline; FD_fselect *lfs = ob->form->fdui; - const XEvent *xev = fl_last_event(); thisline = fl_get_browser(ob); - if (thisline <= 0) return; @@ -335,31 +329,9 @@ strcpy(seltext, seltext + 2); - dblclick = (lastline == thisline && clicked && - fl_time_passed(FL_FS_T) < ob->click_timeout * 0.001f); - - lastline = thisline; - - clicked = (clicked || xev->type == ButtonPress); - - /* cursor keys can cause a single line being repeatedly selected - causing a wrong dblclick detection */ - - if (clicked) - { - if (xev->type == KeyPress || xev->type == KeyRelease) - { - dblclick = 0; - clicked = 0; - lastline = -1; - } - } - - fl_reset_time(FL_FS_T); - if (dir) { - if (dblclick) + if (isdblclick) { strcat(append_slash(lfs->dname), seltext); fl_fix_dirname(lfs->dname); @@ -374,7 +346,7 @@ fl_set_input(lfs->input, seltext); strcpy(lfs->filename, seltext); - if (dblclick) + if (isdblclick) { if (lfs->fselect_cb) { @@ -385,7 +357,6 @@ fl_object_qenter(lfs->ready); } } - return; } #endif @@ -964,6 +935,7 @@ fs->browser = obj = fl_add_browser(FL_HOLD_BROWSER, 15, 80, 185, 180, ""); #if ATTACHABLE fl_set_object_callback(obj, select_cb, 0); + fl_set_browser_dblclick_callback(obj, select_cb, 1); #endif fl_set_object_gravity(obj, NorthWestGravity, SouthEastGravity); obj->click_timeout = FL_CLICK_TIMEOUT; From Jean-Marc.Lasgouttes at inria.fr Wed Dec 3 12:12:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Dec 3 06:12:26 2003 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: (Angus Leeming's message of "Tue, 02 Dec 2003 20:02:26 -0500") References: Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> CVSROOT: /cvsroot/xforms Module name: xforms Branch: Changes Angus> by: Angus Leeming 03/12/02 Angus> 20:02:26 Angus> Modified files: . : ChangeLog demos : Makefile.am lib/include : Angus> Makefile.am Angus> Log message: Some subtle little fixes needed to get things Angus> working on non-gnu platforms. - sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ + sed "1,/crop here for forms/d" ${srcdir}/`basename $$i` >> tmpforms; \ an you explain briefly what this does? JMarc From angus.leeming at btopenworld.com Wed Dec 3 11:25:53 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Dec 3 06:25:55 2003 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: References: Message-ID: <200312031125.53040.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 11:12 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > Angus> CVSROOT: /cvsroot/xforms Module name: xforms Branch: Changes > Angus> by: Angus Leeming 03/12/02 > Angus> 20:02:26 > > Angus> Modified files: . : ChangeLog demos : Makefile.am lib/include : > Angus> Makefile.am > > Angus> Log message: Some subtle little fixes needed to get things > Angus> working on non-gnu platforms. > > - sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ > + sed "1,/crop here for forms/d" ${srcdir}/`basename $$i` >> tmpforms; \ > > an you explain briefly what this does? You mean the change? I'm trying to overcome a problem compiling with Dec's make and with srcdir != builddir. This snippet in Makefile.am (ie the original snippet): for i in $(noinst_HEADERS); do \ sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ done Is expanded by Dec's make to: for i in ../../../lib/include/Basic.h ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h ../../../lib/include/box.h [snip file list]; do sed "1,/crop here for forms/d" ../../../lib/include/$i >> tmpforms; done sed: Cannot find or open file ../../../lib/include/../../../lib/include/Basic.h. Doing the same thing with gnu make: for i in Basic.h XBasic.h bitmap.h box.h browser.h button.h canvas.h chart.h choice.h clipbd.h clock.h counter.h cursor.h dial.h filesys.h flps.h formbrowser.h frame.h free.h goodies.h input.h menu.h menubar.h popup.h positioner.h scrollbar.h slider.h tabfolder.h text.h thumbwheel.h timer.h xyplot.h zzz.h; do \ sed "1,/crop here for forms/d" ../../../lib/include/$i >> tmpforms; \ done You see the problem? One make gives the files their full path and the other doesn't. The trick, therefore, is to use only the filename part. Any better ideas? Angus From Jean-Marc.Lasgouttes at inria.fr Wed Dec 3 12:41:15 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Dec 3 06:41:24 2003 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: <200312031125.53040.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 3 Dec 2003 11:25:53 +0000") References: <200312031125.53040.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> You mean the change? I'm trying to overcome a problem compiling Angus> with Dec's make and with srcdir != builddir. This snippet in Angus> Makefile.am (ie the original snippet): Angus> for i in $(noinst_HEADERS); do \ sed "1,/crop here for Angus> forms/d" ${srcdir}/$$i >> tmpforms; \ done Angus> Is expanded by Dec's make to: Angus> for i in ../../../lib/include/Basic.h Angus> ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h Angus> ../../../lib/include/box.h [snip file list]; do sed "1,/crop Angus> here for forms/d" ../../../lib/include/$i >> tmpforms; done I am surprised, since in my Makefile.in noinst_HEADER is noinst_HEADERS = \ Basic.h \ XBasic.h \ bitmap.h \ box.h \ ... Is it different in the Makefile.in on your dec? This would mean a problem with automake, not with the version of make... JMarc From angus.leeming at btopenworld.com Wed Dec 3 12:01:18 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Dec 3 07:01:43 2003 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: References: <200312031125.53040.angus.leeming@btopenworld.com> Message-ID: <200312031201.18373.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 11:41 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> You mean the change? I'm trying to overcome a problem compiling > Angus> with Dec's make and with srcdir != builddir. This snippet in > Angus> Makefile.am (ie the original snippet): > > Angus> for i in $(noinst_HEADERS); do \ sed "1,/crop here for > Angus> forms/d" ${srcdir}/$$i >> tmpforms; \ done > > Angus> Is expanded by Dec's make to: > > Angus> for i in ../../../lib/include/Basic.h > Angus> ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h > Angus> ../../../lib/include/box.h [snip file list]; do sed "1,/crop > Angus> here for forms/d" ../../../lib/include/$i >> tmpforms; done > > I am surprised, since in my Makefile.in noinst_HEADER is > noinst_HEADERS = \ > Basic.h \ > XBasic.h \ > bitmap.h \ > box.h \ > ... > > Is it different in the Makefile.in on your dec? Nope. It's the same (also in Makefile itself). The relevant part of the generated Makefile appears to be: distdir: $(DISTFILES) @list='$(DISTFILES)'; for file in $$list; do \ Ie, the answer lies in the definition of $(DISTFILES) DIST_COMMON = $(noinst_HEADERS) AAA.h.in Makefile.am Makefile.in DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) It appears that Dec make does something weird when expanding $(noinst_HEADERS). Angus k From angus.leeming at btopenworld.com Wed Dec 3 12:38:54 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Dec 3 07:39:15 2003 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: Message-ID: <200312031238.54118.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 12:16 am, Mike Heffner wrote: > To subscribers of the xforms list > Try the attached patch. This appears to work and is much > simpler than the current version, but I'll have to look further > into the xforms event handling code to see whether this causes > a race condition. Anyone know? Oohhh! I like this kind of patch ;-) What sort of problems are you tinking about? Angus From mheffner at vt.edu Wed Dec 3 09:45:47 2003 From: mheffner at vt.edu (Mike Heffner) Date: Wed Dec 3 09:46:10 2003 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <200312031238.54118.angus.leeming@btopenworld.com> Message-ID: On 03-Dec-2003 Angus Leeming wrote: | | | On Wednesday 03 December 2003 12:16 am, Mike Heffner wrote: | |> Try the attached patch. This appears to work and is much |> simpler than the current version, but I'll have to look further |> into the xforms event handling code to see whether this causes |> a race condition. Anyone know? | | Oohhh! I like this kind of patch ;-) | | What sort of problems are you tinking about? | Well, the patch adds two callbacks for the browser object in the file selector: fl_set_object_callback(obj, select_cb, 0); + fl_set_browser_dblclick_callback(obj, select_cb, 1); On a double click we'll want the first call back (single click) to always be called first, (possibly two times, once for each click), then the double click callback to be called. However, if it happened the other way around it might do something weird like select a file in the list right after moving to a new directory. The question is, is there a race condition here that we should handle better, or just depend on the callback's be called in the correct order? Actually though, now that I look at it more closely, even if the single click callback is called after the double click, it will most likely be invalidated. Once we've double clicked and entered a new directory there shouldn't be anything selected so the test against fl_get_browser()>0 at the beginning of the callback would fail and the callback would do nothing. Mike -- Mike Heffner From joel at fc.hp.com Tue Dec 9 09:52:03 2003 From: joel at fc.hp.com (Joel Lefebvre) Date: Tue Dec 9 11:52:09 2003 Subject: [XForms] savannah down? Message-ID: <3FD5FDB3.2050003@fc.hp.com> I'm trying to get the latest Xforms from savannah.nongnu.org but it seems to be down. Anyone know if savannah is having a problem? Is there an alternate source for Xforms? Thanks Joel -- ------------------------------------------------------------ Joel Lefebvre joel@fc.hp.com Hewlett Packard 970-898-7970 All opinions expressed are my own and do not necessarily represent those of Hewlett Packard. ------------------------------------------------------------ From Jean-Marc.Lasgouttes at inria.fr Wed Dec 10 11:39:18 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Dec 10 05:49:16 2003 Subject: [XForms] savannah down? In-Reply-To: <3FD5FDB3.2050003@fc.hp.com> (Joel Lefebvre's message of "Tue, 09 Dec 2003 09:52:03 -0700") References: <3FD5FDB3.2050003@fc.hp.com> Message-ID: >>>>> "Joel" == Joel Lefebvre writes: Joel> To subscribers of the xforms list I'm trying to get the latest Joel> Xforms from savannah.nongnu.org but it seems to be down. Anyone Joel> know if savannah is having a problem? Is there an alternate Joel> source for Xforms? Hello, Savannah has been hacked recently, and the site has been closed until they manage to restore everything: http://savannah.gnu.org/statement.html What version of xforms are you looking for? JMarc From bob at bob.usuhs.mil Thu Jun 12 15:25:54 2003 From: bob at bob.usuhs.mil (Robert Williams) Date: Thu, 12 Jun 2003 15:25:54 -0400 Subject: [XForms] New xforms list server Message-ID: <3EE8D3C2.8050003@bob.usuhs.mil> I've finally moved the xforms list to a fast machine running mailman. There may be a few adjustments that I have to make, but if you recieve this, it appears to work. Bob Williams xforms list maintainer From lahaye at users.sourceforge.net Thu Jun 12 19:56:37 2003 From: lahaye at users.sourceforge.net (Rob Lahaye) Date: Fri, 13 Jun 2003 08:56:37 +0900 Subject: [XForms] Re: New xforms list server In-Reply-To: <3EE8D3C2.8050003@bob.usuhs.mil> References: <3EE8D3C2.8050003@bob.usuhs.mil> Message-ID: <3EE91335.6030403@users.sourceforge.net> Robert Williams wrote: > > To subscribers of the xforms list > > > I've finally moved the xforms list to > a fast machine running mailman. There may > be a few adjustments that I have to make, > but if you recieve this, it appears to work. > > Bob Williams > xforms list maintainer Notice that the 2002 archive still collects current messages; and we are already half way 2003! Can you break it up and add the 2003 messages to a new 2003 tree ? Regards, Rob. From ldm at risc4.numis.nwu.edu Mon Jun 16 09:21:42 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Mon, 16 Jun 2003 08:21:42 -0500 (CDT) Subject: [XForms] Libraries, configure etc Message-ID: Two questions: Do the compiled libraries exist anywhere, or have they now gone. Has anyone converted to Imake structure to a configure (i.e. autoconf/automake) one? I am not that familiar with image, but know that configure can be arranged to determine enough about the system to make compilation seamless. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From angus.leeming at btopenworld.com Mon Jun 16 20:17:39 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 17 Jun 2003 00:17:39 +0000 Subject: [XForms] Libraries, configure etc In-Reply-To: References: Message-ID: <200306170017.39950.angus.leeming@btopenworld.com> On Monday 16 June 2003 11:12 pm, you wrote: > We are about to release some code which uses libforms. > If a tgz file is available with a standard configure, > we can use this otherwise we may need to write our > way around including libforms. Can you make one > available? Why not grab a copy of the cvs repository, following the instructions on the web page I posted to you and thereafter: $ ./autogen.sh $ ./configure your_options $ make dist which should generate your desired tar.gz file. Regards, Angus From nicolas.castagne at imag.fr Wed Jun 18 07:54:15 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Wed, 18 Jun 2003 13:54:15 +0200 Subject: [XForms] Threads and OpenGL --- again ! ;-) Message-ID: <958998B0-A183-11D7-B36A-000393C76CA6@imag.fr> Hi all, I have worked again a bit on a small demo program running a gl CANVAS drawn through a THREAD. You will find attached the sources. ----- I - description of the program The code assumes: 1) that each thread has its own current GLXContext 2) that concurrent calls to glXMakeCurrent and glXSwapBuffer can be made, provided the context used for each one is possessed by the calling thread. The program shows in a form two canvas with a rotating cube. The main process creates and display the form. The "MainCanvas" and its GLXcontext are created by the Main Proces. The "MainCanvas" drawn through an idle callback. The ThreadCanvas is created by the Thread and drawn by it. Its GLXcontext is also created by the thread, through the call to fl_add_object(Form, ThreadCanvas). A communication process ensures that Expose Events on the "ThreadCanvas" (handled by the XForms main loop in the Main Process) are communicated to the Thread. As an evidence, this communication process could be improved. However, it is not the problem today. ----- II - results and problem When rendering is made in DIRECT mode, every thing runs correctly on every SGI engine I was able to test. The call to XinitThread() even does not seem to be necessary. On the contrary, the program ALWAYS CRASHES when rendering is made through the X Server. This happens in two cases: 1) when the constant DIRECT, at the beginning of the sources, is set to 0; 2) when distant execution is performed (direct rendering is then impossible). The error messages I get from the X server are various. Mainly : X Error of failed request: GLXBadContextTag Major opcode of failed request: 146 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 667 Current serial number in output stream: 681 or : X Error of failed request: GLXBadContextTag Major opcode of failed request: 146 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 651 Current serial number in output stream: 656 Note that the GLXBadContextTag error is not well documented. As an example, it does not appear in the GL man pages. I don't really understand what it means. ----- II - help ! ;-) I have worked quite a lot around the problem, trying various solutions... But without success. It would be really helpful if one of you could have a look on the problem: Numerous mails concerning threads and GLcanvas have been posted for the past years on the list, but never a definitive answer. As a matter of fact, it could be of interest to : 1) propose a valid small demo program within the XForms examples. 2) by the end, add to the library an API for threaded Gl canvas. I may work on these points... But i need help today ! You may help in different ways : 1) trying to compile and run my program on other platforms, to see what happens; 2) debugging my program, showing what is wrong; 2) sending other pieces of code with threaded Glcanvas that run properly, what ever the rendering mode is, so that I could make the previous jobs on my own. Thx in advance ! Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadGL.c Type: application/applefile Size: 70 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030618/b8eff1b5/attachment.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadGL.c Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030618/b8eff1b5/attachment.c -------------- next part -------------- ------------------------------------------------------------------------ -------------------------- Nicolas CASTAGNE Chercheur, IR de l'ACROE/ICA, Association pour la Cr?ation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Cr?ation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------ -------------------------- From ldm at risc4.numis.nwu.edu Mon Jun 16 19:19:49 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Mon, 16 Jun 2003 18:19:49 -0500 (CDT) Subject: [XForms] Libraries, configure etc In-Reply-To: <200306170017.39950.angus.leeming@btopenworld.com> Message-ID: I will....if I have time before I leave on Saturday to teach at a school in Moscow where I will be using the software On Tue, 17 Jun 2003, Angus Leeming wrote: > On Monday 16 June 2003 11:12 pm, you wrote: > > We are about to release some code which uses libforms. > > If a tgz file is available with a standard configure, > > we can use this otherwise we may need to write our > > way around including libforms. Can you make one > > available? > > Why not grab a copy of the cvs repository, following the instructions on the > web page I posted to you and thereafter: > > $ ./autogen.sh > $ ./configure your_options > $ make dist > > which should generate your desired tar.gz file. > > Regards, > Angus > > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From nicolas.castagne at imag.fr Thu Jun 19 12:05:22 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Thu, 19 Jun 2003 18:05:22 +0200 Subject: [XForms] Formbrowser : adjusting the size of the forms Message-ID: Hy all ! As you know, formbrowsers may need some improvments. For example, an adjustement of the vertical scrollbar (position, size) is needed in case of a call to fl_set_form_size() on one of the forms added to the formbrowser. Does any one actually work on this question ? Shall I have a look on it ? Who could answer to some question I have concerning the best way to solve these problems ? Thx, Nicolas From Mickael.Le.Coz at ifremer.fr Fri Jun 27 04:45:14 2003 From: Mickael.Le.Coz at ifremer.fr (Mickael LE COZ) Date: Fri, 27 Jun 2003 10:45:14 +0200 Subject: [XForms] installation on cygwin emulator Message-ID: <3EFC041A.D4C30C0F@ifremer.fr> Hello, I have untar the "xforms-1.0.tar.gz" file in he X11r6 directory; So when I type ,in the Cygwin/XFree86 rl : xmkmkf >> mv -f Makefile Makefile.bak >>imake -DUseInstalled -I/usr/X11R6/lib/X11/config >>/tmp/IIf.004357:92: unterminated #if conditional >>imake: Exit code 1. >> Stop. and when I type : make Makefiles or make install >>Makefile:11: *** missing operator. Stop Here is the Makefile: # 1 "Imakefile.c" # 1 "/usr/X11R6/lib/X11/config/Imake.tmpl" 1 XCOMM ---------------------------------------------------------------------- XCOMM Makefile generated from "Imake.tmpl" and XCOMM $Xorg: Imake.tmpl,v 1.4 2000/08/17 19:41:46 cpqbld Exp $ XCOMM XCOMM XCOMM XCOMM XCOMM $XFree86: xc/config/cf/Imake.tmpl,v 3.114 2001/11/08 02:09:06 tsi Exp $ XCOMM ---------------------------------------------------------------------- What is the problem? thank you for your help, Micka?l. From nicolas.castagne at imag.fr Fri Jun 27 09:55:13 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 15:55:13 +0200 Subject: [XForms] OpenGL and Threads- again Message-ID: This mail is addressed to those that use OpenGL within XForms. I have had no answer concerning my last message, but I really think the subject of threads and openGL is of interest for the XForms community..... My aim concerning this question is to add a small demo to the XForms demo programs. So, let's play again ! ------- You will find enclosed a short program which implements a GLCanvas drawn by a thread. This program is stable with direct rendering. However, it is not stable on my IRIX system in case of rendering through the X sever, especially in case of a distant execution. -> Could some of you try to compile this program and run it locally and on a distant machine ? 10 min. work ! ------- The next part of the message is addressed to those who have successfully implemented a GLCanvas drawn by a thread. Did you tried non-direct rendering on these canvas ? If it runs properly, it would be very helpful if you could have a look to my code and give advices ! Thx , Nicolas From nicolas.castagne at imag.fr Fri Jun 27 10:36:55 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 16:36:55 +0200 Subject: [XForms] OpenGL and Threads- again In-Reply-To: Message-ID: Sure it is better with the attachement... Thx for testing ! Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadGL.c Type: application/applefile Size: 70 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030627/30e85acb/attachment.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadGL.c Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030627/30e85acb/attachment.c -------------- next part -------------- Le vendredi, 27 jun 2003, ? 15:55 Europe/Paris, Nicolas Castagn? a ?crit : > To subscribers of the xforms list > > > This mail is addressed to those that use OpenGL within XForms. > > I have had no answer concerning my last message, but I really think > the subject of threads and openGL is of interest for the XForms > community..... > My aim concerning this question is to add a small demo to the XForms > demo programs. > > So, let's play again ! > > ------- > > You will find enclosed a short program which implements a GLCanvas > drawn by a thread. > > This program is stable with direct rendering. However, it is not > stable on my IRIX system in case of rendering through the X sever, > especially in case of a distant execution. > > -> Could some of you try to compile this program and run it locally > and on a distant machine ? 10 min. work ! > > ------- > > The next part of the message is addressed to those who have > successfully implemented a GLCanvas drawn by a thread. > > Did you tried non-direct rendering on these canvas ? > If it runs properly, it would be very helpful if you could have a > look to my code and give advices ! > > > Thx , > > Nicolas > > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > From Jean-Marc.Lasgouttes at inria.fr Fri Jun 27 10:46:14 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 27 Jun 2003 16:46:14 +0200 Subject: [XForms] installation on cygwin emulator In-Reply-To: <3EFC041A.D4C30C0F@ifremer.fr> (Mickael LE's message of "Fri, 27 Jun 2003 10:45:14 +0200") References: <3EFC041A.D4C30C0F@ifremer.fr> Message-ID: >>>>> "Mickael" == Mickael LE COZ writes: Mickael> To subscribers of the xforms list Hello, Mickael> I have untar the "xforms-1.0.tar.gz" file in he X11r6 Mickael> directory; So when I type ,in the Cygwin/XFree86 rl : xmkmkf Did you try 'xmkmf -a'? JMarc From nicolas.castagne at imag.fr Fri Jun 27 14:57:00 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 20:57:00 +0200 Subject: Fwd: [XForms] OpenGL and Threads- again Message-ID: <220DA38B-A8D1-11D7-8814-000393C76CA6@imag.fr> Hi all, Thx for trying David. I decided to fwd your mail on the mail list (see below), since it may be of interest for other. The behaviour you obtained is somehow the one I get on octane - appart the fact SGi octane is a bit slower ;-) The questions then are : 1) is multithreading correctly supported by OpenGL in case of non-direct rendering ? 2) if so, where is the fault in my program ? Wish some of you may answer ! Once again, I would ask those who have already implemented a 'multithreaded' GL canvas under XForms to test their program with non-direct rendering (Canvas's direct field set to 0 or distant execution). Thx, Nicolas D?but du message r?exp?di? : > De: David Scriven > Date: Ven 27 jun 2003 20:42:26 Europe/Paris > ?: "Nicolas_Castagn?" > Objet: R?p : [XForms] OpenGL and Threads- again > > Hi Nicolas, > > I tried your program on a platform running RedHat 9 with XFree86 4.3.0 > on an NVIDIA Ti 4200 (NVIDIA supply their own drivers and GL libraries) > > 1. With DIRECT = 1 the program ran fine although the rate in the > left hand window was so fast that the cube was blurred. The rate > in the right window was much slower. > > 2. With DIRECT = 0 the program still worked, BUT, the program would > not respond to the buttons once Go! was pressed and the cube on > the right did not move. In addition, when I covered and then uncovered > the window, the right hand screen was not redrawn (ie it remained > black). In addition I got messages like: > Xlib: unexpected async reply (sequence 0x288ad)! > > 3,. In light of the above I didn't try remote execution. > > I compiled the program with > > gcc ThreadGL.c -o ThreadGL -I /usr/X11R6/include -O2 -L/usr/X11R6/lib > -lforms -lformsGL -lpthread -lGL -lGLU > > using gcc ver 3.2.2 > > I'll try and look through your code this weekend if I get a chance. > > DS > > : > To subscribers of the xforms list >> >> >> This mail is addressed to those that use OpenGL within XForms. >> >> I have had no answer concerning my last message, but I really think >> the subject of threads and openGL is of interest for the XForms >> community..... >> My aim concerning this question is to add a small demo to the XForms >> >> demo programs. >> >> So, let's play again ! >> >> ------- >> >> You will find enclosed a short program which implements a GLCanvas >> drawn by a thread. >> >> This program is stable with direct rendering. However, it is not >> stable on my IRIX system in case of rendering through the X sever, >> especially in case of a distant execution. >> >> -> Could some of you try to compile this program and run it locally >> and on a distant machine ? 10 min. work ! >> >> ------- >> >> The next part of the message is addressed to those who have >> successfully implemented a GLCanvas drawn by a thread. >> >> Did you tried non-direct rendering on these canvas ? >> If it runs properly, it would be very helpful if you could have a >> look >> to my code and give advices ! >> >> >> Thx , >> >> Nicolas >> >> >> _______________________________________________ >> To unsubscribe, send the message "unsubscribe" to >> xforms-request at bob.usuhs.mil or see: >> http://cweblog.usuhs.mil/mailman/listinfo/xforms >> XForms Home Page: http://world.std.com/~xforms >> List Archive: http://bob.usuhs.mil/pipermail/xforms and >> http://bob.usuhs.mil/mailserv/list-archives/ >> Development: http://savannah.nongnu.org/files/?group=xforms > > ______________________________________________________________________ > Post your free ad now! http://personals.yahoo.ca > From ddembrow at nlxcorp.com Mon Jun 30 15:43:39 2003 From: ddembrow at nlxcorp.com (ddembrow at nlxcorp.com) Date: Mon, 30 Jun 2003 15:43:39 -0400 Subject: [XForms] Next xforms release inquiry Message-ID: Are there any plans to release another version of xforms including the latest modifications as a stable release beyond 1.0 rc5? From Jean-Marc.Lasgouttes at inria.fr Tue Jul 1 04:24:21 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 01 Jul 2003 10:24:21 +0200 Subject: [XForms] Next xforms release inquiry In-Reply-To: (ddembrow@nlxcorp.com's message of "Mon, 30 Jun 2003 15:43:39 -0400") References: Message-ID: >>>>> "ddembrow" == ddembrow writes: ddembrow> Are there any plans to ddembrow> release another version of xforms including the latest ddembrow> modifications as a stable release beyond 1.0 rc5? The latest released version is actually 1.0, available here https://savannah.nongnu.org/files/?group=xforms In the cvs available from there https://savannah.nongnu.org/cvs/?group=xforms you will find what is going to become 1.1.0. It contains several bug fixes, and support for autoconf-based build. This is the part that is not finished yet. Hope this helps. JMarc From davidwriter at yahoo.com Sun Jul 6 17:00:08 2003 From: davidwriter at yahoo.com (David Scriven) Date: Sun, 6 Jul 2003 17:00:08 -0400 (EDT) Subject: [XForms] Timing in XForms In-Reply-To: <200306070213.h572D0004065@pc18.math.umbc.edu> Message-ID: <20030706210008.99028.qmail@web41213.mail.yahoo.com> When XForms was originally developed, in the mid 1980's, machines were much slower than they are today, so I suspect the designers had to make a compromise between CPU cycles and response. In XForms there are two critical values that are set : TIMER_RES, which is 50 ms (and can be partly reset by fl_set_idle_delta), and the number of FL_STEP events that are swallowed before the system responds (l 1977-78 of forms.c) /* Handle FL_STEP. Every 10 events. This will reduce cpu usage */ if ((++auto_cnt % 10) == 0) This latter statement clearly will slow down the way in which XForms responds and probably explains the effect I have noticed on my machines; that XForms programs speed up when the mouse is moved. My query is whether the settings in XForms are appropriate to today's fast machines and whether these settings could be dynamically changed to suit the machine that XForms is running on. What I would have in mind is a routine inside fl_initialize that detects the real clock precision and clock speed and sets the values for TIMER_RES, and steps swallowed, dynamically. XForms is extremely complex and such changes might have unforseen side effects (T.C., your comments?), but I think it might be worth thinking about. DS ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From jac at casurgica.com Thu Jul 10 23:33:25 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Thu, 10 Jul 2003 23:33:25 -0400 (EDT) Subject: [XForms] fl_get_object_component In-Reply-To: <20030706210008.99028.qmail@web41213.mail.yahoo.com> References: <200306070213.h572D0004065@pc18.math.umbc.edu> <20030706210008.99028.qmail@web41213.mail.yahoo.com> Message-ID: <39941.69.3.42.242.1057894405@sun-qmail17.laserlink.net> Does anybody know where I can find a list of all the objects that have component objects that can be retrieved with fl_get_object_component(), and of what those component objects are? J. Cipriani From jac at casurgica.com Fri Jul 11 21:48:00 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Fri, 11 Jul 2003 21:48:00 -0400 (EDT) Subject: [XForms] A tip for using secret inputs. In-Reply-To: <20030706210008.99028.qmail@web41213.mail.yahoo.com> References: <200306070213.h572D0004065@pc18.math.umbc.edu> <20030706210008.99028.qmail@web41213.mail.yahoo.com> Message-ID: <46119.69.3.42.242.1057974480@sun-qmail12.laserlink.net> The SECRET_INPUT is completely unusable. However, you can turn a NORMAL_INPUT into somewhat of a secret input box like so: fl_set_input_color(MyInput, MyInput->col2, MyCaretColor); Where "MyInput" is your NORMAL_INPUT (an FL_OBJEC T*), and MyCaretColor is whatever color you want the caret to be. It makes the text "invisible" by setting the text color to the input's background color. It makes the highlight invisible, too, though, but its still better than the SECRET_INPUT. I only tried that on a form with one input box, though, so the text might become visible when the box loses focus. I dunno. J. Cipriani From rostamian at umbc.edu Sat Jul 12 11:33:00 2003 From: rostamian at umbc.edu (Rouben Rostamian) Date: Sat, 12 Jul 2003 11:33:00 -0400 Subject: [XForms] question about resizing forms Message-ID: <200307121533.h6CFX0jO005951@pc18.math.umbc.edu> I want to set up a form which can be resized only in discrete steps. E.g., in interactive resizing, the form's width and height may only change in multiples of 10 pixels. How do I do this in xforms? -- Rouben Rostamian From jac at casurgica.com Fri Jul 18 11:56:06 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Fri, 18 Jul 2003 11:56:06 -0400 (EDT) Subject: [XForms] BUGFIX: Tab control fixed, working secret inputs, fixed focus and resize problems, etc, etc... Message-ID: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Use GTK. From drriddle at qwest.net Fri Jul 18 20:09:33 2003 From: drriddle at qwest.net (Reed Riddle) Date: Fri, 18 Jul 2003 19:09:33 -0500 Subject: [XForms] BUGFIX: Tab control fixed, working secret inputs, fixed focus and resize problems, etc, etc... In-Reply-To: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Message-ID: <467B5611-B97D-11D7-AB01-003065E23D38@qwest.net> On Friday, July 18, 2003, at 10:56 AM, jac at casurgica.com wrote: > To subscribers of the xforms list > > > Use GTK. Awww, but that would be like giving up! :) When I started building my application, I looked at GTK. It didn't look like it had a plotting element nearly as flexible as the xyplot that Xforms has (and I even had to add a small patch to that to do what I wanted). I also could understand the callback code much better; the GTK interface builder put all kinds of crap in there, while it hardly took me any time at all to figure out Xforms. Oh, and I had never built a GUI before. It's possible that GTK is better now, and that it might be easy for me to switch my code over, but why go to all the trouble when what I have now works well enough? Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From Jean-Marc.Lasgouttes at inria.fr Thu Jul 31 12:24:54 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 31 Jul 2003 18:24:54 +0200 Subject: [XForms] [PATCH] simplifying local.h: the trivial bits Message-ID: A non-text attachment was scrubbed... Name: local.diff Type: text/x-patch Size: 5836 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/fb6de625/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Thu Jul 31 12:36:28 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 31 Jul 2003 18:36:28 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200307311732.59411.leeming@lyx.org> (Angus Leeming's message of "Thu, 31 Jul 2003 17:32:59 +0000") References: <200307311732.59411.leeming@lyx.org> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Thursday 31 July 2003 4:24 pm, Jean-Marc Lasgouttes wrote: >> The attached patch does the easy part in the job of getting rid of >> local.h. Angus, could you please double check that it makes sense >> and apply? >> >> In what remains, there are checks for xenix, vms, lynx and sunos 4. >> I'd be happy to get rid of those. From what I can see, only sunos4 >> had a xforms 0.89 build, so the others would not be missed (I could >> not even find xenix). >> >> Thoughts? Angus> Fantastic effort. The logic here seems to be inverted though. Angus> Am I right? Yes, it should be #ifdef HAVE_USLEEP also, there is a problem with line 83 of signal.c, where dec cc does not like my code. I have to leave now, I'll have a look tomorrow. JMarc From angus.leeming at btopenworld.com Thu Jul 31 13:38:41 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 31 Jul 2003 17:38:41 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: Message-ID: <200307311732.59411.leeming@lyx.org> On Thursday 31 July 2003 4:24 pm, Jean-Marc Lasgouttes wrote: > The attached patch does the easy part in the job of getting rid of > local.h. Angus, could you please double check that it makes sense and > apply? > > In what remains, there are checks for xenix, vms, lynx and sunos 4. > I'd be happy to get rid of those. From what I can see, only sunos4 had > a xforms 0.89 build, so the others would not be missed (I could not > even find xenix). > > Thoughts? Fantastic effort. The logic here seems to be inverted though. Am I right? -#if !defined(DONT_HAVE_USLEEP) +#if !defined(HAVE_USLEEP) Angus From myaconis at nycap.rr.com Thu Jul 31 11:49:00 2003 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Thu, 31 Jul 2003 11:49:00 -0400 Subject: [XForms] Form imaging problems References: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Message-ID: <006301c3577b$499ebe80$6501a8c0@dimensionxp> For some reason the first time I display a form it doesn't image properly. The attached images show what it looks like. The window consists of approximately 50 forms, a main form, a scrollable form, and 40+ row forms whos objects are added to the scrollable form which is then attached to the main form via a form browser. Any suggestions or help would be much appreciated. (The good.png image shows how the form should look. The bad.png image shows how it looks when it is first displayed.) -------------- next part -------------- A non-text attachment was scrubbed... Name: bad.png Type: image/png Size: 20311 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/ae087b2f/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: good.png Type: image/png Size: 25480 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/ae087b2f/attachment-0001.png From drriddle at qwest.net Thu Jul 31 22:20:45 2003 From: drriddle at qwest.net (Reed Riddle) Date: Thu, 31 Jul 2003 21:20:45 -0500 Subject: [XForms] Form imaging problems In-Reply-To: <006301c3577b$499ebe80$6501a8c0@dimensionxp> Message-ID: Try freezing the form, then building it, filling in the data, etc, and then unfreeze the form when everything is loaded. I see this sometimes, but that's usually before I get around to adding the freezing/unfreezing cycle when I do something to the form. Reed On Thursday, July 31, 2003, at 10:49 AM, Matthew Yaconis wrote: > To subscribers of the xforms list > > > For some reason the first time I display a form it doesn't image > properly. > The attached images show what it looks like. The window consists of > approximately 50 forms, a main form, a scrollable form, and 40+ row > forms > whos objects are added to the scrollable form which is then attached > to the > main form via a form browser. > > Any suggestions or help would be much appreciated. (The good.png image > shows how the form should look. The bad.png image shows how it looks > when > it is first displayed.) > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From myaconis at nycap.rr.com Fri Aug 1 10:22:04 2003 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Fri, 1 Aug 2003 10:22:04 -0400 Subject: [XForms] Odd menu field behavior Message-ID: <004401c35838$491d5da0$6501a8c0@dimensionxp> I have a menu object that I generate an FL_PUP_ENTRY structure for from data retrieved from a mysql database. I don't do anything particularly special with this menu object but for some reason the fl_get_menu function returns a "0" (zero) randomly when selections are made off of the list. Does anyone have any idea why fl_get_menu might return a 0 when called within the object's callback routine? The callback routine goes like this: ... callback_routine (...) { choice = fl_get_menu( ob ); ... generic_routine_for_handling(ob, ...); } The generic_routine_for_handling also calls fl_get_menu. Thanks for the help on the last question as well! From eisfuchs at tigress.com Fri Aug 1 11:15:45 2003 From: eisfuchs at tigress.com (Eisfuchs) Date: Fri, 1 Aug 2003 17:15:45 +0200 Subject: [XForms] Unsubscribe and help not working Message-ID: <200308011715.45725.eisfuchs@tigress.com> Hi! I'm trying to unsubscribe from the list but everytime I get errors back. I send an eMail with Subject: unsubscribe and empty body or unsubscribe in the body. Even the help command does not work. Can someone help me? > The original message was received at Fri, 1 Aug 2003 11:01:01 -0400 > from mail.yatho.de [213.200.97.76] > > ----- The following addresses had permanent fatal errors ----- > "|/var/mailman//mail/mailman mailcmd xforms" > (reason: 6) > (expanded from: ) > > ----- Transcript of session follows ----- > Illegal command: mailcmd > 554 5.3.0 unknown mailer error 6 Final-Recipient: RFC822; xforms-request at bob.usuhs.mil X-Actual-Recipient: X-Unix; |/var/mailman//mail/mailman mailcmd xforms Action: failed Status: 5.0.0 Diagnostic-Code: X-Unix; 6 Last-Attempt-Date: Fri, 1 Aug 2003 11:14:46 -0400 -- Eisfuchs, from Germany. From angus.leeming at btopenworld.com Fri Aug 1 12:37:01 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 1 Aug 2003 16:37:01 +0000 Subject: [XForms] Unsubscribe and help not working In-Reply-To: <200308011715.45725.eisfuchs@tigress.com> References: <200308011715.45725.eisfuchs@tigress.com> Message-ID: <200308011637.01891.angus.leeming@btopenworld.com> On Friday 01 August 2003 3:15 pm, Eisfuchs wrote: > To subscribers of the xforms list > > > Hi! > > I'm trying to unsubscribe from the list but everytime I get errors back. > I send an eMail with Subject: unsubscribe and empty body or unsubscribe in > the body. Even the help command does not work. Can someone help me? And what happens if you follow the prescription in the footer to this mail? [snip] To unsubscribe, send the message "unsubscribe" to xforms-request at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms Angus From angus.leeming at btopenworld.com Wed Aug 6 13:53:22 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 6 Aug 2003 17:53:22 +0000 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: <200308061753.22818.angus.leeming@btopenworld.com> On Wednesday 06 August 2003 4:01 pm, L. D. Marks wrote: > In browser.h the definitions: > > FL_EXPORT void fl_set_browser_vscrollbar( > FL_OBJECT *ob, > int on > ); > > FL_EXPORT void fl_set_browser_hscrollbar( > FL_OBJECT *ob, > int on > ); > > are incompatible with at least some C++ where "on" > is predefined. Ouch! Your compiler is brain dead. What are you using? Does it have any other problems with the library? Regards, Angus From angus.leeming at btopenworld.com Thu Aug 7 05:35:20 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 7 Aug 2003 09:35:20 +0000 Subject: [XForms] Libraries: broken libtool.m4 In-Reply-To: References: Message-ID: <200308070935.20490.angus.leeming@btopenworld.com> On Wednesday 06 August 2003 10:59 pm, L. D. Marks wrote: > The version of libtool.m4 that you have in acinclude.m4 > appears to be broken on an HPUX 10.20 (works under linux); > after removing it the standard version picked up by > autoconf/automake & friends works fine. Hi, Laurence. Could you tell us what version of autoconf/automake you are using? From psg at debian.org Tue Sep 2 15:28:31 2003 From: psg at debian.org (Peter S Galbraith) Date: Tue, 02 Sep 2003 15:28:31 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030411130538.61277.qmail@web13403.mail.yahoo.com> References: <20030411130538.61277.qmail@web13403.mail.yahoo.com> Message-ID: <20030902192832.F003738F37@mixing.qc.dfo.ca> T.C. Zhao wrote: > All I need to do is boot up my old linux box and recover the doc and send it. > Will do this sometime in April (I've been travelling, and am sending this > email from Tokyo). > -TC Hi T.C., I really hate to keep nagging you like this. :-) You meant to release the sources of the XForms manual last April but never got around to it. This is a reminder. Also, please avoid using the GNU Free Documentation License (GFDL) since it not a free software license and therefore cannot be included in the Debian distribution. Using the GPL would be fine. I'm writing now because while the Debian GNU/Linux distribution doesn't make a release as often as it should, a freeze is due shortly for a Christmas release. The current packaging of the XForms manual has this license: No part of this document may be reproduced, in any form or by any means, without permission from the authors. Permission to produce hardcopies in its entirety for private use is granted. This lacks the permission to us to _distribute_ the manual so I'll pull the package from Debian's non-free archive soon, before the upcoming release. But instead of removing the package, it would be great to get the manual sources under a free license and move the package to Debian's main archive. Hopefully you will find time to do this. Otherwise I can always re-create the Debian package at a later time when it is released under a free license. Thanks for your time! -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From ldm at risc4.numis.nwu.edu Wed Aug 6 12:02:02 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 06 Aug 2003 16:02:02 -0000 Subject: [XForms] Libraries: small C++ bug In-Reply-To: <200306170017.39950.angus.leeming@btopenworld.com> Message-ID: In browser.h the definitions: FL_EXPORT void fl_set_browser_vscrollbar( FL_OBJECT *ob, int on ); FL_EXPORT void fl_set_browser_hscrollbar( FL_OBJECT *ob, int on ); are incompatible with at least some C++ where "on" is predefined. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From ldm at risc4.numis.nwu.edu Wed Aug 6 19:00:25 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 06 Aug 2003 23:00:25 -0000 Subject: [XForms] Libraries: broken libtool.m4 In-Reply-To: Message-ID: The version of libtool.m4 that you have in acinclude.m4 appears to be broken on an HPUX 10.20 (works under linux); after removing it the standard version picked up by autoconf/automake & friends works fine. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From Jean-Marc.Lasgouttes at inria.fr Wed Sep 3 12:37:01 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 03 Sep 2003 18:37:01 +0200 Subject: [XForms] Re: xforms configuration In-Reply-To: <200309031619.56049.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 3 Sep 2003 16:19:56 +0000") References: <200309031619.56049.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs Angus> and has made some changes, attached. Below is his summary of Angus> what he's done, but I think it can be simply summarised as Angus> Why do we ship these files in the config directory: Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh Angus> They are all parts of the autoconf/libtool code. Why not allow Angus> the user to use the versions that come with their versions of Angus> the autotools? Because a user of xforms is not required to have any of the autotools installed (unless when using cvs, of course). I think that we have to ship all these files, except possibly libtools.m4. However, I think that we must sync this file with ltmain.sh, so even this one is needed. The right thing to do is to upgrade libtool files to the latest version (our libtool.m5 is from 2001, it seems). The choice is libtool 1.4.2 from october 2002 or 1.5 from last month. I do not know whether 1.5 can cause problems. depcomp comes probably with automake, and the config.* from autoconf. All we have to do is upgrade from recent versions. Angus> 1) Removed the "on", since it does not seem to be needed. This is of course a solution, but how does 'on' appear on this system? Is this a preprocessor define in some system header? This would be _very_ bad... Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems. Fine, we probably do not need this one. But I do not think it makes any difference, since we do not rely anywhere on the HAVE_MALLOC macro. Laurence, did it really cause a problem? Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the Angus> version I was using it was not being set. I'll have to check this one. Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and Angus> let automake/autoconf/libtool handle all this. Your version did Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5 I think we should just upgrade the versions we have (after making sure that libtool 1.5 requirements are not too high). Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" Probably OK. Angus> 6) Added a few files needed by make dist (e.g. README, I can't Angus> remember them all). Good idea. Angus> 7) I also did some stuff for our own purposes, primarily Angus> removed pixmap.c so no extra libraries are needed and removed Angus> the checks for them, turned off sharing by default, restricted Angus> the build/dist to the library and removed some of your Angus> informational output at the end of the build. FYI, it works Angus> fine, and is setup so our code will compile forms if it does Angus> not find a working copy already existing on the computer. This should be investigated... Thanks for the input Laurence. JMarc From angus.leeming at btopenworld.com Wed Sep 3 12:19:56 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Sep 2003 16:19:56 +0000 Subject: [XForms] xforms configuration Message-ID: <200309031619.56049.angus.leeming@btopenworld.com> Jean-Marc, Laurence Marks has been trying to compile xforms cvs and has made some changes, attached. Below is his summary of what he's done, but I think it can be simply summarised as Why do we ship these files in the config directory: config.guess config.sub depcomp libtool.m4 ltmain.sh They are all parts of the autoconf/libtool code. Why not allow the user to use the versions that come with their versions of the autotools? Angus Laurence's 'ChangeLog' follows: I did quite a few additional hacks on your configure, testing it on HP,SGI,SUN,cgwin with both native & gcc compilers. The major changes are (I think): 1) Removed the "on", since it does not seem to be needed. 2) Removed AC_FUNC_MALLOC since it is broken on many systems. 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the version I was using it was not being set. 4) Removed the libtool stuff that you had in acinclude.m4, and let automake/autoconf/libtool handle all this. Your version did not work with automake-1.7, autoconf-2.57, libtool-1.5 5) Added (slight overkill, but AC_PATH_XTRA does not work the way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" 6) Added a few files needed by make dist (e.g. README, I can't remember them all). 7) I also did some stuff for our own purposes, primarily removed pixmap.c so no extra libraries are needed and removed the checks for them, turned off sharing by default, restricted the build/dist to the library and removed some of your informational output at the end of the build. FYI, it works fine, and is setup so our code will compile forms if it does not find a working copy already existing on the computer. -------------- next part -------------- A non-text attachment was scrubbed... Name: marks.diff.gz Type: application/x-gzip Size: 49844 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030903/84e1704e/attachment.gz From larsbj at lyx.org Wed Sep 3 17:44:50 2003 From: larsbj at lyx.org (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: Wed, 03 Sep 2003 23:44:50 +0200 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: "L. D. Marks" writes: | To subscribers of the xforms list > > | In browser.h the definitions: > | FL_EXPORT void fl_set_browser_vscrollbar( | FL_OBJECT *ob, | int on | ); > | FL_EXPORT void fl_set_browser_hscrollbar( | FL_OBJECT *ob, | int on | ); > | are incompatible with at least some C++ where "on" | is predefined. Predefined as what? This is certainly not Standard C++. Can you should where/how you get that error? (and the error itself) -- Lgb From larsbj at lyx.org Wed Sep 3 18:53:03 2003 From: larsbj at lyx.org (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: Thu, 04 Sep 2003 00:53:03 +0200 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: "L. D. Marks" writes: | I did a little more checking, and it looks like our code was defining | "on" itself, and since this was in an include that came before forms.h | this created problems. (We probably should not be using "on" - maybe | you might want to think about "forms_on" to be more robust. The | earlier forms header files did not have the "on" defined.) What stops you from polluting the global namespace with a macro/define called forms_on? (and using forms_on in xforms give away the wrong meaning of the parameter... and removing it from the function declaration makes it impossible to see what this int is) It is your code that is in error, not xforms. -- Lgb From Holly.Yeh at grc.nasa.gov Thu Sep 4 10:53:32 2003 From: Holly.Yeh at grc.nasa.gov (Holly Yeh) Date: Thu, 04 Sep 2003 10:53:32 -0400 Subject: [XForms] Making XForms Multi-Threaded Message-ID: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> Hi, We are planning on making XForms multi-threaded. If anyone has any planning or been working on the issue, Please let us know. Thank you very much! Holly Yeh. From angus.leeming at btopenworld.com Thu Sep 4 12:08:46 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 4 Sep 2003 16:08:46 +0000 Subject: [XForms] Making XForms Multi-Threaded In-Reply-To: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> Message-ID: <200309041608.46270.angus.leeming@btopenworld.com> On Thursday 04 September 2003 2:53 pm, Holly Yeh wrote: > To subscribers of the xforms list > > > Hi, > We are planning on making XForms multi-threaded. If anyone has any > planning or been working on the issue, Please let us know. > Thank you very much! > > Holly Yeh. Hello, Holly. that sounds great. However, I wonder if you might not find FLTK (Fast Light ToolKit http://www.fltk.org) fits your needs already. Yeah, yeah, I know. I'm the guy fronting xforms, not fltk. Nonetheless, and without wanting to appear disloyal to xforms, FLTK has an active developer community (which IMO counts for a lot), it has multithreaded support already and, perhaps most importantly, it has an xforms -> fltk converter so porting your app might well be painless. http://www.fltk.org/documentation.php/doc-1.1/forms.html#15_1 Kind regards, Angus From ldm at risc4.numis.nwu.edu Wed Sep 3 12:45:22 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 3 Sep 2003 11:45:22 -0500 (CDT) Subject: [XForms] Re: xforms configuration In-Reply-To: Message-ID: On Wed, 3 Sep 2003, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs > Angus> and has made some changes, attached. Below is his summary of > Angus> what he's done, but I think it can be simply summarised as > > Angus> Why do we ship these files in the config directory: > Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh > > Angus> They are all parts of the autoconf/libtool code. Why not allow > Angus> the user to use the versions that come with their versions of > Angus> the autotools? > > Because a user of xforms is not required to have any of the autotools > installed (unless when using cvs, of course). > > I think that we have to ship all these files, except possibly > libtools.m4. However, I think that we must sync this file with > ltmain.sh, so even this one is needed. > > The right thing to do is to upgrade libtool files to the latest > version (our libtool.m5 is from 2001, it seems). The choice is libtool > 1.4.2 from october 2002 or 1.5 from last month. I do not know whether > 1.5 can cause problems. In the version that was in the cvs, the libtool stuff was in acinclude.m4 so cancelled my more current version of libtool etc. I removed it from acinclude.m4 -- you do need to ship a viable version. > > depcomp comes probably with automake, and the config.* from autoconf. > All we have to do is upgrade from recent versions. > > Angus> 1) Removed the "on", since it does not seem to be needed. > > This is of course a solution, but how does 'on' appear on this system? > Is this a preprocessor define in some system header? This would be > _very_ bad... If I remember right, "on" was defined in g++. The header was fine with gcc, died with g++. > > Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems. > > Fine, we probably do not need this one. But I do not think it makes > any difference, since we do not rely anywhere on the HAVE_MALLOC > macro. Laurence, did it really cause a problem? Yes. If it did not find a GNU malloc it redefined it to rpl_malloc and you then had to link this in otherwise you would have an undefined symbol. > > Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the > Angus> version I was using it was not being set. > > I'll have to check this one. > > Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and > Angus> let automake/autoconf/libtool handle all this. Your version did > Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5 > > I think we should just upgrade the versions we have (after making sure > that libtool 1.5 requirements are not too high). > > Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the > Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) > Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 > Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" > > Probably OK. > > Angus> 6) Added a few files needed by make dist (e.g. README, I can't > Angus> remember them all). > > Good idea. > > Angus> 7) I also did some stuff for our own purposes, primarily > Angus> removed pixmap.c so no extra libraries are needed and removed > Angus> the checks for them, turned off sharing by default, restricted > Angus> the build/dist to the library and removed some of your > Angus> informational output at the end of the build. FYI, it works > Angus> fine, and is setup so our code will compile forms if it does > Angus> not find a working copy already existing on the computer. > > This should be investigated... > > Thanks for the input Laurence. > > JMarc > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From ldm at risc4.numis.nwu.edu Wed Sep 3 18:33:20 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 3 Sep 2003 17:33:20 -0500 (CDT) Subject: [XForms] Libraries: small C++ bug In-Reply-To: Message-ID: I did a little more checking, and it looks like our code was defining "on" itself, and since this was in an include that came before forms.h this created problems. (We probably should not be using "on" - maybe you might want to think about "forms_on" to be more robust. The earlier forms header files did not have the "on" defined.) On Wed, 3 Sep 2003, [iso-8859-1] Lars Gullik Bj?nnes wrote: > "L. D. Marks" writes: > > | To subscribers of the xforms list > > > > > | In browser.h the definitions: > > > | FL_EXPORT void fl_set_browser_vscrollbar( > | FL_OBJECT *ob, > | int on > | ); > > > | FL_EXPORT void fl_set_browser_hscrollbar( > | FL_OBJECT *ob, > | int on > | ); > > > | are incompatible with at least some C++ where "on" > | is predefined. > > Predefined as what? > This is certainly not Standard C++. > > Can you should where/how you get that error? > (and the error itself) > > -- > Lgb > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From jac4 at andrew.cmu.edu Wed Sep 3 23:39:03 2003 From: jac4 at andrew.cmu.edu (jason) Date: Wed, 3 Sep 2003 23:39:03 -0400 (EDT) Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: > | I did a little more checking, and it looks like our code was defining > | "on" itself, and since this was in an include that came before forms.h > | this created problems. (We probably should not be using "on" - maybe > | you might want to think about "forms_on" to be more robust. The > | earlier forms header files did not have the "on" defined.) > > What stops you from polluting the global namespace with a macro/define > called forms_on? (and using forms_on in xforms give away the wrong > meaning of the parameter... and removing it from the function > declaration makes it impossible to see what this int is) > > It is your code that is in error, not xforms. Yeah I'm going to have to agree with him on that one. There is no "on" in any of the standard C++ headers, afaik. Additionally, having a macro defined as "on" is not specific to C++... things could be messed up the same way if everything was in C. From angus.leeming at btopenworld.com Thu Sep 4 13:57:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 4 Sep 2003 17:57:02 +0000 Subject: [XForms] Making XForms Multi-Threaded In-Reply-To: <5.1.1.5.2.20030904124900.01884068@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> <5.1.1.5.2.20030904124900.01884068@popserve.grc.nasa.gov> Message-ID: <200309041757.02703.angus.leeming@btopenworld.com> On Thursday 04 September 2003 4:50 pm, Holly Yeh wrote: > Hi Angus, > Thank you for your input, Is fltk supported on tru64 Unix? > > Holly Yeh. I don't know, Holly. I've never used it in anger. But it's open source, has mailing lists of its own and took about 5 mins to compile the source. I don't suppose it'd take long for you to try it out, now would it? Comes with lots of documentation and test programs too... Best regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Sep 5 09:44:29 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 05 Sep 2003 15:44:29 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: (Jean-Marc Lasgouttes's message of "Thu, 31 Jul 2003 18:36:28 +0200") References: <200307311732.59411.leeming@lyx.org> Message-ID: A non-text attachment was scrubbed... Name: local2.diff Type: text/x-patch Size: 7382 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030905/44db0cb7/attachment.bin From tc_zhao at yahoo.com Mon Sep 8 11:48:38 2003 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Mon, 8 Sep 2003 08:48:38 -0700 (PDT) Subject: [XForms] Re: XForms: Documentation In-Reply-To: <20030902192832.F003738F37@mixing.qc.dfo.ca> Message-ID: <20030908154838.51918.qmail@web13407.mail.yahoo.com> Sorry for the delay and thanks for the info. GPL it is. I am currently travelling and will be back home end of September. Expect the free manual in October sometime. -TC --- Peter S Galbraith wrote: > To subscribers of the xforms list > > > T.C. Zhao wrote: > > > All I need to do is boot up my old linux box and recover the doc and send > it. > > Will do this sometime in April (I've been travelling, and am sending this > > email from Tokyo). > > -TC > > Hi T.C., > > I really hate to keep nagging you like this. :-) > > You meant to release the sources of the XForms manual last April but > never got around to it. This is a reminder. Also, please avoid using > the GNU Free Documentation License (GFDL) since it not a free software > license and therefore cannot be included in the Debian distribution. > Using the GPL would be fine. > > I'm writing now because while the Debian GNU/Linux distribution doesn't > make a release as often as it should, a freeze is due shortly for a > Christmas release. The current packaging of the XForms manual has this > license: > > No part of this document may be reproduced, in any form or by any > means, without permission from the authors. Permission to produce > hardcopies in its entirety for private use is granted. > > This lacks the permission to us to _distribute_ the manual so I'll pull > the package from Debian's non-free archive soon, before the upcoming > release. But instead of removing the package, it would be great to get > the manual sources under a free license and move the package to Debian's > main archive. Hopefully you will find time to do this. Otherwise I can > always re-create the Debian package at a later time when it is released > under a free license. > > Thanks for your time! > -- > Peter S. Galbraith, Debian Developer > http://people.debian.org/~psg > GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From psg at debian.org Mon Sep 8 11:57:53 2003 From: psg at debian.org (Peter S Galbraith) Date: Mon, 08 Sep 2003 11:57:53 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030908154838.51918.qmail@web13407.mail.yahoo.com> References: <20030908154838.51918.qmail@web13407.mail.yahoo.com> Message-ID: <20030908155753.3FB3238F7E@mixing.qc.dfo.ca> T.C. Zhao wrote: > > Sorry for the delay and thanks for the info. GPL it is. > > I am currently travelling and will be back home end of September. Expect the > free manual in October sometime. > > -TC Thanks TC! Would you also mind replying to this message (and CC the mailing list for the public record) and give permission to Debian to distribute the current version of the manual in its non-free archive and mirrors, e.g. http://packages.debian.org/unstable/doc/libforms-doc.html This would gives us the required permission not present in the current license. Thanks again! -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From angus.leeming at btopenworld.com Mon Sep 8 21:04:13 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 01:04:13 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: Message-ID: <200309090051.14280.leeming@lyx.org> On Friday 05 September 2003 1:44 pm, Jean-Marc Lasgouttes wrote: > Angus> Fantastic effort. The logic here seems to be inverted though. > Angus> Am I right? > > Jean-Marc> Yes, it should be #ifdef HAVE_USLEEP > > Jean-Marc> also, there is a problem with line 83 of signal.c, where > Jean-Marc> dec cc does not like my code. I have to leave now, I'll > Jean-Marc> have a look tomorrow. > > I finally finished this a bit and added a few things. Angus, could you > commit this after review? > > JMarc Many thaks for doing this Jean-Marc. It is now committed. Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 05:18:41 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 11:18:41 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309090051.14280.leeming@lyx.org> (Angus Leeming's message of "Tue, 9 Sep 2003 01:04:13 +0000") References: <200309090051.14280.leeming@lyx.org> Message-ID: A non-text attachment was scrubbed... Name: chglog.diff Type: text/x-patch Size: 1075 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/51b7308c/attachment.bin From angus.leeming at btopenworld.com Tue Sep 9 06:43:05 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 10:43:05 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: <200309090051.14280.leeming@lyx.org> Message-ID: <200309091043.05489.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: JMarc> Angus> Many thaks for doing this Jean-Marc. It is now committed. Angus JMarc> You forgot the Changelog entry. No I didn't, but I'll admit that my subsequent commit with a date of 23 May is confusing (and wrong). I've fixed that. Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 06:16:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 12:16:19 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309091043.05489.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 10:43:05 +0000") References: <200309090051.14280.leeming@lyx.org> <200309091043.05489.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: JMarc> Angus> Many thaks for doing this Jean-Marc. It is now JMarc> committed. Angus You forgot the Changelog entry. Angus> No I didn't, but I'll admit that my subsequent commit with a Angus> date of 23 May is confusing (and wrong). I've fixed that. You're right, it is cvs update that got confused actually. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 06:47:37 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 12:47:37 +0200 Subject: [XForms] [PATCH] Enable optional building of demos/ directory Message-ID: A non-text attachment was scrubbed... Name: demos.diff Type: text/x-patch Size: 2257 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/2173d3a5/attachment.bin From angus.leeming at btopenworld.com Tue Sep 9 08:46:50 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 12:46:50 +0000 Subject: [XForms] Re: [PATCH] Enable optional building of demos/ directory In-Reply-To: References: Message-ID: <200309091246.50358.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 10:47 am, Jean-Marc Lasgouttes wrote: > The following patch adds an --enable-demos flag to configure > > Angus, please apply if it works OK for you. Oh, JMarc, you beauty! Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 08:22:32 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 14:22:32 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309091245.11255.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 12:45:11 +0000") References: <200309091043.05489.angus.leeming@btopenworld.com> <200309091245.11255.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Let's try and make a road plan for a 1.1 release. I guess we Angus> should address the problems with the autotools that Laurence Angus> Marks described. Yes. I have not looked at that seriously yet. One thing I noticed is that we lack an INSTALL file (to be taken from autoconf). The file Copyright should maybe be included in some other file (and the reference to COPYING changed to COPYING.LIB). The copyrights should be changed to include at least you (and me) (also in lib/version.c). Angus> Here I have Red Hat 8 which comes with automake 1.6.3, autoconf Angus> 2.53 and libtool 1.4.2. We should probably pick something newer... Angus> I find that if I remove depcomp and the config.*, then Angus> automake, autoconf shove in new versions. Great. However, if I Angus> remove libtool.m4 and run libtoolize, I do do not get a new Angus> version of libtool.m4. I guess, therefore that it is no longer Angus> needed? The libtool documentation says: When you invoke the libtoolize program (see section 5.4.1 Invoking libtoolize), it will tell you where to find a definition of AC_PROG_LIBTOOL. If you use Automake, the aclocal program will automatically add AC_PROG_LIBTOOL support to your configure script. Nevertheless, it is advisable to include a copy of `libtool.m4' in `acinclude.m4', so that, even if `aclocal.m4' and `configure' are rebuilt for any reason, the appropriate libtool macros will be used. The alternative is to hope the user will have a compatible version of `libtool.m4' installed and accessible for aclocal. This may lead to weird errors when versions don't match. So we should keep a libtool.m4. Angus> Here is the patch. Wa d'ya think? Angus I'd say let's refine it a bit first. Angus> NB, reading on the web, it appears that others have added Angus> libtoolize to autogen.sh Angus> http://mail.gnome.org/archives/gtk-devel-list/2002-September/msg00015.html If you look at the autoconf repository, you will even find out that the have special makefile targets to update all these files automatically from the gnu ftp site. I am not sure whether we want to go to such extreme methods, though. JMarc From tc_zhao at yahoo.com Tue Sep 9 10:07:59 2003 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Tue, 9 Sep 2003 07:07:59 -0700 (PDT) Subject: [XForms] Re: XForms: Documentation In-Reply-To: <20030908155753.3FB3238F7E@mixing.qc.dfo.ca> Message-ID: <20030909140759.33379.qmail@web13406.mail.yahoo.com> Hi Peter, Please feel free to include the current manual in the Debian distribution. For the public record, I am granting the rights to all linux distributors to distribute all versions of xforms manual without fee in all electronic formats (.tex,.psf, .ps, .html) with the requirement that the distributed versions retain the copyright notice and version number. -TC --- Peter S Galbraith wrote: > T.C. Zhao wrote: > > > > > Sorry for the delay and thanks for the info. GPL it is. > > > > I am currently travelling and will be back home end of September. Expect > the > > free manual in October sometime. > > > > -TC > > Thanks TC! > > Would you also mind replying to this message (and CC the mailing list > for the public record) and give permission to Debian to distribute the > current version of the manual in its non-free archive and mirrors, e.g. > > http://packages.debian.org/unstable/doc/libforms-doc.html > > This would gives us the required permission not present in the current > license. > > Thanks again! > -- > Peter S. Galbraith, Debian Developer > http://people.debian.org/~psg > GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From psg at debian.org Tue Sep 9 10:21:36 2003 From: psg at debian.org (Peter S Galbraith) Date: Tue, 09 Sep 2003 10:21:36 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030909140759.33379.qmail@web13406.mail.yahoo.com> References: <20030909140759.33379.qmail@web13406.mail.yahoo.com> Message-ID: <20030909142136.C3CEB39205@mixing.qc.dfo.ca> T.C. Zhao wrote: > Hi Peter, > > Please feel free to include the current manual in the Debian distribution. > > For the public record, I am granting the rights to all linux distributors to > distribute all versions of xforms manual without fee in all electronic > formats (.tex,.psf, .ps, .html) with the requirement that the distributed > versions retain the copyright notice and version number. > > -TC Many thanks T.C. ! This is exactly what I needed until the free release. :-) Peter -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 11:02:53 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 17:02:53 +0200 Subject: [XForms] [PATCH] Simplify configure.ac Message-ID: A non-text attachment was scrubbed... Name: conf.diff Type: text/x-patch Size: 3945 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/0a0cb9c4/attachment.bin From angus.leeming at btopenworld.com Tue Sep 9 13:16:10 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 17:16:10 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: References: Message-ID: <200309091716.10189.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 3:02 pm, Jean-Marc Lasgouttes wrote: > The following patch removes tests that are as far as I can see not > used. I tried to check carefully what the side effects of the various > autoconf macros are. The idea is to keep all tests that already exist > in some form in xforms 1.0. > Angus, please double check and apply (note that the ChangeLog chunk > will not apply after my other patch, since this is against unpatched > HEAD; I'll redo the patch if there is a problem). Well, it works for me it all looks reasonable and, as I think of you as the whizz in these things anyway, that's good enough for me. I applied it. Many thanks. > Something that still has to be done is implement --disable-gl to avoid > building libformsGL when not relevant. It should not be too difficult > to make a test to autodetect this. Good idea. Actually, shouldn't that be --enable-gl (defaults to 'no'), identical to you little test for --enable-demos? Of course, it would actually do some testing if the answer were 'yes'. Angus From wd4nmq at comcast.net Tue Sep 9 14:49:22 2003 From: wd4nmq at comcast.net (Jeff Pierce) Date: Tue, 09 Sep 2003 14:49:22 -0400 Subject: [XForms] Windows with transparent background and no border. Message-ID: <3F5E20B2.6030502@comcast.net> Is it possible at all under X windows to have a non-rectangular window like under MS Windows? The call under MS is AddRectToRgn(). Where you have a mask that is treated like chroma mixing, ie green screen, in movies/tv. Then the portions of the underlying desktop will show through and key presses in those areas will not go to the app, but to whatever is underneath it. I know that xfornms does not support this. But, does anybody knoe of a way to do it using any other X frameworks? -- Jeff, wd4nmq wd4nmq at comcast.net http://mywebpages.comcast.net/wd4nmq From Jean-Marc.Lasgouttes at inria.fr Wed Sep 10 08:56:25 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 10 Sep 2003 14:56:25 +0200 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <200309091716.10189.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 17:16:10 +0000") References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: gl.diff Type: text/x-patch Size: 2739 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030910/58819f35/attachment.bin From angus.leeming at btopenworld.com Tue Sep 9 08:45:11 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 12:45:11 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: <200309091043.05489.angus.leeming@btopenworld.com> Message-ID: <200309091245.11255.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 10:16 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > Angus> To subscribers of the xforms list > Angus> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: > JMarc> Angus> Many thaks for doing this Jean-Marc. It is now > JMarc> committed. Angus You forgot the Changelog entry. > > Angus> No I didn't, but I'll admit that my subsequent commit with a > Angus> date of 23 May is confusing (and wrong). I've fixed that. > > You're right, it is cvs update that got confused actually. Let's try and make a road plan for a 1.1 release. I guess we should address the problems with the autotools that Laurence Marks described. > The right thing to do is to upgrade libtool files to the latest > version (our libtool.m5 is from 2001, it seems). The choice is libtool > 1.4.2 from october 2002 or 1.5 from last month. I do not know whether > 1.5 can cause problems. > depcomp comes probably with automake, and the config.* from autoconf. > All we have to do is upgrade from recent versions. Here I have Red Hat 8 which comes with automake 1.6.3, autoconf 2.53 and libtool 1.4.2. I find that if I remove depcomp and the config.*, then automake, autoconf shove in new versions. Great. However, if I remove libtool.m4 and run libtoolize, I do do not get a new version of libtool.m4. I guess, therefore that it is no longer needed? Certainly, I can confirm that everything works for me. Here is the patch. Wa d'ya think? Angus NB, reading on the web, it appears that others have added libtoolize to autogen.sh http://mail.gnome.org/archives/gtk-devel-list/2002-September/msg00015.html Should we do so? -------------- next part -------------- A non-text attachment was scrubbed... Name: updatetools.diff.bz2 Type: application/x-bzip2 Size: 42918 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/4721bc35/attachment.bz2 From angus.leeming at btopenworld.com Wed Sep 10 12:56:42 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 16:56:42 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: <200309101656.42201.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 12:56 pm, Jean-Marc Lasgouttes wrote: > >> Something that still has to be done is implement --disable-gl to > >> avoid building libformsGL when not relevant. It should not be too > >> difficult to make a test to autodetect this. > > Angus> Good idea. Actually, shouldn't that be --enable-gl (defaults to > Angus> 'no'), identical to you little test for --enable-demos? Of > Angus> course, it would actually do some testing if the answer were > Angus> 'yes'. > > See attached patch. The code only builds the gl/ subdir if GL/glx.h is > found. You can add an explicit --disable-gl to avoid building. > > I also simplified the code for --enable-demos. Thanks for this. > BTW, what should we do about the xforms rpm? Building it with gl > support would mean that applications like LyX would depend on GL > support, which is stupid. An alternative would be to make separate > xforms and xforms-gl rpms, but this is a bit heavy IMO. Heavy or not, it is the right thing to do. In fact, being brutal about this, we should have separate rpms for each library, xforms, xforms-image and xforms-gl. Moreover, fdesign and fd2ps are developer tools. They should go, therefore, in the xforms-devel rpm. Angus From psg at debian.org Wed Sep 10 13:02:48 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:02:48 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Jean-Marc Lasgouttes References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: <20030910170249.0137A38F37@mixing.qc.dfo.ca> Jean-Marc Lasgouttes wrote: > support would mean that applications like LyX would depend on GL > support, which is stupid. An alternative would be to make separate > xforms and xforms-gl rpms, but this is a bit heavy IMO. This is what I do for Debian anyway: http://packages.debian.org/unstable/libs/libforms1.html http://packages.debian.org/unstable/libs/libformsgl1.html http://packages.debian.org/unstable/libdevel/libforms-dev.html http://packages.debian.org/unstable/devel/libformsgl-dev.html http://packages.debian.org/unstable/devel/libforms-bin.html Peter From angus.leeming at btopenworld.com Wed Sep 10 14:09:03 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:09:03 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910170249.0137A38F37@mixing.qc.dfo.ca> References: <20030910170249.0137A38F37@mixing.qc.dfo.ca> Message-ID: <200309101809.03546.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:02 pm, Peter S Galbraith wrote: > To subscribers of the xforms list > > Jean-Marc Lasgouttes wrote: > > support would mean that applications like LyX would depend on GL > > support, which is stupid. An alternative would be to make separate > > xforms and xforms-gl rpms, but this is a bit heavy IMO. > > This is what I do for Debian anyway: > > http://packages.debian.org/unstable/libs/libforms1.html > http://packages.debian.org/unstable/libs/libformsgl1.html > http://packages.debian.org/unstable/libdevel/libforms-dev.html > http://packages.debian.org/unstable/devel/libformsgl-dev.html > http://packages.debian.org/unstable/devel/libforms-bin.html Any reason why you don't split up xforms and xforms-image? Is making dep packages automatically just a case of adding the correct Makefile target and leaving the computer to do its stuff? If so, feel free to submit a patch. Angus From psg at debian.org Wed Sep 10 13:25:38 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:25:38 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Angus Leeming <200309101809.03546.angus.leeming@btopenworld.com> References: <20030910170249.0137A38F37@mixing.qc.dfo.ca> <200309101809.03546.angus.leeming@btopenworld.com> Message-ID: <20030910172538.4755438F37@mixing.qc.dfo.ca> Angus Leeming wrote: > On Wednesday 10 September 2003 5:02 pm, Peter S Galbraith wrote: > > To subscribers of the xforms list > > > > Jean-Marc Lasgouttes wrote: > > > support would mean that applications like LyX would depend on GL > > > support, which is stupid. An alternative would be to make separate > > > xforms and xforms-gl rpms, but this is a bit heavy IMO. > > > > This is what I do for Debian anyway: > > > > http://packages.debian.org/unstable/libs/libforms1.html > > http://packages.debian.org/unstable/libs/libformsgl1.html > > http://packages.debian.org/unstable/libdevel/libforms-dev.html > > http://packages.debian.org/unstable/devel/libformsgl-dev.html > > http://packages.debian.org/unstable/devel/libforms-bin.html > > Any reason why you don't split up xforms and xforms-image? Only because the image library didn't cause the added depencies to be too onerous. Most users already have installed the packages for libjpeg, libtiff and libXpm. OpenGL is another story, so I bundled it separately. > Is making dep packages automatically just a case of adding the correct > Makefile target and leaving the computer to do its stuff? If so, feel > free to submit a patch. Making Debian packages involves a debian/ directory. See http://ftp.debian.org/debian/pool/main/libf/libforms1/libforms1_1.0-4.diff.gz for what I add/change from the original tar ball. It's not a huge deal for me to keep this separate and apply it after your release, and I suppose having an outdated debian directory can sometimes cause problems. I include it in CVS for projects that I'm heavily involved with (gri and MH-E) and have CVS access, and don't do it in the majority of my packages (because I don't track CVS as much as would be required). Making the actual packages also involves doing it on a Debian system, of course, since specific tools are required to calculate dependencies and certain helper packages are invoked. Peter From psg at debian.org Wed Sep 10 13:38:27 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:38:27 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Angus Leeming <200309101834.25195.angus.leeming@btopenworld.com> References: <200309101809.03546.angus.leeming@btopenworld.com> <20030910172538.4755438F37@mixing.qc.dfo.ca> <200309101834.25195.angus.leeming@btopenworld.com> Message-ID: <20030910173827.8971A38F37@mixing.qc.dfo.ca> Angus Leeming wrote: > On Wednesday 10 September 2003 5:25 pm, Peter S Galbraith wrote: > > Making Debian packages involves a debian/ directory. See > > http://ftp.debian.org/d[snip...]/libforms1_1.0-4.diff.gz > > Cool! I didn't know you'd done that! I'll have a look at some stage. You didn't know is was packaged? > > Making the actual packages also involves doing it on a Debian system, > > of course, since specific tools are required to calculate dependencies > > and certain helper packages are invoked. > > Sure. But then that is true also of rpmdist. Yeah, I added that as an afterthought. It did seem fairly obvious. I just wanted to make sure. :-) Peter From angus.leeming at btopenworld.com Wed Sep 10 14:34:25 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:34:25 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910172538.4755438F37@mixing.qc.dfo.ca> References: <200309101809.03546.angus.leeming@btopenworld.com> <20030910172538.4755438F37@mixing.qc.dfo.ca> Message-ID: <200309101834.25195.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:25 pm, Peter S Galbraith wrote: > Making Debian packages involves a debian/ directory. See > http://ftp.debian.org/d[snip...]/libforms1_1.0-4.diff.gz Cool! I didn't know you'd done that! I'll have a look at some stage. > Making the actual packages also involves doing it on a Debian system, > of course, since specific tools are required to calculate dependencies > and certain helper packages are invoked. Sure. But then that is true also of rpmdist. This is from Makefile.am in the top level dir. rpmdist: dist if [ -z "`type -path rpmbuild`" ]; \ then \ RPMBUILD=rpm; \ else \ RPMBUILD=rpmbuild; \ fi; $$RPMBUILD -ta $(PACKAGE)-$(VERSION).tar.gz ; saved_status=$$?; \ exit $$saved_status Regards, Angus From angus.leeming at btopenworld.com Wed Sep 10 14:44:23 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:44:23 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910173827.8971A38F37@mixing.qc.dfo.ca> References: <200309101834.25195.angus.leeming@btopenworld.com> <20030910173827.8971A38F37@mixing.qc.dfo.ca> Message-ID: <200309101844.23539.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:38 pm, Peter S Galbraith wrote: > You didn't know is was packaged? Let's just say that my ignorance is boundless. Angus From vs85 at cornell.edu Mon Sep 15 17:11:38 2003 From: vs85 at cornell.edu (Veera) Date: Mon, 15 Sep 2003 17:11:38 -0400 Subject: [XForms] XForms installation Message-ID: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> Hi, I have some problems when i was trying to install xforms on cygwin(latest version 1.5.4 with XFREE86). First I unzipped the xforms.1.0.tar file. then typed xmkmf -a. This command went through well. After that when i typed 'make' the program stops and gives this error message: make[1]: *** No rule to make target `../lib/libforms.a', needed by `fd2ps.exe'. Stop. make[1]: Leaving directory `/usr/x11r6/xforms-1.0/fd2ps' make: *** [all] Error 2 I have already installed the xpm library. Is it a problem due to bad xpm installation? I tried installing the binary version bxforms.089. Again the demos don't run and it gives an fl_initialise error (unable to open). Can someone please tell me the steps for installing xforms on cygwin and making the demos work. thanks Veera From angus.leeming at btopenworld.com Tue Sep 16 05:01:13 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 16 Sep 2003 09:01:13 +0000 Subject: [XForms] XForms installation In-Reply-To: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> References: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> Message-ID: <200309160901.13982.angus.leeming@btopenworld.com> On Monday 15 September 2003 9:11 pm, Veera wrote: > Hi, > > I have some problems when i was trying to install xforms on cygwin(latest > version 1.5.4 with XFREE86). First I unzipped the xforms.1.0.tar file. then > typed xmkmf -a. This command went through well. After that when i typed > 'make' the program stops and gives this error message: > > make[1]: *** No rule to make target `../lib/libforms.a', needed by > `fd2ps.exe'. Stop. > make[1]: Leaving directory `/usr/x11r6/xforms-1.0/fd2ps' > make: *** [all] Error 2 > > Can someone please tell me the steps for installing xforms on cygwin and > making the demos work. This is going to sound kludgy, but... Go into the lib subdirectory and type $ make $ make install (as root) Thereafter, fd2ps should be able to find the libforms.a/.so files fine when you return to the top level directory and type $ make Alternatively, and perhaps less kludgily, set your LD_LIBRARY_PATH variable to include the path to the generated libforms.a/.so files. Angus From ldm at risc4.numis.nwu.edu Tue Sep 23 20:21:32 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Tue, 23 Sep 2003 19:21:32 -0500 (CDT) Subject: [XForms] Redhat 9.0 libforms.a incompatibility Message-ID: I just upgraded my system to Redhat 9.0, and it appears that there are some incompatibilties between the include file definitions (in my version anyway) and the version of libforms.a that they are shipping. (I deleted their version and just installed one I compiled, but you might want to decide how to deal with this in a general way.) ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From davidwriter at yahoo.com Wed Sep 24 14:25:50 2003 From: davidwriter at yahoo.com (David Scriven) Date: Wed, 24 Sep 2003 14:25:50 -0400 (EDT) Subject: [XForms] Redhat 9.0 libforms.a incompatibility In-Reply-To: Message-ID: <20030924182550.70945.qmail@web41214.mail.yahoo.com> As far as I know Red Hat has not shipped xforms since version 7.2. The problems that you were having with the (presumably old) libforms.a are not unique to xforms. Static linking was changed in RH 9 and most old archives had to be recompiled otherwise you get errors. You can check the archive of this list to see what the errors were. DS --- "L. D. Marks" wrote: > To subscribers of the xforms list > > > I just upgraded my system to Redhat 9.0, and it appears > that there are some incompatibilties between the include > file definitions (in my version anyway) and the version > of libforms.a that they are shipping. (I deleted their > version and just installed one I compiled, but you might > want to decide how to deal with this in a general > way.) > > ----------------------------------------------- > Laurence Marks > Department of Materials Science and Engineering > MSE Rm 2036 Cook Hall > 2225 N Campus Drive > Northwestern University > Evanston, IL 60201, USA > Tel: (847) 491-3996 Fax: (847) 491-7820 > mailto:ldm at risc4.numis.nwu.edu > http://www.numis.nwu.edu > ----------------------------------------------- > > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From dstrang at chartermi.net Fri Oct 3 04:07:50 2003 From: dstrang at chartermi.net (David Strang) Date: Fri, 3 Oct 2003 04:07:50 -0400 Subject: [XForms] Hello - Just a test. Message-ID: <000901c38985$7055e940$6401a8c0@athlon> Hello. Regards, Dave Strang From angus.leeming at btopenworld.com Fri Oct 3 05:45:54 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 3 Oct 2003 09:45:54 +0000 Subject: [XForms] Hello - Just a test. In-Reply-To: <000901c38985$7055e940$6401a8c0@athlon> References: <000901c38985$7055e940$6401a8c0@athlon> Message-ID: <200310030945.54699.angus.leeming@btopenworld.com> On Friday 03 October 2003 8:07 am, David Strang wrote: > Hello. Hello, David. Quiet here, isn't it? Angus From ddembrow at nlxcorp.com Fri Oct 3 05:40:59 2003 From: ddembrow at nlxcorp.com (ddembrow at nlxcorp.com) Date: Fri, 3 Oct 2003 05:40:59 -0400 Subject: [XForms] xforms patch Message-ID: I have attached diff patch files for fselect.c and tabfolder.c source. Could a developer look at what is changed, and add it to the development Xforms source? The fselect_patch allows for a borderless form. This allows the use of the file selector goodie in an application which uses nothing but fixed size/borderless forms. The tabfolder_patch corrects the form position when using bottom tab folders. Without the patch the form selected with a bottom tab is place below the tab - for a full screen display the form simply disappears out of the viewing area. Thanks, ---d.dembrow NLX Corporation Phone: (703) 234-2100 FAX: (703) 234-2101 email: ddembrow at nlxcorp.com (See attached file: fselect_patch)(See attached file: tabfolder_patch) -------------- next part -------------- A non-text attachment was scrubbed... Name: fselect_patch Type: application/octet-stream Size: 288 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031003/ad06a891/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: tabfolder_patch Type: application/octet-stream Size: 737 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031003/ad06a891/attachment-0001.obj From angus.leeming at btopenworld.com Fri Oct 3 07:08:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 3 Oct 2003 11:08:26 +0000 Subject: [XForms] xforms patch In-Reply-To: References: Message-ID: <200310031108.26360.angus.leeming@btopenworld.com> On Friday 03 October 2003 9:40 am, ddembrow at nlxcorp.com wrote: > I have attached diff patch files for fselect.c and tabfolder.c source. > Could a developer look at what is changed, and add it to the > development Xforms source? Many thanks for this. > The fselect_patch allows for a borderless form. This allows the > use of the file selector goodie in an application which uses nothing > but fixed size/borderless forms. The restriction does seem entirely arbitrary. I'll apply this one happily. > The tabfolder_patch corrects the form position when usingbottom > tab folders. Without the patch the form selected with a bottom tab > is place below the tab - for a full screen display the form simply > disappears out of the viewing area. Excellent. I'll apply this too. Incidentally, what's your name? Adding this to the ChangeLog seems a little impersonal ;-) 2003-10-03 * lib/fselect.c: remove the arbitrary restriction on the display of borderless forms. * lib/tabfolder.c: display the tab forms correctly when using bottom tab folders. From dstrang at chartermi.net Fri Oct 3 14:32:11 2003 From: dstrang at chartermi.net (David Strang) Date: Fri, 3 Oct 2003 14:32:11 -0400 Subject: [XForms] Looking for advice Message-ID: <001101c389dc$a8fa6b20$6401a8c0@athlon> I have been a original Forms user for about ten years with an SGI. The Xforms libraries seem to be the logical extension for Xwindows. Though I am not new to Linux, getting Xforms to build under Linux has been troublesome for me and obtaining proper information even more so. Could I get some advice on what version of Linux (Redhat x.x/Mandrake x.x/etc.) best supports what version of Xforms. I tried Redhat 9.0 and got all kind of errors due to the new gcc compiler (3.2) and Mandrake 9.0 supplied the base libraries which I installed but couldn't get the source tools built. How do I get a fully working Xforms environment ? Regards, Dave Strang dstrang at chartermi.net From GalbraithP at dfo-mpo.gc.ca Fri Oct 3 14:40:06 2003 From: GalbraithP at dfo-mpo.gc.ca (Peter S Galbraith) Date: Fri, 03 Oct 2003 14:40:06 -0400 Subject: [XForms] Looking for advice In-Reply-To: Message from "David Strang" <001101c389dc$a8fa6b20$6401a8c0@athlon> References: <001101c389dc$a8fa6b20$6401a8c0@athlon> Message-ID: <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> David Strang wrote: > Though I am not new to Linux, getting Xforms to build under Linux has > been troublesome for me and obtaining proper information even more so. > > Could I get some advice on what version of Linux (Redhat x.x/Mandrake > x.x/etc.) best supports > what version of Xforms. I tried Redhat 9.0 and got all kind of errors due to > the new gcc compiler (3.2) > and Mandrake 9.0 supplied the base libraries which I installed but couldn't > get the source tools built. > > How do I get a fully working Xforms environment ? It's packaged under Debian if that helps. You could install Debian via Knoppix and then install XForms from Debian. Peter From angus.leeming at btopenworld.com Sat Oct 4 13:20:39 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 4 Oct 2003 17:20:39 +0000 Subject: [XForms] Looking for advice In-Reply-To: <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> References: <001101c389dc$a8fa6b20$6401a8c0@athlon> <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> Message-ID: <200310041720.39284.angus.leeming@btopenworld.com> On Friday 03 October 2003 6:40 pm, Peter S Galbraith wrote: > > How do I get a fully working Xforms environment ? > > It's packaged under Debian if that helps. You could install Debian via > Knoppix and then install XForms from Debian. There are also rpms available at ftp://ftp.lyx.org/pub/lyx/contrib/libforms-devel-1.0-release.i386.rpm ftp://ftp.lyx.org/pub/lyx/contrib/libforms-1.0-release.i386.rpm Angus From hiller at mpia-hd.mpg.de Fri Oct 10 09:41:41 2003 From: hiller at mpia-hd.mpg.de (Ulrich Hiller) Date: Fri, 10 Oct 2003 15:41:41 +0200 (MET DST) Subject: [XForms] problems installing on solaris Message-ID: <200310101341.h9ADffR02830@mpisrv.mpia-hd.mpg.de> Hello, we want to install xforms 1.0 on sun sloaris 7 and solaris 9. It fails during the make procedure with the following error message: rm -f libflimage.so.1.0~ LD_RUN_PATH=/systools/misc/xforms/lib /usr/ccs/bin/ld -o libflimage.so.1.0~ -G - z text -M mapfile -h libflimage.so.1.0 image.o image_bmp.o image_combine.o im age_convolve.o image_crop.o image_disp.o image_fits.o image_genesis.o image _gif.o image_gzip.o image_io_filter.o image_jpeg.o image_jquant.o image_mar ker.o image_png.o image_pnm.o image_postscript.o image_proc.o image_replace .o image_rotate.o image_scale.o image_sgi.o image_text.o image_tiff.o imag e_type.o image_warp.o image_xbm.o image_xpm.o image_xwd.o postscript.o ps_ core.o ps_draw.o ps_text.o rgb_db.o matrix.o -L/systools/misc/xforms/lib -l Xext -lX11 -L/usr/local/lib -L../lib -lforms -L/systools/lib -ljpeg -L/systo ols/lib -ltiff Text relocation remains referenced against symbol offset in file 0x28 image_png.o 0x30 image_png.o 0x34 image_png.o 0x38 image_png.o 0x4 image.o [........here are many lines of the same kind..............] jpeg_destroy_compress 0x2b8 image_jpeg.o jpeg_CreateCompress 0x88 image_jpeg.o jpeg_stdio_dest 0x98 image_jpeg.o jpeg_set_defaults 0xf0 image_jpeg.o jpeg_set_quality 0x108 image_jpeg.o jpeg_write_marker 0x140 image_jpeg.o jpeg_write_scanlines 0x284 image_jpeg.o jpeg_finish_compress 0x2a0 image_jpeg.o ld: fatal: relocations remain against allocatable but non-writable sections *** Error code 1 make: Fatal error: Command failed for target `libflimage.so.1.0' Current working directory /disk-b/hiller/xforms-1.0/image making all in ./fdesign... rm -f fdesign LD_RUN_PATH=/systools/misc/xforms/lib cc -o fdesign -g -Xc -xF -xcg92 -L/sys tools/misc/xforms/lib fd_attribs.o fd_control.o fd_fake.o fd_file.o fd_forms .o fd_groups.o fd_help.o fd_initforms.o fd_main.o fd_names.o fd_objects.o fd_pallette.o fd_printC.o fd_rubber.o fd_select.o fd_spec.o fd_super.o fd _util.o sp_browser.o sp_button.o sp_choice.o sp_counter.o sp_dial.o sp_fre eobj.o sp_menu.o sp_pixmap.o sp_positioner.o sp_scrollbar.o sp_slider.o sp _twheel.o sp_xyplot.o -lXext -lX11 -static -L../lib -lforms -L/systools/lib -lXpm -dynamic -lm cc: Warning: illegal option -dynamic cc: -a conflicts with -dy. *** Error code 1 make: Fatal error: Command failed for target `fdesign' Current working directory /disk-b/hiller/xforms-1.0/fdesign making all in ./fd2ps... rm -f fd2ps LD_RUN_PATH=/usr/openwin/lib cc -o fd2ps -g -Xc -xF -xcg92 -L/usr/openwin/li b align.o fd2ps.o flsupport.o image2ps.o load.o papers.o pscol.o psdraw.o psobj.o pstext.o readxpm.o sys.o version.o xbmtops.o xpmtops.o -lXext -lX11 -Bstatic -L../image -lflimage -L../lib -lforms -Bdynamic -lm ild: (argument error) can't find library argument :: -lflimage *** Error code 8 make: Fatal error: Command failed for target `fd2ps' Current working directory /disk-b/hiller/xforms-1.0/fd2ps gmake: *** [all] Error 1 I think the main error is the relocation error (which is propably the reason why libflimage.so is not created). Thnaks in advance for your help. Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg Germany phone +49 6221 528238 fax +49 6221 528246 email hiller at mpia.de PS: For your information: Imakefile looks like this: /* Configuration -- see 00README for details */ /* Fairly important stuff */ #define OptimizationLevel -O4 #define DoWall NO #define BuildShared YES #define StaticLink YES #define BuildGL NO /* Less Important or System Specific */ #define HaveStrerror YES #define HaveSnprintf YES #define HaveFloatH YES #define DoOptimize YES #define BuildDemos NO #define DebugSymbols YES /* * You should only define this if you're running a 64 bit compile * environment on Solaris. */ #define Solaris64Bit NO /* Out in the Tall Weeds */ #define InstallNonstandard YES #define XFormsNonstandardInstallDir /systools/misc/xforms #define NonstandardXpm YES #define XpmIncLoc /systools/include #define XpmLibLoc /systools/lib #define NonstandardTiff YES #define TiffIncLoc /systools/include #define TiffLibLoc /systools/lib #define NonstandardJpeg YES #define JpegIncLoc /systools/include #define JpegLibLoc /systools/lib [the rest was not changed] From sian at sleitch.nildram.co.uk Sun Nov 2 13:09:17 2003 From: sian at sleitch.nildram.co.uk (Sian Leitch) Date: Sun, 2 Nov 2003 18:09:17 +0000 Subject: [XForms] Re: XForms: Future xforms development In-Reply-To: <20021210183511.61780.qmail@web41210.mail.yahoo.com> References: <200212101700.gBAH0SF04956@ncmir.ucsd.edu> <20021210183511.61780.qmail@web41210.mail.yahoo.com> Message-ID: <20031102180917.GD1248@sleitch.nildram.co.uk> On Tue, Dec 10, 2002 at 01:35:11PM -0500, David Scriven wrote: > # To subscribers of the xforms list from David Scriven : > > I suspect that the reason that Angus is not > getting any feedback is that there are very few > of us actively developing under XForms, so you > are not getting the 'critical mass' that drives > development. > > There are all sorts of reasons for this - for > example Red Hat dropped XForms from its > PowerTools because it was not open source (is > there some way to encourage them to add it to > their distro now that it is Open Source?) Also > 0.89 was quite buggy, and its > functionality/reliability varied from platform to > platform and that turned a lot of people off. > > Secondly, if I knew nothing about XForms and > wanted to get started I would probably end up on > the XForms home page, which is horribly out of > date, has broken links and links to 0.89, but > none to version 1. > > My point is that if we want XForms to survive we > have to attract users. We have to make it easy to > for new users to get the software and the > documentation so that they can be up and running > quickly. Well, here is one lurker who is actively developing using Xforms. I am currently designing the Home Finance Program (`hfp') and look forward to using `fdesign' once the filter for Algol 68 is completed (`fdtow68'). Meanwhile, I have written some test progs for various ideas. Regards -- Sian Leitch Software Engineer specialising in Algol 68 Algol 68 for Linux is available from and -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031102/a9c09f7f/attachment-0001.bin From drriddle at qwest.net Wed Nov 5 22:41:54 2003 From: drriddle at qwest.net (Reed Riddle) Date: Wed, 5 Nov 2003 21:41:54 -0600 Subject: [XForms] Problem compiling with Mac OS X Message-ID: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Howdy folks, I'm trying to compile the library under OS X, and I keep running into the following errors when I run the configure script: ** Cannot find xpm.h. Please check that the Xpm library is correctly installed on your system. ** Cannot find libjpeg. Please check that the jpeg library is correctly installed on your system. I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in /sw/lib). I know that the X libraries aren't being seen at all when I compile, as all kinds of errors come up related to X. I also know how to set Linux so that it will find where you have libraries (using ldconfig), but I can't find any information like that for OS X. And, I can't figure out what to change in the configuration files to force it to see the library directories. No, I'm not frustrated... :) Anything that can point me in the right direction to get this to work will be greatly appreciated. Thanks! Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From Todd.Denniston at ssa.crane.navy.mil Thu Nov 6 09:00:19 2003 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu, 06 Nov 2003 09:00:19 -0500 Subject: [XForms] Problem compiling with Mac OS X References: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Message-ID: <3FAA53F3.CBE9476A@ssa.crane.navy.mil> Reed Riddle wrote: > > To subscribers of the xforms list > > Howdy folks, > > I'm trying to compile the library under OS X, and I keep running into > the following errors when I run the configure script: > > ** Cannot find xpm.h. Please check that the Xpm library > is correctly installed on your system. > > ** Cannot find libjpeg. Please check that the jpeg library > is correctly installed on your system. > > I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in /sw/lib). > I know that the X libraries aren't being seen at all when I compile, > as all kinds of errors come up related to X. I also know how to set > Linux so that it will find where you have libraries (using ldconfig), > but I can't find any information like that for OS X. And, I can't > figure out what to change in the configuration files to force it to see > the library directories. > > No, I'm not frustrated... :) Anything that can point me in the right > direction to get this to work will be greatly appreciated. Thanks! > > Reed > Sometimes configure will actually use the 'with-extra...' options --with-extra-lib specify extra library directory --with-extra-inc specify extra include directory though my results with them have been sporadic in other library compiles (LessTif), BTW please report on whether they work for you with xforms, if they don't perhaps someone can fix them. if that does not work try exporting `LIBS=-L/sw/lib` & `INCLUDES=-I/usr/X11R6/lib/X11/` and redo the configure/make After compilation you may have to define `export LD_LIBRARY_PATH=/sw/lib` before running the app, until you can figure out what OS X/BSD's options are for setting default library directories. (Sorry, I have not messed with BSD yet) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From Jean-Marc.Lasgouttes at inria.fr Thu Nov 6 09:13:24 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 06 Nov 2003 15:13:24 +0100 Subject: [XForms] Problem compiling with Mac OS X In-Reply-To: <3FAA53F3.CBE9476A@ssa.crane.navy.mil> (Todd Denniston's message of "Thu, 06 Nov 2003 09:00:19 -0500") References: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> <3FAA53F3.CBE9476A@ssa.crane.navy.mil> Message-ID: >>>>> "Todd" == Todd Denniston writes: >> I know that the X libraries aren't being seen at all when >> I compile, as all kinds of errors come up related to X. Is xmkmf in you PATH? JMarc From dstrang at chartermi.net Mon Nov 10 02:40:51 2003 From: dstrang at chartermi.net (David Strang) Date: Mon, 10 Nov 2003 02:40:51 -0500 Subject: [XForms] Mesa/GL demos Message-ID: <000701c3a75d$f84822a0$6401a8c0@athlon24> Hi: I installed the 1.0 version of the Forms library and everything compiled fine with the replacement of the Imakefile (thanks). What do I need to do to get the Mesa/GL demos (gl, glwin) compiled? I'm running Mandrake 9.1 and it looks like I have the shared Mesa 5.0-3 libraries. The 01README mentions using the gl.c from the demos directory (../FORMS/gl.c ??) and recompiling the libform.* . Also, link libGL.a to libMesaGL.a . I couldn't find a libMesaGL.a . Seems I need a little housekeeping here to resolve the Mesa/GL references in gl.c . Help is appreciated. Regards, Dave Strang From nicolas.castagne at imag.fr Mon Nov 10 04:56:35 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Mon, 10 Nov 2003 10:56:35 +0100 Subject: [XForms] Problem compiling with Mac OS X In-Reply-To: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Message-ID: <2BADD5B7-1364-11D8-BEAF-000393C76CA6@imag.fr> Hi all, Here is the report of the uses I made of XForms on Mac-OS-X last week. I also encountered a few problems with compiling the library. After a few trial, I would encourage MacOS X developpers to use the software tool FINK which is available at http://fink.sourceforge.net/ Fink takes into account the specificities of Mac OS X, which is finally not so much a standard linux (sic), to maintain your environment for software development. Especially, Fink is able to 1) scan your Mac OS X system and show which libraries are installed ; 2) download, compile and instal open source libraries ; especially, it will download any library needed to compile a specific package, if it is not yet installed ; 3) keep up to date your packages, since the download locations of almost every library is known by the software. For example, Fink was able to 1) download 2) compile 3) install automatically the XForms library and ALL the necessary packages, including XPM and OpenGL and 4) recompile all my XForms-Based software in 4 hours... Much better than getting crazy with the syntax of Makefiles, is not it? ;-) All the best, Nicolas Le jeudi, 6 nov 2003, ? 04:41 Europe/Paris, Reed Riddle a ?crit : > To subscribers of the xforms list > > > Howdy folks, > > I'm trying to compile the library under OS X, and I keep running into > the following errors when I run the configure script: > > ** Cannot find xpm.h. Please check that the Xpm library > is correctly installed on your system. > > ** Cannot find libjpeg. Please check that the jpeg library > is correctly installed on your system. > > I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in > /sw/lib). I know that the X libraries aren't being seen at all when I > compile, as all kinds of errors come up related to X. I also know how > to set Linux so that it will find where you have libraries (using > ldconfig), but I can't find any information like that for OS X. And, > I can't figure out what to change in the configuration files to force > it to see the library directories. > > No, I'm not frustrated... :) Anything that can point me in the right > direction to get this to work will be greatly appreciated. Thanks! > > Reed > > ---------------------------------------------------------------------- > Dr. Reed L. Riddle > Associate Director of Whole Earth Telescope Operations > Iowa State University Department of Physics & Astronomy > Email: drriddle at qwest.net > Homepage: http://www3.iitap.iastate.edu/~riddle/ > > "This life has been a test. If it had been an actual life, you would > have received actual instructions on where to go and what to do." > -- Angela Chase, "My so-called life" > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > > ------------------------------------------------------------------------ -------------------------- Dr Nicolas CASTAGNE Researcher, IR de l'ACROE / ICA, Association pour la Cr?ation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Cr?ation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------ -------------------------- From Jean-Marc.Lasgouttes at inria.fr Tue Nov 18 10:30:28 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 Nov 2003 16:30:28 +0100 Subject: [XForms] [PATCH] update the autotools files. Message-ID: A non-text attachment was scrubbed... Name: config.diff.gz Type: application/octet-stream Size: 39175 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031118/13162586/attachment.obj -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: INSTALL Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031118/13162586/attachment.pl From angus.leeming at btopenworld.com Tue Nov 18 17:43:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 Nov 2003 22:43:24 +0000 Subject: [XForms] [PATCH] update the autotools files. In-Reply-To: References: Message-ID: <200311182243.24688.angus.leeming@btopenworld.com> On Tuesday 18 November 2003 3:30 pm, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > Here is a small patch updating the config/ files to what I found on > rh9 Thanks JMarc. They're in... Angus From msz at astrouw.edu.pl Wed Nov 19 05:56:06 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 19 Nov 2003 11:56:06 +0100 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: <200305301057.43750.angus.leeming@btopenworld.com> Message-ID: <20031119105606.GA1903@astrouw.edu.pl> Hi XFormers, I'd like to know what the current status of "file selector double-click" bug is? There were a couple of messages regarding this in May, starting with a patch proposed by Mike Heffner, but the discussion that followed raised some doubts. It ended with following message from Mike: > However, we still have the same problem that the callback is never getting > a ButtonPress event. ;-( > > This weekend I'll try rewriting the file selector's callback using the > fl_set_browser_dblclick_callback(). It seems that might be a much easier > way of approaching this. Mike, did you try the rewrite? If no, is Mike's patch included in any (CVS maybe) version of code? I have some heavily-used XForms apps dating back to ver. 0.88 and I'd like very much to rebuild them with 1.0 (also because of problems with static libraries under RedHat 9) but all users here are quite used to double-clicking in file selector. The problems started already in 0.89 and, sadly, have propagated into 1.0. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:11:46 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:11:46 +0100 Subject: [XForms] Mesa/GL demos In-Reply-To: <000701c3a75d$f84822a0$6401a8c0@athlon24> (David Strang's message of "Mon, 10 Nov 2003 02:40:51 -0500") References: <000701c3a75d$f84822a0$6401a8c0@athlon24> Message-ID: >>>>> "David" == David Strang writes: David> To subscribers of the xforms list Hi: David> I installed the 1.0 version of the Forms library and everything David> compiled fine with the replacement of the Imakefile (thanks). David> What do I need to do to get the Mesa/GL demos (gl, glwin) David> compiled? David> I'm running Mandrake 9.1 and it looks like I have the shared David> Mesa 5.0-3 libraries. David> The 01README mentions using the gl.c from the demos directory David> (../FORMS/gl.c ??) and recompiling the libform.* . Also, link David> libGL.a to libMesaGL.a . David> I couldn't find a libMesaGL.a . The .a library should be in the Mesa-devel package (or whatever it's called). You can probably link to libMesaGL.so with a -lMesaGL directive. David> Seems I need a little housekeeping here to resolve the Mesa/GL David> references in gl.c . What would be insteresting is to know whether it works better in xforms cvs where we have switched to autoconf. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:45:03 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:45:03 +0100 Subject: [XForms] Re: XForms: Towards xforms 1.1 In-Reply-To: <200305212241.04744.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 21 May 2003 22:41:04 +0000") References: <200305212241.04744.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: [OK, this was 6 months ago, but I am cleaning my mailbox...] Angus> I think that NT lib/OS2 os2move.cmd gl/canvas.h are all Angus> redundant (the latter is almost identical to glcanvas.h and Angus> appears to be a historical anachronism. It has certainly never Angus> been installed). Angus> Would anybody object if I removed them? Please remove them. Also, I think lib/Readme should be removed (check first...). Do gl demos still work? (I do not have gl stuff installed here to check...). Also, could you update the NEWS file? We will probably need at least a prerelease of 1.1. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:49:23 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:49:23 +0100 Subject: [XForms] [PATCH] Various stuff Message-ID: A non-text attachment was scrubbed... Name: stuff.diff Type: text/x-patch Size: 6171 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/ac02f299/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 09:38:51 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 15:38:51 +0100 Subject: [XForms] [PATCH] Various stuff In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 19 Nov 2003 12:49:23 +0100") References: Message-ID: >>>>> "Jean-Marc" == Jean-Marc Lasgouttes writes: Jean-Marc> To subscribers of the xforms list This patch updates README Jean-Marc> somewhat, makes ure that the X11 include path is used to Jean-Marc> search for xpm.h (should I do the same for jpeg and/or Jean-Marc> gl?), and fixes small things. Jean-Marc> Please apply. Well, I decided to have a look whether I could use my write access on cvs. Guess what? It just worked ! JMarc From angus.leeming at btopenworld.com Wed Nov 19 16:58:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 21:58:02 +0000 Subject: [XForms] [PATCH] Various stuff In-Reply-To: References: Message-ID: <200311192158.02931.angus.leeming@btopenworld.com> On Wednesday 19 November 2003 2:38 pm, Jean-Marc Lasgouttes wrote: > Jean-Marc> This patch updates README somewhat, > Jean-Marc> makes ure that the X11 include path is used to > Jean-Marc> search for xpm.h (should I do the same for jpeg > Jean-Marc> and/or gl?), and fixes small things. > > Jean-Marc> Please apply. > > Well, I decided to have a look whether I could use my write access on > cvs. Guess what? It just worked ! So starts the slippery slope towards responsibility ;-) Many thanks for doing this. Angus From angus.leeming at btopenworld.com Wed Nov 19 17:49:16 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 22:49:16 +0000 Subject: [XForms] Re: XForms: Towards xforms 1.1 In-Reply-To: References: <200305212241.04744.angus.leeming@btopenworld.com> Message-ID: <200311192249.16531.angus.leeming@btopenworld.com> On Wednesday 19 November 2003 11:45 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > [OK, this was 6 months ago, but I am cleaning my mailbox...] > > Angus> I think that NT lib/OS2 os2move.cmd gl/canvas.h are all > Angus> redundant (the latter is almost identical to glcanvas.h and > Angus> appears to be a historical anachronism. It has certainly never > Angus> been installed). > > Angus> Would anybody object if I removed them? > > Please remove them. Done. Is README.OS2 now redundant too? > Also, I think lib/Readme should be removed (check first...). Checked and then removed. > Do gl demos still work? (I do not have gl stuff installed > here to check...). > > Also, could you update the NEWS file? Hmmm. Yes. This will take some effort but I'll put it on my todo list. > We will probably need at least a prerelease of 1.1. Definitely. Angus From angus.leeming at btopenworld.com Wed Nov 19 18:06:17 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 23:06:17 +0000 Subject: [XForms] Towards a warning-free compilation. Message-ID: <200311192306.17228.angus.leeming@btopenworld.com> I have been trying to reduce the number of warnings when compiling xforms with CFLAGS='-O2 -W -Wall -Wno-unused-parameter -pedantic' That's about as strict as C will allow. There are currently two main groups of warning messages: 'uninitialized variable' (almost all in the declaration of arrays) and 'comparison between signed and unsigned'. Attached is a tentative patch that removes all of the 'uninitialized variable' warnings. I say tentative because xforms tends to use macros such as #define NV(a) (#a,a) to simplify such initializations. Eg: #define NV(a) #a,a static FL_IMAP fl_imap[FL_MAX_COLS] = { {NV(FL_BLACK), 0, 0, 0, 0, 0}, {NV(FL_WHITE), 255, 255, 255, 0, 0}, I have squashed the warnings in the case above by adding the final ', 0, 0' to the decalrations, but I could arguably achieve the same end by extending the definition of the NV macro to: #define NV(a,r,g,b) ({#a,a,r,g,b,0,0}) static FL_IMAP fl_imap[FL_MAX_COLS] = { NV(FL_BLACK, 0, 0, 0), NV(FL_WHITE, 255, 255, 255), Given that NV exists already, would it not be more elegant to do things the second way? I also attach the log of the remaining_warnings and a little sed script that I used to strip most everything but the warnings out from the make log file. $ make > make.log 2>&1 $ sed -f striplog.sed make.log > remaining_warnings.txt You'll see that there are also a couple of warnings about inconsistent declarations in there too... Regards, Angus -------------- next part -------------- /^depfile/d /^depmode/d /^gcc/d /^source/d /^\/bin\/sh/d /^make\[[123]\]/d /^Making all/d /^cp -p/d /^creating/d /^(cd/d /^rm -f/d /^mv -f/d /^ar cru/d /^mkdir/d /^echo timestamp/d /^config.status/d /^cd/d /^make/d -------------- next part -------------- A non-text attachment was scrubbed... Name: remaining_warnings.txt.gz Type: application/x-gzip Size: 1152 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/769cd83b/attachment.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: initialization.diff.gz Type: application/x-gzip Size: 5314 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/769cd83b/attachment-0001.gz From tristan at mpegtv.com Wed Nov 19 20:53:36 2003 From: tristan at mpegtv.com (Tristan Savatier) Date: Wed, 19 Nov 2003 17:53:36 -0800 Subject: [XForms] Towards a warning-free compilation. References: <200311192306.17228.angus.leeming@btopenworld.com> Message-ID: <029501c3af09$1ce8c850$0100a8c0@milk> > I have squashed the warnings in the case above by adding the final ', 0, 0' Normally, any partially initialized global or static structure will be padded with zeros. I think it also applies to arrays (?). so the compiler warnings about 'uninitialized variable' would seem bogus to me... From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 04:20:52 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 10:20:52 +0100 Subject: [XForms] [PATCH] Various stuff In-Reply-To: <200311192158.02931.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 19 Nov 2003 21:58:02 +0000") References: <200311192158.02931.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> So starts the slippery slope towards responsibility ;-) Many Angus> thanks for doing this. Angus Well, we _have_ to get this thing going at least until we can deliver a working autotools-based version. JMarc From angus.leeming at btopenworld.com Thu Nov 20 05:04:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 10:04:02 +0000 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: <029501c3af09$1ce8c850$0100a8c0@milk> References: <200311192306.17228.angus.leeming@btopenworld.com> <029501c3af09$1ce8c850$0100a8c0@milk> Message-ID: <200311201002.50320.angus.leeming@btopenworld.com> On Thursday 20 November 2003 1:53 am, Tristan Savatier wrote: > > I have squashed the warnings in the case above by adding the final ', 0, > Normally, any partially initialized global or static structure will be > padded with zeros. I think it also applies to arrays (?). > so the compiler warnings about 'uninitialized variable' would seem bogus to > me... Maybe, but the fact remains that bogus warnings make it harder to see real warnings. If we can squash warnings (with no run-time effect) then we should. Angus From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 05:30:55 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 11:30:55 +0100 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: <200311201002.50320.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 20 Nov 2003 10:04:02 +0000") References: <200311192306.17228.angus.leeming@btopenworld.com> <029501c3af09$1ce8c850$0100a8c0@milk> <200311201002.50320.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> so the compiler warnings about 'uninitialized variable' would seem >> bogus to me... Angus> Maybe, but the fact remains that bogus warnings make it harder Angus> to see real warnings. If we can squash warnings (with no Angus> run-time effect) then we should. Yes. And I think that the patch that you posted is good enough in this regard. JMarc From angus.leeming at btopenworld.com Thu Nov 20 05:49:30 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 10:49:30 +0000 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: References: <200311192306.17228.angus.leeming@btopenworld.com> <200311201002.50320.angus.leeming@btopenworld.com> Message-ID: <200311201049.30448.angus.leeming@btopenworld.com> On Thursday 20 November 2003 10:30 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > >> > >> so the compiler warnings about 'uninitialized variable' would seem > >> bogus to me... > > Angus> Maybe, but the fact remains that bogus warnings make it harder > Angus> to see real warnings. If we can squash warnings (with no > Angus> run-time effect) then we should. > > Yes. And I think that the patch that you posted is good enough in this > regard. Me too. It's in. Angus From angus.leeming at btopenworld.com Thu Nov 20 07:49:29 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 12:49:29 +0000 Subject: [XForms] [PATCH]: squashing all remaining warnings Message-ID: <200311201249.29064.angus.leeming@btopenworld.com> Attached is a patch to squash all the remaining warnings when compiling with CFLAGS='-W -Wall -Wno-unused-parameter'. All these warnings are 'comparison of signed and unsigned'. I have been pretty careful here and when unsure have erred on the side of caution, casting the unsigned var to signed. Much of the time though I have felt that going the other way was fine (ie, casting the signed var to unsigned). I would value it if someone would take the time to verify that I haven't fubar-ed here. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: signed.diff.gz Type: application/x-gzip Size: 5283 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031120/075bb252/attachment.gz From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 08:49:48 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 14:49:48 +0100 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: <200311201249.29064.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 20 Nov 2003 12:49:29 +0000") References: <200311201249.29064.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Attached is a patch to squash Angus> all the remaining warnings when compiling with CFLAGS='-W -Wall Angus> -Wno-unused-parameter'. All these warnings are 'comparison of Angus> signed and unsigned'. Angus> I have been pretty careful here and when unsure have erred on Angus> the side of caution, casting the unsigned var to signed. Much Angus> of the time though I have felt that going the other way was Angus> fine (ie, casting the signed var to unsigned). And did you find any real problem in the process? Angus> I would value it if someone would take the time to verify that Angus> I haven't fubar-ed here. I took a quick look at the patch and it looks like checking each and every of these is a long process. I won't have time to do it. So if you are confident, just apply the patch. Otherwise, we'll have to live with the warnings :) JMarc From angus.leeming at btopenworld.com Fri Nov 21 04:15:55 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 21 Nov 2003 09:15:55 +0000 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: References: <200311201249.29064.angus.leeming@btopenworld.com> Message-ID: <200311210915.55314.angus.leeming@btopenworld.com> On Thursday 20 November 2003 1:49 pm, Jean-Marc Lasgouttes wrote: > Angus> I would value it if someone would take the time to verify that > Angus> I haven't fubar-ed here. > > I took a quick look at the patch and it looks like checking each and > every of these is a long process. I won't have time to do it. > > So if you are confident, just apply the patch. Otherwise, we'll have > to live with the warnings :) Maybe I'll do it a bit at a time. Adding bugs for the sake of squashing warnings seems like a poor trade off to me ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 04:23:13 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 10:23:13 +0100 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: <200311210915.55314.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 21 Nov 2003 09:15:55 +0000") References: <200311201249.29064.angus.leeming@btopenworld.com> <200311210915.55314.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Maybe I'll do it a bit at a time. Adding bugs for the sake of Angus> squashing warnings seems like a poor trade off to me ;-) Definitely :) JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 05:53:37 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 11:53:37 +0100 Subject: [XForms] [PATCH] squash more warnings Message-ID: A non-text attachment was scrubbed... Name: warnings.diff Type: text/x-patch Size: 4787 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/6949fbf8/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mk.log Type: application/octet-stream Size: 4013 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/6949fbf8/attachment.obj From angus.leeming at btopenworld.com Fri Nov 21 08:28:33 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 21 Nov 2003 13:28:33 +0000 Subject: [XForms] Enabling the building of the demo GL programs Message-ID: <200311211328.33037.angus.leeming@btopenworld.com> Ok, I squashed those warnings about the comparison of signed and unsigned vars that I deemed to be safe to squash. The remaining few can wait till I have more energy ;-) Attached is a patch to enable the building of the demo GL programs. Comments? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-diff Size: 2305 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/c6ab75bc/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 09:08:17 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 15:08:17 +0100 Subject: [XForms] Enabling the building of the demo GL programs In-Reply-To: <200311211328.33037.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 21 Nov 2003 13:28:33 +0000") References: <200311211328.33037.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Ok, I squashed those warnings Angus> about the comparison of signed and unsigned vars that I deemed Angus> to be safe to squash. The remaining few can wait till I have Angus> more energy ;-) Good move. Angus> Attached is a patch to enable the building of the demo GL Angus> programs. Angus> Comments? Looks reasonable. JMarc From msz at astrouw.edu.pl Sun Nov 23 10:35:48 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Sun, 23 Nov 2003 16:35:48 +0100 Subject: [XForms] problem with autoconf in RH9 Message-ID: <20031123153548.GA18821@astrouw.edu.pl> Hi, I've just downloaded the source from CVS depository, using: cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . Contrary to what I found in the INSTALL file, the downloaded tree lacks 'configure' script so I ran "autoconf". Unfortunately, it failed saying: >autoconf configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:14: error: possibly undefined macro: AM_MAINTAINER_MODE configure.ac:17: error: possibly undefined macro: AM_INIT_AUTOMAKE configure.ac:29: error: possibly undefined macro: AM_CONDITIONAL configure.ac:52: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:53: error: possibly undefined macro: AM_PROG_LIBTOOL The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, autoconf-2.57-3, libtool-1.4.3-5. Any ideas, hints? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From drriddle at qwest.net Sun Nov 23 16:22:07 2003 From: drriddle at qwest.net (Reed Riddle) Date: Sun, 23 Nov 2003 15:22:07 -0600 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> I just installed this yesterday on a RedHat 9, with the CVS version, and everything worked just fine. It's a standard RedHat install, nothing modified. Have you changed anything in the system settings, or added/updated any software? Reed On Sunday, November 23, 2003, at 09:35 AM, Michal Szymanski wrote: > To subscribers of the xforms list > > > Hi, > > I've just downloaded the source from CVS depository, using: > > cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login > cvs -z3 -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . > > Contrary to what I found in the INSTALL file, the downloaded tree lacks > 'configure' script so I ran "autoconf". Unfortunately, it failed > saying: > >> autoconf > configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.ac:14: error: possibly undefined macro: AM_MAINTAINER_MODE > configure.ac:17: error: possibly undefined macro: AM_INIT_AUTOMAKE > configure.ac:29: error: possibly undefined macro: AM_CONDITIONAL > configure.ac:52: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL > configure.ac:53: error: possibly undefined macro: AM_PROG_LIBTOOL > > The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, > autoconf-2.57-3, libtool-1.4.3-5. > > Any ideas, hints? > > regards, Michal. > > -- > Michal Szymanski (msz at astrouw.edu.pl) > Warsaw University Observatory, Warszawa, POLAND > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > > ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From msz at astrouw.edu.pl Mon Nov 24 02:49:44 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 08:49:44 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> References: <20031123153548.GA18821@astrouw.edu.pl> <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> Message-ID: <20031124074944.GA829@astrouw.edu.pl> On Sun, Nov 23, 2003 at 03:22:07PM -0600, Reed Riddle wrote: > I just installed this yesterday on a RedHat 9, with the CVS version, > and everything worked just fine. It's a standard RedHat install, > nothing modified. Have you changed anything in the system settings, or > added/updated any software? > >The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, > >autoconf-2.57-3, libtool-1.4.3-5. Well, the system *IS* updated, following RH errata. Could you please check your versions of the RPMs given above? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Mon Nov 24 04:30:59 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 24 Nov 2003 10:30:59 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031123153548.GA18821@astrouw.edu.pl> (Michal Szymanski's message of "Sun, 23 Nov 2003 16:35:48 +0100") References: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> I've just downloaded the source from CVS depository, using: Michal> cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms Michal> login cvs -z3 Michal> -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . Michal> Contrary to what I found in the INSTALL file, the downloaded Michal> tree lacks 'configure' script so I ran "autoconf". Try to run ./autogen.sh instead. JMarc From msz at astrouw.edu.pl Mon Nov 24 10:29:57 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 16:29:57 +0100 Subject: [XForms] JPEG/EXIF support? Message-ID: <20031124152956.GA2504@astrouw.edu.pl> Hi, It seems that JPEG support in XForms 1.0 is only for "standard", JFIF format. I have plenty of JPEG/EXIF "extended" format images from digital camera which I'd like very much to display using XForms. Now, unfortunately, I'm getting messages like: In OpenImage [image.c 224] Guad22.jpg: Unknown image format Is there a simpler way to get them loaded properly than to write my own routines and use "flimage_add_format()"? I mean like using newer JPEG library? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Mon Nov 24 11:41:04 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 24 Nov 2003 17:41:04 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031124152956.GA2504@astrouw.edu.pl> (Michal Szymanski's message of "Mon, 24 Nov 2003 16:29:57 +0100") References: <20031124152956.GA2504@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> It seems that JPEG support in XForms 1.0 is only for Michal> "standard", JFIF format. I have plenty of JPEG/EXIF "extended" Michal> format images from digital camera which I'd like very much to Michal> display using XForms. Now, unfortunately, I'm getting messages Michal> like: Michal> In OpenImage [image.c 224] Guad22.jpg: Unknown image format Where is this JPEG/EXIF thing described? JMarc From msz at astrouw.edu.pl Mon Nov 24 12:28:21 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 18:28:21 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: References: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: <20031124172821.GA9534@astrouw.edu.pl> On Mon, Nov 24, 2003 at 10:30:59AM +0100, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > > >>>>> "Michal" == Michal Szymanski writes: > > Michal> To subscribers of the xforms list Hi, > > Michal> I've just downloaded the source from CVS depository, using: > > Michal> cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms > Michal> login cvs -z3 > Michal> -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . > > Michal> Contrary to what I found in the INSTALL file, the downloaded > Michal> tree lacks 'configure' script so I ran "autoconf". > > Try to run ./autogen.sh instead. Thanks, it worked. I guess it might be worth putting into INSTALL file which now is somewhat misleading. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From msz at astrouw.edu.pl Mon Nov 24 13:07:06 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 19:07:06 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: References: <20031124152956.GA2504@astrouw.edu.pl> Message-ID: <20031124180705.GB9534@astrouw.edu.pl> On Mon, Nov 24, 2003 at 05:41:04PM +0100, Jean-Marc Lasgouttes wrote: > >>>>> "Michal" == Michal Szymanski writes: > > Michal> To subscribers of the xforms list Hi, > > Michal> It seems that JPEG support in XForms 1.0 is only for > Michal> "standard", JFIF format. I have plenty of JPEG/EXIF "extended" > Michal> format images from digital camera which I'd like very much to > Michal> display using XForms. Now, unfortunately, I'm getting messages > Michal> like: > > Michal> In OpenImage [image.c 224] Guad22.jpg: Unknown image format > > Where is this JPEG/EXIF thing described? A quick search on the net resulted in following: EXIF stands for Exchangeable Image File Format, and is a standard for storing interchange information in image files, especially those using JPEG compression. Most digital cameras now use the EXIF format. The format is part of the DCF standard created by JEIDA to encourage interoperability between imaging devices. >From what I could quickly find, EXIF data in a JPEG file is stored in an application segment APP1. It seems that JPEG standard supports such segments - I'm not sure why the JPEG code in XForms can't deal with such images (if they really conform to JPEG standard, as it seems). Links: http://www.exif.org/ and links therein, of which one is particularly good: http://park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Mon Nov 24 14:51:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 24 Nov 2003 19:51:26 +0000 Subject: [XForms] Getting rid of auto-generated files... Message-ID: <200311241951.26091.angus.leeming@btopenworld.com> It would be nice if we could get rid of at least some of the .[ch] files generated from .fd datasets. We store .fd files and their associated .[ch] files in the following directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, the .[ch] files in the first two directories would have to remain. (We cannot generate the .[ch] files until fdesign has bee created.) However, it strikes me that the .[ch] files in the remaining directories could all be generated on the fly, just as we do in LyX. Personally, I think that this would be much more elegant. Thoughts? Angus From xforms2 at vjet.demon.co.uk Mon Nov 24 18:43:41 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Mon, 24 Nov 2003 23:43:41 GMT Subject: [XForms] JPEG/EXIF support? Message-ID: <200311242343.hAONhf36001050@vjet.demon.co.uk> Hi, > It seems that JPEG support in XForms 1.0 is only for "standard", JFIF > format. I have plenty of JPEG/EXIF "extended" format images from digital > camera which I'd like very much to display using XForms. > Now, unfortunately, I'm getting messages like: > > In OpenImage [image.c 224] Guad22.jpg: Unknown image format A long time ago I did a patch to improve some stuff in the image handling.. It got lost in the move to 1.0 But I can read images off my camera so it may solve your problem too.. Patch is at http://www.vjet.demon.co.uk/xforms/image.patch It probably needs massaging to work on the latest CVS. It fixes a bug in flimage_dup() , one in image rotate, and makes jpeg + gif reading better. These patches are applied to my 1.0 rpms too (http://www.vjet.demon.co.uk/xforms) HTHs Cheers Clive From mheffner at vt.edu Tue Nov 25 09:27:24 2003 From: mheffner at vt.edu (Mike Heffner) Date: Tue, 25 Nov 2003 09:27:24 -0500 (EST) Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <20031119105606.GA1903@astrouw.edu.pl> Message-ID: On 19-Nov-2003 Michal Szymanski wrote: > To subscribers of the xforms list > >> >> This weekend I'll try rewriting the file selector's callback using the >> fl_set_browser_dblclick_callback(). It seems that might be a much >> easier >> way of approaching this. > > Mike, did you try the rewrite? Nope, unfortunately life got in the way. :) I should have some free time this week to look at it again. Cheers, Mike -- Mike Heffner From angus.leeming at btopenworld.com Tue Nov 25 16:09:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 25 Nov 2003 21:09:26 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311242343.hAONhf36001050@vjet.demon.co.uk> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> Message-ID: <200311252109.26767.angus.leeming@btopenworld.com> On Monday 24 November 2003 11:43 pm, Clive A Stubbings wrote: > A long time ago I did a patch to improve some stuff in the image > handling.. It got lost in the move to 1.0 > > But I can read images off my camera so it may solve your problem too.. > Patch is at http://www.vjet.demon.co.uk/xforms/image.patch Got it. > It probably needs massaging to work on the latest CVS. It fixes a bug in > flimage_dup() , I'm not going to apply this without some discussion. Feel free to explain the rationale. > one in image rotate. I don't see the need for this. See the comment immediately preceeding your patched code. In cvs at least. /* * Now coerce it into +/- 180. */ > and makes jpeg + gif reading better. I've applied both these parts to my local tree, albeit with some re-factoring to get rid of the goto and some signed-unsigned comparson warnings. Could you check to see that all is still as you intended (attached). If you could cast your eye over the ChangeLog entry and maybe rename 'flush_buffer' to something that makes sense to you, that'd be great too... Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: clive.diff Type: text/x-diff Size: 3888 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031125/dead5e72/attachment.bin From angus.leeming at btopenworld.com Tue Nov 25 17:56:45 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 25 Nov 2003 22:56:45 +0000 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311241951.26091.angus.leeming@btopenworld.com> References: <200311241951.26091.angus.leeming@btopenworld.com> Message-ID: <200311252256.45141.angus.leeming@btopenworld.com> On Monday 24 November 2003 7:51 pm, Angus Leeming wrote: > To subscribers of the xforms list > > > It would be nice if we could get rid of at least some of the .[ch] files > generated from .fd datasets. > > We store .fd files and their associated .[ch] files in the following > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, > the .[ch] files in the first two directories would have to remain. (We > cannot generate the .[ch] files until fdesign has bee created.) However, it > strikes me that the .[ch] files in the remaining directories could all be > generated on the fly, just as we do in LyX. > > Personally, I think that this would be much more elegant. Thoughts? Ok, I'm stuck ;-) Jean-Marc, I wonder if you might help... Attached are the changes I've made to demos/Makefile.am. This is proof of concept code and, indeed, works fine. However, I have no idea how to turn it into robust code :-( The problem lies with the block below which generates .[ch] files from a .fd file. Note that I am running this conversion from $build_dir/demos whilst the .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do not want to generate a static library in the fd directory because I want to be able to build individual demo files if I so choose. Here's the troublesome (but working) block: %.c: %.fd ../fdesign/fdesign (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign -convert `basename $<`; \ mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.) Line 1. All is Ok. The generated .c file depends on the .fd file and on the existence of the fdesign binary. %.c: %.fd ../fdesign/fdesign Lines 2,3. The problems. It appears that fdesign must be run from the directory containing the .fd file. That means I lose track of the fdesign binary and then must move the generated .[ch] files into the $builddir tree (if $srcdir != $builddir). Any ideas? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos_makefile.am Type: text/x-diff Size: 1081 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031125/bd54bf1f/attachment.bin From msz at astrouw.edu.pl Wed Nov 26 03:26:09 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 26 Nov 2003 09:26:09 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311252109.26767.angus.leeming@btopenworld.com> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> Message-ID: <20031126082609.GA9882@astrouw.edu.pl> On Tue, Nov 25, 2003 at 09:09:26PM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > On Monday 24 November 2003 11:43 pm, Clive A Stubbings wrote: > > A long time ago I did a patch to improve some stuff in the image > > handling.. It got lost in the move to 1.0 > > > > But I can read images off my camera so it may solve your problem too.. > > Patch is at http://www.vjet.demon.co.uk/xforms/image.patch > > Got it. > > > It probably needs massaging to work on the latest CVS. It fixes a bug in > > flimage_dup() , > > I'm not going to apply this without some discussion. Feel free to explain the > rationale. Hi, I did not go into details but downloaded Clive's patched versions of the 1.0 libs and indeed, my application started to read JPEG/EXIF images from my digital camera without any modification, just relinking. So I'd strongely vote for including the patch(es) into XForms. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Wed Nov 26 05:43:16 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 10:43:16 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031126082609.GA9882@astrouw.edu.pl> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> <20031126082609.GA9882@astrouw.edu.pl> Message-ID: <200311261043.16110.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 8:26 am, Michal Szymanski wrote: > Hi, > > I did not go into details but downloaded Clive's patched versions of the > 1.0 libs and indeed, my application started to read JPEG/EXIF images > from my digital camera without any modification, just relinking. So I'd > strongely vote for including the patch(es) into XForms. Could you revert Clive's patch and try the one I appended in my original reply to his posting? This patch contains the jpeg and gif enhancements and I am more than happy to merge it into the xforms sources. Angus From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 06:54:12 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 12:54:12 +0100 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311252256.45141.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 25 Nov 2003 22:56:45 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. So we could maybe take a look at fixing fdesign, since we have control on it :) Another solution would be to have a Makefile.am in the fd/ directories, maybe. Sorry, I do not have much time to think about it right now. I think this is something that we could leave for after 1.1. I'd like to concentrate on this first. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 08:37:15 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 14:37:15 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 26 Nov 2003 12:54:12 +0100") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-patch Size: 1726 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/d3e34718/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: fddiff.diff Type: text/x-patch Size: 2840 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/d3e34718/attachment-0001.bin From angus.leeming at btopenworld.com Wed Nov 26 08:49:43 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 13:49:43 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> Message-ID: <200311261349.43597.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 1:37 pm, Jean-Marc Lasgouttes wrote: > Angus> Lines 2,3. The problems. It appears that fdesign must be run > Angus> from the directory containing the .fd file. > > Jean-Marc> So we could maybe take a look at fixing fdesign, since we > Jean-Marc> have control on it :) > > The following patch fixes fdesign -convert for me. My problem was that > I have a "." in my homedir name (/afs/inria.fr/...). Does it help you? If it works for you, then I expect that it will work for me. I'll try it out this evening. > Could you re-read the patch to make sure I did not make a mistake? I > think using filename instead of fname is the right thing to do here. > > With this patch applied, I get the following diff on a sample fd file. > So the difference is: > > 1/ the LGPL notice is gone. Is this a big problem? No. These are generated files. If we really, really want an LGPL notice, the place to put it is in the .fd file. In turn that means enabling fdesign to handle comments in its .fd files. Something for the future, maybe, but not something to worry about now. > 2/ we have > -#include "include/forms.h" > +#include "forms.h" > I think this will be solved by using -I$(top_srcdir}/lib/include in > INCLUDES. Sure. > Note also that fdesign now adds > +/** Header file generated with fdesign on Wed Nov 26 14:25:19 2003.**/ > but only to the header (not the .c file). We should probably remove > this altogether, since it creates useless diffs. Agreed. > What do you think? I think that I like it when you claim to be 'too busy to think' ;-) Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 08:55:57 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 14:55:57 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311261349.43597.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 13:49:43 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 1:37 pm, Jean-Marc Lasgouttes wrote: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. >> Jean-Marc> So we could maybe take a look at fixing fdesign, since we Jean-Marc> have control on it :) >> The following patch fixes fdesign -convert for me. My problem was >> that I have a "." in my homedir name (/afs/inria.fr/...). Does it >> help you? Angus> If it works for you, then I expect that it will work for me. Angus> I'll try it out this evening. I'm not sure because my problem was really a "." in path. I did not see one in your path names. >> What do you think? Angus> I think that I like it when you claim to be 'too busy to think' Angus> ;-) Regards, Angus I was pointing at your convoluted makefile rules. Note that I did not propose to fix them :) The fdesign problem, OTOH is definitely a bug that should be fixed before 1.1. JMarc From angus.leeming at btopenworld.com Wed Nov 26 09:08:29 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:08:29 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> Message-ID: <200311261408.29034.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 1:55 pm, Jean-Marc Lasgouttes wrote: > The fdesign problem, OTOH is definitely a bug that should be fixed > before 1.1. The little wrapper script, attached, gives us the functionality that I think that fdesign should have. Usage: $ sh fdesign2c The only problem with the script is in the lst line: # If ${SRCDIR} != ${DESTDIR} then # move the generated .[ch] files to ${DESTDIR}. mv -f `basename ${FDFILE} .fd`.[ch] ${DESTDIR} I have no idea how to test that ${SRCDIR} != ${DESTDIR}. Consequently, I get errors: mv: `butttypes_gui.c' and `/home/angus/xforms/xforms/build/demos/../../demos/fd/butttypes_gui.c' are the same file mv: `butttypes_gui.h' and `/home/angus/xforms/xforms/build/demos/../../demos/fd/butttypes_gui.h' are the same file Any ideas? Angus ps, once this is working, then modifying Makefile.am is a snip. Equally, it should provide the template to modify fdesign itself. I'd imagine using fdesign as $ fdesign -convert A -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign2c Type: application/x-shellscript Size: 1216 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/ea9449d5/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 09:16:03 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 15:16:03 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311261408.29034.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 14:08:29 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> <200311261408.29034.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 1:55 pm, Jean-Marc Lasgouttes wrote: >> The fdesign problem, OTOH is definitely a bug that should be fixed >> before 1.1. Angus> The little wrapper script, attached, gives us the functionality Angus> that I think that fdesign should have. Angus> Usage: $ sh fdesign2c Angus> With my fix, fdesign is able to output .[ch] files in the directory where the .fd file was. Isn't it really good enough for now? Angus> ps, once this is working, then modifying Makefile.am is a snip. Angus> Equally, it should provide the template to modify fdesign Angus> itself. I'd imagine using fdesign as $ fdesign -convert Angus> Why would the Makefile.am not work with the fixed fdesign? Because you do not want the .[ch] files to appear in the source directory, but the build directory? JMarc From angus.leeming at btopenworld.com Wed Nov 26 09:21:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:21:26 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261408.29034.angus.leeming@btopenworld.com> Message-ID: <200311261421.26649.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 2:16 pm, Jean-Marc Lasgouttes wrote: > Angus> ps, once this is working, then modifying Makefile.am is a snip. > Angus> Equally, it should provide the template to modify fdesign > Angus> itself. I'd imagine using fdesign as $ fdesign -convert > Angus> > > Why would the Makefile.am not work with the fixed fdesign? Because you > do not want the .[ch] files to appear in the source directory, but the > build directory? Correct. However, I will indeed try and make things work with your patched fdesign too. Angus From Todd.Denniston at ssa.crane.navy.mil Wed Nov 26 09:21:47 2003 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Wed, 26 Nov 2003 09:21:47 -0500 Subject: [XForms] Getting rid of auto-generated files... References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: <3FC4B6FB.B727860E@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > ------------------------------------------------------------------------ > On Monday 24 November 2003 7:51 pm, Angus Leeming wrote: > > To subscribers of the xforms list > > > > > > It would be nice if we could get rid of at least some of the .[ch] files > > generated from .fd datasets. > > > > We store .fd files and their associated .[ch] files in the following > > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, > > the .[ch] files in the first two directories would have to remain. (We > > cannot generate the .[ch] files until fdesign has bee created.) However, it > > strikes me that the .[ch] files in the remaining directories could all be > > generated on the fly, just as we do in LyX. > > > > Personally, I think that this would be much more elegant. Thoughts? > > Ok, I'm stuck ;-) > > Jean-Marc, I wonder if you might help... Attached are the changes I've made to > demos/Makefile.am. This is proof of concept code and, indeed, works fine. > However, I have no idea how to turn it into robust code :-( > > The problem lies with the block below which generates .[ch] files from a .fd > file. Note that I am running this conversion from $build_dir/demos whilst the > .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do > not want to generate a static library in the fd directory because I want to > be able to build individual demo files if I so choose. > > Here's the troublesome (but working) block: > > %.c: %.fd ../fdesign/fdesign > (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign > -convert `basename $<`; \ > mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.) > > Line 1. All is Ok. The generated .c file depends on the .fd file and on the > existence of the fdesign binary. > %.c: %.fd ../fdesign/fdesign > > Lines 2,3. The problems. It appears that fdesign must be run from the > directory containing the .fd file. That means I lose track of the fdesign > binary and then must move the generated .[ch] files into the $builddir tree > (if $srcdir != $builddir). > > Any ideas? > Angus Actually, fdesign does not need to be ran from the directory containing the .fd file. You can pass it the path to the .fd, as in `fdesign -convert $<`, however fdesign as built now will make the .[ch] files in the same directory as the .fd file. perhaps you can/should use the gnu-make extension of vpath's, i.e., have the following added to the beginning of the demo's directory Makefile: vpath %.h . vpath %.c . vpath %.h ./fd vpath %.c ./fd vpath %.fd ./fd at least when vpath is available. a fallback, for non gnu makes, might be to make a rule that causes a `cp -p *.fd .` to occur if any file is newer in the fd directory than say the 'fdscopied' file, i.e., make fdscopied depend on all .fd files in the fd directory. Ugly but I am pretty sure I have used it in the past with other recalcitrant programs. At a later time it would be nice to have an option to pass to fdesign to either force it to output in the current working directory, or another specified output directory. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From angus.leeming at btopenworld.com Wed Nov 26 09:32:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:32:19 +0000 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <3FC4B6FB.B727860E@ssa.crane.navy.mil> References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> <3FC4B6FB.B727860E@ssa.crane.navy.mil> Message-ID: <200311261432.19460.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 2:21 pm, Todd Denniston wrote: Hi, Todd. > Actually, fdesign does not need to be ran from the directory containing > the .fd file. > You can pass it the path to the .fd, as in `fdesign -convert $<`, > however fdesign as built now will make the .[ch] files in the same > directory as the .fd file. Jean-Marc says that this works only so long as the path to the .fd file does not contain any '.'. See his patch. > perhaps you can/should use the gnu-make extension of vpath's, i.e., have > the following added to the beginning of the demo's directory Makefile: Hacks to work round a broken fdesign. Let's fix fdesign instead. > At a later time it would be nice to have an option to pass to fdesign to > either force it to output in the current working directory, or another > specified output directory. $ fdesign -d -convert ../foo/bar/your_file.fd That's what I'd like to get working. Angus From tacorner at chello.at Wed Nov 26 11:10:04 2003 From: tacorner at chello.at (tacorner at chello.at) Date: Wed, 26 Nov 2003 17:10:04 +0100 (CET) Subject: [XForms] Font selector widget Message-ID: I am thinking about writing a font selection widget for xfmail using xforms. Does such a thing exist in xforms itself or another xforms applications? Any suggestions? Tom Corner --------------------------------------------------- |\/\/\___/\/\/| Carol Anne Corner & \____ o o ____/ Thomas Corner ) ( 26-Nov-2003 17:06:59 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --------------------------------------------------- From msz at astrouw.edu.pl Wed Nov 26 17:06:24 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 26 Nov 2003 23:06:24 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311261043.16110.angus.leeming@btopenworld.com> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> <20031126082609.GA9882@astrouw.edu.pl> <200311261043.16110.angus.leeming@btopenworld.com> Message-ID: <20031126220624.GA11680@astrouw.edu.pl> On Wed, Nov 26, 2003 at 10:43:16AM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > On Wednesday 26 November 2003 8:26 am, Michal Szymanski wrote: > > Hi, > > > > I did not go into details but downloaded Clive's patched versions of the > > 1.0 libs and indeed, my application started to read JPEG/EXIF images > > from my digital camera without any modification, just relinking. So I'd > > strongely vote for including the patch(es) into XForms. > > Could you revert Clive's patch and try the one I appended in my original reply > to his posting? This patch contains the jpeg and gif enhancements and I am > more than happy to merge it into the xforms sources. I've applied your version of Clive's patch to my home CVS source tree. The Changelog patch got rejected but both "image" patches succeeded. And my application reading images can now read JPEG/EXIF files taken from my digital camera. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From xforms2 at vjet.demon.co.uk Wed Nov 26 21:27:21 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Thu, 27 Nov 2003 02:27:21 GMT Subject: [XForms] Re: JPEG/EXIF support? Message-ID: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> Thanks Angus, > > It probably needs massaging to work on the latest CVS. It fixes a bug in > > flimage_dup() , > > I'm not going to apply this without some discussion. Feel free to explain the > rationale. Well, its a while ago, but if memory serves, I found that if I dup'd an image then later free'd both copies I got a crash. The crash was because the first free also closed the files and the second one tried to do the same again, but the fp's were no longer valid. There needs to be only one reference to the fp.. Either it goes in a shared struct that both 'images' point to, or only one image can be associated with the file. I'm not sure that 2 'images' and one file really makes sense anyway. FWIW: I duped the image because I wanted to have the original and a processed copy, so I made a dup and then processed it.. When I'd finished with both images I free'd both.. Seemed reasonable to me. > > > one in image rotate. > > I don't see the need for this. See the comment immediately preceeding your > patched code. In cvs at least. > /* > * Now coerce it into +/- 180. > */ You're right - this one was broken in the 1.0 candidates and fixed in 1.0.. (Sorry..) > > > and makes jpeg + gif reading better. > > I've applied both these parts to my local tree, albeit with some re-factoring > to get rid of the goto and some signed-unsigned comparson warnings. Could you > check to see that all is still as you intended (attached). If you could cast > your eye over the ChangeLog entry and maybe rename 'flush_buffer' to > something that makes sense to you, that'd be great too... Had a fair look at it - seems OK on paper. flush_buffer is fine. The function flushes completed lines from the working buffer. (If you don't like the goto, with hindsight, an else might have been better ;-) Cheers Clive From tacorner at chello.at Thu Nov 27 03:05:52 2003 From: tacorner at chello.at (tacorner at chello.at) Date: Thu, 27 Nov 2003 09:05:52 +0100 (CET) Subject: [XForms] xforms cvs access Message-ID: Another question: Is it possible to get read-only access to the xforms cvs? Thanks, Tom Corner --------------------------------------------------- |\/\/\___/\/\/| Carol Anne Corner & \____ o o ____/ Thomas Corner tacorner at chello.at ) ( 27-Nov-2003 09:04:25 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --------------------------------------------------- From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 04:54:05 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 10:54:05 +0100 Subject: [XForms] xforms cvs access In-Reply-To: (tacorner@chello.at's message of "Thu, 27 Nov 2003 09:05:52 +0100 (CET)") References: Message-ID: >>>>> "tacorner" == tacorner writes: tacorner> To subscribers of the xforms list Another question: Is it tacorner> possible to get read-only access to the xforms cvs? Yes. Look here: https://savannah.nongnu.org/cvs/?group=xforms JMarc From angus.leeming at btopenworld.com Thu Nov 27 05:22:42 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 10:22:42 +0000 Subject: [XForms] xforms cvs access In-Reply-To: References: Message-ID: <200311271022.42662.angus.leeming@btopenworld.com> On Thursday 27 November 2003 8:05 am, tacorner at chello.at wrote: Hi, Tom > Another question: Is it possible to get read-only access to the xforms > cvs? Certainly. See http://savannah.nongnu.org/cvs/?group=xforms In summary cvs -d :pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms co xforms Thereafter, shove this in .cvsrc in your home directory: diff -upN rdiff -upN update -dP and "cvs up" should keep you up-to-date. Regards, Angus From angus.leeming at btopenworld.com Thu Nov 27 05:23:41 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 10:23:41 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031126220624.GA11680@astrouw.edu.pl> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311261043.16110.angus.leeming@btopenworld.com> <20031126220624.GA11680@astrouw.edu.pl> Message-ID: <200311271023.41446.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 10:06 pm, Michal Szymanski wrote: > > Could you revert Clive's patch and try the one I appended in my original > > reply to his posting? This patch contains the jpeg and gif enhancements > > and I am more than happy to merge it into the xforms sources. > > I've applied your version of Clive's patch to my home CVS source tree. > The Changelog patch got rejected but both "image" patches succeeded. And > my application reading images can now read JPEG/EXIF files taken from my > digital camera. Then I shall commit it. Many thanks to you both, Angus From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 05:40:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 11:40:20 +0100 Subject: [XForms] Font selector widget In-Reply-To: (tacorner@chello.at's message of "Wed, 26 Nov 2003 17:10:04 +0100 (CET)") References: Message-ID: >>>>> "tacorner" == tacorner writes: tacorner> To subscribers of the xforms list I am thinking about tacorner> writing a font selection widget for xfmail using xforms. tacorner> Does such a thing exist in xforms itself or another xforms tacorner> applications? Any suggestions? I do not know of any... However, an idea would be to try to track the version 2.x of xfce (www.xfce.org) which is a desktop environment (like cde). Versions 1.x and 2.x where based on xforms (whence the name) and I would expect that there is a lot of xforms code to take from there (including a font chooser, maybe). [Later] I have now tracked down a copy: http://www-rocq.inria.fr/~lasgoutt/xfce-2.4.0.tar.gz Unfortunately, there does not seem to be a font chooser in it. However it may be worth looking if there some reusable widgets in the code (the license is not GPL-compatible, but I would be surprised if the author did not allow for a license change on such an old software). JMarc From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 06:32:05 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 12:32:05 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311271023.41446.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 10:23:41 +0000") References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311261043.16110.angus.leeming@btopenworld.com> <20031126220624.GA11680@astrouw.edu.pl> <200311271023.41446.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 10:06 pm, Michal Szymanski wrote: >> > Could you revert Clive's patch and try the one I appended in my >> original > reply to his posting? This patch contains the jpeg and >> gif enhancements > and I am more than happy to merge it into the >> xforms sources. >> >> I've applied your version of Clive's patch to my home CVS source >> tree. The Changelog patch got rejected but both "image" patches >> succeeded. And my application reading images can now read JPEG/EXIF >> files taken from my digital camera. Angus> Then I shall commit it. Many thanks to you both, Angus tru64 cc does not think that this code is OK: cc -std1 -DHAVE_CONFIG_H -I. -I../../xforms/image -I../lib -DMAKING_FORMS -I../lib -I../../xforms/lib -I/afs/rocq/home/preval/common/include -I/usr/local/include -g -c -MD ../../xforms/image/image_gif.c -DPIC -o .libs/image_gif.lo cc: Warning: ../../xforms/image/image_gif.c, line 672: The scalar variable "incode" is fetched but not initialized. (uninit1) flush_buffer(im, incode); -------------------------^ Indeed, if I read process_lzw_code correctly, the variable incode is not always initialized. Since I do not understand what it stands for, I cannot propose a fix, but obviously this needs to be fixed in some way. JMarc From angus.leeming at btopenworld.com Thu Nov 27 06:49:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 11:49:24 +0000 Subject: [XForms] Re: JPEG/EXIF support? In-Reply-To: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> References: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> Message-ID: <200311271149.24457.angus.leeming@btopenworld.com> On Thursday 27 November 2003 2:27 am, Clive A Stubbings wrote: > > > It fixes a bug in flimage_dup() , > > > > I'm not going to apply this without some discussion. Feel free to explain > > the rationale. > > Well, its a while ago, but if memory serves, I found that if I dup'd an > image then later free'd both copies I got a crash. The crash was because > the first free also closed the files and the second one tried to do the > same again, but the fp's were no longer valid. > > There needs to be only one reference to the fp.. Either it goes in a > shared struct that both 'images' point to, or only one image can be > associated with the file. I'm not sure that 2 'images' and one file > really makes sense anyway. > > FWIW: I duped the image because I wanted to have the original and a > processed copy, so I made a dup and then processed it.. When I'd > finished with both images I free'd both.. Seemed reasonable to me. And to me too. I do something similar in LyX. Here are the relvant parts of my wrapper class. My question to you is, "why doesn't this trigger the crash"? If I make two copies of the image and then invoke flimage_free in the destructor, why don't I run into your problem? class xformsImage { public: xformsImage(): image_(0) {} xformsImage(xformsImage const & other) : image_(0) { if (other.image_) { image_ = flimage_dup(other.image_); image_->u_vdata = this; } } ~xformsImage() { if (image_) flimage_free(image_); } private: /// The xforms container. FL_IMAGE * image_; }; Ahhhhhhh. Because I use a callback function to monitor the loading process and explicitly close the FILE pointers when loading is complete. void xformsImage::statusCB(string const & status_message) { if (status_message.empty()) return; if (prefixIs(status_message, "Done Reading")) { if (image_) flimage_close(image_); finishedLoading(true); } } Anyway, I see the need for your patch or for something like it. Perhaps it would be better to not copy the file pointers in flimage_dup in the first place? Hmmmmmmmm. flimage_dup does NOT copy the FILE pointers. The only place that they are set is in identify_image which in turn is invoked only by flimage_open (in turn invoked by flimage_load). The point is that flimage_dup does not invoke any of these routines. Conclusion: I don't see the need for the patch. No doubt I've got my logic wrong somewhere, so I'd be grateful if you'd have a look at the current xforms sources too... > > > and makes jpeg + gif reading better. > > > > I've applied both these parts to my local tree, albeit with some > > re-factoring to get rid of the goto and some signed-unsigned comparson > > warnings. Could you check to see that all is still as you intended > > (attached). If you could cast your eye over the ChangeLog entry and maybe > > rename 'flush_buffer' to something that makes sense to you, that'd be > > great too... > > Had a fair look at it - seems OK on paper. flush_buffer is fine. The > function flushes completed lines from the working buffer. And Michal says it works, so I have committed it. Many thanks for the patch. > (If you don't like the goto, with hindsight, an else might have been better > ;-) Let's just say I have a pathological hatred of 'goto'. Something to do with maintaining some old Fortran66 code. Regards, Angus From angus.leeming at btopenworld.com Thu Nov 27 07:00:59 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 12:00:59 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311271023.41446.angus.leeming@btopenworld.com> Message-ID: <200311271200.59974.angus.leeming@btopenworld.com> On Thursday 27 November 2003 11:32 am, Jean-Marc Lasgouttes wrote: > Angus> Then I shall commit it. Many thanks to you both, Angus > > tru64 cc does not think that this code is OK: > > cc -std1 -DHAVE_CONFIG_H -I. -I../../xforms/image -I../lib -DMAKING_FORMS > -I../lib -I../../xforms/lib -I/afs/rocq/home/preval/common/include > -I/usr/local/include -g -c -MD ../../xforms/image/image_gif.c -DPIC -o > .libs/image_gif.lo cc: Warning: ../../xforms/image/image_gif.c, line 672: > The scalar variable "incode" is fetched but not initialized. (uninit1) > flush_buffer(im, incode); > -------------------------^ > > Indeed, if I read process_lzw_code correctly, the variable incode is > not always initialized. Since I do not understand what it stands for, > I cannot propose a fix, but obviously this needs to be fixed in some > way. Reading the code again static void flush_buffer(FL_IMAGE * im, int incode) { int i; incode = lbuf - lhead; ... Ie, the first thing that is done in flush_buffer is set incode. So, we have two options: * do not pass incode to the routine and have a local variable instead * pass a pointer to incode. Since the variable incode in process_lzw_code is not static and flush_buffer is the last thing called before returning from process_lzw_code, I think that the first option is sufficient. See attached patch. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: image_giff.diff Type: text/x-diff Size: 1028 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/99303652/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 07:56:17 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 13:56:17 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311271200.59974.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 12:00:59 +0000") References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311271023.41446.angus.leeming@btopenworld.com> <200311271200.59974.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Ie, the first thing that is done in flush_buffer is set incode. Angus> So, we have two options: * do not pass incode to the routine Angus> and have a local variable instead * pass a pointer to incode. Angus> Since the variable incode in process_lzw_code is not static and Angus> flush_buffer is the last thing called before returning from Angus> process_lzw_code, I think that the first option is sufficient. Angus> See attached patch. You are right. JMarc From angus.leeming at btopenworld.com Thu Nov 27 10:23:00 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 15:23:00 +0000 Subject: [XForms] NEWS update Message-ID: <200311271523.00688.angus.leeming@btopenworld.com> As requested... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: news.diff Type: text/x-diff Size: 1451 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/d2c2afb8/attachment.bin From angus.leeming at btopenworld.com Wed Nov 26 11:42:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 16:42:19 +0000 Subject: [XForms] Adding '-dir ' to fdesign Message-ID: <200311261642.19472.angus.leeming@btopenworld.com> See attached. The patch also contains JMarc's changes to fd_forms.c. The only bit I'm unsure about are the initializations in static FL_CMD_OPT fd_cmdopt[] and in static FL_resource fdres[] The rest seems pretty straightforward. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 6372 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/3880bca1/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 11:08:14 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 17:08:14 +0100 Subject: [XForms] Adding '-dir ' to fdesign In-Reply-To: <200311261642.19472.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 16:42:19 +0000") References: <200311261642.19472.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list See attached. The patch also Angus> contains JMarc's changes to fd_forms.c. Wow. This one needed 23 hours to appear... JMarc From angus.leeming at btopenworld.com Thu Nov 27 11:26:57 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 16:26:57 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms/fdesign fd_forms.c fd_main.c fd_main.h f... In-Reply-To: References: Message-ID: <200311271626.57490.angus.leeming@btopenworld.com> On Thursday 27 November 2003 3:41 pm, Jean-Marc Lasgouttes wrote: > Angus> Log message: Give fdesign a -dir option. > > I see you've been busy... Well, not sooooooo busy. > +static char const * > +filename_only(char const * filename) > +{ > + char const * ptr = filename + strlen(filename) - 1; > + for (; ptr >= filename; --ptr) { > + if (*ptr == '/') > + return ptr+1; > + } > + return ptr; > +} > + > > Can't you use strrchr() here? Yup. Thanks. Like this? static char const * filename_only(char const * filename) { char const * ptr = strrchr(filename, '/'); if (ptr) return ptr+1; return filename; } > What happens with the external convertors? They get passed '-dir '. > You should also document the new switch in fdesign man page. Granted. Angus From angus.leeming at btopenworld.com Thu Nov 27 13:15:55 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 18:15:55 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms/fdesign fd_forms.c fd_main.c fd_main.h f... In-Reply-To: <200311271626.57490.angus.leeming@btopenworld.com> References: <200311271626.57490.angus.leeming@btopenworld.com> Message-ID: <200311271815.55461.angus.leeming@btopenworld.com> On Thursday 27 November 2003 4:26 pm, Angus Leeming wrote: > > Can't you use strrchr() here? > Yup. Thanks. Like this? [snip...] > > You should also document the new switch in fdesign man page. > Granted. Patch attached, FYI. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 2080 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/21408007/attachment.bin From angus.leeming at btopenworld.com Thu Nov 27 16:24:57 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 21:24:57 +0000 Subject: [XForms] Getting rid of generated files Message-ID: <200311272124.57343.angus.leeming@btopenworld.com> Attached is a patch that uses the new -dir option of fdesign to get rid of demos/fd/button_gui.[ch] from the cvs repository. I've checked that all works fine from a 'make distdir' tree as well. Indeed, almost all of the .[ch] files in demos/fd can be removed in the same manner. The only ones that must remain are fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. Fdesign does not have the ability currently to #include user-specifed files. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-diff Size: 7226 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/4e33e2b5/attachment.bin From angus.leeming at btopenworld.com Thu Nov 27 17:24:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 22:24:19 +0000 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272124.57343.angus.leeming@btopenworld.com> References: <200311272124.57343.angus.leeming@btopenworld.com> Message-ID: <200311272224.19706.angus.leeming@btopenworld.com> On Thursday 27 November 2003 9:24 pm, Angus Leeming wrote: > To subscribers of the xforms list > Indeed, almost all of the .[ch] files in demos/fd can be removed > in the same manner. The only ones that must remain are > fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend > on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. > Fdesign does not have the ability currently to #include user-specifed files. Actually, it transpires that I can remove these files too. The trick is to ensure that fd/ibrowser_gui.c is not compiled on its own, but rather that it is #included by ibrowser.c. (This trick was much-used in the demos dir; I have retained it only for the compilation of ibrowser.c and itest.c.) Angus From angus.leeming at btopenworld.com Thu Nov 27 17:31:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 22:31:24 +0000 Subject: [XForms] Towards xforms 1.1 Message-ID: <200311272231.24152.angus.leeming@btopenworld.com> Ok, Jean-Marc. I think that we're getting closer, don't you? What else do you have on your to-do list? Regards, Angus From xforms2 at vjet.demon.co.uk Thu Nov 27 20:37:31 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Fri, 28 Nov 2003 01:37:31 GMT Subject: [XForms] Re: JPEG/EXIF support? Message-ID: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> Hi Angus, I built the original fix a long time ago, possibly on one of the really early open releases. It is always possible that it has been subsequently fixed elsewhere. The old flimage_dup did FL_IMAGE * flimage_dup_(FL_IMAGE * sim, int pix) { ... FL_IMAGE *im = flimage_alloc(); ... memcpy(im, sim, sizeof(*im)); Which seems a bit iffy.. I've just checked - thats is also how it is in 1.0. Can you check the current version? Cheers Clive > On Thursday 27 November 2003 2:27 am, Clive A Stubbings wrote: > > > > It fixes a bug in flimage_dup() , > > > > > > I'm not going to apply this without some discussion. Feel free to explain > > > the rationale. > > > > Well, its a while ago, but if memory serves, I found that if I dup'd an > > image then later free'd both copies I got a crash. The crash was because > > the first free also closed the files and the second one tried to do the > > same again, but the fp's were no longer valid. > > > > There needs to be only one reference to the fp.. Either it goes in a > > shared struct that both 'images' point to, or only one image can be > > associated with the file. I'm not sure that 2 'images' and one file > > really makes sense anyway. > > > > FWIW: I duped the image because I wanted to have the original and a > > processed copy, so I made a dup and then processed it.. When I'd > > finished with both images I free'd both.. Seemed reasonable to me. > > And to me too. I do something similar in LyX. Here are the relvant parts of my > wrapper class. My question to you is, "why doesn't this trigger the crash"? > If I make two copies of the image and then invoke flimage_free in the > destructor, why don't I run into your problem? > > class xformsImage { > public: > xformsImage(): image_(0) {} > xformsImage(xformsImage const & other) : image_(0) { > if (other.image_) { > image_ = flimage_dup(other.image_); > image_->u_vdata = this; > } > } > > ~xformsImage() { > if (image_) > flimage_free(image_); > } > private: > /// The xforms container. > FL_IMAGE * image_; > }; > > Ahhhhhhh. Because I use a callback function to monitor the loading process and > explicitly close the FILE pointers when loading is complete. > > void xformsImage::statusCB(string const & status_message) > { > if (status_message.empty()) > return; > > if (prefixIs(status_message, "Done Reading")) { > if (image_) > flimage_close(image_); > finishedLoading(true); > } > } > > Anyway, I see the need for your patch or for something like it. > > Perhaps it would be better to not copy the file pointers in flimage_dup in the > first place? Hmmmmmmmm. flimage_dup does NOT copy the FILE pointers. The only > place that they are set is in identify_image which in turn is invoked only by > flimage_open (in turn invoked by flimage_load). The point is that flimage_dup > does not invoke any of these routines. > > Conclusion: I don't see the need for the patch. > No doubt I've got my logic wrong somewhere, so I'd be grateful if you'd have a > look at the current xforms sources too... > > > > > > > and makes jpeg + gif reading better. > > > > > > I've applied both these parts to my local tree, albeit with some > > > re-factoring to get rid of the goto and some signed-unsigned comparson > > > warnings. Could you check to see that all is still as you intended > > > (attached). If you could cast your eye over the ChangeLog entry and maybe > > > rename 'flush_buffer' to something that makes sense to you, that'd be > > > great too... > > > > Had a fair look at it - seems OK on paper. flush_buffer is fine. The > > function flushes completed lines from the working buffer. > > And Michal says it works, so I have committed it. Many thanks for the patch. > > > (If you don't like the goto, with hindsight, an else might have been better > > ;-) > > Let's just say I have a pathological hatred of 'goto'. Something to do with > maintaining some old Fortran66 code. > > Regards, > Angus > > From angus.leeming at btopenworld.com Fri Nov 28 04:16:22 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 09:16:22 +0000 Subject: [XForms] Re: JPEG/EXIF support? In-Reply-To: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> References: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> Message-ID: <200311280916.22028.angus.leeming@btopenworld.com> On Friday 28 November 2003 1:37 am, Clive A Stubbings wrote: > Hi Angus, > > I built the original fix a long time ago, possibly on one of the really > early open releases. It is always possible that it has been subsequently > fixed elsewhere. > > The old flimage_dup did > > FL_IMAGE * > flimage_dup_(FL_IMAGE * sim, int pix) > { > ... > FL_IMAGE *im = flimage_alloc(); > ... > memcpy(im, sim, sizeof(*im)); > > > Which seems a bit iffy.. I've just checked - thats is also how it is > in 1.0. Can you check the current version? Sigh! Yes, it still does. However, it goes on: memcpy(im, sim, sizeof(*im)); /* reset all pointers */ im->red = im->green = im->blue = im->alpha = 0; im->red_lut = im->green_lut = im->blue_lut = im->alpha_lut = 0; im->gray = 0; im->ci = 0; im->red16 = im->green16 = im->blue16 = im->alpha16 = 0; im->packed = 0; im->wlut = 0; im->llut[0] = im->llut[1] = im->llut[2] = 0; im->extra_io_info = 0; im->info = 0; There are actually a heap more pointers that these defined in the struct, but I guess that it's here that we should reset the fpin and fpout pointers, no? Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:15:43 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:15:43 +0100 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272224.19706.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:24:19 +0000") References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Thursday 27 November 2003 9:24 pm, Angus Leeming wrote: >> To subscribers of the xforms list >> Indeed, almost all of the .[ch] files in demos/fd can be removed in >> the same manner. The only ones that must remain are >> fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend >> on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. >> Fdesign does not have the ability currently to #include >> user-specifed files. Angus> Actually, it transpires that I can remove these files too. The Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on Angus> its own, but rather that it is #included by ibrowser.c. (This Angus> trick was much-used in the demos dir; I have retained it only Angus> for the compilation of ibrowser.c and itest.c.) Excellent. From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:15:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:15:19 +0100 Subject: [XForms] Towards xforms 1.1 In-Reply-To: <200311272231.24152.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:31:24 +0000") References: <200311272231.24152.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Ok, Jean-Marc. I think that Angus> we're getting closer, don't you? What else do you have on your Angus> to-do list? In no particular order: - We've got to decide on a version number. I suggest something like 1.0.90. The m4 code needs to be changed probably, as we seem to have two notions of current version in configure.ac. - we may need to support dlls under windows (but this can maybe wait for next version). The key is to use AC_LIBTOOL_WIN32_DLL: Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with __declspec(dllexport) and imported with __declspec(dllimport). If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts. This macro must be called before AC_PROG_LIBTOOL, and provision must be made to pass `-no-undefined' to libtool in link mode from the package Makefile. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols really are defined at link time! Actually, I do not know whether xforms 1.0 did build as dll for cygwin. - I still have a problem to fix for proper handling of RETSIGTYPE in lib/signal.c. I did not find any clear solution in other programs... Maybe a little bit of autoconf magic will suffice. - we need to update README a little bit more (there is a duplicated part...) - besides the standard installation instructions in INSTALL, should we document things like --enable-demos --enable-gl and friends? JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:17:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:17:20 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031124172821.GA9534@astrouw.edu.pl> (Michal Szymanski's message of "Mon, 24 Nov 2003 18:28:21 +0100") References: <20031123153548.GA18821@astrouw.edu.pl> <20031124172821.GA9534@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: >> Try to run ./autogen.sh instead. Michal> Thanks, it worked. I guess it might be worth putting into Michal> INSTALL file which now is somewhat misleading. I think the right thing to do is to have a README-cvs file which is in cvs (and gives the info) but is not distributed... JMarc From angus.leeming at btopenworld.com Fri Nov 28 12:32:35 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:32:35 +0000 Subject: [XForms] Towards xforms 1.1 In-Reply-To: References: <200311272231.24152.angus.leeming@btopenworld.com> Message-ID: <200311281732.35512.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:15 pm, Jean-Marc Lasgouttes wrote: > Angus> To subscribers of the xforms list Ok, Jean-Marc. I think that > Angus> we're getting closer, don't you? What else do you have on your > Angus> to-do list? > > In no particular order: > > - We've got to decide on a version number. I suggest something like > 1.0.90. Ok. > The m4 code needs to be changed probably, as we seem to have > two notions of current version in configure.ac. Is this the difference between the 'release' version and the 'indication of the binary compatibility of the libraries' version thingy that confused us way back when? Is there no place that we can ask for advice? Someone must understand this stuff. > - we may need to support dlls under windows (but this can maybe wait > for next version). I don't know about you, but I think of this release as the 'autotools' release. Would be nice therefore if we finished it off before release and never had to worry about any of this crap ever again... > - we need to update README a little bit more (there is a duplicated > part...) I'll have a go. > - besides the standard installation instructions in INSTALL, should we > document things like --enable-demos --enable-gl and friends? Yes. Where would it go? In INSTALL, or is that simply the generic stuff. Incidentally, (now that I have repaired your breakage of 'make rpmdist' ;-P), would it make sense to create an xforms-demos src rpm. I guess that there is little point creating a binary of same... Hmmm, I'm not sure that would work, since the Makefile assumes that fdesign is to be found in ../fdesign/fdesign. Let's leave that then ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:28:13 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:28:13 +0100 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272224.19706.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:24:19 +0000") References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: mk.log Type: application/octet-stream Size: 4770 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031128/424be7d7/attachment.obj From angus.leeming at btopenworld.com Fri Nov 28 12:45:56 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:45:56 +0000 Subject: [XForms] Getting rid of generated files In-Reply-To: References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: <200311281745.56835.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:28 pm, Jean-Marc Lasgouttes wrote: > Angus> Actually, it transpires that I can remove these files too. The > Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on > Angus> its own, but rather that it is #included by ibrowser.c. (This > Angus> trick was much-used in the demos dir; I have retained it only > Angus> for the compilation of ibrowser.c and itest.c.) > > Unfortunately, it does not work here. Why? Genuinely no problems here. Question: where is FL_NORMAL_FORMBROWSER defined? Answer lib/include/forms.h Here the first 5 lines of formbrowser_gui.c are: /* Form definition file generated with fdesign. */ #include "forms.h" #include #include "formbrowser_gui.h" Ie, I don't see why it is failing. I'm a bit upset about the subsequent warnings about two many initializers too... Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:38:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:38:20 +0100 Subject: [XForms] Towards xforms 1.1 In-Reply-To: <200311281732.35512.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 Nov 2003 17:32:35 +0000") References: <200311272231.24152.angus.leeming@btopenworld.com> <200311281732.35512.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I don't know about you, but I think of this release as the Angus> 'autotools' release. Would be nice therefore if we finished it Angus> off before release and never had to worry about any of this Angus> crap ever again... Then we need to get Kayvan to test it, but we could maybe release 1.0.90 and implement libtol support from there. >> - besides the standard installation instructions in INSTALL, should >> we document things like --enable-demos --enable-gl and friends? Angus> Yes. Where would it go? In INSTALL, or is that simply the Angus> generic stuff. I do not know. INSTALL is supposed (in GNU world) to come straight from autoconf (I do not know why). I do not know what is the gnuly correct place. Angus> Incidentally, (now that I have repaired your breakage of 'make Angus> rpmdist' ;-P), would it make sense to create an xforms-demos Angus> src rpm. I guess that there is little point creating a binary Angus> of same... Hmmm, I'm not sure that would work, since the Angus> Makefile assumes that fdesign is to be found in Angus> ../fdesign/fdesign. Yes, the sources are not so large. JMarc PS: We should also get the docs on the web page. Also, should we have a document ``how to adapt your application to 1.1'', or is everything just supposed to work magically? From angus.leeming at btopenworld.com Fri Nov 28 12:55:18 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:55:18 +0000 Subject: [XForms] Towards xforms 1.1 In-Reply-To: References: <200311272231.24152.angus.leeming@btopenworld.com> <200311281732.35512.angus.leeming@btopenworld.com> Message-ID: <200311281755.18644.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:38 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> I don't know about you, but I think of this release as the > Angus> 'autotools' release. Would be nice therefore if we finished it > Angus> off before release and never had to worry about any of this > Angus> crap ever again... > > Then we need to get Kayvan to test it, but we could maybe release > 1.0.90 and implement libtol support from there. Ok. > >> - besides the standard installation instructions in INSTALL, should > >> we document things like --enable-demos --enable-gl and friends? > > Angus> Yes. Where would it go? In INSTALL, or is that simply the > Angus> generic stuff. > > I do not know. INSTALL is supposed (in GNU world) to come straight > from autoconf (I do not know why). I do not know what is the gnuly > correct place. Who to ask? > PS: We should also get the docs on the web page. Also, should we have > a document ``how to adapt your application to 1.1'', or is everything > just supposed to work magically? We have been promised these docs since the day xforms 1.0 was released. I really don't know what the problem is :-( Once we get them, it would make sense to invest some time in a homepage on savannah. Angus From angus.leeming at btopenworld.com Sat Nov 29 13:22:36 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 29 Nov 2003 18:22:36 +0000 Subject: [XForms] Re: [Xforms-cvs] First time CVS download. In-Reply-To: <3FC8DBA2.108@omensys.ca> References: <3FC8DBA2.108@omensys.ca> Message-ID: <200311291822.36936.angus.leeming@btopenworld.com> On Saturday 29 November 2003 5:47 pm, Serge B Bromow wrote: > I just tried to download the CVS tree for the first time to a RH7.3 OS. > There seems to be missing files. i.e "forms.h" and more. Generated from the smaller header files in lib/include. > Here is the script I used to retrieve the files and the output from the > script. The script looks Ok. Personally I would have $ ./autogen.sh $ mkdir build && cd build $ ../configure --enable-demos --enable-maintainer-mode $ make > Needless to say, "./configure" na d "make" fail. [snip most of the script output...] Using autoconf (GNU Autoconf) 2.58 Well, that certainly isn't part of RH7.3 ;-) Generate acinclude.m4... done. Building macros... . done. Building config header template... . /usr/bin/m4: configure.in: No such file or directory Ahhhh. We don't support the old version of autoconf (2.13 and below) that use configure.in. Instead, we require you to use autoconf 2.52 or above that uses configure.ac. The fact that your autoconf is searching for configure.in does not square with the message above saying that you are using autoconf 2.58. Jean-Marc, you're the autotools expert around here. Any ideas? > Am I missing something? Any thoughts? > > Serge Angus (cross-posting this to the xforms maiing list to ensure we get JMarc's attention.) From serge at omensys.ca Sat Nov 29 12:32:54 2003 From: serge at omensys.ca (Serge B Bromow) Date: Sat, 29 Nov 2003 12:32:54 -0500 Subject: [XForms] CVS Update Message-ID: <3FC8D846.1050305@omensys.ca> I just tried to download the CVS tree for the first time to a RH7.3 OS. There seem to be missing files. i.e "forms.h" and more. Here is the script I used to retrieve to file and the output from the script. Am I missing something? Any thoughts? Serge ----------------------- Script cd /home/serge rm -rf xforms cvs -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms co xforms cd xforms ./autogen.sh ./configure make ----------- Output [serge at daph serge]$ ./getxforms \Logging in to :pserver:anoncvs at savannah.nongnu.org:2401/cvsroot/xforms CVS password: cvs server: Updating xforms U xforms/.cvsignore U xforms/COPYING.LIB U xforms/ChangeLog U xforms/Copyright U xforms/INSTALL U xforms/Makefile.am U xforms/NEWS U xforms/README U xforms/README.OS2 U xforms/autogen.sh U xforms/configure.ac U xforms/xforms.spec.in cvs server: Updating xforms/NT U xforms/NT/libxforms.dsp U xforms/NT/xformsAll.dsw cvs server: Updating xforms/X11 cvs server: Updating xforms/config U xforms/config/.cvsignore U xforms/config/Makefile.am U xforms/config/common.am U xforms/config/config.guess U xforms/config/config.sub U xforms/config/cygwin.m4 U xforms/config/depcomp U xforms/config/libtool.m4 U xforms/config/ltmain.sh U xforms/config/xformsinclude.m4 cvs server: Updating xforms/demos U xforms/demos/.cvsignore U xforms/demos/01Readme U xforms/demos/Makefile.am U xforms/demos/arrowbutton.c U xforms/demos/bm1.xbm U xforms/demos/bm2.xbm U xforms/demos/borderwidth.c U xforms/demos/boxtype.c U xforms/demos/browserall.c U xforms/demos/browserop.c U xforms/demos/buttonall.c U xforms/demos/butttypes.c U xforms/demos/canvas.c U xforms/demos/chartall.c U xforms/demos/chartstrip.c U xforms/demos/choice.c U xforms/demos/colbrowser.c U xforms/demos/colsel.c U xforms/demos/colsel1.c U xforms/demos/counter.c U xforms/demos/crab.xpm U xforms/demos/crab45.xpm U xforms/demos/crab_tran.xpm U xforms/demos/crossbut.c U xforms/demos/crossbut.h U xforms/demos/cursor.c U xforms/demos/demo.c U xforms/demos/demo.menu U xforms/demos/demo05.c U xforms/demos/demo06.c U xforms/demos/demo27.c U xforms/demos/demo33.c U xforms/demos/demotest.c U xforms/demos/demotest2.c U xforms/demos/demotest3.c U xforms/demos/dirlist.c U xforms/demos/fbrowse.c U xforms/demos/fbrowse1.c U xforms/demos/fdial.c U xforms/demos/flclock.c U xforms/demos/folder.c U xforms/demos/fonts.c U xforms/demos/formbrowser.c U xforms/demos/free1.c U xforms/demos/freedraw.c U xforms/demos/freedraw_leak.c U xforms/demos/gl.c U xforms/demos/glwin.c U xforms/demos/goodies.c U xforms/demos/group.c U xforms/demos/ibrowser.c U xforms/demos/iconify.c U xforms/demos/iconvert.1 U xforms/demos/iconvert.c U xforms/demos/inputall.c U xforms/demos/invslider.c U xforms/demos/itest.c U xforms/demos/lalign.c U xforms/demos/ldial.c U xforms/demos/ll.c U xforms/demos/longlabel.c U xforms/demos/menu.c U xforms/demos/menubar.c U xforms/demos/minput.c U xforms/demos/minput2.c U xforms/demos/multilabel.c U xforms/demos/ndial.c U xforms/demos/newbutton.c U xforms/demos/newmail.xbm U xforms/demos/nnn.c U xforms/demos/nomail.xbm U xforms/demos/objinactive.c U xforms/demos/objpos.c U xforms/demos/objreturn.c U xforms/demos/picture.xbm U xforms/demos/pmbrowse.c U xforms/demos/popup.c U xforms/demos/porsche.xpm U xforms/demos/positioner.c U xforms/demos/positionerXOR.c U xforms/demos/preemptive.c U xforms/demos/pup.c U xforms/demos/pushbutton.c U xforms/demos/pushme.c U xforms/demos/rescale.c U xforms/demos/scrollbar.c U xforms/demos/secretinput.c U xforms/demos/sld_radio.c U xforms/demos/sldinactive.c U xforms/demos/sldsize.c U xforms/demos/sliderall.c U xforms/demos/srs.xbm U xforms/demos/strsize.c U xforms/demos/symbols.c U xforms/demos/test.ps U xforms/demos/test.xpm U xforms/demos/thumb.c U xforms/demos/thumbwheel.c U xforms/demos/timer.c U xforms/demos/timer.h U xforms/demos/timer2.c U xforms/demos/timerprec.c U xforms/demos/touchbutton.c U xforms/demos/wwwl.c U xforms/demos/xconq.xpm U xforms/demos/xterm.xpm U xforms/demos/xyover U xforms/demos/xyplotactive.c U xforms/demos/xyplotall.c U xforms/demos/xyplotover.c U xforms/demos/yesno.c U xforms/demos/yesno_cb.c cvs server: Updating xforms/demos/fd U xforms/demos/fd/.cvsignore U xforms/demos/fd/Makefile.am U xforms/demos/fd/buttons_gui.fd U xforms/demos/fd/butttypes_gui.fd U xforms/demos/fd/dim_porsche.xpm U xforms/demos/fd/fbtest_gui.fd U xforms/demos/fd/folder_gui.fd U xforms/demos/fd/formbrowser_gui.fd U xforms/demos/fd/ibrowser_gui.fd U xforms/demos/fd/inputall_gui.fd U xforms/demos/fd/is_gui.fd U xforms/demos/fd/pmbrowse_gui.fd U xforms/demos/fd/porsche.xpm U xforms/demos/fd/scrollbar_gui.fd U xforms/demos/fd/twheel_gui.fd cvs server: Updating xforms/exports cvs server: Updating xforms/fd2ps U xforms/fd2ps/.cvsignore U xforms/fd2ps/Change U xforms/fd2ps/Makefile.am U xforms/fd2ps/Readme U xforms/fd2ps/align.c U xforms/fd2ps/fd2ps.c U xforms/fd2ps/fd2ps.h U xforms/fd2ps/fd2ps.man U xforms/fd2ps/flsupport.c U xforms/fd2ps/global.h U xforms/fd2ps/image2ps.c U xforms/fd2ps/load.c U xforms/fd2ps/papers.c U xforms/fd2ps/pscol.c U xforms/fd2ps/psdraw.c U xforms/fd2ps/psobj.c U xforms/fd2ps/pstext.c U xforms/fd2ps/readxpm.c U xforms/fd2ps/sys.c U xforms/fd2ps/version.c U xforms/fd2ps/xbmtops.c U xforms/fd2ps/xpmtops.c cvs server: Updating xforms/fd2ps/test U xforms/fd2ps/test/.cvsignore U xforms/fd2ps/test/Makefile.am U xforms/fd2ps/test/all.fd U xforms/fd2ps/test/allcmm.fd U xforms/fd2ps/test/allpoint.fd U xforms/fd2ps/test/bm1.xbm U xforms/fd2ps/test/buttons.fd U xforms/fd2ps/test/crab.xpm U xforms/fd2ps/test/dial.fd U xforms/fd2ps/test/fd_logo.xpm U xforms/fd2ps/test/folder_gui.fd U xforms/fd2ps/test/junk.fd U xforms/fd2ps/test/parameter.xpm U xforms/fd2ps/test/picture.xbm U xforms/fd2ps/test/sym.fd U xforms/fd2ps/test/xconq.xpm cvs server: Updating xforms/fdesign U xforms/fdesign/.cvsignore U xforms/fdesign/Change U xforms/fdesign/Makefile.am U xforms/fdesign/Readme U xforms/fdesign/fd_attribs.c U xforms/fdesign/fd_control.c U xforms/fdesign/fd_fake.c U xforms/fdesign/fd_file.c U xforms/fdesign/fd_forms.c U xforms/fdesign/fd_groups.c U xforms/fdesign/fd_help.c U xforms/fdesign/fd_help.h U xforms/fdesign/fd_initforms.c U xforms/fdesign/fd_main.c U xforms/fdesign/fd_main.h U xforms/fdesign/fd_names.c U xforms/fdesign/fd_objects.c U xforms/fdesign/fd_pallette.c U xforms/fdesign/fd_printC.c U xforms/fdesign/fd_rubber.c U xforms/fdesign/fd_select.c U xforms/fdesign/fd_spec.c U xforms/fdesign/fd_spec.h U xforms/fdesign/fd_super.c U xforms/fdesign/fd_util.c U xforms/fdesign/fdesign.man U xforms/fdesign/sp_browser.c U xforms/fdesign/sp_button.c U xforms/fdesign/sp_choice.c U xforms/fdesign/sp_counter.c U xforms/fdesign/sp_dial.c U xforms/fdesign/sp_freeobj.c U xforms/fdesign/sp_menu.c U xforms/fdesign/sp_pixmap.c U xforms/fdesign/sp_positioner.c U xforms/fdesign/sp_scrollbar.c U xforms/fdesign/sp_slider.c U xforms/fdesign/sp_twheel.c U xforms/fdesign/sp_xyplot.c U xforms/fdesign/viewforms.c U xforms/fdesign/viewforms.fd U xforms/fdesign/viewforms.h U xforms/fdesign/viewforms_main.c U xforms/fdesign/xpm.h cvs server: Updating xforms/fdesign/fd U xforms/fdesign/fd/.cvsignore U xforms/fdesign/fd/Makefile.am U xforms/fdesign/fd/pallette.c U xforms/fdesign/fd/pallette.fd U xforms/fdesign/fd/pallette.h U xforms/fdesign/fd/ui_attrib.c U xforms/fdesign/fd/ui_attrib.fd U xforms/fdesign/fd/ui_attrib.h U xforms/fdesign/fd/ui_objs.c U xforms/fdesign/fd/ui_objs.fd U xforms/fdesign/fd/ui_objs.h U xforms/fdesign/fd/ui_theforms.c U xforms/fdesign/fd/ui_theforms.fd U xforms/fdesign/fd/ui_theforms.h cvs server: Updating xforms/fdesign/fd4test U xforms/fdesign/fd4test/.cvsignore U xforms/fdesign/fd4test/Makefile.am U xforms/fdesign/fd4test/inittest.fd U xforms/fdesign/fd4test/testfd.fd cvs server: Updating xforms/fdesign/notes U xforms/fdesign/notes/.cvsignore U xforms/fdesign/notes/Makefile.am U xforms/fdesign/notes/spec_algo cvs server: Updating xforms/fdesign/spec U xforms/fdesign/spec/.cvsignore U xforms/fdesign/spec/Makefile.am U xforms/fdesign/spec/browser_spec.c U xforms/fdesign/spec/browser_spec.fd U xforms/fdesign/spec/browser_spec.h U xforms/fdesign/spec/button_spec.c U xforms/fdesign/spec/button_spec.fd U xforms/fdesign/spec/button_spec.h U xforms/fdesign/spec/choice_spec.c U xforms/fdesign/spec/choice_spec.fd U xforms/fdesign/spec/choice_spec.h U xforms/fdesign/spec/counter_spec.c U xforms/fdesign/spec/counter_spec.fd U xforms/fdesign/spec/counter_spec.h U xforms/fdesign/spec/dial_spec.c U xforms/fdesign/spec/dial_spec.fd U xforms/fdesign/spec/dial_spec.h U xforms/fdesign/spec/free_spec.c U xforms/fdesign/spec/free_spec.fd U xforms/fdesign/spec/free_spec.h U xforms/fdesign/spec/freeobj_spec.c U xforms/fdesign/spec/freeobj_spec.fd U xforms/fdesign/spec/freeobj_spec.h U xforms/fdesign/spec/menu_spec.c U xforms/fdesign/spec/menu_spec.fd U xforms/fdesign/spec/menu_spec.h U xforms/fdesign/spec/pixmap_spec.c U xforms/fdesign/spec/pixmap_spec.fd U xforms/fdesign/spec/pixmap_spec.h U xforms/fdesign/spec/positioner_spec.c U xforms/fdesign/spec/positioner_spec.fd U xforms/fdesign/spec/positioner_spec.h U xforms/fdesign/spec/scrollbar_spec.c U xforms/fdesign/spec/scrollbar_spec.fd U xforms/fdesign/spec/scrollbar_spec.h U xforms/fdesign/spec/slider_spec.c U xforms/fdesign/spec/slider_spec.fd U xforms/fdesign/spec/slider_spec.h U xforms/fdesign/spec/twheel_spec.c U xforms/fdesign/spec/twheel_spec.fd U xforms/fdesign/spec/twheel_spec.h U xforms/fdesign/spec/xyplot_spec.c U xforms/fdesign/spec/xyplot_spec.fd U xforms/fdesign/spec/xyplot_spec.h cvs server: Updating xforms/fdesign/xpm U xforms/fdesign/xpm/.cvsignore U xforms/fdesign/xpm/Makefile.am U xforms/fdesign/xpm/allbutton.fd U xforms/fdesign/xpm/bm1.xbm U xforms/fdesign/xpm/bottom.xbm U xforms/fdesign/xpm/box.xpm U xforms/fdesign/xpm/br.xpm U xforms/fdesign/xpm/butt.xpm U xforms/fdesign/xpm/chart.xpm U xforms/fdesign/xpm/check.xpm U xforms/fdesign/xpm/choice.fd U xforms/fdesign/xpm/choice.xpm U xforms/fdesign/xpm/clock.xpm U xforms/fdesign/xpm/cnt.xpm U xforms/fdesign/xpm/crab.xpm U xforms/fdesign/xpm/crab_focus.xpm U xforms/fdesign/xpm/dial.xpm U xforms/fdesign/xpm/fd_logo.xpm U xforms/fdesign/xpm/frame.xpm U xforms/fdesign/xpm/glcan.xpm U xforms/fdesign/xpm/hcenter.xbm U xforms/fdesign/xpm/left.xbm U xforms/fdesign/xpm/lightb.xpm U xforms/fdesign/xpm/menu.xpm U xforms/fdesign/xpm/misc.fd U xforms/fdesign/xpm/nomail.xbm U xforms/fdesign/xpm/picture.xbm U xforms/fdesign/xpm/picture1.xbm U xforms/fdesign/xpm/porsche.xpm U xforms/fdesign/xpm/pos.xpm U xforms/fdesign/xpm/r3dbut.xpm U xforms/fdesign/xpm/right.xbm U xforms/fdesign/xpm/roundb.xpm U xforms/fdesign/xpm/scb.xpm U xforms/fdesign/xpm/sld.xpm U xforms/fdesign/xpm/static.fd U xforms/fdesign/xpm/tab.xpm U xforms/fdesign/xpm/text.xpm U xforms/fdesign/xpm/timer.xpm U xforms/fdesign/xpm/top.xbm U xforms/fdesign/xpm/twheel.xpm U xforms/fdesign/xpm/val.fd U xforms/fdesign/xpm/vals.xpm U xforms/fdesign/xpm/vcenter.xbm U xforms/fdesign/xpm/xconq.xpm U xforms/fdesign/xpm/xconq1.xpm U xforms/fdesign/xpm/xyplot.xpm cvs server: Updating xforms/gl U xforms/gl/.cvsignore U xforms/gl/Makefile.am U xforms/gl/glcanvas.c U xforms/gl/glcanvas.h cvs server: Updating xforms/image U xforms/image/.cvsignore U xforms/image/Makefile.am U xforms/image/flimage.h U xforms/image/flimage_int.h U xforms/image/image.c U xforms/image/image_bmp.c U xforms/image/image_combine.c U xforms/image/image_convolve.c U xforms/image/image_crop.c U xforms/image/image_disp.c U xforms/image/image_fits.c U xforms/image/image_genesis.c U xforms/image/image_gif.c U xforms/image/image_gzip.c U xforms/image/image_io_filter.c U xforms/image/image_jpeg.c U xforms/image/image_jquant.c U xforms/image/image_marker.c U xforms/image/image_oquant.c U xforms/image/image_png.c U xforms/image/image_pnm.c U xforms/image/image_postscript.c U xforms/image/image_proc.c U xforms/image/image_replace.c U xforms/image/image_rotate.c U xforms/image/image_scale.c U xforms/image/image_sgi.c U xforms/image/image_text.c U xforms/image/image_tiff.c U xforms/image/image_type.c U xforms/image/image_warp.c U xforms/image/image_xbm.c U xforms/image/image_xpm.c U xforms/image/image_xwd.c U xforms/image/matrix.c U xforms/image/postscript.c U xforms/image/ps_core.c U xforms/image/ps_draw.c U xforms/image/ps_text.c U xforms/image/rgb_db.c cvs server: Updating xforms/lib U xforms/lib/.cvsignore U xforms/lib/Change U xforms/lib/Makefile.am U xforms/lib/align.c U xforms/lib/appwin.c U xforms/lib/asyn_io.c U xforms/lib/be.c U xforms/lib/bitmap.c U xforms/lib/box.c U xforms/lib/browser.c U xforms/lib/button.c U xforms/lib/canvas.c U xforms/lib/chart.c U xforms/lib/checkbut.c U xforms/lib/child.c U xforms/lib/choice.c U xforms/lib/clipboard.c U xforms/lib/clock.c U xforms/lib/cmd_br.c U xforms/lib/colsel.c U xforms/lib/combo.c U xforms/lib/counter.c U xforms/lib/cursor.c U xforms/lib/dial.c U xforms/lib/dirent_vms.h U xforms/lib/display.c U xforms/lib/dmalloc.h U xforms/lib/errmsg.c U xforms/lib/events.c U xforms/lib/extern.h U xforms/lib/flcolor.c U xforms/lib/fldraw.c U xforms/lib/flinternal.h U xforms/lib/flresource.c U xforms/lib/flsnprintf.c U xforms/lib/flvisual.c U xforms/lib/fonts.c U xforms/lib/formbrowser.c U xforms/lib/forms.c U xforms/lib/frame.c U xforms/lib/free.c U xforms/lib/fselect.c U xforms/lib/global.h U xforms/lib/goodie_alert.c U xforms/lib/goodie_choice.c U xforms/lib/goodie_input.c U xforms/lib/goodie_msg.c U xforms/lib/goodie_salert.c U xforms/lib/goodie_sinput.c U xforms/lib/goodie_yesno.c U xforms/lib/goodies.c U xforms/lib/input.c U xforms/lib/interpol.c U xforms/lib/keyboard.c U xforms/lib/labelbut.c U xforms/lib/lframe.c U xforms/lib/lightbut.c U xforms/lib/listdir.c U xforms/lib/local.h U xforms/lib/menu.c U xforms/lib/n2a.c U xforms/lib/objects.c U xforms/lib/oneliner.c U xforms/lib/pixmap.c U xforms/lib/positioner.c U xforms/lib/read2lsbf.c U xforms/lib/read2msbf.c U xforms/lib/read4lsb.c U xforms/lib/read4msb.c U xforms/lib/readint.c U xforms/lib/round3d.c U xforms/lib/roundbut.c U xforms/lib/scrollbar.c U xforms/lib/scrollbut.c U xforms/lib/signal.c U xforms/lib/simu.c U xforms/lib/sldraw.c U xforms/lib/slider.c U xforms/lib/space.c U xforms/lib/spline.c U xforms/lib/strdup.c U xforms/lib/symbols.c U xforms/lib/sysdep.c U xforms/lib/tabfolder.c U xforms/lib/text.c U xforms/lib/textbox.c U xforms/lib/thumbwheel.c U xforms/lib/timeout.c U xforms/lib/timer.c U xforms/lib/tooltip.c U xforms/lib/ulib.h U xforms/lib/util.c U xforms/lib/valuator.c U xforms/lib/version.c U xforms/lib/vms_readdir.c U xforms/lib/vn_pair.c U xforms/lib/vstrcat.c U xforms/lib/win.c U xforms/lib/xdraw.c U xforms/lib/xforms.man U xforms/lib/xpopup.c U xforms/lib/xsupport.c U xforms/lib/xtext.c U xforms/lib/xyplot.c cvs server: Updating xforms/lib/OS2 cvs server: Updating xforms/lib/bitmaps U xforms/lib/bitmaps/.cvsignore U xforms/lib/bitmaps/Makefile.am U xforms/lib/bitmaps/plaid.xpm U xforms/lib/bitmaps/q.xbm U xforms/lib/bitmaps/warn.xbm cvs server: Updating xforms/lib/fd U xforms/lib/fd/.cvsignore U xforms/lib/fd/Makefile.am U xforms/lib/fd/cmdbr.c U xforms/lib/fd/cmdbr.fd U xforms/lib/fd/cmdbr.h U xforms/lib/fd/ginput.c U xforms/lib/fd/ginput.fd U xforms/lib/fd/ginput.h U xforms/lib/fd/micntl.c U xforms/lib/fd/micntl.fd U xforms/lib/fd/micntl.h cvs server: Updating xforms/lib/include U xforms/lib/include/.cvsignore U xforms/lib/include/AAA.h.in U xforms/lib/include/Basic.h U xforms/lib/include/Makefile.am U xforms/lib/include/XBasic.h U xforms/lib/include/bitmap.h U xforms/lib/include/box.h U xforms/lib/include/browser.h U xforms/lib/include/button.h U xforms/lib/include/canvas.h U xforms/lib/include/chart.h U xforms/lib/include/choice.h U xforms/lib/include/clipbd.h U xforms/lib/include/clock.h U xforms/lib/include/counter.h U xforms/lib/include/cursor.h U xforms/lib/include/dial.h U xforms/lib/include/filesys.h U xforms/lib/include/flps.h U xforms/lib/include/formbrowser.h U xforms/lib/include/frame.h U xforms/lib/include/free.h U xforms/lib/include/goodies.h U xforms/lib/include/input.h U xforms/lib/include/menu.h U xforms/lib/include/menubar.h U xforms/lib/include/popup.h U xforms/lib/include/positioner.h U xforms/lib/include/scrollbar.h U xforms/lib/include/slider.h U xforms/lib/include/tabfolder.h U xforms/lib/include/text.h U xforms/lib/include/thumbwheel.h U xforms/lib/include/timer.h U xforms/lib/include/xyplot.h U xforms/lib/include/zzz.h cvs server: Updating xforms/lib/private U xforms/lib/private/.cvsignore U xforms/lib/private/Makefile.am U xforms/lib/private/flsnprintf.h U xforms/lib/private/pbrowser.h U xforms/lib/private/pcanvas.h U xforms/lib/private/pchoice.h U xforms/lib/private/pcounter.h U xforms/lib/private/pdial.h U xforms/lib/private/pflps.h U xforms/lib/private/pformbrowser.h U xforms/lib/private/pmenu.h U xforms/lib/private/ppositioner.h U xforms/lib/private/pscrollbar.h U xforms/lib/private/pslider.h U xforms/lib/private/ptextbox.h U xforms/lib/private/ptwheel.h U xforms/lib/private/pvaluator.h U xforms/lib/private/pxyplot.h U xforms/lib/private/textbox.h cvs server: Updating xforms/snp cvs server: Updating xforms/snp/sparc-sun-sunos Using autoconf (GNU Autoconf) 2.58 Generate acinclude.m4... done. Building macros... . done. Building config header template... . /usr/bin/m4: configure.in: No such file or directory done. Building Makefile templates... . automake: configure.ac: installing `config/install-sh' automake: configure.ac: installing `config/mkinstalldirs' automake: configure.ac: installing `config/missing' configure.ac: 6: required file `./[lib/config.h].in' not found configure.ac: 6: required file `./[lib/stamp-h.in' not found lib/include/Makefile.am:3: invalid variable `nodist_include_HEADERS' fdesign/Makefile.am:19: variable `LIBS' not defined fd2ps/Makefile.am:19: variable `LIBS' not defined demos/Makefile.am:168: variable `LIBS' not defined demos/Makefile.am:172: variable `LIBS' not defined demos/Makefile.am:180: variable `LIBS' not defined demos/Makefile.am:187: variable `LIBS' not defined demos/Makefile.am:199: variable `LIBS' not defined demos/Makefile.am:207: variable `LIBS' not defined demos/Makefile.am:260: variable `LIBS' not defined demos/Makefile.am:225: invalid unused variable name: `nodist_pmbrowse_SOURCES' demos/Makefile.am:160: invalid unused variable name: `nodist_formbrowser_SOURCES' demos/Makefile.am:192: invalid unused variable name: `nodist_inputall_SOURCES' demos/Makefile.am:250: invalid unused variable name: `nodist_thumbwheel_SOURCES'demos/Makefile.am:154: invalid unused variable name: `nodist_folder_SOURCES' demos/Makefile.am:238: invalid unused variable name: `nodist_scrollbar_SOURCES' demos/Makefile.am:138: invalid unused variable name: `nodist_demotest_SOURCES' demos/Makefile.am:145: invalid unused variable name: `nodist_dirlist_SOURCES' demos/Makefile.am:115: invalid unused variable name: `nodist_buttonall_SOURCES' demos/Makefile.am:106: invalid unused variable name: `AM_LDFLAGS' demos/Makefile.am:119: invalid unused variable name: `nodist_butttypes_SOURCES' done. Building configure... . done. run "./configure ; make" From mheffner at vt.edu Tue Dec 2 19:16:15 2003 From: mheffner at vt.edu (Mike Heffner) Date: Tue, 02 Dec 2003 19:16:15 -0500 (EST) Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <20031119105606.GA1903@astrouw.edu.pl> Message-ID: Michal, Try the attached patch. This appears to work and is much simpler than the current version, but I'll have to look further into the xforms event handling code to see whether this causes a race condition. Anyone know? Mike On 19-Nov-2003 Michal Szymanski wrote: | To subscribers of the xforms list | | | Hi XFormers, | | I'd like to know what the current status of "file selector double-click" | bug is? There were a couple of messages regarding this in May, starting | with a patch proposed by Mike Heffner, but the discussion that followed | raised some doubts. It ended with following message from Mike: | |> However, we still have the same problem that the callback is never |> getting |> a ButtonPress event. ;-( |> |> This weekend I'll try rewriting the file selector's callback using the |> fl_set_browser_dblclick_callback(). It seems that might be a much |> easier |> way of approaching this. | | Mike, did you try the rewrite? | | If no, is Mike's patch included in any (CVS maybe) version of code? | | I have some heavily-used XForms apps dating back to ver. 0.88 and I'd | like very much to rebuild them with 1.0 (also because of problems with | static libraries under RedHat 9) but all users here are quite used to | double-clicking in file selector. The problems started already in 0.89 | and, sadly, have propagated into 1.0. | | regards, Michal. | -- Mike Heffner -------------- next part -------------- --- lib/fselect.c Sat Jun 1 18:09:38 2002 +++ /home/spock/fselect.c Tue Dec 2 19:06:46 2003 @@ -308,24 +308,18 @@ } return 0; } + #else -/* - * A file is selected from the browser. - * generate ready if valid selection (e.g. double-clicked) - * Note that if a call back is defined, never generate ready - */ + static void -select_cb(FL_OBJECT * ob, long arg) +select_cb(FL_OBJECT *ob, long isdblclick) { int dir; char seltext[FL_PATH_MAX]; - static int lastline = -1, clicked; - int dblclick, thisline; + int thisline; FD_fselect *lfs = ob->form->fdui; - const XEvent *xev = fl_last_event(); thisline = fl_get_browser(ob); - if (thisline <= 0) return; @@ -335,31 +329,9 @@ strcpy(seltext, seltext + 2); - dblclick = (lastline == thisline && clicked && - fl_time_passed(FL_FS_T) < ob->click_timeout * 0.001f); - - lastline = thisline; - - clicked = (clicked || xev->type == ButtonPress); - - /* cursor keys can cause a single line being repeatedly selected - causing a wrong dblclick detection */ - - if (clicked) - { - if (xev->type == KeyPress || xev->type == KeyRelease) - { - dblclick = 0; - clicked = 0; - lastline = -1; - } - } - - fl_reset_time(FL_FS_T); - if (dir) { - if (dblclick) + if (isdblclick) { strcat(append_slash(lfs->dname), seltext); fl_fix_dirname(lfs->dname); @@ -374,7 +346,7 @@ fl_set_input(lfs->input, seltext); strcpy(lfs->filename, seltext); - if (dblclick) + if (isdblclick) { if (lfs->fselect_cb) { @@ -385,7 +357,6 @@ fl_object_qenter(lfs->ready); } } - return; } #endif @@ -964,6 +935,7 @@ fs->browser = obj = fl_add_browser(FL_HOLD_BROWSER, 15, 80, 185, 180, ""); #if ATTACHABLE fl_set_object_callback(obj, select_cb, 0); + fl_set_browser_dblclick_callback(obj, select_cb, 1); #endif fl_set_object_gravity(obj, NorthWestGravity, SouthEastGravity); obj->click_timeout = FL_CLICK_TIMEOUT; From Jean-Marc.Lasgouttes at inria.fr Wed Dec 3 06:12:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 03 Dec 2003 12:12:19 +0100 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: (Angus Leeming's message of "Tue, 02 Dec 2003 20:02:26 -0500") References: Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> CVSROOT: /cvsroot/xforms Module name: xforms Branch: Changes Angus> by: Angus Leeming 03/12/02 Angus> 20:02:26 Angus> Modified files: . : ChangeLog demos : Makefile.am lib/include : Angus> Makefile.am Angus> Log message: Some subtle little fixes needed to get things Angus> working on non-gnu platforms. - sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ + sed "1,/crop here for forms/d" ${srcdir}/`basename $$i` >> tmpforms; \ an you explain briefly what this does? JMarc From angus.leeming at btopenworld.com Wed Dec 3 06:25:53 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Dec 2003 11:25:53 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: References: Message-ID: <200312031125.53040.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 11:12 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > Angus> CVSROOT: /cvsroot/xforms Module name: xforms Branch: Changes > Angus> by: Angus Leeming 03/12/02 > Angus> 20:02:26 > > Angus> Modified files: . : ChangeLog demos : Makefile.am lib/include : > Angus> Makefile.am > > Angus> Log message: Some subtle little fixes needed to get things > Angus> working on non-gnu platforms. > > - sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ > + sed "1,/crop here for forms/d" ${srcdir}/`basename $$i` >> tmpforms; \ > > an you explain briefly what this does? You mean the change? I'm trying to overcome a problem compiling with Dec's make and with srcdir != builddir. This snippet in Makefile.am (ie the original snippet): for i in $(noinst_HEADERS); do \ sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ done Is expanded by Dec's make to: for i in ../../../lib/include/Basic.h ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h ../../../lib/include/box.h [snip file list]; do sed "1,/crop here for forms/d" ../../../lib/include/$i >> tmpforms; done sed: Cannot find or open file ../../../lib/include/../../../lib/include/Basic.h. Doing the same thing with gnu make: for i in Basic.h XBasic.h bitmap.h box.h browser.h button.h canvas.h chart.h choice.h clipbd.h clock.h counter.h cursor.h dial.h filesys.h flps.h formbrowser.h frame.h free.h goodies.h input.h menu.h menubar.h popup.h positioner.h scrollbar.h slider.h tabfolder.h text.h thumbwheel.h timer.h xyplot.h zzz.h; do \ sed "1,/crop here for forms/d" ../../../lib/include/$i >> tmpforms; \ done You see the problem? One make gives the files their full path and the other doesn't. The trick, therefore, is to use only the filename part. Any better ideas? Angus From Jean-Marc.Lasgouttes at inria.fr Wed Dec 3 06:41:15 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 03 Dec 2003 12:41:15 +0100 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: <200312031125.53040.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 3 Dec 2003 11:25:53 +0000") References: <200312031125.53040.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> You mean the change? I'm trying to overcome a problem compiling Angus> with Dec's make and with srcdir != builddir. This snippet in Angus> Makefile.am (ie the original snippet): Angus> for i in $(noinst_HEADERS); do \ sed "1,/crop here for Angus> forms/d" ${srcdir}/$$i >> tmpforms; \ done Angus> Is expanded by Dec's make to: Angus> for i in ../../../lib/include/Basic.h Angus> ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h Angus> ../../../lib/include/box.h [snip file list]; do sed "1,/crop Angus> here for forms/d" ../../../lib/include/$i >> tmpforms; done I am surprised, since in my Makefile.in noinst_HEADER is noinst_HEADERS = \ Basic.h \ XBasic.h \ bitmap.h \ box.h \ ... Is it different in the Makefile.in on your dec? This would mean a problem with automake, not with the version of make... JMarc From angus.leeming at btopenworld.com Wed Dec 3 07:01:18 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Dec 2003 12:01:18 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: References: <200312031125.53040.angus.leeming@btopenworld.com> Message-ID: <200312031201.18373.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 11:41 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> You mean the change? I'm trying to overcome a problem compiling > Angus> with Dec's make and with srcdir != builddir. This snippet in > Angus> Makefile.am (ie the original snippet): > > Angus> for i in $(noinst_HEADERS); do \ sed "1,/crop here for > Angus> forms/d" ${srcdir}/$$i >> tmpforms; \ done > > Angus> Is expanded by Dec's make to: > > Angus> for i in ../../../lib/include/Basic.h > Angus> ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h > Angus> ../../../lib/include/box.h [snip file list]; do sed "1,/crop > Angus> here for forms/d" ../../../lib/include/$i >> tmpforms; done > > I am surprised, since in my Makefile.in noinst_HEADER is > noinst_HEADERS = \ > Basic.h \ > XBasic.h \ > bitmap.h \ > box.h \ > ... > > Is it different in the Makefile.in on your dec? Nope. It's the same (also in Makefile itself). The relevant part of the generated Makefile appears to be: distdir: $(DISTFILES) @list='$(DISTFILES)'; for file in $$list; do \ Ie, the answer lies in the definition of $(DISTFILES) DIST_COMMON = $(noinst_HEADERS) AAA.h.in Makefile.am Makefile.in DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) It appears that Dec make does something weird when expanding $(noinst_HEADERS). Angus k From angus.leeming at btopenworld.com Wed Dec 3 07:38:54 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Dec 2003 12:38:54 +0000 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: Message-ID: <200312031238.54118.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 12:16 am, Mike Heffner wrote: > To subscribers of the xforms list > Try the attached patch. This appears to work and is much > simpler than the current version, but I'll have to look further > into the xforms event handling code to see whether this causes > a race condition. Anyone know? Oohhh! I like this kind of patch ;-) What sort of problems are you tinking about? Angus From mheffner at vt.edu Wed Dec 3 09:45:47 2003 From: mheffner at vt.edu (Mike Heffner) Date: Wed, 03 Dec 2003 09:45:47 -0500 (EST) Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <200312031238.54118.angus.leeming@btopenworld.com> Message-ID: On 03-Dec-2003 Angus Leeming wrote: | | | On Wednesday 03 December 2003 12:16 am, Mike Heffner wrote: | |> Try the attached patch. This appears to work and is much |> simpler than the current version, but I'll have to look further |> into the xforms event handling code to see whether this causes |> a race condition. Anyone know? | | Oohhh! I like this kind of patch ;-) | | What sort of problems are you tinking about? | Well, the patch adds two callbacks for the browser object in the file selector: fl_set_object_callback(obj, select_cb, 0); + fl_set_browser_dblclick_callback(obj, select_cb, 1); On a double click we'll want the first call back (single click) to always be called first, (possibly two times, once for each click), then the double click callback to be called. However, if it happened the other way around it might do something weird like select a file in the list right after moving to a new directory. The question is, is there a race condition here that we should handle better, or just depend on the callback's be called in the correct order? Actually though, now that I look at it more closely, even if the single click callback is called after the double click, it will most likely be invalidated. Once we've double clicked and entered a new directory there shouldn't be anything selected so the test against fl_get_browser()>0 at the beginning of the callback would fail and the callback would do nothing. Mike -- Mike Heffner From joel at fc.hp.com Tue Dec 9 11:52:03 2003 From: joel at fc.hp.com (Joel Lefebvre) Date: Tue, 09 Dec 2003 09:52:03 -0700 Subject: [XForms] savannah down? Message-ID: <3FD5FDB3.2050003@fc.hp.com> I'm trying to get the latest Xforms from savannah.nongnu.org but it seems to be down. Anyone know if savannah is having a problem? Is there an alternate source for Xforms? Thanks Joel -- ------------------------------------------------------------ Joel Lefebvre joel at fc.hp.com Hewlett Packard 970-898-7970 All opinions expressed are my own and do not necessarily represent those of Hewlett Packard. ------------------------------------------------------------ From Jean-Marc.Lasgouttes at inria.fr Wed Dec 10 05:39:18 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 10 Dec 2003 11:39:18 +0100 Subject: [XForms] savannah down? In-Reply-To: <3FD5FDB3.2050003@fc.hp.com> (Joel Lefebvre's message of "Tue, 09 Dec 2003 09:52:03 -0700") References: <3FD5FDB3.2050003@fc.hp.com> Message-ID: >>>>> "Joel" == Joel Lefebvre writes: Joel> To subscribers of the xforms list I'm trying to get the latest Joel> Xforms from savannah.nongnu.org but it seems to be down. Anyone Joel> know if savannah is having a problem? Is there an alternate Joel> source for Xforms? Hello, Savannah has been hacked recently, and the site has been closed until they manage to restore everything: http://savannah.gnu.org/statement.html What version of xforms are you looking for? JMarc From bob at bob.usuhs.mil Thu Jun 12 15:25:54 2003 From: bob at bob.usuhs.mil (Robert Williams) Date: Thu, 12 Jun 2003 15:25:54 -0400 Subject: [XForms] New xforms list server Message-ID: <3EE8D3C2.8050003@bob.usuhs.mil> I've finally moved the xforms list to a fast machine running mailman. There may be a few adjustments that I have to make, but if you recieve this, it appears to work. Bob Williams xforms list maintainer From lahaye at users.sourceforge.net Thu Jun 12 19:56:37 2003 From: lahaye at users.sourceforge.net (Rob Lahaye) Date: Fri, 13 Jun 2003 08:56:37 +0900 Subject: [XForms] Re: New xforms list server In-Reply-To: <3EE8D3C2.8050003@bob.usuhs.mil> References: <3EE8D3C2.8050003@bob.usuhs.mil> Message-ID: <3EE91335.6030403@users.sourceforge.net> Robert Williams wrote: > > To subscribers of the xforms list > > > I've finally moved the xforms list to > a fast machine running mailman. There may > be a few adjustments that I have to make, > but if you recieve this, it appears to work. > > Bob Williams > xforms list maintainer Notice that the 2002 archive still collects current messages; and we are already half way 2003! Can you break it up and add the 2003 messages to a new 2003 tree ? Regards, Rob. From ldm at risc4.numis.nwu.edu Mon Jun 16 09:21:42 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Mon, 16 Jun 2003 08:21:42 -0500 (CDT) Subject: [XForms] Libraries, configure etc Message-ID: Two questions: Do the compiled libraries exist anywhere, or have they now gone. Has anyone converted to Imake structure to a configure (i.e. autoconf/automake) one? I am not that familiar with image, but know that configure can be arranged to determine enough about the system to make compilation seamless. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From angus.leeming at btopenworld.com Mon Jun 16 20:17:39 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 17 Jun 2003 00:17:39 +0000 Subject: [XForms] Libraries, configure etc In-Reply-To: References: Message-ID: <200306170017.39950.angus.leeming@btopenworld.com> On Monday 16 June 2003 11:12 pm, you wrote: > We are about to release some code which uses libforms. > If a tgz file is available with a standard configure, > we can use this otherwise we may need to write our > way around including libforms. Can you make one > available? Why not grab a copy of the cvs repository, following the instructions on the web page I posted to you and thereafter: $ ./autogen.sh $ ./configure your_options $ make dist which should generate your desired tar.gz file. Regards, Angus From nicolas.castagne at imag.fr Wed Jun 18 07:54:15 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Wed, 18 Jun 2003 13:54:15 +0200 Subject: [XForms] Threads and OpenGL --- again ! ;-) Message-ID: <958998B0-A183-11D7-B36A-000393C76CA6@imag.fr> Hi all, I have worked again a bit on a small demo program running a gl CANVAS drawn through a THREAD. You will find attached the sources. ----- I - description of the program The code assumes: 1) that each thread has its own current GLXContext 2) that concurrent calls to glXMakeCurrent and glXSwapBuffer can be made, provided the context used for each one is possessed by the calling thread. The program shows in a form two canvas with a rotating cube. The main process creates and display the form. The "MainCanvas" and its GLXcontext are created by the Main Proces. The "MainCanvas" drawn through an idle callback. The ThreadCanvas is created by the Thread and drawn by it. Its GLXcontext is also created by the thread, through the call to fl_add_object(Form, ThreadCanvas). A communication process ensures that Expose Events on the "ThreadCanvas" (handled by the XForms main loop in the Main Process) are communicated to the Thread. As an evidence, this communication process could be improved. However, it is not the problem today. ----- II - results and problem When rendering is made in DIRECT mode, every thing runs correctly on every SGI engine I was able to test. The call to XinitThread() even does not seem to be necessary. On the contrary, the program ALWAYS CRASHES when rendering is made through the X Server. This happens in two cases: 1) when the constant DIRECT, at the beginning of the sources, is set to 0; 2) when distant execution is performed (direct rendering is then impossible). The error messages I get from the X server are various. Mainly : X Error of failed request: GLXBadContextTag Major opcode of failed request: 146 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 667 Current serial number in output stream: 681 or : X Error of failed request: GLXBadContextTag Major opcode of failed request: 146 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 651 Current serial number in output stream: 656 Note that the GLXBadContextTag error is not well documented. As an example, it does not appear in the GL man pages. I don't really understand what it means. ----- II - help ! ;-) I have worked quite a lot around the problem, trying various solutions... But without success. It would be really helpful if one of you could have a look on the problem: Numerous mails concerning threads and GLcanvas have been posted for the past years on the list, but never a definitive answer. As a matter of fact, it could be of interest to : 1) propose a valid small demo program within the XForms examples. 2) by the end, add to the library an API for threaded Gl canvas. I may work on these points... But i need help today ! You may help in different ways : 1) trying to compile and run my program on other platforms, to see what happens; 2) debugging my program, showing what is wrong; 2) sending other pieces of code with threaded Glcanvas that run properly, what ever the rendering mode is, so that I could make the previous jobs on my own. Thx in advance ! Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadGL.c Type: application/applefile Size: 70 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030618/b8eff1b5/attachment-0001.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadGL.c Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030618/b8eff1b5/attachment-0001.c -------------- next part -------------- ------------------------------------------------------------------------ -------------------------- Nicolas CASTAGNE Chercheur, IR de l'ACROE/ICA, Association pour la Cr?ation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Cr?ation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------ -------------------------- From ldm at risc4.numis.nwu.edu Mon Jun 16 19:19:49 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Mon, 16 Jun 2003 18:19:49 -0500 (CDT) Subject: [XForms] Libraries, configure etc In-Reply-To: <200306170017.39950.angus.leeming@btopenworld.com> Message-ID: I will....if I have time before I leave on Saturday to teach at a school in Moscow where I will be using the software On Tue, 17 Jun 2003, Angus Leeming wrote: > On Monday 16 June 2003 11:12 pm, you wrote: > > We are about to release some code which uses libforms. > > If a tgz file is available with a standard configure, > > we can use this otherwise we may need to write our > > way around including libforms. Can you make one > > available? > > Why not grab a copy of the cvs repository, following the instructions on the > web page I posted to you and thereafter: > > $ ./autogen.sh > $ ./configure your_options > $ make dist > > which should generate your desired tar.gz file. > > Regards, > Angus > > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From nicolas.castagne at imag.fr Thu Jun 19 12:05:22 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Thu, 19 Jun 2003 18:05:22 +0200 Subject: [XForms] Formbrowser : adjusting the size of the forms Message-ID: Hy all ! As you know, formbrowsers may need some improvments. For example, an adjustement of the vertical scrollbar (position, size) is needed in case of a call to fl_set_form_size() on one of the forms added to the formbrowser. Does any one actually work on this question ? Shall I have a look on it ? Who could answer to some question I have concerning the best way to solve these problems ? Thx, Nicolas From Mickael.Le.Coz at ifremer.fr Fri Jun 27 04:45:14 2003 From: Mickael.Le.Coz at ifremer.fr (Mickael LE COZ) Date: Fri, 27 Jun 2003 10:45:14 +0200 Subject: [XForms] installation on cygwin emulator Message-ID: <3EFC041A.D4C30C0F@ifremer.fr> Hello, I have untar the "xforms-1.0.tar.gz" file in he X11r6 directory; So when I type ,in the Cygwin/XFree86 rl : xmkmkf >> mv -f Makefile Makefile.bak >>imake -DUseInstalled -I/usr/X11R6/lib/X11/config >>/tmp/IIf.004357:92: unterminated #if conditional >>imake: Exit code 1. >> Stop. and when I type : make Makefiles or make install >>Makefile:11: *** missing operator. Stop Here is the Makefile: # 1 "Imakefile.c" # 1 "/usr/X11R6/lib/X11/config/Imake.tmpl" 1 XCOMM ---------------------------------------------------------------------- XCOMM Makefile generated from "Imake.tmpl" and XCOMM $Xorg: Imake.tmpl,v 1.4 2000/08/17 19:41:46 cpqbld Exp $ XCOMM XCOMM XCOMM XCOMM XCOMM $XFree86: xc/config/cf/Imake.tmpl,v 3.114 2001/11/08 02:09:06 tsi Exp $ XCOMM ---------------------------------------------------------------------- What is the problem? thank you for your help, Micka?l. From nicolas.castagne at imag.fr Fri Jun 27 09:55:13 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 15:55:13 +0200 Subject: [XForms] OpenGL and Threads- again Message-ID: This mail is addressed to those that use OpenGL within XForms. I have had no answer concerning my last message, but I really think the subject of threads and openGL is of interest for the XForms community..... My aim concerning this question is to add a small demo to the XForms demo programs. So, let's play again ! ------- You will find enclosed a short program which implements a GLCanvas drawn by a thread. This program is stable with direct rendering. However, it is not stable on my IRIX system in case of rendering through the X sever, especially in case of a distant execution. -> Could some of you try to compile this program and run it locally and on a distant machine ? 10 min. work ! ------- The next part of the message is addressed to those who have successfully implemented a GLCanvas drawn by a thread. Did you tried non-direct rendering on these canvas ? If it runs properly, it would be very helpful if you could have a look to my code and give advices ! Thx , Nicolas From nicolas.castagne at imag.fr Fri Jun 27 10:36:55 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 16:36:55 +0200 Subject: [XForms] OpenGL and Threads- again In-Reply-To: Message-ID: Sure it is better with the attachement... Thx for testing ! Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadGL.c Type: application/applefile Size: 70 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030627/30e85acb/attachment-0001.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadGL.c Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030627/30e85acb/attachment-0001.c -------------- next part -------------- Le vendredi, 27 jun 2003, ? 15:55 Europe/Paris, Nicolas Castagn? a ?crit : > To subscribers of the xforms list > > > This mail is addressed to those that use OpenGL within XForms. > > I have had no answer concerning my last message, but I really think > the subject of threads and openGL is of interest for the XForms > community..... > My aim concerning this question is to add a small demo to the XForms > demo programs. > > So, let's play again ! > > ------- > > You will find enclosed a short program which implements a GLCanvas > drawn by a thread. > > This program is stable with direct rendering. However, it is not > stable on my IRIX system in case of rendering through the X sever, > especially in case of a distant execution. > > -> Could some of you try to compile this program and run it locally > and on a distant machine ? 10 min. work ! > > ------- > > The next part of the message is addressed to those who have > successfully implemented a GLCanvas drawn by a thread. > > Did you tried non-direct rendering on these canvas ? > If it runs properly, it would be very helpful if you could have a > look to my code and give advices ! > > > Thx , > > Nicolas > > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > From Jean-Marc.Lasgouttes at inria.fr Fri Jun 27 10:46:14 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 27 Jun 2003 16:46:14 +0200 Subject: [XForms] installation on cygwin emulator In-Reply-To: <3EFC041A.D4C30C0F@ifremer.fr> (Mickael LE's message of "Fri, 27 Jun 2003 10:45:14 +0200") References: <3EFC041A.D4C30C0F@ifremer.fr> Message-ID: >>>>> "Mickael" == Mickael LE COZ writes: Mickael> To subscribers of the xforms list Hello, Mickael> I have untar the "xforms-1.0.tar.gz" file in he X11r6 Mickael> directory; So when I type ,in the Cygwin/XFree86 rl : xmkmkf Did you try 'xmkmf -a'? JMarc From nicolas.castagne at imag.fr Fri Jun 27 14:57:00 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 20:57:00 +0200 Subject: Fwd: [XForms] OpenGL and Threads- again Message-ID: <220DA38B-A8D1-11D7-8814-000393C76CA6@imag.fr> Hi all, Thx for trying David. I decided to fwd your mail on the mail list (see below), since it may be of interest for other. The behaviour you obtained is somehow the one I get on octane - appart the fact SGi octane is a bit slower ;-) The questions then are : 1) is multithreading correctly supported by OpenGL in case of non-direct rendering ? 2) if so, where is the fault in my program ? Wish some of you may answer ! Once again, I would ask those who have already implemented a 'multithreaded' GL canvas under XForms to test their program with non-direct rendering (Canvas's direct field set to 0 or distant execution). Thx, Nicolas D?but du message r?exp?di? : > De: David Scriven > Date: Ven 27 jun 2003 20:42:26 Europe/Paris > ?: "Nicolas_Castagn?" > Objet: R?p : [XForms] OpenGL and Threads- again > > Hi Nicolas, > > I tried your program on a platform running RedHat 9 with XFree86 4.3.0 > on an NVIDIA Ti 4200 (NVIDIA supply their own drivers and GL libraries) > > 1. With DIRECT = 1 the program ran fine although the rate in the > left hand window was so fast that the cube was blurred. The rate > in the right window was much slower. > > 2. With DIRECT = 0 the program still worked, BUT, the program would > not respond to the buttons once Go! was pressed and the cube on > the right did not move. In addition, when I covered and then uncovered > the window, the right hand screen was not redrawn (ie it remained > black). In addition I got messages like: > Xlib: unexpected async reply (sequence 0x288ad)! > > 3,. In light of the above I didn't try remote execution. > > I compiled the program with > > gcc ThreadGL.c -o ThreadGL -I /usr/X11R6/include -O2 -L/usr/X11R6/lib > -lforms -lformsGL -lpthread -lGL -lGLU > > using gcc ver 3.2.2 > > I'll try and look through your code this weekend if I get a chance. > > DS > > : > To subscribers of the xforms list >> >> >> This mail is addressed to those that use OpenGL within XForms. >> >> I have had no answer concerning my last message, but I really think >> the subject of threads and openGL is of interest for the XForms >> community..... >> My aim concerning this question is to add a small demo to the XForms >> >> demo programs. >> >> So, let's play again ! >> >> ------- >> >> You will find enclosed a short program which implements a GLCanvas >> drawn by a thread. >> >> This program is stable with direct rendering. However, it is not >> stable on my IRIX system in case of rendering through the X sever, >> especially in case of a distant execution. >> >> -> Could some of you try to compile this program and run it locally >> and on a distant machine ? 10 min. work ! >> >> ------- >> >> The next part of the message is addressed to those who have >> successfully implemented a GLCanvas drawn by a thread. >> >> Did you tried non-direct rendering on these canvas ? >> If it runs properly, it would be very helpful if you could have a >> look >> to my code and give advices ! >> >> >> Thx , >> >> Nicolas >> >> >> _______________________________________________ >> To unsubscribe, send the message "unsubscribe" to >> xforms-request at bob.usuhs.mil or see: >> http://cweblog.usuhs.mil/mailman/listinfo/xforms >> XForms Home Page: http://world.std.com/~xforms >> List Archive: http://bob.usuhs.mil/pipermail/xforms and >> http://bob.usuhs.mil/mailserv/list-archives/ >> Development: http://savannah.nongnu.org/files/?group=xforms > > ______________________________________________________________________ > Post your free ad now! http://personals.yahoo.ca > From ddembrow at nlxcorp.com Mon Jun 30 15:43:39 2003 From: ddembrow at nlxcorp.com (ddembrow at nlxcorp.com) Date: Mon, 30 Jun 2003 15:43:39 -0400 Subject: [XForms] Next xforms release inquiry Message-ID: Are there any plans to release another version of xforms including the latest modifications as a stable release beyond 1.0 rc5? From Jean-Marc.Lasgouttes at inria.fr Tue Jul 1 04:24:21 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 01 Jul 2003 10:24:21 +0200 Subject: [XForms] Next xforms release inquiry In-Reply-To: (ddembrow@nlxcorp.com's message of "Mon, 30 Jun 2003 15:43:39 -0400") References: Message-ID: >>>>> "ddembrow" == ddembrow writes: ddembrow> Are there any plans to ddembrow> release another version of xforms including the latest ddembrow> modifications as a stable release beyond 1.0 rc5? The latest released version is actually 1.0, available here https://savannah.nongnu.org/files/?group=xforms In the cvs available from there https://savannah.nongnu.org/cvs/?group=xforms you will find what is going to become 1.1.0. It contains several bug fixes, and support for autoconf-based build. This is the part that is not finished yet. Hope this helps. JMarc From davidwriter at yahoo.com Sun Jul 6 17:00:08 2003 From: davidwriter at yahoo.com (David Scriven) Date: Sun, 6 Jul 2003 17:00:08 -0400 (EDT) Subject: [XForms] Timing in XForms In-Reply-To: <200306070213.h572D0004065@pc18.math.umbc.edu> Message-ID: <20030706210008.99028.qmail@web41213.mail.yahoo.com> When XForms was originally developed, in the mid 1980's, machines were much slower than they are today, so I suspect the designers had to make a compromise between CPU cycles and response. In XForms there are two critical values that are set : TIMER_RES, which is 50 ms (and can be partly reset by fl_set_idle_delta), and the number of FL_STEP events that are swallowed before the system responds (l 1977-78 of forms.c) /* Handle FL_STEP. Every 10 events. This will reduce cpu usage */ if ((++auto_cnt % 10) == 0) This latter statement clearly will slow down the way in which XForms responds and probably explains the effect I have noticed on my machines; that XForms programs speed up when the mouse is moved. My query is whether the settings in XForms are appropriate to today's fast machines and whether these settings could be dynamically changed to suit the machine that XForms is running on. What I would have in mind is a routine inside fl_initialize that detects the real clock precision and clock speed and sets the values for TIMER_RES, and steps swallowed, dynamically. XForms is extremely complex and such changes might have unforseen side effects (T.C., your comments?), but I think it might be worth thinking about. DS ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From jac at casurgica.com Thu Jul 10 23:33:25 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Thu, 10 Jul 2003 23:33:25 -0400 (EDT) Subject: [XForms] fl_get_object_component In-Reply-To: <20030706210008.99028.qmail@web41213.mail.yahoo.com> References: <200306070213.h572D0004065@pc18.math.umbc.edu> <20030706210008.99028.qmail@web41213.mail.yahoo.com> Message-ID: <39941.69.3.42.242.1057894405@sun-qmail17.laserlink.net> Does anybody know where I can find a list of all the objects that have component objects that can be retrieved with fl_get_object_component(), and of what those component objects are? J. Cipriani From jac at casurgica.com Fri Jul 11 21:48:00 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Fri, 11 Jul 2003 21:48:00 -0400 (EDT) Subject: [XForms] A tip for using secret inputs. In-Reply-To: <20030706210008.99028.qmail@web41213.mail.yahoo.com> References: <200306070213.h572D0004065@pc18.math.umbc.edu> <20030706210008.99028.qmail@web41213.mail.yahoo.com> Message-ID: <46119.69.3.42.242.1057974480@sun-qmail12.laserlink.net> The SECRET_INPUT is completely unusable. However, you can turn a NORMAL_INPUT into somewhat of a secret input box like so: fl_set_input_color(MyInput, MyInput->col2, MyCaretColor); Where "MyInput" is your NORMAL_INPUT (an FL_OBJEC T*), and MyCaretColor is whatever color you want the caret to be. It makes the text "invisible" by setting the text color to the input's background color. It makes the highlight invisible, too, though, but its still better than the SECRET_INPUT. I only tried that on a form with one input box, though, so the text might become visible when the box loses focus. I dunno. J. Cipriani From rostamian at umbc.edu Sat Jul 12 11:33:00 2003 From: rostamian at umbc.edu (Rouben Rostamian) Date: Sat, 12 Jul 2003 11:33:00 -0400 Subject: [XForms] question about resizing forms Message-ID: <200307121533.h6CFX0jO005951@pc18.math.umbc.edu> I want to set up a form which can be resized only in discrete steps. E.g., in interactive resizing, the form's width and height may only change in multiples of 10 pixels. How do I do this in xforms? -- Rouben Rostamian From jac at casurgica.com Fri Jul 18 11:56:06 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Fri, 18 Jul 2003 11:56:06 -0400 (EDT) Subject: [XForms] BUGFIX: Tab control fixed, working secret inputs, fixed focus and resize problems, etc, etc... Message-ID: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Use GTK. From drriddle at qwest.net Fri Jul 18 20:09:33 2003 From: drriddle at qwest.net (Reed Riddle) Date: Fri, 18 Jul 2003 19:09:33 -0500 Subject: [XForms] BUGFIX: Tab control fixed, working secret inputs, fixed focus and resize problems, etc, etc... In-Reply-To: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Message-ID: <467B5611-B97D-11D7-AB01-003065E23D38@qwest.net> On Friday, July 18, 2003, at 10:56 AM, jac at casurgica.com wrote: > To subscribers of the xforms list > > > Use GTK. Awww, but that would be like giving up! :) When I started building my application, I looked at GTK. It didn't look like it had a plotting element nearly as flexible as the xyplot that Xforms has (and I even had to add a small patch to that to do what I wanted). I also could understand the callback code much better; the GTK interface builder put all kinds of crap in there, while it hardly took me any time at all to figure out Xforms. Oh, and I had never built a GUI before. It's possible that GTK is better now, and that it might be easy for me to switch my code over, but why go to all the trouble when what I have now works well enough? Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From Jean-Marc.Lasgouttes at inria.fr Thu Jul 31 12:24:54 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 31 Jul 2003 18:24:54 +0200 Subject: [XForms] [PATCH] simplifying local.h: the trivial bits Message-ID: A non-text attachment was scrubbed... Name: local.diff Type: text/x-patch Size: 5836 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/fb6de625/attachment-0001.bin From Jean-Marc.Lasgouttes at inria.fr Thu Jul 31 12:36:28 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 31 Jul 2003 18:36:28 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200307311732.59411.leeming@lyx.org> (Angus Leeming's message of "Thu, 31 Jul 2003 17:32:59 +0000") References: <200307311732.59411.leeming@lyx.org> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Thursday 31 July 2003 4:24 pm, Jean-Marc Lasgouttes wrote: >> The attached patch does the easy part in the job of getting rid of >> local.h. Angus, could you please double check that it makes sense >> and apply? >> >> In what remains, there are checks for xenix, vms, lynx and sunos 4. >> I'd be happy to get rid of those. From what I can see, only sunos4 >> had a xforms 0.89 build, so the others would not be missed (I could >> not even find xenix). >> >> Thoughts? Angus> Fantastic effort. The logic here seems to be inverted though. Angus> Am I right? Yes, it should be #ifdef HAVE_USLEEP also, there is a problem with line 83 of signal.c, where dec cc does not like my code. I have to leave now, I'll have a look tomorrow. JMarc From angus.leeming at btopenworld.com Thu Jul 31 13:38:41 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 31 Jul 2003 17:38:41 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: Message-ID: <200307311732.59411.leeming@lyx.org> On Thursday 31 July 2003 4:24 pm, Jean-Marc Lasgouttes wrote: > The attached patch does the easy part in the job of getting rid of > local.h. Angus, could you please double check that it makes sense and > apply? > > In what remains, there are checks for xenix, vms, lynx and sunos 4. > I'd be happy to get rid of those. From what I can see, only sunos4 had > a xforms 0.89 build, so the others would not be missed (I could not > even find xenix). > > Thoughts? Fantastic effort. The logic here seems to be inverted though. Am I right? -#if !defined(DONT_HAVE_USLEEP) +#if !defined(HAVE_USLEEP) Angus From myaconis at nycap.rr.com Thu Jul 31 11:49:00 2003 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Thu, 31 Jul 2003 11:49:00 -0400 Subject: [XForms] Form imaging problems References: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Message-ID: <006301c3577b$499ebe80$6501a8c0@dimensionxp> For some reason the first time I display a form it doesn't image properly. The attached images show what it looks like. The window consists of approximately 50 forms, a main form, a scrollable form, and 40+ row forms whos objects are added to the scrollable form which is then attached to the main form via a form browser. Any suggestions or help would be much appreciated. (The good.png image shows how the form should look. The bad.png image shows how it looks when it is first displayed.) -------------- next part -------------- A non-text attachment was scrubbed... Name: bad.png Type: image/png Size: 20311 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/ae087b2f/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: good.png Type: image/png Size: 25480 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/ae087b2f/attachment-0003.png From drriddle at qwest.net Thu Jul 31 22:20:45 2003 From: drriddle at qwest.net (Reed Riddle) Date: Thu, 31 Jul 2003 21:20:45 -0500 Subject: [XForms] Form imaging problems In-Reply-To: <006301c3577b$499ebe80$6501a8c0@dimensionxp> Message-ID: Try freezing the form, then building it, filling in the data, etc, and then unfreeze the form when everything is loaded. I see this sometimes, but that's usually before I get around to adding the freezing/unfreezing cycle when I do something to the form. Reed On Thursday, July 31, 2003, at 10:49 AM, Matthew Yaconis wrote: > To subscribers of the xforms list > > > For some reason the first time I display a form it doesn't image > properly. > The attached images show what it looks like. The window consists of > approximately 50 forms, a main form, a scrollable form, and 40+ row > forms > whos objects are added to the scrollable form which is then attached > to the > main form via a form browser. > > Any suggestions or help would be much appreciated. (The good.png image > shows how the form should look. The bad.png image shows how it looks > when > it is first displayed.) > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From myaconis at nycap.rr.com Fri Aug 1 10:22:04 2003 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Fri, 1 Aug 2003 10:22:04 -0400 Subject: [XForms] Odd menu field behavior Message-ID: <004401c35838$491d5da0$6501a8c0@dimensionxp> I have a menu object that I generate an FL_PUP_ENTRY structure for from data retrieved from a mysql database. I don't do anything particularly special with this menu object but for some reason the fl_get_menu function returns a "0" (zero) randomly when selections are made off of the list. Does anyone have any idea why fl_get_menu might return a 0 when called within the object's callback routine? The callback routine goes like this: ... callback_routine (...) { choice = fl_get_menu( ob ); ... generic_routine_for_handling(ob, ...); } The generic_routine_for_handling also calls fl_get_menu. Thanks for the help on the last question as well! From eisfuchs at tigress.com Fri Aug 1 11:15:45 2003 From: eisfuchs at tigress.com (Eisfuchs) Date: Fri, 1 Aug 2003 17:15:45 +0200 Subject: [XForms] Unsubscribe and help not working Message-ID: <200308011715.45725.eisfuchs@tigress.com> Hi! I'm trying to unsubscribe from the list but everytime I get errors back. I send an eMail with Subject: unsubscribe and empty body or unsubscribe in the body. Even the help command does not work. Can someone help me? > The original message was received at Fri, 1 Aug 2003 11:01:01 -0400 > from mail.yatho.de [213.200.97.76] > > ----- The following addresses had permanent fatal errors ----- > "|/var/mailman//mail/mailman mailcmd xforms" > (reason: 6) > (expanded from: ) > > ----- Transcript of session follows ----- > Illegal command: mailcmd > 554 5.3.0 unknown mailer error 6 Final-Recipient: RFC822; xforms-request at bob.usuhs.mil X-Actual-Recipient: X-Unix; |/var/mailman//mail/mailman mailcmd xforms Action: failed Status: 5.0.0 Diagnostic-Code: X-Unix; 6 Last-Attempt-Date: Fri, 1 Aug 2003 11:14:46 -0400 -- Eisfuchs, from Germany. From angus.leeming at btopenworld.com Fri Aug 1 12:37:01 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 1 Aug 2003 16:37:01 +0000 Subject: [XForms] Unsubscribe and help not working In-Reply-To: <200308011715.45725.eisfuchs@tigress.com> References: <200308011715.45725.eisfuchs@tigress.com> Message-ID: <200308011637.01891.angus.leeming@btopenworld.com> On Friday 01 August 2003 3:15 pm, Eisfuchs wrote: > To subscribers of the xforms list > > > Hi! > > I'm trying to unsubscribe from the list but everytime I get errors back. > I send an eMail with Subject: unsubscribe and empty body or unsubscribe in > the body. Even the help command does not work. Can someone help me? And what happens if you follow the prescription in the footer to this mail? [snip] To unsubscribe, send the message "unsubscribe" to xforms-request at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms Angus From angus.leeming at btopenworld.com Wed Aug 6 13:53:22 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 6 Aug 2003 17:53:22 +0000 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: <200308061753.22818.angus.leeming@btopenworld.com> On Wednesday 06 August 2003 4:01 pm, L. D. Marks wrote: > In browser.h the definitions: > > FL_EXPORT void fl_set_browser_vscrollbar( > FL_OBJECT *ob, > int on > ); > > FL_EXPORT void fl_set_browser_hscrollbar( > FL_OBJECT *ob, > int on > ); > > are incompatible with at least some C++ where "on" > is predefined. Ouch! Your compiler is brain dead. What are you using? Does it have any other problems with the library? Regards, Angus From angus.leeming at btopenworld.com Thu Aug 7 05:35:20 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 7 Aug 2003 09:35:20 +0000 Subject: [XForms] Libraries: broken libtool.m4 In-Reply-To: References: Message-ID: <200308070935.20490.angus.leeming@btopenworld.com> On Wednesday 06 August 2003 10:59 pm, L. D. Marks wrote: > The version of libtool.m4 that you have in acinclude.m4 > appears to be broken on an HPUX 10.20 (works under linux); > after removing it the standard version picked up by > autoconf/automake & friends works fine. Hi, Laurence. Could you tell us what version of autoconf/automake you are using? From psg at debian.org Tue Sep 2 15:28:31 2003 From: psg at debian.org (Peter S Galbraith) Date: Tue, 02 Sep 2003 15:28:31 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030411130538.61277.qmail@web13403.mail.yahoo.com> References: <20030411130538.61277.qmail@web13403.mail.yahoo.com> Message-ID: <20030902192832.F003738F37@mixing.qc.dfo.ca> T.C. Zhao wrote: > All I need to do is boot up my old linux box and recover the doc and send it. > Will do this sometime in April (I've been travelling, and am sending this > email from Tokyo). > -TC Hi T.C., I really hate to keep nagging you like this. :-) You meant to release the sources of the XForms manual last April but never got around to it. This is a reminder. Also, please avoid using the GNU Free Documentation License (GFDL) since it not a free software license and therefore cannot be included in the Debian distribution. Using the GPL would be fine. I'm writing now because while the Debian GNU/Linux distribution doesn't make a release as often as it should, a freeze is due shortly for a Christmas release. The current packaging of the XForms manual has this license: No part of this document may be reproduced, in any form or by any means, without permission from the authors. Permission to produce hardcopies in its entirety for private use is granted. This lacks the permission to us to _distribute_ the manual so I'll pull the package from Debian's non-free archive soon, before the upcoming release. But instead of removing the package, it would be great to get the manual sources under a free license and move the package to Debian's main archive. Hopefully you will find time to do this. Otherwise I can always re-create the Debian package at a later time when it is released under a free license. Thanks for your time! -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From ldm at risc4.numis.nwu.edu Wed Aug 6 12:02:02 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 06 Aug 2003 16:02:02 -0000 Subject: [XForms] Libraries: small C++ bug In-Reply-To: <200306170017.39950.angus.leeming@btopenworld.com> Message-ID: In browser.h the definitions: FL_EXPORT void fl_set_browser_vscrollbar( FL_OBJECT *ob, int on ); FL_EXPORT void fl_set_browser_hscrollbar( FL_OBJECT *ob, int on ); are incompatible with at least some C++ where "on" is predefined. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From ldm at risc4.numis.nwu.edu Wed Aug 6 19:00:25 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 06 Aug 2003 23:00:25 -0000 Subject: [XForms] Libraries: broken libtool.m4 In-Reply-To: Message-ID: The version of libtool.m4 that you have in acinclude.m4 appears to be broken on an HPUX 10.20 (works under linux); after removing it the standard version picked up by autoconf/automake & friends works fine. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From Jean-Marc.Lasgouttes at inria.fr Wed Sep 3 12:37:01 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 03 Sep 2003 18:37:01 +0200 Subject: [XForms] Re: xforms configuration In-Reply-To: <200309031619.56049.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 3 Sep 2003 16:19:56 +0000") References: <200309031619.56049.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs Angus> and has made some changes, attached. Below is his summary of Angus> what he's done, but I think it can be simply summarised as Angus> Why do we ship these files in the config directory: Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh Angus> They are all parts of the autoconf/libtool code. Why not allow Angus> the user to use the versions that come with their versions of Angus> the autotools? Because a user of xforms is not required to have any of the autotools installed (unless when using cvs, of course). I think that we have to ship all these files, except possibly libtools.m4. However, I think that we must sync this file with ltmain.sh, so even this one is needed. The right thing to do is to upgrade libtool files to the latest version (our libtool.m5 is from 2001, it seems). The choice is libtool 1.4.2 from october 2002 or 1.5 from last month. I do not know whether 1.5 can cause problems. depcomp comes probably with automake, and the config.* from autoconf. All we have to do is upgrade from recent versions. Angus> 1) Removed the "on", since it does not seem to be needed. This is of course a solution, but how does 'on' appear on this system? Is this a preprocessor define in some system header? This would be _very_ bad... Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems. Fine, we probably do not need this one. But I do not think it makes any difference, since we do not rely anywhere on the HAVE_MALLOC macro. Laurence, did it really cause a problem? Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the Angus> version I was using it was not being set. I'll have to check this one. Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and Angus> let automake/autoconf/libtool handle all this. Your version did Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5 I think we should just upgrade the versions we have (after making sure that libtool 1.5 requirements are not too high). Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" Probably OK. Angus> 6) Added a few files needed by make dist (e.g. README, I can't Angus> remember them all). Good idea. Angus> 7) I also did some stuff for our own purposes, primarily Angus> removed pixmap.c so no extra libraries are needed and removed Angus> the checks for them, turned off sharing by default, restricted Angus> the build/dist to the library and removed some of your Angus> informational output at the end of the build. FYI, it works Angus> fine, and is setup so our code will compile forms if it does Angus> not find a working copy already existing on the computer. This should be investigated... Thanks for the input Laurence. JMarc From angus.leeming at btopenworld.com Wed Sep 3 12:19:56 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Sep 2003 16:19:56 +0000 Subject: [XForms] xforms configuration Message-ID: <200309031619.56049.angus.leeming@btopenworld.com> Jean-Marc, Laurence Marks has been trying to compile xforms cvs and has made some changes, attached. Below is his summary of what he's done, but I think it can be simply summarised as Why do we ship these files in the config directory: config.guess config.sub depcomp libtool.m4 ltmain.sh They are all parts of the autoconf/libtool code. Why not allow the user to use the versions that come with their versions of the autotools? Angus Laurence's 'ChangeLog' follows: I did quite a few additional hacks on your configure, testing it on HP,SGI,SUN,cgwin with both native & gcc compilers. The major changes are (I think): 1) Removed the "on", since it does not seem to be needed. 2) Removed AC_FUNC_MALLOC since it is broken on many systems. 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the version I was using it was not being set. 4) Removed the libtool stuff that you had in acinclude.m4, and let automake/autoconf/libtool handle all this. Your version did not work with automake-1.7, autoconf-2.57, libtool-1.5 5) Added (slight overkill, but AC_PATH_XTRA does not work the way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" 6) Added a few files needed by make dist (e.g. README, I can't remember them all). 7) I also did some stuff for our own purposes, primarily removed pixmap.c so no extra libraries are needed and removed the checks for them, turned off sharing by default, restricted the build/dist to the library and removed some of your informational output at the end of the build. FYI, it works fine, and is setup so our code will compile forms if it does not find a working copy already existing on the computer. -------------- next part -------------- A non-text attachment was scrubbed... Name: marks.diff.gz Type: application/x-gzip Size: 49844 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030903/84e1704e/attachment-0001.gz From larsbj at lyx.org Wed Sep 3 17:44:50 2003 From: larsbj at lyx.org (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: Wed, 03 Sep 2003 23:44:50 +0200 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: "L. D. Marks" writes: | To subscribers of the xforms list > > | In browser.h the definitions: > | FL_EXPORT void fl_set_browser_vscrollbar( | FL_OBJECT *ob, | int on | ); > | FL_EXPORT void fl_set_browser_hscrollbar( | FL_OBJECT *ob, | int on | ); > | are incompatible with at least some C++ where "on" | is predefined. Predefined as what? This is certainly not Standard C++. Can you should where/how you get that error? (and the error itself) -- Lgb From larsbj at lyx.org Wed Sep 3 18:53:03 2003 From: larsbj at lyx.org (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: Thu, 04 Sep 2003 00:53:03 +0200 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: "L. D. Marks" writes: | I did a little more checking, and it looks like our code was defining | "on" itself, and since this was in an include that came before forms.h | this created problems. (We probably should not be using "on" - maybe | you might want to think about "forms_on" to be more robust. The | earlier forms header files did not have the "on" defined.) What stops you from polluting the global namespace with a macro/define called forms_on? (and using forms_on in xforms give away the wrong meaning of the parameter... and removing it from the function declaration makes it impossible to see what this int is) It is your code that is in error, not xforms. -- Lgb From Holly.Yeh at grc.nasa.gov Thu Sep 4 10:53:32 2003 From: Holly.Yeh at grc.nasa.gov (Holly Yeh) Date: Thu, 04 Sep 2003 10:53:32 -0400 Subject: [XForms] Making XForms Multi-Threaded Message-ID: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> Hi, We are planning on making XForms multi-threaded. If anyone has any planning or been working on the issue, Please let us know. Thank you very much! Holly Yeh. From angus.leeming at btopenworld.com Thu Sep 4 12:08:46 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 4 Sep 2003 16:08:46 +0000 Subject: [XForms] Making XForms Multi-Threaded In-Reply-To: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> Message-ID: <200309041608.46270.angus.leeming@btopenworld.com> On Thursday 04 September 2003 2:53 pm, Holly Yeh wrote: > To subscribers of the xforms list > > > Hi, > We are planning on making XForms multi-threaded. If anyone has any > planning or been working on the issue, Please let us know. > Thank you very much! > > Holly Yeh. Hello, Holly. that sounds great. However, I wonder if you might not find FLTK (Fast Light ToolKit http://www.fltk.org) fits your needs already. Yeah, yeah, I know. I'm the guy fronting xforms, not fltk. Nonetheless, and without wanting to appear disloyal to xforms, FLTK has an active developer community (which IMO counts for a lot), it has multithreaded support already and, perhaps most importantly, it has an xforms -> fltk converter so porting your app might well be painless. http://www.fltk.org/documentation.php/doc-1.1/forms.html#15_1 Kind regards, Angus From ldm at risc4.numis.nwu.edu Wed Sep 3 12:45:22 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 3 Sep 2003 11:45:22 -0500 (CDT) Subject: [XForms] Re: xforms configuration In-Reply-To: Message-ID: On Wed, 3 Sep 2003, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs > Angus> and has made some changes, attached. Below is his summary of > Angus> what he's done, but I think it can be simply summarised as > > Angus> Why do we ship these files in the config directory: > Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh > > Angus> They are all parts of the autoconf/libtool code. Why not allow > Angus> the user to use the versions that come with their versions of > Angus> the autotools? > > Because a user of xforms is not required to have any of the autotools > installed (unless when using cvs, of course). > > I think that we have to ship all these files, except possibly > libtools.m4. However, I think that we must sync this file with > ltmain.sh, so even this one is needed. > > The right thing to do is to upgrade libtool files to the latest > version (our libtool.m5 is from 2001, it seems). The choice is libtool > 1.4.2 from october 2002 or 1.5 from last month. I do not know whether > 1.5 can cause problems. In the version that was in the cvs, the libtool stuff was in acinclude.m4 so cancelled my more current version of libtool etc. I removed it from acinclude.m4 -- you do need to ship a viable version. > > depcomp comes probably with automake, and the config.* from autoconf. > All we have to do is upgrade from recent versions. > > Angus> 1) Removed the "on", since it does not seem to be needed. > > This is of course a solution, but how does 'on' appear on this system? > Is this a preprocessor define in some system header? This would be > _very_ bad... If I remember right, "on" was defined in g++. The header was fine with gcc, died with g++. > > Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems. > > Fine, we probably do not need this one. But I do not think it makes > any difference, since we do not rely anywhere on the HAVE_MALLOC > macro. Laurence, did it really cause a problem? Yes. If it did not find a GNU malloc it redefined it to rpl_malloc and you then had to link this in otherwise you would have an undefined symbol. > > Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the > Angus> version I was using it was not being set. > > I'll have to check this one. > > Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and > Angus> let automake/autoconf/libtool handle all this. Your version did > Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5 > > I think we should just upgrade the versions we have (after making sure > that libtool 1.5 requirements are not too high). > > Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the > Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) > Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 > Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" > > Probably OK. > > Angus> 6) Added a few files needed by make dist (e.g. README, I can't > Angus> remember them all). > > Good idea. > > Angus> 7) I also did some stuff for our own purposes, primarily > Angus> removed pixmap.c so no extra libraries are needed and removed > Angus> the checks for them, turned off sharing by default, restricted > Angus> the build/dist to the library and removed some of your > Angus> informational output at the end of the build. FYI, it works > Angus> fine, and is setup so our code will compile forms if it does > Angus> not find a working copy already existing on the computer. > > This should be investigated... > > Thanks for the input Laurence. > > JMarc > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From ldm at risc4.numis.nwu.edu Wed Sep 3 18:33:20 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 3 Sep 2003 17:33:20 -0500 (CDT) Subject: [XForms] Libraries: small C++ bug In-Reply-To: Message-ID: I did a little more checking, and it looks like our code was defining "on" itself, and since this was in an include that came before forms.h this created problems. (We probably should not be using "on" - maybe you might want to think about "forms_on" to be more robust. The earlier forms header files did not have the "on" defined.) On Wed, 3 Sep 2003, [iso-8859-1] Lars Gullik Bj?nnes wrote: > "L. D. Marks" writes: > > | To subscribers of the xforms list > > > > > | In browser.h the definitions: > > > | FL_EXPORT void fl_set_browser_vscrollbar( > | FL_OBJECT *ob, > | int on > | ); > > > | FL_EXPORT void fl_set_browser_hscrollbar( > | FL_OBJECT *ob, > | int on > | ); > > > | are incompatible with at least some C++ where "on" > | is predefined. > > Predefined as what? > This is certainly not Standard C++. > > Can you should where/how you get that error? > (and the error itself) > > -- > Lgb > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From jac4 at andrew.cmu.edu Wed Sep 3 23:39:03 2003 From: jac4 at andrew.cmu.edu (jason) Date: Wed, 3 Sep 2003 23:39:03 -0400 (EDT) Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: > | I did a little more checking, and it looks like our code was defining > | "on" itself, and since this was in an include that came before forms.h > | this created problems. (We probably should not be using "on" - maybe > | you might want to think about "forms_on" to be more robust. The > | earlier forms header files did not have the "on" defined.) > > What stops you from polluting the global namespace with a macro/define > called forms_on? (and using forms_on in xforms give away the wrong > meaning of the parameter... and removing it from the function > declaration makes it impossible to see what this int is) > > It is your code that is in error, not xforms. Yeah I'm going to have to agree with him on that one. There is no "on" in any of the standard C++ headers, afaik. Additionally, having a macro defined as "on" is not specific to C++... things could be messed up the same way if everything was in C. From angus.leeming at btopenworld.com Thu Sep 4 13:57:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 4 Sep 2003 17:57:02 +0000 Subject: [XForms] Making XForms Multi-Threaded In-Reply-To: <5.1.1.5.2.20030904124900.01884068@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> <5.1.1.5.2.20030904124900.01884068@popserve.grc.nasa.gov> Message-ID: <200309041757.02703.angus.leeming@btopenworld.com> On Thursday 04 September 2003 4:50 pm, Holly Yeh wrote: > Hi Angus, > Thank you for your input, Is fltk supported on tru64 Unix? > > Holly Yeh. I don't know, Holly. I've never used it in anger. But it's open source, has mailing lists of its own and took about 5 mins to compile the source. I don't suppose it'd take long for you to try it out, now would it? Comes with lots of documentation and test programs too... Best regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Sep 5 09:44:29 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 05 Sep 2003 15:44:29 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: (Jean-Marc Lasgouttes's message of "Thu, 31 Jul 2003 18:36:28 +0200") References: <200307311732.59411.leeming@lyx.org> Message-ID: A non-text attachment was scrubbed... Name: local2.diff Type: text/x-patch Size: 7382 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030905/44db0cb7/attachment-0001.bin From tc_zhao at yahoo.com Mon Sep 8 11:48:38 2003 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Mon, 8 Sep 2003 08:48:38 -0700 (PDT) Subject: [XForms] Re: XForms: Documentation In-Reply-To: <20030902192832.F003738F37@mixing.qc.dfo.ca> Message-ID: <20030908154838.51918.qmail@web13407.mail.yahoo.com> Sorry for the delay and thanks for the info. GPL it is. I am currently travelling and will be back home end of September. Expect the free manual in October sometime. -TC --- Peter S Galbraith wrote: > To subscribers of the xforms list > > > T.C. Zhao wrote: > > > All I need to do is boot up my old linux box and recover the doc and send > it. > > Will do this sometime in April (I've been travelling, and am sending this > > email from Tokyo). > > -TC > > Hi T.C., > > I really hate to keep nagging you like this. :-) > > You meant to release the sources of the XForms manual last April but > never got around to it. This is a reminder. Also, please avoid using > the GNU Free Documentation License (GFDL) since it not a free software > license and therefore cannot be included in the Debian distribution. > Using the GPL would be fine. > > I'm writing now because while the Debian GNU/Linux distribution doesn't > make a release as often as it should, a freeze is due shortly for a > Christmas release. The current packaging of the XForms manual has this > license: > > No part of this document may be reproduced, in any form or by any > means, without permission from the authors. Permission to produce > hardcopies in its entirety for private use is granted. > > This lacks the permission to us to _distribute_ the manual so I'll pull > the package from Debian's non-free archive soon, before the upcoming > release. But instead of removing the package, it would be great to get > the manual sources under a free license and move the package to Debian's > main archive. Hopefully you will find time to do this. Otherwise I can > always re-create the Debian package at a later time when it is released > under a free license. > > Thanks for your time! > -- > Peter S. Galbraith, Debian Developer > http://people.debian.org/~psg > GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From psg at debian.org Mon Sep 8 11:57:53 2003 From: psg at debian.org (Peter S Galbraith) Date: Mon, 08 Sep 2003 11:57:53 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030908154838.51918.qmail@web13407.mail.yahoo.com> References: <20030908154838.51918.qmail@web13407.mail.yahoo.com> Message-ID: <20030908155753.3FB3238F7E@mixing.qc.dfo.ca> T.C. Zhao wrote: > > Sorry for the delay and thanks for the info. GPL it is. > > I am currently travelling and will be back home end of September. Expect the > free manual in October sometime. > > -TC Thanks TC! Would you also mind replying to this message (and CC the mailing list for the public record) and give permission to Debian to distribute the current version of the manual in its non-free archive and mirrors, e.g. http://packages.debian.org/unstable/doc/libforms-doc.html This would gives us the required permission not present in the current license. Thanks again! -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From angus.leeming at btopenworld.com Mon Sep 8 21:04:13 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 01:04:13 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: Message-ID: <200309090051.14280.leeming@lyx.org> On Friday 05 September 2003 1:44 pm, Jean-Marc Lasgouttes wrote: > Angus> Fantastic effort. The logic here seems to be inverted though. > Angus> Am I right? > > Jean-Marc> Yes, it should be #ifdef HAVE_USLEEP > > Jean-Marc> also, there is a problem with line 83 of signal.c, where > Jean-Marc> dec cc does not like my code. I have to leave now, I'll > Jean-Marc> have a look tomorrow. > > I finally finished this a bit and added a few things. Angus, could you > commit this after review? > > JMarc Many thaks for doing this Jean-Marc. It is now committed. Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 05:18:41 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 11:18:41 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309090051.14280.leeming@lyx.org> (Angus Leeming's message of "Tue, 9 Sep 2003 01:04:13 +0000") References: <200309090051.14280.leeming@lyx.org> Message-ID: A non-text attachment was scrubbed... Name: chglog.diff Type: text/x-patch Size: 1075 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/51b7308c/attachment-0001.bin From angus.leeming at btopenworld.com Tue Sep 9 06:43:05 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 10:43:05 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: <200309090051.14280.leeming@lyx.org> Message-ID: <200309091043.05489.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: JMarc> Angus> Many thaks for doing this Jean-Marc. It is now committed. Angus JMarc> You forgot the Changelog entry. No I didn't, but I'll admit that my subsequent commit with a date of 23 May is confusing (and wrong). I've fixed that. Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 06:16:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 12:16:19 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309091043.05489.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 10:43:05 +0000") References: <200309090051.14280.leeming@lyx.org> <200309091043.05489.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: JMarc> Angus> Many thaks for doing this Jean-Marc. It is now JMarc> committed. Angus You forgot the Changelog entry. Angus> No I didn't, but I'll admit that my subsequent commit with a Angus> date of 23 May is confusing (and wrong). I've fixed that. You're right, it is cvs update that got confused actually. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 06:47:37 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 12:47:37 +0200 Subject: [XForms] [PATCH] Enable optional building of demos/ directory Message-ID: A non-text attachment was scrubbed... Name: demos.diff Type: text/x-patch Size: 2257 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/2173d3a5/attachment-0001.bin From angus.leeming at btopenworld.com Tue Sep 9 08:46:50 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 12:46:50 +0000 Subject: [XForms] Re: [PATCH] Enable optional building of demos/ directory In-Reply-To: References: Message-ID: <200309091246.50358.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 10:47 am, Jean-Marc Lasgouttes wrote: > The following patch adds an --enable-demos flag to configure > > Angus, please apply if it works OK for you. Oh, JMarc, you beauty! Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 08:22:32 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 14:22:32 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309091245.11255.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 12:45:11 +0000") References: <200309091043.05489.angus.leeming@btopenworld.com> <200309091245.11255.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Let's try and make a road plan for a 1.1 release. I guess we Angus> should address the problems with the autotools that Laurence Angus> Marks described. Yes. I have not looked at that seriously yet. One thing I noticed is that we lack an INSTALL file (to be taken from autoconf). The file Copyright should maybe be included in some other file (and the reference to COPYING changed to COPYING.LIB). The copyrights should be changed to include at least you (and me) (also in lib/version.c). Angus> Here I have Red Hat 8 which comes with automake 1.6.3, autoconf Angus> 2.53 and libtool 1.4.2. We should probably pick something newer... Angus> I find that if I remove depcomp and the config.*, then Angus> automake, autoconf shove in new versions. Great. However, if I Angus> remove libtool.m4 and run libtoolize, I do do not get a new Angus> version of libtool.m4. I guess, therefore that it is no longer Angus> needed? The libtool documentation says: When you invoke the libtoolize program (see section 5.4.1 Invoking libtoolize), it will tell you where to find a definition of AC_PROG_LIBTOOL. If you use Automake, the aclocal program will automatically add AC_PROG_LIBTOOL support to your configure script. Nevertheless, it is advisable to include a copy of `libtool.m4' in `acinclude.m4', so that, even if `aclocal.m4' and `configure' are rebuilt for any reason, the appropriate libtool macros will be used. The alternative is to hope the user will have a compatible version of `libtool.m4' installed and accessible for aclocal. This may lead to weird errors when versions don't match. So we should keep a libtool.m4. Angus> Here is the patch. Wa d'ya think? Angus I'd say let's refine it a bit first. Angus> NB, reading on the web, it appears that others have added Angus> libtoolize to autogen.sh Angus> http://mail.gnome.org/archives/gtk-devel-list/2002-September/msg00015.html If you look at the autoconf repository, you will even find out that the have special makefile targets to update all these files automatically from the gnu ftp site. I am not sure whether we want to go to such extreme methods, though. JMarc From tc_zhao at yahoo.com Tue Sep 9 10:07:59 2003 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Tue, 9 Sep 2003 07:07:59 -0700 (PDT) Subject: [XForms] Re: XForms: Documentation In-Reply-To: <20030908155753.3FB3238F7E@mixing.qc.dfo.ca> Message-ID: <20030909140759.33379.qmail@web13406.mail.yahoo.com> Hi Peter, Please feel free to include the current manual in the Debian distribution. For the public record, I am granting the rights to all linux distributors to distribute all versions of xforms manual without fee in all electronic formats (.tex,.psf, .ps, .html) with the requirement that the distributed versions retain the copyright notice and version number. -TC --- Peter S Galbraith wrote: > T.C. Zhao wrote: > > > > > Sorry for the delay and thanks for the info. GPL it is. > > > > I am currently travelling and will be back home end of September. Expect > the > > free manual in October sometime. > > > > -TC > > Thanks TC! > > Would you also mind replying to this message (and CC the mailing list > for the public record) and give permission to Debian to distribute the > current version of the manual in its non-free archive and mirrors, e.g. > > http://packages.debian.org/unstable/doc/libforms-doc.html > > This would gives us the required permission not present in the current > license. > > Thanks again! > -- > Peter S. Galbraith, Debian Developer > http://people.debian.org/~psg > GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From psg at debian.org Tue Sep 9 10:21:36 2003 From: psg at debian.org (Peter S Galbraith) Date: Tue, 09 Sep 2003 10:21:36 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030909140759.33379.qmail@web13406.mail.yahoo.com> References: <20030909140759.33379.qmail@web13406.mail.yahoo.com> Message-ID: <20030909142136.C3CEB39205@mixing.qc.dfo.ca> T.C. Zhao wrote: > Hi Peter, > > Please feel free to include the current manual in the Debian distribution. > > For the public record, I am granting the rights to all linux distributors to > distribute all versions of xforms manual without fee in all electronic > formats (.tex,.psf, .ps, .html) with the requirement that the distributed > versions retain the copyright notice and version number. > > -TC Many thanks T.C. ! This is exactly what I needed until the free release. :-) Peter -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 11:02:53 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 17:02:53 +0200 Subject: [XForms] [PATCH] Simplify configure.ac Message-ID: A non-text attachment was scrubbed... Name: conf.diff Type: text/x-patch Size: 3945 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/0a0cb9c4/attachment-0001.bin From angus.leeming at btopenworld.com Tue Sep 9 13:16:10 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 17:16:10 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: References: Message-ID: <200309091716.10189.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 3:02 pm, Jean-Marc Lasgouttes wrote: > The following patch removes tests that are as far as I can see not > used. I tried to check carefully what the side effects of the various > autoconf macros are. The idea is to keep all tests that already exist > in some form in xforms 1.0. > Angus, please double check and apply (note that the ChangeLog chunk > will not apply after my other patch, since this is against unpatched > HEAD; I'll redo the patch if there is a problem). Well, it works for me it all looks reasonable and, as I think of you as the whizz in these things anyway, that's good enough for me. I applied it. Many thanks. > Something that still has to be done is implement --disable-gl to avoid > building libformsGL when not relevant. It should not be too difficult > to make a test to autodetect this. Good idea. Actually, shouldn't that be --enable-gl (defaults to 'no'), identical to you little test for --enable-demos? Of course, it would actually do some testing if the answer were 'yes'. Angus From wd4nmq at comcast.net Tue Sep 9 14:49:22 2003 From: wd4nmq at comcast.net (Jeff Pierce) Date: Tue, 09 Sep 2003 14:49:22 -0400 Subject: [XForms] Windows with transparent background and no border. Message-ID: <3F5E20B2.6030502@comcast.net> Is it possible at all under X windows to have a non-rectangular window like under MS Windows? The call under MS is AddRectToRgn(). Where you have a mask that is treated like chroma mixing, ie green screen, in movies/tv. Then the portions of the underlying desktop will show through and key presses in those areas will not go to the app, but to whatever is underneath it. I know that xfornms does not support this. But, does anybody knoe of a way to do it using any other X frameworks? -- Jeff, wd4nmq wd4nmq at comcast.net http://mywebpages.comcast.net/wd4nmq From Jean-Marc.Lasgouttes at inria.fr Wed Sep 10 08:56:25 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 10 Sep 2003 14:56:25 +0200 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <200309091716.10189.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 17:16:10 +0000") References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: gl.diff Type: text/x-patch Size: 2739 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030910/58819f35/attachment-0001.bin From angus.leeming at btopenworld.com Tue Sep 9 08:45:11 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 12:45:11 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: <200309091043.05489.angus.leeming@btopenworld.com> Message-ID: <200309091245.11255.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 10:16 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > Angus> To subscribers of the xforms list > Angus> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: > JMarc> Angus> Many thaks for doing this Jean-Marc. It is now > JMarc> committed. Angus You forgot the Changelog entry. > > Angus> No I didn't, but I'll admit that my subsequent commit with a > Angus> date of 23 May is confusing (and wrong). I've fixed that. > > You're right, it is cvs update that got confused actually. Let's try and make a road plan for a 1.1 release. I guess we should address the problems with the autotools that Laurence Marks described. > The right thing to do is to upgrade libtool files to the latest > version (our libtool.m5 is from 2001, it seems). The choice is libtool > 1.4.2 from october 2002 or 1.5 from last month. I do not know whether > 1.5 can cause problems. > depcomp comes probably with automake, and the config.* from autoconf. > All we have to do is upgrade from recent versions. Here I have Red Hat 8 which comes with automake 1.6.3, autoconf 2.53 and libtool 1.4.2. I find that if I remove depcomp and the config.*, then automake, autoconf shove in new versions. Great. However, if I remove libtool.m4 and run libtoolize, I do do not get a new version of libtool.m4. I guess, therefore that it is no longer needed? Certainly, I can confirm that everything works for me. Here is the patch. Wa d'ya think? Angus NB, reading on the web, it appears that others have added libtoolize to autogen.sh http://mail.gnome.org/archives/gtk-devel-list/2002-September/msg00015.html Should we do so? -------------- next part -------------- A non-text attachment was scrubbed... Name: updatetools.diff.bz2 Type: application/x-bzip2 Size: 42918 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/4721bc35/attachment-0001.bz2 From angus.leeming at btopenworld.com Wed Sep 10 12:56:42 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 16:56:42 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: <200309101656.42201.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 12:56 pm, Jean-Marc Lasgouttes wrote: > >> Something that still has to be done is implement --disable-gl to > >> avoid building libformsGL when not relevant. It should not be too > >> difficult to make a test to autodetect this. > > Angus> Good idea. Actually, shouldn't that be --enable-gl (defaults to > Angus> 'no'), identical to you little test for --enable-demos? Of > Angus> course, it would actually do some testing if the answer were > Angus> 'yes'. > > See attached patch. The code only builds the gl/ subdir if GL/glx.h is > found. You can add an explicit --disable-gl to avoid building. > > I also simplified the code for --enable-demos. Thanks for this. > BTW, what should we do about the xforms rpm? Building it with gl > support would mean that applications like LyX would depend on GL > support, which is stupid. An alternative would be to make separate > xforms and xforms-gl rpms, but this is a bit heavy IMO. Heavy or not, it is the right thing to do. In fact, being brutal about this, we should have separate rpms for each library, xforms, xforms-image and xforms-gl. Moreover, fdesign and fd2ps are developer tools. They should go, therefore, in the xforms-devel rpm. Angus From psg at debian.org Wed Sep 10 13:02:48 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:02:48 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Jean-Marc Lasgouttes References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: <20030910170249.0137A38F37@mixing.qc.dfo.ca> Jean-Marc Lasgouttes wrote: > support would mean that applications like LyX would depend on GL > support, which is stupid. An alternative would be to make separate > xforms and xforms-gl rpms, but this is a bit heavy IMO. This is what I do for Debian anyway: http://packages.debian.org/unstable/libs/libforms1.html http://packages.debian.org/unstable/libs/libformsgl1.html http://packages.debian.org/unstable/libdevel/libforms-dev.html http://packages.debian.org/unstable/devel/libformsgl-dev.html http://packages.debian.org/unstable/devel/libforms-bin.html Peter From angus.leeming at btopenworld.com Wed Sep 10 14:09:03 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:09:03 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910170249.0137A38F37@mixing.qc.dfo.ca> References: <20030910170249.0137A38F37@mixing.qc.dfo.ca> Message-ID: <200309101809.03546.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:02 pm, Peter S Galbraith wrote: > To subscribers of the xforms list > > Jean-Marc Lasgouttes wrote: > > support would mean that applications like LyX would depend on GL > > support, which is stupid. An alternative would be to make separate > > xforms and xforms-gl rpms, but this is a bit heavy IMO. > > This is what I do for Debian anyway: > > http://packages.debian.org/unstable/libs/libforms1.html > http://packages.debian.org/unstable/libs/libformsgl1.html > http://packages.debian.org/unstable/libdevel/libforms-dev.html > http://packages.debian.org/unstable/devel/libformsgl-dev.html > http://packages.debian.org/unstable/devel/libforms-bin.html Any reason why you don't split up xforms and xforms-image? Is making dep packages automatically just a case of adding the correct Makefile target and leaving the computer to do its stuff? If so, feel free to submit a patch. Angus From psg at debian.org Wed Sep 10 13:25:38 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:25:38 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Angus Leeming <200309101809.03546.angus.leeming@btopenworld.com> References: <20030910170249.0137A38F37@mixing.qc.dfo.ca> <200309101809.03546.angus.leeming@btopenworld.com> Message-ID: <20030910172538.4755438F37@mixing.qc.dfo.ca> Angus Leeming wrote: > On Wednesday 10 September 2003 5:02 pm, Peter S Galbraith wrote: > > To subscribers of the xforms list > > > > Jean-Marc Lasgouttes wrote: > > > support would mean that applications like LyX would depend on GL > > > support, which is stupid. An alternative would be to make separate > > > xforms and xforms-gl rpms, but this is a bit heavy IMO. > > > > This is what I do for Debian anyway: > > > > http://packages.debian.org/unstable/libs/libforms1.html > > http://packages.debian.org/unstable/libs/libformsgl1.html > > http://packages.debian.org/unstable/libdevel/libforms-dev.html > > http://packages.debian.org/unstable/devel/libformsgl-dev.html > > http://packages.debian.org/unstable/devel/libforms-bin.html > > Any reason why you don't split up xforms and xforms-image? Only because the image library didn't cause the added depencies to be too onerous. Most users already have installed the packages for libjpeg, libtiff and libXpm. OpenGL is another story, so I bundled it separately. > Is making dep packages automatically just a case of adding the correct > Makefile target and leaving the computer to do its stuff? If so, feel > free to submit a patch. Making Debian packages involves a debian/ directory. See http://ftp.debian.org/debian/pool/main/libf/libforms1/libforms1_1.0-4.diff.gz for what I add/change from the original tar ball. It's not a huge deal for me to keep this separate and apply it after your release, and I suppose having an outdated debian directory can sometimes cause problems. I include it in CVS for projects that I'm heavily involved with (gri and MH-E) and have CVS access, and don't do it in the majority of my packages (because I don't track CVS as much as would be required). Making the actual packages also involves doing it on a Debian system, of course, since specific tools are required to calculate dependencies and certain helper packages are invoked. Peter From psg at debian.org Wed Sep 10 13:38:27 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:38:27 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Angus Leeming <200309101834.25195.angus.leeming@btopenworld.com> References: <200309101809.03546.angus.leeming@btopenworld.com> <20030910172538.4755438F37@mixing.qc.dfo.ca> <200309101834.25195.angus.leeming@btopenworld.com> Message-ID: <20030910173827.8971A38F37@mixing.qc.dfo.ca> Angus Leeming wrote: > On Wednesday 10 September 2003 5:25 pm, Peter S Galbraith wrote: > > Making Debian packages involves a debian/ directory. See > > http://ftp.debian.org/d[snip...]/libforms1_1.0-4.diff.gz > > Cool! I didn't know you'd done that! I'll have a look at some stage. You didn't know is was packaged? > > Making the actual packages also involves doing it on a Debian system, > > of course, since specific tools are required to calculate dependencies > > and certain helper packages are invoked. > > Sure. But then that is true also of rpmdist. Yeah, I added that as an afterthought. It did seem fairly obvious. I just wanted to make sure. :-) Peter From angus.leeming at btopenworld.com Wed Sep 10 14:34:25 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:34:25 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910172538.4755438F37@mixing.qc.dfo.ca> References: <200309101809.03546.angus.leeming@btopenworld.com> <20030910172538.4755438F37@mixing.qc.dfo.ca> Message-ID: <200309101834.25195.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:25 pm, Peter S Galbraith wrote: > Making Debian packages involves a debian/ directory. See > http://ftp.debian.org/d[snip...]/libforms1_1.0-4.diff.gz Cool! I didn't know you'd done that! I'll have a look at some stage. > Making the actual packages also involves doing it on a Debian system, > of course, since specific tools are required to calculate dependencies > and certain helper packages are invoked. Sure. But then that is true also of rpmdist. This is from Makefile.am in the top level dir. rpmdist: dist if [ -z "`type -path rpmbuild`" ]; \ then \ RPMBUILD=rpm; \ else \ RPMBUILD=rpmbuild; \ fi; $$RPMBUILD -ta $(PACKAGE)-$(VERSION).tar.gz ; saved_status=$$?; \ exit $$saved_status Regards, Angus From angus.leeming at btopenworld.com Wed Sep 10 14:44:23 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:44:23 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910173827.8971A38F37@mixing.qc.dfo.ca> References: <200309101834.25195.angus.leeming@btopenworld.com> <20030910173827.8971A38F37@mixing.qc.dfo.ca> Message-ID: <200309101844.23539.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:38 pm, Peter S Galbraith wrote: > You didn't know is was packaged? Let's just say that my ignorance is boundless. Angus From vs85 at cornell.edu Mon Sep 15 17:11:38 2003 From: vs85 at cornell.edu (Veera) Date: Mon, 15 Sep 2003 17:11:38 -0400 Subject: [XForms] XForms installation Message-ID: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> Hi, I have some problems when i was trying to install xforms on cygwin(latest version 1.5.4 with XFREE86). First I unzipped the xforms.1.0.tar file. then typed xmkmf -a. This command went through well. After that when i typed 'make' the program stops and gives this error message: make[1]: *** No rule to make target `../lib/libforms.a', needed by `fd2ps.exe'. Stop. make[1]: Leaving directory `/usr/x11r6/xforms-1.0/fd2ps' make: *** [all] Error 2 I have already installed the xpm library. Is it a problem due to bad xpm installation? I tried installing the binary version bxforms.089. Again the demos don't run and it gives an fl_initialise error (unable to open). Can someone please tell me the steps for installing xforms on cygwin and making the demos work. thanks Veera From angus.leeming at btopenworld.com Tue Sep 16 05:01:13 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 16 Sep 2003 09:01:13 +0000 Subject: [XForms] XForms installation In-Reply-To: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> References: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> Message-ID: <200309160901.13982.angus.leeming@btopenworld.com> On Monday 15 September 2003 9:11 pm, Veera wrote: > Hi, > > I have some problems when i was trying to install xforms on cygwin(latest > version 1.5.4 with XFREE86). First I unzipped the xforms.1.0.tar file. then > typed xmkmf -a. This command went through well. After that when i typed > 'make' the program stops and gives this error message: > > make[1]: *** No rule to make target `../lib/libforms.a', needed by > `fd2ps.exe'. Stop. > make[1]: Leaving directory `/usr/x11r6/xforms-1.0/fd2ps' > make: *** [all] Error 2 > > Can someone please tell me the steps for installing xforms on cygwin and > making the demos work. This is going to sound kludgy, but... Go into the lib subdirectory and type $ make $ make install (as root) Thereafter, fd2ps should be able to find the libforms.a/.so files fine when you return to the top level directory and type $ make Alternatively, and perhaps less kludgily, set your LD_LIBRARY_PATH variable to include the path to the generated libforms.a/.so files. Angus From ldm at risc4.numis.nwu.edu Tue Sep 23 20:21:32 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Tue, 23 Sep 2003 19:21:32 -0500 (CDT) Subject: [XForms] Redhat 9.0 libforms.a incompatibility Message-ID: I just upgraded my system to Redhat 9.0, and it appears that there are some incompatibilties between the include file definitions (in my version anyway) and the version of libforms.a that they are shipping. (I deleted their version and just installed one I compiled, but you might want to decide how to deal with this in a general way.) ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From davidwriter at yahoo.com Wed Sep 24 14:25:50 2003 From: davidwriter at yahoo.com (David Scriven) Date: Wed, 24 Sep 2003 14:25:50 -0400 (EDT) Subject: [XForms] Redhat 9.0 libforms.a incompatibility In-Reply-To: Message-ID: <20030924182550.70945.qmail@web41214.mail.yahoo.com> As far as I know Red Hat has not shipped xforms since version 7.2. The problems that you were having with the (presumably old) libforms.a are not unique to xforms. Static linking was changed in RH 9 and most old archives had to be recompiled otherwise you get errors. You can check the archive of this list to see what the errors were. DS --- "L. D. Marks" wrote: > To subscribers of the xforms list > > > I just upgraded my system to Redhat 9.0, and it appears > that there are some incompatibilties between the include > file definitions (in my version anyway) and the version > of libforms.a that they are shipping. (I deleted their > version and just installed one I compiled, but you might > want to decide how to deal with this in a general > way.) > > ----------------------------------------------- > Laurence Marks > Department of Materials Science and Engineering > MSE Rm 2036 Cook Hall > 2225 N Campus Drive > Northwestern University > Evanston, IL 60201, USA > Tel: (847) 491-3996 Fax: (847) 491-7820 > mailto:ldm at risc4.numis.nwu.edu > http://www.numis.nwu.edu > ----------------------------------------------- > > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From dstrang at chartermi.net Fri Oct 3 04:07:50 2003 From: dstrang at chartermi.net (David Strang) Date: Fri, 3 Oct 2003 04:07:50 -0400 Subject: [XForms] Hello - Just a test. Message-ID: <000901c38985$7055e940$6401a8c0@athlon> Hello. Regards, Dave Strang From angus.leeming at btopenworld.com Fri Oct 3 05:45:54 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 3 Oct 2003 09:45:54 +0000 Subject: [XForms] Hello - Just a test. In-Reply-To: <000901c38985$7055e940$6401a8c0@athlon> References: <000901c38985$7055e940$6401a8c0@athlon> Message-ID: <200310030945.54699.angus.leeming@btopenworld.com> On Friday 03 October 2003 8:07 am, David Strang wrote: > Hello. Hello, David. Quiet here, isn't it? Angus From ddembrow at nlxcorp.com Fri Oct 3 05:40:59 2003 From: ddembrow at nlxcorp.com (ddembrow at nlxcorp.com) Date: Fri, 3 Oct 2003 05:40:59 -0400 Subject: [XForms] xforms patch Message-ID: I have attached diff patch files for fselect.c and tabfolder.c source. Could a developer look at what is changed, and add it to the development Xforms source? The fselect_patch allows for a borderless form. This allows the use of the file selector goodie in an application which uses nothing but fixed size/borderless forms. The tabfolder_patch corrects the form position when using bottom tab folders. Without the patch the form selected with a bottom tab is place below the tab - for a full screen display the form simply disappears out of the viewing area. Thanks, ---d.dembrow NLX Corporation Phone: (703) 234-2100 FAX: (703) 234-2101 email: ddembrow at nlxcorp.com (See attached file: fselect_patch)(See attached file: tabfolder_patch) -------------- next part -------------- A non-text attachment was scrubbed... Name: fselect_patch Type: application/octet-stream Size: 288 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031003/ad06a891/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: tabfolder_patch Type: application/octet-stream Size: 737 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031003/ad06a891/attachment-0003.obj From angus.leeming at btopenworld.com Fri Oct 3 07:08:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 3 Oct 2003 11:08:26 +0000 Subject: [XForms] xforms patch In-Reply-To: References: Message-ID: <200310031108.26360.angus.leeming@btopenworld.com> On Friday 03 October 2003 9:40 am, ddembrow at nlxcorp.com wrote: > I have attached diff patch files for fselect.c and tabfolder.c source. > Could a developer look at what is changed, and add it to the > development Xforms source? Many thanks for this. > The fselect_patch allows for a borderless form. This allows the > use of the file selector goodie in an application which uses nothing > but fixed size/borderless forms. The restriction does seem entirely arbitrary. I'll apply this one happily. > The tabfolder_patch corrects the form position when usingbottom > tab folders. Without the patch the form selected with a bottom tab > is place below the tab - for a full screen display the form simply > disappears out of the viewing area. Excellent. I'll apply this too. Incidentally, what's your name? Adding this to the ChangeLog seems a little impersonal ;-) 2003-10-03 * lib/fselect.c: remove the arbitrary restriction on the display of borderless forms. * lib/tabfolder.c: display the tab forms correctly when using bottom tab folders. From dstrang at chartermi.net Fri Oct 3 14:32:11 2003 From: dstrang at chartermi.net (David Strang) Date: Fri, 3 Oct 2003 14:32:11 -0400 Subject: [XForms] Looking for advice Message-ID: <001101c389dc$a8fa6b20$6401a8c0@athlon> I have been a original Forms user for about ten years with an SGI. The Xforms libraries seem to be the logical extension for Xwindows. Though I am not new to Linux, getting Xforms to build under Linux has been troublesome for me and obtaining proper information even more so. Could I get some advice on what version of Linux (Redhat x.x/Mandrake x.x/etc.) best supports what version of Xforms. I tried Redhat 9.0 and got all kind of errors due to the new gcc compiler (3.2) and Mandrake 9.0 supplied the base libraries which I installed but couldn't get the source tools built. How do I get a fully working Xforms environment ? Regards, Dave Strang dstrang at chartermi.net From GalbraithP at dfo-mpo.gc.ca Fri Oct 3 14:40:06 2003 From: GalbraithP at dfo-mpo.gc.ca (Peter S Galbraith) Date: Fri, 03 Oct 2003 14:40:06 -0400 Subject: [XForms] Looking for advice In-Reply-To: Message from "David Strang" <001101c389dc$a8fa6b20$6401a8c0@athlon> References: <001101c389dc$a8fa6b20$6401a8c0@athlon> Message-ID: <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> David Strang wrote: > Though I am not new to Linux, getting Xforms to build under Linux has > been troublesome for me and obtaining proper information even more so. > > Could I get some advice on what version of Linux (Redhat x.x/Mandrake > x.x/etc.) best supports > what version of Xforms. I tried Redhat 9.0 and got all kind of errors due to > the new gcc compiler (3.2) > and Mandrake 9.0 supplied the base libraries which I installed but couldn't > get the source tools built. > > How do I get a fully working Xforms environment ? It's packaged under Debian if that helps. You could install Debian via Knoppix and then install XForms from Debian. Peter From angus.leeming at btopenworld.com Sat Oct 4 13:20:39 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 4 Oct 2003 17:20:39 +0000 Subject: [XForms] Looking for advice In-Reply-To: <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> References: <001101c389dc$a8fa6b20$6401a8c0@athlon> <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> Message-ID: <200310041720.39284.angus.leeming@btopenworld.com> On Friday 03 October 2003 6:40 pm, Peter S Galbraith wrote: > > How do I get a fully working Xforms environment ? > > It's packaged under Debian if that helps. You could install Debian via > Knoppix and then install XForms from Debian. There are also rpms available at ftp://ftp.lyx.org/pub/lyx/contrib/libforms-devel-1.0-release.i386.rpm ftp://ftp.lyx.org/pub/lyx/contrib/libforms-1.0-release.i386.rpm Angus From hiller at mpia-hd.mpg.de Fri Oct 10 09:41:41 2003 From: hiller at mpia-hd.mpg.de (Ulrich Hiller) Date: Fri, 10 Oct 2003 15:41:41 +0200 (MET DST) Subject: [XForms] problems installing on solaris Message-ID: <200310101341.h9ADffR02830@mpisrv.mpia-hd.mpg.de> Hello, we want to install xforms 1.0 on sun sloaris 7 and solaris 9. It fails during the make procedure with the following error message: rm -f libflimage.so.1.0~ LD_RUN_PATH=/systools/misc/xforms/lib /usr/ccs/bin/ld -o libflimage.so.1.0~ -G - z text -M mapfile -h libflimage.so.1.0 image.o image_bmp.o image_combine.o im age_convolve.o image_crop.o image_disp.o image_fits.o image_genesis.o image _gif.o image_gzip.o image_io_filter.o image_jpeg.o image_jquant.o image_mar ker.o image_png.o image_pnm.o image_postscript.o image_proc.o image_replace .o image_rotate.o image_scale.o image_sgi.o image_text.o image_tiff.o imag e_type.o image_warp.o image_xbm.o image_xpm.o image_xwd.o postscript.o ps_ core.o ps_draw.o ps_text.o rgb_db.o matrix.o -L/systools/misc/xforms/lib -l Xext -lX11 -L/usr/local/lib -L../lib -lforms -L/systools/lib -ljpeg -L/systo ols/lib -ltiff Text relocation remains referenced against symbol offset in file 0x28 image_png.o 0x30 image_png.o 0x34 image_png.o 0x38 image_png.o 0x4 image.o [........here are many lines of the same kind..............] jpeg_destroy_compress 0x2b8 image_jpeg.o jpeg_CreateCompress 0x88 image_jpeg.o jpeg_stdio_dest 0x98 image_jpeg.o jpeg_set_defaults 0xf0 image_jpeg.o jpeg_set_quality 0x108 image_jpeg.o jpeg_write_marker 0x140 image_jpeg.o jpeg_write_scanlines 0x284 image_jpeg.o jpeg_finish_compress 0x2a0 image_jpeg.o ld: fatal: relocations remain against allocatable but non-writable sections *** Error code 1 make: Fatal error: Command failed for target `libflimage.so.1.0' Current working directory /disk-b/hiller/xforms-1.0/image making all in ./fdesign... rm -f fdesign LD_RUN_PATH=/systools/misc/xforms/lib cc -o fdesign -g -Xc -xF -xcg92 -L/sys tools/misc/xforms/lib fd_attribs.o fd_control.o fd_fake.o fd_file.o fd_forms .o fd_groups.o fd_help.o fd_initforms.o fd_main.o fd_names.o fd_objects.o fd_pallette.o fd_printC.o fd_rubber.o fd_select.o fd_spec.o fd_super.o fd _util.o sp_browser.o sp_button.o sp_choice.o sp_counter.o sp_dial.o sp_fre eobj.o sp_menu.o sp_pixmap.o sp_positioner.o sp_scrollbar.o sp_slider.o sp _twheel.o sp_xyplot.o -lXext -lX11 -static -L../lib -lforms -L/systools/lib -lXpm -dynamic -lm cc: Warning: illegal option -dynamic cc: -a conflicts with -dy. *** Error code 1 make: Fatal error: Command failed for target `fdesign' Current working directory /disk-b/hiller/xforms-1.0/fdesign making all in ./fd2ps... rm -f fd2ps LD_RUN_PATH=/usr/openwin/lib cc -o fd2ps -g -Xc -xF -xcg92 -L/usr/openwin/li b align.o fd2ps.o flsupport.o image2ps.o load.o papers.o pscol.o psdraw.o psobj.o pstext.o readxpm.o sys.o version.o xbmtops.o xpmtops.o -lXext -lX11 -Bstatic -L../image -lflimage -L../lib -lforms -Bdynamic -lm ild: (argument error) can't find library argument :: -lflimage *** Error code 8 make: Fatal error: Command failed for target `fd2ps' Current working directory /disk-b/hiller/xforms-1.0/fd2ps gmake: *** [all] Error 1 I think the main error is the relocation error (which is propably the reason why libflimage.so is not created). Thnaks in advance for your help. Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg Germany phone +49 6221 528238 fax +49 6221 528246 email hiller at mpia.de PS: For your information: Imakefile looks like this: /* Configuration -- see 00README for details */ /* Fairly important stuff */ #define OptimizationLevel -O4 #define DoWall NO #define BuildShared YES #define StaticLink YES #define BuildGL NO /* Less Important or System Specific */ #define HaveStrerror YES #define HaveSnprintf YES #define HaveFloatH YES #define DoOptimize YES #define BuildDemos NO #define DebugSymbols YES /* * You should only define this if you're running a 64 bit compile * environment on Solaris. */ #define Solaris64Bit NO /* Out in the Tall Weeds */ #define InstallNonstandard YES #define XFormsNonstandardInstallDir /systools/misc/xforms #define NonstandardXpm YES #define XpmIncLoc /systools/include #define XpmLibLoc /systools/lib #define NonstandardTiff YES #define TiffIncLoc /systools/include #define TiffLibLoc /systools/lib #define NonstandardJpeg YES #define JpegIncLoc /systools/include #define JpegLibLoc /systools/lib [the rest was not changed] From sian at sleitch.nildram.co.uk Sun Nov 2 13:09:17 2003 From: sian at sleitch.nildram.co.uk (Sian Leitch) Date: Sun, 2 Nov 2003 18:09:17 +0000 Subject: [XForms] Re: XForms: Future xforms development In-Reply-To: <20021210183511.61780.qmail@web41210.mail.yahoo.com> References: <200212101700.gBAH0SF04956@ncmir.ucsd.edu> <20021210183511.61780.qmail@web41210.mail.yahoo.com> Message-ID: <20031102180917.GD1248@sleitch.nildram.co.uk> On Tue, Dec 10, 2002 at 01:35:11PM -0500, David Scriven wrote: > # To subscribers of the xforms list from David Scriven : > > I suspect that the reason that Angus is not > getting any feedback is that there are very few > of us actively developing under XForms, so you > are not getting the 'critical mass' that drives > development. > > There are all sorts of reasons for this - for > example Red Hat dropped XForms from its > PowerTools because it was not open source (is > there some way to encourage them to add it to > their distro now that it is Open Source?) Also > 0.89 was quite buggy, and its > functionality/reliability varied from platform to > platform and that turned a lot of people off. > > Secondly, if I knew nothing about XForms and > wanted to get started I would probably end up on > the XForms home page, which is horribly out of > date, has broken links and links to 0.89, but > none to version 1. > > My point is that if we want XForms to survive we > have to attract users. We have to make it easy to > for new users to get the software and the > documentation so that they can be up and running > quickly. Well, here is one lurker who is actively developing using Xforms. I am currently designing the Home Finance Program (`hfp') and look forward to using `fdesign' once the filter for Algol 68 is completed (`fdtow68'). Meanwhile, I have written some test progs for various ideas. Regards -- Sian Leitch Software Engineer specialising in Algol 68 Algol 68 for Linux is available from and -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031102/a9c09f7f/attachment-0002.bin From drriddle at qwest.net Wed Nov 5 22:41:54 2003 From: drriddle at qwest.net (Reed Riddle) Date: Wed, 5 Nov 2003 21:41:54 -0600 Subject: [XForms] Problem compiling with Mac OS X Message-ID: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Howdy folks, I'm trying to compile the library under OS X, and I keep running into the following errors when I run the configure script: ** Cannot find xpm.h. Please check that the Xpm library is correctly installed on your system. ** Cannot find libjpeg. Please check that the jpeg library is correctly installed on your system. I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in /sw/lib). I know that the X libraries aren't being seen at all when I compile, as all kinds of errors come up related to X. I also know how to set Linux so that it will find where you have libraries (using ldconfig), but I can't find any information like that for OS X. And, I can't figure out what to change in the configuration files to force it to see the library directories. No, I'm not frustrated... :) Anything that can point me in the right direction to get this to work will be greatly appreciated. Thanks! Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From Todd.Denniston at ssa.crane.navy.mil Thu Nov 6 09:00:19 2003 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu, 06 Nov 2003 09:00:19 -0500 Subject: [XForms] Problem compiling with Mac OS X References: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Message-ID: <3FAA53F3.CBE9476A@ssa.crane.navy.mil> Reed Riddle wrote: > > To subscribers of the xforms list > > Howdy folks, > > I'm trying to compile the library under OS X, and I keep running into > the following errors when I run the configure script: > > ** Cannot find xpm.h. Please check that the Xpm library > is correctly installed on your system. > > ** Cannot find libjpeg. Please check that the jpeg library > is correctly installed on your system. > > I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in /sw/lib). > I know that the X libraries aren't being seen at all when I compile, > as all kinds of errors come up related to X. I also know how to set > Linux so that it will find where you have libraries (using ldconfig), > but I can't find any information like that for OS X. And, I can't > figure out what to change in the configuration files to force it to see > the library directories. > > No, I'm not frustrated... :) Anything that can point me in the right > direction to get this to work will be greatly appreciated. Thanks! > > Reed > Sometimes configure will actually use the 'with-extra...' options --with-extra-lib specify extra library directory --with-extra-inc specify extra include directory though my results with them have been sporadic in other library compiles (LessTif), BTW please report on whether they work for you with xforms, if they don't perhaps someone can fix them. if that does not work try exporting `LIBS=-L/sw/lib` & `INCLUDES=-I/usr/X11R6/lib/X11/` and redo the configure/make After compilation you may have to define `export LD_LIBRARY_PATH=/sw/lib` before running the app, until you can figure out what OS X/BSD's options are for setting default library directories. (Sorry, I have not messed with BSD yet) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From Jean-Marc.Lasgouttes at inria.fr Thu Nov 6 09:13:24 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 06 Nov 2003 15:13:24 +0100 Subject: [XForms] Problem compiling with Mac OS X In-Reply-To: <3FAA53F3.CBE9476A@ssa.crane.navy.mil> (Todd Denniston's message of "Thu, 06 Nov 2003 09:00:19 -0500") References: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> <3FAA53F3.CBE9476A@ssa.crane.navy.mil> Message-ID: >>>>> "Todd" == Todd Denniston writes: >> I know that the X libraries aren't being seen at all when >> I compile, as all kinds of errors come up related to X. Is xmkmf in you PATH? JMarc From dstrang at chartermi.net Mon Nov 10 02:40:51 2003 From: dstrang at chartermi.net (David Strang) Date: Mon, 10 Nov 2003 02:40:51 -0500 Subject: [XForms] Mesa/GL demos Message-ID: <000701c3a75d$f84822a0$6401a8c0@athlon24> Hi: I installed the 1.0 version of the Forms library and everything compiled fine with the replacement of the Imakefile (thanks). What do I need to do to get the Mesa/GL demos (gl, glwin) compiled? I'm running Mandrake 9.1 and it looks like I have the shared Mesa 5.0-3 libraries. The 01README mentions using the gl.c from the demos directory (../FORMS/gl.c ??) and recompiling the libform.* . Also, link libGL.a to libMesaGL.a . I couldn't find a libMesaGL.a . Seems I need a little housekeeping here to resolve the Mesa/GL references in gl.c . Help is appreciated. Regards, Dave Strang From nicolas.castagne at imag.fr Mon Nov 10 04:56:35 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Mon, 10 Nov 2003 10:56:35 +0100 Subject: [XForms] Problem compiling with Mac OS X In-Reply-To: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Message-ID: <2BADD5B7-1364-11D8-BEAF-000393C76CA6@imag.fr> Hi all, Here is the report of the uses I made of XForms on Mac-OS-X last week. I also encountered a few problems with compiling the library. After a few trial, I would encourage MacOS X developpers to use the software tool FINK which is available at http://fink.sourceforge.net/ Fink takes into account the specificities of Mac OS X, which is finally not so much a standard linux (sic), to maintain your environment for software development. Especially, Fink is able to 1) scan your Mac OS X system and show which libraries are installed ; 2) download, compile and instal open source libraries ; especially, it will download any library needed to compile a specific package, if it is not yet installed ; 3) keep up to date your packages, since the download locations of almost every library is known by the software. For example, Fink was able to 1) download 2) compile 3) install automatically the XForms library and ALL the necessary packages, including XPM and OpenGL and 4) recompile all my XForms-Based software in 4 hours... Much better than getting crazy with the syntax of Makefiles, is not it? ;-) All the best, Nicolas Le jeudi, 6 nov 2003, ? 04:41 Europe/Paris, Reed Riddle a ?crit : > To subscribers of the xforms list > > > Howdy folks, > > I'm trying to compile the library under OS X, and I keep running into > the following errors when I run the configure script: > > ** Cannot find xpm.h. Please check that the Xpm library > is correctly installed on your system. > > ** Cannot find libjpeg. Please check that the jpeg library > is correctly installed on your system. > > I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in > /sw/lib). I know that the X libraries aren't being seen at all when I > compile, as all kinds of errors come up related to X. I also know how > to set Linux so that it will find where you have libraries (using > ldconfig), but I can't find any information like that for OS X. And, > I can't figure out what to change in the configuration files to force > it to see the library directories. > > No, I'm not frustrated... :) Anything that can point me in the right > direction to get this to work will be greatly appreciated. Thanks! > > Reed > > ---------------------------------------------------------------------- > Dr. Reed L. Riddle > Associate Director of Whole Earth Telescope Operations > Iowa State University Department of Physics & Astronomy > Email: drriddle at qwest.net > Homepage: http://www3.iitap.iastate.edu/~riddle/ > > "This life has been a test. If it had been an actual life, you would > have received actual instructions on where to go and what to do." > -- Angela Chase, "My so-called life" > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > > ------------------------------------------------------------------------ -------------------------- Dr Nicolas CASTAGNE Researcher, IR de l'ACROE / ICA, Association pour la Cr?ation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Cr?ation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------ -------------------------- From Jean-Marc.Lasgouttes at inria.fr Tue Nov 18 10:30:28 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 Nov 2003 16:30:28 +0100 Subject: [XForms] [PATCH] update the autotools files. Message-ID: A non-text attachment was scrubbed... Name: config.diff.gz Type: application/octet-stream Size: 39175 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031118/13162586/attachment-0001.obj -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: INSTALL Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031118/13162586/attachment-0001.pl From angus.leeming at btopenworld.com Tue Nov 18 17:43:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 Nov 2003 22:43:24 +0000 Subject: [XForms] [PATCH] update the autotools files. In-Reply-To: References: Message-ID: <200311182243.24688.angus.leeming@btopenworld.com> On Tuesday 18 November 2003 3:30 pm, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > Here is a small patch updating the config/ files to what I found on > rh9 Thanks JMarc. They're in... Angus From msz at astrouw.edu.pl Wed Nov 19 05:56:06 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 19 Nov 2003 11:56:06 +0100 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: <200305301057.43750.angus.leeming@btopenworld.com> Message-ID: <20031119105606.GA1903@astrouw.edu.pl> Hi XFormers, I'd like to know what the current status of "file selector double-click" bug is? There were a couple of messages regarding this in May, starting with a patch proposed by Mike Heffner, but the discussion that followed raised some doubts. It ended with following message from Mike: > However, we still have the same problem that the callback is never getting > a ButtonPress event. ;-( > > This weekend I'll try rewriting the file selector's callback using the > fl_set_browser_dblclick_callback(). It seems that might be a much easier > way of approaching this. Mike, did you try the rewrite? If no, is Mike's patch included in any (CVS maybe) version of code? I have some heavily-used XForms apps dating back to ver. 0.88 and I'd like very much to rebuild them with 1.0 (also because of problems with static libraries under RedHat 9) but all users here are quite used to double-clicking in file selector. The problems started already in 0.89 and, sadly, have propagated into 1.0. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:11:46 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:11:46 +0100 Subject: [XForms] Mesa/GL demos In-Reply-To: <000701c3a75d$f84822a0$6401a8c0@athlon24> (David Strang's message of "Mon, 10 Nov 2003 02:40:51 -0500") References: <000701c3a75d$f84822a0$6401a8c0@athlon24> Message-ID: >>>>> "David" == David Strang writes: David> To subscribers of the xforms list Hi: David> I installed the 1.0 version of the Forms library and everything David> compiled fine with the replacement of the Imakefile (thanks). David> What do I need to do to get the Mesa/GL demos (gl, glwin) David> compiled? David> I'm running Mandrake 9.1 and it looks like I have the shared David> Mesa 5.0-3 libraries. David> The 01README mentions using the gl.c from the demos directory David> (../FORMS/gl.c ??) and recompiling the libform.* . Also, link David> libGL.a to libMesaGL.a . David> I couldn't find a libMesaGL.a . The .a library should be in the Mesa-devel package (or whatever it's called). You can probably link to libMesaGL.so with a -lMesaGL directive. David> Seems I need a little housekeeping here to resolve the Mesa/GL David> references in gl.c . What would be insteresting is to know whether it works better in xforms cvs where we have switched to autoconf. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:45:03 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:45:03 +0100 Subject: [XForms] Re: XForms: Towards xforms 1.1 In-Reply-To: <200305212241.04744.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 21 May 2003 22:41:04 +0000") References: <200305212241.04744.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: [OK, this was 6 months ago, but I am cleaning my mailbox...] Angus> I think that NT lib/OS2 os2move.cmd gl/canvas.h are all Angus> redundant (the latter is almost identical to glcanvas.h and Angus> appears to be a historical anachronism. It has certainly never Angus> been installed). Angus> Would anybody object if I removed them? Please remove them. Also, I think lib/Readme should be removed (check first...). Do gl demos still work? (I do not have gl stuff installed here to check...). Also, could you update the NEWS file? We will probably need at least a prerelease of 1.1. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:49:23 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:49:23 +0100 Subject: [XForms] [PATCH] Various stuff Message-ID: A non-text attachment was scrubbed... Name: stuff.diff Type: text/x-patch Size: 6171 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/ac02f299/attachment-0001.bin From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 09:38:51 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 15:38:51 +0100 Subject: [XForms] [PATCH] Various stuff In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 19 Nov 2003 12:49:23 +0100") References: Message-ID: >>>>> "Jean-Marc" == Jean-Marc Lasgouttes writes: Jean-Marc> To subscribers of the xforms list This patch updates README Jean-Marc> somewhat, makes ure that the X11 include path is used to Jean-Marc> search for xpm.h (should I do the same for jpeg and/or Jean-Marc> gl?), and fixes small things. Jean-Marc> Please apply. Well, I decided to have a look whether I could use my write access on cvs. Guess what? It just worked ! JMarc From angus.leeming at btopenworld.com Wed Nov 19 16:58:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 21:58:02 +0000 Subject: [XForms] [PATCH] Various stuff In-Reply-To: References: Message-ID: <200311192158.02931.angus.leeming@btopenworld.com> On Wednesday 19 November 2003 2:38 pm, Jean-Marc Lasgouttes wrote: > Jean-Marc> This patch updates README somewhat, > Jean-Marc> makes ure that the X11 include path is used to > Jean-Marc> search for xpm.h (should I do the same for jpeg > Jean-Marc> and/or gl?), and fixes small things. > > Jean-Marc> Please apply. > > Well, I decided to have a look whether I could use my write access on > cvs. Guess what? It just worked ! So starts the slippery slope towards responsibility ;-) Many thanks for doing this. Angus From angus.leeming at btopenworld.com Wed Nov 19 17:49:16 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 22:49:16 +0000 Subject: [XForms] Re: XForms: Towards xforms 1.1 In-Reply-To: References: <200305212241.04744.angus.leeming@btopenworld.com> Message-ID: <200311192249.16531.angus.leeming@btopenworld.com> On Wednesday 19 November 2003 11:45 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > [OK, this was 6 months ago, but I am cleaning my mailbox...] > > Angus> I think that NT lib/OS2 os2move.cmd gl/canvas.h are all > Angus> redundant (the latter is almost identical to glcanvas.h and > Angus> appears to be a historical anachronism. It has certainly never > Angus> been installed). > > Angus> Would anybody object if I removed them? > > Please remove them. Done. Is README.OS2 now redundant too? > Also, I think lib/Readme should be removed (check first...). Checked and then removed. > Do gl demos still work? (I do not have gl stuff installed > here to check...). > > Also, could you update the NEWS file? Hmmm. Yes. This will take some effort but I'll put it on my todo list. > We will probably need at least a prerelease of 1.1. Definitely. Angus From angus.leeming at btopenworld.com Wed Nov 19 18:06:17 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 23:06:17 +0000 Subject: [XForms] Towards a warning-free compilation. Message-ID: <200311192306.17228.angus.leeming@btopenworld.com> I have been trying to reduce the number of warnings when compiling xforms with CFLAGS='-O2 -W -Wall -Wno-unused-parameter -pedantic' That's about as strict as C will allow. There are currently two main groups of warning messages: 'uninitialized variable' (almost all in the declaration of arrays) and 'comparison between signed and unsigned'. Attached is a tentative patch that removes all of the 'uninitialized variable' warnings. I say tentative because xforms tends to use macros such as #define NV(a) (#a,a) to simplify such initializations. Eg: #define NV(a) #a,a static FL_IMAP fl_imap[FL_MAX_COLS] = { {NV(FL_BLACK), 0, 0, 0, 0, 0}, {NV(FL_WHITE), 255, 255, 255, 0, 0}, I have squashed the warnings in the case above by adding the final ', 0, 0' to the decalrations, but I could arguably achieve the same end by extending the definition of the NV macro to: #define NV(a,r,g,b) ({#a,a,r,g,b,0,0}) static FL_IMAP fl_imap[FL_MAX_COLS] = { NV(FL_BLACK, 0, 0, 0), NV(FL_WHITE, 255, 255, 255), Given that NV exists already, would it not be more elegant to do things the second way? I also attach the log of the remaining_warnings and a little sed script that I used to strip most everything but the warnings out from the make log file. $ make > make.log 2>&1 $ sed -f striplog.sed make.log > remaining_warnings.txt You'll see that there are also a couple of warnings about inconsistent declarations in there too... Regards, Angus -------------- next part -------------- /^depfile/d /^depmode/d /^gcc/d /^source/d /^\/bin\/sh/d /^make\[[123]\]/d /^Making all/d /^cp -p/d /^creating/d /^(cd/d /^rm -f/d /^mv -f/d /^ar cru/d /^mkdir/d /^echo timestamp/d /^config.status/d /^cd/d /^make/d -------------- next part -------------- A non-text attachment was scrubbed... Name: remaining_warnings.txt.gz Type: application/x-gzip Size: 1152 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/769cd83b/attachment-0002.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: initialization.diff.gz Type: application/x-gzip Size: 5314 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/769cd83b/attachment-0003.gz From tristan at mpegtv.com Wed Nov 19 20:53:36 2003 From: tristan at mpegtv.com (Tristan Savatier) Date: Wed, 19 Nov 2003 17:53:36 -0800 Subject: [XForms] Towards a warning-free compilation. References: <200311192306.17228.angus.leeming@btopenworld.com> Message-ID: <029501c3af09$1ce8c850$0100a8c0@milk> > I have squashed the warnings in the case above by adding the final ', 0, 0' Normally, any partially initialized global or static structure will be padded with zeros. I think it also applies to arrays (?). so the compiler warnings about 'uninitialized variable' would seem bogus to me... From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 04:20:52 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 10:20:52 +0100 Subject: [XForms] [PATCH] Various stuff In-Reply-To: <200311192158.02931.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 19 Nov 2003 21:58:02 +0000") References: <200311192158.02931.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> So starts the slippery slope towards responsibility ;-) Many Angus> thanks for doing this. Angus Well, we _have_ to get this thing going at least until we can deliver a working autotools-based version. JMarc From angus.leeming at btopenworld.com Thu Nov 20 05:04:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 10:04:02 +0000 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: <029501c3af09$1ce8c850$0100a8c0@milk> References: <200311192306.17228.angus.leeming@btopenworld.com> <029501c3af09$1ce8c850$0100a8c0@milk> Message-ID: <200311201002.50320.angus.leeming@btopenworld.com> On Thursday 20 November 2003 1:53 am, Tristan Savatier wrote: > > I have squashed the warnings in the case above by adding the final ', 0, > Normally, any partially initialized global or static structure will be > padded with zeros. I think it also applies to arrays (?). > so the compiler warnings about 'uninitialized variable' would seem bogus to > me... Maybe, but the fact remains that bogus warnings make it harder to see real warnings. If we can squash warnings (with no run-time effect) then we should. Angus From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 05:30:55 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 11:30:55 +0100 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: <200311201002.50320.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 20 Nov 2003 10:04:02 +0000") References: <200311192306.17228.angus.leeming@btopenworld.com> <029501c3af09$1ce8c850$0100a8c0@milk> <200311201002.50320.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> so the compiler warnings about 'uninitialized variable' would seem >> bogus to me... Angus> Maybe, but the fact remains that bogus warnings make it harder Angus> to see real warnings. If we can squash warnings (with no Angus> run-time effect) then we should. Yes. And I think that the patch that you posted is good enough in this regard. JMarc From angus.leeming at btopenworld.com Thu Nov 20 05:49:30 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 10:49:30 +0000 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: References: <200311192306.17228.angus.leeming@btopenworld.com> <200311201002.50320.angus.leeming@btopenworld.com> Message-ID: <200311201049.30448.angus.leeming@btopenworld.com> On Thursday 20 November 2003 10:30 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > >> > >> so the compiler warnings about 'uninitialized variable' would seem > >> bogus to me... > > Angus> Maybe, but the fact remains that bogus warnings make it harder > Angus> to see real warnings. If we can squash warnings (with no > Angus> run-time effect) then we should. > > Yes. And I think that the patch that you posted is good enough in this > regard. Me too. It's in. Angus From angus.leeming at btopenworld.com Thu Nov 20 07:49:29 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 12:49:29 +0000 Subject: [XForms] [PATCH]: squashing all remaining warnings Message-ID: <200311201249.29064.angus.leeming@btopenworld.com> Attached is a patch to squash all the remaining warnings when compiling with CFLAGS='-W -Wall -Wno-unused-parameter'. All these warnings are 'comparison of signed and unsigned'. I have been pretty careful here and when unsure have erred on the side of caution, casting the unsigned var to signed. Much of the time though I have felt that going the other way was fine (ie, casting the signed var to unsigned). I would value it if someone would take the time to verify that I haven't fubar-ed here. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: signed.diff.gz Type: application/x-gzip Size: 5283 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031120/075bb252/attachment-0001.gz From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 08:49:48 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 14:49:48 +0100 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: <200311201249.29064.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 20 Nov 2003 12:49:29 +0000") References: <200311201249.29064.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Attached is a patch to squash Angus> all the remaining warnings when compiling with CFLAGS='-W -Wall Angus> -Wno-unused-parameter'. All these warnings are 'comparison of Angus> signed and unsigned'. Angus> I have been pretty careful here and when unsure have erred on Angus> the side of caution, casting the unsigned var to signed. Much Angus> of the time though I have felt that going the other way was Angus> fine (ie, casting the signed var to unsigned). And did you find any real problem in the process? Angus> I would value it if someone would take the time to verify that Angus> I haven't fubar-ed here. I took a quick look at the patch and it looks like checking each and every of these is a long process. I won't have time to do it. So if you are confident, just apply the patch. Otherwise, we'll have to live with the warnings :) JMarc From angus.leeming at btopenworld.com Fri Nov 21 04:15:55 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 21 Nov 2003 09:15:55 +0000 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: References: <200311201249.29064.angus.leeming@btopenworld.com> Message-ID: <200311210915.55314.angus.leeming@btopenworld.com> On Thursday 20 November 2003 1:49 pm, Jean-Marc Lasgouttes wrote: > Angus> I would value it if someone would take the time to verify that > Angus> I haven't fubar-ed here. > > I took a quick look at the patch and it looks like checking each and > every of these is a long process. I won't have time to do it. > > So if you are confident, just apply the patch. Otherwise, we'll have > to live with the warnings :) Maybe I'll do it a bit at a time. Adding bugs for the sake of squashing warnings seems like a poor trade off to me ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 04:23:13 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 10:23:13 +0100 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: <200311210915.55314.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 21 Nov 2003 09:15:55 +0000") References: <200311201249.29064.angus.leeming@btopenworld.com> <200311210915.55314.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Maybe I'll do it a bit at a time. Adding bugs for the sake of Angus> squashing warnings seems like a poor trade off to me ;-) Definitely :) JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 05:53:37 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 11:53:37 +0100 Subject: [XForms] [PATCH] squash more warnings Message-ID: A non-text attachment was scrubbed... Name: warnings.diff Type: text/x-patch Size: 4787 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/6949fbf8/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mk.log Type: application/octet-stream Size: 4013 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/6949fbf8/attachment-0001.obj From angus.leeming at btopenworld.com Fri Nov 21 08:28:33 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 21 Nov 2003 13:28:33 +0000 Subject: [XForms] Enabling the building of the demo GL programs Message-ID: <200311211328.33037.angus.leeming@btopenworld.com> Ok, I squashed those warnings about the comparison of signed and unsigned vars that I deemed to be safe to squash. The remaining few can wait till I have more energy ;-) Attached is a patch to enable the building of the demo GL programs. Comments? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-diff Size: 2305 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/c6ab75bc/attachment-0001.bin From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 09:08:17 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 15:08:17 +0100 Subject: [XForms] Enabling the building of the demo GL programs In-Reply-To: <200311211328.33037.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 21 Nov 2003 13:28:33 +0000") References: <200311211328.33037.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Ok, I squashed those warnings Angus> about the comparison of signed and unsigned vars that I deemed Angus> to be safe to squash. The remaining few can wait till I have Angus> more energy ;-) Good move. Angus> Attached is a patch to enable the building of the demo GL Angus> programs. Angus> Comments? Looks reasonable. JMarc From msz at astrouw.edu.pl Sun Nov 23 10:35:48 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Sun, 23 Nov 2003 16:35:48 +0100 Subject: [XForms] problem with autoconf in RH9 Message-ID: <20031123153548.GA18821@astrouw.edu.pl> Hi, I've just downloaded the source from CVS depository, using: cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . Contrary to what I found in the INSTALL file, the downloaded tree lacks 'configure' script so I ran "autoconf". Unfortunately, it failed saying: >autoconf configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:14: error: possibly undefined macro: AM_MAINTAINER_MODE configure.ac:17: error: possibly undefined macro: AM_INIT_AUTOMAKE configure.ac:29: error: possibly undefined macro: AM_CONDITIONAL configure.ac:52: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:53: error: possibly undefined macro: AM_PROG_LIBTOOL The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, autoconf-2.57-3, libtool-1.4.3-5. Any ideas, hints? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From drriddle at qwest.net Sun Nov 23 16:22:07 2003 From: drriddle at qwest.net (Reed Riddle) Date: Sun, 23 Nov 2003 15:22:07 -0600 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> I just installed this yesterday on a RedHat 9, with the CVS version, and everything worked just fine. It's a standard RedHat install, nothing modified. Have you changed anything in the system settings, or added/updated any software? Reed On Sunday, November 23, 2003, at 09:35 AM, Michal Szymanski wrote: > To subscribers of the xforms list > > > Hi, > > I've just downloaded the source from CVS depository, using: > > cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login > cvs -z3 -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . > > Contrary to what I found in the INSTALL file, the downloaded tree lacks > 'configure' script so I ran "autoconf". Unfortunately, it failed > saying: > >> autoconf > configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.ac:14: error: possibly undefined macro: AM_MAINTAINER_MODE > configure.ac:17: error: possibly undefined macro: AM_INIT_AUTOMAKE > configure.ac:29: error: possibly undefined macro: AM_CONDITIONAL > configure.ac:52: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL > configure.ac:53: error: possibly undefined macro: AM_PROG_LIBTOOL > > The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, > autoconf-2.57-3, libtool-1.4.3-5. > > Any ideas, hints? > > regards, Michal. > > -- > Michal Szymanski (msz at astrouw.edu.pl) > Warsaw University Observatory, Warszawa, POLAND > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > > ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From msz at astrouw.edu.pl Mon Nov 24 02:49:44 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 08:49:44 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> References: <20031123153548.GA18821@astrouw.edu.pl> <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> Message-ID: <20031124074944.GA829@astrouw.edu.pl> On Sun, Nov 23, 2003 at 03:22:07PM -0600, Reed Riddle wrote: > I just installed this yesterday on a RedHat 9, with the CVS version, > and everything worked just fine. It's a standard RedHat install, > nothing modified. Have you changed anything in the system settings, or > added/updated any software? > >The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, > >autoconf-2.57-3, libtool-1.4.3-5. Well, the system *IS* updated, following RH errata. Could you please check your versions of the RPMs given above? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Mon Nov 24 04:30:59 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 24 Nov 2003 10:30:59 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031123153548.GA18821@astrouw.edu.pl> (Michal Szymanski's message of "Sun, 23 Nov 2003 16:35:48 +0100") References: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> I've just downloaded the source from CVS depository, using: Michal> cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms Michal> login cvs -z3 Michal> -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . Michal> Contrary to what I found in the INSTALL file, the downloaded Michal> tree lacks 'configure' script so I ran "autoconf". Try to run ./autogen.sh instead. JMarc From msz at astrouw.edu.pl Mon Nov 24 10:29:57 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 16:29:57 +0100 Subject: [XForms] JPEG/EXIF support? Message-ID: <20031124152956.GA2504@astrouw.edu.pl> Hi, It seems that JPEG support in XForms 1.0 is only for "standard", JFIF format. I have plenty of JPEG/EXIF "extended" format images from digital camera which I'd like very much to display using XForms. Now, unfortunately, I'm getting messages like: In OpenImage [image.c 224] Guad22.jpg: Unknown image format Is there a simpler way to get them loaded properly than to write my own routines and use "flimage_add_format()"? I mean like using newer JPEG library? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Mon Nov 24 11:41:04 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 24 Nov 2003 17:41:04 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031124152956.GA2504@astrouw.edu.pl> (Michal Szymanski's message of "Mon, 24 Nov 2003 16:29:57 +0100") References: <20031124152956.GA2504@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> It seems that JPEG support in XForms 1.0 is only for Michal> "standard", JFIF format. I have plenty of JPEG/EXIF "extended" Michal> format images from digital camera which I'd like very much to Michal> display using XForms. Now, unfortunately, I'm getting messages Michal> like: Michal> In OpenImage [image.c 224] Guad22.jpg: Unknown image format Where is this JPEG/EXIF thing described? JMarc From msz at astrouw.edu.pl Mon Nov 24 12:28:21 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 18:28:21 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: References: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: <20031124172821.GA9534@astrouw.edu.pl> On Mon, Nov 24, 2003 at 10:30:59AM +0100, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > > >>>>> "Michal" == Michal Szymanski writes: > > Michal> To subscribers of the xforms list Hi, > > Michal> I've just downloaded the source from CVS depository, using: > > Michal> cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms > Michal> login cvs -z3 > Michal> -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . > > Michal> Contrary to what I found in the INSTALL file, the downloaded > Michal> tree lacks 'configure' script so I ran "autoconf". > > Try to run ./autogen.sh instead. Thanks, it worked. I guess it might be worth putting into INSTALL file which now is somewhat misleading. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From msz at astrouw.edu.pl Mon Nov 24 13:07:06 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 19:07:06 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: References: <20031124152956.GA2504@astrouw.edu.pl> Message-ID: <20031124180705.GB9534@astrouw.edu.pl> On Mon, Nov 24, 2003 at 05:41:04PM +0100, Jean-Marc Lasgouttes wrote: > >>>>> "Michal" == Michal Szymanski writes: > > Michal> To subscribers of the xforms list Hi, > > Michal> It seems that JPEG support in XForms 1.0 is only for > Michal> "standard", JFIF format. I have plenty of JPEG/EXIF "extended" > Michal> format images from digital camera which I'd like very much to > Michal> display using XForms. Now, unfortunately, I'm getting messages > Michal> like: > > Michal> In OpenImage [image.c 224] Guad22.jpg: Unknown image format > > Where is this JPEG/EXIF thing described? A quick search on the net resulted in following: EXIF stands for Exchangeable Image File Format, and is a standard for storing interchange information in image files, especially those using JPEG compression. Most digital cameras now use the EXIF format. The format is part of the DCF standard created by JEIDA to encourage interoperability between imaging devices. >From what I could quickly find, EXIF data in a JPEG file is stored in an application segment APP1. It seems that JPEG standard supports such segments - I'm not sure why the JPEG code in XForms can't deal with such images (if they really conform to JPEG standard, as it seems). Links: http://www.exif.org/ and links therein, of which one is particularly good: http://park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Mon Nov 24 14:51:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 24 Nov 2003 19:51:26 +0000 Subject: [XForms] Getting rid of auto-generated files... Message-ID: <200311241951.26091.angus.leeming@btopenworld.com> It would be nice if we could get rid of at least some of the .[ch] files generated from .fd datasets. We store .fd files and their associated .[ch] files in the following directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, the .[ch] files in the first two directories would have to remain. (We cannot generate the .[ch] files until fdesign has bee created.) However, it strikes me that the .[ch] files in the remaining directories could all be generated on the fly, just as we do in LyX. Personally, I think that this would be much more elegant. Thoughts? Angus From xforms2 at vjet.demon.co.uk Mon Nov 24 18:43:41 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Mon, 24 Nov 2003 23:43:41 GMT Subject: [XForms] JPEG/EXIF support? Message-ID: <200311242343.hAONhf36001050@vjet.demon.co.uk> Hi, > It seems that JPEG support in XForms 1.0 is only for "standard", JFIF > format. I have plenty of JPEG/EXIF "extended" format images from digital > camera which I'd like very much to display using XForms. > Now, unfortunately, I'm getting messages like: > > In OpenImage [image.c 224] Guad22.jpg: Unknown image format A long time ago I did a patch to improve some stuff in the image handling.. It got lost in the move to 1.0 But I can read images off my camera so it may solve your problem too.. Patch is at http://www.vjet.demon.co.uk/xforms/image.patch It probably needs massaging to work on the latest CVS. It fixes a bug in flimage_dup() , one in image rotate, and makes jpeg + gif reading better. These patches are applied to my 1.0 rpms too (http://www.vjet.demon.co.uk/xforms) HTHs Cheers Clive From mheffner at vt.edu Tue Nov 25 09:27:24 2003 From: mheffner at vt.edu (Mike Heffner) Date: Tue, 25 Nov 2003 09:27:24 -0500 (EST) Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <20031119105606.GA1903@astrouw.edu.pl> Message-ID: On 19-Nov-2003 Michal Szymanski wrote: > To subscribers of the xforms list > >> >> This weekend I'll try rewriting the file selector's callback using the >> fl_set_browser_dblclick_callback(). It seems that might be a much >> easier >> way of approaching this. > > Mike, did you try the rewrite? Nope, unfortunately life got in the way. :) I should have some free time this week to look at it again. Cheers, Mike -- Mike Heffner From angus.leeming at btopenworld.com Tue Nov 25 16:09:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 25 Nov 2003 21:09:26 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311242343.hAONhf36001050@vjet.demon.co.uk> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> Message-ID: <200311252109.26767.angus.leeming@btopenworld.com> On Monday 24 November 2003 11:43 pm, Clive A Stubbings wrote: > A long time ago I did a patch to improve some stuff in the image > handling.. It got lost in the move to 1.0 > > But I can read images off my camera so it may solve your problem too.. > Patch is at http://www.vjet.demon.co.uk/xforms/image.patch Got it. > It probably needs massaging to work on the latest CVS. It fixes a bug in > flimage_dup() , I'm not going to apply this without some discussion. Feel free to explain the rationale. > one in image rotate. I don't see the need for this. See the comment immediately preceeding your patched code. In cvs at least. /* * Now coerce it into +/- 180. */ > and makes jpeg + gif reading better. I've applied both these parts to my local tree, albeit with some re-factoring to get rid of the goto and some signed-unsigned comparson warnings. Could you check to see that all is still as you intended (attached). If you could cast your eye over the ChangeLog entry and maybe rename 'flush_buffer' to something that makes sense to you, that'd be great too... Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: clive.diff Type: text/x-diff Size: 3888 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031125/dead5e72/attachment-0001.bin From angus.leeming at btopenworld.com Tue Nov 25 17:56:45 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 25 Nov 2003 22:56:45 +0000 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311241951.26091.angus.leeming@btopenworld.com> References: <200311241951.26091.angus.leeming@btopenworld.com> Message-ID: <200311252256.45141.angus.leeming@btopenworld.com> On Monday 24 November 2003 7:51 pm, Angus Leeming wrote: > To subscribers of the xforms list > > > It would be nice if we could get rid of at least some of the .[ch] files > generated from .fd datasets. > > We store .fd files and their associated .[ch] files in the following > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, > the .[ch] files in the first two directories would have to remain. (We > cannot generate the .[ch] files until fdesign has bee created.) However, it > strikes me that the .[ch] files in the remaining directories could all be > generated on the fly, just as we do in LyX. > > Personally, I think that this would be much more elegant. Thoughts? Ok, I'm stuck ;-) Jean-Marc, I wonder if you might help... Attached are the changes I've made to demos/Makefile.am. This is proof of concept code and, indeed, works fine. However, I have no idea how to turn it into robust code :-( The problem lies with the block below which generates .[ch] files from a .fd file. Note that I am running this conversion from $build_dir/demos whilst the .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do not want to generate a static library in the fd directory because I want to be able to build individual demo files if I so choose. Here's the troublesome (but working) block: %.c: %.fd ../fdesign/fdesign (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign -convert `basename $<`; \ mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.) Line 1. All is Ok. The generated .c file depends on the .fd file and on the existence of the fdesign binary. %.c: %.fd ../fdesign/fdesign Lines 2,3. The problems. It appears that fdesign must be run from the directory containing the .fd file. That means I lose track of the fdesign binary and then must move the generated .[ch] files into the $builddir tree (if $srcdir != $builddir). Any ideas? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos_makefile.am Type: text/x-diff Size: 1081 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031125/bd54bf1f/attachment-0001.bin From msz at astrouw.edu.pl Wed Nov 26 03:26:09 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 26 Nov 2003 09:26:09 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311252109.26767.angus.leeming@btopenworld.com> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> Message-ID: <20031126082609.GA9882@astrouw.edu.pl> On Tue, Nov 25, 2003 at 09:09:26PM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > On Monday 24 November 2003 11:43 pm, Clive A Stubbings wrote: > > A long time ago I did a patch to improve some stuff in the image > > handling.. It got lost in the move to 1.0 > > > > But I can read images off my camera so it may solve your problem too.. > > Patch is at http://www.vjet.demon.co.uk/xforms/image.patch > > Got it. > > > It probably needs massaging to work on the latest CVS. It fixes a bug in > > flimage_dup() , > > I'm not going to apply this without some discussion. Feel free to explain the > rationale. Hi, I did not go into details but downloaded Clive's patched versions of the 1.0 libs and indeed, my application started to read JPEG/EXIF images from my digital camera without any modification, just relinking. So I'd strongely vote for including the patch(es) into XForms. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Wed Nov 26 05:43:16 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 10:43:16 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031126082609.GA9882@astrouw.edu.pl> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> <20031126082609.GA9882@astrouw.edu.pl> Message-ID: <200311261043.16110.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 8:26 am, Michal Szymanski wrote: > Hi, > > I did not go into details but downloaded Clive's patched versions of the > 1.0 libs and indeed, my application started to read JPEG/EXIF images > from my digital camera without any modification, just relinking. So I'd > strongely vote for including the patch(es) into XForms. Could you revert Clive's patch and try the one I appended in my original reply to his posting? This patch contains the jpeg and gif enhancements and I am more than happy to merge it into the xforms sources. Angus From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 06:54:12 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 12:54:12 +0100 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311252256.45141.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 25 Nov 2003 22:56:45 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. So we could maybe take a look at fixing fdesign, since we have control on it :) Another solution would be to have a Makefile.am in the fd/ directories, maybe. Sorry, I do not have much time to think about it right now. I think this is something that we could leave for after 1.1. I'd like to concentrate on this first. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 08:37:15 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 14:37:15 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 26 Nov 2003 12:54:12 +0100") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-patch Size: 1726 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/d3e34718/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: fddiff.diff Type: text/x-patch Size: 2840 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/d3e34718/attachment-0003.bin From angus.leeming at btopenworld.com Wed Nov 26 08:49:43 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 13:49:43 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> Message-ID: <200311261349.43597.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 1:37 pm, Jean-Marc Lasgouttes wrote: > Angus> Lines 2,3. The problems. It appears that fdesign must be run > Angus> from the directory containing the .fd file. > > Jean-Marc> So we could maybe take a look at fixing fdesign, since we > Jean-Marc> have control on it :) > > The following patch fixes fdesign -convert for me. My problem was that > I have a "." in my homedir name (/afs/inria.fr/...). Does it help you? If it works for you, then I expect that it will work for me. I'll try it out this evening. > Could you re-read the patch to make sure I did not make a mistake? I > think using filename instead of fname is the right thing to do here. > > With this patch applied, I get the following diff on a sample fd file. > So the difference is: > > 1/ the LGPL notice is gone. Is this a big problem? No. These are generated files. If we really, really want an LGPL notice, the place to put it is in the .fd file. In turn that means enabling fdesign to handle comments in its .fd files. Something for the future, maybe, but not something to worry about now. > 2/ we have > -#include "include/forms.h" > +#include "forms.h" > I think this will be solved by using -I$(top_srcdir}/lib/include in > INCLUDES. Sure. > Note also that fdesign now adds > +/** Header file generated with fdesign on Wed Nov 26 14:25:19 2003.**/ > but only to the header (not the .c file). We should probably remove > this altogether, since it creates useless diffs. Agreed. > What do you think? I think that I like it when you claim to be 'too busy to think' ;-) Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 08:55:57 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 14:55:57 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311261349.43597.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 13:49:43 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 1:37 pm, Jean-Marc Lasgouttes wrote: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. >> Jean-Marc> So we could maybe take a look at fixing fdesign, since we Jean-Marc> have control on it :) >> The following patch fixes fdesign -convert for me. My problem was >> that I have a "." in my homedir name (/afs/inria.fr/...). Does it >> help you? Angus> If it works for you, then I expect that it will work for me. Angus> I'll try it out this evening. I'm not sure because my problem was really a "." in path. I did not see one in your path names. >> What do you think? Angus> I think that I like it when you claim to be 'too busy to think' Angus> ;-) Regards, Angus I was pointing at your convoluted makefile rules. Note that I did not propose to fix them :) The fdesign problem, OTOH is definitely a bug that should be fixed before 1.1. JMarc From angus.leeming at btopenworld.com Wed Nov 26 09:08:29 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:08:29 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> Message-ID: <200311261408.29034.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 1:55 pm, Jean-Marc Lasgouttes wrote: > The fdesign problem, OTOH is definitely a bug that should be fixed > before 1.1. The little wrapper script, attached, gives us the functionality that I think that fdesign should have. Usage: $ sh fdesign2c The only problem with the script is in the lst line: # If ${SRCDIR} != ${DESTDIR} then # move the generated .[ch] files to ${DESTDIR}. mv -f `basename ${FDFILE} .fd`.[ch] ${DESTDIR} I have no idea how to test that ${SRCDIR} != ${DESTDIR}. Consequently, I get errors: mv: `butttypes_gui.c' and `/home/angus/xforms/xforms/build/demos/../../demos/fd/butttypes_gui.c' are the same file mv: `butttypes_gui.h' and `/home/angus/xforms/xforms/build/demos/../../demos/fd/butttypes_gui.h' are the same file Any ideas? Angus ps, once this is working, then modifying Makefile.am is a snip. Equally, it should provide the template to modify fdesign itself. I'd imagine using fdesign as $ fdesign -convert A -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign2c Type: application/x-shellscript Size: 1216 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/ea9449d5/attachment-0001.bin From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 09:16:03 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 15:16:03 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311261408.29034.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 14:08:29 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> <200311261408.29034.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 1:55 pm, Jean-Marc Lasgouttes wrote: >> The fdesign problem, OTOH is definitely a bug that should be fixed >> before 1.1. Angus> The little wrapper script, attached, gives us the functionality Angus> that I think that fdesign should have. Angus> Usage: $ sh fdesign2c Angus> With my fix, fdesign is able to output .[ch] files in the directory where the .fd file was. Isn't it really good enough for now? Angus> ps, once this is working, then modifying Makefile.am is a snip. Angus> Equally, it should provide the template to modify fdesign Angus> itself. I'd imagine using fdesign as $ fdesign -convert Angus> Why would the Makefile.am not work with the fixed fdesign? Because you do not want the .[ch] files to appear in the source directory, but the build directory? JMarc From angus.leeming at btopenworld.com Wed Nov 26 09:21:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:21:26 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261408.29034.angus.leeming@btopenworld.com> Message-ID: <200311261421.26649.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 2:16 pm, Jean-Marc Lasgouttes wrote: > Angus> ps, once this is working, then modifying Makefile.am is a snip. > Angus> Equally, it should provide the template to modify fdesign > Angus> itself. I'd imagine using fdesign as $ fdesign -convert > Angus> > > Why would the Makefile.am not work with the fixed fdesign? Because you > do not want the .[ch] files to appear in the source directory, but the > build directory? Correct. However, I will indeed try and make things work with your patched fdesign too. Angus From Todd.Denniston at ssa.crane.navy.mil Wed Nov 26 09:21:47 2003 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Wed, 26 Nov 2003 09:21:47 -0500 Subject: [XForms] Getting rid of auto-generated files... References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: <3FC4B6FB.B727860E@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > ------------------------------------------------------------------------ > On Monday 24 November 2003 7:51 pm, Angus Leeming wrote: > > To subscribers of the xforms list > > > > > > It would be nice if we could get rid of at least some of the .[ch] files > > generated from .fd datasets. > > > > We store .fd files and their associated .[ch] files in the following > > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, > > the .[ch] files in the first two directories would have to remain. (We > > cannot generate the .[ch] files until fdesign has bee created.) However, it > > strikes me that the .[ch] files in the remaining directories could all be > > generated on the fly, just as we do in LyX. > > > > Personally, I think that this would be much more elegant. Thoughts? > > Ok, I'm stuck ;-) > > Jean-Marc, I wonder if you might help... Attached are the changes I've made to > demos/Makefile.am. This is proof of concept code and, indeed, works fine. > However, I have no idea how to turn it into robust code :-( > > The problem lies with the block below which generates .[ch] files from a .fd > file. Note that I am running this conversion from $build_dir/demos whilst the > .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do > not want to generate a static library in the fd directory because I want to > be able to build individual demo files if I so choose. > > Here's the troublesome (but working) block: > > %.c: %.fd ../fdesign/fdesign > (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign > -convert `basename $<`; \ > mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.) > > Line 1. All is Ok. The generated .c file depends on the .fd file and on the > existence of the fdesign binary. > %.c: %.fd ../fdesign/fdesign > > Lines 2,3. The problems. It appears that fdesign must be run from the > directory containing the .fd file. That means I lose track of the fdesign > binary and then must move the generated .[ch] files into the $builddir tree > (if $srcdir != $builddir). > > Any ideas? > Angus Actually, fdesign does not need to be ran from the directory containing the .fd file. You can pass it the path to the .fd, as in `fdesign -convert $<`, however fdesign as built now will make the .[ch] files in the same directory as the .fd file. perhaps you can/should use the gnu-make extension of vpath's, i.e., have the following added to the beginning of the demo's directory Makefile: vpath %.h . vpath %.c . vpath %.h ./fd vpath %.c ./fd vpath %.fd ./fd at least when vpath is available. a fallback, for non gnu makes, might be to make a rule that causes a `cp -p *.fd .` to occur if any file is newer in the fd directory than say the 'fdscopied' file, i.e., make fdscopied depend on all .fd files in the fd directory. Ugly but I am pretty sure I have used it in the past with other recalcitrant programs. At a later time it would be nice to have an option to pass to fdesign to either force it to output in the current working directory, or another specified output directory. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From angus.leeming at btopenworld.com Wed Nov 26 09:32:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:32:19 +0000 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <3FC4B6FB.B727860E@ssa.crane.navy.mil> References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> <3FC4B6FB.B727860E@ssa.crane.navy.mil> Message-ID: <200311261432.19460.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 2:21 pm, Todd Denniston wrote: Hi, Todd. > Actually, fdesign does not need to be ran from the directory containing > the .fd file. > You can pass it the path to the .fd, as in `fdesign -convert $<`, > however fdesign as built now will make the .[ch] files in the same > directory as the .fd file. Jean-Marc says that this works only so long as the path to the .fd file does not contain any '.'. See his patch. > perhaps you can/should use the gnu-make extension of vpath's, i.e., have > the following added to the beginning of the demo's directory Makefile: Hacks to work round a broken fdesign. Let's fix fdesign instead. > At a later time it would be nice to have an option to pass to fdesign to > either force it to output in the current working directory, or another > specified output directory. $ fdesign -d -convert ../foo/bar/your_file.fd That's what I'd like to get working. Angus From tacorner at chello.at Wed Nov 26 11:10:04 2003 From: tacorner at chello.at (tacorner at chello.at) Date: Wed, 26 Nov 2003 17:10:04 +0100 (CET) Subject: [XForms] Font selector widget Message-ID: I am thinking about writing a font selection widget for xfmail using xforms. Does such a thing exist in xforms itself or another xforms applications? Any suggestions? Tom Corner --------------------------------------------------- |\/\/\___/\/\/| Carol Anne Corner & \____ o o ____/ Thomas Corner ) ( 26-Nov-2003 17:06:59 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --------------------------------------------------- From msz at astrouw.edu.pl Wed Nov 26 17:06:24 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 26 Nov 2003 23:06:24 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311261043.16110.angus.leeming@btopenworld.com> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> <20031126082609.GA9882@astrouw.edu.pl> <200311261043.16110.angus.leeming@btopenworld.com> Message-ID: <20031126220624.GA11680@astrouw.edu.pl> On Wed, Nov 26, 2003 at 10:43:16AM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > On Wednesday 26 November 2003 8:26 am, Michal Szymanski wrote: > > Hi, > > > > I did not go into details but downloaded Clive's patched versions of the > > 1.0 libs and indeed, my application started to read JPEG/EXIF images > > from my digital camera without any modification, just relinking. So I'd > > strongely vote for including the patch(es) into XForms. > > Could you revert Clive's patch and try the one I appended in my original reply > to his posting? This patch contains the jpeg and gif enhancements and I am > more than happy to merge it into the xforms sources. I've applied your version of Clive's patch to my home CVS source tree. The Changelog patch got rejected but both "image" patches succeeded. And my application reading images can now read JPEG/EXIF files taken from my digital camera. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From xforms2 at vjet.demon.co.uk Wed Nov 26 21:27:21 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Thu, 27 Nov 2003 02:27:21 GMT Subject: [XForms] Re: JPEG/EXIF support? Message-ID: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> Thanks Angus, > > It probably needs massaging to work on the latest CVS. It fixes a bug in > > flimage_dup() , > > I'm not going to apply this without some discussion. Feel free to explain the > rationale. Well, its a while ago, but if memory serves, I found that if I dup'd an image then later free'd both copies I got a crash. The crash was because the first free also closed the files and the second one tried to do the same again, but the fp's were no longer valid. There needs to be only one reference to the fp.. Either it goes in a shared struct that both 'images' point to, or only one image can be associated with the file. I'm not sure that 2 'images' and one file really makes sense anyway. FWIW: I duped the image because I wanted to have the original and a processed copy, so I made a dup and then processed it.. When I'd finished with both images I free'd both.. Seemed reasonable to me. > > > one in image rotate. > > I don't see the need for this. See the comment immediately preceeding your > patched code. In cvs at least. > /* > * Now coerce it into +/- 180. > */ You're right - this one was broken in the 1.0 candidates and fixed in 1.0.. (Sorry..) > > > and makes jpeg + gif reading better. > > I've applied both these parts to my local tree, albeit with some re-factoring > to get rid of the goto and some signed-unsigned comparson warnings. Could you > check to see that all is still as you intended (attached). If you could cast > your eye over the ChangeLog entry and maybe rename 'flush_buffer' to > something that makes sense to you, that'd be great too... Had a fair look at it - seems OK on paper. flush_buffer is fine. The function flushes completed lines from the working buffer. (If you don't like the goto, with hindsight, an else might have been better ;-) Cheers Clive From tacorner at chello.at Thu Nov 27 03:05:52 2003 From: tacorner at chello.at (tacorner at chello.at) Date: Thu, 27 Nov 2003 09:05:52 +0100 (CET) Subject: [XForms] xforms cvs access Message-ID: Another question: Is it possible to get read-only access to the xforms cvs? Thanks, Tom Corner --------------------------------------------------- |\/\/\___/\/\/| Carol Anne Corner & \____ o o ____/ Thomas Corner tacorner at chello.at ) ( 27-Nov-2003 09:04:25 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --------------------------------------------------- From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 04:54:05 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 10:54:05 +0100 Subject: [XForms] xforms cvs access In-Reply-To: (tacorner@chello.at's message of "Thu, 27 Nov 2003 09:05:52 +0100 (CET)") References: Message-ID: >>>>> "tacorner" == tacorner writes: tacorner> To subscribers of the xforms list Another question: Is it tacorner> possible to get read-only access to the xforms cvs? Yes. Look here: https://savannah.nongnu.org/cvs/?group=xforms JMarc From angus.leeming at btopenworld.com Thu Nov 27 05:22:42 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 10:22:42 +0000 Subject: [XForms] xforms cvs access In-Reply-To: References: Message-ID: <200311271022.42662.angus.leeming@btopenworld.com> On Thursday 27 November 2003 8:05 am, tacorner at chello.at wrote: Hi, Tom > Another question: Is it possible to get read-only access to the xforms > cvs? Certainly. See http://savannah.nongnu.org/cvs/?group=xforms In summary cvs -d :pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms co xforms Thereafter, shove this in .cvsrc in your home directory: diff -upN rdiff -upN update -dP and "cvs up" should keep you up-to-date. Regards, Angus From angus.leeming at btopenworld.com Thu Nov 27 05:23:41 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 10:23:41 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031126220624.GA11680@astrouw.edu.pl> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311261043.16110.angus.leeming@btopenworld.com> <20031126220624.GA11680@astrouw.edu.pl> Message-ID: <200311271023.41446.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 10:06 pm, Michal Szymanski wrote: > > Could you revert Clive's patch and try the one I appended in my original > > reply to his posting? This patch contains the jpeg and gif enhancements > > and I am more than happy to merge it into the xforms sources. > > I've applied your version of Clive's patch to my home CVS source tree. > The Changelog patch got rejected but both "image" patches succeeded. And > my application reading images can now read JPEG/EXIF files taken from my > digital camera. Then I shall commit it. Many thanks to you both, Angus From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 05:40:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 11:40:20 +0100 Subject: [XForms] Font selector widget In-Reply-To: (tacorner@chello.at's message of "Wed, 26 Nov 2003 17:10:04 +0100 (CET)") References: Message-ID: >>>>> "tacorner" == tacorner writes: tacorner> To subscribers of the xforms list I am thinking about tacorner> writing a font selection widget for xfmail using xforms. tacorner> Does such a thing exist in xforms itself or another xforms tacorner> applications? Any suggestions? I do not know of any... However, an idea would be to try to track the version 2.x of xfce (www.xfce.org) which is a desktop environment (like cde). Versions 1.x and 2.x where based on xforms (whence the name) and I would expect that there is a lot of xforms code to take from there (including a font chooser, maybe). [Later] I have now tracked down a copy: http://www-rocq.inria.fr/~lasgoutt/xfce-2.4.0.tar.gz Unfortunately, there does not seem to be a font chooser in it. However it may be worth looking if there some reusable widgets in the code (the license is not GPL-compatible, but I would be surprised if the author did not allow for a license change on such an old software). JMarc From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 06:32:05 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 12:32:05 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311271023.41446.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 10:23:41 +0000") References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311261043.16110.angus.leeming@btopenworld.com> <20031126220624.GA11680@astrouw.edu.pl> <200311271023.41446.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 10:06 pm, Michal Szymanski wrote: >> > Could you revert Clive's patch and try the one I appended in my >> original > reply to his posting? This patch contains the jpeg and >> gif enhancements > and I am more than happy to merge it into the >> xforms sources. >> >> I've applied your version of Clive's patch to my home CVS source >> tree. The Changelog patch got rejected but both "image" patches >> succeeded. And my application reading images can now read JPEG/EXIF >> files taken from my digital camera. Angus> Then I shall commit it. Many thanks to you both, Angus tru64 cc does not think that this code is OK: cc -std1 -DHAVE_CONFIG_H -I. -I../../xforms/image -I../lib -DMAKING_FORMS -I../lib -I../../xforms/lib -I/afs/rocq/home/preval/common/include -I/usr/local/include -g -c -MD ../../xforms/image/image_gif.c -DPIC -o .libs/image_gif.lo cc: Warning: ../../xforms/image/image_gif.c, line 672: The scalar variable "incode" is fetched but not initialized. (uninit1) flush_buffer(im, incode); -------------------------^ Indeed, if I read process_lzw_code correctly, the variable incode is not always initialized. Since I do not understand what it stands for, I cannot propose a fix, but obviously this needs to be fixed in some way. JMarc From angus.leeming at btopenworld.com Thu Nov 27 06:49:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 11:49:24 +0000 Subject: [XForms] Re: JPEG/EXIF support? In-Reply-To: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> References: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> Message-ID: <200311271149.24457.angus.leeming@btopenworld.com> On Thursday 27 November 2003 2:27 am, Clive A Stubbings wrote: > > > It fixes a bug in flimage_dup() , > > > > I'm not going to apply this without some discussion. Feel free to explain > > the rationale. > > Well, its a while ago, but if memory serves, I found that if I dup'd an > image then later free'd both copies I got a crash. The crash was because > the first free also closed the files and the second one tried to do the > same again, but the fp's were no longer valid. > > There needs to be only one reference to the fp.. Either it goes in a > shared struct that both 'images' point to, or only one image can be > associated with the file. I'm not sure that 2 'images' and one file > really makes sense anyway. > > FWIW: I duped the image because I wanted to have the original and a > processed copy, so I made a dup and then processed it.. When I'd > finished with both images I free'd both.. Seemed reasonable to me. And to me too. I do something similar in LyX. Here are the relvant parts of my wrapper class. My question to you is, "why doesn't this trigger the crash"? If I make two copies of the image and then invoke flimage_free in the destructor, why don't I run into your problem? class xformsImage { public: xformsImage(): image_(0) {} xformsImage(xformsImage const & other) : image_(0) { if (other.image_) { image_ = flimage_dup(other.image_); image_->u_vdata = this; } } ~xformsImage() { if (image_) flimage_free(image_); } private: /// The xforms container. FL_IMAGE * image_; }; Ahhhhhhh. Because I use a callback function to monitor the loading process and explicitly close the FILE pointers when loading is complete. void xformsImage::statusCB(string const & status_message) { if (status_message.empty()) return; if (prefixIs(status_message, "Done Reading")) { if (image_) flimage_close(image_); finishedLoading(true); } } Anyway, I see the need for your patch or for something like it. Perhaps it would be better to not copy the file pointers in flimage_dup in the first place? Hmmmmmmmm. flimage_dup does NOT copy the FILE pointers. The only place that they are set is in identify_image which in turn is invoked only by flimage_open (in turn invoked by flimage_load). The point is that flimage_dup does not invoke any of these routines. Conclusion: I don't see the need for the patch. No doubt I've got my logic wrong somewhere, so I'd be grateful if you'd have a look at the current xforms sources too... > > > and makes jpeg + gif reading better. > > > > I've applied both these parts to my local tree, albeit with some > > re-factoring to get rid of the goto and some signed-unsigned comparson > > warnings. Could you check to see that all is still as you intended > > (attached). If you could cast your eye over the ChangeLog entry and maybe > > rename 'flush_buffer' to something that makes sense to you, that'd be > > great too... > > Had a fair look at it - seems OK on paper. flush_buffer is fine. The > function flushes completed lines from the working buffer. And Michal says it works, so I have committed it. Many thanks for the patch. > (If you don't like the goto, with hindsight, an else might have been better > ;-) Let's just say I have a pathological hatred of 'goto'. Something to do with maintaining some old Fortran66 code. Regards, Angus From angus.leeming at btopenworld.com Thu Nov 27 07:00:59 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 12:00:59 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311271023.41446.angus.leeming@btopenworld.com> Message-ID: <200311271200.59974.angus.leeming@btopenworld.com> On Thursday 27 November 2003 11:32 am, Jean-Marc Lasgouttes wrote: > Angus> Then I shall commit it. Many thanks to you both, Angus > > tru64 cc does not think that this code is OK: > > cc -std1 -DHAVE_CONFIG_H -I. -I../../xforms/image -I../lib -DMAKING_FORMS > -I../lib -I../../xforms/lib -I/afs/rocq/home/preval/common/include > -I/usr/local/include -g -c -MD ../../xforms/image/image_gif.c -DPIC -o > .libs/image_gif.lo cc: Warning: ../../xforms/image/image_gif.c, line 672: > The scalar variable "incode" is fetched but not initialized. (uninit1) > flush_buffer(im, incode); > -------------------------^ > > Indeed, if I read process_lzw_code correctly, the variable incode is > not always initialized. Since I do not understand what it stands for, > I cannot propose a fix, but obviously this needs to be fixed in some > way. Reading the code again static void flush_buffer(FL_IMAGE * im, int incode) { int i; incode = lbuf - lhead; ... Ie, the first thing that is done in flush_buffer is set incode. So, we have two options: * do not pass incode to the routine and have a local variable instead * pass a pointer to incode. Since the variable incode in process_lzw_code is not static and flush_buffer is the last thing called before returning from process_lzw_code, I think that the first option is sufficient. See attached patch. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: image_giff.diff Type: text/x-diff Size: 1028 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/99303652/attachment-0001.bin From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 07:56:17 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 13:56:17 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311271200.59974.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 12:00:59 +0000") References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311271023.41446.angus.leeming@btopenworld.com> <200311271200.59974.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Ie, the first thing that is done in flush_buffer is set incode. Angus> So, we have two options: * do not pass incode to the routine Angus> and have a local variable instead * pass a pointer to incode. Angus> Since the variable incode in process_lzw_code is not static and Angus> flush_buffer is the last thing called before returning from Angus> process_lzw_code, I think that the first option is sufficient. Angus> See attached patch. You are right. JMarc From angus.leeming at btopenworld.com Thu Nov 27 10:23:00 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 15:23:00 +0000 Subject: [XForms] NEWS update Message-ID: <200311271523.00688.angus.leeming@btopenworld.com> As requested... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: news.diff Type: text/x-diff Size: 1451 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/d2c2afb8/attachment-0001.bin From angus.leeming at btopenworld.com Wed Nov 26 11:42:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 16:42:19 +0000 Subject: [XForms] Adding '-dir ' to fdesign Message-ID: <200311261642.19472.angus.leeming@btopenworld.com> See attached. The patch also contains JMarc's changes to fd_forms.c. The only bit I'm unsure about are the initializations in static FL_CMD_OPT fd_cmdopt[] and in static FL_resource fdres[] The rest seems pretty straightforward. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 6372 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/3880bca1/attachment-0001.bin From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 11:08:14 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 17:08:14 +0100 Subject: [XForms] Adding '-dir ' to fdesign In-Reply-To: <200311261642.19472.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 16:42:19 +0000") References: <200311261642.19472.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list See attached. The patch also Angus> contains JMarc's changes to fd_forms.c. Wow. This one needed 23 hours to appear... JMarc From angus.leeming at btopenworld.com Thu Nov 27 11:26:57 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 16:26:57 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms/fdesign fd_forms.c fd_main.c fd_main.h f... In-Reply-To: References: Message-ID: <200311271626.57490.angus.leeming@btopenworld.com> On Thursday 27 November 2003 3:41 pm, Jean-Marc Lasgouttes wrote: > Angus> Log message: Give fdesign a -dir option. > > I see you've been busy... Well, not sooooooo busy. > +static char const * > +filename_only(char const * filename) > +{ > + char const * ptr = filename + strlen(filename) - 1; > + for (; ptr >= filename; --ptr) { > + if (*ptr == '/') > + return ptr+1; > + } > + return ptr; > +} > + > > Can't you use strrchr() here? Yup. Thanks. Like this? static char const * filename_only(char const * filename) { char const * ptr = strrchr(filename, '/'); if (ptr) return ptr+1; return filename; } > What happens with the external convertors? They get passed '-dir '. > You should also document the new switch in fdesign man page. Granted. Angus From angus.leeming at btopenworld.com Thu Nov 27 13:15:55 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 18:15:55 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms/fdesign fd_forms.c fd_main.c fd_main.h f... In-Reply-To: <200311271626.57490.angus.leeming@btopenworld.com> References: <200311271626.57490.angus.leeming@btopenworld.com> Message-ID: <200311271815.55461.angus.leeming@btopenworld.com> On Thursday 27 November 2003 4:26 pm, Angus Leeming wrote: > > Can't you use strrchr() here? > Yup. Thanks. Like this? [snip...] > > You should also document the new switch in fdesign man page. > Granted. Patch attached, FYI. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 2080 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/21408007/attachment-0001.bin From angus.leeming at btopenworld.com Thu Nov 27 16:24:57 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 21:24:57 +0000 Subject: [XForms] Getting rid of generated files Message-ID: <200311272124.57343.angus.leeming@btopenworld.com> Attached is a patch that uses the new -dir option of fdesign to get rid of demos/fd/button_gui.[ch] from the cvs repository. I've checked that all works fine from a 'make distdir' tree as well. Indeed, almost all of the .[ch] files in demos/fd can be removed in the same manner. The only ones that must remain are fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. Fdesign does not have the ability currently to #include user-specifed files. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-diff Size: 7226 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/4e33e2b5/attachment-0001.bin From angus.leeming at btopenworld.com Thu Nov 27 17:24:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 22:24:19 +0000 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272124.57343.angus.leeming@btopenworld.com> References: <200311272124.57343.angus.leeming@btopenworld.com> Message-ID: <200311272224.19706.angus.leeming@btopenworld.com> On Thursday 27 November 2003 9:24 pm, Angus Leeming wrote: > To subscribers of the xforms list > Indeed, almost all of the .[ch] files in demos/fd can be removed > in the same manner. The only ones that must remain are > fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend > on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. > Fdesign does not have the ability currently to #include user-specifed files. Actually, it transpires that I can remove these files too. The trick is to ensure that fd/ibrowser_gui.c is not compiled on its own, but rather that it is #included by ibrowser.c. (This trick was much-used in the demos dir; I have retained it only for the compilation of ibrowser.c and itest.c.) Angus From angus.leeming at btopenworld.com Thu Nov 27 17:31:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 22:31:24 +0000 Subject: [XForms] Towards xforms 1.1 Message-ID: <200311272231.24152.angus.leeming@btopenworld.com> Ok, Jean-Marc. I think that we're getting closer, don't you? What else do you have on your to-do list? Regards, Angus From xforms2 at vjet.demon.co.uk Thu Nov 27 20:37:31 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Fri, 28 Nov 2003 01:37:31 GMT Subject: [XForms] Re: JPEG/EXIF support? Message-ID: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> Hi Angus, I built the original fix a long time ago, possibly on one of the really early open releases. It is always possible that it has been subsequently fixed elsewhere. The old flimage_dup did FL_IMAGE * flimage_dup_(FL_IMAGE * sim, int pix) { ... FL_IMAGE *im = flimage_alloc(); ... memcpy(im, sim, sizeof(*im)); Which seems a bit iffy.. I've just checked - thats is also how it is in 1.0. Can you check the current version? Cheers Clive > On Thursday 27 November 2003 2:27 am, Clive A Stubbings wrote: > > > > It fixes a bug in flimage_dup() , > > > > > > I'm not going to apply this without some discussion. Feel free to explain > > > the rationale. > > > > Well, its a while ago, but if memory serves, I found that if I dup'd an > > image then later free'd both copies I got a crash. The crash was because > > the first free also closed the files and the second one tried to do the > > same again, but the fp's were no longer valid. > > > > There needs to be only one reference to the fp.. Either it goes in a > > shared struct that both 'images' point to, or only one image can be > > associated with the file. I'm not sure that 2 'images' and one file > > really makes sense anyway. > > > > FWIW: I duped the image because I wanted to have the original and a > > processed copy, so I made a dup and then processed it.. When I'd > > finished with both images I free'd both.. Seemed reasonable to me. > > And to me too. I do something similar in LyX. Here are the relvant parts of my > wrapper class. My question to you is, "why doesn't this trigger the crash"? > If I make two copies of the image and then invoke flimage_free in the > destructor, why don't I run into your problem? > > class xformsImage { > public: > xformsImage(): image_(0) {} > xformsImage(xformsImage const & other) : image_(0) { > if (other.image_) { > image_ = flimage_dup(other.image_); > image_->u_vdata = this; > } > } > > ~xformsImage() { > if (image_) > flimage_free(image_); > } > private: > /// The xforms container. > FL_IMAGE * image_; > }; > > Ahhhhhhh. Because I use a callback function to monitor the loading process and > explicitly close the FILE pointers when loading is complete. > > void xformsImage::statusCB(string const & status_message) > { > if (status_message.empty()) > return; > > if (prefixIs(status_message, "Done Reading")) { > if (image_) > flimage_close(image_); > finishedLoading(true); > } > } > > Anyway, I see the need for your patch or for something like it. > > Perhaps it would be better to not copy the file pointers in flimage_dup in the > first place? Hmmmmmmmm. flimage_dup does NOT copy the FILE pointers. The only > place that they are set is in identify_image which in turn is invoked only by > flimage_open (in turn invoked by flimage_load). The point is that flimage_dup > does not invoke any of these routines. > > Conclusion: I don't see the need for the patch. > No doubt I've got my logic wrong somewhere, so I'd be grateful if you'd have a > look at the current xforms sources too... > > > > > > > and makes jpeg + gif reading better. > > > > > > I've applied both these parts to my local tree, albeit with some > > > re-factoring to get rid of the goto and some signed-unsigned comparson > > > warnings. Could you check to see that all is still as you intended > > > (attached). If you could cast your eye over the ChangeLog entry and maybe > > > rename 'flush_buffer' to something that makes sense to you, that'd be > > > great too... > > > > Had a fair look at it - seems OK on paper. flush_buffer is fine. The > > function flushes completed lines from the working buffer. > > And Michal says it works, so I have committed it. Many thanks for the patch. > > > (If you don't like the goto, with hindsight, an else might have been better > > ;-) > > Let's just say I have a pathological hatred of 'goto'. Something to do with > maintaining some old Fortran66 code. > > Regards, > Angus > > From angus.leeming at btopenworld.com Fri Nov 28 04:16:22 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 09:16:22 +0000 Subject: [XForms] Re: JPEG/EXIF support? In-Reply-To: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> References: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> Message-ID: <200311280916.22028.angus.leeming@btopenworld.com> On Friday 28 November 2003 1:37 am, Clive A Stubbings wrote: > Hi Angus, > > I built the original fix a long time ago, possibly on one of the really > early open releases. It is always possible that it has been subsequently > fixed elsewhere. > > The old flimage_dup did > > FL_IMAGE * > flimage_dup_(FL_IMAGE * sim, int pix) > { > ... > FL_IMAGE *im = flimage_alloc(); > ... > memcpy(im, sim, sizeof(*im)); > > > Which seems a bit iffy.. I've just checked - thats is also how it is > in 1.0. Can you check the current version? Sigh! Yes, it still does. However, it goes on: memcpy(im, sim, sizeof(*im)); /* reset all pointers */ im->red = im->green = im->blue = im->alpha = 0; im->red_lut = im->green_lut = im->blue_lut = im->alpha_lut = 0; im->gray = 0; im->ci = 0; im->red16 = im->green16 = im->blue16 = im->alpha16 = 0; im->packed = 0; im->wlut = 0; im->llut[0] = im->llut[1] = im->llut[2] = 0; im->extra_io_info = 0; im->info = 0; There are actually a heap more pointers that these defined in the struct, but I guess that it's here that we should reset the fpin and fpout pointers, no? Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:15:43 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:15:43 +0100 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272224.19706.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:24:19 +0000") References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Thursday 27 November 2003 9:24 pm, Angus Leeming wrote: >> To subscribers of the xforms list >> Indeed, almost all of the .[ch] files in demos/fd can be removed in >> the same manner. The only ones that must remain are >> fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend >> on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. >> Fdesign does not have the ability currently to #include >> user-specifed files. Angus> Actually, it transpires that I can remove these files too. The Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on Angus> its own, but rather that it is #included by ibrowser.c. (This Angus> trick was much-used in the demos dir; I have retained it only Angus> for the compilation of ibrowser.c and itest.c.) Excellent. From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:15:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:15:19 +0100 Subject: [XForms] Towards xforms 1.1 In-Reply-To: <200311272231.24152.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:31:24 +0000") References: <200311272231.24152.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Ok, Jean-Marc. I think that Angus> we're getting closer, don't you? What else do you have on your Angus> to-do list? In no particular order: - We've got to decide on a version number. I suggest something like 1.0.90. The m4 code needs to be changed probably, as we seem to have two notions of current version in configure.ac. - we may need to support dlls under windows (but this can maybe wait for next version). The key is to use AC_LIBTOOL_WIN32_DLL: Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with __declspec(dllexport) and imported with __declspec(dllimport). If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts. This macro must be called before AC_PROG_LIBTOOL, and provision must be made to pass `-no-undefined' to libtool in link mode from the package Makefile. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols really are defined at link time! Actually, I do not know whether xforms 1.0 did build as dll for cygwin. - I still have a problem to fix for proper handling of RETSIGTYPE in lib/signal.c. I did not find any clear solution in other programs... Maybe a little bit of autoconf magic will suffice. - we need to update README a little bit more (there is a duplicated part...) - besides the standard installation instructions in INSTALL, should we document things like --enable-demos --enable-gl and friends? JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:17:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:17:20 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031124172821.GA9534@astrouw.edu.pl> (Michal Szymanski's message of "Mon, 24 Nov 2003 18:28:21 +0100") References: <20031123153548.GA18821@astrouw.edu.pl> <20031124172821.GA9534@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: >> Try to run ./autogen.sh instead. Michal> Thanks, it worked. I guess it might be worth putting into Michal> INSTALL file which now is somewhat misleading. I think the right thing to do is to have a README-cvs file which is in cvs (and gives the info) but is not distributed... JMarc From angus.leeming at btopenworld.com Fri Nov 28 12:32:35 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:32:35 +0000 Subject: [XForms] Towards xforms 1.1 In-Reply-To: References: <200311272231.24152.angus.leeming@btopenworld.com> Message-ID: <200311281732.35512.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:15 pm, Jean-Marc Lasgouttes wrote: > Angus> To subscribers of the xforms list Ok, Jean-Marc. I think that > Angus> we're getting closer, don't you? What else do you have on your > Angus> to-do list? > > In no particular order: > > - We've got to decide on a version number. I suggest something like > 1.0.90. Ok. > The m4 code needs to be changed probably, as we seem to have > two notions of current version in configure.ac. Is this the difference between the 'release' version and the 'indication of the binary compatibility of the libraries' version thingy that confused us way back when? Is there no place that we can ask for advice? Someone must understand this stuff. > - we may need to support dlls under windows (but this can maybe wait > for next version). I don't know about you, but I think of this release as the 'autotools' release. Would be nice therefore if we finished it off before release and never had to worry about any of this crap ever again... > - we need to update README a little bit more (there is a duplicated > part...) I'll have a go. > - besides the standard installation instructions in INSTALL, should we > document things like --enable-demos --enable-gl and friends? Yes. Where would it go? In INSTALL, or is that simply the generic stuff. Incidentally, (now that I have repaired your breakage of 'make rpmdist' ;-P), would it make sense to create an xforms-demos src rpm. I guess that there is little point creating a binary of same... Hmmm, I'm not sure that would work, since the Makefile assumes that fdesign is to be found in ../fdesign/fdesign. Let's leave that then ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:28:13 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:28:13 +0100 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272224.19706.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:24:19 +0000") References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: mk.log Type: application/octet-stream Size: 4770 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031128/424be7d7/attachment-0001.obj From angus.leeming at btopenworld.com Fri Nov 28 12:45:56 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:45:56 +0000 Subject: [XForms] Getting rid of generated files In-Reply-To: References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: <200311281745.56835.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:28 pm, Jean-Marc Lasgouttes wrote: > Angus> Actually, it transpires that I can remove these files too. The > Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on > Angus> its own, but rather that it is #included by ibrowser.c. (This > Angus> trick was much-used in the demos dir; I have retained it only > Angus> for the compilation of ibrowser.c and itest.c.) > > Unfortunately, it does not work here. Why? Genuinely no problems here. Question: where is FL_NORMAL_FORMBROWSER defined? Answer lib/include/forms.h Here the first 5 lines of formbrowser_gui.c are: /* Form definition file generated with fdesign. */ #include "forms.h" #include #include "formbrowser_gui.h" Ie, I don't see why it is failing. I'm a bit upset about the subsequent warnings about two many initializers too... Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:38:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:38:20 +0100 Subject: [XForms] Towards xforms 1.1 In-Reply-To: <200311281732.35512.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 Nov 2003 17:32:35 +0000") References: <200311272231.24152.angus.leeming@btopenworld.com> <200311281732.35512.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I don't know about you, but I think of this release as the Angus> 'autotools' release. Would be nice therefore if we finished it Angus> off before release and never had to worry about any of this Angus> crap ever again... Then we need to get Kayvan to test it, but we could maybe release 1.0.90 and implement libtol support from there. >> - besides the standard installation instructions in INSTALL, should >> we document things like --enable-demos --enable-gl and friends? Angus> Yes. Where would it go? In INSTALL, or is that simply the Angus> generic stuff. I do not know. INSTALL is supposed (in GNU world) to come straight from autoconf (I do not know why). I do not know what is the gnuly correct place. Angus> Incidentally, (now that I have repaired your breakage of 'make Angus> rpmdist' ;-P), would it make sense to create an xforms-demos Angus> src rpm. I guess that there is little point creating a binary Angus> of same... Hmmm, I'm not sure that would work, since the Angus> Makefile assumes that fdesign is to be found in Angus> ../fdesign/fdesign. Yes, the sources are not so large. JMarc PS: We should also get the docs on the web page. Also, should we have a document ``how to adapt your application to 1.1'', or is everything just supposed to work magically? From angus.leeming at btopenworld.com Fri Nov 28 12:55:18 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:55:18 +0000 Subject: [XForms] Towards xforms 1.1 In-Reply-To: References: <200311272231.24152.angus.leeming@btopenworld.com> <200311281732.35512.angus.leeming@btopenworld.com> Message-ID: <200311281755.18644.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:38 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> I don't know about you, but I think of this release as the > Angus> 'autotools' release. Would be nice therefore if we finished it > Angus> off before release and never had to worry about any of this > Angus> crap ever again... > > Then we need to get Kayvan to test it, but we could maybe release > 1.0.90 and implement libtol support from there. Ok. > >> - besides the standard installation instructions in INSTALL, should > >> we document things like --enable-demos --enable-gl and friends? > > Angus> Yes. Where would it go? In INSTALL, or is that simply the > Angus> generic stuff. > > I do not know. INSTALL is supposed (in GNU world) to come straight > from autoconf (I do not know why). I do not know what is the gnuly > correct place. Who to ask? > PS: We should also get the docs on the web page. Also, should we have > a document ``how to adapt your application to 1.1'', or is everything > just supposed to work magically? We have been promised these docs since the day xforms 1.0 was released. I really don't know what the problem is :-( Once we get them, it would make sense to invest some time in a homepage on savannah. Angus From angus.leeming at btopenworld.com Sat Nov 29 13:22:36 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 29 Nov 2003 18:22:36 +0000 Subject: [XForms] Re: [Xforms-cvs] First time CVS download. In-Reply-To: <3FC8DBA2.108@omensys.ca> References: <3FC8DBA2.108@omensys.ca> Message-ID: <200311291822.36936.angus.leeming@btopenworld.com> On Saturday 29 November 2003 5:47 pm, Serge B Bromow wrote: > I just tried to download the CVS tree for the first time to a RH7.3 OS. > There seems to be missing files. i.e "forms.h" and more. Generated from the smaller header files in lib/include. > Here is the script I used to retrieve the files and the output from the > script. The script looks Ok. Personally I would have $ ./autogen.sh $ mkdir build && cd build $ ../configure --enable-demos --enable-maintainer-mode $ make > Needless to say, "./configure" na d "make" fail. [snip most of the script output...] Using autoconf (GNU Autoconf) 2.58 Well, that certainly isn't part of RH7.3 ;-) Generate acinclude.m4... done. Building macros... . done. Building config header template... . /usr/bin/m4: configure.in: No such file or directory Ahhhh. We don't support the old version of autoconf (2.13 and below) that use configure.in. Instead, we require you to use autoconf 2.52 or above that uses configure.ac. The fact that your autoconf is searching for configure.in does not square with the message above saying that you are using autoconf 2.58. Jean-Marc, you're the autotools expert around here. Any ideas? > Am I missing something? Any thoughts? > > Serge Angus (cross-posting this to the xforms maiing list to ensure we get JMarc's attention.) From serge at omensys.ca Sat Nov 29 12:32:54 2003 From: serge at omensys.ca (Serge B Bromow) Date: Sat, 29 Nov 2003 12:32:54 -0500 Subject: [XForms] CVS Update Message-ID: <3FC8D846.1050305@omensys.ca> I just tried to download the CVS tree for the first time to a RH7.3 OS. There seem to be missing files. i.e "forms.h" and more. Here is the script I used to retrieve to file and the output from the script. Am I missing something? Any thoughts? Serge ----------------------- Script cd /home/serge rm -rf xforms cvs -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms co xforms cd xforms ./autogen.sh ./configure make ----------- Output [serge at daph serge]$ ./getxforms \Logging in to :pserver:anoncvs at savannah.nongnu.org:2401/cvsroot/xforms CVS password: cvs server: Updating xforms U xforms/.cvsignore U xforms/COPYING.LIB U xforms/ChangeLog U xforms/Copyright U xforms/INSTALL U xforms/Makefile.am U xforms/NEWS U xforms/README U xforms/README.OS2 U xforms/autogen.sh U xforms/configure.ac U xforms/xforms.spec.in cvs server: Updating xforms/NT U xforms/NT/libxforms.dsp U xforms/NT/xformsAll.dsw cvs server: Updating xforms/X11 cvs server: Updating xforms/config U xforms/config/.cvsignore U xforms/config/Makefile.am U xforms/config/common.am U xforms/config/config.guess U xforms/config/config.sub U xforms/config/cygwin.m4 U xforms/config/depcomp U xforms/config/libtool.m4 U xforms/config/ltmain.sh U xforms/config/xformsinclude.m4 cvs server: Updating xforms/demos U xforms/demos/.cvsignore U xforms/demos/01Readme U xforms/demos/Makefile.am U xforms/demos/arrowbutton.c U xforms/demos/bm1.xbm U xforms/demos/bm2.xbm U xforms/demos/borderwidth.c U xforms/demos/boxtype.c U xforms/demos/browserall.c U xforms/demos/browserop.c U xforms/demos/buttonall.c U xforms/demos/butttypes.c U xforms/demos/canvas.c U xforms/demos/chartall.c U xforms/demos/chartstrip.c U xforms/demos/choice.c U xforms/demos/colbrowser.c U xforms/demos/colsel.c U xforms/demos/colsel1.c U xforms/demos/counter.c U xforms/demos/crab.xpm U xforms/demos/crab45.xpm U xforms/demos/crab_tran.xpm U xforms/demos/crossbut.c U xforms/demos/crossbut.h U xforms/demos/cursor.c U xforms/demos/demo.c U xforms/demos/demo.menu U xforms/demos/demo05.c U xforms/demos/demo06.c U xforms/demos/demo27.c U xforms/demos/demo33.c U xforms/demos/demotest.c U xforms/demos/demotest2.c U xforms/demos/demotest3.c U xforms/demos/dirlist.c U xforms/demos/fbrowse.c U xforms/demos/fbrowse1.c U xforms/demos/fdial.c U xforms/demos/flclock.c U xforms/demos/folder.c U xforms/demos/fonts.c U xforms/demos/formbrowser.c U xforms/demos/free1.c U xforms/demos/freedraw.c U xforms/demos/freedraw_leak.c U xforms/demos/gl.c U xforms/demos/glwin.c U xforms/demos/goodies.c U xforms/demos/group.c U xforms/demos/ibrowser.c U xforms/demos/iconify.c U xforms/demos/iconvert.1 U xforms/demos/iconvert.c U xforms/demos/inputall.c U xforms/demos/invslider.c U xforms/demos/itest.c U xforms/demos/lalign.c U xforms/demos/ldial.c U xforms/demos/ll.c U xforms/demos/longlabel.c U xforms/demos/menu.c U xforms/demos/menubar.c U xforms/demos/minput.c U xforms/demos/minput2.c U xforms/demos/multilabel.c U xforms/demos/ndial.c U xforms/demos/newbutton.c U xforms/demos/newmail.xbm U xforms/demos/nnn.c U xforms/demos/nomail.xbm U xforms/demos/objinactive.c U xforms/demos/objpos.c U xforms/demos/objreturn.c U xforms/demos/picture.xbm U xforms/demos/pmbrowse.c U xforms/demos/popup.c U xforms/demos/porsche.xpm U xforms/demos/positioner.c U xforms/demos/positionerXOR.c U xforms/demos/preemptive.c U xforms/demos/pup.c U xforms/demos/pushbutton.c U xforms/demos/pushme.c U xforms/demos/rescale.c U xforms/demos/scrollbar.c U xforms/demos/secretinput.c U xforms/demos/sld_radio.c U xforms/demos/sldinactive.c U xforms/demos/sldsize.c U xforms/demos/sliderall.c U xforms/demos/srs.xbm U xforms/demos/strsize.c U xforms/demos/symbols.c U xforms/demos/test.ps U xforms/demos/test.xpm U xforms/demos/thumb.c U xforms/demos/thumbwheel.c U xforms/demos/timer.c U xforms/demos/timer.h U xforms/demos/timer2.c U xforms/demos/timerprec.c U xforms/demos/touchbutton.c U xforms/demos/wwwl.c U xforms/demos/xconq.xpm U xforms/demos/xterm.xpm U xforms/demos/xyover U xforms/demos/xyplotactive.c U xforms/demos/xyplotall.c U xforms/demos/xyplotover.c U xforms/demos/yesno.c U xforms/demos/yesno_cb.c cvs server: Updating xforms/demos/fd U xforms/demos/fd/.cvsignore U xforms/demos/fd/Makefile.am U xforms/demos/fd/buttons_gui.fd U xforms/demos/fd/butttypes_gui.fd U xforms/demos/fd/dim_porsche.xpm U xforms/demos/fd/fbtest_gui.fd U xforms/demos/fd/folder_gui.fd U xforms/demos/fd/formbrowser_gui.fd U xforms/demos/fd/ibrowser_gui.fd U xforms/demos/fd/inputall_gui.fd U xforms/demos/fd/is_gui.fd U xforms/demos/fd/pmbrowse_gui.fd U xforms/demos/fd/porsche.xpm U xforms/demos/fd/scrollbar_gui.fd U xforms/demos/fd/twheel_gui.fd cvs server: Updating xforms/exports cvs server: Updating xforms/fd2ps U xforms/fd2ps/.cvsignore U xforms/fd2ps/Change U xforms/fd2ps/Makefile.am U xforms/fd2ps/Readme U xforms/fd2ps/align.c U xforms/fd2ps/fd2ps.c U xforms/fd2ps/fd2ps.h U xforms/fd2ps/fd2ps.man U xforms/fd2ps/flsupport.c U xforms/fd2ps/global.h U xforms/fd2ps/image2ps.c U xforms/fd2ps/load.c U xforms/fd2ps/papers.c U xforms/fd2ps/pscol.c U xforms/fd2ps/psdraw.c U xforms/fd2ps/psobj.c U xforms/fd2ps/pstext.c U xforms/fd2ps/readxpm.c U xforms/fd2ps/sys.c U xforms/fd2ps/version.c U xforms/fd2ps/xbmtops.c U xforms/fd2ps/xpmtops.c cvs server: Updating xforms/fd2ps/test U xforms/fd2ps/test/.cvsignore U xforms/fd2ps/test/Makefile.am U xforms/fd2ps/test/all.fd U xforms/fd2ps/test/allcmm.fd U xforms/fd2ps/test/allpoint.fd U xforms/fd2ps/test/bm1.xbm U xforms/fd2ps/test/buttons.fd U xforms/fd2ps/test/crab.xpm U xforms/fd2ps/test/dial.fd U xforms/fd2ps/test/fd_logo.xpm U xforms/fd2ps/test/folder_gui.fd U xforms/fd2ps/test/junk.fd U xforms/fd2ps/test/parameter.xpm U xforms/fd2ps/test/picture.xbm U xforms/fd2ps/test/sym.fd U xforms/fd2ps/test/xconq.xpm cvs server: Updating xforms/fdesign U xforms/fdesign/.cvsignore U xforms/fdesign/Change U xforms/fdesign/Makefile.am U xforms/fdesign/Readme U xforms/fdesign/fd_attribs.c U xforms/fdesign/fd_control.c U xforms/fdesign/fd_fake.c U xforms/fdesign/fd_file.c U xforms/fdesign/fd_forms.c U xforms/fdesign/fd_groups.c U xforms/fdesign/fd_help.c U xforms/fdesign/fd_help.h U xforms/fdesign/fd_initforms.c U xforms/fdesign/fd_main.c U xforms/fdesign/fd_main.h U xforms/fdesign/fd_names.c U xforms/fdesign/fd_objects.c U xforms/fdesign/fd_pallette.c U xforms/fdesign/fd_printC.c U xforms/fdesign/fd_rubber.c U xforms/fdesign/fd_select.c U xforms/fdesign/fd_spec.c U xforms/fdesign/fd_spec.h U xforms/fdesign/fd_super.c U xforms/fdesign/fd_util.c U xforms/fdesign/fdesign.man U xforms/fdesign/sp_browser.c U xforms/fdesign/sp_button.c U xforms/fdesign/sp_choice.c U xforms/fdesign/sp_counter.c U xforms/fdesign/sp_dial.c U xforms/fdesign/sp_freeobj.c U xforms/fdesign/sp_menu.c U xforms/fdesign/sp_pixmap.c U xforms/fdesign/sp_positioner.c U xforms/fdesign/sp_scrollbar.c U xforms/fdesign/sp_slider.c U xforms/fdesign/sp_twheel.c U xforms/fdesign/sp_xyplot.c U xforms/fdesign/viewforms.c U xforms/fdesign/viewforms.fd U xforms/fdesign/viewforms.h U xforms/fdesign/viewforms_main.c U xforms/fdesign/xpm.h cvs server: Updating xforms/fdesign/fd U xforms/fdesign/fd/.cvsignore U xforms/fdesign/fd/Makefile.am U xforms/fdesign/fd/pallette.c U xforms/fdesign/fd/pallette.fd U xforms/fdesign/fd/pallette.h U xforms/fdesign/fd/ui_attrib.c U xforms/fdesign/fd/ui_attrib.fd U xforms/fdesign/fd/ui_attrib.h U xforms/fdesign/fd/ui_objs.c U xforms/fdesign/fd/ui_objs.fd U xforms/fdesign/fd/ui_objs.h U xforms/fdesign/fd/ui_theforms.c U xforms/fdesign/fd/ui_theforms.fd U xforms/fdesign/fd/ui_theforms.h cvs server: Updating xforms/fdesign/fd4test U xforms/fdesign/fd4test/.cvsignore U xforms/fdesign/fd4test/Makefile.am U xforms/fdesign/fd4test/inittest.fd U xforms/fdesign/fd4test/testfd.fd cvs server: Updating xforms/fdesign/notes U xforms/fdesign/notes/.cvsignore U xforms/fdesign/notes/Makefile.am U xforms/fdesign/notes/spec_algo cvs server: Updating xforms/fdesign/spec U xforms/fdesign/spec/.cvsignore U xforms/fdesign/spec/Makefile.am U xforms/fdesign/spec/browser_spec.c U xforms/fdesign/spec/browser_spec.fd U xforms/fdesign/spec/browser_spec.h U xforms/fdesign/spec/button_spec.c U xforms/fdesign/spec/button_spec.fd U xforms/fdesign/spec/button_spec.h U xforms/fdesign/spec/choice_spec.c U xforms/fdesign/spec/choice_spec.fd U xforms/fdesign/spec/choice_spec.h U xforms/fdesign/spec/counter_spec.c U xforms/fdesign/spec/counter_spec.fd U xforms/fdesign/spec/counter_spec.h U xforms/fdesign/spec/dial_spec.c U xforms/fdesign/spec/dial_spec.fd U xforms/fdesign/spec/dial_spec.h U xforms/fdesign/spec/free_spec.c U xforms/fdesign/spec/free_spec.fd U xforms/fdesign/spec/free_spec.h U xforms/fdesign/spec/freeobj_spec.c U xforms/fdesign/spec/freeobj_spec.fd U xforms/fdesign/spec/freeobj_spec.h U xforms/fdesign/spec/menu_spec.c U xforms/fdesign/spec/menu_spec.fd U xforms/fdesign/spec/menu_spec.h U xforms/fdesign/spec/pixmap_spec.c U xforms/fdesign/spec/pixmap_spec.fd U xforms/fdesign/spec/pixmap_spec.h U xforms/fdesign/spec/positioner_spec.c U xforms/fdesign/spec/positioner_spec.fd U xforms/fdesign/spec/positioner_spec.h U xforms/fdesign/spec/scrollbar_spec.c U xforms/fdesign/spec/scrollbar_spec.fd U xforms/fdesign/spec/scrollbar_spec.h U xforms/fdesign/spec/slider_spec.c U xforms/fdesign/spec/slider_spec.fd U xforms/fdesign/spec/slider_spec.h U xforms/fdesign/spec/twheel_spec.c U xforms/fdesign/spec/twheel_spec.fd U xforms/fdesign/spec/twheel_spec.h U xforms/fdesign/spec/xyplot_spec.c U xforms/fdesign/spec/xyplot_spec.fd U xforms/fdesign/spec/xyplot_spec.h cvs server: Updating xforms/fdesign/xpm U xforms/fdesign/xpm/.cvsignore U xforms/fdesign/xpm/Makefile.am U xforms/fdesign/xpm/allbutton.fd U xforms/fdesign/xpm/bm1.xbm U xforms/fdesign/xpm/bottom.xbm U xforms/fdesign/xpm/box.xpm U xforms/fdesign/xpm/br.xpm U xforms/fdesign/xpm/butt.xpm U xforms/fdesign/xpm/chart.xpm U xforms/fdesign/xpm/check.xpm U xforms/fdesign/xpm/choice.fd U xforms/fdesign/xpm/choice.xpm U xforms/fdesign/xpm/clock.xpm U xforms/fdesign/xpm/cnt.xpm U xforms/fdesign/xpm/crab.xpm U xforms/fdesign/xpm/crab_focus.xpm U xforms/fdesign/xpm/dial.xpm U xforms/fdesign/xpm/fd_logo.xpm U xforms/fdesign/xpm/frame.xpm U xforms/fdesign/xpm/glcan.xpm U xforms/fdesign/xpm/hcenter.xbm U xforms/fdesign/xpm/left.xbm U xforms/fdesign/xpm/lightb.xpm U xforms/fdesign/xpm/menu.xpm U xforms/fdesign/xpm/misc.fd U xforms/fdesign/xpm/nomail.xbm U xforms/fdesign/xpm/picture.xbm U xforms/fdesign/xpm/picture1.xbm U xforms/fdesign/xpm/porsche.xpm U xforms/fdesign/xpm/pos.xpm U xforms/fdesign/xpm/r3dbut.xpm U xforms/fdesign/xpm/right.xbm U xforms/fdesign/xpm/roundb.xpm U xforms/fdesign/xpm/scb.xpm U xforms/fdesign/xpm/sld.xpm U xforms/fdesign/xpm/static.fd U xforms/fdesign/xpm/tab.xpm U xforms/fdesign/xpm/text.xpm U xforms/fdesign/xpm/timer.xpm U xforms/fdesign/xpm/top.xbm U xforms/fdesign/xpm/twheel.xpm U xforms/fdesign/xpm/val.fd U xforms/fdesign/xpm/vals.xpm U xforms/fdesign/xpm/vcenter.xbm U xforms/fdesign/xpm/xconq.xpm U xforms/fdesign/xpm/xconq1.xpm U xforms/fdesign/xpm/xyplot.xpm cvs server: Updating xforms/gl U xforms/gl/.cvsignore U xforms/gl/Makefile.am U xforms/gl/glcanvas.c U xforms/gl/glcanvas.h cvs server: Updating xforms/image U xforms/image/.cvsignore U xforms/image/Makefile.am U xforms/image/flimage.h U xforms/image/flimage_int.h U xforms/image/image.c U xforms/image/image_bmp.c U xforms/image/image_combine.c U xforms/image/image_convolve.c U xforms/image/image_crop.c U xforms/image/image_disp.c U xforms/image/image_fits.c U xforms/image/image_genesis.c U xforms/image/image_gif.c U xforms/image/image_gzip.c U xforms/image/image_io_filter.c U xforms/image/image_jpeg.c U xforms/image/image_jquant.c U xforms/image/image_marker.c U xforms/image/image_oquant.c U xforms/image/image_png.c U xforms/image/image_pnm.c U xforms/image/image_postscript.c U xforms/image/image_proc.c U xforms/image/image_replace.c U xforms/image/image_rotate.c U xforms/image/image_scale.c U xforms/image/image_sgi.c U xforms/image/image_text.c U xforms/image/image_tiff.c U xforms/image/image_type.c U xforms/image/image_warp.c U xforms/image/image_xbm.c U xforms/image/image_xpm.c U xforms/image/image_xwd.c U xforms/image/matrix.c U xforms/image/postscript.c U xforms/image/ps_core.c U xforms/image/ps_draw.c U xforms/image/ps_text.c U xforms/image/rgb_db.c cvs server: Updating xforms/lib U xforms/lib/.cvsignore U xforms/lib/Change U xforms/lib/Makefile.am U xforms/lib/align.c U xforms/lib/appwin.c U xforms/lib/asyn_io.c U xforms/lib/be.c U xforms/lib/bitmap.c U xforms/lib/box.c U xforms/lib/browser.c U xforms/lib/button.c U xforms/lib/canvas.c U xforms/lib/chart.c U xforms/lib/checkbut.c U xforms/lib/child.c U xforms/lib/choice.c U xforms/lib/clipboard.c U xforms/lib/clock.c U xforms/lib/cmd_br.c U xforms/lib/colsel.c U xforms/lib/combo.c U xforms/lib/counter.c U xforms/lib/cursor.c U xforms/lib/dial.c U xforms/lib/dirent_vms.h U xforms/lib/display.c U xforms/lib/dmalloc.h U xforms/lib/errmsg.c U xforms/lib/events.c U xforms/lib/extern.h U xforms/lib/flcolor.c U xforms/lib/fldraw.c U xforms/lib/flinternal.h U xforms/lib/flresource.c U xforms/lib/flsnprintf.c U xforms/lib/flvisual.c U xforms/lib/fonts.c U xforms/lib/formbrowser.c U xforms/lib/forms.c U xforms/lib/frame.c U xforms/lib/free.c U xforms/lib/fselect.c U xforms/lib/global.h U xforms/lib/goodie_alert.c U xforms/lib/goodie_choice.c U xforms/lib/goodie_input.c U xforms/lib/goodie_msg.c U xforms/lib/goodie_salert.c U xforms/lib/goodie_sinput.c U xforms/lib/goodie_yesno.c U xforms/lib/goodies.c U xforms/lib/input.c U xforms/lib/interpol.c U xforms/lib/keyboard.c U xforms/lib/labelbut.c U xforms/lib/lframe.c U xforms/lib/lightbut.c U xforms/lib/listdir.c U xforms/lib/local.h U xforms/lib/menu.c U xforms/lib/n2a.c U xforms/lib/objects.c U xforms/lib/oneliner.c U xforms/lib/pixmap.c U xforms/lib/positioner.c U xforms/lib/read2lsbf.c U xforms/lib/read2msbf.c U xforms/lib/read4lsb.c U xforms/lib/read4msb.c U xforms/lib/readint.c U xforms/lib/round3d.c U xforms/lib/roundbut.c U xforms/lib/scrollbar.c U xforms/lib/scrollbut.c U xforms/lib/signal.c U xforms/lib/simu.c U xforms/lib/sldraw.c U xforms/lib/slider.c U xforms/lib/space.c U xforms/lib/spline.c U xforms/lib/strdup.c U xforms/lib/symbols.c U xforms/lib/sysdep.c U xforms/lib/tabfolder.c U xforms/lib/text.c U xforms/lib/textbox.c U xforms/lib/thumbwheel.c U xforms/lib/timeout.c U xforms/lib/timer.c U xforms/lib/tooltip.c U xforms/lib/ulib.h U xforms/lib/util.c U xforms/lib/valuator.c U xforms/lib/version.c U xforms/lib/vms_readdir.c U xforms/lib/vn_pair.c U xforms/lib/vstrcat.c U xforms/lib/win.c U xforms/lib/xdraw.c U xforms/lib/xforms.man U xforms/lib/xpopup.c U xforms/lib/xsupport.c U xforms/lib/xtext.c U xforms/lib/xyplot.c cvs server: Updating xforms/lib/OS2 cvs server: Updating xforms/lib/bitmaps U xforms/lib/bitmaps/.cvsignore U xforms/lib/bitmaps/Makefile.am U xforms/lib/bitmaps/plaid.xpm U xforms/lib/bitmaps/q.xbm U xforms/lib/bitmaps/warn.xbm cvs server: Updating xforms/lib/fd U xforms/lib/fd/.cvsignore U xforms/lib/fd/Makefile.am U xforms/lib/fd/cmdbr.c U xforms/lib/fd/cmdbr.fd U xforms/lib/fd/cmdbr.h U xforms/lib/fd/ginput.c U xforms/lib/fd/ginput.fd U xforms/lib/fd/ginput.h U xforms/lib/fd/micntl.c U xforms/lib/fd/micntl.fd U xforms/lib/fd/micntl.h cvs server: Updating xforms/lib/include U xforms/lib/include/.cvsignore U xforms/lib/include/AAA.h.in U xforms/lib/include/Basic.h U xforms/lib/include/Makefile.am U xforms/lib/include/XBasic.h U xforms/lib/include/bitmap.h U xforms/lib/include/box.h U xforms/lib/include/browser.h U xforms/lib/include/button.h U xforms/lib/include/canvas.h U xforms/lib/include/chart.h U xforms/lib/include/choice.h U xforms/lib/include/clipbd.h U xforms/lib/include/clock.h U xforms/lib/include/counter.h U xforms/lib/include/cursor.h U xforms/lib/include/dial.h U xforms/lib/include/filesys.h U xforms/lib/include/flps.h U xforms/lib/include/formbrowser.h U xforms/lib/include/frame.h U xforms/lib/include/free.h U xforms/lib/include/goodies.h U xforms/lib/include/input.h U xforms/lib/include/menu.h U xforms/lib/include/menubar.h U xforms/lib/include/popup.h U xforms/lib/include/positioner.h U xforms/lib/include/scrollbar.h U xforms/lib/include/slider.h U xforms/lib/include/tabfolder.h U xforms/lib/include/text.h U xforms/lib/include/thumbwheel.h U xforms/lib/include/timer.h U xforms/lib/include/xyplot.h U xforms/lib/include/zzz.h cvs server: Updating xforms/lib/private U xforms/lib/private/.cvsignore U xforms/lib/private/Makefile.am U xforms/lib/private/flsnprintf.h U xforms/lib/private/pbrowser.h U xforms/lib/private/pcanvas.h U xforms/lib/private/pchoice.h U xforms/lib/private/pcounter.h U xforms/lib/private/pdial.h U xforms/lib/private/pflps.h U xforms/lib/private/pformbrowser.h U xforms/lib/private/pmenu.h U xforms/lib/private/ppositioner.h U xforms/lib/private/pscrollbar.h U xforms/lib/private/pslider.h U xforms/lib/private/ptextbox.h U xforms/lib/private/ptwheel.h U xforms/lib/private/pvaluator.h U xforms/lib/private/pxyplot.h U xforms/lib/private/textbox.h cvs server: Updating xforms/snp cvs server: Updating xforms/snp/sparc-sun-sunos Using autoconf (GNU Autoconf) 2.58 Generate acinclude.m4... done. Building macros... . done. Building config header template... . /usr/bin/m4: configure.in: No such file or directory done. Building Makefile templates... . automake: configure.ac: installing `config/install-sh' automake: configure.ac: installing `config/mkinstalldirs' automake: configure.ac: installing `config/missing' configure.ac: 6: required file `./[lib/config.h].in' not found configure.ac: 6: required file `./[lib/stamp-h.in' not found lib/include/Makefile.am:3: invalid variable `nodist_include_HEADERS' fdesign/Makefile.am:19: variable `LIBS' not defined fd2ps/Makefile.am:19: variable `LIBS' not defined demos/Makefile.am:168: variable `LIBS' not defined demos/Makefile.am:172: variable `LIBS' not defined demos/Makefile.am:180: variable `LIBS' not defined demos/Makefile.am:187: variable `LIBS' not defined demos/Makefile.am:199: variable `LIBS' not defined demos/Makefile.am:207: variable `LIBS' not defined demos/Makefile.am:260: variable `LIBS' not defined demos/Makefile.am:225: invalid unused variable name: `nodist_pmbrowse_SOURCES' demos/Makefile.am:160: invalid unused variable name: `nodist_formbrowser_SOURCES' demos/Makefile.am:192: invalid unused variable name: `nodist_inputall_SOURCES' demos/Makefile.am:250: invalid unused variable name: `nodist_thumbwheel_SOURCES'demos/Makefile.am:154: invalid unused variable name: `nodist_folder_SOURCES' demos/Makefile.am:238: invalid unused variable name: `nodist_scrollbar_SOURCES' demos/Makefile.am:138: invalid unused variable name: `nodist_demotest_SOURCES' demos/Makefile.am:145: invalid unused variable name: `nodist_dirlist_SOURCES' demos/Makefile.am:115: invalid unused variable name: `nodist_buttonall_SOURCES' demos/Makefile.am:106: invalid unused variable name: `AM_LDFLAGS' demos/Makefile.am:119: invalid unused variable name: `nodist_butttypes_SOURCES' done. Building configure... . done. run "./configure ; make" From mheffner at vt.edu Tue Dec 2 19:16:15 2003 From: mheffner at vt.edu (Mike Heffner) Date: Tue, 02 Dec 2003 19:16:15 -0500 (EST) Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <20031119105606.GA1903@astrouw.edu.pl> Message-ID: Michal, Try the attached patch. This appears to work and is much simpler than the current version, but I'll have to look further into the xforms event handling code to see whether this causes a race condition. Anyone know? Mike On 19-Nov-2003 Michal Szymanski wrote: | To subscribers of the xforms list | | | Hi XFormers, | | I'd like to know what the current status of "file selector double-click" | bug is? There were a couple of messages regarding this in May, starting | with a patch proposed by Mike Heffner, but the discussion that followed | raised some doubts. It ended with following message from Mike: | |> However, we still have the same problem that the callback is never |> getting |> a ButtonPress event. ;-( |> |> This weekend I'll try rewriting the file selector's callback using the |> fl_set_browser_dblclick_callback(). It seems that might be a much |> easier |> way of approaching this. | | Mike, did you try the rewrite? | | If no, is Mike's patch included in any (CVS maybe) version of code? | | I have some heavily-used XForms apps dating back to ver. 0.88 and I'd | like very much to rebuild them with 1.0 (also because of problems with | static libraries under RedHat 9) but all users here are quite used to | double-clicking in file selector. The problems started already in 0.89 | and, sadly, have propagated into 1.0. | | regards, Michal. | -- Mike Heffner -------------- next part -------------- --- lib/fselect.c Sat Jun 1 18:09:38 2002 +++ /home/spock/fselect.c Tue Dec 2 19:06:46 2003 @@ -308,24 +308,18 @@ } return 0; } + #else -/* - * A file is selected from the browser. - * generate ready if valid selection (e.g. double-clicked) - * Note that if a call back is defined, never generate ready - */ + static void -select_cb(FL_OBJECT * ob, long arg) +select_cb(FL_OBJECT *ob, long isdblclick) { int dir; char seltext[FL_PATH_MAX]; - static int lastline = -1, clicked; - int dblclick, thisline; + int thisline; FD_fselect *lfs = ob->form->fdui; - const XEvent *xev = fl_last_event(); thisline = fl_get_browser(ob); - if (thisline <= 0) return; @@ -335,31 +329,9 @@ strcpy(seltext, seltext + 2); - dblclick = (lastline == thisline && clicked && - fl_time_passed(FL_FS_T) < ob->click_timeout * 0.001f); - - lastline = thisline; - - clicked = (clicked || xev->type == ButtonPress); - - /* cursor keys can cause a single line being repeatedly selected - causing a wrong dblclick detection */ - - if (clicked) - { - if (xev->type == KeyPress || xev->type == KeyRelease) - { - dblclick = 0; - clicked = 0; - lastline = -1; - } - } - - fl_reset_time(FL_FS_T); - if (dir) { - if (dblclick) + if (isdblclick) { strcat(append_slash(lfs->dname), seltext); fl_fix_dirname(lfs->dname); @@ -374,7 +346,7 @@ fl_set_input(lfs->input, seltext); strcpy(lfs->filename, seltext); - if (dblclick) + if (isdblclick) { if (lfs->fselect_cb) { @@ -385,7 +357,6 @@ fl_object_qenter(lfs->ready); } } - return; } #endif @@ -964,6 +935,7 @@ fs->browser = obj = fl_add_browser(FL_HOLD_BROWSER, 15, 80, 185, 180, ""); #if ATTACHABLE fl_set_object_callback(obj, select_cb, 0); + fl_set_browser_dblclick_callback(obj, select_cb, 1); #endif fl_set_object_gravity(obj, NorthWestGravity, SouthEastGravity); obj->click_timeout = FL_CLICK_TIMEOUT; From Jean-Marc.Lasgouttes at inria.fr Wed Dec 3 06:12:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 03 Dec 2003 12:12:19 +0100 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: (Angus Leeming's message of "Tue, 02 Dec 2003 20:02:26 -0500") References: Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> CVSROOT: /cvsroot/xforms Module name: xforms Branch: Changes Angus> by: Angus Leeming 03/12/02 Angus> 20:02:26 Angus> Modified files: . : ChangeLog demos : Makefile.am lib/include : Angus> Makefile.am Angus> Log message: Some subtle little fixes needed to get things Angus> working on non-gnu platforms. - sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ + sed "1,/crop here for forms/d" ${srcdir}/`basename $$i` >> tmpforms; \ an you explain briefly what this does? JMarc From angus.leeming at btopenworld.com Wed Dec 3 06:25:53 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Dec 2003 11:25:53 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: References: Message-ID: <200312031125.53040.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 11:12 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > Angus> CVSROOT: /cvsroot/xforms Module name: xforms Branch: Changes > Angus> by: Angus Leeming 03/12/02 > Angus> 20:02:26 > > Angus> Modified files: . : ChangeLog demos : Makefile.am lib/include : > Angus> Makefile.am > > Angus> Log message: Some subtle little fixes needed to get things > Angus> working on non-gnu platforms. > > - sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ > + sed "1,/crop here for forms/d" ${srcdir}/`basename $$i` >> tmpforms; \ > > an you explain briefly what this does? You mean the change? I'm trying to overcome a problem compiling with Dec's make and with srcdir != builddir. This snippet in Makefile.am (ie the original snippet): for i in $(noinst_HEADERS); do \ sed "1,/crop here for forms/d" ${srcdir}/$$i >> tmpforms; \ done Is expanded by Dec's make to: for i in ../../../lib/include/Basic.h ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h ../../../lib/include/box.h [snip file list]; do sed "1,/crop here for forms/d" ../../../lib/include/$i >> tmpforms; done sed: Cannot find or open file ../../../lib/include/../../../lib/include/Basic.h. Doing the same thing with gnu make: for i in Basic.h XBasic.h bitmap.h box.h browser.h button.h canvas.h chart.h choice.h clipbd.h clock.h counter.h cursor.h dial.h filesys.h flps.h formbrowser.h frame.h free.h goodies.h input.h menu.h menubar.h popup.h positioner.h scrollbar.h slider.h tabfolder.h text.h thumbwheel.h timer.h xyplot.h zzz.h; do \ sed "1,/crop here for forms/d" ../../../lib/include/$i >> tmpforms; \ done You see the problem? One make gives the files their full path and the other doesn't. The trick, therefore, is to use only the filename part. Any better ideas? Angus From Jean-Marc.Lasgouttes at inria.fr Wed Dec 3 06:41:15 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 03 Dec 2003 12:41:15 +0100 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: <200312031125.53040.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 3 Dec 2003 11:25:53 +0000") References: <200312031125.53040.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> You mean the change? I'm trying to overcome a problem compiling Angus> with Dec's make and with srcdir != builddir. This snippet in Angus> Makefile.am (ie the original snippet): Angus> for i in $(noinst_HEADERS); do \ sed "1,/crop here for Angus> forms/d" ${srcdir}/$$i >> tmpforms; \ done Angus> Is expanded by Dec's make to: Angus> for i in ../../../lib/include/Basic.h Angus> ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h Angus> ../../../lib/include/box.h [snip file list]; do sed "1,/crop Angus> here for forms/d" ../../../lib/include/$i >> tmpforms; done I am surprised, since in my Makefile.in noinst_HEADER is noinst_HEADERS = \ Basic.h \ XBasic.h \ bitmap.h \ box.h \ ... Is it different in the Makefile.in on your dec? This would mean a problem with automake, not with the version of make... JMarc From angus.leeming at btopenworld.com Wed Dec 3 07:01:18 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Dec 2003 12:01:18 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms ./ChangeLog demos/Makefile.am lib/includ... In-Reply-To: References: <200312031125.53040.angus.leeming@btopenworld.com> Message-ID: <200312031201.18373.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 11:41 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> You mean the change? I'm trying to overcome a problem compiling > Angus> with Dec's make and with srcdir != builddir. This snippet in > Angus> Makefile.am (ie the original snippet): > > Angus> for i in $(noinst_HEADERS); do \ sed "1,/crop here for > Angus> forms/d" ${srcdir}/$$i >> tmpforms; \ done > > Angus> Is expanded by Dec's make to: > > Angus> for i in ../../../lib/include/Basic.h > Angus> ../../../lib/include/XBasic.h ../../../lib/include/bitmap.h > Angus> ../../../lib/include/box.h [snip file list]; do sed "1,/crop > Angus> here for forms/d" ../../../lib/include/$i >> tmpforms; done > > I am surprised, since in my Makefile.in noinst_HEADER is > noinst_HEADERS = \ > Basic.h \ > XBasic.h \ > bitmap.h \ > box.h \ > ... > > Is it different in the Makefile.in on your dec? Nope. It's the same (also in Makefile itself). The relevant part of the generated Makefile appears to be: distdir: $(DISTFILES) @list='$(DISTFILES)'; for file in $$list; do \ Ie, the answer lies in the definition of $(DISTFILES) DIST_COMMON = $(noinst_HEADERS) AAA.h.in Makefile.am Makefile.in DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) It appears that Dec make does something weird when expanding $(noinst_HEADERS). Angus k From angus.leeming at btopenworld.com Wed Dec 3 07:38:54 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Dec 2003 12:38:54 +0000 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: Message-ID: <200312031238.54118.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 12:16 am, Mike Heffner wrote: > To subscribers of the xforms list > Try the attached patch. This appears to work and is much > simpler than the current version, but I'll have to look further > into the xforms event handling code to see whether this causes > a race condition. Anyone know? Oohhh! I like this kind of patch ;-) What sort of problems are you tinking about? Angus From mheffner at vt.edu Wed Dec 3 09:45:47 2003 From: mheffner at vt.edu (Mike Heffner) Date: Wed, 03 Dec 2003 09:45:47 -0500 (EST) Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <200312031238.54118.angus.leeming@btopenworld.com> Message-ID: On 03-Dec-2003 Angus Leeming wrote: | | | On Wednesday 03 December 2003 12:16 am, Mike Heffner wrote: | |> Try the attached patch. This appears to work and is much |> simpler than the current version, but I'll have to look further |> into the xforms event handling code to see whether this causes |> a race condition. Anyone know? | | Oohhh! I like this kind of patch ;-) | | What sort of problems are you tinking about? | Well, the patch adds two callbacks for the browser object in the file selector: fl_set_object_callback(obj, select_cb, 0); + fl_set_browser_dblclick_callback(obj, select_cb, 1); On a double click we'll want the first call back (single click) to always be called first, (possibly two times, once for each click), then the double click callback to be called. However, if it happened the other way around it might do something weird like select a file in the list right after moving to a new directory. The question is, is there a race condition here that we should handle better, or just depend on the callback's be called in the correct order? Actually though, now that I look at it more closely, even if the single click callback is called after the double click, it will most likely be invalidated. Once we've double clicked and entered a new directory there shouldn't be anything selected so the test against fl_get_browser()>0 at the beginning of the callback would fail and the callback would do nothing. Mike -- Mike Heffner From joel at fc.hp.com Tue Dec 9 11:52:03 2003 From: joel at fc.hp.com (Joel Lefebvre) Date: Tue, 09 Dec 2003 09:52:03 -0700 Subject: [XForms] savannah down? Message-ID: <3FD5FDB3.2050003@fc.hp.com> I'm trying to get the latest Xforms from savannah.nongnu.org but it seems to be down. Anyone know if savannah is having a problem? Is there an alternate source for Xforms? Thanks Joel -- ------------------------------------------------------------ Joel Lefebvre joel at fc.hp.com Hewlett Packard 970-898-7970 All opinions expressed are my own and do not necessarily represent those of Hewlett Packard. ------------------------------------------------------------ From Jean-Marc.Lasgouttes at inria.fr Wed Dec 10 05:39:18 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 10 Dec 2003 11:39:18 +0100 Subject: [XForms] savannah down? In-Reply-To: <3FD5FDB3.2050003@fc.hp.com> (Joel Lefebvre's message of "Tue, 09 Dec 2003 09:52:03 -0700") References: <3FD5FDB3.2050003@fc.hp.com> Message-ID: >>>>> "Joel" == Joel Lefebvre writes: Joel> To subscribers of the xforms list I'm trying to get the latest Joel> Xforms from savannah.nongnu.org but it seems to be down. Anyone Joel> know if savannah is having a problem? Is there an alternate Joel> source for Xforms? Hello, Savannah has been hacked recently, and the site has been closed until they manage to restore everything: http://savannah.gnu.org/statement.html What version of xforms are you looking for? JMarc From bob at bob.usuhs.mil Thu Jun 12 15:25:54 2003 From: bob at bob.usuhs.mil (Robert Williams) Date: Thu, 12 Jun 2003 15:25:54 -0400 Subject: [XForms] New xforms list server Message-ID: <3EE8D3C2.8050003@bob.usuhs.mil> I've finally moved the xforms list to a fast machine running mailman. There may be a few adjustments that I have to make, but if you recieve this, it appears to work. Bob Williams xforms list maintainer From lahaye at users.sourceforge.net Thu Jun 12 19:56:37 2003 From: lahaye at users.sourceforge.net (Rob Lahaye) Date: Fri, 13 Jun 2003 08:56:37 +0900 Subject: [XForms] Re: New xforms list server In-Reply-To: <3EE8D3C2.8050003@bob.usuhs.mil> References: <3EE8D3C2.8050003@bob.usuhs.mil> Message-ID: <3EE91335.6030403@users.sourceforge.net> Robert Williams wrote: > > To subscribers of the xforms list > > > I've finally moved the xforms list to > a fast machine running mailman. There may > be a few adjustments that I have to make, > but if you recieve this, it appears to work. > > Bob Williams > xforms list maintainer Notice that the 2002 archive still collects current messages; and we are already half way 2003! Can you break it up and add the 2003 messages to a new 2003 tree ? Regards, Rob. From ldm at risc4.numis.nwu.edu Mon Jun 16 09:21:42 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Mon, 16 Jun 2003 08:21:42 -0500 (CDT) Subject: [XForms] Libraries, configure etc Message-ID: Two questions: Do the compiled libraries exist anywhere, or have they now gone. Has anyone converted to Imake structure to a configure (i.e. autoconf/automake) one? I am not that familiar with image, but know that configure can be arranged to determine enough about the system to make compilation seamless. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From angus.leeming at btopenworld.com Mon Jun 16 20:17:39 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 17 Jun 2003 00:17:39 +0000 Subject: [XForms] Libraries, configure etc In-Reply-To: References: Message-ID: <200306170017.39950.angus.leeming@btopenworld.com> On Monday 16 June 2003 11:12 pm, you wrote: > We are about to release some code which uses libforms. > If a tgz file is available with a standard configure, > we can use this otherwise we may need to write our > way around including libforms. Can you make one > available? Why not grab a copy of the cvs repository, following the instructions on the web page I posted to you and thereafter: $ ./autogen.sh $ ./configure your_options $ make dist which should generate your desired tar.gz file. Regards, Angus From nicolas.castagne at imag.fr Wed Jun 18 07:54:15 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Wed, 18 Jun 2003 13:54:15 +0200 Subject: [XForms] Threads and OpenGL --- again ! ;-) Message-ID: <958998B0-A183-11D7-B36A-000393C76CA6@imag.fr> Hi all, I have worked again a bit on a small demo program running a gl CANVAS drawn through a THREAD. You will find attached the sources. ----- I - description of the program The code assumes: 1) that each thread has its own current GLXContext 2) that concurrent calls to glXMakeCurrent and glXSwapBuffer can be made, provided the context used for each one is possessed by the calling thread. The program shows in a form two canvas with a rotating cube. The main process creates and display the form. The "MainCanvas" and its GLXcontext are created by the Main Proces. The "MainCanvas" drawn through an idle callback. The ThreadCanvas is created by the Thread and drawn by it. Its GLXcontext is also created by the thread, through the call to fl_add_object(Form, ThreadCanvas). A communication process ensures that Expose Events on the "ThreadCanvas" (handled by the XForms main loop in the Main Process) are communicated to the Thread. As an evidence, this communication process could be improved. However, it is not the problem today. ----- II - results and problem When rendering is made in DIRECT mode, every thing runs correctly on every SGI engine I was able to test. The call to XinitThread() even does not seem to be necessary. On the contrary, the program ALWAYS CRASHES when rendering is made through the X Server. This happens in two cases: 1) when the constant DIRECT, at the beginning of the sources, is set to 0; 2) when distant execution is performed (direct rendering is then impossible). The error messages I get from the X server are various. Mainly : X Error of failed request: GLXBadContextTag Major opcode of failed request: 146 (GLX) Minor opcode of failed request: 11 (X_GLXSwapBuffers) Serial number of failed request: 667 Current serial number in output stream: 681 or : X Error of failed request: GLXBadContextTag Major opcode of failed request: 146 (GLX) Minor opcode of failed request: 1 (X_GLXRender) Serial number of failed request: 651 Current serial number in output stream: 656 Note that the GLXBadContextTag error is not well documented. As an example, it does not appear in the GL man pages. I don't really understand what it means. ----- II - help ! ;-) I have worked quite a lot around the problem, trying various solutions... But without success. It would be really helpful if one of you could have a look on the problem: Numerous mails concerning threads and GLcanvas have been posted for the past years on the list, but never a definitive answer. As a matter of fact, it could be of interest to : 1) propose a valid small demo program within the XForms examples. 2) by the end, add to the library an API for threaded Gl canvas. I may work on these points... But i need help today ! You may help in different ways : 1) trying to compile and run my program on other platforms, to see what happens; 2) debugging my program, showing what is wrong; 2) sending other pieces of code with threaded Glcanvas that run properly, what ever the rendering mode is, so that I could make the previous jobs on my own. Thx in advance ! Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadGL.c Type: application/applefile Size: 70 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030618/b8eff1b5/attachment-0002.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadGL.c Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030618/b8eff1b5/attachment-0002.c -------------- next part -------------- ------------------------------------------------------------------------ -------------------------- Nicolas CASTAGNE Chercheur, IR de l'ACROE/ICA, Association pour la Cr?ation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Cr?ation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------ -------------------------- From ldm at risc4.numis.nwu.edu Mon Jun 16 19:19:49 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Mon, 16 Jun 2003 18:19:49 -0500 (CDT) Subject: [XForms] Libraries, configure etc In-Reply-To: <200306170017.39950.angus.leeming@btopenworld.com> Message-ID: I will....if I have time before I leave on Saturday to teach at a school in Moscow where I will be using the software On Tue, 17 Jun 2003, Angus Leeming wrote: > On Monday 16 June 2003 11:12 pm, you wrote: > > We are about to release some code which uses libforms. > > If a tgz file is available with a standard configure, > > we can use this otherwise we may need to write our > > way around including libforms. Can you make one > > available? > > Why not grab a copy of the cvs repository, following the instructions on the > web page I posted to you and thereafter: > > $ ./autogen.sh > $ ./configure your_options > $ make dist > > which should generate your desired tar.gz file. > > Regards, > Angus > > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From nicolas.castagne at imag.fr Thu Jun 19 12:05:22 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Thu, 19 Jun 2003 18:05:22 +0200 Subject: [XForms] Formbrowser : adjusting the size of the forms Message-ID: Hy all ! As you know, formbrowsers may need some improvments. For example, an adjustement of the vertical scrollbar (position, size) is needed in case of a call to fl_set_form_size() on one of the forms added to the formbrowser. Does any one actually work on this question ? Shall I have a look on it ? Who could answer to some question I have concerning the best way to solve these problems ? Thx, Nicolas From Mickael.Le.Coz at ifremer.fr Fri Jun 27 04:45:14 2003 From: Mickael.Le.Coz at ifremer.fr (Mickael LE COZ) Date: Fri, 27 Jun 2003 10:45:14 +0200 Subject: [XForms] installation on cygwin emulator Message-ID: <3EFC041A.D4C30C0F@ifremer.fr> Hello, I have untar the "xforms-1.0.tar.gz" file in he X11r6 directory; So when I type ,in the Cygwin/XFree86 rl : xmkmkf >> mv -f Makefile Makefile.bak >>imake -DUseInstalled -I/usr/X11R6/lib/X11/config >>/tmp/IIf.004357:92: unterminated #if conditional >>imake: Exit code 1. >> Stop. and when I type : make Makefiles or make install >>Makefile:11: *** missing operator. Stop Here is the Makefile: # 1 "Imakefile.c" # 1 "/usr/X11R6/lib/X11/config/Imake.tmpl" 1 XCOMM ---------------------------------------------------------------------- XCOMM Makefile generated from "Imake.tmpl" and XCOMM $Xorg: Imake.tmpl,v 1.4 2000/08/17 19:41:46 cpqbld Exp $ XCOMM XCOMM XCOMM XCOMM XCOMM $XFree86: xc/config/cf/Imake.tmpl,v 3.114 2001/11/08 02:09:06 tsi Exp $ XCOMM ---------------------------------------------------------------------- What is the problem? thank you for your help, Micka?l. From nicolas.castagne at imag.fr Fri Jun 27 09:55:13 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 15:55:13 +0200 Subject: [XForms] OpenGL and Threads- again Message-ID: This mail is addressed to those that use OpenGL within XForms. I have had no answer concerning my last message, but I really think the subject of threads and openGL is of interest for the XForms community..... My aim concerning this question is to add a small demo to the XForms demo programs. So, let's play again ! ------- You will find enclosed a short program which implements a GLCanvas drawn by a thread. This program is stable with direct rendering. However, it is not stable on my IRIX system in case of rendering through the X sever, especially in case of a distant execution. -> Could some of you try to compile this program and run it locally and on a distant machine ? 10 min. work ! ------- The next part of the message is addressed to those who have successfully implemented a GLCanvas drawn by a thread. Did you tried non-direct rendering on these canvas ? If it runs properly, it would be very helpful if you could have a look to my code and give advices ! Thx , Nicolas From nicolas.castagne at imag.fr Fri Jun 27 10:36:55 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 16:36:55 +0200 Subject: [XForms] OpenGL and Threads- again In-Reply-To: Message-ID: Sure it is better with the attachement... Thx for testing ! Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: ThreadGL.c Type: application/applefile Size: 70 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030627/30e85acb/attachment-0002.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ThreadGL.c Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030627/30e85acb/attachment-0002.c -------------- next part -------------- Le vendredi, 27 jun 2003, ? 15:55 Europe/Paris, Nicolas Castagn? a ?crit : > To subscribers of the xforms list > > > This mail is addressed to those that use OpenGL within XForms. > > I have had no answer concerning my last message, but I really think > the subject of threads and openGL is of interest for the XForms > community..... > My aim concerning this question is to add a small demo to the XForms > demo programs. > > So, let's play again ! > > ------- > > You will find enclosed a short program which implements a GLCanvas > drawn by a thread. > > This program is stable with direct rendering. However, it is not > stable on my IRIX system in case of rendering through the X sever, > especially in case of a distant execution. > > -> Could some of you try to compile this program and run it locally > and on a distant machine ? 10 min. work ! > > ------- > > The next part of the message is addressed to those who have > successfully implemented a GLCanvas drawn by a thread. > > Did you tried non-direct rendering on these canvas ? > If it runs properly, it would be very helpful if you could have a > look to my code and give advices ! > > > Thx , > > Nicolas > > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > From Jean-Marc.Lasgouttes at inria.fr Fri Jun 27 10:46:14 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 27 Jun 2003 16:46:14 +0200 Subject: [XForms] installation on cygwin emulator In-Reply-To: <3EFC041A.D4C30C0F@ifremer.fr> (Mickael LE's message of "Fri, 27 Jun 2003 10:45:14 +0200") References: <3EFC041A.D4C30C0F@ifremer.fr> Message-ID: >>>>> "Mickael" == Mickael LE COZ writes: Mickael> To subscribers of the xforms list Hello, Mickael> I have untar the "xforms-1.0.tar.gz" file in he X11r6 Mickael> directory; So when I type ,in the Cygwin/XFree86 rl : xmkmkf Did you try 'xmkmf -a'? JMarc From nicolas.castagne at imag.fr Fri Jun 27 14:57:00 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Fri, 27 Jun 2003 20:57:00 +0200 Subject: Fwd: [XForms] OpenGL and Threads- again Message-ID: <220DA38B-A8D1-11D7-8814-000393C76CA6@imag.fr> Hi all, Thx for trying David. I decided to fwd your mail on the mail list (see below), since it may be of interest for other. The behaviour you obtained is somehow the one I get on octane - appart the fact SGi octane is a bit slower ;-) The questions then are : 1) is multithreading correctly supported by OpenGL in case of non-direct rendering ? 2) if so, where is the fault in my program ? Wish some of you may answer ! Once again, I would ask those who have already implemented a 'multithreaded' GL canvas under XForms to test their program with non-direct rendering (Canvas's direct field set to 0 or distant execution). Thx, Nicolas D?but du message r?exp?di? : > De: David Scriven > Date: Ven 27 jun 2003 20:42:26 Europe/Paris > ?: "Nicolas_Castagn?" > Objet: R?p : [XForms] OpenGL and Threads- again > > Hi Nicolas, > > I tried your program on a platform running RedHat 9 with XFree86 4.3.0 > on an NVIDIA Ti 4200 (NVIDIA supply their own drivers and GL libraries) > > 1. With DIRECT = 1 the program ran fine although the rate in the > left hand window was so fast that the cube was blurred. The rate > in the right window was much slower. > > 2. With DIRECT = 0 the program still worked, BUT, the program would > not respond to the buttons once Go! was pressed and the cube on > the right did not move. In addition, when I covered and then uncovered > the window, the right hand screen was not redrawn (ie it remained > black). In addition I got messages like: > Xlib: unexpected async reply (sequence 0x288ad)! > > 3,. In light of the above I didn't try remote execution. > > I compiled the program with > > gcc ThreadGL.c -o ThreadGL -I /usr/X11R6/include -O2 -L/usr/X11R6/lib > -lforms -lformsGL -lpthread -lGL -lGLU > > using gcc ver 3.2.2 > > I'll try and look through your code this weekend if I get a chance. > > DS > > : > To subscribers of the xforms list >> >> >> This mail is addressed to those that use OpenGL within XForms. >> >> I have had no answer concerning my last message, but I really think >> the subject of threads and openGL is of interest for the XForms >> community..... >> My aim concerning this question is to add a small demo to the XForms >> >> demo programs. >> >> So, let's play again ! >> >> ------- >> >> You will find enclosed a short program which implements a GLCanvas >> drawn by a thread. >> >> This program is stable with direct rendering. However, it is not >> stable on my IRIX system in case of rendering through the X sever, >> especially in case of a distant execution. >> >> -> Could some of you try to compile this program and run it locally >> and on a distant machine ? 10 min. work ! >> >> ------- >> >> The next part of the message is addressed to those who have >> successfully implemented a GLCanvas drawn by a thread. >> >> Did you tried non-direct rendering on these canvas ? >> If it runs properly, it would be very helpful if you could have a >> look >> to my code and give advices ! >> >> >> Thx , >> >> Nicolas >> >> >> _______________________________________________ >> To unsubscribe, send the message "unsubscribe" to >> xforms-request at bob.usuhs.mil or see: >> http://cweblog.usuhs.mil/mailman/listinfo/xforms >> XForms Home Page: http://world.std.com/~xforms >> List Archive: http://bob.usuhs.mil/pipermail/xforms and >> http://bob.usuhs.mil/mailserv/list-archives/ >> Development: http://savannah.nongnu.org/files/?group=xforms > > ______________________________________________________________________ > Post your free ad now! http://personals.yahoo.ca > From ddembrow at nlxcorp.com Mon Jun 30 15:43:39 2003 From: ddembrow at nlxcorp.com (ddembrow at nlxcorp.com) Date: Mon, 30 Jun 2003 15:43:39 -0400 Subject: [XForms] Next xforms release inquiry Message-ID: Are there any plans to release another version of xforms including the latest modifications as a stable release beyond 1.0 rc5? From Jean-Marc.Lasgouttes at inria.fr Tue Jul 1 04:24:21 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 01 Jul 2003 10:24:21 +0200 Subject: [XForms] Next xforms release inquiry In-Reply-To: (ddembrow@nlxcorp.com's message of "Mon, 30 Jun 2003 15:43:39 -0400") References: Message-ID: >>>>> "ddembrow" == ddembrow writes: ddembrow> Are there any plans to ddembrow> release another version of xforms including the latest ddembrow> modifications as a stable release beyond 1.0 rc5? The latest released version is actually 1.0, available here https://savannah.nongnu.org/files/?group=xforms In the cvs available from there https://savannah.nongnu.org/cvs/?group=xforms you will find what is going to become 1.1.0. It contains several bug fixes, and support for autoconf-based build. This is the part that is not finished yet. Hope this helps. JMarc From davidwriter at yahoo.com Sun Jul 6 17:00:08 2003 From: davidwriter at yahoo.com (David Scriven) Date: Sun, 6 Jul 2003 17:00:08 -0400 (EDT) Subject: [XForms] Timing in XForms In-Reply-To: <200306070213.h572D0004065@pc18.math.umbc.edu> Message-ID: <20030706210008.99028.qmail@web41213.mail.yahoo.com> When XForms was originally developed, in the mid 1980's, machines were much slower than they are today, so I suspect the designers had to make a compromise between CPU cycles and response. In XForms there are two critical values that are set : TIMER_RES, which is 50 ms (and can be partly reset by fl_set_idle_delta), and the number of FL_STEP events that are swallowed before the system responds (l 1977-78 of forms.c) /* Handle FL_STEP. Every 10 events. This will reduce cpu usage */ if ((++auto_cnt % 10) == 0) This latter statement clearly will slow down the way in which XForms responds and probably explains the effect I have noticed on my machines; that XForms programs speed up when the mouse is moved. My query is whether the settings in XForms are appropriate to today's fast machines and whether these settings could be dynamically changed to suit the machine that XForms is running on. What I would have in mind is a routine inside fl_initialize that detects the real clock precision and clock speed and sets the values for TIMER_RES, and steps swallowed, dynamically. XForms is extremely complex and such changes might have unforseen side effects (T.C., your comments?), but I think it might be worth thinking about. DS ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From jac at casurgica.com Thu Jul 10 23:33:25 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Thu, 10 Jul 2003 23:33:25 -0400 (EDT) Subject: [XForms] fl_get_object_component In-Reply-To: <20030706210008.99028.qmail@web41213.mail.yahoo.com> References: <200306070213.h572D0004065@pc18.math.umbc.edu> <20030706210008.99028.qmail@web41213.mail.yahoo.com> Message-ID: <39941.69.3.42.242.1057894405@sun-qmail17.laserlink.net> Does anybody know where I can find a list of all the objects that have component objects that can be retrieved with fl_get_object_component(), and of what those component objects are? J. Cipriani From jac at casurgica.com Fri Jul 11 21:48:00 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Fri, 11 Jul 2003 21:48:00 -0400 (EDT) Subject: [XForms] A tip for using secret inputs. In-Reply-To: <20030706210008.99028.qmail@web41213.mail.yahoo.com> References: <200306070213.h572D0004065@pc18.math.umbc.edu> <20030706210008.99028.qmail@web41213.mail.yahoo.com> Message-ID: <46119.69.3.42.242.1057974480@sun-qmail12.laserlink.net> The SECRET_INPUT is completely unusable. However, you can turn a NORMAL_INPUT into somewhat of a secret input box like so: fl_set_input_color(MyInput, MyInput->col2, MyCaretColor); Where "MyInput" is your NORMAL_INPUT (an FL_OBJEC T*), and MyCaretColor is whatever color you want the caret to be. It makes the text "invisible" by setting the text color to the input's background color. It makes the highlight invisible, too, though, but its still better than the SECRET_INPUT. I only tried that on a form with one input box, though, so the text might become visible when the box loses focus. I dunno. J. Cipriani From rostamian at umbc.edu Sat Jul 12 11:33:00 2003 From: rostamian at umbc.edu (Rouben Rostamian) Date: Sat, 12 Jul 2003 11:33:00 -0400 Subject: [XForms] question about resizing forms Message-ID: <200307121533.h6CFX0jO005951@pc18.math.umbc.edu> I want to set up a form which can be resized only in discrete steps. E.g., in interactive resizing, the form's width and height may only change in multiples of 10 pixels. How do I do this in xforms? -- Rouben Rostamian From jac at casurgica.com Fri Jul 18 11:56:06 2003 From: jac at casurgica.com (jac at casurgica.com) Date: Fri, 18 Jul 2003 11:56:06 -0400 (EDT) Subject: [XForms] BUGFIX: Tab control fixed, working secret inputs, fixed focus and resize problems, etc, etc... Message-ID: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Use GTK. From drriddle at qwest.net Fri Jul 18 20:09:33 2003 From: drriddle at qwest.net (Reed Riddle) Date: Fri, 18 Jul 2003 19:09:33 -0500 Subject: [XForms] BUGFIX: Tab control fixed, working secret inputs, fixed focus and resize problems, etc, etc... In-Reply-To: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Message-ID: <467B5611-B97D-11D7-AB01-003065E23D38@qwest.net> On Friday, July 18, 2003, at 10:56 AM, jac at casurgica.com wrote: > To subscribers of the xforms list > > > Use GTK. Awww, but that would be like giving up! :) When I started building my application, I looked at GTK. It didn't look like it had a plotting element nearly as flexible as the xyplot that Xforms has (and I even had to add a small patch to that to do what I wanted). I also could understand the callback code much better; the GTK interface builder put all kinds of crap in there, while it hardly took me any time at all to figure out Xforms. Oh, and I had never built a GUI before. It's possible that GTK is better now, and that it might be easy for me to switch my code over, but why go to all the trouble when what I have now works well enough? Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From Jean-Marc.Lasgouttes at inria.fr Thu Jul 31 12:24:54 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 31 Jul 2003 18:24:54 +0200 Subject: [XForms] [PATCH] simplifying local.h: the trivial bits Message-ID: A non-text attachment was scrubbed... Name: local.diff Type: text/x-patch Size: 5836 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/fb6de625/attachment-0002.bin From Jean-Marc.Lasgouttes at inria.fr Thu Jul 31 12:36:28 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 31 Jul 2003 18:36:28 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200307311732.59411.leeming@lyx.org> (Angus Leeming's message of "Thu, 31 Jul 2003 17:32:59 +0000") References: <200307311732.59411.leeming@lyx.org> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Thursday 31 July 2003 4:24 pm, Jean-Marc Lasgouttes wrote: >> The attached patch does the easy part in the job of getting rid of >> local.h. Angus, could you please double check that it makes sense >> and apply? >> >> In what remains, there are checks for xenix, vms, lynx and sunos 4. >> I'd be happy to get rid of those. From what I can see, only sunos4 >> had a xforms 0.89 build, so the others would not be missed (I could >> not even find xenix). >> >> Thoughts? Angus> Fantastic effort. The logic here seems to be inverted though. Angus> Am I right? Yes, it should be #ifdef HAVE_USLEEP also, there is a problem with line 83 of signal.c, where dec cc does not like my code. I have to leave now, I'll have a look tomorrow. JMarc From angus.leeming at btopenworld.com Thu Jul 31 13:38:41 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 31 Jul 2003 17:38:41 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: Message-ID: <200307311732.59411.leeming@lyx.org> On Thursday 31 July 2003 4:24 pm, Jean-Marc Lasgouttes wrote: > The attached patch does the easy part in the job of getting rid of > local.h. Angus, could you please double check that it makes sense and > apply? > > In what remains, there are checks for xenix, vms, lynx and sunos 4. > I'd be happy to get rid of those. From what I can see, only sunos4 had > a xforms 0.89 build, so the others would not be missed (I could not > even find xenix). > > Thoughts? Fantastic effort. The logic here seems to be inverted though. Am I right? -#if !defined(DONT_HAVE_USLEEP) +#if !defined(HAVE_USLEEP) Angus From myaconis at nycap.rr.com Thu Jul 31 11:49:00 2003 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Thu, 31 Jul 2003 11:49:00 -0400 Subject: [XForms] Form imaging problems References: <43270.69.3.42.242.1058543766@sun-qmail17.laserlink.net> Message-ID: <006301c3577b$499ebe80$6501a8c0@dimensionxp> For some reason the first time I display a form it doesn't image properly. The attached images show what it looks like. The window consists of approximately 50 forms, a main form, a scrollable form, and 40+ row forms whos objects are added to the scrollable form which is then attached to the main form via a form browser. Any suggestions or help would be much appreciated. (The good.png image shows how the form should look. The bad.png image shows how it looks when it is first displayed.) -------------- next part -------------- A non-text attachment was scrubbed... Name: bad.png Type: image/png Size: 20311 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/ae087b2f/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: good.png Type: image/png Size: 25480 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030731/ae087b2f/attachment-0005.png From drriddle at qwest.net Thu Jul 31 22:20:45 2003 From: drriddle at qwest.net (Reed Riddle) Date: Thu, 31 Jul 2003 21:20:45 -0500 Subject: [XForms] Form imaging problems In-Reply-To: <006301c3577b$499ebe80$6501a8c0@dimensionxp> Message-ID: Try freezing the form, then building it, filling in the data, etc, and then unfreeze the form when everything is loaded. I see this sometimes, but that's usually before I get around to adding the freezing/unfreezing cycle when I do something to the form. Reed On Thursday, July 31, 2003, at 10:49 AM, Matthew Yaconis wrote: > To subscribers of the xforms list > > > For some reason the first time I display a form it doesn't image > properly. > The attached images show what it looks like. The window consists of > approximately 50 forms, a main form, a scrollable form, and 40+ row > forms > whos objects are added to the scrollable form which is then attached > to the > main form via a form browser. > > Any suggestions or help would be much appreciated. (The good.png image > shows how the form should look. The bad.png image shows how it looks > when > it is first displayed.) > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From myaconis at nycap.rr.com Fri Aug 1 10:22:04 2003 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Fri, 1 Aug 2003 10:22:04 -0400 Subject: [XForms] Odd menu field behavior Message-ID: <004401c35838$491d5da0$6501a8c0@dimensionxp> I have a menu object that I generate an FL_PUP_ENTRY structure for from data retrieved from a mysql database. I don't do anything particularly special with this menu object but for some reason the fl_get_menu function returns a "0" (zero) randomly when selections are made off of the list. Does anyone have any idea why fl_get_menu might return a 0 when called within the object's callback routine? The callback routine goes like this: ... callback_routine (...) { choice = fl_get_menu( ob ); ... generic_routine_for_handling(ob, ...); } The generic_routine_for_handling also calls fl_get_menu. Thanks for the help on the last question as well! From eisfuchs at tigress.com Fri Aug 1 11:15:45 2003 From: eisfuchs at tigress.com (Eisfuchs) Date: Fri, 1 Aug 2003 17:15:45 +0200 Subject: [XForms] Unsubscribe and help not working Message-ID: <200308011715.45725.eisfuchs@tigress.com> Hi! I'm trying to unsubscribe from the list but everytime I get errors back. I send an eMail with Subject: unsubscribe and empty body or unsubscribe in the body. Even the help command does not work. Can someone help me? > The original message was received at Fri, 1 Aug 2003 11:01:01 -0400 > from mail.yatho.de [213.200.97.76] > > ----- The following addresses had permanent fatal errors ----- > "|/var/mailman//mail/mailman mailcmd xforms" > (reason: 6) > (expanded from: ) > > ----- Transcript of session follows ----- > Illegal command: mailcmd > 554 5.3.0 unknown mailer error 6 Final-Recipient: RFC822; xforms-request at bob.usuhs.mil X-Actual-Recipient: X-Unix; |/var/mailman//mail/mailman mailcmd xforms Action: failed Status: 5.0.0 Diagnostic-Code: X-Unix; 6 Last-Attempt-Date: Fri, 1 Aug 2003 11:14:46 -0400 -- Eisfuchs, from Germany. From angus.leeming at btopenworld.com Fri Aug 1 12:37:01 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 1 Aug 2003 16:37:01 +0000 Subject: [XForms] Unsubscribe and help not working In-Reply-To: <200308011715.45725.eisfuchs@tigress.com> References: <200308011715.45725.eisfuchs@tigress.com> Message-ID: <200308011637.01891.angus.leeming@btopenworld.com> On Friday 01 August 2003 3:15 pm, Eisfuchs wrote: > To subscribers of the xforms list > > > Hi! > > I'm trying to unsubscribe from the list but everytime I get errors back. > I send an eMail with Subject: unsubscribe and empty body or unsubscribe in > the body. Even the help command does not work. Can someone help me? And what happens if you follow the prescription in the footer to this mail? [snip] To unsubscribe, send the message "unsubscribe" to xforms-request at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms Angus From angus.leeming at btopenworld.com Wed Aug 6 13:53:22 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 6 Aug 2003 17:53:22 +0000 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: <200308061753.22818.angus.leeming@btopenworld.com> On Wednesday 06 August 2003 4:01 pm, L. D. Marks wrote: > In browser.h the definitions: > > FL_EXPORT void fl_set_browser_vscrollbar( > FL_OBJECT *ob, > int on > ); > > FL_EXPORT void fl_set_browser_hscrollbar( > FL_OBJECT *ob, > int on > ); > > are incompatible with at least some C++ where "on" > is predefined. Ouch! Your compiler is brain dead. What are you using? Does it have any other problems with the library? Regards, Angus From angus.leeming at btopenworld.com Thu Aug 7 05:35:20 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 7 Aug 2003 09:35:20 +0000 Subject: [XForms] Libraries: broken libtool.m4 In-Reply-To: References: Message-ID: <200308070935.20490.angus.leeming@btopenworld.com> On Wednesday 06 August 2003 10:59 pm, L. D. Marks wrote: > The version of libtool.m4 that you have in acinclude.m4 > appears to be broken on an HPUX 10.20 (works under linux); > after removing it the standard version picked up by > autoconf/automake & friends works fine. Hi, Laurence. Could you tell us what version of autoconf/automake you are using? From psg at debian.org Tue Sep 2 15:28:31 2003 From: psg at debian.org (Peter S Galbraith) Date: Tue, 02 Sep 2003 15:28:31 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030411130538.61277.qmail@web13403.mail.yahoo.com> References: <20030411130538.61277.qmail@web13403.mail.yahoo.com> Message-ID: <20030902192832.F003738F37@mixing.qc.dfo.ca> T.C. Zhao wrote: > All I need to do is boot up my old linux box and recover the doc and send it. > Will do this sometime in April (I've been travelling, and am sending this > email from Tokyo). > -TC Hi T.C., I really hate to keep nagging you like this. :-) You meant to release the sources of the XForms manual last April but never got around to it. This is a reminder. Also, please avoid using the GNU Free Documentation License (GFDL) since it not a free software license and therefore cannot be included in the Debian distribution. Using the GPL would be fine. I'm writing now because while the Debian GNU/Linux distribution doesn't make a release as often as it should, a freeze is due shortly for a Christmas release. The current packaging of the XForms manual has this license: No part of this document may be reproduced, in any form or by any means, without permission from the authors. Permission to produce hardcopies in its entirety for private use is granted. This lacks the permission to us to _distribute_ the manual so I'll pull the package from Debian's non-free archive soon, before the upcoming release. But instead of removing the package, it would be great to get the manual sources under a free license and move the package to Debian's main archive. Hopefully you will find time to do this. Otherwise I can always re-create the Debian package at a later time when it is released under a free license. Thanks for your time! -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From ldm at risc4.numis.nwu.edu Wed Aug 6 12:02:02 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 06 Aug 2003 16:02:02 -0000 Subject: [XForms] Libraries: small C++ bug In-Reply-To: <200306170017.39950.angus.leeming@btopenworld.com> Message-ID: In browser.h the definitions: FL_EXPORT void fl_set_browser_vscrollbar( FL_OBJECT *ob, int on ); FL_EXPORT void fl_set_browser_hscrollbar( FL_OBJECT *ob, int on ); are incompatible with at least some C++ where "on" is predefined. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From ldm at risc4.numis.nwu.edu Wed Aug 6 19:00:25 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 06 Aug 2003 23:00:25 -0000 Subject: [XForms] Libraries: broken libtool.m4 In-Reply-To: Message-ID: The version of libtool.m4 that you have in acinclude.m4 appears to be broken on an HPUX 10.20 (works under linux); after removing it the standard version picked up by autoconf/automake & friends works fine. ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From Jean-Marc.Lasgouttes at inria.fr Wed Sep 3 12:37:01 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 03 Sep 2003 18:37:01 +0200 Subject: [XForms] Re: xforms configuration In-Reply-To: <200309031619.56049.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 3 Sep 2003 16:19:56 +0000") References: <200309031619.56049.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs Angus> and has made some changes, attached. Below is his summary of Angus> what he's done, but I think it can be simply summarised as Angus> Why do we ship these files in the config directory: Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh Angus> They are all parts of the autoconf/libtool code. Why not allow Angus> the user to use the versions that come with their versions of Angus> the autotools? Because a user of xforms is not required to have any of the autotools installed (unless when using cvs, of course). I think that we have to ship all these files, except possibly libtools.m4. However, I think that we must sync this file with ltmain.sh, so even this one is needed. The right thing to do is to upgrade libtool files to the latest version (our libtool.m5 is from 2001, it seems). The choice is libtool 1.4.2 from october 2002 or 1.5 from last month. I do not know whether 1.5 can cause problems. depcomp comes probably with automake, and the config.* from autoconf. All we have to do is upgrade from recent versions. Angus> 1) Removed the "on", since it does not seem to be needed. This is of course a solution, but how does 'on' appear on this system? Is this a preprocessor define in some system header? This would be _very_ bad... Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems. Fine, we probably do not need this one. But I do not think it makes any difference, since we do not rely anywhere on the HAVE_MALLOC macro. Laurence, did it really cause a problem? Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the Angus> version I was using it was not being set. I'll have to check this one. Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and Angus> let automake/autoconf/libtool handle all this. Your version did Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5 I think we should just upgrade the versions we have (after making sure that libtool 1.5 requirements are not too high). Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" Probably OK. Angus> 6) Added a few files needed by make dist (e.g. README, I can't Angus> remember them all). Good idea. Angus> 7) I also did some stuff for our own purposes, primarily Angus> removed pixmap.c so no extra libraries are needed and removed Angus> the checks for them, turned off sharing by default, restricted Angus> the build/dist to the library and removed some of your Angus> informational output at the end of the build. FYI, it works Angus> fine, and is setup so our code will compile forms if it does Angus> not find a working copy already existing on the computer. This should be investigated... Thanks for the input Laurence. JMarc From angus.leeming at btopenworld.com Wed Sep 3 12:19:56 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 3 Sep 2003 16:19:56 +0000 Subject: [XForms] xforms configuration Message-ID: <200309031619.56049.angus.leeming@btopenworld.com> Jean-Marc, Laurence Marks has been trying to compile xforms cvs and has made some changes, attached. Below is his summary of what he's done, but I think it can be simply summarised as Why do we ship these files in the config directory: config.guess config.sub depcomp libtool.m4 ltmain.sh They are all parts of the autoconf/libtool code. Why not allow the user to use the versions that come with their versions of the autotools? Angus Laurence's 'ChangeLog' follows: I did quite a few additional hacks on your configure, testing it on HP,SGI,SUN,cgwin with both native & gcc compilers. The major changes are (I think): 1) Removed the "on", since it does not seem to be needed. 2) Removed AC_FUNC_MALLOC since it is broken on many systems. 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the version I was using it was not being set. 4) Removed the libtool stuff that you had in acinclude.m4, and let automake/autoconf/libtool handle all this. Your version did not work with automake-1.7, autoconf-2.57, libtool-1.5 5) Added (slight overkill, but AC_PATH_XTRA does not work the way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" 6) Added a few files needed by make dist (e.g. README, I can't remember them all). 7) I also did some stuff for our own purposes, primarily removed pixmap.c so no extra libraries are needed and removed the checks for them, turned off sharing by default, restricted the build/dist to the library and removed some of your informational output at the end of the build. FYI, it works fine, and is setup so our code will compile forms if it does not find a working copy already existing on the computer. -------------- next part -------------- A non-text attachment was scrubbed... Name: marks.diff.gz Type: application/x-gzip Size: 49844 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030903/84e1704e/attachment-0002.gz From larsbj at lyx.org Wed Sep 3 17:44:50 2003 From: larsbj at lyx.org (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: Wed, 03 Sep 2003 23:44:50 +0200 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: "L. D. Marks" writes: | To subscribers of the xforms list > > | In browser.h the definitions: > | FL_EXPORT void fl_set_browser_vscrollbar( | FL_OBJECT *ob, | int on | ); > | FL_EXPORT void fl_set_browser_hscrollbar( | FL_OBJECT *ob, | int on | ); > | are incompatible with at least some C++ where "on" | is predefined. Predefined as what? This is certainly not Standard C++. Can you should where/how you get that error? (and the error itself) -- Lgb From larsbj at lyx.org Wed Sep 3 18:53:03 2003 From: larsbj at lyx.org (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: Thu, 04 Sep 2003 00:53:03 +0200 Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: "L. D. Marks" writes: | I did a little more checking, and it looks like our code was defining | "on" itself, and since this was in an include that came before forms.h | this created problems. (We probably should not be using "on" - maybe | you might want to think about "forms_on" to be more robust. The | earlier forms header files did not have the "on" defined.) What stops you from polluting the global namespace with a macro/define called forms_on? (and using forms_on in xforms give away the wrong meaning of the parameter... and removing it from the function declaration makes it impossible to see what this int is) It is your code that is in error, not xforms. -- Lgb From Holly.Yeh at grc.nasa.gov Thu Sep 4 10:53:32 2003 From: Holly.Yeh at grc.nasa.gov (Holly Yeh) Date: Thu, 04 Sep 2003 10:53:32 -0400 Subject: [XForms] Making XForms Multi-Threaded Message-ID: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> Hi, We are planning on making XForms multi-threaded. If anyone has any planning or been working on the issue, Please let us know. Thank you very much! Holly Yeh. From angus.leeming at btopenworld.com Thu Sep 4 12:08:46 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 4 Sep 2003 16:08:46 +0000 Subject: [XForms] Making XForms Multi-Threaded In-Reply-To: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> Message-ID: <200309041608.46270.angus.leeming@btopenworld.com> On Thursday 04 September 2003 2:53 pm, Holly Yeh wrote: > To subscribers of the xforms list > > > Hi, > We are planning on making XForms multi-threaded. If anyone has any > planning or been working on the issue, Please let us know. > Thank you very much! > > Holly Yeh. Hello, Holly. that sounds great. However, I wonder if you might not find FLTK (Fast Light ToolKit http://www.fltk.org) fits your needs already. Yeah, yeah, I know. I'm the guy fronting xforms, not fltk. Nonetheless, and without wanting to appear disloyal to xforms, FLTK has an active developer community (which IMO counts for a lot), it has multithreaded support already and, perhaps most importantly, it has an xforms -> fltk converter so porting your app might well be painless. http://www.fltk.org/documentation.php/doc-1.1/forms.html#15_1 Kind regards, Angus From ldm at risc4.numis.nwu.edu Wed Sep 3 12:45:22 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 3 Sep 2003 11:45:22 -0500 (CDT) Subject: [XForms] Re: xforms configuration In-Reply-To: Message-ID: On Wed, 3 Sep 2003, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> Jean-Marc, Laurence Marks has been trying to compile xforms cvs > Angus> and has made some changes, attached. Below is his summary of > Angus> what he's done, but I think it can be simply summarised as > > Angus> Why do we ship these files in the config directory: > Angus> config.guess config.sub depcomp libtool.m4 ltmain.sh > > Angus> They are all parts of the autoconf/libtool code. Why not allow > Angus> the user to use the versions that come with their versions of > Angus> the autotools? > > Because a user of xforms is not required to have any of the autotools > installed (unless when using cvs, of course). > > I think that we have to ship all these files, except possibly > libtools.m4. However, I think that we must sync this file with > ltmain.sh, so even this one is needed. > > The right thing to do is to upgrade libtool files to the latest > version (our libtool.m5 is from 2001, it seems). The choice is libtool > 1.4.2 from october 2002 or 1.5 from last month. I do not know whether > 1.5 can cause problems. In the version that was in the cvs, the libtool stuff was in acinclude.m4 so cancelled my more current version of libtool etc. I removed it from acinclude.m4 -- you do need to ship a viable version. > > depcomp comes probably with automake, and the config.* from autoconf. > All we have to do is upgrade from recent versions. > > Angus> 1) Removed the "on", since it does not seem to be needed. > > This is of course a solution, but how does 'on' appear on this system? > Is this a preprocessor define in some system header? This would be > _very_ bad... If I remember right, "on" was defined in g++. The header was fine with gcc, died with g++. > > Angus> 2) Removed AC_FUNC_MALLOC since it is broken on many systems. > > Fine, we probably do not need this one. But I do not think it makes > any difference, since we do not rely anywhere on the HAVE_MALLOC > macro. Laurence, did it really cause a problem? Yes. If it did not find a GNU malloc it redefined it to rpl_malloc and you then had to link this in otherwise you would have an undefined symbol. > > Angus> 3) Added in acinclude.m4 ac_save_CFLAGS=$CFLAGS At least in the > Angus> version I was using it was not being set. > > I'll have to check this one. > > Angus> 4) Removed the libtool stuff that you had in acinclude.m4, and > Angus> let automake/autoconf/libtool handle all this. Your version did > Angus> not work with automake-1.7, autoconf-2.57, libtool-1.5 > > I think we should just upgrade the versions we have (after making sure > that libtool 1.5 requirements are not too high). > > Angus> 5) Added (slight overkill, but AC_PATH_XTRA does not work the > Angus> way it claims to!) AC_SUBST(X_LIBS) AC_SUBST(X_PRE_LIBS) > Angus> AC_SUBST(X_CFLAGS) LIBS="$X_LIBS $X_PRE_LIBS -lX11 > Angus> $X_EXTRA_LIBS $LIBS" CPPFLAGS="$X_CFLAGS $CPPFLAGS" > > Probably OK. > > Angus> 6) Added a few files needed by make dist (e.g. README, I can't > Angus> remember them all). > > Good idea. > > Angus> 7) I also did some stuff for our own purposes, primarily > Angus> removed pixmap.c so no extra libraries are needed and removed > Angus> the checks for them, turned off sharing by default, restricted > Angus> the build/dist to the library and removed some of your > Angus> informational output at the end of the build. FYI, it works > Angus> fine, and is setup so our code will compile forms if it does > Angus> not find a working copy already existing on the computer. > > This should be investigated... > > Thanks for the input Laurence. > > JMarc > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From ldm at risc4.numis.nwu.edu Wed Sep 3 18:33:20 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Wed, 3 Sep 2003 17:33:20 -0500 (CDT) Subject: [XForms] Libraries: small C++ bug In-Reply-To: Message-ID: I did a little more checking, and it looks like our code was defining "on" itself, and since this was in an include that came before forms.h this created problems. (We probably should not be using "on" - maybe you might want to think about "forms_on" to be more robust. The earlier forms header files did not have the "on" defined.) On Wed, 3 Sep 2003, [iso-8859-1] Lars Gullik Bj?nnes wrote: > "L. D. Marks" writes: > > | To subscribers of the xforms list > > > > > | In browser.h the definitions: > > > | FL_EXPORT void fl_set_browser_vscrollbar( > | FL_OBJECT *ob, > | int on > | ); > > > | FL_EXPORT void fl_set_browser_hscrollbar( > | FL_OBJECT *ob, > | int on > | ); > > > | are incompatible with at least some C++ where "on" > | is predefined. > > Predefined as what? > This is certainly not Standard C++. > > Can you should where/how you get that error? > (and the error itself) > > -- > Lgb > ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From jac4 at andrew.cmu.edu Wed Sep 3 23:39:03 2003 From: jac4 at andrew.cmu.edu (jason) Date: Wed, 3 Sep 2003 23:39:03 -0400 (EDT) Subject: [XForms] Libraries: small C++ bug In-Reply-To: References: Message-ID: > | I did a little more checking, and it looks like our code was defining > | "on" itself, and since this was in an include that came before forms.h > | this created problems. (We probably should not be using "on" - maybe > | you might want to think about "forms_on" to be more robust. The > | earlier forms header files did not have the "on" defined.) > > What stops you from polluting the global namespace with a macro/define > called forms_on? (and using forms_on in xforms give away the wrong > meaning of the parameter... and removing it from the function > declaration makes it impossible to see what this int is) > > It is your code that is in error, not xforms. Yeah I'm going to have to agree with him on that one. There is no "on" in any of the standard C++ headers, afaik. Additionally, having a macro defined as "on" is not specific to C++... things could be messed up the same way if everything was in C. From angus.leeming at btopenworld.com Thu Sep 4 13:57:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 4 Sep 2003 17:57:02 +0000 Subject: [XForms] Making XForms Multi-Threaded In-Reply-To: <5.1.1.5.2.20030904124900.01884068@popserve.grc.nasa.gov> References: <5.1.1.5.2.20030904101229.01880be8@popserve.grc.nasa.gov> <5.1.1.5.2.20030904124900.01884068@popserve.grc.nasa.gov> Message-ID: <200309041757.02703.angus.leeming@btopenworld.com> On Thursday 04 September 2003 4:50 pm, Holly Yeh wrote: > Hi Angus, > Thank you for your input, Is fltk supported on tru64 Unix? > > Holly Yeh. I don't know, Holly. I've never used it in anger. But it's open source, has mailing lists of its own and took about 5 mins to compile the source. I don't suppose it'd take long for you to try it out, now would it? Comes with lots of documentation and test programs too... Best regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Sep 5 09:44:29 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 05 Sep 2003 15:44:29 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: (Jean-Marc Lasgouttes's message of "Thu, 31 Jul 2003 18:36:28 +0200") References: <200307311732.59411.leeming@lyx.org> Message-ID: A non-text attachment was scrubbed... Name: local2.diff Type: text/x-patch Size: 7382 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030905/44db0cb7/attachment-0002.bin From tc_zhao at yahoo.com Mon Sep 8 11:48:38 2003 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Mon, 8 Sep 2003 08:48:38 -0700 (PDT) Subject: [XForms] Re: XForms: Documentation In-Reply-To: <20030902192832.F003738F37@mixing.qc.dfo.ca> Message-ID: <20030908154838.51918.qmail@web13407.mail.yahoo.com> Sorry for the delay and thanks for the info. GPL it is. I am currently travelling and will be back home end of September. Expect the free manual in October sometime. -TC --- Peter S Galbraith wrote: > To subscribers of the xforms list > > > T.C. Zhao wrote: > > > All I need to do is boot up my old linux box and recover the doc and send > it. > > Will do this sometime in April (I've been travelling, and am sending this > > email from Tokyo). > > -TC > > Hi T.C., > > I really hate to keep nagging you like this. :-) > > You meant to release the sources of the XForms manual last April but > never got around to it. This is a reminder. Also, please avoid using > the GNU Free Documentation License (GFDL) since it not a free software > license and therefore cannot be included in the Debian distribution. > Using the GPL would be fine. > > I'm writing now because while the Debian GNU/Linux distribution doesn't > make a release as often as it should, a freeze is due shortly for a > Christmas release. The current packaging of the XForms manual has this > license: > > No part of this document may be reproduced, in any form or by any > means, without permission from the authors. Permission to produce > hardcopies in its entirety for private use is granted. > > This lacks the permission to us to _distribute_ the manual so I'll pull > the package from Debian's non-free archive soon, before the upcoming > release. But instead of removing the package, it would be great to get > the manual sources under a free license and move the package to Debian's > main archive. Hopefully you will find time to do this. Otherwise I can > always re-create the Debian package at a later time when it is released > under a free license. > > Thanks for your time! > -- > Peter S. Galbraith, Debian Developer > http://people.debian.org/~psg > GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From psg at debian.org Mon Sep 8 11:57:53 2003 From: psg at debian.org (Peter S Galbraith) Date: Mon, 08 Sep 2003 11:57:53 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030908154838.51918.qmail@web13407.mail.yahoo.com> References: <20030908154838.51918.qmail@web13407.mail.yahoo.com> Message-ID: <20030908155753.3FB3238F7E@mixing.qc.dfo.ca> T.C. Zhao wrote: > > Sorry for the delay and thanks for the info. GPL it is. > > I am currently travelling and will be back home end of September. Expect the > free manual in October sometime. > > -TC Thanks TC! Would you also mind replying to this message (and CC the mailing list for the public record) and give permission to Debian to distribute the current version of the manual in its non-free archive and mirrors, e.g. http://packages.debian.org/unstable/doc/libforms-doc.html This would gives us the required permission not present in the current license. Thanks again! -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From angus.leeming at btopenworld.com Mon Sep 8 21:04:13 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 01:04:13 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: Message-ID: <200309090051.14280.leeming@lyx.org> On Friday 05 September 2003 1:44 pm, Jean-Marc Lasgouttes wrote: > Angus> Fantastic effort. The logic here seems to be inverted though. > Angus> Am I right? > > Jean-Marc> Yes, it should be #ifdef HAVE_USLEEP > > Jean-Marc> also, there is a problem with line 83 of signal.c, where > Jean-Marc> dec cc does not like my code. I have to leave now, I'll > Jean-Marc> have a look tomorrow. > > I finally finished this a bit and added a few things. Angus, could you > commit this after review? > > JMarc Many thaks for doing this Jean-Marc. It is now committed. Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 05:18:41 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 11:18:41 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309090051.14280.leeming@lyx.org> (Angus Leeming's message of "Tue, 9 Sep 2003 01:04:13 +0000") References: <200309090051.14280.leeming@lyx.org> Message-ID: A non-text attachment was scrubbed... Name: chglog.diff Type: text/x-patch Size: 1075 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/51b7308c/attachment-0002.bin From angus.leeming at btopenworld.com Tue Sep 9 06:43:05 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 10:43:05 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: <200309090051.14280.leeming@lyx.org> Message-ID: <200309091043.05489.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: JMarc> Angus> Many thaks for doing this Jean-Marc. It is now committed. Angus JMarc> You forgot the Changelog entry. No I didn't, but I'll admit that my subsequent commit with a date of 23 May is confusing (and wrong). I've fixed that. Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 06:16:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 12:16:19 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309091043.05489.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 10:43:05 +0000") References: <200309090051.14280.leeming@lyx.org> <200309091043.05489.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: JMarc> Angus> Many thaks for doing this Jean-Marc. It is now JMarc> committed. Angus You forgot the Changelog entry. Angus> No I didn't, but I'll admit that my subsequent commit with a Angus> date of 23 May is confusing (and wrong). I've fixed that. You're right, it is cvs update that got confused actually. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 06:47:37 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 12:47:37 +0200 Subject: [XForms] [PATCH] Enable optional building of demos/ directory Message-ID: A non-text attachment was scrubbed... Name: demos.diff Type: text/x-patch Size: 2257 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/2173d3a5/attachment-0002.bin From angus.leeming at btopenworld.com Tue Sep 9 08:46:50 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 12:46:50 +0000 Subject: [XForms] Re: [PATCH] Enable optional building of demos/ directory In-Reply-To: References: Message-ID: <200309091246.50358.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 10:47 am, Jean-Marc Lasgouttes wrote: > The following patch adds an --enable-demos flag to configure > > Angus, please apply if it works OK for you. Oh, JMarc, you beauty! Angus From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 08:22:32 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 14:22:32 +0200 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: <200309091245.11255.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 12:45:11 +0000") References: <200309091043.05489.angus.leeming@btopenworld.com> <200309091245.11255.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Let's try and make a road plan for a 1.1 release. I guess we Angus> should address the problems with the autotools that Laurence Angus> Marks described. Yes. I have not looked at that seriously yet. One thing I noticed is that we lack an INSTALL file (to be taken from autoconf). The file Copyright should maybe be included in some other file (and the reference to COPYING changed to COPYING.LIB). The copyrights should be changed to include at least you (and me) (also in lib/version.c). Angus> Here I have Red Hat 8 which comes with automake 1.6.3, autoconf Angus> 2.53 and libtool 1.4.2. We should probably pick something newer... Angus> I find that if I remove depcomp and the config.*, then Angus> automake, autoconf shove in new versions. Great. However, if I Angus> remove libtool.m4 and run libtoolize, I do do not get a new Angus> version of libtool.m4. I guess, therefore that it is no longer Angus> needed? The libtool documentation says: When you invoke the libtoolize program (see section 5.4.1 Invoking libtoolize), it will tell you where to find a definition of AC_PROG_LIBTOOL. If you use Automake, the aclocal program will automatically add AC_PROG_LIBTOOL support to your configure script. Nevertheless, it is advisable to include a copy of `libtool.m4' in `acinclude.m4', so that, even if `aclocal.m4' and `configure' are rebuilt for any reason, the appropriate libtool macros will be used. The alternative is to hope the user will have a compatible version of `libtool.m4' installed and accessible for aclocal. This may lead to weird errors when versions don't match. So we should keep a libtool.m4. Angus> Here is the patch. Wa d'ya think? Angus I'd say let's refine it a bit first. Angus> NB, reading on the web, it appears that others have added Angus> libtoolize to autogen.sh Angus> http://mail.gnome.org/archives/gtk-devel-list/2002-September/msg00015.html If you look at the autoconf repository, you will even find out that the have special makefile targets to update all these files automatically from the gnu ftp site. I am not sure whether we want to go to such extreme methods, though. JMarc From tc_zhao at yahoo.com Tue Sep 9 10:07:59 2003 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Tue, 9 Sep 2003 07:07:59 -0700 (PDT) Subject: [XForms] Re: XForms: Documentation In-Reply-To: <20030908155753.3FB3238F7E@mixing.qc.dfo.ca> Message-ID: <20030909140759.33379.qmail@web13406.mail.yahoo.com> Hi Peter, Please feel free to include the current manual in the Debian distribution. For the public record, I am granting the rights to all linux distributors to distribute all versions of xforms manual without fee in all electronic formats (.tex,.psf, .ps, .html) with the requirement that the distributed versions retain the copyright notice and version number. -TC --- Peter S Galbraith wrote: > T.C. Zhao wrote: > > > > > Sorry for the delay and thanks for the info. GPL it is. > > > > I am currently travelling and will be back home end of September. Expect > the > > free manual in October sometime. > > > > -TC > > Thanks TC! > > Would you also mind replying to this message (and CC the mailing list > for the public record) and give permission to Debian to distribute the > current version of the manual in its non-free archive and mirrors, e.g. > > http://packages.debian.org/unstable/doc/libforms-doc.html > > This would gives us the required permission not present in the current > license. > > Thanks again! > -- > Peter S. Galbraith, Debian Developer > http://people.debian.org/~psg > GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From psg at debian.org Tue Sep 9 10:21:36 2003 From: psg at debian.org (Peter S Galbraith) Date: Tue, 09 Sep 2003 10:21:36 -0400 Subject: [XForms] Re: XForms: Documentation In-Reply-To: Message from "T.C. Zhao" <20030909140759.33379.qmail@web13406.mail.yahoo.com> References: <20030909140759.33379.qmail@web13406.mail.yahoo.com> Message-ID: <20030909142136.C3CEB39205@mixing.qc.dfo.ca> T.C. Zhao wrote: > Hi Peter, > > Please feel free to include the current manual in the Debian distribution. > > For the public record, I am granting the rights to all linux distributors to > distribute all versions of xforms manual without fee in all electronic > formats (.tex,.psf, .ps, .html) with the requirement that the distributed > versions retain the copyright notice and version number. > > -TC Many thanks T.C. ! This is exactly what I needed until the free release. :-) Peter -- Peter S. Galbraith, Debian Developer http://people.debian.org/~psg GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E From Jean-Marc.Lasgouttes at inria.fr Tue Sep 9 11:02:53 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 09 Sep 2003 17:02:53 +0200 Subject: [XForms] [PATCH] Simplify configure.ac Message-ID: A non-text attachment was scrubbed... Name: conf.diff Type: text/x-patch Size: 3945 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/0a0cb9c4/attachment-0002.bin From angus.leeming at btopenworld.com Tue Sep 9 13:16:10 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 17:16:10 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: References: Message-ID: <200309091716.10189.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 3:02 pm, Jean-Marc Lasgouttes wrote: > The following patch removes tests that are as far as I can see not > used. I tried to check carefully what the side effects of the various > autoconf macros are. The idea is to keep all tests that already exist > in some form in xforms 1.0. > Angus, please double check and apply (note that the ChangeLog chunk > will not apply after my other patch, since this is against unpatched > HEAD; I'll redo the patch if there is a problem). Well, it works for me it all looks reasonable and, as I think of you as the whizz in these things anyway, that's good enough for me. I applied it. Many thanks. > Something that still has to be done is implement --disable-gl to avoid > building libformsGL when not relevant. It should not be too difficult > to make a test to autodetect this. Good idea. Actually, shouldn't that be --enable-gl (defaults to 'no'), identical to you little test for --enable-demos? Of course, it would actually do some testing if the answer were 'yes'. Angus From wd4nmq at comcast.net Tue Sep 9 14:49:22 2003 From: wd4nmq at comcast.net (Jeff Pierce) Date: Tue, 09 Sep 2003 14:49:22 -0400 Subject: [XForms] Windows with transparent background and no border. Message-ID: <3F5E20B2.6030502@comcast.net> Is it possible at all under X windows to have a non-rectangular window like under MS Windows? The call under MS is AddRectToRgn(). Where you have a mask that is treated like chroma mixing, ie green screen, in movies/tv. Then the portions of the underlying desktop will show through and key presses in those areas will not go to the app, but to whatever is underneath it. I know that xfornms does not support this. But, does anybody knoe of a way to do it using any other X frameworks? -- Jeff, wd4nmq wd4nmq at comcast.net http://mywebpages.comcast.net/wd4nmq From Jean-Marc.Lasgouttes at inria.fr Wed Sep 10 08:56:25 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 10 Sep 2003 14:56:25 +0200 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <200309091716.10189.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 9 Sep 2003 17:16:10 +0000") References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: gl.diff Type: text/x-patch Size: 2739 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030910/58819f35/attachment-0002.bin From angus.leeming at btopenworld.com Tue Sep 9 08:45:11 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 9 Sep 2003 12:45:11 +0000 Subject: [XForms] Re: [PATCH] simplifying local.h: the trivial bits In-Reply-To: References: <200309091043.05489.angus.leeming@btopenworld.com> Message-ID: <200309091245.11255.angus.leeming@btopenworld.com> On Tuesday 09 September 2003 10:16 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > Angus> To subscribers of the xforms list > Angus> On Tuesday 09 September 2003 9:18 am, Jean-Marc Lasgouttes wrote: > JMarc> Angus> Many thaks for doing this Jean-Marc. It is now > JMarc> committed. Angus You forgot the Changelog entry. > > Angus> No I didn't, but I'll admit that my subsequent commit with a > Angus> date of 23 May is confusing (and wrong). I've fixed that. > > You're right, it is cvs update that got confused actually. Let's try and make a road plan for a 1.1 release. I guess we should address the problems with the autotools that Laurence Marks described. > The right thing to do is to upgrade libtool files to the latest > version (our libtool.m5 is from 2001, it seems). The choice is libtool > 1.4.2 from october 2002 or 1.5 from last month. I do not know whether > 1.5 can cause problems. > depcomp comes probably with automake, and the config.* from autoconf. > All we have to do is upgrade from recent versions. Here I have Red Hat 8 which comes with automake 1.6.3, autoconf 2.53 and libtool 1.4.2. I find that if I remove depcomp and the config.*, then automake, autoconf shove in new versions. Great. However, if I remove libtool.m4 and run libtoolize, I do do not get a new version of libtool.m4. I guess, therefore that it is no longer needed? Certainly, I can confirm that everything works for me. Here is the patch. Wa d'ya think? Angus NB, reading on the web, it appears that others have added libtoolize to autogen.sh http://mail.gnome.org/archives/gtk-devel-list/2002-September/msg00015.html Should we do so? -------------- next part -------------- A non-text attachment was scrubbed... Name: updatetools.diff.bz2 Type: application/x-bzip2 Size: 42918 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20030909/4721bc35/attachment-0002.bz2 From angus.leeming at btopenworld.com Wed Sep 10 12:56:42 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 16:56:42 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: <200309101656.42201.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 12:56 pm, Jean-Marc Lasgouttes wrote: > >> Something that still has to be done is implement --disable-gl to > >> avoid building libformsGL when not relevant. It should not be too > >> difficult to make a test to autodetect this. > > Angus> Good idea. Actually, shouldn't that be --enable-gl (defaults to > Angus> 'no'), identical to you little test for --enable-demos? Of > Angus> course, it would actually do some testing if the answer were > Angus> 'yes'. > > See attached patch. The code only builds the gl/ subdir if GL/glx.h is > found. You can add an explicit --disable-gl to avoid building. > > I also simplified the code for --enable-demos. Thanks for this. > BTW, what should we do about the xforms rpm? Building it with gl > support would mean that applications like LyX would depend on GL > support, which is stupid. An alternative would be to make separate > xforms and xforms-gl rpms, but this is a bit heavy IMO. Heavy or not, it is the right thing to do. In fact, being brutal about this, we should have separate rpms for each library, xforms, xforms-image and xforms-gl. Moreover, fdesign and fd2ps are developer tools. They should go, therefore, in the xforms-devel rpm. Angus From psg at debian.org Wed Sep 10 13:02:48 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:02:48 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Jean-Marc Lasgouttes References: <200309091716.10189.angus.leeming@btopenworld.com> Message-ID: <20030910170249.0137A38F37@mixing.qc.dfo.ca> Jean-Marc Lasgouttes wrote: > support would mean that applications like LyX would depend on GL > support, which is stupid. An alternative would be to make separate > xforms and xforms-gl rpms, but this is a bit heavy IMO. This is what I do for Debian anyway: http://packages.debian.org/unstable/libs/libforms1.html http://packages.debian.org/unstable/libs/libformsgl1.html http://packages.debian.org/unstable/libdevel/libforms-dev.html http://packages.debian.org/unstable/devel/libformsgl-dev.html http://packages.debian.org/unstable/devel/libforms-bin.html Peter From angus.leeming at btopenworld.com Wed Sep 10 14:09:03 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:09:03 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910170249.0137A38F37@mixing.qc.dfo.ca> References: <20030910170249.0137A38F37@mixing.qc.dfo.ca> Message-ID: <200309101809.03546.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:02 pm, Peter S Galbraith wrote: > To subscribers of the xforms list > > Jean-Marc Lasgouttes wrote: > > support would mean that applications like LyX would depend on GL > > support, which is stupid. An alternative would be to make separate > > xforms and xforms-gl rpms, but this is a bit heavy IMO. > > This is what I do for Debian anyway: > > http://packages.debian.org/unstable/libs/libforms1.html > http://packages.debian.org/unstable/libs/libformsgl1.html > http://packages.debian.org/unstable/libdevel/libforms-dev.html > http://packages.debian.org/unstable/devel/libformsgl-dev.html > http://packages.debian.org/unstable/devel/libforms-bin.html Any reason why you don't split up xforms and xforms-image? Is making dep packages automatically just a case of adding the correct Makefile target and leaving the computer to do its stuff? If so, feel free to submit a patch. Angus From psg at debian.org Wed Sep 10 13:25:38 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:25:38 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Angus Leeming <200309101809.03546.angus.leeming@btopenworld.com> References: <20030910170249.0137A38F37@mixing.qc.dfo.ca> <200309101809.03546.angus.leeming@btopenworld.com> Message-ID: <20030910172538.4755438F37@mixing.qc.dfo.ca> Angus Leeming wrote: > On Wednesday 10 September 2003 5:02 pm, Peter S Galbraith wrote: > > To subscribers of the xforms list > > > > Jean-Marc Lasgouttes wrote: > > > support would mean that applications like LyX would depend on GL > > > support, which is stupid. An alternative would be to make separate > > > xforms and xforms-gl rpms, but this is a bit heavy IMO. > > > > This is what I do for Debian anyway: > > > > http://packages.debian.org/unstable/libs/libforms1.html > > http://packages.debian.org/unstable/libs/libformsgl1.html > > http://packages.debian.org/unstable/libdevel/libforms-dev.html > > http://packages.debian.org/unstable/devel/libformsgl-dev.html > > http://packages.debian.org/unstable/devel/libforms-bin.html > > Any reason why you don't split up xforms and xforms-image? Only because the image library didn't cause the added depencies to be too onerous. Most users already have installed the packages for libjpeg, libtiff and libXpm. OpenGL is another story, so I bundled it separately. > Is making dep packages automatically just a case of adding the correct > Makefile target and leaving the computer to do its stuff? If so, feel > free to submit a patch. Making Debian packages involves a debian/ directory. See http://ftp.debian.org/debian/pool/main/libf/libforms1/libforms1_1.0-4.diff.gz for what I add/change from the original tar ball. It's not a huge deal for me to keep this separate and apply it after your release, and I suppose having an outdated debian directory can sometimes cause problems. I include it in CVS for projects that I'm heavily involved with (gri and MH-E) and have CVS access, and don't do it in the majority of my packages (because I don't track CVS as much as would be required). Making the actual packages also involves doing it on a Debian system, of course, since specific tools are required to calculate dependencies and certain helper packages are invoked. Peter From psg at debian.org Wed Sep 10 13:38:27 2003 From: psg at debian.org (Peter S Galbraith) Date: Wed, 10 Sep 2003 13:38:27 -0400 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: Message from Angus Leeming <200309101834.25195.angus.leeming@btopenworld.com> References: <200309101809.03546.angus.leeming@btopenworld.com> <20030910172538.4755438F37@mixing.qc.dfo.ca> <200309101834.25195.angus.leeming@btopenworld.com> Message-ID: <20030910173827.8971A38F37@mixing.qc.dfo.ca> Angus Leeming wrote: > On Wednesday 10 September 2003 5:25 pm, Peter S Galbraith wrote: > > Making Debian packages involves a debian/ directory. See > > http://ftp.debian.org/d[snip...]/libforms1_1.0-4.diff.gz > > Cool! I didn't know you'd done that! I'll have a look at some stage. You didn't know is was packaged? > > Making the actual packages also involves doing it on a Debian system, > > of course, since specific tools are required to calculate dependencies > > and certain helper packages are invoked. > > Sure. But then that is true also of rpmdist. Yeah, I added that as an afterthought. It did seem fairly obvious. I just wanted to make sure. :-) Peter From angus.leeming at btopenworld.com Wed Sep 10 14:34:25 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:34:25 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910172538.4755438F37@mixing.qc.dfo.ca> References: <200309101809.03546.angus.leeming@btopenworld.com> <20030910172538.4755438F37@mixing.qc.dfo.ca> Message-ID: <200309101834.25195.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:25 pm, Peter S Galbraith wrote: > Making Debian packages involves a debian/ directory. See > http://ftp.debian.org/d[snip...]/libforms1_1.0-4.diff.gz Cool! I didn't know you'd done that! I'll have a look at some stage. > Making the actual packages also involves doing it on a Debian system, > of course, since specific tools are required to calculate dependencies > and certain helper packages are invoked. Sure. But then that is true also of rpmdist. This is from Makefile.am in the top level dir. rpmdist: dist if [ -z "`type -path rpmbuild`" ]; \ then \ RPMBUILD=rpm; \ else \ RPMBUILD=rpmbuild; \ fi; $$RPMBUILD -ta $(PACKAGE)-$(VERSION).tar.gz ; saved_status=$$?; \ exit $$saved_status Regards, Angus From angus.leeming at btopenworld.com Wed Sep 10 14:44:23 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 10 Sep 2003 18:44:23 +0000 Subject: [XForms] Re: [PATCH] Simplify configure.ac In-Reply-To: <20030910173827.8971A38F37@mixing.qc.dfo.ca> References: <200309101834.25195.angus.leeming@btopenworld.com> <20030910173827.8971A38F37@mixing.qc.dfo.ca> Message-ID: <200309101844.23539.angus.leeming@btopenworld.com> On Wednesday 10 September 2003 5:38 pm, Peter S Galbraith wrote: > You didn't know is was packaged? Let's just say that my ignorance is boundless. Angus From vs85 at cornell.edu Mon Sep 15 17:11:38 2003 From: vs85 at cornell.edu (Veera) Date: Mon, 15 Sep 2003 17:11:38 -0400 Subject: [XForms] XForms installation Message-ID: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> Hi, I have some problems when i was trying to install xforms on cygwin(latest version 1.5.4 with XFREE86). First I unzipped the xforms.1.0.tar file. then typed xmkmf -a. This command went through well. After that when i typed 'make' the program stops and gives this error message: make[1]: *** No rule to make target `../lib/libforms.a', needed by `fd2ps.exe'. Stop. make[1]: Leaving directory `/usr/x11r6/xforms-1.0/fd2ps' make: *** [all] Error 2 I have already installed the xpm library. Is it a problem due to bad xpm installation? I tried installing the binary version bxforms.089. Again the demos don't run and it gives an fl_initialise error (unable to open). Can someone please tell me the steps for installing xforms on cygwin and making the demos work. thanks Veera From angus.leeming at btopenworld.com Tue Sep 16 05:01:13 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 16 Sep 2003 09:01:13 +0000 Subject: [XForms] XForms installation In-Reply-To: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> References: <5.0.0.25.0.20030915165844.00a5a200@postoffice9.mail.cornell.edu> Message-ID: <200309160901.13982.angus.leeming@btopenworld.com> On Monday 15 September 2003 9:11 pm, Veera wrote: > Hi, > > I have some problems when i was trying to install xforms on cygwin(latest > version 1.5.4 with XFREE86). First I unzipped the xforms.1.0.tar file. then > typed xmkmf -a. This command went through well. After that when i typed > 'make' the program stops and gives this error message: > > make[1]: *** No rule to make target `../lib/libforms.a', needed by > `fd2ps.exe'. Stop. > make[1]: Leaving directory `/usr/x11r6/xforms-1.0/fd2ps' > make: *** [all] Error 2 > > Can someone please tell me the steps for installing xforms on cygwin and > making the demos work. This is going to sound kludgy, but... Go into the lib subdirectory and type $ make $ make install (as root) Thereafter, fd2ps should be able to find the libforms.a/.so files fine when you return to the top level directory and type $ make Alternatively, and perhaps less kludgily, set your LD_LIBRARY_PATH variable to include the path to the generated libforms.a/.so files. Angus From ldm at risc4.numis.nwu.edu Tue Sep 23 20:21:32 2003 From: ldm at risc4.numis.nwu.edu (L. D. Marks) Date: Tue, 23 Sep 2003 19:21:32 -0500 (CDT) Subject: [XForms] Redhat 9.0 libforms.a incompatibility Message-ID: I just upgraded my system to Redhat 9.0, and it appears that there are some incompatibilties between the include file definitions (in my version anyway) and the version of libforms.a that they are shipping. (I deleted their version and just installed one I compiled, but you might want to decide how to deal with this in a general way.) ----------------------------------------------- Laurence Marks Department of Materials Science and Engineering MSE Rm 2036 Cook Hall 2225 N Campus Drive Northwestern University Evanston, IL 60201, USA Tel: (847) 491-3996 Fax: (847) 491-7820 mailto:ldm at risc4.numis.nwu.edu http://www.numis.nwu.edu ----------------------------------------------- From davidwriter at yahoo.com Wed Sep 24 14:25:50 2003 From: davidwriter at yahoo.com (David Scriven) Date: Wed, 24 Sep 2003 14:25:50 -0400 (EDT) Subject: [XForms] Redhat 9.0 libforms.a incompatibility In-Reply-To: Message-ID: <20030924182550.70945.qmail@web41214.mail.yahoo.com> As far as I know Red Hat has not shipped xforms since version 7.2. The problems that you were having with the (presumably old) libforms.a are not unique to xforms. Static linking was changed in RH 9 and most old archives had to be recompiled otherwise you get errors. You can check the archive of this list to see what the errors were. DS --- "L. D. Marks" wrote: > To subscribers of the xforms list > > > I just upgraded my system to Redhat 9.0, and it appears > that there are some incompatibilties between the include > file definitions (in my version anyway) and the version > of libforms.a that they are shipping. (I deleted their > version and just installed one I compiled, but you might > want to decide how to deal with this in a general > way.) > > ----------------------------------------------- > Laurence Marks > Department of Materials Science and Engineering > MSE Rm 2036 Cook Hall > 2225 N Campus Drive > Northwestern University > Evanston, IL 60201, USA > Tel: (847) 491-3996 Fax: (847) 491-7820 > mailto:ldm at risc4.numis.nwu.edu > http://www.numis.nwu.edu > ----------------------------------------------- > > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From dstrang at chartermi.net Fri Oct 3 04:07:50 2003 From: dstrang at chartermi.net (David Strang) Date: Fri, 3 Oct 2003 04:07:50 -0400 Subject: [XForms] Hello - Just a test. Message-ID: <000901c38985$7055e940$6401a8c0@athlon> Hello. Regards, Dave Strang From angus.leeming at btopenworld.com Fri Oct 3 05:45:54 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 3 Oct 2003 09:45:54 +0000 Subject: [XForms] Hello - Just a test. In-Reply-To: <000901c38985$7055e940$6401a8c0@athlon> References: <000901c38985$7055e940$6401a8c0@athlon> Message-ID: <200310030945.54699.angus.leeming@btopenworld.com> On Friday 03 October 2003 8:07 am, David Strang wrote: > Hello. Hello, David. Quiet here, isn't it? Angus From ddembrow at nlxcorp.com Fri Oct 3 05:40:59 2003 From: ddembrow at nlxcorp.com (ddembrow at nlxcorp.com) Date: Fri, 3 Oct 2003 05:40:59 -0400 Subject: [XForms] xforms patch Message-ID: I have attached diff patch files for fselect.c and tabfolder.c source. Could a developer look at what is changed, and add it to the development Xforms source? The fselect_patch allows for a borderless form. This allows the use of the file selector goodie in an application which uses nothing but fixed size/borderless forms. The tabfolder_patch corrects the form position when using bottom tab folders. Without the patch the form selected with a bottom tab is place below the tab - for a full screen display the form simply disappears out of the viewing area. Thanks, ---d.dembrow NLX Corporation Phone: (703) 234-2100 FAX: (703) 234-2101 email: ddembrow at nlxcorp.com (See attached file: fselect_patch)(See attached file: tabfolder_patch) -------------- next part -------------- A non-text attachment was scrubbed... Name: fselect_patch Type: application/octet-stream Size: 288 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031003/ad06a891/attachment-0004.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: tabfolder_patch Type: application/octet-stream Size: 737 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031003/ad06a891/attachment-0005.obj From angus.leeming at btopenworld.com Fri Oct 3 07:08:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 3 Oct 2003 11:08:26 +0000 Subject: [XForms] xforms patch In-Reply-To: References: Message-ID: <200310031108.26360.angus.leeming@btopenworld.com> On Friday 03 October 2003 9:40 am, ddembrow at nlxcorp.com wrote: > I have attached diff patch files for fselect.c and tabfolder.c source. > Could a developer look at what is changed, and add it to the > development Xforms source? Many thanks for this. > The fselect_patch allows for a borderless form. This allows the > use of the file selector goodie in an application which uses nothing > but fixed size/borderless forms. The restriction does seem entirely arbitrary. I'll apply this one happily. > The tabfolder_patch corrects the form position when usingbottom > tab folders. Without the patch the form selected with a bottom tab > is place below the tab - for a full screen display the form simply > disappears out of the viewing area. Excellent. I'll apply this too. Incidentally, what's your name? Adding this to the ChangeLog seems a little impersonal ;-) 2003-10-03 * lib/fselect.c: remove the arbitrary restriction on the display of borderless forms. * lib/tabfolder.c: display the tab forms correctly when using bottom tab folders. From dstrang at chartermi.net Fri Oct 3 14:32:11 2003 From: dstrang at chartermi.net (David Strang) Date: Fri, 3 Oct 2003 14:32:11 -0400 Subject: [XForms] Looking for advice Message-ID: <001101c389dc$a8fa6b20$6401a8c0@athlon> I have been a original Forms user for about ten years with an SGI. The Xforms libraries seem to be the logical extension for Xwindows. Though I am not new to Linux, getting Xforms to build under Linux has been troublesome for me and obtaining proper information even more so. Could I get some advice on what version of Linux (Redhat x.x/Mandrake x.x/etc.) best supports what version of Xforms. I tried Redhat 9.0 and got all kind of errors due to the new gcc compiler (3.2) and Mandrake 9.0 supplied the base libraries which I installed but couldn't get the source tools built. How do I get a fully working Xforms environment ? Regards, Dave Strang dstrang at chartermi.net From GalbraithP at dfo-mpo.gc.ca Fri Oct 3 14:40:06 2003 From: GalbraithP at dfo-mpo.gc.ca (Peter S Galbraith) Date: Fri, 03 Oct 2003 14:40:06 -0400 Subject: [XForms] Looking for advice In-Reply-To: Message from "David Strang" <001101c389dc$a8fa6b20$6401a8c0@athlon> References: <001101c389dc$a8fa6b20$6401a8c0@athlon> Message-ID: <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> David Strang wrote: > Though I am not new to Linux, getting Xforms to build under Linux has > been troublesome for me and obtaining proper information even more so. > > Could I get some advice on what version of Linux (Redhat x.x/Mandrake > x.x/etc.) best supports > what version of Xforms. I tried Redhat 9.0 and got all kind of errors due to > the new gcc compiler (3.2) > and Mandrake 9.0 supplied the base libraries which I installed but couldn't > get the source tools built. > > How do I get a fully working Xforms environment ? It's packaged under Debian if that helps. You could install Debian via Knoppix and then install XForms from Debian. Peter From angus.leeming at btopenworld.com Sat Oct 4 13:20:39 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 4 Oct 2003 17:20:39 +0000 Subject: [XForms] Looking for advice In-Reply-To: <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> References: <001101c389dc$a8fa6b20$6401a8c0@athlon> <20031003184006.A6F54DA5C8@mixing.qc.dfo.ca> Message-ID: <200310041720.39284.angus.leeming@btopenworld.com> On Friday 03 October 2003 6:40 pm, Peter S Galbraith wrote: > > How do I get a fully working Xforms environment ? > > It's packaged under Debian if that helps. You could install Debian via > Knoppix and then install XForms from Debian. There are also rpms available at ftp://ftp.lyx.org/pub/lyx/contrib/libforms-devel-1.0-release.i386.rpm ftp://ftp.lyx.org/pub/lyx/contrib/libforms-1.0-release.i386.rpm Angus From hiller at mpia-hd.mpg.de Fri Oct 10 09:41:41 2003 From: hiller at mpia-hd.mpg.de (Ulrich Hiller) Date: Fri, 10 Oct 2003 15:41:41 +0200 (MET DST) Subject: [XForms] problems installing on solaris Message-ID: <200310101341.h9ADffR02830@mpisrv.mpia-hd.mpg.de> Hello, we want to install xforms 1.0 on sun sloaris 7 and solaris 9. It fails during the make procedure with the following error message: rm -f libflimage.so.1.0~ LD_RUN_PATH=/systools/misc/xforms/lib /usr/ccs/bin/ld -o libflimage.so.1.0~ -G - z text -M mapfile -h libflimage.so.1.0 image.o image_bmp.o image_combine.o im age_convolve.o image_crop.o image_disp.o image_fits.o image_genesis.o image _gif.o image_gzip.o image_io_filter.o image_jpeg.o image_jquant.o image_mar ker.o image_png.o image_pnm.o image_postscript.o image_proc.o image_replace .o image_rotate.o image_scale.o image_sgi.o image_text.o image_tiff.o imag e_type.o image_warp.o image_xbm.o image_xpm.o image_xwd.o postscript.o ps_ core.o ps_draw.o ps_text.o rgb_db.o matrix.o -L/systools/misc/xforms/lib -l Xext -lX11 -L/usr/local/lib -L../lib -lforms -L/systools/lib -ljpeg -L/systo ols/lib -ltiff Text relocation remains referenced against symbol offset in file 0x28 image_png.o 0x30 image_png.o 0x34 image_png.o 0x38 image_png.o 0x4 image.o [........here are many lines of the same kind..............] jpeg_destroy_compress 0x2b8 image_jpeg.o jpeg_CreateCompress 0x88 image_jpeg.o jpeg_stdio_dest 0x98 image_jpeg.o jpeg_set_defaults 0xf0 image_jpeg.o jpeg_set_quality 0x108 image_jpeg.o jpeg_write_marker 0x140 image_jpeg.o jpeg_write_scanlines 0x284 image_jpeg.o jpeg_finish_compress 0x2a0 image_jpeg.o ld: fatal: relocations remain against allocatable but non-writable sections *** Error code 1 make: Fatal error: Command failed for target `libflimage.so.1.0' Current working directory /disk-b/hiller/xforms-1.0/image making all in ./fdesign... rm -f fdesign LD_RUN_PATH=/systools/misc/xforms/lib cc -o fdesign -g -Xc -xF -xcg92 -L/sys tools/misc/xforms/lib fd_attribs.o fd_control.o fd_fake.o fd_file.o fd_forms .o fd_groups.o fd_help.o fd_initforms.o fd_main.o fd_names.o fd_objects.o fd_pallette.o fd_printC.o fd_rubber.o fd_select.o fd_spec.o fd_super.o fd _util.o sp_browser.o sp_button.o sp_choice.o sp_counter.o sp_dial.o sp_fre eobj.o sp_menu.o sp_pixmap.o sp_positioner.o sp_scrollbar.o sp_slider.o sp _twheel.o sp_xyplot.o -lXext -lX11 -static -L../lib -lforms -L/systools/lib -lXpm -dynamic -lm cc: Warning: illegal option -dynamic cc: -a conflicts with -dy. *** Error code 1 make: Fatal error: Command failed for target `fdesign' Current working directory /disk-b/hiller/xforms-1.0/fdesign making all in ./fd2ps... rm -f fd2ps LD_RUN_PATH=/usr/openwin/lib cc -o fd2ps -g -Xc -xF -xcg92 -L/usr/openwin/li b align.o fd2ps.o flsupport.o image2ps.o load.o papers.o pscol.o psdraw.o psobj.o pstext.o readxpm.o sys.o version.o xbmtops.o xpmtops.o -lXext -lX11 -Bstatic -L../image -lflimage -L../lib -lforms -Bdynamic -lm ild: (argument error) can't find library argument :: -lflimage *** Error code 8 make: Fatal error: Command failed for target `fd2ps' Current working directory /disk-b/hiller/xforms-1.0/fd2ps gmake: *** [all] Error 1 I think the main error is the relocation error (which is propably the reason why libflimage.so is not created). Thnaks in advance for your help. Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg Germany phone +49 6221 528238 fax +49 6221 528246 email hiller at mpia.de PS: For your information: Imakefile looks like this: /* Configuration -- see 00README for details */ /* Fairly important stuff */ #define OptimizationLevel -O4 #define DoWall NO #define BuildShared YES #define StaticLink YES #define BuildGL NO /* Less Important or System Specific */ #define HaveStrerror YES #define HaveSnprintf YES #define HaveFloatH YES #define DoOptimize YES #define BuildDemos NO #define DebugSymbols YES /* * You should only define this if you're running a 64 bit compile * environment on Solaris. */ #define Solaris64Bit NO /* Out in the Tall Weeds */ #define InstallNonstandard YES #define XFormsNonstandardInstallDir /systools/misc/xforms #define NonstandardXpm YES #define XpmIncLoc /systools/include #define XpmLibLoc /systools/lib #define NonstandardTiff YES #define TiffIncLoc /systools/include #define TiffLibLoc /systools/lib #define NonstandardJpeg YES #define JpegIncLoc /systools/include #define JpegLibLoc /systools/lib [the rest was not changed] From sian at sleitch.nildram.co.uk Sun Nov 2 13:09:17 2003 From: sian at sleitch.nildram.co.uk (Sian Leitch) Date: Sun, 2 Nov 2003 18:09:17 +0000 Subject: [XForms] Re: XForms: Future xforms development In-Reply-To: <20021210183511.61780.qmail@web41210.mail.yahoo.com> References: <200212101700.gBAH0SF04956@ncmir.ucsd.edu> <20021210183511.61780.qmail@web41210.mail.yahoo.com> Message-ID: <20031102180917.GD1248@sleitch.nildram.co.uk> On Tue, Dec 10, 2002 at 01:35:11PM -0500, David Scriven wrote: > # To subscribers of the xforms list from David Scriven : > > I suspect that the reason that Angus is not > getting any feedback is that there are very few > of us actively developing under XForms, so you > are not getting the 'critical mass' that drives > development. > > There are all sorts of reasons for this - for > example Red Hat dropped XForms from its > PowerTools because it was not open source (is > there some way to encourage them to add it to > their distro now that it is Open Source?) Also > 0.89 was quite buggy, and its > functionality/reliability varied from platform to > platform and that turned a lot of people off. > > Secondly, if I knew nothing about XForms and > wanted to get started I would probably end up on > the XForms home page, which is horribly out of > date, has broken links and links to 0.89, but > none to version 1. > > My point is that if we want XForms to survive we > have to attract users. We have to make it easy to > for new users to get the software and the > documentation so that they can be up and running > quickly. Well, here is one lurker who is actively developing using Xforms. I am currently designing the Home Finance Program (`hfp') and look forward to using `fdesign' once the filter for Algol 68 is completed (`fdtow68'). Meanwhile, I have written some test progs for various ideas. Regards -- Sian Leitch Software Engineer specialising in Algol 68 Algol 68 for Linux is available from and -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031102/a9c09f7f/attachment-0003.bin From drriddle at qwest.net Wed Nov 5 22:41:54 2003 From: drriddle at qwest.net (Reed Riddle) Date: Wed, 5 Nov 2003 21:41:54 -0600 Subject: [XForms] Problem compiling with Mac OS X Message-ID: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Howdy folks, I'm trying to compile the library under OS X, and I keep running into the following errors when I run the configure script: ** Cannot find xpm.h. Please check that the Xpm library is correctly installed on your system. ** Cannot find libjpeg. Please check that the jpeg library is correctly installed on your system. I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in /sw/lib). I know that the X libraries aren't being seen at all when I compile, as all kinds of errors come up related to X. I also know how to set Linux so that it will find where you have libraries (using ldconfig), but I can't find any information like that for OS X. And, I can't figure out what to change in the configuration files to force it to see the library directories. No, I'm not frustrated... :) Anything that can point me in the right direction to get this to work will be greatly appreciated. Thanks! Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From Todd.Denniston at ssa.crane.navy.mil Thu Nov 6 09:00:19 2003 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu, 06 Nov 2003 09:00:19 -0500 Subject: [XForms] Problem compiling with Mac OS X References: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Message-ID: <3FAA53F3.CBE9476A@ssa.crane.navy.mil> Reed Riddle wrote: > > To subscribers of the xforms list > > Howdy folks, > > I'm trying to compile the library under OS X, and I keep running into > the following errors when I run the configure script: > > ** Cannot find xpm.h. Please check that the Xpm library > is correctly installed on your system. > > ** Cannot find libjpeg. Please check that the jpeg library > is correctly installed on your system. > > I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in /sw/lib). > I know that the X libraries aren't being seen at all when I compile, > as all kinds of errors come up related to X. I also know how to set > Linux so that it will find where you have libraries (using ldconfig), > but I can't find any information like that for OS X. And, I can't > figure out what to change in the configuration files to force it to see > the library directories. > > No, I'm not frustrated... :) Anything that can point me in the right > direction to get this to work will be greatly appreciated. Thanks! > > Reed > Sometimes configure will actually use the 'with-extra...' options --with-extra-lib specify extra library directory --with-extra-inc specify extra include directory though my results with them have been sporadic in other library compiles (LessTif), BTW please report on whether they work for you with xforms, if they don't perhaps someone can fix them. if that does not work try exporting `LIBS=-L/sw/lib` & `INCLUDES=-I/usr/X11R6/lib/X11/` and redo the configure/make After compilation you may have to define `export LD_LIBRARY_PATH=/sw/lib` before running the app, until you can figure out what OS X/BSD's options are for setting default library directories. (Sorry, I have not messed with BSD yet) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From Jean-Marc.Lasgouttes at inria.fr Thu Nov 6 09:13:24 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 06 Nov 2003 15:13:24 +0100 Subject: [XForms] Problem compiling with Mac OS X In-Reply-To: <3FAA53F3.CBE9476A@ssa.crane.navy.mil> (Todd Denniston's message of "Thu, 06 Nov 2003 09:00:19 -0500") References: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> <3FAA53F3.CBE9476A@ssa.crane.navy.mil> Message-ID: >>>>> "Todd" == Todd Denniston writes: >> I know that the X libraries aren't being seen at all when >> I compile, as all kinds of errors come up related to X. Is xmkmf in you PATH? JMarc From dstrang at chartermi.net Mon Nov 10 02:40:51 2003 From: dstrang at chartermi.net (David Strang) Date: Mon, 10 Nov 2003 02:40:51 -0500 Subject: [XForms] Mesa/GL demos Message-ID: <000701c3a75d$f84822a0$6401a8c0@athlon24> Hi: I installed the 1.0 version of the Forms library and everything compiled fine with the replacement of the Imakefile (thanks). What do I need to do to get the Mesa/GL demos (gl, glwin) compiled? I'm running Mandrake 9.1 and it looks like I have the shared Mesa 5.0-3 libraries. The 01README mentions using the gl.c from the demos directory (../FORMS/gl.c ??) and recompiling the libform.* . Also, link libGL.a to libMesaGL.a . I couldn't find a libMesaGL.a . Seems I need a little housekeeping here to resolve the Mesa/GL references in gl.c . Help is appreciated. Regards, Dave Strang From nicolas.castagne at imag.fr Mon Nov 10 04:56:35 2003 From: nicolas.castagne at imag.fr (=?ISO-8859-1?Q?Nicolas_Castagn=E9?=) Date: Mon, 10 Nov 2003 10:56:35 +0100 Subject: [XForms] Problem compiling with Mac OS X In-Reply-To: <29F012C7-100B-11D8-971A-003065E23D38@qwest.net> Message-ID: <2BADD5B7-1364-11D8-BEAF-000393C76CA6@imag.fr> Hi all, Here is the report of the uses I made of XForms on Mac-OS-X last week. I also encountered a few problems with compiling the library. After a few trial, I would encourage MacOS X developpers to use the software tool FINK which is available at http://fink.sourceforge.net/ Fink takes into account the specificities of Mac OS X, which is finally not so much a standard linux (sic), to maintain your environment for software development. Especially, Fink is able to 1) scan your Mac OS X system and show which libraries are installed ; 2) download, compile and instal open source libraries ; especially, it will download any library needed to compile a specific package, if it is not yet installed ; 3) keep up to date your packages, since the download locations of almost every library is known by the software. For example, Fink was able to 1) download 2) compile 3) install automatically the XForms library and ALL the necessary packages, including XPM and OpenGL and 4) recompile all my XForms-Based software in 4 hours... Much better than getting crazy with the syntax of Makefiles, is not it? ;-) All the best, Nicolas Le jeudi, 6 nov 2003, ? 04:41 Europe/Paris, Reed Riddle a ?crit : > To subscribers of the xforms list > > > Howdy folks, > > I'm trying to compile the library under OS X, and I keep running into > the following errors when I run the configure script: > > ** Cannot find xpm.h. Please check that the Xpm library > is correctly installed on your system. > > ** Cannot find libjpeg. Please check that the jpeg library > is correctly installed on your system. > > I can see both xpm.h (in /usr/X11R6/lib/X11/) and libjpeg (in > /sw/lib). I know that the X libraries aren't being seen at all when I > compile, as all kinds of errors come up related to X. I also know how > to set Linux so that it will find where you have libraries (using > ldconfig), but I can't find any information like that for OS X. And, > I can't figure out what to change in the configuration files to force > it to see the library directories. > > No, I'm not frustrated... :) Anything that can point me in the right > direction to get this to work will be greatly appreciated. Thanks! > > Reed > > ---------------------------------------------------------------------- > Dr. Reed L. Riddle > Associate Director of Whole Earth Telescope Operations > Iowa State University Department of Physics & Astronomy > Email: drriddle at qwest.net > Homepage: http://www3.iitap.iastate.edu/~riddle/ > > "This life has been a test. If it had been an actual life, you would > have received actual instructions on where to go and what to do." > -- Angela Chase, "My so-called life" > > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > > ------------------------------------------------------------------------ -------------------------- Dr Nicolas CASTAGNE Researcher, IR de l'ACROE / ICA, Association pour la Cr?ation et la Recherche sur les Outils d'Expression Laboratoire Informatique et Cr?ation Artistique INPG, 46 av. F. Viallet, 38000 Grenoble, France. pro : (33) 4 76 57 46 60 fax : (33) 4 76 57 48 89 ------------------------------------------------------------------------ -------------------------- From Jean-Marc.Lasgouttes at inria.fr Tue Nov 18 10:30:28 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 Nov 2003 16:30:28 +0100 Subject: [XForms] [PATCH] update the autotools files. Message-ID: A non-text attachment was scrubbed... Name: config.diff.gz Type: application/octet-stream Size: 39175 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031118/13162586/attachment-0002.obj -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: INSTALL Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031118/13162586/attachment-0002.pl From angus.leeming at btopenworld.com Tue Nov 18 17:43:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 Nov 2003 22:43:24 +0000 Subject: [XForms] [PATCH] update the autotools files. In-Reply-To: References: Message-ID: <200311182243.24688.angus.leeming@btopenworld.com> On Tuesday 18 November 2003 3:30 pm, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > Here is a small patch updating the config/ files to what I found on > rh9 Thanks JMarc. They're in... Angus From msz at astrouw.edu.pl Wed Nov 19 05:56:06 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 19 Nov 2003 11:56:06 +0100 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: <200305301057.43750.angus.leeming@btopenworld.com> Message-ID: <20031119105606.GA1903@astrouw.edu.pl> Hi XFormers, I'd like to know what the current status of "file selector double-click" bug is? There were a couple of messages regarding this in May, starting with a patch proposed by Mike Heffner, but the discussion that followed raised some doubts. It ended with following message from Mike: > However, we still have the same problem that the callback is never getting > a ButtonPress event. ;-( > > This weekend I'll try rewriting the file selector's callback using the > fl_set_browser_dblclick_callback(). It seems that might be a much easier > way of approaching this. Mike, did you try the rewrite? If no, is Mike's patch included in any (CVS maybe) version of code? I have some heavily-used XForms apps dating back to ver. 0.88 and I'd like very much to rebuild them with 1.0 (also because of problems with static libraries under RedHat 9) but all users here are quite used to double-clicking in file selector. The problems started already in 0.89 and, sadly, have propagated into 1.0. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:11:46 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:11:46 +0100 Subject: [XForms] Mesa/GL demos In-Reply-To: <000701c3a75d$f84822a0$6401a8c0@athlon24> (David Strang's message of "Mon, 10 Nov 2003 02:40:51 -0500") References: <000701c3a75d$f84822a0$6401a8c0@athlon24> Message-ID: >>>>> "David" == David Strang writes: David> To subscribers of the xforms list Hi: David> I installed the 1.0 version of the Forms library and everything David> compiled fine with the replacement of the Imakefile (thanks). David> What do I need to do to get the Mesa/GL demos (gl, glwin) David> compiled? David> I'm running Mandrake 9.1 and it looks like I have the shared David> Mesa 5.0-3 libraries. David> The 01README mentions using the gl.c from the demos directory David> (../FORMS/gl.c ??) and recompiling the libform.* . Also, link David> libGL.a to libMesaGL.a . David> I couldn't find a libMesaGL.a . The .a library should be in the Mesa-devel package (or whatever it's called). You can probably link to libMesaGL.so with a -lMesaGL directive. David> Seems I need a little housekeeping here to resolve the Mesa/GL David> references in gl.c . What would be insteresting is to know whether it works better in xforms cvs where we have switched to autoconf. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:45:03 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:45:03 +0100 Subject: [XForms] Re: XForms: Towards xforms 1.1 In-Reply-To: <200305212241.04744.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 21 May 2003 22:41:04 +0000") References: <200305212241.04744.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: [OK, this was 6 months ago, but I am cleaning my mailbox...] Angus> I think that NT lib/OS2 os2move.cmd gl/canvas.h are all Angus> redundant (the latter is almost identical to glcanvas.h and Angus> appears to be a historical anachronism. It has certainly never Angus> been installed). Angus> Would anybody object if I removed them? Please remove them. Also, I think lib/Readme should be removed (check first...). Do gl demos still work? (I do not have gl stuff installed here to check...). Also, could you update the NEWS file? We will probably need at least a prerelease of 1.1. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 06:49:23 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 12:49:23 +0100 Subject: [XForms] [PATCH] Various stuff Message-ID: A non-text attachment was scrubbed... Name: stuff.diff Type: text/x-patch Size: 6171 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/ac02f299/attachment-0002.bin From Jean-Marc.Lasgouttes at inria.fr Wed Nov 19 09:38:51 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 19 Nov 2003 15:38:51 +0100 Subject: [XForms] [PATCH] Various stuff In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 19 Nov 2003 12:49:23 +0100") References: Message-ID: >>>>> "Jean-Marc" == Jean-Marc Lasgouttes writes: Jean-Marc> To subscribers of the xforms list This patch updates README Jean-Marc> somewhat, makes ure that the X11 include path is used to Jean-Marc> search for xpm.h (should I do the same for jpeg and/or Jean-Marc> gl?), and fixes small things. Jean-Marc> Please apply. Well, I decided to have a look whether I could use my write access on cvs. Guess what? It just worked ! JMarc From angus.leeming at btopenworld.com Wed Nov 19 16:58:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 21:58:02 +0000 Subject: [XForms] [PATCH] Various stuff In-Reply-To: References: Message-ID: <200311192158.02931.angus.leeming@btopenworld.com> On Wednesday 19 November 2003 2:38 pm, Jean-Marc Lasgouttes wrote: > Jean-Marc> This patch updates README somewhat, > Jean-Marc> makes ure that the X11 include path is used to > Jean-Marc> search for xpm.h (should I do the same for jpeg > Jean-Marc> and/or gl?), and fixes small things. > > Jean-Marc> Please apply. > > Well, I decided to have a look whether I could use my write access on > cvs. Guess what? It just worked ! So starts the slippery slope towards responsibility ;-) Many thanks for doing this. Angus From angus.leeming at btopenworld.com Wed Nov 19 17:49:16 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 22:49:16 +0000 Subject: [XForms] Re: XForms: Towards xforms 1.1 In-Reply-To: References: <200305212241.04744.angus.leeming@btopenworld.com> Message-ID: <200311192249.16531.angus.leeming@btopenworld.com> On Wednesday 19 November 2003 11:45 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming writes: > > [OK, this was 6 months ago, but I am cleaning my mailbox...] > > Angus> I think that NT lib/OS2 os2move.cmd gl/canvas.h are all > Angus> redundant (the latter is almost identical to glcanvas.h and > Angus> appears to be a historical anachronism. It has certainly never > Angus> been installed). > > Angus> Would anybody object if I removed them? > > Please remove them. Done. Is README.OS2 now redundant too? > Also, I think lib/Readme should be removed (check first...). Checked and then removed. > Do gl demos still work? (I do not have gl stuff installed > here to check...). > > Also, could you update the NEWS file? Hmmm. Yes. This will take some effort but I'll put it on my todo list. > We will probably need at least a prerelease of 1.1. Definitely. Angus From angus.leeming at btopenworld.com Wed Nov 19 18:06:17 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 Nov 2003 23:06:17 +0000 Subject: [XForms] Towards a warning-free compilation. Message-ID: <200311192306.17228.angus.leeming@btopenworld.com> I have been trying to reduce the number of warnings when compiling xforms with CFLAGS='-O2 -W -Wall -Wno-unused-parameter -pedantic' That's about as strict as C will allow. There are currently two main groups of warning messages: 'uninitialized variable' (almost all in the declaration of arrays) and 'comparison between signed and unsigned'. Attached is a tentative patch that removes all of the 'uninitialized variable' warnings. I say tentative because xforms tends to use macros such as #define NV(a) (#a,a) to simplify such initializations. Eg: #define NV(a) #a,a static FL_IMAP fl_imap[FL_MAX_COLS] = { {NV(FL_BLACK), 0, 0, 0, 0, 0}, {NV(FL_WHITE), 255, 255, 255, 0, 0}, I have squashed the warnings in the case above by adding the final ', 0, 0' to the decalrations, but I could arguably achieve the same end by extending the definition of the NV macro to: #define NV(a,r,g,b) ({#a,a,r,g,b,0,0}) static FL_IMAP fl_imap[FL_MAX_COLS] = { NV(FL_BLACK, 0, 0, 0), NV(FL_WHITE, 255, 255, 255), Given that NV exists already, would it not be more elegant to do things the second way? I also attach the log of the remaining_warnings and a little sed script that I used to strip most everything but the warnings out from the make log file. $ make > make.log 2>&1 $ sed -f striplog.sed make.log > remaining_warnings.txt You'll see that there are also a couple of warnings about inconsistent declarations in there too... Regards, Angus -------------- next part -------------- /^depfile/d /^depmode/d /^gcc/d /^source/d /^\/bin\/sh/d /^make\[[123]\]/d /^Making all/d /^cp -p/d /^creating/d /^(cd/d /^rm -f/d /^mv -f/d /^ar cru/d /^mkdir/d /^echo timestamp/d /^config.status/d /^cd/d /^make/d -------------- next part -------------- A non-text attachment was scrubbed... Name: remaining_warnings.txt.gz Type: application/x-gzip Size: 1152 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/769cd83b/attachment-0004.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: initialization.diff.gz Type: application/x-gzip Size: 5314 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031119/769cd83b/attachment-0005.gz From tristan at mpegtv.com Wed Nov 19 20:53:36 2003 From: tristan at mpegtv.com (Tristan Savatier) Date: Wed, 19 Nov 2003 17:53:36 -0800 Subject: [XForms] Towards a warning-free compilation. References: <200311192306.17228.angus.leeming@btopenworld.com> Message-ID: <029501c3af09$1ce8c850$0100a8c0@milk> > I have squashed the warnings in the case above by adding the final ', 0, 0' Normally, any partially initialized global or static structure will be padded with zeros. I think it also applies to arrays (?). so the compiler warnings about 'uninitialized variable' would seem bogus to me... From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 04:20:52 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 10:20:52 +0100 Subject: [XForms] [PATCH] Various stuff In-Reply-To: <200311192158.02931.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 19 Nov 2003 21:58:02 +0000") References: <200311192158.02931.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> So starts the slippery slope towards responsibility ;-) Many Angus> thanks for doing this. Angus Well, we _have_ to get this thing going at least until we can deliver a working autotools-based version. JMarc From angus.leeming at btopenworld.com Thu Nov 20 05:04:02 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 10:04:02 +0000 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: <029501c3af09$1ce8c850$0100a8c0@milk> References: <200311192306.17228.angus.leeming@btopenworld.com> <029501c3af09$1ce8c850$0100a8c0@milk> Message-ID: <200311201002.50320.angus.leeming@btopenworld.com> On Thursday 20 November 2003 1:53 am, Tristan Savatier wrote: > > I have squashed the warnings in the case above by adding the final ', 0, > Normally, any partially initialized global or static structure will be > padded with zeros. I think it also applies to arrays (?). > so the compiler warnings about 'uninitialized variable' would seem bogus to > me... Maybe, but the fact remains that bogus warnings make it harder to see real warnings. If we can squash warnings (with no run-time effect) then we should. Angus From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 05:30:55 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 11:30:55 +0100 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: <200311201002.50320.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 20 Nov 2003 10:04:02 +0000") References: <200311192306.17228.angus.leeming@btopenworld.com> <029501c3af09$1ce8c850$0100a8c0@milk> <200311201002.50320.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> so the compiler warnings about 'uninitialized variable' would seem >> bogus to me... Angus> Maybe, but the fact remains that bogus warnings make it harder Angus> to see real warnings. If we can squash warnings (with no Angus> run-time effect) then we should. Yes. And I think that the patch that you posted is good enough in this regard. JMarc From angus.leeming at btopenworld.com Thu Nov 20 05:49:30 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 10:49:30 +0000 Subject: [XForms] Towards a warning-free compilation. In-Reply-To: References: <200311192306.17228.angus.leeming@btopenworld.com> <200311201002.50320.angus.leeming@btopenworld.com> Message-ID: <200311201049.30448.angus.leeming@btopenworld.com> On Thursday 20 November 2003 10:30 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > >> > >> so the compiler warnings about 'uninitialized variable' would seem > >> bogus to me... > > Angus> Maybe, but the fact remains that bogus warnings make it harder > Angus> to see real warnings. If we can squash warnings (with no > Angus> run-time effect) then we should. > > Yes. And I think that the patch that you posted is good enough in this > regard. Me too. It's in. Angus From angus.leeming at btopenworld.com Thu Nov 20 07:49:29 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 20 Nov 2003 12:49:29 +0000 Subject: [XForms] [PATCH]: squashing all remaining warnings Message-ID: <200311201249.29064.angus.leeming@btopenworld.com> Attached is a patch to squash all the remaining warnings when compiling with CFLAGS='-W -Wall -Wno-unused-parameter'. All these warnings are 'comparison of signed and unsigned'. I have been pretty careful here and when unsure have erred on the side of caution, casting the unsigned var to signed. Much of the time though I have felt that going the other way was fine (ie, casting the signed var to unsigned). I would value it if someone would take the time to verify that I haven't fubar-ed here. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: signed.diff.gz Type: application/x-gzip Size: 5283 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031120/075bb252/attachment-0002.gz From Jean-Marc.Lasgouttes at inria.fr Thu Nov 20 08:49:48 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Nov 2003 14:49:48 +0100 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: <200311201249.29064.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 20 Nov 2003 12:49:29 +0000") References: <200311201249.29064.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Attached is a patch to squash Angus> all the remaining warnings when compiling with CFLAGS='-W -Wall Angus> -Wno-unused-parameter'. All these warnings are 'comparison of Angus> signed and unsigned'. Angus> I have been pretty careful here and when unsure have erred on Angus> the side of caution, casting the unsigned var to signed. Much Angus> of the time though I have felt that going the other way was Angus> fine (ie, casting the signed var to unsigned). And did you find any real problem in the process? Angus> I would value it if someone would take the time to verify that Angus> I haven't fubar-ed here. I took a quick look at the patch and it looks like checking each and every of these is a long process. I won't have time to do it. So if you are confident, just apply the patch. Otherwise, we'll have to live with the warnings :) JMarc From angus.leeming at btopenworld.com Fri Nov 21 04:15:55 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 21 Nov 2003 09:15:55 +0000 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: References: <200311201249.29064.angus.leeming@btopenworld.com> Message-ID: <200311210915.55314.angus.leeming@btopenworld.com> On Thursday 20 November 2003 1:49 pm, Jean-Marc Lasgouttes wrote: > Angus> I would value it if someone would take the time to verify that > Angus> I haven't fubar-ed here. > > I took a quick look at the patch and it looks like checking each and > every of these is a long process. I won't have time to do it. > > So if you are confident, just apply the patch. Otherwise, we'll have > to live with the warnings :) Maybe I'll do it a bit at a time. Adding bugs for the sake of squashing warnings seems like a poor trade off to me ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 04:23:13 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 10:23:13 +0100 Subject: [XForms] [PATCH]: squashing all remaining warnings In-Reply-To: <200311210915.55314.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 21 Nov 2003 09:15:55 +0000") References: <200311201249.29064.angus.leeming@btopenworld.com> <200311210915.55314.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Maybe I'll do it a bit at a time. Adding bugs for the sake of Angus> squashing warnings seems like a poor trade off to me ;-) Definitely :) JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 05:53:37 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 11:53:37 +0100 Subject: [XForms] [PATCH] squash more warnings Message-ID: A non-text attachment was scrubbed... Name: warnings.diff Type: text/x-patch Size: 4787 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/6949fbf8/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: mk.log Type: application/octet-stream Size: 4013 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/6949fbf8/attachment-0002.obj From angus.leeming at btopenworld.com Fri Nov 21 08:28:33 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 21 Nov 2003 13:28:33 +0000 Subject: [XForms] Enabling the building of the demo GL programs Message-ID: <200311211328.33037.angus.leeming@btopenworld.com> Ok, I squashed those warnings about the comparison of signed and unsigned vars that I deemed to be safe to squash. The remaining few can wait till I have more energy ;-) Attached is a patch to enable the building of the demo GL programs. Comments? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-diff Size: 2305 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031121/c6ab75bc/attachment-0002.bin From Jean-Marc.Lasgouttes at inria.fr Fri Nov 21 09:08:17 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 21 Nov 2003 15:08:17 +0100 Subject: [XForms] Enabling the building of the demo GL programs In-Reply-To: <200311211328.33037.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 21 Nov 2003 13:28:33 +0000") References: <200311211328.33037.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Ok, I squashed those warnings Angus> about the comparison of signed and unsigned vars that I deemed Angus> to be safe to squash. The remaining few can wait till I have Angus> more energy ;-) Good move. Angus> Attached is a patch to enable the building of the demo GL Angus> programs. Angus> Comments? Looks reasonable. JMarc From msz at astrouw.edu.pl Sun Nov 23 10:35:48 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Sun, 23 Nov 2003 16:35:48 +0100 Subject: [XForms] problem with autoconf in RH9 Message-ID: <20031123153548.GA18821@astrouw.edu.pl> Hi, I've just downloaded the source from CVS depository, using: cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . Contrary to what I found in the INSTALL file, the downloaded tree lacks 'configure' script so I ran "autoconf". Unfortunately, it failed saying: >autoconf configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:14: error: possibly undefined macro: AM_MAINTAINER_MODE configure.ac:17: error: possibly undefined macro: AM_INIT_AUTOMAKE configure.ac:29: error: possibly undefined macro: AM_CONDITIONAL configure.ac:52: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL configure.ac:53: error: possibly undefined macro: AM_PROG_LIBTOOL The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, autoconf-2.57-3, libtool-1.4.3-5. Any ideas, hints? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From drriddle at qwest.net Sun Nov 23 16:22:07 2003 From: drriddle at qwest.net (Reed Riddle) Date: Sun, 23 Nov 2003 15:22:07 -0600 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> I just installed this yesterday on a RedHat 9, with the CVS version, and everything worked just fine. It's a standard RedHat install, nothing modified. Have you changed anything in the system settings, or added/updated any software? Reed On Sunday, November 23, 2003, at 09:35 AM, Michal Szymanski wrote: > To subscribers of the xforms list > > > Hi, > > I've just downloaded the source from CVS depository, using: > > cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login > cvs -z3 -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . > > Contrary to what I found in the INSTALL file, the downloaded tree lacks > 'configure' script so I ran "autoconf". Unfortunately, it failed > saying: > >> autoconf > configure.ac:6: error: possibly undefined macro: AM_CONFIG_HEADER > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.ac:14: error: possibly undefined macro: AM_MAINTAINER_MODE > configure.ac:17: error: possibly undefined macro: AM_INIT_AUTOMAKE > configure.ac:29: error: possibly undefined macro: AM_CONDITIONAL > configure.ac:52: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL > configure.ac:53: error: possibly undefined macro: AM_PROG_LIBTOOL > > The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, > autoconf-2.57-3, libtool-1.4.3-5. > > Any ideas, hints? > > regards, Michal. > > -- > Michal Szymanski (msz at astrouw.edu.pl) > Warsaw University Observatory, Warszawa, POLAND > _______________________________________________ > To unsubscribe, send the message "unsubscribe" to > xforms-request at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > XForms Home Page: http://world.std.com/~xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > > ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Email: drriddle at qwest.net Homepage: http://www3.iitap.iastate.edu/~riddle/ "This life has been a test. If it had been an actual life, you would have received actual instructions on where to go and what to do." -- Angela Chase, "My so-called life" From msz at astrouw.edu.pl Mon Nov 24 02:49:44 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 08:49:44 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> References: <20031123153548.GA18821@astrouw.edu.pl> <176DFD26-1DFB-11D8-A9C3-003065E23D38@qwest.net> Message-ID: <20031124074944.GA829@astrouw.edu.pl> On Sun, Nov 23, 2003 at 03:22:07PM -0600, Reed Riddle wrote: > I just installed this yesterday on a RedHat 9, with the CVS version, > and everything worked just fine. It's a standard RedHat install, > nothing modified. Have you changed anything in the system settings, or > added/updated any software? > >The system is RedHat 9 Linux, kernel 2.4.20-20.9, glibc-2.3.2-27.9, > >autoconf-2.57-3, libtool-1.4.3-5. Well, the system *IS* updated, following RH errata. Could you please check your versions of the RPMs given above? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Mon Nov 24 04:30:59 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 24 Nov 2003 10:30:59 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031123153548.GA18821@astrouw.edu.pl> (Michal Szymanski's message of "Sun, 23 Nov 2003 16:35:48 +0100") References: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> I've just downloaded the source from CVS depository, using: Michal> cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms Michal> login cvs -z3 Michal> -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . Michal> Contrary to what I found in the INSTALL file, the downloaded Michal> tree lacks 'configure' script so I ran "autoconf". Try to run ./autogen.sh instead. JMarc From msz at astrouw.edu.pl Mon Nov 24 10:29:57 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 16:29:57 +0100 Subject: [XForms] JPEG/EXIF support? Message-ID: <20031124152956.GA2504@astrouw.edu.pl> Hi, It seems that JPEG support in XForms 1.0 is only for "standard", JFIF format. I have plenty of JPEG/EXIF "extended" format images from digital camera which I'd like very much to display using XForms. Now, unfortunately, I'm getting messages like: In OpenImage [image.c 224] Guad22.jpg: Unknown image format Is there a simpler way to get them loaded properly than to write my own routines and use "flimage_add_format()"? I mean like using newer JPEG library? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Mon Nov 24 11:41:04 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 24 Nov 2003 17:41:04 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031124152956.GA2504@astrouw.edu.pl> (Michal Szymanski's message of "Mon, 24 Nov 2003 16:29:57 +0100") References: <20031124152956.GA2504@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> It seems that JPEG support in XForms 1.0 is only for Michal> "standard", JFIF format. I have plenty of JPEG/EXIF "extended" Michal> format images from digital camera which I'd like very much to Michal> display using XForms. Now, unfortunately, I'm getting messages Michal> like: Michal> In OpenImage [image.c 224] Guad22.jpg: Unknown image format Where is this JPEG/EXIF thing described? JMarc From msz at astrouw.edu.pl Mon Nov 24 12:28:21 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 18:28:21 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: References: <20031123153548.GA18821@astrouw.edu.pl> Message-ID: <20031124172821.GA9534@astrouw.edu.pl> On Mon, Nov 24, 2003 at 10:30:59AM +0100, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > > >>>>> "Michal" == Michal Szymanski writes: > > Michal> To subscribers of the xforms list Hi, > > Michal> I've just downloaded the source from CVS depository, using: > > Michal> cvs -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms > Michal> login cvs -z3 > Michal> -d:pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms co . > > Michal> Contrary to what I found in the INSTALL file, the downloaded > Michal> tree lacks 'configure' script so I ran "autoconf". > > Try to run ./autogen.sh instead. Thanks, it worked. I guess it might be worth putting into INSTALL file which now is somewhat misleading. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From msz at astrouw.edu.pl Mon Nov 24 13:07:06 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon, 24 Nov 2003 19:07:06 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: References: <20031124152956.GA2504@astrouw.edu.pl> Message-ID: <20031124180705.GB9534@astrouw.edu.pl> On Mon, Nov 24, 2003 at 05:41:04PM +0100, Jean-Marc Lasgouttes wrote: > >>>>> "Michal" == Michal Szymanski writes: > > Michal> To subscribers of the xforms list Hi, > > Michal> It seems that JPEG support in XForms 1.0 is only for > Michal> "standard", JFIF format. I have plenty of JPEG/EXIF "extended" > Michal> format images from digital camera which I'd like very much to > Michal> display using XForms. Now, unfortunately, I'm getting messages > Michal> like: > > Michal> In OpenImage [image.c 224] Guad22.jpg: Unknown image format > > Where is this JPEG/EXIF thing described? A quick search on the net resulted in following: EXIF stands for Exchangeable Image File Format, and is a standard for storing interchange information in image files, especially those using JPEG compression. Most digital cameras now use the EXIF format. The format is part of the DCF standard created by JEIDA to encourage interoperability between imaging devices. >From what I could quickly find, EXIF data in a JPEG file is stored in an application segment APP1. It seems that JPEG standard supports such segments - I'm not sure why the JPEG code in XForms can't deal with such images (if they really conform to JPEG standard, as it seems). Links: http://www.exif.org/ and links therein, of which one is particularly good: http://park2.wakwak.com/~tsuruzoh/Computer/Digicams/exif-e.html regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Mon Nov 24 14:51:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 24 Nov 2003 19:51:26 +0000 Subject: [XForms] Getting rid of auto-generated files... Message-ID: <200311241951.26091.angus.leeming@btopenworld.com> It would be nice if we could get rid of at least some of the .[ch] files generated from .fd datasets. We store .fd files and their associated .[ch] files in the following directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, the .[ch] files in the first two directories would have to remain. (We cannot generate the .[ch] files until fdesign has bee created.) However, it strikes me that the .[ch] files in the remaining directories could all be generated on the fly, just as we do in LyX. Personally, I think that this would be much more elegant. Thoughts? Angus From xforms2 at vjet.demon.co.uk Mon Nov 24 18:43:41 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Mon, 24 Nov 2003 23:43:41 GMT Subject: [XForms] JPEG/EXIF support? Message-ID: <200311242343.hAONhf36001050@vjet.demon.co.uk> Hi, > It seems that JPEG support in XForms 1.0 is only for "standard", JFIF > format. I have plenty of JPEG/EXIF "extended" format images from digital > camera which I'd like very much to display using XForms. > Now, unfortunately, I'm getting messages like: > > In OpenImage [image.c 224] Guad22.jpg: Unknown image format A long time ago I did a patch to improve some stuff in the image handling.. It got lost in the move to 1.0 But I can read images off my camera so it may solve your problem too.. Patch is at http://www.vjet.demon.co.uk/xforms/image.patch It probably needs massaging to work on the latest CVS. It fixes a bug in flimage_dup() , one in image rotate, and makes jpeg + gif reading better. These patches are applied to my 1.0 rpms too (http://www.vjet.demon.co.uk/xforms) HTHs Cheers Clive From mheffner at vt.edu Tue Nov 25 09:27:24 2003 From: mheffner at vt.edu (Mike Heffner) Date: Tue, 25 Nov 2003 09:27:24 -0500 (EST) Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <20031119105606.GA1903@astrouw.edu.pl> Message-ID: On 19-Nov-2003 Michal Szymanski wrote: > To subscribers of the xforms list > >> >> This weekend I'll try rewriting the file selector's callback using the >> fl_set_browser_dblclick_callback(). It seems that might be a much >> easier >> way of approaching this. > > Mike, did you try the rewrite? Nope, unfortunately life got in the way. :) I should have some free time this week to look at it again. Cheers, Mike -- Mike Heffner From angus.leeming at btopenworld.com Tue Nov 25 16:09:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 25 Nov 2003 21:09:26 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311242343.hAONhf36001050@vjet.demon.co.uk> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> Message-ID: <200311252109.26767.angus.leeming@btopenworld.com> On Monday 24 November 2003 11:43 pm, Clive A Stubbings wrote: > A long time ago I did a patch to improve some stuff in the image > handling.. It got lost in the move to 1.0 > > But I can read images off my camera so it may solve your problem too.. > Patch is at http://www.vjet.demon.co.uk/xforms/image.patch Got it. > It probably needs massaging to work on the latest CVS. It fixes a bug in > flimage_dup() , I'm not going to apply this without some discussion. Feel free to explain the rationale. > one in image rotate. I don't see the need for this. See the comment immediately preceeding your patched code. In cvs at least. /* * Now coerce it into +/- 180. */ > and makes jpeg + gif reading better. I've applied both these parts to my local tree, albeit with some re-factoring to get rid of the goto and some signed-unsigned comparson warnings. Could you check to see that all is still as you intended (attached). If you could cast your eye over the ChangeLog entry and maybe rename 'flush_buffer' to something that makes sense to you, that'd be great too... Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: clive.diff Type: text/x-diff Size: 3888 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031125/dead5e72/attachment-0002.bin From angus.leeming at btopenworld.com Tue Nov 25 17:56:45 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 25 Nov 2003 22:56:45 +0000 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311241951.26091.angus.leeming@btopenworld.com> References: <200311241951.26091.angus.leeming@btopenworld.com> Message-ID: <200311252256.45141.angus.leeming@btopenworld.com> On Monday 24 November 2003 7:51 pm, Angus Leeming wrote: > To subscribers of the xforms list > > > It would be nice if we could get rid of at least some of the .[ch] files > generated from .fd datasets. > > We store .fd files and their associated .[ch] files in the following > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, > the .[ch] files in the first two directories would have to remain. (We > cannot generate the .[ch] files until fdesign has bee created.) However, it > strikes me that the .[ch] files in the remaining directories could all be > generated on the fly, just as we do in LyX. > > Personally, I think that this would be much more elegant. Thoughts? Ok, I'm stuck ;-) Jean-Marc, I wonder if you might help... Attached are the changes I've made to demos/Makefile.am. This is proof of concept code and, indeed, works fine. However, I have no idea how to turn it into robust code :-( The problem lies with the block below which generates .[ch] files from a .fd file. Note that I am running this conversion from $build_dir/demos whilst the .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do not want to generate a static library in the fd directory because I want to be able to build individual demo files if I so choose. Here's the troublesome (but working) block: %.c: %.fd ../fdesign/fdesign (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign -convert `basename $<`; \ mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.) Line 1. All is Ok. The generated .c file depends on the .fd file and on the existence of the fdesign binary. %.c: %.fd ../fdesign/fdesign Lines 2,3. The problems. It appears that fdesign must be run from the directory containing the .fd file. That means I lose track of the fdesign binary and then must move the generated .[ch] files into the $builddir tree (if $srcdir != $builddir). Any ideas? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos_makefile.am Type: text/x-diff Size: 1081 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031125/bd54bf1f/attachment-0002.bin From msz at astrouw.edu.pl Wed Nov 26 03:26:09 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 26 Nov 2003 09:26:09 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311252109.26767.angus.leeming@btopenworld.com> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> Message-ID: <20031126082609.GA9882@astrouw.edu.pl> On Tue, Nov 25, 2003 at 09:09:26PM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > On Monday 24 November 2003 11:43 pm, Clive A Stubbings wrote: > > A long time ago I did a patch to improve some stuff in the image > > handling.. It got lost in the move to 1.0 > > > > But I can read images off my camera so it may solve your problem too.. > > Patch is at http://www.vjet.demon.co.uk/xforms/image.patch > > Got it. > > > It probably needs massaging to work on the latest CVS. It fixes a bug in > > flimage_dup() , > > I'm not going to apply this without some discussion. Feel free to explain the > rationale. Hi, I did not go into details but downloaded Clive's patched versions of the 1.0 libs and indeed, my application started to read JPEG/EXIF images from my digital camera without any modification, just relinking. So I'd strongely vote for including the patch(es) into XForms. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Wed Nov 26 05:43:16 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 10:43:16 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031126082609.GA9882@astrouw.edu.pl> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> <20031126082609.GA9882@astrouw.edu.pl> Message-ID: <200311261043.16110.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 8:26 am, Michal Szymanski wrote: > Hi, > > I did not go into details but downloaded Clive's patched versions of the > 1.0 libs and indeed, my application started to read JPEG/EXIF images > from my digital camera without any modification, just relinking. So I'd > strongely vote for including the patch(es) into XForms. Could you revert Clive's patch and try the one I appended in my original reply to his posting? This patch contains the jpeg and gif enhancements and I am more than happy to merge it into the xforms sources. Angus From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 06:54:12 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 12:54:12 +0100 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311252256.45141.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 25 Nov 2003 22:56:45 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. So we could maybe take a look at fixing fdesign, since we have control on it :) Another solution would be to have a Makefile.am in the fd/ directories, maybe. Sorry, I do not have much time to think about it right now. I think this is something that we could leave for after 1.1. I'd like to concentrate on this first. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 08:37:15 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 14:37:15 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 26 Nov 2003 12:54:12 +0100") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-patch Size: 1726 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/d3e34718/attachment-0004.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: fddiff.diff Type: text/x-patch Size: 2840 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/d3e34718/attachment-0005.bin From angus.leeming at btopenworld.com Wed Nov 26 08:49:43 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 13:49:43 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> Message-ID: <200311261349.43597.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 1:37 pm, Jean-Marc Lasgouttes wrote: > Angus> Lines 2,3. The problems. It appears that fdesign must be run > Angus> from the directory containing the .fd file. > > Jean-Marc> So we could maybe take a look at fixing fdesign, since we > Jean-Marc> have control on it :) > > The following patch fixes fdesign -convert for me. My problem was that > I have a "." in my homedir name (/afs/inria.fr/...). Does it help you? If it works for you, then I expect that it will work for me. I'll try it out this evening. > Could you re-read the patch to make sure I did not make a mistake? I > think using filename instead of fname is the right thing to do here. > > With this patch applied, I get the following diff on a sample fd file. > So the difference is: > > 1/ the LGPL notice is gone. Is this a big problem? No. These are generated files. If we really, really want an LGPL notice, the place to put it is in the .fd file. In turn that means enabling fdesign to handle comments in its .fd files. Something for the future, maybe, but not something to worry about now. > 2/ we have > -#include "include/forms.h" > +#include "forms.h" > I think this will be solved by using -I$(top_srcdir}/lib/include in > INCLUDES. Sure. > Note also that fdesign now adds > +/** Header file generated with fdesign on Wed Nov 26 14:25:19 2003.**/ > but only to the header (not the .c file). We should probably remove > this altogether, since it creates useless diffs. Agreed. > What do you think? I think that I like it when you claim to be 'too busy to think' ;-) Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 08:55:57 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 14:55:57 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311261349.43597.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 13:49:43 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 1:37 pm, Jean-Marc Lasgouttes wrote: Angus> Lines 2,3. The problems. It appears that fdesign must be run Angus> from the directory containing the .fd file. >> Jean-Marc> So we could maybe take a look at fixing fdesign, since we Jean-Marc> have control on it :) >> The following patch fixes fdesign -convert for me. My problem was >> that I have a "." in my homedir name (/afs/inria.fr/...). Does it >> help you? Angus> If it works for you, then I expect that it will work for me. Angus> I'll try it out this evening. I'm not sure because my problem was really a "." in path. I did not see one in your path names. >> What do you think? Angus> I think that I like it when you claim to be 'too busy to think' Angus> ;-) Regards, Angus I was pointing at your convoluted makefile rules. Note that I did not propose to fix them :) The fdesign problem, OTOH is definitely a bug that should be fixed before 1.1. JMarc From angus.leeming at btopenworld.com Wed Nov 26 09:08:29 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:08:29 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> Message-ID: <200311261408.29034.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 1:55 pm, Jean-Marc Lasgouttes wrote: > The fdesign problem, OTOH is definitely a bug that should be fixed > before 1.1. The little wrapper script, attached, gives us the functionality that I think that fdesign should have. Usage: $ sh fdesign2c The only problem with the script is in the lst line: # If ${SRCDIR} != ${DESTDIR} then # move the generated .[ch] files to ${DESTDIR}. mv -f `basename ${FDFILE} .fd`.[ch] ${DESTDIR} I have no idea how to test that ${SRCDIR} != ${DESTDIR}. Consequently, I get errors: mv: `butttypes_gui.c' and `/home/angus/xforms/xforms/build/demos/../../demos/fd/butttypes_gui.c' are the same file mv: `butttypes_gui.h' and `/home/angus/xforms/xforms/build/demos/../../demos/fd/butttypes_gui.h' are the same file Any ideas? Angus ps, once this is working, then modifying Makefile.am is a snip. Equally, it should provide the template to modify fdesign itself. I'd imagine using fdesign as $ fdesign -convert A -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign2c Type: application/x-shellscript Size: 1216 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/ea9449d5/attachment-0002.bin From Jean-Marc.Lasgouttes at inria.fr Wed Nov 26 09:16:03 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 26 Nov 2003 15:16:03 +0100 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: <200311261408.29034.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 14:08:29 +0000") References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261349.43597.angus.leeming@btopenworld.com> <200311261408.29034.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 1:55 pm, Jean-Marc Lasgouttes wrote: >> The fdesign problem, OTOH is definitely a bug that should be fixed >> before 1.1. Angus> The little wrapper script, attached, gives us the functionality Angus> that I think that fdesign should have. Angus> Usage: $ sh fdesign2c Angus> With my fix, fdesign is able to output .[ch] files in the directory where the .fd file was. Isn't it really good enough for now? Angus> ps, once this is working, then modifying Makefile.am is a snip. Angus> Equally, it should provide the template to modify fdesign Angus> itself. I'd imagine using fdesign as $ fdesign -convert Angus> Why would the Makefile.am not work with the fixed fdesign? Because you do not want the .[ch] files to appear in the source directory, but the build directory? JMarc From angus.leeming at btopenworld.com Wed Nov 26 09:21:26 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:21:26 +0000 Subject: [PATCH] Re: [XForms] Getting rid of auto-generated files... In-Reply-To: References: <200311241951.26091.angus.leeming@btopenworld.com> <200311261408.29034.angus.leeming@btopenworld.com> Message-ID: <200311261421.26649.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 2:16 pm, Jean-Marc Lasgouttes wrote: > Angus> ps, once this is working, then modifying Makefile.am is a snip. > Angus> Equally, it should provide the template to modify fdesign > Angus> itself. I'd imagine using fdesign as $ fdesign -convert > Angus> > > Why would the Makefile.am not work with the fixed fdesign? Because you > do not want the .[ch] files to appear in the source directory, but the > build directory? Correct. However, I will indeed try and make things work with your patched fdesign too. Angus From Todd.Denniston at ssa.crane.navy.mil Wed Nov 26 09:21:47 2003 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Wed, 26 Nov 2003 09:21:47 -0500 Subject: [XForms] Getting rid of auto-generated files... References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> Message-ID: <3FC4B6FB.B727860E@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > ------------------------------------------------------------------------ > On Monday 24 November 2003 7:51 pm, Angus Leeming wrote: > > To subscribers of the xforms list > > > > > > It would be nice if we could get rid of at least some of the .[ch] files > > generated from .fd datasets. > > > > We store .fd files and their associated .[ch] files in the following > > directories: lib/fd, fdesign/fd, fd2ps/test, demos and demos/fd. Of these, > > the .[ch] files in the first two directories would have to remain. (We > > cannot generate the .[ch] files until fdesign has bee created.) However, it > > strikes me that the .[ch] files in the remaining directories could all be > > generated on the fly, just as we do in LyX. > > > > Personally, I think that this would be much more elegant. Thoughts? > > Ok, I'm stuck ;-) > > Jean-Marc, I wonder if you might help... Attached are the changes I've made to > demos/Makefile.am. This is proof of concept code and, indeed, works fine. > However, I have no idea how to turn it into robust code :-( > > The problem lies with the block below which generates .[ch] files from a .fd > file. Note that I am running this conversion from $build_dir/demos whilst the > .fd file is to be found in $srcdir/demos/fd. Note the extra '/fd' there. I do > not want to generate a static library in the fd directory because I want to > be able to build individual demo files if I so choose. > > Here's the troublesome (but working) block: > > %.c: %.fd ../fdesign/fdesign > (cd `dirname $<` && /home/angus/xforms/cvs/build/fdesign/fdesign > -convert `basename $<`; \ > mv `basename $< .fd`.[ch] /home/angus/xforms/cvs/build/demos/fd/.) > > Line 1. All is Ok. The generated .c file depends on the .fd file and on the > existence of the fdesign binary. > %.c: %.fd ../fdesign/fdesign > > Lines 2,3. The problems. It appears that fdesign must be run from the > directory containing the .fd file. That means I lose track of the fdesign > binary and then must move the generated .[ch] files into the $builddir tree > (if $srcdir != $builddir). > > Any ideas? > Angus Actually, fdesign does not need to be ran from the directory containing the .fd file. You can pass it the path to the .fd, as in `fdesign -convert $<`, however fdesign as built now will make the .[ch] files in the same directory as the .fd file. perhaps you can/should use the gnu-make extension of vpath's, i.e., have the following added to the beginning of the demo's directory Makefile: vpath %.h . vpath %.c . vpath %.h ./fd vpath %.c ./fd vpath %.fd ./fd at least when vpath is available. a fallback, for non gnu makes, might be to make a rule that causes a `cp -p *.fd .` to occur if any file is newer in the fd directory than say the 'fdscopied' file, i.e., make fdscopied depend on all .fd files in the fd directory. Ugly but I am pretty sure I have used it in the past with other recalcitrant programs. At a later time it would be nice to have an option to pass to fdesign to either force it to output in the current working directory, or another specified output directory. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From angus.leeming at btopenworld.com Wed Nov 26 09:32:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 14:32:19 +0000 Subject: [XForms] Getting rid of auto-generated files... In-Reply-To: <3FC4B6FB.B727860E@ssa.crane.navy.mil> References: <200311241951.26091.angus.leeming@btopenworld.com> <200311252256.45141.angus.leeming@btopenworld.com> <3FC4B6FB.B727860E@ssa.crane.navy.mil> Message-ID: <200311261432.19460.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 2:21 pm, Todd Denniston wrote: Hi, Todd. > Actually, fdesign does not need to be ran from the directory containing > the .fd file. > You can pass it the path to the .fd, as in `fdesign -convert $<`, > however fdesign as built now will make the .[ch] files in the same > directory as the .fd file. Jean-Marc says that this works only so long as the path to the .fd file does not contain any '.'. See his patch. > perhaps you can/should use the gnu-make extension of vpath's, i.e., have > the following added to the beginning of the demo's directory Makefile: Hacks to work round a broken fdesign. Let's fix fdesign instead. > At a later time it would be nice to have an option to pass to fdesign to > either force it to output in the current working directory, or another > specified output directory. $ fdesign -d -convert ../foo/bar/your_file.fd That's what I'd like to get working. Angus From tacorner at chello.at Wed Nov 26 11:10:04 2003 From: tacorner at chello.at (tacorner at chello.at) Date: Wed, 26 Nov 2003 17:10:04 +0100 (CET) Subject: [XForms] Font selector widget Message-ID: I am thinking about writing a font selection widget for xfmail using xforms. Does such a thing exist in xforms itself or another xforms applications? Any suggestions? Tom Corner --------------------------------------------------- |\/\/\___/\/\/| Carol Anne Corner & \____ o o ____/ Thomas Corner ) ( 26-Nov-2003 17:06:59 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --------------------------------------------------- From msz at astrouw.edu.pl Wed Nov 26 17:06:24 2003 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 26 Nov 2003 23:06:24 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311261043.16110.angus.leeming@btopenworld.com> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311252109.26767.angus.leeming@btopenworld.com> <20031126082609.GA9882@astrouw.edu.pl> <200311261043.16110.angus.leeming@btopenworld.com> Message-ID: <20031126220624.GA11680@astrouw.edu.pl> On Wed, Nov 26, 2003 at 10:43:16AM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > On Wednesday 26 November 2003 8:26 am, Michal Szymanski wrote: > > Hi, > > > > I did not go into details but downloaded Clive's patched versions of the > > 1.0 libs and indeed, my application started to read JPEG/EXIF images > > from my digital camera without any modification, just relinking. So I'd > > strongely vote for including the patch(es) into XForms. > > Could you revert Clive's patch and try the one I appended in my original reply > to his posting? This patch contains the jpeg and gif enhancements and I am > more than happy to merge it into the xforms sources. I've applied your version of Clive's patch to my home CVS source tree. The Changelog patch got rejected but both "image" patches succeeded. And my application reading images can now read JPEG/EXIF files taken from my digital camera. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From xforms2 at vjet.demon.co.uk Wed Nov 26 21:27:21 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Thu, 27 Nov 2003 02:27:21 GMT Subject: [XForms] Re: JPEG/EXIF support? Message-ID: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> Thanks Angus, > > It probably needs massaging to work on the latest CVS. It fixes a bug in > > flimage_dup() , > > I'm not going to apply this without some discussion. Feel free to explain the > rationale. Well, its a while ago, but if memory serves, I found that if I dup'd an image then later free'd both copies I got a crash. The crash was because the first free also closed the files and the second one tried to do the same again, but the fp's were no longer valid. There needs to be only one reference to the fp.. Either it goes in a shared struct that both 'images' point to, or only one image can be associated with the file. I'm not sure that 2 'images' and one file really makes sense anyway. FWIW: I duped the image because I wanted to have the original and a processed copy, so I made a dup and then processed it.. When I'd finished with both images I free'd both.. Seemed reasonable to me. > > > one in image rotate. > > I don't see the need for this. See the comment immediately preceeding your > patched code. In cvs at least. > /* > * Now coerce it into +/- 180. > */ You're right - this one was broken in the 1.0 candidates and fixed in 1.0.. (Sorry..) > > > and makes jpeg + gif reading better. > > I've applied both these parts to my local tree, albeit with some re-factoring > to get rid of the goto and some signed-unsigned comparson warnings. Could you > check to see that all is still as you intended (attached). If you could cast > your eye over the ChangeLog entry and maybe rename 'flush_buffer' to > something that makes sense to you, that'd be great too... Had a fair look at it - seems OK on paper. flush_buffer is fine. The function flushes completed lines from the working buffer. (If you don't like the goto, with hindsight, an else might have been better ;-) Cheers Clive From tacorner at chello.at Thu Nov 27 03:05:52 2003 From: tacorner at chello.at (tacorner at chello.at) Date: Thu, 27 Nov 2003 09:05:52 +0100 (CET) Subject: [XForms] xforms cvs access Message-ID: Another question: Is it possible to get read-only access to the xforms cvs? Thanks, Tom Corner --------------------------------------------------- |\/\/\___/\/\/| Carol Anne Corner & \____ o o ____/ Thomas Corner tacorner at chello.at ) ( 27-Nov-2003 09:04:25 Vienna, Austria ( * * ) mailer: xfmail \___/ Web Page: www.corner.chello.at --------------------------------------------------- From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 04:54:05 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 10:54:05 +0100 Subject: [XForms] xforms cvs access In-Reply-To: (tacorner@chello.at's message of "Thu, 27 Nov 2003 09:05:52 +0100 (CET)") References: Message-ID: >>>>> "tacorner" == tacorner writes: tacorner> To subscribers of the xforms list Another question: Is it tacorner> possible to get read-only access to the xforms cvs? Yes. Look here: https://savannah.nongnu.org/cvs/?group=xforms JMarc From angus.leeming at btopenworld.com Thu Nov 27 05:22:42 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 10:22:42 +0000 Subject: [XForms] xforms cvs access In-Reply-To: References: Message-ID: <200311271022.42662.angus.leeming@btopenworld.com> On Thursday 27 November 2003 8:05 am, tacorner at chello.at wrote: Hi, Tom > Another question: Is it possible to get read-only access to the xforms > cvs? Certainly. See http://savannah.nongnu.org/cvs/?group=xforms In summary cvs -d :pserver:anoncvs at subversions.gnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms co xforms Thereafter, shove this in .cvsrc in your home directory: diff -upN rdiff -upN update -dP and "cvs up" should keep you up-to-date. Regards, Angus From angus.leeming at btopenworld.com Thu Nov 27 05:23:41 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 10:23:41 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <20031126220624.GA11680@astrouw.edu.pl> References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311261043.16110.angus.leeming@btopenworld.com> <20031126220624.GA11680@astrouw.edu.pl> Message-ID: <200311271023.41446.angus.leeming@btopenworld.com> On Wednesday 26 November 2003 10:06 pm, Michal Szymanski wrote: > > Could you revert Clive's patch and try the one I appended in my original > > reply to his posting? This patch contains the jpeg and gif enhancements > > and I am more than happy to merge it into the xforms sources. > > I've applied your version of Clive's patch to my home CVS source tree. > The Changelog patch got rejected but both "image" patches succeeded. And > my application reading images can now read JPEG/EXIF files taken from my > digital camera. Then I shall commit it. Many thanks to you both, Angus From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 05:40:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 11:40:20 +0100 Subject: [XForms] Font selector widget In-Reply-To: (tacorner@chello.at's message of "Wed, 26 Nov 2003 17:10:04 +0100 (CET)") References: Message-ID: >>>>> "tacorner" == tacorner writes: tacorner> To subscribers of the xforms list I am thinking about tacorner> writing a font selection widget for xfmail using xforms. tacorner> Does such a thing exist in xforms itself or another xforms tacorner> applications? Any suggestions? I do not know of any... However, an idea would be to try to track the version 2.x of xfce (www.xfce.org) which is a desktop environment (like cde). Versions 1.x and 2.x where based on xforms (whence the name) and I would expect that there is a lot of xforms code to take from there (including a font chooser, maybe). [Later] I have now tracked down a copy: http://www-rocq.inria.fr/~lasgoutt/xfce-2.4.0.tar.gz Unfortunately, there does not seem to be a font chooser in it. However it may be worth looking if there some reusable widgets in the code (the license is not GPL-compatible, but I would be surprised if the author did not allow for a license change on such an old software). JMarc From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 06:32:05 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 12:32:05 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311271023.41446.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 10:23:41 +0000") References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311261043.16110.angus.leeming@btopenworld.com> <20031126220624.GA11680@astrouw.edu.pl> <200311271023.41446.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 26 November 2003 10:06 pm, Michal Szymanski wrote: >> > Could you revert Clive's patch and try the one I appended in my >> original > reply to his posting? This patch contains the jpeg and >> gif enhancements > and I am more than happy to merge it into the >> xforms sources. >> >> I've applied your version of Clive's patch to my home CVS source >> tree. The Changelog patch got rejected but both "image" patches >> succeeded. And my application reading images can now read JPEG/EXIF >> files taken from my digital camera. Angus> Then I shall commit it. Many thanks to you both, Angus tru64 cc does not think that this code is OK: cc -std1 -DHAVE_CONFIG_H -I. -I../../xforms/image -I../lib -DMAKING_FORMS -I../lib -I../../xforms/lib -I/afs/rocq/home/preval/common/include -I/usr/local/include -g -c -MD ../../xforms/image/image_gif.c -DPIC -o .libs/image_gif.lo cc: Warning: ../../xforms/image/image_gif.c, line 672: The scalar variable "incode" is fetched but not initialized. (uninit1) flush_buffer(im, incode); -------------------------^ Indeed, if I read process_lzw_code correctly, the variable incode is not always initialized. Since I do not understand what it stands for, I cannot propose a fix, but obviously this needs to be fixed in some way. JMarc From angus.leeming at btopenworld.com Thu Nov 27 06:49:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 11:49:24 +0000 Subject: [XForms] Re: JPEG/EXIF support? In-Reply-To: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> References: <200311270227.hAR2RL6l001210@vjet.demon.co.uk> Message-ID: <200311271149.24457.angus.leeming@btopenworld.com> On Thursday 27 November 2003 2:27 am, Clive A Stubbings wrote: > > > It fixes a bug in flimage_dup() , > > > > I'm not going to apply this without some discussion. Feel free to explain > > the rationale. > > Well, its a while ago, but if memory serves, I found that if I dup'd an > image then later free'd both copies I got a crash. The crash was because > the first free also closed the files and the second one tried to do the > same again, but the fp's were no longer valid. > > There needs to be only one reference to the fp.. Either it goes in a > shared struct that both 'images' point to, or only one image can be > associated with the file. I'm not sure that 2 'images' and one file > really makes sense anyway. > > FWIW: I duped the image because I wanted to have the original and a > processed copy, so I made a dup and then processed it.. When I'd > finished with both images I free'd both.. Seemed reasonable to me. And to me too. I do something similar in LyX. Here are the relvant parts of my wrapper class. My question to you is, "why doesn't this trigger the crash"? If I make two copies of the image and then invoke flimage_free in the destructor, why don't I run into your problem? class xformsImage { public: xformsImage(): image_(0) {} xformsImage(xformsImage const & other) : image_(0) { if (other.image_) { image_ = flimage_dup(other.image_); image_->u_vdata = this; } } ~xformsImage() { if (image_) flimage_free(image_); } private: /// The xforms container. FL_IMAGE * image_; }; Ahhhhhhh. Because I use a callback function to monitor the loading process and explicitly close the FILE pointers when loading is complete. void xformsImage::statusCB(string const & status_message) { if (status_message.empty()) return; if (prefixIs(status_message, "Done Reading")) { if (image_) flimage_close(image_); finishedLoading(true); } } Anyway, I see the need for your patch or for something like it. Perhaps it would be better to not copy the file pointers in flimage_dup in the first place? Hmmmmmmmm. flimage_dup does NOT copy the FILE pointers. The only place that they are set is in identify_image which in turn is invoked only by flimage_open (in turn invoked by flimage_load). The point is that flimage_dup does not invoke any of these routines. Conclusion: I don't see the need for the patch. No doubt I've got my logic wrong somewhere, so I'd be grateful if you'd have a look at the current xforms sources too... > > > and makes jpeg + gif reading better. > > > > I've applied both these parts to my local tree, albeit with some > > re-factoring to get rid of the goto and some signed-unsigned comparson > > warnings. Could you check to see that all is still as you intended > > (attached). If you could cast your eye over the ChangeLog entry and maybe > > rename 'flush_buffer' to something that makes sense to you, that'd be > > great too... > > Had a fair look at it - seems OK on paper. flush_buffer is fine. The > function flushes completed lines from the working buffer. And Michal says it works, so I have committed it. Many thanks for the patch. > (If you don't like the goto, with hindsight, an else might have been better > ;-) Let's just say I have a pathological hatred of 'goto'. Something to do with maintaining some old Fortran66 code. Regards, Angus From angus.leeming at btopenworld.com Thu Nov 27 07:00:59 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 12:00:59 +0000 Subject: [XForms] JPEG/EXIF support? In-Reply-To: References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311271023.41446.angus.leeming@btopenworld.com> Message-ID: <200311271200.59974.angus.leeming@btopenworld.com> On Thursday 27 November 2003 11:32 am, Jean-Marc Lasgouttes wrote: > Angus> Then I shall commit it. Many thanks to you both, Angus > > tru64 cc does not think that this code is OK: > > cc -std1 -DHAVE_CONFIG_H -I. -I../../xforms/image -I../lib -DMAKING_FORMS > -I../lib -I../../xforms/lib -I/afs/rocq/home/preval/common/include > -I/usr/local/include -g -c -MD ../../xforms/image/image_gif.c -DPIC -o > .libs/image_gif.lo cc: Warning: ../../xforms/image/image_gif.c, line 672: > The scalar variable "incode" is fetched but not initialized. (uninit1) > flush_buffer(im, incode); > -------------------------^ > > Indeed, if I read process_lzw_code correctly, the variable incode is > not always initialized. Since I do not understand what it stands for, > I cannot propose a fix, but obviously this needs to be fixed in some > way. Reading the code again static void flush_buffer(FL_IMAGE * im, int incode) { int i; incode = lbuf - lhead; ... Ie, the first thing that is done in flush_buffer is set incode. So, we have two options: * do not pass incode to the routine and have a local variable instead * pass a pointer to incode. Since the variable incode in process_lzw_code is not static and flush_buffer is the last thing called before returning from process_lzw_code, I think that the first option is sufficient. See attached patch. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: image_giff.diff Type: text/x-diff Size: 1028 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/99303652/attachment-0002.bin From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 07:56:17 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 13:56:17 +0100 Subject: [XForms] JPEG/EXIF support? In-Reply-To: <200311271200.59974.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 12:00:59 +0000") References: <200311242343.hAONhf36001050@vjet.demon.co.uk> <200311271023.41446.angus.leeming@btopenworld.com> <200311271200.59974.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Ie, the first thing that is done in flush_buffer is set incode. Angus> So, we have two options: * do not pass incode to the routine Angus> and have a local variable instead * pass a pointer to incode. Angus> Since the variable incode in process_lzw_code is not static and Angus> flush_buffer is the last thing called before returning from Angus> process_lzw_code, I think that the first option is sufficient. Angus> See attached patch. You are right. JMarc From angus.leeming at btopenworld.com Thu Nov 27 10:23:00 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 15:23:00 +0000 Subject: [XForms] NEWS update Message-ID: <200311271523.00688.angus.leeming@btopenworld.com> As requested... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: news.diff Type: text/x-diff Size: 1451 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/d2c2afb8/attachment-0002.bin From angus.leeming at btopenworld.com Wed Nov 26 11:42:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 26 Nov 2003 16:42:19 +0000 Subject: [XForms] Adding '-dir ' to fdesign Message-ID: <200311261642.19472.angus.leeming@btopenworld.com> See attached. The patch also contains JMarc's changes to fd_forms.c. The only bit I'm unsure about are the initializations in static FL_CMD_OPT fd_cmdopt[] and in static FL_resource fdres[] The rest seems pretty straightforward. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 6372 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031126/3880bca1/attachment-0002.bin From Jean-Marc.Lasgouttes at inria.fr Thu Nov 27 11:08:14 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 Nov 2003 17:08:14 +0100 Subject: [XForms] Adding '-dir ' to fdesign In-Reply-To: <200311261642.19472.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 26 Nov 2003 16:42:19 +0000") References: <200311261642.19472.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list See attached. The patch also Angus> contains JMarc's changes to fd_forms.c. Wow. This one needed 23 hours to appear... JMarc From angus.leeming at btopenworld.com Thu Nov 27 11:26:57 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 16:26:57 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms/fdesign fd_forms.c fd_main.c fd_main.h f... In-Reply-To: References: Message-ID: <200311271626.57490.angus.leeming@btopenworld.com> On Thursday 27 November 2003 3:41 pm, Jean-Marc Lasgouttes wrote: > Angus> Log message: Give fdesign a -dir option. > > I see you've been busy... Well, not sooooooo busy. > +static char const * > +filename_only(char const * filename) > +{ > + char const * ptr = filename + strlen(filename) - 1; > + for (; ptr >= filename; --ptr) { > + if (*ptr == '/') > + return ptr+1; > + } > + return ptr; > +} > + > > Can't you use strrchr() here? Yup. Thanks. Like this? static char const * filename_only(char const * filename) { char const * ptr = strrchr(filename, '/'); if (ptr) return ptr+1; return filename; } > What happens with the external convertors? They get passed '-dir '. > You should also document the new switch in fdesign man page. Granted. Angus From angus.leeming at btopenworld.com Thu Nov 27 13:15:55 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 18:15:55 +0000 Subject: [XForms] Re: [Xforms-cvs] xforms/fdesign fd_forms.c fd_main.c fd_main.h f... In-Reply-To: <200311271626.57490.angus.leeming@btopenworld.com> References: <200311271626.57490.angus.leeming@btopenworld.com> Message-ID: <200311271815.55461.angus.leeming@btopenworld.com> On Thursday 27 November 2003 4:26 pm, Angus Leeming wrote: > > Can't you use strrchr() here? > Yup. Thanks. Like this? [snip...] > > You should also document the new switch in fdesign man page. > Granted. Patch attached, FYI. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 2080 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/21408007/attachment-0002.bin From angus.leeming at btopenworld.com Thu Nov 27 16:24:57 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 21:24:57 +0000 Subject: [XForms] Getting rid of generated files Message-ID: <200311272124.57343.angus.leeming@btopenworld.com> Attached is a patch that uses the new -dir option of fdesign to get rid of demos/fd/button_gui.[ch] from the cvs repository. I've checked that all works fine from a 'make distdir' tree as well. Indeed, almost all of the .[ch] files in demos/fd can be removed in the same manner. The only ones that must remain are fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. Fdesign does not have the ability currently to #include user-specifed files. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: demos.diff Type: text/x-diff Size: 7226 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031127/4e33e2b5/attachment-0002.bin From angus.leeming at btopenworld.com Thu Nov 27 17:24:19 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 22:24:19 +0000 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272124.57343.angus.leeming@btopenworld.com> References: <200311272124.57343.angus.leeming@btopenworld.com> Message-ID: <200311272224.19706.angus.leeming@btopenworld.com> On Thursday 27 November 2003 9:24 pm, Angus Leeming wrote: > To subscribers of the xforms list > Indeed, almost all of the .[ch] files in demos/fd can be removed > in the same manner. The only ones that must remain are > fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend > on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. > Fdesign does not have the ability currently to #include user-specifed files. Actually, it transpires that I can remove these files too. The trick is to ensure that fd/ibrowser_gui.c is not compiled on its own, but rather that it is #included by ibrowser.c. (This trick was much-used in the demos dir; I have retained it only for the compilation of ibrowser.c and itest.c.) Angus From angus.leeming at btopenworld.com Thu Nov 27 17:31:24 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 Nov 2003 22:31:24 +0000 Subject: [XForms] Towards xforms 1.1 Message-ID: <200311272231.24152.angus.leeming@btopenworld.com> Ok, Jean-Marc. I think that we're getting closer, don't you? What else do you have on your to-do list? Regards, Angus From xforms2 at vjet.demon.co.uk Thu Nov 27 20:37:31 2003 From: xforms2 at vjet.demon.co.uk (Clive A Stubbings) Date: Fri, 28 Nov 2003 01:37:31 GMT Subject: [XForms] Re: JPEG/EXIF support? Message-ID: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> Hi Angus, I built the original fix a long time ago, possibly on one of the really early open releases. It is always possible that it has been subsequently fixed elsewhere. The old flimage_dup did FL_IMAGE * flimage_dup_(FL_IMAGE * sim, int pix) { ... FL_IMAGE *im = flimage_alloc(); ... memcpy(im, sim, sizeof(*im)); Which seems a bit iffy.. I've just checked - thats is also how it is in 1.0. Can you check the current version? Cheers Clive > On Thursday 27 November 2003 2:27 am, Clive A Stubbings wrote: > > > > It fixes a bug in flimage_dup() , > > > > > > I'm not going to apply this without some discussion. Feel free to explain > > > the rationale. > > > > Well, its a while ago, but if memory serves, I found that if I dup'd an > > image then later free'd both copies I got a crash. The crash was because > > the first free also closed the files and the second one tried to do the > > same again, but the fp's were no longer valid. > > > > There needs to be only one reference to the fp.. Either it goes in a > > shared struct that both 'images' point to, or only one image can be > > associated with the file. I'm not sure that 2 'images' and one file > > really makes sense anyway. > > > > FWIW: I duped the image because I wanted to have the original and a > > processed copy, so I made a dup and then processed it.. When I'd > > finished with both images I free'd both.. Seemed reasonable to me. > > And to me too. I do something similar in LyX. Here are the relvant parts of my > wrapper class. My question to you is, "why doesn't this trigger the crash"? > If I make two copies of the image and then invoke flimage_free in the > destructor, why don't I run into your problem? > > class xformsImage { > public: > xformsImage(): image_(0) {} > xformsImage(xformsImage const & other) : image_(0) { > if (other.image_) { > image_ = flimage_dup(other.image_); > image_->u_vdata = this; > } > } > > ~xformsImage() { > if (image_) > flimage_free(image_); > } > private: > /// The xforms container. > FL_IMAGE * image_; > }; > > Ahhhhhhh. Because I use a callback function to monitor the loading process and > explicitly close the FILE pointers when loading is complete. > > void xformsImage::statusCB(string const & status_message) > { > if (status_message.empty()) > return; > > if (prefixIs(status_message, "Done Reading")) { > if (image_) > flimage_close(image_); > finishedLoading(true); > } > } > > Anyway, I see the need for your patch or for something like it. > > Perhaps it would be better to not copy the file pointers in flimage_dup in the > first place? Hmmmmmmmm. flimage_dup does NOT copy the FILE pointers. The only > place that they are set is in identify_image which in turn is invoked only by > flimage_open (in turn invoked by flimage_load). The point is that flimage_dup > does not invoke any of these routines. > > Conclusion: I don't see the need for the patch. > No doubt I've got my logic wrong somewhere, so I'd be grateful if you'd have a > look at the current xforms sources too... > > > > > > > and makes jpeg + gif reading better. > > > > > > I've applied both these parts to my local tree, albeit with some > > > re-factoring to get rid of the goto and some signed-unsigned comparson > > > warnings. Could you check to see that all is still as you intended > > > (attached). If you could cast your eye over the ChangeLog entry and maybe > > > rename 'flush_buffer' to something that makes sense to you, that'd be > > > great too... > > > > Had a fair look at it - seems OK on paper. flush_buffer is fine. The > > function flushes completed lines from the working buffer. > > And Michal says it works, so I have committed it. Many thanks for the patch. > > > (If you don't like the goto, with hindsight, an else might have been better > > ;-) > > Let's just say I have a pathological hatred of 'goto'. Something to do with > maintaining some old Fortran66 code. > > Regards, > Angus > > From angus.leeming at btopenworld.com Fri Nov 28 04:16:22 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 09:16:22 +0000 Subject: [XForms] Re: JPEG/EXIF support? In-Reply-To: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> References: <200311280137.hAS1bVlk001626@vjet.demon.co.uk> Message-ID: <200311280916.22028.angus.leeming@btopenworld.com> On Friday 28 November 2003 1:37 am, Clive A Stubbings wrote: > Hi Angus, > > I built the original fix a long time ago, possibly on one of the really > early open releases. It is always possible that it has been subsequently > fixed elsewhere. > > The old flimage_dup did > > FL_IMAGE * > flimage_dup_(FL_IMAGE * sim, int pix) > { > ... > FL_IMAGE *im = flimage_alloc(); > ... > memcpy(im, sim, sizeof(*im)); > > > Which seems a bit iffy.. I've just checked - thats is also how it is > in 1.0. Can you check the current version? Sigh! Yes, it still does. However, it goes on: memcpy(im, sim, sizeof(*im)); /* reset all pointers */ im->red = im->green = im->blue = im->alpha = 0; im->red_lut = im->green_lut = im->blue_lut = im->alpha_lut = 0; im->gray = 0; im->ci = 0; im->red16 = im->green16 = im->blue16 = im->alpha16 = 0; im->packed = 0; im->wlut = 0; im->llut[0] = im->llut[1] = im->llut[2] = 0; im->extra_io_info = 0; im->info = 0; There are actually a heap more pointers that these defined in the struct, but I guess that it's here that we should reset the fpin and fpout pointers, no? Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:15:43 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:15:43 +0100 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272224.19706.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:24:19 +0000") References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Thursday 27 November 2003 9:24 pm, Angus Leeming wrote: >> To subscribers of the xforms list >> Indeed, almost all of the .[ch] files in demos/fd can be removed in >> the same manner. The only ones that must remain are >> fd/ibrowser_gui.[ch] and fd/is_gui.[ch] because the .c files depend >> on enum values defined in image/flimage.h. Eg FL_IMAGE_MONO. >> Fdesign does not have the ability currently to #include >> user-specifed files. Angus> Actually, it transpires that I can remove these files too. The Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on Angus> its own, but rather that it is #included by ibrowser.c. (This Angus> trick was much-used in the demos dir; I have retained it only Angus> for the compilation of ibrowser.c and itest.c.) Excellent. From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:15:19 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:15:19 +0100 Subject: [XForms] Towards xforms 1.1 In-Reply-To: <200311272231.24152.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:31:24 +0000") References: <200311272231.24152.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Ok, Jean-Marc. I think that Angus> we're getting closer, don't you? What else do you have on your Angus> to-do list? In no particular order: - We've got to decide on a version number. I suggest something like 1.0.90. The m4 code needs to be changed probably, as we seem to have two notions of current version in configure.ac. - we may need to support dlls under windows (but this can maybe wait for next version). The key is to use AC_LIBTOOL_WIN32_DLL: Macro: AC_LIBTOOL_WIN32_DLL This macro should be used if the package has been ported to build clean dlls on win32 platforms. Usually this means that any library data items are exported with __declspec(dllexport) and imported with __declspec(dllimport). If this macro is not used, libtool will assume that the package libraries are not dll clean and will build only static libraries on win32 hosts. This macro must be called before AC_PROG_LIBTOOL, and provision must be made to pass `-no-undefined' to libtool in link mode from the package Makefile. Naturally, if you pass `-no-undefined', you must ensure that all the library symbols really are defined at link time! Actually, I do not know whether xforms 1.0 did build as dll for cygwin. - I still have a problem to fix for proper handling of RETSIGTYPE in lib/signal.c. I did not find any clear solution in other programs... Maybe a little bit of autoconf magic will suffice. - we need to update README a little bit more (there is a duplicated part...) - besides the standard installation instructions in INSTALL, should we document things like --enable-demos --enable-gl and friends? JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:17:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:17:20 +0100 Subject: [XForms] problem with autoconf in RH9 In-Reply-To: <20031124172821.GA9534@astrouw.edu.pl> (Michal Szymanski's message of "Mon, 24 Nov 2003 18:28:21 +0100") References: <20031123153548.GA18821@astrouw.edu.pl> <20031124172821.GA9534@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: >> Try to run ./autogen.sh instead. Michal> Thanks, it worked. I guess it might be worth putting into Michal> INSTALL file which now is somewhat misleading. I think the right thing to do is to have a README-cvs file which is in cvs (and gives the info) but is not distributed... JMarc From angus.leeming at btopenworld.com Fri Nov 28 12:32:35 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:32:35 +0000 Subject: [XForms] Towards xforms 1.1 In-Reply-To: References: <200311272231.24152.angus.leeming@btopenworld.com> Message-ID: <200311281732.35512.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:15 pm, Jean-Marc Lasgouttes wrote: > Angus> To subscribers of the xforms list Ok, Jean-Marc. I think that > Angus> we're getting closer, don't you? What else do you have on your > Angus> to-do list? > > In no particular order: > > - We've got to decide on a version number. I suggest something like > 1.0.90. Ok. > The m4 code needs to be changed probably, as we seem to have > two notions of current version in configure.ac. Is this the difference between the 'release' version and the 'indication of the binary compatibility of the libraries' version thingy that confused us way back when? Is there no place that we can ask for advice? Someone must understand this stuff. > - we may need to support dlls under windows (but this can maybe wait > for next version). I don't know about you, but I think of this release as the 'autotools' release. Would be nice therefore if we finished it off before release and never had to worry about any of this crap ever again... > - we need to update README a little bit more (there is a duplicated > part...) I'll have a go. > - besides the standard installation instructions in INSTALL, should we > document things like --enable-demos --enable-gl and friends? Yes. Where would it go? In INSTALL, or is that simply the generic stuff. Incidentally, (now that I have repaired your breakage of 'make rpmdist' ;-P), would it make sense to create an xforms-demos src rpm. I guess that there is little point creating a binary of same... Hmmm, I'm not sure that would work, since the Makefile assumes that fdesign is to be found in ../fdesign/fdesign. Let's leave that then ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:28:13 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:28:13 +0100 Subject: [XForms] Getting rid of generated files In-Reply-To: <200311272224.19706.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 Nov 2003 22:24:19 +0000") References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: mk.log Type: application/octet-stream Size: 4770 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20031128/424be7d7/attachment-0002.obj From angus.leeming at btopenworld.com Fri Nov 28 12:45:56 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:45:56 +0000 Subject: [XForms] Getting rid of generated files In-Reply-To: References: <200311272124.57343.angus.leeming@btopenworld.com> <200311272224.19706.angus.leeming@btopenworld.com> Message-ID: <200311281745.56835.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:28 pm, Jean-Marc Lasgouttes wrote: > Angus> Actually, it transpires that I can remove these files too. The > Angus> trick is to ensure that fd/ibrowser_gui.c is not compiled on > Angus> its own, but rather that it is #included by ibrowser.c. (This > Angus> trick was much-used in the demos dir; I have retained it only > Angus> for the compilation of ibrowser.c and itest.c.) > > Unfortunately, it does not work here. Why? Genuinely no problems here. Question: where is FL_NORMAL_FORMBROWSER defined? Answer lib/include/forms.h Here the first 5 lines of formbrowser_gui.c are: /* Form definition file generated with fdesign. */ #include "forms.h" #include #include "formbrowser_gui.h" Ie, I don't see why it is failing. I'm a bit upset about the subsequent warnings about two many initializers too... Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Nov 28 12:38:20 2003 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 Nov 2003 18:38:20 +0100 Subject: [XForms] Towards xforms 1.1 In-Reply-To: <200311281732.35512.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 Nov 2003 17:32:35 +0000") References: <200311272231.24152.angus.leeming@btopenworld.com> <200311281732.35512.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I don't know about you, but I think of this release as the Angus> 'autotools' release. Would be nice therefore if we finished it Angus> off before release and never had to worry about any of this Angus> crap ever again... Then we need to get Kayvan to test it, but we could maybe release 1.0.90 and implement libtol support from there. >> - besides the standard installation instructions in INSTALL, should >> we document things like --enable-demos --enable-gl and friends? Angus> Yes. Where would it go? In INSTALL, or is that simply the Angus> generic stuff. I do not know. INSTALL is supposed (in GNU world) to come straight from autoconf (I do not know why). I do not know what is the gnuly correct place. Angus> Incidentally, (now that I have repaired your breakage of 'make Angus> rpmdist' ;-P), would it make sense to create an xforms-demos Angus> src rpm. I guess that there is little point creating a binary Angus> of same... Hmmm, I'm not sure that would work, since the Angus> Makefile assumes that fdesign is to be found in Angus> ../fdesign/fdesign. Yes, the sources are not so large. JMarc PS: We should also get the docs on the web page. Also, should we have a document ``how to adapt your application to 1.1'', or is everything just supposed to work magically? From angus.leeming at btopenworld.com Fri Nov 28 12:55:18 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 Nov 2003 17:55:18 +0000 Subject: [XForms] Towards xforms 1.1 In-Reply-To: References: <200311272231.24152.angus.leeming@btopenworld.com> <200311281732.35512.angus.leeming@btopenworld.com> Message-ID: <200311281755.18644.angus.leeming@btopenworld.com> On Friday 28 November 2003 5:38 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> I don't know about you, but I think of this release as the > Angus> 'autotools' release. Would be nice therefore if we finished it > Angus> off before release and never had to worry about any of this > Angus> crap ever again... > > Then we need to get Kayvan to test it, but we could maybe release > 1.0.90 and implement libtol support from there. Ok. > >> - besides the standard installation instructions in INSTALL, should > >> we document things like --enable-demos --enable-gl and friends? > > Angus> Yes. Where would it go? In INSTALL, or is that simply the > Angus> generic stuff. > > I do not know. INSTALL is supposed (in GNU world) to come straight > from autoconf (I do not know why). I do not know what is the gnuly > correct place. Who to ask? > PS: We should also get the docs on the web page. Also, should we have > a document ``how to adapt your application to 1.1'', or is everything > just supposed to work magically? We have been promised these docs since the day xforms 1.0 was released. I really don't know what the problem is :-( Once we get them, it would make sense to invest some time in a homepage on savannah. Angus From angus.leeming at btopenworld.com Sat Nov 29 13:22:36 2003 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 29 Nov 2003 18:22:36 +0000 Subject: [XForms] Re: [Xforms-cvs] First time CVS download. In-Reply-To: <3FC8DBA2.108@omensys.ca> References: <3FC8DBA2.108@omensys.ca> Message-ID: <200311291822.36936.angus.leeming@btopenworld.com> On Saturday 29 November 2003 5:47 pm, Serge B Bromow wrote: > I just tried to download the CVS tree for the first time to a RH7.3 OS. > There seems to be missing files. i.e "forms.h" and more. Generated from the smaller header files in lib/include. > Here is the script I used to retrieve the files and the output from the > script. The script looks Ok. Personally I would have $ ./autogen.sh $ mkdir build && cd build $ ../configure --enable-demos --enable-maintainer-mode $ make > Needless to say, "./configure" na d "make" fail. [snip most of the script output...] Using autoconf (GNU Autoconf) 2.58 Well, that certainly isn't part of RH7.3 ;-) Generate acinclude.m4... done. Building macros... . done. Building config header template... . /usr/bin/m4: configure.in: No such file or directory Ahhhh. We don't support the old version of autoconf (2.13 and below) that use configure.in. Instead, we require you to use autoconf 2.52 or above that uses configure.ac. The fact that your autoconf is searching for configure.in does not square with the message above saying that you are using autoconf 2.58. Jean-Marc, you're the autotools expert around here. Any ideas? > Am I missing something? Any thoughts? > > Serge Angus (cross-posting this to the xforms maiing list to ensure we get JMarc's attention.) From serge at omensys.ca Sat Nov 29 12:32:54 2003 From: serge at omensys.ca (Serge B Bromow) Date: Sat, 29 Nov 2003 12:32:54 -0500 Subject: [XForms] CVS Update Message-ID: <3FC8D846.1050305@omensys.ca> I just tried to download the CVS tree for the first time to a RH7.3 OS. There seem to be missing files. i.e "forms.h" and more. Here is the script I used to retrieve to file and the output from the script. Am I missing something? Any thoughts? Serge ----------------------- Script cd /home/serge rm -rf xforms cvs -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms login cvs -z3 -d:pserver:anoncvs at savannah.nongnu.org:/cvsroot/xforms co xforms cd xforms ./autogen.sh ./configure make ----------- Output [serge at daph serge]$ ./getxforms \Logging in to :pserver:anoncvs at savannah.nongnu.org:2401/cvsroot/xforms CVS password: cvs server: Updating xforms U xforms/.cvsignore U xforms/COPYING.LIB U xforms/ChangeLog U xforms/Copyright U xforms/INSTALL U xforms/Makefile.am U xforms/NEWS U xforms/README U xforms/README.OS2 U xforms/autogen.sh U xforms/configure.ac U xforms/xforms.spec.in cvs server: Updating xforms/NT U xforms/NT/libxforms.dsp U xforms/NT/xformsAll.dsw cvs server: Updating xforms/X11 cvs server: Updating xforms/config U xforms/config/.cvsignore U xforms/config/Makefile.am U xforms/config/common.am U xforms/config/config.guess U xforms/config/config.sub U xforms/config/cygwin.m4 U xforms/config/depcomp U xforms/config/libtool.m4 U xforms/config/ltmain.sh U xforms/config/xformsinclude.m4 cvs server: Updating xforms/demos U xforms/demos/.cvsignore U xforms/demos/01Readme U xforms/demos/Makefile.am U xforms/demos/arrowbutton.c U xforms/demos/bm1.xbm U xforms/demos/bm2.xbm U xforms/demos/borderwidth.c U xforms/demos/boxtype.c U xforms/demos/browserall.c U xforms/demos/browserop.c U xforms/demos/buttonall.c U xforms/demos/butttypes.c U xforms/demos/canvas.c U xforms/demos/chartall.c U xforms/demos/chartstrip.c U xforms/demos/choice.c U xforms/demos/colbrowser.c U xforms/demos/colsel.c U xforms/demos/colsel1.c U xforms/demos/counter.c U xforms/demos/crab.xpm U xforms/demos/crab45.xpm U xforms/demos/crab_tran.xpm U xforms/demos/crossbut.c U xforms/demos/crossbut.h U xforms/demos/cursor.c U xforms/demos/demo.c U xforms/demos/demo.menu U xforms/demos/demo05.c U xforms/demos/demo06.c U xforms/demos/demo27.c U xforms/demos/demo33.c U xforms/demos/demotest.c U xforms/demos/demotest2.c U xforms/demos/demotest3.c U xforms/demos/dirlist.c U xforms/demos/fbrowse.c U xforms/demos/fbrowse1.c U xforms/demos/fdial.c U xforms/demos/flclock.c U xforms/demos/folder.c U xforms/demos/fonts.c U xforms/demos/formbrowser.c U xforms/demos/free1.c U xforms/demos/freedraw.c U xforms/demos/freedraw_leak.c U xforms/demos/gl.c U xforms/demos/glwin.c U xforms/demos/goodies.c U xforms/demos/group.c U xforms/demos/ibrowser.c U xforms/demos/iconify.c U xforms/demos/iconvert.1 U xforms/demos/iconvert.c U xforms/demos/inputall.c U xforms/demos/invslider.c U xforms/demos/itest.c U xforms/demos/lalign.c U xforms/demos/ldial.c U xforms/demos/ll.c U xforms/demos/longlabel.c U xforms/demos/menu.c U xforms/demos/menubar.c U xforms/demos/minput.c U xforms/demos/minput2.c U xforms/demos/multilabel.c U xforms/demos/ndial.c U xforms/demos/newbutton.c U xforms/demos/newmail.xbm U xforms/demos/nnn.c U xforms/demos/nomail.xbm U xforms/demos/objinactive.c U xforms/demos/objpos.c U xforms/demos/objreturn.c U xforms/demos/picture.xbm U xforms/demos/pmbrowse.c U xforms/demos/popup.c U xforms/demos/porsche.xpm U xforms/demos/positioner.c U xforms/demos/positionerXOR.c U xforms/demos/preemptive.c U xforms/demos/pup.c U xforms/demos/pushbutton.c U xforms/demos/pushme.c U xforms/demos/rescale.c U xforms/demos/scrollbar.c U xforms/demos/secretinput.c U xforms/demos/sld_radio.c U xforms/demos/sldinactive.c U xforms/demos/sldsize.c U xforms/demos/sliderall.c U xforms/demos/srs.xbm U xforms/demos/strsize.c U xforms/demos/symbols.c U xforms/demos/test.ps U xforms/demos/test.xpm U xforms/demos/thumb.c U xforms/demos/thumbwheel.c U xforms/demos/timer.c U xforms/demos/timer.h U xforms/demos/timer2.c U xforms/demos/timerprec.c U xforms/demos/touchbutton.c U xforms/demos/wwwl.c U xforms/demos/xconq.xpm U xforms/demos/xterm.xpm U xforms/demos/xyover U xforms/demos/xyplotactive.c U xforms/demos/xyplotall.c U xforms/demos/xyplotover.c U xforms/demos/yesno.c U xforms/demos/yesno_cb.c cvs server: Updating xforms/demos/fd U xforms/demos/fd/.cvsignore U xforms/demos/fd/Makefile.am U xforms/demos/fd/buttons_gui.fd U xforms/demos/fd/butttypes_gui.fd U xforms/demos/fd/dim_porsche.xpm U xforms/demos/fd/fbtest_gui.fd U xforms/demos/fd/folder_gui.fd U xforms/demos/fd/formbrowser_gui.fd U xforms/demos/fd/ibrowser_gui.fd U xforms/demos/fd/inputall_gui.fd U xforms/demos/fd/is_gui.fd U xforms/demos/fd/pmbrowse_gui.fd U xforms/demos/fd/porsche.xpm U xforms/demos/fd/scrollbar_gui.fd U xforms/demos/fd/twheel_gui.fd cvs server: Updating xforms/exports cvs server: Updating xforms/fd2ps U xforms/fd2ps/.cvsignore U xforms/fd2ps/Change U xforms/fd2ps/Makefile.am U xforms/fd2ps/Readme U xforms/fd2ps/align.c U xforms/fd2ps/fd2ps.c U xforms/fd2ps/fd2ps.h U xforms/fd2ps/fd2ps.man U xforms/fd2ps/flsupport.c U xforms/fd2ps/global.h U xforms/fd2ps/image2ps.c U xforms/fd2ps/load.c U xforms/fd2ps/papers.c U xforms/fd2ps/pscol.c U xforms/fd2ps/psdraw.c U xforms/fd2ps/psobj.c U xforms/fd2ps/pstext.c U xforms/fd2ps/readxpm.c U xforms/fd2ps/sys.c U xforms/fd2ps/version.c U xforms/fd2ps/xbmtops.c U xforms/fd2ps/xpmtops.c cvs server: Updating xforms/fd2ps/test U xforms/fd2ps/test/.cvsignore U xforms/fd2ps/test/Makefile.am U xforms/fd2ps/test/all.fd U xforms/fd2ps/test/allcmm.fd U xforms/fd2ps/test/allpoint.fd U xforms/fd2ps/test/bm1.xbm U xforms/fd2ps/test/buttons.fd U xforms/fd2ps/test/crab.xpm U xforms/fd2ps/test/dial.fd U xforms/fd2ps/test/fd_logo.xpm U xforms/fd2ps/test/folder_gui.fd U xforms/fd2ps/test/junk.fd U xforms/fd2ps/test/parameter.xpm U xforms/fd2ps/test/picture.xbm U xforms/fd2ps/test/sym.fd U xforms/fd2ps/test/xconq.xpm cvs server: Updating xforms/fdesign U xforms/fdesign/.cvsignore U xforms/fdesign/Change U xforms/fdesign/Makefile.am U xforms/fdesign/Readme U xforms/fdesign/fd_attribs.c U xforms/fdesign/fd_control.c U xforms/fdesign/fd_fake.c U xforms/fdesign/fd_file.c U xforms/fdesign/fd_forms.c U xforms/fdesign/fd_groups.c U xforms/fdesign/fd_help.c U xforms/fdesign/fd_help.h U xforms/fdesign/fd_initforms.c U xforms/fdesign/fd_main.c U xforms/fdesign/fd_main.h U xforms/fdesign/fd_names.c U xforms/fdesign/fd_objects.c U xforms/fdesign/fd_pallette.c U xforms/fdesign/fd_printC.c U xforms/fdesign/fd_rubber.c U xforms/fdesign/fd_select.c U xforms/fdesign/fd_spec.c U xforms/fdesign/fd_spec.h U xforms/fdesign/fd_super.c U xforms/fdesign/fd_util.c U xforms/fdesign/fdesign.man U xforms/fdesign/sp_browser.c U xforms/fdesign/sp_button.c U xforms/fdesign/sp_choice.c U xforms/fdesign/sp_counter.c U xforms/fdesign/sp_dial.c U xforms/fdesign/sp_freeobj.c U xforms/fdesign/sp_menu.c U xforms/fdesign/sp_pixmap.c U xforms/fdesign/sp_positioner.c U xforms/fdesign/sp_scrollbar.c U xforms/fdesign/sp_slider.c U xforms/fdesign/sp_twheel.c U xforms/fdesign/sp_xyplot.c U xforms/fdesign/viewforms.c U xforms/fdesign/viewforms.fd U xforms/fdesign/viewforms.h U xforms/fdesign/viewforms_main.c U xforms/fdesign/xpm.h cvs server: Updating xforms/fdesign/fd U xforms/fdesign/fd/.cvsignore U xforms/fdesign/fd/Makefile.am U xforms/fdesign/fd/pallette.c U xforms/fdesign/fd/pallette.fd U xforms/fdesign/fd/pallette.h U xforms/fdesign/fd/ui_attrib.c U xforms/fdesign/fd/ui_attrib.fd U xforms/fdesign/fd/ui_attrib.h U xforms/fdesign/fd/ui_objs.c U xforms/fdesign/fd/ui_objs.fd U xforms/fdesign/fd/ui_objs.h U xforms/fdesign/fd/ui_theforms.c U xforms/fdesign/fd/ui_theforms.fd U xforms/fdesign/fd/ui_theforms.h cvs server: Updating xforms/fdesign/fd4test U xforms/fdesign/fd4test/.cvsignore U xforms/fdesign/fd4test/Makefile.am U xforms/fdesign/fd4test/inittest.fd U xforms/fdesign/fd4test/testfd.fd cvs server: Updating xforms/fdesign/notes U xforms/fdesign/notes/.cvsignore U xforms/fdesign/notes/Makefile.am U xforms/fdesign/notes/spec_algo cvs server: Updating xforms/fdesign/spec U xforms/fdesign/spec/.cvsignore U xforms/fdesign/spec/Makefile.am U xforms/fdesign/spec/browser_spec.c U xforms/fdesign/spec/browser_spec.fd U xforms/fdesign/spec/browser_spec.h U xforms/fdesign/spec/button_spec.c U xforms/fdesign/spec/button_spec.fd U xforms/fdesign/spec/button_spec.h U xforms/fdesign/spec/choice_spec.c U xforms/fdesign/spec/choice_spec.fd U xforms/fdesign/spec/choice_spec.h U xforms/fdesign/spec/counter_spec.c U xforms/fdesign/spec/counter_spec.fd U xforms/fdesign/spec/counter_spec.h U xforms/fdesign/spec/dial_spec.c U xforms/fdesign/spec/dial_spec.fd U xforms/fdesign/spec/dial_spec.h U xforms/fdesign/spec/free_spec.c U xforms/fdesign/spec/free_spec.fd U xforms/fdesign/spec/free_spec.h U xforms/fdesign/spec/freeobj_spec.c U xforms/fdesign/spec/freeobj_spec.fd U xforms/fdesign/spec/freeobj_spec.h U xforms/fdesign/spec/menu_spec.c U xforms/fdesign/spec/menu_spec.fd U xforms/fdesign/spec/menu_spec.h U xforms/fdesign/spec/pixmap_spec.c U xforms/fdesign/spec/pixmap_spec.fd U xforms/fdesign/spec/pixmap_spec.h U xforms/fdesign/spec/positioner_spec.c U xforms/fdesign/spec/positioner_spec.fd U xforms/fdesign/spec/positioner_spec.h U xforms/fdesign/spec/scrollbar_spec.c U xforms/fdesign/spec/scrollbar_spec.fd U xforms/fdesign/spec/scrollbar_spec.h U xforms/fdesign/spec/slider_spec.c U xforms/fdesign/spec/slider_spec.fd U xforms/fdesign/spec/slider_spec.h U xforms/fdesign/spec/twheel_spec.c U xforms/fdesign/spec/twheel_spec.fd U xforms/fdesign/spec/twheel_spec.h U xforms/fdesign/spec/xyplot_spec.c U xforms/fdesign/spec/xyplot_spec.fd U xforms/fdesign/spec/xyplot_spec.h cvs server: Updating xforms/fdesign/xpm U xforms/fdesign/xpm/.cvsignore U xforms/fdesign/xpm/Makefile.am U xforms/fdesign/xpm/allbutton.fd U xforms/fdesign/xpm/bm1.xbm U xforms/fdesign/xpm/bottom.xbm U xforms/fdesign/xpm/box.xpm U xforms/fdesign/xpm/br.xpm U xforms/fdesign/xpm/butt.xpm U xforms/fdesign/xpm/chart.xpm U xforms/fdesign/xpm/check.xpm U xforms/fdesign/xpm/choice.fd U xforms/fdesign/xpm/choice.xpm U xforms/fdesign/xpm/clock.xpm U xforms/fdesign/xpm/cnt.xpm U xforms/fdesign/xpm/crab.xpm U xforms/fdesign/xpm/crab_focus.xpm U xforms/fdesign/xpm/dial.xpm U xforms/fdesign/xpm/fd_logo.xpm U xforms/fdesign/xpm/frame.xpm U xforms/fdesign/xpm/glcan.xpm U xforms/fdesign/xpm/hcenter.xbm U xforms/fdesign/xpm/left.xbm U xforms/fdesign/xpm/lightb.xpm U xforms/fdesign/xpm/menu.xpm U xforms/fdesign/xpm/misc.fd U xforms/fdesign/xpm/nomail.xbm U xforms/fdesign/xpm/picture.xbm U xforms/fdesign/xpm/picture1.xbm U xforms/fdesign/xpm/porsche.xpm U xforms/fdesign/xpm/pos.xpm U xforms/fdesign/xpm/r3dbut.xpm U xforms/fdesign/xpm/right.xbm U xforms/fdesign/xpm/roundb.xpm U xforms/fdesign/xpm/scb.xpm U xforms/fdesign/xpm/sld.xpm U xforms/fdesign/xpm/static.fd U xforms/fdesign/xpm/tab.xpm U xforms/fdesign/xpm/text.xpm U xforms/fdesign/xpm/timer.xpm U xforms/fdesign/xpm/top.xbm U xforms/fdesign/xpm/twheel.xpm U xforms/fdesign/xpm/val.fd U xforms/fdesign/xpm/vals.xpm U xforms/fdesign/xpm/vcenter.xbm U xforms/fdesign/xpm/xconq.xpm U xforms/fdesign/xpm/xconq1.xpm U xforms/fdesign/xpm/xyplot.xpm cvs server: Updating xforms/gl U xforms/gl/.cvsignore U xforms/gl/Makefile.am U xforms/gl/glcanvas.c U xforms/gl/glcanvas.h cvs server: Updating xforms/image U xforms/image/.cvsignore U xforms/image/Makefile.am U xforms/image/flimage.h U xforms/image/flimage_int.h U xforms/image/image.c U xforms/image/image_bmp.c U xforms/image/image_combine.c U xforms/image/image_convolve.c U xforms/image/image_crop.c U xforms/image/image_disp.c U xforms/image/image_fits.c U xforms/image/image_genesis.c U xforms/image/image_gif.c U xforms/image/image_gzip.c U xforms/image/image_io_filter.c U xforms/image/image_jpeg.c U xforms/image/image_jquant.c U xforms/image/image_marker.c U xforms/image/image_oquant.c U xforms/image/image_png.c U xforms/image/image_pnm.c U xforms/image/image_postscript.c U xforms/image/image_proc.c U xforms/image/image_replace.c U xforms/image/image_rotate.c U xforms/image/image_scale.c U xforms/image/image_sgi.c U xforms/image/image_text.c U xforms/image/image_tiff.c U xforms/image/image_type.c U xforms/image/image_warp.c U xforms/image/image_xbm.c U xforms/image/image_xpm.c U xforms/image/image_xwd.c U xforms/image/matrix.c U xforms/image/postscript.c U xforms/image/ps_core.c U xforms/image/ps_draw.c U xforms/image/ps_text.c U xforms/image/rgb_db.c cvs server: Updating xforms/lib U xforms/lib/.cvsignore U xforms/lib/Change U xforms/lib/Makefile.am U xforms/lib/align.c U xforms/lib/appwin.c U xforms/lib/asyn_io.c U xforms/lib/be.c U xforms/lib/bitmap.c U xforms/lib/box.c U xforms/lib/browser.c U xforms/lib/button.c U xforms/lib/canvas.c U xforms/lib/chart.c U xforms/lib/checkbut.c U xforms/lib/child.c U xforms/lib/choice.c U xforms/lib/clipboard.c U xforms/lib/clock.c U xforms/lib/cmd_br.c U xforms/lib/colsel.c U xforms/lib/combo.c U xforms/lib/counter.c U xforms/lib/cursor.c U xforms/lib/dial.c U xforms/lib/dirent_vms.h U xforms/lib/display.c U xforms/lib/dmalloc.h U xforms/lib/errmsg.c U xforms/lib/events.c U xforms/lib/extern.h U xforms/lib/flcolor.c U xforms/lib/fldraw.c U xforms/lib/flinternal.h U xforms/lib/flresource.c U xforms/lib/flsnprintf.c U xforms/lib/flvisual.c U xforms/lib/fonts.c U xforms/lib/formbrowser.c U xforms/lib/forms.c U xforms/lib/frame.c U xforms/lib/free.c U xforms/lib/fselect.c U xforms/lib/global.h U xforms/lib/goodie_alert.c U xforms/lib/goodie_choice.c U xforms/lib/goodie_input.c U xforms/lib/goodie_msg.c U xforms/lib/goodie_salert.c U xforms/lib/goodie_sinput.c U xforms/lib/goodie_yesno.c U xforms/lib/goodies.c U xforms/lib/input.c U xforms/lib/interpol.c U xforms/lib/keyboard.c U xforms/lib/labelbut.c U xforms/lib/lframe.c U xforms/lib/lightbut.c U xforms/lib/listdir.c U xforms/lib/local.h U xforms/lib/menu.c U xforms/lib/n2a.c U xforms/lib/objects.c U xforms/lib/oneliner.c U xforms/lib/pixmap.c U xforms/lib/positioner.c U xforms/lib/read2lsbf.c U xforms/lib/read2msbf.c U xforms/lib/read4lsb.c U xforms/lib/read4msb.c U xforms/lib/readint.c U xforms/lib/round3d.c U xforms/lib/roundbut.c U xforms/lib/scrollbar.c U xforms/lib/scrollbut.c U xforms/lib/signal.c U xforms/lib/simu.c U xforms/lib/sldraw.c U xforms/lib/slider.c U xforms/lib/space.c U xforms/lib/spline.c U xforms/lib/strdup.c U xforms/lib/symbols.c U xforms/lib/sysdep.c U xforms/lib/tabfolder.c U xforms/lib/text.c U xforms/lib/textbox.c U xforms/lib/thumbwheel.c U xforms/lib/timeout.c U xforms/lib/timer.c U xforms/lib/tooltip.c U xforms/lib/ulib.h U xforms/lib/util.c U xforms/lib/valuator.c U xforms/lib/version.c U xforms/lib/vms_readdir.c U xforms/lib/vn_pair.c U xforms/lib/vstrcat.c U xforms/lib/win.c U xforms/lib/xdraw.c U xforms/lib/xforms.man U xforms/lib/xpopup.c U xforms/lib/xsupport.c U xforms/lib/xtext.c U xforms/lib/xyplot.c cvs server: Updating xforms/lib/OS2 cvs server: Updating xforms/lib/bitmaps U xforms/lib/bitmaps/.cvsignore U xforms/lib/bitmaps/Makefile.am U xforms/lib/bitmaps/plaid.xpm U xforms/lib/bitmaps/q.xbm U xforms/lib/bitmaps/warn.xbm cvs server: Updating xforms/lib/fd U xforms/lib/fd/.cvsignore U xforms/lib/fd/Makefile.am U xforms/lib/fd/cmdbr.c U xforms/lib/fd/cmdbr.fd U xforms/lib/fd/cmdbr.h U xforms/lib/fd/ginput.c U xforms/lib/fd/ginput.fd U xforms/lib/fd/ginput.h U xforms/lib/fd/micntl.c U xforms/lib/fd/micntl.fd U xforms/lib/fd/micntl.h cvs server: Updating xforms/lib/include U xforms/lib/include/.cvsignore U xforms/lib/include/AAA.h.in U xforms/lib/include/Basic.h U xforms/lib/include/Makefile.am U xforms/lib/include/XBasic.h U xforms/lib/include/bitmap.h U xforms/lib/include/box.h U xforms/lib/include/browser.h U xforms/lib/include/button.h U xforms/lib/include/canvas.h U xforms/lib/include/chart.h U xforms/lib/include/choice.h U xforms/lib/include/clipbd.h U xforms/lib/include/clock.h U xforms/lib/include/counter.h U xforms/lib/include/cursor.h U xforms/lib/include/dial.h U xforms/lib/include/filesys.h U xforms/lib/include/flps.h U xforms/lib/include/formbrowser.h U xforms/lib/include/frame.h U xforms/lib/include/free.h U xforms/lib/include/goodies.h U xforms/lib/include/input.h U xforms/lib/include/menu.h U xforms/lib/include/menubar.h U xforms/lib/include/popup.h U xforms/lib/include/positioner.h U xforms/lib/include/scrollbar.h U xforms/lib/include/slider.h U xforms/lib/include/tabfolder.h U xforms/lib/include/text.h U xforms/lib/include/thumbwheel.h U xforms/lib/include/timer.h U xforms/lib/include/xyplot.h U xforms/lib/include/zzz.h cvs server: Updating xforms/lib/private U xforms/lib/private/.cvsignore U xforms/lib/private/Makefile.am U xforms/lib/private/flsnprintf.h U xforms/lib/private/pbrowser.h U xforms/lib/private/pcanvas.h U xforms/lib/private/pchoice.h U xforms/lib/private/pcounter.h U xforms/lib/private/pdial.h U xforms/lib/private/pflps.h U xforms/lib/private/pformbrowser.h U xforms/lib/private/pmenu.h U xforms/lib/private/ppositioner.h U xforms/lib/private/pscrollbar.h U xforms/lib/private/pslider.h U xforms/lib/private/ptextbox.h U xforms/lib/private/ptwheel.h U xforms/lib/private/pvaluator.h U xforms/lib/private/