From jt at toerring.de Sat Aug 8 20:40:31 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 8 Aug 2009 20:40:31 +0200 Subject: [XForms] New mailing list Message-ID: <20090808184031.GA415@toerring.de> To subscribers of the xforms list Hi everybody, I had a bit of a look at the mailing lists supported by Savannah and it looks as if it's using the same soft- ware as the one Bob has been using (mailman). So the transition shouldn't be too painful and moving things over there not too much trouble. If I can get the archi- ves over there is still a unclear to me (it seems a bit unlikely that it's possible) but I will further investi- gate. Now the big question is: is there anyone who objects to being automatically subscribed to the new list at Savannah? If you do object please send either a mail to this list or to me personally ()! For all others I will do a 'mass subscription' to the new mailing list. When I have done that you will receive an email with all the relevant information (including the new password - I don't have the old ones and don't want to know them;-) You may have to adjust your personal settings to match those you had set for Bob's mailing list since I don't have any information beside the email addresses (and if you want to get all messages immediately or only a digest - I will try to keep that setting). Since I would like to give those of you that don't want to be subscribed automatically to the new mailing list a chance to tell me I will wait a few days before I open it up. Of course, if someone has objections, better ideas or even wants to volunteer to run the mailing list somewhere else please tell me! Also volunteers for taking care of the administration of the list are welcome - the main job will probably be to vet the first posts of new subscribers to keep spammers out. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Fri Aug 7 17:13:43 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 7 Aug 2009 17:13:43 +0200 Subject: [XForms] 2009 archives? In-Reply-To: <4A7C28F8.60306@bob.usuhs.mil> References: <4A7B5D58.5000009@math.unl.edu> <20090807084720.GA19875@toerring.de> <4A7C28F8.60306@bob.usuhs.mil> Message-ID: <20090807151343.GA6212@toerring.de> To subscribers of the xforms list Hi everybody, On Fri, Aug 07, 2009 at 09:15:36AM -0400, Robert Williams wrote: > Yes, I did miss this. I think it's time for me to > hand the mailing list over to someone else who > has the time to take better care of it. security > requirements here will eventually shut this list > down, it's broken again, and I just can't fix it now. > > I'll send the list and the archives I have to Jens. He > can forward it to someone willing to step forward. > > I've enjoyed supporting this group and I wish > to continue to subscribe to the new list. I would like to say a big thank you to Bob for all the work he did all these years! Bob already send me a list with the email addresses of all subscribers as well as an archive with the data since 2003. Question now is how to proceed. One possibility seems to be to host the mailing list on Savannah. I now still have to figure out if it's possible to subscribe all of you automatically there (at least if you don't mind if I do that if possible) and if it's feasible to get the old messages into that system. Please give me a few days for that... Of course, if there's somebody prepared to volunteer to host and administrate the mailing list that might be a good alternative. Any one of you looking for some extra work?;-) Just by chance I also just today have applied for a domain for XForms - I will post the details once it's finalized, i.e. offically assigned to me. But where it's hosted I only can have static content, so running the mailing list from there isn't possible. But at least the archive of the mai- ling list could go there if it's not possible to get it onto Savannah... Or, if somebody has some better hosting I could sign over the domain once I have got it for sure. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From lasgouttes at lyx.org Fri Aug 7 15:30:29 2009 From: lasgouttes at lyx.org (Jean-Marc Lasgouttes) Date: Fri, 07 Aug 2009 15:30:29 +0200 Subject: [XForms] 2009 archives? In-Reply-To: <4A7C28F8.60306@bob.usuhs.mil> (Robert Williams's message of "Fri, 07 Aug 2009 09:15:36 -0400") References: <4A7B5D58.5000009@math.unl.edu> <20090807084720.GA19875@toerring.de> <4A7C28F8.60306@bob.usuhs.mil> Message-ID: To subscribers of the xforms list Robert Williams writes: > Yes, I did miss this. I think it's time for me to > hand the mailing list over to someone else who > has the time to take better care of it. security > requirements here will eventually shut this list > down, it's broken again, and I just can't fix it now. Thanks for all your work, Bob. > I'll send the list and the archives I have to Jens. He > can forward it to someone willing to step forward. What about using savannah to host the list? JMarc _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From bob at bob.usuhs.mil Fri Aug 7 15:15:36 2009 From: bob at bob.usuhs.mil (Robert Williams) Date: Fri, 07 Aug 2009 09:15:36 -0400 Subject: [XForms] 2009 archives? In-Reply-To: <20090807084720.GA19875@toerring.de> References: <4A7B5D58.5000009@math.unl.edu> <20090807084720.GA19875@toerring.de> Message-ID: <4A7C28F8.60306@bob.usuhs.mil> To subscribers of the xforms list Yes, I did miss this. I think it's time for me to hand the mailing list over to someone else who has the time to take better care of it. security requirements here will eventually shut this list down, it's broken again, and I just can't fix it now. I'll send the list and the archives I have to Jens. He can forward it to someone willing to step forward. I've enjoyed supporting this group and I wish to continue to subscribe to the new list. Best regards, Bob Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi Rex, > > On Thu, Aug 06, 2009 at 05:46:48PM -0500, Rex Dieter wrote: > >> Just joined the list, went to >> http://cweblog.usuhs.mil/pipermail/xforms/ >> look over the list archive, and see only up through 2008 archived. Am I >> missing something? >> > > Welcome aboard;-) > > You aren't missing anything, it must be gone missing again > without Bob (who takes care of the mailing list) noticing. I > guess he will repair it ASAP now that you pointed it out. In > the meantime you can also find everything from this year > mirrored at > > http://groups.google.com/group/fa.xforms/topics?lnk > > Best regards, Jens > -- Dr. Robert Williams CIV, USUHS Department of Biomedical Informatics, Program in Molecular and Cell Biology, Phone: 301-295-3568 _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Fri Aug 7 10:47:20 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 7 Aug 2009 10:47:20 +0200 Subject: [XForms] 2009 archives? In-Reply-To: <4A7B5D58.5000009@math.unl.edu> References: <4A7B5D58.5000009@math.unl.edu> Message-ID: <20090807084720.GA19875@toerring.de> To subscribers of the xforms list Hi Rex, On Thu, Aug 06, 2009 at 05:46:48PM -0500, Rex Dieter wrote: > Just joined the list, went to > http://cweblog.usuhs.mil/pipermail/xforms/ > look over the list archive, and see only up through 2008 archived. Am I > missing something? Welcome aboard;-) You aren't missing anything, it must be gone missing again without Bob (who takes care of the mailing list) noticing. I guess he will repair it ASAP now that you pointed it out. In the meantime you can also find everything from this year mirrored at http://groups.google.com/group/fa.xforms/topics?lnk Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From rdieter at math.unl.edu Fri Aug 7 00:46:48 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 06 Aug 2009 17:46:48 -0500 Subject: [XForms] 2009 archives? Message-ID: <4A7B5D58.5000009@math.unl.edu> To subscribers of the xforms list Just joined the list, went to http://cweblog.usuhs.mil/pipermail/xforms/ look over the list archive, and see only up through 2008 archived. Am I missing something? -- Rex _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Sun Jul 12 15:30:24 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 12 Jul 2009 15:30:24 +0200 Subject: [XForms] New pre-release: xforms-1.0.92.pre6 Message-ID: <20090712133024.GA749@toerring.de> To subscribers of the xforms list Hi, here's a new pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92pre6.tar.gz Due to the help of Werner Heisch a number of bugs that mostly concerned fdesign (crashes under Gnome/KDE and other problems) could be fixed. Also a bug that kept the key from wor- king for FL_RETURN_BUTTONs has been repaired, as well as a focus setting problem in the file selector. The rather longish file forms.c has been split into two, forms.c, which now is dealing with showing and hidding of forms and changing their properties, and handling.c, which takes care of the handling of events for forms. Also an updated version of the documentation has been uploaded. And, as usual, please let me know if you find bugs! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Tue Jun 30 00:12:18 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 30 Jun 2009 00:12:18 +0200 Subject: [XForms] New pre-release: xforms-1.0.92.pre5 Message-ID: <20090629221218.GA27416@toerring.de> To subscribers of the xforms list Hi, I hope I'm not boring you death but there's another pre- release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92pre5.tar.gz It fixes a number of bugs Werner Heisch pointed out to me as well as some more bugs I found later, mostly related to the handling of browsers in fdesign. And, as usual, also the do- cumentation you can download from Savannah has been updated a bit. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Thu Jun 11 02:05:54 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 11 Jun 2009 02:05:54 +0200 Subject: [XForms] New pre-release: xforms-1.0.92.pre4 In-Reply-To: <20090609213241.GB26405@toerring.de> References: <20090609213241.GB26405@toerring.de> Message-ID: <20090611000554.GC2708@toerring.de> To subscribers of the xforms list Hi everybody, sorry to bother you again, but I found that I had mis- understood some aspects of the browser related functions, especially concerning the treatment of newline characters within the strings passed to the functions for adding, inserting and replacing lines. Thus I went back and cor- rected the code to make it work as far as possible like former XForms versions (and also updated the documenta- tion to spell out things in a way that even I hopefully will be able to understand what's supposed to be going on). The result is a fresh upload of the 1.0.92pre4 version of the sources for the library as well of the documentation. Please use that for testing instead of the version from yesteray... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Tue Jun 9 23:32:41 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 9 Jun 2009 23:32:41 +0200 Subject: [XForms] New pre-release: xforms-1.0.92.pre4 Message-ID: <20090609213241.GB26405@toerring.de> To subscribers of the xforms list Hi everybody, here we go again with another pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92pre4.tar.gz (as usual it may take some time until it has made it to the mirror severs...) For a start I would like to apologize for the length of the following text but since I introduced a number of changes that may affect existing applictions please bear with me... When trying to write the code for the new "spinner" widget I hit a number of snags. After some time I realized that this was due to some inconsistencies I hadn't been aware of before. As far as I understand the way XForms is supposed to works it's like this: when the "state" of an object changes the object gets either returned back to the application from a function like fl_do_forms() or, if a callback for the object is installed, that callback function is invoked. And you can influence what is repor- ted (i.e. report all changes, report on the end of the interaction or on end of interaction only if the object's state did change as a result of the interaction). And this is the way it actually did work, at least for most objects (of course leaving out objects that never change state like boxes, frames etc.). But things get hairy for objects that are basically a combination of other objects. The simplest example is a scrollbar, which is nothing but a slider and two (touch) buttons. But already for this rather simple widget the usual rules don't hold anymore: a scroll- bar never gets returned to the application e.g. by fl_do_forms() - you could get at changes only via installing a callbac. IMHO, this is simply wrong. The user shouldn't have to know if some object is "simple" or made up of child objects, all objects should work the same way. So I changed a few things while trying not to break too much existent code. Things now work like this: a) As before, but with greater flexibility, you can set for all objects (at least those for which it makes sense) under which conditions they're supposed to be reported back to your appli- cation - be it either via invoking a callback you installed for an object or be it via the object getting returned by e.g. fl_do_forms(). b) All objects (with a few exceptions I didn't got around to fixing yet like menus etc., which are a a PITA anyway) now follow the same simple scheme: when a state change of the type you requested happens they get returned to your appli- cation, either via a callback you installed or by returning the object from fl_do_forms() or similar. c) Once an object gets returned to your application you can check which condition led to it being returned. Here's an example. Take a browser as one of the more complex objects. It constists of a text area (a widget not part of the public interface) and (up to) two scrollbars (of which each in turn constists of a slider and two touch buttons). Until now for browsers only changes in the selection state of lines (for browser types that support selections) got reported, and that only via their callbacks. To get at changes of the scollbars an ad-hoc mechanism was needed, that's why the functions fl_set_browser_[vh]scroll_callback() exist at all. With the new version you can use the function fl_set_object return() (which already existed but wasn't documented) to tell what kind of events you want to get reported back to your application. These are (for browsers, for other objects there might be less choices): FL_RETURN_NONE never report changes FL_RETURN_CHANGED scrolling has happened (via scrollbars or e.g. keyboard) FL_RETURN_END end of scroll interaction (i.e. mouse had been used to move the scrollbar and has been released) FL_RETURN_SELECTION one (or more) lines in the browser got selected FL_RETURN_DESElECTION one (or more) lines in the browser got deselected FL_RETURN_ALWAYS one of all of the abobe events All events can be OR'ed, so you can request combinations of them to be reported. And then there's another one that's a bit special: FL_RETURN_END_CHANGED end of scroll interaction and, after scrolling, the text displayed in the browser has been changed (which wouldn't be the case if you scroll down and back to the original position with the scroll- bars) which is a combination of FL_RETURN_CHANGED ans FL_RETURN_END, i.e. it only gets reported when the interaction ends and resulted in a change. Within the code for handling object events you can find out which kind of event resulted in the object getting reprorted to your application by using the new function int fl_get_object_return_state(FL_OBJECT *obj); It will return FL_RETURN_CHANGED, FL_RETURN_END, FL_RETURN_SELECTION or FL_RETURN_DESELECTION or a combination by logical OR. (If you asked for the object to be reported on FL_RETURN_END_CHANGED then both FL_RETURN_CHANGED and FL_RETURN_END will be set) Please note that calling fl_get_object_return_state() only makes sense directly after the object has been returned to your application (or in the calback you installed) since any further user interaction with the object will result in the value getting changed. One possibility is also that the function returns the value FL_RETURN_TRIGGERED in case the object wasn't returned due to user interaction but because of a call of fl_trigger_object(). The descriptions in the documentation now list for each type of object which return settings make sense and what will get returned under which conditions. Unfortunately, there are a few cases where problems with existing code are inevitable. Programs that don't install a callback for scrollbars or browsers and don't catch when they get returned from fl_do_forms() may break. For these programs it would be best if after creating the browser or scrollbar fl_set_object_return() would be called with FL_RETURN_NONE as the second argument. A an alternative, you can compile the librarry for backward compatibi- lity for these cases by adding --enable-bw-bs-hack to the list of flags passed to configure. This makes sure that browsers and scrollbars keep their traditional behaviour, i.e. they won't get returned by fl_do_forms() but callbacks work. In the process of doing these changes I also rewrote parts of the browser object (especially the internal textbox widget). Before it wasn't really possible to have different font sizes in a browser (you had to put extra empty lines around lines with fonts larger than the default font) and, at least to me, it didn't look nice that there often was a lot of empty space at the end of the browser area if there wasn't room enough to show the last line completely. Also the restriction on the maximum number of charac- ters in a line didn't look too good to me. Now I hope browsers look more like people are used to from other toolkits (and I changed the default background color from gray to white). I tried to make things as similar as possible to the previous behaviour but, of course, a few things had to be changed - please take a look if there's anything that breaks your appli- cations and tell me about it. There are also a few new functions for browsers: double fl_get_browser_rel_xoffset(FL_OBJECT *obj); int fl_get_browser_yoffset(FL_OBJECT *obj); double fl_get_browser_rel_yoffset(FL_OBJECT *obj); void fl_set_browser_rel_xoffset(FL_OBJECT *obj, double offset); void fl_set_browser_yoffset(FL_OBJECT *obj, int pixels); void fl_set_browser_rel_yoffset(FL_OBJECT *obj, double offset); int fl_get_browser_line_yoffset(FL_OBJECT *obj, int line); They allow to query or set the amount of horizontal and vertical scrolling of the browser. This can obtained or set either in absolute values (pixels) or relative units (a value between 0.0 and 1.0 with the functions containing '_rel_' in their names). The last function allows to determine which y-offset must be set that a line appears as the topmost line in the browser (-1 gets returned if the line doesn't exists). And, of course, with the new pre-release also comes a new version of the dicumentation which you also can download from savannah. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From JOEL.MOOTS at L-3com.com Wed May 20 15:03:14 2009 From: JOEL.MOOTS at L-3com.com (JOEL.MOOTS at L-3com.com) Date: Wed, 20 May 2009 08:03:14 -0500 Subject: [XForms] New pre-release: xforms-1.0.92pre3 In-Reply-To: <20090519220711.GA30255@toerring.de> References: <20090517203156.GA18352@toerring.de> <615935CE76907149AFEC6599C969D4D50307E956@XCGTXH01.corp.eos.l-3com.com> <20090518221032.GA23031@toerring.de> <615935CE76907149AFEC6599C969D4D50307EF8B@XCGTXH01.corp.eos.l-3com.com> <20090519220711.GA30255@toerring.de> Message-ID: <615935CE76907149AFEC6599C969D4D50311C3E6@XCGTXH01.corp.eos.l-3com.com> To subscribers of the xforms list > -----Original Message----- > From: Jens Thoms Toerring [mailto:jt at toerring.de] > Sent: Tuesday, May 19, 2009 3:07 PM > To: Moots, Joel A. @ EOS; xforms at bob.usuhs.mil > Subject: Re: [XForms] New pre-release: xforms-1.0.92pre3 > > Anyway, as that is the case, wouldn't it make sense to have all > the > > prototypes use 'long' since the FL_OBJECT argument member that > > fl_set_object_callback sets is 'long' anyway? It shouldn't break > any > > existing code, and we'd be consistent at least. Any conversions > from 'void > > *' to 'long' and back would continue to behave the same, and we > could always > > switch any such unsafe code to use the extra u_ members, right? > > But then you would get a lot of warnings (and perhaps even com- > pile time errors with C++) for existing programs that use correct > arguments for e.g. form callbacks which expect a void pointer in- > stead of a long. I guess I would be pretty annoyed if my cleanly > compiling code suddenly would throw lots of warnings or worse... It suddenly occurs to me that I've been arguing the wrong thing. From glancing around, it seems to me that callbacks on FL_OBJECTs (e.g., that can be set from fdesign) take 'long' for user data and all remaining callbacks (that have a user data arg) use 'void *'. Is that wrong? -joel _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From lasgouttes at lyx.org Wed May 20 11:10:17 2009 From: lasgouttes at lyx.org (Jean-Marc Lasgouttes) Date: Wed, 20 May 2009 11:10:17 +0200 Subject: [XForms] New pre-release: xforms-1.0.92pre3 In-Reply-To: <20090519220711.GA30255@toerring.de> (Jens Thoms Toerring's message of "Wed, 20 May 2009 00:07:11 +0200") References: <20090517203156.GA18352@toerring.de> <615935CE76907149AFEC6599C969D4D50307E956@XCGTXH01.corp.eos.l-3com.com> <20090518221032.GA23031@toerring.de> <615935CE76907149AFEC6599C969D4D50307EF8B@XCGTXH01.corp.eos.l-3com.com> <20090519220711.GA30255@toerring.de> Message-ID: To subscribers of the xforms list Jens Thoms Toerring writes: > I think it's rather common that people assume that there's no > problem with casting between integers and pointers - for the > most common platforms it works well. I guess you must either > have been bitten by such problems or learned about them in > places like comp.lang.c to become aware of them (I wouldn't > expect anyone to read the C standard just for the fun of it;-) One example may be Microsoft VC++ in 64 bit mode: http://en.wikipedia.org/wiki/64-bit#Specific_data_models long is 32-bit, and pointers are 64-bit. JMarc _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Wed May 20 00:07:11 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 20 May 2009 00:07:11 +0200 Subject: [XForms] New pre-release: xforms-1.0.92pre3 In-Reply-To: <615935CE76907149AFEC6599C969D4D50307EF8B@XCGTXH01.corp.eos.l-3com.com> References: <20090517203156.GA18352@toerring.de> <615935CE76907149AFEC6599C969D4D50307E956@XCGTXH01.corp.eos.l-3com.com> <20090518221032.GA23031@toerring.de> <615935CE76907149AFEC6599C969D4D50307EF8B@XCGTXH01.corp.eos.l-3com.com> Message-ID: <20090519220711.GA30255@toerring.de> To subscribers of the xforms list Hi Joel, On Tue, May 19, 2009 at 10:34:37AM -0500, JOEL.MOOTS at L-3com.com wrote: > > The problem with casting between (object) pointers and integers > > (be it normal ints or long ints) is that the C standard doesn't > > allow it - or at least declares it as only "implementation > > defined". > > I.e. it's not forbidden to work but also not guaranteed to work > > everywhere. On most architectures it indeed does work, but there > > seem to be some where it doesn't (I don't remember which ones that > > are, I would have to ask the guys in comp.lang.c, but there are > > some really weird architectures in the wild;-) and I guess that > > is why it's not allowed in general by the C standard. > > Wow. Can't believe I've been living such an ignorant (and lucky) life so > far; I figured it said something about my programming. I think it's rather common that people assume that there's no problem with casting between integers and pointers - for the most common platforms it works well. I guess you must either have been bitten by such problems or learned about them in places like comp.lang.c to become aware of them (I wouldn't expect anyone to read the C standard just for the fun of it;-) And there are lots of tutorials that don't mention it or even encourage such casts. I also only became more careful after I spend a lot of time cleaning up one of my programs that worked nicely on one architecture but crashed badly when I had to port it to another (due to some different but similar problem)! Only then I started to learn that there are a lot of things in C that usually work but aren't guaranteed to work everywhere and nowadays try to avoid them... > Anyway, as that is the case, wouldn't it make sense to have all the > prototypes use 'long' since the FL_OBJECT argument member that > fl_set_object_callback sets is 'long' anyway? It shouldn't break any > existing code, and we'd be consistent at least. Any conversions from 'void > *' to 'long' and back would continue to behave the same, and we could always > switch any such unsafe code to use the extra u_ members, right? But then you would get a lot of warnings (and perhaps even com- pile time errors with C++) for existing programs that use correct arguments for e.g. form callbacks which expect a void pointer in- stead of a long. I guess I would be pretty annoyed if my cleanly compiling code suddenly would throw lots of warnings or worse... > > I don't see at the moment how to get around the casting issue with > > typedefs. I am currently pondering if it would be possible to use > > a union with a long and a void pointer and perhaps to get it to > > work > > by use of some macros without breaking existing code (or at least > > not requiring extensive rewrites), but I haven't figured out any- > > thing that would work and isn't too ugly;-) > > I can't think of *any* way (ugly or not) to allow this in C without > breaking code. I suppose we could duplicate a lot of code/members and > give the user the option of which type of callback to use, but, as > someone used to tell me, the "juice is not worth the squeeze." I haven't spend too much time thinking about this yet. If there's a solution that uses macros to get around the issue it definitely will require at least small changes to legacy code, like adding a define before inclusions of or a call of a function before fl_initialize(). I guess that would still be acceptable, at least there weren't too many complaints I remember when with version 0.89 the y-axis was switched and for older code you had to add a call of fl_flip_yorigin() to get it to work again. But as I already said, I haven't spend enough time on this to even have any good idea if it might work at all... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From JOEL.MOOTS at L-3com.com Tue May 19 17:34:37 2009 From: JOEL.MOOTS at L-3com.com (JOEL.MOOTS at L-3com.com) Date: Tue, 19 May 2009 10:34:37 -0500 Subject: [XForms] New pre-release: xforms-1.0.92pre3 In-Reply-To: <20090518221032.GA23031@toerring.de> References: <20090517203156.GA18352@toerring.de> <615935CE76907149AFEC6599C969D4D50307E956@XCGTXH01.corp.eos.l-3com.com> <20090518221032.GA23031@toerring.de> Message-ID: <615935CE76907149AFEC6599C969D4D50307EF8B@XCGTXH01.corp.eos.l-3com.com> To subscribers of the xforms list > The problem with casting between (object) pointers and integers > (be it normal ints or long ints) is that the C standard doesn't > allow it - or at least declares it as only "implementation > defined". > I.e. it's not forbidden to work but also not guaranteed to work > everywhere. On most architectures it indeed does work, but there > seem to be some where it doesn't (I don't remember which ones that > are, I would have to ask the guys in comp.lang.c, but there are > some really weird architectures in the wild;-) and I guess that > is why it's not allowed in general by the C standard. Wow. Can't believe I've been living such an ignorant (and lucky) life so far; I figured it said something about my programming. Anyway, as that is the case, wouldn't it make sense to have all the prototypes use 'long' since the FL_OBJECT argument member that fl_set_object_callback sets is 'long' anyway? It shouldn't break any existing code, and we'd be consistent at least. Any conversions from 'void *' to 'long' and back would continue to behave the same, and we could always switch any such unsafe code to use the extra u_ members, right? > I don't see at the moment how to get around the casting issue with > typedefs. I am currently pondering if it would be possible to use > a union with a long and a void pointer and perhaps to get it to > work > by use of some macros without breaking existing code (or at least > not requiring extensive rewrites), but I haven't figured out any- > thing that would work and isn't too ugly;-) I can't think of *any* way (ugly or not) to allow this in C without breaking code. I suppose we could duplicate a lot of code/members and give the user the option of which type of callback to use, but, as someone used to tell me, the "juice is not worth the squeeze." -joel _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Tue May 19 00:10:32 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 19 May 2009 00:10:32 +0200 Subject: [XForms] New pre-release: xforms-1.0.92pre3 In-Reply-To: <615935CE76907149AFEC6599C969D4D50307E956@XCGTXH01.corp.eos.l-3com.com> References: <20090517203156.GA18352@toerring.de> <615935CE76907149AFEC6599C969D4D50307E956@XCGTXH01.corp.eos.l-3com.com> Message-ID: <20090518221032.GA23031@toerring.de> To subscribers of the xforms list Hi Joel, On Mon, May 18, 2009 at 09:45:38AM -0500, JOEL.MOOTS at L-3com.com wrote: > > Another thing I am rather unhappy with is the prototypes for > > callback functions. Some callbacks take a 'long' as the second > > argument, others a void pointer. There doesn't seem to be any > > obvious reason why one of them is used. And in some situations > > a 'long' value is quite useful, but in others a void pointer > > is much better and when there's only a 'long' that can be passed > > to the callback there's the temptation to use casts between > > pointer and integer types (that work on a lot of architectures > > but aren't correct C and may fail on some architectures). IMHO > > it would be best if each callback would receive both a long and > > a void pointer. But that would break a lot of existing code. If > > anybody has a good idea on how to deal with that I would be de- > > lighted to hear about it! > > I've always wondered about this too. I suppose I'm ignorant when it > comes to many architecture issues, but the only reason I can think of > for using some long type rather than always void * would be to allow > use of data in some cases without a cast. Personally, I think it should > always be void *, but that would obviously break existing code that does > not cast. I don't see how casting from void * to integer types is not > 'correct' C (which probably just says something of my programming); > isn't that pretty much the standard way all Xt stuff works? So, I don't > really see any value in adding an additional arg. The problem with casting between (object) pointers and integers (be it normal ints or long ints) is that the C standard doesn't allow it - or at least declares it as only "implementation defined". I.e. it's not forbidden to work but also not guaranteed to work everywhere. On most architectures it indeed does work, but there seem to be some where it doesn't (I don't remember which ones that are, I would have to ask the guys in comp.lang.c, but there are some really weird architectures in the wild;-) and I guess that is why it's not allowed in general by the C standard. Perhaps POSIX requires it to work (like it requires that you can convert between void and function pointers, that the C standard sees as undefined behaviour but which is needed for dlsym(3) to work) but I am not aware of that... > I don't have much 64-bit experience, but I could see how using a long > might fail (if long were no longer large enough to hold all pointer > types), in which case, switching to void * would necessary, since it is > guaranteed to be large enough. On the 64-bit architecture I am just using it does work - a long has also 64 bits but I don't know if that can be taken for granted. Admittedly, I am a bit pedantic when it comes to C and thus I would normally not cast between pointers and integers. But what I am also not too happy with is that it looks rather random for which kind of callback functions a long is used and for which a void pointer, at least I wasn't able yet to find any system be- hind it... > Or we could possibly use a typedef > somewhere (akin to the XtPointer) and always use that type. Then most > folks, if they desired a long type everywhere, could probably use it > with little to no compile errors.. I don't see at the moment how to get around the casting issue with typedefs. I am currently pondering if it would be possible to use a union with a long and a void pointer and perhaps to get it to work by use of some macros without breaking existing code (or at least not requiring extensive rewrites), but I haven't figured out any- thing that would work and isn't too ugly;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From JOEL.MOOTS at L-3com.com Mon May 18 16:45:38 2009 From: JOEL.MOOTS at L-3com.com (JOEL.MOOTS at L-3com.com) Date: Mon, 18 May 2009 09:45:38 -0500 Subject: [XForms] New pre-release: xforms-1.0.92pre3 In-Reply-To: <20090517203156.GA18352@toerring.de> References: <20090517203156.GA18352@toerring.de> Message-ID: <615935CE76907149AFEC6599C969D4D50307E956@XCGTXH01.corp.eos.l-3com.com> To subscribers of the xforms list > Another thing I am rather unhappy with is the prototypes for > callback functions. Some callbacks take a 'long' as the second > argument, others a void pointer. There doesn't seem to be any > obvious reason why one of them is used. And in some situations > a 'long' value is quite useful, but in others a void pointer > is much better and when there's only a 'long' that can be passed > to the callback there's the temptation to use casts between > pointer and integer types (that work on a lot of architectures > but aren't correct C and may fail on some architectures). IMHO > it would be best if each callback would receive both a long and > a void pointer. But that would break a lot of existing code. If > anybody has a good idea on how to deal with that I would be de- > lighted to hear about it! I've always wondered about this too. I suppose I'm ignorant when it comes to many architecture issues, but the only reason I can think of for using some long type rather than always void * would be to allow use of data in some cases without a cast. Personally, I think it should always be void *, but that would obviously break existing code that does not cast. I don't see how casting from void * to integer types is not 'correct' C (which probably just says something of my programming); isn't that pretty much the standard way all Xt stuff works? So, I don't really see any value in adding an additional arg. I don't have much 64-bit experience, but I could see how using a long might fail (if long were no longer large enough to hold all pointer types), in which case, switching to void * would necessary, since it is guaranteed to be large enough. Or we could possibly use a typedef somewhere (akin to the XtPointer) and always use that type. Then most folks, if they desired a long type everywhere, could probably use it with little to no compile errors.. Sincerely, -joel P.S.: Jens, I know I'm a lurker so don't say this enough (have I ever?), but thanks for all your hard work. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Sun May 17 22:31:56 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 17 May 2009 22:31:56 +0200 Subject: [XForms] New pre-release: xforms-1.0.92pre3 Message-ID: <20090517203156.GA18352@toerring.de> To subscribers of the xforms list Hi everybody, here's another pre-relase, to be downloaded from http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92pre3.tar.gz Please keep in mind that it may take some time before it be- comes available from the mirror servers, While trying to write a new widget I came upon some problem I hadn't realized to exist before. As we all know the default be- haviour of the fl_do_forms() function is to return the address of an object that had experienced some changes - unless there's a callback function in\stalled for that object. That's a rather basic rule of XForms. But now I realized that this doesn't hold for some objects! The objects for which this isn't the case are those that are made up from a combination of other objects. E.g a scrollbar is made up from a slider and two (touch) buttons. Changes to a scrollbar aren't reported by fl_do_forms() even if you didn't install a callback for the scrollbar. Other examples are the formbrowser and tabfolder objects. This simply looks wrong to me. It doesn't seem to have been a real problem for anybody yet (at least I can't remember anybody complaining about it), but it's against what one expects when using XForms. Thus I changed the event handling code to "rectify" that. But in order not to break any programs that may depend on the old behaviour I set a "dummy" callback functions for all widgets that didn't report changes via fl_do_forms() before. So, all older programs should continue to work without changes. But you can now get notified by fl_do_forms() by simply switching off the callback. And you can write widgets that use already existing widgets and have them behave like "ordinary" widgets. Another thing I am rather unhappy with is the prototypes for callback functions. Some callbacks take a 'long' as the second argument, others a void pointer. There doesn't seem to be any obvious reason why one of them is used. And in some situations a 'long' value is quite useful, but in others a void pointer is much better and when there's only a 'long' that can be passed to the callback there's the temptation to use casts between pointer and integer types (that work on a lot of architectures but aren't correct C and may fail on some architectures). IMHO it would be best if each callback would receive both a long and a void pointer. But that would break a lot of existing code. If anybody has a good idea on how to deal with that I would be de- lighted to hear about it! I integrated the documentation into the make process. When you run 'configure' there's now a new option, '--enable-docs'. If that is set the documentation in info format is created. To make the HTML or PDF documentation just go into the doc subdirectory and do 'make html' and/or 'make pdf'. Of course, you need texi2html for the HTML version of the documentation and tesi2pdf for the PDF version. The HTML documentation (in- cluding the images needed) ends up in a subdirecectory of the doc subdirectory, called xforms.html. Finally, there's a new widget, a 'spinner'. It's similar to a counter object in that it has two buttons that let you in- or decrease a value, but you can also edit the value manually. You create one by calling fl_create_spinner(). There are two types, one for integer and one for double values, called FL_INT_SPINNER and FL_FLOAT_SPINNER. fl_get_spinner_value() returns the value (as a double, also for int spinneres) and with fl_set_spinner_value() you can set a new value. With fl_set_spinner_bounds() the minimum and maximum value can be adjusted, fl_get_spinner_bounds() returns the current settings. fl_set_spinner_step() and fl_get_spinner_step() set and query the increment and decrement step size. And fl_set_spinner_precision() and fl_get_spinner_precision() set and query the number of digits after the decimal point shown for float spinners (default is 1). Full documentation will be added real soon;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Tue May 12 13:04:00 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 12 May 2009 13:04:00 +0200 Subject: [XForms] New pre-release: xforms-1.0.02pre2 In-Reply-To: <20090512120734.owp5b64ikgk4c4ss@webmail.saao.ac.za> References: <20090510140134.GA21092@toerring.de> <20090512120734.owp5b64ikgk4c4ss@webmail.saao.ac.za> Message-ID: <20090512110400.GA26257@toerring.de> To subscribers of the xforms list Hi Luis, On Tue, May 12, 2009 at 12:07:34PM +0200, lab at saao.ac.za wrote: > I downloaded and complied 1.0.92pre2 frrom scratch (./configure, make). > During the "make" it exits with this error: > > In file included from fd_main.h:537, > from fd_attribs.c:39: > fd/ui_theforms.h:6:19: forms.h: No such file or directory > > Any ideas? Yes, I didnt check things well enough:-( Actually, the file demos/fd/ui_theforms.h was recreated using fdesign and fdesign puts a line with #include into the file. But as long as xforms isn't installed that file does not exist and I should have changed that line manually to #include "include/forms.h" which I forgot. I corrected that problem (or at least I hope I did) as well as another one wih fdesign that I noticed only yesterday and up- loaded a new version of xforms-1.0.92pre.tar.gz to savannah. I hope this new version will work for you. Thank's a lot for pointing out the problem and sorry for the inconvenience! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Sun May 10 16:01:34 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 10 May 2009 16:01:34 +0200 Subject: [XForms] New pre-release: xforms-1.0.02pre2 Message-ID: <20090510140134.GA21092@toerring.de> To subscribers of the xforms list Hi everybody, I guess it's time for a new pre-release. You can download it from http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92pre2.tar.gz Also the documentation was updated and you can get it in PDF or HTML format: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92.pdf http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92-html.tar.gz Please note that it might take some time until the new versions have made it to the mirror servers... Main changes are: a) Rob Carpenter noted that fdesign didn't automatically produces code to include when needed. Changed that so this header gets included when necessary. b) Selection of composite objects in fdesign had stopped working. c) Browsers created with fdesign could only be initialized in fdesign with 128 lines. Removed that arbitary limit. d) Signal handling: a caught signal could lead to an infinite loop if in the handler function for the signal XForms functions got called. e) FL_RETURN_BUTON objects didn't work if there was only a single input object in the same form. f) The functions fl_show_form(), fl_prepare_form_window() and fl_show_form_window() now return have return type 'Window' as the documentation already claimed. fl_prepare_form_window() now returns 'None' on failure instead of -1 as it probably was intended from the beginning. g) Documentation: new figures added, corrections and more internal links to make it easier to navigate. Please note: due to some necessary changes the new version isn't a drop-in replacement for 1.0.91 since a few changes had to be made to some essential types, so please recompile your applications before using it. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From bob at bob.usuhs.mil Tue Apr 28 15:34:48 2009 From: bob at bob.usuhs.mil (Robert Williams) Date: Tue, 28 Apr 2009 09:34:48 -0400 Subject: [XForms] c++ xforms code segfaults In-Reply-To: <20090428105216.GA14600@toerring.de> References: <49EF94FD.4090706@bob.usuhs.mil> <20090428105216.GA14600@toerring.de> Message-ID: <49F705F8.7030404@bob.usuhs.mil> To subscribers of the xforms list Dear Jens, Yes, I did solve this problem, primarily by including "-lgfortran" in my link list. This is probably not something of general interest, but it does put a stress test on the xforms library, linking C++, C, and Fortran libraries, that it appears to have passed nicely. Here is the top of my Makefile: CPP=g++ #-ggdb3 #CPP=gcc # FC=gfortran #-ggdb3 LIBS= -I/usr/X11R6/include/X11 \ -L/usr/X11R6/lib -lX11 -lXaw -lforms \ -Lpgplot -lcpgplot -lpgplot \ -lgfortran -lfftw3 -lm FFLAGS=-c -I/usr/X11R6/include/X11 -I/usr/local/include FCFLAGS=-c -ffixed-line-length-none -ff2c The full source of this project, with screenshots, is at: http://bob.usuhs.mil/xspectra/ The executable produced by the new XForms library does appear to have a few tics that I'll have to sort out. Thanks, Bob Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi Bon, > > On Wed, Apr 22, 2009 at 06:06:53PM -0400, Robert Williams wrote: > >> I'm trying to resurrect an XForms based package >> of mine named XSpectra, written in mixed C++ and >> Fortran. The package was working once, >> compiles and links without errors, >> but segfaults before entering the main program: >> >> (gdb) run >> Starting program: /usr/local/src/xspectra_march_2009/xspectra >> Program received signal SIGSEGV, Segmentation fault. >> 0xb7fb03d7 in __do_global_dtors_aux () >> Current language: auto; currently asm >> >> Breakpoints don't help and backtrace shows only the >> __do_global_dtors_aux () line above. Does anyone on the list have >> a small working C++ example, or any experience with this >> situation? >> > > I haven't answered yet because I am not very well acquainted > with C++ but I would of course be very interested if you could > solve this problem already and if it had anything to do with > the newer version of XForms. I tried to write an extremely > simple C++ program using XForms (just calling fl_initialize() > and fl_finish() and with that I couldn't reproduce your pro- > blem - but that, of course, doesn't prove anything... > > Best regards, Jens > -- Dr. Robert Williams CIV, USUHS Department of Biomedical Informatics Program in Molecular and Cell Biology Faculty Senate Past President, Phone: 301-295-3568 _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Tue Apr 28 12:52:16 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 28 Apr 2009 12:52:16 +0200 Subject: [XForms] c++ xforms code segfaults In-Reply-To: <49EF94FD.4090706@bob.usuhs.mil> References: <49EF94FD.4090706@bob.usuhs.mil> Message-ID: <20090428105216.GA14600@toerring.de> To subscribers of the xforms list Hi Bon, On Wed, Apr 22, 2009 at 06:06:53PM -0400, Robert Williams wrote: > I'm trying to resurrect an XForms based package > of mine named XSpectra, written in mixed C++ and > Fortran. The package was working once, > compiles and links without errors, > but segfaults before entering the main program: > > (gdb) run > Starting program: /usr/local/src/xspectra_march_2009/xspectra > Program received signal SIGSEGV, Segmentation fault. > 0xb7fb03d7 in __do_global_dtors_aux () > Current language: auto; currently asm > > Breakpoints don't help and backtrace shows only the > __do_global_dtors_aux () line above. Does anyone on the list have > a small working C++ example, or any experience with this > situation? I haven't answered yet because I am not very well acquainted with C++ but I would of course be very interested if you could solve this problem already and if it had anything to do with the newer version of XForms. I tried to write an extremely simple C++ program using XForms (just calling fl_initialize() and fl_finish() and with that I couldn't reproduce your pro- blem - but that, of course, doesn't prove anything... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From bob at bob.usuhs.mil Thu Apr 23 00:06:53 2009 From: bob at bob.usuhs.mil (Robert Williams) Date: Wed, 22 Apr 2009 18:06:53 -0400 Subject: [XForms] c++ xforms code segfaults Message-ID: <49EF94FD.4090706@bob.usuhs.mil> To subscribers of the xforms list Dear List, I'm trying to resurrect an XForms based package of mine named XSpectra, written in mixed C++ and Fortran. The package was working once, compiles and links without errors, but segfaults before entering the main program: (gdb) run Starting program: /usr/local/src/xspectra_march_2009/xspectra Program received signal SIGSEGV, Segmentation fault. 0xb7fb03d7 in __do_global_dtors_aux () Current language: auto; currently asm Breakpoints don't help and backtrace shows only the __do_global_dtors_aux () line above. Does anyone on the list have a small working C++ example, or any experience with this situation? Best regards, Bob -- Dr. Robert Williams CIV, USUHS Department of Biomedical Informatics Program in Molecular and Cell Biology Faculty Senate Past President, Phone: 301-295-3568 _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Thu Apr 16 12:40:07 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 16 Apr 2009 12:40:07 +0200 Subject: [XForms] git repository added Message-ID: <20090416104007.GB23687@toerring.de> To subscribers of the xforms list Hi, this time it's not about a new pre-release (I hadn't time enough for that recently) but to let you know that there's now also a git repository for the source code on Savannah. If you have git installed on your machine (if not you can get it from ) you can download it with git clone git://git.savannah.nongnu.org/xforms.git and get the source code with all the history (it's just about 3 MB). Whenever you later want to get the newest version you only have to use git pull to update to it. Of course, the CVS repository continues to exist and I will check in all changes also there (although perhaps with a bit of a delay). The "Homepage" at Savannah has also been changed a bit to redirect to the HTML version of the documentation (currently hosted on my personal web page since XForms has no own web page) instead to the very old XForms web page that doesn't exist anymore. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From dennisk at netspace.net.au Sun Apr 12 14:07:22 2009 From: dennisk at netspace.net.au (Dennis K) Date: Sun, 12 Apr 2009 12:07:22 +0000 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <20090411095508.GA15008@toerring.de> References: <49E06FA1.2000007@netspace.net.au> <20090411013450.GA13305@toerring.de> <49E0E647.10004@netspace.net.au> <20090411095508.GA15008@toerring.de> Message-ID: <49E1D97A.8000008@netspace.net.au> To subscribers of the xforms list Makes perfect sense. I occured to me that the program was exiting normally, I was just under the incorrect impression that it shoudln't have. Thank's a million, and have a great Easter! It's just that I've never come across this before and coincidently came accross it when upgrading from v0.89 to v1.0.91. It's a great toolkit with a really easy to use GUI builder which lends itself perfectly to those who want to write lightweight graphical programs with ease. Thanks, Dennis Jens Thoms Toerring wrote: > Hi Dennis, > > On Sat, Apr 11, 2009 at 06:49:43PM +0000, Dennis K wrote: > >>the diffence between whether those buttons cause the app to crash, is >>wether something has been entered in the 'callback' secton of the >>attributes form. No callback = program exit. Callback = runs fine. > > > I don't think it's a bug what you are seeing here. In the > example program you have more or less this: > > fl_do_forms( ); > return 0; /* end of program */ > > Now, fl_do_forms() isn't just an infinite loop. It returns > the address of the object when interaction with that object > happened - unless a callback function is installed for the > object. And I think that's what happens in your case: when > there's no callback for the button the fl_do_forms() func- > tion returns the address of the button's object and then the > program simply ends. If you install a callback for the button > fl_do_forms() does not return, so the program continues to > run. So if you don't use callbacks you should use something > like this > > while ( fl_do_form() != quit_button ) > /* empty ; */ > return 0; > > in order to avoid ending the program until some "Quit" > button (object 'quit_button') has been clicked on. The > fdesign program can't do that for you since it simply > isn't clever enough to figure out which object might be > the "Quit" button (or if there's one at all or more than > one etc.), so it just puts in the call to fl_do_forms() > and relies on you to fill in the rest. > > Does that make sense to you? > > Best regards, Jens -- --------------------------- I am not an atomic playboy. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From serge at dineamix.ca Sat Apr 11 14:45:04 2009 From: serge at dineamix.ca (Serge Bromow) Date: Sat, 11 Apr 2009 08:45:04 -0400 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <49E0E647.10004@netspace.net.au> References: <49E06FA1.2000007@netspace.net.au> <20090411013450.GA13305@toerring.de> <49E0E647.10004@netspace.net.au> Message-ID: <49E090D0.30108@dineamix.ca> To subscribers of the xforms list -------------- next part -------------- Hi Dennis, This behavior is normal for the code you provided. The app is not crashing but simply falling through the "fl_do_forms()" and ending properly. If a button has no call back then pressing the button will cause "fl_do_forms" to exit and proceed to the next step in your code. To keep the program active, try; while( 1 ) { // TRUE fl_do_forms(); } If "fl_do_forms" exits it will simply be start again. To exit the program you need to setup a callback that calls "exit()". Hope this helps, Serge Dennis K wrote: > To subscribers of the xforms list > > Sorry about all the e-mails, one last thing. > > the diffence between whether those buttons cause the app to crash, is > wether something has been entered in the 'callback' secton of the > attributes form. No callback = program exit. Callback = runs fine. > > > Jens Thoms Toerring wrote: > >> Hi Dennis, >> >> On Sat, Apr 11, 2009 at 10:23:29AM +0000, Dennis K wrote: >> >> >>> Just want to make you aware of an issue present in version 1.0.91 and >>> 1.0.92pre1. >>> >>> It seems I'm not the only one who has noticed this. >>> >>> http://www.ks.uiuc.edu/Research/vmd/vmd-1.5/devel.html >>> >>> The issue concerns the use of the 'lightbutton' widget. When used >>> placed in a form, and then pressed, the 'light' turns yellow. When the >>> mouse button is then released the program disappears, presumably because >>> it has crashed. When testing the form in fdesign, it runs correctly. >>> My system is RedHat 7.3, gcc version 2.96 >>> >>> Is the development team aware of this issue? If there is anything I can >>> do to assist, let me know. >>> >> No, I am not aware of that bug! Unfortunately, I can't reproduce >> it here on my machine and I can't remember to have had a problem >> with LightButtons. The entry on the VMD web page is quite old >> (from 2000). Are you sure you're really using a new (1.0.91 or >> newer) version and you're program isn't picking up an older >> version of the library accidentally? (It should be easy to check: >> just click somewhere within some window with the middle button >> while pressing the key - then a box with information about >> the version should pop up.) If it's a newer version could you >> perhaps send me an example program that exhibits the bug? That >> would be very helpful! >> Thanks and best regards, Jens >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Sat Apr 11 12:57:23 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 11 Apr 2009 12:57:23 +0200 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <49E012E0.50202@dineamix.ca> References: <49E06FA1.2000007@netspace.net.au> <20090411013450.GA13305@toerring.de> <49E012E0.50202@dineamix.ca> Message-ID: <20090411105723.GA18470@toerring.de> To subscribers of the xforms list Hi Serge, On Fri, Apr 10, 2009 at 11:47:44PM -0400, Serge Bromow wrote: > middle button you say! On my machine just middle button does the trick. Actually, it's the key that results in Mod1Mask getting set in the keymask for an ButtonPress X event. I guess you can influence that via your xmodmap settings... Regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Sat Apr 11 11:55:08 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 11 Apr 2009 11:55:08 +0200 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <49E0E647.10004@netspace.net.au> References: <49E06FA1.2000007@netspace.net.au> <20090411013450.GA13305@toerring.de> <49E0E647.10004@netspace.net.au> Message-ID: <20090411095508.GA15008@toerring.de> To subscribers of the xforms list Hi Dennis, On Sat, Apr 11, 2009 at 06:49:43PM +0000, Dennis K wrote: > the diffence between whether those buttons cause the app to crash, is > wether something has been entered in the 'callback' secton of the > attributes form. No callback = program exit. Callback = runs fine. I don't think it's a bug what you are seeing here. In the example program you have more or less this: fl_do_forms( ); return 0; /* end of program */ Now, fl_do_forms() isn't just an infinite loop. It returns the address of the object when interaction with that object happened - unless a callback function is installed for the object. And I think that's what happens in your case: when there's no callback for the button the fl_do_forms() func- tion returns the address of the button's object and then the program simply ends. If you install a callback for the button fl_do_forms() does not return, so the program continues to run. So if you don't use callbacks you should use something like this while ( fl_do_form() != quit_button ) /* empty ; */ return 0; in order to avoid ending the program until some "Quit" button (object 'quit_button') has been clicked on. The fdesign program can't do that for you since it simply isn't clever enough to figure out which object might be the "Quit" button (or if there's one at all or more than one etc.), so it just puts in the call to fl_do_forms() and relies on you to fill in the rest. Does that make sense to you? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From dennisk at netspace.net.au Sat Apr 11 20:49:43 2009 From: dennisk at netspace.net.au (Dennis K) Date: Sat, 11 Apr 2009 18:49:43 +0000 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <20090411013450.GA13305@toerring.de> References: <49E06FA1.2000007@netspace.net.au> <20090411013450.GA13305@toerring.de> Message-ID: <49E0E647.10004@netspace.net.au> To subscribers of the xforms list Sorry about all the e-mails, one last thing. the diffence between whether those buttons cause the app to crash, is wether something has been entered in the 'callback' secton of the attributes form. No callback = program exit. Callback = runs fine. Jens Thoms Toerring wrote: > Hi Dennis, > > On Sat, Apr 11, 2009 at 10:23:29AM +0000, Dennis K wrote: > >>Just want to make you aware of an issue present in version 1.0.91 and >>1.0.92pre1. >> >>It seems I'm not the only one who has noticed this. >> >>http://www.ks.uiuc.edu/Research/vmd/vmd-1.5/devel.html >> >>The issue concerns the use of the 'lightbutton' widget. When used >>placed in a form, and then pressed, the 'light' turns yellow. When the >>mouse button is then released the program disappears, presumably because >>it has crashed. When testing the form in fdesign, it runs correctly. >>My system is RedHat 7.3, gcc version 2.96 >> >>Is the development team aware of this issue? If there is anything I can >>do to assist, let me know. > > > No, I am not aware of that bug! Unfortunately, I can't reproduce > it here on my machine and I can't remember to have had a problem > with LightButtons. The entry on the VMD web page is quite old > (from 2000). Are you sure you're really using a new (1.0.91 or > newer) version and you're program isn't picking up an older > version of the library accidentally? (It should be easy to check: > just click somewhere within some window with the middle button > while pressing the key - then a box with information about > the version should pop up.) If it's a newer version could you > perhaps send me an example program that exhibits the bug? That > would be very helpful! > Thanks and best regards, Jens -- --------------------------- I am not an atomic playboy. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From dennisk at netspace.net.au Sat Apr 11 19:29:42 2009 From: dennisk at netspace.net.au (Dennis K) Date: Sat, 11 Apr 2009 17:29:42 +0000 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <20090411013450.GA13305@toerring.de> References: <49E06FA1.2000007@netspace.net.au> <20090411013450.GA13305@toerring.de> Message-ID: <49E0D386.1030304@netspace.net.au> To subscribers of the xforms list FYI, All the button types do this, roundbutton, round3dbutton, scrollbutton, bitmapbutton, pixmapbutton and labelbutton. All except the standard one. Jens Thoms Toerring wrote: > Hi Dennis, > > On Sat, Apr 11, 2009 at 10:23:29AM +0000, Dennis K wrote: > >>Just want to make you aware of an issue present in version 1.0.91 and >>1.0.92pre1. >> >>It seems I'm not the only one who has noticed this. >> >>http://www.ks.uiuc.edu/Research/vmd/vmd-1.5/devel.html >> >>The issue concerns the use of the 'lightbutton' widget. When used >>placed in a form, and then pressed, the 'light' turns yellow. When the >>mouse button is then released the program disappears, presumably because >>it has crashed. When testing the form in fdesign, it runs correctly. >>My system is RedHat 7.3, gcc version 2.96 >> >>Is the development team aware of this issue? If there is anything I can >>do to assist, let me know. > > > No, I am not aware of that bug! Unfortunately, I can't reproduce > it here on my machine and I can't remember to have had a problem > with LightButtons. The entry on the VMD web page is quite old > (from 2000). Are you sure you're really using a new (1.0.91 or > newer) version and you're program isn't picking up an older > version of the library accidentally? (It should be easy to check: > just click somewhere within some window with the middle button > while pressing the key - then a box with information about > the version should pop up.) If it's a newer version could you > perhaps send me an example program that exhibits the bug? That > would be very helpful! > Thanks and best regards, Jens -- --------------------------- I am not an atomic playboy. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From dennisk at netspace.net.au Sat Apr 11 19:19:17 2009 From: dennisk at netspace.net.au (Dennis K) Date: Sat, 11 Apr 2009 17:19:17 +0000 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <20090411013450.GA13305@toerring.de> References: <49E06FA1.2000007@netspace.net.au> <20090411013450.GA13305@toerring.de> Message-ID: <49E0D115.2040709@netspace.net.au> To subscribers of the xforms list -------------- next part -------------- Attached is an example source file. command to compile used was gcc lightbutton_test.c -L/usr/X11R6/lib -lforms -lX11 -lXpm I compiled the library with maximum debugging output, ran it as ./a.out -fldebug 4 and caught it all output in the attached text file, fldebug.txt. The last section, after the '****' is after pressing the lightbutton. Thanks, Dennis It most definately is version 1.0.91. Jens Thoms Toerring wrote: > Hi Dennis, > > On Sat, Apr 11, 2009 at 10:23:29AM +0000, Dennis K wrote: > >>Just want to make you aware of an issue present in version 1.0.91 and >>1.0.92pre1. >> >>It seems I'm not the only one who has noticed this. >> >>http://www.ks.uiuc.edu/Research/vmd/vmd-1.5/devel.html >> >>The issue concerns the use of the 'lightbutton' widget. When used >>placed in a form, and then pressed, the 'light' turns yellow. When the >>mouse button is then released the program disappears, presumably because >>it has crashed. When testing the form in fdesign, it runs correctly. >>My system is RedHat 7.3, gcc version 2.96 >> >>Is the development team aware of this issue? If there is anything I can >>do to assist, let me know. > > > No, I am not aware of that bug! Unfortunately, I can't reproduce > it here on my machine and I can't remember to have had a problem > with LightButtons. The entry on the VMD web page is quite old > (from 2000). Are you sure you're really using a new (1.0.91 or > newer) version and you're program isn't picking up an older > version of the library accidentally? (It should be easy to check: > just click somewhere within some window with the middle button > while pressing the key - then a box with information about > the version should pop up.) If it's a newer version could you > perhaps send me an example program that exhibits the bug? That > would be very helpful! > Thanks and best regards, Jens -- --------------------------- I am not an atomic playboy. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lightbutton_test.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fldebug.txt URL: -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From serge at dineamix.ca Sat Apr 11 05:47:44 2009 From: serge at dineamix.ca (Serge Bromow) Date: Fri, 10 Apr 2009 23:47:44 -0400 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <20090411013450.GA13305@toerring.de> References: <49E06FA1.2000007@netspace.net.au> <20090411013450.GA13305@toerring.de> Message-ID: <49E012E0.50202@dineamix.ca> To subscribers of the xforms list -------------- next part -------------- middle button you say! Well look at that. Thats a handy feature. 10 Years and still learning. Thanks Jens, Serge Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi Dennis, > > On Sat, Apr 11, 2009 at 10:23:29AM +0000, Dennis K wrote: > >> Just want to make you aware of an issue present in version 1.0.91 and >> 1.0.92pre1. >> >> It seems I'm not the only one who has noticed this. >> >> http://www.ks.uiuc.edu/Research/vmd/vmd-1.5/devel.html >> >> The issue concerns the use of the 'lightbutton' widget. When used >> placed in a form, and then pressed, the 'light' turns yellow. When the >> mouse button is then released the program disappears, presumably because >> it has crashed. When testing the form in fdesign, it runs correctly. >> My system is RedHat 7.3, gcc version 2.96 >> >> Is the development team aware of this issue? If there is anything I can >> do to assist, let me know. >> > > No, I am not aware of that bug! Unfortunately, I can't reproduce > it here on my machine and I can't remember to have had a problem > with LightButtons. The entry on the VMD web page is quite old > (from 2000). Are you sure you're really using a new (1.0.91 or > newer) version and you're program isn't picking up an older > version of the library accidentally? (It should be easy to check: > just click somewhere within some window with the middle button > while pressing the key - then a box with information about > the version should pop up.) If it's a newer version could you > perhaps send me an example program that exhibits the bug? That > would be very helpful! > Thanks and best regards, Jens > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Sat Apr 11 03:34:50 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 11 Apr 2009 03:34:50 +0200 Subject: [XForms] Lightbutton bug - Button causes app to crash. In-Reply-To: <49E06FA1.2000007@netspace.net.au> References: <49E06FA1.2000007@netspace.net.au> Message-ID: <20090411013450.GA13305@toerring.de> To subscribers of the xforms list Hi Dennis, On Sat, Apr 11, 2009 at 10:23:29AM +0000, Dennis K wrote: > Just want to make you aware of an issue present in version 1.0.91 and > 1.0.92pre1. > > It seems I'm not the only one who has noticed this. > > http://www.ks.uiuc.edu/Research/vmd/vmd-1.5/devel.html > > The issue concerns the use of the 'lightbutton' widget. When used > placed in a form, and then pressed, the 'light' turns yellow. When the > mouse button is then released the program disappears, presumably because > it has crashed. When testing the form in fdesign, it runs correctly. > My system is RedHat 7.3, gcc version 2.96 > > Is the development team aware of this issue? If there is anything I can > do to assist, let me know. No, I am not aware of that bug! Unfortunately, I can't reproduce it here on my machine and I can't remember to have had a problem with LightButtons. The entry on the VMD web page is quite old (from 2000). Are you sure you're really using a new (1.0.91 or newer) version and you're program isn't picking up an older version of the library accidentally? (It should be easy to check: just click somewhere within some window with the middle button while pressing the key - then a box with information about the version should pop up.) If it's a newer version could you perhaps send me an example program that exhibits the bug? That would be very helpful! Thanks and best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From dennisk at netspace.net.au Sat Apr 11 12:23:29 2009 From: dennisk at netspace.net.au (Dennis K) Date: Sat, 11 Apr 2009 10:23:29 +0000 Subject: [XForms] Lightbutton bug - Button causes app to crash. Message-ID: <49E06FA1.2000007@netspace.net.au> To subscribers of the xforms list Hello, Just want to make you aware of an issue present in version 1.0.91 and 1.0.92pre1. It seems I'm not the only one who has noticed this. http://www.ks.uiuc.edu/Research/vmd/vmd-1.5/devel.html The issue concerns the use of the 'lightbutton' widget. When used placed in a form, and then pressed, the 'light' turns yellow. When the mouse button is then released the program disappears, presumably because it has crashed. When testing the form in fdesign, it runs correctly. My system is RedHat 7.3, gcc version 2.96 Is the development team aware of this issue? If there is anything I can do to assist, let me know. Regards, Dennis -- --------------------------- I am not an atomic playboy. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Sun Jan 18 22:11:41 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 18 Jan 2009 22:11:41 +0100 Subject: [XForms] New XForms pre-relase 1.0.92pre1 In-Reply-To: <20090117214252.GA24359@toerring.de> References: <20090117214252.GA24359@toerring.de> Message-ID: <20090118211141.GA26213@toerring.de> To subscribers of the xforms list Hi again, On Sat, Jan 17, 2009 at 10:42:52PM +0100, Jens Thoms Toerring wrote: > I just uploaded a new pre-release of XForms: > > http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92pre1.tar.gz Pleae note: I just uploaded a new version since I found that I left some remnants from debugging in the code. Sorry for that! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Sat Jan 17 22:42:52 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 17 Jan 2009 22:42:52 +0100 Subject: [XForms] New XForms pre-relase 1.0.92pre1 Message-ID: <20090117214252.GA24359@toerring.de> To subscribers of the xforms list Hi everybody, I just uploaded a new pre-release of XForms: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92pre1.tar.gz as well as the newest version of the documentation http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92.pdf http://download.savannah.gnu.org/releases/xforms/xforms-1.0.92-html.tar.gz Alas, most igures are still missing from the documenatation... It may still take a bit of time until this links are working, there seems to be some delay until the mirror servers get updated. If you have to download stuff *now* try http://download.savannah.gnu.org/releases-noredirect/xforms/ to avoid being redirected to a mirror server Please note that I also cleaned up the download directory a bit, removing e.g. the pre-releases for 1.0.91. Here's the list of the main changes: a) As I already wrote I rewrote the whole popup stuff since the old code had more or less become unmaintainable. I now also added two new object classes, select and nmenu, that are supposed to replace the choice and menu class which were based on the old popup code. I also added two new demo programs for these classes, select.c and nmenu.c to demonstrate the new classes and changed a few other demo programs to use the new classes instead of the old ones. Of course, the old xpopup, choice and menu classes still work as before. I haven't tried to add handling of the new select and nmenu classes to fdesign. I guess I better wait until I get a bit of feedback about them... b) Documentation was updated to describe the new classes (the stuff about the old xpopup, menu and choice class are moved to a new chapter about "deprecated" object classes. c) Luis Balona told me that there are some problems with the itest demo program when using it under newer versions of Ubuntu with Gnome or KDE - the images are displayed as half-transparent. As far as I could figure out it's related to the COMPOSITE extension and I tried to hack around that. The images I tried it with now look normal again but I am not convinced that the problem is completely solved yet... d) Both Rob Carpenter and Werner Heisch told me that there's an error window popping up when fdesign is started. That doesn't keep fdesign from working but is annoying and hopefully repaired. e) Werner Heisch also found that there was a bug in fdesign that resul- ted in the label alignment getting set incorrectly (always ended up as FL_ALIGN_CENTER). This hopefully is removed now. f) Rob Carpenter noticed that it sometimes can be difficult to use a counter to just change it by a single step. Thus, according to his suggstions, the first step now takes longer and the time between following steps gets smaller and smaller until a final minimum timeout is reached (initial timeout is 600 ms and final is 50 ms per default). The fl_get_counter_repeat() and fl_set_counter_repeat() are now for the initial timeout and the final timeout can be con- trolled via the new functions fl_set_counter_min_repeat() and fl_get_counter_min_repeat(). To switch back to the old behaviour use the functions fl_set_counter_speedup()/fl_get_counter_speedup() and set the initial and final rate to the same value. If speed-up is switched off but initial and final timeouts differ the initial timeout is used for the first step and the final timeout for all following steps. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From jt at toerring.de Fri Jan 2 12:16:45 2009 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 2 Jan 2009 12:16:45 +0100 Subject: [XForms] Mouse button action on app button In-Reply-To: <495D4135.8090706@funnyvoid.com> References: <495D4135.8090706@funnyvoid.com> Message-ID: <20090102111645.GA18600@toerring.de> To subscribers of the xforms list Hi maddoxik, On Thu, Jan 01, 2009 at 11:18:29PM +0100, maddoxik wrote: > I'm new in xforms and I'm little bit confusing with mouse buttons > behavior on application button in xforms-1.0.91. Every mouse buttons > made action on application button. I think it will be better when only > FL_MBUTTON1 made action on application button. I also found it not very intuitive that buttons react to all mouse buttons. On the other hand this behaviour has been the way it is sinc (I guess) the beginnings of XForms and, when I tried to change it, I learned that there are a number of applications that rely on this behaviour, e.g. because they ascociating a different meaning to a mouse click on a button when done with mouse button 2 instead of mouse button 1 etc. Thus completely restricting the reaction of buttons to the left mouse button breaks existing programs which I think we should rather avoid. For that reason I added a new function which you can use to explicitely set which mouse buttons a button reacts to: void fl_set_button_mouse_buttons(FL_OBJECT *obj, int mbuttons); where 'mbuttons' is the bitwise OR of the numbers 1 for the left mouse button, 2 for the middle, 4 for the right mouse button, 8 for moving the scroll wheel up "button" and 16 for scrolling down "button". You can also set this for each button with fdesign (open the form for the button attri- butes and select which mouse button to react to in the "Spec" tab - per default all are allowed, but you can switch off all except the left mouse button). (That's what the "!sp->react_to[key - 1]" part of the testing of which mouse button was clicked on in button.c is meant for.) Unfortunately, this function is rather new, so it isn't in the old documentation for version 0.89. You can only find it documented in the new version of the documentation I uploaded a few day ago (and which isn't 100% complete yet). I hope that this solves the problem for you without going as far as restricting the reaction to mouse button 1 only, which would make some other people unhappy. My best wishes for a happy new year and best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms From maddoxik at funnyvoid.com Thu Jan 1 23:18:29 2009 From: maddoxik at funnyvoid.com (maddoxik) Date: Thu, 01 Jan 2009 23:18:29 +0100 Subject: [XForms] Mouse button action on app button Message-ID: <495D4135.8090706@funnyvoid.com> To subscribers of the xforms list -------------- next part -------------- Hi all, I'm new in xforms and I'm little bit confusing with mouse buttons behavior on application button in xforms-1.0.91. Every mouse buttons made action on application button. I think it will be better when only FL_MBUTTON1 made action on application button. I wrote small patch which solve this strange behavior. maddoxik -------------- next part -------------- A non-text attachment was scrubbed... Name: button.patch Type: text/x-patch Size: 785 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ XForms Home: http://savannah.nongnu.org/projects/xforms