From angus.leeming at btopenworld.com Fri Jan 2 22:17:43 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jan 2 17:17:44 2004 Subject: [XForms] Re: XForms In-Reply-To: References: Message-ID: <200401022217.43948.angus.leeming@btopenworld.com> On Friday 02 January 2004 9:55 pm, you wrote: > The xforms download page at savannah.nongnu.org/files/?group=xforms is > not operational. Wehre is the download page for xforms? Is xforms still > an active project or has it gone moribund (and I should use some other > library for my project). The library is alive and well, but the savannah web site was hacked. Everything is now working fine again, but the download page is not yet repaired. Find the xforms 1.0 release (871kB) at http://www.devel.lyx.org/~leeming/xforms-1.0.tar.gz and today's cvs snapshot (989kB) at http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz The code is little changed, but we've migrated the build away from Imake to the GNU autotools. It should be trivially easy to build and install now... > Also what is the relation between XForms and the XML forms library > called Xforms (www.w3.org/MarkUp/Forms) I assume that the similarity of > names is all the similarity ( and the similarity of names is ripe for > confusion.) There is no relation at all. The xforms gui toolkit has been around since the mid-80's, so could claim to have 'been there first' ... Regards, Angus From angus.leeming at btopenworld.com Wed Jan 7 09:28:26 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Jan 7 04:28:22 2004 Subject: [XForms] Re: XForms In-Reply-To: References: <200401042017.36360.angus.leeming@btopenworld.com> Message-ID: <200401070928.26124.angus.leeming@btopenworld.com> On Wednesday 07 January 2004 8:55 am, you wrote: > Just a suggestion: The axis tick marks if you are using a log scale for > the axis is messed up. The minor ticks should not be equally spaced-- > they should be at the logs of the integers Ie, it would be good to be > able to have the minor tick marks falling on the integrers (ie log(2) > log(3)...) . > The current behaviour in which the minor tick marks are > placed at equally spaced points along the axis does not work at all. > > Also, I want to plot a plot from 10 to 20000 along the x axis with log > scale. The tick mark function however forces the axis to go to 100,000. > Ie it does not like having the right hand edge not falling on a major tick > mark. Again, this makes for a graph with wasted spece. The plot should > respect the bounds-- with the bounds located on the edges or at least it > should be possible to force it to do so. Hi Bill. I think that you should consider subscribing to the xforms mailing list, xforms@bob.usuhs.mil. See http://bob.usuhs.mil/mailserv/xforms.html for instructions how to subscribe. Additionally, there's a bug tracker on the savannah project page http://savannah.nongnu.org/bugs/?group=xforms&func=additem Adding your request there will ensure that it doesn't get lost. Regards, Angus From bob at bob.usuhs.mil Wed Jan 7 09:26:02 2004 From: bob at bob.usuhs.mil (Robert Williams) Date: Wed Jan 7 09:26:16 2004 Subject: [XForms] Subscribing to Xforms In-Reply-To: <200401070928.26124.angus.leeming@btopenworld.com> References: <200401042017.36360.angus.leeming@btopenworld.com> <200401070928.26124.angus.leeming@btopenworld.com> Message-ID: <3FFC16FA.3060905@bob.usuhs.mil> Just a brief correction: With respect to the instructions about how to subscribe to the xforms list, the mailserv page cited below, belonging to the old majordomo set of files, is no longer functional. Xforms now uses mailman, and the instructions for subscribing are at the bottom of this and every other XForms list message. Angus Leeming wrote: > To subscribers of the xforms list > > > On Wednesday 07 January 2004 8:55 am, you wrote: > >>Just a suggestion: The axis tick marks if you are using a log scale for >>the axis is messed up. The minor ticks should not be equally spaced-- >>they should be at the logs of the integers Ie, it would be good to be >>able to have the minor tick marks falling on the integrers (ie log(2) >>log(3)...) . >> The current behaviour in which the minor tick marks are >>placed at equally spaced points along the axis does not work at all. >> >>Also, I want to plot a plot from 10 to 20000 along the x axis with log >>scale. The tick mark function however forces the axis to go to 100,000. >>Ie it does not like having the right hand edge not falling on a major tick >>mark. Again, this makes for a graph with wasted spece. The plot should >>respect the bounds-- with the bounds located on the edges or at least it >>should be possible to force it to do so. > > > Hi Bill. > I think that you should consider subscribing to the xforms mailing list, > xforms@bob.usuhs.mil. See http://bob.usuhs.mil/mailserv/xforms.html for > instructions how to subscribe. I've removed this page. Thanks Angus for the nudge. > > Additionally, there's a bug tracker on the savannah project page > http://savannah.nongnu.org/bugs/?group=xforms&func=additem > Adding your request there will ensure that it doesn't get lost. > > Regards, > Angus > > > > _______________________________________________ > 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. Robert Williams Dept. of Biomedical Informatics Uniformed Services University 301-295-3568 From msz at astrouw.edu.pl Tue Jan 13 03:20:43 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Mon Jan 12 21:20:57 2004 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <200312031238.54118.angus.leeming@btopenworld.com> References: <200312031238.54118.angus.leeming@btopenworld.com> Message-ID: <20040113022043.GA26511@astrouw.edu.pl> On Wed, Dec 03, 2003 at 12:38:54PM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > 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 ;-) Angus, So you liked it but did not include it, did you? I've downloaded 1.0.2 from your page (as Savannah is still down) but it does not seem to contain this patch. Well I'm now a bit bifurcated :) I would like to use both your version of Clive's JPEG/EXIF patch (in CVS) *and* Mike's double click patch (apparently only in standard 1.0 release). This does not seem to be possible at the same time without fiddling with the code which I would strongly not want to do. regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From mheffner at vt.edu Thu Jan 15 00:30:42 2004 From: mheffner at vt.edu (Mike Heffner) Date: Thu Jan 15 00:30:49 2004 Subject: [XForms] fl_set_font_name() verbiage Message-ID: When fl_set_font_name() fails it will return -1 but it also prints: In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah This function is typically used as a method of testing whether a font is loadable or not, so it's not always a fatal condition. Can this print statement be wrapped in a debug-only conditional? Thanks, Mike -- Mike Heffner From Jean-Marc.Lasgouttes at inria.fr Thu Jan 15 12:25:20 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Jan 15 06:25:26 2004 Subject: [XForms] So, what now? Message-ID: Now that savannah has (almost) returned to life, it seems that we have no more excuse for letting this project languish :) - we have to check whether the code has been hacked. I wonder who could do that, but... The diffs since last trusted version are at ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz Unfortunately, it seems that there has been a lot of whitespace changes, and this makes checking very boring. I do not know of a way to change the diffs to ignore such garbage. Once this is done (or we have decided not to do it :), Angus should notice the savannah people. - I have some changes in my tree, but unfortunately I do not have access to ssh2 here, only ssh1 (believe it or not). So I cannot even do anonymous cvs anymore. I'll have to find out a solution. - we need to write down a TODO list, and actually handle it :) JMarc From Todd.Denniston at ssa.crane.navy.mil Thu Jan 15 10:15:54 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu Jan 15 10:16:26 2004 Subject: [XForms] So, what now? References: Message-ID: <4006AEAA.415506BA@ssa.crane.navy.mil> Jean-Marc Lasgouttes wrote: > > - we have to check whether the code has been hacked. I wonder who > could do that, but... The diffs since last trusted version are at > ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz > > Unfortunately, it seems that there has been a lot of whitespace > changes, and this makes checking very boring. I do not know of a way > to change the diffs to ignore such garbage. pass the -w option to gnu diff, -w Ignore white space when comparing lines. `diff -w [other options]` or `cvs diff -w [other options]` if there is both a white space and real change the line will still show as a diff. > you may also want: from diff man page -b Ignore changes in amount of white space. -B Ignore changes that just insert or delete blank lines. --ignore-blank-lines Ignore changes that just insert or delete blank lines. --ignore-space-change Ignore changes in amount of white space. or --ignore-all-space Ignore white space when comparing lines. -- 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 Jan 15 16:24:20 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Jan 15 10:24:26 2004 Subject: [XForms] So, what now? In-Reply-To: <4006AEAA.415506BA@ssa.crane.navy.mil> (Todd Denniston's message of "Thu, 15 Jan 2004 10:15:54 -0500") References: <4006AEAA.415506BA@ssa.crane.navy.mil> Message-ID: >>>>> "Todd" == Todd Denniston writes: Todd> Jean-Marc Lasgouttes wrote: >> Todd> >> - we have to check whether the code has been hacked. I wonder who >> could do that, but... The diffs since last trusted version are at >> ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz >> >> Unfortunately, it seems that there has been a lot of whitespace >> changes, and this makes checking very boring. I do not know of a >> way to change the diffs to ignore such garbage. Todd> pass the -w option to gnu diff, -w Ignore white space when Todd> comparing lines. Yes, but can I do this to an already existing diff? That's what I have here. JMarc From Todd.Denniston at ssa.crane.navy.mil Thu Jan 15 10:29:15 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu Jan 15 10:29:21 2004 Subject: [XForms] So, what now? References: Message-ID: <4006B1CB.8C488249@ssa.crane.navy.mil> Jean-Marc Lasgouttes wrote: > > >>>>> "Todd" == Todd Denniston writes: > > Todd> Jean-Marc Lasgouttes wrote: > >> > Todd> > >> - we have to check whether the code has been hacked. I wonder who > >> could do that, but... The diffs since last trusted version are at > >> ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz > >> > >> Unfortunately, it seems that there has been a lot of whitespace > >> changes, and this makes checking very boring. I do not know of a > >> way to change the diffs to ignore such garbage. > Todd> pass the -w option to gnu diff, -w Ignore white space when > Todd> comparing lines. > > Yes, but can I do this to an already existing diff? That's what I have here. > drad, no. unless you can use them as patches to some trusted set and then do the diffs again. I have not downloaded the tarball so I do not know what's there, and I just noticed that the diffs were at gnu.org so you did not gen them. any chance someone at gnu.org could be coaxed into generating the same diffs with the options you want/need? > JMarc -- 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 Jan 15 16:32:59 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Jan 15 12:22:47 2004 Subject: [XForms] So, what now? In-Reply-To: <4006B1CB.8C488249@ssa.crane.navy.mil> (Todd Denniston's message of "Thu, 15 Jan 2004 10:29:15 -0500") References: <4006AEAA.415506BA@ssa.crane.navy.mil> <4006B1CB.8C488249@ssa.crane.navy.mil> Message-ID: >>>>> "Todd" == Todd Denniston writes: Todd> drad, no. unless you can use them as patches to some trusted set Todd> and then do the diffs again. I have not downloaded the tarball Todd> so I do not know what's there, and I just noticed that the diffs Todd> were at gnu.org so you did not gen them. any chance someone at Todd> gnu.org could be coaxed into generating the same diffs with the Todd> options you want/need? I guess they think that if we are very paranoid about security we should not ignore security implications of whitespace... I have to say that my motivation for hunting hacks in xforms code is a bit low. I guess we have to do it nevertheless. JMarc From angus.leeming at btopenworld.com Thu Jan 15 19:49:37 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jan 16 09:52:17 2004 Subject: [XForms] So, what now? In-Reply-To: References: Message-ID: <200401151949.37777.angus.leeming@btopenworld.com> On Thursday 15 January 2004 11:25 am, Jean-Marc Lasgouttes wrote: > Now that savannah has (almost) returned to life, it seems that we have > no more excuse for letting this project languish :) > > - we have to check whether the code has been hacked. I wonder who > could do that, but... The diffs since last trusted version are at > ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz > > Unfortunately, it seems that there has been a lot of whitespace > changes, and this makes checking very boring. I do not know of a way > to change the diffs to ignore such garbage. I have already checked a large chunk of it. Everything in the root directory, in config and in demos. That leaves the directories fd2ps, fdesign, gl, image and lib. Take your pick. > > Once this is done (or we have decided not to do it :), Angus should > notice the savannah people. ... > - I have some changes in my tree, but unfortunately I do not have > access to ssh2 here, only ssh1 (believe it or not). So I cannot even > do anonymous cvs anymore. I'll have to find out a solution. Tell your admins to move with the times? > - we need to write down a TODO list, and actually handle it :) ... Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jan 16 16:05:51 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jan 16 10:06:03 2004 Subject: [XForms] So, what now? In-Reply-To: <200401151949.37777.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 15 Jan 2004 19:49:37 +0000") References: <200401151949.37777.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I have already checked a large chunk of it. Everything in the Angus> root directory, in config and in demos. That leaves the Angus> directories fd2ps, fdesign, gl, image and lib. Take your pick. Thanks for doing this. I'll try to do my share. >> - I have some changes in my tree, but unfortunately I do not have >> access to ssh2 here, only ssh1 (believe it or not). So I cannot >> even do anonymous cvs anymore. I'll have to find out a solution. Angus> Tell your admins to move with the times? Yes, something like that. It seems that they want a solution that integrates perfectly with afs/kerberos5 (which I do not really need) and this seems difficult to achieve. >> - we need to write down a TODO list, and actually handle it :) Angus> ... Is that some substitute for *shrug*? JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Jan 16 16:37:05 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jan 16 10:37:12 2004 Subject: [XForms] So, what now? In-Reply-To: <200401151949.37777.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 15 Jan 2004 19:49:37 +0000") References: <200401151949.37777.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I have already checked a large chunk of it. Everything in the Angus> root directory, in config and in demos. That leaves the Angus> directories fd2ps, fdesign, gl, image and lib. Take your pick. OK, I have checked the remainder, thanks to a diff provided to me by Mike Heffner (thanks Mike!). So it seems that we are clear in this respect (which is not a surprise). It may be nice also to put xforms-1.0 back to the download area, if we have access to that. Finally, this short patch is the only local change I had in my tree. It should fix compilation problems related to signal cllbacks returning either nothing or an int. The solution I took is to cast our callback which returns void to the proper prototype. I hope that C allows that, but please tell me if I am wrong. This fix was the last in my personal must-fix list. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: signal.diff Type: text/x-patch Size: 1405 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040116/0670c97c/signal.bin From angus.leeming at btopenworld.com Sat Jan 17 13:18:29 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat Jan 17 08:18:31 2004 Subject: [XForms] So, what now? In-Reply-To: References: <200401151949.37777.angus.leeming@btopenworld.com> Message-ID: <200401171318.29328.angus.leeming@btopenworld.com> On Friday 16 January 2004 3:37 pm, Jean-Marc Lasgouttes wrote: > Angus> I have already checked a large chunk of it. Everything in the > Angus> root directory, in config and in demos. That leaves the > Angus> directories fd2ps, fdesign, gl, image and lib. Take your pick. > > OK, I have checked the remainder, thanks to a diff provided to me by > Mike Heffner (thanks Mike!). So it seems that we are clear in this > respect (which is not a surprise). Indeed. All I need do now is tell savannah that the source is clean. The question is "how"? Is it sufficient to drop a mail to savannah-hackers@gnu.org? > It may be nice also to put xforms-1.0 back to the download area, if we > have access to that. http://savannah.nongnu.org/ Latest News Download areas posted by corvus, Thu 01/15/04 at 17:15 - 0 reply Files that were in the download areas on Savannah before the compromise can be downloaded from ftp://ftp.gnu.org/savannah/files. We kindly ask project administrators to verify the integrity of those Project download area posted by rudy, Sat 01/10/04 at 13:56 - 0 reply As most user have noticed, the project download area is not yet working. We are working on it. So I guess that I should check the download... done. Again, how do I report this to savannah? > Finally, this short patch is the only local change I had in my tree. > It should fix compilation problems related to signal cllbacks > returning either nothing or an int. The solution I took is to cast our > callback which returns void to the proper prototype. I hope that C > allows that, but please tell me if I am wrong. > > This fix was the last in my personal must-fix list. > > JMarc From Jean-Marc.Lasgouttes at inria.fr Mon Jan 19 10:38:29 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon Jan 19 04:38:36 2004 Subject: [XForms] So, what now? In-Reply-To: <200401171318.29328.angus.leeming@btopenworld.com> (Angus Leeming's message of "Sat, 17 Jan 2004 13:18:29 +0000") References: <200401151949.37777.angus.leeming@btopenworld.com> <200401171318.29328.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Indeed. All I need do now is tell savannah that the source is Angus> clean. The question is "how"? Is it sufficient to drop a mail Angus> to savannah-hackers@gnu.org? >From http://savannah.gnu.org/forum/forum.php?forum_id=2749: These difference sets should assist you in auditing your software. Once you have audited your packages, please contact <>, and let us know the results. JMarc From angus.leeming at btopenworld.com Mon Jan 19 23:53:10 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Jan 19 18:53:09 2004 Subject: [XForms] So, what now? In-Reply-To: References: <200401171318.29328.angus.leeming@btopenworld.com> Message-ID: <200401192353.10481.angus.leeming@btopenworld.com> On Monday 19 January 2004 9:38 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> Indeed. All I need do now is tell savannah that the source is > Angus> clean. The question is "how"? Is it sufficient to drop a mail > Angus> to savannah-hackers@gnu.org? > > From http://savannah.gnu.org/forum/forum.php?forum_id=2749: > > These difference sets should assist you in auditing your software. Once > you have audited your packages, please contact > <>, and let us know the results. Thanks, JMarc. I've sent of the letter telling them that all is Okk with our sources. Angus From mheffner at vt.edu Thu Jan 22 16:21:12 2004 From: mheffner at vt.edu (Mike Heffner) Date: Thu Jan 22 16:21:16 2004 Subject: [XForms] Xforms text editors Message-ID: For the XFMail project we use the text editor written by Marc van Kempen, available at: http://cvs.sourceforge.net/viewcvs.py/archimedes/xfmail/src/editor/ It is a great editor and we've been using it for quite awhile, however it is quite slow when viewing/editing a large email with 1,000+ lines. To improve it we are going to have to rewrite large portions of it to reduce the O(n) line insertion/deletion/lookup time. I wanted to pool the xforms community to see whether there are any other xforms text editors out there that we could look into as a replacement. Also, assuming the author agrees to a GPL license...would the xforms community be interested in importing this into xforms itself if it is the best current text editor available? Cheers, Mike -- Mike Heffner From msz at astrouw.edu.pl Tue Feb 24 14:56:23 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue Feb 24 08:56:41 2004 Subject: [XForms] strange message from app using xforms-1.0.2 Message-ID: <20040224135623.GA22585@astrouw.edu.pl> Hi, I have just recompiled my old application with new CVS 1.0.2 version of XForms. I did it on three different systems: Linux/x86 (RH 7.2) Linux/alpha (RH 7.2) Solaris/sparc (2.5.1) When invoked, it does its job just fine on all systems, but on one, namely Solaris, it outputs following strange message at start: In fl_initialize [flresource.c 972] Could not create an input context it does not show up on any Linux system. Any ideas what this could mean? regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From msz at astrouw.edu.pl Tue Feb 24 15:01:24 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue Feb 24 09:01:37 2004 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <200401130842.43682.angus.leeming@btopenworld.com> References: <200312031238.54118.angus.leeming@btopenworld.com> <20040113022043.GA26511@astrouw.edu.pl> <200401130842.43682.angus.leeming@btopenworld.com> Message-ID: <20040224140124.GA22610@astrouw.edu.pl> On Tue, Jan 13, 2004 at 08:42:43AM +0000, Angus Leeming wrote: > > Well I'm now a bit bifurcated :) I would like to use both your version > > of Clive's JPEG/EXIF patch (in CVS) *and* Mike's double click patch > > (apparently only in standard 1.0 release). This does not seem to be > > possible at the same time without fiddling with the code which I would > > strongly not want to do. > > Why not? I'd recommend that you grab an anoncvs copy of the repository and > apply Mike's patch. When it gets merged into the repository itself, cvs will > either report a conflict (trivially easy to resolve) or will tell you that > your checked-out tree already contains the patch. Well, I did try :) Attached is the manually crafted versions of the Mike's patch applied to the source named xforms-1.0.2 taken from http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz Experts, Author, please check it. regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND -------------- next part -------------- --- lib/fselect.c.orig Thu Nov 13 22:56:02 2003 +++ lib/fselect.c Mon Feb 23 14:32:13 2004 @@ -314,23 +314,16 @@ 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; @@ -340,31 +333,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); @@ -379,7 +350,7 @@ fl_set_input(lfs->input, seltext); strcpy(lfs->filename, seltext); - if (dblclick) + if (isdblclick) { if (lfs->fselect_cb) { @@ -390,7 +361,6 @@ fl_object_qenter(lfs->ready); } } - return; } #endif @@ -969,6 +939,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 Tue Feb 24 16:00:07 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Feb 24 10:00:31 2004 Subject: [XForms] strange message from app using xforms-1.0.2 In-Reply-To: <20040224135623.GA22585@astrouw.edu.pl> (Michal Szymanski's message of "Tue, 24 Feb 2004 14:56:23 +0100") References: <20040224135623.GA22585@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> I have just recompiled my old application with new CVS 1.0.2 Michal> version of XForms. I did it on three different systems: Michal> Linux/x86 (RH 7.2) Linux/alpha (RH 7.2) Solaris/sparc (2.5.1) Michal> When invoked, it does its job just fine on all systems, but on Michal> one, namely Solaris, it outputs following strange message at Michal> start: Michal> In fl_initialize [flresource.c 972] Could not create an Michal> input context Input contexts (and input methods) are what is used to enter special characters like those obtained with the compose key of the keyboard (or with an additional patch which is not yet in xforms, chinese, japanses or korean). It would be interesting to know why the XCreateIC call fails. It may be actually that cghan patch to use CJK languages with xforms will fix your problem on solaris too. Do you have special locale-related environment variables set? JMarc From msz at astrouw.edu.pl Tue Feb 24 17:05:01 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue Feb 24 11:05:12 2004 Subject: [XForms] strange message from app using xforms-1.0.2 In-Reply-To: References: <20040224135623.GA22585@astrouw.edu.pl> Message-ID: <20040224160501.GA22773@astrouw.edu.pl> On Tue, Feb 24, 2004 at 04:00:07PM +0100, Jean-Marc Lasgouttes wrote: > Michal> When invoked, it does its job just fine on all systems, but on > Michal> one, namely Solaris, it outputs following strange message at > Michal> start: > > Michal> In fl_initialize [flresource.c 972] Could not create an > Michal> input context > > Input contexts (and input methods) are what is used to enter special > characters like those obtained with the compose key of the keyboard > (or with an additional patch which is not yet in xforms, chinese, > japanses or korean). > > It would be interesting to know why the XCreateIC call fails. It may > be actually that cghan patch to use CJK languages with xforms will fix > your problem on solaris too. > > Do you have special locale-related environment variables set? No. On the Solaris machine in question, the output of 'locale' command is following: LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= I guess the "locale/NLS" etc. issues on such an old version of Solaris are not addressed very deeply, so maybe this makes a problem? Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Tue Feb 24 17:36:12 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Feb 24 11:36:29 2004 Subject: [XForms] strange message from app using xforms-1.0.2 In-Reply-To: <20040224160501.GA22773@astrouw.edu.pl> (Michal Szymanski's message of "Tue, 24 Feb 2004 17:05:01 +0100") References: <20040224135623.GA22585@astrouw.edu.pl> <20040224160501.GA22773@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: >> Do you have special locale-related environment variables set? Michal> No. On the Solaris machine in question, the output of 'locale' Michal> command is following: Michal> LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" Michal> LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= Michal> I guess the "locale/NLS" etc. issues on such an old version of Michal> Solaris are not addressed very deeply, so maybe this makes a Michal> problem? I do remember that some users said that since xforms got input methods support, they could not use compose key anymore in LyX. This probably means that the code to set input methods in xforms is not correct. Unfortunately, I do not know much about this. JMarc From wd4nmq at comcast.net Tue Feb 24 13:18:23 2004 From: wd4nmq at comcast.net (Jeff Pierce) Date: Tue Feb 24 16:18:15 2004 Subject: [XForms] xform and shape extension Message-ID: <403B956F.4080508@comcast.net> Is there any plans for xforms to include the shape extension that allows for non-rectangular windows like xeyes? I've always used xforms for my X applications but I now feel it is falling way behind other X wrappers, ie gtk/glade. -- Jeff, wd4nmq wd4nmq@comcast.net http://mywebpages.comcast.net/wd4nmq From wd4nmq at comcast.net Wed Feb 25 18:26:21 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed Feb 25 18:31:26 2004 Subject: [XForms] Test message Message-ID: <403D2F1D.9060107@comcast.net> This isa test messge, I sent a post the other night and I never saw it reflected or got a reply about it Jeff From wd4nmq at comcast.net Wed Feb 25 18:35:44 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed Feb 25 18:40:54 2004 Subject: [XForms] Where is xforms? Message-ID: <403D3150.9000708@comcast.net> Have I got something set wrong or what? Going to the link http://savannah.nongnu.org/files/?group=xforms Which is what is listed on teh mailing list messages and where you end up going thru the home page lists only an entry for "Parent Dirctory", nothing else. Where is xforms 1.0? Jeff From wd4nmq at comcast.net Fri Feb 27 00:14:51 2004 From: wd4nmq at comcast.net (Jeff) Date: Fri Feb 27 10:19:46 2004 Subject: [XForms] Anybody alive out there? Message-ID: <403ED24B.8040008@comcast.net> Is xforms dead or breathing it's last gasps? I posted a couple of days ago stating that xforms 1.0 was no longer available by going to http://world.std.com/~xforms/ and following the links that lead you to http://savannah.nongnu.org/files/?group=xforms But, just a "Parent Directory" entry, no xforms. Jeff From msz at astrouw.edu.pl Fri Feb 27 16:32:42 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Fri Feb 27 10:32:54 2004 Subject: [XForms] Anybody alive out there? In-Reply-To: <403ED24B.8040008@comcast.net> References: <403ED24B.8040008@comcast.net> Message-ID: <20040227153242.GA2372@astrouw.edu.pl> On Fri, Feb 27, 2004 at 12:14:51AM -0500, Jeff wrote: > > Is xforms dead or breathing it's last gasps? I posted a couple of days > ago stating that xforms 1.0 was no longer available by going to > http://world.std.com/~xforms/ and following the links that lead you to > http://savannah.nongnu.org/files/?group=xforms > But, just a "Parent Directory" entry, no xforms. Well, the list is not *very* busy lately :) Savannah got compromised some time ago - my understanding was it has already recovered but maybe this is not true yet. Angus gave following links for alternate download. I think they are still valid but note: grap the file(s) directly, the directory is not world readable: Find the xforms 1.0 release (871kB) at http://www.devel.lyx.org/~leeming/xforms-1.0.tar.gz and CVS snapshot (989kB) at http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Fri Feb 27 17:32:25 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Feb 27 11:32:43 2004 Subject: [XForms] Anybody alive out there? In-Reply-To: <20040227153242.GA2372@astrouw.edu.pl> (Michal Szymanski's message of "Fri, 27 Feb 2004 16:32:42 +0100") References: <403ED24B.8040008@comcast.net> <20040227153242.GA2372@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Michal> On Fri, Feb 27, 2004 at 12:14:51AM -0500, Jeff wrote: >> Is xforms dead or breathing it's last gasps? I posted a couple of >> days ago stating that xforms 1.0 was no longer available by going >> to http://world.std.com/~xforms/ and following the links that lead >> you to http://savannah.nongnu.org/files/?group=xforms But, just a >> "Parent Directory" entry, no xforms. Michal> Well, the list is not *very* busy lately :) Michal> Savannah got compromised some time ago - my understanding was Michal> it has already recovered but maybe this is not true yet. Yes, Angus has to re-upload the files, but it looks like he is busy. Hopefully we will be able to release xforms 1.1.0 in the coming weeks rather than months :) JMarc From wd4nmq at comcast.net Fri Feb 27 12:50:08 2004 From: wd4nmq at comcast.net (Jeff) Date: Fri Feb 27 12:50:25 2004 Subject: [XForms] Threads and events Message-ID: <403F8350.2060402@comcast.net> I hope what I am about to ask makes sense, but here goes. I wrote an app in xforms that had a thread. The thread accessed a server and then filled in a browser object. Now, due to problems with with GL, if I remember the reason, and this is the code I used. while(1){ timeout.tv_sec = 0; timeout.tv_usec = 1000; select(0, NULL, NULL, NULL, &timeout); pthread_mutex_lock(&browserLock); fl_check_forms(); pthread_mutex_unlock(&browserLock); } The thread then uses pthread_mutex_lock(&browserLock); // Update the browser pthread_mutex_unlock(&browserLock); To write to the browser. The server access was a thread so as not to lock out user input will the server was found, accessed and data gotten. Once the data was rceived, the thread wrote it to the browser object. I just got finished doing a Windows project that involved kinda the same thing. A gui thread and a worker thread. Now, in this I was able to use the Windows API call PostThreadMessage() for the gui to send send requests to the thread in response to user requests and the thread used PostMessage() to talk to the gui. In the case above the gui would use PostThreadMessage() to tell the thread to access the server. The thread would get the data from the server and place it in memory and use PostMessage() back to the gui, giving it the pointer, telling it to display the data in the browser. Now, since the thread never calls ANY object controls, only the gui thread does that, there would be no conflict between the two accessing the gui objects. Now for the question. Can the Windows API method of messaging be duplicated with events some how in the X/xforms environment? This would allow a total seperation of gui and worker thread and neither would have to wait on a mutex. Of course, in windows you have window handles and thread ids that are used to know where to post the messages to. Can you do the same thing in X to direct events? Needles to say, I don't know very much, if anything , about the way X handles events. One theory is to have an event callback function, and the other thread post the event to call it to that threads event handler. Is that a possiblity? Only the gui would use events. A worker thread could use what I do now to get input from the gui, a queue, queue access mutex, and a conditional wait on the mutex. This got kinda long winded and I apologize for that. But, I really would like to know if this can be done. Thank you just for reading this long post. Jeff wd4nmq@comcast.net From angus.leeming at btopenworld.com Mon Mar 1 19:29:10 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Mar 1 16:19:54 2004 Subject: [XForms] Fwd: Software using xforms Message-ID: <200403011929.10035.angus.leeming@btopenworld.com> Hi, Laurence! I've forwarded your message to the xforms user list so that it can receive as wide a dissemination as possible. Regards, Angus ---------- Forwarded Message ---------- FYI: we released on Friday some software which uses forms (see http://www.numis.northwestern.edu/edm). It is a slightly older version, and at some stage in the future we will update it to a more recent version. ----------------------------------------------- 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.northwestern.edu http://www.numis.northwestern.edu Nanocrystallography Workshop, http://ncem.lbl.gov/workshop.htm ----------------------------------------------- -------------- next part -------------- An embedded message was scrubbed... From: "L. D. Marks" Subject: Software using xforms Date: Mon, 1 Mar 2004 07:05:58 -0600 (CST) Size: 1839 Url: http://bob.usuhs.mil/pipermail/xforms/attachments/20040301/782a3e12/attachment.eml -------------- next part -------------- An embedded message was scrubbed... From: xforms-cvs-request@nongnu.org Subject: confirm 9fa3a209c783216ddd0d35ee87d2e88f842f9a37 Date: no date Size: 630 Url: http://bob.usuhs.mil/pipermail/xforms/attachments/20040301/782a3e12/attachment-0001.eml From wd4nmq at comcast.net Mon Mar 1 18:24:16 2004 From: wd4nmq at comcast.net (Jeff) Date: Mon Mar 1 18:24:21 2004 Subject: [XForms] FL_EVENT and it's use Message-ID: <4043C620.70001@comcast.net> Several days ago I posted a message concerning client message events and if xforms could handle them. To which I got no reply. I was looking through the xforms manual looking for something else and in section 4.3, Dealing With Windows. I found it talking about the FL_EVENT. To qoute: "To help find out when and event has occured, whenever fl_do_form() and fl_check_foems() encounter an event that is not meant for them, but for the appliaction program they return a special object FL_EVENT. Upon receiving this special event, the application program can and must remove the pending event from the queue using fl_XNextEvent()." There is then a code snippet. Does this mean that this how you would handle an XClientMessageEvent? while(! ready){ obj = fl_do_form(); // does form as long as events are for form if(obj == FL_EVENT){ fl_XNextEvent(&xevent); if(xevent.type == XClientMessageEvent){ // This is from the thread // update server data browser object } } Is this the right path? Jeff wd4nmq@comcast.net http://mywebpages.comcast.net/wd4nmq From dmitry at karasik.eu.org Mon Mar 1 11:33:03 2004 From: dmitry at karasik.eu.org (Dmitry Karasik) Date: Tue Mar 2 09:09:34 2004 Subject: [XForms] XForms text rendering bug patch Message-ID: <4043115F.9080007@karasik.eu.org> Under certain condition, input lines do not display any text. The bug, which is basically comparison of a signed integer as a boolean, is fixed by the following patch: --- xtext.c Mon Mar 1 11:26:24 2004 +++ /usr/ports/x11-toolkits/xforms/work/xforms-1.0/lib/xtext.c Mon Mar 1 11:26 :29 2004 @@ -210,7 +210,7 @@ for (i = topline; i < endline; i++) { /* Check whether visible */ + if (clip > 0 && (starty[i] + flx->fdesc) > y + h) - if (clip && (starty[i] + flx->fdesc) > y + h) continue; ulpos = -1; From richard at canido.co.uk Tue Mar 2 12:52:52 2004 From: richard at canido.co.uk (Richard Hughes) Date: Tue Mar 2 09:35:06 2004 Subject: [XForms] Xforms 1.0 LGPL Message-ID: <000001c40055$5f15c960$c800a8c0@canido.co.uk> Hi, Where is Xforms 1.0 LGPL available for download since your Freshmeat page links to the old non GPL page where I am only able to find versions 0.88 and 0.99. Thanks for your help Richard Hughes From Jean-Marc.Lasgouttes at inria.fr Tue Mar 2 15:41:09 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 2 09:41:15 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <4043115F.9080007@karasik.eu.org> (Dmitry Karasik's message of "Mon, 01 Mar 2004 11:33:03 +0100") References: <4043115F.9080007@karasik.eu.org> Message-ID: >>>>> "Dmitry" == Dmitry Karasik writes: Dmitry> To subscribers of the xforms list Under certain condition, Dmitry> input lines do not display any text. The bug, which is Dmitry> basically comparison of a signed integer as a boolean, is Dmitry> fixed by the following patch: Hello, Thanks for the patch. I think we are suffering from this bug in LyX in some circumstances, but we never got to fix it. Are you sure that your fix is the right one? I do not know this part of code at all, but the comment before the function says: /* Major text drawing routine * clip == 0: no clipping * clip == 1: do clipping here * clip == -1: clipping is done outside of this routine */ so testing for clip as a boolean means 'if there is some clipping going on somewhere', which may be a reasonable test. Are you sure that only the 'do clipping here' case should be handled? We want to be extra careful about the side-effects. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 2 15:44:47 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 2 09:44:53 2004 Subject: [XForms] FL_EVENT and it's use In-Reply-To: <4043C620.70001@comcast.net> (wd4nmq@comcast.net's message of "Mon, 01 Mar 2004 18:24:16 -0500") References: <4043C620.70001@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list Several days ago I posted a Jeff> message concerning client message events and if xforms could Jeff> handle them. To which I got no reply. Personnally I did not answer because I was scared by the 'thread' part :) Jeff> I was looking through the xforms manual looking for something Jeff> else and in section 4.3, Dealing With Windows. I found it Jeff> talking about the FL_EVENT. Jeff> To qoute: "To help find out when and event has occured, whenever Jeff> fl_do_form() and fl_check_foems() encounter an event that is not Jeff> meant for them, but for the appliaction program they return a Jeff> special object FL_EVENT. Upon receiving this special event, the Jeff> application program can and must remove the pending event from Jeff> the queue using fl_XNextEvent()." All I know is that in LyX we handle this just to drop the events. Jeff> There is then a code snippet. Does this mean that this how you Jeff> would handle an XClientMessageEvent? Yes, it looks reasonable. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 2 15:47:11 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 2 09:47:16 2004 Subject: [XForms] xform and shape extension In-Reply-To: <403B956F.4080508@comcast.net> (Jeff Pierce's message of "Tue, 24 Feb 2004 13:18:23 -0500") References: <403B956F.4080508@comcast.net> Message-ID: >>>>> "Jeff" == Jeff Pierce writes: Jeff> To subscribers of the xforms list Is there any plans for xforms Jeff> to include the shape extension that allows for non-rectangular Jeff> windows like xeyes? Jeff> I've always used xforms for my X applications but I now feel it Jeff> is falling way behind other X wrappers, ie gtk/glade. To reply to this older message: Jeff, I agree that xforms is falling behind in terms of appearance. I do not think we have enough developers to change that. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 2 15:50:35 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 2 09:51:23 2004 Subject: [XForms] Xforms 1.0 LGPL In-Reply-To: <000001c40055$5f15c960$c800a8c0@canido.co.uk> (Richard Hughes's message of "Tue, 2 Mar 2004 12:52:52 -0000") References: <000001c40055$5f15c960$c800a8c0@canido.co.uk> Message-ID: >>>>> "Richard" == Richard Hughes writes: Richard> To subscribers of the xforms list Hi, Richard> Where is Xforms 1.0 LGPL available for download since your Richard> Freshmeat page links to the old non GPL page where I am only Richard> able to find versions 0.88 and 0.99. Until we repair our pages at savannah, you can find it here: http://www.devel.lyx.org/~leeming/xforms-1.0.tar.gz JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 3 18:01:03 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Mar 3 12:15:40 2004 Subject: [XForms] [Laurent Fournier] Re: XForms: [again] pup interaction bug? Message-ID: Hello Laurent, I forward your message to the xforms mailing list, which is the right place to discuss your changes. Could you describe what the problem with xpopups was, and how memset solves these problems? Concerning the combox, there is already some code lifted from LyX the we planned to include in xforms. I guess it would be interesting to compare the two implementations and merge them. Thanks a lot for your input JMarc -------------- next part -------------- An embedded message was scrubbed... From: Laurent Fournier Subject: Re: XForms: [again] pup interaction bug? Date: Wed, 03 Mar 2004 17:05:28 +0100 Size: 76096 Url: http://bob.usuhs.mil/pipermail/xforms/attachments/20040303/e5e7cdd4/attachment.eml From Jean-Marc.Lasgouttes at inria.fr Thu Mar 4 18:03:34 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Mar 4 12:03:53 2004 Subject: [XForms] [Laurent Fournier] Xforms : popup menus Message-ID: Hello Laurent, Again, I forward your message to the xforms mailing list as well as replying to it. It would be nice in the future to continue this conversation on the list, so that it gets correctly archived. You can subscribe to the list from here http://cweblog.usuhs.mil/mailman/listinfo/xforms The flow of message is (depressingly) low. Concerning your problem with popups, I guess that using valgrind on xforms apps could help too. I do not have time to look at the popup code at the moment, but I guess it should be done. I am not sure that I like the memset approach, since it seems to me like papering over the issue rather than fixing it. Concerning the issue of maximum number of menus, you can always change the limit with fl_setpup_maxpup. If the number of menus is not known in advance (like in LyX), you'll need to keep track of it, which is indeed a bit annoying. I am not sure that increasing the limit automatically, which is certainly easy to do, is the best solution... Merci pour ces infos, JMarc -------------- next part -------------- An embedded message was scrubbed... From: Laurent Fournier Subject: Xforms : popup menus Date: Thu, 04 Mar 2004 11:41:54 +0100 Size: 5001 Url: http://bob.usuhs.mil/pipermail/xforms/attachments/20040304/307640ca/attachment.eml From wd4nmq at comcast.net Thu Mar 4 18:20:31 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu Mar 4 21:20:27 2004 Subject: [XForms] Window id in a form Message-ID: <4047B9BF.9030009@comcast.net> Where is the window's id stored? Ya know, the return value of XCreateWindow(). If I have an app that has only the form called, say testEvent, it would be stored in fd_testEvent->testEvent->window, but I'm not sure. I am trying to be able to have threads send ClientMessage events to the main form. I have posted that idea before. I wrote an app that writes fd_testEvent->testEvent->window to a text widget so I now what it is and then do the following: while(1){ obj = fl_do_forms(); puts("We are out of fl_do_forms()"); if(obj == FL_EVENT){ fl_XNextEvent(&ev); if(ev.type = ClientMessage){ puts("We received a ClientMessage event"); } } } I have another app that I enter the displayed id and it uses XSendEvent() to send a ClientMessage event to it. I have tested this out with a short Xlib app to make sure my sending app works, and it does. But, when I use the xforms app as the recipient, it never comes out of the fl_do_forms(). Anybody got any ideas? Jeff wd4nmq@comcast.net From jkhn2 at cam.ac.uk Sat Mar 6 12:44:10 2004 From: jkhn2 at cam.ac.uk (James Ng) Date: Mon Mar 8 08:21:47 2004 Subject: [XForms] Can't build xforms Message-ID: <002301c40378$b8e5c000$20c16f83@jkhn2xp> Dear all, I just downloaded xforms 1.0 from the mirror site ftp://ftp.u-aizu.ac.jp/pub/x11/misc/xforms/stable.pkg/1.0/ and tried to build it without success. I am using Cygwin on Windows XP Pro. Following the instructions in the INSTALL file, I ran the commands: xmkmf -a make at which point I get the following error messages: making all in ./lib/include... make[1]: Entering directory `/cygdrive/c/xforms-1.0/lib/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/lib/include' making all in ./lib... make[1]: Entering directory `/cygdrive/c/xforms-1.0/lib' make[1]: *** No rule to make target `forms-def.cpp', needed by `forms.def'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/lib' making all in ./image... make[1]: Entering directory `/cygdrive/c/xforms-1.0/image' make[1]: *** No rule to make target `flimage-def.cpp', needed by `flimage.def'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/image' making all in ./gl... make[1]: Entering directory `/cygdrive/c/xforms-1.0/gl' make[1]: *** No rule to make target `formsGL-def.cpp', needed by `formsGL.def'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/gl' making all in ./fdesign... make[1]: Entering directory `/cygdrive/c/xforms-1.0/fdesign' make[1]: *** No rule to make target `../lib/libforms.a', needed by `fdesign.exe'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/fdesign' making all in ./fd2ps... make[1]: Entering directory `/cygdrive/c/xforms-1.0/fd2ps' make[1]: *** No rule to make target `../lib/libforms.a', needed by `fd2ps.exe'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/fd2ps' make: *** [all] Error 2 Any help would be much appreciated. Thanks. James From Lawrence.Lifshitz at umassmed.edu Thu Mar 11 12:54:36 2004 From: Lawrence.Lifshitz at umassmed.edu (Lawrence M./ Lifshitz) Date: Thu Mar 11 12:54:40 2004 Subject: [XForms] 64 bit Opteron compile of xforms 1.0? Message-ID: <4050A7DC.8030201@umassmed.edu> Hi, Has anyone compiled xforms on an Opteron with Suse's 64 Linux installed? If so, what do I need to do? If not, any obvious problems with attempting such a feat? Thanks. Larry -- Lawrence M. Lifshitz, Ph. D., Associate Professor Biomedical Imaging Group (http://invitro.umassmed.edu) University of Massachusetts Medical School (http://www.umassmed.edu) Phone: (508) 856-3392 email: Lawrence.Lifshitz@umassmed.edu Fax: (508) 856-1840 web: http://invitro.umassmed.edu/lml From wd4nmq at comcast.net Thu Mar 11 22:49:41 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu Mar 11 22:49:39 2004 Subject: [XForms] ClientMessage handling change? Message-ID: <40513355.1080004@comcast.net> As I have said in previous posts I want to be able to process ClientMessage Xevent messages. After several attempts I found that ClientMessages are handled. But, it is very limited in scope. It looks for a WM_PROTOCOLS and WM_DELETE_WINDOW atoms. If it is not that, it passes it to fl_handle_form with FL_OTHER and FL_OTHER causes it to be passed to other open forms. Now, I thought the whole purpose of ClientMessage was to pass messages to specific windows, ie forms. Now, would it nor make since to have a user registered routine to handle ClientMessage's that are not WM_PROTOCOLS and WM_DELETE_WINDOW atoms? So, a flow in handle_client_message() could go: Is message type == WM_PROTOCOL? Yes, then handle it and exit function. No, is there a registered ClientMessage Handler? Yes, pass it to user handler function and exit on return. No, pass as FL_OTHER to fl_handle_form as before. The user's handler code would use it's on message type atoms. I really think this would be a good thing for xforms. It seems that gtk and kde already support this. Plus, as I previuosly mentioned it would be much easier to have worker threads use the XSendEvent to a form's event handler to do a form gui update rather then have to use mutexes in an event loop. So what does anybody who still reads this list and thinks xforms may still survive think about this idea? Jeff wd4nmq@comcast.net From Jean-Marc.Lasgouttes at inria.fr Fri Mar 12 11:19:53 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Mar 12 05:20:00 2004 Subject: [XForms] 64 bit Opteron compile of xforms 1.0? In-Reply-To: <4050A7DC.8030201@umassmed.edu> (Lawrence M.'s message of "Thu, 11 Mar 2004 12:54:36 -0500") References: <4050A7DC.8030201@umassmed.edu> Message-ID: >>>>> "Lawrence" == Lawrence M / Lifshitz writes: Lawrence> To subscribers of the xforms list Hi, Has anyone compiled Lawrence> xforms on an Opteron with Suse's 64 Linux installed? If so, Lawrence> what do I need to do? If not, any obvious problems with Lawrence> attempting such a feat? Thanks. You will probably have more success with the latest cvs snapshot found here: http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz This one uses autoconf and libtool, and is known to work one some 64bits architectures, like alpha. JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Mar 12 11:22:35 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Mar 12 05:22:40 2004 Subject: [XForms] ClientMessage handling change? In-Reply-To: <40513355.1080004@comcast.net> (wd4nmq@comcast.net's message of "Thu, 11 Mar 2004 22:49:41 -0500") References: <40513355.1080004@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list As I have said in previous Jeff> posts I want to be able to process ClientMessage Xevent Jeff> messages. After several attempts I found that ClientMessages are Jeff> handled. But, it is very limited in scope. Jeff> It looks for a WM_PROTOCOLS and WM_DELETE_WINDOW atoms. If it is Jeff> not that, it passes it to fl_handle_form with FL_OTHER and Jeff> FL_OTHER causes it to be passed to other open forms. Jeff> Now, I thought the whole purpose of ClientMessage was to pass Jeff> messages to specific windows, ie forms. Now, would it nor make Jeff> since to have a user registered routine to handle Jeff> ClientMessage's that are not WM_PROTOCOLS and WM_DELETE_WINDOW Jeff> atoms? Yes, that would be a good idea, since it is backward compatible with the current behaviour. Jeff> So, a flow in handle_client_message() could go: Jeff> Is message type == WM_PROTOCOL? Yes, then handle it and exit Jeff> function. No, is there a registered ClientMessage Handler? Yes, Jeff> pass it to user handler function and exit on return. No, pass as Jeff> FL_OTHER to fl_handle_form as before. Or you could have a default handler that handles WM_PROTOCOL, and the user handler would be free to call this or completely override it. Jeff> I really think this would be a good thing for xforms. It seems Jeff> that gtk and kde already support this. Plus, as I previuosly Jeff> mentioned it would be much easier to have worker threads use the Jeff> XSendEvent to a form's event handler to do a form gui update Jeff> rather then have to use mutexes in an event loop. Could you try to write a sample implementation? JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Mar 12 11:24:23 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Mar 12 05:24:29 2004 Subject: [XForms] Can't build xforms In-Reply-To: <002301c40378$b8e5c000$20c16f83@jkhn2xp> (James Ng's message of "Sat, 6 Mar 2004 12:44:10 -0000") References: <002301c40378$b8e5c000$20c16f83@jkhn2xp> Message-ID: >>>>> "James" == James Ng writes: James> To subscribers of the xforms list Dear all, James> I just downloaded xforms 1.0 from the mirror site James> ftp://ftp.u-aizu.ac.jp/pub/x11/misc/xforms/stable.pkg/1.0/ and James> tried to build it without success. I am using Cygwin on Windows James> XP Pro. I do not have experience myself on building xforms on cygwin. Moreover, the situation is probably different with the latest autoconf based version. Could you try out http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz ? JMarc From wd4nmq at comcast.net Fri Mar 12 09:50:01 2004 From: wd4nmq at comcast.net (Jeff) Date: Fri Mar 12 09:50:03 2004 Subject: [XForms] Maintainers? Message-ID: <4051CE19.1080606@comcast.net> Who are the "offical" maintainers of xforms? I remember that Steve Lamont had to give it up, but who actualy took over? Jeff wd4nmq@comcast.net From Jean-Marc.Lasgouttes at inria.fr Fri Mar 12 16:22:52 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Mar 12 10:22:59 2004 Subject: [XForms] Maintainers? In-Reply-To: <4051CE19.1080606@comcast.net> (wd4nmq@comcast.net's message of "Fri, 12 Mar 2004 09:50:01 -0500") References: <4051CE19.1080606@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list Who are the "offical" Jeff> maintainers of xforms? I remember that Steve Lamont had to give Jeff> it up, but who actualy took over? The official maintainer is Angus Leeming, who seems to have less time recently to finish up what he has done (mainly to convertion to autoconf, but also many fixes). I do have cvs access too, but my knowledge of the internals of xforms (like this message passing stuff) is a bit mysterious to me. The goal before savannah got compromised was to cleanup what we have now and release it as 1.1. The we can have a look at new features to add. The intention is not to turn xforms into something than can rival with kde or gtk, but rather to maintain it in a usable form and fix bugs. Of course, to Angus and myself, usable means 'usable for LyX', since we are both LyX maintainers. There seem to be several people using xforms with GL, for example, and I know nothing about that. Anybody who is willing to give a hand is welcome, as far as I am concerned. JMarc From angus.leeming at btopenworld.com Sun Mar 14 17:15:20 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sun Mar 14 12:15:12 2004 Subject: [XForms] Maintainers? In-Reply-To: References: <4051CE19.1080606@comcast.net> Message-ID: <200403141715.20395.angus.leeming@btopenworld.com> On Friday 12 March 2004 3:22 pm, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Jeff" == Jeff writes: > > Jeff> To subscribers of the xforms list Who are the "offical" > Jeff> maintainers of xforms? I remember that Steve Lamont had to > give Jeff> it up, but who actualy took over? > > The official maintainer is Angus Leeming, who seems to have less > time recently to finish up what he has done (mainly to convertion > to autoconf, but also many fixes). I do have cvs access too, but my > knowledge of the internals of xforms (like this message passing > stuff) is a bit mysterious to me. > > The goal before savannah got compromised was to cleanup what we > have now and release it as 1.1. The we can have a look at new > features to add. The intention is not to turn xforms into something > than can rival with kde or gtk, but rather to maintain it in a > usable form and fix bugs. Of course, to Angus and myself, usable > means 'usable for LyX', since we are both LyX maintainers. Jean-Marc, all, I *have* been very busy recently. Apologies for neglecting this list. I would like to upload the xforms-1.0 source code to the home page once more but need to have/use pgp to do so. As this will require me to find the time to read up on pgp and how to use it, this may take some time :-( So, Jean-Marc, if you have pgp set up on your machines, the archive is at www.devel.lyx.org/~leeming/stable.pkg/1.0/README-1.0 www.devel.lyx.org/~leeming/stable.pkg/1.0/xforms-1.0.tar.gz Angus From wd4nmq at comcast.net Mon Mar 15 00:50:45 2004 From: wd4nmq at comcast.net (Jeff) Date: Mon Mar 15 00:50:40 2004 Subject: [XForms] Client Message handler success. Message-ID: <40554435.8070409@comcast.net> Angus and Jean-marc, (Lets try this using my registered email account :-), Sorry) I have the code working to allow for a user supplied callback to handle ClientMessage XEvents. It was actually very little code to change. Just tracing the code to find where to put it was a royal pain . I quick synopsis. XClient messages are used as an XEvent message that has user defined data. Refer to XLib documents for the CLient message data structure. Now, the present xforms seems to use client messages for forms to destroy other forms and use the WM_PROTOCOLS and WM_DELETE_WINDOW X atoms to specify that action. And of course, you can use user defined atoms. If the message_type is not these, the client message is passed to any other forms in the forms list. Now, I do not understand why if the client message is not WM_PROTOCOLS, etc, it is passed on. The whole purpose of XSendEvent with ClientMessage is to send it to a SPECIFIC window, or form in xforms terminology. So here is what I did. I added a member to the FL_FORMS structure to hold a function pointer. So only two lines were added to forms.h line 649: typedef void (*FL_CLIENT_CALLBACK)(void *); line 703: FL_CLIENT_CALLBACK client_callback; in objects.c added at line 105 form->client_callback = 0; And in forms.c removed line 1657 fl_handle_form(form, FL_OTHER, 0, xev); and replaced it with: if(form->client_callback){ if(!form->client_callback(xev)) fl_handle_form(form, FL_OTHER, 0, xev); } else fl_handle_form(form, FL_OTHER, 0, xev); What this does is test to see if a client callback has been set, if not, it goes through fl_handle_form just like before. Also the client callback returns a TRUE if it did consume the event and a FLASE if it did not. If a FALSE is returned, fl_handle_form() is called as in original code. So, in the users code you need only assign a function pointer to (your form name)->client_callback to get ClientMessage's sent to you code. A quick snippet: // user's ClientMessage handler: int clientCallback(XEvent *xev){ // test message type for atom defining data structure // and handle it. return 1; } // This code is in initialization before do_forms(); fd_testEvent->testEvent->client_callback = clientCallback; One thing I did notice as I traced through the code starting at fl_handle_form with FL_OTHER as the event was I could not find any other code in that chain that tested for FL_OTHER event. I think that it is a dead event starting at fl_handle_form. But, just to make sure I left the chain in if the client message is not consumed by user code. This is just a prelimenary annoucement. I am doing more testing and once I believe it is stable and introduces no bugs, I will do difff and pass the patch to you. I hope to make it into the next release, which I also hope is coming soon, as I want to use this on an amatuer radio application I wrote. And, if I use it others need to be able to get the same xforms version from savannah. Any idea on when the next release will happen? As I have stated before, this will allow worker threads to be able to send ClientMessage XEvents to the gui thread containing user defined atoms to display data, set indicators, etc WITHOUT having to create/lock/unlock mutexes in a big while loop. Since the message is on the xforms gui event queue, it is handles just like a mouse click or key pressed event. Creatly simplifing code. Please feel free to ask questions or make comments. Jeff wd4nmq@comcast.net From Jean-Marc.Lasgouttes at inria.fr Tue Mar 16 16:33:15 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 16 10:33:27 2004 Subject: [XForms] Maintainers? In-Reply-To: <200403141715.20395.angus.leeming@btopenworld.com> (Angus Leeming's message of "Sun, 14 Mar 2004 17:15:20 +0000") References: <4051CE19.1080606@comcast.net> <200403141715.20395.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I *have* been very busy recently. Apologies for neglecting this Angus> list. Angus> I would like to upload the xforms-1.0 source code to the home Angus> page once more but need to have/use pgp to do so. As this will Angus> require me to find the time to read up on pgp and how to use Angus> it, this may take some time :-( Angus> So, Jean-Marc, if you have pgp set up on your machines, the Angus> archive is at Angus> www.devel.lyx.org/~leeming/stable.pkg/1.0/README-1.0 Angus> www.devel.lyx.org/~leeming/stable.pkg/1.0/xforms-1.0.tar.gz I have gpg, and just uploaded a public key and uploaded the files to savannah. I really do not understand anything about gpg, so I'll just see what happens... Do I have to be admin to be allowed to upload files? I guess time will tell. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 16 16:48:31 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 16 10:48:38 2004 Subject: [XForms] Client Message handler success. In-Reply-To: <40554435.8070409@comcast.net> (wd4nmq@comcast.net's message of "Mon, 15 Mar 2004 00:50:45 -0500") References: <40554435.8070409@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list Angus and Jean-marc, Jeff> (Lets try this using my registered email account :-), Sorry) Jeff> I have the code working to allow for a user supplied callback to Jeff> handle ClientMessage XEvents. Jeff> It was actually very little code to change. Just tracing the Jeff> code to find where to put it was a royal pain . Jeff> I quick synopsis. The general idea looks fine. Let's see the details :) Jeff> line 649: typedef void (*FL_CLIENT_CALLBACK)(void *); Why not like the others typedef void (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); Is should be possible, like with the atclose callback to set either a global client callback or a forms one. Or maybe what I am saying does not make sense? Also, if you add this new callback to forms_ struct, you break binary comaptibility, right? Can we avoid that somehow? Jeff> What this does is test to see if a client callback has been set, Jeff> if not, it goes through fl_handle_form just like before. Also Jeff> the client callback returns a TRUE if it did consume the event Jeff> and a FLASE if it did not. If a FALSE is returned, Jeff> fl_handle_form() is called as in original code. This is OK. Jeff> So, in the users code you need only assign a function pointer to Jeff> (your form name)->client_callback to get ClientMessage's sent to Jeff> you code. fd_testEvent-> testEvent->client_callback = clientCallback; I'd rather see something like fl_set_client_callback(fd_testEvent->testEvent, clientCallback); if only to do something similar to the other callbacks. Jeff> This is just a prelimenary annoucement. I am doing more testing Jeff> and once I believe it is stable and introduces no bugs, I will Jeff> do difff and pass the patch to you. I hope to make it into the Jeff> next release, which I also hope is coming soon, as I want to use Jeff> this on an amatuer radio application I wrote. And, if I use it Jeff> others need to be able to get the same xforms version from Jeff> savannah. This is definitely something that could go in next version, excpet that I am a bit worried about binary compatibility. Jeff> Any idea on when the next release will happen? I do not know yet :( JMarc From wd4nmq at comcast.net Tue Mar 16 11:40:06 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue Mar 16 11:39:59 2004 Subject: [XForms] Client Message handler success. In-Reply-To: References: <40554435.8070409@comcast.net> Message-ID: <40572DE6.6080604@comcast.net> Jean-Marc, Can you explain what you you mean by "breaking binary compatiblity"? >Why not like the others >typedef void (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); >Is should be possible, like with the atclose callback to set either a >global client callback or a forms one. Or maybe what I am saying does >not make sense? >I'd rather see something like >fl_set_client_callback(fd_testEvent->testEvent, clientCallback); >if only to do something similar to the other callbacks. Yea, I thought about that later, Heh, it was 1 am when I was doing this :-). Jean-Marc Lasgouttes wrote: >>>>>>"Jeff" == Jeff writes: >>>>>> >>>>>> > >Jeff> To subscribers of the xforms list Angus and Jean-marc, > >Jeff> (Lets try this using my registered email account :-), Sorry) > >Jeff> I have the code working to allow for a user supplied callback to >Jeff> handle ClientMessage XEvents. > >Jeff> It was actually very little code to change. Just tracing the >Jeff> code to find where to put it was a royal pain . > >Jeff> I quick synopsis. > >The general idea looks fine. Let's see the details :) > >Jeff> line 649: typedef void (*FL_CLIENT_CALLBACK)(void *); > >Why not like the others >typedef void (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); > >Is should be possible, like with the atclose callback to set either a >global client callback or a forms one. Or maybe what I am saying does >not make sense? > >Also, if you add this new callback to forms_ struct, you break binary >comaptibility, right? Can we avoid that somehow >Jeff> What this does is test to see if a client callback has been set, >Jeff> if not, it goes through fl_handle_form just like before. Also >Jeff> the client callback returns a TRUE if it did consume the event >Jeff> and a FLASE if it did not. If a FALSE is returned, >Jeff> fl_handle_form() is called as in original code. > >This is OK. > >Jeff> So, in the users code you need only assign a function pointer to >Jeff> (your form name)->client_callback to get ClientMessage's sent to >Jeff> you code. > >fd_testEvent-> testEvent->client_callback = clientCallback; > >I'd rather see something like >fl_set_client_callback(fd_testEvent->testEvent, clientCallback); >if only to do something similar to the other callbacks. > >Jeff> This is just a prelimenary annoucement. I am doing more testing >Jeff> and once I believe it is stable and introduces no bugs, I will >Jeff> do difff and pass the patch to you. I hope to make it into the >Jeff> next release, which I also hope is coming soon, as I want to use >Jeff> this on an amatuer radio application I wrote. And, if I use it >Jeff> others need to be able to get the same xforms version from >Jeff> savannah. > >This is definitely something that could go in next version, excpet >that I am a bit worried about binary compatibility. > >Jeff> Any idea on when the next release will happen? > >I do not know yet :( > >JMarc > > > > From wd4nmq at comcast.net Tue Mar 16 22:52:43 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue Mar 16 22:52:34 2004 Subject: [XForms] Redone client callback Message-ID: <4057CB8B.9000207@comcast.net> I changed code on my client callbacK to match the other callback calls. In forms.h: typedef int (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); and: FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( FL_FORM *form, FL_CLIENT_CALLBACK rcb ); I added the new call in forms.c: FL_CLIENT_CALLBACK fl_register_client_callback(FL_FORM *form,FL_CLIENT_CALLBACK clientCallback){ FL_CLIENT_CALLBACK old_rcb; old_rcb =form->client_callback; form->client_callback = clientCallback; return old_rcb; } Jeff wd4nmq@comcast.net From tc_zhao at yahoo.com Wed Mar 17 22:57:45 2004 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Thu Mar 18 01:57:50 2004 Subject: [XForms] Redone client callback In-Reply-To: <4057CB8B.9000207@comcast.net> Message-ID: <20040318065745.3868.qmail@web13423.mail.yahoo.com> Thanks, Jeff. I think it's a good addition. --- Jeff wrote: > To subscribers of the xforms list > > > I changed code on my client callbacK to match the other callback calls. > In forms.h: > typedef int (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); > > and: > > FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( > FL_FORM *form, > FL_CLIENT_CALLBACK rcb > ); > > I added the new call in forms.c: > FL_CLIENT_CALLBACK > fl_register_client_callback(FL_FORM *form,FL_CLIENT_CALLBACK > clientCallback){ > FL_CLIENT_CALLBACK old_rcb; > > old_rcb =form->client_callback; > form->client_callback = clientCallback; > return old_rcb; > } > > Jeff > wd4nmq@comcast.net > > > _______________________________________________ > 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! Mail - More reliable, more storage, less spam http://mail.yahoo.com From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 12:11:56 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 30 05:12:04 2004 Subject: [XForms] [PATCH] Trying to go ahead Message-ID: Hello, Let's try to go ahead... The attached patch finally fixes the signal code (in a trivial way) and updates a bit the version scheme. Angus, I'd appreciate that you take a look at it before I commit. What I would like to do now is to release xforms 1.0.90, which will be a prerelease of xforms 1.1. The idea of the new numbering scheme is that all releases with FL_FIXLEVEL >= 50 are development releases. 1.0.90 will serve mainly as a testbed for the new autotools-based configuration scheme. Before we can ship 1.1.0, there are several patches that we should investigate: - the patch to handle client message (once we get it, of course) - the patch to xpopup.c memory handling (I have to take a serious look at it) - the patch to fix clipping of text objects And probably others I forgot. Let me now. Angus, does releasing 1.0.90 look like a good idea to you? I can do it if you want. In other news, I have finally uploaded xforms-1.0 to the savannah web site again (at last!). I will also upload the docs (only 0.89, unfortunately...). JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: prepare-1.0.90.diff Type: text/x-patch Size: 7707 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040330/f1b933aa/prepare-1.0.90.bin From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 12:17:54 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 30 05:17:59 2004 Subject: [XForms] Redone client callback In-Reply-To: <20040318065745.3868.qmail@web13423.mail.yahoo.com> (T. C. Zhao's message of "Wed, 17 Mar 2004 22:57:45 -0800 (PST)") References: <20040318065745.3868.qmail@web13423.mail.yahoo.com> Message-ID: >>>>> "T" == T C Zhao writes: T> Thanks, Jeff. I think it's a good addition. Thanks for chiming in, TC. BTW, if I may be a bit insistent, is there a chance that we get the docs in source form? Finally, if we finally get to construct a new web site, would you agree to let us 'steal' some parts of the old one? JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 12:28:17 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 30 05:28:23 2004 Subject: [XForms] Client Message handler success. In-Reply-To: <40572DE6.6080604@comcast.net> (wd4nmq@comcast.net's message of "Tue, 16 Mar 2004 11:40:06 -0500") References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> Jean-Marc, Can you explain what you you mean by "breaking binary Jeff> compatiblity"? You add your new pointer in line 703, that is /* WM_DELETE_WINDOW message handler */ FL_FORM_ATCLOSE close_callback; void *close_data; /*========= HERE=============*/ void *flpixmap; /* back buffer */ This is in the FL_FORM struct. This means that any program built against version 1.0 of xforms, when it tries to access the flpixmap member of a form, will actually access your pointer, and a crash will occur in the best case. This means that a program built against xforms 1.0 will not work if xforms is upgraded. This is definitely bad, and we do such things only if it is unavoidable. Note however that FL_FORM ends with: void *attach_data; int no_tooltip; int reserved[10]; /* future use */ } FL_FORM; This 'reserved' array can be used to add new entries to FL_FORM. I would do something like line 649: typedef void (*FL_CLIENT_CALLBACK)(void *); line 703: FL_CLIENT_CALLBACK client_callback; void *attach_data; int no_tooltip; FL_CLIENT_CALLBACK client_callback; int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ } FL_FORM; I use an explicit sizeof here because I do not know what the size of a pointer is (on a 64 bits architecture, it will be 8). A question though is whether you need to support having a different callback for each form. If we decide that it is only possible to register _one_ callback for the whole app (note that the forms pointer can be passed to the callback, so it is possible to work from that), then the compatibility problem goes away. I hope those explanations were useful. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 12:49:20 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 30 05:49:25 2004 Subject: [XForms] Xforms 0.89 documentation available in postscript form Message-ID: I uploaded to the files section the xforms documentation that was previously available through the xforms ftp site. It is all we have for now, so it has not been updated for 1.0. I did not upload the xforms 0.88 documentation, but I can do it if there is a need for it. [I uploaded a README file along with it, but for some reason it just disappeared...] JMarc From xyzzy at speakeasy.org Tue Mar 30 03:18:59 2004 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue Mar 30 06:19:08 2004 Subject: [XForms] Client Message handler success. In-Reply-To: Message-ID: On Tue, 30 Mar 2004, Jean-Marc Lasgouttes wrote: > int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ That should be: int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 13:58:02 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 30 06:58:09 2004 Subject: [XForms] Client Message handler success. In-Reply-To: (Trent Piepho's message of "Tue, 30 Mar 2004 03:18:59 -0800 (PST)") References: Message-ID: >>>>> "Trent" == Trent Piepho writes: Trent> To subscribers of the xforms list Trent> On Tue, 30 Mar 2004, Jean-Marc Lasgouttes wrote: >> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ Trent> That should be: Trent> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; Opps! You are right... Actually, I read char instead of int. JMarc From angus.leeming at btopenworld.com Tue Mar 30 13:03:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Mar 30 07:01:33 2004 Subject: [XForms] Re: [PATCH] Trying to go ahead In-Reply-To: References: Message-ID: <200403301303.33137.angus.leeming@btopenworld.com> On Tuesday 30 March 2004 5:11 am, Jean-Marc Lasgouttes wrote: > Hello, > > Let's try to go ahead... The attached patch finally fixes the > signal code (in a trivial way) and updates a bit the version > scheme. Angus, I'd appreciate that you take a look at it before I > commit. I have looked. Looks good. > What I would like to do now is to release xforms 1.0.90, which will > be a prerelease of xforms 1.1. The idea of the new numbering scheme > is that all releases with FL_FIXLEVEL >= 50 are development > releases. Makes sense. > Angus, does releasing 1.0.90 look like a good idea to you? I can do > it if you want. Yes please. The good news is that I'm going to make a serious attempt to sort out gnupg. > In other news, I have finally uploaded xforms-1.0 to the savannah > web site again (at last!). I will also upload the docs (only 0.89, > unfortunately...). Thanks for all this. Angus From msz at astrouw.edu.pl Tue Mar 30 14:11:13 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue Mar 30 07:11:21 2004 Subject: [XForms] Xforms 0.89 documentation available in postscript form In-Reply-To: References: Message-ID: <20040330121113.GA25064@astrouw.edu.pl> On Tue, Mar 30, 2004 at 12:49:20PM +0200, Jean-Marc Lasgouttes wrote: > I uploaded to the files section the xforms documentation that was > previously available through the xforms ftp site. It is all we have > for now, so it has not been updated for 1.0. Hi, Is there any real chance to get documentation sources from the original authors? Looks strange to have a GPLed software w/o up-to-date docs. If not, maybe at least some short description of changes introduced since 0.89? regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 14:28:17 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 30 07:28:34 2004 Subject: [XForms] Xforms 0.89 documentation available in postscript form In-Reply-To: <20040330121113.GA25064@astrouw.edu.pl> (Michal Szymanski's message of "Tue, 30 Mar 2004 14:11:13 +0200") References: <20040330121113.GA25064@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> Is there any real chance to get documentation sources from the Michal> original authors? Looks strange to have a GPLed software w/o Michal> up-to-date docs. TC Zhao has promised to send us the sources as soon as he has time to fetch it. Obviously he did not have time yet. Michal> If not, maybe at least some short description of changes Michal> introduced since 0.89? What we have is the NEWS file. If I remove all bug fixes, here is what remains as user-visible changes. As you see, it is really not much. There has also been lots of small bug fixes. JMarc ------------------------------------------ V1.1cvs o Migrate from Imake to the GNU autotools. o fl_init_RGBdatabase is no longer needed, does nothing and is retained for compatibility only. o Pass KeyRelease events to the widgets. o Enable fdesign to work correctly with paths like ../foo/bar/your_file.fd. o Add a -dir option to fdesign to place generated files in destdir. ------------------------------------------ V1.0RC1 May 30, 2002 o. Very minor API changes. `FL_ERROR_FUNC' has been typedef'd for fl_set_error_handler() function. `FL_VAL_FILTER' has also been typedef'd for use by fl_set_{counter,slider}_filter(). Neither of these changes should affect much of anything. o. The flimage functions are in their own library now: libflimage. They should be usable standalone, but I have not had an opportunity to test them. o. The OpenGL functions are in their own library now: libformsGL fl_add_glcanvas() and its ilk live there. Application build scripts/ Makefiles should include -lformsGL. o. The Xpm library is no longer built or distributed with XForms. o. The majority of the function prototypes in `forms.h' have been expanded to include variable names. From angus.leeming at btopenworld.com Tue Mar 30 13:36:25 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Mar 30 07:34:23 2004 Subject: [XForms] Xforms 0.89 documentation available in postscript form In-Reply-To: References: <20040330121113.GA25064@astrouw.edu.pl> Message-ID: <200403301336.25121.angus.leeming@btopenworld.com> On Tuesday 30 March 2004 7:28 am, Jean-Marc Lasgouttes wrote: > What we have is the NEWS file. If I remove all bug fixes, here is > what remains as user-visible changes. As you see, it is really not > much. There has also been lots of small bug fixes. + the snprintf functions are now 'hidden' away, are no longer compiled into their own library, are not compiled at all if your system has 'em and are not accessible as fl_snprintf etc. Angus From lasgouttes at lyx.org Tue Mar 30 16:38:29 2004 From: lasgouttes at lyx.org (Jean-Marc Lasgouttes) Date: Tue Mar 30 09:38:34 2004 Subject: [XForms] [ANNOUNCE] XForms 1.0.90 Message-ID: Dear XForms users, I am glad to announce the release of XForms 1.0.90, which marks a first step on the road to XForms 1.1.0. This development release has the primary goal of making sure that the new autoconf-based setup used for XForms works correctly on as many architectures as possible. There are still a few bugs to fix before 1.1.0, and I am sure that a couple new feature will creep in too. Here is the relevant excerpt from the ANNOUNCE file: V1.0.90 March 30, 2004 o Migrate from Imake to the GNU autotools. o "Composite" widgets, such as the browser, can now display tooltips. o Prevent a crash when rotating grayscale images by 90 degree multiples. o Enable xforms to handle XPixmaps containing colour "opaque". o Tabfolder widgets are now resizable. o Re-add fl_lookup_RGBcolor which fell off the dist at 1.0pre3. o fl_init_RGBdatabase is no longer needed, does nothing and is retained for compatibility only. o Pass KeyRelease events to the widgets. o Display the tab forms correctly when using bottom tab folders. o Enable xforms to read a wider variety of gif and jpeg images. o Enable fdesign to work correctly with paths like ../foo/bar/your_file.fd. o Add a -dir option to fdesign to place generated files in destdir. o Add an RPM spec file. o Get rid of the separate snprintf compatibility library. o Removal of lots of little pieces of cruft that crept into the xforms 1.0 release. You can grab xforms from the download section of the XForms project page: http://savannah.nongnu.org/download/xforms/ Please send bug reports to this list (xforms@bob.usuhs.mil). JMarc From hjohnson at mail.psychiatry.uiowa.edu Tue Mar 30 09:06:12 2004 From: hjohnson at mail.psychiatry.uiowa.edu (Hans J. Johnson) Date: Tue Mar 30 10:06:16 2004 Subject: [XForms] More robust XPM checking patch Message-ID: <1080659171.8009.14.camel@ipl-imac.psychiatry.uiowa.edu> Hello Xforms Maintainers, I've applied the patch below for quite some time now to various versions of xforms. It has been submitted to the list before, but may have been overlooked, or silently discredited. This patch allows me to compile xforms on both SGI-IRIX, and various versions of Linux. (the XPM_34g_or_later flag is not set properly on SGI-IRIX). Please consider including it in future releases. Regards, Hans J. Johnson hans-johnson@uiowa.edu -------------- next part -------------- --- pixmap.c.old Mon Apr 1 16:06:48 2002 +++ pixmap.c Mon Apr 1 15:52:26 2002 @@ -84,19 +84,21 @@ if (!xpma || !xpma->colormap) return; - if (XPM_34g_or_later) + +#if (XpmFormat >=3) && (XpmVersion >= 4) && ( XpmRevision >= 7) { M_warn("XpmCleanUP", "Using 3.4g features"); XFreeColors(flx->display, xpma->colormap, xpma->alloc_pixels, xpma->nalloc_pixels, 0); } - else +#else { /* somewhat dangerous */ M_warn("XpmCleanUP", "Using old xpm libs"); XFreeColors(flx->display, xpma->colormap, xpma->pixels, xpma->npixels, 0); } +#endif xpma->colormap = 0; From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 17:29:32 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Mar 30 10:29:38 2004 Subject: [XForms] More robust XPM checking patch In-Reply-To: <1080659171.8009.14.camel@ipl-imac.psychiatry.uiowa.edu> (Hans J. Johnson's message of "Tue, 30 Mar 2004 09:06:12 -0600") References: <1080659171.8009.14.camel@ipl-imac.psychiatry.uiowa.edu> Message-ID: >>>>> "Hans" == Hans J Johnson writes: Hans> I've applied the patch below for quite some time now to various Hans> versions of xforms. It has been submitted to the list before, Hans> but may have been overlooked, or silently discredited. Hello, I do not remember seeing this patch... Hans> This patch allows me to compile xforms on both SGI-IRIX, and Hans> various versions of Linux. (the XPM_34g_or_later flag is not set Hans> properly on SGI-IRIX). Do you know why the test fails on SGI-IRIX? The only reason I can see is that the version in the xpm.h file (used in the #if) does not match the one in the library (used in the original version). This would be of course a bad configuration on your machine (and this does happens on some badly configured systems where I work). So if I were you, I'd check whether the library and headers match... Anyway, the patch looks reasonable, so I think I'll apply it. Thanks. JMarc From wd4nmq at comcast.net Tue Mar 30 12:07:35 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue Mar 30 12:07:48 2004 Subject: [XForms] Client Message handler success. In-Reply-To: References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> Message-ID: <4069A957.5050201@comcast.net> Jean-Marc, Ok, I see what you are saying. I thought you may have meant MS-Windows compatabilty somehow and just wanted it clarified. I agree moving it to the end and taking part of the reserve would be the best place and I did not think of "backwards binary" compatibility. I will make those changes today. On the question of each form having a client message callback I believe that would be the correct way to go. As I understand it, each form is a seperate X window. So, since XSendEvent() targets an X window, it would make sense for each form/window to have it's own client message callback. This would also save the application programmer from having to decide which form the message is for. Plus, it would be on the developer to come up with a data structure member to represent the targeted form as XSendEvent()/XNextEvent() only contain values of the targeted display and window/form. Jean-Marc Lasgouttes wrote: >>>>>>"Jeff" == Jeff writes: >>>>>> >>>>>> > >Jeff> Jean-Marc, Can you explain what you you mean by "breaking binary >Jeff> compatiblity"? > >You add your new pointer in line 703, that is > > /* WM_DELETE_WINDOW message handler */ > FL_FORM_ATCLOSE close_callback; > void *close_data; >/*========= HERE=============*/ > void *flpixmap; /* back buffer */ > >This is in the FL_FORM struct. This means that any program built >against version 1.0 of xforms, when it tries to access the flpixmap >member of a form, will actually access your pointer, and a crash will >occur in the best case. > >This means that a program built against xforms 1.0 will not work if >xforms is upgraded. This is definitely bad, and we do such things only >if it is unavoidable. > >Note however that FL_FORM ends with: > > void *attach_data; > int no_tooltip; > int reserved[10]; /* future use */ >} >FL_FORM; > >This 'reserved' array can be used to add new entries to FL_FORM. I >would do something like > >line 649: >typedef void (*FL_CLIENT_CALLBACK)(void *); > >line 703: >FL_CLIENT_CALLBACK client_callback; > > void *attach_data; > int no_tooltip; > > FL_CLIENT_CALLBACK client_callback; > > int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ >} >FL_FORM; > >I use an explicit sizeof here because I do not know what the size of a >pointer is (on a 64 bits architecture, it will be 8). > >A question though is whether you need to support having a different >callback for each form. If we decide that it is only possible to >register _one_ callback for the whole app (note that the forms pointer >can be passed to the callback, so it is possible to work from that), >then the compatibility problem goes away. > >I hope those explanations were useful. > >JMarc > > > From wd4nmq at comcast.net Tue Mar 30 12:10:40 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue Mar 30 12:10:46 2004 Subject: [XForms] Client Message handler success. In-Reply-To: References: Message-ID: <4069AA10.20604@comcast.net> I will be using Trent's suggestion: int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; OK? Anybody see any probelms? unsigned char Jean-Marc Lasgouttes wrote: >To subscribers of the xforms list > > > > >>>>>>"Trent" == Trent Piepho writes: >>>>>> >>>>>> > >Trent> To subscribers of the xforms list >Trent> On Tue, 30 Mar 2004, Jean-Marc Lasgouttes wrote: > > >>>int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ >>> >>> > >Trent> That should be: > >Trent> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; > >Opps! You are right... Actually, I read char instead of int. > >JMarc >_______________________________________________ >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 wd4nmq at comcast.net Tue Mar 30 12:16:36 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue Mar 30 12:16:44 2004 Subject: [XForms] [ANNOUNCE] XForms 1.0.90 In-Reply-To: References: Message-ID: <4069AB74.3050100@comcast.net> Jean-Marc, If it is ok with you, I will apply my changes to this new release and will make diffs againest it. I hope to have the diffs either tonight or tomorrow. Jean-Marc Lasgouttes wrote: >To subscribers of the xforms list > > > >Dear XForms users, > >I am glad to announce the release of XForms 1.0.90, which marks a >first step on the road to XForms 1.1.0. This development release has >the primary goal of making sure that the new autoconf-based setup used >for XForms works correctly on as many architectures as possible. > >There are still a few bugs to fix before 1.1.0, and I am sure that a >couple new feature will creep in too. > >Here is the relevant excerpt from the ANNOUNCE file: > >V1.0.90 March 30, 2004 > o Migrate from Imake to the GNU autotools. > o "Composite" widgets, such as the browser, can now display tooltips. > o Prevent a crash when rotating grayscale images by 90 degree multiples. > o Enable xforms to handle XPixmaps containing colour "opaque". > o Tabfolder widgets are now resizable. > o Re-add fl_lookup_RGBcolor which fell off the dist at 1.0pre3. > o fl_init_RGBdatabase is no longer needed, does nothing and is > retained for compatibility only. > o Pass KeyRelease events to the widgets. > o Display the tab forms correctly when using bottom tab folders. > o Enable xforms to read a wider variety of gif and jpeg images. > o Enable fdesign to work correctly with paths like ../foo/bar/your_file.fd. > o Add a -dir option to fdesign to place generated files in destdir. > o Add an RPM spec file. > o Get rid of the separate snprintf compatibility library. > o Removal of lots of little pieces of cruft that crept into the xforms > 1.0 release. > >You can grab xforms from the download section of the XForms project >page: >http://savannah.nongnu.org/download/xforms/ > >Please send bug reports to this list (xforms@bob.usuhs.mil). > >JMarc >_______________________________________________ >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 Wed Mar 31 12:12:27 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Mar 31 05:12:34 2004 Subject: [XForms] Client Message handler success. In-Reply-To: <4069AA10.20604@comcast.net> (wd4nmq@comcast.net's message of "Tue, 30 Mar 2004 12:10:40 -0500") References: <4069AA10.20604@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> I will be using Trent's suggestion: int reserved[10 - Jeff> sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; Jeff> OK? Anybody see any probelms? I think that's fine. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 12:12:58 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Mar 31 05:13:03 2004 Subject: [XForms] [ANNOUNCE] XForms 1.0.90 In-Reply-To: <4069AB74.3050100@comcast.net> (wd4nmq@comcast.net's message of "Tue, 30 Mar 2004 12:16:36 -0500") References: <4069AB74.3050100@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list Jean-Marc, Jeff> If it is ok with you, I will apply my changes to this new Jeff> release and will make diffs againest it. I hope to have the Jeff> diffs either tonight or tomorrow. Very good. I was about to ask you to do that :) JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 12:25:12 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Mar 31 05:25:17 2004 Subject: [XForms] Client Message handler success. In-Reply-To: <4069A957.5050201@comcast.net> (wd4nmq@comcast.net's message of "Tue, 30 Mar 2004 12:07:35 -0500") References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> <4069A957.5050201@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> On the question of each form having a client message callback I Jeff> believe that would be the correct way to go. As I understand it, Jeff> each form is a seperate X window. So, since XSendEvent() targets Jeff> an X window, it would make sense for each form/window to have Jeff> it's own client message callback. That makes sense. It was just a suggestion. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 12:51:23 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Mar 31 05:51:28 2004 Subject: [XForms] Re: Xforms : popup menus In-Reply-To: <404707F2.2070306@lapp.in2p3.fr> (Laurent Fournier's message of "Thu, 04 Mar 2004 11:41:54 +0100") References: <404707F2.2070306@lapp.in2p3.fr> Message-ID: >>>>> "Laurent" == Laurent Fournier writes: Dear Laurent, Sorry for not answering earlier to your message. I wanted to take a look at the code first. I'd like to settle this popup issue before 1.1.0, but I am somhow not satisfied with the solution of using memset (why? I do not know precisely :) Laurent> Dear Jean-Marc, I will try to give you some more information Laurent> on how I use Xforms and how I discovered this bug. [snip] Laurent> *** The context of using the menus of Xforms. The first steps Laurent> of development were to use menus (not directly popups) Laurent> because there was no need for cascaded menus. I got crashes Laurent> some times when exiting from a menu (with or without Laurent> selection) but I did not compile on LynxOS... then I could Laurent> not find the reason of the problem. When came the need of Laurent> cascaded menus, then I used directly popups, with the Laurent> PopupEntry structure. The data is made of a fixed part and a Laurent> variable part coming from the configuration file. Things Laurent> became worse ! I then turned myself towards LynxOS which I Laurent> know to be very sensitive to memory corruptions (we use Laurent> real-time CPUs for data acquisition which is also a big part Laurent> of my job). In a few hours I got several segmentation Laurent> violations and I discovered the following : When calling Laurent> fl_freepup(), there is a loop which frees all menu items by Laurent> looping on ALL entries (it is limited to FL_MAXPUPI, not Laurent> nitems) but the data is not set to 0. What particular data should have been set to zero and caused problem? At least the pointers are correctly reset. Was the problem related to callbacks? Laurent> This is the reason why I replaced all settings to 0 in the Laurent> initialization routine by a single memset() (which is Laurent> portable on almost every OS) and I have done the same when Laurent> setting the maximum number of popups (fl_setpup_maxpup()) Laurent> because realloc() does not set the data to 0. Laurent> The call to memset() should not affect speed as it is only Laurent> called at initialization time. When calling fl_safe_free(), Laurent> the NULL pointers are obviously not freed and everything Laurent> works fine. I agree that memset is not expensive. I would just like to understand where the real problem was, in order to be sure that we do not miss something. Laurent> I sometimes had the problem reported in the forum but I did Laurent> not experience the problem since this correction. The current Laurent> patched version is not released yet to users and I do not Laurent> have enough feedback from the users. Besides this, one major Laurent> improvement to popups would be not to use a "maxpup" value Laurent> but to have automatic reallocation, when needed. My Laurent> application stores much more than 64 menus but the number of Laurent> menus is not known by advance... I am not sure whether automatic reallocation is really a good thing. It may bite you if you have a popup leak (which may happen easily). Laurent> Last but not least : could you please send me the exact web Laurent> address when reading about Xforms and getting new releases ? Laurent> I would be grateful to get the mails from the Xforms Laurent> developers, as I feel now to have enough experience on the Laurent> whole library. The home of the xforms project is now: https://savannah.nongnu.org/projects/xforms You will find in the Files section xforms 1.0.90, released yesterday in preparation for 1.1.0. I would appreciate if you could test it with the systems you have here (like lynxOS) since we have switched to a new configuration scheme. There is also a mailing list accessible from there: http://cweblog.usuhs.mil/mailman/listinfo/xforms Please use the list for further communication. Laurent> I thank you very much for your attention. Please feel free to Laurent> ask for more, if needed. You're very welcome. JMarc From laurent.fournier at lapp.in2p3.fr Wed Mar 31 16:24:59 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Wed Mar 31 09:25:08 2004 Subject: [XForms] Re: Xforms : popup menus In-Reply-To: References: <404707F2.2070306@lapp.in2p3.fr> Message-ID: <406AD4BB.9060800@lapp.in2p3.fr> Jean-Marc Lasgouttes wrote: >Sorry for not answering earlier to your message. I wanted to take a >look at the code first. I'd like to settle this popup issue before >1.1.0, but I am somhow not satisfied with the solution of using memset >(why? I do not know precisely :) > > I agree with your point of view. The use of memset() is only a way to ensure data initialization. As a rule of thumb we develop our code assuming that a NULL pointer is free, then we use to call calloc(), or realloc() with a memset() on any additional data. The best way would be to use the exact amount of memory we need for the menu item array. >What particular data should have been set to zero and caused problem? >At least the pointers are correctly reset. Was the problem related to >callbacks? > > The data what causes problems is the menu item array, when setting fl_maxpup to a higher value than FL_MAXPUP with fl_setpup_maxpup(), i.e. the pointer to menu items and the menu items themselves are not NULL. When calling fl_setpup_maxpup(), the default array of popup menus is resized and then reallocated. But at the initialization time (the very first call to fl_init_pup), the first allocation is made using a calloc() which sets all data to zero, and in particular the pointer "menu_rec->item". When not set to zero, we get garbage into the pointer array which leads to invalid data segments on the array (and thus menu items), and LynxOS gives a SIGSEGV when freeing any segment beginning with '9' (these are reserved adresses for the kernel but this is not the only case with this very sensitive OS). Thus, the problem is not directly related to callbacks, even if fl_freepup() is called on FL_FREEMEM events. >I agree that memset is not expensive. I would just like to understand >where the real problem was, in order to be sure that we do not miss >something. > > If you prefer not to call memset(), one solution to the real problem could be : 1 - to ensure proper initialization of unused pointers (especially menu_rec->item of course) when calling fl_setpup_maxpup(), 2 - to limit the loop counter in the function fl_freepup() to p->nitem instead of FL_MAXPUPI (line 1157 in v0.9999/lib/xpopup.c) because p->nitem handles the number of actually allocated menu item structures (i.e. valid pointers). Anyhow, fl_safe_free() checks only NULL pointers and is not enough for invalid pointers unless you ensure that a NULL pointer is free. This is the main reason for crashes under LynxOS with the so-called '9' segment. Moreover, memset() gives a slightly shorter code because we do not have to set many fields to 0 (we have limited space on Lynx CPUs). >I am not sure whether automatic reallocation is really a good thing. >It may bite you if you have a popup leak (which may happen easily). > > This is quite true. My application works fine when allocating a (big) default number of popups (and a call to memset() at this time). The only thing what I have to assume is to ensure enough (initialized) memory space. Moreover, reallocating memory for popups during the running phase seems not to be a problem. But in that case I need to gain access to the static variable fl_max_pup to count the number of popups and get more space when needed. I thank you for your kind attention on this problem... I thoroughly look for version 1.1 ! Amicalement, Laurent. From wd4nmq at comcast.net Wed Mar 31 10:01:20 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed Mar 31 10:01:26 2004 Subject: [XForms] Client Message handler success. In-Reply-To: References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> <4069A957.5050201@comcast.net> Message-ID: <406ADD40.6060001@comcast.net> All sugestions greatfully accepted. My bad habit is I like to explain why I did something a particular way. That way if somebody might see something in my explanation that could be done better, or might not work at all, they can bring it to my attention. Jean-Marc Lasgouttes wrote: >To subscribers of the xforms list > > > > >>>>>>"Jeff" == Jeff writes: >>>>>> >>>>>> > >Jeff> On the question of each form having a client message callback I >Jeff> believe that would be the correct way to go. As I understand it, >Jeff> each form is a seperate X window. So, since XSendEvent() targets >Jeff> an X window, it would make sense for each form/window to have >Jeff> it's own client message callback. > >That makes sense. It was just a suggestion. > >JMarc > Jeff From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 17:18:52 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Mar 31 10:18:58 2004 Subject: [XForms] Re: Xforms : popup menus In-Reply-To: <406AD4BB.9060800@lapp.in2p3.fr> (laurent FOURNIER's message of "Wed, 31 Mar 2004 16:24:59 +0200") References: <404707F2.2070306@lapp.in2p3.fr> <406AD4BB.9060800@lapp.in2p3.fr> Message-ID: >>>>> "laurent" == laurent FOURNIER writes: laurent> Jean-Marc Lasgouttes wrote: laurent> I agree with your point of view. The use of memset() is only laurent> a way to ensure data initialization. As a rule of thumb we laurent> develop our code assuming that a NULL pointer is free, then laurent> we use to call calloc(), or realloc() with a memset() on any laurent> additional data. The best way would be to use the exact laurent> amount of memory we need for the menu item array. Sure. I memory very tight in your setting? laurent> The data what causes problems is the menu item array, when laurent> setting fl_maxpup to a higher value than FL_MAXPUP with laurent> fl_setpup_maxpup(), i.e. the pointer to menu items and the laurent> menu items themselves are not NULL. There is not real pointer to menu items, since item is an array. All the code that I have seen sets the first entry (item[0]) to 0 when needed, so there should not be any problem [actually, I know there is a problem, since you experienced it. But I fail to see it] laurent> When calling fl_setpup_maxpup(), the default array of popup laurent> menus is resized and then reallocated. But at the laurent> initialization time (the very first call to fl_init_pup), the laurent> first allocation is made using a calloc() which sets all data laurent> to zero, and in particular the pointer "menu_rec->item". When laurent> not set to zero, we get garbage into the pointer array which laurent> leads to invalid data segments on the array (and thus menu laurent> items), and LynxOS gives a SIGSEGV when freeing any segment laurent> beginning with '9' (these are reserved adresses for the laurent> kernel but this is not the only case with this very sensitive laurent> OS). fl_setpup_maxpup does reset title and item[0] for each new popup. It seems however that it fails to reset parent, and this may cause problems with the following test in find_index: if (!p->title && !p->item[0] && !p->parent) Then fl_setpup_maxpup would read: int fl_setpup_maxpup(int n) { int i; if (n < FL_MAXPUP) return FL_MAXPUP; fl_init_pup(); menu_rec = fl_realloc(menu_rec, n * sizeof(*menu_rec)); for (i = fl_maxpup; i < n; i++) { menu_rec[i].title = 0; menu_rec[i].item[0] = 0; menu_rec[i].parent = 0; /* <================== */ } return fl_maxpup = n; } However, I fail to see how this missing piece could cause a crash. As far as I can see, the only possible consequence is that find_index would fail to recognize a popup as available. The fix is probably good nevertheless. laurent> If you prefer not to call memset(), one solution to the real laurent> problem could be : laurent> 1 - to ensure proper initialization of unused pointers laurent> (especially menu_rec-> item of course) when calling laurent> fl_setpup_maxpup(), But menu_rec->item is not really a pointer, is it? laurent> 2 - to limit the loop counter in the function fl_freepup() to laurent> p->nitem instead of FL_MAXPUPI (line 1157 in laurent> v0.9999/lib/xpopup.c) because p->nitem handles the number of laurent> actually allocated menu item p->structures laurent> (i.e. valid pointers). Yes, this one seems to be the real killer. I'll try to reproduce its effect under valgrind here. laurent> Anyhow, fl_safe_free() checks only NULL pointers and is not laurent> enough for invalid pointers unless you ensure that a NULL laurent> pointer is free. This is the main reason for crashes under laurent> LynxOS with the so-called '9' segment. Moreover, memset() laurent> gives a slightly shorter code because we do not have to set laurent> many fields to 0 (we have limited space on Lynx CPUs). I doubt that this difference in space will be important enough. I guess there many other sources of bloat in xforms :) laurent> This is quite true. My application works fine when allocating laurent> a (big) default number of popups (and a call to memset() at laurent> this time). The only thing what I have to assume is to ensure laurent> enough (initialized) memory space. Moreover, reallocating laurent> memory for popups during the running phase seems not to be a laurent> problem. But in that case I need to gain access to the static laurent> variable fl_max_pup to count the number of popups and get laurent> more space when needed. What we do in LyX is that we maintain our own maxpup variable that starts at 32 and we call fl_setpup_maxpup as needed. The (C++) code looks like int get_new_submenu(vector & smn, Window win) { static size_type max_number_of_menus = 32; if (smn.size() >= max_number_of_menus) max_number_of_menus = fl_setpup_maxpup(static_cast(2*smn.size())); [...] Here, smn holds the list of menus that have been allocated. This is used to deallocate them when they ar enot needed any more (menus are generated just before displaying them in LyX). I'll try to come up with a patch against xforms 1.0.90. I'd be interested to see whether it fixes your problems. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 17:20:28 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Mar 31 10:20:34 2004 Subject: [XForms] Client Message handler success. In-Reply-To: <406ADD40.6060001@comcast.net> (wd4nmq@comcast.net's message of "Wed, 31 Mar 2004 10:01:20 -0500") References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> <4069A957.5050201@comcast.net> <406ADD40.6060001@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> All sugestions greatfully accepted. My bad habit is I like to Jeff> explain why I did something a particular way. That way if Jeff> somebody might see something in my explanation that could be Jeff> done better, or might not work at all, they can bring it to my Jeff> attention. That's how I read it, and you convinced me. JMarc From wd4nmq at comcast.net Wed Mar 31 10:43:03 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed Mar 31 10:43:08 2004 Subject: [XForms] making diff file Message-ID: <406AE707.9030300@comcast.net> To maintainers, How do you want the diff command executed and which directory do you want as the base directory where diff is run from? Jeff From angus.leeming at btopenworld.com Wed Mar 31 16:48:32 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Mar 31 10:47:00 2004 Subject: [XForms] making diff file In-Reply-To: <406AE707.9030300@comcast.net> References: <406AE707.9030300@comcast.net> Message-ID: <200403311648.32663.angus.leeming@btopenworld.com> On Wednesday 31 March 2004 4:43 pm, Jeff wrote: > To maintainers, > > How do you want the diff command executed and which directory do > you want as the base directory where diff is run from? "diff -u" please. I'm too stupid to understand the other flavours. Run it from the top level directory (the one containing the ChangeLog file). Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 17:53:08 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Mar 31 10:53:14 2004 Subject: [XForms] making diff file In-Reply-To: <406AE707.9030300@comcast.net> (wd4nmq@comcast.net's message of "Wed, 31 Mar 2004 10:43:03 -0500") References: <406AE707.9030300@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list To maintainers, Jeff> How do you want the diff command executed and which directory do Jeff> you want as the base directory where diff is run from? Do a diff from the root xforms source directory. Also the preferred style for diffs is unified (-u). So if you work from cvs, it will be "cvs diff -u". JMarc From wd4nmq at comcast.net Wed Mar 31 20:41:00 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed Mar 31 20:41:05 2004 Subject: [XForms] Adding more calls to support fl_register_client_callback()? Message-ID: <406B732C.2000501@comcast.net> Before I submit the client message patch I had this thought. There are a couple of X lib calls that are needed when using the new fl_register_client_callback(). These would be XInternAtom() and XSendEvent(). One of the parameters is a propertty atom. This is used by the client callback to determine how the data is formated. XInternAtom() is used to set the atom ID and must be called to set an atom BEFORE client messaging can be used. XSendEvent is used to send the event. Now, do we want have a user use the raw X lib calls, or encapsulate them in an fl_*? Like: Atom fl_intern_atom(FL_FORM *form, char *atom_name, Bool only_if_exists); This function would then call XInternAtom() . Status fl_send_clientEvent(FL_FORM *form, Bool propogate); Which would in turn fill in the proper event masks and use *form to get the display and window data and then call XSendEvent(). What ya'll think? Jeff wd4nmq@comcast.net From laurent.fournier at lapp.in2p3.fr Thu Apr 1 09:44:03 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Thu Apr 1 02:44:13 2004 Subject: [XForms] Re: Xforms : popup menus In-Reply-To: References: <404707F2.2070306@lapp.in2p3.fr> <406AD4BB.9060800@lapp.in2p3.fr> Message-ID: <406BC843.1090105@lapp.in2p3.fr> Jean-Marc Lasgouttes wrote: >Sure. I memory very tight in your setting? > Yes, a process cannot get more than 16Mb (but this can be tuned). The total memory is usually 32Mb (some CPUs have up to 96Mb), no hard drive >There is not real pointer to menu items, since item is an array. All >the code that I have seen sets the first entry (item[0]) to 0 when >needed, so there should not be any problem [actually, I know there is >a problem, since you experienced it. But I fail to see it] > >fl_setpup_maxpup does reset title and item[0] for each new popup. It >seems however that it fails to reset parent, and this may cause >problems with the following test in find_index: > if (!p->title && !p->item[0] && !p->parent) > > I did not experience problems with this data... but it was perhaps set to values which do not put the system in trouble. The forms are always created "on the fly" as the user needs them. The only form that is created at startup is the main one since there can be a really huge number of forms. >Then fl_setpup_maxpup would read: > >int >fl_setpup_maxpup(int n) >{ > int i; > > if (n < FL_MAXPUP) > return FL_MAXPUP; > > fl_init_pup(); > > menu_rec = fl_realloc(menu_rec, n * sizeof(*menu_rec)); > for (i = fl_maxpup; i < n; i++) > { > menu_rec[i].title = 0; > menu_rec[i].item[0] = 0; > menu_rec[i].parent = 0; /* <================== */ > } > > return fl_maxpup = n; >} > > I had a look on the code, I think this initialization is quite full of sense ! :-) >But menu_rec->item is not really a pointer, is it? > Not exactly, you are right. >I doubt that this difference in space will be important enough. I >guess there many other sources of bloat in xforms :) > Of course. I like things that are compact, but this is purely personal. >What we do in LyX is that we maintain our own maxpup variable that >starts at 32 and we call fl_setpup_maxpup as needed. The (C++) code >looks like > >int get_new_submenu(vector & smn, Window win) >{ > static size_type max_number_of_menus = 32; > if (smn.size() >= max_number_of_menus) > max_number_of_menus = > fl_setpup_maxpup(static_cast(2*smn.size())); >[...] > >Here, smn holds the list of menus that have been allocated. This is >used to deallocate them when they ar enot needed any more (menus are >generated just before displaying them in LyX). > > I tried a code which is strongly inspired from yours for menu creation (to get the real number of available popups : just call fl_setpup_maxpup(0) ! this returns the number of avalable popups :-) ). Thanks to a preemptive handler on FL_FREEMEM events(for down counting), my application now allocates just enough space. Thank you for the advice ! >I'll try to come up with a patch against xforms 1.0.90. I'd be >interested to see whether it fixes your problems. > >JMarc > > I let you know as soon as possible, I thank you once again for your work. Laurent. From angus.leeming at btopenworld.com Thu Apr 1 18:24:28 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Apr 1 12:23:01 2004 Subject: [XForms] Adding more calls to support fl_register_client_callback()? In-Reply-To: <406B732C.2000501@comcast.net> References: <406B732C.2000501@comcast.net> Message-ID: <200404011824.28040.angus.leeming@btopenworld.com> On Thursday 01 April 2004 2:41 am, Jeff wrote: > XInternAtom() is used to set the atom ID and must be called to set > an atom BEFORE client messaging can be used. > XSendEvent is used to send the event. > > Now, do we want have a user use the raw X lib calls, or encapsulate > them in an fl_*? Like: > > Atom fl_intern_atom(FL_FORM *form, > char *atom_name, > Bool only_if_exists); Would wrapping the X lib call give the user anything other than a familiar fl_... ? If not, then I guess that we should use the raw X lib call. Could you give us an example of all this in action. It's hard to make any meaningful statements without some code. Angus From Jean-Marc.Lasgouttes at inria.fr Fri Apr 2 11:05:00 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Apr 2 04:05:10 2004 Subject: [XForms] Adding more calls to support fl_register_client_callback()? In-Reply-To: <200404011824.28040.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 1 Apr 2004 18:24:28 +0100") References: <406B732C.2000501@comcast.net> <200404011824.28040.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Thursday 01 April 2004 2:41 am, Jeff wrote: >> XInternAtom() is used to set the atom ID and must be called to set >> an atom BEFORE client messaging can be used. XSendEvent is used to >> send the event. >> >> Now, do we want have a user use the raw X lib calls, or encapsulate >> them in an fl_*? Like: >> >> Atom fl_intern_atom(FL_FORM *form, char *atom_name, Bool >> only_if_exists); Angus> Would wrapping the X lib call give the user anything other than Angus> a familiar fl_... ? If not, then I guess that we should use the Angus> raw X lib call. Well we could forget about the notion of atoms. fl_create_client_message() fl_send_client_message() ... However, I do not know how these atoms are used in real life... Angus, I do not think that there is any place in xforms where you need to manipulate X objects to use a feature. Hmm, let's grep in forms.h... OK, there are fl_XNextEvent and its friends, but I do not know how common it is to use them. Angus> Could you give us an example of all this in action. It's hard Angus> to make any meaningful statements without some code. Actually, it would be nice to have a demo program for the client message feature. JMarc From laurent.fournier at lapp.in2p3.fr Fri Apr 2 12:05:27 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Fri Apr 2 05:05:34 2004 Subject: [XForms] once more about popups Message-ID: <406D3AE7.5090303@lapp.in2p3.fr> Dear Jean-Marc, I have tried your patch in the initialization routine for popups (function fl_setpup_maxpup). In my application the sequence is the following : FL_OBJECT *obj = fl_add_menu(type, x, y, w, h, label); fl_set_object_boxtype(obj, FL_UP_BOX); fl_setpup_default_fontsize(CL_FONT_SIZE); /* this is an integer from config file, usually = 8 or 10 */ fl_setpup_default_fontstyle(FL_NORMAL_STYLE); I made a new run this morning on LynxOS and got the following while calling fl_setup_default_fontsize() in the above sequence : X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 4 (X_DestroyWindow) etc... Then the program enters a deadlock while stacking calls to XSync() (but this is likely a problem with X11 itself on LynxOS) while calling close_pupwin() (xpopup.c line 430). The error occurs because the field pup->win is not initialized to zero ... and does not occur in my own patched version. One more argument towards memset() ! :-) But I do not understand why this did not appear before... Amicalement, Laurent. From wd4nmq at comcast.net Fri Apr 2 11:38:04 2004 From: wd4nmq at comcast.net (Jeff) Date: Fri Apr 2 11:38:15 2004 Subject: [XForms] Adding more calls to support fl_register_client_callback()? In-Reply-To: References: <406B732C.2000501@comcast.net> <200404011824.28040.angus.leeming@btopenworld.com> Message-ID: <406D96EC.9020805@comcast.net> I'll put together a quicky threaded app later today when I get a chance. It will just be a clock. The form will display the time while the thread will do the actual time functions and send the time for display via a client message. That ok? Jeff Jean-Marc Lasgouttes wrote: >To subscribers of the xforms list > > > > >>>>>>"Angus" == Angus Leeming writes: >>>>>> >>>>>> > >Angus> To subscribers of the xforms list >Angus> On Thursday 01 April 2004 2:41 am, Jeff wrote: > > >>>XInternAtom() is used to set the atom ID and must be called to set >>>an atom BEFORE client messaging can be used. XSendEvent is used to >>>send the event. >>> >>>Now, do we want have a user use the raw X lib calls, or encapsulate >>>them in an fl_*? Like: >>> >>>Atom fl_intern_atom(FL_FORM *form, char *atom_name, Bool >>>only_if_exists); >>> >>> > >Angus> Would wrapping the X lib call give the user anything other than >Angus> a familiar fl_... ? If not, then I guess that we should use the >Angus> raw X lib call. > >Well we could forget about the notion of atoms. >fl_create_client_message() >fl_send_client_message() >... > >However, I do not know how these atoms are used in real life... > >Angus, I do not think that there is any place in xforms where you need >to manipulate X objects to use a feature. Hmm, let's grep in >forms.h... OK, there are fl_XNextEvent and its friends, but I do not >know how common it is to use them. > >Angus> Could you give us an example of all this in action. It's hard >Angus> to make any meaningful statements without some code. > >Actually, it would be nice to have a demo program for the client >message feature. > >JMarc >_______________________________________________ >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 wd4nmq at comcast.net Sat Apr 3 01:42:42 2004 From: wd4nmq at comcast.net (Jeff) Date: Sat Apr 3 01:42:44 2004 Subject: [XForms] client event sample application Message-ID: <406E5CE2.5010907@comcast.net> Below is an appliaction that uses the fl_register_client_callback() and demonstrates why atoms are needed. As asked for by Angus I believe. A quick explanation on why atoms are needed. When a client callback is called, all it gets is a pointer to an XEvent structure and all it knows is it is a ClientMessage. It has no idea how the data is formatted. This is where an atom comes into play. An atom is registered with the XInternAtom() call. This atom is then put into effect for the whole X display, like 0:0. Now, any app or thread running in display 0:0 can use that atom. In my demo below I have a text widget that the time is displayed in. The actual time is read from the system in a thread. The time is sent as either a long, or as a pointer to a time struct. These alternate every second. Now, to demonstate how atoms are used I create two atoms, timeStructAtom & longTimeAtom. if the time data is a long, longTimeAtom is used. If it is a pointer to time struct, timeStructAtom is used. Now the client callback can decide how the time is encoded and act appropiatly to display it. Remember, there can be only ONE user ClientMessage callback for an app. So atoms are important in letting the callback know how the data is formatted. The code: #include "forms.h" #include #include "timeEvent.h" #include #include Atom longTimeAtom, timeStructAtom; pthread_t getTimeThread; FD_testEvent *fd_testEvent; FD_testEvent *create_form_testEvent(void) { FL_OBJECT *obj; FD_testEvent *fdui = (FD_testEvent *) fl_calloc(1, sizeof(*fdui)); fdui->testEvent = fl_bgn_form(FL_NO_BOX, 420, 250); obj = fl_add_box(FL_UP_BOX,0,0,420,250,""); fdui->timeText = obj = fl_add_text(FL_NORMAL_TEXT,30,90,350,60,""); fl_set_object_boxtype(obj,FL_SHADOW_BOX); fl_set_object_lsize(obj,FL_HUGE_SIZE); fl_set_object_lalign(obj,FL_ALIGN_LEFT|FL_ALIGN_INSIDE); fl_end_form(); fdui->testEvent->fdui = fdui; return fdui; } /*---------------------------------------*/ FL_CLIENT_CALLBACK clientCallback(FL_FORM *form, XEvent *xev){ char line[128]; // Use message_type to decide how time is encoded if(xev->xclient.message_type == longTimeAtom){ fl_set_object_label(fd_testEvent->timeText, ctime(&xev->xclient.data.l[0])); } else if(xev->xclient.message_type == timeStructAtom){ strftime(line,128, "%a %b %d %H:%M:%S %Y",xev->xclient.data.l[0]); fl_set_object_label(fd_testEvent->timeText, line); } } /*******************************************/ int timerThread(void *ptr){ time_t the_time; struct tm *tm_ptr; XEvent xev; sleep(3); // long timeout first time while(1){ the_time = time((time_t *)0); if(the_time & 0x0001){ xev.xclient.type = ClientMessage; xev.xclient.window = fl_get_winID(fd_testEvent->testEvent); xev.xclient.message_type = longTimeAtom; xev.xclient.format = 16; xev.xclient.data.l[0] = the_time; } else { tm_ptr = localtime(&the_time); xev.xclient.type = ClientMessage; xev.xclient.window = fl_get_winID(fd_testEvent->testEvent); xev.xclient.message_type = timeStructAtom; xev.xclient.format = 16; xev.xclient.data.l[0] = (long)tm_ptr; } XSendEvent(fl_display, fl_get_winID(fd_testEvent->testEvent), False, 0l, &xev); sleep(1); } } /*************************************/ int main(int argc, char *argv[]) { int rtn; fl_initialize(&argc, argv, 0, 0, 0); fd_testEvent = create_form_testEvent(); longTimeAtom = XInternAtom(fl_display, "Long Time", FALSE); timeStructAtom = XInternAtom(fl_display, "Time Pointer", FALSE); fl_register_client_callback(fd_testEvent->testEvent, clientCallback); /* fill-in form initialization code */ /* show the first form */ fl_show_form(fd_testEvent->testEvent,FL_PLACE_CENTERFREE, FL_FULLBORDER,"testEvent"); rtn = pthread_create(&getTimeThread, NULL, (void *) timerThread, NULL); fl_do_forms(); return 0; } // End of code Now, since the code to update the time widget is running in the gui code space, and not the thread actually getting the time. There are no conflicts for the internal xforms code to write the form. You can use fl_do_forms() instead of fl_check_forms() and have to have mutexes for threads to be able to update a form. I believe this is much cleaner. Well, it's 1:30 am local and I am hitting the sack. Jeff From wd4nmq at comcast.net Sat Apr 3 10:15:17 2004 From: wd4nmq at comcast.net (Jeff) Date: Sat Apr 3 10:15:20 2004 Subject: [XForms] Where to put forms.h changes Message-ID: <406ED505.4090604@comcast.net> Angus, Where would you put changes to lib/include/forms.h BEFORE running configure and make? Since it is created by make I cannot change forms.h in the original distribution. Jeff From angus.leeming at btopenworld.com Sat Apr 3 16:23:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat Apr 3 10:23:49 2004 Subject: [XForms] Where to put forms.h changes In-Reply-To: <406ED505.4090604@comcast.net> References: <406ED505.4090604@comcast.net> Message-ID: <200404031623.18117.angus.leeming@btopenworld.com> On Saturday 03 April 2004 4:15 pm, Jeff wrote: > To subscribers of the xforms list > > > Angus, > > Where would you put changes to lib/include/forms.h BEFORE running > configure and make? Since it is created by make I cannot change > forms.h in the original distribution. Hi, Jeff. See the files in lib/include. They are concatenated together to create forms.h Angus From Gayle.C.Roth at nasa.gov Mon Apr 5 11:56:00 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Mon Apr 5 12:52:44 2004 Subject: [XForms] OpenVMS version of xforms Message-ID: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> Hi. I'm trying to get an OpenVMS version of xforms. Does anyone know the CURRENT web site with the downloads, with the operating system names next to their links? I went to the web site http://world.std.com/~xforms/ftp/ftp.html, which had an OpenVMS link. This however is outdated since the only thing I got was a README that said that site is no longer the repository, and the repository now is: http://savannah.nongnu.org/files/?group=xforms. That site has several downloads but nothing next to the file names (i.e. no indication of which one is for which operating system). Can someone tell me how to get an openVMS (or just plain VMS) download? Thanks, Gayle Roth From angus.leeming at btopenworld.com Mon Apr 5 19:03:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Apr 6 01:34:24 2004 Subject: [XForms] OpenVMS version of xforms In-Reply-To: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> Message-ID: <200404051803.33774.angus.leeming@btopenworld.com> On Monday 05 April 2004 3:56 pm, Gayle C Roth wrote: > I'm trying to get an OpenVMS version of xforms. Does anyone know > the CURRENT web site with the downloads, with the operating system > names next to their links? I went to the web site > http://world.std.com/~xforms/ftp/ftp.html, which had an OpenVMS > link. This however is outdated since the only thing I got was a > README that said that site is no longer the repository, and the > repository now > is: http://savannah.nongnu.org/files/?group=xforms. That site has > several downloads but nothing next to the file names (i.e. no > indication of which one is for which operating system). Can > someone tell me how to get an openVMS (or just plain VMS) download? Hi, Gayle. xforms has moved to an Open Source licence meaning that there's no need for us to provide binaries for tens of different platforms. Grab the source and compile it. The xforms 1.0 release uses xmkmf and family to generate the Makefiles. It is kludgy and I don't think that anybody here knows much about it. The xforms 1.0.90 pre-release for xforms 1.1 uses the gnu autotools to generate the Makefiles. We'd be very grateful if you could try it out on your box. The source itself is little changed from xforms 1.0 modulo a fair number of bug fixes. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Tue Apr 6 17:09:29 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Apr 6 10:09:34 2004 Subject: [XForms] [PATCH] Fix valgrind warning Message-ID: I just committed the attached patch. It fixes a valgrind warning where strncpy is used to copy a strings over itself. I do not think that the bug was harmful. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: strncpy.diff Type: text/x-patch Size: 1336 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040406/8e73c304/strncpy.bin From Jean-Marc.Lasgouttes at inria.fr Tue Apr 6 17:46:47 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Apr 6 10:46:53 2004 Subject: [XForms] OpenVMS version of xforms In-Reply-To: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> (Gayle C. Roth's message of "Mon, 05 Apr 2004 10:56:00 -0400") References: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> Message-ID: >>>>> "Gayle" == Gayle C Roth writes: Gayle> To subscribers of the xforms list Hi. Gayle> I'm trying to get an OpenVMS version of xforms. Does anyone Gayle> know the CURRENT web site with the downloads, with the Gayle> operating system names next to their links? If you go to the old ftp site (ncmir.ucsd.edu) and visit the directory /pub/xforms/Attic/OpenVMS/, you will find a binary for xforms 0.88. This is admittedly old, but nobody here knows how to compile on OpenVMS. If OpenVMS has basic support for looking like unix (like running a unix shell), you can try the version 1.0.90 at http://savannah.nongnu.org/files/?group=xforms This is a source distribution, and you will have to compile it yourself. However, we are here to help. JMarc From angus.leeming at btopenworld.com Tue Apr 6 23:28:34 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Apr 6 17:30:32 2004 Subject: [XForms] OpenVMS version of xforms In-Reply-To: <5.1.1.5.2.20040406092010.01667ea8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> <5.1.1.5.2.20040406092010.01667ea8@popserve.grc.nasa.gov> Message-ID: <200404062228.34701.angus.leeming@btopenworld.com> On Tuesday 06 April 2004 2:25 pm, Gayle C Roth wrote: > > > I'm trying to get an OpenVMS version of xforms. Does anyone > > > know the CURRENT web site with the downloads, with the > > > operating system names next to their links? I went to the web > > > site > > > http://world.std.com/~xforms/ftp/ftp.html, which had an OpenVMS > > > link. This however is outdated since the only thing I got was > > > a README that said that site is no longer the repository, and > > > the repository now > > > is: http://savannah.nongnu.org/files/?group=xforms. That site > > > has several downloads but nothing next to the file names (i.e. > > > no indication of which one is for which operating system). Can > > > someone tell me how to get an openVMS (or just plain VMS) > > > download? > > Thanks, Angus. I actually have the source but was hoping there was > still a binary out there for OpenVMS because I may have to port my > GUI which uses xforms in the very near future. Unfortunately, the > Makefile generation doesn't apply here because OpenVMS is not UNIX. > Otherwise, I'd be happy to try out that tool. > > Wish me luck! Good luck! And remember, we're here to help. Incidentally, a quick search on google suggests that gnu make works on OpenVMS. The gnu autotools are a bunch of perl scripts that will create a config.h header file defining lots of system-specific macros and a bunch of Makefiles. Angus > >Hi, Gayle. > > > >xforms has moved to an Open Source licence meaning that there's no > >need for us to provide binaries for tens of different platforms. > > Grab the source and compile it. > > > >The xforms 1.0 release uses xmkmf and family to generate the > >Makefiles. It is kludgy and I don't think that anybody here knows > >much about it. > > > >The xforms 1.0.90 pre-release for xforms 1.1 uses the gnu > > autotools to generate the Makefiles. We'd be very grateful if you > > could try it out on your box. The source itself is little changed > > from xforms 1.0 modulo a fair number of bug fixes. > > > >Regards, > >Angus From angus.leeming at btopenworld.com Thu Apr 8 22:41:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Apr 8 15:43:34 2004 Subject: [XForms] Resurrecting an old patch for slider.c Message-ID: <200404082141.18915.angus.leeming@btopenworld.com> Below is a mesage and attached is a patch that I originally sent to the xforms list 16 months ago. The question is, should I apply this simple patch or should I apply the more complex alternative using a timer? Regards, Angus The investigation was originally motivated by this bug report: Clicking in the scrollbar trough to scroll through a document auto-repeats after a short delay, as expected. However, the delay before auti-repeating kicks in is too short and the repeat rate much to fast on my system. Most of the time I cannot use clicking in the scrollbar trough to page forward in my documents because the delay before auto-repeating is shorter than my single-click time (and I'm not a slow mouser...) In fact, the entire sorry saga can be found here: http://bugzilla.lyx.org/show_bug.cgi?id=747 The upshot was that I posted the message below to the xforms list. Nothing came of it... On Monday 02 December 2002 7:36 pm, John Levon wrote: > 4. xforms should mediate these callbacks to a reasonable pace using a > timer. I've spent some time trying to ascertain exactly what we want and what xforms gives us at the moment. Allow me to take you through it. You'll find at the end that xforms already gives us what we want --- almost --- so bear with me... The problem is that we want quite fine-grained control over the scrollbar and it's only for one of these interactions that we need/want the mediation that John is suggesting. The scrollbar is actually a "complex widget" made up of three "simple widget"s, a "slider" and two buttons named "up" and "down" that are the little arrow buttons at the end of the slider. The user can control the slider position in several different ways: * Click on and drag the slider to the desired position. * Click in the slider trough with the LMB * Click in the slider trough with the RMB * Click on the up/down buttons with any mouse button. Each interaction results in a different behaviour. Specifically, if the scrollbar increment is set: fl_set_scrollbar_increment(scrollbar, lmb_inc, rmb_inc); then clicking in the slider trough with the LMB increments the slider by lmb_inc. Ditto, clicking in the slider trough with the RMB increments the slider by rmb_inc. Finally, clicking on the up and down buttons with any mouse button increments the slider by rmb_inc. All four types of "click-interaction" result in a call to the user-specified scrollbar->object_callback routine. The user has no way of differentiating between the different possible click behaviours. I have extracted this information through the use of judiciously placed print statements in the xforms source. It isn't woolly; it's an accurate description of the code. In our particular case, lmb_inc is "increment by 1 page" and rmb_inc is "increment by 1 line" Moreover, because the LMB click in the slider trough results in a large increment, we would like callbacks resulting from it to be mediated by a reasonable delay between callbacks. From all this, I conclude that we should focus our attention on the simple slider widget rather than the complex scrollbar widget. Moreover, an examination of slider.c's source shows that the code to do what we want is already there --- almost. We need merely modify slider.c's handle_mouse routine. I append the relevant code snippet below. Note how xforms currently uses a "timdel" variable to ignore the callbacks 1-10 after the mouse button is pressed. Thereafter, every other mouse event gets through. Proposal 1 use the current approach, but reset timdel to 0 after it's reached 11. make 11 tunable from the outside. Proposal 2 use a timer instead of timdel. Does this make sense? Would you like to try and fix the source this way or are you set on your idea still? Regards, Angus (who's starting to get to grips with the xforms source...) ps. We've had similar problem reports about the counter from users. Note that it too has a handle_mouse routine using a timdel variable, so it looks to me that we can cure both problems in the same way. That's wasted the morning. Best do some proper work this afternoon. A. -------------- next part -------------- A non-text attachment was scrubbed... Name: xforms-slider.diff Type: text/x-diff Size: 910 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040408/74bedffe/xforms-slider.bin From Jean-Marc.Lasgouttes at inria.fr Fri Apr 9 14:55:11 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Apr 9 07:55:18 2004 Subject: [XForms] Resurrecting an old patch for slider.c In-Reply-To: <200404082141.18915.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 8 Apr 2004 21:41:18 +0100") References: <200404082141.18915.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Below is a mesage and Angus> attached is a patch that I originally sent to the xforms list Angus> 16 months ago. The question is, should I apply this simple Angus> patch or should I apply the more complex alternative using a Angus> timer? I guess the problem is to know whether your patch produces the right feeling for applications like LyX. Did you try it at the time? I do not know what other applications out there have a use for a slider over a large text. Maybe XFMail? JMarc From Gayle.C.Roth at nasa.gov Fri Apr 9 11:47:27 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Fri Apr 9 10:47:38 2004 Subject: [XForms] xforms 1.0.90 pre-release Message-ID: <5.1.1.5.2.20040409103937.016851c8@popserve.grc.nasa.gov> Hi. A few days ago, Angus told me about the xforms 1.0.90 pre-release for xforms 1.1. He said it includes gnu autotools to generate Makefiles. I'd like to try it out for OpenVMS but don't know where to get it. Where do I go to download this pre-release? I've tried searches on xforms 1.0 and xforms 1.1 and don't know what to do from those pages. Thanks, Gayle From bob at bob.usuhs.mil Fri Apr 9 15:30:58 2004 From: bob at bob.usuhs.mil (Robert Williams) Date: Fri Apr 9 14:32:21 2004 Subject: [XForms] Possible problems with list subscriptions Message-ID: <4076EBE2.6090009@bob.usuhs.mil> Our subnet, where the xforms list server lives, has been hit very hard by email worms in the past few days. None of these have found their way to our list server, but admins up and down the line at various .mil sites have been doing some pretty drastic things to stop the flow and clear the decks. As a consequence, the list has seen a flurry of bounces and unsubscribes that appear to have nothing to do with the wishes of subscribed members. I'm trying to keep a list of unsubscribe notices, but since my address seems to have found its way into the worms list, I'm getting hundreds of these worms myself (mimedefanged by our server, but I still get the notices and bounces from other sites.)... So I'm not paying a lot of attention to the unsubscribe notices, and if you find yourself unsubscribed at some point, you will have to resubscribe yourself to the list if you want back on. The info page is at: http://cweblog.usuhs.mil/mailman/listinfo/xforms -- Dr. Robert Williams Dept. of Biomedical Informatics Uniformed Services University 301-295-3568 From angus.leeming at btopenworld.com Mon Apr 12 21:13:05 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Apr 12 14:15:24 2004 Subject: [XForms] xforms 1.0.90 pre-release In-Reply-To: <5.1.1.5.2.20040409103937.016851c8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040409103937.016851c8@popserve.grc.nasa.gov> Message-ID: <200404122013.05910.angus.leeming@btopenworld.com> On Friday 09 April 2004 3:47 pm, Gayle C Roth wrote: > Hi. > > A few days ago, Angus told me about the xforms 1.0.90 pre-release > for xforms 1.1. He said it includes gnu autotools to generate > Makefiles. I'd like to try it out for OpenVMS but don't know where > to get it. Where do I go to download this pre-release? I've tried > searches on xforms 1.0 and xforms 1.1 and don't know what to do > from those pages. > > Thanks, > Gayle Hi, Gayle. Sorry for any confusion, but my use of "autotools" is just shorthand for "autoconf and automake". These pages have links to the official gnu download sites: http://www.gnu.org/software/autoconf/ http://www.gnu.org/software/automake/ They're both perl scripts. autoconf will generate a header file config.h that is #included in the .c files. It contains a bunch of macros #define HAVE_DECL_VSNPRINTF 1 #define HAVE_STDLIB_H 1 etc. automake generates portable makefiles from the Makefile.am templates. Thereafter you'll need a 'make' executable to build the sources. To use them, execute the autogen.sh shell script in the top-level directory. Here's what I do: cd xforms ./autogen.sh mkdir build && cd build ../configure make This builds the object, executable and library files in a directory 'build' that is separate from the sources themselves. Keeps things clean. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Tue Apr 13 12:31:46 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Apr 13 05:31:55 2004 Subject: [XForms] xforms 1.0.90 pre-release In-Reply-To: <200404122013.05910.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 12 Apr 2004 20:13:05 +0100") References: <5.1.1.5.2.20040409103937.016851c8@popserve.grc.nasa.gov> <200404122013.05910.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Sorry for any confusion, but my use of "autotools" is just Angus> shorthand for "autoconf and automake". These pages have links Angus> to the official gnu download sites: As far as I know, autoconf and automake have not been ported to OpenVMS yet. There is a project named GNV that is working on unix interoperability, though: http://gnv.sourceforge.net/ We should maybe take another look at the vms support in xforms 1.0 and see whether we can get rid of the need for autoconf in this case. Gayle, if you are willing to spend some time on that, we could have a go at it. JMarc From ncrespo at interlab.es Wed Apr 14 11:33:53 2004 From: ncrespo at interlab.es (Natalia Crespo) Date: Wed Apr 14 03:35:23 2004 Subject: [XForms] FL_NOBORDER forms and sawfish Message-ID: <407CF771.1040308@interlab.es> Hello, We've been working with fvwm2 window manager and applications using xforms library. We need to use windows with FL_FULLBORDER and FL_NOBORDER border in the same application and with fvwm2 we don't have any problem. However, we've decided to use GNOME with sawfish as window manager and we've got quite problems showing a window with no border and after that another one with full border. The second window (with border) stays at the back of the first (without border) one and the application doesn't work properly. We'd like to know if it's possible to configure sawfish to manage that kind of window without problems. We've been trying to configurate it using "~/.sawfishrc" file but we haven't found a solution. Anybody knows if it's necessary to change any attribute to get it? Any other suggestion? Thanks a lot in avance. Natalia. From wd4nmq at comcast.net Wed Apr 14 12:12:39 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed Apr 14 11:12:30 2004 Subject: [XForms] Where to change forms.h? Message-ID: <407D54E7.5070607@comcast.net> I've asked this problem before, but where do you implement changes for /lib/include/forms.h? It is created during the ./confiigure and make steps. So, where do I make changes to add my client message functionality? Jeff wd4nmq@comcast.net From angus.leeming at btopenworld.com Wed Apr 14 17:21:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Apr 14 18:16:03 2004 Subject: [XForms] Where to change forms.h? In-Reply-To: <407D54E7.5070607@comcast.net> References: <407D54E7.5070607@comcast.net> Message-ID: <200404141621.19008.angus.leeming@btopenworld.com> On Wednesday 14 April 2004 4:12 pm, Jeff wrote: > I've asked this problem before, but where do you implement changes > for /lib/include/forms.h? > > It is created during the ./confiigure and make steps. I answered it before too: See the files in lib/include. They are concatenated together to create forms.h So, one possible solution would be to create a new file client_msg.h and add it to the list of files in lib/include/Makefile.am Angus From wd4nmq at comcast.net Thu Apr 15 11:28:24 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu Apr 15 10:28:15 2004 Subject: [XForms] Where to change forms.h? In-Reply-To: <200404141621.19008.angus.leeming@btopenworld.com> References: <407D54E7.5070607@comcast.net> <200404141621.19008.angus.leeming@btopenworld.com> Message-ID: <407E9C08.1080809@comcast.net> I did have an email glitch and I must have missed it. Sorry. I am getting the patch ready in the next day or two. Jeff Angus Leeming wrote: >On Wednesday 14 April 2004 4:12 pm, Jeff wrote: > > >>I've asked this problem before, but where do you implement changes >>for /lib/include/forms.h? >> >>It is created during the ./confiigure and make steps. >> >> > >I answered it before too: > >See the files in lib/include. They are concatenated together to create >forms.h > >So, one possible solution would be to create a new file client_msg.h >and add it to the list of files in lib/include/Makefile.am > >Angus > > > > From Jean-Marc.Lasgouttes at inria.fr Tue Apr 20 18:24:20 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Apr 20 11:24:28 2004 Subject: [XForms] [PATCH] configuration fixes Message-ID: This patch allows in particular to build the gl demos. I'll commit it in a minute. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: conf.diff Type: text/x-patch Size: 2581 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040420/198fe33b/conf.bin From Jean-Marc.Lasgouttes at inria.fr Tue Apr 20 19:01:24 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Apr 20 12:01:32 2004 Subject: [XForms] [PATCH] Re: once more about popups In-Reply-To: <406D3AE7.5090303@lapp.in2p3.fr> (laurent FOURNIER's message of "Fri, 02 Apr 2004 12:05:27 +0200") References: <406D3AE7.5090303@lapp.in2p3.fr> Message-ID: >>>>> "laurent" == laurent FOURNIER writes: laurent> I made a new run this morning on LynxOS and got the following laurent> while calling fl_setup_default_fontsize() in the above laurent> sequence : [...] laurent> Then the program enters a deadlock while stacking calls to laurent> XSync() (but this is likely a problem with X11 itself on laurent> LynxOS) while calling close_pupwin() (xpopup.c line 430). The laurent> error occurs because the field pup->win is not initialized to laurent> zero ... and does not occur in my own patched version. One laurent> more argument towards memset() ! :-) But I do not understand laurent> why this did not appear before... Dear Laurent, Sorry for taking so long to answer (again!). Could you try the attached patch? I suspect that the fact that parent is now reset means that old entries can be re-used, and this is why a bad win eventually bites us. Concerning the use of memset, what I want is just to minimize the number of places where we do such things. However, it would probably be wise to have a clear_pup(p) that clears a popup entry (maybe with memset ;). That would be called by init_popup(), for example. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: xpopup.diff Type: text/x-patch Size: 1742 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040420/5bee91e8/xpopup.bin From laurent.fournier at lapp.in2p3.fr Wed Apr 21 10:33:47 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Wed Apr 21 03:33:56 2004 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: References: <406D3AE7.5090303@lapp.in2p3.fr> Message-ID: <408623DB.8020206@lapp.in2p3.fr> Dear Jean-Marc, >laurent> I made a new run this morning on LynxOS and got the following >laurent> while calling fl_setup_default_fontsize() in the above >laurent> sequence : [...] > >laurent> Then the program enters a deadlock while stacking calls to >laurent> XSync() (but this is likely a problem with X11 itself on >laurent> LynxOS) while calling close_pupwin() (xpopup.c line 430). The >laurent> error occurs because the field pup->win is not initialized to >laurent> zero ... and does not occur in my own patched version. One >laurent> more argument towards memset() ! :-) But I do not understand >laurent> why this did not appear before... > >Dear Laurent, > >Sorry for taking so long to answer (again!). Could you try the >attached patch? > I thought I was boring you with my problems... I thank you very much for your help, I try this as soon as possible (probably today) and I let you know. >I suspect that the fact that parent is now reset means that old >entries can be re-used, and this is why a bad win eventually bites us. > >Concerning the use of memset, what I want is just to minimize the >number of places where we do such things. However, it would probably >be wise to have a clear_pup(p) that clears a popup entry (maybe with >memset ;). That would be called by init_popup(), for example. > I totally agree this point of view. >JMarc > > Thank you again. Laurent. From Jean-Marc.Lasgouttes at inria.fr Wed Apr 21 12:56:43 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Apr 21 05:56:50 2004 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: <408623DB.8020206@lapp.in2p3.fr> (laurent FOURNIER's message of "Wed, 21 Apr 2004 09:33:47 +0200") References: <406D3AE7.5090303@lapp.in2p3.fr> <408623DB.8020206@lapp.in2p3.fr> Message-ID: >>>>> "laurent" == laurent FOURNIER writes: >> Sorry for taking so long to answer (again!). Could you try the >> attached patch? >> laurent> I thought I was boring you with my problems... I thank you laurent> very much for your help, I try this as soon as possible laurent> (probably today) and I let you know. No, but I do not have much time and wanted to take a real look at the sources before proposing a patch. [I do not suggest that it was soo difficult to do, I am just trying to cover up my laziness :)] JMarc From laurent.fournier at lapp.in2p3.fr Wed Apr 21 16:09:53 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Wed Apr 21 09:10:00 2004 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: References: <406D3AE7.5090303@lapp.in2p3.fr> Message-ID: <408672A1.5050008@lapp.in2p3.fr> Dear Jean-Marc, >Dear Laurent, > >Sorry for taking so long to answer (again!). Could you try the >attached patch? > I just try your patch... works fine... I adopt it ! >JMarc > > Now looking forward to the new version. I thank you again. Laurent. From Jean-Marc.Lasgouttes at inria.fr Wed Apr 21 17:18:02 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Apr 21 10:18:08 2004 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: <408672A1.5050008@lapp.in2p3.fr> (laurent FOURNIER's message of "Wed, 21 Apr 2004 15:09:53 +0200") References: <406D3AE7.5090303@lapp.in2p3.fr> <408672A1.5050008@lapp.in2p3.fr> Message-ID: >>>>> "laurent" == laurent FOURNIER writes: laurent> Dear Jean-Marc, >> Dear Laurent, >> >> Sorry for taking so long to answer (again!). Could you try the >> attached patch? >> laurent> I just try your patch... works fine... I adopt it ! Thanks. I'll apply it asap. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Apr 21 18:21:18 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Apr 21 11:21:23 2004 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 21 Apr 2004 16:18:02 +0200") References: <406D3AE7.5090303@lapp.in2p3.fr> <408672A1.5050008@lapp.in2p3.fr> Message-ID: >>>>> "Jean-Marc" == Jean-Marc Lasgouttes writes: laurent> I just try your patch... works fine... I adopt it ! Jean-Marc> Thanks. I'll apply it asap. Done. BTW Laurent: thanks for being so patient :) JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Apr 21 18:28:42 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Apr 21 11:28:47 2004 Subject: [XForms] FL_NOBORDER forms and sawfish In-Reply-To: <407CF771.1040308@interlab.es> (Natalia Crespo's message of "Wed, 14 Apr 2004 10:33:53 +0200") References: <407CF771.1040308@interlab.es> Message-ID: >>>>> "Natalia" == Natalia Crespo writes: Natalia> To subscribers of the xforms list Hello, Natalia> We've been working with fvwm2 window manager and applications Natalia> using xforms library. We need to use windows with Natalia> FL_FULLBORDER and FL_NOBORDER border in the same application Natalia> and with fvwm2 we don't have any problem. Natalia> However, we've decided to use GNOME with sawfish as window Natalia> manager and we've got quite problems showing a window with no Natalia> border and after that another one with full border. The Natalia> second window (with border) stays at the back of the first Natalia> (without border) one and the application doesn't work Natalia> properly. We'd like to know if it's possible to configure Natalia> sawfish to manage that kind of window without problems. We've Natalia> been trying to configurate it using "~/.sawfishrc" file but Natalia> we haven't found a solution. Anybody knows if it's necessary Natalia> to change any attribute to get it? Any other suggestion? Hello Natalia, Did you try to ask about that on a sawfish mailing list? What do the properties (as seen by xprop) of your windows look like? JMarc From viton.1 at osu.edu Thu Apr 22 11:01:05 2004 From: viton.1 at osu.edu (Philip A. Viton) Date: Thu Apr 22 14:48:20 2004 Subject: [XForms] xforms downloads on savannah Message-ID: <6.1.0.6.2.20040422095836.01c6bfb8@localhost> Hi: Are you sure that the xforms files in savannah's Downloads section are OK? I downloaded eg forms.ps.gz and gzip doesn't seem to recognize it as valid. I tried gzip on a file from another source, and it works fine; suggesting that it's not necessarily gzip's problem. (This in under Win2k/cygwin). Regards, ------------------------ Philip A. Viton City Planning, Ohio State University 190 W. 17th Ave,Columbus OH 43210 viton.1@osu.edu From angus.leeming at btopenworld.com Thu Apr 22 21:06:04 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Apr 22 15:08:27 2004 Subject: [XForms] xforms downloads on savannah In-Reply-To: <6.1.0.6.2.20040422095836.01c6bfb8@localhost> References: <6.1.0.6.2.20040422095836.01c6bfb8@localhost> Message-ID: <200404222006.04058.angus.leeming@btopenworld.com> On Thursday 22 April 2004 2:01 pm, Philip A. Viton wrote: > Hi: > > Are you sure that the xforms files in savannah's Downloads section > are OK? I downloaded eg forms.ps.gz and gzip doesn't seem to > recognize it as valid. I tried gzip on a file from another source, > and it works fine; suggesting that it's not necessarily gzip's > problem. (This in under Win2k/cygwin). I've just tried forms.ps.gz and it views fine for me with gs. Perhaps your download was corrupt? Angus From GalbraithP at dfo-mpo.gc.ca Thu Apr 22 16:14:45 2004 From: GalbraithP at dfo-mpo.gc.ca (Peter S Galbraith) Date: Thu Apr 22 15:14:51 2004 Subject: [XForms] xforms downloads on savannah In-Reply-To: Message from "Philip A. Viton" <6.1.0.6.2.20040422095836.01c6bfb8@localhost> References: <6.1.0.6.2.20040422095836.01c6bfb8@localhost> Message-ID: <20040422191446.44C90DA0A3@mixing.qc.dfo.ca> Philip A. Viton wrote: > Are you sure that the xforms files in savannah's Downloads section are OK? > I downloaded eg forms.ps.gz and gzip doesn't seem to recognize it as > valid. I just tried it and gv liked it fine. Try again? Peter From angus.leeming at btopenworld.com Sun May 2 12:01:21 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sun May 2 06:01:39 2004 Subject: [XForms] [patch]: squash valgrind warning about possible memory leak. Message-ID: <200405021101.21521.angus.leeming@btopenworld.com> Jean-Marc, all It seems that the attached patch is needed to make valgrind happy. It looks sensible to me, but I'd value a sanity check. Angus ==8727== 13 bytes in 1 blocks are possibly lost in loss record 11 of 144 ==8727== at 0x32728B: malloc (vg_replace_malloc.c:153) ==8727== by 0x2A0EEE: fl_strdup (strdup.c:44) ==8727== by 0x284F35: get_command_name (flresource.c:693) ==8727== by 0x2850F3: fl_initialize (flresource.c:800) ==8727== by 0x81F17EB: lyx_gui::parse_init(int&, char**) (lyx_gui.C:162) ==8727== by 0x80D9269: LyX::priv_exec(int&, char**) (lyx_main.C:190) ==8727== by 0x80D8F7D: LyX::exec(int&, char**) (scoped_ptr.hpp:94) ==8727== by 0x805408D: main (main.C:42) ==8727== by 0x6C4BBE: __libc_start_main (in /lib/libc-2.3.2.so) ==8727== by 0x8053FB4: (within /home/angus/lyx/devel/build/src/lyx-xforms) -------------- next part -------------- A non-text attachment was scrubbed... Name: flresource.diff Type: text/x-diff Size: 1153 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040502/f970b5ff/flresource.bin From Jean-Marc.Lasgouttes at inria.fr Mon May 3 12:28:31 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon May 3 05:28:37 2004 Subject: [XForms] [patch]: squash valgrind warning about possible memory leak. In-Reply-To: <200405021101.21521.angus.leeming@btopenworld.com> (Angus Leeming's message of "Sun, 2 May 2004 11:01:21 +0100") References: <200405021101.21521.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, all Angus> It seems that the attached patch is needed to make valgrind Angus> happy. It looks sensible to me, but I'd value a sanity check. Looks reasonable. I did see this report, but did not know what to do about it. JMarc From angus.leeming at btopenworld.com Tue May 4 18:30:59 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 4 12:31:43 2004 Subject: [XForms] Enable FL_FREE objects to optimize their drawing Message-ID: <200405041730.59672.angus.leeming@btopenworld.com> The attached patch passes the associated (XEvent * xev) to fl_handle_object on an FL_DRAW event. This XEvent * is not used at all by any of xforms' "native" widgets, but an FL_FREE object is able to make use of this info to redraw only the part of the window that has changed. An example being the FL_FREE object used by LyX for the main screen. I can see no harm in adding this patch as it does not change existing behaviour at all. Thoughts? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: xforms-redraw.diff Type: text/x-diff Size: 4165 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040504/e1bb529d/xforms-redraw.bin From angus.leeming at btopenworld.com Wed May 5 14:09:06 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 08:09:06 2004 Subject: [XForms] Enable FL_FREE objects to optimize their drawing In-Reply-To: <200405041730.59672.angus.leeming@btopenworld.com> References: <200405041730.59672.angus.leeming@btopenworld.com> Message-ID: <200405051309.06532.angus.leeming@btopenworld.com> On Tuesday 04 May 2004 5:30 pm, Angus Leeming wrote: > The attached patch passes the associated (XEvent * xev) to > fl_handle_object on an FL_DRAW event. This XEvent * is not used at > all by any of xforms' "native" widgets, but an FL_FREE object is > able to make use of this info to redraw only the part of the window > that has changed. > > An example being the FL_FREE object used by LyX for the main > screen. > > I can see no harm in adding this patch as it does not change > existing behaviour at all. Thoughts? Ok, I committed it. Angus From angus.leeming at btopenworld.com Wed May 5 15:23:58 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 09:24:04 2004 Subject: [XForms] Catching up on patches Message-ID: <200405051423.58780.angus.leeming@btopenworld.com> It seems to me that these mails and patches need to be incorporated in the xforms tree. Have I missed anythiing? Regards, Angus Mike Heffner [XForms] Re: [PATCH] Double clicking doesn't work in file http://bob.usuhs.mil/pipermail/xforms/2003/000163.html [XForms] fl_set_font_name() verbiage http://bob.usuhs.mil/pipermail/xforms/2004/000176.html Dmitry Karasik [XForms] XForms text rendering bug patch http://bob.usuhs.mil/pipermail/xforms/2004/000203.html Jeff [XForms] Redone client callback http://bob.usuhs.mil/pipermail/xforms/2004/000225.html Jeff [XForms] client event sample application http://bob.usuhs.mil/pipermail/xforms/2004/000260.html From msz at astrouw.edu.pl Wed May 5 16:33:50 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed May 5 09:34:01 2004 Subject: [XForms] Catching up on patches In-Reply-To: <200405051423.58780.angus.leeming@btopenworld.com> References: <200405051423.58780.angus.leeming@btopenworld.com> Message-ID: <20040505133350.GA4071@astrouw.edu.pl> > It seems to me that these mails and patches need to be incorporated in > the xforms tree. Have I missed anythiing? Angus, There was also Clive Stubbings' JPEG/Image patch but maybe it is already in. regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Wed May 5 15:43:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 09:43:19 2004 Subject: [XForms] Catching up on patches In-Reply-To: <20040505133350.GA4071@astrouw.edu.pl> References: <200405051423.58780.angus.leeming@btopenworld.com> <20040505133350.GA4071@astrouw.edu.pl> Message-ID: <200405051443.18746.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 2:33 pm, Michal Szymanski wrote: > > It seems to me that these mails and patches need to be > > incorporated in the xforms tree. Have I missed anythiing? > > Angus, > > There was also Clive Stubbings' JPEG/Image patch but maybe it is > already in. I believe so: http://savannah.nongnu.org/cgi-bin/viewcvs/xforms/xforms/ChangeLog.diff?r1=1.68&r2=1.69 http://savannah.nongnu.org/cgi-bin/viewcvs/xforms/xforms/image/image_gif.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.7&diff_format=h http://savannah.nongnu.org/cgi-bin/viewcvs/xforms/xforms/image/image_jpeg.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.7&diff_format=h Regards, Angus From angus.leeming at btopenworld.com Wed May 5 15:56:31 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 09:56:33 2004 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: Message-ID: <200405051456.31697.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 12:16 am, Mike Heffner wrote: > 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 Mike, many apologies for the delay, but I finally committed this patch. Kind regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fselect.diff Type: text/x-diff Size: 3015 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040505/c7fd5586/fselect.bin From angus.leeming at btopenworld.com Wed May 5 16:01:01 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 10:01:00 2004 Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: References: Message-ID: <200405051501.01448.angus.leeming@btopenworld.com> On Thursday 15 January 2004 5:30 am, Mike Heffner wrote: > When fl_set_font_name() fails it will return -1 but it also prints: > > In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah > > This function is typically used as a method of testing whether a > font is loadable or not, so it's not always a fatal condition. Can > this print statement be wrapped in a debug-only conditional? Mike does this do the job: - M_err("SetFont", "Bad FontStyle request %d: %s", numb, flf->fname); + M_warn("SetFont", "Bad FontStyle request %d: %s", numb, flf->fname); of are you actually looking for something like this: #if (FL_DEBUG >= ML_DEBUG) M_debug("SetFont", "Bad FontStyle request %d: %s", numb, flf->fname); #endif Angus From angus.leeming at btopenworld.com Wed May 5 16:41:13 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 10:41:13 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: References: <4043115F.9080007@karasik.eu.org> Message-ID: <200405051541.13406.angus.leeming@btopenworld.com> On Tuesday 02 March 2004 2:41 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Dmitry" == Dmitry Karasik writes: > Dmitry> Under certain condition, > Dmitry> input lines do not display any text. The bug, which is > Dmitry> basically comparison of a signed integer as a boolean, is > Dmitry> fixed by the following patch: > Hello, > Thanks for the patch. I think we are suffering from this bug in LyX > in some circumstances, but we never got to fix it. Can you expand further? > Are you sure that your fix is the right one? I do not know this > part of code at all, but the comment before the function says: > /* Major text drawing routine > * clip == 0: no clipping > * clip == 1: do clipping here > * clip == -1: clipping is done outside of this routine > */ > so testing for clip as a boolean means 'if there is some clipping > going on somewhere', which may be a reasonable test. Are you sure > that only the 'do clipping here' case should be handled? Jean-Marc, I've been reading the code. (clip == -1) is used only by the input.c routine draw_input I read this: if (clip && (starty[i] + flx->fdesc) > y + h) continue; as saying "if clipping and if the position of the baseline + the font descent is greater than the bottom of the widget then loop. I also see that this command is the only place in the routine that mentions clip and which does not qualify it with (clip > 0). In fact, all they are used for elsewhere is: if (clip > 0) fl_set_text_clipping(); if (clip > 0) fl_unset_text_clipping(); Conclusion, it's meant and should stay. Angus From angus.leeming at btopenworld.com Wed May 5 16:49:06 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 10:49:08 2004 Subject: [XForms] Where to change forms.h? In-Reply-To: <407E9C08.1080809@comcast.net> References: <407D54E7.5070607@comcast.net> <200404141621.19008.angus.leeming@btopenworld.com> <407E9C08.1080809@comcast.net> Message-ID: <200405051549.06082.angus.leeming@btopenworld.com> On Thursday 15 April 2004 3:28 pm, Jeff wrote: > To subscribers of the xforms list > I did have an email glitch and I must have missed it. Sorry. > I am getting the patch ready in the next day or two. > > Jeff Jeff, did I miss this patch or is it still a work in progress? Angus > Angus Leeming wrote: > >On Wednesday 14 April 2004 4:12 pm, Jeff wrote: > >>I've asked this problem before, but where do you implement > >> changes for /lib/include/forms.h? > >> > >>It is created during the ./confiigure and make steps. > > > >I answered it before too: > > > >See the files in lib/include. They are concatenated together to > > create forms.h > > > >So, one possible solution would be to create a new file > > client_msg.h and add it to the list of files in > > lib/include/Makefile.am > > > >Angus From angus.leeming at btopenworld.com Wed May 5 17:16:30 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 11:16:29 2004 Subject: [XForms] The NT directory Message-ID: <200405051616.30029.angus.leeming@btopenworld.com> Jean-Marc, is it good for anything? Doesn't libtool handle Win32 issues? Angus From Jean-Marc.Lasgouttes at inria.fr Wed May 5 18:41:36 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed May 5 11:41:42 2004 Subject: [XForms] The NT directory In-Reply-To: <200405051616.30029.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 16:16:30 +0100") References: <200405051616.30029.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, is it good for Angus> anything? Doesn't libtool handle Win32 issues? Angus AFAIK it contains visual c++ project files, which are the replacement for our makefiles. I really do not know whether they are still usable, and actually, I believe that they are not. If you look at ftp://ncmir.ucsd.edu/pub/xforms/Attic/NT/, you will find that the version in W32/, which is according to Readme.txt the one that needs this NT/ directory, has not been upgraded after version 0.88.1. Thus one may consider that it is dead and that the cygwin version is good enough. Actually, I guess that making a mingw version would be more useful than this vc++ version. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed May 5 18:50:08 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed May 5 11:50:13 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <200405051541.13406.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 15:41:13 +0100") References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Tuesday 02 March 2004 2:41 pm, Jean-Marc Lasgouttes wrote: >> >>>>> "Dmitry" == Dmitry Karasik writes: Dmitry> Under certain condition, input lines do not display any text. Dmitry> The bug, which is basically comparison of a signed integer as Dmitry> a boolean, is fixed by the following patch: >> Hello, >> Thanks for the patch. I think we are suffering from this bug in LyX >> in some circumstances, but we never got to fix it. Angus> Can you expand further? I was thinking about bugs like the following: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg41904.html Angus> I also see that this command is the only place in the routine Angus> that mentions clip and which does not qualify it with (clip > Angus> 0). In fact, all they are used for elsewhere is: Angus> if (clip > 0) fl_set_text_clipping(); Angus> if (clip > 0) fl_unset_text_clipping(); Angus> Conclusion, it's meant and should stay. The it should probably be "if (clip !=0)" to make things clear. JMarc From angus.leeming at btopenworld.com Wed May 5 17:54:27 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 11:54:30 2004 Subject: [XForms] The NT directory In-Reply-To: References: <200405051616.30029.angus.leeming@btopenworld.com> Message-ID: <200405051654.27959.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 4:41 pm, Jean-Marc Lasgouttes wrote: > Angus> Jean-Marc, is it good for > Angus> anything? Doesn't libtool handle Win32 issues? Angus > > AFAIK it contains visual c++ project files, which are the > replacement for our makefiles. > > I really do not know whether they are still usable, and actually, I > believe that they are not. > > If you look at ftp://ncmir.ucsd.edu/pub/xforms/Attic/NT/, you will > find that the version in W32/, which is according to Readme.txt the > one that needs this NT/ directory, has not been upgraded after > version 0.88.1. Thus one may consider that it is dead and that the > cygwin version is good enough. Actually, I guess that making a > mingw version would be more useful than this vc++ version. In that case I'll put these in the Attic too. Angus From angus.leeming at btopenworld.com Wed May 5 18:03:30 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 12:03:30 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> Message-ID: <200405051703.30709.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 4:50 pm, Jean-Marc Lasgouttes wrote: > >> Thanks for the patch. I think we are suffering from this bug in > >> LyX in some circumstances, but we never got to fix it. > > Angus> Can you expand further? > > I was thinking about bugs like the following: > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg41904.html Ouch! Incidentally, how do you remember stuff like this? > Angus> I also see that this command is the only place in the > routine Angus> that mentions clip and which does not qualify it > with (clip > Angus> 0). In fact, all they are used for elsewhere > is: > > Angus> if (clip > 0) fl_set_text_clipping(); > > Angus> if (clip > 0) fl_unset_text_clipping(); > > Angus> Conclusion, it's meant and should stay. > > The it should probably be "if (clip !=0)" to make things clear. I'll do that now. Angus From angus.leeming at btopenworld.com Wed May 5 18:08:24 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 12:08:24 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> Message-ID: <200405051708.24812.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 4:50 pm, Jean-Marc Lasgouttes wrote: > I was thinking about bugs like the following: > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg41904.html Actually, wouldn't this bug be fixed by changing this: /* Check whether visible */ if (clip != 0 && (starty[i] + flx->fdesc) > y + h) continue; to this: /* Check whether visible */ if (clip != 0 && starty[i] > y + h) continue; Ie, draw this line of text even if it extends beyond the widget and then rely on XSetClipRectangles to do its stuff. Angus From Jean-Marc.Lasgouttes at inria.fr Wed May 5 19:28:41 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed May 5 12:28:46 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <200405051703.30709.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 17:03:30 +0100") References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> <200405051703.30709.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Ouch! Incidentally, how do you remember stuff like this? Well, I have over 300 messages in my lyx-devel folder, and the oldest is from May 2000. From time to time, I go over the mailbox and see what bugs are still relevant. This one was a bug that I did not know how to solve, but that I wanted to remember about. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed May 5 19:30:29 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed May 5 12:30:35 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <200405051708.24812.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 17:08:24 +0100") References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> <200405051708.24812.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 05 May 2004 4:50 pm, Jean-Marc Lasgouttes wrote: >> I was thinking about bugs like the following: >> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg41904.html Angus> Actually, wouldn't this bug be fixed by changing this: Angus> /* Check whether visible */ Angus> if (clip != 0 && (starty[i] + flx->fdesc) > y + h) continue; Angus> to this: Angus> /* Check whether visible */ Angus> if (clip != 0 && starty[i] > y + h) continue; Angus> Ie, draw this line of text even if it extends beyond the widget Angus> and then rely on XSetClipRectangles to do its stuff. It seems reasonable. Do we have a way to check that it does what we think it does? JMarc From Jean-Marc.Lasgouttes at inria.fr Wed May 5 19:30:53 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed May 5 12:30:57 2004 Subject: [XForms] Catching up on patches In-Reply-To: <200405051423.58780.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 14:23:58 +0100") References: <200405051423.58780.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list It seems to me that these Angus> mails and patches need to be incorporated in the xforms tree. Angus> Have I missed anythiing? Your slider patch maybe? JMarc From angus.leeming at btopenworld.com Wed May 5 18:46:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 12:46:29 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: References: <4043115F.9080007@karasik.eu.org> <200405051708.24812.angus.leeming@btopenworld.com> Message-ID: <200405051746.18902.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 5:30 pm, Jean-Marc Lasgouttes wrote: > Angus> Actually, wouldn't this bug be fixed by changing this: > > Angus> /* Check whether visible */ > Angus> if (clip != 0 && (starty[i] + flx->fdesc) > y + h) > continue; > > Angus> to this: > > Angus> /* Check whether visible */ > Angus> if (clip != 0 && starty[i] > y + h) continue; > > Angus> Ie, draw this line of text even if it extends beyond the > widget Angus> and then rely on XSetClipRectangles to do its stuff. > > It seems reasonable. Do we have a way to check that it does what we > think it does? Here's the (correct) patch and a test case that works as expected with it and displays nothing without it. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: text.diff Type: text/x-diff Size: 651 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040505/e6cfca40/text.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: input_test.C Type: text/x-c++src Size: 921 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040505/e6cfca40/input_test.bin From angus.leeming at btopenworld.com Wed May 5 19:04:28 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 13:04:51 2004 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <4043115F.9080007@karasik.eu.org> References: <4043115F.9080007@karasik.eu.org> Message-ID: <200405051804.28169.angus.leeming@btopenworld.com> On Monday 01 March 2004 10:33 am, Dmitry Karasik wrote: > To subscribers of the xforms list > > > Under certain condition, input lines do not display any text. > The bug, which is basically comparison of a signed integer as a > boolean, is fixed by the following patch: Hi, Dmitry. I don't think that your patch is correct. Instead I propose the one attached. Could you try it out and report back whether it works for you? Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: text.diff Type: text/x-diff Size: 651 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040505/3ea8fcb4/text.bin From angus.leeming at btopenworld.com Wed May 5 19:40:50 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 13:40:50 2004 Subject: [XForms] Catching up on patches In-Reply-To: References: <200405051423.58780.angus.leeming@btopenworld.com> Message-ID: <200405051840.50791.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 5:30 pm, Jean-Marc Lasgouttes wrote: > Angus> It seems to me that these > Angus> mails and patches need to be incorporated in the xforms > tree. Angus> Have I missed anythiing? > > Your slider patch maybe? Yes, of course. I've just tried it out with lyx. Works beautifully on this 2.66GHz machine. Still, the trouble with a counter is that eventually, the patch will have to be patched to enable it to be usable on tomorrows 266GHz machine. What do you think? Angus From angus.leeming at btopenworld.com Wed May 5 20:30:08 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 14:30:09 2004 Subject: [XForms] Catching up on patches In-Reply-To: <200405051840.50791.angus.leeming@btopenworld.com> References: <200405051423.58780.angus.leeming@btopenworld.com> <200405051840.50791.angus.leeming@btopenworld.com> Message-ID: <200405051930.08967.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 6:40 pm, Angus Leeming wrote: > On Wednesday 05 May 2004 5:30 pm, Jean-Marc Lasgouttes wrote: > > Angus> It seems to me that these > > Angus> mails and patches need to be incorporated in the xforms > > tree. Angus> Have I missed anythiing? > > > > Your slider patch maybe? > > Yes, of course. I've just tried it out with lyx. Works beautifully > on this 2.66GHz machine. Still, the trouble with a counter is that > eventually, the patch will have to be patched to enable it to be > usable on tomorrows 266GHz machine. > > What do you think? > Angus To give you something to base your thoughts on, here are two patches. slider_v1.diff is the counter version and slider_v2.diff is the timeout version. Personally, I prefer the timeout version, with the proviso that it needs void fl_set_slider_timeout(int millisecs); int fl_get_slider_timeout(); The same technique can be used for the counters class. Thoughts? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: slider_v1.diff Type: text/x-diff Size: 1228 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040505/3dda1d04/slider_v1.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: slider_v2.diff Type: text/x-diff Size: 1679 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040505/3dda1d04/slider_v2.bin From angus.leeming at btopenworld.com Wed May 5 22:43:55 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 5 16:43:54 2004 Subject: [XForms] An improved slider patch Message-ID: <200405052143.55156.angus.leeming@btopenworld.com> * uses a timeout to trigger the repeat (as did slider_v2.diff) * the repeat interval is configurable, through new functions: /** Functions to set and get the timeout value used by the slider code to increment the position of the knob. */ FL_EXPORT int fl_get_slider_repeat(FL_OBJECT *ob ); FL_EXPORT void fl_set_slider_repeat(FL_OBJECT *ob, int millisec); * slider behaviour is configurable on a per-slider basis. No changes to any publicly-visible structs, so the library remains binary compatible with version 1.0. Suggestions and improvements are, of course, welcome, but if no one objects, I'll commit this. The counter code can be refactored in similar fashion also. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: slider_v3.diff Type: text/x-diff Size: 4479 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040505/37716ef0/slider_v3.bin From mheffner at vt.edu Wed May 5 19:12:15 2004 From: mheffner at vt.edu (Mike Heffner) Date: Wed May 5 18:12:25 2004 Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: <200405051501.01448.angus.leeming@btopenworld.com> Message-ID: On 05-May-2004 Angus Leeming wrote: | On Thursday 15 January 2004 5:30 am, Mike Heffner wrote: |> When fl_set_font_name() fails it will return -1 but it also prints: |> |> In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah |> |> This function is typically used as a method of testing whether a |> font is loadable or not, so it's not always a fatal condition. Can |> this print statement be wrapped in a debug-only conditional? | | Mike does this do the job: | - M_err("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); | + M_warn("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); | | of are you actually looking for something like this: |#if (FL_DEBUG >= ML_DEBUG) | M_debug("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); |#endif | Whichever would prevent it from being displayed if libforms is not compiled in debug mode. When is M_warn() printed? Mike -- Mike Heffner From angus.leeming at btopenworld.com Thu May 6 12:05:57 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 06:05:59 2004 Subject: [XForms] Committed patch Message-ID: <200405061105.57973.angus.leeming@btopenworld.com> FYI Enable input widgets to (partially) display characters larger than the input height. Jean-Marc, I guess that you can remove that bug report from your inbox. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: text.diff Type: text/x-diff Size: 1803 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040506/ef5becf6/text.bin From Jean-Marc.Lasgouttes at inria.fr Thu May 6 13:23:07 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu May 6 06:23:11 2004 Subject: [XForms] Committed patch In-Reply-To: <200405061105.57973.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 6 May 2004 11:05:57 +0100") References: <200405061105.57973.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list FYI Angus> Enable input widgets to (partially) display characters larger Angus> than the input height. Angus> Jean-Marc, I guess that you can remove that bug report from Angus> your inbox. Thanks :) JMarc From angus.leeming at btopenworld.com Thu May 6 13:55:04 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 07:55:04 2004 Subject: [XForms] Committed patch Message-ID: <200405061255.04611.angus.leeming@btopenworld.com> FYI Building of rpms works again. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: rpm.diff Type: text/x-diff Size: 2354 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040506/9a65fd1e/rpm.bin From angus.leeming at btopenworld.com Thu May 6 15:46:41 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 09:46:42 2004 Subject: [XForms] rpms are not quite right Message-ID: <200405061446.41297.angus.leeming@btopenworld.com> Jean-Marc, all, Executive summary: how do we get rpm to install the symbolic links libforms.so and libforms.so.1 that are to point at libforms.so.1.0.0? Is this a libtool issue? Detailed description of what I've done. I've built the xforms rpms (as non-root) by 1. creating a file .rpmmacros: $ cat ~/.rpmmacros %_topdir /home/angus/rpm 2. generating the necessary subdirectories of ~/rpm $ mkdir ~/rpm $ cd ~/rpm $ mkdir -p RPMS/i386 RPMS/noarch SRPMS SOURCES BUILD SPECS Thereafter I can build the rpms as non-root with $ cd ~/xforms/cvs/build $ make rpmdist The rpms are generated as expected: $ cd ~/rpm/RPMS/i386/ $ ls xforms-1.0.90-1rh8x.i386.rpm xforms-devel-1.0.90-1rh8x.i386.rpm xforms-debuginfo-1.0.90-1rh8x.i386.rpm Two questions: a. Any idea what this last one is??? b. The names are incorrect. I'm building on a fedora core 1 machine so that 'rh8x' is incorrect. Is there a way to specify this portably in the xforms.spec.in file or must it be hard coded? Thereafter, as root, I install in /usr/local: # rpm -Uvh --prefix /usr/local xforms-1.0.90-1rh8x.i386.rpm Preparing... ############################# [100%] 1:xforms ############################# [100%] # rpm -Uvh --prefix /usr/local xforms-devel-1.0.90-1rh8x.i386.rpm Preparing... ############################# [100%] 1:xforms-devel ########################### [100%] Everything appears to be OK: # ls -l /usr/local/bin/f* -rwxr-xr-x 1 root root 81916 May 6 14:33 /usr/local/bin/fd2ps -rwxr-xr-x 1 root root 221920 May 6 14:33 /usr/local/bin/fdesign # ls -l /usr/local/include total 160 -rw-r--r-- 1 root root 24582 May 6 14:33 flimage.h -rw-r--r-- 1 root root 123575 May 6 14:33 forms.h -rw-r--r-- 1 root root 1129 May 6 14:33 glcanvas.h # ls -l /usr/local/lib total 1540 -rw-r--r-- 1 root root 254026 May 6 14:33 libflimage.a -rwxr-xr-x 1 root root 729 May 6 14:33 libflimage.la -rwxr-xr-x 1 root root 190856 May 6 14:33 libflimage.so.1.0.0 -rw-r--r-- 1 root root 637862 May 6 14:33 libforms.a -rw-r--r-- 1 root root 4692 May 6 14:33 libformsGL.a -rwxr-xr-x 1 root root 729 May 6 14:33 libformsGL.la -rwxr-xr-x 1 root root 7204 May 6 14:33 libformsGL.so.1.0.0 -rwxr-xr-x 1 root root 715 May 6 14:33 libforms.la -rwxr-xr-x 1 root root 435300 May 6 14:33 libforms.so.1.0.0 However, note that there are no libforms.so, libforms.so.1, etc symbolic links. Just the libforms.so.1.0.0 There absence means that fdesign and fd2ps are not executable: # ldd /usr/local/bin/fdesign libforms.so.1 => not found libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00cc2000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x00e1f000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x00c43000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00437000) libc.so.6 => /lib/tls/libc.so.6 (0x005c1000) libm.so.6 => /lib/tls/libm.so.6 (0x00799000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00a48000) libdl.so.2 => /lib/libdl.so.2 (0x0082a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00325000) How to rectify the situation? Angus From Jean-Marc.Lasgouttes at inria.fr Thu May 6 17:13:04 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu May 6 10:13:11 2004 Subject: [XForms] rpms are not quite right In-Reply-To: <200405061446.41297.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 6 May 2004 14:46:41 +0100") References: <200405061446.41297.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, all, Angus> Executive summary: how do we get rpm to install the symbolic Angus> links libforms.so and libforms.so.1 that are to point at Angus> libforms.so.1.0.0? Is this a libtool issue? Does libtool do that correctly when you do a 'make install'? It may be that you have to do that yourself in a postinstall phase. You may want to look at the rpm spec file of another existing library. Angus> Two questions: a. Any idea what this last one is??? I guess it is a version where debug infomation has not been stripped. This would only make sense when building without --disable-debug, I guess. Angus> b. The names are incorrect. I'm building on a fedora core 1 Angus> machine so that 'rh8x' is incorrect. Is there a way to specify Angus> this portably in the xforms.spec.in file or must it be hard Angus> coded? The rh8x comes from this thing at the top: Release: 1rh8x Just replace it with '1'. We do not have any reason to generate versions that are specific to some distributions, I think. BTW, the line just below is wrong, since the downloads have changed place. Source0: http://savannah.nongnu.org/download/xforms/stable.pkg/1.0/%{name}-%{version}.tar.gz JMarc From angus.leeming at btopenworld.com Thu May 6 16:18:06 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 10:18:05 2004 Subject: [XForms] rpms are not quite right In-Reply-To: References: <200405061446.41297.angus.leeming@btopenworld.com> Message-ID: <200405061518.06646.angus.leeming@btopenworld.com> On Thursday 06 May 2004 3:13 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> To subscribers of the xforms list Jean-Marc, all, > > Angus> Executive summary: how do we get rpm to install the symbolic > Angus> links libforms.so and libforms.so.1 that are to point at > Angus> libforms.so.1.0.0? Is this a libtool issue? > > Does libtool do that correctly when you do a 'make install'? Yes. As usual, you've nailed down the problem. 'make install' works perfectly. What fails is: allfiles=`find ${RPM_BUILD_ROOT}/usr -type f -print | sed "s@^${RPM_BUILD_ROOT}@@g"` 'find' does not pick up the symbolic links. Indeed, it shouldn't. > It may be that you have to do that yourself in a postinstall phase. > You may want to look at the rpm spec file of another existing library. Thanks ;-) > The rh8x comes from this thing at the top: > Release: 1rh8x > > Just replace it with '1'. We do not have any reason to generate > versions that are specific to some distributions, I think. Good. > BTW, the line just below is wrong, since the downloads have changed place. > > Source0: > http://savannah.nongnu.org/download/xforms/stable.pkg/1.0/%{name}-%{version >}.tar.gz Ok. I'll fix that too. Angus From angus.leeming at btopenworld.com Thu May 6 17:47:54 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 11:47:55 2004 Subject: [XForms] rpms are not quite right In-Reply-To: <200405061518.06646.angus.leeming@btopenworld.com> References: <200405061446.41297.angus.leeming@btopenworld.com> <200405061518.06646.angus.leeming@btopenworld.com> Message-ID: <200405061647.54808.angus.leeming@btopenworld.com> On Thursday 06 May 2004 3:18 pm, Angus Leeming wrote: > On Thursday 06 May 2004 3:13 pm, Jean-Marc Lasgouttes wrote: > > It may be that you have to do that yourself in a postinstall phase. > > You may want to look at the rpm spec file of another existing library. > > Thanks ;-) Ok, Jean-Marc. The attached patch *almost* does the right thing. # rpm -Uvh --prefix /home/angus/test /home/angus/rpm/RPMS/i386/xforms-1.0.90-1.i386.rpm Preparing... ########################################### [100%] 1:xforms ########################################### [100%] Executing post installation ln -sf /home/angus/test/lib/libforms.so.1.0.90 /home/angus/test/lib/libforms.so ln -sf /home/angus/test/lib/libforms.so.1.0.90 /home/angus/test/lib/libforms.so.1 ln -sf /home/angus/test/lib/libformsGL.so.1.0.90 /home/angus/test/lib/libformsGL.so ln -sf /home/angus/test/lib/libformsGL.so.1.0.90 /home/angus/test/lib/libformsGL.so.1 ln -sf /home/angus/test/lib/libflimage.so.1.0.90 /home/angus/test/lib/libflimage.so ln -sf /home/angus/test/lib/libflimage.so.1.0.90 /home/angus/test/lib/libflimage.so.1 # rpm -e xforms Executing post uninstallation rm -f /home/angus/test/lib/libforms.so /home/angus/test/lib/libforms.so.1 rm -f /home/angus/test/lib/libformsGL.so /home/angus/test/lib/libformsGL.so.1 rm -f /home/angus/test/lib/libflimage.so /home/angus/test/lib/libflimage.so.1 Note, however, that we should be linking against 1.0.0 files not 1.0.90 ones. I remember our discussions some time ago about the meaning of these version numbers in the .so files and why they should be different to those of the package version. The .so version numbers are defined in lib/Makefile.am. However, it looks to me as if we need a new variable in configure.ac, say SO_VERSION, which will be substituted at compile time for '1:0:0'. lib/Makefile.am would contain the line: libforms_la_LDFLAGS = -version-info @SO_VERSION@ and xforms.spec.in would contain the line SO_VERSION=@SO_VERSION@ Thereafter, it's just a case of straightforward manipulation. Thoughts? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: xforms.spec.in.diff Type: text/x-diff Size: 1796 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040506/f517b2e1/xforms.spec.in.bin From angus.leeming at btopenworld.com Thu May 6 18:55:46 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 12:55:46 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system Message-ID: <200405061755.46491.angus.leeming@btopenworld.com> As usual, I'm less than sure of myself ;-) When xforms 1.0 was released, the libtool versioning was set to '1:0:0', a flag of the form 'current:revision:age' where 'age' must be less than or equal to the 'current' interface number. >From the libtool manual: Here are a set of rules to help you update your library version information: 1. Start with version information of `0:0:0' for each libtool library. 2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 3. If the library source code has changed at all since the last update, then increment revision (`c:r:a' becomes `c:r+1:a'). 4. If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0. 5. If any interfaces have been added since the last public release, then increment age. 6. If any interfaces have been removed since the last public release, then set age to 0. My take on this: * We're approaching a public release, so it's time to update the version info. (Rule 2.) * The source code has changed since the last update. (Rule 3.) r==1 --> '1:1:0' * Rule 4 applies. Interfaces have been added. c==2, r==0 --> '2:0:0' * Rule 5 applies. Interfaces hace been added. a==1 --> '2:0:1' * Rule 6 does not apply. No interfaces have been removed. Conclusion, the libtool version info is '2:0:1'. Does this look correct? Angus From angus.leeming at btopenworld.com Thu May 6 19:10:23 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 13:10:24 2004 Subject: [XForms] [patch] rpm spec file Message-ID: <200405061810.23953.angus.leeming@btopenworld.com> I believe that this 'does the right thing'. It creates symbolic links libforms.so and libforms.so.1 to libforms.so.1.0.0 when the rpm is installed and removes these links if the rpm is uninstalled. '1:0:0' is the libtool version of the shared libraries. This version info is used in two places, lib/Makefile.am and in xforms.spec.in, so I've moved it to configure.ac. Only one thing to keep up to date. Feedback is, of course, welcome. Else I'll commit tomorrow. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: spec.diff Type: text/x-diff Size: 4172 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040506/4a9f18fd/spec.bin From angus.leeming at btopenworld.com Thu May 6 19:16:21 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 13:16:21 2004 Subject: [XForms] [patch] sliders and counters Message-ID: <200405061816.21372.angus.leeming@btopenworld.com> The patch attached uses a timeout to control the rate at which the slider/counter is incremented. This replaces the current strategy which used a simple counter loop and which has become unusable with today's fast processors. The timeout is configurable on a per-slider/counter basis using the new accessor functions int fl_get_counter_repeat(FL_OBJECT * ob); void fl_set_counter_repeat(FL_OBJECT * ob, int millisec); int fl_get_slider_repeat(FL_OBJECT *ob); void fl_set_slider_repeat(FL_OBJECT *ob, int millisec); Once again, feedback is, of course, welcome. Else I'll commit tomorrow. I think that's all patches in the queue now dealt with. Waiting on Jeff and his 'client callback' patch. Other than that, all systems should be go. What else is needed for the 1.1 release? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: slider_counter.diff Type: text/x-diff Size: 8133 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040506/8b3d61c5/slider_counter.bin From angus.leeming at btopenworld.com Thu May 6 19:55:09 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 6 13:55:08 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <200405061755.46491.angus.leeming@btopenworld.com> References: <200405061755.46491.angus.leeming@btopenworld.com> Message-ID: <200405061855.09049.angus.leeming@btopenworld.com> On Thursday 06 May 2004 5:55 pm, Angus Leeming wrote: > Conclusion, the libtool version info is '2:0:1'. I find that the explanation of the system is much clearer here: http://sources.redhat.com/autobook/autobook/autobook_91.html Using this source, I get a version-info of '2:0:1' again, meaning that the interface is a superset of that of the previous, '1:0:0', public release and that programs compiled against '1:0:0' will link successfully against '2:0:1'. Full explanation below. Angus All Libtool libraries start with `-version-info' set to `0:0:0' -- this will be the default version number if you don't explicitly set it on the Libtool link command line. The meaning of these numbers (from left to right) is as follows: current The number of the current interface exported by the library. A current value of `0', means that you are calling the interface exported by this library interface 0. revision The implementation number of the most recent interface exported by this library. In this case, a revision value of `0' means that this is the first implementation of the interface. If the next release of this library exports the same interface, but has a different implementation (perhaps some bugs have been fixed), the revision number will be higher, but current number will be the same. In that case, when given a choice, the library with the highest revision will always be used by the runtime loader. age The number of previous additional interfaces supported by this library. If age were `2', then this library can be linked into executables which were built with a release of this library that exported the current interface number, current, or any of the previous two interfaces. By definition age must be less than or equal to current. At the outset, only the first ever interface is implemented, so age can only be `0'. For later releases of a library, the `-version-info' argument needs to be set correctly depending on any interface changes you have made. This is quite straightforward when you understand what the three numbers mean: 1. If you have changed any of the sources for this library, the revision number must be incremented. This is a new revision of the current interface. Yes -> version-info == 1:1:0 2. If the interface has changed, then current must be incremented, and revision reset to `0'. This is the first revision of a new interface. Yes -> version-info == 2:0:0 3. If the new interface is a superset of the previous interface (that is, if the previous interface has not been broken by the changes in this new release), then age must be incremented. This release is backwards compatible with the previous release. Yes -> version-info == 2:0:1 4. If the new interface has removed elements with respect to the previous interface, then you have broken backward compatibility and age must be reset to `0'. This release has a new, but backwards incompatible interface. No. version-info unchanged. From Todd.Denniston at ssa.crane.navy.mil Thu May 6 19:23:16 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu May 6 19:23:45 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system References: <200405061755.46491.angus.leeming@btopenworld.com> Message-ID: <409AC8E4.4357E80D@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > As usual, I'm less than sure of myself ;-) > > When xforms 1.0 was released, the libtool versioning was set to > '1:0:0', a flag of the form 'current:revision:age' where 'age' must > be less than or equal to the 'current' interface number. > > >From the libtool manual: unfortunately the archive does not go back to december of 1999 but the lestif guy's were having fun with the libtool versions too. https://terror.hungry.com/pipermail/lesstif/ http://www.lesstif.org/ but the cvs repo goes back that far you might look at the libtool changes from 1999-05-10 to 2000-08-22 and especially 1999-10-23. http://www.lesstif.org/cvs.html :pserver:anonymous@cvs.lesstif.sourceforge.net:/cvsroot/lesstif perhaps their trials might help you. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From angus.leeming at btopenworld.com Fri May 7 10:34:00 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 7 04:34:18 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <409AC8E4.4357E80D@ssa.crane.navy.mil> References: <200405061755.46491.angus.leeming@btopenworld.com> <409AC8E4.4357E80D@ssa.crane.navy.mil> Message-ID: <200405070934.00340.angus.leeming@btopenworld.com> On Friday 07 May 2004 12:23 am, Todd Denniston wrote: > unfortunately the archive does not go back to december of 1999 > but the lestif guy's were having fun with the libtool versions too. Interesting. However, could you help me out a little more? Specifically, which files should I be looking at? Regards, Angus ps, I'm away for the w/e so any silence is merely abscence ;-) From angus.leeming at btopenworld.com Fri May 7 10:41:21 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 7 04:41:20 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <200405070934.00340.angus.leeming@btopenworld.com> References: <200405061755.46491.angus.leeming@btopenworld.com> <409AC8E4.4357E80D@ssa.crane.navy.mil> <200405070934.00340.angus.leeming@btopenworld.com> Message-ID: <200405070941.21232.angus.leeming@btopenworld.com> On Friday 07 May 2004 9:34 am, Angus Leeming wrote: > ps, I'm away for the w/e so any silence is merely abscence ;-) I must try harder to spell correctly. Absence, absence, absence, absence, ... Mea culpa, A From angus.leeming at btopenworld.com Fri May 7 10:50:03 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 7 04:50:07 2004 Subject: [XForms] [patch] sliders and counters In-Reply-To: <200405061816.21372.angus.leeming@btopenworld.com> References: <200405061816.21372.angus.leeming@btopenworld.com> Message-ID: <200405070950.03505.angus.leeming@btopenworld.com> On Thursday 06 May 2004 6:16 pm, Angus Leeming wrote: > Once again, feedback is, of course, welcome. Else I'll commit > tomorrow. I've now done so. Both the slider/counter patch and the rpm spec file patch are now in cvs. Angus > I think that's all patches in the queue now dealt with. Waiting on > Jeff and his 'client callback' patch. Other than that, all systems > should be go. > > What else is needed for the 1.1 release? > Angus From xyzzy at speakeasy.org Fri May 7 03:53:17 2004 From: xyzzy at speakeasy.org (Trent Piepho) Date: Fri May 7 05:53:31 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <200405070934.00340.angus.leeming@btopenworld.com> Message-ID: On Fri, 7 May 2004, Angus Leeming wrote: > On Friday 07 May 2004 12:23 am, Todd Denniston wrote: > > unfortunately the archive does not go back to december of 1999 > > but the lestif guy's were having fun with the libtool versions too. I missed the beginning and point of this thread, but I'm going to go out on a limb and guess what you're trying to do. I created a libtool verion of the Makefile for netcdf, which uses a normal verion number scheme, major.minor.patchlevel, just like pretty much everything does. libtool uses a different and unique version number system, mapped into the normal major.minor.patch system that the dynamic linker uses. I decided that rather than use the libtool system, I'd just have normal version numbers. So I did this in the Makefile: $(LIBRARY): $(LIB_OBJS) major=`cut -d. -f1 ../VERSION` && \ minor=`cut -d. -f2 ../VERSION` && \ rev=`cut -d. -f3 ../VERSION` && \ libtoolver=`expr $$major + $$minor` && \ $(LINK.c) $(LIB_OBJS) \ -rpath $(LIBDIR) -version-info $$libtoolver:$$rev:$$minor VERSION is a file that was part of the normal build process, and would just have the text "3.5.0" in it. This will get libtool to create a shared object libnetcdf.so-3.5.0, like you would expect. If you're trying to create a libforms shared object with a normal version number, maybe this will help? From angus.leeming at btopenworld.com Fri May 7 12:33:51 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 7 06:33:50 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: References: Message-ID: <200405071133.51019.angus.leeming@btopenworld.com> On Friday 07 May 2004 10:53 am, Trent Piepho wrote: > To subscribers of the xforms list > > On Fri, 7 May 2004, Angus Leeming wrote: > > On Friday 07 May 2004 12:23 am, Todd Denniston wrote: > > > unfortunately the archive does not go back to december of 1999 > > > but the lestif guy's were having fun with the libtool versions > > > too. > > I missed the beginning and point of this thread, but I'm going to > go out on a limb and guess what you're trying to do. Thanks, Trent. Whilst I understand why you're doing what you're doing, I'm going to try and stick with the libtool scheme. At least until I've got a handle on lesstif's experience ;-) Regards, Angus From angus.leeming at btopenworld.com Fri May 7 13:04:59 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 7 07:04:57 2004 Subject: [XForms] One more piece of rpm magic needed Message-ID: <200405071204.59432.angus.leeming@btopenworld.com> This is just a heads up before I disappear for the w/e. Linking LyX against the XForms libraries installed from an rpm with: rpm -Uvh --prefix /usr/local xforms-1.0.90-1.i386.rpm I get the following warnings: libtool: link: warning: library `/usr/local/lib/libflimage.la' was moved. libtool: link: warning: library `/usr/local/lib/libforms.la' was moved. All because libflimage.la etc end with # Directory that this library needs to be installed in: libdir='/usr/lib' So I guess one more piece of post install magic is needed. I guess it's as simple as sed "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" Angus From Jean-Marc.Lasgouttes at inria.fr Fri May 7 15:47:55 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 7 08:48:00 2004 Subject: [XForms] One more piece of rpm magic needed In-Reply-To: <200405071204.59432.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 7 May 2004 12:04:59 +0100") References: <200405071204.59432.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> So I guess one more piece of post install magic is needed. Angus> I guess it's as simple as sed Angus> "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" Except that you can't use a slash as sed delimiter here, of course. JMarc From angus.leeming at btopenworld.com Fri May 7 14:51:44 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 7 08:51:46 2004 Subject: [XForms] One more piece of rpm magic needed In-Reply-To: References: <200405071204.59432.angus.leeming@btopenworld.com> Message-ID: <200405071351.44809.angus.leeming@btopenworld.com> On Friday 07 May 2004 1:47 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> So I guess one more piece of post install magic is needed. > > Angus> I guess it's as simple as sed > Angus> "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" > > Except that you can't use a slash as sed delimiter here, of course. Ahhhh, but I can. Patch attached works perfectly. Indeed the above is the *best* way to do things IMO. (The identifying regex before the s/// block *must* be bounded by '/'. The s@@@ is find.) (A rather smug) Angus (who really is off for the w/e NOW. -------------- next part -------------- A non-text attachment was scrubbed... Name: spec.diff Type: text/x-diff Size: 1985 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040507/512ecdd3/spec.bin From Jean-Marc.Lasgouttes at inria.fr Fri May 7 15:59:34 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 7 08:59:38 2004 Subject: [XForms] [patch] sliders and counters In-Reply-To: <200405061816.21372.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 6 May 2004 18:16:21 +0100") References: <200405061816.21372.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> What else is needed for the 1.1 release? I am currently trying to play around with xpopup.c to fix two problems: 1/ if you open a menu in LyX and then a submenu and then click on another submenu of the same level the first menu stays on screen. OK, I explain: in LyX, do File>New, and then click on Insert>Math and then Inset>Special Character. The result is that you have both submenus shown. I think the problem is that there should be some redraw event taking place, but that it does not happen. I tried to reproduce this with demos/popup or demos/pup, but nothing happens there. The problem does not occur on screen that honor backing store (as reported by xdpyinfo), but it seems that modern linux distributions ship an XFree86 that does not do backing store. So probably this is only a LyX bug. How can I debug this? 2/ There is an annoying behaviour of the LyX menus that mean that if you click on File, and then on Edit, the file menu will not close itself. The reason is the code in xpopup.c:is_on_title, which assumes that one has to click beyong the first 2 thirds of the menu (horizontally speaking) in order to get the menu to go away. I tried to remove this extra code, but all I get now is that menus are closed when one releases the mouse on the File menu (like macos used to do). I am not sure people will like this. Of course, none of these things are primordial for xforms 1.1. Anyway From Jean-Marc.Lasgouttes at inria.fr Fri May 7 16:05:02 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 7 09:05:07 2004 Subject: [XForms] One more piece of rpm magic needed In-Reply-To: <200405071351.44809.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 7 May 2004 13:51:44 +0100") References: <200405071204.59432.angus.leeming@btopenworld.com> <200405071351.44809.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Friday 07 May 2004 1:47 pm, Jean-Marc Lasgouttes wrote: >> >>>>> "Angus" == Angus Leeming >> >>>>> writes: >> Angus> So I guess one more piece of post install magic is needed. >> Angus> I guess it's as simple as sed Angus> "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" >> Except that you can't use a slash as sed delimiter here, of >> course. Angus> Ahhhh, but I can. Patch attached works perfectly. Indeed the Angus> above is the *best* way to do things IMO. Angus> (The identifying regex before the s/// block *must* be bounded Angus> by '/'. The s@@@ is find.) Hmm, OK, I give up you. You won this time, but beware of my next attempt... BTW, thanks for this flurry of activity on the xforms front. It seems that it is actually going to be released now :) JMarc From Todd.Denniston at ssa.crane.navy.mil Fri May 7 11:14:30 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Fri May 7 11:14:53 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system References: <200405071133.51019.angus.leeming@btopenworld.com> Message-ID: <409BA7D6.FDA153C2@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > On Friday 07 May 2004 10:53 am, Trent Piepho wrote: > > To subscribers of the xforms list > > > > On Fri, 7 May 2004, Angus Leeming wrote: > > > On Friday 07 May 2004 12:23 am, Todd Denniston wrote: > > > > unfortunately the archive does not go back to december of 1999 > > > > but the lestif guy's were having fun with the libtool versions > > > > too. > > > > I missed the beginning and point of this thread, but I'm going to > > go out on a limb and guess what you're trying to do. > > Thanks, Trent. Whilst I understand why you're doing what you're doing, > I'm going to try and stick with the libtool scheme. At least until > I've got a handle on lesstif's experience ;-) actually going back and reading the whole thread again[1] I believe they finally went with what libtool wanted for what was compiled, but had some softlinks setup. It erupted because they went to libtool 1.3.4 and it changed some things. Also part of their problem was that there are 2 version numbers for lestif, one describes the lestif release, and the other describes the M*tif version lestif is implementing. It was that libtool was not using the same M*tif version number on all platforms, specifically on Digital Unix libtool wanted to make it version 1.0.2 where it should be (and was on other platforms) 1.2.0 . Sorry if this has lead down a wrong path. Angus Leeming wrote: > > Interesting. However, could you help me out a little more? > Specifically, which files should I be looking at? the following have libtool mentioned in the comments. configure.in & *Makefile.am 2001-08-29 acconfig.h acinclude.m4 configure.in CVSMake 2000-08-22 configure.in 1999-10-23 07:15 [1] I have my personal copy of the lestif mailing list back to August 99, from which I sent Angus one of the messages that terminated the discussion on lestif. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From drriddle at mac.com Mon May 10 00:20:58 2004 From: drriddle at mac.com (drriddle@mac.com) Date: Mon May 10 00:21:09 2004 Subject: [XForms] xyplot patch, OS X compatibility Message-ID: <70579D31-A239-11D8-9713-003065E23D38@mac.com> Howdy all, A while ago, I put up a patch for the fl_replace_xyplot_point routine that would allow one to change the value of an overlay point (the current version only allows you to change the value of the main data plot point). Did that make it into the new version of the library? Also, you should be able to use the instructions at http://wet.physics.iastate.edu/Tools/xqed/index.html to compile Xforms under Mac OS X, version 10.3. I'll test that again once the new version of the library comes out, just to make sure it still works. That's also the page for the code I'm working on; if you're interested in downloading it and looking at the code, you may want to wait a few weeks. I should have a new version out by the end of the month, and it will be much improved (and the programming will suck much less ;) ). Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Homepage: http://wet.physics.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 angus.leeming at btopenworld.com Mon May 10 23:01:20 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 10 16:01:25 2004 Subject: [XForms] One more piece of rpm magic needed In-Reply-To: References: <200405071204.59432.angus.leeming@btopenworld.com> <200405071351.44809.angus.leeming@btopenworld.com> Message-ID: <200405102201.20053.angus.leeming@btopenworld.com> On Friday 07 May 2004 2:05 pm, Jean-Marc Lasgouttes wrote: > Angus> (The identifying regex before the s/// block *must* be > bounded Angus> by '/'. The s@@@ is find.) > > Hmm, OK, I give up you. You won this time, but beware of my next > attempt... I'm forever watchful ;-) > BTW, thanks for this flurry of activity on the xforms front. It > seems that it is actually going to be released now :) Yes, let's get this albatross off and flying. Angus From angus.leeming at btopenworld.com Mon May 10 23:05:30 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 10 16:05:34 2004 Subject: [XForms] [patch] sliders and counters In-Reply-To: References: <200405061816.21372.angus.leeming@btopenworld.com> Message-ID: <200405102205.30326.angus.leeming@btopenworld.com> On Friday 07 May 2004 1:59 pm, Jean-Marc Lasgouttes wrote: > Angus> What else is needed for the 1.1 release? > > I am currently trying to play around with xpopup.c to fix two > problems: [...snip...] > Of course, none of these things are primordial for xforms 1.1. Yes, I can certainly recreate each bug and I agree they're annoying. If you can find a fix soon, great, but let's keep up the momentum... Angus From angus.leeming at btopenworld.com Mon May 10 23:25:43 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 10 16:25:49 2004 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <409BA7D6.FDA153C2@ssa.crane.navy.mil> References: <200405071133.51019.angus.leeming@btopenworld.com> <409BA7D6.FDA153C2@ssa.crane.navy.mil> Message-ID: <200405102225.43844.angus.leeming@btopenworld.com> On Friday 07 May 2004 4:14 pm, Todd Denniston wrote: > actually going back and reading the whole thread again[1] I believe > they finally went with what libtool wanted for what was compiled, > but had some softlinks setup. It erupted because they went to > libtool 1.3.4 and it changed some things. > Also part of their problem was that there are 2 version numbers for > lestif, one describes the lestif release, and the other describes > the M*tif version lestif is implementing. It was that libtool was > not using the same M*tif version number on all platforms, > specifically on Digital Unix libtool wanted to make it version > 1.0.2 where it should be (and was on other platforms) 1.2.0 . > > Sorry if this has lead down a wrong path. Don't be. All information is good information. Thanks for taking the time to do this, Todd. > Angus Leeming wrote: > > Interesting. However, could you help me out a little more? > > Specifically, which files should I be looking at? > > the following have libtool mentioned in the comments. > configure.in & *Makefile.am 2001-08-29 > acconfig.h acinclude.m4 configure.in CVSMake 2000-08-22 > configure.in 1999-10-23 07:15 Great. I'll have a look over the next day or so. Angus From lab at saao.ac.za Tue May 11 10:32:32 2004 From: lab at saao.ac.za (Luis Balona) Date: Tue May 11 03:32:41 2004 Subject: [XForms] Crash in fl_check_forms In-Reply-To: <200405102225.43844.angus.leeming@btopenworld.com> Message-ID: We are using xforms-0.89 for a software project involving the South African Large Telescope. Since most of the telescope system is coded in LabView I needed to include a LabView shell which calls various C functions in a shared library. Much of the functionality in the C code resides in an image display and GUI built around xforms. I've had no problem at all until recently when I've been experiencing a segmentation fault soon after starting the program. This fault occurs at sporadic intervals, not always. I've tracked it down to a call to fl_check_forms. Somewhere in here it is referencing an illegal address. I know very little about XEvents. Can anyone offer some suggestions? Regards Luis ----------------------------------------------------------------------------- Dr Luis A Balona lab@saao.ac.za South African Astronomical Observatory Tel: 2721-447-0025 P O Box 9 Fax: 2721-447-3639 Observatory 7935 Cape Town South Africa ------------------------------------------------------------------------------ From angus.leeming at btopenworld.com Tue May 11 21:23:51 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 11 15:23:58 2004 Subject: [XForms] Crash in fl_check_forms In-Reply-To: References: Message-ID: <200405112023.51529.angus.leeming@btopenworld.com> I sent this privately to Luis by mistake, so to prevent anyone else spending precious time on it, am reposting it to the mailing list. Angus On Tuesday 11 May 2004 8:32 am, Luis Balona wrote: > I've had no problem at all until recently when I've been > experiencing a segmentation fault soon after starting the program. > This fault occurs at sporadic intervals, not always. I've tracked > it down to a call to fl_check_forms. Hello, Luis. fl_check_forms is just the public interface to the GUI library. The probelm could actually be occuring pretty well anywhere inside either xforms or your own code. Can you compile your executable with optimization turned off and debugging turned on and then run it within a debugger such as gdb: $ gdb your_app gdb> r when it crashes type 'bt' to obtain a full backtrace of the problem. That will help you pin down the problem far more precisely. > Somewhere in here it is > referencing an illegal address. I know very little about XEvents. > Can anyone offer some suggestions? HTH, but feel free to come back as often as it takes. If you're running on a PC using linux, then another *great* debugging tool is valgrind which will flag all illegal instructions for you. Angus From Jean-Marc.Lasgouttes at inria.fr Wed May 12 15:49:10 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed May 12 08:49:19 2004 Subject: [XForms] [PATCH] Re: Makefile problem in xforms-1.0.90.tar.gz In-Reply-To: <20040511173353.90B8D15C45@mendez.freesurf.fr> (Rod Curling-Hope's message of "Tue, 11 May 2004 19:33:53 +0200 (CEST)") References: <20040511173353.90B8D15C45@mendez.freesurf.fr> Message-ID: >>>>> "Rod" == Rod Curling-Hope writes: Rod> Thanks for Xforms. FYI When I ran configure in xforms-1.0.90, it Rod> did not include X_CFLAGS in COMPILE in the Makefiles created in Rod> the fd2ps and fdesign directories. I patched them in manually Rod> (yuk!!) just to get it compiled. Hello Rod, Thanks for noticing this. It is actually needed also in the gl and demos directories. I am going to apply the attached patch. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: xcflags.diff Type: text/x-patch Size: 2830 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040512/369b9a5a/xcflags.bin From dirk at CeBiTec.Uni-Bielefeld.DE Wed May 12 10:31:36 2004 From: dirk at CeBiTec.Uni-Bielefeld.DE (Dirk Evers) Date: Wed May 12 10:19:53 2004 Subject: [XForms] xforms on windows? Message-ID: <40A1D2D8.4000608@CeBiTec.Uni-Bielefeld.DE> This is probably documented somewhere... :-) Is there a version of xforms for windows? What do I need to use it? I know about fltk, but I would prefer not having to rewrite for it. Regards Dirk -- Dirk J. Evers dirk.evers@cebitec.uni-bielefeld.de NRW Graduate School in +49 (0)521/106-3793 Bioinformatics and Genome Research, CeBiTec - Center for Biotechnology University of Bielefeld, D-33594 Bielefeld, Germany From angus.leeming at btopenworld.com Thu May 13 19:00:07 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 13 13:02:19 2004 Subject: [XForms] [patch] fl_replace_xyplot_point_in_overlay Message-ID: <200405131800.07535.angus.leeming@btopenworld.com> I'm committing this now, so this is FYI. Attached is a patch from Reed. It generalizes the existing fl_replace_xyplot_point which acts only on the first dataset. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: xyplot.diff Type: text/x-diff Size: 2224 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040513/eb22f03c/xyplot.bin From angus.leeming at btopenworld.com Thu May 13 19:07:42 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 13 13:08:10 2004 Subject: [XForms] [patch] libtool version number Message-ID: <200405131807.42656.angus.leeming@btopenworld.com> Jean-Marc, would you prefer me to commit this patch now or only immediately before we release XForms 1.1 final? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: so_version.diff Type: text/x-diff Size: 1096 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040513/0d727541/so_version.bin From jac4 at mindless.com Thu May 13 18:21:06 2004 From: jac4 at mindless.com (jason cipriani) Date: Thu May 13 18:21:12 2004 Subject: [XForms] Patch: GLCanvas context sharing support. Message-ID: <20040513222106.E8E9079004B@ws1-14.us4.outblaze.com> This patch allows support for context sharing in GLCanvases, a feature which should have been in there long, long ago. Not tested because something about 1.0.90 seems to have broken the GLCanvas stuff entirely (as in, none of the GLCanvas functions are in forms.h any more). So I'll have to get to the bottom of that first. In the mean time, here is the patch (glcanvas.c/glcanvas.h), if anybody has a version of 1.0.90 with working GLCanvases. GLCanvases that share the same GLX Context will share GL call lists and (for GL version >= 1.1) textures. TODO: Add support to fdesign for using shared GLCanvases. --- orig/glcanvas.c 2004-05-13 17:43:51.000000000 -0400 +++ glcanvas.c 2004-05-13 17:57:37.000000000 -0400 @@ -38,6 +38,12 @@ * See ../DEMOS/gl.c for an example use of glcanvas. * See ../DEMOS/glwin.c for an example use of fl_glwinopen * + * 13-may-2004: jason cipriani (jac4@mindless.com): + * - added support for glx context sharing. + * - added the following functions: + * - fl_add_glcanvas_shared() + * - fl_create_glcanvas_shared() + * - fl_get_glcanvas_shared_context() */ #if defined(F_ID) || defined(DEBUG) @@ -59,6 +65,7 @@ { XVisualInfo *xvinfo; GLXContext context; + GLXContext context_shared; // Context to share data with. int direct; int glconfig[MAXATTRIB]; } @@ -91,7 +98,15 @@ fl_add_glcanvas(int type, FL_Coord x, FL_Coord y, FL_Coord w, FL_Coord h, const char *label) { - FL_OBJECT * ob = fl_create_glcanvas(type, x, y, w, h, label); + return fl_add_glcanvas_shared(type, x, y, w, h, label, NULL); +} + +FL_OBJECT * +fl_add_glcanvas_shared (int type, FL_Coord x, FL_Coord y, FL_Coord w, + FL_Coord h, const char *label, FL_OBJECT *shared_with) +{ + FL_OBJECT * ob = fl_create_glcanvas_shared(type, x, y, w, h, label, + shared_with); fl_add_object(fl_current_form, ob); return ob; } @@ -151,6 +166,12 @@ return GLPROP(ob)->context; } +GLXContext +fl_get_glcanvas_shared_context (FL_OBJECT *ob) +{ + return GLPROP(ob)->context_shared; +} + XVisualInfo * fl_get_glcanvas_xvisualinfo(FL_OBJECT * ob) { @@ -169,15 +190,38 @@ fl_create_glcanvas(int type, FL_Coord x, FL_Coord y, FL_Coord w, FL_Coord h, const char *label) { + return fl_create_glcanvas_shared(type, x, y, w, h, label, NULL); +} + +/* GLCanvas with context sharing. */ +FL_OBJECT * +fl_create_glcanvas_shared(int type, FL_Coord x, FL_Coord y, FL_Coord w, + FL_Coord h, const char *label, FL_OBJECT *shared_with) +{ FL_OBJECT *ob = fl_create_canvas(type, x, y, w, h, label); + GLXContext sctx; ob->objclass = FL_GLCANVAS; fl_modify_canvas_prop(ob, glx_init, glx_activate, glx_cleanup); + /* figure out glx context to share with. if shared_with is NULL or if it's + * not a GL canvas, then we can't do sharing. otherwise, the gl context to + * share with is chosen as follows: + * - if shared_with is also sharing data with another glx context, use + * the glx context shared_with is sharing data with, otherwise... + * - use shared_with's actual glx context. + */ + if (shared_with && shared_with->objclass == FL_GLCANVAS) { + if (!(sctx = fl_get_glcanvas_shared_context(shared_with))) + sctx = fl_get_glcanvas_context(shared_with); + } else + sctx = NULL; + /* initialize glcanvas specific stuff */ ob->c_vdata = fl_calloc(1, sizeof(CSPEC)); memcpy(GLPROP(ob)->glconfig, glconfig, sizeof(glconfig)); GLPROP(ob)->direct = GL_TRUE; + GLPROP(ob)->context_shared = sctx; return ob; } @@ -208,7 +252,8 @@ fl_set_canvas_depth(ob, vi->depth); fl_set_canvas_colormap(ob, fl_create_colormap(vi, 1)); - context = glXCreateContext(fl_display, vi, None, GLPROP(ob)->direct); + context = glXCreateContext(fl_display, vi, GLPROP(ob)->context_shared, + GLPROP(ob)->direct); if (!context) { --- orig/glcanvas.h 2004-05-13 17:43:51.000000000 -0400 +++ glcanvas.h 2004-05-13 17:46:55.000000000 -0400 @@ -11,6 +11,15 @@ const char *label ); +FL_EXPORT FL_OBJECT *fl_create_glcanvas_shared ( + int type, + FL_Coord x, + FL_Coord y, + FL_Coord w, + FL_Coord h, + const char *label, + FL_OBJECT *shared_with + ); FL_EXPORT FL_OBJECT *fl_add_glcanvas( int type, @@ -21,6 +30,16 @@ const char *label ); +FL_EXPORT FL_OBJECT *fl_add_glcanvas_shared ( + int type, + FL_Coord x, + FL_Coord y, + FL_Coord w, + FL_Coord h, + const char *label, + FL_OBJECT *shared_with + ); + FL_EXPORT void fl_set_glcanvas_defaults( const int *config @@ -58,6 +77,10 @@ FL_OBJECT *ob ); +FL_EXPORT GLXContext fl_get_glcanvas_shared_context ( + FL_OBJECT *ob + ); + FL_EXPORT Window fl_glwincreate( int *config, GLXContext *context, -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: glcanvas.diff.tgz Type: application/octet-stream Size: 2058 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040513/ccec6cc0/glcanvas.diff.obj From angus.leeming at btopenworld.com Fri May 14 10:30:05 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 14 04:30:28 2004 Subject: [XForms] Patch: GLCanvas context sharing support. In-Reply-To: <20040513222106.E8E9079004B@ws1-14.us4.outblaze.com> References: <20040513222106.E8E9079004B@ws1-14.us4.outblaze.com> Message-ID: <200405140930.05519.angus.leeming@btopenworld.com> On Thursday 13 May 2004 11:21 pm, jason cipriani wrote: > This patch allows support for context sharing in GLCanvases, a > feature which should have been in there long, long ago. Not tested > because something about 1.0.90 seems to have broken the GLCanvas > stuff entirely (as in, none of the GLCanvas functions are in > forms.h any more). So I'll have to get to the bottom of that first. > In the mean time, here is the patch (glcanvas.c/glcanvas.h), if > anybody has a version of 1.0.90 with working GLCanvases. Jason, all the GL stuff was moved into its own directory/libraryheader file for the 1.0 release. Find it in the gl directory. 'make install' will lead to these files being installed: fd2ps fdesign flimage.h forms.h glcanvas.h libflimage.a libforms.a libformsGL.a libflimage.so libforms.so libformsGL.so Angus From Jean-Marc.Lasgouttes at inria.fr Fri May 14 16:05:24 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 14 09:05:34 2004 Subject: [XForms] [patch] libtool version number In-Reply-To: <200405131807.42656.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 13 May 2004 18:07:42 +0100") References: <200405131807.42656.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, Angus> would you prefer me to commit this patch now or only Angus> immediately before we release XForms 1.1 final? We can maybe wait, but I am not sure that it matters :) JMarc From angus.leeming at btopenworld.com Fri May 14 15:46:37 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 14 09:46:42 2004 Subject: [XForms] [patch] libtool version number In-Reply-To: References: <200405131807.42656.angus.leeming@btopenworld.com> Message-ID: <200405141446.37277.angus.leeming@btopenworld.com> On Friday 14 May 2004 2:05 pm, Jean-Marc Lasgouttes wrote: > Angus> would you prefer me to commit this patch now or only > Angus> immediately before we release XForms 1.1 final? > > We can maybe wait, but I am not sure that it matters :) Given our huge user base you mean? I think that we're about ready for another pre-release, don't you? The only stuff I have listed as pending are in the hands of the three Js: Jason Cipriani: some feedback on whether the GLCanvas stuff works with version 1.0.90. If he can confirm that his patch implementing context sharing in GLCanvases works, then I'm happy to shove it in. (It being stuff about which I am entirely ignorant.) Jeff Pierce: apparently has a patch to add FL_CLIENT_CALLBACK, fl_register_client_callback. Don't know if he wants this in XForms 1.1, but he should get a shifty on if he does ;-) Jean-Marc Lasgouttes: some meddlings with the popup code. What's the story with the documentation? Angus From jac4 at mindless.com Fri May 14 11:45:41 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri May 14 12:05:19 2004 Subject: [XForms] Patch: GLCanvas context sharing support. Message-ID: <20040514154541.9FE3A79004B@ws1-14.us4.outblaze.com> The patch needs a bit of work anyway, I shouldn't have submitted it without testing it. Primary issue being the fact that it needs a GLXContext to share with, which isn't created until the canvas is about to be shown, so it will work fine if you created a shared canvas after the form is shown but that doesn't lend itself well to fdesign. I have another method that works just fine but I have a question about this part of glx_init() in glcanvas.c: /* under some conditions, the parent of the gl canvas might go away, leaving the old context and vi hanging. */ glx_cleanup(ob); What conditions are "some conditions"? What I am doing now is keeping the FL_OBJECT* for the glcanvas you want to share a context with in the glcanvas's CSPEC. Then, in glx_init(), it checks to see if that glcanvas has a GLXContext yet. If it doesn't, then it forces initialization of that canvas. That's fine but what that means is that if "some conditions" are true and also if the shared canvas is created -before- the canvas it's sharing context data with, then the shared canvas's glx_init() won't attempt to initialize the canvas its sharing data with (since it's GLXContext isn't 0), so it will use it's GLXContext. But then when the canvas its sharing data with is initialized (and some conditions are true), then its context will be destroyed and a new one will be creating, invalidating the GLXContext that the shared canvas is sharing data with. So I need to figure out a way to ensure that the canvas its sharing data with is properly initialized first, rather than it just having some leftover old GLXContext associated with it because "the parent of the gl canvas [went] away". As far as the GL stuff, the problem was that this was removed from forms.h in 1.0.90 (it was there in 1.0): #if defined(__GLX_glx_h__) || defined(GLX_H) #include #endif Simple solution was to add it back in, rather than #include'ing glcanvas.h in all the xforms apps we have. Jason ----- Original Message ----- From: Angus Leeming Date: Fri, 14 May 2004 09:30:05 +0100 To: xforms Subject: Re: [XForms] Patch: GLCanvas context sharing support. > On Thursday 13 May 2004 11:21 pm, jason cipriani wrote: > > This patch allows support for context sharing in GLCanvases, a > > feature which should have been in there long, long ago. Not tested > > because something about 1.0.90 seems to have broken the GLCanvas > > stuff entirely (as in, none of the GLCanvas functions are in > > forms.h any more). So I'll have to get to the bottom of that first. > > In the mean time, here is the patch (glcanvas.c/glcanvas.h), if > > anybody has a version of 1.0.90 with working GLCanvases. > > Jason, all the GL stuff was moved into its own directory/libraryheader > file for the 1.0 release. Find it in the gl directory. > > 'make install' will lead to these files being installed: > > fd2ps fdesign > flimage.h forms.h glcanvas.h > libflimage.a libforms.a libformsGL.a > libflimage.so libforms.so libformsGL.so > > Angus > > -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Fri May 14 18:16:15 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 14 12:16:21 2004 Subject: [XForms] Patch: GLCanvas context sharing support. In-Reply-To: <20040514153007.089AE79004B@ws1-14.us4.outblaze.com> References: <20040514153007.089AE79004B@ws1-14.us4.outblaze.com> Message-ID: <200405141716.15416.angus.leeming@btopenworld.com> On Friday 14 May 2004 4:30 pm, jason cipriani wrote: > /* under some conditions, the parent of the gl canvas might go > away, leaving the old context and vi hanging. */ > glx_cleanup(ob); > > What conditions are "some conditions"? Ha! I have no idea. My knowledge of this part of the code base is nil. > What I am doing now is keeping the FL_OBJECT* for the glcanvas you > want to share a context with in the glcanvas's CSPEC. Then, in > glx_init(), it checks to see if that glcanvas has a GLXContext yet. > If it doesn't, then it forces initialization of that canvas. That's > fine but what that means is that if "some conditions" are true and > also if the shared canvas is created -before- the canvas it's > sharing context data with, then the shared canvas's glx_init() > won't attempt to initialize the canvas its sharing data with (since > it's GLXContext isn't 0), so it will use it's GLXContext. But then > when the canvas its sharing data with is initialized (and some > conditions are true), then its context will be destroyed and a new > one will be creating, invalidating the GLXContext that the shared > canvas is sharing data with. Phew. 2 sentences covering 10 lines. I keep forgetting the start before I get to the end ;-) > So I need to figure out a way to ensure that the canvas its sharing > data with is properly initialized first, rather than it just having > some leftover old GLXContext associated with it because "the parent > of the gl canvas [went] away". The parent of the gl canvas is the Window on which the FL_FORM and FL_OBJECT are displayed, right? Or is it the FL_FORM itself? If the former, could you not use (form->window == GLPROP(ob)->window) as a check. You'd need to add a new variable, window, to CSPEC but so what? Or have I got all this wrong? > As far as the GL stuff, the problem was that this was removed from > forms.h in 1.0.90 (it was there in 1.0): > > #if defined(__GLX_glx_h__) || defined(GLX_H) > #include > #endif > > Simple solution was to add it back in, rather than #include'ing > glcanvas.h in all the xforms apps we have. Ahhhhhh. So you'd like forms.h to #include glcanvas.h if a preprocessor guard is defined. What defines __GLX_glx_h__, GLX_H? I don't think that the preprocessor guard should be a system or compiler-defined macro. You should have to define it explicitly. Eg #ifdef FORM_GLCANVAS_H #include FORM_GLCANVAS_H #endif where FORM_GLCANVAS_H is defined either in your file for the project or is passed via a -D flag on the compiler command. Angus k From davidwriter at yahoo.com Fri May 14 15:33:57 2004 From: davidwriter at yahoo.com (David Scriven) Date: Fri May 14 14:34:01 2004 Subject: [XForms] Patch: GLCanvas context sharing support. In-Reply-To: <20040514154541.9FE3A79004B@ws1-14.us4.outblaze.com> Message-ID: <20040514183357.23666.qmail@web60310.mail.yahoo.com> Jason, Maybe I'm being slow, but I don't see why we need this patch - can you give an example of how you would use it. One can obtain the context of a canvas after you create it: .... fl_add_glcanvas.... ... fl_initialize ... GLXContext CanvasContext = NULL; CanvasContext = fl_get_glcanvas_context(form->canvas); if(CanvasContext == NULL) { ....aaargh - disaster ! } and use it in calls to glXCopyContext. > As far as the GL stuff, the problem was that this was removed from > forms.h in 1.0.90 (it was there in 1.0): > > #if defined(__GLX_glx_h__) || defined(GLX_H) > #include > #endif > This definition doesn't always work - for example NVIDIA defines its glx.h file differently, so you have to have #if defined(__GLX_glx_h__) || defined(GLX_H) || defined(__glx_h__) for glcanvas to work. Clearly not a good thing if we have to alter the test to cover all the internal structures of various vendor's glx.h files. DS ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From jac4 at mindless.com Fri May 14 15:31:01 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri May 14 15:33:49 2004 Subject: [XForms] Patch: GLCanvas context sharing support. Message-ID: <20040514193101.62E0E79004B@ws1-14.us4.outblaze.com> > Jason, Maybe I'm being slow, but I don't see why we need > this patch - can you give an example of how you would > use it. AGL, GLX, and wGL all support GL context sharing. When two GL contexts are shared, what this means is that they share the same call list and (for GL >= 1.1) texturing namespaces. So, if you have a form with 4 GL canvases on it, the way it is now, and you want to display the same, say, 60K+ polygon surface model on all 4 canvases, you need to create 4 separate call lists. So you need to store the same call list in memory 4 times, and you need to take the time to generate 4 identical call lists. And if you have the same texture that you want to display on all 4 canvases, you have to load the same texture 4 times. Same deal. For example (as far as texturing goes), if you wanted to display captured video on a surface, you may choose to copy the captured image to texture mapped memory to update that texture and display the video. Your frame rate -will- suffer if you have to load the same image into memory 4 times simply because you have 4 separate GL canvases. Also, in applications with huge amounts of textures, memory -does- become an issue when you have to load the same textures into memory 2, 3, or more times. Context sharing, as far as XForms goes, allows you to use the same call lists and textures for multiple GL canvases. When you think about the impact this has on the amount of memory your application uses and the amount of time you have to spend processing call lists and textures, the benefits are clear. As a matter of fact, GLX makes it simple to share contexts: the glXCreateContext function can actually take, as a parameter, another context which you want to share data with. Problem is, of course, the XForms GL canvas doesn't provide a way for you to specify a context to share data with. Also note that you can't begin sharing contexts after both contexts are created. You have to specify the context to share data with at the time you create a new context, so it's not something that you can do with GLX calls after you have already created and displayed the GL canvases. glXCopyContext will create a copy of the context but the new context will not share the same call list and texture namespace as the one it was copied from, and you cannot specify a context to share data with in the glXCopyContext call. It -must- be done in the glXCreateContext call. Even if glXCopyContext did work, there currently exists no clean way to change the GLXContext of a GL canvas, as far as I know, although you can "change" it by directly modifying the data in the GL canvases CSPEC. > This definition doesn't always work - for example NVIDIA > defines its glx.h file differently, so you have to have > ... > for glcanvas to work. Clearly not a good thing if we have to > alter the test to cover all the internal structures of various > vendor's glx.h files. Absolutely true. We use nVidia cards here and when we set up a new machine with XForms 1.0 we have to go modify forms.h to check for nVidia's glx.h defines. Dirty but, that's the way it was done, and now we have a whole bunch of apps that don't explicitly #include glcanvas.h. Angus wrote: > #ifdef FORM_GLCANVAS_H > #include FORM_GLCANVAS_H > #endif > > where FORM_GLCANVAS_H is defined either in your file for > the project or is passed via a -D flag on the compiler command. Which is a much better way to do it, and I think that forms.h should have that in it in the next release. What I wrote was a quick fix and actually what I am doing now is using a modified forms.h that just includes and then includes without checking for anything. Dirty but it works on my machine. Angus' way allows the least breaking of existing apps (in my case, I have some common make include files for everything so adding a -DFORM_GLCANVAS_H is trivial) while at the same time not relying on vendor-specific #defines in glx.h. Hope that makes sense, Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Fri May 14 23:23:22 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 14 17:27:38 2004 Subject: [XForms] Patch: GLCanvas context sharing support. In-Reply-To: <20040514193101.62E0E79004B@ws1-14.us4.outblaze.com> References: <20040514193101.62E0E79004B@ws1-14.us4.outblaze.com> Message-ID: <200405142223.22018.angus.leeming@btopenworld.com> On Friday 14 May 2004 8:31 pm, jason cipriani wrote: > Angus wrote: > > #ifdef FORM_GLCANVAS_H > > #include FORM_GLCANVAS_H > > #endif > > > > where FORM_GLCANVAS_H is defined either in your file > > for the project or is passed via a -D flag on the compiler > > command. > > Which is a much better way to do it, and I think that forms.h > should have that in it in the next release. Ok, Jason. I've just committed the attached patch. You'll need to alter your project code so that a config.h file contains the magical #define GLCANVAS_H_LOCATION or alternatively pass the macro to your compiler directly. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: canvas.diff Type: text/x-diff Size: 1383 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040514/7a28d034/canvas.bin From jac4 at mindless.com Sun May 16 05:04:49 2004 From: jac4 at mindless.com (jason cipriani) Date: Sun May 16 05:04:57 2004 Subject: [XForms] Adding source files to fdesign. Message-ID: <20040516090449.92E90101C3@ws1-16.us4.outblaze.com> Ok. I've been struggling with this for a while now. I'm a bit lost when it comes to all this 'configure' stuff and, building Makefiles from other makefiles from other makefiles, and that kind of stuff. Could somebody please explain to me how to add a source file to the fdesign/spec directory, and actually get it to compile? I've got a working GLX context sharing patch, it's great. Adding fdesign support for it... that seems to be the hard part. Here is what I have done as far as fdesign source files go: 1) Added fdesign/sp_glcanvas.c (and fdesign/.deps/sp_glcanvas.Po), it compiles, just fine. 2) Added fdesign/spec/glcanvas_spec.fd/.c/.h. And I can't, for the life of me, convince make to compile glcanvas_spec.c. (Just to make it clear, the problem is that the source file isn't compiling at all; it's not a problem with actual compiler/linker errors aside from the obvious linker errors from undefined references to functions in that source file). I pretty much copied all the freeobj stuff, since that seemed to be the simplest. Still, I can't figure this out. Call me stupid. Thanks, Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jac4 at mindless.com Sun May 16 17:57:50 2004 From: jac4 at mindless.com (jason cipriani) Date: Sun May 16 17:57:56 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) Message-ID: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> Ok, here it is. Tested on Mac OS X and Linux-testing coming on Monday. It's a rather large patch. The attached file contains patch.diff, sglcanvas.html (which somewhat resembles documentation), and a test program (which isn't worked into the demo folder, and the Makefile might require some tweaking to compile). This patch adds support for GLX context sharing in gl canvases, and also gives fdesign the ability to set up canvas sharing via the Spec tab in the glcanvas attribute editor. Turns out the GLCANVAS_H_LOCATION thing is still inadequate, mostly because if GLCANVAS_H_LOCATION is defined, forms.h includes glcanvas.h. There are some functions in glcanvas.h that use the GLXContext type, declared in GL/glx.h. So fdesign generated source files that include forms.h also include glcanvas.h and the compiler breaks because GL/glx.h wasn't included in the fdesign source files. So how about this, it seems to work fine: Instead of GLCANVAS_H_LOCATION, use GLX_H_LOCATION. If GLX_H_LOCATION is defined, then canvas.h can #include both GLX_H_LOCATION and . That should fix it. Just compile source with -DGLX_H_LOCATION="" or something, and glcanvas.h is automatically included after GL/glx.h is. If you are using gl canvases then indirectly including GL/glx.h from forms.h is not going to hurt anything. If you aren't using gl canvases then just don't defined GLX_H_LOCATION and everything remains the same. For now I am #including GL/glx.h directly from glcanvas.h. It's in the patch but I'm not happy with it, so remember to take it out if you decide on another way. You may have to fiddle with the "demo" program Makefile to get it to compile. I didn't work it into /demos. If anybody wants to try this patch now (it requires Angus' GLCANVAS_H_LOCATION thing too) for some reason: 1) Download fresh copy of xforms-1.0.90, and download attached patch. 2) Before ./configure, head to the xforms-1.0.90 root and do "patch -p1 patch.diff". 3) Build as usual. Detailed changes (some fdesign files are new): gl/glcanvas.c - Added functions to support creation of shared canvases and canvas pools. gl/glcanvas.h - #include "GL/glx.h" - FL_SGLPOOL - fl_activate_named_sglpool() - fl_activate_sglpool() - fl_add_shared_glcanvas() - fl_create_shared_glcanvas() - fl_get_glcanvas_sglpool() - fl_get_max_sglpools() - fl_get_named_sglpool() - fl_get_num_sglpools() - fl_get_sglpool_name() - fl_set_glcanvas_pool_name() - fl_set_max_sglpools() fdesign/Makefile.am - Compile sp_glcanvas.c. fdesign/Makefile.in - Compile sp_glcanvas.c fdesign/fd_main.h - Added 'shared' and 'poolname' to SuperSPEC. fdesign/fd_spec.c - Added attrib callbacks for FL_GLCANVAS. - Read "shared" and "poolname" from .fd files into SuperSPEC. fdesign/fd_spec.h - Prototypes for sp_glcanvas.c functions. fdesign/sp_glcanvas.c (new file) - This file handles spec attributes for FL_GLCANVAS. - emit_glcanvas_code() - get_glcanvas_spec_fdform() - glcanvas_spec_restore() - save_glcanvas_attrib() - set_glcanvas_attrib() fdesign/spec/Makefile.am - glcanvas_spec.c - glcanvas_spec.fd - glcanvas_spec.h fdesign/spec/Makefile.in - glcanvas_spec.c - glcanvas_spec.fd - glcanvas_spec.h fdesign/spec/glcanvas_spec.c (new file) - Source code for glcanvas spec form. fdesign/spec/glcanvas_spec.fd (new file) - FD file for glcanvas spec form. fdesign/spec/glcanvas_spec.h (new file) - Header for glcanvas spec form. Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.tgz Type: application/octet-stream Size: 24901 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040516/25fde4c0/patch.obj From angus.leeming at btopenworld.com Mon May 17 09:24:07 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 03:24:09 2004 Subject: [XForms] Adding source files to fdesign. In-Reply-To: <20040516090449.92E90101C3@ws1-16.us4.outblaze.com> References: <20040516090449.92E90101C3@ws1-16.us4.outblaze.com> Message-ID: <200405170824.07650.angus.leeming@btopenworld.com> On Sunday 16 May 2004 10:04 am, jason cipriani wrote: > To subscribers of the xforms list > > > Ok. I've been struggling with this for a while now. I'm a bit lost > when it comes to all this 'configure' stuff and, building Makefiles > from other makefiles from other makefiles, and that kind of stuff. > Could somebody please explain to me how to add a source file to the > fdesign/spec directory, and actually get it to compile? Ok. We don't actually compile anything in this directory, for reasons of historical laziness. Instead, what has happened is that we #include both the .h and the .c file in the 'parent' file in the fdesign directory. See, eg, sp_xyplot.c: sp_xyplot.c:#include "spec/xyplot_spec.h" sp_xyplot.c:#include "spec/xyplot_spec.c" You should add your files to the EXTRA_DIST target in fdesign/spec/Makefile.am to ensure that they are distributed when the library is packaged as a tar file. > I've got a working GLX context sharing patch, it's great. Well done. > Adding fdesign support for it... that seems to be the hard part. > Here is what I have done as far as fdesign source files go: > > 1) Added fdesign/sp_glcanvas.c (and fdesign/.deps/sp_glcanvas.Po), > it compiles, just fine. Good. You've modified the generated Makefile it would appear. No problem, I can easily move this to Makefile.am. > Added fdesign/spec/glcanvas_spec.fd/.c/.h. And I can't, for > the life of me, convince make to compile glcanvas_spec.c. See above. > (Just to make it clear, the problem is that the source file isn't > compiling at all; it's not a problem with actual compiler/linker > errors aside from the obvious linker errors from undefined > references to functions in that source file). > > I pretty much copied all the freeobj stuff, since that seemed to be > the simplest. Still, I can't figure this out. Call me stupid. Not today ;-) Angus > Thanks, > Jason From angus.leeming at btopenworld.com Mon May 17 10:42:47 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 04:43:13 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> Message-ID: <200405170942.47719.angus.leeming@btopenworld.com> On Sunday 16 May 2004 10:57 pm, jason cipriani wrote: > Ok, here it is. Tested on Mac OS X and Linux-testing coming on > Monday. It's a rather large patch. The attached file contains > patch.diff, sglcanvas.html (which somewhat resembles > documentation), and a test program (which isn't worked into the > demo folder, and the Makefile might require some tweaking to > compile). This patch adds support for GLX context sharing in gl > canvases, and also gives fdesign the ability to set up canvas > sharing via the Spec tab in the glcanvas attribute editor. Woooo! Jason, I think that we should hold off on this until after XForms 1.1 is out of the door. It's big, big, big and we're very close to a release. However, I think we should resolve the GLCANVAS_H problem now. I think that header files should be self-contained. Ie #include "foo.h" int main() { return 0; } should compile. If it doesn't, then that's a problem. As you say, glcanvas.h contains code like: FL_EXPORT GLXContext fl_get_glcanvas_context(FL_OBJECT *ob); As we can't forward-declare GLXContext, the only permissible solution is to #include in glcanvas.h. Thereafter, things should "just work" with my GLCANVAS_H_LOCATION patch. Comments? Angus From angus.leeming at btopenworld.com Mon May 17 11:27:08 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 05:29:13 2004 Subject: [XForms] [patch] self-contained glcanvas.h Message-ID: <200405171027.08559.angus.leeming@btopenworld.com> Attached is a patch that allows #include "glcanvas.h" int main() { return 0; } to compile. However, I'm not entirely happy with it. The line #include "forms.h" pre-supposes forms.h is in a directory that is searched directly by the compiler. Is this a valid assumption? I seem to remember that forms.h is sometimes #included as , but this may be in older versions of the XForms library. Jean-Marc, all? Any advice? Angus ps, it appears that something similar is needed for flimage.h, but let's sort out one thing at a time. A -------------- next part -------------- A non-text attachment was scrubbed... Name: glcanvas.diff Type: text/x-diff Size: 668 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040517/8d792ade/glcanvas.bin From Jean-Marc.Lasgouttes at inria.fr Mon May 17 12:34:02 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon May 17 05:34:07 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <200405170942.47719.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 09:42:47 +0100") References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405170942.47719.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> However, I think we should resolve the GLCANVAS_H problem now. Angus> I think that header files should be self-contained. Ie #include Angus> "foo.h" int main() { return 0; } should compile. If it doesn't, Angus> then that's a problem. Angus> As you say, glcanvas.h contains code like: FL_EXPORT GLXContext Angus> fl_get_glcanvas_context(FL_OBJECT *ob); As we can't Angus> forward-declare GLXContext, the only permissible solution is to Angus> #include in glcanvas.h. Angus> Thereafter, things should "just work" with my Angus> GLCANVAS_H_LOCATION patch. Angus, I tried to read the thread about this header problem, but I do not really understand what the issue is. Could you explain it to me? JMarc From angus.leeming at btopenworld.com Mon May 17 11:47:39 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 05:48:08 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405170942.47719.angus.leeming@btopenworld.com> Message-ID: <200405171047.39127.angus.leeming@btopenworld.com> On Monday 17 May 2004 10:34 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> However, I think we should resolve the GLCANVAS_H problem > now. > > Angus> I think that header files should be self-contained. Ie > #include Angus> "foo.h" int main() { return 0; } should compile. If > it doesn't, Angus> then that's a problem. > > Angus> As you say, glcanvas.h contains code like: FL_EXPORT > GLXContext Angus> fl_get_glcanvas_context(FL_OBJECT *ob); As we > can't Angus> forward-declare GLXContext, the only permissible > solution is to Angus> #include in glcanvas.h. > > Angus> Thereafter, things should "just work" with my > Angus> GLCANVAS_H_LOCATION patch. > > Angus, I tried to read the thread about this header problem, but I > do not really understand what the issue is. Could you explain it to > me? Yes. forms.h is built automatically from the header files in lib/include. One of these, canvas.h, used to #include glcanvas.h with the block: #if defined(__GLX_glx_h__) || defined(GLX_H) #include #endif This got removed (13 months ago, by me) because glcanvas.h is now part of a separate library, it doesn't get installed in the X11 directory, the guard was crappy and liable to break etc, etc. Unfortunately, doing so breaks Jason's codes. So my solution is to add the #include back in, but in a more explicit manner: #ifdef GLCANVAS_H_LOCATION #include GLCANVAS_H_LOCATION #endif That seems like a reasonable compromise, don't you think? This is all separate to the 'glcanvas.h should be self-contained' problem. Angus From Jean-Marc.Lasgouttes at inria.fr Mon May 17 13:14:42 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon May 17 06:14:48 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <200405171047.39127.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 10:47:39 +0100") References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405170942.47719.angus.leeming@btopenworld.com> <200405171047.39127.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> forms.h is built automatically from the header files in Angus> lib/include. Yes. Angus> One of these, canvas.h, used to #include glcanvas.h with the Angus> block: Angus> #if defined(__GLX_glx_h__) || defined(GLX_H) #include Angus> #endif Angus> This got removed (13 months ago, by me) because glcanvas.h is Angus> now part of a separate library, it doesn't get installed in the Angus> X11 directory, the guard was crappy and liable to break etc, Angus> etc. Yes. Angus> Unfortunately, doing so breaks Jason's codes. So my solution is Angus> to add the #include back in, but in a more explicit manner: Angus> #ifdef GLCANVAS_H_LOCATION #include GLCANVAS_H_LOCATION #endif There are two separate issues: 1/ the easiest one: we need the xxx_LOCATION nonsense because imake-based build systems tend to put header files in places like X11/forms.h. This is not the case anymore, so we should assume now that header files have to be on the search path. Thus a #include "glcanvas.h" should be enough. 2/ the problem of including glcanvas.h: If we are serious about separating the gl stuff from the rest, we want people to be able to use forms.h without any gl stuff installed. I would prefer to make people include "glcanvas.h" manually, but I agree that we can have a backdoor for people who do not want to change their code. In this case, we should probably rely on a HAVE_GLCANVAS_H define, which is straightforward to define through autoconf, and add code like #ifdef HAVE_GLCANVAS_H #include "glcanvas.h" #endif However, I think that we should not make this way the preferred way, because it is a bit unnatural to my eyes. Do you think it would work correctly? Angus> This is all separate to the 'glcanvas.h should be Angus> self-contained' problem. Concerning this later problem, I am not sure we want to enforce it. Asking people to include forms.h seems rather reasonable to me. JMarc From angus.leeming at btopenworld.com Mon May 17 12:27:29 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 06:30:18 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405171047.39127.angus.leeming@btopenworld.com> Message-ID: <200405171127.29447.angus.leeming@btopenworld.com> On Monday 17 May 2004 11:14 am, Jean-Marc Lasgouttes wrote: > Angus> #ifdef GLCANVAS_H_LOCATION #include GLCANVAS_H_LOCATION > #endif > > There are two separate issues: > > 1/ the easiest one: we need the xxx_LOCATION nonsense because > imake-based build systems tend to put header files in places like > X11/forms.h. This is not the case anymore, so we should assume now > that header files have to be on the search path. Thus a #include > "glcanvas.h" should be enough. Yes. > 2/ the problem of including glcanvas.h: If we are serious about > separating the gl stuff from the rest, we want people to be able to > use forms.h without any gl stuff installed. I would prefer to make > people include "glcanvas.h" manually, but I agree that we can have > a backdoor for people who do not want to change their code. In this > case, we should probably rely on a HAVE_GLCANVAS_H define, which is > straightforward to define through autoconf, and add code like > #ifdef HAVE_GLCANVAS_H > #include "glcanvas.h" > #endif Yes. > However, I think that we should not make this way the preferred > way, because it is a bit unnatural to my eyes. Agreed. This solution provides a means for people to continue to compile existing code. It's not nice and shouldn't be on by default. > Do you think it would work correctly? Yes. However, I don't think we should add HAVE_GLCANVAS_H to *our* autoconf files. This 'nonsense' is for whatever configure-magic the *user* uses to compile his code. All *we* need to do is to provide the pre-processor handle. Why not be explicit and define INCLUDE_GLCANVAS_H_FROM_CANVAS_H ? I think that being verbose here is a good thing. > Angus> This is all separate to the 'glcanvas.h should be > Angus> self-contained' problem. > > Concerning this later problem, I am not sure we want to enforce it. > Asking people to include forms.h seems rather reasonable to me. But it's inelegant! Anyway, the #include and the C++ guards are definitely needed IMO. Agree? Angus From Jean-Marc.Lasgouttes at inria.fr Mon May 17 13:50:48 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon May 17 06:50:54 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <200405171127.29447.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 11:27:29 +0100") References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405171047.39127.angus.leeming@btopenworld.com> <200405171127.29447.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> Do you think it would work correctly? Angus> Yes. However, I don't think we should add HAVE_GLCANVAS_H to Angus> *our* autoconf files. Did I say something like that? It would not make much sense, actually. Angus> This 'nonsense' is for whatever configure-magic the *user* uses Angus> to compile his code. All *we* need to do is to provide the Angus> pre-processor handle. Why not be explicit and define Angus> INCLUDE_GLCANVAS_H_FROM_CANVAS_H ? I think that being verbose Angus> here is a good thing. OK, you are probaly right, although the define should be INCLUDE_GLCANVAS_H_FROM_FORMS_H or maybe the slightly shorter AUTOINCLUDE_GLCANVAS_H. Angus> This is all separate to the 'glcanvas.h should be Angus> self-contained' problem. >> Concerning this later problem, I am not sure we want to enforce >> it. Asking people to include forms.h seems rather reasonable to me. Angus> But it's inelegant! Angus> Anyway, the #include and the C++ guards are Angus> definitely needed IMO. Agree? Yes. OK, it probably does not hurt to make it self contained, but I think it encourages sloppiness, since glcanvas.h is such a tiny portion of the forms api. I do not see anybody wanting to use _only_ glcanvas-related API in a program. I think people should include headers for the API that they explicitly use. JMarc From angus.leeming at btopenworld.com Mon May 17 13:01:14 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 07:01:48 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405171127.29447.angus.leeming@btopenworld.com> Message-ID: <200405171201.14904.angus.leeming@btopenworld.com> On Monday 17 May 2004 11:50 am, Jean-Marc Lasgouttes wrote: > OK, you are probaly right, although the define should be > INCLUDE_GLCANVAS_H_FROM_FORMS_H or maybe the slightly shorter > AUTOINCLUDE_GLCANVAS_H. I'll do this. > OK, it probably does not hurt to make it self contained, but I > think it encourages sloppiness, since glcanvas.h is such a tiny > portion of the forms api. I do not see anybody wanting to use > _only_ > glcanvas-related API in a program. I think people should include > headers for the API that they explicitly use. Ok, I'll throw out this suggestion for now. Patch attached. Are you happy for me to commit this? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-diff Size: 1947 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040517/4d46ac47/patch.bin From Jean-Marc.Lasgouttes at inria.fr Mon May 17 14:06:36 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon May 17 07:06:41 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <200405171201.14904.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 12:01:14 +0100") References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405171127.29447.angus.leeming@btopenworld.com> <200405171201.14904.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Patch attached. Are you happy for me to commit this? Angus Definitely. JMarc From Jean-Marc.Lasgouttes at inria.fr Mon May 17 14:10:44 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon May 17 07:10:49 2004 Subject: [XForms] [patch] libtool version number In-Reply-To: <200405141446.37277.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 14 May 2004 14:46:37 +0100") References: <200405131807.42656.angus.leeming@btopenworld.com> <200405141446.37277.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> We can maybe wait, but I am not sure that it matters :) Angus> Given our huge user base you mean? Especially the huge use base of xforms cvs. Angus> I think that we're about ready for another pre-release, don't Angus> you? That would be nice. Angus> Jean-Marc Lasgouttes: some meddlings with the popup code. I have given up for now. I suspect that the bad redrawing of menus in LyX are a LyX bug, since the popup demos do the redraw correctly. Angus> What's the story with the documentation? The story is that we still do not have anything. What would be very nice of us in this respect is to write down note about what has changed since the 0.89.6 release: how to use xforms (what headers what libraries), what new api exists, etc. Do you think we could do that? I do not think that there is a lot to write down. An of course we should try to get the real thing from TC. JMarc From angus.leeming at btopenworld.com Mon May 17 13:39:20 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 07:39:21 2004 Subject: [XForms] [patch] libtool version number In-Reply-To: References: <200405131807.42656.angus.leeming@btopenworld.com> <200405141446.37277.angus.leeming@btopenworld.com> Message-ID: <200405171239.20613.angus.leeming@btopenworld.com> On Monday 17 May 2004 12:10 pm, Jean-Marc Lasgouttes wrote: > Angus> What's the story with the documentation? > > The story is that we still do not have anything. What would be very > nice of us in this respect is to write down note about what has > changed since the 0.89.6 release: how to use xforms (what headers > what libraries), what new api exists, etc. Do you think we could do > that? I do not think that there is a lot to write down. New FL_EVENTS, FL_MOVEORIGIN and FL_RESIZED. New typedef FL_ERROR_FUNC. Hmmm, why don't we use the FL_SIGNAL_HANDLER typedef here: -FL_EXPORT void fl_add_signal_callback(int, FL_SIGNAL_HANDLER, void *); +FL_EXPORT void fl_add_signal_callback( + int s, + void (*cb)(int, + void *), + void *data + ); Why 'register'? -FL_EXPORT int fl_get_vn_value(FL_VN_PAIR *, const char *); +FL_EXPORT int fl_get_vn_value( + register FL_VN_PAIR *vn_pair, + const char *name + ); Ach. This is going to take a while. Angus From jac4 at mindless.com Mon May 17 13:14:59 2004 From: jac4 at mindless.com (jason cipriani) Date: Mon May 17 13:15:06 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) Message-ID: <20040517171459.3A53B790060@ws1-14.us4.outblaze.com> ----- Original Message ----- From: Angus Leeming Date: Mon, 17 May 2004 12:01:14 +0100 To: Jean-Marc Lasgouttes Subject: Re: [XForms] Patch: Context Sharing + fdesign (real thing) > To subscribers of the xforms list > > > > On Monday 17 May 2004 11:50 am, Jean-Marc Lasgouttes wrote: > > OK, you are probaly right, although the define should be > > INCLUDE_GLCANVAS_H_FROM_FORMS_H or maybe the slightly shorter > > AUTOINCLUDE_GLCANVAS_H. > > I'll do this. > > > OK, it probably does not hurt to make it self contained, but I > > think it encourages sloppiness, since glcanvas.h is such a tiny > > portion of the forms api. I do not see anybody wanting to use > > _only_ > > glcanvas-related API in a program. I think people should include > > headers for the API that they explicitly use. > > Ok, I'll throw out this suggestion for now. > > Patch attached. Are you happy for me to commit this? > Angus << patch.diff >> > > _______________________________________________ > 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 -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Mon May 17 19:18:38 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 13:18:43 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <20040517171427.8653F79004A@ws1-14.us4.outblaze.com> References: <20040517171427.8653F79004A@ws1-14.us4.outblaze.com> Message-ID: <200405171818.38560.angus.leeming@btopenworld.com> On Monday 17 May 2004 6:14 pm, jason cipriani wrote: > > On Monday 17 May 2004 11:50 am, Jean-Marc Lasgouttes wrote: > > > OK, you are probaly right, although the define should be > > > INCLUDE_GLCANVAS_H_FROM_FORMS_H or maybe the slightly shorter > > > AUTOINCLUDE_GLCANVAS_H. > > > > I'll do this. > > Ok, but the fdesign problem will still remain (right?). You'll need > to modify fdesign so that it #includes before #including > forms.h (bad), or modify glcanvas.h so it #includes > (better) (which I think you already did but I got lost a few emails > ago). I modified glcanvas.h so it #includes , so all should be well. Famous last words... Angus From angus.leeming at btopenworld.com Mon May 17 19:27:25 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 13:31:34 2004 Subject: [XForms] [patch] libtool version number In-Reply-To: References: <200405131807.42656.angus.leeming@btopenworld.com> <200405141446.37277.angus.leeming@btopenworld.com> Message-ID: <200405171827.25693.angus.leeming@btopenworld.com> On Monday 17 May 2004 12:10 pm, Jean-Marc Lasgouttes wrote: > Angus> What's the story with the documentation? > > The story is that we still do not have anything. What would be very > nice of us in this respect is to write down note about what has > changed since the 0.89.6 release: how to use xforms (what headers > what libraries), what new api exists, etc. Do you think we could do > that? I do not think that there is a lot to write down. Ok, Jean-Marc, attached are all changes to the API since the release of XForms 0.89 patch level 5. I've split the changes into two files, changes_forms.h, which includes changes to stuff now in glcanvas.h, and changes_flimage.h. Many of these changes are pedantic. Eg: -FL_EXPORT void fl_bk_color(FL_COLOR); +FL_EXPORT void fl_bk_color(unsigned long); But there are new functions. There's even at least one regression. Anyway, I attach these files for the record. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: changes_flimage.h Type: text/x-chdr Size: 5131 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040517/c7a9f800/changes_flimage.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: changes_forms.h Type: text/x-chdr Size: 9125 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040517/c7a9f800/changes_forms.bin From angus.leeming at btopenworld.com Tue May 18 00:01:16 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon May 17 18:01:41 2004 Subject: [XForms] [patch] API pseudo changes Message-ID: <200405172301.16660.angus.leeming@btopenworld.com> The attached patch partially reverts the appearance of the API to that of XForms 0.89 patch level 5. In all cases, this is just a case of using the typedef rather than the raw type. In all cases, this results in a clearer intent. The patch seems completely uncontroversial to me. Any objections, or should I just shove it in? While I'm at it, several functions that were declared using 'unsigned int' are now declared using 'unsigned'. Eg: -Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned int *); +Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned *); Again, they're equivalent, but I fail to see why the change was a good one. Shall I change them back? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: api.diff Type: text/x-diff Size: 15893 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040517/1d43495a/api.bin From jac4 at mindless.com Mon May 17 19:39:17 2004 From: jac4 at mindless.com (jason cipriani) Date: Mon May 17 19:39:24 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) Message-ID: <20040517233917.188FC79004A@ws1-14.us4.outblaze.com> Ok, tested the context sharing on Redhat 9.0 with a GeForce 4 and some version of XFree86 that isn't the newest one (can't remember the version number). It works fine. On a slightly different note, the reason I'm not using the newest XFree86 is that I had been running Fedora 1 on this machine with the latest version, and I was having problems with xforms apps that used GL (with an unmodified xforms 1.0) crashing the X server itself when I called fl_free_form() or fl_finish(). I didn't look into it any further as Fedora was already getting on my nerves, I just switched to Redhat and kept the old version of the X server. I'll get to the bottom of that someday but if anybody had a similar experience maybe they've already done some investigation. It only occured on that one machine so it could have been -anything-. > Jason, I think that we should hold off on this until after XForms 1.1 > is out of the door. It's big, big, big and we're very close to a > release. :_( However, I did get another idea for another feature to add to the context sharing stuff, I'll keep you posted. Also, how come every time I respond to a message on this mail list I break the thread in the archives? Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jac4 at mindless.com Tue May 18 01:32:35 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue May 18 01:32:41 2004 Subject: [XForms] Patch: Off-screen GLXContext in context sharing pools. Message-ID: <20040518053235.C53EC101C3@ws1-16.us4.outblaze.com> > However, I did get another idea for another feature to add to the context sharing stuff, I'll keep you posted. I appear to be on a roll. Here's a patch for the context sharing patch, in a manner of speaking. This patch provides three new API functions in glcanvas.c/ .h: - fl_enable_sglpool_persistence() - fl_disable_sglpool_persistence() - fl_is_sglpool_persistent() This patch also #defines SGLDEBUG to 0 in glcanvas.c to disable debugging output, and removes a #define that was no longer needed that I forgot to get rid of (MAXPOOLNAMELEN or something). Additonally, there is also an update for the test program that was included in the last patch and the "documentation" (sglcanvas.html) as well. Using patch -p1, these diff files may be applied like so: 1) Obtain fresh copy of xforms-1.0.90. Do the following before ./configure: 2) Apply Angus' GL_CANVAS_LOCATION patch (this is for the demo program -- you don't have to do it but you'll have to modify the demo program to use whatever system for including GL/glx.h and glcanvas.h is in place). 3) Download first patch, extract it. 4) Apply $FIRST_PATCH/patch.diff in xforms-1.0.90/ --- 5) Download second patch, extract it. 6) Apply $SECOND_PATCH/patch2.diff in xforms-1.0.90/ 7) Apply $SECOND_PATCH/demo.diff in $FIRST_PATCH/demo/ 8) Apply $SECOND_PATCH/doc.diff in $FIRST_PATCH/ --- 9) Build and install xforms as usual, then build demo which still may require some Makefile tweaking. patch2.diff updates gl/glcanvas.c and gl/glcanvas.h. I now consider the context sharing stuff finished. Although, now that I'm feeling familiar with the fdesign source and I'm done with school, expect some neato fdesign code in the next few weeks ;) . Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: patch2.tgz Type: application/octet-stream Size: 9289 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040518/0b173d88/patch2.obj From angus.leeming at btopenworld.com Tue May 18 09:51:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 03:51:34 2004 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <20040517233917.188FC79004A@ws1-14.us4.outblaze.com> References: <20040517233917.188FC79004A@ws1-14.us4.outblaze.com> Message-ID: <200405180851.33642.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 12:39 am, jason cipriani wrote: > > Jason, I think that we should hold off on this until after XForms > > 1.1 is out of the door. It's big, big, big and we're very close > > to a release. > > > :_( Don't worry. It'd be nice to release little and often in the future. This time around there has been a huge amount of 'bookkeeping' work to move the tree over to the use of the GNU autotools. I anticipate that *nothing* we do in the future will be so disruptive. > Also, how come every time I respond to a message on this mail list > I break the thread in the archives? Dunno, but I don't think it's just you. Angus From angus.leeming at btopenworld.com Tue May 18 10:57:05 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 04:57:10 2004 Subject: [XForms] [patch] API pseudo changes In-Reply-To: <200405172301.16660.angus.leeming@btopenworld.com> References: <200405172301.16660.angus.leeming@btopenworld.com> Message-ID: <200405180957.05377.angus.leeming@btopenworld.com> On Monday 17 May 2004 11:01 pm, Angus Leeming wrote: > The attached patch partially reverts the appearance of the API to > that of XForms 0.89 patch level 5. In all cases, this is just a > case of using the typedef rather than the raw type. In all cases, > this results in a clearer intent. > > The patch seems completely uncontroversial to me. Any objections, > or should I just shove it in? I committed it. Angus From angus.leeming at btopenworld.com Tue May 18 11:25:15 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 05:25:16 2004 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms 0.89 Message-ID: <200405181025.15390.angus.leeming@btopenworld.com> Jean-Marc, all, I think that below are all the genuine API changes to forms.h since XForms 0.89. AFAICS, there is only one genuine regression and that it probably trivial. Nonetheless, I guess we should #define fl_set_error_logfp fl_set_err_logfp. I don't see any implications in passing 'unsigned long' to functions that used to receive 'unsigned' vars. Are there any implications when using shared objects? I don't see any implications at all to returning an 'int' from functions that were previously declared as 'void'. I have no feeling whatsoever about the implications of functions previously receiving 'char *' that now receive 'char []'. Once these points have been nailed down, it'll be trivial to document these changes. Angus New static constants: FL_ARGUMENT = -3, FL_ALLOC = -4, FL_BAD_OBJECT = -5 New FL_EVENTS: FL_MOVEORIGIN, /* dragging the form across the screen changes its absolute x,y coords. Objects that themselves contain forms should ensure that they are up to date. */ FL_RESIZED /* The object has been resized by scale_form Tell it that this has happened so that it can resize any FL_FORMs that it contains. */ -FL_EXPORT unsigned long fl_msleep(unsigned); +FL_EXPORT unsigned long fl_msleep(unsigned long); -FL_EXPORT FL_RAW_CALLBACK fl_register_raw_callback(FL_FORM *, unsigned, FL_RAW_CALLBACK); +FL_EXPORT FL_RAW_CALLBACK fl_register_raw_callback(FL_FORM *, unsigned long, FL_RAW_CALLBACK); -FL_EXPORT void fl_set_error_logfp(FILE *); +FL_EXPORT void fl_set_err_logfp(FILE *); -#define FL_CHART_MAX 512 +#define FL_CHART_MAX 2048 -FL_EXPORT void fl_set_chart_maxnumb(FL_OBJECT *, int); +FL_EXPORT int fl_set_chart_maxnumb(FL_OBJECT *, int); +FL_EXPORT void fl_set_chart_baseline(FL_OBJECT *, int); +enum +{ + FL_TRIANGLE_UPBOX1, + FL_TRIANGLE_UPBOX2, + FL_TRIANGLE_UPBOX3, + FL_TRIANGLE_UPBOX4, + FL_TRIANGLE_UPBOX6, + FL_TRIANGLE_UPBOX7, + FL_TRIANGLE_UPBOX8, + FL_TRIANGLE_UPBOX9, + FL_TRIANGLE_DOWNBOX1, + FL_TRIANGLE_DOWNBOX2, + FL_TRIANGLE_DOWNBOX3, + FL_TRIANGLE_DOWNBOX4, + FL_TRIANGLE_DOWNBOX6, + FL_TRIANGLE_DOWNBOX7, + FL_TRIANGLE_DOWNBOX8, + FL_TRIANGLE_DOWNBOX9 +}; +typedef void (*FL_ERROR_FUNC)( const char *, const char *,... ); +typedef const char *(*FL_VAL_FILTER) (FL_OBJECT *, double, int); +/** Functions to set and get the timeout value used by the + * counter code to control modification of the counter value. + */ +FL_EXPORT int fl_get_counter_repeat(FL_OBJECT *); +FL_EXPORT void fl_set_counter_repeat(FL_OBJECT *, int); -FL_EXPORT char *fl_fix_dirname(char *); +FL_EXPORT char *fl_fix_dirname(char dir[]); +FL_EXPORT int fl_goodies_atclose(FL_FORM *, void *); +/** Functions to set and get the timeout value used by the + slider code to increment the position of the knob. + */ +FL_EXPORT int fl_get_slider_repeat(FL_OBJECT *); +FL_EXPORT void fl_set_slider_repeat(FL_OBJECT *, int); -FL_EXPORT void fl_set_xyplot_data(FL_OBJECT *, float *, float *, int, const char *, const char *, const char *); +FL_EXPORT int fl_set_xyplot_data(FL_OBJECT *, float *, float *, int, const char *, const char *, const char *); +FL_EXPORT int fl_set_xyplot_data_double(FL_OBJECT *, double *, double *, int, const char *, const char *, const char *); +/* Replace the value of a particular point in dataset setID, + * where setID=0 is the first data set. + * This routine is an extension of fl_replace_xyplot_point + * which acts on the first dataset only. + */ +FL_EXPORT void fl_replace_xyplot_point_in_overlay(FL_OBJECT *, int, int, double, double); -FL_EXPORT void fl_get_glcanvas_defaults(int *); +FL_EXPORT void fl_get_glcanvas_defaults(int[]); From angus.leeming at btopenworld.com Tue May 18 11:27:34 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 05:27:34 2004 Subject: [XForms] API regression to flimage.h on 64 bit machines since XForms 0.89 Message-ID: <200405181027.34232.angus.leeming@btopenworld.com> The change below assumes that a sizeof(pointer) == 4. Not so on 64 bit machines. How should we address this? Angus typedef struct flimage_ { int type; /* image type */ @@ -279,8 +311,10 @@ int isPixmap; FLIMAGESETUP setup; char *info; - int internal_reserved[16]; + struct flimage_src_ *src; /* src other than file */ + struct flimage_dest_ *dest; /* destination other than file */ + int internal_reserved[14]; } FL_IMAGE; From Jean-Marc.Lasgouttes at inria.fr Tue May 18 15:00:56 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 18 08:01:04 2004 Subject: [XForms] [patch] API pseudo changes In-Reply-To: <200405172301.16660.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 23:01:16 +0100") References: <200405172301.16660.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list The attached patch partially Angus> reverts the appearance of the API to that of XForms 0.89 patch Angus> level 5. In all cases, this is just a case of using the typedef Angus> rather than the raw type. In all cases, this results in a Angus> clearer intent. Angus> The patch seems completely uncontroversial to me. Any Angus> objections, or should I just shove it in? It looks like the right thing to do, but I do not understand why things have been changed previously. There has to be a reason, don't you think? Angus> While I'm at it, several functions that were declared using Angus> 'unsigned int' are now declared using 'unsigned'. Eg: Angus> -Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned int *); Angus> +Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned *); Angus> Again, they're equivalent, but I fail to see why the change was Angus> a good one. Shall I change them back? I think so. JMarc From angus.leeming at btopenworld.com Tue May 18 14:06:26 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 08:06:27 2004 Subject: [XForms] [patch] API pseudo changes In-Reply-To: References: <200405172301.16660.angus.leeming@btopenworld.com> Message-ID: <200405181306.26752.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 1:00 pm, Jean-Marc Lasgouttes wrote: > Angus> The patch seems completely uncontroversial to me. Any > Angus> objections, or should I just shove it in? > > It looks like the right thing to do, but I do not understand why > things have been changed previously. There has to be a reason, > don't you think? I'm not so sure. The old closed-source development was so fragmented, with different versions for different architectures, that it may well be that the stuff I grabbed as ftp://ncmir.ucsd.edu/pub/xforms/Attic/linux/elf/bxform-089-glibc2.1.tgz was not the basis for the open source release. > Angus> While I'm at it, several functions that were declared using > Angus> 'unsigned int' are now declared using 'unsigned'. Eg: > > Angus> -Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned int > *); Angus> +Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned > *); > > Angus> Again, they're equivalent, but I fail to see why the change > was Angus> a good one. Shall I change them back? > > I think so. Ok, dokey. I'll have a go. Angus From Jean-Marc.Lasgouttes at inria.fr Tue May 18 15:08:36 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 18 08:08:40 2004 Subject: [XForms] API regression to flimage.h on 64 bit machines since XForms 0.89 In-Reply-To: <200405181027.34232.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 18 May 2004 10:27:34 +0100") References: <200405181027.34232.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list The change below assumes that Angus> a sizeof(pointer) == 4. Not so on 64 bit machines. How should Angus> we address this? I would say that keeping binary compatibility with 1.0 is more important than keeping it with 0.89. So let's leave things as they are. JMarc From angus.leeming at btopenworld.com Tue May 18 14:10:44 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 08:10:46 2004 Subject: [XForms] API regression to flimage.h on 64 bit machines since XForms 0.89 In-Reply-To: References: <200405181027.34232.angus.leeming@btopenworld.com> Message-ID: <200405181310.44974.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 1:08 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> To subscribers of the xforms list The change below assumes > that Angus> a sizeof(pointer) == 4. Not so on 64 bit machines. How > should Angus> we address this? > > I would say that keeping binary compatibility with 1.0 is more > important than keeping it with 0.89. So let's leave things as they > are. Ok. Anyway, all this info should make it easy for you to document the changes ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Tue May 18 15:12:12 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 18 08:12:16 2004 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms 0.89 In-Reply-To: <200405181025.15390.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 18 May 2004 10:25:15 +0100") References: <200405181025.15390.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, all, Angus> I think that below are all the genuine API changes to forms.h Angus> since XForms 0.89. AFAICS, there is only one genuine regression Angus> and that it probably trivial. Nonetheless, I guess we should Angus> #define fl_set_error_logfp fl_set_err_logfp. Yes. Angus> I don't see any implications in passing 'unsigned long' to Angus> functions that used to receive 'unsigned' vars. Are there any Angus> implications when using shared objects? It might be that binary compatibility is not kept. However, the harm is done in 1.0 already, I guess. Angus> I don't see any implications at all to returning an 'int' from Angus> functions that were previously declared as 'void'. Don't know. Angus> I have no feeling whatsoever about the implications of Angus> functions previously receiving 'char *' that now receive 'char Angus> []'. Don't know. Angus> Once these points have been nailed down, it'll be trivial to Angus> document these changes. Yes. Concerning the constants, we should document what they are good for. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue May 18 15:13:44 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 18 08:13:48 2004 Subject: [XForms] xforms on windows? In-Reply-To: <40A1D2D8.4000608@CeBiTec.Uni-Bielefeld.DE> (Dirk Evers's message of "Wed, 12 May 2004 09:31:36 +0200") References: <40A1D2D8.4000608@CeBiTec.Uni-Bielefeld.DE> Message-ID: >>>>> "Dirk" == Dirk Evers writes: Dirk> To subscribers of the xforms list This is probably documented Dirk> somewhere... :-) Dirk> Is there a version of xforms for windows? What do I need to use Dirk> it? I know about fltk, but I would prefer not having to rewrite Dirk> for it. Xforms 1.0 and 1.0.90 should compile fine on windows, but one needs to use cygwin (aka unix-on-windows) and a X server. There is no native windows support. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue May 18 15:15:33 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 18 08:15:37 2004 Subject: [XForms] API regression to flimage.h on 64 bit machines since XForms 0.89 In-Reply-To: <200405181310.44974.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 18 May 2004 13:10:44 +0100") References: <200405181027.34232.angus.leeming@btopenworld.com> <200405181310.44974.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Anyway, all this info should make it easy for you to document Angus> the changes ;-) You almost got me :) I'd rather not have to do it now, since this week is going to be very short for me (as in, only one day left with plenty of work). JMarc From Jean-Marc.Lasgouttes at inria.fr Tue May 18 16:01:33 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 18 09:01:37 2004 Subject: [XForms] xyplot patch, OS X compatibility In-Reply-To: <70579D31-A239-11D8-9713-003065E23D38@mac.com> (drriddle@mac.com's message of "Sun, 9 May 2004 23:20:58 -0500") References: <70579D31-A239-11D8-9713-003065E23D38@mac.com> Message-ID: >>>>> "drriddle" == drriddle writes: drriddle> To subscribers of the xforms list Howdy all, drriddle> A while ago, I put up a patch for the drriddle> fl_replace_xyplot_point routine that would allow one to drriddle> change the value of an overlay point (the current version drriddle> only allows you to change the value of the main data plot drriddle> point). Did that make it into the new version of the drriddle> library? Hmm, could you post it again? I have lost track. drriddle> Also, you should be able to use the instructions at drriddle> http://wet.physics.iastate.edu/Tools/xqed/index.html drriddle> to compile Xforms under Mac OS X, version 10.3. I'll test drriddle> that again once the new version of the library comes out, drriddle> just to make sure it still works. Concerning the information on the page: - the new release versions, like 1.0.90 do not require to have autoconf 2.5x. The autotools are only needed when one builds from cvs. - I do not see any reason why it would not build on redhat 7. I would be interested by reports of the contrary. - On Mac OS X, the configure options should read --with-extra-inc and not --with_extra_inc. Actually, one can use --with-extra-prefix=/sw, which will replace the two statements. Hope this helps. There is some information on building xforms in the README file. If you can suggest some modifications to accommodate OS X peculiarities, they will be welcome. JMarc From angus.leeming at btopenworld.com Tue May 18 15:05:01 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 09:05:03 2004 Subject: [XForms] xyplot patch, OS X compatibility In-Reply-To: References: <70579D31-A239-11D8-9713-003065E23D38@mac.com> Message-ID: <200405181405.01930.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 2:01 pm, Jean-Marc Lasgouttes wrote: > drriddle> A while ago, I put up a patch for the > drriddle> fl_replace_xyplot_point routine that would allow one to > drriddle> change the value of an overlay point (the current version > drriddle> only allows you to change the value of the main data plot > drriddle> point). Did that make it into the new version of the > drriddle> library? > > Hmm, could you post it again? I have lost track. It's now in the cvs tree as 'fl_replace_xyplot_point_in_overlay' Angus From Jean-Marc.Lasgouttes at inria.fr Tue May 18 16:10:47 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 18 09:10:52 2004 Subject: [XForms] xyplot patch, OS X compatibility In-Reply-To: <200405181405.01930.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 18 May 2004 14:05:01 +0100") References: <70579D31-A239-11D8-9713-003065E23D38@mac.com> <200405181405.01930.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> Hmm, could you post it again? I have lost track. Angus> It's now in the cvs tree as Angus> 'fl_replace_xyplot_point_in_overlay' Thanks. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue May 18 16:18:01 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 18 09:18:06 2004 Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: (Mike Heffner's message of "Wed, 05 May 2004 18:12:15 -0400 (EDT)") References: Message-ID: >>>>> "Mike" == Mike Heffner writes: Mike> Whichever would prevent it from being displayed if libforms is Mike> not compiled in debug mode. When is M_warn() printed? I think this is controlled by the -debug switch to xforms apps. I am not sure what should go in which level, but I guess level 1 is OK in this case. JMarc From angus.leeming at btopenworld.com Tue May 18 15:58:44 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 09:58:46 2004 Subject: [XForms] [patch] API pseudo changes In-Reply-To: References: <200405172301.16660.angus.leeming@btopenworld.com> Message-ID: <200405181458.44602.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 1:00 pm, Jean-Marc Lasgouttes wrote: > Angus> While I'm at it, several functions that were declared using > Angus> 'unsigned int' are now declared using 'unsigned'. Eg: > > Angus> -Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned int > *); Angus> +Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned > *); > > Angus> Again, they're equivalent, but I fail to see why the change > was Angus> a good one. Shall I change them back? > > I think so. I wrote a little script to do it everywhere. Not very elegant, but did the job. Patch attached and committed. Angus #! /bin/sh TMP=tmp for dir in demos fd2ps fdesign gl image lib do DATA=`grep -n -r unsigned $dir | \ sed 's/unsigned *long//g s/unsigned *int//g s/unsigned *char//g s/unsigned *short//g /unsigned/!d'` echo "$DATA" | while read LINE do FILE=`echo $LINE | cut -d':' -f1` LN=`echo $LINE | cut -d':' -f2` test "$FILE" != "" -a "$LN" != "" || continue sed "${LN} s/unsigned/unsigned int/g; s/\(unsigned int\) int/\1/" ${FILE} > $TMP cmp -s $FILE $TMP && continue diff -u $FILE $TMP #mv -f $TMP $FILE done done -------------- next part -------------- A non-text attachment was scrubbed... Name: uint.diff.bz2 Type: application/x-bzip2 Size: 11854 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040518/02afbcb6/uint.diff.bin From Todd.Denniston at ssa.crane.navy.mil Tue May 18 10:07:27 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Tue May 18 10:07:37 2004 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms 0.89 References: <200405181025.15390.angus.leeming@btopenworld.com> Message-ID: <40AA189F.1EA025FF@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > Jean-Marc, all, > > I think that below are all the genuine API changes to forms.h since > XForms 0.89. AFAICS, there is only one genuine regression and that it > probably trivial. Nonetheless, I guess we should > #define fl_set_error_logfp fl_set_err_logfp. > Don't know don't care. > I don't see any implications in passing 'unsigned long' to functions > that used to receive 'unsigned' vars. Are there any implications when > using shared objects? > Probably not with gcc (int and long are 32 bits), might be with other compilers. > I don't see any implications at all to returning an 'int' from > functions that were previously declared as 'void'. > void means no return value, int means there is an integer return value. if the user wants to ignore the return value, that is probably fine, I think some compiler settings will warn on ignoreing return values. However if the function is defined as an int it should ALWAYS exit by returning an integer. I have not looked at the code for the function(s) you are refering too, but as long as there is a reason (return value) for them to be int all is good. > I have no feeling whatsoever about the implications of functions > previously receiving 'char *' that now receive 'char []'. > I suppose they are equivilent but the 'char *' has always been more clear to me and more common in the code I have recived. If you like the new way go with it. > Once these points have been nailed down, it'll be trivial to document > these changes. > > Angus > -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From angus.leeming at btopenworld.com Tue May 18 16:14:00 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 10:15:57 2004 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms 0.89 In-Reply-To: <40AA189F.1EA025FF@ssa.crane.navy.mil> References: <200405181025.15390.angus.leeming@btopenworld.com> <40AA189F.1EA025FF@ssa.crane.navy.mil> Message-ID: <200405181514.00848.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 3:07 pm, Todd Denniston wrote: > > I have no feeling whatsoever about the implications of functions > > previously receiving 'char *' that now receive 'char []'. > > I suppose they are equivilent but the 'char *' has always been more > clear to me and more common in the code I have recived. If you like > the new way go with it. Thanks for the reassurances, Todd. I guess that the new way is marginally safer, but I was more concerned that code compiled with the old header would continue to compile with the new one. As a guy who wrote fortran and then moved to c++, it all looks ugly ;-) Angus From jac4 at mindless.com Tue May 18 13:18:27 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue May 18 13:18:28 2004 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms0.89 Message-ID: <20040518171827.79F621F4FEB@ws1-12.us4.outblaze.com> > Angus> I don't see any implications in passing 'unsigned long' to > Angus> functions that used to receive 'unsigned' vars. Are there any > Angus> implications when using shared objects? > > It might be that binary compatibility is not kept. However, the harm > is done in 1.0 already, I guess. > > Angus> I don't see any implications at all to returning an 'int' from > Angus> functions that were previously declared as 'void'. > > Don't know. As far as coding go it would only break code that took addresses of these functions and assumed they had a certain type. Should be easy to fix in any apps that do that, though. > Angus> To subscribers of the xforms list The change below assumes that > Angus> a sizeof(pointer) == 4. Not so on 64 bit machines. How should > Angus> we address this? It assumed that sizeof(pointer) == sizeof(int), and 2 byte ints are allowed. If you are trying to keep the size of the structure constant then perhaps it would make more sense to change it to: - int internal_reserved[16]; + struct flimage_src_ *src; /* src other than file */ + struct flimage_dest_ *dest; /* destination other than file */ + char internal_reserved[64 - 2 * sizeof(void *)]; In other words, make the decision right now that internal_reserved is 64 bytes. Cross your fingers that nobody (who can't rebuild their apps after the header change) relied on internal_reserved being 64 bytes on a system with ints that weren't 4 bytes, and then it becomes simple to change it predictably in the future. > I think some compiler settings will warn on ignoreing return values. Is that the case? Even with -Wall -pedantic gcc doesn't warn. It's also perfectly legal to do things like: { 0; } There really shouldn't be any problem converting void returns to int returns other than function pointer problems and shared library dynamic linking (dunno how it's done on non-Windows, and it may not even have a problem as C function names aren't mangled based on their return value). Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From xyzzy at speakeasy.org Tue May 18 11:52:53 2004 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue May 18 13:53:03 2004 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms0.89 In-Reply-To: <20040518171827.79F621F4FEB@ws1-12.us4.outblaze.com> Message-ID: On Tue, 18 May 2004, jason cipriani wrote: > > There really shouldn't be any problem converting void returns to int returns other than function pointer problems and shared > library dynamic linking (dunno how it's done on non-Windows, and it may not even have a problem as C function names aren't > mangled based on their return value). Why is it you want to change void returns to int returns, for functions that don't return a value? You get warning in the function is compiled: bar.c:1: warning: `return' with no value, in function returning non-void From jac4 at mindless.com Tue May 18 15:34:03 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue May 18 15:34:14 2004 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms0.89 Message-ID: <20040518193403.D2DA8164036@ws1-15.us4.outblaze.com> > Why is it you want to change void returns to int returns, for functions that > don't return a value? Wasn't my idea! > You get warning in the function is compiled: > > bar.c:1: warning: `return' with no value, in function returning non-void That's only if you don't return anything, as in: int func (void) { return; } The situation in question is this: int func (void) { return 0; } func(); Where you call func() (which is properly written) but do nothing with the return value. At least... I think it's the case. I don't think Angus was planning on changing a bunch of void-returning functions to int without actually making them return an error/success status... right? -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Tue May 18 21:41:38 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 18 16:15:07 2004 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms0.89 In-Reply-To: <20040518193403.D2DA8164036@ws1-15.us4.outblaze.com> References: <20040518193403.D2DA8164036@ws1-15.us4.outblaze.com> Message-ID: <200405182041.38728.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 8:34 pm, jason cipriani wrote: > At least... I think it's the case. I don't think Angus was planning > on changing a bunch of void-returning functions to int without > actually making them return an error/success status... right? Correct. I'm just trying to document changes that occured sometime during the 0.89 -> 1.0 interval. Specifically: API changes from XForms 0.89 to XForms 1.0 ========================================== fl_set_chart_maxnumb now returns FL_ARGUMENT (== -3) if maxnum < 0 FL_ALLOC (== -4) if the chart object previously had no space allocated for these values. 0 if the object was resized and re-displayed successfully. -FL_EXPORT void fl_set_chart_maxnumb(FL_OBJECT *, int maxnum); +FL_EXPORT int fl_set_chart_maxnumb(FL_OBJECT *, int maxnum); Now returns 0 on success. FL_ALLOC if unable to allocate sufficient memory to the object. -FL_EXPORT void fl_set_xyplot_data(FL_OBJECT *, float *, float *, int, const char *, const char *, const char *); +FL_EXPORT int fl_set_xyplot_data(FL_OBJECT *, float *, float *, int, const char *, const char *, const char *); From Jens.Toerring at physik.fu-berlin.de Wed May 19 16:42:39 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Wed May 19 09:42:46 2004 Subject: [XForms] Figuring out a windows state Message-ID: <20040519134239.GA30072@crowley.physik.fu-berlin.de> Hi, I have just a stupid question. I would like to find out if a certain window is iconified or not. I looked throught the documen- tation and also tried to find something fitting in the sources but to no avail, no function seems to exist that helps me finding that out. So, do I have to do that myself using XGetWindowProperty() or something similar or am I just not looking carefully enough? Thanks, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From angus.leeming at btopenworld.com Wed May 19 15:52:19 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 19 09:52:23 2004 Subject: [XForms] Figuring out a windows state In-Reply-To: <20040519134239.GA30072@crowley.physik.fu-berlin.de> References: <20040519134239.GA30072@crowley.physik.fu-berlin.de> Message-ID: <200405191452.19272.angus.leeming@btopenworld.com> On Wednesday 19 May 2004 2:42 pm, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > > Hi, > > I have just a stupid question. I would like to find out if a > certain window is iconified or not. I looked throught the documen- > tation and also tried to find something fitting in the sources but > to no avail, no function seems to exist that helps me finding that > out. So, do I have to do that myself using XGetWindowProperty() > or something similar or am I just not looking carefully enough? No, you're looking closely enough. FWIW, this is how LyX goes about showing an iconified window. HTH, Angus if (form()->visible) { fl_raise_form(form()); /* This XMapWindow() will hopefully ensure that * iconified dialogs are de-iconified. Mad props * out to those crazy Xlib guys for forgetting a * XDeiconifyWindow(). At least WindowMaker, when * being notified of the redirected MapRequest will * specifically de-iconify. From source, fvwm2 seems * to do the same. */ XMapWindow(fl_get_display(), form()->window); } else { // calls to fl_set_form_minsize/maxsize apply only to the next // fl_show_form(), so this comes first. fl_set_form_minsize(form(), minw_, minh_); if (!allow_resize_) fl_set_form_maxsize(form(), minw_, minh_); string const maximize_title = "LyX: " + title_; int const iconify_policy = getController().IconifyWithMain() ? FL_TRANSIENT : 0; fl_show_form(form(), FL_PLACE_MOUSE | FL_FREE_SIZE, iconify_policy, maximize_title.c_str()); } From Jens.Toerring at physik.fu-berlin.de Wed May 19 17:10:57 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Wed May 19 10:11:01 2004 Subject: [XForms] Figuring out a windows state In-Reply-To: <200405191452.19272.angus.leeming@btopenworld.com> References: <20040519134239.GA30072@crowley.physik.fu-berlin.de> <200405191452.19272.angus.leeming@btopenworld.com> Message-ID: <20040519141057.GA30160@crowley.physik.fu-berlin.de> On Wed, May 19, 2004 at 02:52:19PM +0100, Angus Leeming wrote: > On Wednesday 19 May 2004 2:42 pm, Jens Thoms Toerring wrote: > > To subscribers of the xforms list > > I have just a stupid question. I would like to find out if a > > certain window is iconified or not. I looked throught the documen- > > tation and also tried to find something fitting in the sources but > > to no avail, no function seems to exist that helps me finding that > > out. So, do I have to do that myself using XGetWindowProperty() > > or something similar or am I just not looking carefully enough? > > No, you're looking closely enough. > > FWIW, this is how LyX goes about showing an iconified window. > > HTH, > Angus > > if (form()->visible) { > fl_raise_form(form()); > /* This XMapWindow() will hopefully ensure that > * iconified dialogs are de-iconified. Mad props > * out to those crazy Xlib guys for forgetting a > * XDeiconifyWindow(). At least WindowMaker, when > * being notified of the redirected MapRequest will > * specifically de-iconify. From source, fvwm2 seems > * to do the same. > */ > XMapWindow(fl_get_display(), form()->window); > } else { > // calls to fl_set_form_minsize/maxsize apply only to the next > // fl_show_form(), so this comes first. > fl_set_form_minsize(form(), minw_, minh_); > if (!allow_resize_) > fl_set_form_maxsize(form(), minw_, minh_); > > string const maximize_title = "LyX: " + title_; > int const iconify_policy = > getController().IconifyWithMain() ? FL_TRANSIENT : 0; > > fl_show_form(form(), > FL_PLACE_MOUSE | FL_FREE_SIZE, > iconify_policy, > maximize_title.c_str()); > } Thanks, but as far as a quick test shows me form()->visible seems only to tell me if the window is mapped, it doesn't seem to make a difference if the window is fully visible or iconified. So what your code seems to, as far as I understand it, is to make sure a window gets de-iconified. But for my problem I need to know if a window is iconfied because I take that as a hint from the user on how to continue within the program. So, I probably will have to figure out how to get XGetWindowProperty() to tell me ;-) Thanks, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From angus.leeming at btopenworld.com Wed May 19 16:38:56 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed May 19 10:48:14 2004 Subject: [XForms] Figuring out a windows state In-Reply-To: <20040519141057.GA30160@crowley.physik.fu-berlin.de> References: <20040519134239.GA30072@crowley.physik.fu-berlin.de> <200405191452.19272.angus.leeming@btopenworld.com> <20040519141057.GA30160@crowley.physik.fu-berlin.de> Message-ID: <200405191538.56053.angus.leeming@btopenworld.com> On Wednesday 19 May 2004 3:10 pm, Jens Thoms Toerring wrote: > Thanks, but as far as a quick test shows me form()->visible seems > only to tell me if the window is mapped, it doesn't seem to make a > difference if the window is fully visible or iconified. So what > your code seems to, as far as I understand it, is to make sure a > window gets de-iconified. But for my problem I need to know if a That's correct. We've never needed to know whether a window is iconified, only to ensure that it is de-iconified. > But for my problem I need to know if a > window is iconfied because I take that as a hint from the user on > how to continue within the program. So, I probably will have to > figure out how to get XGetWindowProperty() to tell me ;-) Ok. The Qt sources have lots of examples of XGetWindowProperty in action. See qapplication_x11.cpp at http://tinyurl.com/27r3m HTH, Angus From msz at astrouw.edu.pl Wed May 19 17:49:02 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed May 19 10:49:08 2004 Subject: [XForms] subpixel sampling in image scaling - does it work? Message-ID: <20040519144902.GA29155@astrouw.edu.pl> Hello, I have a simple app displaying several images from a digital camera in a 3x3 grid of small (230x170) canvases, with the main purpose of easy choosing the images for hardcopy prints. The original images are 1840x1232 JPEGs so before displaying I scale them to the canvas' size. I have noticed that the quality of such shrinked images is rather poor so I tried to employ subpixel sampling to make them look better. Strangely, or-ing FLIMAGE_SUBPIXEL flag into the basic flag used in flimage_scale(img[no], w, h, scale_flag) (which used to be FLIMAGE_ASPECT | FLIMAGE_CENTER) DOES NOT change anything. When I imported (ImageMagick's import) single image canvas into a TIFF image file (first, with the flag added and then without it), the resulting two files did not show ANY differences on byte-by-byte comparison (with the one-byte exception at the file name which is also stored in a TIFF image). Any ideas what is wrong here? I can hardly imagine that a typical image (two persons in a garden full of flowers) could yield no differences after any pixel interpolation process. regards, Michal. -- Michal Szymanski (msz@astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jens.Toerring at physik.fu-berlin.de Wed May 19 17:51:59 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Wed May 19 10:52:02 2004 Subject: [XForms] Figuring out a windows state In-Reply-To: <200405191538.56053.angus.leeming@btopenworld.com> References: <20040519134239.GA30072@crowley.physik.fu-berlin.de> <200405191452.19272.angus.leeming@btopenworld.com> <20040519141057.GA30160@crowley.physik.fu-berlin.de> <200405191538.56053.angus.leeming@btopenworld.com> Message-ID: <20040519145159.GA30260@crowley.physik.fu-berlin.de> On Wed, May 19, 2004 at 03:38:56PM +0100, Angus Leeming wrote: > The Qt sources have lots of examples of XGetWindowProperty in action. > See qapplication_x11.cpp at http://tinyurl.com/27r3m Thanks a lot, I hope I will be able to figure it out. Best regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From angus.leeming at btopenworld.com Mon May 24 02:42:45 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sun May 23 19:42:49 2004 Subject: [XForms] Re: Xforms-cvs post from emails@hahnebach.com requires approval In-Reply-To: References: Message-ID: <200405240142.45508.angus.leeming@btopenworld.com> Hi, Bernd, I'm afraid that you've posted to the wrong list. xforms-cvs@nongnu.org is a list documenting commits to the xforms-cvs tree. Or it would be if we could get it to work. (Separate problem.) I've forwarded your mail to the xforms development list at . This list is fairly low volume (5 emails / day on a busy day ;-), so I really recommend that you subscribe for a little while. See http://cweblog.usuhs.mil/mailman/listinfo/xforms Hope to see you there, Angus On Sunday 23 May 2004 5:50 pm, xforms-cvs-owner@nongnu.org wrote: > Hi, > > I found the software xstab which I really would like to get > running. The project has been dead for years. The code is GPL. I > was trying to compile it for hours. The GUI is based on xforms > 0.88. It is still listed on > http://world.std.com/~xforms/new/app.html although the home page is > dead. The source code can be found at > http://goemon.polito.it/software/lethal/scheda.php?id=26 > > I installed the already compiled library of xform to /usr/local. > Compiling xstab worked really well for a long time. Than I got the > following: > > ... > /usr/local/lib/libforms.so: undefined reference to `errno' > /usr/local/lib/libforms.so: undefined reference to `_xstat' > collect2: ld returned 1 exit status > make[1]: *** [XStab] Fehler 1 > make[1]: Leaving directory > `/home/hugo/Documents/xstab/programm/XStab/src' make: *** [srcs] > Fehler 2 > hugo@linux:~/Documents/xstab/programm/XStab> > > > I found out it is something regarding newer version gcc. > ("Since version 2.9 of the GCC compiler the compiler has become a > lot stricter over declaring external references. Undefined > reference to ?errno?") > > I am using gcc 3.3 > > For me it seems I need to recompile xforms with gcc 3.3 or I coud > use an older version of gcc. To be honest I really do not have a > glue what to do next. > > > Thanks for any help > Bernd Hahnebach > > I am not a member of the list would you replies mails to emails at > hahnebach.com From angus.leeming at btopenworld.com Mon May 24 02:45:25 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sun May 23 19:45:27 2004 Subject: [XForms] Fwd: xform 0.88; undefined reference to `errno' Message-ID: <200405240145.25278.angus.leeming@btopenworld.com> Original post was to xforms-cvs@nongun.org. Readership nil. Angus ----------------------- Forwarded message ----------------------- xform 0.88; undefined reference to `errno' Date: Saturday 6:09:31 am From: Bernd Hahnebach To: xforms-cvs@nongnu.org Hi, I found the software xstab which I really would like to get running. The project has been dead for years. The code is GPL. I was trying to compile it for hours. The GUI is based on xforms 0.88. It is still listed on http://world.std.com/~xforms/new/app.html although the home page is dead. The source code can be found at http://goemon.polito.it/software/lethal/scheda.php?id=26 I installed the already compiled library of xform to /usr/local. Compiling xstab worked really well for a long time. Than I got the following: ... /usr/local/lib/libforms.so: undefined reference to `errno' /usr/local/lib/libforms.so: undefined reference to `_xstat' collect2: ld returned 1 exit status make[1]: *** [XStab] Fehler 1 make[1]: Leaving directory `/home/hugo/Documents/xstab/programm/XStab/src' make: *** [srcs] Fehler 2 hugo@linux:~/Documents/xstab/programm/XStab> I found out it is something regarding newer version gcc. ("Since version 2.9 of the GCC compiler the compiler has become a lot stricter over declaring external references. Undefined reference to ?errno?") I am using gcc 3.3 For me it seems I need to recompile xforms with gcc 3.3 or I coud use an older version of gcc. To be honest I really do not have a glue what to do next. Thanks for any help Bernd Hahnebach I am not a member of the list would you replies mails to emails at hahnebach.com -------------- next part -------------- An embedded message was scrubbed... From: xforms-cvs-owner@nongnu.org Subject: Xforms-cvs post from emails@hahnebach.com requires approval Date: Sun, 23 May 2004 12:50:39 -0400 Size: 6209 Url: http://bob.usuhs.mil/pipermail/xforms/attachments/20040524/341ca784/attachment.eml From angus.leeming at btopenworld.com Tue May 25 12:46:17 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue May 25 06:48:07 2004 Subject: [XForms] Re: Fwd: xform 0.88; undefined reference to `errno' In-Reply-To: <200405240145.25278.angus.leeming@btopenworld.com> References: <200405240145.25278.angus.leeming@btopenworld.com> Message-ID: <200405251146.17943.angus.leeming@btopenworld.com> On Monday 24 May 2004 1:45 am, you wrote: > The source code can be found at > http://goemon.polito.it/software/lethal/scheda.php?id=26 I get an 'access denied' message when I try and connect. > I installed the already compiled library of xform to /usr/local. Could you tell me what version of XForms you are using? > /usr/local/lib/libforms.so: undefined reference to `errno' > /usr/local/lib/libforms.so: undefined reference to `_xstat' So you need to also link in the libraries that contain 'errno' and '_xstat'. 'errno' is part of libc. See 'man errno'. Add '-lc' to the options passed to the linker. '_xstat' is an implementation detail of the system 'stat' call. See 'man stat'. It's also part of libc. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Tue May 25 15:14:58 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue May 25 08:15:04 2004 Subject: [XForms] Re: Fwd: xform 0.88; undefined reference to `errno' In-Reply-To: <200405251146.17943.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 25 May 2004 11:46:17 +0100") References: <200405240145.25278.angus.leeming@btopenworld.com> <200405251146.17943.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> /usr/local/lib/libforms.so: undefined reference to `errno' >> /usr/local/lib/libforms.so: undefined reference to `_xstat' Angus> So you need to also link in the libraries that contain 'errno' Angus> and '_xstat'. Angus> 'errno' is part of libc. See 'man errno'. Add '-lc' to the Angus> options passed to the linker. Angus> '_xstat' is an implementation detail of the system 'stat' call. Angus> See 'man stat'. It's also part of libc. If I remember correctly, this kind of thing can happen when one uses a xforms library which has not been linked against the right glibc version. Bernd, why don't you get the latest xforms version and build it? JMarc From wd4nmq at comcast.net Tue May 25 20:51:37 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue May 25 19:51:47 2004 Subject: [XForms] Where to add entry for forms.h Message-ID: <40B3DC09.9080209@comcast.net> Angus, or anbody, Where do I add the line: FL_CLIENT_CALLBACK client_callback; so it appears in the forms structuer. I thnk it would go into Basic.h. But do I also need to adjust the line int reserved[10]; /* future use */ to include the size of the new client_callback enty in struct FL_FORM in Basic.h I also guess the header declaration FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( FL_FORM *form, FL_CLIENT_CALLBACK rcb ); Would also go into Basic.h. I want to finally submit this patch. Jeff From mheffner at vt.edu Wed May 26 00:58:11 2004 From: mheffner at vt.edu (Mike Heffner) Date: Tue May 25 22:58:11 2004 Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: <200405051501.01448.angus.leeming@btopenworld.com> Message-ID: On 05-May-2004 Angus Leeming wrote: | On Thursday 15 January 2004 5:30 am, Mike Heffner wrote: |> When fl_set_font_name() fails it will return -1 but it also prints: |> |> In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah |> |> This function is typically used as a method of testing whether a |> font is loadable or not, so it's not always a fatal condition. Can |> this print statement be wrapped in a debug-only conditional? | | Mike does this do the job: | - M_err("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); | + M_warn("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); | How about changing it to M_debug(...)? 'warn' and 'err' essentially always get printed (a bug for another day). Thanks, Mike -- Mike Heffner From angus.leeming at btopenworld.com Thu May 27 17:00:22 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 27 11:00:38 2004 Subject: [XForms] Where to add entry for forms.h In-Reply-To: <40B3DC09.9080209@comcast.net> References: <40B3DC09.9080209@comcast.net> Message-ID: <200405271600.22916.angus.leeming@btopenworld.com> On Wednesday 26 May 2004 12:51 am, Jeff wrote: > Angus, or anbody, Hello, Jeff. > Where do I add the line: > FL_CLIENT_CALLBACK client_callback; > so it appears in the forms structuer. I thnk it would go into > Basic.h. Sounds correct to me. That's where 'struct forms_' is defined. > But do I also need to adjust the line > int reserved[10]; /* future use */ > > to include the size of the new client_callback enty in struct > FL_FORM in Basic.h That would be nice. It will allow us to maintain binary compatibility with previous versions of the library. You'll want something like int reserved[10 - sizeof(FL_CLIENT_CALLBACK)]; > I also guess the header declaration > FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( > FL_FORM *form, > FL_CLIENT_CALLBACK rcb > ); > > Would also go into Basic.h. Sounds reasonable. > I want to finally submit this patch. Great! Angus From Jean-Marc.Lasgouttes at inria.fr Thu May 27 18:13:30 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu May 27 11:13:39 2004 Subject: [XForms] Where to add entry for forms.h In-Reply-To: <200405271600.22916.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 May 2004 16:00:22 +0100") References: <40B3DC09.9080209@comcast.net> <200405271600.22916.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> That would be nice. It will allow us to maintain binary Angus> compatibility with previous versions of the library. You'll Angus> want something like Angus> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)]; This is what I said earlier, but it is wrong. One needs something like int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; JMarc From angus.leeming at btopenworld.com Thu May 27 17:19:24 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 27 11:19:37 2004 Subject: [XForms] Where to add entry for forms.h In-Reply-To: References: <40B3DC09.9080209@comcast.net> <200405271600.22916.angus.leeming@btopenworld.com> Message-ID: <200405271619.24067.angus.leeming@btopenworld.com> On Thursday 27 May 2004 4:13 pm, Jean-Marc Lasgouttes wrote: > Angus> You'll want something like > Angus> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)]; > This is what I said earlier, but it is wrong. One needs something > like > int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; Just testing. ;-) Incidentally, assuming that this patch arrives, we now have two patches providing new functionality. The other one is the 'context sharing' patch from Jason Cipriani. I'd told Jason that I was not going to include his patch in 1.1 but I'm minded that there isn't actually *anything* new in 1.1, just bug fixes. Do you have any opinion on this? Angus ps, could I get you to roll 1.0.91, given that you made so little fuss getting 1.0.90 out of the door? A From Jean-Marc.Lasgouttes at inria.fr Thu May 27 18:31:43 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu May 27 11:31:48 2004 Subject: [XForms] Where to add entry for forms.h In-Reply-To: <200405271619.24067.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 May 2004 16:19:24 +0100") References: <40B3DC09.9080209@comcast.net> <200405271600.22916.angus.leeming@btopenworld.com> <200405271619.24067.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Incidentally, assuming that this patch arrives, we now have two Angus> patches providing new functionality. The other one is the Angus> 'context sharing' patch from Jason Cipriani. Angus> I'd told Jason that I was not going to include his patch in 1.1 Angus> but I'm minded that there isn't actually *anything* new in 1.1, Angus> just bug fixes. Do you have any opinion on this? I do not know really. Jeff's patch should clearly be harmless for people who do not use the functionality. I do not know enough about GL to know whether Jason's patch would be risky. Angus> ps, could I get you to roll 1.0.91, given that you made so Angus> little fuss getting 1.0.90 out of the door? When, right now? Do you plan it to be the last prerelease? In this case, we could name it 1.0.98 or something. JMarc From angus.leeming at btopenworld.com Thu May 27 17:42:14 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 27 11:43:17 2004 Subject: [XForms] Where to add entry for forms.h In-Reply-To: References: <40B3DC09.9080209@comcast.net> <200405271619.24067.angus.leeming@btopenworld.com> Message-ID: <200405271642.14309.angus.leeming@btopenworld.com> On Thursday 27 May 2004 4:31 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> Incidentally, assuming that this patch arrives, we now have > two Angus> patches providing new functionality. The other one is > the Angus> 'context sharing' patch from Jason Cipriani. > > Angus> I'd told Jason that I was not going to include his patch in > 1.1 Angus> but I'm minded that there isn't actually *anything* new > in 1.1, Angus> just bug fixes. Do you have any opinion on this? > > I do not know really. Jeff's patch should clearly be harmless for > people who do not use the functionality. Then it can go in. > I do not know enough about > GL to know whether Jason's patch would be risky. Me neither, but then again we won't know any better after we it is merged into the tree whenever this is done. Sometimes we just have to go on trust... > Angus> ps, could I get you to roll 1.0.91, given that you made so > Angus> little fuss getting 1.0.90 out of the door? > > When, right now? Do you plan it to be the last prerelease? In this > case, we could name it 1.0.98 or something. Given that Jeff's patch isn't yet here and that we believe it to be harmless, let's wait until it is merged into the tree. The only thing that I think isn't ready for the release of 1.1 proper is this line in configure.ac AC_SUBST(SO_VERSION, ["1:0:0"]) We should also address Lars' concerns about fdesign's output semantics and decide what to do with Jason's patch. Angus From Jean-Marc.Lasgouttes at inria.fr Thu May 27 18:47:06 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu May 27 11:47:11 2004 Subject: [XForms] Where to add entry for forms.h In-Reply-To: <200405271642.14309.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 May 2004 16:42:14 +0100") References: <40B3DC09.9080209@comcast.net> <200405271619.24067.angus.leeming@btopenworld.com> <200405271642.14309.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Me neither, but then again we won't know any better after we it Angus> is merged into the tree whenever this is done. Sometimes we Angus> just have to go on trust... Sure. Angus> The only thing that I think isn't ready for the release of 1.1 Angus> proper is this line in configure.ac AC_SUBST(SO_VERSION, Angus> ["1:0:0"]) Should not be too difficult. Angus> We should also address Lars' concerns about fdesign's output Angus> semantics and decide what to do with Jason's patch. Yes. Also, there is the doc update stuff. JMarc From wd4nmq at comcast.net Thu May 27 15:13:38 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu May 27 14:13:43 2004 Subject: [XForms] Patch help Message-ID: <40B62FD2.2020009@comcast.net> It's been many years since I have made a patch and I am having trouble creating one tht works with Xforms. I untar xforms-1.0.90 and then cp it to mine-1.0.90 and make my changes to files in mine-1.0.90. then from their base directory I run: diff -ruN xforms1.0.90 mine-1.0.90 > xforms.patch Now to test it I go to a vigin directory, copy xforms.patch there and untar xforms.1.0.90 again. Then I run patch -p0 xforms.patch But I get an error: patching file xforms-1.090/lib/forms.c Reversed (or previously applied) patch detected! Assume -R? [n] What am I doing wrong? I want to test out the patch before submitting it today. Jeff From jac4 at mindless.com Thu May 27 14:48:50 2004 From: jac4 at mindless.com (jason cipriani) Date: Thu May 27 14:48:56 2004 Subject: [XForms] Patch help Message-ID: <20040527184850.A39EB790046@ws1-14.us4.outblaze.com> Generate your diff file just like you are doing now: diff -ruN xforms1.0.90 mine-1.0.90 > xforms.patch Then download a fresh copy of xforms, untar it to say, fresh-1.0.90, then do: cd fresh-1.0.90 patch -p1 < ../xforms.patch Don't forget the < in patch. Most versions of 'patch' take input files that way, you can't specify them as command line parameters. The -p1 will tell patch to skip the "xforms1.0.90/" or "mine-1.0.90/" when getting file names from the patch file. Jason ----- Original Message ----- From: Jeff Date: Thu, 27 May 2004 14:13:38 -0400 To: xforms Subject: [XForms] Patch help > To subscribers of the xforms list > > > It's been many years since I have made a patch and I am having trouble > creating one tht works with Xforms. > > I untar xforms-1.0.90 and then cp it to mine-1.0.90 and make my changes > to files in mine-1.0.90. > then from their base directory I run: > > diff -ruN xforms1.0.90 mine-1.0.90 > xforms.patch > > Now to test it I go to a vigin directory, copy xforms.patch there and > untar xforms.1.0.90 again. Then I run > > patch -p0 xforms.patch > > But I get an error: > patching file xforms-1.090/lib/forms.c > Reversed (or previously applied) patch detected! Assume -R? [n] > > What am I doing wrong? > > I want to test out the patch before submitting it today. > > Jeff > > > _______________________________________________ > 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 -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Fri May 28 00:13:56 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 27 18:14:10 2004 Subject: [XForms] Shared GL contexts Message-ID: <200405272313.56243.angus.leeming@btopenworld.com> Jason, attached is your shared GL context patch in a form ready for inclusion in current XForms cvs. I've done little more than rename the files of the demo as demos/sgl.c demos/fd/sgl_gui.fd demos/fd/sgl_help.fd demos/fd/sgl_sub.fd with concommittant changes to the names of the FD_ structs. I've also ensured that the demo will #include forms.h and glcanvas.h from the tree rather than any already-installed versions. To build, I ran: $ ./autogen.sh $ mkdir build && cd build $ ../configure --enable-demos $ make I had a play with the demo. Very pretty ;-) Unfortuanately, I managed to shut down X11 when I exited from the demo. It doesn't do this everytime, but most definitely did do it once. I'd been playing with the main window quite a lot and had managed to 'turn off' the objects in the three left-most sub windows on the top row. I'd popped up the sub window and read the data in the help menu. I can't remember whether all three windows were open when I hit the 'Exit' button on the main form. At that point X died. I'll try and crash it again from within gdb, but this is just a heads up. Incidentally, does anyone know how I can pipe the output from gdb to a file? I'm not going to get much useful info if I run gdb from an xterm if I'm going to end up killing X... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: shared_gl_canvas.diff.gz Type: application/x-gzip Size: 18010 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040527/f294d6bb/shared_gl_canvas.diff.bin From wd4nmq at comcast.net Thu May 27 19:32:05 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu May 27 18:32:11 2004 Subject: [XForms] pathc to add client message callback Message-ID: <40B66C65.8080601@comcast.net> To all, Ok, here is the patch for adding the an X client message handling callback. Why did I do this? I had an app that periodically went to a server to get a list to display in a list box. However, when the server code was in the apps main execution thread the user was "locked out" while all the network DNS lookups, connection to, transfer from, and desconnection took place. Your input was locked out because your main form was not getting events, mouse, keyboard, etc, off of the X event queue. Now, my first step was to thread the server access code. This way the main form's event loop would still run while the data was being retrieved from the server. But, since the Xforms code is not re-entrant, the thread could not just update the xforms list box. You had to do strange girations in the main loop code using mutexes. It's explained in the Xforms manual. This seemed like a lot of work and added even more complexity as more "worker threads" were added. Plus, I had done a Windows C++ app, heh, it pays the bills, that does kinda of the same thing. I had the main thread that handled the gui, and several threads that monitored things and then sent messages to the gui thread's message loop to display the data. X also has a call to that, XSendEvent(). With this you can have different threads, or apps, send messages to another threads or apps windows. One of those messages is called a client message. Now, using the new fl_register_client_message() and fl_get_winID() calls, my server thread simply gets the data and uses XSendEvent() passing the pointer to the data to notify the main form to display the data. No mutexes waits or anthing else. We simply use the event queue that is already in place. As I stated, there are two new functions. The first is FL_EXPORT Window fl_get_winID( FL_FORM *form ); This returns the window id of the form. This is needed by XSendEvent() to know where to send the client message. FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( FL_FORM *form, FL_CLIENT_CALLBACK rcb ); It is used just like any of the xforms calls to register a callback. Here I use it to register clientCallback(). fl_register_client_callback(fd_testEvent->testEvent, (void *) clientCallback); int clientCallback(FL_FORM *form, XEvent *xev){ printf("We are in the client function, time = %d\n", xev->xclient.data.l[0]); return 1; } I then have a thread the periodically uses XSendEvent() to send the current time. Simplistic, but demonstrates it's use. Now you can have several worker threads and only one gui thread and no mutexes or delaying. All the worker threads just send their data via XSendEvent() to a client message event type. Now, there are ways in X to register data types called atoms to disquinish what the data format is. Just look on the web for Xlib Atoms. Also rad up on XSendEvent() which is an Xlib call. Angus and Jean-Marc, if you like I can write a manual section for this. Jeff -------------- next part -------------- diff -ruN xforms-1.0.90/lib/forms.c mine-1.0.90/lib/forms.c --- xforms-1.0.90/lib/forms.c 2003-11-21 09:09:46.000000000 -0500 +++ mine-1.0.90/lib/forms.c 2004-05-27 16:13:42.000000000 -0400 @@ -1666,7 +1666,12 @@ else { /* pump it thru current form */ - fl_handle_form(form, FL_OTHER, 0, xev); + if(form->client_callback){ + if(!form->client_callback(form, xev)) + fl_handle_form(form, FL_OTHER, 0, xev); + } + else + fl_handle_form(form, FL_OTHER, 0, xev); } } @@ -2258,6 +2263,16 @@ has_initial = 1; } +FL_CLIENT_CALLBACK +fl_register_client_callback(FL_FORM *form, FL_CLIENT_CALLBACK clientCallback){ + + FL_CLIENT_CALLBACK old_rcb; + + old_rcb =form->client_callback; + form->client_callback = clientCallback; + return old_rcb; +} + /* register pre-emptive event handlers */ FL_RAW_CALLBACK fl_register_raw_callback(FL_FORM * form, unsigned long mask, FL_RAW_CALLBACK rcb) @@ -2811,3 +2826,8 @@ } return len; } + +/**********************************/ +Window fl_get_winID(FL_FORM *form){ + return form->window; +} diff -ruN xforms-1.0.90/lib/include/Basic.h mine-1.0.90/lib/include/Basic.h --- xforms-1.0.90/lib/include/Basic.h 2003-09-08 20:28:25.000000000 -0400 +++ mine-1.0.90/lib/include/Basic.h 2004-05-27 17:25:37.000000000 -0400 @@ -579,6 +579,7 @@ /* preemptive callback function */ typedef int (*FL_RAW_CALLBACK) (struct forms_ *, void *); +typedef int (*FL_CLIENT_CALLBACK) (struct forms_ *, void *); /* at close (WM menu delete/close etc.) */ typedef int (*FL_FORM_ATCLOSE) (struct forms_ *, void *); @@ -662,7 +663,9 @@ void (*pre_attach)(struct forms_ *); void *attach_data; int no_tooltip; - int reserved[10]; /* future use */ + FL_CLIENT_CALLBACK client_callback; + /* future use */ + int reserved[10- sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; } FL_FORM; @@ -1016,6 +1019,10 @@ FL_FORM *form ); +FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( + FL_FORM *form, + FL_CLIENT_CALLBACK rcb + ); FL_EXPORT FL_RAW_CALLBACK fl_register_raw_callback( FL_FORM *form, diff -ruN xforms-1.0.90/lib/include/XBasic.h mine-1.0.90/lib/include/XBasic.h --- xforms-1.0.90/lib/include/XBasic.h 2003-09-08 20:28:25.000000000 -0400 +++ mine-1.0.90/lib/include/XBasic.h 2004-05-27 17:25:15.000000000 -0400 @@ -1028,6 +1028,10 @@ ); +FL_EXPORT Window fl_get_winID( + FL_FORM *form + ); + /* how we pack and unpack colors */ #ifndef FL_PCBITS typedef unsigned char FL_PCTYPE; /* primary color type */ diff -ruN xforms-1.0.90/lib/objects.c mine-1.0.90/lib/objects.c --- xforms-1.0.90/lib/objects.c 2003-09-08 20:28:25.000000000 -0400 +++ mine-1.0.90/lib/objects.c 2004-05-27 16:13:53.000000000 -0400 @@ -106,6 +106,7 @@ form->close_data = 0; form->icon_pixmap = form->icon_mask = 0; form->no_tooltip = 0; + form->client_callback = 0; return form; } From angus.leeming at btopenworld.com Fri May 28 01:07:14 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu May 27 19:07:41 2004 Subject: [XForms] Shared GL contexts Message-ID: <200405280007.14133.angus.leeming@btopenworld.com> On Thursday 27 May 2004 11:13 pm, Angus Leeming wrote: > Unfortuanately, I managed to shut down X11 when I exited from the > demo. It doesn't do this everytime, but most definitely did do it > once. It's actually very easy to do this. $ cd xforms/devel $ cd build $ make maintainer-clean $ cd .. $ rm -rf build $ patch -p0 < shared_gl_canvas.diff $ ./autogen.sh $ mkdir build && cd build $ ../configure --enable-demos $ make demos/sgl is the statically-linked executable. There's also a dynamically-linked executable hidden away in the demos/.libs directory. Now, the dynamically-linked executable isn't going to run as things stand, because the installed libformsGL.so doesn't contain the new functions. So, let's use the statically linked one. $ ./sgl The app pops up as expected. At this point, I'm going to save the mail in the expectation of crashing X. I'll return with the prescription... ... returning having crashed X, here's the prescription: If the 8 sub windows are labelled so: 1 2 3 4 5 6 7 8 Then I can crash X reproducibly by clicking on the buttons: 3:Visible --- hide sub window 3. 2:B --- the object changes to a cone 2:B -- the object disappears from sub windows 1 and 2. 2:C -- usually there is no apparent change. Occasionally X crashes. Exit -- X *always* crashes. Here I'm running a linux box with a stock Fedora Core 1 distribution. Angus From angus.leeming at btopenworld.com Fri May 28 11:51:12 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 28 05:56:42 2004 Subject: [XForms] [patch] fdesign output Message-ID: <200405281051.12382.angus.leeming@btopenworld.com> The attached patch ensures that fdesign outputs converted files in the current directory if no output_dir is specified. At present, they are output in the same directory as the .fd file. The patch also guarantees that 'build_fname' is safe against buffer overflows. fdesign -convert foo/bar/baz.fd will create bar.[ch] in the current directory. fdesign -dir some/other/dir -convert foo/bar/baz.fd will place bar.[ch] in some/other/dir, if it exists. The fdesign shipped with XForms 1.0 and earlier allowed only fdesign -convert baz.fd Ie, you had to be in the same directory as baz.fd in order to run the conversion. The change results in 'expected behaviour' and has been requested on the lyx list. I see no reason not to commit it, so will do so presently. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 2633 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040528/7ab4c462/fdesign.bin From Jean-Marc.Lasgouttes at inria.fr Fri May 28 13:53:09 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 28 06:53:13 2004 Subject: [XForms] [patch] fdesign output In-Reply-To: <200405281051.12382.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 May 2004 10:51:12 +0100") References: <200405281051.12382.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list The attached patch ensures Angus> that fdesign outputs converted files in the current directory Angus> if no output_dir is specified. At present, they are output in Angus> the same directory as the .fd file. Angus> The patch also guarantees that 'build_fname' is safe against Angus> buffer overflows. Looks good. What happens with the other converters? JMarc From angus.leeming at btopenworld.com Fri May 28 13:21:40 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 28 07:22:08 2004 Subject: [XForms] [patch] fdesign output In-Reply-To: References: <200405281051.12382.angus.leeming@btopenworld.com> Message-ID: <200405281221.40311.angus.leeming@btopenworld.com> On Friday 28 May 2004 11:53 am, Jean-Marc Lasgouttes wrote: > Angus> To subscribers of the xforms list The attached patch ensures > Angus> that fdesign outputs converted files in the current > directory Angus> if no output_dir is specified. At present, they > are output in Angus> the same directory as the .fd file. > > Angus> The patch also guarantees that 'build_fname' is safe against > Angus> buffer overflows. > > Looks good. What happens with the other converters? We pass the command line args to them and let them deal with it. All other converters are outside of our control. Ie, they're not part of the XForms library. See fd_forms.c, line 500-ish. From angus.leeming at btopenworld.com Fri May 28 13:36:55 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri May 28 07:37:09 2004 Subject: [XForms] pathc to add client message callback In-Reply-To: <40B66C65.8080601@comcast.net> References: <40B66C65.8080601@comcast.net> Message-ID: <200405281236.55512.angus.leeming@btopenworld.com> On Thursday 27 May 2004 11:32 pm, Jeff wrote: > To all, > > Ok, here is the patch for adding the an X client message handling > callback. Jeff, many thanks for this. Unfortunately, I won't have time to look at this properly until Tuesday. Jean-Marc, can I leave it to your tender care? Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri May 28 15:01:36 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 28 08:01:41 2004 Subject: [XForms] [patch] fdesign output In-Reply-To: <200405281221.40311.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 May 2004 12:21:40 +0100") References: <200405281051.12382.angus.leeming@btopenworld.com> <200405281221.40311.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Friday 28 May 2004 11:53 am, Jean-Marc Lasgouttes wrote: To Angus> subscribers of the xforms list The attached patch ensures that Angus> fdesign outputs converted files in the current >> directory Angus> if no output_dir is specified. At present, they >> are output in Angus> the same directory as the .fd file. >> Angus> The patch also guarantees that 'build_fname' is safe against Angus> buffer overflows. >> Looks good. What happens with the other converters? Angus> We pass the command line args to them and let them deal with Angus> it. All other converters are outside of our control. Ie, Angus> they're not part of the XForms library. See fd_forms.c, line Angus> 500-ish. We'll leave it like that, then. And is there something to do about fd2ps? I guess we do not care about this one until we get the doc sources, though. JMarc From Jean-Marc.Lasgouttes at inria.fr Fri May 28 15:02:48 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 28 08:02:53 2004 Subject: [XForms] pathc to add client message callback In-Reply-To: <200405281236.55512.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 May 2004 12:36:55 +0100") References: <40B66C65.8080601@comcast.net> <200405281236.55512.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Thursday 27 May 2004 11:32 pm, Jeff wrote: >> To all, >> >> Ok, here is the patch for adding the an X client message handling >> callback. Angus> Jeff, many thanks for this. Angus> Unfortunately, I won't have time to look at this properly until Angus> Tuesday. Jean-Marc, can I leave it to your tender care? I will not have much time until tuesday either, unfortunately (going to London...). JMarc From newsletter at hahnebach.com Fri May 28 17:13:16 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Fri May 28 10:13:13 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) Message-ID: <40B748FC.8020503@hahnebach.com> Hi, 1. just for information: Angus send me this link for information about xforms mailing list: http://cweblog.usuhs.mil/mailman/listinfo/xforms This link works well. As you see I just subscribed. The main page of xforms: http://world.std.com/~xforms/ points to: http://world.std.com/~xforms/new/mlist.html regarding mailing list. This page points to: *http://bob.usuf2.usuhs.mil/mailserv/xforms.html* --> The requested URL was not found on this server. 2. It's again about XStab. As I said the software compiles using xforms 0.88 as well as using xforms 1.0.x There is only one differences which is quit important. The decimal separator in the whole software is a dot using 0.88 and a comma using 1.0.x. The comma causes big problems. I would like to use xforms 1.0.x and the dot as decimal separator. Thanks for any help. Bernd From Jens.Toerring at physik.fu-berlin.de Fri May 28 17:46:45 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Fri May 28 10:46:49 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <40B748FC.8020503@hahnebach.com> References: <40B748FC.8020503@hahnebach.com> Message-ID: <20040528144559.GA6825@crowley.physik.fu-berlin.de> On Fri, May 28, 2004 at 04:13:16PM +0200, Bernd Hahnebach wrote: > 2. It's again about XStab. As I said the software compiles using xforms > 0.88 > as well as using xforms 1.0.x There is only one differences which is quit > important. The decimal separator in the whole software is a dot using > 0.88 and a comma using 1.0.x. The comma causes big problems. I would like to > use xforms 1.0.x and the dot as decimal separator. Newer versions of xforms seem to set the locale to the one set in the environment variables (caught me also unaware when that happened, suddenly lots of things stopped working...). You may have to tell it which one to use instead after the fl_initialize() call. I usually set it with setlocale( LC_NUMERIC, "C" ); directly after the flinitialize() call. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From Jean-Marc.Lasgouttes at inria.fr Fri May 28 17:55:50 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 28 10:55:55 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040528144559.GA6825@crowley.physik.fu-berlin.de> (Jens Thoms Toerring's message of "Fri, 28 May 2004 16:46:45 +0200") References: <40B748FC.8020503@hahnebach.com> <20040528144559.GA6825@crowley.physik.fu-berlin.de> Message-ID: >>>>> "Jens" == Jens Thoms Toerring writes: Jens> To subscribers of the xforms list Jens> On Fri, May 28, 2004 at 04:13:16PM +0200, Bernd Hahnebach wrote: >> 2. It's again about XStab. As I said the software compiles using >> xforms 0.88 as well as using xforms 1.0.x There is only one >> differences which is quit important. The decimal separator in the >> whole software is a dot using 0.88 and a comma using 1.0.x. The >> comma causes big problems. I would like to use xforms 1.0.x and the >> dot as decimal separator. Jens> Newer versions of xforms seem to set the locale to the one set Jens> in the environment variables (caught me also unaware when that Jens> happened, suddenly lots of things stopped working...). You may Jens> have to tell it which one to use instead after the Jens> fl_initialize() call. I usually set it with Jens> setlocale( LC_NUMERIC, "C" ); Jens> directly after the flinitialize() call. Yes, this began after xforms 0.89.5 and I do not really like it :( However, I am not sure that we should remove that now... JMarc From Jean-Marc.Lasgouttes at inria.fr Fri May 28 18:10:05 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri May 28 11:10:13 2004 Subject: [XForms] pathc to add client message callback In-Reply-To: <40B66C65.8080601@comcast.net> (wd4nmq@comcast.net's message of "Thu, 27 May 2004 18:32:05 -0400") References: <40B66C65.8080601@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list To all, Jeff> Ok, here is the patch for adding the an X client message Jeff> handling callback. Jeff, something that would be very nice is a ChangeLog entry describing what you did to each file/function. Also, a demo program (I think you had one) would be great. The patch lokks very good in general, but I have a few formatting nitpicks: /* pump it thru current form */ - fl_handle_form(form, FL_OTHER, 0, xev); + if(form->client_callback){ + if(!form->client_callback(form, xev)) + fl_handle_form(form, FL_OTHER, 0, xev); + } + else + fl_handle_form(form, FL_OTHER, 0, xev); } } Please respect the indentation conventions of the file: 4 characters for each nesting level. Also, you should add a space after "if (". +FL_CLIENT_CALLBACK +fl_register_client_callback(FL_FORM *form, FL_CLIENT_CALLBACK clientCallback){ + + FL_CLIENT_CALLBACK old_rcb; + + old_rcb =form->client_callback; + form->client_callback = clientCallback; + return old_rcb; +} Add a space after "=" above. Respect indentation. Put the opening brace of the function block on a line by itself. + +/**********************************/ +Window fl_get_winID(FL_FORM *form){ + return form->window; +} Is this really needed since FL_FORM->window is public (and documented?). Moreover, I do not think the name follows xforms conventions. +FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( + FL_FORM *form, + FL_CLIENT_CALLBACK rcb + ); Indentation seems to be made of two tabs in this file. +FL_EXPORT Window fl_get_winID( + FL_FORM *form + ); + here too. Don't feel put down by these remarks, I am just trying to keep the code style coherent. JMarc From Jens.Toerring at physik.fu-berlin.de Fri May 28 18:41:11 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Fri May 28 11:41:16 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: References: <40B748FC.8020503@hahnebach.com> <20040528144559.GA6825@crowley.physik.fu-berlin.de> Message-ID: <20040528154111.GA7046@crowley.physik.fu-berlin.de> On Fri, May 28, 2004 at 04:55:50PM +0200, Jean-Marc Lasgouttes wrote: > >>>>> "Jens" == Jens Thoms Toerring writes: > Jens> To subscribers of the xforms list > Jens> On Fri, May 28, 2004 at 04:13:16PM +0200, Bernd Hahnebach wrote: > >> 2. It's again about XStab. As I said the software compiles using > >> xforms 0.88 as well as using xforms 1.0.x There is only one > >> differences which is quit important. The decimal separator in the > >> whole software is a dot using 0.88 and a comma using 1.0.x. The > >> comma causes big problems. I would like to use xforms 1.0.x and the > >> dot as decimal separator. > > Jens> Newer versions of xforms seem to set the locale to the one set > Jens> in the environment variables (caught me also unaware when that > Jens> happened, suddenly lots of things stopped working...). You may > Jens> have to tell it which one to use instead after the > Jens> fl_initialize() call. I usually set it with > > Jens> setlocale( LC_NUMERIC, "C" ); > > Jens> directly after the flinitialize() call. > > Yes, this began after xforms 0.89.5 and I do not really like it :( > However, I am not sure that we should remove that now... I think it's a misfeature - if someone wants to set a locale (s)he knows where to find it, and changing it behinds ones back isn't the right thing IMHO. Especially since there's nothing that would force you to call fl_initialize() at the first thing in your program. So a different locale may have already been set, which then suddenly gets overwritten. And it's also rather astonishing when out of the blue e.g. scanf() looks for a comma as the decimal separator and you have never seen something like this before. Took me quite some time to figure out what was happening back then (I hadn't taken a closer look at locales before) and xforms was more or less the last suspect, I thought I had screwed up somewhere;-) Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From jac4 at mindless.com Fri May 28 11:45:08 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri May 28 11:45:11 2004 Subject: [XForms] Shared GL contexts Message-ID: <20040528154508.5AAEE79006A@ws1-14.us4.outblaze.com> > Here I'm running a linux box with a stock Fedora Core 1 distribution. That is the problem. I believe I mentioned this before but there's either a problem with Fedora 1 or a problem with the latest X server that causes apps that use GL to crash the server when they exit. The problem is not limited to the context sharing stuff, it is present in a clean 1.0.90 and 1.0 version of xforms as well. Here at work we switched two machines to Fedora, had that problem with both of them, then went back to using RH9. I have no idea what the cause is. Another way that I found to reproduce it was: 1) Create an xforms 1.0 or 1.0.90 application that uses GLCanvases and GL. 2) Run two instances of the application at the same time. 3) Close one of them. That always did it for me. I would also experience weird things like: 1) Create an xforms 1.0 or 1.0.90 application that uses GL and calls glLineWidth(5.0). 2) Run it, exit it, some times it crashes some times it doesn't. 3) Start a completely different GL application and note that the line width in that application is 5.0! Strange stuff like the GL states carrying across applications, and other things. Like I said, we could not figure out the cause at all. And it only happened in certain applications... but nothing about the way those applications were coded stood out from the applications that -did- work. PS: In fdesign/spec/glcanvas_spec.c I believe I inadvertently #included "forms.h" rather than "include/forms.h". Could you make sure that it's including the right thing? Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jac4 at mindless.com Fri May 28 11:51:36 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri May 28 11:51:43 2004 Subject: [XForms] Shared GL contexts Message-ID: <20040528155136.5BA6179006B@ws1-14.us4.outblaze.com> > If the 8 sub windows are labelled so: > 1 2 3 4 > 5 6 7 8 > > Then I can crash X reproducibly by clicking on the buttons: > 3:Visible --- hide sub window 3. > 2:B --- the object changes to a cone > 2:B -- the object disappears from sub windows 1 and 2. > 2:C -- usually there is no apparent change. Occasionally X crashes. > Exit -- X *always* crashes. Oops, I totally forgot in my last reply: On Redhat 9.0, this is not reproducible and the application works as it should: 3:Visible -- hide sub window 3 2:B -- object changes to a cone 2:B -- object remains a cone, does not disappear 2:C -- object changes to a sphere Exit -- application exits It also works correctly on OS X 10.3.3 and 10.3.4. We have obtained some Fedora Core 2 CDs so when I have more time I will see if the problem was fixed. Like I said, it seems very likely that it is a bug in Fedora Core 1 more than anything else. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From newsletter at hahnebach.com Fri May 28 19:27:24 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Fri May 28 12:27:20 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040528144559.GA6825@crowley.physik.fu-berlin.de> References: <40B748FC.8020503@hahnebach.com> <20040528144559.GA6825@crowley.physik.fu-berlin.de> Message-ID: <40B7686C.3070303@hahnebach.com> Thanks. I copied the line. I got the next problem. main.c:34: warning: return type of `main' is not `int' main.c: In function `main': main.c:48: warning: implicit declaration of function `setlocale' main.c:48: error: `LC_NUMERIC' undeclared (first use in this function) main.c:48: error: (Each undeclared identifier is reported only once main.c:48: error: for each function it appears in.) make[1]: *** [main.o] Fehler 1 make[1]: Leaving directory `/home/hugo/Documents/projekte/software/xstab/zprogramm/XStab/src' make: *** [srcs] Fehler 2 Bernd Jens Thoms Toerring schrieb: >To subscribers of the xforms list > > >On Fri, May 28, 2004 at 04:13:16PM +0200, Bernd Hahnebach wrote: > > >>2. It's again about XStab. As I said the software compiles using xforms >>0.88 >>as well as using xforms 1.0.x There is only one differences which is quit >>important. The decimal separator in the whole software is a dot using >>0.88 and a comma using 1.0.x. The comma causes big problems. I would like to >>use xforms 1.0.x and the dot as decimal separator. >> >> > >Newer versions of xforms seem to set the locale to the one set in the >environment variables (caught me also unaware when that happened, >suddenly lots of things stopped working...). You may have to tell it >which one to use instead after the fl_initialize() call. I usually set >it with > >setlocale( LC_NUMERIC, "C" ); > >directly after the flinitialize() call. > > Regards, Jens > > From jac4 at mindless.com Fri May 28 12:46:47 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri May 28 12:46:51 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) Message-ID: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> > Thanks. I copied the line. I got the next problem. > ... > main.c:48: warning: implicit declaration of function `setlocale' > main.c:48: error: `LC_NUMERIC' undeclared (first use in this function) > ... > Bernd I believe you also need to #include to use setlocale(). Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From Jens.Toerring at physik.fu-berlin.de Fri May 28 19:50:27 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Fri May 28 12:50:31 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <40B7686C.3070303@hahnebach.com> References: <40B748FC.8020503@hahnebach.com> <20040528144559.GA6825@crowley.physik.fu-berlin.de> <40B7686C.3070303@hahnebach.com> Message-ID: <20040528165027.GA7407@crowley.physik.fu-berlin.de> On Fri, May 28, 2004 at 06:27:24PM +0200, Bernd Hahnebach wrote: > To subscribers of the xforms list > Thanks. I copied the line. I got the next problem. > > main.c:34: warning: return type of `main' is not `int' > main.c: In function `main': > main.c:48: warning: implicit declaration of function `setlocale' > main.c:48: error: `LC_NUMERIC' undeclared (first use in this function) > main.c:48: error: (Each undeclared identifier is reported only once > main.c:48: error: for each function it appears in.) > make[1]: *** [main.o] Fehler 1 > make[1]: Leaving directory > `/home/hugo/Documents/projekte/software/xstab/zprogramm/XStab/src' > make: *** [srcs] Fehler 2 Did you include ? That's where the function is declared and the constants defined. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From davidwriter at yahoo.com Fri May 28 15:48:29 2004 From: davidwriter at yahoo.com (David Scriven) Date: Fri May 28 14:48:37 2004 Subject: [XForms] Shared GL contexts In-Reply-To: <20040528154508.5AAEE79006A@ws1-14.us4.outblaze.com> Message-ID: <20040528184830.56528.qmail@web60309.mail.yahoo.com> --- jason cipriani wrote: > To subscribers of the xforms list > > > > Here I'm running a linux box with a stock Fedora Core 1 > distribution. > > That is the problem. I believe I mentioned this before but there's > either a problem with Fedora 1 or a problem with the latest X server > that causes apps that use GL to crash the server when they exit. The > problem is not limited to the context sharing stuff, it is present in > a clean 1.0.90 and 1.0 version of xforms as well. > > Here at work we switched two machines to Fedora, had that problem > with both of them, then went back to using RH9. > > I have no idea what the cause is. Another way that I found to > reproduce it was: > > 1) Create an xforms 1.0 or 1.0.90 application that uses GLCanvases > and GL. > 2) Run two instances of the application at the same time. > 3) Close one of them. > This is rather worrying. It doesn't seem to be a problem with XForms-GL apps built with 0.89. I can run any number under Fedora and they don't seem to interact. My Fedora is fully updated and I'm using the latest NVIDIA driver - 5336. I've rebuilt the apps in Fedora with the latest g++, but I haven't rebuilt the XForms library - so it makes me wonder - is there something in XForms that is causing the problem? The only way to test this (I think) is to compile an app under Fedora and link it with both the old (0.89) library and the new to see if there is any difference in behaviour. > That always did it for me. I would also experience weird things like: > > 1) Create an xforms 1.0 or 1.0.90 application that uses GL and calls > glLineWidth(5.0). > 2) Run it, exit it, some times it crashes some times it doesn't. > 3) Start a completely different GL application and note that the line > width in that application is 5.0! > > Strange stuff like the GL states carrying across applications, and > other things. > > Like I said, we could not figure out the cause at all. And it only > happened in certain applications... but nothing about the way those > applications were coded stood out from the applications that -did- > work. > > PS: In fdesign/spec/glcanvas_spec.c I believe I inadvertently > #included "forms.h" rather than "include/forms.h". Could you make > sure that it's including the right thing? > > Jason > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > 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 newsletter at hahnebach.com Fri May 28 22:06:11 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Fri May 28 15:06:05 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> Message-ID: <40B78DA3.1010807@hahnebach.com> added to main.c: #include and directly under: fl_initialize(&argc,argv,version,0,0); setlocale( LC_NUMERIC, "C" ); XStab compiles but it still does commas instead of dots. I did the other way around just to have success. Using LANG=en_US before starting XStab works. Only dots dots dots :-) I don't want to bother you, but I still would like to find a solution. Bernd jason cipriani schrieb: >>Thanks. I copied the line. I got the next problem. >> ... >>main.c:48: warning: implicit declaration of function `setlocale' >>main.c:48: error: `LC_NUMERIC' undeclared (first use in this function) >> ... >>Bernd >> >> > >I believe you also need to #include to use setlocale(). > >Jason > > From Jens.Toerring at physik.fu-berlin.de Sat May 29 00:52:13 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Fri May 28 17:52:17 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <40B78DA3.1010807@hahnebach.com> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> Message-ID: <20040528215213.GA8172@crowley.physik.fu-berlin.de> On Fri, May 28, 2004 at 09:06:11PM +0200, Bernd Hahnebach wrote: > added to main.c: > > #include > > and directly under: fl_initialize(&argc,argv,version,0,0); > setlocale( LC_NUMERIC, "C" ); > > XStab compiles but it still does commas instead of dots. > > I did the other way around just to have success. Using > LANG=en_US before starting XStab works. Only dots dots dots :-) > > I don't want to bother you, but I still would like to find a solution. In what context do the commata (or commas or what's the correct plural of comma in English?) appear instead of dots? If you have a look at the man page for setlocale() you'll see that there several other categories you could set beside LC_NUMERIC (which I set exclusively because I don't care about the rest). Perhaps you get better results when you use instead setlocale( LC_ALL, "C" ); That should take care of all categories and hopefully get rid of your problem. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From newsletter at hahnebach.com Sat May 29 16:51:05 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Sat May 29 09:50:58 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040528215213.GA8172@crowley.physik.fu-berlin.de> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> Message-ID: <40B89549.5030506@hahnebach.com> It does not get rid of my problem. LC_NUMERIC or ALL seams not to be problem. Nothing changes it does not matter what I use. It is about all numbers in the whole program. e.g.: input data (it does piiiiep if I try to input a dot), output on screen, output to file, there is coordinate system with numbers on screen.... All numbers have a comma respectively a dot using LANG=C I read man page of setlocale and locale (Thanks, I did not know about.) but could not find something that helps. Bernd sitting in front of my computer and look for the big hammer ;-) Jens Thoms Toerring schrieb: >To subscribers of the xforms list > > >On Fri, May 28, 2004 at 09:06:11PM +0200, Bernd Hahnebach wrote: > > >>added to main.c: >> >>#include >> >>and directly under: fl_initialize(&argc,argv,version,0,0); >>setlocale( LC_NUMERIC, "C" ); >> >>XStab compiles but it still does commas instead of dots. >> >>I did the other way around just to have success. Using >>LANG=en_US before starting XStab works. Only dots dots dots :-) >> >>I don't want to bother you, but I still would like to find a solution. >> >> > >In what context do the commata (or commas or what's the correct >plural of comma in English?) appear instead of dots? If you have >a look at the man page for setlocale() you'll see that there >several other categories you could set beside LC_NUMERIC (which >I set exclusively because I don't care about the rest). Perhaps >you get better results when you use instead > >setlocale( LC_ALL, "C" ); > >That should take care of all categories and hopefully get rid of >your problem. > Regards, Jens > > From Jens.Toerring at physik.fu-berlin.de Sat May 29 19:54:13 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Sat May 29 12:54:16 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <40B89549.5030506@hahnebach.com> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> <40B89549.5030506@hahnebach.com> Message-ID: <20040529165413.GA11663@crowley.physik.fu-berlin.de> On Sat, May 29, 2004 at 03:51:05PM +0200, Bernd Hahnebach wrote: > It does not get rid of my problem. LC_NUMERIC or ALL seams > not to be problem. Nothing changes it does not matter what I use. > > It is about all numbers in the whole program. > e.g.: input data (it does piiiiep if I try to input a dot), output on > screen, > output to file, there is coordinate system with numbers on screen.... > All numbers have a comma respectively a dot using LANG=C That's strange, especially since it seems to pick up the locale from the environment variable... Could it be some trivial reason like that you by some misfortune don't invoke the new version where you added the setlocale() call? That could happen when you e.g. didn't install the new version and instead try to start it from within the directory where the new executable is and you use the command "progname" instead of "./progname" while your PATH isn't set up to look in the current directory first... Can you publish the sources somewhere (or send them to me via email)? > sitting in front of my computer and look for the big hammer ;-) Don't let it mess up your weekend;-) Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From Jens.Toerring at physik.fu-berlin.de Sun May 30 17:46:42 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Sun May 30 10:46:49 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040529165413.GA11663@crowley.physik.fu-berlin.de> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> <40B89549.5030506@hahnebach.com> <20040529165413.GA11663@crowley.physik.fu-berlin.de> Message-ID: <20040530144642.GA15263@crowley.physik.fu-berlin.de> Hi, for those still interested in the setlocale() etc. question here some new observations: On an older Linux machine (with 2.2.4 libc) setting the locale back to "C" works as expected - i.e. if my LANG environment variable is "de_DE" (for German, where a comma instead of a dot is used as the decimal separator) I afterwards can use the dot in input and it gets printed out in output. With a newer Linux machine (libc 2.3.2) this doesn't work anymore. Even after having the setlocale() call immediately after the call of fl_initialize() does not help. On both I am using XForms 1.0.0. With a test program (not using XForms) I can correctly switch between the locales. On the newer Linux machine, when I switch the locale to "C" after fl_initialize() it gets switched back to "de_DE" in the first call of fl_show_form(). Up till now I couldn't figure out where exactly this happens within fl_show_form. Whatever the reasons I would strongly suggest to throw out all that locale switching from XForms - messing around with this is really annoying, especially since it hits you in unexpected places. Take for example a command line program that reads in some double data. This works perfectly well with data with a dot as decimal separator since the start locale is always "C" when the program start. But when you then add a GUI using XForms it suddenly breaks since XForms believes it's more clever than the programmer and switches from "C" to "de_DE". This is especially going to be a problem with programs written by let's say an American (who usually doesn't even have to be aware off all this because it always works with both the "C" and the "en_US" locale) and which is then run by someone else in Germany, with LANG set to "de_DE". Suddenly the program does not work anymore for some completely mysterious reasons (it may be just some output some cryptic error message like "Invalid data in input file".) Neither the american programmer nor the german user will have any good clues about what happens - the same file works perfectly well for the american programmer and coming up with the explanation will take lots of time and communication. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de \__________________________ http://www.toerring.de From Jean-Marc.Lasgouttes at inria.fr Tue Jun 1 12:35:46 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Jun 1 05:35:58 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040530144642.GA15263@crowley.physik.fu-berlin.de> (Jens Thoms Toerring's message of "Sun, 30 May 2004 16:46:42 +0200") References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> <40B89549.5030506@hahnebach.com> <20040529165413.GA11663@crowley.physik.fu-berlin.de> <20040530144642.GA15263@crowley.physik.fu-berlin.de> Message-ID: >>>>> "Jens" == Jens Thoms Toerring writes: Jens> On an older Linux machine (with 2.2.4 libc) setting the locale Jens> back to "C" works as expected - i.e. if my LANG environment Jens> variable is "de_DE" (for German, where a comma instead of a dot Jens> is used as the decimal separator) I afterwards can use the dot Jens> in input and it gets printed out in output. Jens> With a newer Linux machine (libc 2.3.2) this doesn't work Jens> anymore. Even after having the setlocale() call immediately Jens> after the call of fl_initialize() does not help. Are using SuSE and the xforms version shipped with it? If you do, then you should update to the latest revision of the xforms package, which has a bug like this one fixed. Their version of xforms includes a still not official internationalization patch (to allow entering CJK characters) whic had problems. This got debugged on the LyX list a few months ago. Hope this helps. JMarc From angus.leeming at btopenworld.com Tue Jun 1 11:50:29 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Jun 1 05:52:27 2004 Subject: [XForms] Shared GL contexts In-Reply-To: <20040528154508.5AAEE79006A@ws1-14.us4.outblaze.com> References: <20040528154508.5AAEE79006A@ws1-14.us4.outblaze.com> Message-ID: <200406011050.29301.angus.leeming@btopenworld.com> On Friday 28 May 2004 4:45 pm, jason cipriani wrote: > PS: In fdesign/spec/glcanvas_spec.c I believe I inadvertently > #included "forms.h" rather than "include/forms.h". Could you make > sure that it's including the right thing? Done in my local copy. Angus From angus.leeming at btopenworld.com Tue Jun 1 12:02:41 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Jun 1 06:02:54 2004 Subject: [XForms] Shared GL contexts In-Reply-To: <20040528184830.56528.qmail@web60309.mail.yahoo.com> References: <20040528184830.56528.qmail@web60309.mail.yahoo.com> Message-ID: <200406011102.41477.angus.leeming@btopenworld.com> On Friday 28 May 2004 7:48 pm, David Scriven wrote: > > I have no idea what the cause is. Another way that I found to > > reproduce it was: > > > > 1) Create an xforms 1.0 or 1.0.90 application that uses > > GLCanvases and GL. > > 2) Run two instances of the application at the same time. > > 3) Close one of them. > > This is rather worrying. It doesn't seem to be a problem with > XForms-GL apps built with 0.89. I can run any number under > Fedora and they don't seem to interact. My Fedora is fully > updated and I'm using the latest NVIDIA driver - 5336. > > I've rebuilt the apps in Fedora with the latest g++, but I haven't > rebuilt the XForms library - so it makes me wonder - is there > something in XForms that is causing the problem? The only way > to test this (I think) is to compile an app under Fedora and > link it with both the old (0.89) library and the new to see > if there is any difference in behaviour. I cannot reproduce this with the two GL demo apps, demos/gl and demos/glwin. Jason, can you supply me with a minimal GL code that compiles and runs correctly under XForms 0.89 but which demonstrates this problem under XForms >= 1.0? We can possibly get TC to provide a copy of the 0.89 sources to help track down the offending change. Angus From jac4 at mindless.com Tue Jun 1 08:59:59 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue Jun 1 09:00:05 2004 Subject: [XForms] Shared GL contexts Message-ID: <20040601125959.B4F33101D7@ws1-3.us4.outblaze.com> > Jason, can you supply me with a minimal GL code that compiles and runs > correctly under XForms 0.89 but which demonstrates this problem under > XForms >= 1.0? Unfortunately, no... I don't have a spare machine to install Fedora on at this time. And I am not so sure that the problem doesn't occur on 0.89 as well... I've never tried it. It was somebody else that said that. I'll see if I can't find an extra hard drive laying around somewhere to throw Fedora on but it might be a while before I can get you some examples. Sorry :/ -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Tue Jun 1 17:03:17 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Jun 1 11:03:26 2004 Subject: [XForms] What does this 'ugly hack' do? Message-ID: <200406011603.17886.angus.leeming@btopenworld.com> I've played with the pop ups and can discern no change of behaviour after making the attached change. Obviously, I'm missing something. Can anyone provide me with some insight, or a methodology to see the change in behaviour? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: forms.diff Type: text/x-diff Size: 593 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040601/81a7a384/forms.bin From Gayle.C.Roth at nasa.gov Tue Jun 1 13:13:44 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Tue Jun 1 12:13:51 2004 Subject: [XForms] version 1.0.90 regarding forms.h Message-ID: <5.1.1.5.2.20040601120606.01679150@popserve.grc.nasa.gov> Hi. I have a question. While trying to port the forms library (version 1.0.90) to OpenVMS, I discovered that forms.h is no longer being distributed. I subsequently read the changelog file and found out that it's now automatically generated. Unfortunately for me, the mechanism for doing this is tucked into Makefile.am, which is useless on an OpenVMS system without GNV. Does anyone know of some way to generate forms.h on a non-UNIX system? Any help is appreciated. Thanks. - Gayle From angus.leeming at btopenworld.com Tue Jun 1 18:41:47 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Jun 1 12:41:57 2004 Subject: [XForms] version 1.0.90 regarding forms.h In-Reply-To: <5.1.1.5.2.20040601120606.01679150@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040601120606.01679150@popserve.grc.nasa.gov> Message-ID: <200406011741.47902.angus.leeming@btopenworld.com> WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site's MIMEDefang policy, contact Robert Williams . For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment named gen_forms_h.sh was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. -------------- next part -------------- On Tuesday 01 June 2004 5:13 pm, Gayle C Roth wrote: > To subscribers of the xforms list > > > Hi. > > I have a question. While trying to port the forms library (version > 1.0.90) to OpenVMS, I discovered that forms.h is no longer being > distributed. I subsequently read the changelog file and found out > that it's now automatically generated. Unfortunately for me, the > mechanism for doing this is tucked into Makefile.am, which is > useless on an OpenVMS system without GNV. Does anyone know of some > way to generate forms.h on a non-UNIX system? > > Any help is appreciated. Thanks. Hi, Gayle. forms.h is generated from AAA.h and the files listed in the noinst_HEADERS target of Makefile.am (all in the lib/include directory.) The code doing this work is found in the stamp-forms target of Makefile.am. AAA.h is generated at configure-time from AAA.h.in. That is, autoconf relplaces the '@' delimited variables in AAA.h.in with the values specified in $top/configure.ac: [angus@boris devel]$ diff -u lib/include/AAA.h.in build/lib/include/AAA.h --- lib/include/AAA.h.in 2003-09-09 01:28:25.000000000 +0100 +++ build/lib/include/AAA.h 2004-05-28 00:08:46.000000000 +0100 @@ -54,9 +54,9 @@ #ifndef FL_FORMS_H #define FL_FORMS_H -#define FL_VERSION @FL_VERSION@ -#define FL_REVISION @FL_REVISION@ -#define FL_FIXLEVEL @FL_FIXLEVEL@ +#define FL_VERSION 1 +#define FL_REVISION 0 +#define FL_FIXLEVEL 90 #define FL_INCLUDE_VERSION (FL_VERSION * 1000 + FL_REVISION) #include If you want to generate forms.h yourself, then a little shell script should do the job. Running the attached gen_forms_h.sh from the lib/include directory as sh gen_forms_h.sh works for me... Regards, Angus From angus.leeming at btopenworld.com Tue Jun 1 18:48:40 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Jun 1 12:48:48 2004 Subject: [XForms] version 1.0.90 regarding forms.h In-Reply-To: <200406011741.47902.angus.leeming@btopenworld.com> References: <5.1.1.5.2.20040601120606.01679150@popserve.grc.nasa.gov> <200406011741.47902.angus.leeming@btopenworld.com> Message-ID: <200406011748.40141.angus.leeming@btopenworld.com> On Tuesday 01 June 2004 5:41 pm, Angus Leeming wrote: > If you want to generate forms.h yourself, then a little shell > script should do the job. Running the attached gen_forms_h.sh from > the lib/include directory as > sh gen_forms_h.sh > works for me... ... > WARNING: This e-mail has been altered by MIMEDefang. Following > this paragraph are indications of the actual changes made. For > more information about your site's MIMEDefang policy, contact > Robert Williams . For more information about > MIMEDefang, see: > > http://www.roaringpenguin.com/mimedefang/enduser.php3 > > An attachment named gen_forms_h.sh was removed from this document > as it constituted a security hazard. If you require this document, > please contact the sender and arrange an alternate means of > receiving it. Oh, bother. Renaming the offending script as gen_forms_h_sh... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: gen_forms_h_sh Type: application/x-shellscript Size: 768 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040601/99c54b44/gen_forms_h_sh.bin From Gayle.C.Roth at nasa.gov Tue Jun 1 18:02:04 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Tue Jun 1 17:02:10 2004 Subject: [XForms] Building xforms library (1.0.90) Message-ID: <5.1.1.5.2.20040601164852.017d5e98@popserve.grc.nasa.gov> Hi. Angus, you solved my previous problem so well (the missing forms.h one) that I'm going to throw another one at you... when I tried to compile (on VMS) the 1st C source, I got an error on the following statement in FLINTERNAL.H: typedef RETSIGTYPE(*FL_OSSIG_HANDLER) (int); It said: found '*' when expecting one of : ,... I think the type 'RETSIGTYPE' isn't defined at that point. I noticed by searching for RETSIGTYPE that some of the times it's supposed to be void but not necessarily all the time. So what should I do? Thanks, Gayle From angus.leeming at btopenworld.com Tue Jun 1 23:27:11 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Jun 1 17:27:21 2004 Subject: [XForms] Building xforms library (1.0.90) In-Reply-To: <5.1.1.5.2.20040601164852.017d5e98@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040601164852.017d5e98@popserve.grc.nasa.gov> Message-ID: <200406012227.11177.angus.leeming@btopenworld.com> On Tuesday 01 June 2004 10:02 pm, Gayle C Roth wrote: > To subscribers of the xforms list > > > Hi. > > Angus, you solved my previous problem so well (the missing forms.h > one) that I'm going to throw another one at you... when I tried to > compile (on VMS) the 1st C source, I got an error on the following > statement in FLINTERNAL.H: > > typedef RETSIGTYPE(*FL_OSSIG_HANDLER) (int); > > It said: found '*' when expecting one of : ,... > > I think the type 'RETSIGTYPE' isn't defined at that point. I > noticed by searching for RETSIGTYPE that some of the times it's > supposed to be void but not necessarily all the time. So what > should I do? Let's see: $ grep -r RETSIGTYPE lib lib/flinternal.h:typedef RETSIGTYPE(*FL_OSSIG_HANDLER) (int); lib/signal.c:static RETSIGTYPE lib/signal.c:#ifndef RETSIGTYPE_IS_VOID lib/config.h.in:#undef RETSIGTYPE lib/config.h.in:#undef RETSIGTYPE_IS_VOID $ grep RETSIGTYPE build/lib/config.h #define RETSIGTYPE void #define RETSIGTYPE_IS_VOID 1 config.h is a file generated by the configure script from config.h.in which, in turn, is generated by autoconf from configure.ac. Given that you don't have the autotools at your disposal, I'm attaching both so that you can create your own config.h using config.h.in as a template. Here, on linux, 'man signal' gives me this signature, confirming that RETSIGTYPE should be 'void' on this platform. #include typedef void (*sighandler_t)(int); Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: config.h.in Type: text/x-csrc Size: 4336 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040601/f0925261/config.h.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: config.h Type: text/x-chdr Size: 4594 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040601/f0925261/config.bin From newsletter at hahnebach.com Wed Jun 2 01:32:55 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Tue Jun 1 18:32:49 2004 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> <40B89549.5030506@hahnebach.com> <20040529165413.GA11663@crowley.physik.fu-berlin.de> <20040530144642.GA15263@crowley.physik.fu-berlin.de> Message-ID: <40BD0417.6040801@hahnebach.com> Yep, thats it. Just installed xforms 1.0.90. It works. Thanks. Jean-Marc Lasgouttes schrieb: >Are using SuSE and the xforms version shipped with it? If you do, then >you should update to the latest revision of the xforms package, which >has a bug like this one fixed. Their version of xforms includes a >still not official internationalization patch (to allow entering CJK >characters) whic had problems. This got debugged on the LyX list a few >months ago. > >Hope this helps. > >JMarc > > > > From newsletter at hahnebach.com Wed Jun 2 01:35:07 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Tue Jun 1 18:34:59 2004 Subject: [XForms] How to tell my computer he should use a spezified version of xforms? Message-ID: <40BD049B.7000109@hahnebach.com> Hi, As a result of dot vs. comm problem I installed xforms 1.0.90 from source code. For compilation of my software it is easy to tell which version of the library should be used. Compiling my software using static labrary it works. Asuming I compile using shared library. I have got a problem. How do I know which library is my computer using during run time of my software? How can I tell him which library should he use? Both are versions 1.0.x Bernd From angus.leeming at btopenworld.com Wed Jun 2 00:56:24 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Jun 1 18:56:49 2004 Subject: [XForms] How to tell my computer he should use a spezified version of xforms? In-Reply-To: <40BD049B.7000109@hahnebach.com> References: <40BD049B.7000109@hahnebach.com> Message-ID: <200406012356.24186.angus.leeming@btopenworld.com> On Tuesday 01 June 2004 11:35 pm, Bernd Hahnebach wrote: > To subscribers of the xforms list > > > Hi, > > As a result of dot vs. comm problem I installed xforms 1.0.90 from > source code. For compilation of my software it is easy to tell > which version of the library should be used. Compiling my software > using static labrary it works. > > Asuming I compile using > shared library. I have got a problem. How do I know which > library is my computer using during run time of my software? > How can I tell him which library should he use? > > Both are versions 1.0.x Hi, Bernd. Generally speaking, a link line such as $ cc -o trial trial.c -lforms -lX11 will link against the .so versions of the libraries if the compiler can find them. On linux, $ ldd ./trial will list the shared object dependencies. If you look closely, you'll find that you have created executables fdesign and fd2ps, linked both statically and dynamically. The static version of fdesign is found in $build_tree/fdesign/fdesign whilst the dynamic version is found in $build_tree/fdesign/.libs/fdesign $ cd fdesign $ ldd ./fdesign not a dynamic executable $ ldd .libs/fdesign libforms.so.1 => /usr/local/lib/libforms.so.1 (0x005f6000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00513000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x00a4e000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x00ba4000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00181000) libc.so.6 => /lib/tls/libc.so.6 (0x0029c000) libm.so.6 => /lib/tls/libm.so.6 (0x008a7000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x004cc000) libdl.so.2 => /lib/libdl.so.2 (0x00111000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00eda000) It is the dynamicly-linked version that is installed. The simplest way to make the two versions of your executable is: Dynamically-linked: $ gcc -o trial trial.c Staticly-linked: $ gcc -static -o trial trial.c If you don't use gcc, then 'man cc' is your friend. HTH, Angus From Gayle.C.Roth at nasa.gov Thu Jun 3 12:28:19 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Thu Jun 3 11:28:27 2004 Subject: [XForms] can't find file Message-ID: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> Hi. I ran into another stumbling block in my effort to build the xforms library on an OpenVMS system (surprise, surprise :) ). The build procedure was doing fine until it tried to compile [.xforms.lib]listdir.c. Then, I got the error message "Cannot find file vms_readdir.c" which, indeed, is not to be found. This leads me to ask the following questions: 1) Is this file necessary for building the xforms library on OpenVMS? 2) If yes, how can I generate it or the information contained in it? 3) What does it do? Thanks, Gayle From angus.leeming at btopenworld.com Thu Jun 3 17:40:16 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Jun 3 11:40:40 2004 Subject: [XForms] can't find file In-Reply-To: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> Message-ID: <200406031640.16048.angus.leeming@btopenworld.com> On Thursday 03 June 2004 4:28 pm, Gayle C Roth wrote: > Hi. > > I ran into another stumbling block in my effort to build the xforms > library on an OpenVMS system (surprise, surprise :) ). The build > procedure was doing fine until it tried to compile > [.xforms.lib]listdir.c. Then, I got the error message "Cannot find > file vms_readdir.c" which, indeed, is not to be found. This leads > me to ask the following questions: > > 1) Is this file necessary for building the xforms library on > OpenVMS? 2) If yes, how can I generate it or the information > contained in it? 3) What does it do? Ahhhh. The file *does* exist in the cvs tree, but is not packaged in the distribution. That's an oversight which I'll correct immediately. The file is attached. Shove it in [.xforms.lib] Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: vms_readdir.c.gz Type: application/x-gzip Size: 4783 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040603/bfbd8d44/vms_readdir.c.bin From angus.leeming at btopenworld.com Thu Jun 3 17:42:55 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Jun 3 11:43:03 2004 Subject: [XForms] can't find file In-Reply-To: <200406031640.16048.angus.leeming@btopenworld.com> References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> <200406031640.16048.angus.leeming@btopenworld.com> Message-ID: <200406031642.55983.angus.leeming@btopenworld.com> On Thursday 03 June 2004 4:40 pm, Angus Leeming wrote: > Ahhhh. The file *does* exist in the cvs tree, but is not packaged > in the distribution. That's an oversight which I'll correct > immediately. > > The file is attached. Shove it in [.xforms.lib] You'll also need dirent_vms.h. Same problem. Also attached. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: dirent_vms.h Type: text/x-chdr Size: 1967 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040603/d48bb2e8/dirent_vms.bin From newsletter at hahnebach.com Fri Jun 4 02:10:09 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Thu Jun 3 19:10:05 2004 Subject: [XForms] How to tell my computer he should use a spezified version of xforms? In-Reply-To: <200406012356.24186.angus.leeming@btopenworld.com> References: <40BD049B.7000109@hahnebach.com> <200406012356.24186.angus.leeming@btopenworld.com> Message-ID: <40BFAFD1.2050902@hahnebach.com> Thanks, for help. They weren't exactly what I was looking for, but they really got me on the way. After playing around using your tips, xforms hello world example, ldd, ldconfig, a short description of gcc compilerflaggs (man gcc is quit a BIG friend :-)) I found what I was looking for. Bernd Angus Leeming schrieb: >To subscribers of the xforms list > > >On Tuesday 01 June 2004 11:35 pm, Bernd Hahnebach wrote: > > >>To subscribers of the xforms list >> >> >>Hi, >> >>As a result of dot vs. comm problem I installed xforms 1.0.90 from >>source code. For compilation of my software it is easy to tell >>which version of the library should be used. Compiling my software >>using static labrary it works. >> >>Asuming I compile using >>shared library. I have got a problem. How do I know which >>library is my computer using during run time of my software? >>How can I tell him which library should he use? >> >>Both are versions 1.0.x >> >> > >Hi, Bernd. > >Generally speaking, a link line such as > >$ cc -o trial trial.c -lforms -lX11 > >will link against the .so versions of the libraries if the compiler >can find them. > >On linux, >$ ldd ./trial >will list the shared object dependencies. > >If you look closely, you'll find that you have created executables >fdesign and fd2ps, linked both statically and dynamically. > >The static version of fdesign is found in $build_tree/fdesign/fdesign >whilst the dynamic version is found in >$build_tree/fdesign/.libs/fdesign > >$ cd fdesign >$ ldd ./fdesign > not a dynamic executable >$ ldd .libs/fdesign > libforms.so.1 => /usr/local/lib/libforms.so.1 (0x005f6000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00513000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x00a4e000) > libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x00ba4000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00181000) > libc.so.6 => /lib/tls/libc.so.6 (0x0029c000) > libm.so.6 => /lib/tls/libm.so.6 (0x008a7000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x004cc000) > libdl.so.2 => /lib/libdl.so.2 (0x00111000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00eda000) > >It is the dynamicly-linked version that is installed. > >The simplest way to make the two versions of your executable is: > >Dynamically-linked: >$ gcc -o trial trial.c > >Staticly-linked: >$ gcc -static -o trial trial.c > >If you don't use gcc, then 'man cc' is your friend. > >HTH, >Angus > >_______________________________________________ >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 angus.leeming at btopenworld.com Fri Jun 4 10:32:49 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 04:33:51 2004 Subject: [XForms] can't find file In-Reply-To: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> Message-ID: <200406040932.49826.angus.leeming@btopenworld.com> On Thursday 03 June 2004 4:28 pm, Gayle C Roth wrote: > To subscribers of the xforms list > Hi. > > I ran into another stumbling block in my effort to build the xforms > library on an OpenVMS system (surprise, surprise :) ). The build > procedure was doing fine until it tried to compile > [.xforms.lib]listdir.c. Then, I got the error message "Cannot find > file vms_readdir.c" which, indeed, is not to be found. This leads > me to ask the following questions: Gayle, it occurred to me last night that you're trying to compile the xforms-1.0.90.tar.gz prelease, right? If that is the case, all this noise about the gnu autotools has been, well, just noise. These tools do no more than * generate the configure script in the top level directory from configure.ac * generate files Makefile.in in each directory from the corresponding Makefile.am both sets of files should exist already in the prerelease. That being the case, then you should be able to build XForms in identical manner to me: mkdir build cd build ../configure --enable-demos make The configure step will generate lib/config.h in the build tree together with Makefiles from the corresponding Makefile.in files. Of course, you'll still need to shove the missing vms_readdir.c and dirent_vms.h files in the lib directory of the src tree. Let me know. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 12:03:44 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 4 05:03:49 2004 Subject: [XForms] can't find file In-Reply-To: <200406040932.49826.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 09:32:49 +0100") References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> <200406040932.49826.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> That being the case, then you should be able to build XForms in Angus> identical manner to me: Angus> mkdir build cd build ../configure --enable-demos make Angus, I do not think that configure scripts work under vms... I may be wrong, of course. JMarc From angus.leeming at btopenworld.com Fri Jun 4 11:17:05 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 05:17:12 2004 Subject: [XForms] can't find file In-Reply-To: References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> <200406040932.49826.angus.leeming@btopenworld.com> Message-ID: <200406041017.05210.angus.leeming@btopenworld.com> On Friday 04 June 2004 10:03 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> That being the case, then you should be able to build XForms > in Angus> identical manner to me: > > Angus> mkdir build cd build ../configure --enable-demos make > > Angus, I do not think that configure scripts work under vms... I > may be wrong, of course. GNV includes a port of bash to VMS. http://gnv.sourceforge.net/ GNU's Not VMS! GNV is a GNU based project, delivering a Unix environment for OpenVMS. It is intended to provide the important subset of Unix/Linux/POSIX necessary to port UNIX OpenSource software to OpenVMS. GNV consists of two parts: a Unix like shell environment and the CTRL Supplemental Library which provides functions typically found on Unix systems, but are missing, incomplete, or incorrect on VMS. Many OpenSource software packages ship a source tarball. When extracted, the software is built by running the 'configure' script, followed by a 'make'. This procedure examines features of the Unix system your running on, and builds the sofware package accordingly. This process may also work on an OpenVMS system, using the BASH shell provided by GNV. It is a goal of the GNV project to improve the porting of such OpenSource projects to OpenVMS. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 12:33:34 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 4 05:33:39 2004 Subject: [XForms] can't find file In-Reply-To: <200406041017.05210.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 10:17:05 +0100") References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> <200406040932.49826.angus.leeming@btopenworld.com> <200406041017.05210.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> GNV includes a port of bash to VMS. http://gnv.sourceforge.net/ OK, so it's only the autotools that do not work yet... Thanks for clearing things up. JMarc From angus.leeming at btopenworld.com Fri Jun 4 12:25:46 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 06:25:53 2004 Subject: [XForms] Fixing the popups? Message-ID: <200406041125.46406.angus.leeming@btopenworld.com> Jean-Marc, this patch removes the 'ugly hack' in forms.c and tries to do the 'right thing' in xpopup.c. My testing suggests that the popups in LyX are behaving 'better', but you're the one who's more familiar with those problems. Could you try it out? I'd value some feedback about any changes to the user experience, good or bad. A side effect is that the scrollbar will now work correctly in LyX when linked against XForms cvs. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: popup.diff Type: text/x-diff Size: 2041 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040604/f4081cd1/popup.bin From angus.leeming at btopenworld.com Fri Jun 4 12:39:51 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 06:39:59 2004 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041125.46406.angus.leeming@btopenworld.com> References: <200406041125.46406.angus.leeming@btopenworld.com> Message-ID: <200406041139.51941.angus.leeming@btopenworld.com> On Friday 04 June 2004 11:25 am, Angus Leeming wrote: > Jean-Marc, > > this patch removes the 'ugly hack' in forms.c and tries to do the > 'right thing' in xpopup.c. My testing suggests that the popups in > LyX are behaving 'better', but you're the one who's more familiar > with those problems. > > Could you try it out? I'd value some feedback about any changes to > the user experience, good or bad. Forget it. The XSendEvent stuff makes it impossible to interact with the menu in demos/popup. Incidentally, both demos/popup and demos/pup have a different behaviour to popups in LyX. It breaks the popup code (popup and pup) in the demos directory. Incidentally, both these demos behave differently to popups in LyX. Angus From angus.leeming at btopenworld.com Fri Jun 4 12:59:23 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 06:59:29 2004 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041139.51941.angus.leeming@btopenworld.com> References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041139.51941.angus.leeming@btopenworld.com> Message-ID: <200406041159.23109.angus.leeming@btopenworld.com> On Friday 04 June 2004 11:39 am, Angus Leeming wrote: > To subscribers of the xforms list > > On Friday 04 June 2004 11:25 am, Angus Leeming wrote: > > Jean-Marc, > > > > this patch removes the 'ugly hack' in forms.c and tries to do the > > 'right thing' in xpopup.c. My testing suggests that the popups in > > LyX are behaving 'better', but you're the one who's more familiar > > with those problems. Is it me, or does demos/menu behave in a very strange way? If I click on "menu 4" a popup menu is displayed. If I click elsewhere on the form another, identical popup menu is displayed. If I click on this menu, a third, identical menu is displayed. If I click on this third menu, the action is taken and all popups disappear. This behaviour is identical in Xforms 1.0 and in XForms 1.1cvs (code identical to that on savannah), so it isn't my messing around that's broken stuff. Weird and nasty. Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 15:21:57 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 4 08:22:07 2004 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041139.51941.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 11:39:51 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041139.51941.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Friday 04 June 2004 11:25 am, Angus Leeming wrote: >> Jean-Marc, >> >> this patch removes the 'ugly hack' in forms.c and tries to do the >> 'right thing' in xpopup.c. My testing suggests that the popups in >> LyX are behaving 'better', but you're the one who's more familiar >> with those problems. >> >> Could you try it out? I'd value some feedback about any changes to >> the user experience, good or bad. Angus> Forget it. The XSendEvent stuff makes it impossible to interact Angus> with the menu in demos/popup. Indeed. Angus> It breaks the popup code (popup and pup) in the demos Angus> directory. Incidentally, both these demos behave differently to Angus> popups in LyX. Yes, and I do not see why. JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 16:54:43 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 4 09:54:52 2004 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041159.23109.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 11:59:23 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041139.51941.angus.leeming@btopenworld.com> <200406041159.23109.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Is it me, or does demos/menu behave in a very strange way? If I Angus> click on "menu 4" a popup menu is displayed. If I click Angus> elsewhere on the form another, identical popup menu is Angus> displayed. If I click on this menu, a third, identical menu is Angus> displayed. If I click on this third menu, the action is taken Angus> and all popups disappear. Angus> This behaviour is identical in Xforms 1.0 and in XForms 1.1cvs Angus> (code identical to that on savannah), so it isn't my messing Angus> around that's broken stuff. It looks quite broken, indeed. It is maybe because the 4th menu is a TOUCH_MENU. These look quite useless, anyway. The code in pup.c seems to be very similar to what is done in xforms, but it does not suffer from redraw problems... JMarc From angus.leeming at btopenworld.com Fri Jun 4 16:04:12 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 10:04:19 2004 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041159.23109.angus.leeming@btopenworld.com> Message-ID: <200406041504.12465.angus.leeming@btopenworld.com> On Friday 04 June 2004 2:54 pm, Jean-Marc Lasgouttes wrote: > It looks quite broken, indeed. It is maybe because the 4th menu is > a TOUCH_MENU. These look quite useless, anyway. > > The code in pup.c seems to be very similar to what is done in > xforms, but it does not suffer from redraw problems... Can you give me a prescription to trigger these problems myself? I've always been rather hazy about them. Now that I've got your attention ;-) Could you try out the attached patch (try 2). It seems to do the right thing (Ie, I can detect no change to either the demos programs or LyX) It seems that this code is triggered very rarely, if at all. If you remove the 'button_down' test, you'll get masses of print statements, so I think that it's doing the right thing. if (fl_pushobj && !button_down(xev.xbutton.state)) { fprintf(stderr, "Dispatching...\n"); XSendEvent(flx->display, flx->win, False, 0, &xev); } And it has the advantage of fixing the lyx scrollbar again... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: popup.diff Type: text/x-diff Size: 2947 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040604/ff4382c4/popup.bin From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 18:16:23 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 4 11:16:29 2004 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041504.12465.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 15:04:12 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041159.23109.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Can you give me a prescription to trigger these problems Angus> myself? I've always been rather hazy about them. Launch LyX and open a document. Click on Insert Click on Math Click on 'Special character' The math menu is supposed to have disappeared, but since no redraw has occured, there is a painting problem. I tried to take a snapshot, but it failed miserably. Angus> Now that I've got your attention ;-) Angus> Could you try out the attached patch (try 2). It seems to do Angus> the right thing (Ie, I can detect no change to either the demos Angus> programs or LyX) Does not fix the problem with LyX. But when I move the mouse over the lyx document, there is an horrible flicker. Angus> And it has the advantage of fixing the lyx scrollbar again... But we'll have to fix the scrollbar for other xforms versions anyway, won't we? JMarc From angus.leeming at btopenworld.com Fri Jun 4 17:59:37 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 12:02:00 2004 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> Message-ID: <200406041659.37572.angus.leeming@btopenworld.com> On Friday 04 June 2004 4:16 pm, Jean-Marc Lasgouttes wrote: > Angus> Can you give me a prescription to trigger these problems > Angus> myself? I've always been rather hazy about them. > > Launch LyX and open a document. > Click on Insert > Click on Math > Click on 'Special character' > > The math menu is supposed to have disappeared, but since no redraw > has occured, there is a painting problem. I tried to take a > snapshot, but it failed miserably. Ok, I see it. Are you absolutely sure that it's a redraw problem? It seems to me that it should be possible to check if any 'shadowed' popups are visible before drawing an 'unshadowed' one. If they are, then they should be hidden. I also note that demos/pup.c has a posthandler. Something that XFormsMenubar does not. Moreover, this posthandler calls fl_showpup and fl_hidepup explicitly. Nowhere in XFormsMenubar are there calls to these functions. Regards, Angus From angus.leeming at btopenworld.com Fri Jun 4 18:00:52 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 12:02:03 2004 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> Message-ID: <200406041700.52948.angus.leeming@btopenworld.com> On Friday 04 June 2004 4:16 pm, Jean-Marc Lasgouttes wrote: > Angus> Could you try out the attached patch (try 2). It seems to do > Angus> the right thing (Ie, I can detect no change to either the > demos Angus> programs or LyX) > > Does not fix the problem with LyX. Agreed, but equally importantly it does not break anything either. > But when I move the mouse over > the lyx document, there is an horrible flicker. You mean when selecting text? Yes, I see that too. However, it it occurs also without the patch. (Just tried.) Something is triggering fl_redraw_form. > Angus> And it has the advantage of fixing the lyx scrollbar > again... > > But we'll have to fix the scrollbar for other xforms versions > anyway, won't we? Sure, but that's easy: XWorkArea::XWorkArea(LyXView & owner, int w, int h) { ... unsigned long const mask = #if FL_VERSION == 0 || (FL_VERSION == 1 && FL_REVISION == 0) GCFunction; #else GCFunction | GCGraphicsExposures; #end copy_gc = XCreateGC(fl_get_display(), RootWindow(fl_get_display(), 0), mask, &val); } Ie, we revert to the same behaviour as in LyX 1.3.x. Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 19:16:26 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 4 12:16:30 2004 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041700.52948.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 17:00:52 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> <200406041700.52948.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> But when I move the mouse over the lyx document, there is an >> horrible flicker. Angus> You mean when selecting text? Yes, I see that too. However, it Angus> it occurs also without the patch. (Just tried.) Something is Angus> triggering fl_redraw_form. No, just move quickly the mouse over an empty document. >> But we'll have to fix the scrollbar for other xforms versions >> anyway, won't we? Angus> Sure, but that's easy: OK. JMarc From angus.leeming at btopenworld.com Fri Jun 4 18:16:54 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 12:17:00 2004 Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: References: Message-ID: <200406041716.54100.angus.leeming@btopenworld.com> On Wednesday 26 May 2004 4:58 am, Mike Heffner wrote: > On 05-May-2004 Angus Leeming wrote: > | On Thursday 15 January 2004 5:30 am, Mike Heffner wrote: > |> When fl_set_font_name() fails it will return -1 but it also > |> prints: > |> > |> In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah > |> > |> This function is typically used as a method of testing whether a > |> font is loadable or not, so it's not always a fatal condition. > |> Can this print statement be wrapped in a debug-only conditional? > | > | Mike does this do the job: > | - M_err("SetFont", "Bad FontStyle request %d: %s", > | numb, flf->fname); > | + M_warn("SetFont", "Bad FontStyle request %d: %s", > | numb, flf->fname); > > How about changing it to M_debug(...)? 'warn' and 'err' essentially > always get printed (a bug for another day). I set it to M_info, which is just below the default threshold for printing. Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 19:18:57 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 4 12:19:01 2004 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041659.37572.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 16:59:37 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> <200406041659.37572.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Ok, I see it. Are you absolutely sure that it's a redraw Angus> problem? It seems to me that it should be possible to check if Angus> any 'shadowed' popups are visible before drawing an Angus> 'unshadowed' one. If they are, then they should be hidden. As I see it, the code relies if possible on saveunders, which are not enabled on modern linux. Angus> I also note that demos/pup.c has a posthandler. Something that Angus> XFormsMenubar does not. Moreover, this posthandler calls Angus> fl_showpup and fl_hidepup explicitly. Nowhere in XFormsMenubar Angus> are there calls to these functions. But popup.c does not as far as I can see. JMarc From angus.leeming at btopenworld.com Fri Jun 4 18:24:44 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 12:24:51 2004 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041700.52948.angus.leeming@btopenworld.com> Message-ID: <200406041724.44213.angus.leeming@btopenworld.com> On Friday 04 June 2004 5:16 pm, Jean-Marc Lasgouttes wrote: > >> But when I move the mouse over the lyx document, there is an > >> horrible flicker. > > Angus> You mean when selecting text? Yes, I see that too. However, > it Angus> it occurs also without the patch. (Just tried.) Something > is Angus> triggering fl_redraw_form. > > No, just move quickly the mouse over an empty document. I see nothing peculiar when I just move the mouse over an empty document. If, however, I press the LMB and repeat the exercise, then I do, indeed, get the flicker. Is that what you're doing? Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 19:34:16 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri Jun 4 12:34:20 2004 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041724.44213.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 17:24:44 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041700.52948.angus.leeming@btopenworld.com> <200406041724.44213.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> No, just move quickly the mouse over an empty document. Angus> I see nothing peculiar when I just move the mouse over an empty Angus> document. If, however, I press the LMB and repeat the exercise, Angus> then I do, indeed, get the flicker. Angus> Is that what you're doing? Launch LyX File>New Open file menu, and then click somewhere else to close it move the mouse JMarc From Ivan.Powis at nottingham.ac.uk Fri Jun 4 18:48:11 2004 From: Ivan.Powis at nottingham.ac.uk (Ivan Powis) Date: Fri Jun 4 12:48:13 2004 Subject: [XForms] Xforms: incorrect reporting of mouse (XEvent) status to post-handler Message-ID: I have an old application which uses the post-handler to add greater interaction (rubber banded selections, zoom etc) to xy_plots. It used to work (with an occasional hiccup) but the problem has now got so bad as to make it unusable. Apparent problem: Inconsistent data is passed to the post handler by forms. In particular it seems to lose track of the "key" state. Immediately after a mouse button is depressed (generating an FL_PUSH) an immediate release (FL_RELEASE, key=0) is frequently getting reported back to the post handler, even though the button is still physically down, and is reported as such by fl_mouse_button(). Additionally examining the XEvent structure passed to the post handler as "xev" by using fl_xevent_name_print() reports the event as 12: Expose. [OK I know that the manual implies that the void *xev might not always be a valid XEvent pointer, but my experience in trying to debug this problem suggests that everywhere else in the posthandler section its more often right than not!] Once this spurious button release has been reported the forms lib obviously decides to remember the erroneous information that the mouse button is up! So it will not then report a genuine release as FL_RELEASE, and if the mouse is dragged with a button physically still down, forms reports FL_MOTION rather than FL_MOUSE to the posthandler - this rather breaks my rubber-banding code. Again interrogating xev for the raw XEvent codes shows that xev->xmotion.state correctly identifies the physically depressed mouse button. I may note that the problem appears the same in v.89 and v1 of the forms library, and isn't confined to a particular version of Linux and/or gcc. For example on Mandrake linux 8.2 (kernel 4.2, XFree 4.2.0, KDE 2.2.2) on the console xserver the app becomes unusable. But connect to this same system a remote pc running Exceed xserver and there is no problem using either the full KDE session or a single X-window opened on the Windows desktop. Likewise on a Redhat (kernel 2.4.20, XFree 4.3.0 KDE 3.1) the app is unusable at the console, but OK if viewed via a remote pc Xserver - in this case just an occasional glitch crops up, but basic functinality is not compromised). I think we saw some similar minor glitches on older HP/UX systems. Actually the degradation in performance at the linux consoles seems to correlate with the use of a heavyweight window manager like KDE or GNOME, but isn't confined to any particular WM. It seems then as though the forms library, rather than tracking the mouse button state via the XEvents it receives, tries to maintain its own internal record, which more often than not gets out of sync with the physical state and the reported status via xev. This then seems far far worse with a heavyweight local WM. I don't quite understand the significance of this, nor the inner workings of X. Anyone got any ideas, or suggestions where in the source to browse and what to look for? One possible work round here is to base decision making in the post handler on an examination of the raw XEvent *xev structure rather than whatever forms lib reports, but I'm concerned that the library doesn't seem to guarantee passing xev valid. Ivan -------------------------------------------------------------------- ___ ___/ _ __ / Ivan Powis [Ivan.Powis@Nottingham.ac.uk] / / / School of Chemistry / / _/ University of Nottingham / ___/ Nottingham NG7 2RD, UK / / TEL: +44-115-951-3467 / / FAX: +44-115-951-3562 _______/ ____/ http://www.chem.nott.ac.uk/IP.html -------------------------------------------------------------------- From angus.leeming at btopenworld.com Fri Jun 4 19:19:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 13:20:12 2004 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041659.37572.angus.leeming@btopenworld.com> Message-ID: <200406041819.18921.angus.leeming@btopenworld.com> On Friday 04 June 2004 5:18 pm, Jean-Marc Lasgouttes wrote: > Angus> Ok, I see it. Are you absolutely sure that it's a redraw > Angus> problem? It seems to me that it should be possible to check > if Angus> any 'shadowed' popups are visible before drawing an > Angus> 'unshadowed' one. If they are, then they should be hidden. > > As I see it, the code relies if possible on saveunders, which are > not enabled on modern linux. > > Angus> I also note that demos/pup.c has a posthandler. Something > that Angus> XFormsMenubar does not. Moreover, this posthandler > calls Angus> fl_showpup and fl_hidepup explicitly. Nowhere in > XFormsMenubar Angus> are there calls to these functions. > > But popup.c does not as far as I can see. Ok, and the posthandlers are for the buttons b1, b2, not for the "Popup" button, so they're irrelvant here. Angus From angus.leeming at btopenworld.com Fri Jun 4 19:24:50 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 4 13:24:57 2004 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041724.44213.angus.leeming@btopenworld.com> Message-ID: <200406041824.50814.angus.leeming@btopenworld.com> On Friday 04 June 2004 5:34 pm, Jean-Marc Lasgouttes wrote: > Angus> I see nothing peculiar when I just move the mouse over an > empty Angus> document. If, however, I press the LMB and repeat the > exercise, Angus> then I do, indeed, get the flicker. > > Angus> Is that what you're doing? > > Launch LyX > File>New > Open file menu, and then click somewhere else to close it > move the mouse Got it. Thanks. Angus From Gayle.C.Roth at nasa.gov Fri Jun 4 16:27:21 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Fri Jun 4 15:27:28 2004 Subject: [XForms] Wrong dirent header file? Message-ID: <5.1.1.5.2.20040604150948.016e4160@popserve.grc.nasa.gov> Hi. According to comments in listdir.c at the place where dirent_vms.h is included, and the #ifdef around the #include statement, the header file dirent_vms.h is only supposed to be included if the VMS version is less than 7.0. Ours is 7.3-2. It turned out that dirent_vms.h was not being included because of that #ifdef, so even though we have 7.3-2, I commented out the #ifdef and #endif so the struct definitions would be included. That's when I found out that, no, dirent_vms.h is the wrong file to include since its structs are not up to date (for example, there's no 'd_reclen' in struct dirent). Therefore, I still got a fatal compiler error. What's the up-to-date header file for version 7.3-2? That must be what I need. Thanks, Gayle From rostamian at umbc.edu Fri Jun 4 20:57:58 2004 From: rostamian at umbc.edu (Rouben Rostamian) Date: Fri Jun 4 19:58:00 2004 Subject: [XForms] missing #include in glcanvas.h Message-ID: <200406042357.i54Nvw7Y028210@pc18.math.umbc.edu> Minor bug in xforms-1.0.90: Where: xforms-1.0.90/gl/glcanvas.h Problem: Missing header: #include How to fix: Add: #include near the top of xforms-1.0.90/gl/glcanvas.h Details: The #include is needed to resolve references to GLXContext in xforms-1.0.90/gl/glcanvas.h. Currently, the supplied demos work by accident, because they happen to #include the header files #include #include just in the right order. Reversing the #include order will break them. -- Rouben Rostamian From angus.leeming at btopenworld.com Sat Jun 5 13:25:32 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat Jun 5 07:25:40 2004 Subject: [XForms] missing #include in glcanvas.h In-Reply-To: <200406042357.i54Nvw7Y028210@pc18.math.umbc.edu> References: <200406042357.i54Nvw7Y028210@pc18.math.umbc.edu> Message-ID: <200406051225.32631.angus.leeming@btopenworld.com> On Saturday 05 June 2004 12:57 am, Rouben Rostamian wrote: > To subscribers of the xforms list > Problem: > Missing header: > #include Hi, Rouben. Thanks for the bug report. The fix is already in cvs and will, therefore, also be in XForms 1.1. Regards, Angus From jac4 at mindless.com Mon Jun 7 10:22:55 2004 From: jac4 at mindless.com (jason cipriani) Date: Mon Jun 7 10:23:06 2004 Subject: [XForms] missing #include in glcanvas.h Message-ID: <20040607142255.33A78790036@ws1-14.us4.outblaze.com> I can't help but chuckle, though. Oh if only GL (and GLX... and WGL... and AGL... and... ugh) was part of the standard C library, heh... On another topic, I've been quite busy with work recently, but I will eventually have time to put together some of that buggy Fedora GL code. I didn't forget. Jason > To subscribers of the xforms list > > > On Saturday 05 June 2004 12:57 am, Rouben Rostamian wrote: > > To subscribers of the xforms list > > Problem: > > Missing header: > > #include > > Hi, Rouben. > Thanks for the bug report. The fix is already in cvs and will, > therefore, also be in XForms 1.1. > > Regards, > Angus -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From Ivan.Powis at nottingham.ac.uk Sat Jun 12 23:38:57 2004 From: Ivan.Powis at nottingham.ac.uk (Ivan Powis) Date: Sat Jun 12 17:37:35 2004 Subject: [XForms] incorrect reporting of mouse (XEvent) status to post-handler Message-ID: I posted this problem a week ago. In short, in an application providing mouse interaction via pre/post handlers I notice a spurious response - seemingly xforms detects and reports an FL_RELEASE immediately following FL_PUSH event, even when the mouse button is still physically held down. This completely screws up the ability of the application to track the mouse actions. It occurs in version of xforms since 0.89, on various OSes. Interestingly it is is much more evident on the console of a linux box, than when running via a remote X server. I have at least now tracked the apparent problem to the following section of forms.c, around line 1357: #if 1 /* this is an ugly hack. This is necessary due to popup pointer grab where a button release is eaten. Really should do a send event from the pop-up routines */ if (fl_pushobj && !button_down(fl_keymask) /* && event == FL_ENTER */ ) { obj = fl_pushobj; fl_pushobj = NULL; fl_handle_object(obj, FL_RELEASE, xx, yy, key, xev); } #endif .. in particular it is the call to fl_handle_object which I believe initiates the spurious FL_RELEASE report to the handlers. Evidently this section of code comes with a health warning attached. Anyone understand what it is trying to do? Wasn't there some reference to this same section in a discussion of odd pup-up behaviour a few weeks ago? Ivan Powis -----Original Message----- From: xforms-bounces@bob.usuhs.mil [mailto:xforms-bounces@bob.usuhs.mil]On Behalf Of Ivan Powis Sent: 04 June 2004 17:48 To: xforms@bob.usuhs.mil Subject: [XForms] Xforms: incorrect reporting of mouse (XEvent) status to post-handler To subscribers of the xforms list [...] I may note that the problem appears the same in v.89 and v1 of the forms library, and isn't confined to a particular version of Linux and/or gcc. For example on Mandrake linux 8.2 (kernel 4.2, XFree 4.2.0, KDE 2.2.2) on the console xserver the app becomes unusable. But connect to this same system a remote pc running Exceed xserver and there is no problem using either the full KDE session or a single X-window opened on the Windows desktop. Likewise on a Redhat (kernel 2.4.20, XFree 4.3.0 KDE 3.1) the app is unusable at the console, but OK if viewed via a remote pc Xserver - in this case just an occasional glitch crops up, but basic functinality is not compromised). I think we saw some similar minor glitches on older HP/UX systems. Actually the degradation in performance at the linux consoles seems to correlate with the use of a heavyweight window manager like KDE or GNOME, but isn't confined to any particular WM. It seems then as though the forms library, rather than tracking the mouse button state via the XEvents it receives, tries to maintain its own internal record, which more often than not gets out of sync with the physical state and the reported status via xev. This then seems far far worse with a heavyweight local WM. I don't quite understand the significance of this, nor the inner workings of X. Anyone got any ideas, or suggestions where in the source to browse and what to look for? This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From angus.leeming at btopenworld.com Mon Jun 14 10:36:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Jun 14 04:37:53 2004 Subject: [XForms] incorrect reporting of mouse (XEvent) status to post-handler In-Reply-To: References: Message-ID: <200406140936.33028.angus.leeming@btopenworld.com> On Saturday 12 June 2004 10:38 pm, Ivan Powis wrote: > I posted this problem a week ago. Sorry. Been busy. > In short, in an application > providing mouse interaction via pre/post handlers > I notice a spurious response - seemingly xforms detects > and reports an FL_RELEASE immediately following FL_PUSH event, even > when the mouse button is still physically held down. This > completely screws up the ability of the application to track the > mouse actions. It occurs in version of xforms since 0.89, on > various OSes. Interestingly it is > is much more evident on the console of a linux box, than when > running via a remote X server. > > I have at least now tracked the apparent problem to the following > section of forms.c, > around line 1357: > > #if 1 > /* this is an ugly hack. This is necessary due to popup pointer > grab where a button release is eaten. Really should do a send event > from the pop-up routines */ > > if (fl_pushobj && !button_down(fl_keymask) /* && event == > FL_ENTER */ ) { > obj = fl_pushobj; > fl_pushobj = NULL; > fl_handle_object(obj, FL_RELEASE, xx, yy, key, xev); > } > #endif Ahhhhhhhhhhhhhhhh. Evil, isn't it. > .. in particular it is the call to fl_handle_object which I > believe initiates the spurious > FL_RELEASE report to the handlers. > > Evidently this section of code comes with a health warning > attached. Anyone understand what it is trying to do? Wasn't there > some reference to this same section in a discussion of odd pup-up > behaviour a few weeks ago? Yes. I too am being bitten by this block of code. It seems to stem from the popup code (xpopup.c), which grabs the pointer and the keyboard and which throws away any genuinely pending XEvents. The hack tries to limit the damage. The fix would be to do the right thing in the popups. I attach my attempt at a fix. Unfortunately, it makes popup behaviour far worse than it is at the moment, so more needs to be done. Also unfortunately, I've run out of time for the moment. Nonetheless, I hope that this info proves valuable. If, in the meantime, you resolve the problem, then *please* let me know. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: popup.diff Type: text/x-diff Size: 3008 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040614/d80960a9/popup.bin From Gayle.C.Roth at nasa.gov Fri Jun 18 17:32:13 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Fri Jun 18 16:32:25 2004 Subject: [XForms] Version 1.0.90 Message-ID: <5.1.1.5.2.20040618162109.01690fd8@popserve.grc.nasa.gov> Hi. I'm experiencing several problems as I try to build the demos on VMS. There appear to be inconsistencies between struct definitions and usage in the source code. This has happened already in 3 cases, and I'm only up to demotest (I'm doing it in alphabetical order). An example of this is while attempting to compile buttonall.c, the source file refers to members of the FD_buttform struct that appear not to exist -- for example, 'backface', 'objsgroup, 'done', 'pbutt', 'bbutt', and 'bw_obj' are referenced as members of FD_buttform, but in the file pallette.h, which has the definition of FD_buttform, these members do not exist! Is there something I'm missing, or is this a mistake? Thanks, Gayle From angus.leeming at btopenworld.com Sat Jun 19 00:11:08 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jun 18 18:11:12 2004 Subject: [XForms] Version 1.0.90 In-Reply-To: <5.1.1.5.2.20040618162109.01690fd8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040618162109.01690fd8@popserve.grc.nasa.gov> Message-ID: <200406182311.08718.angus.leeming@btopenworld.com> On Friday 18 June 2004 9:32 pm, Gayle C Roth wrote: > To subscribers of the xforms list > > > Hi. > > I'm experiencing several problems as I try to build the demos on > VMS. There appear to be inconsistencies between struct definitions > and usage in the source code. This has happened already in 3 > cases, and I'm only up to demotest (I'm doing it in alphabetical > order). An example of this is while attempting to compile > buttonall.c, the source file refers to members of the FD_buttform > struct that appear not to exist -- for example, 'backface', > 'objsgroup, 'done', 'pbutt', 'bbutt', and 'bw_obj' are referenced > as members of FD_buttform, but in the file pallette.h, which has > the definition of FD_buttform, these members do not exist! Is > there something I'm missing, or is this a mistake? Given that buttonall.c has these #includes only: #include "include/forms.h" #include "fd/buttons_gui.h" /* from fd/ directory */ #include (note that pallette.h is not one of them), I'd guess that you are mistaken. "fd/buttons_gui.h" is meant to be generated from fd/buttons_gui.fd during the build process. The relevant part of demos/Makefile.am is: buttonall_SOURCES = buttonall.c nodist_buttonall_SOURCES = fd/buttons_gui.c fd/buttons_gui.h buttonall.$(OBJEXT): fd/buttons_gui.c which says that "buttonall.o" depends on fd/buttons_gui.c. At the the bottom of demos/Makefile.am is the make rule defining how to go from a .fd file to a .c one: .fd.c: ../fdesign/fdesign ../fdesign/fdesign -dir fd -convert $< The moral, go into demos/fd and run the equivalent of #! /bin/sh for file in *.fd do ${PATH TO FDESIGN}/fdesign -convert $file done which should give you the .[ch] files from the .fd ones. HTH, Angus From Gayle.C.Roth at nasa.gov Mon Jun 21 12:33:45 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Mon Jun 21 11:33:52 2004 Subject: [XForms] fdesign Message-ID: <5.1.1.5.2.20040621111722.016b9a98@popserve.grc.nasa.gov> Hi. While attempting to create the necessary .c and .h files on an intermediary UNIX machine (between the PC and the VMS machine where I'm trying to do builds) and yes, I confess, using an old version of fdesign in convert mode to create the .c & .h files from the 1.0.90 .fd's, I ran into problems with 3 of the .fd's. I got a core dump while attempting this on the following files (in demos/fd): formbrowser_gui.fd is_gui.fd twheel_gui.fd I did dbx on 2 of the 3 cores and it apparently aborted in XQueryPointer. I used the old fdesign because I thought it would save time, since I have not built the fdesign with the 1.0.90 source. I don't have automake on the UNIX machine I was using, so I guess I should put it there. Once, that's done, how do I build something in a given directory (such as xforms/fdesign)? I have the necessary source there (on UNIX) already. Or would it be better just to copy the .c's and .h's I have down to the VMS machine and just not build the demos that involve those 3 files that caused the core dumps? Thanks, Gayle From angus.leeming at btopenworld.com Mon Jun 21 17:44:58 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Jun 21 11:45:03 2004 Subject: [XForms] fdesign In-Reply-To: <5.1.1.5.2.20040621111722.016b9a98@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040621111722.016b9a98@popserve.grc.nasa.gov> Message-ID: <200406211644.58158.angus.leeming@btopenworld.com> On Monday 21 June 2004 4:33 pm, Gayle C Roth wrote: > I don't have automake on the UNIX machine I was using, so I guess I > should put it there. Once, that's done, how do I build something > in a given directory (such as xforms/fdesign)? I have the > necessary source there (on UNIX) already. Gayle, if you're building from the 1.0.90 tarball, you don't need automake. $ tar xvzf xforms-1_0_90.tar.gz $ cd xforms-1_0_90 $ mkdir build $ cd build $ ../configure $ make Should work fine. All generated files will be inthe build tree and will not pollute your original source tree. If you are using cvs, you will need automake and autoconf to generate the Makefile.in files and configure. The build strategy above would differ only in that you'd add a command $ ./autogen.sh before the 'cd build' line. > Or would it be better just to copy the .c's and .h's I have down to > the VMS machine and just not build the demos that involve those 3 > files that caused the core dumps? It would be better to track down the root cause of the problem... Angus From jac4 at mindless.com Mon Jun 21 14:56:33 2004 From: jac4 at mindless.com (jason cipriani) Date: Mon Jun 21 14:56:52 2004 Subject: [XForms] Setting FL_CHOICE colors. Message-ID: <20040621185633.1C5E379005B@ws1-14.us4.outblaze.com> How do you set the color of the text of the items in the dropdown box that appears when you click on an FL_NORMAL_CHOICE2? The color of the label, and the color of the title in this dropdown box is obj->lcolor. The color of the text inside the choice box is obj->col2. But I can't figure out which one is the color of the items in the box. Also, the color of the text in a browser is obj->lcolor, yet the style of the text in the browser is not obj->lstyle/obj->lsize. This is both inconsistent with itself and with FL_CHOICE, where the text color is obj->col2. This is all undocumented. Does anybody know why this is so patchy? Thanks, Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Mon Jun 21 22:56:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Jun 21 16:56:42 2004 Subject: [XForms] Setting FL_CHOICE colors. In-Reply-To: <20040621185633.1C5E379005B@ws1-14.us4.outblaze.com> References: <20040621185633.1C5E379005B@ws1-14.us4.outblaze.com> Message-ID: <200406212156.33093.angus.leeming@btopenworld.com> On Monday 21 June 2004 7:56 pm, jason cipriani wrote: > To subscribers of the xforms list > > > How do you set the color of the text of the items in the dropdown > box that appears when you click on an FL_NORMAL_CHOICE2? > > The color of the label, and the color of the title in this dropdown > box is obj->lcolor. The color of the text inside the choice box is > obj->col2. But I can't figure out which one is the color of the > items in the box. Jason, the list is a popup. (See xpopup.c.) The code used to draw it in choice.c is to be found in do_pup. Anyway, I think the magic line of code you're looking for is to be found about line 120 in xpopup.c: static FL_COLOR pupcolor = FL_COL1, puptcolor = FL_BLACK; Followed by line 480: void fl_setpup_default_color(FL_COLOR fg, FL_COLOR bg) { pupcolor = fg; puptcolor = bg; } > Also, the color of the text in a browser is obj->lcolor, yet the > style of the text in the browser is not obj->lstyle/obj->lsize. > This is both inconsistent with itself and with FL_CHOICE, where the > text color is obj->col2. This is all undocumented. Does anybody > know why this is so patchy? I suspect it is because the original driving force behind the code development was waning somewhat by the time these widgets came to be written. Hope this helps, Angus From oszwald at web.de Mon Jun 21 00:34:19 2004 From: oszwald at web.de (Florian Oszwald) Date: Mon Jun 21 17:35:29 2004 Subject: [XForms] fl_get_glcanvas_attributes Message-ID: <40D602DB.4080804@web.de> Dear List, maybe someone could give me hint on this: I tried to install darwin2k which requires xforms under suse 9.0 So I downloaded xform 1.0.90 and configured it and installed it. When I try to install darwin I get an error during make saying, that fl_get_glcanvas_attributes is undecleared Well, I have xforms installed, what might be the point? I thought, that the compiler cannot see the xform files. How can I changed this? Thank you very much for your help. Best, Florian From angus.leeming at btopenworld.com Mon Jun 21 23:42:11 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon Jun 21 17:42:18 2004 Subject: [XForms] fl_get_glcanvas_attributes In-Reply-To: <40D602DB.4080804@web.de> References: <40D602DB.4080804@web.de> Message-ID: <200406212242.11983.angus.leeming@btopenworld.com> On Sunday 20 June 2004 10:34 pm, Florian Oszwald wrote: > Dear List, > > maybe someone could give me hint on this: > > I tried to install darwin2k which requires xforms under suse 9.0 > > So I downloaded xform 1.0.90 and configured it and installed it. > When I try to install darwin I get an error during make saying, > that fl_get_glcanvas_attributes is undecleared > > Well, I have xforms installed, what might be the point? I thought, > that the compiler cannot see the xform files. How can I changed > this? > > Thank you very much for your help. I'm afraid that your report is too vague to allow me to really help you. However, maybe this will help: $ grep -r fl_get_glcanvas_attributes . Binary file ./build/gl/.libs/libformsGL.so.1.0.0 matches Binary file ./build/gl/.libs/libformsGL.so.1 matches Binary file ./build/gl/.libs/libformsGL.so matches Binary file ./build/gl/.libs/libformsGL.a matches Binary file ./build/gl/glcanvas.o matches Binary file ./build/gl/glcanvas.lo matches ./gl/glcanvas.c:fl_get_glcanvas_attributes(FL_OBJECT * ob, int *attributes) ./gl/glcanvas.h:FL_EXPORT void fl_get_glcanvas_attributes( Conclusion: the function is present in libformsGL.so Do you link against this, or only against libforms.so? Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Tue Jun 22 11:49:03 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Jun 22 04:49:23 2004 Subject: [XForms] fl_get_glcanvas_attributes In-Reply-To: <200406212242.11983.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 21 Jun 2004 22:42:11 +0100") References: <40D602DB.4080804@web.de> <200406212242.11983.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Conclusion: the function is present in libformsGL.so Do you Angus> link against this, or only against libforms.so? It seems that the latest version of darwin2k is from march 2003, so maybe it was not tested against latest xforms version where formsGL has been separated. JMarc From jac4 at mindless.com Tue Jun 22 10:14:28 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue Jun 22 10:14:46 2004 Subject: [XForms] Setting FL_CHOICE colors. Message-ID: <20040622141428.2FEDD79006B@ws1-14.us4.outblaze.com> Jason wrote: > > How do you set the color of the text of the items in the dropdown > > box that appears when you click on an FL_NORMAL_CHOICE2? Angus wrote: > the list is a popup. (See xpopup.c.) The code used to draw it in > choice.c is to be found in do_pup. > ... > fl_setpup_default_color(FL_COLOR fg, FL_COLOR bg) Ah, thanks! I'm not too familiar with the popup stuff (...yet :/ ). This did work, unfortunately, the fg color is not only the color of the text, but it is the color of the border around the title and one of the colors in the popup's shadow. So a white foreground with a dark blue background is kind of abrasive, heh. I wonder if changing it so fg was only the text color would break anybody's code. I dunno. If you changed the popup default fg color, it would have to be a subtle change to get acceptable results. So it would probably be pretty close to black in most applications; doesn't seem like leaving the title border and shadow black would make much of a difference. Does anybody here use light-colored popup fg colors in any of their applications? PS: Sorry if you got this twice Angus, I'm a bit clumsy when it comes to mailing lists. *cough* forums *cough* -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jac4 at mindless.com Tue Jun 22 10:18:19 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue Jun 22 10:18:34 2004 Subject: [XForms] fl_get_glcanvas_attributes Message-ID: <20040622141819.7DCB779006C@ws1-14.us4.outblaze.com> > So I downloaded xform 1.0.90 and configured it and installed it. > When I try to install darwin I get an error during make saying, that > fl_get_glcanvas_attributes is undecleared If it's the compiler saying it's undeclared (as opposed to the linker saying it's undefined), then it could also be the ol' glcanvas.h thing (TM). Try, just for grins, editing your installed forms.h file and adding these two lines somewhere: #include #include Assuming that GL/glx.h and the installed glcanvas.h are in your include path. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jac4 at mindless.com Fri Jun 25 14:28:07 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri Jun 25 14:28:28 2004 Subject: [XForms] FL_NoColor? Message-ID: <20040625182807.87FFA79005B@ws1-14.us4.outblaze.com> So I've been having this problem in applications that use GLCanvases where the canvases flicker a lot in response to Expose events because the forms library is calling XClearWindow() to draw the fdesign-set background color on the canvas. Sometimes, the GLCanvas image disappears entirely (when the X server decides to process XClearWindow() -after- I swap GL buffers). I looked into this and noticed FL_NoColor in the library code. When a canvas's col1 is set to FL_NoColor, the forms library doesn't call XClearWindow() to clear the background color. It shouldn't do this for GLCanvases anyway: why clear the canvas with an X call when the application is going to be redrawing the entire canvas with GL calls anyway? Apparently, canvases are initially created with col1 set to FL_NoColor. But then, the fdesign-generated code calls fl_set_object_color() and overrides this. Unfortunately, FL_NoColor (=0x7fffffff) is defined in the libraries private header files but does -not- appear in forms.h. So the only way to programmatically give a canvas on an fdesign-generated form no background color is: fl_set_object_color(my_canvas, 0x7fffffff, FL_BLACK); Works but I like named constants better than actual values. So, with that in mind: 1) Why is FL_NoColor not in forms.h? 2) Can you stick it in there in the next release? 3) Am I unleashing a dangerous beast by explicitly calling fl_object_color() with 0x7fffffff? There is no way to prevent the XClearWindow() call simply by clever use of preemptive callbacks because if you return FL_PREEMPT on an FL_DRAW event, init_canvas() never gets called and X complains about bad drawables. And if you don't return FL_PREEMPT, then that kind of defeats the purpose here. Setting col1 to 0x7fffffff seems to be the cleanest way of getting rid of the flicker. Thanks, Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From dimasmm at visgraf.impa.br Tue Jun 29 19:30:33 2004 From: dimasmm at visgraf.impa.br (Dimas Martnez Morera) Date: Tue Jun 29 16:34:16 2004 Subject: [XForms] fl_show_fselector Message-ID: <200406291830.33864.dimasmm@visgraf.impa.br> Hi everybody,=20 I new to xforms and I'm trying to use fl_show_fselector. In fact I did it without any problem. But now I'm getting "segmentation fault" in the line of code: filename = fl_show_fselector("Select file to open",".","*.off", ""); the error message is: In SetFont [fonts.c 224] Bad FontStyle request 0:=20 Segmentation fault (core dumped) I'm wondering what is happening here. Can anybody help me? Thanks a lot, Dimas From Gayle.C.Roth at nasa.gov Wed Jul 7 16:22:42 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Wed Jul 7 15:22:49 2004 Subject: [XForms] Problem linking w/ xforms Message-ID: <5.1.1.5.2.20040707145059.0169cf20@popserve.grc.nasa.gov> Hi. As I think I mentioned, I grabbed the binary of xforms, version 0.88. I unpacked it, and currently I'm trying to build my GUI with the xforms shared library. This is on OpenVMS 7.3-2. I'm presently having problems linking -- getting unresolved references for FL_DISPLAY and FL_EVENT. For FL_DISPLAY, forms.h is the only file that mentions it. Here are the places in forms.h that mentions FL_DISPLAY and FL_EVENT: --------------------------------------------------- #if !defined(FL_WIN32) || !defined(SHARED_LIB) # define FL_EXPORT extern #else # ifdef MAKING_FORMS # define FL_EXPORT __declspec( dllexport ) extern # else # define FL_EXPORT __declspec( dllimport ) extern # endif /* MAKING_FORMS */ #endif /* FL_WIN32 */ ... FL_EXPORT Display *fl_display; ... FL_EXPORT FL_OBJECT *FL_EVENT; ----------------------------------------------------------------- Any idea what I need to do to get FL_DISPLAY and FL_EVENT recognized? Thanks, Gayle From jac4 at mindless.com Thu Jul 8 01:34:47 2004 From: jac4 at mindless.com (jason cipriani) Date: Thu Jul 8 01:52:53 2004 Subject: [XForms] Problem linking w/ xforms Message-ID: <20040708053447.C3FF516402D@ws1-4.us4.outblaze.com> Perhaps your system already came with a newer version of xforms installed, and it's using the new header but trying to link with the old library? 1.0.90 is out now, and compiles with relative ease, is there a specific reason you are using 0.88? There's some xforms library/header version functions and macros, can't remember what they are exactly, but theyre in the documentation. If you check the lib version against the header version that might yield some clues. The earliest version I've ever used is 0.89 so I don't really know if there were specific problems like that with 0.88. One thing you could do is locate all forms.h and libforms.* on your machine, remove (read: rename and move to a safe place) them, and then copy your 0.89 lib and header files to the appropriate paths, just to make sure that the 0.88 stuff is the -only- stuff you are using. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From Jean-Marc.Lasgouttes at inria.fr Thu Jul 8 12:08:05 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Jul 8 05:08:11 2004 Subject: [XForms] Problem linking w/ xforms In-Reply-To: <20040708053447.C3FF516402D@ws1-4.us4.outblaze.com> (jason cipriani's message of "Thu, 08 Jul 2004 00:34:47 -0500") References: <20040708053447.C3FF516402D@ws1-4.us4.outblaze.com> Message-ID: >>>>> "jason" == jason cipriani writes: jason> Perhaps your system already came with a newer version of xforms jason> installed, and it's using the new header but trying to link jason> with the old library? jason> 1.0.90 is out now, and compiles with relative ease, is there a jason> specific reason you are using 0.88? Gayle is (desperately) trying to compile xforms under OpenVMS. That's why he is trying version 0.88, which is supposed to work. Compiling the autoconf-enabled is much more difficult on a non-unix system. JMarc From Gayle.C.Roth at nasa.gov Wed Jul 14 11:02:49 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Wed Jul 14 10:23:10 2004 Subject: [XForms] OpenVMS application Message-ID: <5.1.1.5.2.20040714095205.0168f280@popserve.grc.nasa.gov> Hi. I finally succeeded in building and running my OpenVMS application which uses xforms. However, I keep getting this "Bad file Number" message for as long as xforms is up. The same thing happens when I run the demos. I'm using the binary (shared library) from version .88; the last binary (at least the last one still left anywhere) out there. I know someone not familiar with my dilemma is going to ask why don't I use the open source version 1.0.90. It's because I'm building on OpenVMS WITHOUT GNV!! Therefore, it's extremely difficult if not impossible to handle situations such as missing files because they're automatically generated by automake, which I don't have access to! Angus, I appreciate all the help you gave me in providing me with scripts to generate some of these files -- and in some cases with the files themselves. However, I just encountered too many hurdles that in some cases proved impossible to overcome. At some future point in time, I'll go the open source route -- but right now we're trying to get on the fast track to show our users we're actually doing something. Does anyone have any idea what's causing this 'Bad file number' message? Any ideas are appreciated. Thanks, Gayle From Gayle.C.Roth at nasa.gov Wed Jul 21 11:01:51 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Wed Jul 21 10:02:00 2004 Subject: [XForms] Source for .89.5 Message-ID: <5.1.1.5.2.20040721094043.016952b8@popserve.grc.nasa.gov> Is the source for version 0.89.5 available? Currently, I'm running with the .88 binary version on OpenVMS 7.3-2 and there are some problems. One of them is that the text written to and entered into input boxes does not show up. It's there, but it doesn't appear no matter what color the background is. I need source for a PRE-AUTOMAKE version, because I'm building on OpenVMS w/ NO GNV!! Therefore, I need a version that does not generate files automatically. Please let me know, as I think that building with a post-.88 version is the only way to get rid of these problems I'm encountering. Thanks, Gayle From adejneka at comail.ru Thu Jul 22 21:08:05 2004 From: adejneka at comail.ru (Alexey Dejneka) Date: Thu Jul 22 12:08:26 2004 Subject: [XForms] inactive objects receive focus Message-ID: Hello, When a group is shown, the first input field is focused, even if it is deactivated. I've attached the test: run the program, press "show group" button. Two input fields will appear, first being focused, and even accepting input. While after moving focus to the second input, it will be impossible to return the focus to the first. Shouldn't ``if (ob->input && ob->form->focusobj == NULL)'' in fl_show_object be ``if (ob->input && ob->active>0 && ob->form->focusobj == NULL)''? -- Regards, Alexey Dejneka "Alas, the spheres of truth are less transparent than those of illusion." -- L.E.J. Brouwer -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: application/octet-stream Size: 941 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20040722/bd1a99ea/test.obj From Ivan.Powis at nottingham.ac.uk Fri Jul 23 14:14:45 2004 From: Ivan.Powis at nottingham.ac.uk (Ivan Powis) Date: Fri Jul 23 08:14:49 2004 Subject: [XForms] Source for .89.5 In-Reply-To: <5.1.1.5.2.20040721094043.016952b8@popserve.grc.nasa.gov> Message-ID: > -----Original Message----- > From: xforms-bounces@bob.usuhs.mil > [mailto:xforms-bounces@bob.usuhs.mil]On Behalf Of Gayle C Roth > Sent: 21 July 2004 15:02 > To: xforms@bob.usuhs.mil > Subject: [XForms] Source for .89.5 > of them is that the text written to and entered into input boxes does not > show up. It's there, but it doesn't appear no matter what color the > background is. > This sounds like an old bug/feature of xforms input boxes. As I recall its related to the font size being too big for the input box. Often can happen when transferring an application written on one system, or even using one X display, to another due to variations in available fonts dpi etc. Any way what happened I think was that forms saw it couldn't put the text in fully, and so rather than clipping it didn't display anything at all! Try enlarging the input boxes. Ivan Powis This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From angus.leeming at btopenworld.com Fri Jul 23 14:18:32 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Jul 23 08:18:14 2004 Subject: [XForms] Source for .89.5 In-Reply-To: <5.1.1.5.2.20040721094043.016952b8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040721094043.016952b8@popserve.grc.nasa.gov> Message-ID: <200407231318.32790.angus.leeming@btopenworld.com> On Wednesday 21 July 2004 3:01 pm, Gayle C Roth wrote: > To subscribers of the xforms list > > > Is the source for version 0.89.5 available? Currently, I'm running > with the .88 binary version on OpenVMS 7.3-2 and there are some > problems. One of them is that the text written to and entered into > input boxes does not show up. It's there, but it doesn't appear no > matter what color the background is. This bug is fixed in current cvs, so once you manage to build XForms 1.0 using the Imakefile, you'll be able to backport the fix... Angus From Gayle.C.Roth at nasa.gov Tue Jul 27 18:06:38 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Tue Jul 27 17:06:46 2004 Subject: [XForms] building on OpenVMS Message-ID: <5.1.1.5.2.20040727165927.016865b8@popserve.grc.nasa.gov> Hi. I built xforms 1.0.9 on an OpenVMS (that is, I got a shared executable with no undefined symbols). But, when I built one of the demos and tried to run it, I got the following message: "You forget to call fl_initialize". Of course, there IS a call to fl_initialize. Also, I'm sure it said "You forget..." rather than "You forgot...". When I searched on "You forget", all I got was "You forget to call fl_end_form...". I searched on "You forgot to call fl_initialize" and got a hit in flresource.c, when there was no 'fl_display' defined. Does anyone have an idea where this message is coming from and what I need to do to get rid of it? All the dates in xforms.olb look good. Thanks, Gayle From angus.leeming at btopenworld.com Tue Jul 27 23:15:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue Jul 27 17:15:12 2004 Subject: [XForms] building on OpenVMS In-Reply-To: <5.1.1.5.2.20040727165927.016865b8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040727165927.016865b8@popserve.grc.nasa.gov> Message-ID: <200407272215.33553.angus.leeming@btopenworld.com> On Tuesday 27 July 2004 10:06 pm, Gayle C Roth wrote: > To subscribers of the xforms list > > > Hi. > > I built xforms 1.0.9 on an OpenVMS (that is, I got a shared > executable with no undefined symbols). Congratulations! > But, when I built one of the demos and tried to run it, I got > the following message: "You forget to call fl_initialize". > Of course, there IS a call to fl_initialize. And you're sure that the demo is linked against this shared library and not another one that's installed in the system library, f.ex.? Angus From Gayle.C.Roth at nasa.gov Wed Jul 28 12:48:51 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Wed Jul 28 11:48:58 2004 Subject: [XForms] xforms 1.0.9 on VMS Message-ID: <5.1.1.5.2.20040728112856.0169f0e8@popserve.grc.nasa.gov> Hi. Great news!! It worked! I successfully ran a demo w/ xforms 1.0.9 on OpenVMS. The problem before is that apparently the system was looking for the shared library on sys$share (which had the .88 version) instead of where I built it. Our system administrator copied my 1.0.9 version to sys$share and then it worked. Thanks for you help, Angus! - Gayle P.S. Unfortunately the 'select: bad file number' message still happens. From angus.leeming at btopenworld.com Wed Jul 28 17:56:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Jul 28 11:56:13 2004 Subject: [XForms] xforms 1.0.9 on VMS In-Reply-To: <5.1.1.5.2.20040728112856.0169f0e8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040728112856.0169f0e8@popserve.grc.nasa.gov> Message-ID: <200407281656.33036.angus.leeming@btopenworld.com> On Wednesday 28 July 2004 4:48 pm, Gayle C Roth wrote: > Hi. > > Great news!! It worked! Patch please! (a README_VMS would be good too). > I successfully ran a demo w/ xforms 1.0.9 > on OpenVMS. The problem before is that apparently the system was > looking for the shared library on sys$share (which had the .88 > version) instead of where I built it. Our system administrator > copied my 1.0.9 version to sys$share and then it worked. Thanks > for you help, Angus! > > - Gayle > > P.S. Unfortunately the 'select: bad file number' message still > happens. Could you isolate the problem? Sending an invalid file descriptor to select isn't nice. Angus From amittal3 at csc.com Wed Jul 28 21:08:06 2004 From: amittal3 at csc.com (Ankur Mittal) Date: Wed Jul 28 12:20:07 2004 Subject: [XForms] saving to file and then redirecting to another page Message-ID: Hi , I am trying to save my instance data to a local xml file and then redirect to another page. The problem is it redirects me to another page first instead of saving. If I comment the redirect part(xforms:load) then data is saved to a local file easily. So How can I save the data first and then redirect to another file?. my relevant code is - ... Save and Continue Any help is the regard would be appreciated. Best regards, Ankur Mittal Software Engg, CSC, Noida Mobile :9891360614 Ext- 1371 ---------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. ---------------------------------------------------------------------------------------- From wd4nmq at comcast.net Wed Jul 28 18:41:41 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed Jul 28 17:41:39 2004 Subject: [XForms] Next release of xforms with client message included? Message-ID: <41081D95.3070800@comcast.net> Does anyone have a time frame as to when the next release of xforms will take place. Especially if it includes my fl_register_client_event() patch? I need to release a new version of my my software the uses the client message event code. Plus, I know if I release it with the patch for to do the patch themselves on xforms.1.0.90 I'll be openning a whole can of worms with the users of my code. And I DON'T even want to go there. Most have a hard enough time just installing my base application and if code isn't in an rpm, they're totally lost. Jeff From angus.leeming at btopenworld.com Thu Jul 29 10:56:07 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Jul 29 04:55:48 2004 Subject: [XForms] saving to file and then redirecting to another page In-Reply-To: References: Message-ID: <200407290956.07925.angus.leeming@btopenworld.com> On Wednesday 28 July 2004 3:38 pm, Ankur Mittal wrote: > Hi , > > I am trying to save my instance data to a local xml file and then > redirect to another page. Hi, Ankur. I suspect that you have the wrong list. This list is for the XForms GUI library and has nothing to do with the XForms xml language stuff. An unfortuate clash of project names but not our fault since we've been here since the mid eighties... Regards, Angus From angus.leeming at btopenworld.com Thu Jul 29 11:06:52 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu Jul 29 05:06:30 2004 Subject: [XForms] Next release of xforms with client message included? In-Reply-To: <41081D95.3070800@comcast.net> References: <41081D95.3070800@comcast.net> Message-ID: <200407291006.52346.angus.leeming@btopenworld.com> On Wednesday 28 July 2004 10:41 pm, Jeff wrote: > To subscribers of the xforms list > > > Does anyone have a time frame as to when the next release of xforms > will take place. Especially if it includes my > fl_register_client_event() patch? I need to release a new version > of my my software the uses the client message event code. Plus, I > know if I release it with the patch for to do the patch themselves > on xforms.1.0.90 I'll be openning a whole can of worms with the > users of my code. And I DON'T even want to go there. Most have a > hard enough time just installing my base application and if code > isn't in an rpm, they're totally lost. Hi, Jeff. Sorry, I've been very lax when it comes to XForms recently, but from what I remember you never posted a patch in 'ready to apply' form. Of course, it may just have dropped out of my sight but by 'pending' box currently has: so_version.diff, a trivial upgrade of library version numbers to happen just before release. shared_gl_canvas.diff, a patch from Jason Cipriani that won't be applied this time round because it crashes the X server on machines running Red Hat and Fedora Core distributions of linux. popup.diff, an experimental patch of mine that also won't be applied this time as it too is buggy. font_message.diff, an attempt to squash messages of the form "Bad FontStyle request -1: blahblahblah" that the original requester hasn't tested. Looks like it too won't go in... So, send me your patch again. From what I remember, JMarc thought that there were no 'issues' associated with it. Thereafter, I think that we're ready to release any time I get my arse in gear. Regards, Angus From Gayle.C.Roth at nasa.gov Fri Jul 30 14:56:54 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Fri Jul 30 13:57:02 2004 Subject: [XForms] xforms 1.0.9 library Message-ID: <5.1.1.5.2.20040730134128.01689838@popserve.grc.nasa.gov> Hi. On OpenVMS, I've now built and began running (just barely) my GUI that now uses the xforms 1.0.9 library. I've found a couple of weird things so far: 1) Calls to fl_calloc (from within my GUI) are causing access violations. However, when I substitute malloc, it works fine. 2) fl_raise_form causes an access violation, so I did a search through the library code to see if I could find its implementation, and it doesn't appear anywhere! Is there a substitute in this version for fl_raise_form? thanks, Gayle P.S. I'm going to be on vacation for 2 weeks starting Monday so all of you will get a break from that lady asking the weird OpenVMS questions. From GalbraithP at dfo-mpo.gc.ca Mon Aug 2 13:22:55 2004 From: GalbraithP at dfo-mpo.gc.ca (Peter S Galbraith) Date: Mon Aug 2 12:23:00 2004 Subject: [XForms] XForms Manual in HTML link is dead Message-ID: <20040802162255.7A37CD9DAB@mixing.qc.dfo.ca> On http://world.std.com/~xforms/ there is a dead link to the XForms Manual in HTML at http://www.westworld.com/~dau/xforms/forms.html Peter From Jean-Marc.Lasgouttes at inria.fr Mon Aug 2 19:23:21 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon Aug 2 12:23:28 2004 Subject: [XForms] Next release of xforms with client message included? In-Reply-To: <200407291006.52346.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 29 Jul 2004 10:06:52 +0100") References: <41081D95.3070800@comcast.net> <200407291006.52346.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Sorry, I've been very lax when it comes to XForms recently, but Angus> from what I remember you never posted a patch in 'ready to Angus> apply' form. I have no trace of such a 'finished' patch either. Angus> So, send me your patch again. From what I remember, JMarc Angus> thought that there were no 'issues' associated with it. That's it :) JMarc From jac4 at mindless.com Fri Aug 13 14:08:11 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri Aug 13 14:08:24 2004 Subject: [XForms] Moving towards 1.1? Message-ID: <20040813180811.003451C5E92@ws1-2a.us4.outblaze.com> I have a couple of questions about the next xforms release. We have been using xforms 1.0.90 here for quite some time, with the glx context sharing stuff, with no problems other than the GL problems with Fedora Core 1 (which occur with/without context sharing, and with xforms 0.89 and 1.0). I haven't even looked into the Fedora stuff since the last time we talked about it on this list but it seems to be unrelated/irrelevant. Also I remember somebody saying that the 1.1 release has a lot of changes already and the GL stuff might not make it in. Naturally, we'd feel more comfortable using an official xforms release rather than a hacky patched one. So: 1) How is version 1.1 coming along? Is there any estimated release date? 2) What is going to be new in 1.1 (just out of curiosity)? 3) Would it be possible to put the context sharing functionality in 1.1? It's pretty well-tested from my end (on Mac OS X 10.3.1-10.3.3 systems, and Redhat 8.0 and 9.0 systems with various nVidia cards and driver versions). As far as the context sharing stuff goes, I will post a patch shortly that has the combined contents of both the original patches plus the fix to the #include'd file in glcanvas_spec.c. On a different note, I asked a question awhile back about the missing publicly defined FL_NoColor, in regards to backgroundless canvases. Exporting FL_NoColor in forms.h would make people feel more comfortable about using it to turn off canvas background drawing, I think (rather than just passing 0x7FFFFFFF). Thanks, Jason From Gayle.C.Roth at nasa.gov Tue Aug 24 16:13:49 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Tue Aug 24 15:13:56 2004 Subject: [XForms] Problem showing forms Message-ID: <5.1.1.5.2.20040824145839.01697050@popserve.grc.nasa.gov> Hi. This problem is with version 1.0.9 on OpenVMS. When attempting to display most dialogs with fl_show_form, I get the following error: X Error of failed request - BadDrawable (invalid pixmap or window parameter). Major opcode of failed request: 67 (X_PolyRectangle). ... I checked the dimensions of these forms, and they look fine. Sometimes, the dialog comes up the first time but when I go through the very same thing a second time (i.e. choosing a specific item from my popup menu to get to the dialog), I get this BadDrawable error. I don't know if this has anything to do with it, but the forms that don't require that I get at them through one of my popup menu choices always appear fine. Thanks, Gayle From mkg at san.rr.com Mon Sep 13 10:51:57 2004 From: mkg at san.rr.com (Michael Gleicher) Date: Mon Sep 13 12:58:36 2004 Subject: [XForms] RE: xforms - a GUI toolkit for X Message-ID: Hello - I ran into a problem trying to build Xforms 1.0.90 on IBM AIX OS level 5.1. AIX make gave the following error after the configure script had run successfully: "Makefile", line 449: make: 1254-055 Dependency line needs \ colon or double colon separator This was puzzling, as line 449 was in the middle of the .PHONY target. However, if I commented out the line following the .PHONY list, # Hack so that the targets that use tar will also work with automake 1.4 AMTAR ?= $(TAR) AIX make was happy. The AMTAR line must be a forms that's unique to gnu make. I also ran into a problem using the IBM xlc_r7 compiler, compiling the jpeg files in the image directory. I got a preprocessor error because --HAVE_STDLIB_H is defined in both xforms config.h file, and also in the jpeg header files (in jconfig.h). I changed the jconfig.h file to conditionally define the symbol only if it is not already defined, and xforms built without problems from that point on. I just wanted to thank you all for this terrific toolkit and interface designer. I am especially happy that it does not require so many dependent tools and libraries that it becomes a major effort collect and build all the dependencies, which unfortunately is what has happened to GTK+. I am just now starting to learn how to use this, and am hoping it will be what I need for a couple of projects that I am undertaking. From what I've seen so far, it looks like it's just exactly what I've been looking for. Best regards, Michael Gleicher Regards, Michael Gleicher From maili at heisch.inka.de Mon Sep 20 14:52:47 2004 From: maili at heisch.inka.de (Gerald Emig) Date: Mon Sep 20 08:00:43 2004 Subject: [XForms] XForms for production code In-Reply-To: <200407291006.52346.angus.leeming@btopenworld.com> References: <41081D95.3070800@comcast.net> <200407291006.52346.angus.leeming@btopenworld.com> Message-ID: <20040920135247.499d221c@emig4.heisch.inka.de> To subscribers of the xforms list Hi all, What is the latest release of XForms that can be used in production code ? Where can I get it from ? Best regards, Gerald Emig From Jean-Marc.Lasgouttes at inria.fr Wed Sep 22 15:34:03 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Sep 22 08:34:22 2004 Subject: [XForms] XForms for production code In-Reply-To: <20040920135247.499d221c@emig4.heisch.inka.de> (Gerald Emig's message of "Mon, 20 Sep 2004 13:52:47 +0200") References: <41081D95.3070800@comcast.net> <200407291006.52346.angus.leeming@btopenworld.com> <20040920135247.499d221c@emig4.heisch.inka.de> Message-ID: >>>>> "Gerald" == Gerald Emig writes: Gerald> What is the latest release of XForms that can be used in Gerald> production code ? Where can I get it from ? The latest official release is the older xforms 1.0. Version 1.0.90, which is more recent, is not an official version, but I believe it is at least as good as 1.0. Both versions can be found at: http://savannah.nongnu.org/download/xforms/ And, yes, version 1.1.0 of xforms is long overdue. JMarc From jac4 at mindless.com Wed Sep 22 10:57:22 2004 From: jac4 at mindless.com (jason cipriani) Date: Wed Sep 22 10:57:42 2004 Subject: [XForms] Re: Moving towards 1.1? Message-ID: <20040922145722.16A331C5F0B@ws1-2a.us4.outblaze.com> Well, since I know the mailing list is still alive, I might as well resend this: --- I have a couple of questions about the next xforms release. We have been using xforms 1.0.90 here for quite some time, with the glx context sharing stuff, with no problems other than the GL problems with Fedora Core 1 (which occur with/without context sharing, and with xforms 0.89 and 1.0). I haven't even looked into the Fedora stuff since the last time we talked about it on this list but it seems to be unrelated/irrelevant. Also I remember somebody saying that the 1.1 release has a lot of changes already and the GL stuff might not make it in. Naturally, we'd feel more comfortable using an official xforms release rather than a hacky patched one. So: 1) How is version 1.1 coming along? Is there any estimated release date? 2) What is going to be new in 1.1 (just out of curiosity)? 3) Would it be possible to put the context sharing functionality in 1.1? It's pretty well-tested from my end (on Mac OS X 10.3.1-10.3.3 systems, and Redhat 8.0 and 9.0 systems with various nVidia cards and driver versions). As far as the context sharing stuff goes, I will post a patch shortly that has the combined contents of both the original patches plus the fix to the #include'd file in glcanvas_spec.c. On a different note, I asked a question awhile back about the missing publicly defined FL_NoColor, in regards to backgroundless canvases. Exporting FL_NoColor in forms.h would make people feel more comfortable about using it to turn off canvas background drawing, I think (rather than just passing 0x7FFFFFFF). --- Thanks, Jason From myaconis at nycap.rr.com Thu Sep 23 10:30:26 2004 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Thu Sep 23 09:30:39 2004 Subject: [XForms] fl_check_forms Message-ID: <007e01c4a171$7d431060$0264a8c0@dimensionxp> I coded an application that loads a significant amount of data from a database. The way the program is supposed to work is: 1. User clicks "Load" 2. A message appears (a custom form) (Please wait...loading data). 3. Data loads (20-30 seconds) 4. The message is hidden. 5. Normal operation occurs. However, when I originally coded this, I used fl_show_form to show the message form effectively within the "load" callback routine and then started to query the database. Usually what would happen with that was either the message wouldn't show up or there would be a black box where the message form was supposed to appear. In order to remedy this, I added a call to fl_check_forms immediately after the fl_show_form call. This caused the window to appear but the following messages appear: In RemoveTimeout [timeout.c 102] ID 560 not found -- Resource temporarily unavailable. In RemoveTimeout [timeout.c 102] ID 559 not found In RemoveTimeout [timeout.c 102] ID 558 not found In RemoveTimeout [timeout.c 102] ID 557 not found In RemoveTimeout [timeout.c 102] ID 556 not found In RemoveTimeout [timeout.c 102] ID 555 not found In RemoveTimeout [timeout.c 102] ID 554 not found Sometimes I get more messages sometimes less. I think the Resource temporarily unavailable message actually generates the multiple timeout routine and the program performance gets extremely poor. Does anyone have an idea as to why this is occuring? From laurent.fournier at lapp.in2p3.fr Fri Sep 24 12:04:31 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Fri Sep 24 05:04:39 2004 Subject: [XForms] fl_check_forms (from Matthew Yaconis) Message-ID: <4153E31F.5090304@lapp.in2p3.fr> Dear Matthiew, I have developped a graphical client which is supposed to run either on OSF/1, Linux and LynxOS. The sources of data are multiple : either data comes from the X11 server, or from a "Cm" message via TCP/IP or from a pipe. My application was loosing many graphical refreshes or was missing messages coming via TCP/IP (we use a comunication library called "Cm") from external servers, or missing piped data from forked processes. The problems appeared to be directly connected to the select() function. This function (as well as poll() which is used inside Xforms) seems not to get good results when it is called from many places in the application. It is to be noticed that even threads did not give good results (I tried to have one thread for each socket). The only solution was to "concentrate" all the select() calls into one (I had to rewrite the remote command code and not use Xform's one to get piped data). Because Cm is not "very open" to external sockets, I had to make an adaptation which calls fl_check_forms() from within a hack inside the Cm library when the X11 socket is activated. I made the same for pipes. Then now my application runs fine and does not loose anymore graphical events nor comunication data. In that way, the call to select() is inside my main loop and I can process data from every source when an event occurs. I am not sure my explanation is very clear to you, especially because of my poor english... The main word to retain would be : have only one call to select() in your application for both database exchanges and X11. But this is perhaps connected to the OS you are using, too. Regards, Laurent. From Todd.Denniston at ssa.crane.navy.mil Fri Sep 24 12:19:36 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Fri Sep 24 12:39:09 2004 Subject: [XForms] fl_check_forms (from Matthew Yaconis) References: <4153E31F.5090304@lapp.in2p3.fr> Message-ID: <41544918.9A2194BF@ssa.crane.navy.mil> laurent FOURNIER wrote: > > To subscribers of the xforms list > > Dear Matthiew, > > I have developped a graphical client which is supposed to run either on > OSF/1, Linux and LynxOS. The sources of data are multiple : either data > comes from the X11 server, or from a "Cm" message via TCP/IP or from a pipe. > My application was loosing many graphical refreshes or was missing > messages coming via TCP/IP (we use a comunication library called "Cm") > from external servers, or missing piped data from forked processes. > > The problems appeared to be directly connected to the select() function. > This function (as well as poll() which is used inside Xforms) seems not > to get good results when it is called from many places in the > application. It is to be noticed that even threads did not give good > results (I tried to have one thread for each socket). > > The only solution was to "concentrate" all the select() calls into one > (I had to rewrite the remote command code and not use Xform's one to get > piped data). Yes within an X application, using more than one select call is not good, because it can block (waiting for your file input and not the xserver) and you loose the illusion of interactive response. most X apps use the select of the widget library they are using, with xforms that is done by calling fl_add_io_callback to add your file io file descriptor(fd), and fl_remove_io_callback when you no longer want to watch the fd. For Fournier's app I realize that was difficult/impossible because of the "Cm" lib, but when possible it is best to do selects using fl_add_io_callback. In the past when I have been in Fournier's position, I have moved the lib calls into a small app that communicated with my X app via fifos and io_callbacked the fifos. For Yaconis's situation, if you have not already you might want to get forms.ps.gz from: ftp://ncmir.ucsd.edu/pub/xforms/DOC It may be a bit dated[1] but it is an excellent manual on xforms. section 4.2 talks about using fl_check_forms, I am betting Yaconis needs to call fl_check_forms more often to allow some timer callbacks to work. [1] unfortunately I cant see anything more from TC about a release of the doc post this: http://bob.usuhs.mil/pipermail/xforms/2003/000044.html maybe it's time to do a pstohtml + html2latex and ask TC to bless the output for GPL release??? (it's so fine a manual that I would really hate to see us have to start from scratch on a new one) http://cgm.cs.mcgill.ca/~luc/PSto.html http://html2latex.sourceforge.net/ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From myaconis at nycap.rr.com Mon Sep 27 11:44:43 2004 From: myaconis at nycap.rr.com (Matthew Yaconis) Date: Mon Sep 27 10:44:53 2004 Subject: [XForms] fl_check_forms (from Matthew Yaconis) References: <4153E31F.5090304@lapp.in2p3.fr> <41544918.9A2194BF@ssa.crane.navy.mil> Message-ID: <01ec01c4a4a0$881840f0$0264a8c0@dimensionxp> > For Yaconis's situation, if you have not already you might want to get > forms.ps.gz from: > ftp://ncmir.ucsd.edu/pub/xforms/DOC > It may be a bit dated[1] but it is an excellent manual on xforms. section 4.2 > talks about using fl_check_forms, I am betting Yaconis needs to call > fl_check_forms more often to allow some timer callbacks to work. The program executes kind of like this: 1. fl_do_forms (standard looping - the user clicks a button to go to step 2) 2. Callback routine starts 3. A window is shown 4. fl_check_forms is called (the window actually appears) 5. The rest of the callback executes ~30 seconds 6. The window is hidden. 7. The callback routine exits. 8. fl_do_forms standard looping continues So you are suggesting several calls to fl_check_forms at step 4 or trying to spread them out within the time intensive portion of execution? From Todd.Denniston at ssa.crane.navy.mil Mon Sep 27 11:12:59 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Mon Sep 27 11:16:51 2004 Subject: [XForms] fl_check_forms (from Matthew Yaconis) References: <4153E31F.5090304@lapp.in2p3.fr> <01ec01c4a4a0$881840f0$0264a8c0@dimensionxp> Message-ID: <41582DFB.78A55718@ssa.crane.navy.mil> Matthew Yaconis wrote: > > To subscribers of the xforms list > > > For Yaconis's situation, if you have not already you might want to get > > forms.ps.gz from: > > ftp://ncmir.ucsd.edu/pub/xforms/DOC > > It may be a bit dated[1] but it is an excellent manual on xforms. section > 4.2 > > talks about using fl_check_forms, I am betting Yaconis needs to call > > fl_check_forms more often to allow some timer callbacks to work. > > The program executes kind of like this: > > 1. fl_do_forms (standard looping - the user clicks a button to go to step 2) > 2. Callback routine starts > 3. A window is shown > 4. fl_check_forms is called (the window actually appears) > 5. The rest of the callback executes ~30 seconds > 6. The window is hidden. > 7. The callback routine exits. > 8. fl_do_forms standard looping continues > > So you are suggesting several calls to fl_check_forms at step 4 or trying to > spread them out within the time intensive portion of execution? If you read section 4.2 of the manual[1], pg 41&42, you will note that in step 5 you should at appropriate locations (many places or the outer loop of the long processing) you should make a call to fl_check_forms _AND_ then if the returned object is something that needs handled call to some kind of forms handler that returns as soon as the object is handled. i.e. fl_check_forms only tells you something needs done and what it is, it does not do the thing. [1] my copy is: Forms Library, V0.86, March 1997, T.C. Zhao -- 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 Oct 6 14:32:14 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Oct 6 08:31:07 2004 Subject: [XForms] Re: Moving towards 1.1? In-Reply-To: <20040922145722.16A331C5F0B@ws1-2a.us4.outblaze.com> References: <20040922145722.16A331C5F0B@ws1-2a.us4.outblaze.com> Message-ID: <200410061332.14366.angus.leeming@btopenworld.com> On Wednesday 22 September 2004 3:57 pm, jason cipriani wrote: > Well, since I know the mailing list is still alive, I might as well > resend this: The mailing list is alive, but I've been otherwise engaged. Jean-Marc has finally managed to stir me into action again. > 1) How is version 1.1 coming along? Is there any estimated release > date? 2) What is going to be new in 1.1 (just out of curiosity)? 3) > Would it be possible to put the context sharing functionality in > 1.1? It's pretty well-tested from my end (on Mac OS X 10.3.1-10.3.3 > systems, and Redhat 8.0 and 9.0 systems with various nVidia cards > and driver versions). Nothing has really happened to the source for a couple of months. It's basically ready to ship as 1.1 I think. I am not happy about shipping 1.1 with your GL context sharing stuff because it *does* cause my machine to crash. I assume that you'll eventually upgrade your machines from RH8,9? > As far as the context sharing stuff goes, I will post a patch > shortly that has the combined contents of both the original patches > plus the fix to the #include'd file in glcanvas_spec.c. What's this? I guess I've missed it. > On a different note, I asked a question awhile back about the > missing publicly defined FL_NoColor, in regards to backgroundless > canvases. Exporting FL_NoColor in forms.h would make people feel > more comfortable about using it to turn off canvas background > drawing, I think (rather than just passing 0x7FFFFFFF). I guess that I also missed this question. How about the attached patch? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fl_nocolor.diff Type: text/x-diff Size: 1169 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20041006/c16386eb/fl_nocolor.bin From dadembro at rockwellcollins.com Wed Oct 6 16:34:24 2004 From: dadembro at rockwellcollins.com (dadembro@rockwellcollins.com) Date: Wed Oct 6 15:35:11 2004 Subject: [XForms] Re: Moving towards 1.1? Message-ID: Angus, I got around to trying the 1.0.90 source archive and noticed it included an rpm spec file. So I gave it try and it mostly worked - successfully built, and generated rpms, and srpm without the expected library links (on a redhat 9 system). I have attached a diff file of the xforms.spec which includes a post installation, and pre uninstallation to create and remove the library links. Could you have a look at it and update the source tree? Thanks very much for supporting the xforms development. Regards, ---d.dembrow (See attached file: xforms.spec.diff)-------------- next part -------------- z'µìmjÛZržžÜ²Ç+¹¶ÞtÖ¦{è®k,¥ç‰÷ÓÊ—š¦™bq«b¢èr×­²ÚÞjd¢ÍízßÆòµëzÇ'¢Ö¯j)ZnW”®Xm¶Ÿÿn†î²èlš)¦*^®f¢—ü_¢¹¬ý«miÈfz{lÿm4ã]4ë÷¼yÆö×ñ~Šæ²Ê^r†ã From jac4 at mindless.com Wed Oct 6 18:32:51 2004 From: jac4 at mindless.com (jason cipriani) Date: Wed Oct 6 18:33:05 2004 Subject: [XForms] Re: Moving towards 1.1? Message-ID: <20041006223251.DA4971C5F10@ws1-2a.us4.outblaze.com> > I am not happy about shipping 1.1 with your GL context sharing stuff > because it *does* cause my machine to crash. I assume that you'll > eventually upgrade your machines from RH8,9? That stuff works on at least Redhat versions 6 through 9 (and OS X 10.3.0-10.3.6), and has been working stably for quite some time. I had problems with -normal- GL stuff crashing the X server (and even carrying GL states over into other applications *gasp*) on Fedora Core 1. Have not tried anything with Fedora 2+. It -seems- to be unique to Fedora. We weren't planning on "upgrading", except Fedora 2.6 has some nice thread/process scheduling features that we want to take advantage of; so we'll be switching at least one machine to Fedora soon and I can try to recreate the problems. BTW, what kind of graphics card (and what driver revisions) do you have on your system (apologies if you've already told me)? And you aren't still running Fedora Core 1 are you? Do you have the latest version of the X server? I'm not pushing, necessarily, to have the context sharing patch shipped with XForms; I'm just wondering if it will or won't, for organizational reasons. Looks like it won't. > > As far as the context sharing stuff goes, I will post a patch > > shortly that has the combined contents of both the original patches > > plus the fix to the #include'd file in glcanvas_spec.c. > > What's this? I guess I've missed it. Er, I coulda sworn I sent out a mail about this, but I can't find it in the archives. In glcanvas_spec.c, it #includes "forms.h" instead of "include/forms.h" or something like that. > > On a different note, I asked a question awhile back about the > > missing publicly defined FL_NoColor, in regards to backgroundless > > canvases. Exporting FL_NoColor in forms.h would make people feel > > more comfortable about using it to turn off canvas background > > drawing, I think (rather than just passing 0x7FFFFFFF). > > I guess that I also missed this question. How about the attached > patch? Perfect! Thanks! :D Original message is at http://bob.usuhs.mil/pipermail/xforms/2004/000499.html. Jason From jac4 at mindless.com Wed Oct 6 18:38:28 2004 From: jac4 at mindless.com (jason cipriani) Date: Wed Oct 6 18:38:32 2004 Subject: [XForms] Re: Moving towards 1.1? Message-ID: <20041006223828.3C73A1C5FF9@ws1-2a.us4.outblaze.com> Ah, found it. > > As far as the context sharing stuff goes, I will post a patch > > shortly that has the combined contents of both the original patches > > plus the fix to the #include'd file in glcanvas_spec.c. > > What's this? I guess I've missed it. I can't believe you forgot! :_( http://bob.usuhs.mil/pipermail/xforms/2004/000445.html From angus.leeming at btopenworld.com Thu Oct 7 00:44:48 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Oct 6 18:43:34 2004 Subject: [XForms] Re: Moving towards 1.1? In-Reply-To: <20041006223828.3C73A1C5FF9@ws1-2a.us4.outblaze.com> References: <20041006223828.3C73A1C5FF9@ws1-2a.us4.outblaze.com> Message-ID: <200410062344.48373.angus.leeming@btopenworld.com> On Wednesday 06 October 2004 11:38 pm, jason cipriani wrote: > Ah, found it. > > > > As far as the context sharing stuff goes, I will post a patch > > > shortly that has the combined contents of both the original > > > patches plus the fix to the #include'd file in glcanvas_spec.c. > > > > What's this? I guess I've missed it. > > I can't believe you forgot! :_( > > http://bob.usuhs.mil/pipermail/xforms/2004/000445.html Ok, but this isn't in the official sources yet, now is it ;-) Angus From angus.leeming at btopenworld.com Thu Oct 7 00:47:40 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Oct 6 18:46:27 2004 Subject: [XForms] Re: Moving towards 1.1? In-Reply-To: <20041006223251.DA4971C5F10@ws1-2a.us4.outblaze.com> References: <20041006223251.DA4971C5F10@ws1-2a.us4.outblaze.com> Message-ID: <200410062347.40987.angus.leeming@btopenworld.com> On Wednesday 06 October 2004 11:32 pm, jason cipriani wrote: > > I am not happy about shipping 1.1 with your GL context sharing > > stuff because it *does* cause my machine to crash. I assume that > > you'll eventually upgrade your machines from RH8,9? > > I'm just wondering if it will or won't, for organizational reasons. > Looks like it won't. Let's say "no" and get the bloody thing out of the door. > > > On a different note, I asked a question awhile back about the > > > missing publicly defined FL_NoColor, in regards to > > > backgroundless canvases. Exporting FL_NoColor in forms.h would > > > make people feel more comfortable about using it to turn off > > > canvas background drawing, I think (rather than just passing > > > 0x7FFFFFFF). > > > > I guess that I also missed this question. How about the attached > > patch? > > Perfect! Thanks! Angus From angus.leeming at btopenworld.com Thu Oct 7 00:57:23 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Oct 6 18:56:08 2004 Subject: [XForms] Re: Moving towards 1.1? In-Reply-To: References: Message-ID: <200410062357.23280.angus.leeming@btopenworld.com> On Wednesday 06 October 2004 8:34 pm, dadembro@rockwellcollins.com wrote: > Angus, > > I got around to trying the 1.0.90 source archive and noticed it > included an rpm spec file. So I gave it try and it mostly worked - > successfully built, and generated rpms, and srpm without the > expected library links (on a redhat 9 system). I have attached a > diff file of the xforms.spec which includes a post installation, > and pre uninstallation to create and remove the library links. > Could you have a look at it and update the source tree? Thank you, David. I noticed something similar sometime after the release of 1.0.90 and so did something similar myself. Funnily enough, I was just playing with the .spec file myself this evening when your mail arrived. Attached is my version of xforms.spec which is a little more complex than yours but which results in a fully relocatable rpm: $ rpm -i --prefix /usr/local xforms-1.0.90-1.i386.rpm > Thanks very much for supporting the xforms development. I've been somewhat lax recently... Angus -------------- next part -------------- Summary: XForms library Name: xforms Version: 1.0.90 Release: 1 Source0: http://savannah.nongnu.org/download/xforms/%{name}-%{version}.tar.gz License: LGPL Group: System/Libraries BuildRequires: xpm BuildRequires: xpm-devel BuildRoot: %{_tmppath}/%{name}-buildroot Prefix: %{_prefix} URL: http://www.nongnu.org/xforms/ %description XForms is a GUI toolkit based on Xlib for X Window Systems. It features a rich set of objects, such as buttons, sliders, and menus etc. integrated into an easy and efficient object/event callback execution model that allows fast and easy construction of X-applications. In addition, the library is extensible and new objects can easily be created and added to the library. %package -n %{name}-devel Summary: XForms development header files Group: System/Libraries Provides: %{name} %description -n %{name}-devel XForms header files for development. %prep %setup -q -n %{name}-%{version} %build ./configure --prefix=%{_prefix} --mandir=%{_mandir} --bindir=%{_bindir} \ --without-warnings --disable-debug --enable-optimization=-O2 make %install rm -rf ${RPM_BUILD_ROOT} install -d -m 755 ${RPM_BUILD_ROOT} make DESTDIR=${RPM_BUILD_ROOT} install gzip -f9 ${RPM_BUILD_ROOT}%{_mandir}/man?/* allfiles=`find ${RPM_BUILD_ROOT}/usr -type f -print | sed "s@^${RPM_BUILD_ROOT}@@g"` echo "$allfiles" | grep -v "^/usr/include/" > \ %{_tmppath}/%{name}-%{version}-binfiles echo "$allfiles" | grep "^/usr/include/" > \ %{_tmppath}/%{name}-%{version}-devfiles %clean rm -rf $RPM_BUILD_ROOT rm -f %{_tmppath}/%{name}-%{version}-binfiles rm -f %{_tmppath}/%{name}-%{version}-devfiles %files -n %{name} -f %{_tmppath}/%{name}-%{version}-binfiles %defattr(-,root,root) %doc COPYING.LIB Copyright ChangeLog INSTALL NEWS README %files -n %{name}-devel -f %{_tmppath}/%{name}-%{version}-devfiles %defattr(-,root,root) %post -n %{name} # # Create symbolic links from libforms.so.1.0.0 to libforms.so, libforms.so.1 # # 1. Create a list of files that require symbolic links. # lib_prefix=${RPM_INSTALL_PREFIX}/lib sofiles="" for file in \ "${lib_prefix}/libforms.so"* \ "${lib_prefix}/libformsGL.so"* \ "${lib_prefix}/libflimage.so"* do test -L "${file}" || sofiles="${sofiles} ${file}" done # # 2. Create the links. # for file in ${sofiles} do test -f "${file}" || continue symlink=`echo "${file}" | sed 's/\(\.so\.[0-9]\).*/\1/'` test "${file}" != "${symlink}" && ln -fs "${file}" "${symlink}" symlink=`echo "${symlink}" | sed 's/\(\.so\).*/\1/'` test "${file}" != "${symlink}" && ln -fs "${file}" "${symlink}" done # # Modify libforms.la et al. to prevent libtool from complaining # that the files have been moved. # test "${RPM_INSTALL_PREFIX}" = "/usr" && exit for la_name in libforms.la libformsGL.la libflimage.la do la_path="${lib_prefix}/${la_name}" tmp=`sed "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" ${la_path}` echo "${tmp}" > ${la_path} done %postun -n %{name} # # Remove symbolic links libforms.so, libforms.so.1, etc # lib_prefix=${RPM_INSTALL_PREFIX}/lib for file in \ "${lib_prefix}/libforms.so"* \ "${lib_prefix}/libformsGL.so"* \ "${lib_prefix}/libflimage.so"* do test -L "${file}" && rm -f "${file}" done %changelog * Wed Oct 6 2004 Angus Leeming 1.0.90 - Re-write the 'post' and 'postun' scripts to create the symbolic links correctly without requiring the SO_VERSION hack. * Fri May 7 2004 Angus Leeming 1.0.90 - add code to the 'post' script to modify libforms.la et al. to prevent libtool from complaining that the files have been moved. * Thu May 6 2004 Angus Leeming 1.0.90 - fix 'Release' and 'Source0' info. - add 'post' and 'postun' scripts to create and remove symbolic links, respectively. * Thu May 6 2004 Angus Leeming 1.0.90 - no longer place devfiles and binfiles in ${RPM_BUILD_ROOT}. Prevents rpm from bombing with a "Checking for unpackaged files" error. * Sat Aug 31 2002 Duncan Haldane 1.0-RC4 - mv fdesign, fd2ps to devel. restore xforms name of rpm. * Sun Jul 14 2002 Greg Hosler 1.0-RC4 - Pass DESTDIR to makeinstall_std. * Thu Jul 11 2002 Peter Galbraith 1.0-RC4 - Move from libxforms to libforms to match other distros. * Tue Jul 8 2002 Chris Freeze 1.0-RC4 - First stab at spec file. From angus.leeming at btopenworld.com Thu Oct 7 01:34:03 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed Oct 6 19:36:20 2004 Subject: [XForms] Resizing forms rapidly Message-ID: <200410070034.03880.angus.leeming@btopenworld.com> XForms has always behaved badly when a form is resized quickly. The attached patch provides some diagnostics. It appears that the width and height of the form don't keep up with the width and height of the window. Maybe there's hope of fixing this properly someday... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: diagnostic.diff Type: text/x-diff Size: 832 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20041007/222b47f9/diagnostic.bin From msz at astrouw.edu.pl Sun Oct 10 19:33:47 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Sun Oct 10 12:34:01 2004 Subject: [XForms] trapping "close window" desktop manager button? Message-ID: <20041010163347.GA11032@astrouw.edu.pl> Hi, When using a multi-form XForms application under any desktop manager that provides a title bar button for closing the window (usually something like X), it apparently kills the whole application which is often undesirable (especially when clicked on a "secondary" form window). Is there any portable (in terms of DM) way to trap such an action? regards, Michal. -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Sun Oct 10 19:19:00 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sun Oct 10 13:52:36 2004 Subject: [XForms] trapping "close window" desktop manager button? In-Reply-To: <20041010163347.GA11032@astrouw.edu.pl> References: <20041010163347.GA11032@astrouw.edu.pl> Message-ID: <200410101819.00820.angus.leeming@btopenworld.com> On Sunday 10 October 2004 5:33 pm, Michal Szymanski wrote: > To subscribers of the xforms list > > > Hi, > > When using a multi-form XForms application under any desktop > manager that provides a title bar button for closing the window > (usually something like X), it apparently kills the whole > application which is often undesirable (especially when clicked on > a "secondary" form window). Is there any portable (in terms of DM) > way to trap such an action? > > regards, Michal. Add this to the code that builds the dialog: fl_set_form_atclose(form_, C_WMHideCB, 0); C_WMHideCB can do anything you like, but to simply close the dialog you'd write: static int C_WMHideCB(FL_FORM * form, void * p) { fl_hide_form(form); return FL_CANCEL; } Angus From juerg.hauser at krist.unibe.ch Wed Oct 13 21:26:32 2004 From: juerg.hauser at krist.unibe.ch (=?iso-8859-1?Q?J=FCrg_Hauser?=) Date: Wed Oct 13 14:27:13 2004 Subject: [XForms] strange side effect of fl_initialize() Message-ID: <00f001c4b152$29d731e0$3b725c82@kristpc9> Hi all, I'm trying to move a program which runs on IRIX and RedHat 7.3 to SuSE 9.1. The program fails because a sscanf() instruction not involved in any Xforms business gives strange results. If I remove fl_initialize() (and all other fl_ instructions) sscanf() works prefectly well. If I add fl_initalize() only again, sscanf() behaves strange again. I've tried XForms 1.0 and 1.0.90. Any ideas? Thanks Juerg From Jean-Marc.Lasgouttes at inria.fr Thu Oct 14 08:37:56 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Oct 14 01:38:03 2004 Subject: [XForms] strange side effect of fl_initialize() In-Reply-To: <00f001c4b152$29d731e0$3b725c82@kristpc9> 20:26:32 +0200") References: <00f001c4b152$29d731e0$3b725c82@kristpc9> Message-ID: >>>>> "J?rg" == J?rg Hauser writes: J?rg> To subscribers of the xforms list Hi all, I'm trying to move a J?rg> program which runs on IRIX and RedHat 7.3 to SuSE 9.1. The J?rg> program fails because a sscanf() instruction not involved in any J?rg> Xforms business gives strange results. If I remove J?rg> fl_initialize() (and all other fl_ instructions) sscanf() works J?rg> prefectly well. If I add fl_initalize() only again, sscanf() J?rg> behaves strange again. I've tried XForms 1.0 and 1.0.90. Any J?rg> ideas? A wild guess: fl_initialize calls setlocale(LC_ALL,""). Could it be that it affects sscanf()? JMarc From jac4 at mindless.com Thu Oct 14 09:39:23 2004 From: jac4 at mindless.com (jason cipriani) Date: Thu Oct 14 09:39:41 2004 Subject: [XForms] strange side effect of fl_initialize() Message-ID: <20041014133923.834941C5E95@ws1-2a.us4.outblaze.com> I think I remember reading about this on this mail list in the past. If I'm not mistaken, setlocale() affects how sscanf reads numbers as far as things like using a "," or a "." to read decimal points, and other things probably. Could you be a little more specific about the "strange results"? Jason > J?rg> To subscribers of the xforms list Hi all, I'm trying to move a > J?rg> program which runs on IRIX and RedHat 7.3 to SuSE 9.1. The > J?rg> program fails because a sscanf() instruction not involved in any > J?rg> Xforms business gives strange results. If I remove > J?rg> fl_initialize() (and all other fl_ instructions) sscanf() works > J?rg> prefectly well. If I add fl_initalize() only again, sscanf() > J?rg> behaves strange again. I've tried XForms 1.0 and 1.0.90. Any > J?rg> ideas? > > A wild guess: fl_initialize calls setlocale(LC_ALL,""). Could it be > that it affects sscanf()? > > JMarc From juerg.hauser at krist.unibe.ch Thu Oct 14 16:39:16 2004 From: juerg.hauser at krist.unibe.ch (=?iso-8859-1?Q?J=FCrg_Hauser?=) Date: Thu Oct 14 09:39:53 2004 Subject: [XForms] strange side effect of fl_initialize() References: <00f001c4b152$29d731e0$3b725c82@kristpc9> Message-ID: <004801c4b1f3$334cd8a0$3b725c82@kristpc9> Jean-Marc, > > A wild guess: fl_initialize calls setlocale(LC_ALL,""). Could it be > that it affects sscanf()? > It maybe was a wild guess but it also is a full hit. Thanks a lot! Juerg From Jean-Marc.Lasgouttes at inria.fr Thu Oct 14 16:42:09 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Oct 14 09:42:14 2004 Subject: [XForms] strange side effect of fl_initialize() In-Reply-To: <20041014133923.834941C5E95@ws1-2a.us4.outblaze.com> (jason cipriani's message of "Thu, 14 Oct 2004 08:39:23 -0500") References: <20041014133923.834941C5E95@ws1-2a.us4.outblaze.com> Message-ID: >>>>> "jason" == jason cipriani writes: jason> I think I remember reading about this on this mail list in the jason> past. If I'm not mistaken, setlocale() affects how sscanf reads jason> numbers as far as things like using a "," or a "." to read jason> decimal points, and other things probably. Could you be a jason> little more specific about the "strange results"? Jason Exactly. And since this affects in particular the french and german locale, I guess it could affect whatever swiss-compliant locale J?rg is using. JMarc From Jean-Marc.Lasgouttes at inria.fr Thu Oct 14 16:55:08 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu Oct 14 09:55:11 2004 Subject: [XForms] strange side effect of fl_initialize() In-Reply-To: <004801c4b1f3$334cd8a0$3b725c82@kristpc9> 15:39:16 +0200") References: <00f001c4b152$29d731e0$3b725c82@kristpc9> <004801c4b1f3$334cd8a0$3b725c82@kristpc9> Message-ID: >>>>> "J?rg" == J?rg Hauser writes: J?rg> To subscribers of the xforms list Jean-Marc, >> A wild guess: fl_initialize calls setlocale(LC_ALL,""). Could it >> be that it affects sscanf()? >> J?rg> It maybe was a wild guess but it also is a full hit. Thanks a J?rg> lot! Juerg I really think that we should remove this setlocale from fl_initialize. The question is: are there applications out there which depend on this behaviour? I would like to do it before 1.1, actually (this was a new and undocumented behaviour since xforms 0.89.5). JMarc From juerg.hauser at krist.unibe.ch Thu Oct 14 17:41:47 2004 From: juerg.hauser at krist.unibe.ch (=?iso-8859-1?Q?J=FCrg_Hauser?=) Date: Thu Oct 14 11:06:18 2004 Subject: [XForms] strange side effect of fl_initialize() References: <20041014133923.834941C5E95@ws1-2a.us4.outblaze.com> Message-ID: <005c01c4b1fb$eea6c130$3b725c82@kristpc9> I've tried to parse the string " SYOP 1 0 0 0.0000000 0 1 0 0.0000000 0 0 1 0.0000000" with rc=sscanf(str,"%*10c%d%d%d%f %d%d%d%f %d%d%d%f ", ...) and get rc=4. LC_NUMERIC and all other LC_* are set to "de_DE.UTF-8". If call in my application after fl_initialize(...) setlocale(LC_NUMERIC, "POSIX") sscanf works fine. Juerg > > I think I remember reading about this on this mail list in the past. If I'm not mistaken, setlocale() affects how sscanf reads numbers as far as things like using a "," or a "." to read decimal points, and other things probably. Could you be a little more specific about the "strange results"? > > Jason > > > J?rg> To subscribers of the xforms list Hi all, I'm trying to move a > > J?rg> program which runs on IRIX and RedHat 7.3 to SuSE 9.1. The > > J?rg> program fails because a sscanf() instruction not involved in any > > J?rg> Xforms business gives strange results. If I remove > > J?rg> fl_initialize() (and all other fl_ instructions) sscanf() works > > J?rg> prefectly well. If I add fl_initalize() only again, sscanf() > > J?rg> behaves strange again. I've tried XForms 1.0 and 1.0.90. Any > > J?rg> ideas? > > > > A wild guess: fl_initialize calls setlocale(LC_ALL,""). Could it be > > that it affects sscanf()? > > > > JMarc From angus.leeming at btopenworld.com Fri Oct 15 10:13:00 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri Oct 15 04:11:41 2004 Subject: [XForms] strange side effect of fl_initialize() In-Reply-To: References: <00f001c4b152$29d731e0$3b725c82@kristpc9> <004801c4b1f3$334cd8a0$3b725c82@kristpc9> Message-ID: <200410150913.00451.angus.leeming@btopenworld.com> On Thursday 14 October 2004 2:55 pm, Jean-Marc Lasgouttes wrote: > I would like to do it before 1.1, actually (this was a new and > undocumented behaviour since xforms 0.89.5). Agreed. It's really nasty behaviour. Anything relying on undocumented features shouldn't ;-) Angus From paigen at heathen.com Mon Nov 1 20:48:09 2004 From: paigen at heathen.com (Paigen) Date: Mon Nov 1 14:48:59 2004 Subject: [XForms] Re: Thanks :) Message-ID: WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site's MIMEDefang policy, contact Robert Williams . For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment named price.scr was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://bob.usuhs.mil/pipermail/xforms/attachments/20041101/be986074/attachment.htm From paigen at heathen.com Wed Nov 3 08:52:39 2004 From: paigen at heathen.com (Paigen) Date: Wed Nov 3 02:53:11 2004 Subject: [XForms] Re: Thanks :) Message-ID: WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site's MIMEDefang policy, contact Robert Williams . For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment named price.scr was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://bob.usuhs.mil/pipermail/xforms/attachments/20041103/fbafd688/attachment.htm From paigen at heathen.com Sat Nov 6 06:49:05 2004 From: paigen at heathen.com (Paigen) Date: Sat Nov 6 00:49:24 2004 Subject: [XForms] Re: Thanks :) Message-ID: WARNING: This e-mail has been altered by MIMEDefang. Following this paragraph are indications of the actual changes made. For more information about your site's MIMEDefang policy, contact Robert Williams . For more information about MIMEDefang, see: http://www.roaringpenguin.com/mimedefang/enduser.php3 An attachment named Joke.scr was removed from this document as it constituted a security hazard. If you require this document, please contact the sender and arrange an alternate means of receiving it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://bob.usuhs.mil/pipermail/xforms/attachments/20041106/4da42bba/attachment.htm From pmcnary at cameron.net Wed Dec 8 14:24:12 2004 From: pmcnary at cameron.net (Paul McNary) Date: Wed Dec 8 15:24:38 2004 Subject: [XForms] Xforms 1.0.x on Openserver 5.0.7 Message-ID: <004f01c4dd63$e12ead90$3202a8c0@mcnary001> Hello Could someone give me the procedure to compile and install the current Xforms build on SCO Openserver 5.0.7. The .90 binaries functioned fine. Thank you Paul McNary pmcnary@cameron.net From dadembro at rockwellcollins.com Tue Dec 14 16:35:12 2004 From: dadembro at rockwellcollins.com (dadembro@rockwellcollins.com) Date: Tue Dec 14 16:36:48 2004 Subject: [XForms] Ghost popup menu behavior. Message-ID: I recently noticed strange behavior from menu popups which leave behind a ghost menu (like the display does not get redrawn). I can also duplicate the behavior with the pup.c demo program I will use as an example. I realize the steps to reproduce the ghost menu is idiotic. Unfortunately, I have to deal with a user that enjoys locating such things. Launch the pup executable. Select the PopUp menu button. o The four menu items appear. Select the flat Menu button to the right of the PopUp menu button. o The four menu items remain (this is the ghost menu) along with the three menu items for the flat Menu button. Does anyone else notice this behavior? Is there anyway to correct it? I am using xforms 1.0.90 on Redhat 9 Linux. Thanks, ---d.dembrow From Jean-Marc.Lasgouttes at inria.fr Wed Dec 15 09:53:31 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Dec 15 03:53:38 2004 Subject: [XForms] Ghost popup menu behavior. In-Reply-To: (dadembro@rockwellcollins.com's message of "Tue, 14 Dec 2004 16:35:12 -0500") References: Message-ID: >>>>> "d" == writes: d> To subscribers of the xforms list I recently noticed strange d> behavior from menu popups which leave behind a ghost menu (like the d> display does not get redrawn). I can also duplicate the behavior d> with the pup.c demo program I will use as an example. This happens because xforms try to use a backing store, and this is disabled by default on newer linux setup of X Window. I tried to see how to avoid it, but I failed miserably. If you start your X server with the +bs option, things should work again. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Dec 15 09:55:37 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Dec 15 03:55:44 2004 Subject: [XForms] Xforms 1.0.x on Openserver 5.0.7 In-Reply-To: <004f01c4dd63$e12ead90$3202a8c0@mcnary001> (Paul McNary's message of "Wed, 8 Dec 2004 14:24:12 -0600") References: <004f01c4dd63$e12ead90$3202a8c0@mcnary001> Message-ID: >>>>> "Paul" == Paul McNary writes: Paul> To subscribers of the xforms list Hello Paul> Could someone give me the procedure to compile and install the Paul> current Xforms build on SCO Openserver 5.0.7. The .90 binaries Paul> functioned fine. If you get xforms 1.0.90 from http://savannah.nongnu.org/download/xforms/ it should be as easy as ./configure make make install at least in theory. I'd be interested to see how well it works. JMarc PS: sorry for being sooo long to answer From Jean-Marc.Lasgouttes at inria.fr Wed Dec 15 10:28:11 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Dec 15 04:28:20 2004 Subject: [XForms] strange side effect of fl_initialize() In-Reply-To: <200410150913.00451.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 15 Oct 2004 09:13:00 +0100") References: <00f001c4b152$29d731e0$3b725c82@kristpc9> <004801c4b1f3$334cd8a0$3b725c82@kristpc9> <200410150913.00451.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Thursday 14 October 2004 2:55 pm, Jean-Marc Lasgouttes wrote: >> I would like to do it before 1.1, actually (this was a new and >> undocumented behaviour since xforms 0.89.5). Angus> Agreed. It's really nasty behaviour. Anything relying on Angus> undocumented features shouldn't ;-) OK, does the following patch do the right thing? JMarc PS: how about actually doing something for a release? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: nolocale.diff Type: text/x-patch Size: 2659 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20041215/069541c9/nolocale.bin From jac4 at mindless.com Wed Dec 15 10:45:14 2004 From: jac4 at mindless.com (jason cipriani) Date: Wed Dec 15 10:45:29 2004 Subject: [XForms] Showing an fselector on top of a fullscreen window. Message-ID: <20041215154514.35B3F2000C@ws1-1a.us4.outblaze.com> If my main application window was shown with the FL_PLACE_FULLSCREEN and FL_NO_BORDER styles, how do I show a file selector goodie on top of it? The fl_set_fselector_border() function does not let you set the fselector border to FL_NO_BORDER. However, unless a window has no border, it can't be displayed on top of a fullscreen window. This seems like a fairly simple task, I must be missing something. Thanks, Jason Cipriani From pmcnary at cameron.net Wed Dec 15 10:16:53 2004 From: pmcnary at cameron.net (Paul McNary) Date: Wed Dec 15 11:17:02 2004 Subject: [XForms] Xforms 1.0.x on Openserver 5.0.7 In-Reply-To: Message-ID: <006601c4e2c1$7dc8e5a0$3202a8c0@mcnary001> Jean-Marc Thank you for your reply. System OpenServer 507 MP3 UP3 GCC 2.95 GNU Make I get the following error when make: gmake[1]: Entering directory `/sco_maint/gcc343/gcc-3.4.3/libiberty' gmake[2]: Entering directory `/sco_maint/gcc343/gcc-3.4.3/libiberty/testsuite' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/sco_maint/gcc343/gcc-3.4.3/libiberty/testsuite' gmake[1]: Leaving directory `/sco_maint/gcc343/gcc-3.4.3/libiberty' gmake[1]: Entering directory `/sco_maint/gcc343/gcc-3.4.3/intl' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/sco_maint/gcc343/gcc-3.4.3/intl' gmake[1]: Entering directory `/sco_maint/gcc343/gcc-3.4.3/zlib' : gmake ; exec true "AR_FLAGS=rc" "CC_FOR_BUILD=gcc" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=-O2 -g -O2" "INSTALL=/usr/gnu/bin/ginstall -c" "INSTALL_DATA=/usr/gnu/bin/ginstall -c -m 644" "INSTALL_PROGRAM=/usr/gnu/bin/ginstall -c" "INSTALL_SCRIPT=/usr/gnu/bin/ginstall -c" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCFLAGS_FOR_TARGET=-O2 -g -O2" "MAKE=gmake" "MAKEINFO=makeinfo --split-size=5000000 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh" "EXPECT=expect" "RUNTEST=runtest" "RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/info" "libdir=/usr/local/lib" "prefix=/usr/local" "tooldir=/usr/local/i686-pc-sco3.2v5.0.7" "AR=ar" "AS=as" "CC=gcc" "CXX=c++" "LD=ld" "LIBCFLAGS=-g -O2" "NM=nm" "PICFLAG=" "RANLIB=ranlib" "DESTDIR=" DO=all multi-do gmake[1]: Leaving directory `/sco_maint/gcc343/gcc-3.4.3/zlib' gmake[1]: Entering directory `/sco_maint/gcc343/gcc-3.4.3/gcc' gmake \ CFLAGS="-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long " \ CONFIG_H="config.h auto-host.h ./../include/ansidecl.h" \ MAKEOVERRIDES= \ -f libgcc.mk all gmake[2]: Entering directory `/sco_maint/gcc343/gcc-3.4.3/gcc' for d in libgcc pic libgcc/pic; do \ if [ -d $d ]; then true; else /bin/sh ./mkinstalldirs $d; fi; \ done if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi /sco_maint/gcc343/gcc-3.4.3/gcc/xgcc -B/sco_maint/gcc343/gcc-3.4.3/gcc/ -B/usr/local/i686-pc-sco3.2v5.0.7/bin/ -B/usr/local/i686-pc-sco3.2v5.0.7/lib/ -isystem /usr/local/i686-pc-sco3.2v5.0.7/include -isystem /usr/local/i686-pc-sco3.2v5.0.7/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I. -I./. -I./../include -fPIC -DL_divdi3 -c ./libgcc2.c -fexceptions -fnon-call-exceptions -o libgcc/pic/_divdi3.o UX:i386as: ERROR: /usr/tmp//ccuTSSAD.s:324:defined relocatable values from the same section required, op - gmake[2]: *** [libgcc/pic/_divdi3.o] Error 1 gmake[2]: Leaving directory `/sco_maint/gcc343/gcc-3.4.3/gcc' gmake[1]: *** [stmp-multilib] Error 2 gmake[1]: Leaving directory `/sco_maint/gcc343/gcc-3.4.3/gcc' gmake: *** [all-gcc] Error 2 Thank you for your assisstance Paul McNary pmcnary@cameron.net > -----Original Message----- > From: xforms-bounces@bob.usuhs.mil > [mailto:xforms-bounces@bob.usuhs.mil] On Behalf Of Jean-Marc > Lasgouttes > Sent: Wednesday, December 15, 2004 2:56 AM > To: Paul McNary > Cc: xforms@bob.usuhs.mil > Subject: Re: [XForms] Xforms 1.0.x on Openserver 5.0.7 > > > To subscribers of the xforms list > > > >>>>> "Paul" == Paul McNary writes: > > Paul> To subscribers of the xforms list Hello > > Paul> Could someone give me the procedure to compile and install the > Paul> current Xforms build on SCO Openserver 5.0.7. The .90 binaries > Paul> functioned fine. > > If you get xforms 1.0.90 from > http://savannah.nongnu.org/download/xforms/ > it should be as easy as > ./configure > make > make install > at least in theory. I'd be interested to see how well it works. > > JMarc > > PS: sorry for being sooo long to answer > _______________________________________________ > 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 pmcnary at cameron.net Wed Dec 15 10:23:26 2004 From: pmcnary at cameron.net (Paul McNary) Date: Wed Dec 15 11:23:41 2004 Subject: [XForms] Xforms 1.0.x on Openserver 5.0.7 In-Reply-To: Message-ID: <006701c4e2c2$67e1ca80$3202a8c0@mcnary001> Jean-Marc Sorry the GCC is 3.4.3 however the error was the same on 2.95. Thank you Paul McNary pmcnary@cameron.net > -----Original Message----- > From: xforms-bounces@bob.usuhs.mil > [mailto:xforms-bounces@bob.usuhs.mil] On Behalf Of Jean-Marc > Lasgouttes > Sent: Wednesday, December 15, 2004 2:56 AM > To: Paul McNary > Cc: xforms@bob.usuhs.mil > Subject: Re: [XForms] Xforms 1.0.x on Openserver 5.0.7 > > > To subscribers of the xforms list > > > >>>>> "Paul" == Paul McNary writes: > > Paul> To subscribers of the xforms list Hello > > Paul> Could someone give me the procedure to compile and install the > Paul> current Xforms build on SCO Openserver 5.0.7. The .90 binaries > Paul> functioned fine. > > If you get xforms 1.0.90 from > http://savannah.nongnu.org/download/xforms/ > it should be as easy as > ./configure > make > make install > at least in theory. I'd be interested to see how well it works. > > JMarc > > PS: sorry for being sooo long to answer > _______________________________________________ > 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 Wed Dec 15 18:17:17 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Dec 15 12:17:22 2004 Subject: [XForms] Xforms 1.0.x on Openserver 5.0.7 In-Reply-To: <006701c4e2c2$67e1ca80$3202a8c0@mcnary001> (Paul McNary's message of "Wed, 15 Dec 2004 10:23:26 -0600") References: <006701c4e2c2$67e1ca80$3202a8c0@mcnary001> Message-ID: >>>>> "Paul" == Paul McNary writes: Paul> Jean-Marc Sorry the GCC is 3.4.3 however the error was the same Paul> on 2.95. Sorry, I am not sure that I understand. You are trying to build gcc, aren't you? How is this related to xforms? JMarc From jac4 at mindless.com Wed Dec 15 18:03:12 2004 From: jac4 at mindless.com (jason cipriani) Date: Wed Dec 15 18:03:37 2004 Subject: [XForms] Showing an fselector on top of a fullscreen window. Message-ID: <20041215230312.3083820009@ws1-1a.us4.outblaze.com> Yeah, that does the trick. I put too much faith in the documentation and didn't bother trying to pass FL_NOBORDER to that function. Thanks :) Jason ----- Original Message ----- From: dadembro@rockwellcollins.com To: jac4@mindless.com Subject: Re: [XForms] Showing an fselector on top of a fullscreen window. Date: Wed, 15 Dec 2004 15:57:13 -0500 > > I ran into the same problem and submitted a patch to allow a file selector > to be borderless. > > I am pretty certain it made it into the 1.0.90 release as that is what I am > using > now with a call to: > > fl_set_fselector_border( FL_NOBORDER ) > > Slainte, > ---d.dembrow > > > > > "jason cipriani" > m> To > Sent by: xforms@bob.usuhs.mil > xforms-bounces@bo cc > b.usuhs.mil > Subject > [XForms] Showing an fselector on > 12/15/2004 10:45 top of a fullscreen window. > AM > > > > > > > > > > To subscribers of the xforms list > > > If my main application window was shown with the FL_PLACE_FULLSCREEN and > FL_NO_BORDER styles, how do I show a file selector goodie on top of it? The > fl_set_fselector_border() function does not let you set the fselector > border to FL_NO_BORDER. However, unless a window has no border, it can't be > displayed on top of a fullscreen window. This seems like a fairly simple > task, I must be missing something. > > Thanks, > Jason Cipriani > > _______________________________________________ > 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 nimnod at gnu.univ.gda.pl Sat Dec 18 22:13:14 2004 From: nimnod at gnu.univ.gda.pl (Nimnod) Date: Sat Dec 18 16:13:18 2004 Subject: [XForms] None Message-ID: Hello, is this mailing list really living? The last post came around 1997 as far as I know... Is Xforms still supported and developed? From jac4 at mindless.com Sat Dec 18 17:07:44 2004 From: jac4 at mindless.com (jason cipriani) Date: Sat Dec 18 17:08:06 2004 Subject: [XForms] None Message-ID: <20041218220744.673841C5EA7@ws1-2a.us4.outblaze.com> > is this mailing list really living? Yeah, there's flurries of activity every once in a while. The mailing list archives moved as well; although I'll be damned if I can remember where they moved to. > Is Xforms still supported and developed? Heh... wouldn't that be nice. From jac4 at mindless.com Sat Dec 18 17:19:00 2004 From: jac4 at mindless.com (jason cipriani) Date: Sat Dec 18 17:19:05 2004 Subject: [XForms] None Message-ID: <20041218221900.E2D071C5E93@ws1-2a.us4.outblaze.com> Ah... looks like mail to nimnod's been getting spamblocked. His loss! ;) ----- Original Message ----- From: "jason cipriani" To: Nimnod , xforms@bob.usuf2.usuhs.mil Subject: Re: [XForms] None Date: Sat, 18 Dec 2004 17:07:44 -0500 > > To subscribers of the xforms list > > > > is this mailing list really living? > > Yeah, there's flurries of activity every once in a while. The mailing list > archives moved as well; although I'll be damned if I can remember where they > moved to. > > > Is Xforms still supported and developed? > > Heh... wouldn't that be nice. > > _______________________________________________ > 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 Tue Dec 28 16:30:47 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue Dec 28 10:31:02 2004 Subject: [XForms] Xforms 1.0.x on Openserver 5.0.7 In-Reply-To: <009401c4e2f8$15898f80$3202a8c0@mcnary001> (Paul McNary's message of "Wed, 15 Dec 2004 16:47:40 -0600") References: <009401c4e2f8$15898f80$3202a8c0@mcnary001> Message-ID: >>>>> "Paul" == Paul McNary writes: Paul> I added the following to local.h as OSR 507 still doesn't have Paul> S_ISSOCK: Here is the patch I intend to commit shortly. I see no reason why it would not work, especially since GU diff uses something like that. Paul, I'd appreciate if you could try the patch on 1.0.90 JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: issock.diff Type: text/x-patch Size: 1559 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20041228/d20aa8df/issock.bin From Jean-Marc.Lasgouttes at inria.fr Wed Dec 29 12:01:16 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed Dec 29 06:01:22 2004 Subject: [XForms] RE: xforms - a GUI toolkit for X In-Reply-To: (Michael Gleicher's message of "Mon, 13 Sep 2004 09:51:57 -0700") References: Message-ID: >>>>> "Michael" == Michael Gleicher writes: Michael> I ran into a problem trying to build Xforms 1.0.90 on IBM AIX Michael> OS level 5.1. Hello Michael, I am slowly trying to go through my xforms inbox, sorry for the delay. I am going to commit the following patch, which will hopefully solve your AIX problems. JMarc -------------- next part -------------- A non-text attachment was scrubbed... Name: aix.diff Type: text/x-patch Size: 2532 bytes Desc: not available Url : http://bob.usuhs.mil/pipermail/xforms/attachments/20041229/1d8c0add/aix.bin From angus.leeming at btopenworld.com Fri Jan 2 17:17:43 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 2 Jan 2004 22:17:43 +0000 Subject: [XForms] Re: XForms In-Reply-To: References: Message-ID: <200401022217.43948.angus.leeming@btopenworld.com> On Friday 02 January 2004 9:55 pm, you wrote: > The xforms download page at savannah.nongnu.org/files/?group=xforms is > not operational. Wehre is the download page for xforms? Is xforms still > an active project or has it gone moribund (and I should use some other > library for my project). The library is alive and well, but the savannah web site was hacked. Everything is now working fine again, but the download page is not yet repaired. Find the xforms 1.0 release (871kB) at http://www.devel.lyx.org/~leeming/xforms-1.0.tar.gz and today's cvs snapshot (989kB) at http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz The code is little changed, but we've migrated the build away from Imake to the GNU autotools. It should be trivially easy to build and install now... > Also what is the relation between XForms and the XML forms library > called Xforms (www.w3.org/MarkUp/Forms) I assume that the similarity of > names is all the similarity ( and the similarity of names is ripe for > confusion.) There is no relation at all. The xforms gui toolkit has been around since the mid-80's, so could claim to have 'been there first' ... Regards, Angus From angus.leeming at btopenworld.com Wed Jan 7 04:28:26 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 7 Jan 2004 09:28:26 +0000 Subject: [XForms] Re: XForms In-Reply-To: References: <200401042017.36360.angus.leeming@btopenworld.com> Message-ID: <200401070928.26124.angus.leeming@btopenworld.com> On Wednesday 07 January 2004 8:55 am, you wrote: > Just a suggestion: The axis tick marks if you are using a log scale for > the axis is messed up. The minor ticks should not be equally spaced-- > they should be at the logs of the integers Ie, it would be good to be > able to have the minor tick marks falling on the integrers (ie log(2) > log(3)...) . > The current behaviour in which the minor tick marks are > placed at equally spaced points along the axis does not work at all. > > Also, I want to plot a plot from 10 to 20000 along the x axis with log > scale. The tick mark function however forces the axis to go to 100,000. > Ie it does not like having the right hand edge not falling on a major tick > mark. Again, this makes for a graph with wasted spece. The plot should > respect the bounds-- with the bounds located on the edges or at least it > should be possible to force it to do so. Hi Bill. I think that you should consider subscribing to the xforms mailing list, xforms at bob.usuhs.mil. See http://bob.usuhs.mil/mailserv/xforms.html for instructions how to subscribe. Additionally, there's a bug tracker on the savannah project page http://savannah.nongnu.org/bugs/?group=xforms&func=additem Adding your request there will ensure that it doesn't get lost. Regards, Angus From bob at bob.usuhs.mil Wed Jan 7 09:26:02 2004 From: bob at bob.usuhs.mil (Robert Williams) Date: Wed, 07 Jan 2004 09:26:02 -0500 Subject: [XForms] Subscribing to Xforms In-Reply-To: <200401070928.26124.angus.leeming@btopenworld.com> References: <200401042017.36360.angus.leeming@btopenworld.com> <200401070928.26124.angus.leeming@btopenworld.com> Message-ID: <3FFC16FA.3060905@bob.usuhs.mil> Just a brief correction: With respect to the instructions about how to subscribe to the xforms list, the mailserv page cited below, belonging to the old majordomo set of files, is no longer functional. Xforms now uses mailman, and the instructions for subscribing are at the bottom of this and every other XForms list message. Angus Leeming wrote: > To subscribers of the xforms list > > > On Wednesday 07 January 2004 8:55 am, you wrote: > >>Just a suggestion: The axis tick marks if you are using a log scale for >>the axis is messed up. The minor ticks should not be equally spaced-- >>they should be at the logs of the integers Ie, it would be good to be >>able to have the minor tick marks falling on the integrers (ie log(2) >>log(3)...) . >> The current behaviour in which the minor tick marks are >>placed at equally spaced points along the axis does not work at all. >> >>Also, I want to plot a plot from 10 to 20000 along the x axis with log >>scale. The tick mark function however forces the axis to go to 100,000. >>Ie it does not like having the right hand edge not falling on a major tick >>mark. Again, this makes for a graph with wasted spece. The plot should >>respect the bounds-- with the bounds located on the edges or at least it >>should be possible to force it to do so. > > > Hi Bill. > I think that you should consider subscribing to the xforms mailing list, > xforms at bob.usuhs.mil. See http://bob.usuhs.mil/mailserv/xforms.html for > instructions how to subscribe. I've removed this page. Thanks Angus for the nudge. > > Additionally, there's a bug tracker on the savannah project page > http://savannah.nongnu.org/bugs/?group=xforms&func=additem > Adding your request there will ensure that it doesn't get lost. > > Regards, > Angus > > > > _______________________________________________ > 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. Robert Williams Dept. of Biomedical Informatics Uniformed Services University 301-295-3568 From msz at astrouw.edu.pl Mon Jan 12 21:20:43 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue, 13 Jan 2004 03:20:43 +0100 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <200312031238.54118.angus.leeming@btopenworld.com> References: <200312031238.54118.angus.leeming@btopenworld.com> Message-ID: <20040113022043.GA26511@astrouw.edu.pl> On Wed, Dec 03, 2003 at 12:38:54PM +0000, Angus Leeming wrote: > To subscribers of the xforms list > > > 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 ;-) Angus, So you liked it but did not include it, did you? I've downloaded 1.0.2 from your page (as Savannah is still down) but it does not seem to contain this patch. Well I'm now a bit bifurcated :) I would like to use both your version of Clive's JPEG/EXIF patch (in CVS) *and* Mike's double click patch (apparently only in standard 1.0 release). This does not seem to be possible at the same time without fiddling with the code which I would strongly not want to do. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From mheffner at vt.edu Thu Jan 15 00:30:42 2004 From: mheffner at vt.edu (Mike Heffner) Date: Thu, 15 Jan 2004 00:30:42 -0500 (EST) Subject: [XForms] fl_set_font_name() verbiage Message-ID: When fl_set_font_name() fails it will return -1 but it also prints: In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah This function is typically used as a method of testing whether a font is loadable or not, so it's not always a fatal condition. Can this print statement be wrapped in a debug-only conditional? Thanks, Mike -- Mike Heffner From Jean-Marc.Lasgouttes at inria.fr Thu Jan 15 06:25:20 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 15 Jan 2004 12:25:20 +0100 Subject: [XForms] So, what now? Message-ID: Now that savannah has (almost) returned to life, it seems that we have no more excuse for letting this project languish :) - we have to check whether the code has been hacked. I wonder who could do that, but... The diffs since last trusted version are at ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz Unfortunately, it seems that there has been a lot of whitespace changes, and this makes checking very boring. I do not know of a way to change the diffs to ignore such garbage. Once this is done (or we have decided not to do it :), Angus should notice the savannah people. - I have some changes in my tree, but unfortunately I do not have access to ssh2 here, only ssh1 (believe it or not). So I cannot even do anonymous cvs anymore. I'll have to find out a solution. - we need to write down a TODO list, and actually handle it :) JMarc From Todd.Denniston at ssa.crane.navy.mil Thu Jan 15 10:15:54 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu, 15 Jan 2004 10:15:54 -0500 Subject: [XForms] So, what now? References: Message-ID: <4006AEAA.415506BA@ssa.crane.navy.mil> Jean-Marc Lasgouttes wrote: > > - we have to check whether the code has been hacked. I wonder who > could do that, but... The diffs since last trusted version are at > ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz > > Unfortunately, it seems that there has been a lot of whitespace > changes, and this makes checking very boring. I do not know of a way > to change the diffs to ignore such garbage. pass the -w option to gnu diff, -w Ignore white space when comparing lines. `diff -w [other options]` or `cvs diff -w [other options]` if there is both a white space and real change the line will still show as a diff. > you may also want: from diff man page -b Ignore changes in amount of white space. -B Ignore changes that just insert or delete blank lines. --ignore-blank-lines Ignore changes that just insert or delete blank lines. --ignore-space-change Ignore changes in amount of white space. or --ignore-all-space Ignore white space when comparing lines. -- 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 Jan 15 10:24:20 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 15 Jan 2004 16:24:20 +0100 Subject: [XForms] So, what now? In-Reply-To: <4006AEAA.415506BA@ssa.crane.navy.mil> (Todd Denniston's message of "Thu, 15 Jan 2004 10:15:54 -0500") References: <4006AEAA.415506BA@ssa.crane.navy.mil> Message-ID: >>>>> "Todd" == Todd Denniston writes: Todd> Jean-Marc Lasgouttes wrote: >> Todd> >> - we have to check whether the code has been hacked. I wonder who >> could do that, but... The diffs since last trusted version are at >> ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz >> >> Unfortunately, it seems that there has been a lot of whitespace >> changes, and this makes checking very boring. I do not know of a >> way to change the diffs to ignore such garbage. Todd> pass the -w option to gnu diff, -w Ignore white space when Todd> comparing lines. Yes, but can I do this to an already existing diff? That's what I have here. JMarc From Todd.Denniston at ssa.crane.navy.mil Thu Jan 15 10:29:15 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu, 15 Jan 2004 10:29:15 -0500 Subject: [XForms] So, what now? References: Message-ID: <4006B1CB.8C488249@ssa.crane.navy.mil> Jean-Marc Lasgouttes wrote: > > >>>>> "Todd" == Todd Denniston writes: > > Todd> Jean-Marc Lasgouttes wrote: > >> > Todd> > >> - we have to check whether the code has been hacked. I wonder who > >> could do that, but... The diffs since last trusted version are at > >> ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz > >> > >> Unfortunately, it seems that there has been a lot of whitespace > >> changes, and this makes checking very boring. I do not know of a > >> way to change the diffs to ignore such garbage. > Todd> pass the -w option to gnu diff, -w Ignore white space when > Todd> comparing lines. > > Yes, but can I do this to an already existing diff? That's what I have here. > drad, no. unless you can use them as patches to some trusted set and then do the diffs again. I have not downloaded the tarball so I do not know what's there, and I just noticed that the diffs were at gnu.org so you did not gen them. any chance someone at gnu.org could be coaxed into generating the same diffs with the options you want/need? > JMarc -- 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 Jan 15 10:32:59 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 15 Jan 2004 16:32:59 +0100 Subject: [XForms] So, what now? In-Reply-To: <4006B1CB.8C488249@ssa.crane.navy.mil> (Todd Denniston's message of "Thu, 15 Jan 2004 10:29:15 -0500") References: <4006AEAA.415506BA@ssa.crane.navy.mil> <4006B1CB.8C488249@ssa.crane.navy.mil> Message-ID: >>>>> "Todd" == Todd Denniston writes: Todd> drad, no. unless you can use them as patches to some trusted set Todd> and then do the diffs again. I have not downloaded the tarball Todd> so I do not know what's there, and I just noticed that the diffs Todd> were at gnu.org so you did not gen them. any chance someone at Todd> gnu.org could be coaxed into generating the same diffs with the Todd> options you want/need? I guess they think that if we are very paranoid about security we should not ignore security implications of whitespace... I have to say that my motivation for hunting hacks in xforms code is a bit low. I guess we have to do it nevertheless. JMarc From angus.leeming at btopenworld.com Thu Jan 15 14:49:37 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 15 Jan 2004 19:49:37 +0000 Subject: [XForms] So, what now? In-Reply-To: References: Message-ID: <200401151949.37777.angus.leeming@btopenworld.com> On Thursday 15 January 2004 11:25 am, Jean-Marc Lasgouttes wrote: > Now that savannah has (almost) returned to life, it seems that we have > no more excuse for letting this project languish :) > > - we have to check whether the code has been hacked. I wonder who > could do that, but... The diffs since last trusted version are at > ftp://ftp.gnu.org/savannah/changsets/xforms-changes.tar.gz > > Unfortunately, it seems that there has been a lot of whitespace > changes, and this makes checking very boring. I do not know of a way > to change the diffs to ignore such garbage. I have already checked a large chunk of it. Everything in the root directory, in config and in demos. That leaves the directories fd2ps, fdesign, gl, image and lib. Take your pick. > > Once this is done (or we have decided not to do it :), Angus should > notice the savannah people. ... > - I have some changes in my tree, but unfortunately I do not have > access to ssh2 here, only ssh1 (believe it or not). So I cannot even > do anonymous cvs anymore. I'll have to find out a solution. Tell your admins to move with the times? > - we need to write down a TODO list, and actually handle it :) ... Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jan 16 10:05:51 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 16 Jan 2004 16:05:51 +0100 Subject: [XForms] So, what now? In-Reply-To: <200401151949.37777.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 15 Jan 2004 19:49:37 +0000") References: <200401151949.37777.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I have already checked a large chunk of it. Everything in the Angus> root directory, in config and in demos. That leaves the Angus> directories fd2ps, fdesign, gl, image and lib. Take your pick. Thanks for doing this. I'll try to do my share. >> - I have some changes in my tree, but unfortunately I do not have >> access to ssh2 here, only ssh1 (believe it or not). So I cannot >> even do anonymous cvs anymore. I'll have to find out a solution. Angus> Tell your admins to move with the times? Yes, something like that. It seems that they want a solution that integrates perfectly with afs/kerberos5 (which I do not really need) and this seems difficult to achieve. >> - we need to write down a TODO list, and actually handle it :) Angus> ... Is that some substitute for *shrug*? JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Jan 16 10:37:05 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 16 Jan 2004 16:37:05 +0100 Subject: [XForms] So, what now? In-Reply-To: <200401151949.37777.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 15 Jan 2004 19:49:37 +0000") References: <200401151949.37777.angus.leeming@btopenworld.com> Message-ID: A non-text attachment was scrubbed... Name: signal.diff Type: text/x-patch Size: 1405 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040116/0670c97c/attachment.bin From angus.leeming at btopenworld.com Sat Jan 17 08:18:29 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 17 Jan 2004 13:18:29 +0000 Subject: [XForms] So, what now? In-Reply-To: References: <200401151949.37777.angus.leeming@btopenworld.com> Message-ID: <200401171318.29328.angus.leeming@btopenworld.com> On Friday 16 January 2004 3:37 pm, Jean-Marc Lasgouttes wrote: > Angus> I have already checked a large chunk of it. Everything in the > Angus> root directory, in config and in demos. That leaves the > Angus> directories fd2ps, fdesign, gl, image and lib. Take your pick. > > OK, I have checked the remainder, thanks to a diff provided to me by > Mike Heffner (thanks Mike!). So it seems that we are clear in this > respect (which is not a surprise). Indeed. All I need do now is tell savannah that the source is clean. The question is "how"? Is it sufficient to drop a mail to savannah-hackers at gnu.org? > It may be nice also to put xforms-1.0 back to the download area, if we > have access to that. http://savannah.nongnu.org/ Latest News Download areas posted by corvus, Thu 01/15/04 at 17:15 - 0 reply Files that were in the download areas on Savannah before the compromise can be downloaded from ftp://ftp.gnu.org/savannah/files. We kindly ask project administrators to verify the integrity of those Project download area posted by rudy, Sat 01/10/04 at 13:56 - 0 reply As most user have noticed, the project download area is not yet working. We are working on it. So I guess that I should check the download... done. Again, how do I report this to savannah? > Finally, this short patch is the only local change I had in my tree. > It should fix compilation problems related to signal cllbacks > returning either nothing or an int. The solution I took is to cast our > callback which returns void to the proper prototype. I hope that C > allows that, but please tell me if I am wrong. > > This fix was the last in my personal must-fix list. > > JMarc From Jean-Marc.Lasgouttes at inria.fr Mon Jan 19 04:38:29 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 19 Jan 2004 10:38:29 +0100 Subject: [XForms] So, what now? In-Reply-To: <200401171318.29328.angus.leeming@btopenworld.com> (Angus Leeming's message of "Sat, 17 Jan 2004 13:18:29 +0000") References: <200401151949.37777.angus.leeming@btopenworld.com> <200401171318.29328.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Indeed. All I need do now is tell savannah that the source is Angus> clean. The question is "how"? Is it sufficient to drop a mail Angus> to savannah-hackers at gnu.org? >From http://savannah.gnu.org/forum/forum.php?forum_id=2749: These difference sets should assist you in auditing your software. Once you have audited your packages, please contact <>, and let us know the results. JMarc From angus.leeming at btopenworld.com Mon Jan 19 18:53:10 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 19 Jan 2004 23:53:10 +0000 Subject: [XForms] So, what now? In-Reply-To: References: <200401171318.29328.angus.leeming@btopenworld.com> Message-ID: <200401192353.10481.angus.leeming@btopenworld.com> On Monday 19 January 2004 9:38 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> Indeed. All I need do now is tell savannah that the source is > Angus> clean. The question is "how"? Is it sufficient to drop a mail > Angus> to savannah-hackers at gnu.org? > > From http://savannah.gnu.org/forum/forum.php?forum_id=2749: > > These difference sets should assist you in auditing your software. Once > you have audited your packages, please contact > <>, and let us know the results. Thanks, JMarc. I've sent of the letter telling them that all is Okk with our sources. Angus From mheffner at vt.edu Thu Jan 22 16:21:12 2004 From: mheffner at vt.edu (Mike Heffner) Date: Thu, 22 Jan 2004 16:21:12 -0500 (EST) Subject: [XForms] Xforms text editors Message-ID: For the XFMail project we use the text editor written by Marc van Kempen, available at: http://cvs.sourceforge.net/viewcvs.py/archimedes/xfmail/src/editor/ It is a great editor and we've been using it for quite awhile, however it is quite slow when viewing/editing a large email with 1,000+ lines. To improve it we are going to have to rewrite large portions of it to reduce the O(n) line insertion/deletion/lookup time. I wanted to pool the xforms community to see whether there are any other xforms text editors out there that we could look into as a replacement. Also, assuming the author agrees to a GPL license...would the xforms community be interested in importing this into xforms itself if it is the best current text editor available? Cheers, Mike -- Mike Heffner From msz at astrouw.edu.pl Tue Feb 24 08:56:23 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue, 24 Feb 2004 14:56:23 +0100 Subject: [XForms] strange message from app using xforms-1.0.2 Message-ID: <20040224135623.GA22585@astrouw.edu.pl> Hi, I have just recompiled my old application with new CVS 1.0.2 version of XForms. I did it on three different systems: Linux/x86 (RH 7.2) Linux/alpha (RH 7.2) Solaris/sparc (2.5.1) When invoked, it does its job just fine on all systems, but on one, namely Solaris, it outputs following strange message at start: In fl_initialize [flresource.c 972] Could not create an input context it does not show up on any Linux system. Any ideas what this could mean? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From msz at astrouw.edu.pl Tue Feb 24 09:01:24 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue, 24 Feb 2004 15:01:24 +0100 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: <200401130842.43682.angus.leeming@btopenworld.com> References: <200312031238.54118.angus.leeming@btopenworld.com> <20040113022043.GA26511@astrouw.edu.pl> <200401130842.43682.angus.leeming@btopenworld.com> Message-ID: <20040224140124.GA22610@astrouw.edu.pl> On Tue, Jan 13, 2004 at 08:42:43AM +0000, Angus Leeming wrote: > > Well I'm now a bit bifurcated :) I would like to use both your version > > of Clive's JPEG/EXIF patch (in CVS) *and* Mike's double click patch > > (apparently only in standard 1.0 release). This does not seem to be > > possible at the same time without fiddling with the code which I would > > strongly not want to do. > > Why not? I'd recommend that you grab an anoncvs copy of the repository and > apply Mike's patch. When it gets merged into the repository itself, cvs will > either report a conflict (trivially easy to resolve) or will tell you that > your checked-out tree already contains the patch. Well, I did try :) Attached is the manually crafted versions of the Mike's patch applied to the source named xforms-1.0.2 taken from http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz Experts, Author, please check it. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND -------------- next part -------------- --- lib/fselect.c.orig Thu Nov 13 22:56:02 2003 +++ lib/fselect.c Mon Feb 23 14:32:13 2004 @@ -314,23 +314,16 @@ 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; @@ -340,31 +333,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); @@ -379,7 +350,7 @@ fl_set_input(lfs->input, seltext); strcpy(lfs->filename, seltext); - if (dblclick) + if (isdblclick) { if (lfs->fselect_cb) { @@ -390,7 +361,6 @@ fl_object_qenter(lfs->ready); } } - return; } #endif @@ -969,6 +939,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 Tue Feb 24 10:00:07 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 24 Feb 2004 16:00:07 +0100 Subject: [XForms] strange message from app using xforms-1.0.2 In-Reply-To: <20040224135623.GA22585@astrouw.edu.pl> (Michal Szymanski's message of "Tue, 24 Feb 2004 14:56:23 +0100") References: <20040224135623.GA22585@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Hi, Michal> I have just recompiled my old application with new CVS 1.0.2 Michal> version of XForms. I did it on three different systems: Michal> Linux/x86 (RH 7.2) Linux/alpha (RH 7.2) Solaris/sparc (2.5.1) Michal> When invoked, it does its job just fine on all systems, but on Michal> one, namely Solaris, it outputs following strange message at Michal> start: Michal> In fl_initialize [flresource.c 972] Could not create an Michal> input context Input contexts (and input methods) are what is used to enter special characters like those obtained with the compose key of the keyboard (or with an additional patch which is not yet in xforms, chinese, japanses or korean). It would be interesting to know why the XCreateIC call fails. It may be actually that cghan patch to use CJK languages with xforms will fix your problem on solaris too. Do you have special locale-related environment variables set? JMarc From msz at astrouw.edu.pl Tue Feb 24 11:05:01 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue, 24 Feb 2004 17:05:01 +0100 Subject: [XForms] strange message from app using xforms-1.0.2 In-Reply-To: References: <20040224135623.GA22585@astrouw.edu.pl> Message-ID: <20040224160501.GA22773@astrouw.edu.pl> On Tue, Feb 24, 2004 at 04:00:07PM +0100, Jean-Marc Lasgouttes wrote: > Michal> When invoked, it does its job just fine on all systems, but on > Michal> one, namely Solaris, it outputs following strange message at > Michal> start: > > Michal> In fl_initialize [flresource.c 972] Could not create an > Michal> input context > > Input contexts (and input methods) are what is used to enter special > characters like those obtained with the compose key of the keyboard > (or with an additional patch which is not yet in xforms, chinese, > japanses or korean). > > It would be interesting to know why the XCreateIC call fails. It may > be actually that cghan patch to use CJK languages with xforms will fix > your problem on solaris too. > > Do you have special locale-related environment variables set? No. On the Solaris machine in question, the output of 'locale' command is following: LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= I guess the "locale/NLS" etc. issues on such an old version of Solaris are not addressed very deeply, so maybe this makes a problem? Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Tue Feb 24 11:36:12 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 24 Feb 2004 17:36:12 +0100 Subject: [XForms] strange message from app using xforms-1.0.2 In-Reply-To: <20040224160501.GA22773@astrouw.edu.pl> (Michal Szymanski's message of "Tue, 24 Feb 2004 17:05:01 +0100") References: <20040224135623.GA22585@astrouw.edu.pl> <20040224160501.GA22773@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: >> Do you have special locale-related environment variables set? Michal> No. On the Solaris machine in question, the output of 'locale' Michal> command is following: Michal> LANG= LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" Michal> LC_MONETARY="C" LC_MESSAGES="C" LC_ALL= Michal> I guess the "locale/NLS" etc. issues on such an old version of Michal> Solaris are not addressed very deeply, so maybe this makes a Michal> problem? I do remember that some users said that since xforms got input methods support, they could not use compose key anymore in LyX. This probably means that the code to set input methods in xforms is not correct. Unfortunately, I do not know much about this. JMarc From wd4nmq at comcast.net Tue Feb 24 13:18:23 2004 From: wd4nmq at comcast.net (Jeff Pierce) Date: Tue, 24 Feb 2004 13:18:23 -0500 Subject: [XForms] xform and shape extension Message-ID: <403B956F.4080508@comcast.net> Is there any plans for xforms to include the shape extension that allows for non-rectangular windows like xeyes? I've always used xforms for my X applications but I now feel it is falling way behind other X wrappers, ie gtk/glade. -- Jeff, wd4nmq wd4nmq at comcast.net http://mywebpages.comcast.net/wd4nmq From wd4nmq at comcast.net Wed Feb 25 18:26:21 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed, 25 Feb 2004 18:26:21 -0500 Subject: [XForms] Test message Message-ID: <403D2F1D.9060107@comcast.net> This isa test messge, I sent a post the other night and I never saw it reflected or got a reply about it Jeff From wd4nmq at comcast.net Wed Feb 25 18:35:44 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed, 25 Feb 2004 18:35:44 -0500 Subject: [XForms] Where is xforms? Message-ID: <403D3150.9000708@comcast.net> Have I got something set wrong or what? Going to the link http://savannah.nongnu.org/files/?group=xforms Which is what is listed on teh mailing list messages and where you end up going thru the home page lists only an entry for "Parent Dirctory", nothing else. Where is xforms 1.0? Jeff From wd4nmq at comcast.net Fri Feb 27 00:14:51 2004 From: wd4nmq at comcast.net (Jeff) Date: Fri, 27 Feb 2004 00:14:51 -0500 Subject: [XForms] Anybody alive out there? Message-ID: <403ED24B.8040008@comcast.net> Is xforms dead or breathing it's last gasps? I posted a couple of days ago stating that xforms 1.0 was no longer available by going to http://world.std.com/~xforms/ and following the links that lead you to http://savannah.nongnu.org/files/?group=xforms But, just a "Parent Directory" entry, no xforms. Jeff From msz at astrouw.edu.pl Fri Feb 27 10:32:42 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Fri, 27 Feb 2004 16:32:42 +0100 Subject: [XForms] Anybody alive out there? In-Reply-To: <403ED24B.8040008@comcast.net> References: <403ED24B.8040008@comcast.net> Message-ID: <20040227153242.GA2372@astrouw.edu.pl> On Fri, Feb 27, 2004 at 12:14:51AM -0500, Jeff wrote: > > Is xforms dead or breathing it's last gasps? I posted a couple of days > ago stating that xforms 1.0 was no longer available by going to > http://world.std.com/~xforms/ and following the links that lead you to > http://savannah.nongnu.org/files/?group=xforms > But, just a "Parent Directory" entry, no xforms. Well, the list is not *very* busy lately :) Savannah got compromised some time ago - my understanding was it has already recovered but maybe this is not true yet. Angus gave following links for alternate download. I think they are still valid but note: grap the file(s) directly, the directory is not world readable: Find the xforms 1.0 release (871kB) at http://www.devel.lyx.org/~leeming/xforms-1.0.tar.gz and CVS snapshot (989kB) at http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Fri Feb 27 11:32:25 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 27 Feb 2004 17:32:25 +0100 Subject: [XForms] Anybody alive out there? In-Reply-To: <20040227153242.GA2372@astrouw.edu.pl> (Michal Szymanski's message of "Fri, 27 Feb 2004 16:32:42 +0100") References: <403ED24B.8040008@comcast.net> <20040227153242.GA2372@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> To subscribers of the xforms list Michal> On Fri, Feb 27, 2004 at 12:14:51AM -0500, Jeff wrote: >> Is xforms dead or breathing it's last gasps? I posted a couple of >> days ago stating that xforms 1.0 was no longer available by going >> to http://world.std.com/~xforms/ and following the links that lead >> you to http://savannah.nongnu.org/files/?group=xforms But, just a >> "Parent Directory" entry, no xforms. Michal> Well, the list is not *very* busy lately :) Michal> Savannah got compromised some time ago - my understanding was Michal> it has already recovered but maybe this is not true yet. Yes, Angus has to re-upload the files, but it looks like he is busy. Hopefully we will be able to release xforms 1.1.0 in the coming weeks rather than months :) JMarc From wd4nmq at comcast.net Fri Feb 27 12:50:08 2004 From: wd4nmq at comcast.net (Jeff) Date: Fri, 27 Feb 2004 12:50:08 -0500 Subject: [XForms] Threads and events Message-ID: <403F8350.2060402@comcast.net> I hope what I am about to ask makes sense, but here goes. I wrote an app in xforms that had a thread. The thread accessed a server and then filled in a browser object. Now, due to problems with with GL, if I remember the reason, and this is the code I used. while(1){ timeout.tv_sec = 0; timeout.tv_usec = 1000; select(0, NULL, NULL, NULL, &timeout); pthread_mutex_lock(&browserLock); fl_check_forms(); pthread_mutex_unlock(&browserLock); } The thread then uses pthread_mutex_lock(&browserLock); // Update the browser pthread_mutex_unlock(&browserLock); To write to the browser. The server access was a thread so as not to lock out user input will the server was found, accessed and data gotten. Once the data was rceived, the thread wrote it to the browser object. I just got finished doing a Windows project that involved kinda the same thing. A gui thread and a worker thread. Now, in this I was able to use the Windows API call PostThreadMessage() for the gui to send send requests to the thread in response to user requests and the thread used PostMessage() to talk to the gui. In the case above the gui would use PostThreadMessage() to tell the thread to access the server. The thread would get the data from the server and place it in memory and use PostMessage() back to the gui, giving it the pointer, telling it to display the data in the browser. Now, since the thread never calls ANY object controls, only the gui thread does that, there would be no conflict between the two accessing the gui objects. Now for the question. Can the Windows API method of messaging be duplicated with events some how in the X/xforms environment? This would allow a total seperation of gui and worker thread and neither would have to wait on a mutex. Of course, in windows you have window handles and thread ids that are used to know where to post the messages to. Can you do the same thing in X to direct events? Needles to say, I don't know very much, if anything , about the way X handles events. One theory is to have an event callback function, and the other thread post the event to call it to that threads event handler. Is that a possiblity? Only the gui would use events. A worker thread could use what I do now to get input from the gui, a queue, queue access mutex, and a conditional wait on the mutex. This got kinda long winded and I apologize for that. But, I really would like to know if this can be done. Thank you just for reading this long post. Jeff wd4nmq at comcast.net From angus.leeming at btopenworld.com Mon Mar 1 14:29:10 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 1 Mar 2004 19:29:10 +0000 Subject: [XForms] Fwd: Software using xforms Message-ID: <200403011929.10035.angus.leeming@btopenworld.com> Hi, Laurence! I've forwarded your message to the xforms user list so that it can receive as wide a dissemination as possible. Regards, Angus ---------- Forwarded Message ---------- FYI: we released on Friday some software which uses forms (see http://www.numis.northwestern.edu/edm). It is a slightly older version, and at some stage in the future we will update it to a more recent version. ----------------------------------------------- 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.northwestern.edu http://www.numis.northwestern.edu Nanocrystallography Workshop, http://ncem.lbl.gov/workshop.htm ----------------------------------------------- -------------- next part -------------- An embedded message was scrubbed... From: "L. D. Marks" Subject: Software using xforms Date: Mon, 1 Mar 2004 07:05:58 -0600 (CST) Size: 1839 Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040301/782a3e12/attachment.mht -------------- next part -------------- An embedded message was scrubbed... From: xforms-cvs-request at nongnu.org Subject: confirm 9fa3a209c783216ddd0d35ee87d2e88f842f9a37 Date: no date Size: 630 Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040301/782a3e12/attachment-0001.mht From wd4nmq at comcast.net Mon Mar 1 18:24:16 2004 From: wd4nmq at comcast.net (Jeff) Date: Mon, 01 Mar 2004 18:24:16 -0500 Subject: [XForms] FL_EVENT and it's use Message-ID: <4043C620.70001@comcast.net> Several days ago I posted a message concerning client message events and if xforms could handle them. To which I got no reply. I was looking through the xforms manual looking for something else and in section 4.3, Dealing With Windows. I found it talking about the FL_EVENT. To qoute: "To help find out when and event has occured, whenever fl_do_form() and fl_check_foems() encounter an event that is not meant for them, but for the appliaction program they return a special object FL_EVENT. Upon receiving this special event, the application program can and must remove the pending event from the queue using fl_XNextEvent()." There is then a code snippet. Does this mean that this how you would handle an XClientMessageEvent? while(! ready){ obj = fl_do_form(); // does form as long as events are for form if(obj == FL_EVENT){ fl_XNextEvent(&xevent); if(xevent.type == XClientMessageEvent){ // This is from the thread // update server data browser object } } Is this the right path? Jeff wd4nmq at comcast.net http://mywebpages.comcast.net/wd4nmq From dmitry at karasik.eu.org Mon Mar 1 05:33:03 2004 From: dmitry at karasik.eu.org (Dmitry Karasik) Date: Mon, 01 Mar 2004 11:33:03 +0100 Subject: [XForms] XForms text rendering bug patch Message-ID: <4043115F.9080007@karasik.eu.org> Under certain condition, input lines do not display any text. The bug, which is basically comparison of a signed integer as a boolean, is fixed by the following patch: --- xtext.c Mon Mar 1 11:26:24 2004 +++ /usr/ports/x11-toolkits/xforms/work/xforms-1.0/lib/xtext.c Mon Mar 1 11:26 :29 2004 @@ -210,7 +210,7 @@ for (i = topline; i < endline; i++) { /* Check whether visible */ + if (clip > 0 && (starty[i] + flx->fdesc) > y + h) - if (clip && (starty[i] + flx->fdesc) > y + h) continue; ulpos = -1; From richard at canido.co.uk Tue Mar 2 07:52:52 2004 From: richard at canido.co.uk (Richard Hughes) Date: Tue, 2 Mar 2004 12:52:52 -0000 Subject: [XForms] Xforms 1.0 LGPL Message-ID: <000001c40055$5f15c960$c800a8c0@canido.co.uk> Hi, Where is Xforms 1.0 LGPL available for download since your Freshmeat page links to the old non GPL page where I am only able to find versions 0.88 and 0.99. Thanks for your help Richard Hughes From Jean-Marc.Lasgouttes at inria.fr Tue Mar 2 09:41:09 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 02 Mar 2004 15:41:09 +0100 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <4043115F.9080007@karasik.eu.org> (Dmitry Karasik's message of "Mon, 01 Mar 2004 11:33:03 +0100") References: <4043115F.9080007@karasik.eu.org> Message-ID: >>>>> "Dmitry" == Dmitry Karasik writes: Dmitry> To subscribers of the xforms list Under certain condition, Dmitry> input lines do not display any text. The bug, which is Dmitry> basically comparison of a signed integer as a boolean, is Dmitry> fixed by the following patch: Hello, Thanks for the patch. I think we are suffering from this bug in LyX in some circumstances, but we never got to fix it. Are you sure that your fix is the right one? I do not know this part of code at all, but the comment before the function says: /* Major text drawing routine * clip == 0: no clipping * clip == 1: do clipping here * clip == -1: clipping is done outside of this routine */ so testing for clip as a boolean means 'if there is some clipping going on somewhere', which may be a reasonable test. Are you sure that only the 'do clipping here' case should be handled? We want to be extra careful about the side-effects. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 2 09:44:47 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 02 Mar 2004 15:44:47 +0100 Subject: [XForms] FL_EVENT and it's use In-Reply-To: <4043C620.70001@comcast.net> (wd4nmq@comcast.net's message of "Mon, 01 Mar 2004 18:24:16 -0500") References: <4043C620.70001@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list Several days ago I posted a Jeff> message concerning client message events and if xforms could Jeff> handle them. To which I got no reply. Personnally I did not answer because I was scared by the 'thread' part :) Jeff> I was looking through the xforms manual looking for something Jeff> else and in section 4.3, Dealing With Windows. I found it Jeff> talking about the FL_EVENT. Jeff> To qoute: "To help find out when and event has occured, whenever Jeff> fl_do_form() and fl_check_foems() encounter an event that is not Jeff> meant for them, but for the appliaction program they return a Jeff> special object FL_EVENT. Upon receiving this special event, the Jeff> application program can and must remove the pending event from Jeff> the queue using fl_XNextEvent()." All I know is that in LyX we handle this just to drop the events. Jeff> There is then a code snippet. Does this mean that this how you Jeff> would handle an XClientMessageEvent? Yes, it looks reasonable. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 2 09:47:11 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 02 Mar 2004 15:47:11 +0100 Subject: [XForms] xform and shape extension In-Reply-To: <403B956F.4080508@comcast.net> (Jeff Pierce's message of "Tue, 24 Feb 2004 13:18:23 -0500") References: <403B956F.4080508@comcast.net> Message-ID: >>>>> "Jeff" == Jeff Pierce writes: Jeff> To subscribers of the xforms list Is there any plans for xforms Jeff> to include the shape extension that allows for non-rectangular Jeff> windows like xeyes? Jeff> I've always used xforms for my X applications but I now feel it Jeff> is falling way behind other X wrappers, ie gtk/glade. To reply to this older message: Jeff, I agree that xforms is falling behind in terms of appearance. I do not think we have enough developers to change that. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 2 09:50:35 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 02 Mar 2004 15:50:35 +0100 Subject: [XForms] Xforms 1.0 LGPL In-Reply-To: <000001c40055$5f15c960$c800a8c0@canido.co.uk> (Richard Hughes's message of "Tue, 2 Mar 2004 12:52:52 -0000") References: <000001c40055$5f15c960$c800a8c0@canido.co.uk> Message-ID: >>>>> "Richard" == Richard Hughes writes: Richard> To subscribers of the xforms list Hi, Richard> Where is Xforms 1.0 LGPL available for download since your Richard> Freshmeat page links to the old non GPL page where I am only Richard> able to find versions 0.88 and 0.99. Until we repair our pages at savannah, you can find it here: http://www.devel.lyx.org/~leeming/xforms-1.0.tar.gz JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 3 12:01:03 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 03 Mar 2004 18:01:03 +0100 Subject: [XForms] [Laurent Fournier] Re: XForms: [again] pup interaction bug? Message-ID: An embedded message was scrubbed... From: Laurent Fournier Subject: Re: XForms: [again] pup interaction bug? Date: Wed, 03 Mar 2004 17:05:28 +0100 Size: 76096 Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040303/e5e7cdd4/attachment.mht From Jean-Marc.Lasgouttes at inria.fr Thu Mar 4 12:03:34 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 04 Mar 2004 18:03:34 +0100 Subject: [XForms] [Laurent Fournier] Xforms : popup menus Message-ID: An embedded message was scrubbed... From: Laurent Fournier Subject: Xforms : popup menus Date: Thu, 04 Mar 2004 11:41:54 +0100 Size: 5001 Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040304/307640ca/attachment.mht From wd4nmq at comcast.net Thu Mar 4 18:20:31 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu, 04 Mar 2004 18:20:31 -0500 Subject: [XForms] Window id in a form Message-ID: <4047B9BF.9030009@comcast.net> Where is the window's id stored? Ya know, the return value of XCreateWindow(). If I have an app that has only the form called, say testEvent, it would be stored in fd_testEvent->testEvent->window, but I'm not sure. I am trying to be able to have threads send ClientMessage events to the main form. I have posted that idea before. I wrote an app that writes fd_testEvent->testEvent->window to a text widget so I now what it is and then do the following: while(1){ obj = fl_do_forms(); puts("We are out of fl_do_forms()"); if(obj == FL_EVENT){ fl_XNextEvent(&ev); if(ev.type = ClientMessage){ puts("We received a ClientMessage event"); } } } I have another app that I enter the displayed id and it uses XSendEvent() to send a ClientMessage event to it. I have tested this out with a short Xlib app to make sure my sending app works, and it does. But, when I use the xforms app as the recipient, it never comes out of the fl_do_forms(). Anybody got any ideas? Jeff wd4nmq at comcast.net From jkhn2 at cam.ac.uk Sat Mar 6 07:44:10 2004 From: jkhn2 at cam.ac.uk (James Ng) Date: Sat, 6 Mar 2004 12:44:10 -0000 Subject: [XForms] Can't build xforms Message-ID: <002301c40378$b8e5c000$20c16f83@jkhn2xp> Dear all, I just downloaded xforms 1.0 from the mirror site ftp://ftp.u-aizu.ac.jp/pub/x11/misc/xforms/stable.pkg/1.0/ and tried to build it without success. I am using Cygwin on Windows XP Pro. Following the instructions in the INSTALL file, I ran the commands: xmkmf -a make at which point I get the following error messages: making all in ./lib/include... make[1]: Entering directory `/cygdrive/c/xforms-1.0/lib/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/lib/include' making all in ./lib... make[1]: Entering directory `/cygdrive/c/xforms-1.0/lib' make[1]: *** No rule to make target `forms-def.cpp', needed by `forms.def'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/lib' making all in ./image... make[1]: Entering directory `/cygdrive/c/xforms-1.0/image' make[1]: *** No rule to make target `flimage-def.cpp', needed by `flimage.def'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/image' making all in ./gl... make[1]: Entering directory `/cygdrive/c/xforms-1.0/gl' make[1]: *** No rule to make target `formsGL-def.cpp', needed by `formsGL.def'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/gl' making all in ./fdesign... make[1]: Entering directory `/cygdrive/c/xforms-1.0/fdesign' make[1]: *** No rule to make target `../lib/libforms.a', needed by `fdesign.exe'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/fdesign' making all in ./fd2ps... make[1]: Entering directory `/cygdrive/c/xforms-1.0/fd2ps' make[1]: *** No rule to make target `../lib/libforms.a', needed by `fd2ps.exe'. Stop. make[1]: Leaving directory `/cygdrive/c/xforms-1.0/fd2ps' make: *** [all] Error 2 Any help would be much appreciated. Thanks. James From Lawrence.Lifshitz at umassmed.edu Thu Mar 11 12:54:36 2004 From: Lawrence.Lifshitz at umassmed.edu (Lawrence M./ Lifshitz) Date: Thu, 11 Mar 2004 12:54:36 -0500 Subject: [XForms] 64 bit Opteron compile of xforms 1.0? Message-ID: <4050A7DC.8030201@umassmed.edu> Hi, Has anyone compiled xforms on an Opteron with Suse's 64 Linux installed? If so, what do I need to do? If not, any obvious problems with attempting such a feat? Thanks. Larry -- Lawrence M. Lifshitz, Ph. D., Associate Professor Biomedical Imaging Group (http://invitro.umassmed.edu) University of Massachusetts Medical School (http://www.umassmed.edu) Phone: (508) 856-3392 email: Lawrence.Lifshitz at umassmed.edu Fax: (508) 856-1840 web: http://invitro.umassmed.edu/lml From wd4nmq at comcast.net Thu Mar 11 22:49:41 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu, 11 Mar 2004 22:49:41 -0500 Subject: [XForms] ClientMessage handling change? Message-ID: <40513355.1080004@comcast.net> As I have said in previous posts I want to be able to process ClientMessage Xevent messages. After several attempts I found that ClientMessages are handled. But, it is very limited in scope. It looks for a WM_PROTOCOLS and WM_DELETE_WINDOW atoms. If it is not that, it passes it to fl_handle_form with FL_OTHER and FL_OTHER causes it to be passed to other open forms. Now, I thought the whole purpose of ClientMessage was to pass messages to specific windows, ie forms. Now, would it nor make since to have a user registered routine to handle ClientMessage's that are not WM_PROTOCOLS and WM_DELETE_WINDOW atoms? So, a flow in handle_client_message() could go: Is message type == WM_PROTOCOL? Yes, then handle it and exit function. No, is there a registered ClientMessage Handler? Yes, pass it to user handler function and exit on return. No, pass as FL_OTHER to fl_handle_form as before. The user's handler code would use it's on message type atoms. I really think this would be a good thing for xforms. It seems that gtk and kde already support this. Plus, as I previuosly mentioned it would be much easier to have worker threads use the XSendEvent to a form's event handler to do a form gui update rather then have to use mutexes in an event loop. So what does anybody who still reads this list and thinks xforms may still survive think about this idea? Jeff wd4nmq at comcast.net From Jean-Marc.Lasgouttes at inria.fr Fri Mar 12 05:19:53 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 12 Mar 2004 11:19:53 +0100 Subject: [XForms] 64 bit Opteron compile of xforms 1.0? In-Reply-To: <4050A7DC.8030201@umassmed.edu> (Lawrence M.'s message of "Thu, 11 Mar 2004 12:54:36 -0500") References: <4050A7DC.8030201@umassmed.edu> Message-ID: >>>>> "Lawrence" == Lawrence M / Lifshitz writes: Lawrence> To subscribers of the xforms list Hi, Has anyone compiled Lawrence> xforms on an Opteron with Suse's 64 Linux installed? If so, Lawrence> what do I need to do? If not, any obvious problems with Lawrence> attempting such a feat? Thanks. You will probably have more success with the latest cvs snapshot found here: http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz This one uses autoconf and libtool, and is known to work one some 64bits architectures, like alpha. JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Mar 12 05:22:35 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 12 Mar 2004 11:22:35 +0100 Subject: [XForms] ClientMessage handling change? In-Reply-To: <40513355.1080004@comcast.net> (wd4nmq@comcast.net's message of "Thu, 11 Mar 2004 22:49:41 -0500") References: <40513355.1080004@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list As I have said in previous Jeff> posts I want to be able to process ClientMessage Xevent Jeff> messages. After several attempts I found that ClientMessages are Jeff> handled. But, it is very limited in scope. Jeff> It looks for a WM_PROTOCOLS and WM_DELETE_WINDOW atoms. If it is Jeff> not that, it passes it to fl_handle_form with FL_OTHER and Jeff> FL_OTHER causes it to be passed to other open forms. Jeff> Now, I thought the whole purpose of ClientMessage was to pass Jeff> messages to specific windows, ie forms. Now, would it nor make Jeff> since to have a user registered routine to handle Jeff> ClientMessage's that are not WM_PROTOCOLS and WM_DELETE_WINDOW Jeff> atoms? Yes, that would be a good idea, since it is backward compatible with the current behaviour. Jeff> So, a flow in handle_client_message() could go: Jeff> Is message type == WM_PROTOCOL? Yes, then handle it and exit Jeff> function. No, is there a registered ClientMessage Handler? Yes, Jeff> pass it to user handler function and exit on return. No, pass as Jeff> FL_OTHER to fl_handle_form as before. Or you could have a default handler that handles WM_PROTOCOL, and the user handler would be free to call this or completely override it. Jeff> I really think this would be a good thing for xforms. It seems Jeff> that gtk and kde already support this. Plus, as I previuosly Jeff> mentioned it would be much easier to have worker threads use the Jeff> XSendEvent to a form's event handler to do a form gui update Jeff> rather then have to use mutexes in an event loop. Could you try to write a sample implementation? JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Mar 12 05:24:23 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 12 Mar 2004 11:24:23 +0100 Subject: [XForms] Can't build xforms In-Reply-To: <002301c40378$b8e5c000$20c16f83@jkhn2xp> (James Ng's message of "Sat, 6 Mar 2004 12:44:10 -0000") References: <002301c40378$b8e5c000$20c16f83@jkhn2xp> Message-ID: >>>>> "James" == James Ng writes: James> To subscribers of the xforms list Dear all, James> I just downloaded xforms 1.0 from the mirror site James> ftp://ftp.u-aizu.ac.jp/pub/x11/misc/xforms/stable.pkg/1.0/ and James> tried to build it without success. I am using Cygwin on Windows James> XP Pro. I do not have experience myself on building xforms on cygwin. Moreover, the situation is probably different with the latest autoconf based version. Could you try out http://www.devel.lyx.org/~leeming/xforms-1.0.2.tar.gz ? JMarc From wd4nmq at comcast.net Fri Mar 12 09:50:01 2004 From: wd4nmq at comcast.net (Jeff) Date: Fri, 12 Mar 2004 09:50:01 -0500 Subject: [XForms] Maintainers? Message-ID: <4051CE19.1080606@comcast.net> Who are the "offical" maintainers of xforms? I remember that Steve Lamont had to give it up, but who actualy took over? Jeff wd4nmq at comcast.net From Jean-Marc.Lasgouttes at inria.fr Fri Mar 12 10:22:52 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 12 Mar 2004 16:22:52 +0100 Subject: [XForms] Maintainers? In-Reply-To: <4051CE19.1080606@comcast.net> (wd4nmq@comcast.net's message of "Fri, 12 Mar 2004 09:50:01 -0500") References: <4051CE19.1080606@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list Who are the "offical" Jeff> maintainers of xforms? I remember that Steve Lamont had to give Jeff> it up, but who actualy took over? The official maintainer is Angus Leeming, who seems to have less time recently to finish up what he has done (mainly to convertion to autoconf, but also many fixes). I do have cvs access too, but my knowledge of the internals of xforms (like this message passing stuff) is a bit mysterious to me. The goal before savannah got compromised was to cleanup what we have now and release it as 1.1. The we can have a look at new features to add. The intention is not to turn xforms into something than can rival with kde or gtk, but rather to maintain it in a usable form and fix bugs. Of course, to Angus and myself, usable means 'usable for LyX', since we are both LyX maintainers. There seem to be several people using xforms with GL, for example, and I know nothing about that. Anybody who is willing to give a hand is welcome, as far as I am concerned. JMarc From angus.leeming at btopenworld.com Sun Mar 14 12:15:20 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sun, 14 Mar 2004 17:15:20 +0000 Subject: [XForms] Maintainers? In-Reply-To: References: <4051CE19.1080606@comcast.net> Message-ID: <200403141715.20395.angus.leeming@btopenworld.com> On Friday 12 March 2004 3:22 pm, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Jeff" == Jeff writes: > > Jeff> To subscribers of the xforms list Who are the "offical" > Jeff> maintainers of xforms? I remember that Steve Lamont had to > give Jeff> it up, but who actualy took over? > > The official maintainer is Angus Leeming, who seems to have less > time recently to finish up what he has done (mainly to convertion > to autoconf, but also many fixes). I do have cvs access too, but my > knowledge of the internals of xforms (like this message passing > stuff) is a bit mysterious to me. > > The goal before savannah got compromised was to cleanup what we > have now and release it as 1.1. The we can have a look at new > features to add. The intention is not to turn xforms into something > than can rival with kde or gtk, but rather to maintain it in a > usable form and fix bugs. Of course, to Angus and myself, usable > means 'usable for LyX', since we are both LyX maintainers. Jean-Marc, all, I *have* been very busy recently. Apologies for neglecting this list. I would like to upload the xforms-1.0 source code to the home page once more but need to have/use pgp to do so. As this will require me to find the time to read up on pgp and how to use it, this may take some time :-( So, Jean-Marc, if you have pgp set up on your machines, the archive is at www.devel.lyx.org/~leeming/stable.pkg/1.0/README-1.0 www.devel.lyx.org/~leeming/stable.pkg/1.0/xforms-1.0.tar.gz Angus From wd4nmq at comcast.net Mon Mar 15 00:50:45 2004 From: wd4nmq at comcast.net (Jeff) Date: Mon, 15 Mar 2004 00:50:45 -0500 Subject: [XForms] Client Message handler success. Message-ID: <40554435.8070409@comcast.net> Angus and Jean-marc, (Lets try this using my registered email account :-), Sorry) I have the code working to allow for a user supplied callback to handle ClientMessage XEvents. It was actually very little code to change. Just tracing the code to find where to put it was a royal pain . I quick synopsis. XClient messages are used as an XEvent message that has user defined data. Refer to XLib documents for the CLient message data structure. Now, the present xforms seems to use client messages for forms to destroy other forms and use the WM_PROTOCOLS and WM_DELETE_WINDOW X atoms to specify that action. And of course, you can use user defined atoms. If the message_type is not these, the client message is passed to any other forms in the forms list. Now, I do not understand why if the client message is not WM_PROTOCOLS, etc, it is passed on. The whole purpose of XSendEvent with ClientMessage is to send it to a SPECIFIC window, or form in xforms terminology. So here is what I did. I added a member to the FL_FORMS structure to hold a function pointer. So only two lines were added to forms.h line 649: typedef void (*FL_CLIENT_CALLBACK)(void *); line 703: FL_CLIENT_CALLBACK client_callback; in objects.c added at line 105 form->client_callback = 0; And in forms.c removed line 1657 fl_handle_form(form, FL_OTHER, 0, xev); and replaced it with: if(form->client_callback){ if(!form->client_callback(xev)) fl_handle_form(form, FL_OTHER, 0, xev); } else fl_handle_form(form, FL_OTHER, 0, xev); What this does is test to see if a client callback has been set, if not, it goes through fl_handle_form just like before. Also the client callback returns a TRUE if it did consume the event and a FLASE if it did not. If a FALSE is returned, fl_handle_form() is called as in original code. So, in the users code you need only assign a function pointer to (your form name)->client_callback to get ClientMessage's sent to you code. A quick snippet: // user's ClientMessage handler: int clientCallback(XEvent *xev){ // test message type for atom defining data structure // and handle it. return 1; } // This code is in initialization before do_forms(); fd_testEvent->testEvent->client_callback = clientCallback; One thing I did notice as I traced through the code starting at fl_handle_form with FL_OTHER as the event was I could not find any other code in that chain that tested for FL_OTHER event. I think that it is a dead event starting at fl_handle_form. But, just to make sure I left the chain in if the client message is not consumed by user code. This is just a prelimenary annoucement. I am doing more testing and once I believe it is stable and introduces no bugs, I will do difff and pass the patch to you. I hope to make it into the next release, which I also hope is coming soon, as I want to use this on an amatuer radio application I wrote. And, if I use it others need to be able to get the same xforms version from savannah. Any idea on when the next release will happen? As I have stated before, this will allow worker threads to be able to send ClientMessage XEvents to the gui thread containing user defined atoms to display data, set indicators, etc WITHOUT having to create/lock/unlock mutexes in a big while loop. Since the message is on the xforms gui event queue, it is handles just like a mouse click or key pressed event. Creatly simplifing code. Please feel free to ask questions or make comments. Jeff wd4nmq at comcast.net From Jean-Marc.Lasgouttes at inria.fr Tue Mar 16 10:33:15 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 16 Mar 2004 16:33:15 +0100 Subject: [XForms] Maintainers? In-Reply-To: <200403141715.20395.angus.leeming@btopenworld.com> (Angus Leeming's message of "Sun, 14 Mar 2004 17:15:20 +0000") References: <4051CE19.1080606@comcast.net> <200403141715.20395.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> I *have* been very busy recently. Apologies for neglecting this Angus> list. Angus> I would like to upload the xforms-1.0 source code to the home Angus> page once more but need to have/use pgp to do so. As this will Angus> require me to find the time to read up on pgp and how to use Angus> it, this may take some time :-( Angus> So, Jean-Marc, if you have pgp set up on your machines, the Angus> archive is at Angus> www.devel.lyx.org/~leeming/stable.pkg/1.0/README-1.0 Angus> www.devel.lyx.org/~leeming/stable.pkg/1.0/xforms-1.0.tar.gz I have gpg, and just uploaded a public key and uploaded the files to savannah. I really do not understand anything about gpg, so I'll just see what happens... Do I have to be admin to be allowed to upload files? I guess time will tell. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 16 10:48:31 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 16 Mar 2004 16:48:31 +0100 Subject: [XForms] Client Message handler success. In-Reply-To: <40554435.8070409@comcast.net> (wd4nmq@comcast.net's message of "Mon, 15 Mar 2004 00:50:45 -0500") References: <40554435.8070409@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list Angus and Jean-marc, Jeff> (Lets try this using my registered email account :-), Sorry) Jeff> I have the code working to allow for a user supplied callback to Jeff> handle ClientMessage XEvents. Jeff> It was actually very little code to change. Just tracing the Jeff> code to find where to put it was a royal pain . Jeff> I quick synopsis. The general idea looks fine. Let's see the details :) Jeff> line 649: typedef void (*FL_CLIENT_CALLBACK)(void *); Why not like the others typedef void (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); Is should be possible, like with the atclose callback to set either a global client callback or a forms one. Or maybe what I am saying does not make sense? Also, if you add this new callback to forms_ struct, you break binary comaptibility, right? Can we avoid that somehow? Jeff> What this does is test to see if a client callback has been set, Jeff> if not, it goes through fl_handle_form just like before. Also Jeff> the client callback returns a TRUE if it did consume the event Jeff> and a FLASE if it did not. If a FALSE is returned, Jeff> fl_handle_form() is called as in original code. This is OK. Jeff> So, in the users code you need only assign a function pointer to Jeff> (your form name)->client_callback to get ClientMessage's sent to Jeff> you code. fd_testEvent-> testEvent->client_callback = clientCallback; I'd rather see something like fl_set_client_callback(fd_testEvent->testEvent, clientCallback); if only to do something similar to the other callbacks. Jeff> This is just a prelimenary annoucement. I am doing more testing Jeff> and once I believe it is stable and introduces no bugs, I will Jeff> do difff and pass the patch to you. I hope to make it into the Jeff> next release, which I also hope is coming soon, as I want to use Jeff> this on an amatuer radio application I wrote. And, if I use it Jeff> others need to be able to get the same xforms version from Jeff> savannah. This is definitely something that could go in next version, excpet that I am a bit worried about binary compatibility. Jeff> Any idea on when the next release will happen? I do not know yet :( JMarc From wd4nmq at comcast.net Tue Mar 16 11:40:06 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue, 16 Mar 2004 11:40:06 -0500 Subject: [XForms] Client Message handler success. In-Reply-To: References: <40554435.8070409@comcast.net> Message-ID: <40572DE6.6080604@comcast.net> Jean-Marc, Can you explain what you you mean by "breaking binary compatiblity"? >Why not like the others >typedef void (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); >Is should be possible, like with the atclose callback to set either a >global client callback or a forms one. Or maybe what I am saying does >not make sense? >I'd rather see something like >fl_set_client_callback(fd_testEvent->testEvent, clientCallback); >if only to do something similar to the other callbacks. Yea, I thought about that later, Heh, it was 1 am when I was doing this :-). Jean-Marc Lasgouttes wrote: >>>>>>"Jeff" == Jeff writes: >>>>>> >>>>>> > >Jeff> To subscribers of the xforms list Angus and Jean-marc, > >Jeff> (Lets try this using my registered email account :-), Sorry) > >Jeff> I have the code working to allow for a user supplied callback to >Jeff> handle ClientMessage XEvents. > >Jeff> It was actually very little code to change. Just tracing the >Jeff> code to find where to put it was a royal pain . > >Jeff> I quick synopsis. > >The general idea looks fine. Let's see the details :) > >Jeff> line 649: typedef void (*FL_CLIENT_CALLBACK)(void *); > >Why not like the others >typedef void (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); > >Is should be possible, like with the atclose callback to set either a >global client callback or a forms one. Or maybe what I am saying does >not make sense? > >Also, if you add this new callback to forms_ struct, you break binary >comaptibility, right? Can we avoid that somehow >Jeff> What this does is test to see if a client callback has been set, >Jeff> if not, it goes through fl_handle_form just like before. Also >Jeff> the client callback returns a TRUE if it did consume the event >Jeff> and a FLASE if it did not. If a FALSE is returned, >Jeff> fl_handle_form() is called as in original code. > >This is OK. > >Jeff> So, in the users code you need only assign a function pointer to >Jeff> (your form name)->client_callback to get ClientMessage's sent to >Jeff> you code. > >fd_testEvent-> testEvent->client_callback = clientCallback; > >I'd rather see something like >fl_set_client_callback(fd_testEvent->testEvent, clientCallback); >if only to do something similar to the other callbacks. > >Jeff> This is just a prelimenary annoucement. I am doing more testing >Jeff> and once I believe it is stable and introduces no bugs, I will >Jeff> do difff and pass the patch to you. I hope to make it into the >Jeff> next release, which I also hope is coming soon, as I want to use >Jeff> this on an amatuer radio application I wrote. And, if I use it >Jeff> others need to be able to get the same xforms version from >Jeff> savannah. > >This is definitely something that could go in next version, excpet >that I am a bit worried about binary compatibility. > >Jeff> Any idea on when the next release will happen? > >I do not know yet :( > >JMarc > > > > From wd4nmq at comcast.net Tue Mar 16 22:52:43 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue, 16 Mar 2004 22:52:43 -0500 Subject: [XForms] Redone client callback Message-ID: <4057CB8B.9000207@comcast.net> I changed code on my client callbacK to match the other callback calls. In forms.h: typedef int (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); and: FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( FL_FORM *form, FL_CLIENT_CALLBACK rcb ); I added the new call in forms.c: FL_CLIENT_CALLBACK fl_register_client_callback(FL_FORM *form,FL_CLIENT_CALLBACK clientCallback){ FL_CLIENT_CALLBACK old_rcb; old_rcb =form->client_callback; form->client_callback = clientCallback; return old_rcb; } Jeff wd4nmq at comcast.net From tc_zhao at yahoo.com Thu Mar 18 01:57:45 2004 From: tc_zhao at yahoo.com (T.C. Zhao) Date: Wed, 17 Mar 2004 22:57:45 -0800 (PST) Subject: [XForms] Redone client callback In-Reply-To: <4057CB8B.9000207@comcast.net> Message-ID: <20040318065745.3868.qmail@web13423.mail.yahoo.com> Thanks, Jeff. I think it's a good addition. --- Jeff wrote: > To subscribers of the xforms list > > > I changed code on my client callbacK to match the other callback calls. > In forms.h: > typedef int (*FL_CLIENT_CALLBACK)(struct forms_ *, void *); > > and: > > FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( > FL_FORM *form, > FL_CLIENT_CALLBACK rcb > ); > > I added the new call in forms.c: > FL_CLIENT_CALLBACK > fl_register_client_callback(FL_FORM *form,FL_CLIENT_CALLBACK > clientCallback){ > FL_CLIENT_CALLBACK old_rcb; > > old_rcb =form->client_callback; > form->client_callback = clientCallback; > return old_rcb; > } > > Jeff > wd4nmq at comcast.net > > > _______________________________________________ > 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! Mail - More reliable, more storage, less spam http://mail.yahoo.com From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 05:11:56 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 30 Mar 2004 12:11:56 +0200 Subject: [XForms] [PATCH] Trying to go ahead Message-ID: A non-text attachment was scrubbed... Name: prepare-1.0.90.diff Type: text/x-patch Size: 6901 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040330/f1b933aa/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 05:17:54 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 30 Mar 2004 12:17:54 +0200 Subject: [XForms] Redone client callback In-Reply-To: <20040318065745.3868.qmail@web13423.mail.yahoo.com> (T. C. Zhao's message of "Wed, 17 Mar 2004 22:57:45 -0800 (PST)") References: <20040318065745.3868.qmail@web13423.mail.yahoo.com> Message-ID: >>>>> "T" == T C Zhao writes: T> Thanks, Jeff. I think it's a good addition. Thanks for chiming in, TC. BTW, if I may be a bit insistent, is there a chance that we get the docs in source form? Finally, if we finally get to construct a new web site, would you agree to let us 'steal' some parts of the old one? JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 05:28:17 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 30 Mar 2004 12:28:17 +0200 Subject: [XForms] Client Message handler success. In-Reply-To: <40572DE6.6080604@comcast.net> (wd4nmq@comcast.net's message of "Tue, 16 Mar 2004 11:40:06 -0500") References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> Jean-Marc, Can you explain what you you mean by "breaking binary Jeff> compatiblity"? You add your new pointer in line 703, that is /* WM_DELETE_WINDOW message handler */ FL_FORM_ATCLOSE close_callback; void *close_data; /*========= HERE=============*/ void *flpixmap; /* back buffer */ This is in the FL_FORM struct. This means that any program built against version 1.0 of xforms, when it tries to access the flpixmap member of a form, will actually access your pointer, and a crash will occur in the best case. This means that a program built against xforms 1.0 will not work if xforms is upgraded. This is definitely bad, and we do such things only if it is unavoidable. Note however that FL_FORM ends with: void *attach_data; int no_tooltip; int reserved[10]; /* future use */ } FL_FORM; This 'reserved' array can be used to add new entries to FL_FORM. I would do something like line 649: typedef void (*FL_CLIENT_CALLBACK)(void *); line 703: FL_CLIENT_CALLBACK client_callback; void *attach_data; int no_tooltip; FL_CLIENT_CALLBACK client_callback; int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ } FL_FORM; I use an explicit sizeof here because I do not know what the size of a pointer is (on a 64 bits architecture, it will be 8). A question though is whether you need to support having a different callback for each form. If we decide that it is only possible to register _one_ callback for the whole app (note that the forms pointer can be passed to the callback, so it is possible to work from that), then the compatibility problem goes away. I hope those explanations were useful. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 05:49:20 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 30 Mar 2004 12:49:20 +0200 Subject: [XForms] Xforms 0.89 documentation available in postscript form Message-ID: I uploaded to the files section the xforms documentation that was previously available through the xforms ftp site. It is all we have for now, so it has not been updated for 1.0. I did not upload the xforms 0.88 documentation, but I can do it if there is a need for it. [I uploaded a README file along with it, but for some reason it just disappeared...] JMarc From xyzzy at speakeasy.org Tue Mar 30 06:18:59 2004 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue, 30 Mar 2004 03:18:59 -0800 (PST) Subject: [XForms] Client Message handler success. In-Reply-To: Message-ID: On Tue, 30 Mar 2004, Jean-Marc Lasgouttes wrote: > int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ That should be: int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 06:58:02 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 30 Mar 2004 13:58:02 +0200 Subject: [XForms] Client Message handler success. In-Reply-To: (Trent Piepho's message of "Tue, 30 Mar 2004 03:18:59 -0800 (PST)") References: Message-ID: >>>>> "Trent" == Trent Piepho writes: Trent> To subscribers of the xforms list Trent> On Tue, 30 Mar 2004, Jean-Marc Lasgouttes wrote: >> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ Trent> That should be: Trent> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; Opps! You are right... Actually, I read char instead of int. JMarc From angus.leeming at btopenworld.com Tue Mar 30 13:03:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 30 Mar 2004 13:03:33 -0500 Subject: [XForms] Re: [PATCH] Trying to go ahead In-Reply-To: References: Message-ID: <200403301303.33137.angus.leeming@btopenworld.com> On Tuesday 30 March 2004 5:11 am, Jean-Marc Lasgouttes wrote: > Hello, > > Let's try to go ahead... The attached patch finally fixes the > signal code (in a trivial way) and updates a bit the version > scheme. Angus, I'd appreciate that you take a look at it before I > commit. I have looked. Looks good. > What I would like to do now is to release xforms 1.0.90, which will > be a prerelease of xforms 1.1. The idea of the new numbering scheme > is that all releases with FL_FIXLEVEL >= 50 are development > releases. Makes sense. > Angus, does releasing 1.0.90 look like a good idea to you? I can do > it if you want. Yes please. The good news is that I'm going to make a serious attempt to sort out gnupg. > In other news, I have finally uploaded xforms-1.0 to the savannah > web site again (at last!). I will also upload the docs (only 0.89, > unfortunately...). Thanks for all this. Angus From msz at astrouw.edu.pl Tue Mar 30 07:11:13 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Tue, 30 Mar 2004 14:11:13 +0200 Subject: [XForms] Xforms 0.89 documentation available in postscript form In-Reply-To: References: Message-ID: <20040330121113.GA25064@astrouw.edu.pl> On Tue, Mar 30, 2004 at 12:49:20PM +0200, Jean-Marc Lasgouttes wrote: > I uploaded to the files section the xforms documentation that was > previously available through the xforms ftp site. It is all we have > for now, so it has not been updated for 1.0. Hi, Is there any real chance to get documentation sources from the original authors? Looks strange to have a GPLed software w/o up-to-date docs. If not, maybe at least some short description of changes introduced since 0.89? regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 07:28:17 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 30 Mar 2004 14:28:17 +0200 Subject: [XForms] Xforms 0.89 documentation available in postscript form In-Reply-To: <20040330121113.GA25064@astrouw.edu.pl> (Michal Szymanski's message of "Tue, 30 Mar 2004 14:11:13 +0200") References: <20040330121113.GA25064@astrouw.edu.pl> Message-ID: >>>>> "Michal" == Michal Szymanski writes: Michal> Is there any real chance to get documentation sources from the Michal> original authors? Looks strange to have a GPLed software w/o Michal> up-to-date docs. TC Zhao has promised to send us the sources as soon as he has time to fetch it. Obviously he did not have time yet. Michal> If not, maybe at least some short description of changes Michal> introduced since 0.89? What we have is the NEWS file. If I remove all bug fixes, here is what remains as user-visible changes. As you see, it is really not much. There has also been lots of small bug fixes. JMarc ------------------------------------------ V1.1cvs o Migrate from Imake to the GNU autotools. o fl_init_RGBdatabase is no longer needed, does nothing and is retained for compatibility only. o Pass KeyRelease events to the widgets. o Enable fdesign to work correctly with paths like ../foo/bar/your_file.fd. o Add a -dir option to fdesign to place generated files in destdir. ------------------------------------------ V1.0RC1 May 30, 2002 o. Very minor API changes. `FL_ERROR_FUNC' has been typedef'd for fl_set_error_handler() function. `FL_VAL_FILTER' has also been typedef'd for use by fl_set_{counter,slider}_filter(). Neither of these changes should affect much of anything. o. The flimage functions are in their own library now: libflimage. They should be usable standalone, but I have not had an opportunity to test them. o. The OpenGL functions are in their own library now: libformsGL fl_add_glcanvas() and its ilk live there. Application build scripts/ Makefiles should include -lformsGL. o. The Xpm library is no longer built or distributed with XForms. o. The majority of the function prototypes in `forms.h' have been expanded to include variable names. From angus.leeming at btopenworld.com Tue Mar 30 13:36:25 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 30 Mar 2004 13:36:25 -0500 Subject: [XForms] Xforms 0.89 documentation available in postscript form In-Reply-To: References: <20040330121113.GA25064@astrouw.edu.pl> Message-ID: <200403301336.25121.angus.leeming@btopenworld.com> On Tuesday 30 March 2004 7:28 am, Jean-Marc Lasgouttes wrote: > What we have is the NEWS file. If I remove all bug fixes, here is > what remains as user-visible changes. As you see, it is really not > much. There has also been lots of small bug fixes. + the snprintf functions are now 'hidden' away, are no longer compiled into their own library, are not compiled at all if your system has 'em and are not accessible as fl_snprintf etc. Angus From lasgouttes at lyx.org Tue Mar 30 09:38:29 2004 From: lasgouttes at lyx.org (Jean-Marc Lasgouttes) Date: Tue, 30 Mar 2004 16:38:29 +0200 Subject: [XForms] [ANNOUNCE] XForms 1.0.90 Message-ID: Dear XForms users, I am glad to announce the release of XForms 1.0.90, which marks a first step on the road to XForms 1.1.0. This development release has the primary goal of making sure that the new autoconf-based setup used for XForms works correctly on as many architectures as possible. There are still a few bugs to fix before 1.1.0, and I am sure that a couple new feature will creep in too. Here is the relevant excerpt from the ANNOUNCE file: V1.0.90 March 30, 2004 o Migrate from Imake to the GNU autotools. o "Composite" widgets, such as the browser, can now display tooltips. o Prevent a crash when rotating grayscale images by 90 degree multiples. o Enable xforms to handle XPixmaps containing colour "opaque". o Tabfolder widgets are now resizable. o Re-add fl_lookup_RGBcolor which fell off the dist at 1.0pre3. o fl_init_RGBdatabase is no longer needed, does nothing and is retained for compatibility only. o Pass KeyRelease events to the widgets. o Display the tab forms correctly when using bottom tab folders. o Enable xforms to read a wider variety of gif and jpeg images. o Enable fdesign to work correctly with paths like ../foo/bar/your_file.fd. o Add a -dir option to fdesign to place generated files in destdir. o Add an RPM spec file. o Get rid of the separate snprintf compatibility library. o Removal of lots of little pieces of cruft that crept into the xforms 1.0 release. You can grab xforms from the download section of the XForms project page: http://savannah.nongnu.org/download/xforms/ Please send bug reports to this list (xforms at bob.usuhs.mil). JMarc From hjohnson at mail.psychiatry.uiowa.edu Tue Mar 30 10:06:12 2004 From: hjohnson at mail.psychiatry.uiowa.edu (Hans J. Johnson) Date: Tue, 30 Mar 2004 09:06:12 -0600 Subject: [XForms] More robust XPM checking patch Message-ID: <1080659171.8009.14.camel@ipl-imac.psychiatry.uiowa.edu> Hello Xforms Maintainers, I've applied the patch below for quite some time now to various versions of xforms. It has been submitted to the list before, but may have been overlooked, or silently discredited. This patch allows me to compile xforms on both SGI-IRIX, and various versions of Linux. (the XPM_34g_or_later flag is not set properly on SGI-IRIX). Please consider including it in future releases. Regards, Hans J. Johnson hans-johnson at uiowa.edu -------------- next part -------------- --- pixmap.c.old Mon Apr 1 16:06:48 2002 +++ pixmap.c Mon Apr 1 15:52:26 2002 @@ -84,19 +84,21 @@ if (!xpma || !xpma->colormap) return; - if (XPM_34g_or_later) + +#if (XpmFormat >=3) && (XpmVersion >= 4) && ( XpmRevision >= 7) { M_warn("XpmCleanUP", "Using 3.4g features"); XFreeColors(flx->display, xpma->colormap, xpma->alloc_pixels, xpma->nalloc_pixels, 0); } - else +#else { /* somewhat dangerous */ M_warn("XpmCleanUP", "Using old xpm libs"); XFreeColors(flx->display, xpma->colormap, xpma->pixels, xpma->npixels, 0); } +#endif xpma->colormap = 0; From Jean-Marc.Lasgouttes at inria.fr Tue Mar 30 10:29:32 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 30 Mar 2004 17:29:32 +0200 Subject: [XForms] More robust XPM checking patch In-Reply-To: <1080659171.8009.14.camel@ipl-imac.psychiatry.uiowa.edu> (Hans J. Johnson's message of "Tue, 30 Mar 2004 09:06:12 -0600") References: <1080659171.8009.14.camel@ipl-imac.psychiatry.uiowa.edu> Message-ID: >>>>> "Hans" == Hans J Johnson writes: Hans> I've applied the patch below for quite some time now to various Hans> versions of xforms. It has been submitted to the list before, Hans> but may have been overlooked, or silently discredited. Hello, I do not remember seeing this patch... Hans> This patch allows me to compile xforms on both SGI-IRIX, and Hans> various versions of Linux. (the XPM_34g_or_later flag is not set Hans> properly on SGI-IRIX). Do you know why the test fails on SGI-IRIX? The only reason I can see is that the version in the xpm.h file (used in the #if) does not match the one in the library (used in the original version). This would be of course a bad configuration on your machine (and this does happens on some badly configured systems where I work). So if I were you, I'd check whether the library and headers match... Anyway, the patch looks reasonable, so I think I'll apply it. Thanks. JMarc From wd4nmq at comcast.net Tue Mar 30 12:07:35 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue, 30 Mar 2004 12:07:35 -0500 Subject: [XForms] Client Message handler success. In-Reply-To: References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> Message-ID: <4069A957.5050201@comcast.net> Jean-Marc, Ok, I see what you are saying. I thought you may have meant MS-Windows compatabilty somehow and just wanted it clarified. I agree moving it to the end and taking part of the reserve would be the best place and I did not think of "backwards binary" compatibility. I will make those changes today. On the question of each form having a client message callback I believe that would be the correct way to go. As I understand it, each form is a seperate X window. So, since XSendEvent() targets an X window, it would make sense for each form/window to have it's own client message callback. This would also save the application programmer from having to decide which form the message is for. Plus, it would be on the developer to come up with a data structure member to represent the targeted form as XSendEvent()/XNextEvent() only contain values of the targeted display and window/form. Jean-Marc Lasgouttes wrote: >>>>>>"Jeff" == Jeff writes: >>>>>> >>>>>> > >Jeff> Jean-Marc, Can you explain what you you mean by "breaking binary >Jeff> compatiblity"? > >You add your new pointer in line 703, that is > > /* WM_DELETE_WINDOW message handler */ > FL_FORM_ATCLOSE close_callback; > void *close_data; >/*========= HERE=============*/ > void *flpixmap; /* back buffer */ > >This is in the FL_FORM struct. This means that any program built >against version 1.0 of xforms, when it tries to access the flpixmap >member of a form, will actually access your pointer, and a crash will >occur in the best case. > >This means that a program built against xforms 1.0 will not work if >xforms is upgraded. This is definitely bad, and we do such things only >if it is unavoidable. > >Note however that FL_FORM ends with: > > void *attach_data; > int no_tooltip; > int reserved[10]; /* future use */ >} >FL_FORM; > >This 'reserved' array can be used to add new entries to FL_FORM. I >would do something like > >line 649: >typedef void (*FL_CLIENT_CALLBACK)(void *); > >line 703: >FL_CLIENT_CALLBACK client_callback; > > void *attach_data; > int no_tooltip; > > FL_CLIENT_CALLBACK client_callback; > > int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ >} >FL_FORM; > >I use an explicit sizeof here because I do not know what the size of a >pointer is (on a 64 bits architecture, it will be 8). > >A question though is whether you need to support having a different >callback for each form. If we decide that it is only possible to >register _one_ callback for the whole app (note that the forms pointer >can be passed to the callback, so it is possible to work from that), >then the compatibility problem goes away. > >I hope those explanations were useful. > >JMarc > > > From wd4nmq at comcast.net Tue Mar 30 12:10:40 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue, 30 Mar 2004 12:10:40 -0500 Subject: [XForms] Client Message handler success. In-Reply-To: References: Message-ID: <4069AA10.20604@comcast.net> I will be using Trent's suggestion: int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; OK? Anybody see any probelms? unsigned char Jean-Marc Lasgouttes wrote: >To subscribers of the xforms list > > > > >>>>>>"Trent" == Trent Piepho writes: >>>>>> >>>>>> > >Trent> To subscribers of the xforms list >Trent> On Tue, 30 Mar 2004, Jean-Marc Lasgouttes wrote: > > >>>int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use */ >>> >>> > >Trent> That should be: > >Trent> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; > >Opps! You are right... Actually, I read char instead of int. > >JMarc >_______________________________________________ >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 wd4nmq at comcast.net Tue Mar 30 12:16:36 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue, 30 Mar 2004 12:16:36 -0500 Subject: [XForms] [ANNOUNCE] XForms 1.0.90 In-Reply-To: References: Message-ID: <4069AB74.3050100@comcast.net> Jean-Marc, If it is ok with you, I will apply my changes to this new release and will make diffs againest it. I hope to have the diffs either tonight or tomorrow. Jean-Marc Lasgouttes wrote: >To subscribers of the xforms list > > > >Dear XForms users, > >I am glad to announce the release of XForms 1.0.90, which marks a >first step on the road to XForms 1.1.0. This development release has >the primary goal of making sure that the new autoconf-based setup used >for XForms works correctly on as many architectures as possible. > >There are still a few bugs to fix before 1.1.0, and I am sure that a >couple new feature will creep in too. > >Here is the relevant excerpt from the ANNOUNCE file: > >V1.0.90 March 30, 2004 > o Migrate from Imake to the GNU autotools. > o "Composite" widgets, such as the browser, can now display tooltips. > o Prevent a crash when rotating grayscale images by 90 degree multiples. > o Enable xforms to handle XPixmaps containing colour "opaque". > o Tabfolder widgets are now resizable. > o Re-add fl_lookup_RGBcolor which fell off the dist at 1.0pre3. > o fl_init_RGBdatabase is no longer needed, does nothing and is > retained for compatibility only. > o Pass KeyRelease events to the widgets. > o Display the tab forms correctly when using bottom tab folders. > o Enable xforms to read a wider variety of gif and jpeg images. > o Enable fdesign to work correctly with paths like ../foo/bar/your_file.fd. > o Add a -dir option to fdesign to place generated files in destdir. > o Add an RPM spec file. > o Get rid of the separate snprintf compatibility library. > o Removal of lots of little pieces of cruft that crept into the xforms > 1.0 release. > >You can grab xforms from the download section of the XForms project >page: >http://savannah.nongnu.org/download/xforms/ > >Please send bug reports to this list (xforms at bob.usuhs.mil). > >JMarc >_______________________________________________ >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 Wed Mar 31 05:12:27 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 31 Mar 2004 12:12:27 +0200 Subject: [XForms] Client Message handler success. In-Reply-To: <4069AA10.20604@comcast.net> (wd4nmq@comcast.net's message of "Tue, 30 Mar 2004 12:10:40 -0500") References: <4069AA10.20604@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> I will be using Trent's suggestion: int reserved[10 - Jeff> sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; Jeff> OK? Anybody see any probelms? I think that's fine. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 05:12:58 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 31 Mar 2004 12:12:58 +0200 Subject: [XForms] [ANNOUNCE] XForms 1.0.90 In-Reply-To: <4069AB74.3050100@comcast.net> (wd4nmq@comcast.net's message of "Tue, 30 Mar 2004 12:16:36 -0500") References: <4069AB74.3050100@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list Jean-Marc, Jeff> If it is ok with you, I will apply my changes to this new Jeff> release and will make diffs againest it. I hope to have the Jeff> diffs either tonight or tomorrow. Very good. I was about to ask you to do that :) JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 05:25:12 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 31 Mar 2004 12:25:12 +0200 Subject: [XForms] Client Message handler success. In-Reply-To: <4069A957.5050201@comcast.net> (wd4nmq@comcast.net's message of "Tue, 30 Mar 2004 12:07:35 -0500") References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> <4069A957.5050201@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> On the question of each form having a client message callback I Jeff> believe that would be the correct way to go. As I understand it, Jeff> each form is a seperate X window. So, since XSendEvent() targets Jeff> an X window, it would make sense for each form/window to have Jeff> it's own client message callback. That makes sense. It was just a suggestion. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 05:51:23 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 31 Mar 2004 12:51:23 +0200 Subject: [XForms] Re: Xforms : popup menus In-Reply-To: <404707F2.2070306@lapp.in2p3.fr> (Laurent Fournier's message of "Thu, 04 Mar 2004 11:41:54 +0100") References: <404707F2.2070306@lapp.in2p3.fr> Message-ID: >>>>> "Laurent" == Laurent Fournier writes: Dear Laurent, Sorry for not answering earlier to your message. I wanted to take a look at the code first. I'd like to settle this popup issue before 1.1.0, but I am somhow not satisfied with the solution of using memset (why? I do not know precisely :) Laurent> Dear Jean-Marc, I will try to give you some more information Laurent> on how I use Xforms and how I discovered this bug. [snip] Laurent> *** The context of using the menus of Xforms. The first steps Laurent> of development were to use menus (not directly popups) Laurent> because there was no need for cascaded menus. I got crashes Laurent> some times when exiting from a menu (with or without Laurent> selection) but I did not compile on LynxOS... then I could Laurent> not find the reason of the problem. When came the need of Laurent> cascaded menus, then I used directly popups, with the Laurent> PopupEntry structure. The data is made of a fixed part and a Laurent> variable part coming from the configuration file. Things Laurent> became worse ! I then turned myself towards LynxOS which I Laurent> know to be very sensitive to memory corruptions (we use Laurent> real-time CPUs for data acquisition which is also a big part Laurent> of my job). In a few hours I got several segmentation Laurent> violations and I discovered the following : When calling Laurent> fl_freepup(), there is a loop which frees all menu items by Laurent> looping on ALL entries (it is limited to FL_MAXPUPI, not Laurent> nitems) but the data is not set to 0. What particular data should have been set to zero and caused problem? At least the pointers are correctly reset. Was the problem related to callbacks? Laurent> This is the reason why I replaced all settings to 0 in the Laurent> initialization routine by a single memset() (which is Laurent> portable on almost every OS) and I have done the same when Laurent> setting the maximum number of popups (fl_setpup_maxpup()) Laurent> because realloc() does not set the data to 0. Laurent> The call to memset() should not affect speed as it is only Laurent> called at initialization time. When calling fl_safe_free(), Laurent> the NULL pointers are obviously not freed and everything Laurent> works fine. I agree that memset is not expensive. I would just like to understand where the real problem was, in order to be sure that we do not miss something. Laurent> I sometimes had the problem reported in the forum but I did Laurent> not experience the problem since this correction. The current Laurent> patched version is not released yet to users and I do not Laurent> have enough feedback from the users. Besides this, one major Laurent> improvement to popups would be not to use a "maxpup" value Laurent> but to have automatic reallocation, when needed. My Laurent> application stores much more than 64 menus but the number of Laurent> menus is not known by advance... I am not sure whether automatic reallocation is really a good thing. It may bite you if you have a popup leak (which may happen easily). Laurent> Last but not least : could you please send me the exact web Laurent> address when reading about Xforms and getting new releases ? Laurent> I would be grateful to get the mails from the Xforms Laurent> developers, as I feel now to have enough experience on the Laurent> whole library. The home of the xforms project is now: https://savannah.nongnu.org/projects/xforms You will find in the Files section xforms 1.0.90, released yesterday in preparation for 1.1.0. I would appreciate if you could test it with the systems you have here (like lynxOS) since we have switched to a new configuration scheme. There is also a mailing list accessible from there: http://cweblog.usuhs.mil/mailman/listinfo/xforms Please use the list for further communication. Laurent> I thank you very much for your attention. Please feel free to Laurent> ask for more, if needed. You're very welcome. JMarc From laurent.fournier at lapp.in2p3.fr Wed Mar 31 09:24:59 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Wed, 31 Mar 2004 16:24:59 +0200 Subject: [XForms] Re: Xforms : popup menus In-Reply-To: References: <404707F2.2070306@lapp.in2p3.fr> Message-ID: <406AD4BB.9060800@lapp.in2p3.fr> Jean-Marc Lasgouttes wrote: >Sorry for not answering earlier to your message. I wanted to take a >look at the code first. I'd like to settle this popup issue before >1.1.0, but I am somhow not satisfied with the solution of using memset >(why? I do not know precisely :) > > I agree with your point of view. The use of memset() is only a way to ensure data initialization. As a rule of thumb we develop our code assuming that a NULL pointer is free, then we use to call calloc(), or realloc() with a memset() on any additional data. The best way would be to use the exact amount of memory we need for the menu item array. >What particular data should have been set to zero and caused problem? >At least the pointers are correctly reset. Was the problem related to >callbacks? > > The data what causes problems is the menu item array, when setting fl_maxpup to a higher value than FL_MAXPUP with fl_setpup_maxpup(), i.e. the pointer to menu items and the menu items themselves are not NULL. When calling fl_setpup_maxpup(), the default array of popup menus is resized and then reallocated. But at the initialization time (the very first call to fl_init_pup), the first allocation is made using a calloc() which sets all data to zero, and in particular the pointer "menu_rec->item". When not set to zero, we get garbage into the pointer array which leads to invalid data segments on the array (and thus menu items), and LynxOS gives a SIGSEGV when freeing any segment beginning with '9' (these are reserved adresses for the kernel but this is not the only case with this very sensitive OS). Thus, the problem is not directly related to callbacks, even if fl_freepup() is called on FL_FREEMEM events. >I agree that memset is not expensive. I would just like to understand >where the real problem was, in order to be sure that we do not miss >something. > > If you prefer not to call memset(), one solution to the real problem could be : 1 - to ensure proper initialization of unused pointers (especially menu_rec->item of course) when calling fl_setpup_maxpup(), 2 - to limit the loop counter in the function fl_freepup() to p->nitem instead of FL_MAXPUPI (line 1157 in v0.9999/lib/xpopup.c) because p->nitem handles the number of actually allocated menu item structures (i.e. valid pointers). Anyhow, fl_safe_free() checks only NULL pointers and is not enough for invalid pointers unless you ensure that a NULL pointer is free. This is the main reason for crashes under LynxOS with the so-called '9' segment. Moreover, memset() gives a slightly shorter code because we do not have to set many fields to 0 (we have limited space on Lynx CPUs). >I am not sure whether automatic reallocation is really a good thing. >It may bite you if you have a popup leak (which may happen easily). > > This is quite true. My application works fine when allocating a (big) default number of popups (and a call to memset() at this time). The only thing what I have to assume is to ensure enough (initialized) memory space. Moreover, reallocating memory for popups during the running phase seems not to be a problem. But in that case I need to gain access to the static variable fl_max_pup to count the number of popups and get more space when needed. I thank you for your kind attention on this problem... I thoroughly look for version 1.1 ! Amicalement, Laurent. From wd4nmq at comcast.net Wed Mar 31 10:01:20 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed, 31 Mar 2004 10:01:20 -0500 Subject: [XForms] Client Message handler success. In-Reply-To: References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> <4069A957.5050201@comcast.net> Message-ID: <406ADD40.6060001@comcast.net> All sugestions greatfully accepted. My bad habit is I like to explain why I did something a particular way. That way if somebody might see something in my explanation that could be done better, or might not work at all, they can bring it to my attention. Jean-Marc Lasgouttes wrote: >To subscribers of the xforms list > > > > >>>>>>"Jeff" == Jeff writes: >>>>>> >>>>>> > >Jeff> On the question of each form having a client message callback I >Jeff> believe that would be the correct way to go. As I understand it, >Jeff> each form is a seperate X window. So, since XSendEvent() targets >Jeff> an X window, it would make sense for each form/window to have >Jeff> it's own client message callback. > >That makes sense. It was just a suggestion. > >JMarc > Jeff From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 10:18:52 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 31 Mar 2004 17:18:52 +0200 Subject: [XForms] Re: Xforms : popup menus In-Reply-To: <406AD4BB.9060800@lapp.in2p3.fr> (laurent FOURNIER's message of "Wed, 31 Mar 2004 16:24:59 +0200") References: <404707F2.2070306@lapp.in2p3.fr> <406AD4BB.9060800@lapp.in2p3.fr> Message-ID: >>>>> "laurent" == laurent FOURNIER writes: laurent> Jean-Marc Lasgouttes wrote: laurent> I agree with your point of view. The use of memset() is only laurent> a way to ensure data initialization. As a rule of thumb we laurent> develop our code assuming that a NULL pointer is free, then laurent> we use to call calloc(), or realloc() with a memset() on any laurent> additional data. The best way would be to use the exact laurent> amount of memory we need for the menu item array. Sure. I memory very tight in your setting? laurent> The data what causes problems is the menu item array, when laurent> setting fl_maxpup to a higher value than FL_MAXPUP with laurent> fl_setpup_maxpup(), i.e. the pointer to menu items and the laurent> menu items themselves are not NULL. There is not real pointer to menu items, since item is an array. All the code that I have seen sets the first entry (item[0]) to 0 when needed, so there should not be any problem [actually, I know there is a problem, since you experienced it. But I fail to see it] laurent> When calling fl_setpup_maxpup(), the default array of popup laurent> menus is resized and then reallocated. But at the laurent> initialization time (the very first call to fl_init_pup), the laurent> first allocation is made using a calloc() which sets all data laurent> to zero, and in particular the pointer "menu_rec->item". When laurent> not set to zero, we get garbage into the pointer array which laurent> leads to invalid data segments on the array (and thus menu laurent> items), and LynxOS gives a SIGSEGV when freeing any segment laurent> beginning with '9' (these are reserved adresses for the laurent> kernel but this is not the only case with this very sensitive laurent> OS). fl_setpup_maxpup does reset title and item[0] for each new popup. It seems however that it fails to reset parent, and this may cause problems with the following test in find_index: if (!p->title && !p->item[0] && !p->parent) Then fl_setpup_maxpup would read: int fl_setpup_maxpup(int n) { int i; if (n < FL_MAXPUP) return FL_MAXPUP; fl_init_pup(); menu_rec = fl_realloc(menu_rec, n * sizeof(*menu_rec)); for (i = fl_maxpup; i < n; i++) { menu_rec[i].title = 0; menu_rec[i].item[0] = 0; menu_rec[i].parent = 0; /* <================== */ } return fl_maxpup = n; } However, I fail to see how this missing piece could cause a crash. As far as I can see, the only possible consequence is that find_index would fail to recognize a popup as available. The fix is probably good nevertheless. laurent> If you prefer not to call memset(), one solution to the real laurent> problem could be : laurent> 1 - to ensure proper initialization of unused pointers laurent> (especially menu_rec-> item of course) when calling laurent> fl_setpup_maxpup(), But menu_rec->item is not really a pointer, is it? laurent> 2 - to limit the loop counter in the function fl_freepup() to laurent> p->nitem instead of FL_MAXPUPI (line 1157 in laurent> v0.9999/lib/xpopup.c) because p->nitem handles the number of laurent> actually allocated menu item p->structures laurent> (i.e. valid pointers). Yes, this one seems to be the real killer. I'll try to reproduce its effect under valgrind here. laurent> Anyhow, fl_safe_free() checks only NULL pointers and is not laurent> enough for invalid pointers unless you ensure that a NULL laurent> pointer is free. This is the main reason for crashes under laurent> LynxOS with the so-called '9' segment. Moreover, memset() laurent> gives a slightly shorter code because we do not have to set laurent> many fields to 0 (we have limited space on Lynx CPUs). I doubt that this difference in space will be important enough. I guess there many other sources of bloat in xforms :) laurent> This is quite true. My application works fine when allocating laurent> a (big) default number of popups (and a call to memset() at laurent> this time). The only thing what I have to assume is to ensure laurent> enough (initialized) memory space. Moreover, reallocating laurent> memory for popups during the running phase seems not to be a laurent> problem. But in that case I need to gain access to the static laurent> variable fl_max_pup to count the number of popups and get laurent> more space when needed. What we do in LyX is that we maintain our own maxpup variable that starts at 32 and we call fl_setpup_maxpup as needed. The (C++) code looks like int get_new_submenu(vector & smn, Window win) { static size_type max_number_of_menus = 32; if (smn.size() >= max_number_of_menus) max_number_of_menus = fl_setpup_maxpup(static_cast(2*smn.size())); [...] Here, smn holds the list of menus that have been allocated. This is used to deallocate them when they ar enot needed any more (menus are generated just before displaying them in LyX). I'll try to come up with a patch against xforms 1.0.90. I'd be interested to see whether it fixes your problems. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 10:20:28 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 31 Mar 2004 17:20:28 +0200 Subject: [XForms] Client Message handler success. In-Reply-To: <406ADD40.6060001@comcast.net> (wd4nmq@comcast.net's message of "Wed, 31 Mar 2004 10:01:20 -0500") References: <40554435.8070409@comcast.net> <40572DE6.6080604@comcast.net> <4069A957.5050201@comcast.net> <406ADD40.6060001@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> All sugestions greatfully accepted. My bad habit is I like to Jeff> explain why I did something a particular way. That way if Jeff> somebody might see something in my explanation that could be Jeff> done better, or might not work at all, they can bring it to my Jeff> attention. That's how I read it, and you convinced me. JMarc From wd4nmq at comcast.net Wed Mar 31 10:43:03 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed, 31 Mar 2004 10:43:03 -0500 Subject: [XForms] making diff file Message-ID: <406AE707.9030300@comcast.net> To maintainers, How do you want the diff command executed and which directory do you want as the base directory where diff is run from? Jeff From angus.leeming at btopenworld.com Wed Mar 31 10:48:32 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 31 Mar 2004 16:48:32 +0100 Subject: [XForms] making diff file In-Reply-To: <406AE707.9030300@comcast.net> References: <406AE707.9030300@comcast.net> Message-ID: <200403311648.32663.angus.leeming@btopenworld.com> On Wednesday 31 March 2004 4:43 pm, Jeff wrote: > To maintainers, > > How do you want the diff command executed and which directory do > you want as the base directory where diff is run from? "diff -u" please. I'm too stupid to understand the other flavours. Run it from the top level directory (the one containing the ChangeLog file). Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Wed Mar 31 10:53:08 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 31 Mar 2004 17:53:08 +0200 Subject: [XForms] making diff file In-Reply-To: <406AE707.9030300@comcast.net> (wd4nmq@comcast.net's message of "Wed, 31 Mar 2004 10:43:03 -0500") References: <406AE707.9030300@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list To maintainers, Jeff> How do you want the diff command executed and which directory do Jeff> you want as the base directory where diff is run from? Do a diff from the root xforms source directory. Also the preferred style for diffs is unified (-u). So if you work from cvs, it will be "cvs diff -u". JMarc From wd4nmq at comcast.net Wed Mar 31 20:41:00 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed, 31 Mar 2004 20:41:00 -0500 Subject: [XForms] Adding more calls to support fl_register_client_callback()? Message-ID: <406B732C.2000501@comcast.net> Before I submit the client message patch I had this thought. There are a couple of X lib calls that are needed when using the new fl_register_client_callback(). These would be XInternAtom() and XSendEvent(). One of the parameters is a propertty atom. This is used by the client callback to determine how the data is formated. XInternAtom() is used to set the atom ID and must be called to set an atom BEFORE client messaging can be used. XSendEvent is used to send the event. Now, do we want have a user use the raw X lib calls, or encapsulate them in an fl_*? Like: Atom fl_intern_atom(FL_FORM *form, char *atom_name, Bool only_if_exists); This function would then call XInternAtom() . Status fl_send_clientEvent(FL_FORM *form, Bool propogate); Which would in turn fill in the proper event masks and use *form to get the display and window data and then call XSendEvent(). What ya'll think? Jeff wd4nmq at comcast.net From laurent.fournier at lapp.in2p3.fr Thu Apr 1 02:44:03 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Thu, 01 Apr 2004 09:44:03 +0200 Subject: [XForms] Re: Xforms : popup menus In-Reply-To: References: <404707F2.2070306@lapp.in2p3.fr> <406AD4BB.9060800@lapp.in2p3.fr> Message-ID: <406BC843.1090105@lapp.in2p3.fr> Jean-Marc Lasgouttes wrote: >Sure. I memory very tight in your setting? > Yes, a process cannot get more than 16Mb (but this can be tuned). The total memory is usually 32Mb (some CPUs have up to 96Mb), no hard drive >There is not real pointer to menu items, since item is an array. All >the code that I have seen sets the first entry (item[0]) to 0 when >needed, so there should not be any problem [actually, I know there is >a problem, since you experienced it. But I fail to see it] > >fl_setpup_maxpup does reset title and item[0] for each new popup. It >seems however that it fails to reset parent, and this may cause >problems with the following test in find_index: > if (!p->title && !p->item[0] && !p->parent) > > I did not experience problems with this data... but it was perhaps set to values which do not put the system in trouble. The forms are always created "on the fly" as the user needs them. The only form that is created at startup is the main one since there can be a really huge number of forms. >Then fl_setpup_maxpup would read: > >int >fl_setpup_maxpup(int n) >{ > int i; > > if (n < FL_MAXPUP) > return FL_MAXPUP; > > fl_init_pup(); > > menu_rec = fl_realloc(menu_rec, n * sizeof(*menu_rec)); > for (i = fl_maxpup; i < n; i++) > { > menu_rec[i].title = 0; > menu_rec[i].item[0] = 0; > menu_rec[i].parent = 0; /* <================== */ > } > > return fl_maxpup = n; >} > > I had a look on the code, I think this initialization is quite full of sense ! :-) >But menu_rec->item is not really a pointer, is it? > Not exactly, you are right. >I doubt that this difference in space will be important enough. I >guess there many other sources of bloat in xforms :) > Of course. I like things that are compact, but this is purely personal. >What we do in LyX is that we maintain our own maxpup variable that >starts at 32 and we call fl_setpup_maxpup as needed. The (C++) code >looks like > >int get_new_submenu(vector & smn, Window win) >{ > static size_type max_number_of_menus = 32; > if (smn.size() >= max_number_of_menus) > max_number_of_menus = > fl_setpup_maxpup(static_cast(2*smn.size())); >[...] > >Here, smn holds the list of menus that have been allocated. This is >used to deallocate them when they ar enot needed any more (menus are >generated just before displaying them in LyX). > > I tried a code which is strongly inspired from yours for menu creation (to get the real number of available popups : just call fl_setpup_maxpup(0) ! this returns the number of avalable popups :-) ). Thanks to a preemptive handler on FL_FREEMEM events(for down counting), my application now allocates just enough space. Thank you for the advice ! >I'll try to come up with a patch against xforms 1.0.90. I'd be >interested to see whether it fixes your problems. > >JMarc > > I let you know as soon as possible, I thank you once again for your work. Laurent. From angus.leeming at btopenworld.com Thu Apr 1 12:24:28 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 1 Apr 2004 18:24:28 +0100 Subject: [XForms] Adding more calls to support fl_register_client_callback()? In-Reply-To: <406B732C.2000501@comcast.net> References: <406B732C.2000501@comcast.net> Message-ID: <200404011824.28040.angus.leeming@btopenworld.com> On Thursday 01 April 2004 2:41 am, Jeff wrote: > XInternAtom() is used to set the atom ID and must be called to set > an atom BEFORE client messaging can be used. > XSendEvent is used to send the event. > > Now, do we want have a user use the raw X lib calls, or encapsulate > them in an fl_*? Like: > > Atom fl_intern_atom(FL_FORM *form, > char *atom_name, > Bool only_if_exists); Would wrapping the X lib call give the user anything other than a familiar fl_... ? If not, then I guess that we should use the raw X lib call. Could you give us an example of all this in action. It's hard to make any meaningful statements without some code. Angus From Jean-Marc.Lasgouttes at inria.fr Fri Apr 2 04:05:00 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 02 Apr 2004 11:05:00 +0200 Subject: [XForms] Adding more calls to support fl_register_client_callback()? In-Reply-To: <200404011824.28040.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 1 Apr 2004 18:24:28 +0100") References: <406B732C.2000501@comcast.net> <200404011824.28040.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Thursday 01 April 2004 2:41 am, Jeff wrote: >> XInternAtom() is used to set the atom ID and must be called to set >> an atom BEFORE client messaging can be used. XSendEvent is used to >> send the event. >> >> Now, do we want have a user use the raw X lib calls, or encapsulate >> them in an fl_*? Like: >> >> Atom fl_intern_atom(FL_FORM *form, char *atom_name, Bool >> only_if_exists); Angus> Would wrapping the X lib call give the user anything other than Angus> a familiar fl_... ? If not, then I guess that we should use the Angus> raw X lib call. Well we could forget about the notion of atoms. fl_create_client_message() fl_send_client_message() ... However, I do not know how these atoms are used in real life... Angus, I do not think that there is any place in xforms where you need to manipulate X objects to use a feature. Hmm, let's grep in forms.h... OK, there are fl_XNextEvent and its friends, but I do not know how common it is to use them. Angus> Could you give us an example of all this in action. It's hard Angus> to make any meaningful statements without some code. Actually, it would be nice to have a demo program for the client message feature. JMarc From laurent.fournier at lapp.in2p3.fr Fri Apr 2 05:05:27 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Fri, 02 Apr 2004 12:05:27 +0200 Subject: [XForms] once more about popups Message-ID: <406D3AE7.5090303@lapp.in2p3.fr> Dear Jean-Marc, I have tried your patch in the initialization routine for popups (function fl_setpup_maxpup). In my application the sequence is the following : FL_OBJECT *obj = fl_add_menu(type, x, y, w, h, label); fl_set_object_boxtype(obj, FL_UP_BOX); fl_setpup_default_fontsize(CL_FONT_SIZE); /* this is an integer from config file, usually = 8 or 10 */ fl_setpup_default_fontstyle(FL_NORMAL_STYLE); I made a new run this morning on LynxOS and got the following while calling fl_setup_default_fontsize() in the above sequence : X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 4 (X_DestroyWindow) etc... Then the program enters a deadlock while stacking calls to XSync() (but this is likely a problem with X11 itself on LynxOS) while calling close_pupwin() (xpopup.c line 430). The error occurs because the field pup->win is not initialized to zero ... and does not occur in my own patched version. One more argument towards memset() ! :-) But I do not understand why this did not appear before... Amicalement, Laurent. From wd4nmq at comcast.net Fri Apr 2 11:38:04 2004 From: wd4nmq at comcast.net (Jeff) Date: Fri, 02 Apr 2004 11:38:04 -0500 Subject: [XForms] Adding more calls to support fl_register_client_callback()? In-Reply-To: References: <406B732C.2000501@comcast.net> <200404011824.28040.angus.leeming@btopenworld.com> Message-ID: <406D96EC.9020805@comcast.net> I'll put together a quicky threaded app later today when I get a chance. It will just be a clock. The form will display the time while the thread will do the actual time functions and send the time for display via a client message. That ok? Jeff Jean-Marc Lasgouttes wrote: >To subscribers of the xforms list > > > > >>>>>>"Angus" == Angus Leeming writes: >>>>>> >>>>>> > >Angus> To subscribers of the xforms list >Angus> On Thursday 01 April 2004 2:41 am, Jeff wrote: > > >>>XInternAtom() is used to set the atom ID and must be called to set >>>an atom BEFORE client messaging can be used. XSendEvent is used to >>>send the event. >>> >>>Now, do we want have a user use the raw X lib calls, or encapsulate >>>them in an fl_*? Like: >>> >>>Atom fl_intern_atom(FL_FORM *form, char *atom_name, Bool >>>only_if_exists); >>> >>> > >Angus> Would wrapping the X lib call give the user anything other than >Angus> a familiar fl_... ? If not, then I guess that we should use the >Angus> raw X lib call. > >Well we could forget about the notion of atoms. >fl_create_client_message() >fl_send_client_message() >... > >However, I do not know how these atoms are used in real life... > >Angus, I do not think that there is any place in xforms where you need >to manipulate X objects to use a feature. Hmm, let's grep in >forms.h... OK, there are fl_XNextEvent and its friends, but I do not >know how common it is to use them. > >Angus> Could you give us an example of all this in action. It's hard >Angus> to make any meaningful statements without some code. > >Actually, it would be nice to have a demo program for the client >message feature. > >JMarc >_______________________________________________ >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 wd4nmq at comcast.net Sat Apr 3 01:42:42 2004 From: wd4nmq at comcast.net (Jeff) Date: Sat, 03 Apr 2004 01:42:42 -0500 Subject: [XForms] client event sample application Message-ID: <406E5CE2.5010907@comcast.net> Below is an appliaction that uses the fl_register_client_callback() and demonstrates why atoms are needed. As asked for by Angus I believe. A quick explanation on why atoms are needed. When a client callback is called, all it gets is a pointer to an XEvent structure and all it knows is it is a ClientMessage. It has no idea how the data is formatted. This is where an atom comes into play. An atom is registered with the XInternAtom() call. This atom is then put into effect for the whole X display, like 0:0. Now, any app or thread running in display 0:0 can use that atom. In my demo below I have a text widget that the time is displayed in. The actual time is read from the system in a thread. The time is sent as either a long, or as a pointer to a time struct. These alternate every second. Now, to demonstate how atoms are used I create two atoms, timeStructAtom & longTimeAtom. if the time data is a long, longTimeAtom is used. If it is a pointer to time struct, timeStructAtom is used. Now the client callback can decide how the time is encoded and act appropiatly to display it. Remember, there can be only ONE user ClientMessage callback for an app. So atoms are important in letting the callback know how the data is formatted. The code: #include "forms.h" #include #include "timeEvent.h" #include #include Atom longTimeAtom, timeStructAtom; pthread_t getTimeThread; FD_testEvent *fd_testEvent; FD_testEvent *create_form_testEvent(void) { FL_OBJECT *obj; FD_testEvent *fdui = (FD_testEvent *) fl_calloc(1, sizeof(*fdui)); fdui->testEvent = fl_bgn_form(FL_NO_BOX, 420, 250); obj = fl_add_box(FL_UP_BOX,0,0,420,250,""); fdui->timeText = obj = fl_add_text(FL_NORMAL_TEXT,30,90,350,60,""); fl_set_object_boxtype(obj,FL_SHADOW_BOX); fl_set_object_lsize(obj,FL_HUGE_SIZE); fl_set_object_lalign(obj,FL_ALIGN_LEFT|FL_ALIGN_INSIDE); fl_end_form(); fdui->testEvent->fdui = fdui; return fdui; } /*---------------------------------------*/ FL_CLIENT_CALLBACK clientCallback(FL_FORM *form, XEvent *xev){ char line[128]; // Use message_type to decide how time is encoded if(xev->xclient.message_type == longTimeAtom){ fl_set_object_label(fd_testEvent->timeText, ctime(&xev->xclient.data.l[0])); } else if(xev->xclient.message_type == timeStructAtom){ strftime(line,128, "%a %b %d %H:%M:%S %Y",xev->xclient.data.l[0]); fl_set_object_label(fd_testEvent->timeText, line); } } /*******************************************/ int timerThread(void *ptr){ time_t the_time; struct tm *tm_ptr; XEvent xev; sleep(3); // long timeout first time while(1){ the_time = time((time_t *)0); if(the_time & 0x0001){ xev.xclient.type = ClientMessage; xev.xclient.window = fl_get_winID(fd_testEvent->testEvent); xev.xclient.message_type = longTimeAtom; xev.xclient.format = 16; xev.xclient.data.l[0] = the_time; } else { tm_ptr = localtime(&the_time); xev.xclient.type = ClientMessage; xev.xclient.window = fl_get_winID(fd_testEvent->testEvent); xev.xclient.message_type = timeStructAtom; xev.xclient.format = 16; xev.xclient.data.l[0] = (long)tm_ptr; } XSendEvent(fl_display, fl_get_winID(fd_testEvent->testEvent), False, 0l, &xev); sleep(1); } } /*************************************/ int main(int argc, char *argv[]) { int rtn; fl_initialize(&argc, argv, 0, 0, 0); fd_testEvent = create_form_testEvent(); longTimeAtom = XInternAtom(fl_display, "Long Time", FALSE); timeStructAtom = XInternAtom(fl_display, "Time Pointer", FALSE); fl_register_client_callback(fd_testEvent->testEvent, clientCallback); /* fill-in form initialization code */ /* show the first form */ fl_show_form(fd_testEvent->testEvent,FL_PLACE_CENTERFREE, FL_FULLBORDER,"testEvent"); rtn = pthread_create(&getTimeThread, NULL, (void *) timerThread, NULL); fl_do_forms(); return 0; } // End of code Now, since the code to update the time widget is running in the gui code space, and not the thread actually getting the time. There are no conflicts for the internal xforms code to write the form. You can use fl_do_forms() instead of fl_check_forms() and have to have mutexes for threads to be able to update a form. I believe this is much cleaner. Well, it's 1:30 am local and I am hitting the sack. Jeff From wd4nmq at comcast.net Sat Apr 3 10:15:17 2004 From: wd4nmq at comcast.net (Jeff) Date: Sat, 03 Apr 2004 10:15:17 -0500 Subject: [XForms] Where to put forms.h changes Message-ID: <406ED505.4090604@comcast.net> Angus, Where would you put changes to lib/include/forms.h BEFORE running configure and make? Since it is created by make I cannot change forms.h in the original distribution. Jeff From angus.leeming at btopenworld.com Sat Apr 3 10:23:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 3 Apr 2004 16:23:18 +0100 Subject: [XForms] Where to put forms.h changes In-Reply-To: <406ED505.4090604@comcast.net> References: <406ED505.4090604@comcast.net> Message-ID: <200404031623.18117.angus.leeming@btopenworld.com> On Saturday 03 April 2004 4:15 pm, Jeff wrote: > To subscribers of the xforms list > > > Angus, > > Where would you put changes to lib/include/forms.h BEFORE running > configure and make? Since it is created by make I cannot change > forms.h in the original distribution. Hi, Jeff. See the files in lib/include. They are concatenated together to create forms.h Angus From Gayle.C.Roth at nasa.gov Mon Apr 5 10:56:00 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Mon, 05 Apr 2004 10:56:00 -0400 Subject: [XForms] OpenVMS version of xforms Message-ID: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> Hi. I'm trying to get an OpenVMS version of xforms. Does anyone know the CURRENT web site with the downloads, with the operating system names next to their links? I went to the web site http://world.std.com/~xforms/ftp/ftp.html, which had an OpenVMS link. This however is outdated since the only thing I got was a README that said that site is no longer the repository, and the repository now is: http://savannah.nongnu.org/files/?group=xforms. That site has several downloads but nothing next to the file names (i.e. no indication of which one is for which operating system). Can someone tell me how to get an openVMS (or just plain VMS) download? Thanks, Gayle Roth From angus.leeming at btopenworld.com Mon Apr 5 13:03:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 5 Apr 2004 18:03:33 +0100 Subject: [XForms] OpenVMS version of xforms In-Reply-To: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> Message-ID: <200404051803.33774.angus.leeming@btopenworld.com> On Monday 05 April 2004 3:56 pm, Gayle C Roth wrote: > I'm trying to get an OpenVMS version of xforms. Does anyone know > the CURRENT web site with the downloads, with the operating system > names next to their links? I went to the web site > http://world.std.com/~xforms/ftp/ftp.html, which had an OpenVMS > link. This however is outdated since the only thing I got was a > README that said that site is no longer the repository, and the > repository now > is: http://savannah.nongnu.org/files/?group=xforms. That site has > several downloads but nothing next to the file names (i.e. no > indication of which one is for which operating system). Can > someone tell me how to get an openVMS (or just plain VMS) download? Hi, Gayle. xforms has moved to an Open Source licence meaning that there's no need for us to provide binaries for tens of different platforms. Grab the source and compile it. The xforms 1.0 release uses xmkmf and family to generate the Makefiles. It is kludgy and I don't think that anybody here knows much about it. The xforms 1.0.90 pre-release for xforms 1.1 uses the gnu autotools to generate the Makefiles. We'd be very grateful if you could try it out on your box. The source itself is little changed from xforms 1.0 modulo a fair number of bug fixes. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Tue Apr 6 10:09:29 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 06 Apr 2004 16:09:29 +0200 Subject: [XForms] [PATCH] Fix valgrind warning Message-ID: A non-text attachment was scrubbed... Name: strncpy.diff Type: text/x-patch Size: 1336 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040406/8e73c304/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Tue Apr 6 10:46:47 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 06 Apr 2004 16:46:47 +0200 Subject: [XForms] OpenVMS version of xforms In-Reply-To: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> (Gayle C. Roth's message of "Mon, 05 Apr 2004 10:56:00 -0400") References: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> Message-ID: >>>>> "Gayle" == Gayle C Roth writes: Gayle> To subscribers of the xforms list Hi. Gayle> I'm trying to get an OpenVMS version of xforms. Does anyone Gayle> know the CURRENT web site with the downloads, with the Gayle> operating system names next to their links? If you go to the old ftp site (ncmir.ucsd.edu) and visit the directory /pub/xforms/Attic/OpenVMS/, you will find a binary for xforms 0.88. This is admittedly old, but nobody here knows how to compile on OpenVMS. If OpenVMS has basic support for looking like unix (like running a unix shell), you can try the version 1.0.90 at http://savannah.nongnu.org/files/?group=xforms This is a source distribution, and you will have to compile it yourself. However, we are here to help. JMarc From angus.leeming at btopenworld.com Tue Apr 6 17:28:34 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 6 Apr 2004 22:28:34 +0100 Subject: [XForms] OpenVMS version of xforms In-Reply-To: <5.1.1.5.2.20040406092010.01667ea8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040405104158.01667258@popserve.grc.nasa.gov> <5.1.1.5.2.20040406092010.01667ea8@popserve.grc.nasa.gov> Message-ID: <200404062228.34701.angus.leeming@btopenworld.com> On Tuesday 06 April 2004 2:25 pm, Gayle C Roth wrote: > > > I'm trying to get an OpenVMS version of xforms. Does anyone > > > know the CURRENT web site with the downloads, with the > > > operating system names next to their links? I went to the web > > > site > > > http://world.std.com/~xforms/ftp/ftp.html, which had an OpenVMS > > > link. This however is outdated since the only thing I got was > > > a README that said that site is no longer the repository, and > > > the repository now > > > is: http://savannah.nongnu.org/files/?group=xforms. That site > > > has several downloads but nothing next to the file names (i.e. > > > no indication of which one is for which operating system). Can > > > someone tell me how to get an openVMS (or just plain VMS) > > > download? > > Thanks, Angus. I actually have the source but was hoping there was > still a binary out there for OpenVMS because I may have to port my > GUI which uses xforms in the very near future. Unfortunately, the > Makefile generation doesn't apply here because OpenVMS is not UNIX. > Otherwise, I'd be happy to try out that tool. > > Wish me luck! Good luck! And remember, we're here to help. Incidentally, a quick search on google suggests that gnu make works on OpenVMS. The gnu autotools are a bunch of perl scripts that will create a config.h header file defining lots of system-specific macros and a bunch of Makefiles. Angus > >Hi, Gayle. > > > >xforms has moved to an Open Source licence meaning that there's no > >need for us to provide binaries for tens of different platforms. > > Grab the source and compile it. > > > >The xforms 1.0 release uses xmkmf and family to generate the > >Makefiles. It is kludgy and I don't think that anybody here knows > >much about it. > > > >The xforms 1.0.90 pre-release for xforms 1.1 uses the gnu > > autotools to generate the Makefiles. We'd be very grateful if you > > could try it out on your box. The source itself is little changed > > from xforms 1.0 modulo a fair number of bug fixes. > > > >Regards, > >Angus From angus.leeming at btopenworld.com Thu Apr 8 16:41:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 8 Apr 2004 21:41:18 +0100 Subject: [XForms] Resurrecting an old patch for slider.c Message-ID: <200404082141.18915.angus.leeming@btopenworld.com> Below is a mesage and attached is a patch that I originally sent to the xforms list 16 months ago. The question is, should I apply this simple patch or should I apply the more complex alternative using a timer? Regards, Angus The investigation was originally motivated by this bug report: Clicking in the scrollbar trough to scroll through a document auto-repeats after a short delay, as expected. However, the delay before auti-repeating kicks in is too short and the repeat rate much to fast on my system. Most of the time I cannot use clicking in the scrollbar trough to page forward in my documents because the delay before auto-repeating is shorter than my single-click time (and I'm not a slow mouser...) In fact, the entire sorry saga can be found here: http://bugzilla.lyx.org/show_bug.cgi?id=747 The upshot was that I posted the message below to the xforms list. Nothing came of it... On Monday 02 December 2002 7:36 pm, John Levon wrote: > 4. xforms should mediate these callbacks to a reasonable pace using a > timer. I've spent some time trying to ascertain exactly what we want and what xforms gives us at the moment. Allow me to take you through it. You'll find at the end that xforms already gives us what we want --- almost --- so bear with me... The problem is that we want quite fine-grained control over the scrollbar and it's only for one of these interactions that we need/want the mediation that John is suggesting. The scrollbar is actually a "complex widget" made up of three "simple widget"s, a "slider" and two buttons named "up" and "down" that are the little arrow buttons at the end of the slider. The user can control the slider position in several different ways: * Click on and drag the slider to the desired position. * Click in the slider trough with the LMB * Click in the slider trough with the RMB * Click on the up/down buttons with any mouse button. Each interaction results in a different behaviour. Specifically, if the scrollbar increment is set: fl_set_scrollbar_increment(scrollbar, lmb_inc, rmb_inc); then clicking in the slider trough with the LMB increments the slider by lmb_inc. Ditto, clicking in the slider trough with the RMB increments the slider by rmb_inc. Finally, clicking on the up and down buttons with any mouse button increments the slider by rmb_inc. All four types of "click-interaction" result in a call to the user-specified scrollbar->object_callback routine. The user has no way of differentiating between the different possible click behaviours. I have extracted this information through the use of judiciously placed print statements in the xforms source. It isn't woolly; it's an accurate description of the code. In our particular case, lmb_inc is "increment by 1 page" and rmb_inc is "increment by 1 line" Moreover, because the LMB click in the slider trough results in a large increment, we would like callbacks resulting from it to be mediated by a reasonable delay between callbacks. From all this, I conclude that we should focus our attention on the simple slider widget rather than the complex scrollbar widget. Moreover, an examination of slider.c's source shows that the code to do what we want is already there --- almost. We need merely modify slider.c's handle_mouse routine. I append the relevant code snippet below. Note how xforms currently uses a "timdel" variable to ignore the callbacks 1-10 after the mouse button is pressed. Thereafter, every other mouse event gets through. Proposal 1 use the current approach, but reset timdel to 0 after it's reached 11. make 11 tunable from the outside. Proposal 2 use a timer instead of timdel. Does this make sense? Would you like to try and fix the source this way or are you set on your idea still? Regards, Angus (who's starting to get to grips with the xforms source...) ps. We've had similar problem reports about the counter from users. Note that it too has a handle_mouse routine using a timdel variable, so it looks to me that we can cure both problems in the same way. That's wasted the morning. Best do some proper work this afternoon. A. -------------- next part -------------- A non-text attachment was scrubbed... Name: xforms-slider.diff Type: text/x-diff Size: 910 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040408/74bedffe/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Fri Apr 9 07:55:11 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 09 Apr 2004 13:55:11 +0200 Subject: [XForms] Resurrecting an old patch for slider.c In-Reply-To: <200404082141.18915.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 8 Apr 2004 21:41:18 +0100") References: <200404082141.18915.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Below is a mesage and Angus> attached is a patch that I originally sent to the xforms list Angus> 16 months ago. The question is, should I apply this simple Angus> patch or should I apply the more complex alternative using a Angus> timer? I guess the problem is to know whether your patch produces the right feeling for applications like LyX. Did you try it at the time? I do not know what other applications out there have a use for a slider over a large text. Maybe XFMail? JMarc From Gayle.C.Roth at nasa.gov Fri Apr 9 10:47:27 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Fri, 09 Apr 2004 10:47:27 -0400 Subject: [XForms] xforms 1.0.90 pre-release Message-ID: <5.1.1.5.2.20040409103937.016851c8@popserve.grc.nasa.gov> Hi. A few days ago, Angus told me about the xforms 1.0.90 pre-release for xforms 1.1. He said it includes gnu autotools to generate Makefiles. I'd like to try it out for OpenVMS but don't know where to get it. Where do I go to download this pre-release? I've tried searches on xforms 1.0 and xforms 1.1 and don't know what to do from those pages. Thanks, Gayle From bob at bob.usuhs.mil Fri Apr 9 14:30:58 2004 From: bob at bob.usuhs.mil (Robert Williams) Date: Fri, 09 Apr 2004 14:30:58 -0400 Subject: [XForms] Possible problems with list subscriptions Message-ID: <4076EBE2.6090009@bob.usuhs.mil> Our subnet, where the xforms list server lives, has been hit very hard by email worms in the past few days. None of these have found their way to our list server, but admins up and down the line at various .mil sites have been doing some pretty drastic things to stop the flow and clear the decks. As a consequence, the list has seen a flurry of bounces and unsubscribes that appear to have nothing to do with the wishes of subscribed members. I'm trying to keep a list of unsubscribe notices, but since my address seems to have found its way into the worms list, I'm getting hundreds of these worms myself (mimedefanged by our server, but I still get the notices and bounces from other sites.)... So I'm not paying a lot of attention to the unsubscribe notices, and if you find yourself unsubscribed at some point, you will have to resubscribe yourself to the list if you want back on. The info page is at: http://cweblog.usuhs.mil/mailman/listinfo/xforms -- Dr. Robert Williams Dept. of Biomedical Informatics Uniformed Services University 301-295-3568 From angus.leeming at btopenworld.com Mon Apr 12 15:13:05 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 12 Apr 2004 20:13:05 +0100 Subject: [XForms] xforms 1.0.90 pre-release In-Reply-To: <5.1.1.5.2.20040409103937.016851c8@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040409103937.016851c8@popserve.grc.nasa.gov> Message-ID: <200404122013.05910.angus.leeming@btopenworld.com> On Friday 09 April 2004 3:47 pm, Gayle C Roth wrote: > Hi. > > A few days ago, Angus told me about the xforms 1.0.90 pre-release > for xforms 1.1. He said it includes gnu autotools to generate > Makefiles. I'd like to try it out for OpenVMS but don't know where > to get it. Where do I go to download this pre-release? I've tried > searches on xforms 1.0 and xforms 1.1 and don't know what to do > from those pages. > > Thanks, > Gayle Hi, Gayle. Sorry for any confusion, but my use of "autotools" is just shorthand for "autoconf and automake". These pages have links to the official gnu download sites: http://www.gnu.org/software/autoconf/ http://www.gnu.org/software/automake/ They're both perl scripts. autoconf will generate a header file config.h that is #included in the .c files. It contains a bunch of macros #define HAVE_DECL_VSNPRINTF 1 #define HAVE_STDLIB_H 1 etc. automake generates portable makefiles from the Makefile.am templates. Thereafter you'll need a 'make' executable to build the sources. To use them, execute the autogen.sh shell script in the top-level directory. Here's what I do: cd xforms ./autogen.sh mkdir build && cd build ../configure make This builds the object, executable and library files in a directory 'build' that is separate from the sources themselves. Keeps things clean. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Tue Apr 13 05:31:46 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 13 Apr 2004 11:31:46 +0200 Subject: [XForms] xforms 1.0.90 pre-release In-Reply-To: <200404122013.05910.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 12 Apr 2004 20:13:05 +0100") References: <5.1.1.5.2.20040409103937.016851c8@popserve.grc.nasa.gov> <200404122013.05910.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Sorry for any confusion, but my use of "autotools" is just Angus> shorthand for "autoconf and automake". These pages have links Angus> to the official gnu download sites: As far as I know, autoconf and automake have not been ported to OpenVMS yet. There is a project named GNV that is working on unix interoperability, though: http://gnv.sourceforge.net/ We should maybe take another look at the vms support in xforms 1.0 and see whether we can get rid of the need for autoconf in this case. Gayle, if you are willing to spend some time on that, we could have a go at it. JMarc From ncrespo at interlab.es Wed Apr 14 04:33:53 2004 From: ncrespo at interlab.es (Natalia Crespo) Date: Wed, 14 Apr 2004 10:33:53 +0200 Subject: [XForms] FL_NOBORDER forms and sawfish Message-ID: <407CF771.1040308@interlab.es> Hello, We've been working with fvwm2 window manager and applications using xforms library. We need to use windows with FL_FULLBORDER and FL_NOBORDER border in the same application and with fvwm2 we don't have any problem. However, we've decided to use GNOME with sawfish as window manager and we've got quite problems showing a window with no border and after that another one with full border. The second window (with border) stays at the back of the first (without border) one and the application doesn't work properly. We'd like to know if it's possible to configure sawfish to manage that kind of window without problems. We've been trying to configurate it using "~/.sawfishrc" file but we haven't found a solution. Anybody knows if it's necessary to change any attribute to get it? Any other suggestion? Thanks a lot in avance. Natalia. From wd4nmq at comcast.net Wed Apr 14 11:12:39 2004 From: wd4nmq at comcast.net (Jeff) Date: Wed, 14 Apr 2004 11:12:39 -0400 Subject: [XForms] Where to change forms.h? Message-ID: <407D54E7.5070607@comcast.net> I've asked this problem before, but where do you implement changes for /lib/include/forms.h? It is created during the ./confiigure and make steps. So, where do I make changes to add my client message functionality? Jeff wd4nmq at comcast.net From angus.leeming at btopenworld.com Wed Apr 14 11:21:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 14 Apr 2004 16:21:18 +0100 Subject: [XForms] Where to change forms.h? In-Reply-To: <407D54E7.5070607@comcast.net> References: <407D54E7.5070607@comcast.net> Message-ID: <200404141621.19008.angus.leeming@btopenworld.com> On Wednesday 14 April 2004 4:12 pm, Jeff wrote: > I've asked this problem before, but where do you implement changes > for /lib/include/forms.h? > > It is created during the ./confiigure and make steps. I answered it before too: See the files in lib/include. They are concatenated together to create forms.h So, one possible solution would be to create a new file client_msg.h and add it to the list of files in lib/include/Makefile.am Angus From wd4nmq at comcast.net Thu Apr 15 10:28:24 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu, 15 Apr 2004 10:28:24 -0400 Subject: [XForms] Where to change forms.h? In-Reply-To: <200404141621.19008.angus.leeming@btopenworld.com> References: <407D54E7.5070607@comcast.net> <200404141621.19008.angus.leeming@btopenworld.com> Message-ID: <407E9C08.1080809@comcast.net> I did have an email glitch and I must have missed it. Sorry. I am getting the patch ready in the next day or two. Jeff Angus Leeming wrote: >On Wednesday 14 April 2004 4:12 pm, Jeff wrote: > > >>I've asked this problem before, but where do you implement changes >>for /lib/include/forms.h? >> >>It is created during the ./confiigure and make steps. >> >> > >I answered it before too: > >See the files in lib/include. They are concatenated together to create >forms.h > >So, one possible solution would be to create a new file client_msg.h >and add it to the list of files in lib/include/Makefile.am > >Angus > > > > From Jean-Marc.Lasgouttes at inria.fr Tue Apr 20 11:24:20 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 20 Apr 2004 17:24:20 +0200 Subject: [XForms] [PATCH] configuration fixes Message-ID: A non-text attachment was scrubbed... Name: conf.diff Type: text/x-patch Size: 2581 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040420/198fe33b/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Tue Apr 20 12:01:24 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 20 Apr 2004 18:01:24 +0200 Subject: [XForms] [PATCH] Re: once more about popups In-Reply-To: <406D3AE7.5090303@lapp.in2p3.fr> (laurent FOURNIER's message of "Fri, 02 Apr 2004 12:05:27 +0200") References: <406D3AE7.5090303@lapp.in2p3.fr> Message-ID: A non-text attachment was scrubbed... Name: xpopup.diff Type: text/x-patch Size: 1742 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040420/5bee91e8/attachment.bin From laurent.fournier at lapp.in2p3.fr Wed Apr 21 03:33:47 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Wed, 21 Apr 2004 09:33:47 +0200 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: References: <406D3AE7.5090303@lapp.in2p3.fr> Message-ID: <408623DB.8020206@lapp.in2p3.fr> Dear Jean-Marc, >laurent> I made a new run this morning on LynxOS and got the following >laurent> while calling fl_setup_default_fontsize() in the above >laurent> sequence : [...] > >laurent> Then the program enters a deadlock while stacking calls to >laurent> XSync() (but this is likely a problem with X11 itself on >laurent> LynxOS) while calling close_pupwin() (xpopup.c line 430). The >laurent> error occurs because the field pup->win is not initialized to >laurent> zero ... and does not occur in my own patched version. One >laurent> more argument towards memset() ! :-) But I do not understand >laurent> why this did not appear before... > >Dear Laurent, > >Sorry for taking so long to answer (again!). Could you try the >attached patch? > I thought I was boring you with my problems... I thank you very much for your help, I try this as soon as possible (probably today) and I let you know. >I suspect that the fact that parent is now reset means that old >entries can be re-used, and this is why a bad win eventually bites us. > >Concerning the use of memset, what I want is just to minimize the >number of places where we do such things. However, it would probably >be wise to have a clear_pup(p) that clears a popup entry (maybe with >memset ;). That would be called by init_popup(), for example. > I totally agree this point of view. >JMarc > > Thank you again. Laurent. From Jean-Marc.Lasgouttes at inria.fr Wed Apr 21 05:56:43 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 21 Apr 2004 11:56:43 +0200 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: <408623DB.8020206@lapp.in2p3.fr> (laurent FOURNIER's message of "Wed, 21 Apr 2004 09:33:47 +0200") References: <406D3AE7.5090303@lapp.in2p3.fr> <408623DB.8020206@lapp.in2p3.fr> Message-ID: >>>>> "laurent" == laurent FOURNIER writes: >> Sorry for taking so long to answer (again!). Could you try the >> attached patch? >> laurent> I thought I was boring you with my problems... I thank you laurent> very much for your help, I try this as soon as possible laurent> (probably today) and I let you know. No, but I do not have much time and wanted to take a real look at the sources before proposing a patch. [I do not suggest that it was soo difficult to do, I am just trying to cover up my laziness :)] JMarc From laurent.fournier at lapp.in2p3.fr Wed Apr 21 09:09:53 2004 From: laurent.fournier at lapp.in2p3.fr (laurent FOURNIER) Date: Wed, 21 Apr 2004 15:09:53 +0200 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: References: <406D3AE7.5090303@lapp.in2p3.fr> Message-ID: <408672A1.5050008@lapp.in2p3.fr> Dear Jean-Marc, >Dear Laurent, > >Sorry for taking so long to answer (again!). Could you try the >attached patch? > I just try your patch... works fine... I adopt it ! >JMarc > > Now looking forward to the new version. I thank you again. Laurent. From Jean-Marc.Lasgouttes at inria.fr Wed Apr 21 10:18:02 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 21 Apr 2004 16:18:02 +0200 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: <408672A1.5050008@lapp.in2p3.fr> (laurent FOURNIER's message of "Wed, 21 Apr 2004 15:09:53 +0200") References: <406D3AE7.5090303@lapp.in2p3.fr> <408672A1.5050008@lapp.in2p3.fr> Message-ID: >>>>> "laurent" == laurent FOURNIER writes: laurent> Dear Jean-Marc, >> Dear Laurent, >> >> Sorry for taking so long to answer (again!). Could you try the >> attached patch? >> laurent> I just try your patch... works fine... I adopt it ! Thanks. I'll apply it asap. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Apr 21 11:21:18 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 21 Apr 2004 17:21:18 +0200 Subject: [XForms] Re: [PATCH] Re: once more about popups In-Reply-To: (Jean-Marc Lasgouttes's message of "Wed, 21 Apr 2004 16:18:02 +0200") References: <406D3AE7.5090303@lapp.in2p3.fr> <408672A1.5050008@lapp.in2p3.fr> Message-ID: >>>>> "Jean-Marc" == Jean-Marc Lasgouttes writes: laurent> I just try your patch... works fine... I adopt it ! Jean-Marc> Thanks. I'll apply it asap. Done. BTW Laurent: thanks for being so patient :) JMarc From Jean-Marc.Lasgouttes at inria.fr Wed Apr 21 11:28:42 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 21 Apr 2004 17:28:42 +0200 Subject: [XForms] FL_NOBORDER forms and sawfish In-Reply-To: <407CF771.1040308@interlab.es> (Natalia Crespo's message of "Wed, 14 Apr 2004 10:33:53 +0200") References: <407CF771.1040308@interlab.es> Message-ID: >>>>> "Natalia" == Natalia Crespo writes: Natalia> To subscribers of the xforms list Hello, Natalia> We've been working with fvwm2 window manager and applications Natalia> using xforms library. We need to use windows with Natalia> FL_FULLBORDER and FL_NOBORDER border in the same application Natalia> and with fvwm2 we don't have any problem. Natalia> However, we've decided to use GNOME with sawfish as window Natalia> manager and we've got quite problems showing a window with no Natalia> border and after that another one with full border. The Natalia> second window (with border) stays at the back of the first Natalia> (without border) one and the application doesn't work Natalia> properly. We'd like to know if it's possible to configure Natalia> sawfish to manage that kind of window without problems. We've Natalia> been trying to configurate it using "~/.sawfishrc" file but Natalia> we haven't found a solution. Anybody knows if it's necessary Natalia> to change any attribute to get it? Any other suggestion? Hello Natalia, Did you try to ask about that on a sawfish mailing list? What do the properties (as seen by xprop) of your windows look like? JMarc From viton.1 at osu.edu Thu Apr 22 09:01:05 2004 From: viton.1 at osu.edu (Philip A. Viton) Date: Thu, 22 Apr 2004 10:01:05 -0300 Subject: [XForms] xforms downloads on savannah Message-ID: <6.1.0.6.2.20040422095836.01c6bfb8@localhost> Hi: Are you sure that the xforms files in savannah's Downloads section are OK? I downloaded eg forms.ps.gz and gzip doesn't seem to recognize it as valid. I tried gzip on a file from another source, and it works fine; suggesting that it's not necessarily gzip's problem. (This in under Win2k/cygwin). Regards, ------------------------ Philip A. Viton City Planning, Ohio State University 190 W. 17th Ave,Columbus OH 43210 viton.1 at osu.edu From angus.leeming at btopenworld.com Thu Apr 22 15:06:04 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 22 Apr 2004 20:06:04 +0100 Subject: [XForms] xforms downloads on savannah In-Reply-To: <6.1.0.6.2.20040422095836.01c6bfb8@localhost> References: <6.1.0.6.2.20040422095836.01c6bfb8@localhost> Message-ID: <200404222006.04058.angus.leeming@btopenworld.com> On Thursday 22 April 2004 2:01 pm, Philip A. Viton wrote: > Hi: > > Are you sure that the xforms files in savannah's Downloads section > are OK? I downloaded eg forms.ps.gz and gzip doesn't seem to > recognize it as valid. I tried gzip on a file from another source, > and it works fine; suggesting that it's not necessarily gzip's > problem. (This in under Win2k/cygwin). I've just tried forms.ps.gz and it views fine for me with gs. Perhaps your download was corrupt? Angus From GalbraithP at dfo-mpo.gc.ca Thu Apr 22 15:14:45 2004 From: GalbraithP at dfo-mpo.gc.ca (Peter S Galbraith) Date: Thu, 22 Apr 2004 15:14:45 -0400 Subject: [XForms] xforms downloads on savannah In-Reply-To: Message from "Philip A. Viton" <6.1.0.6.2.20040422095836.01c6bfb8@localhost> References: <6.1.0.6.2.20040422095836.01c6bfb8@localhost> Message-ID: <20040422191446.44C90DA0A3@mixing.qc.dfo.ca> Philip A. Viton wrote: > Are you sure that the xforms files in savannah's Downloads section are OK? > I downloaded eg forms.ps.gz and gzip doesn't seem to recognize it as > valid. I just tried it and gv liked it fine. Try again? Peter From angus.leeming at btopenworld.com Sun May 2 06:01:21 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sun, 2 May 2004 11:01:21 +0100 Subject: [XForms] [patch]: squash valgrind warning about possible memory leak. Message-ID: <200405021101.21521.angus.leeming@btopenworld.com> Jean-Marc, all It seems that the attached patch is needed to make valgrind happy. It looks sensible to me, but I'd value a sanity check. Angus ==8727== 13 bytes in 1 blocks are possibly lost in loss record 11 of 144 ==8727== at 0x32728B: malloc (vg_replace_malloc.c:153) ==8727== by 0x2A0EEE: fl_strdup (strdup.c:44) ==8727== by 0x284F35: get_command_name (flresource.c:693) ==8727== by 0x2850F3: fl_initialize (flresource.c:800) ==8727== by 0x81F17EB: lyx_gui::parse_init(int&, char**) (lyx_gui.C:162) ==8727== by 0x80D9269: LyX::priv_exec(int&, char**) (lyx_main.C:190) ==8727== by 0x80D8F7D: LyX::exec(int&, char**) (scoped_ptr.hpp:94) ==8727== by 0x805408D: main (main.C:42) ==8727== by 0x6C4BBE: __libc_start_main (in /lib/libc-2.3.2.so) ==8727== by 0x8053FB4: (within /home/angus/lyx/devel/build/src/lyx-xforms) -------------- next part -------------- A non-text attachment was scrubbed... Name: flresource.diff Type: text/x-diff Size: 1153 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040502/f970b5ff/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Mon May 3 05:28:31 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 03 May 2004 11:28:31 +0200 Subject: [XForms] [patch]: squash valgrind warning about possible memory leak. In-Reply-To: <200405021101.21521.angus.leeming@btopenworld.com> (Angus Leeming's message of "Sun, 2 May 2004 11:01:21 +0100") References: <200405021101.21521.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, all Angus> It seems that the attached patch is needed to make valgrind Angus> happy. It looks sensible to me, but I'd value a sanity check. Looks reasonable. I did see this report, but did not know what to do about it. JMarc From angus.leeming at btopenworld.com Tue May 4 12:30:59 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 4 May 2004 17:30:59 +0100 Subject: [XForms] Enable FL_FREE objects to optimize their drawing Message-ID: <200405041730.59672.angus.leeming@btopenworld.com> The attached patch passes the associated (XEvent * xev) to fl_handle_object on an FL_DRAW event. This XEvent * is not used at all by any of xforms' "native" widgets, but an FL_FREE object is able to make use of this info to redraw only the part of the window that has changed. An example being the FL_FREE object used by LyX for the main screen. I can see no harm in adding this patch as it does not change existing behaviour at all. Thoughts? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: xforms-redraw.diff Type: text/x-diff Size: 4165 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040504/e1bb529d/attachment.bin From angus.leeming at btopenworld.com Wed May 5 08:09:06 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 13:09:06 +0100 Subject: [XForms] Enable FL_FREE objects to optimize their drawing In-Reply-To: <200405041730.59672.angus.leeming@btopenworld.com> References: <200405041730.59672.angus.leeming@btopenworld.com> Message-ID: <200405051309.06532.angus.leeming@btopenworld.com> On Tuesday 04 May 2004 5:30 pm, Angus Leeming wrote: > The attached patch passes the associated (XEvent * xev) to > fl_handle_object on an FL_DRAW event. This XEvent * is not used at > all by any of xforms' "native" widgets, but an FL_FREE object is > able to make use of this info to redraw only the part of the window > that has changed. > > An example being the FL_FREE object used by LyX for the main > screen. > > I can see no harm in adding this patch as it does not change > existing behaviour at all. Thoughts? Ok, I committed it. Angus From angus.leeming at btopenworld.com Wed May 5 09:23:58 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 14:23:58 +0100 Subject: [XForms] Catching up on patches Message-ID: <200405051423.58780.angus.leeming@btopenworld.com> It seems to me that these mails and patches need to be incorporated in the xforms tree. Have I missed anythiing? Regards, Angus Mike Heffner [XForms] Re: [PATCH] Double clicking doesn't work in file http://bob.usuhs.mil/pipermail/xforms/2003/000163.html [XForms] fl_set_font_name() verbiage http://bob.usuhs.mil/pipermail/xforms/2004/000176.html Dmitry Karasik [XForms] XForms text rendering bug patch http://bob.usuhs.mil/pipermail/xforms/2004/000203.html Jeff [XForms] Redone client callback http://bob.usuhs.mil/pipermail/xforms/2004/000225.html Jeff [XForms] client event sample application http://bob.usuhs.mil/pipermail/xforms/2004/000260.html From msz at astrouw.edu.pl Wed May 5 09:33:50 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 5 May 2004 15:33:50 +0200 Subject: [XForms] Catching up on patches In-Reply-To: <200405051423.58780.angus.leeming@btopenworld.com> References: <200405051423.58780.angus.leeming@btopenworld.com> Message-ID: <20040505133350.GA4071@astrouw.edu.pl> > It seems to me that these mails and patches need to be incorporated in > the xforms tree. Have I missed anythiing? Angus, There was also Clive Stubbings' JPEG/Image patch but maybe it is already in. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From angus.leeming at btopenworld.com Wed May 5 09:43:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 14:43:18 +0100 Subject: [XForms] Catching up on patches In-Reply-To: <20040505133350.GA4071@astrouw.edu.pl> References: <200405051423.58780.angus.leeming@btopenworld.com> <20040505133350.GA4071@astrouw.edu.pl> Message-ID: <200405051443.18746.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 2:33 pm, Michal Szymanski wrote: > > It seems to me that these mails and patches need to be > > incorporated in the xforms tree. Have I missed anythiing? > > Angus, > > There was also Clive Stubbings' JPEG/Image patch but maybe it is > already in. I believe so: http://savannah.nongnu.org/cgi-bin/viewcvs/xforms/xforms/ChangeLog.diff?r1=1.68&r2=1.69 http://savannah.nongnu.org/cgi-bin/viewcvs/xforms/xforms/image/image_gif.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.7&diff_format=h http://savannah.nongnu.org/cgi-bin/viewcvs/xforms/xforms/image/image_jpeg.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.7&diff_format=h Regards, Angus From angus.leeming at btopenworld.com Wed May 5 09:56:31 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 14:56:31 +0100 Subject: [XForms] Re: [PATCH] Double clicking doesn't work in file selectors In-Reply-To: References: Message-ID: <200405051456.31697.angus.leeming@btopenworld.com> On Wednesday 03 December 2003 12:16 am, Mike Heffner wrote: > 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 Mike, many apologies for the delay, but I finally committed this patch. Kind regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fselect.diff Type: text/x-diff Size: 3015 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040505/c7fd5586/attachment.bin From angus.leeming at btopenworld.com Wed May 5 10:01:01 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 15:01:01 +0100 Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: References: Message-ID: <200405051501.01448.angus.leeming@btopenworld.com> On Thursday 15 January 2004 5:30 am, Mike Heffner wrote: > When fl_set_font_name() fails it will return -1 but it also prints: > > In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah > > This function is typically used as a method of testing whether a > font is loadable or not, so it's not always a fatal condition. Can > this print statement be wrapped in a debug-only conditional? Mike does this do the job: - M_err("SetFont", "Bad FontStyle request %d: %s", numb, flf->fname); + M_warn("SetFont", "Bad FontStyle request %d: %s", numb, flf->fname); of are you actually looking for something like this: #if (FL_DEBUG >= ML_DEBUG) M_debug("SetFont", "Bad FontStyle request %d: %s", numb, flf->fname); #endif Angus From angus.leeming at btopenworld.com Wed May 5 10:41:13 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 15:41:13 +0100 Subject: [XForms] XForms text rendering bug patch In-Reply-To: References: <4043115F.9080007@karasik.eu.org> Message-ID: <200405051541.13406.angus.leeming@btopenworld.com> On Tuesday 02 March 2004 2:41 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Dmitry" == Dmitry Karasik writes: > Dmitry> Under certain condition, > Dmitry> input lines do not display any text. The bug, which is > Dmitry> basically comparison of a signed integer as a boolean, is > Dmitry> fixed by the following patch: > Hello, > Thanks for the patch. I think we are suffering from this bug in LyX > in some circumstances, but we never got to fix it. Can you expand further? > Are you sure that your fix is the right one? I do not know this > part of code at all, but the comment before the function says: > /* Major text drawing routine > * clip == 0: no clipping > * clip == 1: do clipping here > * clip == -1: clipping is done outside of this routine > */ > so testing for clip as a boolean means 'if there is some clipping > going on somewhere', which may be a reasonable test. Are you sure > that only the 'do clipping here' case should be handled? Jean-Marc, I've been reading the code. (clip == -1) is used only by the input.c routine draw_input I read this: if (clip && (starty[i] + flx->fdesc) > y + h) continue; as saying "if clipping and if the position of the baseline + the font descent is greater than the bottom of the widget then loop. I also see that this command is the only place in the routine that mentions clip and which does not qualify it with (clip > 0). In fact, all they are used for elsewhere is: if (clip > 0) fl_set_text_clipping(); if (clip > 0) fl_unset_text_clipping(); Conclusion, it's meant and should stay. Angus From angus.leeming at btopenworld.com Wed May 5 10:49:06 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 15:49:06 +0100 Subject: [XForms] Where to change forms.h? In-Reply-To: <407E9C08.1080809@comcast.net> References: <407D54E7.5070607@comcast.net> <200404141621.19008.angus.leeming@btopenworld.com> <407E9C08.1080809@comcast.net> Message-ID: <200405051549.06082.angus.leeming@btopenworld.com> On Thursday 15 April 2004 3:28 pm, Jeff wrote: > To subscribers of the xforms list > I did have an email glitch and I must have missed it. Sorry. > I am getting the patch ready in the next day or two. > > Jeff Jeff, did I miss this patch or is it still a work in progress? Angus > Angus Leeming wrote: > >On Wednesday 14 April 2004 4:12 pm, Jeff wrote: > >>I've asked this problem before, but where do you implement > >> changes for /lib/include/forms.h? > >> > >>It is created during the ./confiigure and make steps. > > > >I answered it before too: > > > >See the files in lib/include. They are concatenated together to > > create forms.h > > > >So, one possible solution would be to create a new file > > client_msg.h and add it to the list of files in > > lib/include/Makefile.am > > > >Angus From angus.leeming at btopenworld.com Wed May 5 11:16:30 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 16:16:30 +0100 Subject: [XForms] The NT directory Message-ID: <200405051616.30029.angus.leeming@btopenworld.com> Jean-Marc, is it good for anything? Doesn't libtool handle Win32 issues? Angus From Jean-Marc.Lasgouttes at inria.fr Wed May 5 11:41:36 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 05 May 2004 17:41:36 +0200 Subject: [XForms] The NT directory In-Reply-To: <200405051616.30029.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 16:16:30 +0100") References: <200405051616.30029.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, is it good for Angus> anything? Doesn't libtool handle Win32 issues? Angus AFAIK it contains visual c++ project files, which are the replacement for our makefiles. I really do not know whether they are still usable, and actually, I believe that they are not. If you look at ftp://ncmir.ucsd.edu/pub/xforms/Attic/NT/, you will find that the version in W32/, which is according to Readme.txt the one that needs this NT/ directory, has not been upgraded after version 0.88.1. Thus one may consider that it is dead and that the cygwin version is good enough. Actually, I guess that making a mingw version would be more useful than this vc++ version. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed May 5 11:50:08 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 05 May 2004 17:50:08 +0200 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <200405051541.13406.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 15:41:13 +0100") References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Tuesday 02 March 2004 2:41 pm, Jean-Marc Lasgouttes wrote: >> >>>>> "Dmitry" == Dmitry Karasik writes: Dmitry> Under certain condition, input lines do not display any text. Dmitry> The bug, which is basically comparison of a signed integer as Dmitry> a boolean, is fixed by the following patch: >> Hello, >> Thanks for the patch. I think we are suffering from this bug in LyX >> in some circumstances, but we never got to fix it. Angus> Can you expand further? I was thinking about bugs like the following: http://www.mail-archive.com/lyx-devel at lists.lyx.org/msg41904.html Angus> I also see that this command is the only place in the routine Angus> that mentions clip and which does not qualify it with (clip > Angus> 0). In fact, all they are used for elsewhere is: Angus> if (clip > 0) fl_set_text_clipping(); Angus> if (clip > 0) fl_unset_text_clipping(); Angus> Conclusion, it's meant and should stay. The it should probably be "if (clip !=0)" to make things clear. JMarc From angus.leeming at btopenworld.com Wed May 5 11:54:27 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 16:54:27 +0100 Subject: [XForms] The NT directory In-Reply-To: References: <200405051616.30029.angus.leeming@btopenworld.com> Message-ID: <200405051654.27959.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 4:41 pm, Jean-Marc Lasgouttes wrote: > Angus> Jean-Marc, is it good for > Angus> anything? Doesn't libtool handle Win32 issues? Angus > > AFAIK it contains visual c++ project files, which are the > replacement for our makefiles. > > I really do not know whether they are still usable, and actually, I > believe that they are not. > > If you look at ftp://ncmir.ucsd.edu/pub/xforms/Attic/NT/, you will > find that the version in W32/, which is according to Readme.txt the > one that needs this NT/ directory, has not been upgraded after > version 0.88.1. Thus one may consider that it is dead and that the > cygwin version is good enough. Actually, I guess that making a > mingw version would be more useful than this vc++ version. In that case I'll put these in the Attic too. Angus From angus.leeming at btopenworld.com Wed May 5 12:03:30 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 17:03:30 +0100 Subject: [XForms] XForms text rendering bug patch In-Reply-To: References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> Message-ID: <200405051703.30709.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 4:50 pm, Jean-Marc Lasgouttes wrote: > >> Thanks for the patch. I think we are suffering from this bug in > >> LyX in some circumstances, but we never got to fix it. > > Angus> Can you expand further? > > I was thinking about bugs like the following: > http://www.mail-archive.com/lyx-devel at lists.lyx.org/msg41904.html Ouch! Incidentally, how do you remember stuff like this? > Angus> I also see that this command is the only place in the > routine Angus> that mentions clip and which does not qualify it > with (clip > Angus> 0). In fact, all they are used for elsewhere > is: > > Angus> if (clip > 0) fl_set_text_clipping(); > > Angus> if (clip > 0) fl_unset_text_clipping(); > > Angus> Conclusion, it's meant and should stay. > > The it should probably be "if (clip !=0)" to make things clear. I'll do that now. Angus From angus.leeming at btopenworld.com Wed May 5 12:08:24 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 17:08:24 +0100 Subject: [XForms] XForms text rendering bug patch In-Reply-To: References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> Message-ID: <200405051708.24812.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 4:50 pm, Jean-Marc Lasgouttes wrote: > I was thinking about bugs like the following: > http://www.mail-archive.com/lyx-devel at lists.lyx.org/msg41904.html Actually, wouldn't this bug be fixed by changing this: /* Check whether visible */ if (clip != 0 && (starty[i] + flx->fdesc) > y + h) continue; to this: /* Check whether visible */ if (clip != 0 && starty[i] > y + h) continue; Ie, draw this line of text even if it extends beyond the widget and then rely on XSetClipRectangles to do its stuff. Angus From Jean-Marc.Lasgouttes at inria.fr Wed May 5 12:28:41 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 05 May 2004 18:28:41 +0200 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <200405051703.30709.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 17:03:30 +0100") References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> <200405051703.30709.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Ouch! Incidentally, how do you remember stuff like this? Well, I have over 300 messages in my lyx-devel folder, and the oldest is from May 2000. From time to time, I go over the mailbox and see what bugs are still relevant. This one was a bug that I did not know how to solve, but that I wanted to remember about. JMarc From Jean-Marc.Lasgouttes at inria.fr Wed May 5 12:30:29 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 05 May 2004 18:30:29 +0200 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <200405051708.24812.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 17:08:24 +0100") References: <4043115F.9080007@karasik.eu.org> <200405051541.13406.angus.leeming@btopenworld.com> <200405051708.24812.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Angus> On Wednesday 05 May 2004 4:50 pm, Jean-Marc Lasgouttes wrote: >> I was thinking about bugs like the following: >> http://www.mail-archive.com/lyx-devel at lists.lyx.org/msg41904.html Angus> Actually, wouldn't this bug be fixed by changing this: Angus> /* Check whether visible */ Angus> if (clip != 0 && (starty[i] + flx->fdesc) > y + h) continue; Angus> to this: Angus> /* Check whether visible */ Angus> if (clip != 0 && starty[i] > y + h) continue; Angus> Ie, draw this line of text even if it extends beyond the widget Angus> and then rely on XSetClipRectangles to do its stuff. It seems reasonable. Do we have a way to check that it does what we think it does? JMarc From Jean-Marc.Lasgouttes at inria.fr Wed May 5 12:30:53 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 05 May 2004 18:30:53 +0200 Subject: [XForms] Catching up on patches In-Reply-To: <200405051423.58780.angus.leeming@btopenworld.com> (Angus Leeming's message of "Wed, 5 May 2004 14:23:58 +0100") References: <200405051423.58780.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list It seems to me that these Angus> mails and patches need to be incorporated in the xforms tree. Angus> Have I missed anythiing? Your slider patch maybe? JMarc From angus.leeming at btopenworld.com Wed May 5 12:46:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 17:46:18 +0100 Subject: [XForms] XForms text rendering bug patch In-Reply-To: References: <4043115F.9080007@karasik.eu.org> <200405051708.24812.angus.leeming@btopenworld.com> Message-ID: <200405051746.18902.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 5:30 pm, Jean-Marc Lasgouttes wrote: > Angus> Actually, wouldn't this bug be fixed by changing this: > > Angus> /* Check whether visible */ > Angus> if (clip != 0 && (starty[i] + flx->fdesc) > y + h) > continue; > > Angus> to this: > > Angus> /* Check whether visible */ > Angus> if (clip != 0 && starty[i] > y + h) continue; > > Angus> Ie, draw this line of text even if it extends beyond the > widget Angus> and then rely on XSetClipRectangles to do its stuff. > > It seems reasonable. Do we have a way to check that it does what we > think it does? Here's the (correct) patch and a test case that works as expected with it and displays nothing without it. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: text.diff Type: text/x-diff Size: 651 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040505/e6cfca40/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: input_test.C Type: text/x-c++src Size: 921 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040505/e6cfca40/attachment-0001.bin From angus.leeming at btopenworld.com Wed May 5 13:04:28 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 18:04:28 +0100 Subject: [XForms] XForms text rendering bug patch In-Reply-To: <4043115F.9080007@karasik.eu.org> References: <4043115F.9080007@karasik.eu.org> Message-ID: <200405051804.28169.angus.leeming@btopenworld.com> On Monday 01 March 2004 10:33 am, Dmitry Karasik wrote: > To subscribers of the xforms list > > > Under certain condition, input lines do not display any text. > The bug, which is basically comparison of a signed integer as a > boolean, is fixed by the following patch: Hi, Dmitry. I don't think that your patch is correct. Instead I propose the one attached. Could you try it out and report back whether it works for you? Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: text.diff Type: text/x-diff Size: 651 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040505/3ea8fcb4/attachment.bin From angus.leeming at btopenworld.com Wed May 5 13:40:50 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 18:40:50 +0100 Subject: [XForms] Catching up on patches In-Reply-To: References: <200405051423.58780.angus.leeming@btopenworld.com> Message-ID: <200405051840.50791.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 5:30 pm, Jean-Marc Lasgouttes wrote: > Angus> It seems to me that these > Angus> mails and patches need to be incorporated in the xforms > tree. Angus> Have I missed anythiing? > > Your slider patch maybe? Yes, of course. I've just tried it out with lyx. Works beautifully on this 2.66GHz machine. Still, the trouble with a counter is that eventually, the patch will have to be patched to enable it to be usable on tomorrows 266GHz machine. What do you think? Angus From angus.leeming at btopenworld.com Wed May 5 14:30:08 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 19:30:08 +0100 Subject: [XForms] Catching up on patches In-Reply-To: <200405051840.50791.angus.leeming@btopenworld.com> References: <200405051423.58780.angus.leeming@btopenworld.com> <200405051840.50791.angus.leeming@btopenworld.com> Message-ID: <200405051930.08967.angus.leeming@btopenworld.com> On Wednesday 05 May 2004 6:40 pm, Angus Leeming wrote: > On Wednesday 05 May 2004 5:30 pm, Jean-Marc Lasgouttes wrote: > > Angus> It seems to me that these > > Angus> mails and patches need to be incorporated in the xforms > > tree. Angus> Have I missed anythiing? > > > > Your slider patch maybe? > > Yes, of course. I've just tried it out with lyx. Works beautifully > on this 2.66GHz machine. Still, the trouble with a counter is that > eventually, the patch will have to be patched to enable it to be > usable on tomorrows 266GHz machine. > > What do you think? > Angus To give you something to base your thoughts on, here are two patches. slider_v1.diff is the counter version and slider_v2.diff is the timeout version. Personally, I prefer the timeout version, with the proviso that it needs void fl_set_slider_timeout(int millisecs); int fl_get_slider_timeout(); The same technique can be used for the counters class. Thoughts? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: slider_v1.diff Type: text/x-diff Size: 1228 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040505/3dda1d04/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: slider_v2.diff Type: text/x-diff Size: 1679 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040505/3dda1d04/attachment-0001.bin From angus.leeming at btopenworld.com Wed May 5 16:43:55 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 5 May 2004 21:43:55 +0100 Subject: [XForms] An improved slider patch Message-ID: <200405052143.55156.angus.leeming@btopenworld.com> * uses a timeout to trigger the repeat (as did slider_v2.diff) * the repeat interval is configurable, through new functions: /** Functions to set and get the timeout value used by the slider code to increment the position of the knob. */ FL_EXPORT int fl_get_slider_repeat(FL_OBJECT *ob ); FL_EXPORT void fl_set_slider_repeat(FL_OBJECT *ob, int millisec); * slider behaviour is configurable on a per-slider basis. No changes to any publicly-visible structs, so the library remains binary compatible with version 1.0. Suggestions and improvements are, of course, welcome, but if no one objects, I'll commit this. The counter code can be refactored in similar fashion also. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: slider_v3.diff Type: text/x-diff Size: 4479 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040505/37716ef0/attachment.bin From mheffner at vt.edu Wed May 5 18:12:15 2004 From: mheffner at vt.edu (Mike Heffner) Date: Wed, 05 May 2004 18:12:15 -0400 (EDT) Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: <200405051501.01448.angus.leeming@btopenworld.com> Message-ID: On 05-May-2004 Angus Leeming wrote: | On Thursday 15 January 2004 5:30 am, Mike Heffner wrote: |> When fl_set_font_name() fails it will return -1 but it also prints: |> |> In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah |> |> This function is typically used as a method of testing whether a |> font is loadable or not, so it's not always a fatal condition. Can |> this print statement be wrapped in a debug-only conditional? | | Mike does this do the job: | - M_err("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); | + M_warn("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); | | of are you actually looking for something like this: |#if (FL_DEBUG >= ML_DEBUG) | M_debug("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); |#endif | Whichever would prevent it from being displayed if libforms is not compiled in debug mode. When is M_warn() printed? Mike -- Mike Heffner From angus.leeming at btopenworld.com Thu May 6 06:05:57 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 11:05:57 +0100 Subject: [XForms] Committed patch Message-ID: <200405061105.57973.angus.leeming@btopenworld.com> FYI Enable input widgets to (partially) display characters larger than the input height. Jean-Marc, I guess that you can remove that bug report from your inbox. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: text.diff Type: text/x-diff Size: 1803 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040506/ef5becf6/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Thu May 6 06:23:07 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 06 May 2004 12:23:07 +0200 Subject: [XForms] Committed patch In-Reply-To: <200405061105.57973.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 6 May 2004 11:05:57 +0100") References: <200405061105.57973.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list FYI Angus> Enable input widgets to (partially) display characters larger Angus> than the input height. Angus> Jean-Marc, I guess that you can remove that bug report from Angus> your inbox. Thanks :) JMarc From angus.leeming at btopenworld.com Thu May 6 07:55:04 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 12:55:04 +0100 Subject: [XForms] Committed patch Message-ID: <200405061255.04611.angus.leeming@btopenworld.com> FYI Building of rpms works again. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: rpm.diff Type: text/x-diff Size: 2354 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040506/9a65fd1e/attachment.bin From angus.leeming at btopenworld.com Thu May 6 09:46:41 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 14:46:41 +0100 Subject: [XForms] rpms are not quite right Message-ID: <200405061446.41297.angus.leeming@btopenworld.com> Jean-Marc, all, Executive summary: how do we get rpm to install the symbolic links libforms.so and libforms.so.1 that are to point at libforms.so.1.0.0? Is this a libtool issue? Detailed description of what I've done. I've built the xforms rpms (as non-root) by 1. creating a file .rpmmacros: $ cat ~/.rpmmacros %_topdir /home/angus/rpm 2. generating the necessary subdirectories of ~/rpm $ mkdir ~/rpm $ cd ~/rpm $ mkdir -p RPMS/i386 RPMS/noarch SRPMS SOURCES BUILD SPECS Thereafter I can build the rpms as non-root with $ cd ~/xforms/cvs/build $ make rpmdist The rpms are generated as expected: $ cd ~/rpm/RPMS/i386/ $ ls xforms-1.0.90-1rh8x.i386.rpm xforms-devel-1.0.90-1rh8x.i386.rpm xforms-debuginfo-1.0.90-1rh8x.i386.rpm Two questions: a. Any idea what this last one is??? b. The names are incorrect. I'm building on a fedora core 1 machine so that 'rh8x' is incorrect. Is there a way to specify this portably in the xforms.spec.in file or must it be hard coded? Thereafter, as root, I install in /usr/local: # rpm -Uvh --prefix /usr/local xforms-1.0.90-1rh8x.i386.rpm Preparing... ############################# [100%] 1:xforms ############################# [100%] # rpm -Uvh --prefix /usr/local xforms-devel-1.0.90-1rh8x.i386.rpm Preparing... ############################# [100%] 1:xforms-devel ########################### [100%] Everything appears to be OK: # ls -l /usr/local/bin/f* -rwxr-xr-x 1 root root 81916 May 6 14:33 /usr/local/bin/fd2ps -rwxr-xr-x 1 root root 221920 May 6 14:33 /usr/local/bin/fdesign # ls -l /usr/local/include total 160 -rw-r--r-- 1 root root 24582 May 6 14:33 flimage.h -rw-r--r-- 1 root root 123575 May 6 14:33 forms.h -rw-r--r-- 1 root root 1129 May 6 14:33 glcanvas.h # ls -l /usr/local/lib total 1540 -rw-r--r-- 1 root root 254026 May 6 14:33 libflimage.a -rwxr-xr-x 1 root root 729 May 6 14:33 libflimage.la -rwxr-xr-x 1 root root 190856 May 6 14:33 libflimage.so.1.0.0 -rw-r--r-- 1 root root 637862 May 6 14:33 libforms.a -rw-r--r-- 1 root root 4692 May 6 14:33 libformsGL.a -rwxr-xr-x 1 root root 729 May 6 14:33 libformsGL.la -rwxr-xr-x 1 root root 7204 May 6 14:33 libformsGL.so.1.0.0 -rwxr-xr-x 1 root root 715 May 6 14:33 libforms.la -rwxr-xr-x 1 root root 435300 May 6 14:33 libforms.so.1.0.0 However, note that there are no libforms.so, libforms.so.1, etc symbolic links. Just the libforms.so.1.0.0 There absence means that fdesign and fd2ps are not executable: # ldd /usr/local/bin/fdesign libforms.so.1 => not found libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00cc2000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x00e1f000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x00c43000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00437000) libc.so.6 => /lib/tls/libc.so.6 (0x005c1000) libm.so.6 => /lib/tls/libm.so.6 (0x00799000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00a48000) libdl.so.2 => /lib/libdl.so.2 (0x0082a000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00325000) How to rectify the situation? Angus From Jean-Marc.Lasgouttes at inria.fr Thu May 6 10:13:04 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 06 May 2004 16:13:04 +0200 Subject: [XForms] rpms are not quite right In-Reply-To: <200405061446.41297.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 6 May 2004 14:46:41 +0100") References: <200405061446.41297.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, all, Angus> Executive summary: how do we get rpm to install the symbolic Angus> links libforms.so and libforms.so.1 that are to point at Angus> libforms.so.1.0.0? Is this a libtool issue? Does libtool do that correctly when you do a 'make install'? It may be that you have to do that yourself in a postinstall phase. You may want to look at the rpm spec file of another existing library. Angus> Two questions: a. Any idea what this last one is??? I guess it is a version where debug infomation has not been stripped. This would only make sense when building without --disable-debug, I guess. Angus> b. The names are incorrect. I'm building on a fedora core 1 Angus> machine so that 'rh8x' is incorrect. Is there a way to specify Angus> this portably in the xforms.spec.in file or must it be hard Angus> coded? The rh8x comes from this thing at the top: Release: 1rh8x Just replace it with '1'. We do not have any reason to generate versions that are specific to some distributions, I think. BTW, the line just below is wrong, since the downloads have changed place. Source0: http://savannah.nongnu.org/download/xforms/stable.pkg/1.0/%{name}-%{version}.tar.gz JMarc From angus.leeming at btopenworld.com Thu May 6 10:18:06 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 15:18:06 +0100 Subject: [XForms] rpms are not quite right In-Reply-To: References: <200405061446.41297.angus.leeming@btopenworld.com> Message-ID: <200405061518.06646.angus.leeming@btopenworld.com> On Thursday 06 May 2004 3:13 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming writes: > > Angus> To subscribers of the xforms list Jean-Marc, all, > > Angus> Executive summary: how do we get rpm to install the symbolic > Angus> links libforms.so and libforms.so.1 that are to point at > Angus> libforms.so.1.0.0? Is this a libtool issue? > > Does libtool do that correctly when you do a 'make install'? Yes. As usual, you've nailed down the problem. 'make install' works perfectly. What fails is: allfiles=`find ${RPM_BUILD_ROOT}/usr -type f -print | sed "s@^${RPM_BUILD_ROOT}@@g"` 'find' does not pick up the symbolic links. Indeed, it shouldn't. > It may be that you have to do that yourself in a postinstall phase. > You may want to look at the rpm spec file of another existing library. Thanks ;-) > The rh8x comes from this thing at the top: > Release: 1rh8x > > Just replace it with '1'. We do not have any reason to generate > versions that are specific to some distributions, I think. Good. > BTW, the line just below is wrong, since the downloads have changed place. > > Source0: > http://savannah.nongnu.org/download/xforms/stable.pkg/1.0/%{name}-%{version >}.tar.gz Ok. I'll fix that too. Angus From angus.leeming at btopenworld.com Thu May 6 11:47:54 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 16:47:54 +0100 Subject: [XForms] rpms are not quite right In-Reply-To: <200405061518.06646.angus.leeming@btopenworld.com> References: <200405061446.41297.angus.leeming@btopenworld.com> <200405061518.06646.angus.leeming@btopenworld.com> Message-ID: <200405061647.54808.angus.leeming@btopenworld.com> On Thursday 06 May 2004 3:18 pm, Angus Leeming wrote: > On Thursday 06 May 2004 3:13 pm, Jean-Marc Lasgouttes wrote: > > It may be that you have to do that yourself in a postinstall phase. > > You may want to look at the rpm spec file of another existing library. > > Thanks ;-) Ok, Jean-Marc. The attached patch *almost* does the right thing. # rpm -Uvh --prefix /home/angus/test /home/angus/rpm/RPMS/i386/xforms-1.0.90-1.i386.rpm Preparing... ########################################### [100%] 1:xforms ########################################### [100%] Executing post installation ln -sf /home/angus/test/lib/libforms.so.1.0.90 /home/angus/test/lib/libforms.so ln -sf /home/angus/test/lib/libforms.so.1.0.90 /home/angus/test/lib/libforms.so.1 ln -sf /home/angus/test/lib/libformsGL.so.1.0.90 /home/angus/test/lib/libformsGL.so ln -sf /home/angus/test/lib/libformsGL.so.1.0.90 /home/angus/test/lib/libformsGL.so.1 ln -sf /home/angus/test/lib/libflimage.so.1.0.90 /home/angus/test/lib/libflimage.so ln -sf /home/angus/test/lib/libflimage.so.1.0.90 /home/angus/test/lib/libflimage.so.1 # rpm -e xforms Executing post uninstallation rm -f /home/angus/test/lib/libforms.so /home/angus/test/lib/libforms.so.1 rm -f /home/angus/test/lib/libformsGL.so /home/angus/test/lib/libformsGL.so.1 rm -f /home/angus/test/lib/libflimage.so /home/angus/test/lib/libflimage.so.1 Note, however, that we should be linking against 1.0.0 files not 1.0.90 ones. I remember our discussions some time ago about the meaning of these version numbers in the .so files and why they should be different to those of the package version. The .so version numbers are defined in lib/Makefile.am. However, it looks to me as if we need a new variable in configure.ac, say SO_VERSION, which will be substituted at compile time for '1:0:0'. lib/Makefile.am would contain the line: libforms_la_LDFLAGS = -version-info @SO_VERSION@ and xforms.spec.in would contain the line SO_VERSION=@SO_VERSION@ Thereafter, it's just a case of straightforward manipulation. Thoughts? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: xforms.spec.in.diff Type: text/x-diff Size: 1796 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040506/f517b2e1/attachment.bin From angus.leeming at btopenworld.com Thu May 6 12:55:46 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 17:55:46 +0100 Subject: [XForms] Trying to get a handle on libtool's versioning system Message-ID: <200405061755.46491.angus.leeming@btopenworld.com> As usual, I'm less than sure of myself ;-) When xforms 1.0 was released, the libtool versioning was set to '1:0:0', a flag of the form 'current:revision:age' where 'age' must be less than or equal to the 'current' interface number. >From the libtool manual: Here are a set of rules to help you update your library version information: 1. Start with version information of `0:0:0' for each libtool library. 2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 3. If the library source code has changed at all since the last update, then increment revision (`c:r:a' becomes `c:r+1:a'). 4. If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0. 5. If any interfaces have been added since the last public release, then increment age. 6. If any interfaces have been removed since the last public release, then set age to 0. My take on this: * We're approaching a public release, so it's time to update the version info. (Rule 2.) * The source code has changed since the last update. (Rule 3.) r==1 --> '1:1:0' * Rule 4 applies. Interfaces have been added. c==2, r==0 --> '2:0:0' * Rule 5 applies. Interfaces hace been added. a==1 --> '2:0:1' * Rule 6 does not apply. No interfaces have been removed. Conclusion, the libtool version info is '2:0:1'. Does this look correct? Angus From angus.leeming at btopenworld.com Thu May 6 13:10:23 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 18:10:23 +0100 Subject: [XForms] [patch] rpm spec file Message-ID: <200405061810.23953.angus.leeming@btopenworld.com> I believe that this 'does the right thing'. It creates symbolic links libforms.so and libforms.so.1 to libforms.so.1.0.0 when the rpm is installed and removes these links if the rpm is uninstalled. '1:0:0' is the libtool version of the shared libraries. This version info is used in two places, lib/Makefile.am and in xforms.spec.in, so I've moved it to configure.ac. Only one thing to keep up to date. Feedback is, of course, welcome. Else I'll commit tomorrow. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: spec.diff Type: text/x-diff Size: 4172 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040506/4a9f18fd/attachment.bin From angus.leeming at btopenworld.com Thu May 6 13:16:21 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 18:16:21 +0100 Subject: [XForms] [patch] sliders and counters Message-ID: <200405061816.21372.angus.leeming@btopenworld.com> The patch attached uses a timeout to control the rate at which the slider/counter is incremented. This replaces the current strategy which used a simple counter loop and which has become unusable with today's fast processors. The timeout is configurable on a per-slider/counter basis using the new accessor functions int fl_get_counter_repeat(FL_OBJECT * ob); void fl_set_counter_repeat(FL_OBJECT * ob, int millisec); int fl_get_slider_repeat(FL_OBJECT *ob); void fl_set_slider_repeat(FL_OBJECT *ob, int millisec); Once again, feedback is, of course, welcome. Else I'll commit tomorrow. I think that's all patches in the queue now dealt with. Waiting on Jeff and his 'client callback' patch. Other than that, all systems should be go. What else is needed for the 1.1 release? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: slider_counter.diff Type: text/x-diff Size: 8133 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040506/8b3d61c5/attachment.bin From angus.leeming at btopenworld.com Thu May 6 13:55:09 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 6 May 2004 18:55:09 +0100 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <200405061755.46491.angus.leeming@btopenworld.com> References: <200405061755.46491.angus.leeming@btopenworld.com> Message-ID: <200405061855.09049.angus.leeming@btopenworld.com> On Thursday 06 May 2004 5:55 pm, Angus Leeming wrote: > Conclusion, the libtool version info is '2:0:1'. I find that the explanation of the system is much clearer here: http://sources.redhat.com/autobook/autobook/autobook_91.html Using this source, I get a version-info of '2:0:1' again, meaning that the interface is a superset of that of the previous, '1:0:0', public release and that programs compiled against '1:0:0' will link successfully against '2:0:1'. Full explanation below. Angus All Libtool libraries start with `-version-info' set to `0:0:0' -- this will be the default version number if you don't explicitly set it on the Libtool link command line. The meaning of these numbers (from left to right) is as follows: current The number of the current interface exported by the library. A current value of `0', means that you are calling the interface exported by this library interface 0. revision The implementation number of the most recent interface exported by this library. In this case, a revision value of `0' means that this is the first implementation of the interface. If the next release of this library exports the same interface, but has a different implementation (perhaps some bugs have been fixed), the revision number will be higher, but current number will be the same. In that case, when given a choice, the library with the highest revision will always be used by the runtime loader. age The number of previous additional interfaces supported by this library. If age were `2', then this library can be linked into executables which were built with a release of this library that exported the current interface number, current, or any of the previous two interfaces. By definition age must be less than or equal to current. At the outset, only the first ever interface is implemented, so age can only be `0'. For later releases of a library, the `-version-info' argument needs to be set correctly depending on any interface changes you have made. This is quite straightforward when you understand what the three numbers mean: 1. If you have changed any of the sources for this library, the revision number must be incremented. This is a new revision of the current interface. Yes -> version-info == 1:1:0 2. If the interface has changed, then current must be incremented, and revision reset to `0'. This is the first revision of a new interface. Yes -> version-info == 2:0:0 3. If the new interface is a superset of the previous interface (that is, if the previous interface has not been broken by the changes in this new release), then age must be incremented. This release is backwards compatible with the previous release. Yes -> version-info == 2:0:1 4. If the new interface has removed elements with respect to the previous interface, then you have broken backward compatibility and age must be reset to `0'. This release has a new, but backwards incompatible interface. No. version-info unchanged. From Todd.Denniston at ssa.crane.navy.mil Thu May 6 19:23:16 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Thu, 06 May 2004 18:23:16 -0500 Subject: [XForms] Trying to get a handle on libtool's versioning system References: <200405061755.46491.angus.leeming@btopenworld.com> Message-ID: <409AC8E4.4357E80D@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > As usual, I'm less than sure of myself ;-) > > When xforms 1.0 was released, the libtool versioning was set to > '1:0:0', a flag of the form 'current:revision:age' where 'age' must > be less than or equal to the 'current' interface number. > > >From the libtool manual: unfortunately the archive does not go back to december of 1999 but the lestif guy's were having fun with the libtool versions too. https://terror.hungry.com/pipermail/lesstif/ http://www.lesstif.org/ but the cvs repo goes back that far you might look at the libtool changes from 1999-05-10 to 2000-08-22 and especially 1999-10-23. http://www.lesstif.org/cvs.html :pserver:anonymous at cvs.lesstif.sourceforge.net:/cvsroot/lesstif perhaps their trials might help you. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From angus.leeming at btopenworld.com Fri May 7 04:34:00 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 7 May 2004 09:34:00 +0100 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <409AC8E4.4357E80D@ssa.crane.navy.mil> References: <200405061755.46491.angus.leeming@btopenworld.com> <409AC8E4.4357E80D@ssa.crane.navy.mil> Message-ID: <200405070934.00340.angus.leeming@btopenworld.com> On Friday 07 May 2004 12:23 am, Todd Denniston wrote: > unfortunately the archive does not go back to december of 1999 > but the lestif guy's were having fun with the libtool versions too. Interesting. However, could you help me out a little more? Specifically, which files should I be looking at? Regards, Angus ps, I'm away for the w/e so any silence is merely abscence ;-) From angus.leeming at btopenworld.com Fri May 7 04:41:21 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 7 May 2004 09:41:21 +0100 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <200405070934.00340.angus.leeming@btopenworld.com> References: <200405061755.46491.angus.leeming@btopenworld.com> <409AC8E4.4357E80D@ssa.crane.navy.mil> <200405070934.00340.angus.leeming@btopenworld.com> Message-ID: <200405070941.21232.angus.leeming@btopenworld.com> On Friday 07 May 2004 9:34 am, Angus Leeming wrote: > ps, I'm away for the w/e so any silence is merely abscence ;-) I must try harder to spell correctly. Absence, absence, absence, absence, ... Mea culpa, A From angus.leeming at btopenworld.com Fri May 7 04:50:03 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 7 May 2004 09:50:03 +0100 Subject: [XForms] [patch] sliders and counters In-Reply-To: <200405061816.21372.angus.leeming@btopenworld.com> References: <200405061816.21372.angus.leeming@btopenworld.com> Message-ID: <200405070950.03505.angus.leeming@btopenworld.com> On Thursday 06 May 2004 6:16 pm, Angus Leeming wrote: > Once again, feedback is, of course, welcome. Else I'll commit > tomorrow. I've now done so. Both the slider/counter patch and the rpm spec file patch are now in cvs. Angus > I think that's all patches in the queue now dealt with. Waiting on > Jeff and his 'client callback' patch. Other than that, all systems > should be go. > > What else is needed for the 1.1 release? > Angus From xyzzy at speakeasy.org Fri May 7 05:53:17 2004 From: xyzzy at speakeasy.org (Trent Piepho) Date: Fri, 7 May 2004 02:53:17 -0700 (PDT) Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <200405070934.00340.angus.leeming@btopenworld.com> Message-ID: On Fri, 7 May 2004, Angus Leeming wrote: > On Friday 07 May 2004 12:23 am, Todd Denniston wrote: > > unfortunately the archive does not go back to december of 1999 > > but the lestif guy's were having fun with the libtool versions too. I missed the beginning and point of this thread, but I'm going to go out on a limb and guess what you're trying to do. I created a libtool verion of the Makefile for netcdf, which uses a normal verion number scheme, major.minor.patchlevel, just like pretty much everything does. libtool uses a different and unique version number system, mapped into the normal major.minor.patch system that the dynamic linker uses. I decided that rather than use the libtool system, I'd just have normal version numbers. So I did this in the Makefile: $(LIBRARY): $(LIB_OBJS) major=`cut -d. -f1 ../VERSION` && \ minor=`cut -d. -f2 ../VERSION` && \ rev=`cut -d. -f3 ../VERSION` && \ libtoolver=`expr $$major + $$minor` && \ $(LINK.c) $(LIB_OBJS) \ -rpath $(LIBDIR) -version-info $$libtoolver:$$rev:$$minor VERSION is a file that was part of the normal build process, and would just have the text "3.5.0" in it. This will get libtool to create a shared object libnetcdf.so-3.5.0, like you would expect. If you're trying to create a libforms shared object with a normal version number, maybe this will help? From angus.leeming at btopenworld.com Fri May 7 06:33:51 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 7 May 2004 11:33:51 +0100 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: References: Message-ID: <200405071133.51019.angus.leeming@btopenworld.com> On Friday 07 May 2004 10:53 am, Trent Piepho wrote: > To subscribers of the xforms list > > On Fri, 7 May 2004, Angus Leeming wrote: > > On Friday 07 May 2004 12:23 am, Todd Denniston wrote: > > > unfortunately the archive does not go back to december of 1999 > > > but the lestif guy's were having fun with the libtool versions > > > too. > > I missed the beginning and point of this thread, but I'm going to > go out on a limb and guess what you're trying to do. Thanks, Trent. Whilst I understand why you're doing what you're doing, I'm going to try and stick with the libtool scheme. At least until I've got a handle on lesstif's experience ;-) Regards, Angus From angus.leeming at btopenworld.com Fri May 7 07:04:59 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 7 May 2004 12:04:59 +0100 Subject: [XForms] One more piece of rpm magic needed Message-ID: <200405071204.59432.angus.leeming@btopenworld.com> This is just a heads up before I disappear for the w/e. Linking LyX against the XForms libraries installed from an rpm with: rpm -Uvh --prefix /usr/local xforms-1.0.90-1.i386.rpm I get the following warnings: libtool: link: warning: library `/usr/local/lib/libflimage.la' was moved. libtool: link: warning: library `/usr/local/lib/libforms.la' was moved. All because libflimage.la etc end with # Directory that this library needs to be installed in: libdir='/usr/lib' So I guess one more piece of post install magic is needed. I guess it's as simple as sed "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" Angus From Jean-Marc.Lasgouttes at inria.fr Fri May 7 08:47:55 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 07 May 2004 14:47:55 +0200 Subject: [XForms] One more piece of rpm magic needed In-Reply-To: <200405071204.59432.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 7 May 2004 12:04:59 +0100") References: <200405071204.59432.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> So I guess one more piece of post install magic is needed. Angus> I guess it's as simple as sed Angus> "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" Except that you can't use a slash as sed delimiter here, of course. JMarc From angus.leeming at btopenworld.com Fri May 7 08:51:44 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 7 May 2004 13:51:44 +0100 Subject: [XForms] One more piece of rpm magic needed In-Reply-To: References: <200405071204.59432.angus.leeming@btopenworld.com> Message-ID: <200405071351.44809.angus.leeming@btopenworld.com> On Friday 07 May 2004 1:47 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> So I guess one more piece of post install magic is needed. > > Angus> I guess it's as simple as sed > Angus> "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" > > Except that you can't use a slash as sed delimiter here, of course. Ahhhh, but I can. Patch attached works perfectly. Indeed the above is the *best* way to do things IMO. (The identifying regex before the s/// block *must* be bounded by '/'. The s@@@ is find.) (A rather smug) Angus (who really is off for the w/e NOW. -------------- next part -------------- A non-text attachment was scrubbed... Name: spec.diff Type: text/x-diff Size: 1985 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040507/512ecdd3/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Fri May 7 08:59:34 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 07 May 2004 14:59:34 +0200 Subject: [XForms] [patch] sliders and counters In-Reply-To: <200405061816.21372.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 6 May 2004 18:16:21 +0100") References: <200405061816.21372.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> What else is needed for the 1.1 release? I am currently trying to play around with xpopup.c to fix two problems: 1/ if you open a menu in LyX and then a submenu and then click on another submenu of the same level the first menu stays on screen. OK, I explain: in LyX, do File>New, and then click on Insert>Math and then Inset>Special Character. The result is that you have both submenus shown. I think the problem is that there should be some redraw event taking place, but that it does not happen. I tried to reproduce this with demos/popup or demos/pup, but nothing happens there. The problem does not occur on screen that honor backing store (as reported by xdpyinfo), but it seems that modern linux distributions ship an XFree86 that does not do backing store. So probably this is only a LyX bug. How can I debug this? 2/ There is an annoying behaviour of the LyX menus that mean that if you click on File, and then on Edit, the file menu will not close itself. The reason is the code in xpopup.c:is_on_title, which assumes that one has to click beyong the first 2 thirds of the menu (horizontally speaking) in order to get the menu to go away. I tried to remove this extra code, but all I get now is that menus are closed when one releases the mouse on the File menu (like macos used to do). I am not sure people will like this. Of course, none of these things are primordial for xforms 1.1. Anyway From Jean-Marc.Lasgouttes at inria.fr Fri May 7 09:05:02 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 07 May 2004 15:05:02 +0200 Subject: [XForms] One more piece of rpm magic needed In-Reply-To: <200405071351.44809.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 7 May 2004 13:51:44 +0100") References: <200405071204.59432.angus.leeming@btopenworld.com> <200405071351.44809.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Friday 07 May 2004 1:47 pm, Jean-Marc Lasgouttes wrote: >> >>>>> "Angus" == Angus Leeming >> >>>>> writes: >> Angus> So I guess one more piece of post install magic is needed. >> Angus> I guess it's as simple as sed Angus> "/^libdir=/s@/usr@${RPM_INSTALL_PREFIX}@" >> Except that you can't use a slash as sed delimiter here, of >> course. Angus> Ahhhh, but I can. Patch attached works perfectly. Indeed the Angus> above is the *best* way to do things IMO. Angus> (The identifying regex before the s/// block *must* be bounded Angus> by '/'. The s@@@ is find.) Hmm, OK, I give up you. You won this time, but beware of my next attempt... BTW, thanks for this flurry of activity on the xforms front. It seems that it is actually going to be released now :) JMarc From Todd.Denniston at ssa.crane.navy.mil Fri May 7 11:14:30 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Fri, 07 May 2004 10:14:30 -0500 Subject: [XForms] Trying to get a handle on libtool's versioning system References: <200405071133.51019.angus.leeming@btopenworld.com> Message-ID: <409BA7D6.FDA153C2@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > On Friday 07 May 2004 10:53 am, Trent Piepho wrote: > > To subscribers of the xforms list > > > > On Fri, 7 May 2004, Angus Leeming wrote: > > > On Friday 07 May 2004 12:23 am, Todd Denniston wrote: > > > > unfortunately the archive does not go back to december of 1999 > > > > but the lestif guy's were having fun with the libtool versions > > > > too. > > > > I missed the beginning and point of this thread, but I'm going to > > go out on a limb and guess what you're trying to do. > > Thanks, Trent. Whilst I understand why you're doing what you're doing, > I'm going to try and stick with the libtool scheme. At least until > I've got a handle on lesstif's experience ;-) actually going back and reading the whole thread again[1] I believe they finally went with what libtool wanted for what was compiled, but had some softlinks setup. It erupted because they went to libtool 1.3.4 and it changed some things. Also part of their problem was that there are 2 version numbers for lestif, one describes the lestif release, and the other describes the M*tif version lestif is implementing. It was that libtool was not using the same M*tif version number on all platforms, specifically on Digital Unix libtool wanted to make it version 1.0.2 where it should be (and was on other platforms) 1.2.0 . Sorry if this has lead down a wrong path. Angus Leeming wrote: > > Interesting. However, could you help me out a little more? > Specifically, which files should I be looking at? the following have libtool mentioned in the comments. configure.in & *Makefile.am 2001-08-29 acconfig.h acinclude.m4 configure.in CVSMake 2000-08-22 configure.in 1999-10-23 07:15 [1] I have my personal copy of the lestif mailing list back to August 99, from which I sent Angus one of the messages that terminated the discussion on lestif. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From drriddle at mac.com Mon May 10 00:20:58 2004 From: drriddle at mac.com (drriddle at mac.com) Date: Sun, 9 May 2004 23:20:58 -0500 Subject: [XForms] xyplot patch, OS X compatibility Message-ID: <70579D31-A239-11D8-9713-003065E23D38@mac.com> Howdy all, A while ago, I put up a patch for the fl_replace_xyplot_point routine that would allow one to change the value of an overlay point (the current version only allows you to change the value of the main data plot point). Did that make it into the new version of the library? Also, you should be able to use the instructions at http://wet.physics.iastate.edu/Tools/xqed/index.html to compile Xforms under Mac OS X, version 10.3. I'll test that again once the new version of the library comes out, just to make sure it still works. That's also the page for the code I'm working on; if you're interested in downloading it and looking at the code, you may want to wait a few weeks. I should have a new version out by the end of the month, and it will be much improved (and the programming will suck much less ;) ). Reed ---------------------------------------------------------------------- Dr. Reed L. Riddle Associate Director of Whole Earth Telescope Operations Iowa State University Department of Physics & Astronomy Homepage: http://wet.physics.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 angus.leeming at btopenworld.com Mon May 10 17:01:20 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 10 May 2004 22:01:20 +0100 Subject: [XForms] One more piece of rpm magic needed In-Reply-To: References: <200405071204.59432.angus.leeming@btopenworld.com> <200405071351.44809.angus.leeming@btopenworld.com> Message-ID: <200405102201.20053.angus.leeming@btopenworld.com> On Friday 07 May 2004 2:05 pm, Jean-Marc Lasgouttes wrote: > Angus> (The identifying regex before the s/// block *must* be > bounded Angus> by '/'. The s@@@ is find.) > > Hmm, OK, I give up you. You won this time, but beware of my next > attempt... I'm forever watchful ;-) > BTW, thanks for this flurry of activity on the xforms front. It > seems that it is actually going to be released now :) Yes, let's get this albatross off and flying. Angus From angus.leeming at btopenworld.com Mon May 10 17:05:30 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 10 May 2004 22:05:30 +0100 Subject: [XForms] [patch] sliders and counters In-Reply-To: References: <200405061816.21372.angus.leeming@btopenworld.com> Message-ID: <200405102205.30326.angus.leeming@btopenworld.com> On Friday 07 May 2004 1:59 pm, Jean-Marc Lasgouttes wrote: > Angus> What else is needed for the 1.1 release? > > I am currently trying to play around with xpopup.c to fix two > problems: [...snip...] > Of course, none of these things are primordial for xforms 1.1. Yes, I can certainly recreate each bug and I agree they're annoying. If you can find a fix soon, great, but let's keep up the momentum... Angus From angus.leeming at btopenworld.com Mon May 10 17:25:43 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 10 May 2004 22:25:43 +0100 Subject: [XForms] Trying to get a handle on libtool's versioning system In-Reply-To: <409BA7D6.FDA153C2@ssa.crane.navy.mil> References: <200405071133.51019.angus.leeming@btopenworld.com> <409BA7D6.FDA153C2@ssa.crane.navy.mil> Message-ID: <200405102225.43844.angus.leeming@btopenworld.com> On Friday 07 May 2004 4:14 pm, Todd Denniston wrote: > actually going back and reading the whole thread again[1] I believe > they finally went with what libtool wanted for what was compiled, > but had some softlinks setup. It erupted because they went to > libtool 1.3.4 and it changed some things. > Also part of their problem was that there are 2 version numbers for > lestif, one describes the lestif release, and the other describes > the M*tif version lestif is implementing. It was that libtool was > not using the same M*tif version number on all platforms, > specifically on Digital Unix libtool wanted to make it version > 1.0.2 where it should be (and was on other platforms) 1.2.0 . > > Sorry if this has lead down a wrong path. Don't be. All information is good information. Thanks for taking the time to do this, Todd. > Angus Leeming wrote: > > Interesting. However, could you help me out a little more? > > Specifically, which files should I be looking at? > > the following have libtool mentioned in the comments. > configure.in & *Makefile.am 2001-08-29 > acconfig.h acinclude.m4 configure.in CVSMake 2000-08-22 > configure.in 1999-10-23 07:15 Great. I'll have a look over the next day or so. Angus From lab at saao.ac.za Tue May 11 03:32:32 2004 From: lab at saao.ac.za (Luis Balona) Date: Tue, 11 May 2004 09:32:32 +0200 (SAST) Subject: [XForms] Crash in fl_check_forms In-Reply-To: <200405102225.43844.angus.leeming@btopenworld.com> Message-ID: We are using xforms-0.89 for a software project involving the South African Large Telescope. Since most of the telescope system is coded in LabView I needed to include a LabView shell which calls various C functions in a shared library. Much of the functionality in the C code resides in an image display and GUI built around xforms. I've had no problem at all until recently when I've been experiencing a segmentation fault soon after starting the program. This fault occurs at sporadic intervals, not always. I've tracked it down to a call to fl_check_forms. Somewhere in here it is referencing an illegal address. I know very little about XEvents. Can anyone offer some suggestions? Regards Luis ----------------------------------------------------------------------------- Dr Luis A Balona lab at saao.ac.za South African Astronomical Observatory Tel: 2721-447-0025 P O Box 9 Fax: 2721-447-3639 Observatory 7935 Cape Town South Africa ------------------------------------------------------------------------------ From angus.leeming at btopenworld.com Tue May 11 15:23:51 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 11 May 2004 20:23:51 +0100 Subject: [XForms] Crash in fl_check_forms In-Reply-To: References: Message-ID: <200405112023.51529.angus.leeming@btopenworld.com> I sent this privately to Luis by mistake, so to prevent anyone else spending precious time on it, am reposting it to the mailing list. Angus On Tuesday 11 May 2004 8:32 am, Luis Balona wrote: > I've had no problem at all until recently when I've been > experiencing a segmentation fault soon after starting the program. > This fault occurs at sporadic intervals, not always. I've tracked > it down to a call to fl_check_forms. Hello, Luis. fl_check_forms is just the public interface to the GUI library. The probelm could actually be occuring pretty well anywhere inside either xforms or your own code. Can you compile your executable with optimization turned off and debugging turned on and then run it within a debugger such as gdb: $ gdb your_app gdb> r when it crashes type 'bt' to obtain a full backtrace of the problem. That will help you pin down the problem far more precisely. > Somewhere in here it is > referencing an illegal address. I know very little about XEvents. > Can anyone offer some suggestions? HTH, but feel free to come back as often as it takes. If you're running on a PC using linux, then another *great* debugging tool is valgrind which will flag all illegal instructions for you. Angus From Jean-Marc.Lasgouttes at inria.fr Wed May 12 08:49:10 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Wed, 12 May 2004 14:49:10 +0200 Subject: [XForms] [PATCH] Re: Makefile problem in xforms-1.0.90.tar.gz In-Reply-To: <20040511173353.90B8D15C45@mendez.freesurf.fr> (Rod Curling-Hope's message of "Tue, 11 May 2004 19:33:53 +0200 (CEST)") References: <20040511173353.90B8D15C45@mendez.freesurf.fr> Message-ID: A non-text attachment was scrubbed... Name: xcflags.diff Type: text/x-patch Size: 2830 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040512/369b9a5a/attachment.bin From dirk at CeBiTec.Uni-Bielefeld.DE Wed May 12 03:31:36 2004 From: dirk at CeBiTec.Uni-Bielefeld.DE (Dirk Evers) Date: Wed, 12 May 2004 09:31:36 +0200 Subject: [XForms] xforms on windows? Message-ID: <40A1D2D8.4000608@CeBiTec.Uni-Bielefeld.DE> This is probably documented somewhere... :-) Is there a version of xforms for windows? What do I need to use it? I know about fltk, but I would prefer not having to rewrite for it. Regards Dirk -- Dirk J. Evers dirk.evers at cebitec.uni-bielefeld.de NRW Graduate School in +49 (0)521/106-3793 Bioinformatics and Genome Research, CeBiTec - Center for Biotechnology University of Bielefeld, D-33594 Bielefeld, Germany From angus.leeming at btopenworld.com Thu May 13 13:00:07 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 13 May 2004 18:00:07 +0100 Subject: [XForms] [patch] fl_replace_xyplot_point_in_overlay Message-ID: <200405131800.07535.angus.leeming@btopenworld.com> I'm committing this now, so this is FYI. Attached is a patch from Reed. It generalizes the existing fl_replace_xyplot_point which acts only on the first dataset. Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: xyplot.diff Type: text/x-diff Size: 2224 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040513/eb22f03c/attachment.bin From angus.leeming at btopenworld.com Thu May 13 13:07:42 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 13 May 2004 18:07:42 +0100 Subject: [XForms] [patch] libtool version number Message-ID: <200405131807.42656.angus.leeming@btopenworld.com> Jean-Marc, would you prefer me to commit this patch now or only immediately before we release XForms 1.1 final? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: so_version.diff Type: text/x-diff Size: 1096 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040513/0d727541/attachment.bin From jac4 at mindless.com Thu May 13 18:21:06 2004 From: jac4 at mindless.com (jason cipriani) Date: Thu, 13 May 2004 17:21:06 -0500 Subject: [XForms] Patch: GLCanvas context sharing support. Message-ID: <20040513222106.E8E9079004B@ws1-14.us4.outblaze.com> This patch allows support for context sharing in GLCanvases, a feature which should have been in there long, long ago. Not tested because something about 1.0.90 seems to have broken the GLCanvas stuff entirely (as in, none of the GLCanvas functions are in forms.h any more). So I'll have to get to the bottom of that first. In the mean time, here is the patch (glcanvas.c/glcanvas.h), if anybody has a version of 1.0.90 with working GLCanvases. GLCanvases that share the same GLX Context will share GL call lists and (for GL version >= 1.1) textures. TODO: Add support to fdesign for using shared GLCanvases. --- orig/glcanvas.c 2004-05-13 17:43:51.000000000 -0400 +++ glcanvas.c 2004-05-13 17:57:37.000000000 -0400 @@ -38,6 +38,12 @@ * See ../DEMOS/gl.c for an example use of glcanvas. * See ../DEMOS/glwin.c for an example use of fl_glwinopen * + * 13-may-2004: jason cipriani (jac4 at mindless.com): + * - added support for glx context sharing. + * - added the following functions: + * - fl_add_glcanvas_shared() + * - fl_create_glcanvas_shared() + * - fl_get_glcanvas_shared_context() */ #if defined(F_ID) || defined(DEBUG) @@ -59,6 +65,7 @@ { XVisualInfo *xvinfo; GLXContext context; + GLXContext context_shared; // Context to share data with. int direct; int glconfig[MAXATTRIB]; } @@ -91,7 +98,15 @@ fl_add_glcanvas(int type, FL_Coord x, FL_Coord y, FL_Coord w, FL_Coord h, const char *label) { - FL_OBJECT * ob = fl_create_glcanvas(type, x, y, w, h, label); + return fl_add_glcanvas_shared(type, x, y, w, h, label, NULL); +} + +FL_OBJECT * +fl_add_glcanvas_shared (int type, FL_Coord x, FL_Coord y, FL_Coord w, + FL_Coord h, const char *label, FL_OBJECT *shared_with) +{ + FL_OBJECT * ob = fl_create_glcanvas_shared(type, x, y, w, h, label, + shared_with); fl_add_object(fl_current_form, ob); return ob; } @@ -151,6 +166,12 @@ return GLPROP(ob)->context; } +GLXContext +fl_get_glcanvas_shared_context (FL_OBJECT *ob) +{ + return GLPROP(ob)->context_shared; +} + XVisualInfo * fl_get_glcanvas_xvisualinfo(FL_OBJECT * ob) { @@ -169,15 +190,38 @@ fl_create_glcanvas(int type, FL_Coord x, FL_Coord y, FL_Coord w, FL_Coord h, const char *label) { + return fl_create_glcanvas_shared(type, x, y, w, h, label, NULL); +} + +/* GLCanvas with context sharing. */ +FL_OBJECT * +fl_create_glcanvas_shared(int type, FL_Coord x, FL_Coord y, FL_Coord w, + FL_Coord h, const char *label, FL_OBJECT *shared_with) +{ FL_OBJECT *ob = fl_create_canvas(type, x, y, w, h, label); + GLXContext sctx; ob->objclass = FL_GLCANVAS; fl_modify_canvas_prop(ob, glx_init, glx_activate, glx_cleanup); + /* figure out glx context to share with. if shared_with is NULL or if it's + * not a GL canvas, then we can't do sharing. otherwise, the gl context to + * share with is chosen as follows: + * - if shared_with is also sharing data with another glx context, use + * the glx context shared_with is sharing data with, otherwise... + * - use shared_with's actual glx context. + */ + if (shared_with && shared_with->objclass == FL_GLCANVAS) { + if (!(sctx = fl_get_glcanvas_shared_context(shared_with))) + sctx = fl_get_glcanvas_context(shared_with); + } else + sctx = NULL; + /* initialize glcanvas specific stuff */ ob->c_vdata = fl_calloc(1, sizeof(CSPEC)); memcpy(GLPROP(ob)->glconfig, glconfig, sizeof(glconfig)); GLPROP(ob)->direct = GL_TRUE; + GLPROP(ob)->context_shared = sctx; return ob; } @@ -208,7 +252,8 @@ fl_set_canvas_depth(ob, vi->depth); fl_set_canvas_colormap(ob, fl_create_colormap(vi, 1)); - context = glXCreateContext(fl_display, vi, None, GLPROP(ob)->direct); + context = glXCreateContext(fl_display, vi, GLPROP(ob)->context_shared, + GLPROP(ob)->direct); if (!context) { --- orig/glcanvas.h 2004-05-13 17:43:51.000000000 -0400 +++ glcanvas.h 2004-05-13 17:46:55.000000000 -0400 @@ -11,6 +11,15 @@ const char *label ); +FL_EXPORT FL_OBJECT *fl_create_glcanvas_shared ( + int type, + FL_Coord x, + FL_Coord y, + FL_Coord w, + FL_Coord h, + const char *label, + FL_OBJECT *shared_with + ); FL_EXPORT FL_OBJECT *fl_add_glcanvas( int type, @@ -21,6 +30,16 @@ const char *label ); +FL_EXPORT FL_OBJECT *fl_add_glcanvas_shared ( + int type, + FL_Coord x, + FL_Coord y, + FL_Coord w, + FL_Coord h, + const char *label, + FL_OBJECT *shared_with + ); + FL_EXPORT void fl_set_glcanvas_defaults( const int *config @@ -58,6 +77,10 @@ FL_OBJECT *ob ); +FL_EXPORT GLXContext fl_get_glcanvas_shared_context ( + FL_OBJECT *ob + ); + FL_EXPORT Window fl_glwincreate( int *config, GLXContext *context, -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: glcanvas.diff.tgz Type: application/octet-stream Size: 1518 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040513/ccec6cc0/attachment.obj From angus.leeming at btopenworld.com Fri May 14 04:30:05 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 14 May 2004 09:30:05 +0100 Subject: [XForms] Patch: GLCanvas context sharing support. In-Reply-To: <20040513222106.E8E9079004B@ws1-14.us4.outblaze.com> References: <20040513222106.E8E9079004B@ws1-14.us4.outblaze.com> Message-ID: <200405140930.05519.angus.leeming@btopenworld.com> On Thursday 13 May 2004 11:21 pm, jason cipriani wrote: > This patch allows support for context sharing in GLCanvases, a > feature which should have been in there long, long ago. Not tested > because something about 1.0.90 seems to have broken the GLCanvas > stuff entirely (as in, none of the GLCanvas functions are in > forms.h any more). So I'll have to get to the bottom of that first. > In the mean time, here is the patch (glcanvas.c/glcanvas.h), if > anybody has a version of 1.0.90 with working GLCanvases. Jason, all the GL stuff was moved into its own directory/libraryheader file for the 1.0 release. Find it in the gl directory. 'make install' will lead to these files being installed: fd2ps fdesign flimage.h forms.h glcanvas.h libflimage.a libforms.a libformsGL.a libflimage.so libforms.so libformsGL.so Angus From Jean-Marc.Lasgouttes at inria.fr Fri May 14 09:05:24 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 14 May 2004 15:05:24 +0200 Subject: [XForms] [patch] libtool version number In-Reply-To: <200405131807.42656.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 13 May 2004 18:07:42 +0100") References: <200405131807.42656.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, Angus> would you prefer me to commit this patch now or only Angus> immediately before we release XForms 1.1 final? We can maybe wait, but I am not sure that it matters :) JMarc From angus.leeming at btopenworld.com Fri May 14 09:46:37 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 14 May 2004 14:46:37 +0100 Subject: [XForms] [patch] libtool version number In-Reply-To: References: <200405131807.42656.angus.leeming@btopenworld.com> Message-ID: <200405141446.37277.angus.leeming@btopenworld.com> On Friday 14 May 2004 2:05 pm, Jean-Marc Lasgouttes wrote: > Angus> would you prefer me to commit this patch now or only > Angus> immediately before we release XForms 1.1 final? > > We can maybe wait, but I am not sure that it matters :) Given our huge user base you mean? I think that we're about ready for another pre-release, don't you? The only stuff I have listed as pending are in the hands of the three Js: Jason Cipriani: some feedback on whether the GLCanvas stuff works with version 1.0.90. If he can confirm that his patch implementing context sharing in GLCanvases works, then I'm happy to shove it in. (It being stuff about which I am entirely ignorant.) Jeff Pierce: apparently has a patch to add FL_CLIENT_CALLBACK, fl_register_client_callback. Don't know if he wants this in XForms 1.1, but he should get a shifty on if he does ;-) Jean-Marc Lasgouttes: some meddlings with the popup code. What's the story with the documentation? Angus From jac4 at mindless.com Fri May 14 11:45:41 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri, 14 May 2004 10:45:41 -0500 Subject: [XForms] Patch: GLCanvas context sharing support. Message-ID: <20040514154541.9FE3A79004B@ws1-14.us4.outblaze.com> The patch needs a bit of work anyway, I shouldn't have submitted it without testing it. Primary issue being the fact that it needs a GLXContext to share with, which isn't created until the canvas is about to be shown, so it will work fine if you created a shared canvas after the form is shown but that doesn't lend itself well to fdesign. I have another method that works just fine but I have a question about this part of glx_init() in glcanvas.c: /* under some conditions, the parent of the gl canvas might go away, leaving the old context and vi hanging. */ glx_cleanup(ob); What conditions are "some conditions"? What I am doing now is keeping the FL_OBJECT* for the glcanvas you want to share a context with in the glcanvas's CSPEC. Then, in glx_init(), it checks to see if that glcanvas has a GLXContext yet. If it doesn't, then it forces initialization of that canvas. That's fine but what that means is that if "some conditions" are true and also if the shared canvas is created -before- the canvas it's sharing context data with, then the shared canvas's glx_init() won't attempt to initialize the canvas its sharing data with (since it's GLXContext isn't 0), so it will use it's GLXContext. But then when the canvas its sharing data with is initialized (and some conditions are true), then its context will be destroyed and a new one will be creating, invalidating the GLXContext that the shared canvas is sharing data with. So I need to figure out a way to ensure that the canvas its sharing data with is properly initialized first, rather than it just having some leftover old GLXContext associated with it because "the parent of the gl canvas [went] away". As far as the GL stuff, the problem was that this was removed from forms.h in 1.0.90 (it was there in 1.0): #if defined(__GLX_glx_h__) || defined(GLX_H) #include #endif Simple solution was to add it back in, rather than #include'ing glcanvas.h in all the xforms apps we have. Jason ----- Original Message ----- From: Angus Leeming Date: Fri, 14 May 2004 09:30:05 +0100 To: xforms Subject: Re: [XForms] Patch: GLCanvas context sharing support. > On Thursday 13 May 2004 11:21 pm, jason cipriani wrote: > > This patch allows support for context sharing in GLCanvases, a > > feature which should have been in there long, long ago. Not tested > > because something about 1.0.90 seems to have broken the GLCanvas > > stuff entirely (as in, none of the GLCanvas functions are in > > forms.h any more). So I'll have to get to the bottom of that first. > > In the mean time, here is the patch (glcanvas.c/glcanvas.h), if > > anybody has a version of 1.0.90 with working GLCanvases. > > Jason, all the GL stuff was moved into its own directory/libraryheader > file for the 1.0 release. Find it in the gl directory. > > 'make install' will lead to these files being installed: > > fd2ps fdesign > flimage.h forms.h glcanvas.h > libflimage.a libforms.a libformsGL.a > libflimage.so libforms.so libformsGL.so > > Angus > > -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Fri May 14 12:16:15 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 14 May 2004 17:16:15 +0100 Subject: [XForms] Patch: GLCanvas context sharing support. In-Reply-To: <20040514153007.089AE79004B@ws1-14.us4.outblaze.com> References: <20040514153007.089AE79004B@ws1-14.us4.outblaze.com> Message-ID: <200405141716.15416.angus.leeming@btopenworld.com> On Friday 14 May 2004 4:30 pm, jason cipriani wrote: > /* under some conditions, the parent of the gl canvas might go > away, leaving the old context and vi hanging. */ > glx_cleanup(ob); > > What conditions are "some conditions"? Ha! I have no idea. My knowledge of this part of the code base is nil. > What I am doing now is keeping the FL_OBJECT* for the glcanvas you > want to share a context with in the glcanvas's CSPEC. Then, in > glx_init(), it checks to see if that glcanvas has a GLXContext yet. > If it doesn't, then it forces initialization of that canvas. That's > fine but what that means is that if "some conditions" are true and > also if the shared canvas is created -before- the canvas it's > sharing context data with, then the shared canvas's glx_init() > won't attempt to initialize the canvas its sharing data with (since > it's GLXContext isn't 0), so it will use it's GLXContext. But then > when the canvas its sharing data with is initialized (and some > conditions are true), then its context will be destroyed and a new > one will be creating, invalidating the GLXContext that the shared > canvas is sharing data with. Phew. 2 sentences covering 10 lines. I keep forgetting the start before I get to the end ;-) > So I need to figure out a way to ensure that the canvas its sharing > data with is properly initialized first, rather than it just having > some leftover old GLXContext associated with it because "the parent > of the gl canvas [went] away". The parent of the gl canvas is the Window on which the FL_FORM and FL_OBJECT are displayed, right? Or is it the FL_FORM itself? If the former, could you not use (form->window == GLPROP(ob)->window) as a check. You'd need to add a new variable, window, to CSPEC but so what? Or have I got all this wrong? > As far as the GL stuff, the problem was that this was removed from > forms.h in 1.0.90 (it was there in 1.0): > > #if defined(__GLX_glx_h__) || defined(GLX_H) > #include > #endif > > Simple solution was to add it back in, rather than #include'ing > glcanvas.h in all the xforms apps we have. Ahhhhhh. So you'd like forms.h to #include glcanvas.h if a preprocessor guard is defined. What defines __GLX_glx_h__, GLX_H? I don't think that the preprocessor guard should be a system or compiler-defined macro. You should have to define it explicitly. Eg #ifdef FORM_GLCANVAS_H #include FORM_GLCANVAS_H #endif where FORM_GLCANVAS_H is defined either in your file for the project or is passed via a -D flag on the compiler command. Angus k From davidwriter at yahoo.com Fri May 14 14:33:57 2004 From: davidwriter at yahoo.com (David Scriven) Date: Fri, 14 May 2004 14:33:57 -0400 (EDT) Subject: [XForms] Patch: GLCanvas context sharing support. In-Reply-To: <20040514154541.9FE3A79004B@ws1-14.us4.outblaze.com> Message-ID: <20040514183357.23666.qmail@web60310.mail.yahoo.com> Jason, Maybe I'm being slow, but I don't see why we need this patch - can you give an example of how you would use it. One can obtain the context of a canvas after you create it: .... fl_add_glcanvas.... ... fl_initialize ... GLXContext CanvasContext = NULL; CanvasContext = fl_get_glcanvas_context(form->canvas); if(CanvasContext == NULL) { ....aaargh - disaster ! } and use it in calls to glXCopyContext. > As far as the GL stuff, the problem was that this was removed from > forms.h in 1.0.90 (it was there in 1.0): > > #if defined(__GLX_glx_h__) || defined(GLX_H) > #include > #endif > This definition doesn't always work - for example NVIDIA defines its glx.h file differently, so you have to have #if defined(__GLX_glx_h__) || defined(GLX_H) || defined(__glx_h__) for glcanvas to work. Clearly not a good thing if we have to alter the test to cover all the internal structures of various vendor's glx.h files. DS ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca From jac4 at mindless.com Fri May 14 15:31:01 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri, 14 May 2004 14:31:01 -0500 Subject: [XForms] Patch: GLCanvas context sharing support. Message-ID: <20040514193101.62E0E79004B@ws1-14.us4.outblaze.com> > Jason, Maybe I'm being slow, but I don't see why we need > this patch - can you give an example of how you would > use it. AGL, GLX, and wGL all support GL context sharing. When two GL contexts are shared, what this means is that they share the same call list and (for GL >= 1.1) texturing namespaces. So, if you have a form with 4 GL canvases on it, the way it is now, and you want to display the same, say, 60K+ polygon surface model on all 4 canvases, you need to create 4 separate call lists. So you need to store the same call list in memory 4 times, and you need to take the time to generate 4 identical call lists. And if you have the same texture that you want to display on all 4 canvases, you have to load the same texture 4 times. Same deal. For example (as far as texturing goes), if you wanted to display captured video on a surface, you may choose to copy the captured image to texture mapped memory to update that texture and display the video. Your frame rate -will- suffer if you have to load the same image into memory 4 times simply because you have 4 separate GL canvases. Also, in applications with huge amounts of textures, memory -does- become an issue when you have to load the same textures into memory 2, 3, or more times. Context sharing, as far as XForms goes, allows you to use the same call lists and textures for multiple GL canvases. When you think about the impact this has on the amount of memory your application uses and the amount of time you have to spend processing call lists and textures, the benefits are clear. As a matter of fact, GLX makes it simple to share contexts: the glXCreateContext function can actually take, as a parameter, another context which you want to share data with. Problem is, of course, the XForms GL canvas doesn't provide a way for you to specify a context to share data with. Also note that you can't begin sharing contexts after both contexts are created. You have to specify the context to share data with at the time you create a new context, so it's not something that you can do with GLX calls after you have already created and displayed the GL canvases. glXCopyContext will create a copy of the context but the new context will not share the same call list and texture namespace as the one it was copied from, and you cannot specify a context to share data with in the glXCopyContext call. It -must- be done in the glXCreateContext call. Even if glXCopyContext did work, there currently exists no clean way to change the GLXContext of a GL canvas, as far as I know, although you can "change" it by directly modifying the data in the GL canvases CSPEC. > This definition doesn't always work - for example NVIDIA > defines its glx.h file differently, so you have to have > ... > for glcanvas to work. Clearly not a good thing if we have to > alter the test to cover all the internal structures of various > vendor's glx.h files. Absolutely true. We use nVidia cards here and when we set up a new machine with XForms 1.0 we have to go modify forms.h to check for nVidia's glx.h defines. Dirty but, that's the way it was done, and now we have a whole bunch of apps that don't explicitly #include glcanvas.h. Angus wrote: > #ifdef FORM_GLCANVAS_H > #include FORM_GLCANVAS_H > #endif > > where FORM_GLCANVAS_H is defined either in your file for > the project or is passed via a -D flag on the compiler command. Which is a much better way to do it, and I think that forms.h should have that in it in the next release. What I wrote was a quick fix and actually what I am doing now is using a modified forms.h that just includes and then includes without checking for anything. Dirty but it works on my machine. Angus' way allows the least breaking of existing apps (in my case, I have some common make include files for everything so adding a -DFORM_GLCANVAS_H is trivial) while at the same time not relying on vendor-specific #defines in glx.h. Hope that makes sense, Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Fri May 14 17:23:22 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 14 May 2004 22:23:22 +0100 Subject: [XForms] Patch: GLCanvas context sharing support. In-Reply-To: <20040514193101.62E0E79004B@ws1-14.us4.outblaze.com> References: <20040514193101.62E0E79004B@ws1-14.us4.outblaze.com> Message-ID: <200405142223.22018.angus.leeming@btopenworld.com> On Friday 14 May 2004 8:31 pm, jason cipriani wrote: > Angus wrote: > > #ifdef FORM_GLCANVAS_H > > #include FORM_GLCANVAS_H > > #endif > > > > where FORM_GLCANVAS_H is defined either in your file > > for the project or is passed via a -D flag on the compiler > > command. > > Which is a much better way to do it, and I think that forms.h > should have that in it in the next release. Ok, Jason. I've just committed the attached patch. You'll need to alter your project code so that a config.h file contains the magical #define GLCANVAS_H_LOCATION or alternatively pass the macro to your compiler directly. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: canvas.diff Type: text/x-diff Size: 1383 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040514/7a28d034/attachment.bin From jac4 at mindless.com Sun May 16 05:04:49 2004 From: jac4 at mindless.com (jason cipriani) Date: Sun, 16 May 2004 04:04:49 -0500 Subject: [XForms] Adding source files to fdesign. Message-ID: <20040516090449.92E90101C3@ws1-16.us4.outblaze.com> Ok. I've been struggling with this for a while now. I'm a bit lost when it comes to all this 'configure' stuff and, building Makefiles from other makefiles from other makefiles, and that kind of stuff. Could somebody please explain to me how to add a source file to the fdesign/spec directory, and actually get it to compile? I've got a working GLX context sharing patch, it's great. Adding fdesign support for it... that seems to be the hard part. Here is what I have done as far as fdesign source files go: 1) Added fdesign/sp_glcanvas.c (and fdesign/.deps/sp_glcanvas.Po), it compiles, just fine. 2) Added fdesign/spec/glcanvas_spec.fd/.c/.h. And I can't, for the life of me, convince make to compile glcanvas_spec.c. (Just to make it clear, the problem is that the source file isn't compiling at all; it's not a problem with actual compiler/linker errors aside from the obvious linker errors from undefined references to functions in that source file). I pretty much copied all the freeobj stuff, since that seemed to be the simplest. Still, I can't figure this out. Call me stupid. Thanks, Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jac4 at mindless.com Sun May 16 17:57:50 2004 From: jac4 at mindless.com (jason cipriani) Date: Sun, 16 May 2004 16:57:50 -0500 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) Message-ID: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> Ok, here it is. Tested on Mac OS X and Linux-testing coming on Monday. It's a rather large patch. The attached file contains patch.diff, sglcanvas.html (which somewhat resembles documentation), and a test program (which isn't worked into the demo folder, and the Makefile might require some tweaking to compile). This patch adds support for GLX context sharing in gl canvases, and also gives fdesign the ability to set up canvas sharing via the Spec tab in the glcanvas attribute editor. Turns out the GLCANVAS_H_LOCATION thing is still inadequate, mostly because if GLCANVAS_H_LOCATION is defined, forms.h includes glcanvas.h. There are some functions in glcanvas.h that use the GLXContext type, declared in GL/glx.h. So fdesign generated source files that include forms.h also include glcanvas.h and the compiler breaks because GL/glx.h wasn't included in the fdesign source files. So how about this, it seems to work fine: Instead of GLCANVAS_H_LOCATION, use GLX_H_LOCATION. If GLX_H_LOCATION is defined, then canvas.h can #include both GLX_H_LOCATION and . That should fix it. Just compile source with -DGLX_H_LOCATION="" or something, and glcanvas.h is automatically included after GL/glx.h is. If you are using gl canvases then indirectly including GL/glx.h from forms.h is not going to hurt anything. If you aren't using gl canvases then just don't defined GLX_H_LOCATION and everything remains the same. For now I am #including GL/glx.h directly from glcanvas.h. It's in the patch but I'm not happy with it, so remember to take it out if you decide on another way. You may have to fiddle with the "demo" program Makefile to get it to compile. I didn't work it into /demos. If anybody wants to try this patch now (it requires Angus' GLCANVAS_H_LOCATION thing too) for some reason: 1) Download fresh copy of xforms-1.0.90, and download attached patch. 2) Before ./configure, head to the xforms-1.0.90 root and do "patch -p1 patch.diff". 3) Build as usual. Detailed changes (some fdesign files are new): gl/glcanvas.c - Added functions to support creation of shared canvases and canvas pools. gl/glcanvas.h - #include "GL/glx.h" - FL_SGLPOOL - fl_activate_named_sglpool() - fl_activate_sglpool() - fl_add_shared_glcanvas() - fl_create_shared_glcanvas() - fl_get_glcanvas_sglpool() - fl_get_max_sglpools() - fl_get_named_sglpool() - fl_get_num_sglpools() - fl_get_sglpool_name() - fl_set_glcanvas_pool_name() - fl_set_max_sglpools() fdesign/Makefile.am - Compile sp_glcanvas.c. fdesign/Makefile.in - Compile sp_glcanvas.c fdesign/fd_main.h - Added 'shared' and 'poolname' to SuperSPEC. fdesign/fd_spec.c - Added attrib callbacks for FL_GLCANVAS. - Read "shared" and "poolname" from .fd files into SuperSPEC. fdesign/fd_spec.h - Prototypes for sp_glcanvas.c functions. fdesign/sp_glcanvas.c (new file) - This file handles spec attributes for FL_GLCANVAS. - emit_glcanvas_code() - get_glcanvas_spec_fdform() - glcanvas_spec_restore() - save_glcanvas_attrib() - set_glcanvas_attrib() fdesign/spec/Makefile.am - glcanvas_spec.c - glcanvas_spec.fd - glcanvas_spec.h fdesign/spec/Makefile.in - glcanvas_spec.c - glcanvas_spec.fd - glcanvas_spec.h fdesign/spec/glcanvas_spec.c (new file) - Source code for glcanvas spec form. fdesign/spec/glcanvas_spec.fd (new file) - FD file for glcanvas spec form. fdesign/spec/glcanvas_spec.h (new file) - Header for glcanvas spec form. Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.tgz Type: application/octet-stream Size: 18368 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040516/25fde4c0/attachment.obj From angus.leeming at btopenworld.com Mon May 17 03:24:07 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 08:24:07 +0100 Subject: [XForms] Adding source files to fdesign. In-Reply-To: <20040516090449.92E90101C3@ws1-16.us4.outblaze.com> References: <20040516090449.92E90101C3@ws1-16.us4.outblaze.com> Message-ID: <200405170824.07650.angus.leeming@btopenworld.com> On Sunday 16 May 2004 10:04 am, jason cipriani wrote: > To subscribers of the xforms list > > > Ok. I've been struggling with this for a while now. I'm a bit lost > when it comes to all this 'configure' stuff and, building Makefiles > from other makefiles from other makefiles, and that kind of stuff. > Could somebody please explain to me how to add a source file to the > fdesign/spec directory, and actually get it to compile? Ok. We don't actually compile anything in this directory, for reasons of historical laziness. Instead, what has happened is that we #include both the .h and the .c file in the 'parent' file in the fdesign directory. See, eg, sp_xyplot.c: sp_xyplot.c:#include "spec/xyplot_spec.h" sp_xyplot.c:#include "spec/xyplot_spec.c" You should add your files to the EXTRA_DIST target in fdesign/spec/Makefile.am to ensure that they are distributed when the library is packaged as a tar file. > I've got a working GLX context sharing patch, it's great. Well done. > Adding fdesign support for it... that seems to be the hard part. > Here is what I have done as far as fdesign source files go: > > 1) Added fdesign/sp_glcanvas.c (and fdesign/.deps/sp_glcanvas.Po), > it compiles, just fine. Good. You've modified the generated Makefile it would appear. No problem, I can easily move this to Makefile.am. > Added fdesign/spec/glcanvas_spec.fd/.c/.h. And I can't, for > the life of me, convince make to compile glcanvas_spec.c. See above. > (Just to make it clear, the problem is that the source file isn't > compiling at all; it's not a problem with actual compiler/linker > errors aside from the obvious linker errors from undefined > references to functions in that source file). > > I pretty much copied all the freeobj stuff, since that seemed to be > the simplest. Still, I can't figure this out. Call me stupid. Not today ;-) Angus > Thanks, > Jason From angus.leeming at btopenworld.com Mon May 17 04:42:47 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 09:42:47 +0100 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> Message-ID: <200405170942.47719.angus.leeming@btopenworld.com> On Sunday 16 May 2004 10:57 pm, jason cipriani wrote: > Ok, here it is. Tested on Mac OS X and Linux-testing coming on > Monday. It's a rather large patch. The attached file contains > patch.diff, sglcanvas.html (which somewhat resembles > documentation), and a test program (which isn't worked into the > demo folder, and the Makefile might require some tweaking to > compile). This patch adds support for GLX context sharing in gl > canvases, and also gives fdesign the ability to set up canvas > sharing via the Spec tab in the glcanvas attribute editor. Woooo! Jason, I think that we should hold off on this until after XForms 1.1 is out of the door. It's big, big, big and we're very close to a release. However, I think we should resolve the GLCANVAS_H problem now. I think that header files should be self-contained. Ie #include "foo.h" int main() { return 0; } should compile. If it doesn't, then that's a problem. As you say, glcanvas.h contains code like: FL_EXPORT GLXContext fl_get_glcanvas_context(FL_OBJECT *ob); As we can't forward-declare GLXContext, the only permissible solution is to #include in glcanvas.h. Thereafter, things should "just work" with my GLCANVAS_H_LOCATION patch. Comments? Angus From angus.leeming at btopenworld.com Mon May 17 05:27:08 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 10:27:08 +0100 Subject: [XForms] [patch] self-contained glcanvas.h Message-ID: <200405171027.08559.angus.leeming@btopenworld.com> Attached is a patch that allows #include "glcanvas.h" int main() { return 0; } to compile. However, I'm not entirely happy with it. The line #include "forms.h" pre-supposes forms.h is in a directory that is searched directly by the compiler. Is this a valid assumption? I seem to remember that forms.h is sometimes #included as , but this may be in older versions of the XForms library. Jean-Marc, all? Any advice? Angus ps, it appears that something similar is needed for flimage.h, but let's sort out one thing at a time. A -------------- next part -------------- A non-text attachment was scrubbed... Name: glcanvas.diff Type: text/x-diff Size: 668 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040517/8d792ade/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Mon May 17 05:34:02 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 17 May 2004 11:34:02 +0200 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <200405170942.47719.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 09:42:47 +0100") References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405170942.47719.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> However, I think we should resolve the GLCANVAS_H problem now. Angus> I think that header files should be self-contained. Ie #include Angus> "foo.h" int main() { return 0; } should compile. If it doesn't, Angus> then that's a problem. Angus> As you say, glcanvas.h contains code like: FL_EXPORT GLXContext Angus> fl_get_glcanvas_context(FL_OBJECT *ob); As we can't Angus> forward-declare GLXContext, the only permissible solution is to Angus> #include in glcanvas.h. Angus> Thereafter, things should "just work" with my Angus> GLCANVAS_H_LOCATION patch. Angus, I tried to read the thread about this header problem, but I do not really understand what the issue is. Could you explain it to me? JMarc From angus.leeming at btopenworld.com Mon May 17 05:47:39 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 10:47:39 +0100 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405170942.47719.angus.leeming@btopenworld.com> Message-ID: <200405171047.39127.angus.leeming@btopenworld.com> On Monday 17 May 2004 10:34 am, Jean-Marc Lasgouttes wrote: > To subscribers of the xforms list > > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> However, I think we should resolve the GLCANVAS_H problem > now. > > Angus> I think that header files should be self-contained. Ie > #include Angus> "foo.h" int main() { return 0; } should compile. If > it doesn't, Angus> then that's a problem. > > Angus> As you say, glcanvas.h contains code like: FL_EXPORT > GLXContext Angus> fl_get_glcanvas_context(FL_OBJECT *ob); As we > can't Angus> forward-declare GLXContext, the only permissible > solution is to Angus> #include in glcanvas.h. > > Angus> Thereafter, things should "just work" with my > Angus> GLCANVAS_H_LOCATION patch. > > Angus, I tried to read the thread about this header problem, but I > do not really understand what the issue is. Could you explain it to > me? Yes. forms.h is built automatically from the header files in lib/include. One of these, canvas.h, used to #include glcanvas.h with the block: #if defined(__GLX_glx_h__) || defined(GLX_H) #include #endif This got removed (13 months ago, by me) because glcanvas.h is now part of a separate library, it doesn't get installed in the X11 directory, the guard was crappy and liable to break etc, etc. Unfortunately, doing so breaks Jason's codes. So my solution is to add the #include back in, but in a more explicit manner: #ifdef GLCANVAS_H_LOCATION #include GLCANVAS_H_LOCATION #endif That seems like a reasonable compromise, don't you think? This is all separate to the 'glcanvas.h should be self-contained' problem. Angus From Jean-Marc.Lasgouttes at inria.fr Mon May 17 06:14:42 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 17 May 2004 12:14:42 +0200 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <200405171047.39127.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 10:47:39 +0100") References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405170942.47719.angus.leeming@btopenworld.com> <200405171047.39127.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> forms.h is built automatically from the header files in Angus> lib/include. Yes. Angus> One of these, canvas.h, used to #include glcanvas.h with the Angus> block: Angus> #if defined(__GLX_glx_h__) || defined(GLX_H) #include Angus> #endif Angus> This got removed (13 months ago, by me) because glcanvas.h is Angus> now part of a separate library, it doesn't get installed in the Angus> X11 directory, the guard was crappy and liable to break etc, Angus> etc. Yes. Angus> Unfortunately, doing so breaks Jason's codes. So my solution is Angus> to add the #include back in, but in a more explicit manner: Angus> #ifdef GLCANVAS_H_LOCATION #include GLCANVAS_H_LOCATION #endif There are two separate issues: 1/ the easiest one: we need the xxx_LOCATION nonsense because imake-based build systems tend to put header files in places like X11/forms.h. This is not the case anymore, so we should assume now that header files have to be on the search path. Thus a #include "glcanvas.h" should be enough. 2/ the problem of including glcanvas.h: If we are serious about separating the gl stuff from the rest, we want people to be able to use forms.h without any gl stuff installed. I would prefer to make people include "glcanvas.h" manually, but I agree that we can have a backdoor for people who do not want to change their code. In this case, we should probably rely on a HAVE_GLCANVAS_H define, which is straightforward to define through autoconf, and add code like #ifdef HAVE_GLCANVAS_H #include "glcanvas.h" #endif However, I think that we should not make this way the preferred way, because it is a bit unnatural to my eyes. Do you think it would work correctly? Angus> This is all separate to the 'glcanvas.h should be Angus> self-contained' problem. Concerning this later problem, I am not sure we want to enforce it. Asking people to include forms.h seems rather reasonable to me. JMarc From angus.leeming at btopenworld.com Mon May 17 06:27:29 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 11:27:29 +0100 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405171047.39127.angus.leeming@btopenworld.com> Message-ID: <200405171127.29447.angus.leeming@btopenworld.com> On Monday 17 May 2004 11:14 am, Jean-Marc Lasgouttes wrote: > Angus> #ifdef GLCANVAS_H_LOCATION #include GLCANVAS_H_LOCATION > #endif > > There are two separate issues: > > 1/ the easiest one: we need the xxx_LOCATION nonsense because > imake-based build systems tend to put header files in places like > X11/forms.h. This is not the case anymore, so we should assume now > that header files have to be on the search path. Thus a #include > "glcanvas.h" should be enough. Yes. > 2/ the problem of including glcanvas.h: If we are serious about > separating the gl stuff from the rest, we want people to be able to > use forms.h without any gl stuff installed. I would prefer to make > people include "glcanvas.h" manually, but I agree that we can have > a backdoor for people who do not want to change their code. In this > case, we should probably rely on a HAVE_GLCANVAS_H define, which is > straightforward to define through autoconf, and add code like > #ifdef HAVE_GLCANVAS_H > #include "glcanvas.h" > #endif Yes. > However, I think that we should not make this way the preferred > way, because it is a bit unnatural to my eyes. Agreed. This solution provides a means for people to continue to compile existing code. It's not nice and shouldn't be on by default. > Do you think it would work correctly? Yes. However, I don't think we should add HAVE_GLCANVAS_H to *our* autoconf files. This 'nonsense' is for whatever configure-magic the *user* uses to compile his code. All *we* need to do is to provide the pre-processor handle. Why not be explicit and define INCLUDE_GLCANVAS_H_FROM_CANVAS_H ? I think that being verbose here is a good thing. > Angus> This is all separate to the 'glcanvas.h should be > Angus> self-contained' problem. > > Concerning this later problem, I am not sure we want to enforce it. > Asking people to include forms.h seems rather reasonable to me. But it's inelegant! Anyway, the #include and the C++ guards are definitely needed IMO. Agree? Angus From Jean-Marc.Lasgouttes at inria.fr Mon May 17 06:50:48 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 17 May 2004 12:50:48 +0200 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <200405171127.29447.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 11:27:29 +0100") References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405171047.39127.angus.leeming@btopenworld.com> <200405171127.29447.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> Do you think it would work correctly? Angus> Yes. However, I don't think we should add HAVE_GLCANVAS_H to Angus> *our* autoconf files. Did I say something like that? It would not make much sense, actually. Angus> This 'nonsense' is for whatever configure-magic the *user* uses Angus> to compile his code. All *we* need to do is to provide the Angus> pre-processor handle. Why not be explicit and define Angus> INCLUDE_GLCANVAS_H_FROM_CANVAS_H ? I think that being verbose Angus> here is a good thing. OK, you are probaly right, although the define should be INCLUDE_GLCANVAS_H_FROM_FORMS_H or maybe the slightly shorter AUTOINCLUDE_GLCANVAS_H. Angus> This is all separate to the 'glcanvas.h should be Angus> self-contained' problem. >> Concerning this later problem, I am not sure we want to enforce >> it. Asking people to include forms.h seems rather reasonable to me. Angus> But it's inelegant! Angus> Anyway, the #include and the C++ guards are Angus> definitely needed IMO. Agree? Yes. OK, it probably does not hurt to make it self contained, but I think it encourages sloppiness, since glcanvas.h is such a tiny portion of the forms api. I do not see anybody wanting to use _only_ glcanvas-related API in a program. I think people should include headers for the API that they explicitly use. JMarc From angus.leeming at btopenworld.com Mon May 17 07:01:14 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 12:01:14 +0100 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405171127.29447.angus.leeming@btopenworld.com> Message-ID: <200405171201.14904.angus.leeming@btopenworld.com> On Monday 17 May 2004 11:50 am, Jean-Marc Lasgouttes wrote: > OK, you are probaly right, although the define should be > INCLUDE_GLCANVAS_H_FROM_FORMS_H or maybe the slightly shorter > AUTOINCLUDE_GLCANVAS_H. I'll do this. > OK, it probably does not hurt to make it self contained, but I > think it encourages sloppiness, since glcanvas.h is such a tiny > portion of the forms api. I do not see anybody wanting to use > _only_ > glcanvas-related API in a program. I think people should include > headers for the API that they explicitly use. Ok, I'll throw out this suggestion for now. Patch attached. Are you happy for me to commit this? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-diff Size: 1947 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040517/4d46ac47/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Mon May 17 07:06:36 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 17 May 2004 13:06:36 +0200 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <200405171201.14904.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 12:01:14 +0100") References: <20040516215750.D353F4BDAA@ws1-17.us4.outblaze.com> <200405171127.29447.angus.leeming@btopenworld.com> <200405171201.14904.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Patch attached. Are you happy for me to commit this? Angus Definitely. JMarc From Jean-Marc.Lasgouttes at inria.fr Mon May 17 07:10:44 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Mon, 17 May 2004 13:10:44 +0200 Subject: [XForms] [patch] libtool version number In-Reply-To: <200405141446.37277.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 14 May 2004 14:46:37 +0100") References: <200405131807.42656.angus.leeming@btopenworld.com> <200405141446.37277.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> We can maybe wait, but I am not sure that it matters :) Angus> Given our huge user base you mean? Especially the huge use base of xforms cvs. Angus> I think that we're about ready for another pre-release, don't Angus> you? That would be nice. Angus> Jean-Marc Lasgouttes: some meddlings with the popup code. I have given up for now. I suspect that the bad redrawing of menus in LyX are a LyX bug, since the popup demos do the redraw correctly. Angus> What's the story with the documentation? The story is that we still do not have anything. What would be very nice of us in this respect is to write down note about what has changed since the 0.89.6 release: how to use xforms (what headers what libraries), what new api exists, etc. Do you think we could do that? I do not think that there is a lot to write down. An of course we should try to get the real thing from TC. JMarc From angus.leeming at btopenworld.com Mon May 17 07:39:20 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 12:39:20 +0100 Subject: [XForms] [patch] libtool version number In-Reply-To: References: <200405131807.42656.angus.leeming@btopenworld.com> <200405141446.37277.angus.leeming@btopenworld.com> Message-ID: <200405171239.20613.angus.leeming@btopenworld.com> On Monday 17 May 2004 12:10 pm, Jean-Marc Lasgouttes wrote: > Angus> What's the story with the documentation? > > The story is that we still do not have anything. What would be very > nice of us in this respect is to write down note about what has > changed since the 0.89.6 release: how to use xforms (what headers > what libraries), what new api exists, etc. Do you think we could do > that? I do not think that there is a lot to write down. New FL_EVENTS, FL_MOVEORIGIN and FL_RESIZED. New typedef FL_ERROR_FUNC. Hmmm, why don't we use the FL_SIGNAL_HANDLER typedef here: -FL_EXPORT void fl_add_signal_callback(int, FL_SIGNAL_HANDLER, void *); +FL_EXPORT void fl_add_signal_callback( + int s, + void (*cb)(int, + void *), + void *data + ); Why 'register'? -FL_EXPORT int fl_get_vn_value(FL_VN_PAIR *, const char *); +FL_EXPORT int fl_get_vn_value( + register FL_VN_PAIR *vn_pair, + const char *name + ); Ach. This is going to take a while. Angus From jac4 at mindless.com Mon May 17 13:14:59 2004 From: jac4 at mindless.com (jason cipriani) Date: Mon, 17 May 2004 12:14:59 -0500 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) Message-ID: <20040517171459.3A53B790060@ws1-14.us4.outblaze.com> ----- Original Message ----- From: Angus Leeming Date: Mon, 17 May 2004 12:01:14 +0100 To: Jean-Marc Lasgouttes Subject: Re: [XForms] Patch: Context Sharing + fdesign (real thing) > To subscribers of the xforms list > > > > On Monday 17 May 2004 11:50 am, Jean-Marc Lasgouttes wrote: > > OK, you are probaly right, although the define should be > > INCLUDE_GLCANVAS_H_FROM_FORMS_H or maybe the slightly shorter > > AUTOINCLUDE_GLCANVAS_H. > > I'll do this. > > > OK, it probably does not hurt to make it self contained, but I > > think it encourages sloppiness, since glcanvas.h is such a tiny > > portion of the forms api. I do not see anybody wanting to use > > _only_ > > glcanvas-related API in a program. I think people should include > > headers for the API that they explicitly use. > > Ok, I'll throw out this suggestion for now. > > Patch attached. Are you happy for me to commit this? > Angus << patch.diff >> > > _______________________________________________ > 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 -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Mon May 17 13:18:38 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 18:18:38 +0100 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <20040517171427.8653F79004A@ws1-14.us4.outblaze.com> References: <20040517171427.8653F79004A@ws1-14.us4.outblaze.com> Message-ID: <200405171818.38560.angus.leeming@btopenworld.com> On Monday 17 May 2004 6:14 pm, jason cipriani wrote: > > On Monday 17 May 2004 11:50 am, Jean-Marc Lasgouttes wrote: > > > OK, you are probaly right, although the define should be > > > INCLUDE_GLCANVAS_H_FROM_FORMS_H or maybe the slightly shorter > > > AUTOINCLUDE_GLCANVAS_H. > > > > I'll do this. > > Ok, but the fdesign problem will still remain (right?). You'll need > to modify fdesign so that it #includes before #including > forms.h (bad), or modify glcanvas.h so it #includes > (better) (which I think you already did but I got lost a few emails > ago). I modified glcanvas.h so it #includes , so all should be well. Famous last words... Angus From angus.leeming at btopenworld.com Mon May 17 13:27:25 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 18:27:25 +0100 Subject: [XForms] [patch] libtool version number In-Reply-To: References: <200405131807.42656.angus.leeming@btopenworld.com> <200405141446.37277.angus.leeming@btopenworld.com> Message-ID: <200405171827.25693.angus.leeming@btopenworld.com> On Monday 17 May 2004 12:10 pm, Jean-Marc Lasgouttes wrote: > Angus> What's the story with the documentation? > > The story is that we still do not have anything. What would be very > nice of us in this respect is to write down note about what has > changed since the 0.89.6 release: how to use xforms (what headers > what libraries), what new api exists, etc. Do you think we could do > that? I do not think that there is a lot to write down. Ok, Jean-Marc, attached are all changes to the API since the release of XForms 0.89 patch level 5. I've split the changes into two files, changes_forms.h, which includes changes to stuff now in glcanvas.h, and changes_flimage.h. Many of these changes are pedantic. Eg: -FL_EXPORT void fl_bk_color(FL_COLOR); +FL_EXPORT void fl_bk_color(unsigned long); But there are new functions. There's even at least one regression. Anyway, I attach these files for the record. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: changes_flimage.h Type: text/x-chdr Size: 5131 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040517/c7a9f800/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: changes_forms.h Type: text/x-chdr Size: 9125 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040517/c7a9f800/attachment-0001.bin From angus.leeming at btopenworld.com Mon May 17 18:01:16 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 17 May 2004 23:01:16 +0100 Subject: [XForms] [patch] API pseudo changes Message-ID: <200405172301.16660.angus.leeming@btopenworld.com> The attached patch partially reverts the appearance of the API to that of XForms 0.89 patch level 5. In all cases, this is just a case of using the typedef rather than the raw type. In all cases, this results in a clearer intent. The patch seems completely uncontroversial to me. Any objections, or should I just shove it in? While I'm at it, several functions that were declared using 'unsigned int' are now declared using 'unsigned'. Eg: -Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned int *); +Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned *); Again, they're equivalent, but I fail to see why the change was a good one. Shall I change them back? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: api.diff Type: text/x-diff Size: 15893 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040517/1d43495a/attachment.bin From jac4 at mindless.com Mon May 17 19:39:17 2004 From: jac4 at mindless.com (jason cipriani) Date: Mon, 17 May 2004 18:39:17 -0500 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) Message-ID: <20040517233917.188FC79004A@ws1-14.us4.outblaze.com> Ok, tested the context sharing on Redhat 9.0 with a GeForce 4 and some version of XFree86 that isn't the newest one (can't remember the version number). It works fine. On a slightly different note, the reason I'm not using the newest XFree86 is that I had been running Fedora 1 on this machine with the latest version, and I was having problems with xforms apps that used GL (with an unmodified xforms 1.0) crashing the X server itself when I called fl_free_form() or fl_finish(). I didn't look into it any further as Fedora was already getting on my nerves, I just switched to Redhat and kept the old version of the X server. I'll get to the bottom of that someday but if anybody had a similar experience maybe they've already done some investigation. It only occured on that one machine so it could have been -anything-. > Jason, I think that we should hold off on this until after XForms 1.1 > is out of the door. It's big, big, big and we're very close to a > release. :_( However, I did get another idea for another feature to add to the context sharing stuff, I'll keep you posted. Also, how come every time I respond to a message on this mail list I break the thread in the archives? Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jac4 at mindless.com Tue May 18 01:32:35 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue, 18 May 2004 00:32:35 -0500 Subject: [XForms] Patch: Off-screen GLXContext in context sharing pools. Message-ID: <20040518053235.C53EC101C3@ws1-16.us4.outblaze.com> > However, I did get another idea for another feature to add to the context sharing stuff, I'll keep you posted. I appear to be on a roll. Here's a patch for the context sharing patch, in a manner of speaking. This patch provides three new API functions in glcanvas.c/ .h: - fl_enable_sglpool_persistence() - fl_disable_sglpool_persistence() - fl_is_sglpool_persistent() This patch also #defines SGLDEBUG to 0 in glcanvas.c to disable debugging output, and removes a #define that was no longer needed that I forgot to get rid of (MAXPOOLNAMELEN or something). Additonally, there is also an update for the test program that was included in the last patch and the "documentation" (sglcanvas.html) as well. Using patch -p1, these diff files may be applied like so: 1) Obtain fresh copy of xforms-1.0.90. Do the following before ./configure: 2) Apply Angus' GL_CANVAS_LOCATION patch (this is for the demo program -- you don't have to do it but you'll have to modify the demo program to use whatever system for including GL/glx.h and glcanvas.h is in place). 3) Download first patch, extract it. 4) Apply $FIRST_PATCH/patch.diff in xforms-1.0.90/ --- 5) Download second patch, extract it. 6) Apply $SECOND_PATCH/patch2.diff in xforms-1.0.90/ 7) Apply $SECOND_PATCH/demo.diff in $FIRST_PATCH/demo/ 8) Apply $SECOND_PATCH/doc.diff in $FIRST_PATCH/ --- 9) Build and install xforms as usual, then build demo which still may require some Makefile tweaking. patch2.diff updates gl/glcanvas.c and gl/glcanvas.h. I now consider the context sharing stuff finished. Although, now that I'm feeling familiar with the fdesign source and I'm done with school, expect some neato fdesign code in the next few weeks ;) . Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: patch2.tgz Type: application/octet-stream Size: 6852 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040518/0b173d88/attachment.obj From angus.leeming at btopenworld.com Tue May 18 03:51:33 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 08:51:33 +0100 Subject: [XForms] Patch: Context Sharing + fdesign (real thing) In-Reply-To: <20040517233917.188FC79004A@ws1-14.us4.outblaze.com> References: <20040517233917.188FC79004A@ws1-14.us4.outblaze.com> Message-ID: <200405180851.33642.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 12:39 am, jason cipriani wrote: > > Jason, I think that we should hold off on this until after XForms > > 1.1 is out of the door. It's big, big, big and we're very close > > to a release. > > > :_( Don't worry. It'd be nice to release little and often in the future. This time around there has been a huge amount of 'bookkeeping' work to move the tree over to the use of the GNU autotools. I anticipate that *nothing* we do in the future will be so disruptive. > Also, how come every time I respond to a message on this mail list > I break the thread in the archives? Dunno, but I don't think it's just you. Angus From angus.leeming at btopenworld.com Tue May 18 04:57:05 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 09:57:05 +0100 Subject: [XForms] [patch] API pseudo changes In-Reply-To: <200405172301.16660.angus.leeming@btopenworld.com> References: <200405172301.16660.angus.leeming@btopenworld.com> Message-ID: <200405180957.05377.angus.leeming@btopenworld.com> On Monday 17 May 2004 11:01 pm, Angus Leeming wrote: > The attached patch partially reverts the appearance of the API to > that of XForms 0.89 patch level 5. In all cases, this is just a > case of using the typedef rather than the raw type. In all cases, > this results in a clearer intent. > > The patch seems completely uncontroversial to me. Any objections, > or should I just shove it in? I committed it. Angus From angus.leeming at btopenworld.com Tue May 18 05:25:15 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 10:25:15 +0100 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms 0.89 Message-ID: <200405181025.15390.angus.leeming@btopenworld.com> Jean-Marc, all, I think that below are all the genuine API changes to forms.h since XForms 0.89. AFAICS, there is only one genuine regression and that it probably trivial. Nonetheless, I guess we should #define fl_set_error_logfp fl_set_err_logfp. I don't see any implications in passing 'unsigned long' to functions that used to receive 'unsigned' vars. Are there any implications when using shared objects? I don't see any implications at all to returning an 'int' from functions that were previously declared as 'void'. I have no feeling whatsoever about the implications of functions previously receiving 'char *' that now receive 'char []'. Once these points have been nailed down, it'll be trivial to document these changes. Angus New static constants: FL_ARGUMENT = -3, FL_ALLOC = -4, FL_BAD_OBJECT = -5 New FL_EVENTS: FL_MOVEORIGIN, /* dragging the form across the screen changes its absolute x,y coords. Objects that themselves contain forms should ensure that they are up to date. */ FL_RESIZED /* The object has been resized by scale_form Tell it that this has happened so that it can resize any FL_FORMs that it contains. */ -FL_EXPORT unsigned long fl_msleep(unsigned); +FL_EXPORT unsigned long fl_msleep(unsigned long); -FL_EXPORT FL_RAW_CALLBACK fl_register_raw_callback(FL_FORM *, unsigned, FL_RAW_CALLBACK); +FL_EXPORT FL_RAW_CALLBACK fl_register_raw_callback(FL_FORM *, unsigned long, FL_RAW_CALLBACK); -FL_EXPORT void fl_set_error_logfp(FILE *); +FL_EXPORT void fl_set_err_logfp(FILE *); -#define FL_CHART_MAX 512 +#define FL_CHART_MAX 2048 -FL_EXPORT void fl_set_chart_maxnumb(FL_OBJECT *, int); +FL_EXPORT int fl_set_chart_maxnumb(FL_OBJECT *, int); +FL_EXPORT void fl_set_chart_baseline(FL_OBJECT *, int); +enum +{ + FL_TRIANGLE_UPBOX1, + FL_TRIANGLE_UPBOX2, + FL_TRIANGLE_UPBOX3, + FL_TRIANGLE_UPBOX4, + FL_TRIANGLE_UPBOX6, + FL_TRIANGLE_UPBOX7, + FL_TRIANGLE_UPBOX8, + FL_TRIANGLE_UPBOX9, + FL_TRIANGLE_DOWNBOX1, + FL_TRIANGLE_DOWNBOX2, + FL_TRIANGLE_DOWNBOX3, + FL_TRIANGLE_DOWNBOX4, + FL_TRIANGLE_DOWNBOX6, + FL_TRIANGLE_DOWNBOX7, + FL_TRIANGLE_DOWNBOX8, + FL_TRIANGLE_DOWNBOX9 +}; +typedef void (*FL_ERROR_FUNC)( const char *, const char *,... ); +typedef const char *(*FL_VAL_FILTER) (FL_OBJECT *, double, int); +/** Functions to set and get the timeout value used by the + * counter code to control modification of the counter value. + */ +FL_EXPORT int fl_get_counter_repeat(FL_OBJECT *); +FL_EXPORT void fl_set_counter_repeat(FL_OBJECT *, int); -FL_EXPORT char *fl_fix_dirname(char *); +FL_EXPORT char *fl_fix_dirname(char dir[]); +FL_EXPORT int fl_goodies_atclose(FL_FORM *, void *); +/** Functions to set and get the timeout value used by the + slider code to increment the position of the knob. + */ +FL_EXPORT int fl_get_slider_repeat(FL_OBJECT *); +FL_EXPORT void fl_set_slider_repeat(FL_OBJECT *, int); -FL_EXPORT void fl_set_xyplot_data(FL_OBJECT *, float *, float *, int, const char *, const char *, const char *); +FL_EXPORT int fl_set_xyplot_data(FL_OBJECT *, float *, float *, int, const char *, const char *, const char *); +FL_EXPORT int fl_set_xyplot_data_double(FL_OBJECT *, double *, double *, int, const char *, const char *, const char *); +/* Replace the value of a particular point in dataset setID, + * where setID=0 is the first data set. + * This routine is an extension of fl_replace_xyplot_point + * which acts on the first dataset only. + */ +FL_EXPORT void fl_replace_xyplot_point_in_overlay(FL_OBJECT *, int, int, double, double); -FL_EXPORT void fl_get_glcanvas_defaults(int *); +FL_EXPORT void fl_get_glcanvas_defaults(int[]); From angus.leeming at btopenworld.com Tue May 18 05:27:34 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 10:27:34 +0100 Subject: [XForms] API regression to flimage.h on 64 bit machines since XForms 0.89 Message-ID: <200405181027.34232.angus.leeming@btopenworld.com> The change below assumes that a sizeof(pointer) == 4. Not so on 64 bit machines. How should we address this? Angus typedef struct flimage_ { int type; /* image type */ @@ -279,8 +311,10 @@ int isPixmap; FLIMAGESETUP setup; char *info; - int internal_reserved[16]; + struct flimage_src_ *src; /* src other than file */ + struct flimage_dest_ *dest; /* destination other than file */ + int internal_reserved[14]; } FL_IMAGE; From Jean-Marc.Lasgouttes at inria.fr Tue May 18 08:00:56 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 May 2004 14:00:56 +0200 Subject: [XForms] [patch] API pseudo changes In-Reply-To: <200405172301.16660.angus.leeming@btopenworld.com> (Angus Leeming's message of "Mon, 17 May 2004 23:01:16 +0100") References: <200405172301.16660.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list The attached patch partially Angus> reverts the appearance of the API to that of XForms 0.89 patch Angus> level 5. In all cases, this is just a case of using the typedef Angus> rather than the raw type. In all cases, this results in a Angus> clearer intent. Angus> The patch seems completely uncontroversial to me. Any Angus> objections, or should I just shove it in? It looks like the right thing to do, but I do not understand why things have been changed previously. There has to be a reason, don't you think? Angus> While I'm at it, several functions that were declared using Angus> 'unsigned int' are now declared using 'unsigned'. Eg: Angus> -Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned int *); Angus> +Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned *); Angus> Again, they're equivalent, but I fail to see why the change was Angus> a good one. Shall I change them back? I think so. JMarc From angus.leeming at btopenworld.com Tue May 18 08:06:26 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 13:06:26 +0100 Subject: [XForms] [patch] API pseudo changes In-Reply-To: References: <200405172301.16660.angus.leeming@btopenworld.com> Message-ID: <200405181306.26752.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 1:00 pm, Jean-Marc Lasgouttes wrote: > Angus> The patch seems completely uncontroversial to me. Any > Angus> objections, or should I just shove it in? > > It looks like the right thing to do, but I do not understand why > things have been changed previously. There has to be a reason, > don't you think? I'm not so sure. The old closed-source development was so fragmented, with different versions for different architectures, that it may well be that the stuff I grabbed as ftp://ncmir.ucsd.edu/pub/xforms/Attic/linux/elf/bxform-089-glibc2.1.tgz was not the basis for the open source release. > Angus> While I'm at it, several functions that were declared using > Angus> 'unsigned int' are now declared using 'unsigned'. Eg: > > Angus> -Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned int > *); Angus> +Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned > *); > > Angus> Again, they're equivalent, but I fail to see why the change > was Angus> a good one. Shall I change them back? > > I think so. Ok, dokey. I'll have a go. Angus From Jean-Marc.Lasgouttes at inria.fr Tue May 18 08:08:36 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 May 2004 14:08:36 +0200 Subject: [XForms] API regression to flimage.h on 64 bit machines since XForms 0.89 In-Reply-To: <200405181027.34232.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 18 May 2004 10:27:34 +0100") References: <200405181027.34232.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list The change below assumes that Angus> a sizeof(pointer) == 4. Not so on 64 bit machines. How should Angus> we address this? I would say that keeping binary compatibility with 1.0 is more important than keeping it with 0.89. So let's leave things as they are. JMarc From angus.leeming at btopenworld.com Tue May 18 08:10:44 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 13:10:44 +0100 Subject: [XForms] API regression to flimage.h on 64 bit machines since XForms 0.89 In-Reply-To: References: <200405181027.34232.angus.leeming@btopenworld.com> Message-ID: <200405181310.44974.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 1:08 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> To subscribers of the xforms list The change below assumes > that Angus> a sizeof(pointer) == 4. Not so on 64 bit machines. How > should Angus> we address this? > > I would say that keeping binary compatibility with 1.0 is more > important than keeping it with 0.89. So let's leave things as they > are. Ok. Anyway, all this info should make it easy for you to document the changes ;-) Angus From Jean-Marc.Lasgouttes at inria.fr Tue May 18 08:12:12 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 May 2004 14:12:12 +0200 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms 0.89 In-Reply-To: <200405181025.15390.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 18 May 2004 10:25:15 +0100") References: <200405181025.15390.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list Jean-Marc, all, Angus> I think that below are all the genuine API changes to forms.h Angus> since XForms 0.89. AFAICS, there is only one genuine regression Angus> and that it probably trivial. Nonetheless, I guess we should Angus> #define fl_set_error_logfp fl_set_err_logfp. Yes. Angus> I don't see any implications in passing 'unsigned long' to Angus> functions that used to receive 'unsigned' vars. Are there any Angus> implications when using shared objects? It might be that binary compatibility is not kept. However, the harm is done in 1.0 already, I guess. Angus> I don't see any implications at all to returning an 'int' from Angus> functions that were previously declared as 'void'. Don't know. Angus> I have no feeling whatsoever about the implications of Angus> functions previously receiving 'char *' that now receive 'char Angus> []'. Don't know. Angus> Once these points have been nailed down, it'll be trivial to Angus> document these changes. Yes. Concerning the constants, we should document what they are good for. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue May 18 08:13:44 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 May 2004 14:13:44 +0200 Subject: [XForms] xforms on windows? In-Reply-To: <40A1D2D8.4000608@CeBiTec.Uni-Bielefeld.DE> (Dirk Evers's message of "Wed, 12 May 2004 09:31:36 +0200") References: <40A1D2D8.4000608@CeBiTec.Uni-Bielefeld.DE> Message-ID: >>>>> "Dirk" == Dirk Evers writes: Dirk> To subscribers of the xforms list This is probably documented Dirk> somewhere... :-) Dirk> Is there a version of xforms for windows? What do I need to use Dirk> it? I know about fltk, but I would prefer not having to rewrite Dirk> for it. Xforms 1.0 and 1.0.90 should compile fine on windows, but one needs to use cygwin (aka unix-on-windows) and a X server. There is no native windows support. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue May 18 08:15:33 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 May 2004 14:15:33 +0200 Subject: [XForms] API regression to flimage.h on 64 bit machines since XForms 0.89 In-Reply-To: <200405181310.44974.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 18 May 2004 13:10:44 +0100") References: <200405181027.34232.angus.leeming@btopenworld.com> <200405181310.44974.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Anyway, all this info should make it easy for you to document Angus> the changes ;-) You almost got me :) I'd rather not have to do it now, since this week is going to be very short for me (as in, only one day left with plenty of work). JMarc From Jean-Marc.Lasgouttes at inria.fr Tue May 18 09:01:33 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 May 2004 15:01:33 +0200 Subject: [XForms] xyplot patch, OS X compatibility In-Reply-To: <70579D31-A239-11D8-9713-003065E23D38@mac.com> (drriddle@mac.com's message of "Sun, 9 May 2004 23:20:58 -0500") References: <70579D31-A239-11D8-9713-003065E23D38@mac.com> Message-ID: >>>>> "drriddle" == drriddle writes: drriddle> To subscribers of the xforms list Howdy all, drriddle> A while ago, I put up a patch for the drriddle> fl_replace_xyplot_point routine that would allow one to drriddle> change the value of an overlay point (the current version drriddle> only allows you to change the value of the main data plot drriddle> point). Did that make it into the new version of the drriddle> library? Hmm, could you post it again? I have lost track. drriddle> Also, you should be able to use the instructions at drriddle> http://wet.physics.iastate.edu/Tools/xqed/index.html drriddle> to compile Xforms under Mac OS X, version 10.3. I'll test drriddle> that again once the new version of the library comes out, drriddle> just to make sure it still works. Concerning the information on the page: - the new release versions, like 1.0.90 do not require to have autoconf 2.5x. The autotools are only needed when one builds from cvs. - I do not see any reason why it would not build on redhat 7. I would be interested by reports of the contrary. - On Mac OS X, the configure options should read --with-extra-inc and not --with_extra_inc. Actually, one can use --with-extra-prefix=/sw, which will replace the two statements. Hope this helps. There is some information on building xforms in the README file. If you can suggest some modifications to accommodate OS X peculiarities, they will be welcome. JMarc From angus.leeming at btopenworld.com Tue May 18 09:05:01 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 14:05:01 +0100 Subject: [XForms] xyplot patch, OS X compatibility In-Reply-To: References: <70579D31-A239-11D8-9713-003065E23D38@mac.com> Message-ID: <200405181405.01930.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 2:01 pm, Jean-Marc Lasgouttes wrote: > drriddle> A while ago, I put up a patch for the > drriddle> fl_replace_xyplot_point routine that would allow one to > drriddle> change the value of an overlay point (the current version > drriddle> only allows you to change the value of the main data plot > drriddle> point). Did that make it into the new version of the > drriddle> library? > > Hmm, could you post it again? I have lost track. It's now in the cvs tree as 'fl_replace_xyplot_point_in_overlay' Angus From Jean-Marc.Lasgouttes at inria.fr Tue May 18 09:10:47 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 May 2004 15:10:47 +0200 Subject: [XForms] xyplot patch, OS X compatibility In-Reply-To: <200405181405.01930.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 18 May 2004 14:05:01 +0100") References: <70579D31-A239-11D8-9713-003065E23D38@mac.com> <200405181405.01930.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> Hmm, could you post it again? I have lost track. Angus> It's now in the cvs tree as Angus> 'fl_replace_xyplot_point_in_overlay' Thanks. JMarc From Jean-Marc.Lasgouttes at inria.fr Tue May 18 09:18:01 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 18 May 2004 15:18:01 +0200 Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: (Mike Heffner's message of "Wed, 05 May 2004 18:12:15 -0400 (EDT)") References: Message-ID: >>>>> "Mike" == Mike Heffner writes: Mike> Whichever would prevent it from being displayed if libforms is Mike> not compiled in debug mode. When is M_warn() printed? I think this is controlled by the -debug switch to xforms apps. I am not sure what should go in which level, but I guess level 1 is OK in this case. JMarc From angus.leeming at btopenworld.com Tue May 18 09:58:44 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 14:58:44 +0100 Subject: [XForms] [patch] API pseudo changes In-Reply-To: References: <200405172301.16660.angus.leeming@btopenworld.com> Message-ID: <200405181458.44602.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 1:00 pm, Jean-Marc Lasgouttes wrote: > Angus> While I'm at it, several functions that were declared using > Angus> 'unsigned int' are now declared using 'unsigned'. Eg: > > Angus> -Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned int > *); Angus> +Window fl_get_mouse(FL_Coord *, FL_Coord *, unsigned > *); > > Angus> Again, they're equivalent, but I fail to see why the change > was Angus> a good one. Shall I change them back? > > I think so. I wrote a little script to do it everywhere. Not very elegant, but did the job. Patch attached and committed. Angus #! /bin/sh TMP=tmp for dir in demos fd2ps fdesign gl image lib do DATA=`grep -n -r unsigned $dir | \ sed 's/unsigned *long//g s/unsigned *int//g s/unsigned *char//g s/unsigned *short//g /unsigned/!d'` echo "$DATA" | while read LINE do FILE=`echo $LINE | cut -d':' -f1` LN=`echo $LINE | cut -d':' -f2` test "$FILE" != "" -a "$LN" != "" || continue sed "${LN} s/unsigned/unsigned int/g; s/\(unsigned int\) int/\1/" ${FILE} > $TMP cmp -s $FILE $TMP && continue diff -u $FILE $TMP #mv -f $TMP $FILE done done -------------- next part -------------- A non-text attachment was scrubbed... Name: uint.diff.bz2 Type: application/x-bzip2 Size: 8774 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040518/02afbcb6/attachment.bz2 From Todd.Denniston at ssa.crane.navy.mil Tue May 18 10:07:27 2004 From: Todd.Denniston at ssa.crane.navy.mil (Todd Denniston) Date: Tue, 18 May 2004 09:07:27 -0500 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms 0.89 References: <200405181025.15390.angus.leeming@btopenworld.com> Message-ID: <40AA189F.1EA025FF@ssa.crane.navy.mil> Angus Leeming wrote: > > To subscribers of the xforms list > > Jean-Marc, all, > > I think that below are all the genuine API changes to forms.h since > XForms 0.89. AFAICS, there is only one genuine regression and that it > probably trivial. Nonetheless, I guess we should > #define fl_set_error_logfp fl_set_err_logfp. > Don't know don't care. > I don't see any implications in passing 'unsigned long' to functions > that used to receive 'unsigned' vars. Are there any implications when > using shared objects? > Probably not with gcc (int and long are 32 bits), might be with other compilers. > I don't see any implications at all to returning an 'int' from > functions that were previously declared as 'void'. > void means no return value, int means there is an integer return value. if the user wants to ignore the return value, that is probably fine, I think some compiler settings will warn on ignoreing return values. However if the function is defined as an int it should ALWAYS exit by returning an integer. I have not looked at the code for the function(s) you are refering too, but as long as there is a reason (return value) for them to be int all is good. > I have no feeling whatsoever about the implications of functions > previously receiving 'char *' that now receive 'char []'. > I suppose they are equivilent but the 'char *' has always been more clear to me and more common in the code I have recived. If you like the new way go with it. > Once these points have been nailed down, it'll be trivial to document > these changes. > > Angus > -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter From angus.leeming at btopenworld.com Tue May 18 10:14:00 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 15:14:00 +0100 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms 0.89 In-Reply-To: <40AA189F.1EA025FF@ssa.crane.navy.mil> References: <200405181025.15390.angus.leeming@btopenworld.com> <40AA189F.1EA025FF@ssa.crane.navy.mil> Message-ID: <200405181514.00848.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 3:07 pm, Todd Denniston wrote: > > I have no feeling whatsoever about the implications of functions > > previously receiving 'char *' that now receive 'char []'. > > I suppose they are equivilent but the 'char *' has always been more > clear to me and more common in the code I have recived. If you like > the new way go with it. Thanks for the reassurances, Todd. I guess that the new way is marginally safer, but I was more concerned that code compiled with the old header would continue to compile with the new one. As a guy who wrote fortran and then moved to c++, it all looks ugly ;-) Angus From jac4 at mindless.com Tue May 18 13:18:27 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue, 18 May 2004 12:18:27 -0500 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms0.89 Message-ID: <20040518171827.79F621F4FEB@ws1-12.us4.outblaze.com> > Angus> I don't see any implications in passing 'unsigned long' to > Angus> functions that used to receive 'unsigned' vars. Are there any > Angus> implications when using shared objects? > > It might be that binary compatibility is not kept. However, the harm > is done in 1.0 already, I guess. > > Angus> I don't see any implications at all to returning an 'int' from > Angus> functions that were previously declared as 'void'. > > Don't know. As far as coding go it would only break code that took addresses of these functions and assumed they had a certain type. Should be easy to fix in any apps that do that, though. > Angus> To subscribers of the xforms list The change below assumes that > Angus> a sizeof(pointer) == 4. Not so on 64 bit machines. How should > Angus> we address this? It assumed that sizeof(pointer) == sizeof(int), and 2 byte ints are allowed. If you are trying to keep the size of the structure constant then perhaps it would make more sense to change it to: - int internal_reserved[16]; + struct flimage_src_ *src; /* src other than file */ + struct flimage_dest_ *dest; /* destination other than file */ + char internal_reserved[64 - 2 * sizeof(void *)]; In other words, make the decision right now that internal_reserved is 64 bytes. Cross your fingers that nobody (who can't rebuild their apps after the header change) relied on internal_reserved being 64 bytes on a system with ints that weren't 4 bytes, and then it becomes simple to change it predictably in the future. > I think some compiler settings will warn on ignoreing return values. Is that the case? Even with -Wall -pedantic gcc doesn't warn. It's also perfectly legal to do things like: { 0; } There really shouldn't be any problem converting void returns to int returns other than function pointer problems and shared library dynamic linking (dunno how it's done on non-Windows, and it may not even have a problem as C function names aren't mangled based on their return value). Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From xyzzy at speakeasy.org Tue May 18 13:52:53 2004 From: xyzzy at speakeasy.org (Trent Piepho) Date: Tue, 18 May 2004 10:52:53 -0700 (PDT) Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms0.89 In-Reply-To: <20040518171827.79F621F4FEB@ws1-12.us4.outblaze.com> Message-ID: On Tue, 18 May 2004, jason cipriani wrote: > > There really shouldn't be any problem converting void returns to int returns other than function pointer problems and shared > library dynamic linking (dunno how it's done on non-Windows, and it may not even have a problem as C function names aren't > mangled based on their return value). Why is it you want to change void returns to int returns, for functions that don't return a value? You get warning in the function is compiled: bar.c:1: warning: `return' with no value, in function returning non-void From jac4 at mindless.com Tue May 18 15:34:03 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue, 18 May 2004 14:34:03 -0500 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms0.89 Message-ID: <20040518193403.D2DA8164036@ws1-15.us4.outblaze.com> > Why is it you want to change void returns to int returns, for functions that > don't return a value? Wasn't my idea! > You get warning in the function is compiled: > > bar.c:1: warning: `return' with no value, in function returning non-void That's only if you don't return anything, as in: int func (void) { return; } The situation in question is this: int func (void) { return 0; } func(); Where you call func() (which is properly written) but do nothing with the return value. At least... I think it's the case. I don't think Angus was planning on changing a bunch of void-returning functions to int without actually making them return an error/success status... right? -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Tue May 18 15:41:38 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 18 May 2004 20:41:38 +0100 Subject: [XForms] Genuine API changes to forms.h, glcanvas.h since XForms0.89 In-Reply-To: <20040518193403.D2DA8164036@ws1-15.us4.outblaze.com> References: <20040518193403.D2DA8164036@ws1-15.us4.outblaze.com> Message-ID: <200405182041.38728.angus.leeming@btopenworld.com> On Tuesday 18 May 2004 8:34 pm, jason cipriani wrote: > At least... I think it's the case. I don't think Angus was planning > on changing a bunch of void-returning functions to int without > actually making them return an error/success status... right? Correct. I'm just trying to document changes that occured sometime during the 0.89 -> 1.0 interval. Specifically: API changes from XForms 0.89 to XForms 1.0 ========================================== fl_set_chart_maxnumb now returns FL_ARGUMENT (== -3) if maxnum < 0 FL_ALLOC (== -4) if the chart object previously had no space allocated for these values. 0 if the object was resized and re-displayed successfully. -FL_EXPORT void fl_set_chart_maxnumb(FL_OBJECT *, int maxnum); +FL_EXPORT int fl_set_chart_maxnumb(FL_OBJECT *, int maxnum); Now returns 0 on success. FL_ALLOC if unable to allocate sufficient memory to the object. -FL_EXPORT void fl_set_xyplot_data(FL_OBJECT *, float *, float *, int, const char *, const char *, const char *); +FL_EXPORT int fl_set_xyplot_data(FL_OBJECT *, float *, float *, int, const char *, const char *, const char *); From Jens.Toerring at physik.fu-berlin.de Wed May 19 09:42:39 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Wed, 19 May 2004 15:42:39 +0200 Subject: [XForms] Figuring out a windows state Message-ID: <20040519134239.GA30072@crowley.physik.fu-berlin.de> Hi, I have just a stupid question. I would like to find out if a certain window is iconified or not. I looked throught the documen- tation and also tried to find something fitting in the sources but to no avail, no function seems to exist that helps me finding that out. So, do I have to do that myself using XGetWindowProperty() or something similar or am I just not looking carefully enough? Thanks, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From angus.leeming at btopenworld.com Wed May 19 09:52:19 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 May 2004 14:52:19 +0100 Subject: [XForms] Figuring out a windows state In-Reply-To: <20040519134239.GA30072@crowley.physik.fu-berlin.de> References: <20040519134239.GA30072@crowley.physik.fu-berlin.de> Message-ID: <200405191452.19272.angus.leeming@btopenworld.com> On Wednesday 19 May 2004 2:42 pm, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > > Hi, > > I have just a stupid question. I would like to find out if a > certain window is iconified or not. I looked throught the documen- > tation and also tried to find something fitting in the sources but > to no avail, no function seems to exist that helps me finding that > out. So, do I have to do that myself using XGetWindowProperty() > or something similar or am I just not looking carefully enough? No, you're looking closely enough. FWIW, this is how LyX goes about showing an iconified window. HTH, Angus if (form()->visible) { fl_raise_form(form()); /* This XMapWindow() will hopefully ensure that * iconified dialogs are de-iconified. Mad props * out to those crazy Xlib guys for forgetting a * XDeiconifyWindow(). At least WindowMaker, when * being notified of the redirected MapRequest will * specifically de-iconify. From source, fvwm2 seems * to do the same. */ XMapWindow(fl_get_display(), form()->window); } else { // calls to fl_set_form_minsize/maxsize apply only to the next // fl_show_form(), so this comes first. fl_set_form_minsize(form(), minw_, minh_); if (!allow_resize_) fl_set_form_maxsize(form(), minw_, minh_); string const maximize_title = "LyX: " + title_; int const iconify_policy = getController().IconifyWithMain() ? FL_TRANSIENT : 0; fl_show_form(form(), FL_PLACE_MOUSE | FL_FREE_SIZE, iconify_policy, maximize_title.c_str()); } From Jens.Toerring at physik.fu-berlin.de Wed May 19 10:10:57 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Wed, 19 May 2004 16:10:57 +0200 Subject: [XForms] Figuring out a windows state In-Reply-To: <200405191452.19272.angus.leeming@btopenworld.com> References: <20040519134239.GA30072@crowley.physik.fu-berlin.de> <200405191452.19272.angus.leeming@btopenworld.com> Message-ID: <20040519141057.GA30160@crowley.physik.fu-berlin.de> On Wed, May 19, 2004 at 02:52:19PM +0100, Angus Leeming wrote: > On Wednesday 19 May 2004 2:42 pm, Jens Thoms Toerring wrote: > > To subscribers of the xforms list > > I have just a stupid question. I would like to find out if a > > certain window is iconified or not. I looked throught the documen- > > tation and also tried to find something fitting in the sources but > > to no avail, no function seems to exist that helps me finding that > > out. So, do I have to do that myself using XGetWindowProperty() > > or something similar or am I just not looking carefully enough? > > No, you're looking closely enough. > > FWIW, this is how LyX goes about showing an iconified window. > > HTH, > Angus > > if (form()->visible) { > fl_raise_form(form()); > /* This XMapWindow() will hopefully ensure that > * iconified dialogs are de-iconified. Mad props > * out to those crazy Xlib guys for forgetting a > * XDeiconifyWindow(). At least WindowMaker, when > * being notified of the redirected MapRequest will > * specifically de-iconify. From source, fvwm2 seems > * to do the same. > */ > XMapWindow(fl_get_display(), form()->window); > } else { > // calls to fl_set_form_minsize/maxsize apply only to the next > // fl_show_form(), so this comes first. > fl_set_form_minsize(form(), minw_, minh_); > if (!allow_resize_) > fl_set_form_maxsize(form(), minw_, minh_); > > string const maximize_title = "LyX: " + title_; > int const iconify_policy = > getController().IconifyWithMain() ? FL_TRANSIENT : 0; > > fl_show_form(form(), > FL_PLACE_MOUSE | FL_FREE_SIZE, > iconify_policy, > maximize_title.c_str()); > } Thanks, but as far as a quick test shows me form()->visible seems only to tell me if the window is mapped, it doesn't seem to make a difference if the window is fully visible or iconified. So what your code seems to, as far as I understand it, is to make sure a window gets de-iconified. But for my problem I need to know if a window is iconfied because I take that as a hint from the user on how to continue within the program. So, I probably will have to figure out how to get XGetWindowProperty() to tell me ;-) Thanks, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From angus.leeming at btopenworld.com Wed May 19 10:38:56 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Wed, 19 May 2004 15:38:56 +0100 Subject: [XForms] Figuring out a windows state In-Reply-To: <20040519141057.GA30160@crowley.physik.fu-berlin.de> References: <20040519134239.GA30072@crowley.physik.fu-berlin.de> <200405191452.19272.angus.leeming@btopenworld.com> <20040519141057.GA30160@crowley.physik.fu-berlin.de> Message-ID: <200405191538.56053.angus.leeming@btopenworld.com> On Wednesday 19 May 2004 3:10 pm, Jens Thoms Toerring wrote: > Thanks, but as far as a quick test shows me form()->visible seems > only to tell me if the window is mapped, it doesn't seem to make a > difference if the window is fully visible or iconified. So what > your code seems to, as far as I understand it, is to make sure a > window gets de-iconified. But for my problem I need to know if a That's correct. We've never needed to know whether a window is iconified, only to ensure that it is de-iconified. > But for my problem I need to know if a > window is iconfied because I take that as a hint from the user on > how to continue within the program. So, I probably will have to > figure out how to get XGetWindowProperty() to tell me ;-) Ok. The Qt sources have lots of examples of XGetWindowProperty in action. See qapplication_x11.cpp at http://tinyurl.com/27r3m HTH, Angus From msz at astrouw.edu.pl Wed May 19 10:49:02 2004 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Wed, 19 May 2004 16:49:02 +0200 Subject: [XForms] subpixel sampling in image scaling - does it work? Message-ID: <20040519144902.GA29155@astrouw.edu.pl> Hello, I have a simple app displaying several images from a digital camera in a 3x3 grid of small (230x170) canvases, with the main purpose of easy choosing the images for hardcopy prints. The original images are 1840x1232 JPEGs so before displaying I scale them to the canvas' size. I have noticed that the quality of such shrinked images is rather poor so I tried to employ subpixel sampling to make them look better. Strangely, or-ing FLIMAGE_SUBPIXEL flag into the basic flag used in flimage_scale(img[no], w, h, scale_flag) (which used to be FLIMAGE_ASPECT | FLIMAGE_CENTER) DOES NOT change anything. When I imported (ImageMagick's import) single image canvas into a TIFF image file (first, with the flag added and then without it), the resulting two files did not show ANY differences on byte-by-byte comparison (with the one-byte exception at the file name which is also stored in a TIFF image). Any ideas what is wrong here? I can hardly imagine that a typical image (two persons in a garden full of flowers) could yield no differences after any pixel interpolation process. regards, Michal. -- Michal Szymanski (msz at astrouw.edu.pl) Warsaw University Observatory, Warszawa, POLAND From Jens.Toerring at physik.fu-berlin.de Wed May 19 10:51:59 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Wed, 19 May 2004 16:51:59 +0200 Subject: [XForms] Figuring out a windows state In-Reply-To: <200405191538.56053.angus.leeming@btopenworld.com> References: <20040519134239.GA30072@crowley.physik.fu-berlin.de> <200405191452.19272.angus.leeming@btopenworld.com> <20040519141057.GA30160@crowley.physik.fu-berlin.de> <200405191538.56053.angus.leeming@btopenworld.com> Message-ID: <20040519145159.GA30260@crowley.physik.fu-berlin.de> On Wed, May 19, 2004 at 03:38:56PM +0100, Angus Leeming wrote: > The Qt sources have lots of examples of XGetWindowProperty in action. > See qapplication_x11.cpp at http://tinyurl.com/27r3m Thanks a lot, I hope I will be able to figure it out. Best regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From angus.leeming at btopenworld.com Sun May 23 20:42:45 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 24 May 2004 01:42:45 +0100 Subject: [XForms] Re: Xforms-cvs post from emails@hahnebach.com requires approval In-Reply-To: References: Message-ID: <200405240142.45508.angus.leeming@btopenworld.com> Hi, Bernd, I'm afraid that you've posted to the wrong list. xforms-cvs at nongnu.org is a list documenting commits to the xforms-cvs tree. Or it would be if we could get it to work. (Separate problem.) I've forwarded your mail to the xforms development list at . This list is fairly low volume (5 emails / day on a busy day ;-), so I really recommend that you subscribe for a little while. See http://cweblog.usuhs.mil/mailman/listinfo/xforms Hope to see you there, Angus On Sunday 23 May 2004 5:50 pm, xforms-cvs-owner at nongnu.org wrote: > Hi, > > I found the software xstab which I really would like to get > running. The project has been dead for years. The code is GPL. I > was trying to compile it for hours. The GUI is based on xforms > 0.88. It is still listed on > http://world.std.com/~xforms/new/app.html although the home page is > dead. The source code can be found at > http://goemon.polito.it/software/lethal/scheda.php?id=26 > > I installed the already compiled library of xform to /usr/local. > Compiling xstab worked really well for a long time. Than I got the > following: > > ... > /usr/local/lib/libforms.so: undefined reference to `errno' > /usr/local/lib/libforms.so: undefined reference to `_xstat' > collect2: ld returned 1 exit status > make[1]: *** [XStab] Fehler 1 > make[1]: Leaving directory > `/home/hugo/Documents/xstab/programm/XStab/src' make: *** [srcs] > Fehler 2 > hugo at linux:~/Documents/xstab/programm/XStab> > > > I found out it is something regarding newer version gcc. > ("Since version 2.9 of the GCC compiler the compiler has become a > lot stricter over declaring external references. Undefined > reference to ?errno?") > > I am using gcc 3.3 > > For me it seems I need to recompile xforms with gcc 3.3 or I coud > use an older version of gcc. To be honest I really do not have a > glue what to do next. > > > Thanks for any help > Bernd Hahnebach > > I am not a member of the list would you replies mails to emails at > hahnebach.com From angus.leeming at btopenworld.com Sun May 23 20:45:25 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Mon, 24 May 2004 01:45:25 +0100 Subject: [XForms] Fwd: xform 0.88; undefined reference to `errno' Message-ID: <200405240145.25278.angus.leeming@btopenworld.com> Original post was to xforms-cvs at nongun.org. Readership nil. Angus ----------------------- Forwarded message ----------------------- xform 0.88; undefined reference to `errno' Date: Saturday 6:09:31 am From: Bernd Hahnebach To: xforms-cvs at nongnu.org Hi, I found the software xstab which I really would like to get running. The project has been dead for years. The code is GPL. I was trying to compile it for hours. The GUI is based on xforms 0.88. It is still listed on http://world.std.com/~xforms/new/app.html although the home page is dead. The source code can be found at http://goemon.polito.it/software/lethal/scheda.php?id=26 I installed the already compiled library of xform to /usr/local. Compiling xstab worked really well for a long time. Than I got the following: ... /usr/local/lib/libforms.so: undefined reference to `errno' /usr/local/lib/libforms.so: undefined reference to `_xstat' collect2: ld returned 1 exit status make[1]: *** [XStab] Fehler 1 make[1]: Leaving directory `/home/hugo/Documents/xstab/programm/XStab/src' make: *** [srcs] Fehler 2 hugo at linux:~/Documents/xstab/programm/XStab> I found out it is something regarding newer version gcc. ("Since version 2.9 of the GCC compiler the compiler has become a lot stricter over declaring external references. Undefined reference to ?errno?") I am using gcc 3.3 For me it seems I need to recompile xforms with gcc 3.3 or I coud use an older version of gcc. To be honest I really do not have a glue what to do next. Thanks for any help Bernd Hahnebach I am not a member of the list would you replies mails to emails at hahnebach.com -------------- next part -------------- An embedded message was scrubbed... From: xforms-cvs-owner at nongnu.org Subject: Xforms-cvs post from emails at hahnebach.com requires approval Date: Sun, 23 May 2004 12:50:39 -0400 Size: 6207 Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040524/341ca784/attachment.mht From angus.leeming at btopenworld.com Tue May 25 06:46:17 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 25 May 2004 11:46:17 +0100 Subject: [XForms] Re: Fwd: xform 0.88; undefined reference to `errno' In-Reply-To: <200405240145.25278.angus.leeming@btopenworld.com> References: <200405240145.25278.angus.leeming@btopenworld.com> Message-ID: <200405251146.17943.angus.leeming@btopenworld.com> On Monday 24 May 2004 1:45 am, you wrote: > The source code can be found at > http://goemon.polito.it/software/lethal/scheda.php?id=26 I get an 'access denied' message when I try and connect. > I installed the already compiled library of xform to /usr/local. Could you tell me what version of XForms you are using? > /usr/local/lib/libforms.so: undefined reference to `errno' > /usr/local/lib/libforms.so: undefined reference to `_xstat' So you need to also link in the libraries that contain 'errno' and '_xstat'. 'errno' is part of libc. See 'man errno'. Add '-lc' to the options passed to the linker. '_xstat' is an implementation detail of the system 'stat' call. See 'man stat'. It's also part of libc. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Tue May 25 08:14:58 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 25 May 2004 14:14:58 +0200 Subject: [XForms] Re: Fwd: xform 0.88; undefined reference to `errno' In-Reply-To: <200405251146.17943.angus.leeming@btopenworld.com> (Angus Leeming's message of "Tue, 25 May 2004 11:46:17 +0100") References: <200405240145.25278.angus.leeming@btopenworld.com> <200405251146.17943.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> /usr/local/lib/libforms.so: undefined reference to `errno' >> /usr/local/lib/libforms.so: undefined reference to `_xstat' Angus> So you need to also link in the libraries that contain 'errno' Angus> and '_xstat'. Angus> 'errno' is part of libc. See 'man errno'. Add '-lc' to the Angus> options passed to the linker. Angus> '_xstat' is an implementation detail of the system 'stat' call. Angus> See 'man stat'. It's also part of libc. If I remember correctly, this kind of thing can happen when one uses a xforms library which has not been linked against the right glibc version. Bernd, why don't you get the latest xforms version and build it? JMarc From wd4nmq at comcast.net Tue May 25 19:51:37 2004 From: wd4nmq at comcast.net (Jeff) Date: Tue, 25 May 2004 19:51:37 -0400 Subject: [XForms] Where to add entry for forms.h Message-ID: <40B3DC09.9080209@comcast.net> Angus, or anbody, Where do I add the line: FL_CLIENT_CALLBACK client_callback; so it appears in the forms structuer. I thnk it would go into Basic.h. But do I also need to adjust the line int reserved[10]; /* future use */ to include the size of the new client_callback enty in struct FL_FORM in Basic.h I also guess the header declaration FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( FL_FORM *form, FL_CLIENT_CALLBACK rcb ); Would also go into Basic.h. I want to finally submit this patch. Jeff From mheffner at vt.edu Tue May 25 23:58:11 2004 From: mheffner at vt.edu (Mike Heffner) Date: Tue, 25 May 2004 23:58:11 -0400 (EDT) Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: <200405051501.01448.angus.leeming@btopenworld.com> Message-ID: On 05-May-2004 Angus Leeming wrote: | On Thursday 15 January 2004 5:30 am, Mike Heffner wrote: |> When fl_set_font_name() fails it will return -1 but it also prints: |> |> In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah |> |> This function is typically used as a method of testing whether a |> font is loadable or not, so it's not always a fatal condition. Can |> this print statement be wrapped in a debug-only conditional? | | Mike does this do the job: | - M_err("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); | + M_warn("SetFont", "Bad FontStyle request %d: %s", numb, | flf->fname); | How about changing it to M_debug(...)? 'warn' and 'err' essentially always get printed (a bug for another day). Thanks, Mike -- Mike Heffner From angus.leeming at btopenworld.com Thu May 27 11:00:22 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 May 2004 16:00:22 +0100 Subject: [XForms] Where to add entry for forms.h In-Reply-To: <40B3DC09.9080209@comcast.net> References: <40B3DC09.9080209@comcast.net> Message-ID: <200405271600.22916.angus.leeming@btopenworld.com> On Wednesday 26 May 2004 12:51 am, Jeff wrote: > Angus, or anbody, Hello, Jeff. > Where do I add the line: > FL_CLIENT_CALLBACK client_callback; > so it appears in the forms structuer. I thnk it would go into > Basic.h. Sounds correct to me. That's where 'struct forms_' is defined. > But do I also need to adjust the line > int reserved[10]; /* future use */ > > to include the size of the new client_callback enty in struct > FL_FORM in Basic.h That would be nice. It will allow us to maintain binary compatibility with previous versions of the library. You'll want something like int reserved[10 - sizeof(FL_CLIENT_CALLBACK)]; > I also guess the header declaration > FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( > FL_FORM *form, > FL_CLIENT_CALLBACK rcb > ); > > Would also go into Basic.h. Sounds reasonable. > I want to finally submit this patch. Great! Angus From Jean-Marc.Lasgouttes at inria.fr Thu May 27 11:13:30 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 May 2004 17:13:30 +0200 Subject: [XForms] Where to add entry for forms.h In-Reply-To: <200405271600.22916.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 May 2004 16:00:22 +0100") References: <40B3DC09.9080209@comcast.net> <200405271600.22916.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> That would be nice. It will allow us to maintain binary Angus> compatibility with previous versions of the library. You'll Angus> want something like Angus> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)]; This is what I said earlier, but it is wrong. One needs something like int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; JMarc From angus.leeming at btopenworld.com Thu May 27 11:19:24 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 May 2004 16:19:24 +0100 Subject: [XForms] Where to add entry for forms.h In-Reply-To: References: <40B3DC09.9080209@comcast.net> <200405271600.22916.angus.leeming@btopenworld.com> Message-ID: <200405271619.24067.angus.leeming@btopenworld.com> On Thursday 27 May 2004 4:13 pm, Jean-Marc Lasgouttes wrote: > Angus> You'll want something like > Angus> int reserved[10 - sizeof(FL_CLIENT_CALLBACK)]; > This is what I said earlier, but it is wrong. One needs something > like > int reserved[10 - sizeof(FL_CLIENT_CALLBACK)/sizeof(int)]; Just testing. ;-) Incidentally, assuming that this patch arrives, we now have two patches providing new functionality. The other one is the 'context sharing' patch from Jason Cipriani. I'd told Jason that I was not going to include his patch in 1.1 but I'm minded that there isn't actually *anything* new in 1.1, just bug fixes. Do you have any opinion on this? Angus ps, could I get you to roll 1.0.91, given that you made so little fuss getting 1.0.90 out of the door? A From Jean-Marc.Lasgouttes at inria.fr Thu May 27 11:31:43 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 May 2004 17:31:43 +0200 Subject: [XForms] Where to add entry for forms.h In-Reply-To: <200405271619.24067.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 May 2004 16:19:24 +0100") References: <40B3DC09.9080209@comcast.net> <200405271600.22916.angus.leeming@btopenworld.com> <200405271619.24067.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Incidentally, assuming that this patch arrives, we now have two Angus> patches providing new functionality. The other one is the Angus> 'context sharing' patch from Jason Cipriani. Angus> I'd told Jason that I was not going to include his patch in 1.1 Angus> but I'm minded that there isn't actually *anything* new in 1.1, Angus> just bug fixes. Do you have any opinion on this? I do not know really. Jeff's patch should clearly be harmless for people who do not use the functionality. I do not know enough about GL to know whether Jason's patch would be risky. Angus> ps, could I get you to roll 1.0.91, given that you made so Angus> little fuss getting 1.0.90 out of the door? When, right now? Do you plan it to be the last prerelease? In this case, we could name it 1.0.98 or something. JMarc From angus.leeming at btopenworld.com Thu May 27 11:42:14 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 May 2004 16:42:14 +0100 Subject: [XForms] Where to add entry for forms.h In-Reply-To: References: <40B3DC09.9080209@comcast.net> <200405271619.24067.angus.leeming@btopenworld.com> Message-ID: <200405271642.14309.angus.leeming@btopenworld.com> On Thursday 27 May 2004 4:31 pm, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> Incidentally, assuming that this patch arrives, we now have > two Angus> patches providing new functionality. The other one is > the Angus> 'context sharing' patch from Jason Cipriani. > > Angus> I'd told Jason that I was not going to include his patch in > 1.1 Angus> but I'm minded that there isn't actually *anything* new > in 1.1, Angus> just bug fixes. Do you have any opinion on this? > > I do not know really. Jeff's patch should clearly be harmless for > people who do not use the functionality. Then it can go in. > I do not know enough about > GL to know whether Jason's patch would be risky. Me neither, but then again we won't know any better after we it is merged into the tree whenever this is done. Sometimes we just have to go on trust... > Angus> ps, could I get you to roll 1.0.91, given that you made so > Angus> little fuss getting 1.0.90 out of the door? > > When, right now? Do you plan it to be the last prerelease? In this > case, we could name it 1.0.98 or something. Given that Jeff's patch isn't yet here and that we believe it to be harmless, let's wait until it is merged into the tree. The only thing that I think isn't ready for the release of 1.1 proper is this line in configure.ac AC_SUBST(SO_VERSION, ["1:0:0"]) We should also address Lars' concerns about fdesign's output semantics and decide what to do with Jason's patch. Angus From Jean-Marc.Lasgouttes at inria.fr Thu May 27 11:47:06 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 27 May 2004 17:47:06 +0200 Subject: [XForms] Where to add entry for forms.h In-Reply-To: <200405271642.14309.angus.leeming@btopenworld.com> (Angus Leeming's message of "Thu, 27 May 2004 16:42:14 +0100") References: <40B3DC09.9080209@comcast.net> <200405271619.24067.angus.leeming@btopenworld.com> <200405271642.14309.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Me neither, but then again we won't know any better after we it Angus> is merged into the tree whenever this is done. Sometimes we Angus> just have to go on trust... Sure. Angus> The only thing that I think isn't ready for the release of 1.1 Angus> proper is this line in configure.ac AC_SUBST(SO_VERSION, Angus> ["1:0:0"]) Should not be too difficult. Angus> We should also address Lars' concerns about fdesign's output Angus> semantics and decide what to do with Jason's patch. Yes. Also, there is the doc update stuff. JMarc From wd4nmq at comcast.net Thu May 27 14:13:38 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu, 27 May 2004 14:13:38 -0400 Subject: [XForms] Patch help Message-ID: <40B62FD2.2020009@comcast.net> It's been many years since I have made a patch and I am having trouble creating one tht works with Xforms. I untar xforms-1.0.90 and then cp it to mine-1.0.90 and make my changes to files in mine-1.0.90. then from their base directory I run: diff -ruN xforms1.0.90 mine-1.0.90 > xforms.patch Now to test it I go to a vigin directory, copy xforms.patch there and untar xforms.1.0.90 again. Then I run patch -p0 xforms.patch But I get an error: patching file xforms-1.090/lib/forms.c Reversed (or previously applied) patch detected! Assume -R? [n] What am I doing wrong? I want to test out the patch before submitting it today. Jeff From jac4 at mindless.com Thu May 27 14:48:50 2004 From: jac4 at mindless.com (jason cipriani) Date: Thu, 27 May 2004 13:48:50 -0500 Subject: [XForms] Patch help Message-ID: <20040527184850.A39EB790046@ws1-14.us4.outblaze.com> Generate your diff file just like you are doing now: diff -ruN xforms1.0.90 mine-1.0.90 > xforms.patch Then download a fresh copy of xforms, untar it to say, fresh-1.0.90, then do: cd fresh-1.0.90 patch -p1 < ../xforms.patch Don't forget the < in patch. Most versions of 'patch' take input files that way, you can't specify them as command line parameters. The -p1 will tell patch to skip the "xforms1.0.90/" or "mine-1.0.90/" when getting file names from the patch file. Jason ----- Original Message ----- From: Jeff Date: Thu, 27 May 2004 14:13:38 -0400 To: xforms Subject: [XForms] Patch help > To subscribers of the xforms list > > > It's been many years since I have made a patch and I am having trouble > creating one tht works with Xforms. > > I untar xforms-1.0.90 and then cp it to mine-1.0.90 and make my changes > to files in mine-1.0.90. > then from their base directory I run: > > diff -ruN xforms1.0.90 mine-1.0.90 > xforms.patch > > Now to test it I go to a vigin directory, copy xforms.patch there and > untar xforms.1.0.90 again. Then I run > > patch -p0 xforms.patch > > But I get an error: > patching file xforms-1.090/lib/forms.c > Reversed (or previously applied) patch detected! Assume -R? [n] > > What am I doing wrong? > > I want to test out the patch before submitting it today. > > Jeff > > > _______________________________________________ > 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 -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Thu May 27 18:13:56 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 27 May 2004 23:13:56 +0100 Subject: [XForms] Shared GL contexts Message-ID: <200405272313.56243.angus.leeming@btopenworld.com> Jason, attached is your shared GL context patch in a form ready for inclusion in current XForms cvs. I've done little more than rename the files of the demo as demos/sgl.c demos/fd/sgl_gui.fd demos/fd/sgl_help.fd demos/fd/sgl_sub.fd with concommittant changes to the names of the FD_ structs. I've also ensured that the demo will #include forms.h and glcanvas.h from the tree rather than any already-installed versions. To build, I ran: $ ./autogen.sh $ mkdir build && cd build $ ../configure --enable-demos $ make I had a play with the demo. Very pretty ;-) Unfortuanately, I managed to shut down X11 when I exited from the demo. It doesn't do this everytime, but most definitely did do it once. I'd been playing with the main window quite a lot and had managed to 'turn off' the objects in the three left-most sub windows on the top row. I'd popped up the sub window and read the data in the help menu. I can't remember whether all three windows were open when I hit the 'Exit' button on the main form. At that point X died. I'll try and crash it again from within gdb, but this is just a heads up. Incidentally, does anyone know how I can pipe the output from gdb to a file? I'm not going to get much useful info if I run gdb from an xterm if I'm going to end up killing X... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: shared_gl_canvas.diff.gz Type: application/x-gzip Size: 13332 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040527/f294d6bb/attachment.gz From wd4nmq at comcast.net Thu May 27 18:32:05 2004 From: wd4nmq at comcast.net (Jeff) Date: Thu, 27 May 2004 18:32:05 -0400 Subject: [XForms] pathc to add client message callback Message-ID: <40B66C65.8080601@comcast.net> To all, Ok, here is the patch for adding the an X client message handling callback. Why did I do this? I had an app that periodically went to a server to get a list to display in a list box. However, when the server code was in the apps main execution thread the user was "locked out" while all the network DNS lookups, connection to, transfer from, and desconnection took place. Your input was locked out because your main form was not getting events, mouse, keyboard, etc, off of the X event queue. Now, my first step was to thread the server access code. This way the main form's event loop would still run while the data was being retrieved from the server. But, since the Xforms code is not re-entrant, the thread could not just update the xforms list box. You had to do strange girations in the main loop code using mutexes. It's explained in the Xforms manual. This seemed like a lot of work and added even more complexity as more "worker threads" were added. Plus, I had done a Windows C++ app, heh, it pays the bills, that does kinda of the same thing. I had the main thread that handled the gui, and several threads that monitored things and then sent messages to the gui thread's message loop to display the data. X also has a call to that, XSendEvent(). With this you can have different threads, or apps, send messages to another threads or apps windows. One of those messages is called a client message. Now, using the new fl_register_client_message() and fl_get_winID() calls, my server thread simply gets the data and uses XSendEvent() passing the pointer to the data to notify the main form to display the data. No mutexes waits or anthing else. We simply use the event queue that is already in place. As I stated, there are two new functions. The first is FL_EXPORT Window fl_get_winID( FL_FORM *form ); This returns the window id of the form. This is needed by XSendEvent() to know where to send the client message. FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( FL_FORM *form, FL_CLIENT_CALLBACK rcb ); It is used just like any of the xforms calls to register a callback. Here I use it to register clientCallback(). fl_register_client_callback(fd_testEvent->testEvent, (void *) clientCallback); int clientCallback(FL_FORM *form, XEvent *xev){ printf("We are in the client function, time = %d\n", xev->xclient.data.l[0]); return 1; } I then have a thread the periodically uses XSendEvent() to send the current time. Simplistic, but demonstrates it's use. Now you can have several worker threads and only one gui thread and no mutexes or delaying. All the worker threads just send their data via XSendEvent() to a client message event type. Now, there are ways in X to register data types called atoms to disquinish what the data format is. Just look on the web for Xlib Atoms. Also rad up on XSendEvent() which is an Xlib call. Angus and Jean-Marc, if you like I can write a manual section for this. Jeff -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: xform.patch Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040527/4e1f151c/attachment.pl From angus.leeming at btopenworld.com Thu May 27 19:07:14 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 May 2004 00:07:14 +0100 Subject: [XForms] Shared GL contexts Message-ID: <200405280007.14133.angus.leeming@btopenworld.com> On Thursday 27 May 2004 11:13 pm, Angus Leeming wrote: > Unfortuanately, I managed to shut down X11 when I exited from the > demo. It doesn't do this everytime, but most definitely did do it > once. It's actually very easy to do this. $ cd xforms/devel $ cd build $ make maintainer-clean $ cd .. $ rm -rf build $ patch -p0 < shared_gl_canvas.diff $ ./autogen.sh $ mkdir build && cd build $ ../configure --enable-demos $ make demos/sgl is the statically-linked executable. There's also a dynamically-linked executable hidden away in the demos/.libs directory. Now, the dynamically-linked executable isn't going to run as things stand, because the installed libformsGL.so doesn't contain the new functions. So, let's use the statically linked one. $ ./sgl The app pops up as expected. At this point, I'm going to save the mail in the expectation of crashing X. I'll return with the prescription... ... returning having crashed X, here's the prescription: If the 8 sub windows are labelled so: 1 2 3 4 5 6 7 8 Then I can crash X reproducibly by clicking on the buttons: 3:Visible --- hide sub window 3. 2:B --- the object changes to a cone 2:B -- the object disappears from sub windows 1 and 2. 2:C -- usually there is no apparent change. Occasionally X crashes. Exit -- X *always* crashes. Here I'm running a linux box with a stock Fedora Core 1 distribution. Angus From angus.leeming at btopenworld.com Fri May 28 05:51:12 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 May 2004 10:51:12 +0100 Subject: [XForms] [patch] fdesign output Message-ID: <200405281051.12382.angus.leeming@btopenworld.com> The attached patch ensures that fdesign outputs converted files in the current directory if no output_dir is specified. At present, they are output in the same directory as the .fd file. The patch also guarantees that 'build_fname' is safe against buffer overflows. fdesign -convert foo/bar/baz.fd will create bar.[ch] in the current directory. fdesign -dir some/other/dir -convert foo/bar/baz.fd will place bar.[ch] in some/other/dir, if it exists. The fdesign shipped with XForms 1.0 and earlier allowed only fdesign -convert baz.fd Ie, you had to be in the same directory as baz.fd in order to run the conversion. The change results in 'expected behaviour' and has been requested on the lyx list. I see no reason not to commit it, so will do so presently. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: fdesign.diff Type: text/x-diff Size: 2633 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040528/7ab4c462/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Fri May 28 06:53:09 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 May 2004 12:53:09 +0200 Subject: [XForms] [patch] fdesign output In-Reply-To: <200405281051.12382.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 May 2004 10:51:12 +0100") References: <200405281051.12382.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> To subscribers of the xforms list The attached patch ensures Angus> that fdesign outputs converted files in the current directory Angus> if no output_dir is specified. At present, they are output in Angus> the same directory as the .fd file. Angus> The patch also guarantees that 'build_fname' is safe against Angus> buffer overflows. Looks good. What happens with the other converters? JMarc From angus.leeming at btopenworld.com Fri May 28 07:21:40 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 May 2004 12:21:40 +0100 Subject: [XForms] [patch] fdesign output In-Reply-To: References: <200405281051.12382.angus.leeming@btopenworld.com> Message-ID: <200405281221.40311.angus.leeming@btopenworld.com> On Friday 28 May 2004 11:53 am, Jean-Marc Lasgouttes wrote: > Angus> To subscribers of the xforms list The attached patch ensures > Angus> that fdesign outputs converted files in the current > directory Angus> if no output_dir is specified. At present, they > are output in Angus> the same directory as the .fd file. > > Angus> The patch also guarantees that 'build_fname' is safe against > Angus> buffer overflows. > > Looks good. What happens with the other converters? We pass the command line args to them and let them deal with it. All other converters are outside of our control. Ie, they're not part of the XForms library. See fd_forms.c, line 500-ish. From angus.leeming at btopenworld.com Fri May 28 07:36:55 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 28 May 2004 12:36:55 +0100 Subject: [XForms] pathc to add client message callback In-Reply-To: <40B66C65.8080601@comcast.net> References: <40B66C65.8080601@comcast.net> Message-ID: <200405281236.55512.angus.leeming@btopenworld.com> On Thursday 27 May 2004 11:32 pm, Jeff wrote: > To all, > > Ok, here is the patch for adding the an X client message handling > callback. Jeff, many thanks for this. Unfortunately, I won't have time to look at this properly until Tuesday. Jean-Marc, can I leave it to your tender care? Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri May 28 08:01:36 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 May 2004 14:01:36 +0200 Subject: [XForms] [patch] fdesign output In-Reply-To: <200405281221.40311.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 May 2004 12:21:40 +0100") References: <200405281051.12382.angus.leeming@btopenworld.com> <200405281221.40311.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Friday 28 May 2004 11:53 am, Jean-Marc Lasgouttes wrote: To Angus> subscribers of the xforms list The attached patch ensures that Angus> fdesign outputs converted files in the current >> directory Angus> if no output_dir is specified. At present, they >> are output in Angus> the same directory as the .fd file. >> Angus> The patch also guarantees that 'build_fname' is safe against Angus> buffer overflows. >> Looks good. What happens with the other converters? Angus> We pass the command line args to them and let them deal with Angus> it. All other converters are outside of our control. Ie, Angus> they're not part of the XForms library. See fd_forms.c, line Angus> 500-ish. We'll leave it like that, then. And is there something to do about fd2ps? I guess we do not care about this one until we get the doc sources, though. JMarc From Jean-Marc.Lasgouttes at inria.fr Fri May 28 08:02:48 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 May 2004 14:02:48 +0200 Subject: [XForms] pathc to add client message callback In-Reply-To: <200405281236.55512.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 28 May 2004 12:36:55 +0100") References: <40B66C65.8080601@comcast.net> <200405281236.55512.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Thursday 27 May 2004 11:32 pm, Jeff wrote: >> To all, >> >> Ok, here is the patch for adding the an X client message handling >> callback. Angus> Jeff, many thanks for this. Angus> Unfortunately, I won't have time to look at this properly until Angus> Tuesday. Jean-Marc, can I leave it to your tender care? I will not have much time until tuesday either, unfortunately (going to London...). JMarc From newsletter at hahnebach.com Fri May 28 10:13:16 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Fri, 28 May 2004 16:13:16 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) Message-ID: <40B748FC.8020503@hahnebach.com> Hi, 1. just for information: Angus send me this link for information about xforms mailing list: http://cweblog.usuhs.mil/mailman/listinfo/xforms This link works well. As you see I just subscribed. The main page of xforms: http://world.std.com/~xforms/ points to: http://world.std.com/~xforms/new/mlist.html regarding mailing list. This page points to: *http://bob.usuf2.usuhs.mil/mailserv/xforms.html* --> The requested URL was not found on this server. 2. It's again about XStab. As I said the software compiles using xforms 0.88 as well as using xforms 1.0.x There is only one differences which is quit important. The decimal separator in the whole software is a dot using 0.88 and a comma using 1.0.x. The comma causes big problems. I would like to use xforms 1.0.x and the dot as decimal separator. Thanks for any help. Bernd From Jens.Toerring at physik.fu-berlin.de Fri May 28 10:46:45 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Fri, 28 May 2004 16:46:45 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <40B748FC.8020503@hahnebach.com> References: <40B748FC.8020503@hahnebach.com> Message-ID: <20040528144559.GA6825@crowley.physik.fu-berlin.de> On Fri, May 28, 2004 at 04:13:16PM +0200, Bernd Hahnebach wrote: > 2. It's again about XStab. As I said the software compiles using xforms > 0.88 > as well as using xforms 1.0.x There is only one differences which is quit > important. The decimal separator in the whole software is a dot using > 0.88 and a comma using 1.0.x. The comma causes big problems. I would like to > use xforms 1.0.x and the dot as decimal separator. Newer versions of xforms seem to set the locale to the one set in the environment variables (caught me also unaware when that happened, suddenly lots of things stopped working...). You may have to tell it which one to use instead after the fl_initialize() call. I usually set it with setlocale( LC_NUMERIC, "C" ); directly after the flinitialize() call. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From Jean-Marc.Lasgouttes at inria.fr Fri May 28 10:55:50 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 May 2004 16:55:50 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040528144559.GA6825@crowley.physik.fu-berlin.de> (Jens Thoms Toerring's message of "Fri, 28 May 2004 16:46:45 +0200") References: <40B748FC.8020503@hahnebach.com> <20040528144559.GA6825@crowley.physik.fu-berlin.de> Message-ID: >>>>> "Jens" == Jens Thoms Toerring writes: Jens> To subscribers of the xforms list Jens> On Fri, May 28, 2004 at 04:13:16PM +0200, Bernd Hahnebach wrote: >> 2. It's again about XStab. As I said the software compiles using >> xforms 0.88 as well as using xforms 1.0.x There is only one >> differences which is quit important. The decimal separator in the >> whole software is a dot using 0.88 and a comma using 1.0.x. The >> comma causes big problems. I would like to use xforms 1.0.x and the >> dot as decimal separator. Jens> Newer versions of xforms seem to set the locale to the one set Jens> in the environment variables (caught me also unaware when that Jens> happened, suddenly lots of things stopped working...). You may Jens> have to tell it which one to use instead after the Jens> fl_initialize() call. I usually set it with Jens> setlocale( LC_NUMERIC, "C" ); Jens> directly after the flinitialize() call. Yes, this began after xforms 0.89.5 and I do not really like it :( However, I am not sure that we should remove that now... JMarc From Jean-Marc.Lasgouttes at inria.fr Fri May 28 11:10:05 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 28 May 2004 17:10:05 +0200 Subject: [XForms] pathc to add client message callback In-Reply-To: <40B66C65.8080601@comcast.net> (wd4nmq@comcast.net's message of "Thu, 27 May 2004 18:32:05 -0400") References: <40B66C65.8080601@comcast.net> Message-ID: >>>>> "Jeff" == Jeff writes: Jeff> To subscribers of the xforms list To all, Jeff> Ok, here is the patch for adding the an X client message Jeff> handling callback. Jeff, something that would be very nice is a ChangeLog entry describing what you did to each file/function. Also, a demo program (I think you had one) would be great. The patch lokks very good in general, but I have a few formatting nitpicks: /* pump it thru current form */ - fl_handle_form(form, FL_OTHER, 0, xev); + if(form->client_callback){ + if(!form->client_callback(form, xev)) + fl_handle_form(form, FL_OTHER, 0, xev); + } + else + fl_handle_form(form, FL_OTHER, 0, xev); } } Please respect the indentation conventions of the file: 4 characters for each nesting level. Also, you should add a space after "if (". +FL_CLIENT_CALLBACK +fl_register_client_callback(FL_FORM *form, FL_CLIENT_CALLBACK clientCallback){ + + FL_CLIENT_CALLBACK old_rcb; + + old_rcb =form->client_callback; + form->client_callback = clientCallback; + return old_rcb; +} Add a space after "=" above. Respect indentation. Put the opening brace of the function block on a line by itself. + +/**********************************/ +Window fl_get_winID(FL_FORM *form){ + return form->window; +} Is this really needed since FL_FORM->window is public (and documented?). Moreover, I do not think the name follows xforms conventions. +FL_EXPORT FL_CLIENT_CALLBACK fl_register_client_callback( + FL_FORM *form, + FL_CLIENT_CALLBACK rcb + ); Indentation seems to be made of two tabs in this file. +FL_EXPORT Window fl_get_winID( + FL_FORM *form + ); + here too. Don't feel put down by these remarks, I am just trying to keep the code style coherent. JMarc From Jens.Toerring at physik.fu-berlin.de Fri May 28 11:41:11 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Fri, 28 May 2004 17:41:11 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: References: <40B748FC.8020503@hahnebach.com> <20040528144559.GA6825@crowley.physik.fu-berlin.de> Message-ID: <20040528154111.GA7046@crowley.physik.fu-berlin.de> On Fri, May 28, 2004 at 04:55:50PM +0200, Jean-Marc Lasgouttes wrote: > >>>>> "Jens" == Jens Thoms Toerring writes: > Jens> To subscribers of the xforms list > Jens> On Fri, May 28, 2004 at 04:13:16PM +0200, Bernd Hahnebach wrote: > >> 2. It's again about XStab. As I said the software compiles using > >> xforms 0.88 as well as using xforms 1.0.x There is only one > >> differences which is quit important. The decimal separator in the > >> whole software is a dot using 0.88 and a comma using 1.0.x. The > >> comma causes big problems. I would like to use xforms 1.0.x and the > >> dot as decimal separator. > > Jens> Newer versions of xforms seem to set the locale to the one set > Jens> in the environment variables (caught me also unaware when that > Jens> happened, suddenly lots of things stopped working...). You may > Jens> have to tell it which one to use instead after the > Jens> fl_initialize() call. I usually set it with > > Jens> setlocale( LC_NUMERIC, "C" ); > > Jens> directly after the flinitialize() call. > > Yes, this began after xforms 0.89.5 and I do not really like it :( > However, I am not sure that we should remove that now... I think it's a misfeature - if someone wants to set a locale (s)he knows where to find it, and changing it behinds ones back isn't the right thing IMHO. Especially since there's nothing that would force you to call fl_initialize() at the first thing in your program. So a different locale may have already been set, which then suddenly gets overwritten. And it's also rather astonishing when out of the blue e.g. scanf() looks for a comma as the decimal separator and you have never seen something like this before. Took me quite some time to figure out what was happening back then (I hadn't taken a closer look at locales before) and xforms was more or less the last suspect, I thought I had screwed up somewhere;-) Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From jac4 at mindless.com Fri May 28 11:45:08 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri, 28 May 2004 10:45:08 -0500 Subject: [XForms] Shared GL contexts Message-ID: <20040528154508.5AAEE79006A@ws1-14.us4.outblaze.com> > Here I'm running a linux box with a stock Fedora Core 1 distribution. That is the problem. I believe I mentioned this before but there's either a problem with Fedora 1 or a problem with the latest X server that causes apps that use GL to crash the server when they exit. The problem is not limited to the context sharing stuff, it is present in a clean 1.0.90 and 1.0 version of xforms as well. Here at work we switched two machines to Fedora, had that problem with both of them, then went back to using RH9. I have no idea what the cause is. Another way that I found to reproduce it was: 1) Create an xforms 1.0 or 1.0.90 application that uses GLCanvases and GL. 2) Run two instances of the application at the same time. 3) Close one of them. That always did it for me. I would also experience weird things like: 1) Create an xforms 1.0 or 1.0.90 application that uses GL and calls glLineWidth(5.0). 2) Run it, exit it, some times it crashes some times it doesn't. 3) Start a completely different GL application and note that the line width in that application is 5.0! Strange stuff like the GL states carrying across applications, and other things. Like I said, we could not figure out the cause at all. And it only happened in certain applications... but nothing about the way those applications were coded stood out from the applications that -did- work. PS: In fdesign/spec/glcanvas_spec.c I believe I inadvertently #included "forms.h" rather than "include/forms.h". Could you make sure that it's including the right thing? Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From jac4 at mindless.com Fri May 28 11:51:36 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri, 28 May 2004 10:51:36 -0500 Subject: [XForms] Shared GL contexts Message-ID: <20040528155136.5BA6179006B@ws1-14.us4.outblaze.com> > If the 8 sub windows are labelled so: > 1 2 3 4 > 5 6 7 8 > > Then I can crash X reproducibly by clicking on the buttons: > 3:Visible --- hide sub window 3. > 2:B --- the object changes to a cone > 2:B -- the object disappears from sub windows 1 and 2. > 2:C -- usually there is no apparent change. Occasionally X crashes. > Exit -- X *always* crashes. Oops, I totally forgot in my last reply: On Redhat 9.0, this is not reproducible and the application works as it should: 3:Visible -- hide sub window 3 2:B -- object changes to a cone 2:B -- object remains a cone, does not disappear 2:C -- object changes to a sphere Exit -- application exits It also works correctly on OS X 10.3.3 and 10.3.4. We have obtained some Fedora Core 2 CDs so when I have more time I will see if the problem was fixed. Like I said, it seems very likely that it is a bug in Fedora Core 1 more than anything else. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From newsletter at hahnebach.com Fri May 28 12:27:24 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Fri, 28 May 2004 18:27:24 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040528144559.GA6825@crowley.physik.fu-berlin.de> References: <40B748FC.8020503@hahnebach.com> <20040528144559.GA6825@crowley.physik.fu-berlin.de> Message-ID: <40B7686C.3070303@hahnebach.com> Thanks. I copied the line. I got the next problem. main.c:34: warning: return type of `main' is not `int' main.c: In function `main': main.c:48: warning: implicit declaration of function `setlocale' main.c:48: error: `LC_NUMERIC' undeclared (first use in this function) main.c:48: error: (Each undeclared identifier is reported only once main.c:48: error: for each function it appears in.) make[1]: *** [main.o] Fehler 1 make[1]: Leaving directory `/home/hugo/Documents/projekte/software/xstab/zprogramm/XStab/src' make: *** [srcs] Fehler 2 Bernd Jens Thoms Toerring schrieb: >To subscribers of the xforms list > > >On Fri, May 28, 2004 at 04:13:16PM +0200, Bernd Hahnebach wrote: > > >>2. It's again about XStab. As I said the software compiles using xforms >>0.88 >>as well as using xforms 1.0.x There is only one differences which is quit >>important. The decimal separator in the whole software is a dot using >>0.88 and a comma using 1.0.x. The comma causes big problems. I would like to >>use xforms 1.0.x and the dot as decimal separator. >> >> > >Newer versions of xforms seem to set the locale to the one set in the >environment variables (caught me also unaware when that happened, >suddenly lots of things stopped working...). You may have to tell it >which one to use instead after the fl_initialize() call. I usually set >it with > >setlocale( LC_NUMERIC, "C" ); > >directly after the flinitialize() call. > > Regards, Jens > > From jac4 at mindless.com Fri May 28 12:46:47 2004 From: jac4 at mindless.com (jason cipriani) Date: Fri, 28 May 2004 11:46:47 -0500 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) Message-ID: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> > Thanks. I copied the line. I got the next problem. > ... > main.c:48: warning: implicit declaration of function `setlocale' > main.c:48: error: `LC_NUMERIC' undeclared (first use in this function) > ... > Bernd I believe you also need to #include to use setlocale(). Jason -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From Jens.Toerring at physik.fu-berlin.de Fri May 28 12:50:27 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Fri, 28 May 2004 18:50:27 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <40B7686C.3070303@hahnebach.com> References: <40B748FC.8020503@hahnebach.com> <20040528144559.GA6825@crowley.physik.fu-berlin.de> <40B7686C.3070303@hahnebach.com> Message-ID: <20040528165027.GA7407@crowley.physik.fu-berlin.de> On Fri, May 28, 2004 at 06:27:24PM +0200, Bernd Hahnebach wrote: > To subscribers of the xforms list > Thanks. I copied the line. I got the next problem. > > main.c:34: warning: return type of `main' is not `int' > main.c: In function `main': > main.c:48: warning: implicit declaration of function `setlocale' > main.c:48: error: `LC_NUMERIC' undeclared (first use in this function) > main.c:48: error: (Each undeclared identifier is reported only once > main.c:48: error: for each function it appears in.) > make[1]: *** [main.o] Fehler 1 > make[1]: Leaving directory > `/home/hugo/Documents/projekte/software/xstab/zprogramm/XStab/src' > make: *** [srcs] Fehler 2 Did you include ? That's where the function is declared and the constants defined. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From davidwriter at yahoo.com Fri May 28 14:48:29 2004 From: davidwriter at yahoo.com (David Scriven) Date: Fri, 28 May 2004 14:48:29 -0400 (EDT) Subject: [XForms] Shared GL contexts In-Reply-To: <20040528154508.5AAEE79006A@ws1-14.us4.outblaze.com> Message-ID: <20040528184830.56528.qmail@web60309.mail.yahoo.com> --- jason cipriani wrote: > To subscribers of the xforms list > > > > Here I'm running a linux box with a stock Fedora Core 1 > distribution. > > That is the problem. I believe I mentioned this before but there's > either a problem with Fedora 1 or a problem with the latest X server > that causes apps that use GL to crash the server when they exit. The > problem is not limited to the context sharing stuff, it is present in > a clean 1.0.90 and 1.0 version of xforms as well. > > Here at work we switched two machines to Fedora, had that problem > with both of them, then went back to using RH9. > > I have no idea what the cause is. Another way that I found to > reproduce it was: > > 1) Create an xforms 1.0 or 1.0.90 application that uses GLCanvases > and GL. > 2) Run two instances of the application at the same time. > 3) Close one of them. > This is rather worrying. It doesn't seem to be a problem with XForms-GL apps built with 0.89. I can run any number under Fedora and they don't seem to interact. My Fedora is fully updated and I'm using the latest NVIDIA driver - 5336. I've rebuilt the apps in Fedora with the latest g++, but I haven't rebuilt the XForms library - so it makes me wonder - is there something in XForms that is causing the problem? The only way to test this (I think) is to compile an app under Fedora and link it with both the old (0.89) library and the new to see if there is any difference in behaviour. > That always did it for me. I would also experience weird things like: > > 1) Create an xforms 1.0 or 1.0.90 application that uses GL and calls > glLineWidth(5.0). > 2) Run it, exit it, some times it crashes some times it doesn't. > 3) Start a completely different GL application and note that the line > width in that application is 5.0! > > Strange stuff like the GL states carrying across applications, and > other things. > > Like I said, we could not figure out the cause at all. And it only > happened in certain applications... but nothing about the way those > applications were coded stood out from the applications that -did- > work. > > PS: In fdesign/spec/glcanvas_spec.c I believe I inadvertently > #included "forms.h" rather than "include/forms.h". Could you make > sure that it's including the right thing? > > Jason > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > 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 newsletter at hahnebach.com Fri May 28 15:06:11 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Fri, 28 May 2004 21:06:11 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> Message-ID: <40B78DA3.1010807@hahnebach.com> added to main.c: #include and directly under: fl_initialize(&argc,argv,version,0,0); setlocale( LC_NUMERIC, "C" ); XStab compiles but it still does commas instead of dots. I did the other way around just to have success. Using LANG=en_US before starting XStab works. Only dots dots dots :-) I don't want to bother you, but I still would like to find a solution. Bernd jason cipriani schrieb: >>Thanks. I copied the line. I got the next problem. >> ... >>main.c:48: warning: implicit declaration of function `setlocale' >>main.c:48: error: `LC_NUMERIC' undeclared (first use in this function) >> ... >>Bernd >> >> > >I believe you also need to #include to use setlocale(). > >Jason > > From Jens.Toerring at physik.fu-berlin.de Fri May 28 17:52:13 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Fri, 28 May 2004 23:52:13 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <40B78DA3.1010807@hahnebach.com> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> Message-ID: <20040528215213.GA8172@crowley.physik.fu-berlin.de> On Fri, May 28, 2004 at 09:06:11PM +0200, Bernd Hahnebach wrote: > added to main.c: > > #include > > and directly under: fl_initialize(&argc,argv,version,0,0); > setlocale( LC_NUMERIC, "C" ); > > XStab compiles but it still does commas instead of dots. > > I did the other way around just to have success. Using > LANG=en_US before starting XStab works. Only dots dots dots :-) > > I don't want to bother you, but I still would like to find a solution. In what context do the commata (or commas or what's the correct plural of comma in English?) appear instead of dots? If you have a look at the man page for setlocale() you'll see that there several other categories you could set beside LC_NUMERIC (which I set exclusively because I don't care about the rest). Perhaps you get better results when you use instead setlocale( LC_ALL, "C" ); That should take care of all categories and hopefully get rid of your problem. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From newsletter at hahnebach.com Sat May 29 09:51:05 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Sat, 29 May 2004 15:51:05 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040528215213.GA8172@crowley.physik.fu-berlin.de> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> Message-ID: <40B89549.5030506@hahnebach.com> It does not get rid of my problem. LC_NUMERIC or ALL seams not to be problem. Nothing changes it does not matter what I use. It is about all numbers in the whole program. e.g.: input data (it does piiiiep if I try to input a dot), output on screen, output to file, there is coordinate system with numbers on screen.... All numbers have a comma respectively a dot using LANG=C I read man page of setlocale and locale (Thanks, I did not know about.) but could not find something that helps. Bernd sitting in front of my computer and look for the big hammer ;-) Jens Thoms Toerring schrieb: >To subscribers of the xforms list > > >On Fri, May 28, 2004 at 09:06:11PM +0200, Bernd Hahnebach wrote: > > >>added to main.c: >> >>#include >> >>and directly under: fl_initialize(&argc,argv,version,0,0); >>setlocale( LC_NUMERIC, "C" ); >> >>XStab compiles but it still does commas instead of dots. >> >>I did the other way around just to have success. Using >>LANG=en_US before starting XStab works. Only dots dots dots :-) >> >>I don't want to bother you, but I still would like to find a solution. >> >> > >In what context do the commata (or commas or what's the correct >plural of comma in English?) appear instead of dots? If you have >a look at the man page for setlocale() you'll see that there >several other categories you could set beside LC_NUMERIC (which >I set exclusively because I don't care about the rest). Perhaps >you get better results when you use instead > >setlocale( LC_ALL, "C" ); > >That should take care of all categories and hopefully get rid of >your problem. > Regards, Jens > > From Jens.Toerring at physik.fu-berlin.de Sat May 29 12:54:13 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Sat, 29 May 2004 18:54:13 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <40B89549.5030506@hahnebach.com> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> <40B89549.5030506@hahnebach.com> Message-ID: <20040529165413.GA11663@crowley.physik.fu-berlin.de> On Sat, May 29, 2004 at 03:51:05PM +0200, Bernd Hahnebach wrote: > It does not get rid of my problem. LC_NUMERIC or ALL seams > not to be problem. Nothing changes it does not matter what I use. > > It is about all numbers in the whole program. > e.g.: input data (it does piiiiep if I try to input a dot), output on > screen, > output to file, there is coordinate system with numbers on screen.... > All numbers have a comma respectively a dot using LANG=C That's strange, especially since it seems to pick up the locale from the environment variable... Could it be some trivial reason like that you by some misfortune don't invoke the new version where you added the setlocale() call? That could happen when you e.g. didn't install the new version and instead try to start it from within the directory where the new executable is and you use the command "progname" instead of "./progname" while your PATH isn't set up to look in the current directory first... Can you publish the sources somewhere (or send them to me via email)? > sitting in front of my computer and look for the big hammer ;-) Don't let it mess up your weekend;-) Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From Jens.Toerring at physik.fu-berlin.de Sun May 30 10:46:42 2004 From: Jens.Toerring at physik.fu-berlin.de (Jens Thoms Toerring) Date: Sun, 30 May 2004 16:46:42 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040529165413.GA11663@crowley.physik.fu-berlin.de> References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> <40B89549.5030506@hahnebach.com> <20040529165413.GA11663@crowley.physik.fu-berlin.de> Message-ID: <20040530144642.GA15263@crowley.physik.fu-berlin.de> Hi, for those still interested in the setlocale() etc. question here some new observations: On an older Linux machine (with 2.2.4 libc) setting the locale back to "C" works as expected - i.e. if my LANG environment variable is "de_DE" (for German, where a comma instead of a dot is used as the decimal separator) I afterwards can use the dot in input and it gets printed out in output. With a newer Linux machine (libc 2.3.2) this doesn't work anymore. Even after having the setlocale() call immediately after the call of fl_initialize() does not help. On both I am using XForms 1.0.0. With a test program (not using XForms) I can correctly switch between the locales. On the newer Linux machine, when I switch the locale to "C" after fl_initialize() it gets switched back to "de_DE" in the first call of fl_show_form(). Up till now I couldn't figure out where exactly this happens within fl_show_form. Whatever the reasons I would strongly suggest to throw out all that locale switching from XForms - messing around with this is really annoying, especially since it hits you in unexpected places. Take for example a command line program that reads in some double data. This works perfectly well with data with a dot as decimal separator since the start locale is always "C" when the program start. But when you then add a GUI using XForms it suddenly breaks since XForms believes it's more clever than the programmer and switches from "C" to "de_DE". This is especially going to be a problem with programs written by let's say an American (who usually doesn't even have to be aware off all this because it always works with both the "C" and the "en_US" locale) and which is then run by someone else in Germany, with LANG set to "de_DE". Suddenly the program does not work anymore for some completely mysterious reasons (it may be just some output some cryptic error message like "Invalid data in input file".) Neither the american programmer nor the german user will have any good clues about what happens - the same file works perfectly well for the american programmer and coming up with the explanation will take lots of time and communication. Regards, Jens -- \ Jens Thoms Toerring ___ Jens.Toerring at physik.fu-berlin.de \__________________________ http://www.toerring.de From Jean-Marc.Lasgouttes at inria.fr Tue Jun 1 05:35:46 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Tue, 01 Jun 2004 11:35:46 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: <20040530144642.GA15263@crowley.physik.fu-berlin.de> (Jens Thoms Toerring's message of "Sun, 30 May 2004 16:46:42 +0200") References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> <40B89549.5030506@hahnebach.com> <20040529165413.GA11663@crowley.physik.fu-berlin.de> <20040530144642.GA15263@crowley.physik.fu-berlin.de> Message-ID: >>>>> "Jens" == Jens Thoms Toerring writes: Jens> On an older Linux machine (with 2.2.4 libc) setting the locale Jens> back to "C" works as expected - i.e. if my LANG environment Jens> variable is "de_DE" (for German, where a comma instead of a dot Jens> is used as the decimal separator) I afterwards can use the dot Jens> in input and it gets printed out in output. Jens> With a newer Linux machine (libc 2.3.2) this doesn't work Jens> anymore. Even after having the setlocale() call immediately Jens> after the call of fl_initialize() does not help. Are using SuSE and the xforms version shipped with it? If you do, then you should update to the latest revision of the xforms package, which has a bug like this one fixed. Their version of xforms includes a still not official internationalization patch (to allow entering CJK characters) whic had problems. This got debugged on the LyX list a few months ago. Hope this helps. JMarc From angus.leeming at btopenworld.com Tue Jun 1 05:50:29 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 1 Jun 2004 10:50:29 +0100 Subject: [XForms] Shared GL contexts In-Reply-To: <20040528154508.5AAEE79006A@ws1-14.us4.outblaze.com> References: <20040528154508.5AAEE79006A@ws1-14.us4.outblaze.com> Message-ID: <200406011050.29301.angus.leeming@btopenworld.com> On Friday 28 May 2004 4:45 pm, jason cipriani wrote: > PS: In fdesign/spec/glcanvas_spec.c I believe I inadvertently > #included "forms.h" rather than "include/forms.h". Could you make > sure that it's including the right thing? Done in my local copy. Angus From angus.leeming at btopenworld.com Tue Jun 1 06:02:41 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 1 Jun 2004 11:02:41 +0100 Subject: [XForms] Shared GL contexts In-Reply-To: <20040528184830.56528.qmail@web60309.mail.yahoo.com> References: <20040528184830.56528.qmail@web60309.mail.yahoo.com> Message-ID: <200406011102.41477.angus.leeming@btopenworld.com> On Friday 28 May 2004 7:48 pm, David Scriven wrote: > > I have no idea what the cause is. Another way that I found to > > reproduce it was: > > > > 1) Create an xforms 1.0 or 1.0.90 application that uses > > GLCanvases and GL. > > 2) Run two instances of the application at the same time. > > 3) Close one of them. > > This is rather worrying. It doesn't seem to be a problem with > XForms-GL apps built with 0.89. I can run any number under > Fedora and they don't seem to interact. My Fedora is fully > updated and I'm using the latest NVIDIA driver - 5336. > > I've rebuilt the apps in Fedora with the latest g++, but I haven't > rebuilt the XForms library - so it makes me wonder - is there > something in XForms that is causing the problem? The only way > to test this (I think) is to compile an app under Fedora and > link it with both the old (0.89) library and the new to see > if there is any difference in behaviour. I cannot reproduce this with the two GL demo apps, demos/gl and demos/glwin. Jason, can you supply me with a minimal GL code that compiles and runs correctly under XForms 0.89 but which demonstrates this problem under XForms >= 1.0? We can possibly get TC to provide a copy of the 0.89 sources to help track down the offending change. Angus From jac4 at mindless.com Tue Jun 1 08:59:59 2004 From: jac4 at mindless.com (jason cipriani) Date: Tue, 01 Jun 2004 07:59:59 -0500 Subject: [XForms] Shared GL contexts Message-ID: <20040601125959.B4F33101D7@ws1-3.us4.outblaze.com> > Jason, can you supply me with a minimal GL code that compiles and runs > correctly under XForms 0.89 but which demonstrates this problem under > XForms >= 1.0? Unfortunately, no... I don't have a spare machine to install Fedora on at this time. And I am not so sure that the problem doesn't occur on 0.89 as well... I've never tried it. It was somebody else that said that. I'll see if I can't find an extra hard drive laying around somewhere to throw Fedora on but it might be a while before I can get you some examples. Sorry :/ -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From angus.leeming at btopenworld.com Tue Jun 1 11:03:17 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 1 Jun 2004 16:03:17 +0100 Subject: [XForms] What does this 'ugly hack' do? Message-ID: <200406011603.17886.angus.leeming@btopenworld.com> I've played with the pop ups and can discern no change of behaviour after making the attached change. Obviously, I'm missing something. Can anyone provide me with some insight, or a methodology to see the change in behaviour? Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: forms.diff Type: text/x-diff Size: 593 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040601/81a7a384/attachment.bin From Gayle.C.Roth at nasa.gov Tue Jun 1 12:13:44 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Tue, 01 Jun 2004 12:13:44 -0400 Subject: [XForms] version 1.0.90 regarding forms.h Message-ID: <5.1.1.5.2.20040601120606.01679150@popserve.grc.nasa.gov> Hi. I have a question. While trying to port the forms library (version 1.0.90) to OpenVMS, I discovered that forms.h is no longer being distributed. I subsequently read the changelog file and found out that it's now automatically generated. Unfortunately for me, the mechanism for doing this is tucked into Makefile.am, which is useless on an OpenVMS system without GNV. Does anyone know of some way to generate forms.h on a non-UNIX system? Any help is appreciated. Thanks. - Gayle From angus.leeming at btopenworld.com Tue Jun 1 12:41:47 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 1 Jun 2004 17:41:47 +0100 Subject: [XForms] version 1.0.90 regarding forms.h In-Reply-To: <5.1.1.5.2.20040601120606.01679150@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040601120606.01679150@popserve.grc.nasa.gov> Message-ID: <200406011741.47902.angus.leeming@btopenworld.com> An embedded and charset-unspecified text was scrubbed... Name: warning1.txt Url: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040601/de8571d7/attachment.txt -------------- next part -------------- On Tuesday 01 June 2004 5:13 pm, Gayle C Roth wrote: > To subscribers of the xforms list > > > Hi. > > I have a question. While trying to port the forms library (version > 1.0.90) to OpenVMS, I discovered that forms.h is no longer being > distributed. I subsequently read the changelog file and found out > that it's now automatically generated. Unfortunately for me, the > mechanism for doing this is tucked into Makefile.am, which is > useless on an OpenVMS system without GNV. Does anyone know of some > way to generate forms.h on a non-UNIX system? > > Any help is appreciated. Thanks. Hi, Gayle. forms.h is generated from AAA.h and the files listed in the noinst_HEADERS target of Makefile.am (all in the lib/include directory.) The code doing this work is found in the stamp-forms target of Makefile.am. AAA.h is generated at configure-time from AAA.h.in. That is, autoconf relplaces the '@' delimited variables in AAA.h.in with the values specified in $top/configure.ac: [angus at boris devel]$ diff -u lib/include/AAA.h.in build/lib/include/AAA.h --- lib/include/AAA.h.in 2003-09-09 01:28:25.000000000 +0100 +++ build/lib/include/AAA.h 2004-05-28 00:08:46.000000000 +0100 @@ -54,9 +54,9 @@ #ifndef FL_FORMS_H #define FL_FORMS_H -#define FL_VERSION @FL_VERSION@ -#define FL_REVISION @FL_REVISION@ -#define FL_FIXLEVEL @FL_FIXLEVEL@ +#define FL_VERSION 1 +#define FL_REVISION 0 +#define FL_FIXLEVEL 90 #define FL_INCLUDE_VERSION (FL_VERSION * 1000 + FL_REVISION) #include If you want to generate forms.h yourself, then a little shell script should do the job. Running the attached gen_forms_h.sh from the lib/include directory as sh gen_forms_h.sh works for me... Regards, Angus From angus.leeming at btopenworld.com Tue Jun 1 12:48:40 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 1 Jun 2004 17:48:40 +0100 Subject: [XForms] version 1.0.90 regarding forms.h In-Reply-To: <200406011741.47902.angus.leeming@btopenworld.com> References: <5.1.1.5.2.20040601120606.01679150@popserve.grc.nasa.gov> <200406011741.47902.angus.leeming@btopenworld.com> Message-ID: <200406011748.40141.angus.leeming@btopenworld.com> On Tuesday 01 June 2004 5:41 pm, Angus Leeming wrote: > If you want to generate forms.h yourself, then a little shell > script should do the job. Running the attached gen_forms_h.sh from > the lib/include directory as > sh gen_forms_h.sh > works for me... ... > WARNING: This e-mail has been altered by MIMEDefang. Following > this paragraph are indications of the actual changes made. For > more information about your site's MIMEDefang policy, contact > Robert Williams . For more information about > MIMEDefang, see: > > http://www.roaringpenguin.com/mimedefang/enduser.php3 > > An attachment named gen_forms_h.sh was removed from this document > as it constituted a security hazard. If you require this document, > please contact the sender and arrange an alternate means of > receiving it. Oh, bother. Renaming the offending script as gen_forms_h_sh... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: gen_forms_h_sh Type: application/x-shellscript Size: 768 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040601/99c54b44/attachment.bin From Gayle.C.Roth at nasa.gov Tue Jun 1 17:02:04 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Tue, 01 Jun 2004 17:02:04 -0400 Subject: [XForms] Building xforms library (1.0.90) Message-ID: <5.1.1.5.2.20040601164852.017d5e98@popserve.grc.nasa.gov> Hi. Angus, you solved my previous problem so well (the missing forms.h one) that I'm going to throw another one at you... when I tried to compile (on VMS) the 1st C source, I got an error on the following statement in FLINTERNAL.H: typedef RETSIGTYPE(*FL_OSSIG_HANDLER) (int); It said: found '*' when expecting one of : ,... I think the type 'RETSIGTYPE' isn't defined at that point. I noticed by searching for RETSIGTYPE that some of the times it's supposed to be void but not necessarily all the time. So what should I do? Thanks, Gayle From angus.leeming at btopenworld.com Tue Jun 1 17:27:11 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 1 Jun 2004 22:27:11 +0100 Subject: [XForms] Building xforms library (1.0.90) In-Reply-To: <5.1.1.5.2.20040601164852.017d5e98@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040601164852.017d5e98@popserve.grc.nasa.gov> Message-ID: <200406012227.11177.angus.leeming@btopenworld.com> On Tuesday 01 June 2004 10:02 pm, Gayle C Roth wrote: > To subscribers of the xforms list > > > Hi. > > Angus, you solved my previous problem so well (the missing forms.h > one) that I'm going to throw another one at you... when I tried to > compile (on VMS) the 1st C source, I got an error on the following > statement in FLINTERNAL.H: > > typedef RETSIGTYPE(*FL_OSSIG_HANDLER) (int); > > It said: found '*' when expecting one of : ,... > > I think the type 'RETSIGTYPE' isn't defined at that point. I > noticed by searching for RETSIGTYPE that some of the times it's > supposed to be void but not necessarily all the time. So what > should I do? Let's see: $ grep -r RETSIGTYPE lib lib/flinternal.h:typedef RETSIGTYPE(*FL_OSSIG_HANDLER) (int); lib/signal.c:static RETSIGTYPE lib/signal.c:#ifndef RETSIGTYPE_IS_VOID lib/config.h.in:#undef RETSIGTYPE lib/config.h.in:#undef RETSIGTYPE_IS_VOID $ grep RETSIGTYPE build/lib/config.h #define RETSIGTYPE void #define RETSIGTYPE_IS_VOID 1 config.h is a file generated by the configure script from config.h.in which, in turn, is generated by autoconf from configure.ac. Given that you don't have the autotools at your disposal, I'm attaching both so that you can create your own config.h using config.h.in as a template. Here, on linux, 'man signal' gives me this signature, confirming that RETSIGTYPE should be 'void' on this platform. #include typedef void (*sighandler_t)(int); Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: config.h.in Type: text/x-csrc Size: 4336 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040601/f0925261/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: config.h Type: text/x-chdr Size: 4594 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040601/f0925261/attachment-0001.bin From newsletter at hahnebach.com Tue Jun 1 18:32:55 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Wed, 02 Jun 2004 00:32:55 +0200 Subject: [XForms] dot vs. comma (0.88 vs. 1.0.x) In-Reply-To: References: <20040528164647.998CC79006A@ws1-14.us4.outblaze.com> <40B78DA3.1010807@hahnebach.com> <20040528215213.GA8172@crowley.physik.fu-berlin.de> <40B89549.5030506@hahnebach.com> <20040529165413.GA11663@crowley.physik.fu-berlin.de> <20040530144642.GA15263@crowley.physik.fu-berlin.de> Message-ID: <40BD0417.6040801@hahnebach.com> Yep, thats it. Just installed xforms 1.0.90. It works. Thanks. Jean-Marc Lasgouttes schrieb: >Are using SuSE and the xforms version shipped with it? If you do, then >you should update to the latest revision of the xforms package, which >has a bug like this one fixed. Their version of xforms includes a >still not official internationalization patch (to allow entering CJK >characters) whic had problems. This got debugged on the LyX list a few >months ago. > >Hope this helps. > >JMarc > > > > From newsletter at hahnebach.com Tue Jun 1 18:35:07 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Wed, 02 Jun 2004 00:35:07 +0200 Subject: [XForms] How to tell my computer he should use a spezified version of xforms? Message-ID: <40BD049B.7000109@hahnebach.com> Hi, As a result of dot vs. comm problem I installed xforms 1.0.90 from source code. For compilation of my software it is easy to tell which version of the library should be used. Compiling my software using static labrary it works. Asuming I compile using shared library. I have got a problem. How do I know which library is my computer using during run time of my software? How can I tell him which library should he use? Both are versions 1.0.x Bernd From angus.leeming at btopenworld.com Tue Jun 1 18:56:24 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Tue, 1 Jun 2004 23:56:24 +0100 Subject: [XForms] How to tell my computer he should use a spezified version of xforms? In-Reply-To: <40BD049B.7000109@hahnebach.com> References: <40BD049B.7000109@hahnebach.com> Message-ID: <200406012356.24186.angus.leeming@btopenworld.com> On Tuesday 01 June 2004 11:35 pm, Bernd Hahnebach wrote: > To subscribers of the xforms list > > > Hi, > > As a result of dot vs. comm problem I installed xforms 1.0.90 from > source code. For compilation of my software it is easy to tell > which version of the library should be used. Compiling my software > using static labrary it works. > > Asuming I compile using > shared library. I have got a problem. How do I know which > library is my computer using during run time of my software? > How can I tell him which library should he use? > > Both are versions 1.0.x Hi, Bernd. Generally speaking, a link line such as $ cc -o trial trial.c -lforms -lX11 will link against the .so versions of the libraries if the compiler can find them. On linux, $ ldd ./trial will list the shared object dependencies. If you look closely, you'll find that you have created executables fdesign and fd2ps, linked both statically and dynamically. The static version of fdesign is found in $build_tree/fdesign/fdesign whilst the dynamic version is found in $build_tree/fdesign/.libs/fdesign $ cd fdesign $ ldd ./fdesign not a dynamic executable $ ldd .libs/fdesign libforms.so.1 => /usr/local/lib/libforms.so.1 (0x005f6000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00513000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x00a4e000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x00ba4000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00181000) libc.so.6 => /lib/tls/libc.so.6 (0x0029c000) libm.so.6 => /lib/tls/libm.so.6 (0x008a7000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x004cc000) libdl.so.2 => /lib/libdl.so.2 (0x00111000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00eda000) It is the dynamicly-linked version that is installed. The simplest way to make the two versions of your executable is: Dynamically-linked: $ gcc -o trial trial.c Staticly-linked: $ gcc -static -o trial trial.c If you don't use gcc, then 'man cc' is your friend. HTH, Angus From Gayle.C.Roth at nasa.gov Thu Jun 3 11:28:19 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Thu, 03 Jun 2004 11:28:19 -0400 Subject: [XForms] can't find file Message-ID: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> Hi. I ran into another stumbling block in my effort to build the xforms library on an OpenVMS system (surprise, surprise :) ). The build procedure was doing fine until it tried to compile [.xforms.lib]listdir.c. Then, I got the error message "Cannot find file vms_readdir.c" which, indeed, is not to be found. This leads me to ask the following questions: 1) Is this file necessary for building the xforms library on OpenVMS? 2) If yes, how can I generate it or the information contained in it? 3) What does it do? Thanks, Gayle From angus.leeming at btopenworld.com Thu Jun 3 11:40:16 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 3 Jun 2004 16:40:16 +0100 Subject: [XForms] can't find file In-Reply-To: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> Message-ID: <200406031640.16048.angus.leeming@btopenworld.com> On Thursday 03 June 2004 4:28 pm, Gayle C Roth wrote: > Hi. > > I ran into another stumbling block in my effort to build the xforms > library on an OpenVMS system (surprise, surprise :) ). The build > procedure was doing fine until it tried to compile > [.xforms.lib]listdir.c. Then, I got the error message "Cannot find > file vms_readdir.c" which, indeed, is not to be found. This leads > me to ask the following questions: > > 1) Is this file necessary for building the xforms library on > OpenVMS? 2) If yes, how can I generate it or the information > contained in it? 3) What does it do? Ahhhh. The file *does* exist in the cvs tree, but is not packaged in the distribution. That's an oversight which I'll correct immediately. The file is attached. Shove it in [.xforms.lib] Regards, Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: vms_readdir.c.gz Type: application/x-gzip Size: 3540 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040603/bfbd8d44/attachment.gz From angus.leeming at btopenworld.com Thu Jun 3 11:42:55 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Thu, 3 Jun 2004 16:42:55 +0100 Subject: [XForms] can't find file In-Reply-To: <200406031640.16048.angus.leeming@btopenworld.com> References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> <200406031640.16048.angus.leeming@btopenworld.com> Message-ID: <200406031642.55983.angus.leeming@btopenworld.com> On Thursday 03 June 2004 4:40 pm, Angus Leeming wrote: > Ahhhh. The file *does* exist in the cvs tree, but is not packaged > in the distribution. That's an oversight which I'll correct > immediately. > > The file is attached. Shove it in [.xforms.lib] You'll also need dirent_vms.h. Same problem. Also attached. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: dirent_vms.h Type: text/x-chdr Size: 1967 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040603/d48bb2e8/attachment.bin From newsletter at hahnebach.com Thu Jun 3 19:10:09 2004 From: newsletter at hahnebach.com (Bernd Hahnebach) Date: Fri, 04 Jun 2004 01:10:09 +0200 Subject: [XForms] How to tell my computer he should use a spezified version of xforms? In-Reply-To: <200406012356.24186.angus.leeming@btopenworld.com> References: <40BD049B.7000109@hahnebach.com> <200406012356.24186.angus.leeming@btopenworld.com> Message-ID: <40BFAFD1.2050902@hahnebach.com> Thanks, for help. They weren't exactly what I was looking for, but they really got me on the way. After playing around using your tips, xforms hello world example, ldd, ldconfig, a short description of gcc compilerflaggs (man gcc is quit a BIG friend :-)) I found what I was looking for. Bernd Angus Leeming schrieb: >To subscribers of the xforms list > > >On Tuesday 01 June 2004 11:35 pm, Bernd Hahnebach wrote: > > >>To subscribers of the xforms list >> >> >>Hi, >> >>As a result of dot vs. comm problem I installed xforms 1.0.90 from >>source code. For compilation of my software it is easy to tell >>which version of the library should be used. Compiling my software >>using static labrary it works. >> >>Asuming I compile using >>shared library. I have got a problem. How do I know which >>library is my computer using during run time of my software? >>How can I tell him which library should he use? >> >>Both are versions 1.0.x >> >> > >Hi, Bernd. > >Generally speaking, a link line such as > >$ cc -o trial trial.c -lforms -lX11 > >will link against the .so versions of the libraries if the compiler >can find them. > >On linux, >$ ldd ./trial >will list the shared object dependencies. > >If you look closely, you'll find that you have created executables >fdesign and fd2ps, linked both statically and dynamically. > >The static version of fdesign is found in $build_tree/fdesign/fdesign >whilst the dynamic version is found in >$build_tree/fdesign/.libs/fdesign > >$ cd fdesign >$ ldd ./fdesign > not a dynamic executable >$ ldd .libs/fdesign > libforms.so.1 => /usr/local/lib/libforms.so.1 (0x005f6000) > libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x00513000) > libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x00a4e000) > libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x00ba4000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00181000) > libc.so.6 => /lib/tls/libc.so.6 (0x0029c000) > libm.so.6 => /lib/tls/libm.so.6 (0x008a7000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x004cc000) > libdl.so.2 => /lib/libdl.so.2 (0x00111000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00eda000) > >It is the dynamicly-linked version that is installed. > >The simplest way to make the two versions of your executable is: > >Dynamically-linked: >$ gcc -o trial trial.c > >Staticly-linked: >$ gcc -static -o trial trial.c > >If you don't use gcc, then 'man cc' is your friend. > >HTH, >Angus > >_______________________________________________ >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 angus.leeming at btopenworld.com Fri Jun 4 04:32:49 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 09:32:49 +0100 Subject: [XForms] can't find file In-Reply-To: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> Message-ID: <200406040932.49826.angus.leeming@btopenworld.com> On Thursday 03 June 2004 4:28 pm, Gayle C Roth wrote: > To subscribers of the xforms list > Hi. > > I ran into another stumbling block in my effort to build the xforms > library on an OpenVMS system (surprise, surprise :) ). The build > procedure was doing fine until it tried to compile > [.xforms.lib]listdir.c. Then, I got the error message "Cannot find > file vms_readdir.c" which, indeed, is not to be found. This leads > me to ask the following questions: Gayle, it occurred to me last night that you're trying to compile the xforms-1.0.90.tar.gz prelease, right? If that is the case, all this noise about the gnu autotools has been, well, just noise. These tools do no more than * generate the configure script in the top level directory from configure.ac * generate files Makefile.in in each directory from the corresponding Makefile.am both sets of files should exist already in the prerelease. That being the case, then you should be able to build XForms in identical manner to me: mkdir build cd build ../configure --enable-demos make The configure step will generate lib/config.h in the build tree together with Makefiles from the corresponding Makefile.in files. Of course, you'll still need to shove the missing vms_readdir.c and dirent_vms.h files in the lib directory of the src tree. Let me know. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 05:03:44 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 04 Jun 2004 11:03:44 +0200 Subject: [XForms] can't find file In-Reply-To: <200406040932.49826.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 09:32:49 +0100") References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> <200406040932.49826.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> That being the case, then you should be able to build XForms in Angus> identical manner to me: Angus> mkdir build cd build ../configure --enable-demos make Angus, I do not think that configure scripts work under vms... I may be wrong, of course. JMarc From angus.leeming at btopenworld.com Fri Jun 4 05:17:05 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 10:17:05 +0100 Subject: [XForms] can't find file In-Reply-To: References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> <200406040932.49826.angus.leeming@btopenworld.com> Message-ID: <200406041017.05210.angus.leeming@btopenworld.com> On Friday 04 June 2004 10:03 am, Jean-Marc Lasgouttes wrote: > >>>>> "Angus" == Angus Leeming > >>>>> writes: > > Angus> That being the case, then you should be able to build XForms > in Angus> identical manner to me: > > Angus> mkdir build cd build ../configure --enable-demos make > > Angus, I do not think that configure scripts work under vms... I > may be wrong, of course. GNV includes a port of bash to VMS. http://gnv.sourceforge.net/ GNU's Not VMS! GNV is a GNU based project, delivering a Unix environment for OpenVMS. It is intended to provide the important subset of Unix/Linux/POSIX necessary to port UNIX OpenSource software to OpenVMS. GNV consists of two parts: a Unix like shell environment and the CTRL Supplemental Library which provides functions typically found on Unix systems, but are missing, incomplete, or incorrect on VMS. Many OpenSource software packages ship a source tarball. When extracted, the software is built by running the 'configure' script, followed by a 'make'. This procedure examines features of the Unix system your running on, and builds the sofware package accordingly. This process may also work on an OpenVMS system, using the BASH shell provided by GNV. It is a goal of the GNV project to improve the porting of such OpenSource projects to OpenVMS. Regards, Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 05:33:34 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 04 Jun 2004 11:33:34 +0200 Subject: [XForms] can't find file In-Reply-To: <200406041017.05210.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 10:17:05 +0100") References: <5.1.1.5.2.20040603112047.0167bd58@popserve.grc.nasa.gov> <200406040932.49826.angus.leeming@btopenworld.com> <200406041017.05210.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> GNV includes a port of bash to VMS. http://gnv.sourceforge.net/ OK, so it's only the autotools that do not work yet... Thanks for clearing things up. JMarc From angus.leeming at btopenworld.com Fri Jun 4 06:25:46 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 11:25:46 +0100 Subject: [XForms] Fixing the popups? Message-ID: <200406041125.46406.angus.leeming@btopenworld.com> Jean-Marc, this patch removes the 'ugly hack' in forms.c and tries to do the 'right thing' in xpopup.c. My testing suggests that the popups in LyX are behaving 'better', but you're the one who's more familiar with those problems. Could you try it out? I'd value some feedback about any changes to the user experience, good or bad. A side effect is that the scrollbar will now work correctly in LyX when linked against XForms cvs. Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: popup.diff Type: text/x-diff Size: 2041 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040604/f4081cd1/attachment.bin From angus.leeming at btopenworld.com Fri Jun 4 06:39:51 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 11:39:51 +0100 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041125.46406.angus.leeming@btopenworld.com> References: <200406041125.46406.angus.leeming@btopenworld.com> Message-ID: <200406041139.51941.angus.leeming@btopenworld.com> On Friday 04 June 2004 11:25 am, Angus Leeming wrote: > Jean-Marc, > > this patch removes the 'ugly hack' in forms.c and tries to do the > 'right thing' in xpopup.c. My testing suggests that the popups in > LyX are behaving 'better', but you're the one who's more familiar > with those problems. > > Could you try it out? I'd value some feedback about any changes to > the user experience, good or bad. Forget it. The XSendEvent stuff makes it impossible to interact with the menu in demos/popup. Incidentally, both demos/popup and demos/pup have a different behaviour to popups in LyX. It breaks the popup code (popup and pup) in the demos directory. Incidentally, both these demos behave differently to popups in LyX. Angus From angus.leeming at btopenworld.com Fri Jun 4 06:59:23 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 11:59:23 +0100 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041139.51941.angus.leeming@btopenworld.com> References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041139.51941.angus.leeming@btopenworld.com> Message-ID: <200406041159.23109.angus.leeming@btopenworld.com> On Friday 04 June 2004 11:39 am, Angus Leeming wrote: > To subscribers of the xforms list > > On Friday 04 June 2004 11:25 am, Angus Leeming wrote: > > Jean-Marc, > > > > this patch removes the 'ugly hack' in forms.c and tries to do the > > 'right thing' in xpopup.c. My testing suggests that the popups in > > LyX are behaving 'better', but you're the one who's more familiar > > with those problems. Is it me, or does demos/menu behave in a very strange way? If I click on "menu 4" a popup menu is displayed. If I click elsewhere on the form another, identical popup menu is displayed. If I click on this menu, a third, identical menu is displayed. If I click on this third menu, the action is taken and all popups disappear. This behaviour is identical in Xforms 1.0 and in XForms 1.1cvs (code identical to that on savannah), so it isn't my messing around that's broken stuff. Weird and nasty. Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 08:21:57 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 04 Jun 2004 14:21:57 +0200 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041139.51941.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 11:39:51 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041139.51941.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> On Friday 04 June 2004 11:25 am, Angus Leeming wrote: >> Jean-Marc, >> >> this patch removes the 'ugly hack' in forms.c and tries to do the >> 'right thing' in xpopup.c. My testing suggests that the popups in >> LyX are behaving 'better', but you're the one who's more familiar >> with those problems. >> >> Could you try it out? I'd value some feedback about any changes to >> the user experience, good or bad. Angus> Forget it. The XSendEvent stuff makes it impossible to interact Angus> with the menu in demos/popup. Indeed. Angus> It breaks the popup code (popup and pup) in the demos Angus> directory. Incidentally, both these demos behave differently to Angus> popups in LyX. Yes, and I do not see why. JMarc From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 09:54:43 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 04 Jun 2004 15:54:43 +0200 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041159.23109.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 11:59:23 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041139.51941.angus.leeming@btopenworld.com> <200406041159.23109.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Is it me, or does demos/menu behave in a very strange way? If I Angus> click on "menu 4" a popup menu is displayed. If I click Angus> elsewhere on the form another, identical popup menu is Angus> displayed. If I click on this menu, a third, identical menu is Angus> displayed. If I click on this third menu, the action is taken Angus> and all popups disappear. Angus> This behaviour is identical in Xforms 1.0 and in XForms 1.1cvs Angus> (code identical to that on savannah), so it isn't my messing Angus> around that's broken stuff. It looks quite broken, indeed. It is maybe because the 4th menu is a TOUCH_MENU. These look quite useless, anyway. The code in pup.c seems to be very similar to what is done in xforms, but it does not suffer from redraw problems... JMarc From angus.leeming at btopenworld.com Fri Jun 4 10:04:12 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 15:04:12 +0100 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041159.23109.angus.leeming@btopenworld.com> Message-ID: <200406041504.12465.angus.leeming@btopenworld.com> On Friday 04 June 2004 2:54 pm, Jean-Marc Lasgouttes wrote: > It looks quite broken, indeed. It is maybe because the 4th menu is > a TOUCH_MENU. These look quite useless, anyway. > > The code in pup.c seems to be very similar to what is done in > xforms, but it does not suffer from redraw problems... Can you give me a prescription to trigger these problems myself? I've always been rather hazy about them. Now that I've got your attention ;-) Could you try out the attached patch (try 2). It seems to do the right thing (Ie, I can detect no change to either the demos programs or LyX) It seems that this code is triggered very rarely, if at all. If you remove the 'button_down' test, you'll get masses of print statements, so I think that it's doing the right thing. if (fl_pushobj && !button_down(xev.xbutton.state)) { fprintf(stderr, "Dispatching...\n"); XSendEvent(flx->display, flx->win, False, 0, &xev); } And it has the advantage of fixing the lyx scrollbar again... Angus -------------- next part -------------- A non-text attachment was scrubbed... Name: popup.diff Type: text/x-diff Size: 2947 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20040604/ff4382c4/attachment.bin From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 11:16:23 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 04 Jun 2004 17:16:23 +0200 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041504.12465.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 15:04:12 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041159.23109.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Can you give me a prescription to trigger these problems Angus> myself? I've always been rather hazy about them. Launch LyX and open a document. Click on Insert Click on Math Click on 'Special character' The math menu is supposed to have disappeared, but since no redraw has occured, there is a painting problem. I tried to take a snapshot, but it failed miserably. Angus> Now that I've got your attention ;-) Angus> Could you try out the attached patch (try 2). It seems to do Angus> the right thing (Ie, I can detect no change to either the demos Angus> programs or LyX) Does not fix the problem with LyX. But when I move the mouse over the lyx document, there is an horrible flicker. Angus> And it has the advantage of fixing the lyx scrollbar again... But we'll have to fix the scrollbar for other xforms versions anyway, won't we? JMarc From angus.leeming at btopenworld.com Fri Jun 4 11:59:37 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 16:59:37 +0100 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> Message-ID: <200406041659.37572.angus.leeming@btopenworld.com> On Friday 04 June 2004 4:16 pm, Jean-Marc Lasgouttes wrote: > Angus> Can you give me a prescription to trigger these problems > Angus> myself? I've always been rather hazy about them. > > Launch LyX and open a document. > Click on Insert > Click on Math > Click on 'Special character' > > The math menu is supposed to have disappeared, but since no redraw > has occured, there is a painting problem. I tried to take a > snapshot, but it failed miserably. Ok, I see it. Are you absolutely sure that it's a redraw problem? It seems to me that it should be possible to check if any 'shadowed' popups are visible before drawing an 'unshadowed' one. If they are, then they should be hidden. I also note that demos/pup.c has a posthandler. Something that XFormsMenubar does not. Moreover, this posthandler calls fl_showpup and fl_hidepup explicitly. Nowhere in XFormsMenubar are there calls to these functions. Regards, Angus From angus.leeming at btopenworld.com Fri Jun 4 12:00:52 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 17:00:52 +0100 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> Message-ID: <200406041700.52948.angus.leeming@btopenworld.com> On Friday 04 June 2004 4:16 pm, Jean-Marc Lasgouttes wrote: > Angus> Could you try out the attached patch (try 2). It seems to do > Angus> the right thing (Ie, I can detect no change to either the > demos Angus> programs or LyX) > > Does not fix the problem with LyX. Agreed, but equally importantly it does not break anything either. > But when I move the mouse over > the lyx document, there is an horrible flicker. You mean when selecting text? Yes, I see that too. However, it it occurs also without the patch. (Just tried.) Something is triggering fl_redraw_form. > Angus> And it has the advantage of fixing the lyx scrollbar > again... > > But we'll have to fix the scrollbar for other xforms versions > anyway, won't we? Sure, but that's easy: XWorkArea::XWorkArea(LyXView & owner, int w, int h) { ... unsigned long const mask = #if FL_VERSION == 0 || (FL_VERSION == 1 && FL_REVISION == 0) GCFunction; #else GCFunction | GCGraphicsExposures; #end copy_gc = XCreateGC(fl_get_display(), RootWindow(fl_get_display(), 0), mask, &val); } Ie, we revert to the same behaviour as in LyX 1.3.x. Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 12:16:26 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 04 Jun 2004 18:16:26 +0200 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041700.52948.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 17:00:52 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> <200406041700.52948.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> But when I move the mouse over the lyx document, there is an >> horrible flicker. Angus> You mean when selecting text? Yes, I see that too. However, it Angus> it occurs also without the patch. (Just tried.) Something is Angus> triggering fl_redraw_form. No, just move quickly the mouse over an empty document. >> But we'll have to fix the scrollbar for other xforms versions >> anyway, won't we? Angus> Sure, but that's easy: OK. JMarc From angus.leeming at btopenworld.com Fri Jun 4 12:16:54 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 17:16:54 +0100 Subject: [XForms] fl_set_font_name() verbiage In-Reply-To: References: Message-ID: <200406041716.54100.angus.leeming@btopenworld.com> On Wednesday 26 May 2004 4:58 am, Mike Heffner wrote: > On 05-May-2004 Angus Leeming wrote: > | On Thursday 15 January 2004 5:30 am, Mike Heffner wrote: > |> When fl_set_font_name() fails it will return -1 but it also > |> prints: > |> > |> In SetFont [fonts.c 246] Bad FontStyle request -1: blahblahblah > |> > |> This function is typically used as a method of testing whether a > |> font is loadable or not, so it's not always a fatal condition. > |> Can this print statement be wrapped in a debug-only conditional? > | > | Mike does this do the job: > | - M_err("SetFont", "Bad FontStyle request %d: %s", > | numb, flf->fname); > | + M_warn("SetFont", "Bad FontStyle request %d: %s", > | numb, flf->fname); > > How about changing it to M_debug(...)? 'warn' and 'err' essentially > always get printed (a bug for another day). I set it to M_info, which is just below the default threshold for printing. Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 12:18:57 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 04 Jun 2004 18:18:57 +0200 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041659.37572.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 16:59:37 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041504.12465.angus.leeming@btopenworld.com> <200406041659.37572.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: Angus> Ok, I see it. Are you absolutely sure that it's a redraw Angus> problem? It seems to me that it should be possible to check if Angus> any 'shadowed' popups are visible before drawing an Angus> 'unshadowed' one. If they are, then they should be hidden. As I see it, the code relies if possible on saveunders, which are not enabled on modern linux. Angus> I also note that demos/pup.c has a posthandler. Something that Angus> XFormsMenubar does not. Moreover, this posthandler calls Angus> fl_showpup and fl_hidepup explicitly. Nowhere in XFormsMenubar Angus> are there calls to these functions. But popup.c does not as far as I can see. JMarc From angus.leeming at btopenworld.com Fri Jun 4 12:24:44 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 17:24:44 +0100 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041700.52948.angus.leeming@btopenworld.com> Message-ID: <200406041724.44213.angus.leeming@btopenworld.com> On Friday 04 June 2004 5:16 pm, Jean-Marc Lasgouttes wrote: > >> But when I move the mouse over the lyx document, there is an > >> horrible flicker. > > Angus> You mean when selecting text? Yes, I see that too. However, > it Angus> it occurs also without the patch. (Just tried.) Something > is Angus> triggering fl_redraw_form. > > No, just move quickly the mouse over an empty document. I see nothing peculiar when I just move the mouse over an empty document. If, however, I press the LMB and repeat the exercise, then I do, indeed, get the flicker. Is that what you're doing? Angus From Jean-Marc.Lasgouttes at inria.fr Fri Jun 4 12:34:16 2004 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Fri, 04 Jun 2004 18:34:16 +0200 Subject: [XForms] Fixing the popups? In-Reply-To: <200406041724.44213.angus.leeming@btopenworld.com> (Angus Leeming's message of "Fri, 4 Jun 2004 17:24:44 +0100") References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041700.52948.angus.leeming@btopenworld.com> <200406041724.44213.angus.leeming@btopenworld.com> Message-ID: >>>>> "Angus" == Angus Leeming writes: >> No, just move quickly the mouse over an empty document. Angus> I see nothing peculiar when I just move the mouse over an empty Angus> document. If, however, I press the LMB and repeat the exercise, Angus> then I do, indeed, get the flicker. Angus> Is that what you're doing? Launch LyX File>New Open file menu, and then click somewhere else to close it move the mouse JMarc From Ivan.Powis at nottingham.ac.uk Fri Jun 4 12:48:11 2004 From: Ivan.Powis at nottingham.ac.uk (Ivan Powis) Date: Fri, 4 Jun 2004 17:48:11 +0100 Subject: [XForms] Xforms: incorrect reporting of mouse (XEvent) status to post-handler Message-ID: I have an old application which uses the post-handler to add greater interaction (rubber banded selections, zoom etc) to xy_plots. It used to work (with an occasional hiccup) but the problem has now got so bad as to make it unusable. Apparent problem: Inconsistent data is passed to the post handler by forms. In particular it seems to lose track of the "key" state. Immediately after a mouse button is depressed (generating an FL_PUSH) an immediate release (FL_RELEASE, key=0) is frequently getting reported back to the post handler, even though the button is still physically down, and is reported as such by fl_mouse_button(). Additionally examining the XEvent structure passed to the post handler as "xev" by using fl_xevent_name_print() reports the event as 12: Expose. [OK I know that the manual implies that the void *xev might not always be a valid XEvent pointer, but my experience in trying to debug this problem suggests that everywhere else in the posthandler section its more often right than not!] Once this spurious button release has been reported the forms lib obviously decides to remember the erroneous information that the mouse button is up! So it will not then report a genuine release as FL_RELEASE, and if the mouse is dragged with a button physically still down, forms reports FL_MOTION rather than FL_MOUSE to the posthandler - this rather breaks my rubber-banding code. Again interrogating xev for the raw XEvent codes shows that xev->xmotion.state correctly identifies the physically depressed mouse button. I may note that the problem appears the same in v.89 and v1 of the forms library, and isn't confined to a particular version of Linux and/or gcc. For example on Mandrake linux 8.2 (kernel 4.2, XFree 4.2.0, KDE 2.2.2) on the console xserver the app becomes unusable. But connect to this same system a remote pc running Exceed xserver and there is no problem using either the full KDE session or a single X-window opened on the Windows desktop. Likewise on a Redhat (kernel 2.4.20, XFree 4.3.0 KDE 3.1) the app is unusable at the console, but OK if viewed via a remote pc Xserver - in this case just an occasional glitch crops up, but basic functinality is not compromised). I think we saw some similar minor glitches on older HP/UX systems. Actually the degradation in performance at the linux consoles seems to correlate with the use of a heavyweight window manager like KDE or GNOME, but isn't confined to any particular WM. It seems then as though the forms library, rather than tracking the mouse button state via the XEvents it receives, tries to maintain its own internal record, which more often than not gets out of sync with the physical state and the reported status via xev. This then seems far far worse with a heavyweight local WM. I don't quite understand the significance of this, nor the inner workings of X. Anyone got any ideas, or suggestions where in the source to browse and what to look for? One possible work round here is to base decision making in the post handler on an examination of the raw XEvent *xev structure rather than whatever forms lib reports, but I'm concerned that the library doesn't seem to guarantee passing xev valid. Ivan -------------------------------------------------------------------- ___ ___/ _ __ / Ivan Powis [Ivan.Powis at Nottingham.ac.uk] / / / School of Chemistry / / _/ University of Nottingham / ___/ Nottingham NG7 2RD, UK / / TEL: +44-115-951-3467 / / FAX: +44-115-951-3562 _______/ ____/ http://www.chem.nott.ac.uk/IP.html -------------------------------------------------------------------- From angus.leeming at btopenworld.com Fri Jun 4 13:19:18 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 18:19:18 +0100 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041659.37572.angus.leeming@btopenworld.com> Message-ID: <200406041819.18921.angus.leeming@btopenworld.com> On Friday 04 June 2004 5:18 pm, Jean-Marc Lasgouttes wrote: > Angus> Ok, I see it. Are you absolutely sure that it's a redraw > Angus> problem? It seems to me that it should be possible to check > if Angus> any 'shadowed' popups are visible before drawing an > Angus> 'unshadowed' one. If they are, then they should be hidden. > > As I see it, the code relies if possible on saveunders, which are > not enabled on modern linux. > > Angus> I also note that demos/pup.c has a posthandler. Something > that Angus> XFormsMenubar does not. Moreover, this posthandler > calls Angus> fl_showpup and fl_hidepup explicitly. Nowhere in > XFormsMenubar Angus> are there calls to these functions. > > But popup.c does not as far as I can see. Ok, and the posthandlers are for the buttons b1, b2, not for the "Popup" button, so they're irrelvant here. Angus From angus.leeming at btopenworld.com Fri Jun 4 13:24:50 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Fri, 4 Jun 2004 18:24:50 +0100 Subject: [XForms] Fixing the popups? In-Reply-To: References: <200406041125.46406.angus.leeming@btopenworld.com> <200406041724.44213.angus.leeming@btopenworld.com> Message-ID: <200406041824.50814.angus.leeming@btopenworld.com> On Friday 04 June 2004 5:34 pm, Jean-Marc Lasgouttes wrote: > Angus> I see nothing peculiar when I just move the mouse over an > empty Angus> document. If, however, I press the LMB and repeat the > exercise, Angus> then I do, indeed, get the flicker. > > Angus> Is that what you're doing? > > Launch LyX > File>New > Open file menu, and then click somewhere else to close it > move the mouse Got it. Thanks. Angus From Gayle.C.Roth at nasa.gov Fri Jun 4 15:27:21 2004 From: Gayle.C.Roth at nasa.gov (Gayle C Roth) Date: Fri, 04 Jun 2004 15:27:21 -0400 Subject: [XForms] Wrong dirent header file? Message-ID: <5.1.1.5.2.20040604150948.016e4160@popserve.grc.nasa.gov> Hi. According to comments in listdir.c at the place where dirent_vms.h is included, and the #ifdef around the #include statement, the header file dirent_vms.h is only supposed to be included if the VMS version is less than 7.0. Ours is 7.3-2. It turned out that dirent_vms.h was not being included because of that #ifdef, so even though we have 7.3-2, I commented out the #ifdef and #endif so the struct definitions would be included. That's when I found out that, no, dirent_vms.h is the wrong file to include since its structs are not up to date (for example, there's no 'd_reclen' in struct dirent). Therefore, I still got a fatal compiler error. What's the up-to-date header file for version 7.3-2? That must be what I need. Thanks, Gayle From rostamian at umbc.edu Fri Jun 4 19:57:58 2004 From: rostamian at umbc.edu (Rouben Rostamian) Date: Fri, 4 Jun 2004 19:57:58 -0400 Subject: [XForms] missing #include in glcanvas.h Message-ID: <200406042357.i54Nvw7Y028210@pc18.math.umbc.edu> Minor bug in xforms-1.0.90: Where: xforms-1.0.90/gl/glcanvas.h Problem: Missing header: #include How to fix: Add: #include near the top of xforms-1.0.90/gl/glcanvas.h Details: The #include is needed to resolve references to GLXContext in xforms-1.0.90/gl/glcanvas.h. Currently, the supplied demos work by accident, because they happen to #include the header files #include #include just in the right order. Reversing the #include order will break them. -- Rouben Rostamian From angus.leeming at btopenworld.com Sat Jun 5 07:25:32 2004 From: angus.leeming at btopenworld.com (Angus Leeming) Date: Sat, 5 Jun 2004 12:25:32 +0100 Subject: [XForms] missing #include in glcanvas.h In-Reply-To: <200406042357.i54Nvw7Y028210@pc18.math.umbc.edu> References: <200406042357.i54Nvw7Y028210@pc18.math.umbc.edu> Message-ID: <200406051225.32631.angus.leeming@btopenworld.com> On Saturday 05 June 2004 12:57 am, Rouben Rostamian wrote: > To subscribers of the xforms list > Problem: > Missing header: > #include Hi, Rouben. Thanks for the bug report. The fix is already in cvs and will, therefore, also be in XForms 1.1. Regards, Angus From jac4 at mindless.com Mon Jun 7 10:22:55 2004 From: jac4 at mindless.com (jason cipriani) Date: Mon, 07 Jun 2004 09:22:55 -0500 Subject: [XForms] missing #include in glcanvas.h Message-ID: <20040607142255.33A78790036@ws1-14.us4.outblaze.com> I can't help but chuckle, though. Oh if only GL (and GLX... and WGL... and AGL... and... ugh) was part of the standard C library, heh... On another topic, I've been quite busy with work recently, but I will eventually have time to put together some of that buggy Fedora GL code. I didn't forget. Jason > To subscribers of the xforms list > > > On Saturday 05 June 2004 12:57 am, Rouben Rostamian wrote: > > To subscribers of the xforms list > > Problem: > > Missing header: > > #include > > Hi, Rouben. > Thanks for the bug report. The fix is already in cvs and will, > therefore, also be in XForms 1.1. > > Regards, > Angus -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From Ivan.Powis at nottingham.ac.uk Sat Jun 12 17:38:57 2004 From: Ivan.Powis at nottingham.ac.uk (Ivan Powis) Date: Sat, 12 Jun 2004 22:38:57 +0100 Subject: [XForms] incorrect reporting of mouse (XEvent) status to post-handler Message-ID: I posted this problem a week ago. In short, in an application providing mouse interaction via pre/post handlers I notice a spurious response - seemingly xforms detects and reports an FL_RELEASE immediately following FL_PUSH event, even when the mouse button is still physically held down. This completely screws up the ability of the application to track the mouse actions. It occurs in version of xforms since 0.89, on various OSes. Interestingly it is is much more evident on the console of a linux box, than when running via a remote X server. I have at least now tracked the apparent problem to the following section of forms.c, around line 1357: #if 1 /* this is an ugly hack. This is necessary due to popup pointer grab where a button release is eaten. Really should do a send event from the pop-up routines */ if (fl_pushobj && !button_down(fl_keymask) /* && event == FL_ENTER */ ) { obj = fl_pushobj; fl_pushobj = NULL; fl_handle_object(obj, FL_RELEASE, xx, yy, key, xev); } #endif .. in particular it is the call to fl_handle_object which I believe initiates the spurious FL_RELEASE report to the handlers. Evidently this section of code comes with a health warning attached. Anyone understand what it is trying to do? Wasn't there some reference to this same section in a discussion of odd pup-up behaviour a few weeks ago? Ivan Powis -----Original Message----- From: xforms-bounces at bob.usuhs.mil [mailto:xforms-bounces at bob.usuhs.mil]On Behalf Of Ivan Powis Sent: 04 June 2004 17:48 To: xforms at bob.usuhs.mil Subject: [XForms] Xforms: incorrect reporting of mouse (XEvent) status to post-handler To subscribers of the xforms list [...] I may note that the problem appears the same in v.89 and v1 of the forms library, and isn't confined to a particular version of Linux and/or gcc. For example on Mandrake linux 8.2 (kernel 4.2, XFree 4.2.0, KDE 2.2.2) on the console xserver the app becomes unusable. But connect to this same system a remote pc running Exceed xserver and there is no problem using either the full KDE session or a single X-window opened on the Windows desktop. Likewise on a Redhat (kernel 2.4.20, XFree 4.3.0 KDE 3.1) the app is unusable at the console, but OK if viewed via a remote pc Xserver - in this case just an occasional glitch crops up, but basic functinality is not compromised). I think we saw some similar minor glitches on older HP/UX systems. Actually the degrada