From jt at toerring.de Mon Nov 24 11:49:34 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 24 Nov 2008 17:49:34 +0100 Subject: [XForms] New release XForms 1.0.91 In-Reply-To: <20081124113542.GA31211@toerring.de> References: <20081122204654.GA2445@toerring.de> <492A160C.4090706@dineamix.ca> <20081124113542.GA31211@toerring.de> Message-ID: <20081124164934.GA11034@toerring.de> To subscribers of the xforms list Hi Serge, On Mon, Nov 24, 2008 at 12:35:42PM +0100, Jens Thoms Toerring wrote: > About the second form you have on the web page: I am not sure where > this comes from. I just see that some objects have a black instead > of a grey background but I don't know what kind of objects that are I just had another look and realized that you wrote that it are choice objects, sorry that I missed that before. So I tried to deactivate all kinds of choice objects (i.e. FL_NORMAL_CHOICE, FL_NORMAL_CHOICE2, FL_DROPLIST_CHOICE) but couldn't reproduce the problem here. Did you anything with them beside deactiva- ting them? Could you perhaps send me a few lines from your pro- gram where you create choice objects and manipulate their pro- perties (it doesn't have to be a full working program, just something that gives me an idea what you're doing with the choice objects)? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Nov 24 06:35:42 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 24 Nov 2008 12:35:42 +0100 Subject: [XForms] New release XForms 1.0.91 In-Reply-To: <492A160C.4090706@dineamix.ca> References: <20081122204654.GA2445@toerring.de> <492A160C.4090706@dineamix.ca> Message-ID: <20081124113542.GA31211@toerring.de> To subscribers of the xforms list Hi Serge, > Compiled the libraries without incident. I recompiled some of the x-apps > using the new static xforms library with some odd results. Since I am > unable to include pictures with this post you can view them at > "www.dineamix.ca/xforms" along with some notes. About the fonts in the menus: there seemed to a general consensus here (at least by those that commented) that the old look of XForms wasn't very nice anymore and that it woud be better to make it look a bit more like more modern GUI toolkits. Thus I changes several things: the default border width of objects has been reduced from 3 to 1 pixel. The font in menus, popups etc. has been switched from bold to normal font. The shadows around menus have been re- moved (they were problematic anyway, they actually bever worked correctly and I didn't see any way how to get it right..). So things look less extreme 3D then they used to (which looked a lot like in the early years of the last decade when everybody was a bit over-enthusiastic about having 3D effects;-) If you want just to have a bold font for the labels for menus and popups I think all you need is to call fl_set_object_lstyle( obj, FL_BOLD_STYLE ); on the objects for the menus. That hopefully should give you back the old look of the first form you have on that webpage. If you also want the old font style (bold italics) in the windows that pop up for menus etc., then you would have to call once fl_setpup_default_fontstyle( FL_BOLDITALIC_STYLE ); before you create the menus (this is an application-wide setting). How to give the windows that pop up for menus etc. a more 3D-ish look I haven't figured out yet, it may require adding a new func- tion. For the "shadows" around them I have no idea at all how to get them right, so I can't make any promises that you'll get them back. About the second form you have on the web page: I am not sure where this comes from. I just see that some objects have a black instead of a grey background but I don't know what kind of objects that are (I tried deactivated menus and choice objects but that didn't do the trick here). It's not unlikely that you fond some bug there but since it's not clear to me what types of objects they are I have no good idea at the moment where to look. > As a note I did not use the new GL or flimage libraries. Maybe I should? > I will try these libraries later once our production compiles have > completed. I can't tell since never tried mixing different versions. On the one hand, the libraries should be independent of each other, but you never know;-) Sorry for the inconveniences, I hope we can resolve these problems real soon! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From serge at dineamix.ca Sun Nov 23 21:48:44 2008 From: serge at dineamix.ca (Serge Bromow) Date: Sun, 23 Nov 2008 21:48:44 -0500 Subject: [XForms] New release XForms 1.0.91 In-Reply-To: <20081122204654.GA2445@toerring.de> References: <20081122204654.GA2445@toerring.de> Message-ID: <492A160C.4090706@dineamix.ca> To subscribers of the xforms list Hi Jens, Compiled the libraries without incident. I recompiled some of the x-apps using the new static xforms library with some odd results. Since I am unable to include pictures with this post you can view them at "www.dineamix.ca/xforms" along with some notes. As a note I did not use the new GL or flimage libraries. Maybe I should? I will try these libraries later once our production compiles have completed. Thanks, Serge Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi everybody, > > as threatend I have uploaded a new release of XForms, 1.0.91. > You can download it from > > http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91.tar.gz > > I hope that this is another step on the rather long-winded road to > the 1.1.0 version and I would like to thank all of you for contri- > buting code and bug fixes, send bug reports or made suggestions! > Very special thanks go to Angus Leeming and Jean-Marc Lasgouttes > who both did a lot of excellent work I then could continue from. > > There are a few cosmetic changes compared to the last pre-release, > mostly to silence a few compiler warnings (gcc 4.3.2 is a bit more > picky than the older version I was using before). I hope that I did > not break anything essential with these minor changes... > > With the new release out I guess we should take a look at what's > needed on the further road to 1.1.0. I have three points that I think > could be interesting: > > a) Make the documentation available in a useful format and work in > the changes that have been made in the code > b) UTF-8 support > c) Support for TrueType fonts > > I guess I will start with a) as soon as possible since I feel that > a library without proper documentation is rather useless. As I al- > ready wrote a few days ago I am still undecided about the format. > I got the suggestion via private email to use a Wiki. While that > looks like a good solution I am a bit concerned where we could host > a Wiki and if there are enough people prepared to make sure it won't > get vandalized. There is also the question if it's possible to get a > nicely printed version out of it (but maybe it's only me that likes > printed documentation nowadays, so that isn't necessarily a relevant > argument). If someone has thoughts about all that please let me know. > > Points b) and c) are from my personal wishlist but I don't know how > relevant they are to others. There probably are a lot of other, more > important points that need some work and I would like to ask you to > discuss them here on the mailing list! > > Another point I am a bit concerned about is the claim made in several > places that XForms works X11 R4, R5 and R6 as well as with operating > systems as OS2, VMS etc. I have no access to machines with X11 R4 or > R5 or OS2 or VMS so I am in no position to determine if these are > still correct. Are there some people out there that can confirm them > or should we better stop making these claims? > > And, of course, there will still be a number of bugs in the new > release. So, please, don't stop sending me bug reports about what- > ever you find not to be working correctly. > > Best regards, Jens > -- Serge Bromow DineAmix Inc. 888 411-6636 Ottawa, Canada. http://www.dineamix.ca IMPORTANT NOTICE: This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify DineAmix Inc. immediately by email at postmaster at dineamix.ca. Thank you. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Nov 22 15:46:54 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 22 Nov 2008 21:46:54 +0100 Subject: [XForms] New release XForms 1.0.91 Message-ID: <20081122204654.GA2445@toerring.de> To subscribers of the xforms list Hi everybody, as threatend I have uploaded a new release of XForms, 1.0.91. You can download it from http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91.tar.gz I hope that this is another step on the rather long-winded road to the 1.1.0 version and I would like to thank all of you for contri- buting code and bug fixes, send bug reports or made suggestions! Very special thanks go to Angus Leeming and Jean-Marc Lasgouttes who both did a lot of excellent work I then could continue from. There are a few cosmetic changes compared to the last pre-release, mostly to silence a few compiler warnings (gcc 4.3.2 is a bit more picky than the older version I was using before). I hope that I did not break anything essential with these minor changes... With the new release out I guess we should take a look at what's needed on the further road to 1.1.0. I have three points that I think could be interesting: a) Make the documentation available in a useful format and work in the changes that have been made in the code b) UTF-8 support c) Support for TrueType fonts I guess I will start with a) as soon as possible since I feel that a library without proper documentation is rather useless. As I al- ready wrote a few days ago I am still undecided about the format. I got the suggestion via private email to use a Wiki. While that looks like a good solution I am a bit concerned where we could host a Wiki and if there are enough people prepared to make sure it won't get vandalized. There is also the question if it's possible to get a nicely printed version out of it (but maybe it's only me that likes printed documentation nowadays, so that isn't necessarily a relevant argument). If someone has thoughts about all that please let me know. Points b) and c) are from my personal wishlist but I don't know how relevant they are to others. There probably are a lot of other, more important points that need some work and I would like to ask you to discuss them here on the mailing list! Another point I am a bit concerned about is the claim made in several places that XForms works X11 R4, R5 and R6 as well as with operating systems as OS2, VMS etc. I have no access to machines with X11 R4 or R5 or OS2 or VMS so I am in no position to determine if these are still correct. Are there some people out there that can confirm them or should we better stop making these claims? And, of course, there will still be a number of bugs in the new release. So, please, don't stop sending me bug reports about what- ever you find not to be working correctly. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Nov 20 16:54:09 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 20 Nov 2008 22:54:09 +0100 Subject: [XForms] Any further tests in the working? Message-ID: <20081120215409.GA23334@toerring.de> To subscribers of the xforms list Hi everybody, since the last pre-release 10 days ago I haven't received a single bug report or information about problems. I wonder if I may take this as a sign that the 14th pre-release looks ok to everyone of you. Or are there some people still planing to do tests but didn't come around to do them? In the first case I would consider making a "real" release out of the pre-release over the next weekend. Therefore I would like to ask those of you still planing to do tests to send me () a short email so that I still wait a bit. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Nov 11 12:03:21 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 11 Nov 2008 18:03:21 +0100 Subject: [XForms] Format for documentation Message-ID: <20081111170321.GA29010@toerring.de> To subscribers of the xforms list Hi again, as I already wrote yesterday I am thinking about converting the existing PDF documentation into a format that we can work on again. Now my question is if you have recommendations for the format to be used. I am most used to the texi format, but I also had a look at docbook. Both seem to be quite fine in the sense that you can create documentation in diverse output formats (HTML, PDF, info etc.) which I think is important. Does anyone of you has good arguments for one or the other or maybe even has a better idea? Regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Nov 10 15:57:31 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 10 Nov 2008 21:57:31 +0100 Subject: [XForms] New pre-release: xforms-1.0.91pre14 Message-ID: <20081110205731.GA20287@toerring.de> To subscribers of the xforms list Hi everybody, here again is a new pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre14.tar.gz There are a number of bug fixes and a new function: a) in the code for drawing clocks a memory overrun was fixed b) in the code for fl_finish() a bug that resulted in trying to remove tooltip windows nore than once got removed c) A mistake in the code to decide which mouse buttons a button reacts to was corrected. d) Rob Carpenter found that the bounding box of objects was not computed correctly, resulting in very slow redraws in certain situations. e) Rob also found that trying to scroll in a browser that doesn't contain any lines resulted in a segmentation fault. f) According to Serge Bromow's suggestion a function was added that allows to figure out if a form's window is iconified. It's called fl_form_is_iconified() and takes a single argu- ment, a pointer to the form. Thanks to everbody who send in bug reports and suggestions! As you can see there aren't that many changes, but then I did not receive too many bug reports;-) I hope that this can be taken as a sign that the code has been stabilized a bit and we can finally have a "real" release. Therefor I would like to ask you to have another good look at the new pre-release and please tell me about all bugs or just issues you find so that they can be cleared up before the final release! One outstanding bug is about compiling XForms on AIX, where it seems to be necessary to run the configure script like this LIBS=-lX11 ./configure --enable-demos Since I don't have access to an AIX machine and really don't understand what's happening there I would again like to ask people with access to AIX to take a look at that or, if pos- sible, give me an account on such a machine for a few days. Aonother question is how to proceed when we've got a new release. I think I will try to start working on the documentation first so that it's at least in a form that it can be changed (at the moment there's only a PostScript version of the last version and that has to be converted somehow to a format that can be edited). One thing I also am interested in a bit is to add the capability to XForms to use TrueType fonts. But that's not something I con- sider extremely important and I am open to all kinds of other and perhaps more important suggestions! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From serge at dineamix.ca Tue Oct 21 14:49:56 2008 From: serge at dineamix.ca (Serge Bromow) Date: Tue, 21 Oct 2008 14:49:56 -0400 Subject: [XForms] XForms min/max events In-Reply-To: <20081019221727.GA27479@toerring.de> References: <20081018152249.GA21149@toerring.de> <48FA9043.6010304@dineamix.ca> <20081019221727.GA27479@toerring.de> Message-ID: <48FE2454.8050003@dineamix.ca> To subscribers of the xforms list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20081021/10f729a2/attachment-0005.html -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sun Oct 19 18:17:27 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 20 Oct 2008 00:17:27 +0200 Subject: [XForms] XForms min/max events In-Reply-To: <48FA9043.6010304@dineamix.ca> References: <20081018152249.GA21149@toerring.de> <48FA9043.6010304@dineamix.ca> Message-ID: <20081019221727.GA27479@toerring.de> To subscribers of the xforms list Hi Serge, nice to have you back on board;-) > My problem was when a user minimized the screen using the window > manager decoration I did not have a way of knowing whether I should > raise the window or not since no variable was set. Hence my need to > trap the iconify action from the window manager. > I tried using the "fl_form_is_visible(form);" call but it always > returns TRUE whether the form is on the display or minimized. Other > attempts proved fruitless. i.e checking "form->visible" and > "form->wm_border" variables. > The problem was resolved by using the "XGetWindowAttributes(fl_display, > win_mini, &xwa);" call. This call fills the xwa structure and one > variable in that structure is "xwa.map_state". This is TRUE if the > window is on the display and FALSE if it is minimized or not on the > current display. A test of this variable after a caller event was all I > needed to know if I should set my variables and raise the window.
The value of "form->visible" or the return value of the function fl_form_s_visible() only get changed by calls of the fl_hide_form() or fl_free_form() function but not by the window getting unmapped when it's iconified (XForms doesn't deal with the Unmap/Map event except by calling XRefreshKeyboardMapping() on a MappingNotify event). So even when the window is in iconified state it's treated as "visible". As you already found out you have to query the window attributes to find out if the window is mapped (but note that the "map_state" value isn't just a boolean, there are three possible values it can have, IsUnmapped (0), IsUnviewable (1) and IsViewable (2), the IsUnviewable value undicating that while the window itself is mapped a parent window is unmapped so it's not really shown on the screen). So the combination of "form->visible" being set to FL_VISIBLE (or the corresponding return value of fl_form_is_visible()) together with XGetWindowAttributes() telling you that the window is not mapped looks like the best indication of the window being in iconified state. Perhaps I should add a function with a name like fl_form_is_iconified() to make it easier to check for this. While the name of the function fl_form_is_visible() is a bit unlucky I wouldn't like to change its behaviour since that might break programs that rely on it to tell you if a form has been hidden by a call of fl_hide_form() etc. or not. Or do you need a callback for a form's window becoming iconified or de- iconified? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From serge at dineamix.ca Sat Oct 18 21:41:23 2008 From: serge at dineamix.ca (Serge Bromow) Date: Sat, 18 Oct 2008 21:41:23 -0400 Subject: [XForms] XForms min/max events In-Reply-To: <20081018152249.GA21149@toerring.de> References: <20081018152249.GA21149@toerring.de> Message-ID: <48FA9043.6010304@dineamix.ca> To subscribers of the xforms list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20081018/d922a7a8/attachment-0006.html -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Oct 18 11:22:49 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 18 Oct 2008 17:22:49 +0200 Subject: [XForms] XForms min/max events Message-ID: <20081018152249.GA21149@toerring.de> To subscribers of the xforms list Hi Serge, I have just seen your question on Savannah concerning min/max events, Please accept my appologies for the long delay - questions are normally asked in the XForms mailing list http://cweblog.usuhs.mil/mailman/listinfo/xforms and the last question coming up on Savannah was that long ago that I don't often check there... > Hi Xforms, > I would like my app to trap window min/max events. I have read > through the docs without success. > Is there a way to set a callback or trap a SIGNAL when these events > occur? I guess with min/max event you mean something that happens only when the minimize/maximize button on the window decorations is clicked on. Please correct me if I am wrong but that's the only thing I can think of at the moment. The problem here is that there's no special event that would distinguish it in any way from any other resizing of the window. The only thing visible from an application is receiving a ConfigureNotify X event that informs the application that the windows size has been changed, but there's nothing that indicates that it's due to the minimize/maximize button in the window deco- rations having been clicked on - that's something only the window manager would know about which takes care of these decorations. At the momement there's not even a mechanism to set a callback for ConfigureNotify events (even via fl_register_raw_callback()), probably since an application normal;y doesn't need to know about that (in case you really need to know that a windows size has changed you typically would simply ask for it's size). But I could add something that allows to install a preemptive handler also for ConfigureNotify events if you think it's really needed. But that still won't tell you if that event is due to a min/max button the window manager may display... I am going to send this reply also to the mailing list so that others can comment if they think my answer is wrong or incom- plete or have a good idea for you. If you don't want to sub- scribe to the mailing list you will be able to see further replies also her http://groups.google.com/group/fa.xforms/topics?lnk Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sun Sep 21 09:56:06 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 21 Sep 2008 15:56:06 +0200 Subject: [XForms] New pre-release 1.0.91pre13 Message-ID: <20080921135606.GA23755@cm.toerring.de> To subscribers of the xforms list Hi everybody, sorry for the long delay since the last pre-release but, un- fortunately, I was rather busy with some other work. But here we go again with number 13: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre13.tar.gz Unfortunately, not all the problems that got reported could be addressed with this version since in some cases I didn't get re- plies about the somewhat more elusive bugs (i.e. the ones I did not manage to reproduce). So they have to be left for the next pre-rlease... Most important changes: a) The placement of windows was dealt with in a somewhat out-fashioned way. Especially the assumption was made that all window managers would reparent the windows for forms within a window with the decorations (i.e. title bar and borders). But that's not the case (e.g. with the default 'metacity' window manager used by Gnome). That led to problems for programs that try to store the position of a window and set this position again when the program is run again. Also setting positions with negative posititons (which indicates that the position is meant relative to the right and/or bottom border of the screen) didn't work properly. b) Bug (my own!) in goodies removed that led to texts on buttons being wrong or missing. c) As J. P. Mellor pointed out inactivated input objects could still be edited. Hopefully corrected. d) Removed a bug pointed out by Werner Heisch that crashed fdesign if the type of an object was changed. e) Bug in fdesign fixed that led to crash when the type of a composite object was changed and then Restore or Cancel was clicked. f) Forgotten removal of tooltip in deletion of object added, could lead to a segmentation fault. There are still one or two bugs on my list but about which I am not sure yet if they are XForms bugs or in the application progams and where I am still looking forward to receiving further informations. And then there's a problem with building XForms on AIX 5.3 where make stops with a crash in fdesign when creating the demo programs. While I got all the logs of the make process I unfortunately wasn't able yet to figure out what needs to be done about it. Problem is that I never used AIX and also have no access to such a machine. So if someone here has either experience with AIX and feels like trying to solve the problem or would be able to temporarily give me an account on such machine for testing please send me an email. And, as usual, please tell me about everything you find that's not working correctly! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jpmellor at rose-hulman.edu Sat Jul 19 13:59:47 2008 From: jpmellor at rose-hulman.edu (J.P. Mellor) Date: Sat, 19 Jul 2008 13:59:47 -0400 Subject: [XForms] deactivating input fields In-Reply-To: <20080719173437.GA7382@toerring.de> References: <18562.4075.540294.306434@mellor.home.rose-hulman.edu> <20080719173437.GA7382@toerring.de> Message-ID: <18562.11155.632026.908072@mellor-wireless.home.rose-hulman.edu> To subscribers of the xforms list I'm using 1.0.91pre9. I ment to include that the first time, but hit send too quickly ;^( Thanks, jp Jens Thoms Toerring writes: > Hello, > > On Sat, Jul 19, 2008 at 12:01:47PM -0400, J.P. Mellor wrote: > > It appears that calling fl_deactivate_object() on an input field has > > no effect. After deactivating the input field, the input can still be > > changed. Is this correct behavior or am I missing something. > > I don't think so;-) and I will investigate what's going wrong > ASAP. Just one question: are using the newest pre-release or > something older? And if you have an example program it would > be nice if you could send it to me. > > Best regards, Jens _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Jul 19 13:34:37 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 19 Jul 2008 19:34:37 +0200 Subject: [XForms] deactivating input fields In-Reply-To: <18562.4075.540294.306434@mellor.home.rose-hulman.edu> References: <18562.4075.540294.306434@mellor.home.rose-hulman.edu> Message-ID: <20080719173437.GA7382@toerring.de> To subscribers of the xforms list Hello, On Sat, Jul 19, 2008 at 12:01:47PM -0400, J.P. Mellor wrote: > It appears that calling fl_deactivate_object() on an input field has > no effect. After deactivating the input field, the input can still be > changed. Is this correct behavior or am I missing something. I don't think so;-) and I will investigate what's going wrong ASAP. Just one question: are using the newest pre-release or something older? And if you have an example program it would be nice if you could send it to me. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jpmellor at rose-hulman.edu Sat Jul 19 12:01:47 2008 From: jpmellor at rose-hulman.edu (J.P. Mellor) Date: Sat, 19 Jul 2008 12:01:47 -0400 Subject: [XForms] deactivating input fields Message-ID: <18562.4075.540294.306434@mellor.home.rose-hulman.edu> To subscribers of the xforms list It appears that calling fl_deactivate_object() on an input field has no effect. After deactivating the input field, the input can still be changed. Is this correct behavior or am I missing something. Thanks, jp _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Aug 30 18:27:49 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 31 Aug 2008 00:27:49 +0200 Subject: [XForms] XForms pre-release 1.0.91pre12 In-Reply-To: <20080802200436.GA28377@toerring.de> References: <20080712210708.GB8226@toerring.de> <20080801121058.GA29748@astrouw.edu.pl> <20080802200436.GA28377@toerring.de> Message-ID: <20080830222748.GB8358@toerring.de> To subscribers of the xforms list Hi Michal, i wrote an email to you some time ago since figuring out what the reasons for the bugs you found is a bit difficult without more detailed information. I hope you don't mind that I write you again since I haven't got a reply yet and my or your mail may have got lost. It would be very helpful if you could send me some (preferably compilable;-) example code that shows the problems since I don't know exactly what you're doing in your program and so trying to write something that reproduces the bugs is nearly impossible. If you are prepared to just send me the program (perhaps with a few example data files) that would be just fine, I hope I will find my way through it. In case my email got lost I append it to this mail. Best regards, Jens On Sat, Aug 02, 2008 at 10:04:36PM +0200, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi Michal, > > On Fri, Aug 01, 2008 at 02:10:58PM +0200, Michal Szymanski wrote: > > To subscribers of the xforms list > > I thought that problem was already gone but no, it is still there, maybe > > in a bit changed form. To remind what happens, a self-quote :) > > > > > It seems that the library (?) is autogenerating some events > > > [...] > > > As I deal with images from a mosaic CCD, my app has a group of 8 buttons > > > with the same callback registered, named "cb_select_mosaic" and > > > different "argument" value, from 0 to 7. When clicked, it normally > > > displays file named "some_prefix.N.fts" where N is 1-8 (callback data > > > argument+1). > > > Now, if I run it as "image o.1.fts", everything seems OK, the image gets > > > displayed and when I click mosaic buttons, it displays other files > > > (o.2.fts etc.) > > > > > > When, however, I run the program as "image o.2.fts" (or any other number > > > 2-8), it displays the file but immediately starts to switch between the > > > given number and #1. Somehow the event gets autogenerated I added a > > > debug printout to "cb_select_mosaic" procedure and it shows: > > > > > > cb_select_mosaic 0 > > > cb_select_mosaic 4 > > > cb_select_mosaic 0 > > > cb_select_mosaic 4 > > > > Now the above is fixed, I guess since "pre6" or so. > > Yes, if I remember correctly it was due to not enough memory having > been allocated for storing all command line arguments... > > > I am getting, however, > > similar behavior when I use another feature of my display app: > > > > When it is invoked with more-than-one filename argument, clicking the > > right button on the "FILE" button should display the image taken from > > the next command invocation argument (without having to go through file > > selector form, bound to left-click on the FLE button). It works *mostly* > > fine, unless I click that button many times without waiting for the > > images to be fully loaded. Then, after a few "proper" displays, the app > > starts to auto-change between some (randomly chosen, but always already > > read) images. This seems to be an infinite loop although it still reacts > > (with some delay) to EXIT button, so the app does not completely go > > astray, it just starts to get auto-generated events. > > > > As always, this could be a bug in my app, in old days, however (I still > > have those older version, compiled with "official" XForms releases), it > > worked fine, no matter how quickly I repeated the mouse clicks. > > I guess it's not going to be easy finding the reason without > some program that exhibits the problem. Would it be possible > that you send me your program (or some example program that > shows the same problem)? > > > > The same image display app > > > has a few keyboard shortcuts working while inside the image canvas which > > > open a new window (form) and display some data in it. I have noticed a > > > strange behavior - when the new window is created, it displays its data > > > OK. Then I move the mouse (still in the image canvas) and press > > > the same key again - > > > it should display the data for the new image position, but it does > > > not. Only when I click a mouse button or leave and enter again the image > > > canvas, the key starts to work. And it works fine (displaying proper > > > data for every mouse position in the canvas) until I close the window. > > > When I open it again, the same situation repeats ("dead" after first > > > opening, then clicking or leaving/entering the canvas, then working > > > fine). This problem occurred even in the "official" releases of > > > xforms in some hard-to-pinpoint combinations of Linux system version, > > > X11 version and architecture. Now, with most machines on which it is > > > used got upgraded to more up-to-date systems (e.g. CentOS 5.1), the > > > problem seems to be persistent. It is probably not connected to 1.0.91 > > > but still, may mark a problem in the library. > > Looks like a bit like an old, still unresolved bug. Again, would it > be possible to send me some example code? I guess that would help me > a lot in figuring out what's broken... > > Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Aug 2 16:04:36 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 2 Aug 2008 22:04:36 +0200 Subject: [XForms] New pre-release 1.0.91pre12 In-Reply-To: <20080801121058.GA29748@astrouw.edu.pl> References: <20080712210708.GB8226@toerring.de> <20080801121058.GA29748@astrouw.edu.pl> Message-ID: <20080802200436.GA28377@toerring.de> To subscribers of the xforms list Hi Michal, On Fri, Aug 01, 2008 at 02:10:58PM +0200, Michal Szymanski wrote: > To subscribers of the xforms list > I thought that problem was already gone but no, it is still there, maybe > in a bit changed form. To remind what happens, a self-quote :) > > > It seems that the library (?) is autogenerating some events > > [...] > > As I deal with images from a mosaic CCD, my app has a group of 8 buttons > > with the same callback registered, named "cb_select_mosaic" and > > different "argument" value, from 0 to 7. When clicked, it normally > > displays file named "some_prefix.N.fts" where N is 1-8 (callback data > > argument+1). > > Now, if I run it as "image o.1.fts", everything seems OK, the image gets > > displayed and when I click mosaic buttons, it displays other files > > (o.2.fts etc.) > > > > When, however, I run the program as "image o.2.fts" (or any other number > > 2-8), it displays the file but immediately starts to switch between the > > given number and #1. Somehow the event gets autogenerated I added a > > debug printout to "cb_select_mosaic" procedure and it shows: > > > > cb_select_mosaic 0 > > cb_select_mosaic 4 > > cb_select_mosaic 0 > > cb_select_mosaic 4 > > Now the above is fixed, I guess since "pre6" or so. Yes, if I remember correctly it was due to not enough memory having been allocated for storing all command line arguments... > I am getting, however, > similar behavior when I use another feature of my display app: > > When it is invoked with more-than-one filename argument, clicking the > right button on the "FILE" button should display the image taken from > the next command invocation argument (without having to go through file > selector form, bound to left-click on the FLE button). It works *mostly* > fine, unless I click that button many times without waiting for the > images to be fully loaded. Then, after a few "proper" displays, the app > starts to auto-change between some (randomly chosen, but always already > read) images. This seems to be an infinite loop although it still reacts > (with some delay) to EXIT button, so the app does not completely go > astray, it just starts to get auto-generated events. > > As always, this could be a bug in my app, in old days, however (I still > have those older version, compiled with "official" XForms releases), it > worked fine, no matter how quickly I repeated the mouse clicks. I guess it's not going to be easy finding the reason without some program that exhibits the problem. Would it be possible that you send me your program (or some example program that shows the same problem)? > > The same image display app > > has a few keyboard shortcuts working while inside the image canvas which > > open a new window (form) and display some data in it. I have noticed a > > strange behavior - when the new window is created, it displays its data > > OK. Then I move the mouse (still in the image canvas) and press > > the same key again - > > it should display the data for the new image position, but it does > > not. Only when I click a mouse button or leave and enter again the image > > canvas, the key starts to work. And it works fine (displaying proper > > data for every mouse position in the canvas) until I close the window. > > When I open it again, the same situation repeats ("dead" after first > > opening, then clicking or leaving/entering the canvas, then working > > fine). This problem occurred even in the "official" releases of > > xforms in some hard-to-pinpoint combinations of Linux system version, > > X11 version and architecture. Now, with most machines on which it is > > used got upgraded to more up-to-date systems (e.g. CentOS 5.1), the > > problem seems to be persistent. It is probably not connected to 1.0.91 > > but still, may mark a problem in the library. Looks like a bit like an old, still unresolved bug. Again, would it be possible to send me some example code? I guess that would help me a lot in figuring out what's broken... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From msz at astrouw.edu.pl Fri Aug 1 08:10:58 2008 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Fri, 1 Aug 2008 14:10:58 +0200 Subject: [XForms] New pre-release 1.0.91pre12 In-Reply-To: <20080712210708.GB8226@toerring.de> References: <20080712210708.GB8226@toerring.de> Message-ID: <20080801121058.GA29748@astrouw.edu.pl> To subscribers of the xforms list Hello, I thought that problem was already gone but no, it is still there, maybe in a bit changed form. To remind what happens, a self-quote :) > It seems that the library (?) is autogenerating some events > [...] > As I deal with images from a mosaic CCD, my app has a group of 8 buttons > with the same callback registered, named "cb_select_mosaic" and > different "argument" value, from 0 to 7. When clicked, it normally > displays file named "some_prefix.N.fts" where N is 1-8 (callback data > argument+1). > Now, if I run it as "image o.1.fts", everything seems OK, the image gets > displayed and when I click mosaic buttons, it displays other files > (o.2.fts etc.) > > When, however, I run the program as "image o.2.fts" (or any other number > 2-8), it displays the file but immediately starts to switch between the > given number and #1. Somehow the event gets autogenerated I added a > debug printout to "cb_select_mosaic" procedure and it shows: > > cb_select_mosaic 0 > cb_select_mosaic 4 > cb_select_mosaic 0 > cb_select_mosaic 4 Now the above is fixed, I guess since "pre6" or so. I am getting, however, similar behavior when I use another feature of my display app: When it is invoked with more-than-one filename argument, clicking the right button on the "FILE" button should display the image taken from the next command invocation argument (without having to go through file selector form, bound to left-click on the FLE button). It works *mostly* fine, unless I click that button many times without waiting for the images to be fully loaded. Then, after a few "proper" displays, the app starts to auto-change between some (randomly chosen, but always already read) images. This seems to be an infinite loop although it still reacts (with some delay) to EXIT button, so the app does not completely go astray, it just starts to get auto-generated events. As always, this could be a bug in my app, in old days, however (I still have those older version, compiled with "official" XForms releases), it worked fine, no matter how quickly I repeated the mouse clicks. Another problem which still annoys me a bit is (another self-quote): > The same image display app > has a few keyboard shortcuts working while inside the image canvas which > open a new window (form) and display some data in it. I have noticed a > strange behavior - when the new window is created, it displays its data > OK. Then I move the mouse (still in the image canvas) and press > the same key again - > it should display the data for the new image position, but it does > not. Only when I click a mouse button or leave and enter again the image > canvas, the key starts to work. And it works fine (displaying proper > data for every mouse position in the canvas) until I close the window. > When I open it again, the same situation repeats ("dead" after first > opening, then clicking or leaving/entering the canvas, then working > fine). This problem occurred even in the "official" releases of > xforms in some hard-to-pinpoint combinations of Linux system version, > X11 version and architecture. Now, with most machines on which it is > used got upgraded to more up-to-date systems (e.g. CentOS 5.1), the > problem seems to be persistent. It is probably not connected to 1.0.91 > but still, may mark a problem in the library. regards, Michal. PS. Thanks again, Jens, for your efforts in reviving and improving the XForms. -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Sat Jul 12 17:20:03 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Sat, 12 Jul 2008 17:20:03 -0400 Subject: [XForms] New pre-release 1.0.91pre12 In-Reply-To: <20080712210708.GB8226@toerring.de> References: <20080712210708.GB8226@toerring.de> Message-ID: To subscribers of the xforms list On Sat, Jul 12, 2008 at 5:07 PM, Jens Thoms Toerring wrote: > h) Rob Carpenter also reported ome problems when using more than a > single GL canvas in a form. Unfortunately I wasn't yet able to > determine if this is XForms or GL related - I simply don't know > anything about GL and it also doesn't seem to work too well on > my test machine. So if somebody has suggestions please send them! What kind of problems? There should be no issues with this -- I have yet to see any major problems with XForms glcanvas implementation (aside from it recreating contexts a bit too often). Speaking of OpenGl, I do have that old OpenGL context sharing patch from a few years ago (maybe late 2003 or early 2004, around the time Fedora Core 1 was released), that we have used without a hitch in every single xforms application we've written since then (and I can assure you, there have been many). It appears to be working very well with no issues. If you want, I can prepare a patch for you and send it. It's a pretty handy feature. Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Jul 12 17:07:08 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 12 Jul 2008 23:07:08 +0200 Subject: [XForms] New pre-release 1.0.91pre12 Message-ID: <20080712210708.GB8226@toerring.de> To subscribers of the xforms list Hello, after quite a bit of feedback - thank you to all involved! - here's another pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre12.tar.gz.sig What's new? a) Update to newer version of libtool since, as Raphael Straub, the maintainer of the MacPorts port of XForms, pointed out, fdesign didn't compile on Mac OS X anymore. b) A bug that under some conditions led to a segmentation fault when freeing forms was found by Luis Balona. c) Rob Carpenter pointed me to a bug in the calculation of the boun- ding box of objects could result in redraws becoming extremely slow. d) Some changes in the code for dealing with popups etc. for getting rid of some drawing artefacts that Luis Balona told me about. Un- fortunately, I am not sure if it works now since I can't reproduce the problem on my test machine... e) Jean-Marc Lasgouttes called to my attention a problem when running configure that made it necessary to add config/mkinstalldirs to the distributed files. f) As Luis Balona noticed selected radio buttons did not receive a callback call when they got clicked on which might break existing programs, so it was reintroduced. g) Jason Cipriani found that there were some inconsitencies and problems when trying to delete menu entries and made some very helpful suggestions how to resolve it. This required a number of changes to the public API (some of the functions now accept an unspecified number of extra arguments, i.e. they are now variadic functions, in addition to the traditional arguments). Hopefully this will not break any existing programs. In programs (and fdesign) now callback functions for individual menu entries can be set and each menu entry can be given a certain value (instead of just using it's index). For a full explanation plese see the fike "New_Features,txt" in the main directory. h) Rob Carpenter also reported ome problems when using more than a single GL canvas in a form. Unfortunately I wasn't yet able to determine if this is XForms or GL related - I simply don't know anything about GL and it also doesn't seem to work too well on my test machine. So if somebody has suggestions please send them! Again thanks to everybody who send bug or suggestions. Please don't hestitate to tell me about anything that still doesn't work! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Fri Jul 4 17:46:47 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Fri, 4 Jul 2008 17:46:47 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: To subscribers of the xforms list On Fri, Jul 4, 2008 at 4:37 PM, Jason Cipriani wrote: > On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: >> To get around that you have to change the file lib/menu.c. >> I append a version for 1.0.90 that hopefully works but I >> didn't test the changes with that version, just my newer >> one. Then add to lib/private/menu.h > > Since this change, the functions fl_set_menu_item_mode and > fl_get_menu_item_mode no longer work unless the menu item's index is > the same as it's value. It doesn't matter if you specify an index or a > value to these functions -- if the two are different, they are > ignored. I suspect that something internally is inappropriately mixing > item indices and values, and had always relied on them being the same. I've found the problem, and a partial solution to it (see below, I've also provided a possible full solution), although I'm not sure if the solution breaks anything. SOLUTION #1: In the new %x handling code in addto_menu, around line 357 there is this bit of code that removes the %x from the string after processing it: else { sp->mval[ n ] = strtol( p + 2, &eptr, 10 ); while ( *eptr && isspace( ( int ) *eptr ) ) eptr++; if ( *eptr ) memmove( p, eptr, strlen( eptr ) + 1 ); else *p = '\0'; } The fix is to not remove the "%x" from the string, changing it to just this: else { sp->mval[ n ] = strtol( p + 2, &eptr, 10 ); } The reason this problem was occurring is because every time you display a menu, it uses the setpup stuff to create a popup menu to display. This popup menu is set up in do_menu around line 111 of menu.c. All of the popup menu functions take item IDs, not indices. When you use %x to modify the menu's ID, this causes sp->mval[n] to hold the ID, and so all of the MENU functions know about the ID. However, since the %x is removed from the string, when the popup is created that corresponds to the menu, the item IDs are not propagated to the popup menu -- therefore the MENU functions know about the item ID but the POPUP functions do not. Leaving the "%x" in the string allows the ID to be passed through fl_addtopup() and then the correct IDs are set in the popup menu, and everything seems to work. SOLUTION #2: The reason the above fix isn't complete is that it only applies when you've used %x to set the IDs. The problem solved by the above solution is related to the new feature of parsing %x in menu strings but is not related to removing menu items. However, removing menu items does cause a problem if you haven't used %x at all that the above solution doesn't fix. If that makes sense. Anyways if you do not use %x then the menu item IDs are, initially, the item indices. If you remove a menu item, then indices change but the IDs do not. However, the IDs in this case are never passed to fl_addtopup at all, and so the POPUP menu uses the item INDICES instead -- which no longer correspond to the IDs since an item was removed. This is related to the problem when using %x in that it's also caused by inconsistency between the item IDs in menu.c and the item IDs in xpopup.c. The root cause of all of these problems is that do_menu does not set the popup menu item IDs to the sp->mval[i] values. All menu ID information is lost in the popup. AFAICT, there is no API call to change popup menu item IDs, and therefore there is no easy way for do_menu() to pass ID information to the popup menu when it sets up the menu with fl_addtopup(). One solution for this is to continue removing the %x strings in addto_menu, just as you are doing now, but when creating the popup menu, create temporary strings with a %x concatenated onto the end of them along with the corresponding ID. Something like this in do_menu around line 111: + char tempstr[512]; + snprintf(tempstr, sizeof(tempstr), "%s%%x%i", sp->items[i], sp->mval[i]); + fl_addtopup(sp->menu, tempstr); - fl_addtopup(sp->menu, sp->items[i]); This works fine but it does change the behavior of some other stuff. Specifically, it causes fl_get_menu to return the item ID and NOT the item index as previous. Meaning that you can just do this: int value = fl_get_menu(menu); Rather than having to do this: int value = fl_get_menu_value(menu, fl_get_menu(menu)); Although that now also means that if you're passing the result of fl_get_menu() to other menu functions, you'll need to convert the value to an index first: int index = fl_get_menu_item_from_value(menu, fl_get_menu(menu)); fl_delete_menu_item(menu, index); /* for example */ It's important to note, though, that the above changes in behavior would ONLY happen if the IDs and values are not the same, which can ONLY happen if you've either used %x to change the IDs, or you've removed a menu item. Therefore I believe using the above solution (constructing a temporary string with a %x on the end) will not significantly affect any existing applications because: 1) We know nobody has been removing menu items, since fl_delete_menu_item didn't work at all. 2) We know nobody has been using %x to set the IDs in regular menus, since it was never supported. 3) The only people who may experience changes in behavior are people that had a previously meaningless "%x" in their menu item text, and now it means something. However, your addto_menu change already affected these people, the tempstr thing above doesn't add any new issues. What do you think about solution #2? Do you see any way it could interact with regular popup menus at all? What about fdesign? Things like that? Incidentally, I've also noticed that, every once in a while, fdesign strips the %x from the end of my menu strings. I am not sure why, or what triggers it. It's happened to me twice out of about 15 saves so far, though. Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Fri Jul 4 16:46:45 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Fri, 4 Jul 2008 16:46:45 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: To subscribers of the xforms list On Fri, Jul 4, 2008 at 4:37 PM, Jason Cipriani wrote: > On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: >> To get around that you have to change the file lib/menu.c. >> I append a version for 1.0.90 that hopefully works but I >> didn't test the changes with that version, just my newer >> one. Then add to lib/private/menu.h > > I've done some more testing with this and uncovered a problem that I > am about to dig in to a little more. Unrelated to this issue, I think, in menu.c in the function fl_set_menu_item_mode (around line 505 for me), there is a bit of code that reads: if ((mode & FL_PUP_CHECK)) sp->val = numb; Should that be this instead? if ((mode & FL_PUP_CHECK)) sp->val = sp->mval[numb]; Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Fri Jul 4 16:37:54 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Fri, 4 Jul 2008 16:37:54 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080704105748.GA26035@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: To subscribers of the xforms list -------------- next part -------------- On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: > To get around that you have to change the file lib/menu.c. > I append a version for 1.0.90 that hopefully works but I > didn't test the changes with that version, just my newer > one. Then add to lib/private/menu.h I've done some more testing with this and uncovered a problem that I am about to dig in to a little more. Since this change, the functions fl_set_menu_item_mode and fl_get_menu_item_mode no longer work unless the menu item's index is the same as it's value. It doesn't matter if you specify an index or a value to these functions -- if the two are different, they are ignored. I suspect that something internally is inappropriately mixing item indices and values, and had always relied on them being the same. I've attached another test program that demonstrates this. The menu (click on the word menu) items values are 5, 2, and 9 respectively. Click the checkboxes then click on the menu. The checkboxes to disable menu items only work for "green", where both the index and the value are 2. Maybe you have some insight, I'm also going to look through the code right now. Thanks, Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: deleteitem3.tar.gz Type: application/x-gzip Size: 1533 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20080704/66471058/attachment-0005.gz -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Jul 5 08:04:46 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 5 Jul 2008 14:04:46 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080704175052.GA20513@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> <20080704175052.GA20513@toerring.de> Message-ID: <20080705120446.GB6123@toerring.de> To subscribers of the xforms list Hi Jason, On Fri, Jul 04, 2008 at 05:46:47PM -0400, Jason Cipriani wrote: > On Fri, Jul 4, 2008 at 4:37 PM, Jason Cipriani wrote: > > On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: > >> To get around that you have to change the file lib/menu.c. > >> I append a version for 1.0.90 that hopefully works but I > >> didn't test the changes with that version, just my newer > >> one. Then add to lib/private/menu.h > > > > Since this change, the functions fl_set_menu_item_mode and > > fl_get_menu_item_mode no longer work unless the menu item's index is > > the same as it's value. It doesn't matter if you specify an index or a > > value to these functions -- if the two are different, they are > > ignored. I suspect that something internally is inappropriately mixing > > item indices and values, and had always relied on them being the same. > > I've found the problem, and a partial solution to it (see below, I've > also provided a possible full solution), although I'm not sure if the > solution breaks anything. > > SOLUTION #1: > > In the new %x handling code in addto_menu, around line 357 there is > this bit of code that removes the %x from the string after processing > it: > > else > { > sp->mval[ n ] = strtol( p + 2, &eptr, 10 ); > while ( *eptr && isspace( ( int ) *eptr ) ) > eptr++; > if ( *eptr ) > memmove( p, eptr, strlen( eptr ) + 1 ); > else > *p = '\0'; > } > > The fix is to not remove the "%x" from the string, changing it to just this: > > else > { > sp->mval[ n ] = strtol( p + 2, &eptr, 10 ); > } > > The reason this problem was occurring is because every time you > display a menu, it uses the setpup stuff to create a popup menu to > display. This popup menu is set up in do_menu around line 111 of > menu.c. All of the popup menu functions take item IDs, not indices. > When you use %x to modify the menu's ID, this causes sp->mval[n] to > hold the ID, and so all of the MENU functions know about the ID. > However, since the %x is removed from the string, when the popup is > created that corresponds to the menu, the item IDs are not propagated > to the popup menu -- therefore the MENU functions know about the item > ID but the POPUP functions do not. Leaving the "%x" in the string > allows the ID to be passed through fl_addtopup() and then the correct > IDs are set in the popup menu, and everything seems to work. > > SOLUTION #2: > > The reason the above fix isn't complete is that it only applies when > you've used %x to set the IDs. The problem solved by the above > solution is related to the new feature of parsing %x in menu strings > but is not related to removing menu items. However, removing menu > items does cause a problem if you haven't used %x at all that the > above solution doesn't fix. If that makes sense. > > Anyways if you do not use %x then the menu item IDs are, initially, > the item indices. If you remove a menu item, then indices change but > the IDs do not. However, the IDs in this case are never passed to > fl_addtopup at all, and so the POPUP menu uses the item INDICES > instead -- which no longer correspond to the IDs since an item was > removed. This is related to the problem when using %x in that it's > also caused by inconsistency between the item IDs in menu.c and the > item IDs in xpopup.c. > > The root cause of all of these problems is that do_menu does not set > the popup menu item IDs to the sp->mval[i] values. All menu ID > information is lost in the popup. AFAICT, there is no API call to > change popup menu item IDs, and therefore there is no easy way for > do_menu() to pass ID information to the popup menu when it sets up the > menu with fl_addtopup(). > > One solution for this is to continue removing the %x strings in > addto_menu, just as you are doing now, but when creating the popup > menu, create temporary strings with a %x concatenated onto the end of > them along with the corresponding ID. Something like this in do_menu > around line 111: > > + char tempstr[512]; > + snprintf(tempstr, sizeof(tempstr), "%s%%x%i", sp->items[i], sp->mval[i]); > + fl_addtopup(sp->menu, tempstr); > - fl_addtopup(sp->menu, sp->items[i]); > > This works fine but it does change the behavior of some other stuff. > Specifically, it causes fl_get_menu to return the item ID and NOT the > item index as previous. Meaning that you can just do this: > > int value = fl_get_menu(menu); > > Rather than having to do this: > > int value = fl_get_menu_value(menu, fl_get_menu(menu)); > > Although that now also means that if you're passing the result of > fl_get_menu() to other menu functions, you'll need to convert the > value to an index first: > > int index = fl_get_menu_item_from_value(menu, fl_get_menu(menu)); > fl_delete_menu_item(menu, index); /* for example */ > > It's important to note, though, that the above changes in behavior > would ONLY happen if the IDs and values are not the same, which can > ONLY happen if you've either used %x to change the IDs, or you've > removed a menu item. Therefore I believe using the above solution > (constructing a temporary string with a %x on the end) will not > significantly affect any existing applications because: > > 1) We know nobody has been removing menu items, since > fl_delete_menu_item didn't work at all. It did work, but only for menus created with fl_addto_menu(), not for thise created with fl_set_menu_entries(). > 2) We know nobody has been using %x to set the IDs in regular menus, > since it was never supported. It's even documented as not to work. > 3) The only people who may experience changes in behavior are people > that had a previously meaningless "%x" in their menu item text, and > now it means something. However, your addto_menu change already > affected these people, the tempstr thing above doesn't add any new > issues. > > What do you think about solution #2? Do you see any way it could > interact with regular popup menus at all? What about fdesign? Things > like that? I think all your ideas are very reasonable and #2 is the way I will implement it in the new version. Thanks for doing my work;-) That means: a) A menu ID can be associated with a certain menu item using "%xn" in the string for the text of the menu item. Note that 'n' must be a number larger than 0. b) If no menu ID is assigned explicitely it gets its ID from a counter that is incremented for each menu item added (start- ing from 1). This number is never re-used, even when menu items get deleted. The only exception is that on a call of fl_clear_menu() also the counter gets reset to 1. c) fl_get_menu() now returns the menu ID d) To all functions expecting an item number the ID must now be passed. e) If two menu items receive the same ID the results are un- specified, so the user must make sure that this never happens. f) If a menu item gets delete via fl_delete_menu_item() all other items keep their numbers, even if no menu IDs have been set for them. That is how things work for normal popups and it probably wouldn't be a good idea to do it differently for menus. The only deviations are for the case that menu items get deleted, which can't be done for popups. That also means that both the functions fl_get_menu_value() and fl_get_menu_item_from_value() can disappear again (or the latter go back to being a local only function). Does anybody see any problems with this approach? What I will also try to implement is having a callback function for each menu item. For menus created with the fl_set_menu_entries() function you can already do that, so it looks reasonable to me also to have that ability for all menus. I think I will allow a "%f" in the menu string and change the functions fl_set_menu(), fl_adddto_menu() and fl_replace_menu_item() to be variadic functions (that should introduce compatibilty problems) so that pointers to functions of type FL_PUP_CB can be passed on. Finally, I will have another look if it's possible to get rid of the asymmetry between menus created with calls of fl_addto_menu() and those created by a single call of fl_set_menu_entries(). Having them behave differently in several respects doesn't look too good to me (and the differences at least need to be documen- ted). Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Fri Jul 4 13:50:52 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 4 Jul 2008 19:50:52 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: <20080704175052.GA20513@toerring.de> To subscribers of the xforms list Hi Jason, > One problem that I found is fl_delete_menu_item refers to the item > index, not the value. This can make deleting items pretty tricky. To > that end I've added a function to go the other way, from value to > item. It works for me although I may have missed some things I don't think so. Your's is basically a new version of the already existing (but only local to menu.c) val_to_index() function;-) > (specifically, I'm not sure if the ISPUP thing is right -- and also, If the menu gets created with the fl_set_menu_entries() function instead of as many calls of fl_addto_menu() as there are items the menu is just a normal popup (from which no items can be removed and where no values can be assigned differing from the index etc.) and in this case ISPUP() returns true. So your use is exactly right. > is the item index really 1-based?), Yes. Probably the original author got bored with hunting for bugs due to a mising subtraction of 1 or the corres- ponding addition in the right places. My preference would be anyway to use always 0 based arrays, also in the puplic interface, but I guess it's much too late for doing any- thing about that now... > I tried to make it the inverse of > fl_get_menu_value. Note that if multiple items have the same value, > this returns the first item with that value. Returns -1 if value is > not found. Yes, that's the problem with the values - they get set by the user, so it can't be made sure that they are unique. > === menu.c === > > int > fl_get_menu_item_from_value( FL_OBJECT * ob, > int value ) I will add the function to the new release. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Fri Jul 4 13:25:31 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Fri, 4 Jul 2008 13:25:31 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080704105748.GA26035@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: To subscribers of the xforms list On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: > To get around that you have to change the file lib/menu.c. > I append a version for 1.0.90 that hopefully works but I > didn't test the changes with that version, just my newer > one. Then add to lib/private/menu.h Thanks a lot for digging into this. I've tested your changes and so far everything seems to be working well, I can remove items and use fl_get_menu_value to get the correct ID. > This should give you a new function named fl_get_menu_value() > that expects the menu object and the item index as returned > by fl_get_menu(). If you now create the menu items in fdesign > with texts like One problem that I found is fl_delete_menu_item refers to the item index, not the value. This can make deleting items pretty tricky. To that end I've added a function to go the other way, from value to item. It works for me although I may have missed some things (specifically, I'm not sure if the ISPUP thing is right -- and also, is the item index really 1-based?), I tried to make it the inverse of fl_get_menu_value. Note that if multiple items have the same value, this returns the first item with that value. Returns -1 if value is not found. === menu.c === int fl_get_menu_item_from_value( FL_OBJECT * ob, int value ) { FL_MENU_SPEC *sp = ob->spec; int item; if( ISPUP( sp ) ) return value; for( item = 1; item <= sp->numitems; ++ item ) if (sp->mval[item] == value) return item; return -1; } === menu.h === FL_EXPORT int fl_get_menu_item_from_value( FL_OBJECT * ob, int value ); Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Fri Jul 4 06:57:48 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 4 Jul 2008 12:57:48 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> Message-ID: <20080704105748.GA26035@toerring.de> To subscribers of the xforms list -------------- next part -------------- Hi Jason, On Thu, Jul 03, 2008 at 07:21:01PM -0400, Jason Cipriani wrote: > On Thu, Jul 3, 2008 at 7:05 PM, Jens Thoms Toerring wrote: > > It looks as if the stuff for removing a menu item is badly > > broken already in 1.0.0. I guess nobody ever has tried to use > > it, so it went unnoticed for all those years. I will try to > > come up with a fix that also works for 1.0.90 or 1.0.0 (tell > > me what you are using) but since it's getting a bit late here > > 1.0.90, with some unrelated custom patches to opengl stuff. Here's some good and some bad news: If you want to create a menu with fdesign were you can delete items then you must switch off the "Use Struct" button in the "Spec" tab field for the menus attributes. In that case the menu gets initia- lized via several calls of the function fl_addto_menu() in- stead of a single call of fl_set_menu_entries(). That looks like a minor detail, but internally a rather different type of menu gets created which allows deletion of items. Now the bad news: Deleting an item will change the numbers returned for the items following it, i.e. the number of the selected item is always the (1 based) index of the item in the menu. So you will have to work with comparing the text of the item that you can get with fl_get_menu_item_text(). To get around that you have to change the file lib/menu.c. I append a version for 1.0.90 that hopefully works but I didn't test the changes with that version, just my newer one. Then add to lib/private/menu.h FL_EXPORT int fl_get_menu_value( FL_OBJECT * ob, int item ); and recompile. This should give you a new function named fl_get_menu_value() that expects the menu object and the item index as returned by fl_get_menu(). If you now create the menu items in fdesign with texts like red%x1 green%x2 blue%x3 (the "%xn" stuff will not be shown in the menu with the new version of menu.c) then the new function will return the number following the "%x" and this number does not change after deleting an item. Sorry for all this complexities but the whole stuff for hand- ling menus/popups/choices is rather convoluted and IMHO not very well designed. I guess a complete rewrite (but which then will probably also require changes of the public API) would be the best solution... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de -------------- next part -------------- A non-text attachment was scrubbed... Name: menu.c Type: text/x-csrc Size: 14618 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20080704/bc78de63/attachment-0005.bin -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 19:21:01 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 19:21:01 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080703230528.GA27176@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> Message-ID: To subscribers of the xforms list On Thu, Jul 3, 2008 at 7:05 PM, Jens Thoms Toerring wrote: > It looks as if the stuff for removing a menu item is badly > broken already in 1.0.0. I guess nobody ever has tried to use > it, so it went unnoticed for all those years. I will try to > come up with a fix that also works for 1.0.90 or 1.0.0 (tell > me what you are using) but since it's getting a bit late here 1.0.90, with some unrelated custom patches to opengl stuff. > where I'm living I guess I better get a bit of sleep before I > make a complete mess out of it. I hope you will get something > tomorrow morning (when it is morning in yor time zone that is;-) > but I don't know at the moment how complicated it's going to > be, so please don't hold your breath until then;-) It's no big deal. And, in general, I'm in a perpetual state of breath-holding anyways. If I uncover anything interesting I'll let you know. Thanks, Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Jul 3 19:05:28 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 4 Jul 2008 01:05:28 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> Message-ID: <20080703230528.GA27176@toerring.de> To subscribers of the xforms list Hi Jason, On Thu, Jul 03, 2008 at 06:35:53PM -0400, Jason Cipriani wrote: > Attached is a test program I've created. Thanks, that confirms my own observations... > The form has a single menu with 3 items, 3 buttons to remove each > item, and a button to clear the entire menu (as a sanity check). > > Clearing the menu works properly. Attempting to remove items does not > work at all. > > There's not a way to hide/show individual items, is there? I couldn't > find anything looking through the documentation. If there is, that > would work as a workaround for now. It looks as if the stuff for removing a menu item is badly broken already in 1.0.0. I guess nobody ever has tried to use it, so it went unnoticed for all those years. I will try to come up with a fix that also works for 1.0.90 or 1.0.0 (tell me what you are using) but since it's getting a bit late here where I'm living I guess I better get a bit of sleep before I make a complete mess out of it. I hope you will get something tomorrow morning (when it is morning in yor time zone that is;-) but I don't know at the moment how complicated it's going to be, so please don't hold your breath until then;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 18:35:53 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 18:35:53 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080703221048.GA23177@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> Message-ID: To subscribers of the xforms list -------------- next part -------------- On Thu, Jul 3, 2008 at 6:10 PM, Jens Thoms Toerring wrote: > I am also just looking into this and trying to come up with > an expample program. If you have one at hand just send it to > me - I wouldn't be too surprised if there still are some bugs > lurking;-) Attached is a test program I've created. The form has a single menu with 3 items, 3 buttons to remove each item, and a button to clear the entire menu (as a sanity check). Clearing the menu works properly. Attempting to remove items does not work at all. There's not a way to hide/show individual items, is there? I couldn't find anything looking through the documentation. If there is, that would work as a workaround for now. Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: deleteitem.tar.gz Type: application/x-gzip Size: 1250 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20080703/62690ac5/attachment-0005.gz -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Jul 3 18:10:49 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 4 Jul 2008 00:10:49 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> Message-ID: <20080703221048.GA23177@toerring.de> To subscribers of the xforms list Hi Jason, On Thu, Jul 03, 2008 at 06:01:28PM -0400, Jason Cipriani wrote: > Oh, right. Now that I think about it, not only do I remember reading > that, but I am actually using %x for other menu items elsewhere in > this very same application. I've been staring at the screen too long. > :-S I'm still having trouble getting fl_delete_menu_item to work at > all but I suspect it's something silly as well. I am also just looking into this and trying to come up with an expample program. If you have one at hand just send it to me - I wouldn't be too surprised if there still are some bugs lurking;-) best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 18:01:28 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 18:01:28 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080703214526.GC21371@toerring.de> References: <20080703214526.GC21371@toerring.de> Message-ID: To subscribers of the xforms list On Thu, Jul 3, 2008 at 5:45 PM, Jens Thoms Toerring wrote: > The value that is returned is actually not necessary identical > to the index of the entry, the structure for an entry has a > member for storing the value to be returned. The index of the > item is just the defalt value set at creation. But you can over- > ride this value at creation of the menu, see "%xn" at the end of > page 201 of the PostScript documentation for 0.89, all that's > required is that it's positive (but I don't know off-hand if 0 > is regarded as positive). Oh, right. Now that I think about it, not only do I remember reading that, but I am actually using %x for other menu items elsewhere in this very same application. I've been staring at the screen too long. :-S I'm still having trouble getting fl_delete_menu_item to work at all but I suspect it's something silly as well. Thanks for looking into it, and the quick reply, Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Jul 3 17:45:26 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 3 Jul 2008 23:45:26 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: Message-ID: <20080703214526.GC21371@toerring.de> To subscribers of the xforms list Hi Jason, On Thu, Jul 03, 2008 at 04:53:23PM -0400, Jason Cipriani wrote: > Let's say I have a menu with these items, created in fdesign: > > 1. Red > 2. Green > 3. Blue > > So the IDs (returned by fl_get_menu) are 1, 2, and 3. > > If I use fl_delete_menu_item() to remove the second item (id = 2), > then I've observed that the IDs of the other menu items do NOT change, > leaving the menu like this: > > 1. Red > 3. Blue > > This is convenient and is what I want to happen, I was pleasantly > surprised when I noticed it. However, I was always under the (possibly > incorrect) impression that menu item IDs *always* corresponded to the > index of the item (so Blue would have been changed to 2 rather than > remaining as 3). > > Is this ("Blue" keeping it's ID of 3) a bug that coincidently worked > out well for me? Or is this intentional behavior that I can rely on in > the future? No, I don't think it's a convenient bug but intended that way. The value that is returned is actually not necessary identical to the index of the entry, the structure for an entry has a member for storing the value to be returned. The index of the item is just the defalt value set at creation. But you can over- ride this value at creation of the menu, see "%xn" at the end of page 201 of the PostScript documentation for 0.89, all that's required is that it's positive (but I don't know off-hand if 0 is regarded as positive). So I guess you can rely on the beha- viour and should cry "BUG" if you find it behaves differently;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 17:25:44 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 17:25:44 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: Message-ID: To subscribers of the xforms list On Thu, Jul 3, 2008 at 4:53 PM, Jason Cipriani wrote: > If I use fl_delete_menu_item() to remove the second item (id = 2), > then I've observed that the IDs of the other menu items do NOT change, > leaving the menu like this: I take this back, I seem to have grossly misinterpreted what I was seeing. In fact, fl_delete_menu_item() appears to do nothing at all. If I create a menu with 5 items in fdesign, say it's named "TheMenu", and then attempt to delete one of the items: fl_delete_menu_item(TheForm->TheMenu, 2); It seems that nothing happens at all. No items are deleted. The menu remains unmodified. Is there some other function I need to call to "apply" whatever changes fl_delete_menu_item makes? Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 16:53:23 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 16:53:23 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). Message-ID: To subscribers of the xforms list Let's say I have a menu with these items, created in fdesign: 1. Red 2. Green 3. Blue So the IDs (returned by fl_get_menu) are 1, 2, and 3. If I use fl_delete_menu_item() to remove the second item (id = 2), then I've observed that the IDs of the other menu items do NOT change, leaving the menu like this: 1. Red 3. Blue This is convenient and is what I want to happen, I was pleasantly surprised when I noticed it. However, I was always under the (possibly incorrect) impression that menu item IDs *always* corresponded to the index of the item (so Blue would have been changed to 2 rather than remaining as 3). Is this ("Blue" keeping it's ID of 3) a bug that coincidently worked out well for me? Or is this intentional behavior that I can rely on in the future? Thanks, Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 16:41:17 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 16:41:17 -0400 Subject: [XForms] Hiding menu items. Message-ID: To subscribers of the xforms list Quick question: How do I hide/show an item in a PULLDOWN_MENU? Thanks, Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Jun 23 20:44:31 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 24 Jun 2008 02:44:31 +0200 Subject: [geomview-users] XForms - new release pending Message-ID: <20080624004431.GA23017@toerring.de> Hello, I have seen that at least some of the plugins for Geomview are using XForms. I have become one of the maintainers of XForms and in the last months have made a number of changes to it, mostly trying to remove bugs and making it more stable. Now I am considering to release a new version and I am trying to get as much feedback as possible about outstanding pro- blems as well as about the ones I may have introduced in the process of working on XForms. I would be really grateful if those of you that wrote or maintain plugins based on XForms would be prepared to test it against the newest pre-release of the library http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre11.tar.gz and tell me about everything you deem to be not working cor- rectly. Please note that there were also some changes to the default graphics settings (like border widths etc.) that were made to make XForms look a bit more "modern" but that may in- fluence the look of the plugins if you are using these default settings. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ geomview-users mailing list geomview-users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geomview-users From jt at toerring.de Mon Jun 23 18:01:12 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 24 Jun 2008 00:01:12 +0200 Subject: [XForms] New pre-release 1.0.91pre11 In-Reply-To: <20080623212413.GA16829@toerring.de> References: <20080623212413.GA16829@toerring.de> Message-ID: <20080623220112.GA22140@toerring.de> To subscribers of the xforms list Hi, On Mon, Jun 23, 2008 at 11:24:13PM +0200, Jens Thoms Toerring wrote: > a) Thanks to Werner Heise sending me lots of test programs I Sorry, that should have been Werner Heisch, not Heise. I hope he isn't too annoyed, at least I got his name mixed up with that of the publisher of what are probably the best computer magazines in Germany... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Jun 23 17:24:13 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 23 Jun 2008 23:24:13 +0200 Subject: [XForms] New pre-release 1.0.91pre11 Message-ID: <20080623212413.GA16829@toerring.de> To subscribers of the xforms list Hello, there's a further pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre11.tar.gz As usual here's a list of changes: a) Thanks to Werner Heise sending me lots of test programs I was able to track down a bug in the drawing of pixmaps - clippng wasn't set corectly, so under some circumstances pixmaps would be drawn over objects that were on top of the pixmap. b) The same problem existed also for bitmaps. c) Bitmap buttons now also behave like normal buttons, just with a bitmap drawn of top of it. The foreground color of the bitmap is the same as the label color (and never changes). At the moment I have no outstanding bug reports left and am seriously considering making this pre-release the "official" new 1.0.91 release. Therefore I would like to ask everyone with a bit of time to spend to download the pre-release and test it. I'd rather like to have a release that hasn't some ugly bugs left that should have been found before! It's that long since the last oficial release that some days spent fi- xing still existing bugs won't make much of a difference;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Jun 17 09:39:35 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 17 Jun 2008 15:39:35 +0200 Subject: [XForms] New pre-release 1.0.91pre10 Message-ID: <20080617133935.GA22614@toerring.de> To subscribers of the xforms list Hello, it was rather a long time since the last pre-release, but now there's a new one: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre10.tar.gz Again, due to my somewhat restricted time at the moment not too many changes have been made: a) The whole way pixmap buttons got drawn was a bit of a mess. I think that they should just behave like any other "normal" button with the only difference that a pixmap gets drawn on top of it (which may get exchanged when the button gets or loses the focus, i.e. the mouse gets moved on top of it or off the button). That's the way its supposed to work now - the drawing routine for normal button is also used for drawing pixmap buttons and when it's done the pixmap gets drawn on top of it. b) Another small cleanup of the code for redarwing objects that are in parts obscured by another object has been made. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat May 31 16:07:03 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 31 May 2008 22:07:03 +0200 Subject: [XForms] New pre-release 1.0.91pre9 In-Reply-To: <20080524145233.GA27966@toerring.de> References: <20080524145233.GA27966@toerring.de> Message-ID: <20080531200702.GA4837@toerring.de> To subscribers of the xforms list Hello, there's a new pre-release is available for testing: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre9.tar.gz Not too much has changed compared to the last one: a) Werner Heisch did observe that partially transparent pixmaps weren't displayed correctly anymore in 1.0.91pre8. He also pointed out that the behaviour of pixmap buttons wasn't what was described in the documentation (already in 1.0.90). If there was a focus pixmap (to be shown instead of the original pixmap while the mouse was on top of the button) it was also shown (and did stay shown) when the button was pressed. b) In the code I introduced to make sure "lower" objects don't get drawn above "higher" objects there was a bug in the de- tection if two objects overlap. That led to a lot of useless redraws of other objects when an object got redrawn. That's it for today. Please tell me when you find more bugs! Otherwise I guess there won't be another pre-release next but a real new release;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat May 24 10:52:33 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 24 May 2008 16:52:33 +0200 Subject: [XForms] New pre-release 1.0.91pre8 Message-ID: <20080524145233.GA27966@toerring.de> To subscribers of the xforms list Hello, here we go again with another pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre8.tar.gz What's new? a) Menus and choice object now use normal fonts instead of bold or even bold and italic fonts - they looked much too fat with the reduced border widths. I also made the default background color a tiny bit lighter. b) Alert and message goodies: removed upper limits on the strings that can be passed to them. There's also a new function, called void fl_show_alert2( int c, const char * fmt, ... ) that takes an int (indicating if the alert box is centered on the screen) and a printf()-like format string, followed by as many more aguments as there are format specifiers in the format string. c) Another new function is int fl_get_decoration_sizes( FL_FORM * form, int * top, int * right, int * bottom, int * left ); that you can call with a form and which then returns the widths of the decorations the window manager put around the form window in the four other variables. It returns 0 on success and 1 if it failed. It can fail e.g. because the form is currently not shown on the screen or because it's a form embedded in another form, e.g. as part of a tabfolder. d) When there were overlapping objects and the "lower" object was redrawn the "upper" object did appear to be under the "lower" object. This bug, pointed out by Werner Heisch, has hopefully been removed. e) It could happen that parts of a pixmap got drawn outside of the object it belonged to either because it was larger that the objects bounding box or because its alignment was set to outside. This part of the pixmap then didn't get hidden when the object was hidden. This has now been changed so that only the part that fits into the objects bounding box will get drawn and, when setting the pixmap's alignment an FL_ALIGN_INSIDE is implied. This deviates a bit from the manal where you can read: "Note that although you can place a pixmap outside of the bounding box, it probably is "not a good idea". So the "not so good idea" is now forbidden. In older versions also the additional margins around a pixmap (per default 3 pixels) weren't always correctly drawn if the pixmap wasn't smaller than the objects bounding box. f) Further bugs taken care of: hiding canvases and re-showing tabfolders didn't work correctly (as Rob Carpenter pointed out this led to parts of fdesign not working correctly any- more). Memory access to already deallocated memory in code for handling child objects removed. A few redrawing problems concerning boxes, pointed out by Andrea Scopece, were cleaned up. g) Added a file named 'New_Features.txt' in the main directory with more complete documentation of new functions and other changes. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon May 5 19:54:45 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 6 May 2008 01:54:45 +0200 Subject: [XForms] New pre-release 1.0.91pre7 In-Reply-To: <200805052243.24066.andrea.scopece@tiscali.it> References: <20080505144936.GA23102@toerring.de> <200805052243.24066.andrea.scopece@tiscali.it> Message-ID: <20080505235444.GB5415@toerring.de> To subscribers of the xforms list Hello, On Mon, May 05, 2008 at 10:43:23PM +0200, Andrea Scopece wrote: > My feel is that the library cointain a bit of support for > platform that really are not used anymore. > To cleanup the things there is the need at least to know > what are the platform currently used... > Programmer and Users please: report back some info to list! Yes, that is an issue that needs taken care of in several respects. E.g. on the Savannah project page it's claimed that It should work under X11 R4, R5 & R6. Now I don't know who still got a R4 or R5 release of X11. I definitely don't (and that for years), so I can't test how far this claim is for real. Concerning support for different operating systems at least there don't seem to be those kinds of claims. I guess that OS2 and Windows NT are not really supported anymore. But I have no idea if WIN32 (whatever exactly this is meant to be) works at all - I don't use Windows, so I can't check. And concerning rather old versions of different UNIX flavors there's a similar situation. VMS is another candidate... > > There are quite a number of corner cases, i.e. functions that > > are in but that have never been documented. It's > > difficult to decide what to do in these cases: since the func- > > tion never have "officially" become part of the API one could > > argue that they should be taken out but, on the other hand, > > some existing programs might be using them by now anyway... > > Jens, please could you please list who are that funcs/features ? To be honest, while that's a good question I can't really answer it in detail. I went through the lib/flinternal.h file and the ones below lib/private and grep'ed which functions actually exist at all, which of those were also declared in and in many cases checked against the documentation. But I didn't make any notes on that, so I can't give you a list, sorry... I als haven't gone through all the files below lib/include that make up , but I would take bets that there are also many declarations for functions that just don't exist anymore and quite a number that (at least to my feelings) shouldn't be part of the public API and also haven't been documented as beeing part of the API... > > l) All cases where alert box pops up when there's an internal error > > (most likely due to the caller of a public function not passing > > the correct types of arguments) have been changed to print a > > message to stderr only - I don't think it's proper for a library > > to bother the end user with stuff popping up suddenly with some > > error messages they rather have no idea what they are meant for. > > And actually the whole error handling part of the library is in > > for a rewrite... > I vote for dropping all popups, and returning error by return value, > debug info should be outputted only if requested (cmd line -debug) > and only from functions of the API. There shouldn't be any pop-ups anymore, just error messages going to stderr by default (but that can be redirected to a file or /dev/null or dealt with in other ways by redefining things with fl_set_error_handler()). > Internal errors should/need to be debugged before releasing > the library. Yes, for sure. But all, shit happens;-) And then the library is still not in the state I would like it to be in where errors like improper arguments passed to API functions would get caught in time and wouldn't in turn make internal functions barf. That is something to aim for, but we're definitely not there yet... > > I guess there have been enough new developments by now to permit a > > "real" new release (not 1.1.0 yet but 1.0.91). I also got a bit of > > a feeling that not too much testing is going on (for the last pre- > > releases I have not got much feedback except by two or three people), > > so it may not make much sense to wait any longer - a "real" release > > may stir things up a bit since it could also be noticed by those not > > on the mailing list. Does anyone care to comment? > > My idea, because XForms appear right now like a costant work in progress, > with no real stable-release, is to start a completely new branch (say > 2.0-unstable) and start a rewriting from scratch, collecting the > functionality required, dropping those not used, and implementing > new features. Rewriting things from scratch is a very attractive idea. In principle count me in on that. But (isn't there always a but?) that's going to take a lot of time and work and "old" programs depending on the current version of the XForms API should keep working (my own included;-) and I also guess that's what being a "maintainer" entails. For this reason I may seem to be a bit conservative, but at the moment my primary goals don't go too far beyond getting things to work correctly (I hope may views of that "wrok correctly don't deviate too much from those of others) - that's what I hope I will be able to handle. When I first took a look at the code my reaction was similar to yours, i.e. "get rid of all the old cruft and redo it in a reasonable way", but then I realized what amount of code there is that I don't feel that a "rewrite from scratch" aproach will bear fruits for quite some time. And, on the other hand, in order to attract enough people to get involved for a rewrite (like you perhaps?) I think it could be an advantage to have some- thing that works so that the project doesn't just look like mere vaporware. On a personal note, I had some time to spend on something in- teresting in the last few months since I hadn't had a regular job, but this will probably (and my bank account says "hope- fully";-) change soon. And then I fear I will have to spend more time on other (hopefully also interesting;-) things and less on debugging or even rewriting XForms. What I convinced of is that XForms needs some work-over to have a future at all. There are other toolkits that can be used in- stead and they will be used if there are no new developments to make it attractive again to use and hopefully thus get more people involved. Ok, is there anbody out there on this mailing list that would like to chime in with his/her views? It's not as we would be overwhelmed by the amount of traffic at the moment. I guess Bob's (thanks to him for keeping the mailing list running!) server is going to be able to cope with a bit more;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon May 5 10:49:36 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 5 May 2008 16:49:36 +0200 Subject: [XForms] New pre-release 1.0.91pre7 Message-ID: <20080505144936.GA23102@toerring.de> To subscribers of the xforms list Hello everybody, not that you get the idea that I have been totally lazy, sitting in the sun and twiddling my thumbs the last days ;-) here's one more pre-release: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91pre7.tar.gz And as usual here's the list of the things that got changed. A lot of this is due to Andrea Scopece, who just joined the mailing list and not only pointed out quite a number of problems but also send in patches! a) The '-flversion' option didn't work. Now hopefully it does. b) There was a bug that resulted in a segmentation fault of the main demo program. c) Resizing of scrollbars works again, but with a twist: verti- cal scrollbars get resized per defaulu in y-direction only, while horizontal ones in x-direction. I guess that's what most people would expect. d) The version information output by the library now contains all information, not only the first three lines. e) Jumping from one input field to another with and Shift- now works correctly and for all types of input fields, including multi-line input fields (that before did nothing on s at all). f) Date input fields handle verification of leap years correctly. g) Hiding a form that contains a canvas doesn't result in an XError anymore when the canvas hasn't been unmapped before. h) When a file selector has a callback installed the field for manually entering a file name isn't shown anymore - that field could not be used anyway. i) Message boxes created by fl_show_message() and fl_show_messages() now can display an unlimited amout of text and they automatically get a size so that the whole text fits in. Moreover, there's a new function fl_show_msg(), that takes a printf()-like format string and then an unspecified number of arguments (as amny as there are format specifiers in the format string). j) Removed limits on numbers of forms, objects and groups fdesign can deal with. Moreover, the browser for groups is now a multi- browser as it looks it should have been from the start. k) Spring cleaning: I started trying to distingish more clearly between things in the library that belong to the published API and those used only internally. Therefor I went through the lib/flinternals.h and lib/private/*.h files, removing function declarations that are also in or those for functions that don't exist anymore and renaming functions and macros not belonging to the public API to start with 'fli_' or 'FLI_' in- stead of 'fl_' and 'FL_'. There are quite a number of corner cases, i.e. functions that are in but that have never been documented. It's difficult to decide what to do in these cases: since the func- tion never have "officially" become part of the API one could argue that they should be taken out but, on the other hand, some existing programs might be using them by now anyway... l) All cases where alert box pops up when there's an internal error (most likely due to the caller of a public function not passing the correct types of arguments) have been changed to print a message to stderr only - I don't think it's proper for a library to bother the end user with stuff popping up suddenly with some error messages they rather have no idea what they are meant for. And actually the whole error handling part of the library is in for a rewrite... I guess there have been enough new developments by now to permit a "real" new release (not 1.1.0 yet but 1.0.91). I also got a bit of a feeling that not too much testing is going on (for the last pre- releases I have not got much feedback except by two or three people), so it may not make much sense to wait any longer - a "real" release may stir things up a bit since it could also be noticed by those not on the mailing list. Does anyone care to comment? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Apr 28 19:54:48 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 29 Apr 2008 01:54:48 +0200 Subject: [XForms] Posting not received: xforms do not compile cleanly on aix 5.3 Message-ID: <20080428235448.GA1750@toerring.de> To subscribers of the xforms list Hello, I just found out that our mailing list is mirrored at http://groups.google.com/group/fa.xforms/ And there's a posting from April 23rd which I didn't receive with the subject line Xforms do not compile cleanly on aix 5.3 Unortunately, I can't reply directly to the author ("Max") without signing in to Google (which I don't want to) nor do I get the authors email address. But I would need some more information to be able to figure out what's going on. So if anybody has an idea how to contact the author please let me know. Best regards, Jens PS: The next pre-release will hopefully come out soon. If you can't wait download the CVS version;-) -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sun Apr 20 09:28:10 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 20 Apr 2008 15:28:10 +0200 Subject: [XForms] New pre-release 1.0.91pre6 Message-ID: <20080420132809.GA11455@toerring.de> To subscribers of the xforms list Hello, I guess it's again time for a new pre-release: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91pre6.tar.gz The most important changes are: a) Since the 0.89 version on calling fl_initialize() the locale for the program was set to the default locale on the machine the pro- gram was running on. Unfortunately, this was never documented and led to trouble in several cases (e.g. because the programs stopped to read in floating point numbers with a decimal point using scanf() etc. when run on a machine with e.g. a French or German default locale setting since there a comma is expected instead). Already some years ago there was a discussion if this should be undone but never got removed. Since I feel that setting the locale behind the users back is a bad idea (perhaps also because figuring out the resulting problems took me a lot of time some years ago when switching to 0.89;-) I now removed it. I hope it doesn't break any existing programs, otherwise please let me know. b) Peter Galbraith pointed out a problem when compiling fdesign and told me what needed changing. It hopefully now works again. c) The C output files created by fdesign included "forms.h" instead of . Fixed. d) A few bugs in the code for the file selectors, buttons and sliders were corrected. e) The formbrowsers scrollbars weren't set reasonably when the form it belongs to was resized. And something I already changed in the last pre-release but forgot to mention: When calling fl_check_forms() or fl_check_forms_only() (which is recommended to be done when doing time intensive calcu- lations from time to time to have the program still react to user interactions) the program was put to sleep for at least 10 ms. This seeemed to me to be a rather long time and I thus reduced it to 1 ms. I haven't seen any adverse effects but please tellme if you do. As usual I would be delighted to get bug reports (and also confirmations that things work as expected). Please note that I may not be able to react to emails immediately during the next week, but don't let that keep you from sending me your comments. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sun Apr 13 06:22:50 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 13 Apr 2008 12:22:50 +0200 Subject: [XForms] Tweak needed to build pre-test In-Reply-To: <19621.1208046530@mixed.dyndns.org> References: <19621.1208046530@mixed.dyndns.org> Message-ID: <20080413102250.GA9889@toerring.de> To subscribers of the xforms list Hello Peter, On Sat, Apr 12, 2008 at 08:28:50PM -0400, Peter Galbraith wrote: > I just downloaded the pre-test tar ball and found this small issue: > > In fdesign/fd > > $ grep forms.h * | grep include > > pallette.c:#include "forms.h" > ui_attrib.c:#include "forms.h" > ui_objs.c:#include "forms.h" > ui_theforms.c:#include "forms.h" > > To get a clean build, this should be: > > #include "include/forms.h" > > The same goes for these files in fd/spec : > > browser_spec.c > button_spec.c > choice_spec.c > counter_spec.c > dial_spec.c > freeobj_spec.c > free_spec.c > menu_spec.c > pixmap_spec.c > positioner_spec.c > scrollbar_spec.c > slider_spec.c > twheel_spec.c > xyplot_spec.c Thank you very much for pointing that out! It seemed to built cleanly on my machine (looks like the compiler somehow finds it here without the "include/" in front of it) but I had no- ticed that something strange was going on with "make install", but which I had not understood yet. And that missing "include/" it was! Since I now had a closer look I also realized that for "normal" cases, i.e. when you convert a *.fd file that belongs to a regular project (and not to XForms itself) it should be #include and not #include "include/forms.h" as it used to be. I will add the changes to the CVS version and, of course, it's going into the next pre-release. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From p.galbraith at globetrotter.net Sat Apr 12 20:28:50 2008 From: p.galbraith at globetrotter.net (Peter Galbraith) Date: Sat, 12 Apr 2008 20:28:50 -0400 Subject: [XForms] Tweak needed to build pre-test Message-ID: <19621.1208046530@mixed.dyndns.org> To subscribers of the xforms list Hi, I just downloaded the pre-test tar ball and found this small issue: In fdesign/fd $ grep forms.h * | grep include pallette.c:#include "forms.h" ui_attrib.c:#include "forms.h" ui_objs.c:#include "forms.h" ui_theforms.c:#include "forms.h" To get a clean build, this should be: #include "include/forms.h" The same goes for these files in fd/spec : browser_spec.c button_spec.c choice_spec.c counter_spec.c dial_spec.c freeobj_spec.c free_spec.c menu_spec.c pixmap_spec.c positioner_spec.c scrollbar_spec.c slider_spec.c twheel_spec.c xyplot_spec.c Thanks, -- Peter S. Galbraith GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E 6623'rd GNU/Linux user at the Counter - http://counter.li.org/ _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Apr 9 21:27:27 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 10 Apr 2008 03:27:27 +0200 Subject: [XForms] New pre-release 1.0.91pre5 Message-ID: <20080410012726.GA9940@toerring.de> To subscribers of the xforms list Hello everybody, I guess it's about time for a new pre-release, so here you go: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91pre5.tar.gz Again, there aren't any dramatic changes. Due to some very constructive criticism by Michal Szymanski I undid some of the changes I made: a) I had made buttons only react to the left mouse button. My idea behind this was to make XForms' behaviour more similar to that of other toolkits with this. But it breaks some existing programs and therefore it's probably better to implement it differently. Per default buttons now again react to each and every mouse button (including the scroll wheel) as it used to be. But to make it possible to change that I added a new function void fl_set_button_mouse_buttons( FL_OBJECT * obj, int mb ) The first argument is a pointer to the button object and the second determines which mouse buttons the button object will react to. It's the inclusive OR of ( 1 << ( FL_MBUTTONx - 1 ) ) where the 'x' in 'FL_MBUTTONx' is a number between 1 and 5, with 1 for the left, 2 for the middle and 3 for the right mouse button. 4 stands for rotating the scroll wheel up and 5 for down. For each of the bits set in 'mb' the button will react to clicks of the corresponding mouse button. Of course, there's also the 'reverse' function that lets you determine which mouse buttons a button reacts to, going by the name of int fl_set_button_mouse_buttons( FL_OBJECT * obj ) The return value has the same meaning as the 'mb' value you pass to the other function. b) The behaviour of the buttons can also be set via fdesign. If you look at the attributes of a button. When you select the button and press 'F1' and then click on the "Spec" tab rider you are able to select which mouse buttons the button will react to. The '.fd' files now contain for buttons that aren't set to the default behaviour (all mouse buttons work) an extra line, starting with 'mbuttons:' and followed by an integer with the value of 'mb' for the button. c) Luckily the older fdesign versions don't seem to mind the extra line for buttons starting with 'mbuttons:'. But to make it easier to compile applications that are sensitive to these changes I added a new option to fdesign: '-xforms-version'. This writes the version of the library fdesign was linked against to stderr in a form like FORMS Library Version 1.0.91pre5 d) Also making one of a group of radio buttons "active" automatically wasn't such a great idea as I had imagined. So I simply removed this, reverting back to the original behaviour. e) Michal Szymanski also found out that if you started an appli- cation with a lot of options the program did crash with a segmentation fault in fl_initialize(). It looks as if this was due to not enough memory getting allocated for the copy of the command line arguments done in a function invoked by fl_initialize(). f) I removed the limitation on both the number of symbols that can be created (formerly 16) and the length of their names (formerly 15 characters). g) I got a bit further in my quest to free all memory allocated by the library at least on fl_finish() - all memory allocated for tabfolders now (hopefully) gets released. h) Finally - shame on my - there was a bug I introduced that re- sulted in a program hanging when a menu entry contained a '%'. Best regards and happy testing, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 27 10:41:35 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 27 Mar 2008 15:41:35 +0100 Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: References: <20080326205031.GA631@toerring.de> Message-ID: <20080327144135.GE30263@toerring.de> To subscribers of the xforms list Hello, On Thu, Mar 27, 2008 at 09:22:15AM +0100, Didier Verkindt wrote: > Concerning your last proposal, I fully support it. Fine;-) I now realized that this behaviour was already in the older versions and only got broken due to my own stupidness. It's working correctly again in the CVS version and will so in the next pre-release - or should that become the next re- lease? Since I didn't get much reports if things are working or not I am not sure how to procede... > Less important but it could be useful: is it possible to add > a new type of slider where the resolution can be chosen directly > from an input field associated to it? Please accept my appologies, but at the moment I still have my hands full with trying to understand and, as far as necessary, correct the code so that I wouldn't like to make any promises I probably would have to break anyway;-) But it might be useful to have a kind of a wish-list: there's already the scrolled canvas Michal Szymanski asked for and now your slider with an editable field for the resolution... BTW, do you know that the slider moves slower when you keep the left mouse button down? I changed that part of the code quite a bit and hope that it works more conveniemtly now. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 27 16:19:20 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 27 Mar 2008 21:19:20 +0100 Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: <20080327135652.GA10730@astrouw.edu.pl> References: <20080326205031.GA631@toerring.de> <20080327135652.GA10730@astrouw.edu.pl> Message-ID: <20080327201920.GB27529@toerring.de> To subscribers of the xforms list Hi Michal, On Thu, Mar 27, 2008 at 02:56:52PM +0100, Michal Szymanski wrote: > I have an application for displaying FITS images, using canvas. > While the mouse pointer is in the image canvas, its coordinates should > be printed in the main app window, both at rest and while moving. I hope I found the solution to the problem (I actually don't really understand yet why it works since I just put back in a line I had removed because it didn't make sense to me). You can download the newest version of lib/forms.c (where the bug were) from the CVS repository at Savannah. Or would it be more convenient if I make a new release out of it? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 27 15:17:46 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 27 Mar 2008 20:17:46 +0100 Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: <20080327135652.GA10730@astrouw.edu.pl> References: <20080326205031.GA631@toerring.de> <20080327135652.GA10730@astrouw.edu.pl> Message-ID: <20080327191745.GA27529@toerring.de> To subscribers of the xforms list Hi Michal, On Thu, Mar 27, 2008 at 02:56:52PM +0100, Michal Szymanski wrote: > There is a problem with events servicing, apparently introduced in the > latest (pre3, or pre2, I did not check the pre2) version. > > I have an application for displaying FITS images, using canvas. > While the mouse pointer is in the image canvas, its coordinates should > be printed in the main app window, both at rest and while moving. > > It has always been working fine, including the first 1.0.91 version > provided by Jens. With the "pre3" version, it does not work. When the > mouse enters the canvas, a single position is printed but then it does > not change when the mouse moves around, unless I click the button or > leave the canvas and enter again. Even then I get only single position > printed. The code did not change at all so it must be something inside > the library. > > The excerpt from the code follows. Thank you for the very precise description of the problem! I will try to figure out what's going wrong immediately and notify you when I hope to have solved it. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From msz at astrouw.edu.pl Thu Mar 27 09:56:52 2008 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Thu, 27 Mar 2008 14:56:52 +0100 Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: References: <20080326205031.GA631@toerring.de> Message-ID: <20080327135652.GA10730@astrouw.edu.pl> To subscribers of the xforms list Hi XFormers, There is a problem with events servicing, apparently introduced in the latest (pre3, or pre2, I did not check the pre2) version. I have an application for displaying FITS images, using canvas. While the mouse pointer is in the image canvas, its coordinates should be printed in the main app window, both at rest and while moving. It has always been working fine, including the first 1.0.91 version provided by Jens. With the "pre3" version, it does not work. When the mouse enters the canvas, a single position is printed but then it does not change when the mouse moves around, unless I click the button or leave the canvas and enter again. Even then I get only single position printed. The code did not change at all so it must be something inside the library. The excerpt from the code follows. any ideas? regards, Michal. -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND ------------------------------------------------------------------ int im_canvas_motion(FL_OBJECT *ob, Window win, int ww, int hh, XEvent *ev, void *d) { FD_image *ui = d; int X, Y, x, y, w ,h; double pixval; if ( pixbuf == NULL ) return 0; mouse_xlib_x = ev->xmotion.x; mouse_xlib_y = ev->xmotion.y; xy_xlib2image(mouse_xlib_x, mouse_xlib_y, &X, &Y); sprintf(position,"%4d %4d", X, Y); fl_set_object_label(ui->position, position); /* cut */ } The handler is registered when application starts, with: void init_canvas(FD_image *fdui) { FL_OBJECT *canvas; canvas = fdui->canvas; fl_add_canvas_handler(canvas, MotionNotify, im_canvas_motion, fdui); /* cut (other handlers) */ } _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From verkindt at lapp.in2p3.fr Thu Mar 27 04:22:15 2008 From: verkindt at lapp.in2p3.fr (Didier Verkindt) Date: Thu, 27 Mar 2008 09:22:15 +0100 (CET) Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: <20080326205031.GA631@toerring.de> References: <20080326205031.GA631@toerring.de> Message-ID: To subscribers of the xforms list Hello, Thanks for all this xform revival work! Concerning your last proposal, I fully support it. Less important but it could be useful: is it possible to add a new type of slider where the resolution can be chosen directly from an input field associated to it? Cheers, Didier ----------------------------------------------------------- Didier VERKINDT, LAPP, Ch. de Bellevue, 74941 Annecy-le-Vieux, FRANCE tel:33(0)450091671 or 5573 fax:33(0)450279495 web:lapp.in2p3.fr/~verkindt On Wed, 26 Mar 2008, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hello, > > having a few holidays with rather ugly weather allowed me > to continue so, again, here's something new to play with: > > http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre3.tar.gz > > The most important changes are: > > a) Input objects now lose the focus (and report changes back > to the program) on clicks of other objects that accept a > click with the mouse (buttons, sliders, etc.). This gets > around the problem that if you had an input field, edited > something in there (without hitting the ENTER or TAB key) > and then clicked on some button that's supposed to make > use of what just had got entered into the input field, the > function fl_get_input() still returned the unchanged value > since the input field never lost its focus and thus didn't > accept the changes you made. > > If you move the mouse out of a window with an active input > object and move it into another window keyboard input now > goes to the new window instead of to the one you left. > > Further restructuring of the event handling code. Same > code is now used in xpopup.c and forms.c for dealing > with idling. > > b) Memory gets deallocated also for all objects on call of the > functions fl_free_form() and fl_finish(). I would very much > like to come to a point where XForms doesn't leak memory > anymore - but that's not done yet, at least tabfolders still > pose a problem... > > The code from the file lib/be.c (a kind of primitive garbage > collection) isn't used anymore, it didn't really do what I > guess it was intended to do (and then only when an idle > callback was installed). > > c) Timeouts should be a bit more precise now and not expire > too early anymore (as it's promised in the manual). > > d) Silders (and thus scrollbars) got a rework and some minor > annoyances hopefully have gone. > > e) If available sigaction() is now used instead of signal() > for signal handlers. > > f) Code emitted by fdesign doesn't use fl_calloc() anymore > but instead fl_malloc() (somebody reported to have had a > bit of a problem with that and it didn't make any sense > to zero out the memory anyway). > > I have also another proposal. At the moment the action asso- > ciated with a button gets executed the moment you press down the > left mouse button. Most other toolkits do it differently - the > action only gets executed when the left mouse button is released. > I prefer that behaviour quite a lot since it's then still possible > to move the mouse (with the button still pressed down) away from > the button and release the mouse button only then, thus avoiding > the action coupled to clicking onto the button. This has a few > times saved the day for me when I carelessly clicked somewhere > and only in the very last moment realised that this was a rather > stupid idea... As far as I can see all button types (except touch > buttons for obvious reasons) could be made to work that way. What > do you think? > Best regards, Jens > -- > \ Jens Thoms Toerring ________ jt at toerring.de > \_______________________________ http://toerring.de > _______________________________________________ > To unsubscribe, send any message to > xforms-leave at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 26 16:50:31 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 26 Mar 2008 21:50:31 +0100 Subject: [XForms] New pre-release 1.0.91pre3 Message-ID: <20080326205031.GA631@toerring.de> To subscribers of the xforms list Hello, having a few holidays with rather ugly weather allowed me to continue so, again, here's something new to play with: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre3.tar.gz The most important changes are: a) Input objects now lose the focus (and report changes back to the program) on clicks of other objects that accept a click with the mouse (buttons, sliders, etc.). This gets around the problem that if you had an input field, edited something in there (without hitting the ENTER or TAB key) and then clicked on some button that's supposed to make use of what just had got entered into the input field, the function fl_get_input() still returned the unchanged value since the input field never lost its focus and thus didn't accept the changes you made. If you move the mouse out of a window with an active input object and move it into another window keyboard input now goes to the new window instead of to the one you left. Further restructuring of the event handling code. Same code is now used in xpopup.c and forms.c for dealing with idling. b) Memory gets deallocated also for all objects on call of the functions fl_free_form() and fl_finish(). I would very much like to come to a point where XForms doesn't leak memory anymore - but that's not done yet, at least tabfolders still pose a problem... The code from the file lib/be.c (a kind of primitive garbage collection) isn't used anymore, it didn't really do what I guess it was intended to do (and then only when an idle callback was installed). c) Timeouts should be a bit more precise now and not expire too early anymore (as it's promised in the manual). d) Silders (and thus scrollbars) got a rework and some minor annoyances hopefully have gone. e) If available sigaction() is now used instead of signal() for signal handlers. f) Code emitted by fdesign doesn't use fl_calloc() anymore but instead fl_malloc() (somebody reported to have had a bit of a problem with that and it didn't make any sense to zero out the memory anyway). I have also another proposal. At the moment the action asso- ciated with a button gets executed the moment you press down the left mouse button. Most other toolkits do it differently - the action only gets executed when the left mouse button is released. I prefer that behaviour quite a lot since it's then still possible to move the mouse (with the button still pressed down) away from the button and release the mouse button only then, thus avoiding the action coupled to clicking onto the button. This has a few times saved the day for me when I carelessly clicked somewhere and only in the very last moment realised that this was a rather stupid idea... As far as I can see all button types (except touch buttons for obvious reasons) could be made to work that way. What do you think? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Mar 31 19:19:12 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 1 Apr 2008 01:19:12 +0200 Subject: [XForms] New pre-release 1.0.91pre4 In-Reply-To: <20080320023426.GA19850@toerring.de> References: <20080320023426.GA19850@toerring.de> Message-ID: <20080331231912.GA11721@toerring.de> To subscribers of the xforms list Hello everybody, since I am not going to have much time this week (and may not even be able to react to emails until the weekend) I decided to come up with a new pre-release with the last bug corrections, bugs I have to admit I introduced myself. They concern the way buttons react and the problem Michal Szymanski pointed out, i.e. not getting events for mouse movements in a canvas. Even though there's nothing really new I guess it's simpler for those that want to do tests to have a "proper" pre-release instead of fishing the changed files out of the CVS repository. The archive to download is http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91pre4.tar.gz As usual, comments, feedback about things that don't work etc. will be much appreciated! And example code that shows the problems will get an even warmer reception;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From Jean-Marc.Lasgouttes at inria.fr Thu Mar 20 05:50:36 2008 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Mar 2008 10:50:36 +0100 Subject: [XForms] Update: 1.0.91pre2 In-Reply-To: <20080320023426.GA19850@toerring.de> (Jens Thoms Toerring's message of "Thu\, 20 Mar 2008 03\:34\:26 +0100") References: <20080320023426.GA19850@toerring.de> Message-ID: To subscribers of the xforms list Jens Thoms Toerring writes: > To subscribers of the xforms list > > Hello again, > > I just found that I didn't realize that some part of fdesign > was broken, which resulted in the demo programs not being created > when compiling from the downloaded pre-release. I hope I now fixed > this bug and that everything compiles cleanly with the new version > I just uploaded. Sorry for the inconvenience... Remember to update the NEWS file eventually. In particular, all changes to the API should be documented in a central place (I thought we had such a file, but cannot find it now). JMarc _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 19 22:34:26 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 20 Mar 2008 03:34:26 +0100 Subject: [XForms] Update: 1.0.91pre2 Message-ID: <20080320023426.GA19850@toerring.de> To subscribers of the xforms list Hello again, I just found that I didn't realize that some part of fdesign was broken, which resulted in the demo programs not being created when compiling from the downloaded pre-release. I hope I now fixed this bug and that everything compiles cleanly with the new version I just uploaded. Sorry for the inconvenience... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 19 17:20:42 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 19 Mar 2008 22:20:42 +0100 Subject: [XForms] New pre-release 1.0.91pre2 Message-ID: <20080319212042.GA21255@toerring.de> To subscribers of the xforms list Hello, I couldn't keep from messing around with the XForms code and made some more changes that concern some sensitive internals which need extensive testing. Therefor I have made up a second pre-release for the coming (hopefully soon;-) 1.0.91 release. It can be downloaded friom http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre2.tar.gz The most important changes are: a) Further cleanup of the central event handling code in lib/forms.c. There was quite a bit of cruft that was so complicated that I hadn't dared to touch it before. This also required changes in the handling of button, choice counter and slider/scrollbar objects etc. To me it looks now as if everythings works fine, but it wouldn't be the first time I would have missed rather obvious bugs... b) Repaired a bug (probably my own) in the code for choice objects. Mouse wheel can now be used to walk through the items of a choice object without having to open the opup window. c) Menus now get highlighted when the mouse is moved on top of them, indicating to the user that something will happen if s/he clicks the mouse. I never did like the titles on the popups of menus and thus added a function fl_set_menu_notitle() that takes two arguments, the menu object and a boolean value to switch the title off (when called with a non-zero value) or on. For FL_PUSH_MENU objects with the no_title flag being set his has the following consequence: they only get opened when the mouse button has been released and they appear just below the menu button, just like FL_PULLDOWN_MENU objects. See the left hand menu in the menu demo program for an example. There were also some inconsitency with the handler that may be associated with a menu is invoked: in some situations it was invoked only when the selected menu item had changed, in others when just an item had been selected (even the same as the one already selected. This has been changed to the second type of behaviour, i.e. the handler is called whenever a menu item has been selected. But I don't know if this is clever and if the other variant should be implemented instead... d) Most objects now can only be used with the left mouse button (and some also with the mouse wheel) unless some special meaning is associated with the middle and right mouse button. In the past most objects also did react to the middle and right mouse button which I always found rather irritating and unusual. I actually once lost quite a bit of work since I accidentally moved the scroll wheel when shifting the mouse around and, thanks to Murphy's law, I hit the "Quit" button of the application... e) Just for the fun of it I have reducded the default border- width to one pixel - but that's easy to set back to the traditional value of 3 or something else. Have fun, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Mar 18 20:27:08 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 19 Mar 2008 01:27:08 +0100 Subject: [XForms] Discussion concerning development Message-ID: <20080319002708.GB3158@toerring.de> To subscribers of the xforms list Hello Jason, On Mon, Mar 17, 2008 at 03:17:22PM -0400, Jason Cipriani wrote: > On Fri, Mar 14, 2008 at 7:16 AM, Jens Thoms Toerring wrote: > I think at this point it may even be save to assume C99 compliance, > which is now almost a decade in the past. I wouldn't go that far - as far as I know C99 never did really get of the ground and there are only very few compilers fully C99 compliant (even gcc didn't claim to be the last time I did look). But I also guess that non-C89 compliant compilers are going to be rather hard to find today;-) > It seems reasonable to me to assume that anybody using a machine that > can run XForms is also using a compiler and libc that is less than 20 > years old at this point. It also seems reasonable to assume that > anybody using a compiler and libc that is *more* than 20 years old has > more issues to worry about than compiling XForms. ;-) > > I am rather strongly opposed to arbitrary limits where- > > ever they can be avoided since todays reasonable limits > > can be a headache tomorrow ("Who will ever need more than > > 600kB of memory?") and would try to change the code as far > > as possible to abvoid them. On the other hand I may not > > be seeing the complete picture and these limits may have > > some beneficial effects I am not aware of. Does anybody > > see some good reasons for keeping them? > > If they are causing problems, no. If they are not causing problems, > even though it *would* be better to have dynamic upper limits, there > is also the question of how much work it is to change it. I do not > know where all the fixed limits are, it has been some time since I dug > into XForms source. I am not going to do much about that right now, it was more of a question if there's some reasonable opposition to that idea. All I want to make sure is that by removing arbitrary limits I don't break too many things. > > Another point I am not too happy about some of the default > > looks of XForms. For example I find that the default border > > width of 3 pixels looks plain ugly... > > I nearly always fl_set_border_width(1) anyway. I also think the > default look is pretty ugly. The default colors are a little mirky as > well, but that may just be a personal preference (and also in contrast > to gnome's brighter default colors) -- I almost always override the > defaults with fl_set_icm_color() to something brighter. I seem to have > settled on the following: > > #define UI_COLOR_LIGHT 255, 255, 255 > #define UI_COLOR_LTMID 224, 224, 224 > #define UI_COLOR_MID 202, 202, 202 > #define UI_COLOR_DARK 128, 128, 128 > #define UI_COLOR_DARKER 96, 96, 96 > #define UI_COLOR_INACTIVE 96, 96, 96 > > fl_set_icm_color(FL_TOP_BCOL, UI_COLOR_LIGHT); > fl_set_icm_color(FL_LEFT_BCOL, UI_COLOR_LIGHT); > fl_set_icm_color(FL_MCOL, UI_COLOR_LTMID); > fl_set_icm_color(FL_COL1, UI_COLOR_MID); > fl_set_icm_color(FL_BOTTOM_BCOL, UI_COLOR_DARK); > fl_set_icm_color(FL_RIGHT_BCOL, UI_COLOR_DARK); > fl_set_icm_color(FL_DARKER_COL1, UI_COLOR_DARKER); > fl_set_icm_color(FL_INACTIVE, UI_COLOR_INACTIVE); Yes, default colors are another point! If there's someone with some graphics design background on the mailing list recommendations will definitely be appreciated! For the next pre-release (hopefully coming tomorrow, but there are still a few issues to be taken care of:-( I am going to set the default borderwidth to 1 just for the fun of it. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Mon Mar 17 15:17:22 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Mon, 17 Mar 2008 15:17:22 -0400 Subject: [XForms] Discussion concerning development In-Reply-To: <20080314111611.GA16214@toerring.de> References: <20080314111611.GA16214@toerring.de> Message-ID: To subscribers of the xforms list On Fri, Mar 14, 2008 at 7:16 AM, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hello, > > going through parts of the code of XForms some things > got me puzzled and I would like to ask about your opinion: > > a) It seems to be assumed that the compiler used to comile > XForms isn't even ANSI C89 compatible. This might have > been a problem at the time the XForms project was star- > ted, but nearly 19 years after this standard came out > is this something we still have to care about? Is there > anybody out there still using a pre-C89 compiler and > where for example realloc() called with a NULL pointer > as the first argument isn't the same as a call of > malloc() (i.e. the libc isn't ANSI C89 compliant)? I think at this point it may even be save to assume C99 compliance, which is now almost a decade in the past. It seems reasonable to me to assume that anybody using a machine that can run XForms is also using a compiler and libc that is less than 20 years old at this point. It also seems reasonable to assume that anybody using a compiler and libc that is *more* than 20 years old has more issues to worry about than compiling XForms. > b) In lots of places fixed upper limits exist, starting with > the maximum number of forms (a limitation I already have > removed), the number of popup menus and there entries, > number of file selectors, line lengths in text browsers > etc. etc. I don't know if these "arbitrary limits" were > introduced because the original authors didn't feel too > comfortable with dynamic memory allocation or if it was > assumed that having fixed sized arrays would simply be > faster (especially in the "old times" when memory allo- > cation handling wasn't that optimized as it tends to be > today). Probably a little bit of both. > I am rather strongly opposed to arbitrary limits where- > ever they can be avoided since todays reasonable limits > can be a headache tomorrow ("Who will ever need more than > 600kB of memory?") and would try to change the code as far > as possible to abvoid them. On the other hand I may not > be seeing the complete picture and these limits may have > some beneficial effects I am not aware of. Does anybody > see some good reasons for keeping them? If they are causing problems, no. If they are not causing problems, even though it *would* be better to have dynamic upper limits, there is also the question of how much work it is to change it. I do not know where all the fixed limits are, it has been some time since I dug into XForms source. > Another point I am not too happy about some of the default > looks of XForms. For example I find that the default border > width of 3 pixels looks plain ugly - ten years ago pronounced > 3D effects may have been the the rage, but nowadays it looks > to me pretty old-fashioned. Would anybody mind if I would re- > duce the default border width from 3 to 2 (I personally would > prefer 1, but that might be a bit too extreme a change)? You > can have kind of a preview of the effects if you start your > application with the "-bw 2" option, which changes the default > from 3 to 2. I nearly always fl_set_border_width(1) anyway. I also think the default look is pretty ugly. The default colors are a little mirky as well, but that may just be a personal preference (and also in contrast to gnome's brighter default colors) -- I almost always override the defaults with fl_set_icm_color() to something brighter. I seem to have settled on the following: #define UI_COLOR_LIGHT 255, 255, 255 #define UI_COLOR_LTMID 224, 224, 224 #define UI_COLOR_MID 202, 202, 202 #define UI_COLOR_DARK 128, 128, 128 #define UI_COLOR_DARKER 96, 96, 96 #define UI_COLOR_INACTIVE 96, 96, 96 fl_set_icm_color(FL_TOP_BCOL, UI_COLOR_LIGHT); fl_set_icm_color(FL_LEFT_BCOL, UI_COLOR_LIGHT); fl_set_icm_color(FL_MCOL, UI_COLOR_LTMID); fl_set_icm_color(FL_COL1, UI_COLOR_MID); fl_set_icm_color(FL_BOTTOM_BCOL, UI_COLOR_DARK); fl_set_icm_color(FL_RIGHT_BCOL, UI_COLOR_DARK); fl_set_icm_color(FL_DARKER_COL1, UI_COLOR_DARKER); fl_set_icm_color(FL_INACTIVE, UI_COLOR_INACTIVE); > The same question also arises for the use of bold, italic fonts > in popups and menus. Again I find them rather ugly and would > propose to use normal, non-italic fonts as the default... Personally, I have no opinion about that. I think the italics are a little harsh so I usually turn them off, otherwise I don't know. Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Fri Mar 14 07:16:11 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 14 Mar 2008 12:16:11 +0100 Subject: [XForms] Discussion concerning development Message-ID: <20080314111611.GA16214@toerring.de> To subscribers of the xforms list Hello, going through parts of the code of XForms some things got me puzzled and I would like to ask about your opinion: a) It seems to be assumed that the compiler used to comile XForms isn't even ANSI C89 compatible. This might have been a problem at the time the XForms project was star- ted, but nearly 19 years after this standard came out is this something we still have to care about? Is there anybody out there still using a pre-C89 compiler and where for example realloc() called with a NULL pointer as the first argument isn't the same as a call of malloc() (i.e. the libc isn't ANSI C89 compliant)? b) In lots of places fixed upper limits exist, starting with the maximum number of forms (a limitation I already have removed), the number of popup menus and there entries, number of file selectors, line lengths in text browsers etc. etc. I don't know if these "arbitrary limits" were introduced because the original authors didn't feel too comfortable with dynamic memory allocation or if it was assumed that having fixed sized arrays would simply be faster (especially in the "old times" when memory allo- cation handling wasn't that optimized as it tends to be today). I am rather strongly opposed to arbitrary limits where- ever they can be avoided since todays reasonable limits can be a headache tomorrow ("Who will ever need more than 600kB of memory?") and would try to change the code as far as possible to abvoid them. On the other hand I may not be seeing the complete picture and these limits may have some beneficial effects I am not aware of. Does anybody see some good reasons for keeping them? Another point I am not too happy about some of the default looks of XForms. For example I find that the default border width of 3 pixels looks plain ugly - ten years ago pronounced 3D effects may have been the the rage, but nowadays it looks to me pretty old-fashioned. Would anybody mind if I would re- duce the default border width from 3 to 2 (I personally would prefer 1, but that might be a bit too extreme a change)? You can have kind of a preview of the effects if you start your application with the "-bw 2" option, which changes the default from 3 to 2. The same question also arises for the use of bold, italic fonts in popups and menus. Again I find them rather ugly and would propose to use normal, non-italic fonts as the default... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 14:02:21 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 19:02:21 +0100 Subject: [XForms] Using Xform in background without display In-Reply-To: References: <20080313112646.GA9784@toerring.de> <20080313131224.GB9842@toerring.de> Message-ID: <20080313180221.GA17421@toerring.de> To subscribers of the xforms list Hi Didier, On Thu, Mar 13, 2008 at 05:07:01PM +0100, Didier Verkindt wrote: > My application uses Xform for GUI and ROOT for making plots. > And in some cases, I do not want to interact with the application, > I would like to run it in background, producing a ROOT plot that > is written as a jpg file (thanks to ROOT's class TImageDump) > TImageDump *imgdump = new TImageDump(jpgFileName); > gDDCanvas->Paint(); > TImage *img = imgdump->GetImage(); > img->SetImageQuality(img->kImgFast); > img->SetImageCompression(60); > imgdump->Close(); > imgdump->Delete(); None of these functions seem to be from XForms but ROOT (at least as far as I can tell), so if you don't use any XForms functions you don't have to invoke fl_initialize() at all. I think if this is the case it's rather simple. Do something like this (sorry, it's in C and not C++, but I am not that good at C++ and it probably will be nearly the same): int main( int argc, char * argv[ ] ) { int i; for ( i = 1; i < argc; i++ ) if ( ! strcmp( argv[ i ], "-nodisplay" ) ) break; if ( i == argc ) /* "-nodisplay" not found */ fl_initialize( &argc, argv, "Whatever", 0, 0 ); That way you avoid calling fl_initialize() when the program is invoked with the "-nodisplay" option. And that should be fine as long as you don't call any XForms functions after- wards (you will probably find out if you do so anyway since then XForms would complain loudly;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From verkindt at lapp.in2p3.fr Thu Mar 13 12:07:01 2008 From: verkindt at lapp.in2p3.fr (Didier Verkindt) Date: Thu, 13 Mar 2008 17:07:01 +0100 (CET) Subject: [XForms] Using Xform in background without display In-Reply-To: <20080313131224.GB9842@toerring.de> References: <20080313112646.GA9784@toerring.de> <20080313131224.GB9842@toerring.de> Message-ID: To subscribers of the xforms list Hi, My application uses Xform for GUI and ROOT for making plots. And in some cases, I do not want to interact with the application, I would like to run it in background, producing a ROOT plot that is written as a jpg file (thanks to ROOT's class TImageDump) TImageDump *imgdump = new TImageDump(jpgFileName); gDDCanvas->Paint(); TImage *img = imgdump->GetImage(); img->SetImageQuality(img->kImgFast); img->SetImageCompression(60); imgdump->Close(); imgdump->Delete(); which does not need a display, as far as I know. Only fl_initialize prevented me to do this on a machine with no display. According to what you wrote, it seems difficult to have a call to fl_initialize which would not take care of the display's part. I am not happy but thanks for your investigation. If you have any idea to overcome the problem, do not hesitate. I am not a pro of Xform or X servers, so I do not foresee to find the solution by myself. Best regards, Didier ----------------------------------------------------------- Didier VERKINDT, LAPP, Ch. de Bellevue, 74941 Annecy-le-Vieux, FRANCE tel:33(0)450091671 or 5573 fax:33(0)450279495 web:lapp.in2p3.fr/~verkindt On Thu, 13 Mar 2008, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi Jean-Marc, > > On Thu, Mar 13, 2008 at 12:50:58PM +0100, Jean-Marc Lasgouttes wrote: > > Jens Thoms Toerring writes: > > > Are you actually using anything from XForms when you want the > > > program to run without any graphics output? > > > > I guess the idea is to use flimage. Does this work without a display? > > Mmmm. I have to admit that I didn't went through that part of > XForms more than very superficially yet, so I could be comple- > tely wrong. But a short look at that part of the code shows > that quite a number of Xlib functions are used there, so I > would guess that you can't use that part (which already is > separated out into its own library, libflimage.so) without > having a display (or at least some kind of Xserver that fakes > a display if there's no screen, which using using xvfb might > amount to). > > And, as far as my (very limited) understanding goes, all the > functions in flimage are meant to read in a graphics file and > display it on the screen (e.g. on top of a button etc.) or to > write out an image from an X drawable to a file. In both cases > you would need a display. > > Since Didier wrote that he just wants to write out jpg files > I guess that he will always need to create some X drawable, > draw something onto it and then write it out. But that would > involve an X drawable. But if he just wants to convert e.g. > a gif image to a jpg I would rather recommend to use some- > thing more suitable in that case, e.g. ImageMagick. > > Best regards, Jens > -- > \ Jens Thoms Toerring ________ jt at toerring.de > \_______________________________ http://toerring.de > _______________________________________________ > To unsubscribe, send any message to > xforms-leave at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 09:12:24 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 14:12:24 +0100 Subject: [XForms] Using Xform in background without display In-Reply-To: References: <20080313112646.GA9784@toerring.de> Message-ID: <20080313131224.GB9842@toerring.de> To subscribers of the xforms list Hi Jean-Marc, On Thu, Mar 13, 2008 at 12:50:58PM +0100, Jean-Marc Lasgouttes wrote: > Jens Thoms Toerring writes: > > Are you actually using anything from XForms when you want the > > program to run without any graphics output? > > I guess the idea is to use flimage. Does this work without a display? Mmmm. I have to admit that I didn't went through that part of XForms more than very superficially yet, so I could be comple- tely wrong. But a short look at that part of the code shows that quite a number of Xlib functions are used there, so I would guess that you can't use that part (which already is separated out into its own library, libflimage.so) without having a display (or at least some kind of Xserver that fakes a display if there's no screen, which using using xvfb might amount to). And, as far as my (very limited) understanding goes, all the functions in flimage are meant to read in a graphics file and display it on the screen (e.g. on top of a button etc.) or to write out an image from an X drawable to a file. In both cases you would need a display. Since Didier wrote that he just wants to write out jpg files I guess that he will always need to create some X drawable, draw something onto it and then write it out. But that would involve an X drawable. But if he just wants to convert e.g. a gif image to a jpg I would rather recommend to use some- thing more suitable in that case, e.g. ImageMagick. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From Jean-Marc.Lasgouttes at inria.fr Thu Mar 13 07:50:58 2008 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 13 Mar 2008 12:50:58 +0100 Subject: [XForms] Using Xform in background without display In-Reply-To: <20080313112646.GA9784@toerring.de> (Jens Thoms Toerring's message of "Thu\, 13 Mar 2008 12\:26\:46 +0100") References: <20080313112646.GA9784@toerring.de> Message-ID: To subscribers of the xforms list Jens Thoms Toerring writes: > Are you actually using anything from XForms when you want the > program to run without any graphics output? I guess the idea is to use flimage. Does this work without a display? JMarc _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 07:26:46 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 12:26:46 +0100 Subject: [XForms] Using Xform in background without display Message-ID: <20080313112646.GA9784@toerring.de> To subscribers of the xforms list Hi, > I have developped since several years a data visualization application > that uses Xforms as GUI. In some circumstances, I would like to run this > application in background (producing just jpg files, without user > interaction and without showing any xform window) on a machine which has > no display. But I get stucked on the fl_initialize function. > With the following error message: > Can't open display --No such file or directory > Missing or failed fl_initialize() > > For now, I have overcome the problem by using xvfb when starting the > application. But could the next release of Xform provide an API or a flag > that allows to run temporarily without display? > Or could the next release separate in fl_initialize what is specific xform > init from what is related to the display? That's going to be a bit difficult because XForms is suposed to work with a display. Hardly anything useful can be done without one, and trying to separate out the small number of functions that may be usable without having an open display would probably be a huge amount of work (actually, if that would be possible and any usuful functionality would remain in the resulting subset, it probably should be put into a separate library;-) Are you actually using anything from XForms when you want the program to run without any graphics output? If not, then perhaps a solution like I am using it myself in such circumstances would be to avoid calling fl_initialize() at all. I do that by going through the command line arguments first, looking for a certain option (in my case I use '-nw'). If I find that I don't don't call fl_initialize() (or any other functions from XForms), otherwise I pass on the command line arguments unchanged to fl_initialize(). Having a command line argument that tells fl_initialize() that XForms isn't going to be used sounds a bit strange to me. It would be similar to having a function e.g. in the math library to tell it that no function of this library will ever be used. Or am I misunderstanding what you are trying to do? Regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 07:03:03 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 12:03:03 +0100 Subject: [XForms] Migrating from xforms-0.89 Message-ID: <20080313110303.GA9348@toerring.de> To subscribers of the xforms list Hi, > I have a project which still uses xforms 0.89. I would like to > upgrade, but installing > the new versions results in all sorts of error messages when I compile. Do you get errros when you try to compile the new version of the XForms library or when you try to recompile your program using the new version? In the first case I would be very interested to get a list of all messages! If you're using e.g. a bash like shell you could redirect the output of the configure and make command to files by using e.g. ./configure > configlog 2>&1 make > makelog 2>&1 Please be so kind to send me the resulting files. In the second case it also would be helpful to see what you actually get as error messages. It's a long time since I have been using version 0.89, so I probably don't not re- member most of the changes that happened since then. But I guess that the main changes were: a) The forms.h file to be included by your program was in /usr/X11/include/X11/ Nowadays it's per default in /usr/local/include/ You must make sure that the compiler picks up this new file and not accidentally the old one. Perhaps you will need to pass something like '-I/usr/local/include' to the compiler. b) The library itself also seem to have been in /usr/X11/lib/ but nowadays is per default in /usr/local/lib/ You may have to tell the linker by using something like '-L/usr/local/lib'. c) In version 0.89 Pixmaps were handled by some internal functions is XForms. This has changed and XForms now requires the external Xpm library for this, see e.g. http://koala.ilog.fr/lehors/xpm.html This library needs to be installed on your system and you must explicitely link against it (using e.g. the option '-lXpm' when compiling with gcc). I really don't remember what you had to specify as compiler and linker flags when compiling against 0.89. But nowadays I would probably use someting like -I/usr/local/include -L/usr/local/lib -X11 -lforms -lXpm -lm The API itself hasn't experienced too many changes and I can't remember them. If your problems result from them please post the error messages you got, otherwise it's going to be very figure out what's going wrong;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From verkindt at lapp.in2p3.fr Thu Mar 13 04:18:38 2008 From: verkindt at lapp.in2p3.fr (Didier Verkindt) Date: Thu, 13 Mar 2008 09:18:38 +0100 (CET) Subject: [XForms] Using Xform in background without display In-Reply-To: References: <988FAD2E161E4347BFD7EC93A4D05904022F4B69@xcgaz701.northgrum.com> Message-ID: To subscribers of the xforms list Hi, I am very happy to see that Xforms and this mailing list are still alive. I have developped since several years a data visualization application that uses Xforms as GUI. In some circumstances, I would like to run this application in background (producing just jpg files, without user interaction and without showing any xform window) on a machine which has no display. But I get stucked on the fl_initialize function. With the following error message: Can't open display --No such file or directory Missing or failed fl_initialize() For now, I have overcome the problem by using xvfb when starting the application. But could the next release of Xform provide an API or a flag that allows to run temporarily without display? Or could the next release separate in fl_initialize what is specific xform init from what is related to the display? Thank you, Didier ----------------------------------------------------------- Didier VERKINDT, LAPP, Ch. de Bellevue, 74941 Annecy-le-Vieux, FRANCE tel:33(0)450091671 or 5573 fax:33(0)450279495 web:lapp.in2p3.fr/~verkindt _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Mar 18 18:39:15 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 18 Mar 2008 23:39:15 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <1205809811.47df3293b87de@webmail.minx.net.uk> References: <1205809811.47df3293b87de@webmail.minx.net.uk> Message-ID: <20080318223914.GA30325@toerring.de> To subscribers of the xforms list Hello Chris, On Tue, Mar 18, 2008 at 03:10:11AM +0000, chris at evib.net wrote: > I had, just recently, installed Fedora 8 on my laptop to take away for a 3 > week trip. I hadn't tested the 1.0.90 release of XForms under F8 and found > one of my applications refused to display when using: > > fl_set_input(obj, msgstr); > > The 1.0.91 release cures this problem. As much as I would like to claim that for me I don't think I was responsible for this change for the better;-) Actually, Jean-Marc Lasgouttes and Angus Leeming committed quite a number of changes to the CVS version in the last years which I can build on. And I am rather sure that's one of many problems they already did solve! > However, the initialisation code for a grid which uses code as in the > following fragment (modified from the code generated from the form > definition file): > > fdui->cell00 = obj = fl_add_input(FL_INT_INPUT,x=20,y=40,20,20,""); > fl_set_object_color(obj,FL_MCOL,FL_MCOL); > fl_set_object_lalign(obj,FL_ALIGN_CENTER); > fl_set_object_callback(obj,Grid_Input,cell++); > > steadfastly refuses to change the objects colour regardless of what FL_xxxx > colour is used. Later on, the same sort of code is used to change the cell's > appearance and that works! > > fl_set_object_boxtype(obj, FL_FRAME_BOX); > fl_set_input_cursor_visible(obj, FALSE); > fl_set_object_color(obj, FL_GREEN, FL_GREEN); > fl_set_input(obj, msgstr); > > Strange! Definitely! Unfortunately, I can't reproduce this bug here on my machine by just inserting your example code into one of my programs. Perhaps it's something more complicated than just a bug in the func- tion for settineg an objects colors. In that case it might help me to figure out what's going wrong if you could send me a somewhat longer example. BTW: The indentation of your example code looks a bit as if it was generated by an older version of fdesign. Perhaps you still have two versions of fdesign (or all of XForms) installed on your ma- chine, the old one in /usr/bin and the new one in /usr/local/bin. Please try to get rid of the old installation - if there's a mix- ture of an old and a new versions a lot of things could go wrong... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Mar 18 18:39:15 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 18 Mar 2008 23:39:15 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <1205809811.47df3293b87de@webmail.minx.net.uk> References: <1205809811.47df3293b87de@webmail.minx.net.uk> Message-ID: <20080318223914.GA30325@toerring.de> To subscribers of the xforms list Hello Chris, On Tue, Mar 18, 2008 at 03:10:11AM +0000, chris at evib.net wrote: > I had, just recently, installed Fedora 8 on my laptop to take away for a 3 > week trip. I hadn't tested the 1.0.90 release of XForms under F8 and found > one of my applications refused to display when using: > > fl_set_input(obj, msgstr); > > The 1.0.91 release cures this problem. As much as I would like to claim that for me I don't think I was responsible for this change for the better;-) Actually, Jean-Marc Lasgouttes and Angus Leeming committed quite a number of changes to the CVS version in the last years which I can build on. And I am rather sure that's one of many problems they already did solve! > However, the initialisation code for a grid which uses code as in the > following fragment (modified from the code generated from the form > definition file): > > fdui->cell00 = obj = fl_add_input(FL_INT_INPUT,x=20,y=40,20,20,""); > fl_set_object_color(obj,FL_MCOL,FL_MCOL); > fl_set_object_lalign(obj,FL_ALIGN_CENTER); > fl_set_object_callback(obj,Grid_Input,cell++); > > steadfastly refuses to change the objects colour regardless of what FL_xxxx > colour is used. Later on, the same sort of code is used to change the cell's > appearance and that works! > > fl_set_object_boxtype(obj, FL_FRAME_BOX); > fl_set_input_cursor_visible(obj, FALSE); > fl_set_object_color(obj, FL_GREEN, FL_GREEN); > fl_set_input(obj, msgstr); > > Strange! Definitely! Unfortunately, I can't reproduce this bug here on my machine by just inserting your example code into one of my programs. Perhaps it's something more complicated than just a bug in the func- tion for settineg an objects colors. In that case it might help me to figure out what's going wrong if you could send me a somewhat longer example. BTW: The indentation of your example code looks a bit as if it was generated by an older version of fdesign. Perhaps you still have two versions of fdesign (or all of XForms) installed on your ma- chine, the old one in /usr/bin and the new one in /usr/local/bin. Please try to get rid of the old installation - if there's a mix- ture of an old and a new versions a lot of things could go wrong... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From Jean-Marc.Lasgouttes at inria.fr Thu Mar 13 09:03:39 2008 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 13 Mar 2008 14:03:39 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <20080313120921.GA9842@toerring.de> (Jens Thoms Toerring's message of "Thu\, 13 Mar 2008 13\:09\:21 +0100") References: <20080313120921.GA9842@toerring.de> Message-ID: To subscribers of the xforms list Jens Thoms Toerring writes: > (Hello, Dr. Zhao, if you're reading > this: As far as I know you still didn't consent to make also > the existing documentation "open source" and there's only > the PostScript version at the moment. I would be grateful > if you would contact either me or one of the other main- > tainers about this.) There is also an html version. JMarc _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 08:09:21 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 13:09:21 +0100 Subject: [XForms] New XForms release: call for testers Message-ID: <20080313120921.GA9842@toerring.de> To subscribers of the xforms list Hi, > Now the very quick try of the new code shows all the above problems > seem to have gone. Thanks, that's good news! > I will do more extensive usage tests of several xforms-apps I use. > Especially regarding the program crashes on mouse scroll in text > browsers that I suffered from quite a bit. I hope that this problem is gone. I actually could reproduce something that looked like it with the fbrowse demo program, which quite often simply exited when the mouse wheel was used. There was some bug in the button press/relase handling code that made fl_do_forms() return an object in cases were it shouldn't have done so. And since the program only expected fl_do_forms() to return when the program is supposed to end this then exited. Perhaps you experienced the same problem and in that case it shouldn't happen anymore. Otherwise just complain;-) > PS. If the XForms is to be revived, I would vote for the long- > promised, never-done scrolled canvas :) Please don't hold your breath on that (and I personally never made such a promise;-) My main motvation is that I have a rather largish program using XForms and I want it to work correctly without any glitches under all circumstances. So at the moment I am mostly concerned with a consolidation of the code base (and there are still enough potential problems to keep me busy for a while;-) I think that should be the main focus until the long-awaited 1.1 release is out. Another point that I find very important is to get some up to date documentation. (Hello, Dr. Zhao, if you're reading this: As far as I know you still didn't consent to make also the existing documentation "open source" and there's only the PostScript version at the moment. I would be grateful if you would contact either me or one of the other main- tainers about this.) But that definitely shouldn't keep you (or anybody else) from creating new widgets etc.! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From msz at astrouw.edu.pl Wed Mar 12 19:55:53 2008 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Thu, 13 Mar 2008 00:55:53 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <20080312170818.GA13700@toerring.de> References: <20080312170818.GA13700@toerring.de> Message-ID: <20080312235553.GA8465@astrouw.edu.pl> To subscribers of the xforms list Hi XFormers, Great news. I thought the project was dead. I have just been experiencing problems addressed by Jens, ever since I started using machines with newer OSes and X11. I intensively use my image display xforms-application and I noticed that resizing it often resulted in completely messed window. Also, double-click in file selector stopped working altogether (this, however, used to happen sometimes also in old days). Now the very quick try of the new code shows all the above problems seem to have gone. Good job, Jens, thank you. I will do more extensive usage tests of several xforms-apps I use. Especially regarding the program crashes on mouse scroll in text browsers that I suffered from quite a bit. best regards, Michal. PS. If the XForms is to be revived, I would vote for the long-promised, never-done scrolled canvas :) -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND On Wed, Mar 12, 2008 at 06:08:18PM +0100, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hello, > > as promised in my last mail from end of January I have > continued to work on XForms. The most important changes are: > > a) Update of the event handling subsystem, events can't > get lost anymore. > b) Overwork of window resizing - especially noticable > with window managers that update windows while they > are being resized. > c) Code for popups, menus etc. extensively changed, should > now work better and more like we're used to from other > toolkits. Shadows which ever did work cleanly have been > removed. > d) Text browser sliders now should work correctly. > e) Lots of bugs removed that could lead to segmentation > faults, X errors, memory and X resource leaks, missed > redraws, double click selections in file selectors not > always working, programs sometimes unexpectedly exiting > when mouse scroll wheel is used in text browsers etc. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From lab at saao.ac.za Thu Mar 13 03:34:09 2008 From: lab at saao.ac.za (lab at saao.ac.za) Date: Thu, 13 Mar 2008 09:34:09 +0200 Subject: [XForms] Migrating from xforms-0.89 In-Reply-To: <20080312183546.GE10548@toerring.de> References: <20080312170818.GA13700@toerring.de> <20080312183546.GE10548@toerring.de> Message-ID: <20080313093409.taka941s00skgw0s@webmail.saao.ac.za> To subscribers of the xforms list Hi I have a project which still uses xforms 0.89. I would like to upgrade, but installing the new versions results in all sorts of error messages when I compile. Can anyone give me a roadmap of how to migrate? Many thanks Luis Balona ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Wed Mar 12 18:33:00 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Wed, 12 Mar 2008 18:33:00 -0400 Subject: [XForms] New XForms release: call for testers In-Reply-To: <20080312183546.GE10548@toerring.de> References: <20080312170818.GA13700@toerring.de> <20080312183546.GE10548@toerring.de> Message-ID: To subscribers of the xforms list I am just getting started on a relatively large application that will be using XForms; it does dynamic window updates on resize and is fairly X-intensive. So this is may be a great opportunity to test out this new release. I assure you I'll be stress testing it pretty hard (as usual ;), I'll keep you posted. Jason On Wed, Mar 12, 2008 at 2:35 PM, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hello, > > since already a few people asked for it here's a pre- > release you can download directly (without CVS) and which > doesn't require having all the automake tools installed: > > http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre1.tar.gz > > Just unpack, then run configure and make;-) > > > > Best regards, Jens > -- > \ Jens Thoms Toerring ________ jt at toerring.de > \_______________________________ http://toerring.de > _______________________________________________ > To unsubscribe, send any message to > xforms-leave at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 12 14:35:46 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 12 Mar 2008 19:35:46 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <20080312170818.GA13700@toerring.de> References: <20080312170818.GA13700@toerring.de> Message-ID: <20080312183546.GE10548@toerring.de> To subscribers of the xforms list Hello, since already a few people asked for it here's a pre- release you can download directly (without CVS) and which doesn't require having all the automake tools installed: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre1.tar.gz Just unpack, then run configure and make;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 12 13:08:18 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 12 Mar 2008 18:08:18 +0100 Subject: [XForms] New XForms release: call for testers Message-ID: <20080312170818.GA13700@toerring.de> To subscribers of the xforms list Hello, as promised in my last mail from end of January I have continued to work on XForms. The most important changes are: a) Update of the event handling subsystem, events can't get lost anymore. b) Overwork of window resizing - especially noticable with window managers that update windows while they are being resized. c) Code for popups, menus etc. extensively changed, should now work better and more like we're used to from other toolkits. Shadows which ever did work cleanly have been removed. d) Text browser sliders now should work correctly. e) Lots of bugs removed that could lead to segmentation faults, X errors, memory and X resource leaks, missed redraws, double click selections in file selectors not always working, programs sometimes unexpectedly exiting when mouse scroll wheel is used in text browsers etc. I think it would be time to create a new release, 1.0.91, based on this code. But since all these changes haven't been tested except by myself, I am a bit reluctant to do so and thus would like to ask everybody of you with a bit of time to spare to check out the CVS version and play around with it and report results (both positive and negative;-) To do so just download the CVS version with the command: cvs -d:pserver:anonymous at cvs.sv.gnu.org:/sources/xforms co xforms This will create a directory called 'xforms'. First run the the 'autogen.sh' script in this directory and then compile with the usual 'configure' and make commands. If it would be more convenient for you I could also make a pre-release in which case you woudn't have to have cvs and automake installed on your machine. Just tell me;-) Please note if you link your application against the dynamic library: to make it easier to distinguish from the 1.0.90 version the new version is 'libforms.1.1.0' instead of 'libforms.1.0.0', so you can have both installed but then must either set the sym- bolic link 'libforms.so' accordingly or link explicitely against the new version. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Jan 29 10:23:02 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 29 Jan 2008 16:23:02 +0100 Subject: [XForms] XForms development Message-ID: <20080129152302.GA2495@john.toerring.de> To subscribers of the xforms list Hello, while development of XForms has slowed down a bit I hope it's not dead yet. At least I continue to use XForms for some of my projects and I would rather like to keep it that way. For that reason and since there were some bugs I started to work a bit on the source code, mostly to get rid of a few crashes due to Xerrors and some redrawing problems etc. Jean- Marc Lasgouttes has now given me the opportunity by to upload a new version to the CVS on Savannah. You can find a list of the main changes at http://cvs.savannah.nongnu.org/viewvc/xforms/ChangeLog?revision=1.123&root=xforms&view=markup Of course, there is a rather large chance that I broke many things in the process. Moreover, I can only do tests on my PC- type Linux machine since I don't have access to machines with other architectures or operating systems at the moment. There- fore I would really appreciate it if at least some of you would download the newest version and test it. There are also a few additions to some crucial structures like FL_FORM and FL_OBJECT. While no "normal" programs should access those directly, it could be that some do so anyway and get confused by the changes. Thus I would like to hear if this results in any serious problem. Please also note that this is work in progress. There are still some unresolved issues I hope I will be able to address in the next few days. And probably there are a lotof problems I am not even aware of yet, so input from you about stuff that doesn't work correctly (also in older versions and still in the new CVS version), crashes etc. would be very helpful. If you want to do some tests, the steps are relatively simple. To download the CVS version use the command cvs -d:pserver:anonymous at cvs.sv.gnu.org:/sources/xforms co xforms (This, of course, assumes that you have cvs installed on your machine. I will try to come up with a new 1.0.91 version soon that then can be downloaded as an archive from Savannah, but I would like to have a bit more feedback before doing so in order to avoid disappointing too many people;-) Once you have downloaded the CVS sources (which will create a new subdirectory named 'xforms') go into the 'xforms' subdi- rectory and run the 'autogen.sh' script. To do so you need to have a not too old version of 'automake' installed. Once this script is done you can continue in the normal way to compile the library with configure and make, as described in the READ- ME or INSTALL file. Of course, I also would like to hear about problems when the library and the demo programs get compiled. Perhaps the best way to tell me about them would be to redirect the output of the configure and make process into files and send them to me. My email address is in my signature. Best regards, Jens BTW: Does anybody have the email address of Dr. T.C. Zhao so that we can ask him directly about the documentation which, as far as I remember, he hasn't yet made officially open source? -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Nov 24 11:49:34 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 24 Nov 2008 17:49:34 +0100 Subject: [XForms] New release XForms 1.0.91 In-Reply-To: <20081124113542.GA31211@toerring.de> References: <20081122204654.GA2445@toerring.de> <492A160C.4090706@dineamix.ca> <20081124113542.GA31211@toerring.de> Message-ID: <20081124164934.GA11034@toerring.de> To subscribers of the xforms list Hi Serge, On Mon, Nov 24, 2008 at 12:35:42PM +0100, Jens Thoms Toerring wrote: > About the second form you have on the web page: I am not sure where > this comes from. I just see that some objects have a black instead > of a grey background but I don't know what kind of objects that are I just had another look and realized that you wrote that it are choice objects, sorry that I missed that before. So I tried to deactivate all kinds of choice objects (i.e. FL_NORMAL_CHOICE, FL_NORMAL_CHOICE2, FL_DROPLIST_CHOICE) but couldn't reproduce the problem here. Did you anything with them beside deactiva- ting them? Could you perhaps send me a few lines from your pro- gram where you create choice objects and manipulate their pro- perties (it doesn't have to be a full working program, just something that gives me an idea what you're doing with the choice objects)? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Nov 24 06:35:42 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 24 Nov 2008 12:35:42 +0100 Subject: [XForms] New release XForms 1.0.91 In-Reply-To: <492A160C.4090706@dineamix.ca> References: <20081122204654.GA2445@toerring.de> <492A160C.4090706@dineamix.ca> Message-ID: <20081124113542.GA31211@toerring.de> To subscribers of the xforms list Hi Serge, > Compiled the libraries without incident. I recompiled some of the x-apps > using the new static xforms library with some odd results. Since I am > unable to include pictures with this post you can view them at > "www.dineamix.ca/xforms" along with some notes. About the fonts in the menus: there seemed to a general consensus here (at least by those that commented) that the old look of XForms wasn't very nice anymore and that it woud be better to make it look a bit more like more modern GUI toolkits. Thus I changes several things: the default border width of objects has been reduced from 3 to 1 pixel. The font in menus, popups etc. has been switched from bold to normal font. The shadows around menus have been re- moved (they were problematic anyway, they actually bever worked correctly and I didn't see any way how to get it right..). So things look less extreme 3D then they used to (which looked a lot like in the early years of the last decade when everybody was a bit over-enthusiastic about having 3D effects;-) If you want just to have a bold font for the labels for menus and popups I think all you need is to call fl_set_object_lstyle( obj, FL_BOLD_STYLE ); on the objects for the menus. That hopefully should give you back the old look of the first form you have on that webpage. If you also want the old font style (bold italics) in the windows that pop up for menus etc., then you would have to call once fl_setpup_default_fontstyle( FL_BOLDITALIC_STYLE ); before you create the menus (this is an application-wide setting). How to give the windows that pop up for menus etc. a more 3D-ish look I haven't figured out yet, it may require adding a new func- tion. For the "shadows" around them I have no idea at all how to get them right, so I can't make any promises that you'll get them back. About the second form you have on the web page: I am not sure where this comes from. I just see that some objects have a black instead of a grey background but I don't know what kind of objects that are (I tried deactivated menus and choice objects but that didn't do the trick here). It's not unlikely that you fond some bug there but since it's not clear to me what types of objects they are I have no good idea at the moment where to look. > As a note I did not use the new GL or flimage libraries. Maybe I should? > I will try these libraries later once our production compiles have > completed. I can't tell since never tried mixing different versions. On the one hand, the libraries should be independent of each other, but you never know;-) Sorry for the inconveniences, I hope we can resolve these problems real soon! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From serge at dineamix.ca Sun Nov 23 21:48:44 2008 From: serge at dineamix.ca (Serge Bromow) Date: Sun, 23 Nov 2008 21:48:44 -0500 Subject: [XForms] New release XForms 1.0.91 In-Reply-To: <20081122204654.GA2445@toerring.de> References: <20081122204654.GA2445@toerring.de> Message-ID: <492A160C.4090706@dineamix.ca> To subscribers of the xforms list Hi Jens, Compiled the libraries without incident. I recompiled some of the x-apps using the new static xforms library with some odd results. Since I am unable to include pictures with this post you can view them at "www.dineamix.ca/xforms" along with some notes. As a note I did not use the new GL or flimage libraries. Maybe I should? I will try these libraries later once our production compiles have completed. Thanks, Serge Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi everybody, > > as threatend I have uploaded a new release of XForms, 1.0.91. > You can download it from > > http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91.tar.gz > > I hope that this is another step on the rather long-winded road to > the 1.1.0 version and I would like to thank all of you for contri- > buting code and bug fixes, send bug reports or made suggestions! > Very special thanks go to Angus Leeming and Jean-Marc Lasgouttes > who both did a lot of excellent work I then could continue from. > > There are a few cosmetic changes compared to the last pre-release, > mostly to silence a few compiler warnings (gcc 4.3.2 is a bit more > picky than the older version I was using before). I hope that I did > not break anything essential with these minor changes... > > With the new release out I guess we should take a look at what's > needed on the further road to 1.1.0. I have three points that I think > could be interesting: > > a) Make the documentation available in a useful format and work in > the changes that have been made in the code > b) UTF-8 support > c) Support for TrueType fonts > > I guess I will start with a) as soon as possible since I feel that > a library without proper documentation is rather useless. As I al- > ready wrote a few days ago I am still undecided about the format. > I got the suggestion via private email to use a Wiki. While that > looks like a good solution I am a bit concerned where we could host > a Wiki and if there are enough people prepared to make sure it won't > get vandalized. There is also the question if it's possible to get a > nicely printed version out of it (but maybe it's only me that likes > printed documentation nowadays, so that isn't necessarily a relevant > argument). If someone has thoughts about all that please let me know. > > Points b) and c) are from my personal wishlist but I don't know how > relevant they are to others. There probably are a lot of other, more > important points that need some work and I would like to ask you to > discuss them here on the mailing list! > > Another point I am a bit concerned about is the claim made in several > places that XForms works X11 R4, R5 and R6 as well as with operating > systems as OS2, VMS etc. I have no access to machines with X11 R4 or > R5 or OS2 or VMS so I am in no position to determine if these are > still correct. Are there some people out there that can confirm them > or should we better stop making these claims? > > And, of course, there will still be a number of bugs in the new > release. So, please, don't stop sending me bug reports about what- > ever you find not to be working correctly. > > Best regards, Jens > -- Serge Bromow DineAmix Inc. 888 411-6636 Ottawa, Canada. http://www.dineamix.ca IMPORTANT NOTICE: This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify DineAmix Inc. immediately by email at postmaster at dineamix.ca. Thank you. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Nov 22 15:46:54 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 22 Nov 2008 21:46:54 +0100 Subject: [XForms] New release XForms 1.0.91 Message-ID: <20081122204654.GA2445@toerring.de> To subscribers of the xforms list Hi everybody, as threatend I have uploaded a new release of XForms, 1.0.91. You can download it from http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91.tar.gz I hope that this is another step on the rather long-winded road to the 1.1.0 version and I would like to thank all of you for contri- buting code and bug fixes, send bug reports or made suggestions! Very special thanks go to Angus Leeming and Jean-Marc Lasgouttes who both did a lot of excellent work I then could continue from. There are a few cosmetic changes compared to the last pre-release, mostly to silence a few compiler warnings (gcc 4.3.2 is a bit more picky than the older version I was using before). I hope that I did not break anything essential with these minor changes... With the new release out I guess we should take a look at what's needed on the further road to 1.1.0. I have three points that I think could be interesting: a) Make the documentation available in a useful format and work in the changes that have been made in the code b) UTF-8 support c) Support for TrueType fonts I guess I will start with a) as soon as possible since I feel that a library without proper documentation is rather useless. As I al- ready wrote a few days ago I am still undecided about the format. I got the suggestion via private email to use a Wiki. While that looks like a good solution I am a bit concerned where we could host a Wiki and if there are enough people prepared to make sure it won't get vandalized. There is also the question if it's possible to get a nicely printed version out of it (but maybe it's only me that likes printed documentation nowadays, so that isn't necessarily a relevant argument). If someone has thoughts about all that please let me know. Points b) and c) are from my personal wishlist but I don't know how relevant they are to others. There probably are a lot of other, more important points that need some work and I would like to ask you to discuss them here on the mailing list! Another point I am a bit concerned about is the claim made in several places that XForms works X11 R4, R5 and R6 as well as with operating systems as OS2, VMS etc. I have no access to machines with X11 R4 or R5 or OS2 or VMS so I am in no position to determine if these are still correct. Are there some people out there that can confirm them or should we better stop making these claims? And, of course, there will still be a number of bugs in the new release. So, please, don't stop sending me bug reports about what- ever you find not to be working correctly. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Nov 20 16:54:09 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 20 Nov 2008 22:54:09 +0100 Subject: [XForms] Any further tests in the working? Message-ID: <20081120215409.GA23334@toerring.de> To subscribers of the xforms list Hi everybody, since the last pre-release 10 days ago I haven't received a single bug report or information about problems. I wonder if I may take this as a sign that the 14th pre-release looks ok to everyone of you. Or are there some people still planing to do tests but didn't come around to do them? In the first case I would consider making a "real" release out of the pre-release over the next weekend. Therefore I would like to ask those of you still planing to do tests to send me () a short email so that I still wait a bit. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Nov 11 12:03:21 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 11 Nov 2008 18:03:21 +0100 Subject: [XForms] Format for documentation Message-ID: <20081111170321.GA29010@toerring.de> To subscribers of the xforms list Hi again, as I already wrote yesterday I am thinking about converting the existing PDF documentation into a format that we can work on again. Now my question is if you have recommendations for the format to be used. I am most used to the texi format, but I also had a look at docbook. Both seem to be quite fine in the sense that you can create documentation in diverse output formats (HTML, PDF, info etc.) which I think is important. Does anyone of you has good arguments for one or the other or maybe even has a better idea? Regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Nov 10 15:57:31 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 10 Nov 2008 21:57:31 +0100 Subject: [XForms] New pre-release: xforms-1.0.91pre14 Message-ID: <20081110205731.GA20287@toerring.de> To subscribers of the xforms list Hi everybody, here again is a new pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre14.tar.gz There are a number of bug fixes and a new function: a) in the code for drawing clocks a memory overrun was fixed b) in the code for fl_finish() a bug that resulted in trying to remove tooltip windows nore than once got removed c) A mistake in the code to decide which mouse buttons a button reacts to was corrected. d) Rob Carpenter found that the bounding box of objects was not computed correctly, resulting in very slow redraws in certain situations. e) Rob also found that trying to scroll in a browser that doesn't contain any lines resulted in a segmentation fault. f) According to Serge Bromow's suggestion a function was added that allows to figure out if a form's window is iconified. It's called fl_form_is_iconified() and takes a single argu- ment, a pointer to the form. Thanks to everbody who send in bug reports and suggestions! As you can see there aren't that many changes, but then I did not receive too many bug reports;-) I hope that this can be taken as a sign that the code has been stabilized a bit and we can finally have a "real" release. Therefor I would like to ask you to have another good look at the new pre-release and please tell me about all bugs or just issues you find so that they can be cleared up before the final release! One outstanding bug is about compiling XForms on AIX, where it seems to be necessary to run the configure script like this LIBS=-lX11 ./configure --enable-demos Since I don't have access to an AIX machine and really don't understand what's happening there I would again like to ask people with access to AIX to take a look at that or, if pos- sible, give me an account on such a machine for a few days. Aonother question is how to proceed when we've got a new release. I think I will try to start working on the documentation first so that it's at least in a form that it can be changed (at the moment there's only a PostScript version of the last version and that has to be converted somehow to a format that can be edited). One thing I also am interested in a bit is to add the capability to XForms to use TrueType fonts. But that's not something I con- sider extremely important and I am open to all kinds of other and perhaps more important suggestions! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From serge at dineamix.ca Tue Oct 21 14:49:56 2008 From: serge at dineamix.ca (Serge Bromow) Date: Tue, 21 Oct 2008 14:49:56 -0400 Subject: [XForms] XForms min/max events In-Reply-To: <20081019221727.GA27479@toerring.de> References: <20081018152249.GA21149@toerring.de> <48FA9043.6010304@dineamix.ca> <20081019221727.GA27479@toerring.de> Message-ID: <48FE2454.8050003@dineamix.ca> To subscribers of the xforms list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20081021/10f729a2/attachment-0006.html -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sun Oct 19 18:17:27 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 20 Oct 2008 00:17:27 +0200 Subject: [XForms] XForms min/max events In-Reply-To: <48FA9043.6010304@dineamix.ca> References: <20081018152249.GA21149@toerring.de> <48FA9043.6010304@dineamix.ca> Message-ID: <20081019221727.GA27479@toerring.de> To subscribers of the xforms list Hi Serge, nice to have you back on board;-) > My problem was when a user minimized the screen using the window > manager decoration I did not have a way of knowing whether I should > raise the window or not since no variable was set. Hence my need to > trap the iconify action from the window manager. > I tried using the "fl_form_is_visible(form);" call but it always > returns TRUE whether the form is on the display or minimized. Other > attempts proved fruitless. i.e checking "form->visible" and > "form->wm_border" variables. > The problem was resolved by using the "XGetWindowAttributes(fl_display, > win_mini, &xwa);" call. This call fills the xwa structure and one > variable in that structure is "xwa.map_state". This is TRUE if the > window is on the display and FALSE if it is minimized or not on the > current display. A test of this variable after a caller event was all I > needed to know if I should set my variables and raise the window.
The value of "form->visible" or the return value of the function fl_form_s_visible() only get changed by calls of the fl_hide_form() or fl_free_form() function but not by the window getting unmapped when it's iconified (XForms doesn't deal with the Unmap/Map event except by calling XRefreshKeyboardMapping() on a MappingNotify event). So even when the window is in iconified state it's treated as "visible". As you already found out you have to query the window attributes to find out if the window is mapped (but note that the "map_state" value isn't just a boolean, there are three possible values it can have, IsUnmapped (0), IsUnviewable (1) and IsViewable (2), the IsUnviewable value undicating that while the window itself is mapped a parent window is unmapped so it's not really shown on the screen). So the combination of "form->visible" being set to FL_VISIBLE (or the corresponding return value of fl_form_is_visible()) together with XGetWindowAttributes() telling you that the window is not mapped looks like the best indication of the window being in iconified state. Perhaps I should add a function with a name like fl_form_is_iconified() to make it easier to check for this. While the name of the function fl_form_is_visible() is a bit unlucky I wouldn't like to change its behaviour since that might break programs that rely on it to tell you if a form has been hidden by a call of fl_hide_form() etc. or not. Or do you need a callback for a form's window becoming iconified or de- iconified? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From serge at dineamix.ca Sat Oct 18 21:41:23 2008 From: serge at dineamix.ca (Serge Bromow) Date: Sat, 18 Oct 2008 21:41:23 -0400 Subject: [XForms] XForms min/max events In-Reply-To: <20081018152249.GA21149@toerring.de> References: <20081018152249.GA21149@toerring.de> Message-ID: <48FA9043.6010304@dineamix.ca> To subscribers of the xforms list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://cweblog.usuhs.mil/pipermail/xforms/attachments/20081018/d922a7a8/attachment-0007.html -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Oct 18 11:22:49 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 18 Oct 2008 17:22:49 +0200 Subject: [XForms] XForms min/max events Message-ID: <20081018152249.GA21149@toerring.de> To subscribers of the xforms list Hi Serge, I have just seen your question on Savannah concerning min/max events, Please accept my appologies for the long delay - questions are normally asked in the XForms mailing list http://cweblog.usuhs.mil/mailman/listinfo/xforms and the last question coming up on Savannah was that long ago that I don't often check there... > Hi Xforms, > I would like my app to trap window min/max events. I have read > through the docs without success. > Is there a way to set a callback or trap a SIGNAL when these events > occur? I guess with min/max event you mean something that happens only when the minimize/maximize button on the window decorations is clicked on. Please correct me if I am wrong but that's the only thing I can think of at the moment. The problem here is that there's no special event that would distinguish it in any way from any other resizing of the window. The only thing visible from an application is receiving a ConfigureNotify X event that informs the application that the windows size has been changed, but there's nothing that indicates that it's due to the minimize/maximize button in the window deco- rations having been clicked on - that's something only the window manager would know about which takes care of these decorations. At the momement there's not even a mechanism to set a callback for ConfigureNotify events (even via fl_register_raw_callback()), probably since an application normal;y doesn't need to know about that (in case you really need to know that a windows size has changed you typically would simply ask for it's size). But I could add something that allows to install a preemptive handler also for ConfigureNotify events if you think it's really needed. But that still won't tell you if that event is due to a min/max button the window manager may display... I am going to send this reply also to the mailing list so that others can comment if they think my answer is wrong or incom- plete or have a good idea for you. If you don't want to sub- scribe to the mailing list you will be able to see further replies also her http://groups.google.com/group/fa.xforms/topics?lnk Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sun Sep 21 09:56:06 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 21 Sep 2008 15:56:06 +0200 Subject: [XForms] New pre-release 1.0.91pre13 Message-ID: <20080921135606.GA23755@cm.toerring.de> To subscribers of the xforms list Hi everybody, sorry for the long delay since the last pre-release but, un- fortunately, I was rather busy with some other work. But here we go again with number 13: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre13.tar.gz Unfortunately, not all the problems that got reported could be addressed with this version since in some cases I didn't get re- plies about the somewhat more elusive bugs (i.e. the ones I did not manage to reproduce). So they have to be left for the next pre-rlease... Most important changes: a) The placement of windows was dealt with in a somewhat out-fashioned way. Especially the assumption was made that all window managers would reparent the windows for forms within a window with the decorations (i.e. title bar and borders). But that's not the case (e.g. with the default 'metacity' window manager used by Gnome). That led to problems for programs that try to store the position of a window and set this position again when the program is run again. Also setting positions with negative posititons (which indicates that the position is meant relative to the right and/or bottom border of the screen) didn't work properly. b) Bug (my own!) in goodies removed that led to texts on buttons being wrong or missing. c) As J. P. Mellor pointed out inactivated input objects could still be edited. Hopefully corrected. d) Removed a bug pointed out by Werner Heisch that crashed fdesign if the type of an object was changed. e) Bug in fdesign fixed that led to crash when the type of a composite object was changed and then Restore or Cancel was clicked. f) Forgotten removal of tooltip in deletion of object added, could lead to a segmentation fault. There are still one or two bugs on my list but about which I am not sure yet if they are XForms bugs or in the application progams and where I am still looking forward to receiving further informations. And then there's a problem with building XForms on AIX 5.3 where make stops with a crash in fdesign when creating the demo programs. While I got all the logs of the make process I unfortunately wasn't able yet to figure out what needs to be done about it. Problem is that I never used AIX and also have no access to such a machine. So if someone here has either experience with AIX and feels like trying to solve the problem or would be able to temporarily give me an account on such machine for testing please send me an email. And, as usual, please tell me about everything you find that's not working correctly! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jpmellor at rose-hulman.edu Sat Jul 19 13:59:47 2008 From: jpmellor at rose-hulman.edu (J.P. Mellor) Date: Sat, 19 Jul 2008 13:59:47 -0400 Subject: [XForms] deactivating input fields In-Reply-To: <20080719173437.GA7382@toerring.de> References: <18562.4075.540294.306434@mellor.home.rose-hulman.edu> <20080719173437.GA7382@toerring.de> Message-ID: <18562.11155.632026.908072@mellor-wireless.home.rose-hulman.edu> To subscribers of the xforms list I'm using 1.0.91pre9. I ment to include that the first time, but hit send too quickly ;^( Thanks, jp Jens Thoms Toerring writes: > Hello, > > On Sat, Jul 19, 2008 at 12:01:47PM -0400, J.P. Mellor wrote: > > It appears that calling fl_deactivate_object() on an input field has > > no effect. After deactivating the input field, the input can still be > > changed. Is this correct behavior or am I missing something. > > I don't think so;-) and I will investigate what's going wrong > ASAP. Just one question: are using the newest pre-release or > something older? And if you have an example program it would > be nice if you could send it to me. > > Best regards, Jens _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Jul 19 13:34:37 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 19 Jul 2008 19:34:37 +0200 Subject: [XForms] deactivating input fields In-Reply-To: <18562.4075.540294.306434@mellor.home.rose-hulman.edu> References: <18562.4075.540294.306434@mellor.home.rose-hulman.edu> Message-ID: <20080719173437.GA7382@toerring.de> To subscribers of the xforms list Hello, On Sat, Jul 19, 2008 at 12:01:47PM -0400, J.P. Mellor wrote: > It appears that calling fl_deactivate_object() on an input field has > no effect. After deactivating the input field, the input can still be > changed. Is this correct behavior or am I missing something. I don't think so;-) and I will investigate what's going wrong ASAP. Just one question: are using the newest pre-release or something older? And if you have an example program it would be nice if you could send it to me. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jpmellor at rose-hulman.edu Sat Jul 19 12:01:47 2008 From: jpmellor at rose-hulman.edu (J.P. Mellor) Date: Sat, 19 Jul 2008 12:01:47 -0400 Subject: [XForms] deactivating input fields Message-ID: <18562.4075.540294.306434@mellor.home.rose-hulman.edu> To subscribers of the xforms list It appears that calling fl_deactivate_object() on an input field has no effect. After deactivating the input field, the input can still be changed. Is this correct behavior or am I missing something. Thanks, jp _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Aug 30 18:27:49 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 31 Aug 2008 00:27:49 +0200 Subject: [XForms] XForms pre-release 1.0.91pre12 In-Reply-To: <20080802200436.GA28377@toerring.de> References: <20080712210708.GB8226@toerring.de> <20080801121058.GA29748@astrouw.edu.pl> <20080802200436.GA28377@toerring.de> Message-ID: <20080830222748.GB8358@toerring.de> To subscribers of the xforms list Hi Michal, i wrote an email to you some time ago since figuring out what the reasons for the bugs you found is a bit difficult without more detailed information. I hope you don't mind that I write you again since I haven't got a reply yet and my or your mail may have got lost. It would be very helpful if you could send me some (preferably compilable;-) example code that shows the problems since I don't know exactly what you're doing in your program and so trying to write something that reproduces the bugs is nearly impossible. If you are prepared to just send me the program (perhaps with a few example data files) that would be just fine, I hope I will find my way through it. In case my email got lost I append it to this mail. Best regards, Jens On Sat, Aug 02, 2008 at 10:04:36PM +0200, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi Michal, > > On Fri, Aug 01, 2008 at 02:10:58PM +0200, Michal Szymanski wrote: > > To subscribers of the xforms list > > I thought that problem was already gone but no, it is still there, maybe > > in a bit changed form. To remind what happens, a self-quote :) > > > > > It seems that the library (?) is autogenerating some events > > > [...] > > > As I deal with images from a mosaic CCD, my app has a group of 8 buttons > > > with the same callback registered, named "cb_select_mosaic" and > > > different "argument" value, from 0 to 7. When clicked, it normally > > > displays file named "some_prefix.N.fts" where N is 1-8 (callback data > > > argument+1). > > > Now, if I run it as "image o.1.fts", everything seems OK, the image gets > > > displayed and when I click mosaic buttons, it displays other files > > > (o.2.fts etc.) > > > > > > When, however, I run the program as "image o.2.fts" (or any other number > > > 2-8), it displays the file but immediately starts to switch between the > > > given number and #1. Somehow the event gets autogenerated I added a > > > debug printout to "cb_select_mosaic" procedure and it shows: > > > > > > cb_select_mosaic 0 > > > cb_select_mosaic 4 > > > cb_select_mosaic 0 > > > cb_select_mosaic 4 > > > > Now the above is fixed, I guess since "pre6" or so. > > Yes, if I remember correctly it was due to not enough memory having > been allocated for storing all command line arguments... > > > I am getting, however, > > similar behavior when I use another feature of my display app: > > > > When it is invoked with more-than-one filename argument, clicking the > > right button on the "FILE" button should display the image taken from > > the next command invocation argument (without having to go through file > > selector form, bound to left-click on the FLE button). It works *mostly* > > fine, unless I click that button many times without waiting for the > > images to be fully loaded. Then, after a few "proper" displays, the app > > starts to auto-change between some (randomly chosen, but always already > > read) images. This seems to be an infinite loop although it still reacts > > (with some delay) to EXIT button, so the app does not completely go > > astray, it just starts to get auto-generated events. > > > > As always, this could be a bug in my app, in old days, however (I still > > have those older version, compiled with "official" XForms releases), it > > worked fine, no matter how quickly I repeated the mouse clicks. > > I guess it's not going to be easy finding the reason without > some program that exhibits the problem. Would it be possible > that you send me your program (or some example program that > shows the same problem)? > > > > The same image display app > > > has a few keyboard shortcuts working while inside the image canvas which > > > open a new window (form) and display some data in it. I have noticed a > > > strange behavior - when the new window is created, it displays its data > > > OK. Then I move the mouse (still in the image canvas) and press > > > the same key again - > > > it should display the data for the new image position, but it does > > > not. Only when I click a mouse button or leave and enter again the image > > > canvas, the key starts to work. And it works fine (displaying proper > > > data for every mouse position in the canvas) until I close the window. > > > When I open it again, the same situation repeats ("dead" after first > > > opening, then clicking or leaving/entering the canvas, then working > > > fine). This problem occurred even in the "official" releases of > > > xforms in some hard-to-pinpoint combinations of Linux system version, > > > X11 version and architecture. Now, with most machines on which it is > > > used got upgraded to more up-to-date systems (e.g. CentOS 5.1), the > > > problem seems to be persistent. It is probably not connected to 1.0.91 > > > but still, may mark a problem in the library. > > Looks like a bit like an old, still unresolved bug. Again, would it > be possible to send me some example code? I guess that would help me > a lot in figuring out what's broken... > > Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Aug 2 16:04:36 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 2 Aug 2008 22:04:36 +0200 Subject: [XForms] New pre-release 1.0.91pre12 In-Reply-To: <20080801121058.GA29748@astrouw.edu.pl> References: <20080712210708.GB8226@toerring.de> <20080801121058.GA29748@astrouw.edu.pl> Message-ID: <20080802200436.GA28377@toerring.de> To subscribers of the xforms list Hi Michal, On Fri, Aug 01, 2008 at 02:10:58PM +0200, Michal Szymanski wrote: > To subscribers of the xforms list > I thought that problem was already gone but no, it is still there, maybe > in a bit changed form. To remind what happens, a self-quote :) > > > It seems that the library (?) is autogenerating some events > > [...] > > As I deal with images from a mosaic CCD, my app has a group of 8 buttons > > with the same callback registered, named "cb_select_mosaic" and > > different "argument" value, from 0 to 7. When clicked, it normally > > displays file named "some_prefix.N.fts" where N is 1-8 (callback data > > argument+1). > > Now, if I run it as "image o.1.fts", everything seems OK, the image gets > > displayed and when I click mosaic buttons, it displays other files > > (o.2.fts etc.) > > > > When, however, I run the program as "image o.2.fts" (or any other number > > 2-8), it displays the file but immediately starts to switch between the > > given number and #1. Somehow the event gets autogenerated I added a > > debug printout to "cb_select_mosaic" procedure and it shows: > > > > cb_select_mosaic 0 > > cb_select_mosaic 4 > > cb_select_mosaic 0 > > cb_select_mosaic 4 > > Now the above is fixed, I guess since "pre6" or so. Yes, if I remember correctly it was due to not enough memory having been allocated for storing all command line arguments... > I am getting, however, > similar behavior when I use another feature of my display app: > > When it is invoked with more-than-one filename argument, clicking the > right button on the "FILE" button should display the image taken from > the next command invocation argument (without having to go through file > selector form, bound to left-click on the FLE button). It works *mostly* > fine, unless I click that button many times without waiting for the > images to be fully loaded. Then, after a few "proper" displays, the app > starts to auto-change between some (randomly chosen, but always already > read) images. This seems to be an infinite loop although it still reacts > (with some delay) to EXIT button, so the app does not completely go > astray, it just starts to get auto-generated events. > > As always, this could be a bug in my app, in old days, however (I still > have those older version, compiled with "official" XForms releases), it > worked fine, no matter how quickly I repeated the mouse clicks. I guess it's not going to be easy finding the reason without some program that exhibits the problem. Would it be possible that you send me your program (or some example program that shows the same problem)? > > The same image display app > > has a few keyboard shortcuts working while inside the image canvas which > > open a new window (form) and display some data in it. I have noticed a > > strange behavior - when the new window is created, it displays its data > > OK. Then I move the mouse (still in the image canvas) and press > > the same key again - > > it should display the data for the new image position, but it does > > not. Only when I click a mouse button or leave and enter again the image > > canvas, the key starts to work. And it works fine (displaying proper > > data for every mouse position in the canvas) until I close the window. > > When I open it again, the same situation repeats ("dead" after first > > opening, then clicking or leaving/entering the canvas, then working > > fine). This problem occurred even in the "official" releases of > > xforms in some hard-to-pinpoint combinations of Linux system version, > > X11 version and architecture. Now, with most machines on which it is > > used got upgraded to more up-to-date systems (e.g. CentOS 5.1), the > > problem seems to be persistent. It is probably not connected to 1.0.91 > > but still, may mark a problem in the library. Looks like a bit like an old, still unresolved bug. Again, would it be possible to send me some example code? I guess that would help me a lot in figuring out what's broken... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From msz at astrouw.edu.pl Fri Aug 1 08:10:58 2008 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Fri, 1 Aug 2008 14:10:58 +0200 Subject: [XForms] New pre-release 1.0.91pre12 In-Reply-To: <20080712210708.GB8226@toerring.de> References: <20080712210708.GB8226@toerring.de> Message-ID: <20080801121058.GA29748@astrouw.edu.pl> To subscribers of the xforms list Hello, I thought that problem was already gone but no, it is still there, maybe in a bit changed form. To remind what happens, a self-quote :) > It seems that the library (?) is autogenerating some events > [...] > As I deal with images from a mosaic CCD, my app has a group of 8 buttons > with the same callback registered, named "cb_select_mosaic" and > different "argument" value, from 0 to 7. When clicked, it normally > displays file named "some_prefix.N.fts" where N is 1-8 (callback data > argument+1). > Now, if I run it as "image o.1.fts", everything seems OK, the image gets > displayed and when I click mosaic buttons, it displays other files > (o.2.fts etc.) > > When, however, I run the program as "image o.2.fts" (or any other number > 2-8), it displays the file but immediately starts to switch between the > given number and #1. Somehow the event gets autogenerated I added a > debug printout to "cb_select_mosaic" procedure and it shows: > > cb_select_mosaic 0 > cb_select_mosaic 4 > cb_select_mosaic 0 > cb_select_mosaic 4 Now the above is fixed, I guess since "pre6" or so. I am getting, however, similar behavior when I use another feature of my display app: When it is invoked with more-than-one filename argument, clicking the right button on the "FILE" button should display the image taken from the next command invocation argument (without having to go through file selector form, bound to left-click on the FLE button). It works *mostly* fine, unless I click that button many times without waiting for the images to be fully loaded. Then, after a few "proper" displays, the app starts to auto-change between some (randomly chosen, but always already read) images. This seems to be an infinite loop although it still reacts (with some delay) to EXIT button, so the app does not completely go astray, it just starts to get auto-generated events. As always, this could be a bug in my app, in old days, however (I still have those older version, compiled with "official" XForms releases), it worked fine, no matter how quickly I repeated the mouse clicks. Another problem which still annoys me a bit is (another self-quote): > The same image display app > has a few keyboard shortcuts working while inside the image canvas which > open a new window (form) and display some data in it. I have noticed a > strange behavior - when the new window is created, it displays its data > OK. Then I move the mouse (still in the image canvas) and press > the same key again - > it should display the data for the new image position, but it does > not. Only when I click a mouse button or leave and enter again the image > canvas, the key starts to work. And it works fine (displaying proper > data for every mouse position in the canvas) until I close the window. > When I open it again, the same situation repeats ("dead" after first > opening, then clicking or leaving/entering the canvas, then working > fine). This problem occurred even in the "official" releases of > xforms in some hard-to-pinpoint combinations of Linux system version, > X11 version and architecture. Now, with most machines on which it is > used got upgraded to more up-to-date systems (e.g. CentOS 5.1), the > problem seems to be persistent. It is probably not connected to 1.0.91 > but still, may mark a problem in the library. regards, Michal. PS. Thanks again, Jens, for your efforts in reviving and improving the XForms. -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Sat Jul 12 17:20:03 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Sat, 12 Jul 2008 17:20:03 -0400 Subject: [XForms] New pre-release 1.0.91pre12 In-Reply-To: <20080712210708.GB8226@toerring.de> References: <20080712210708.GB8226@toerring.de> Message-ID: To subscribers of the xforms list On Sat, Jul 12, 2008 at 5:07 PM, Jens Thoms Toerring wrote: > h) Rob Carpenter also reported ome problems when using more than a > single GL canvas in a form. Unfortunately I wasn't yet able to > determine if this is XForms or GL related - I simply don't know > anything about GL and it also doesn't seem to work too well on > my test machine. So if somebody has suggestions please send them! What kind of problems? There should be no issues with this -- I have yet to see any major problems with XForms glcanvas implementation (aside from it recreating contexts a bit too often). Speaking of OpenGl, I do have that old OpenGL context sharing patch from a few years ago (maybe late 2003 or early 2004, around the time Fedora Core 1 was released), that we have used without a hitch in every single xforms application we've written since then (and I can assure you, there have been many). It appears to be working very well with no issues. If you want, I can prepare a patch for you and send it. It's a pretty handy feature. Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Jul 12 17:07:08 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 12 Jul 2008 23:07:08 +0200 Subject: [XForms] New pre-release 1.0.91pre12 Message-ID: <20080712210708.GB8226@toerring.de> To subscribers of the xforms list Hello, after quite a bit of feedback - thank you to all involved! - here's another pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre12.tar.gz.sig What's new? a) Update to newer version of libtool since, as Raphael Straub, the maintainer of the MacPorts port of XForms, pointed out, fdesign didn't compile on Mac OS X anymore. b) A bug that under some conditions led to a segmentation fault when freeing forms was found by Luis Balona. c) Rob Carpenter pointed me to a bug in the calculation of the boun- ding box of objects could result in redraws becoming extremely slow. d) Some changes in the code for dealing with popups etc. for getting rid of some drawing artefacts that Luis Balona told me about. Un- fortunately, I am not sure if it works now since I can't reproduce the problem on my test machine... e) Jean-Marc Lasgouttes called to my attention a problem when running configure that made it necessary to add config/mkinstalldirs to the distributed files. f) As Luis Balona noticed selected radio buttons did not receive a callback call when they got clicked on which might break existing programs, so it was reintroduced. g) Jason Cipriani found that there were some inconsitencies and problems when trying to delete menu entries and made some very helpful suggestions how to resolve it. This required a number of changes to the public API (some of the functions now accept an unspecified number of extra arguments, i.e. they are now variadic functions, in addition to the traditional arguments). Hopefully this will not break any existing programs. In programs (and fdesign) now callback functions for individual menu entries can be set and each menu entry can be given a certain value (instead of just using it's index). For a full explanation plese see the fike "New_Features,txt" in the main directory. h) Rob Carpenter also reported ome problems when using more than a single GL canvas in a form. Unfortunately I wasn't yet able to determine if this is XForms or GL related - I simply don't know anything about GL and it also doesn't seem to work too well on my test machine. So if somebody has suggestions please send them! Again thanks to everybody who send bug or suggestions. Please don't hestitate to tell me about anything that still doesn't work! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Fri Jul 4 17:46:47 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Fri, 4 Jul 2008 17:46:47 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: To subscribers of the xforms list On Fri, Jul 4, 2008 at 4:37 PM, Jason Cipriani wrote: > On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: >> To get around that you have to change the file lib/menu.c. >> I append a version for 1.0.90 that hopefully works but I >> didn't test the changes with that version, just my newer >> one. Then add to lib/private/menu.h > > Since this change, the functions fl_set_menu_item_mode and > fl_get_menu_item_mode no longer work unless the menu item's index is > the same as it's value. It doesn't matter if you specify an index or a > value to these functions -- if the two are different, they are > ignored. I suspect that something internally is inappropriately mixing > item indices and values, and had always relied on them being the same. I've found the problem, and a partial solution to it (see below, I've also provided a possible full solution), although I'm not sure if the solution breaks anything. SOLUTION #1: In the new %x handling code in addto_menu, around line 357 there is this bit of code that removes the %x from the string after processing it: else { sp->mval[ n ] = strtol( p + 2, &eptr, 10 ); while ( *eptr && isspace( ( int ) *eptr ) ) eptr++; if ( *eptr ) memmove( p, eptr, strlen( eptr ) + 1 ); else *p = '\0'; } The fix is to not remove the "%x" from the string, changing it to just this: else { sp->mval[ n ] = strtol( p + 2, &eptr, 10 ); } The reason this problem was occurring is because every time you display a menu, it uses the setpup stuff to create a popup menu to display. This popup menu is set up in do_menu around line 111 of menu.c. All of the popup menu functions take item IDs, not indices. When you use %x to modify the menu's ID, this causes sp->mval[n] to hold the ID, and so all of the MENU functions know about the ID. However, since the %x is removed from the string, when the popup is created that corresponds to the menu, the item IDs are not propagated to the popup menu -- therefore the MENU functions know about the item ID but the POPUP functions do not. Leaving the "%x" in the string allows the ID to be passed through fl_addtopup() and then the correct IDs are set in the popup menu, and everything seems to work. SOLUTION #2: The reason the above fix isn't complete is that it only applies when you've used %x to set the IDs. The problem solved by the above solution is related to the new feature of parsing %x in menu strings but is not related to removing menu items. However, removing menu items does cause a problem if you haven't used %x at all that the above solution doesn't fix. If that makes sense. Anyways if you do not use %x then the menu item IDs are, initially, the item indices. If you remove a menu item, then indices change but the IDs do not. However, the IDs in this case are never passed to fl_addtopup at all, and so the POPUP menu uses the item INDICES instead -- which no longer correspond to the IDs since an item was removed. This is related to the problem when using %x in that it's also caused by inconsistency between the item IDs in menu.c and the item IDs in xpopup.c. The root cause of all of these problems is that do_menu does not set the popup menu item IDs to the sp->mval[i] values. All menu ID information is lost in the popup. AFAICT, there is no API call to change popup menu item IDs, and therefore there is no easy way for do_menu() to pass ID information to the popup menu when it sets up the menu with fl_addtopup(). One solution for this is to continue removing the %x strings in addto_menu, just as you are doing now, but when creating the popup menu, create temporary strings with a %x concatenated onto the end of them along with the corresponding ID. Something like this in do_menu around line 111: + char tempstr[512]; + snprintf(tempstr, sizeof(tempstr), "%s%%x%i", sp->items[i], sp->mval[i]); + fl_addtopup(sp->menu, tempstr); - fl_addtopup(sp->menu, sp->items[i]); This works fine but it does change the behavior of some other stuff. Specifically, it causes fl_get_menu to return the item ID and NOT the item index as previous. Meaning that you can just do this: int value = fl_get_menu(menu); Rather than having to do this: int value = fl_get_menu_value(menu, fl_get_menu(menu)); Although that now also means that if you're passing the result of fl_get_menu() to other menu functions, you'll need to convert the value to an index first: int index = fl_get_menu_item_from_value(menu, fl_get_menu(menu)); fl_delete_menu_item(menu, index); /* for example */ It's important to note, though, that the above changes in behavior would ONLY happen if the IDs and values are not the same, which can ONLY happen if you've either used %x to change the IDs, or you've removed a menu item. Therefore I believe using the above solution (constructing a temporary string with a %x on the end) will not significantly affect any existing applications because: 1) We know nobody has been removing menu items, since fl_delete_menu_item didn't work at all. 2) We know nobody has been using %x to set the IDs in regular menus, since it was never supported. 3) The only people who may experience changes in behavior are people that had a previously meaningless "%x" in their menu item text, and now it means something. However, your addto_menu change already affected these people, the tempstr thing above doesn't add any new issues. What do you think about solution #2? Do you see any way it could interact with regular popup menus at all? What about fdesign? Things like that? Incidentally, I've also noticed that, every once in a while, fdesign strips the %x from the end of my menu strings. I am not sure why, or what triggers it. It's happened to me twice out of about 15 saves so far, though. Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Fri Jul 4 16:46:45 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Fri, 4 Jul 2008 16:46:45 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: To subscribers of the xforms list On Fri, Jul 4, 2008 at 4:37 PM, Jason Cipriani wrote: > On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: >> To get around that you have to change the file lib/menu.c. >> I append a version for 1.0.90 that hopefully works but I >> didn't test the changes with that version, just my newer >> one. Then add to lib/private/menu.h > > I've done some more testing with this and uncovered a problem that I > am about to dig in to a little more. Unrelated to this issue, I think, in menu.c in the function fl_set_menu_item_mode (around line 505 for me), there is a bit of code that reads: if ((mode & FL_PUP_CHECK)) sp->val = numb; Should that be this instead? if ((mode & FL_PUP_CHECK)) sp->val = sp->mval[numb]; Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Fri Jul 4 16:37:54 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Fri, 4 Jul 2008 16:37:54 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080704105748.GA26035@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: To subscribers of the xforms list -------------- next part -------------- On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: > To get around that you have to change the file lib/menu.c. > I append a version for 1.0.90 that hopefully works but I > didn't test the changes with that version, just my newer > one. Then add to lib/private/menu.h I've done some more testing with this and uncovered a problem that I am about to dig in to a little more. Since this change, the functions fl_set_menu_item_mode and fl_get_menu_item_mode no longer work unless the menu item's index is the same as it's value. It doesn't matter if you specify an index or a value to these functions -- if the two are different, they are ignored. I suspect that something internally is inappropriately mixing item indices and values, and had always relied on them being the same. I've attached another test program that demonstrates this. The menu (click on the word menu) items values are 5, 2, and 9 respectively. Click the checkboxes then click on the menu. The checkboxes to disable menu items only work for "green", where both the index and the value are 2. Maybe you have some insight, I'm also going to look through the code right now. Thanks, Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: deleteitem3.tar.gz Type: application/x-gzip Size: 1533 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20080704/66471058/attachment-0006.gz -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat Jul 5 08:04:46 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 5 Jul 2008 14:04:46 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080704175052.GA20513@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> <20080704175052.GA20513@toerring.de> Message-ID: <20080705120446.GB6123@toerring.de> To subscribers of the xforms list Hi Jason, On Fri, Jul 04, 2008 at 05:46:47PM -0400, Jason Cipriani wrote: > On Fri, Jul 4, 2008 at 4:37 PM, Jason Cipriani wrote: > > On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: > >> To get around that you have to change the file lib/menu.c. > >> I append a version for 1.0.90 that hopefully works but I > >> didn't test the changes with that version, just my newer > >> one. Then add to lib/private/menu.h > > > > Since this change, the functions fl_set_menu_item_mode and > > fl_get_menu_item_mode no longer work unless the menu item's index is > > the same as it's value. It doesn't matter if you specify an index or a > > value to these functions -- if the two are different, they are > > ignored. I suspect that something internally is inappropriately mixing > > item indices and values, and had always relied on them being the same. > > I've found the problem, and a partial solution to it (see below, I've > also provided a possible full solution), although I'm not sure if the > solution breaks anything. > > SOLUTION #1: > > In the new %x handling code in addto_menu, around line 357 there is > this bit of code that removes the %x from the string after processing > it: > > else > { > sp->mval[ n ] = strtol( p + 2, &eptr, 10 ); > while ( *eptr && isspace( ( int ) *eptr ) ) > eptr++; > if ( *eptr ) > memmove( p, eptr, strlen( eptr ) + 1 ); > else > *p = '\0'; > } > > The fix is to not remove the "%x" from the string, changing it to just this: > > else > { > sp->mval[ n ] = strtol( p + 2, &eptr, 10 ); > } > > The reason this problem was occurring is because every time you > display a menu, it uses the setpup stuff to create a popup menu to > display. This popup menu is set up in do_menu around line 111 of > menu.c. All of the popup menu functions take item IDs, not indices. > When you use %x to modify the menu's ID, this causes sp->mval[n] to > hold the ID, and so all of the MENU functions know about the ID. > However, since the %x is removed from the string, when the popup is > created that corresponds to the menu, the item IDs are not propagated > to the popup menu -- therefore the MENU functions know about the item > ID but the POPUP functions do not. Leaving the "%x" in the string > allows the ID to be passed through fl_addtopup() and then the correct > IDs are set in the popup menu, and everything seems to work. > > SOLUTION #2: > > The reason the above fix isn't complete is that it only applies when > you've used %x to set the IDs. The problem solved by the above > solution is related to the new feature of parsing %x in menu strings > but is not related to removing menu items. However, removing menu > items does cause a problem if you haven't used %x at all that the > above solution doesn't fix. If that makes sense. > > Anyways if you do not use %x then the menu item IDs are, initially, > the item indices. If you remove a menu item, then indices change but > the IDs do not. However, the IDs in this case are never passed to > fl_addtopup at all, and so the POPUP menu uses the item INDICES > instead -- which no longer correspond to the IDs since an item was > removed. This is related to the problem when using %x in that it's > also caused by inconsistency between the item IDs in menu.c and the > item IDs in xpopup.c. > > The root cause of all of these problems is that do_menu does not set > the popup menu item IDs to the sp->mval[i] values. All menu ID > information is lost in the popup. AFAICT, there is no API call to > change popup menu item IDs, and therefore there is no easy way for > do_menu() to pass ID information to the popup menu when it sets up the > menu with fl_addtopup(). > > One solution for this is to continue removing the %x strings in > addto_menu, just as you are doing now, but when creating the popup > menu, create temporary strings with a %x concatenated onto the end of > them along with the corresponding ID. Something like this in do_menu > around line 111: > > + char tempstr[512]; > + snprintf(tempstr, sizeof(tempstr), "%s%%x%i", sp->items[i], sp->mval[i]); > + fl_addtopup(sp->menu, tempstr); > - fl_addtopup(sp->menu, sp->items[i]); > > This works fine but it does change the behavior of some other stuff. > Specifically, it causes fl_get_menu to return the item ID and NOT the > item index as previous. Meaning that you can just do this: > > int value = fl_get_menu(menu); > > Rather than having to do this: > > int value = fl_get_menu_value(menu, fl_get_menu(menu)); > > Although that now also means that if you're passing the result of > fl_get_menu() to other menu functions, you'll need to convert the > value to an index first: > > int index = fl_get_menu_item_from_value(menu, fl_get_menu(menu)); > fl_delete_menu_item(menu, index); /* for example */ > > It's important to note, though, that the above changes in behavior > would ONLY happen if the IDs and values are not the same, which can > ONLY happen if you've either used %x to change the IDs, or you've > removed a menu item. Therefore I believe using the above solution > (constructing a temporary string with a %x on the end) will not > significantly affect any existing applications because: > > 1) We know nobody has been removing menu items, since > fl_delete_menu_item didn't work at all. It did work, but only for menus created with fl_addto_menu(), not for thise created with fl_set_menu_entries(). > 2) We know nobody has been using %x to set the IDs in regular menus, > since it was never supported. It's even documented as not to work. > 3) The only people who may experience changes in behavior are people > that had a previously meaningless "%x" in their menu item text, and > now it means something. However, your addto_menu change already > affected these people, the tempstr thing above doesn't add any new > issues. > > What do you think about solution #2? Do you see any way it could > interact with regular popup menus at all? What about fdesign? Things > like that? I think all your ideas are very reasonable and #2 is the way I will implement it in the new version. Thanks for doing my work;-) That means: a) A menu ID can be associated with a certain menu item using "%xn" in the string for the text of the menu item. Note that 'n' must be a number larger than 0. b) If no menu ID is assigned explicitely it gets its ID from a counter that is incremented for each menu item added (start- ing from 1). This number is never re-used, even when menu items get deleted. The only exception is that on a call of fl_clear_menu() also the counter gets reset to 1. c) fl_get_menu() now returns the menu ID d) To all functions expecting an item number the ID must now be passed. e) If two menu items receive the same ID the results are un- specified, so the user must make sure that this never happens. f) If a menu item gets delete via fl_delete_menu_item() all other items keep their numbers, even if no menu IDs have been set for them. That is how things work for normal popups and it probably wouldn't be a good idea to do it differently for menus. The only deviations are for the case that menu items get deleted, which can't be done for popups. That also means that both the functions fl_get_menu_value() and fl_get_menu_item_from_value() can disappear again (or the latter go back to being a local only function). Does anybody see any problems with this approach? What I will also try to implement is having a callback function for each menu item. For menus created with the fl_set_menu_entries() function you can already do that, so it looks reasonable to me also to have that ability for all menus. I think I will allow a "%f" in the menu string and change the functions fl_set_menu(), fl_adddto_menu() and fl_replace_menu_item() to be variadic functions (that should introduce compatibilty problems) so that pointers to functions of type FL_PUP_CB can be passed on. Finally, I will have another look if it's possible to get rid of the asymmetry between menus created with calls of fl_addto_menu() and those created by a single call of fl_set_menu_entries(). Having them behave differently in several respects doesn't look too good to me (and the differences at least need to be documen- ted). Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Fri Jul 4 13:50:52 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 4 Jul 2008 19:50:52 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: <20080704175052.GA20513@toerring.de> To subscribers of the xforms list Hi Jason, > One problem that I found is fl_delete_menu_item refers to the item > index, not the value. This can make deleting items pretty tricky. To > that end I've added a function to go the other way, from value to > item. It works for me although I may have missed some things I don't think so. Your's is basically a new version of the already existing (but only local to menu.c) val_to_index() function;-) > (specifically, I'm not sure if the ISPUP thing is right -- and also, If the menu gets created with the fl_set_menu_entries() function instead of as many calls of fl_addto_menu() as there are items the menu is just a normal popup (from which no items can be removed and where no values can be assigned differing from the index etc.) and in this case ISPUP() returns true. So your use is exactly right. > is the item index really 1-based?), Yes. Probably the original author got bored with hunting for bugs due to a mising subtraction of 1 or the corres- ponding addition in the right places. My preference would be anyway to use always 0 based arrays, also in the puplic interface, but I guess it's much too late for doing any- thing about that now... > I tried to make it the inverse of > fl_get_menu_value. Note that if multiple items have the same value, > this returns the first item with that value. Returns -1 if value is > not found. Yes, that's the problem with the values - they get set by the user, so it can't be made sure that they are unique. > === menu.c === > > int > fl_get_menu_item_from_value( FL_OBJECT * ob, > int value ) I will add the function to the new release. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Fri Jul 4 13:25:31 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Fri, 4 Jul 2008 13:25:31 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080704105748.GA26035@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> <20080704105748.GA26035@toerring.de> Message-ID: To subscribers of the xforms list On Fri, Jul 4, 2008 at 6:57 AM, Jens Thoms Toerring wrote: > To get around that you have to change the file lib/menu.c. > I append a version for 1.0.90 that hopefully works but I > didn't test the changes with that version, just my newer > one. Then add to lib/private/menu.h Thanks a lot for digging into this. I've tested your changes and so far everything seems to be working well, I can remove items and use fl_get_menu_value to get the correct ID. > This should give you a new function named fl_get_menu_value() > that expects the menu object and the item index as returned > by fl_get_menu(). If you now create the menu items in fdesign > with texts like One problem that I found is fl_delete_menu_item refers to the item index, not the value. This can make deleting items pretty tricky. To that end I've added a function to go the other way, from value to item. It works for me although I may have missed some things (specifically, I'm not sure if the ISPUP thing is right -- and also, is the item index really 1-based?), I tried to make it the inverse of fl_get_menu_value. Note that if multiple items have the same value, this returns the first item with that value. Returns -1 if value is not found. === menu.c === int fl_get_menu_item_from_value( FL_OBJECT * ob, int value ) { FL_MENU_SPEC *sp = ob->spec; int item; if( ISPUP( sp ) ) return value; for( item = 1; item <= sp->numitems; ++ item ) if (sp->mval[item] == value) return item; return -1; } === menu.h === FL_EXPORT int fl_get_menu_item_from_value( FL_OBJECT * ob, int value ); Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Fri Jul 4 06:57:48 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 4 Jul 2008 12:57:48 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> Message-ID: <20080704105748.GA26035@toerring.de> To subscribers of the xforms list -------------- next part -------------- Hi Jason, On Thu, Jul 03, 2008 at 07:21:01PM -0400, Jason Cipriani wrote: > On Thu, Jul 3, 2008 at 7:05 PM, Jens Thoms Toerring wrote: > > It looks as if the stuff for removing a menu item is badly > > broken already in 1.0.0. I guess nobody ever has tried to use > > it, so it went unnoticed for all those years. I will try to > > come up with a fix that also works for 1.0.90 or 1.0.0 (tell > > me what you are using) but since it's getting a bit late here > > 1.0.90, with some unrelated custom patches to opengl stuff. Here's some good and some bad news: If you want to create a menu with fdesign were you can delete items then you must switch off the "Use Struct" button in the "Spec" tab field for the menus attributes. In that case the menu gets initia- lized via several calls of the function fl_addto_menu() in- stead of a single call of fl_set_menu_entries(). That looks like a minor detail, but internally a rather different type of menu gets created which allows deletion of items. Now the bad news: Deleting an item will change the numbers returned for the items following it, i.e. the number of the selected item is always the (1 based) index of the item in the menu. So you will have to work with comparing the text of the item that you can get with fl_get_menu_item_text(). To get around that you have to change the file lib/menu.c. I append a version for 1.0.90 that hopefully works but I didn't test the changes with that version, just my newer one. Then add to lib/private/menu.h FL_EXPORT int fl_get_menu_value( FL_OBJECT * ob, int item ); and recompile. This should give you a new function named fl_get_menu_value() that expects the menu object and the item index as returned by fl_get_menu(). If you now create the menu items in fdesign with texts like red%x1 green%x2 blue%x3 (the "%xn" stuff will not be shown in the menu with the new version of menu.c) then the new function will return the number following the "%x" and this number does not change after deleting an item. Sorry for all this complexities but the whole stuff for hand- ling menus/popups/choices is rather convoluted and IMHO not very well designed. I guess a complete rewrite (but which then will probably also require changes of the public API) would be the best solution... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de -------------- next part -------------- A non-text attachment was scrubbed... Name: menu.c Type: text/x-csrc Size: 14618 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20080704/bc78de63/attachment-0006.bin -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 19:21:01 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 19:21:01 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080703230528.GA27176@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> <20080703230528.GA27176@toerring.de> Message-ID: To subscribers of the xforms list On Thu, Jul 3, 2008 at 7:05 PM, Jens Thoms Toerring wrote: > It looks as if the stuff for removing a menu item is badly > broken already in 1.0.0. I guess nobody ever has tried to use > it, so it went unnoticed for all those years. I will try to > come up with a fix that also works for 1.0.90 or 1.0.0 (tell > me what you are using) but since it's getting a bit late here 1.0.90, with some unrelated custom patches to opengl stuff. > where I'm living I guess I better get a bit of sleep before I > make a complete mess out of it. I hope you will get something > tomorrow morning (when it is morning in yor time zone that is;-) > but I don't know at the moment how complicated it's going to > be, so please don't hold your breath until then;-) It's no big deal. And, in general, I'm in a perpetual state of breath-holding anyways. If I uncover anything interesting I'll let you know. Thanks, Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Jul 3 19:05:28 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 4 Jul 2008 01:05:28 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> Message-ID: <20080703230528.GA27176@toerring.de> To subscribers of the xforms list Hi Jason, On Thu, Jul 03, 2008 at 06:35:53PM -0400, Jason Cipriani wrote: > Attached is a test program I've created. Thanks, that confirms my own observations... > The form has a single menu with 3 items, 3 buttons to remove each > item, and a button to clear the entire menu (as a sanity check). > > Clearing the menu works properly. Attempting to remove items does not > work at all. > > There's not a way to hide/show individual items, is there? I couldn't > find anything looking through the documentation. If there is, that > would work as a workaround for now. It looks as if the stuff for removing a menu item is badly broken already in 1.0.0. I guess nobody ever has tried to use it, so it went unnoticed for all those years. I will try to come up with a fix that also works for 1.0.90 or 1.0.0 (tell me what you are using) but since it's getting a bit late here where I'm living I guess I better get a bit of sleep before I make a complete mess out of it. I hope you will get something tomorrow morning (when it is morning in yor time zone that is;-) but I don't know at the moment how complicated it's going to be, so please don't hold your breath until then;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 18:35:53 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 18:35:53 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080703221048.GA23177@toerring.de> References: <20080703214526.GC21371@toerring.de> <20080703221048.GA23177@toerring.de> Message-ID: To subscribers of the xforms list -------------- next part -------------- On Thu, Jul 3, 2008 at 6:10 PM, Jens Thoms Toerring wrote: > I am also just looking into this and trying to come up with > an expample program. If you have one at hand just send it to > me - I wouldn't be too surprised if there still are some bugs > lurking;-) Attached is a test program I've created. The form has a single menu with 3 items, 3 buttons to remove each item, and a button to clear the entire menu (as a sanity check). Clearing the menu works properly. Attempting to remove items does not work at all. There's not a way to hide/show individual items, is there? I couldn't find anything looking through the documentation. If there is, that would work as a workaround for now. Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: deleteitem.tar.gz Type: application/x-gzip Size: 1250 bytes Desc: not available Url : http://cweblog.usuhs.mil/pipermail/xforms/attachments/20080703/62690ac5/attachment-0006.gz -------------- next part -------------- _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Jul 3 18:10:49 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 4 Jul 2008 00:10:49 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: <20080703214526.GC21371@toerring.de> Message-ID: <20080703221048.GA23177@toerring.de> To subscribers of the xforms list Hi Jason, On Thu, Jul 03, 2008 at 06:01:28PM -0400, Jason Cipriani wrote: > Oh, right. Now that I think about it, not only do I remember reading > that, but I am actually using %x for other menu items elsewhere in > this very same application. I've been staring at the screen too long. > :-S I'm still having trouble getting fl_delete_menu_item to work at > all but I suspect it's something silly as well. I am also just looking into this and trying to come up with an expample program. If you have one at hand just send it to me - I wouldn't be too surprised if there still are some bugs lurking;-) best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 18:01:28 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 18:01:28 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: <20080703214526.GC21371@toerring.de> References: <20080703214526.GC21371@toerring.de> Message-ID: To subscribers of the xforms list On Thu, Jul 3, 2008 at 5:45 PM, Jens Thoms Toerring wrote: > The value that is returned is actually not necessary identical > to the index of the entry, the structure for an entry has a > member for storing the value to be returned. The index of the > item is just the defalt value set at creation. But you can over- > ride this value at creation of the menu, see "%xn" at the end of > page 201 of the PostScript documentation for 0.89, all that's > required is that it's positive (but I don't know off-hand if 0 > is regarded as positive). Oh, right. Now that I think about it, not only do I remember reading that, but I am actually using %x for other menu items elsewhere in this very same application. I've been staring at the screen too long. :-S I'm still having trouble getting fl_delete_menu_item to work at all but I suspect it's something silly as well. Thanks for looking into it, and the quick reply, Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Jul 3 17:45:26 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 3 Jul 2008 23:45:26 +0200 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: Message-ID: <20080703214526.GC21371@toerring.de> To subscribers of the xforms list Hi Jason, On Thu, Jul 03, 2008 at 04:53:23PM -0400, Jason Cipriani wrote: > Let's say I have a menu with these items, created in fdesign: > > 1. Red > 2. Green > 3. Blue > > So the IDs (returned by fl_get_menu) are 1, 2, and 3. > > If I use fl_delete_menu_item() to remove the second item (id = 2), > then I've observed that the IDs of the other menu items do NOT change, > leaving the menu like this: > > 1. Red > 3. Blue > > This is convenient and is what I want to happen, I was pleasantly > surprised when I noticed it. However, I was always under the (possibly > incorrect) impression that menu item IDs *always* corresponded to the > index of the item (so Blue would have been changed to 2 rather than > remaining as 3). > > Is this ("Blue" keeping it's ID of 3) a bug that coincidently worked > out well for me? Or is this intentional behavior that I can rely on in > the future? No, I don't think it's a convenient bug but intended that way. The value that is returned is actually not necessary identical to the index of the entry, the structure for an entry has a member for storing the value to be returned. The index of the item is just the defalt value set at creation. But you can over- ride this value at creation of the menu, see "%xn" at the end of page 201 of the PostScript documentation for 0.89, all that's required is that it's positive (but I don't know off-hand if 0 is regarded as positive). So I guess you can rely on the beha- viour and should cry "BUG" if you find it behaves differently;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 17:25:44 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 17:25:44 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). In-Reply-To: References: Message-ID: To subscribers of the xforms list On Thu, Jul 3, 2008 at 4:53 PM, Jason Cipriani wrote: > If I use fl_delete_menu_item() to remove the second item (id = 2), > then I've observed that the IDs of the other menu items do NOT change, > leaving the menu like this: I take this back, I seem to have grossly misinterpreted what I was seeing. In fact, fl_delete_menu_item() appears to do nothing at all. If I create a menu with 5 items in fdesign, say it's named "TheMenu", and then attempt to delete one of the items: fl_delete_menu_item(TheForm->TheMenu, 2); It seems that nothing happens at all. No items are deleted. The menu remains unmodified. Is there some other function I need to call to "apply" whatever changes fl_delete_menu_item makes? Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 16:53:23 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 16:53:23 -0400 Subject: [XForms] Question #2: Relying on menu subitem IDs after fl_delete_menu_item(). Message-ID: To subscribers of the xforms list Let's say I have a menu with these items, created in fdesign: 1. Red 2. Green 3. Blue So the IDs (returned by fl_get_menu) are 1, 2, and 3. If I use fl_delete_menu_item() to remove the second item (id = 2), then I've observed that the IDs of the other menu items do NOT change, leaving the menu like this: 1. Red 3. Blue This is convenient and is what I want to happen, I was pleasantly surprised when I noticed it. However, I was always under the (possibly incorrect) impression that menu item IDs *always* corresponded to the index of the item (so Blue would have been changed to 2 rather than remaining as 3). Is this ("Blue" keeping it's ID of 3) a bug that coincidently worked out well for me? Or is this intentional behavior that I can rely on in the future? Thanks, Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Thu Jul 3 16:41:17 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Thu, 3 Jul 2008 16:41:17 -0400 Subject: [XForms] Hiding menu items. Message-ID: To subscribers of the xforms list Quick question: How do I hide/show an item in a PULLDOWN_MENU? Thanks, Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Jun 23 20:44:31 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 24 Jun 2008 02:44:31 +0200 Subject: [geomview-users] XForms - new release pending Message-ID: <20080624004431.GA23017@toerring.de> Hello, I have seen that at least some of the plugins for Geomview are using XForms. I have become one of the maintainers of XForms and in the last months have made a number of changes to it, mostly trying to remove bugs and making it more stable. Now I am considering to release a new version and I am trying to get as much feedback as possible about outstanding pro- blems as well as about the ones I may have introduced in the process of working on XForms. I would be really grateful if those of you that wrote or maintain plugins based on XForms would be prepared to test it against the newest pre-release of the library http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre11.tar.gz and tell me about everything you deem to be not working cor- rectly. Please note that there were also some changes to the default graphics settings (like border widths etc.) that were made to make XForms look a bit more "modern" but that may in- fluence the look of the plugins if you are using these default settings. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ geomview-users mailing list geomview-users at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geomview-users From jt at toerring.de Mon Jun 23 18:01:12 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 24 Jun 2008 00:01:12 +0200 Subject: [XForms] New pre-release 1.0.91pre11 In-Reply-To: <20080623212413.GA16829@toerring.de> References: <20080623212413.GA16829@toerring.de> Message-ID: <20080623220112.GA22140@toerring.de> To subscribers of the xforms list Hi, On Mon, Jun 23, 2008 at 11:24:13PM +0200, Jens Thoms Toerring wrote: > a) Thanks to Werner Heise sending me lots of test programs I Sorry, that should have been Werner Heisch, not Heise. I hope he isn't too annoyed, at least I got his name mixed up with that of the publisher of what are probably the best computer magazines in Germany... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Jun 23 17:24:13 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 23 Jun 2008 23:24:13 +0200 Subject: [XForms] New pre-release 1.0.91pre11 Message-ID: <20080623212413.GA16829@toerring.de> To subscribers of the xforms list Hello, there's a further pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre11.tar.gz As usual here's a list of changes: a) Thanks to Werner Heise sending me lots of test programs I was able to track down a bug in the drawing of pixmaps - clippng wasn't set corectly, so under some circumstances pixmaps would be drawn over objects that were on top of the pixmap. b) The same problem existed also for bitmaps. c) Bitmap buttons now also behave like normal buttons, just with a bitmap drawn of top of it. The foreground color of the bitmap is the same as the label color (and never changes). At the moment I have no outstanding bug reports left and am seriously considering making this pre-release the "official" new 1.0.91 release. Therefore I would like to ask everyone with a bit of time to spend to download the pre-release and test it. I'd rather like to have a release that hasn't some ugly bugs left that should have been found before! It's that long since the last oficial release that some days spent fi- xing still existing bugs won't make much of a difference;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Jun 17 09:39:35 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 17 Jun 2008 15:39:35 +0200 Subject: [XForms] New pre-release 1.0.91pre10 Message-ID: <20080617133935.GA22614@toerring.de> To subscribers of the xforms list Hello, it was rather a long time since the last pre-release, but now there's a new one: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre10.tar.gz Again, due to my somewhat restricted time at the moment not too many changes have been made: a) The whole way pixmap buttons got drawn was a bit of a mess. I think that they should just behave like any other "normal" button with the only difference that a pixmap gets drawn on top of it (which may get exchanged when the button gets or loses the focus, i.e. the mouse gets moved on top of it or off the button). That's the way its supposed to work now - the drawing routine for normal button is also used for drawing pixmap buttons and when it's done the pixmap gets drawn on top of it. b) Another small cleanup of the code for redarwing objects that are in parts obscured by another object has been made. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat May 31 16:07:03 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 31 May 2008 22:07:03 +0200 Subject: [XForms] New pre-release 1.0.91pre9 In-Reply-To: <20080524145233.GA27966@toerring.de> References: <20080524145233.GA27966@toerring.de> Message-ID: <20080531200702.GA4837@toerring.de> To subscribers of the xforms list Hello, there's a new pre-release is available for testing: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre9.tar.gz Not too much has changed compared to the last one: a) Werner Heisch did observe that partially transparent pixmaps weren't displayed correctly anymore in 1.0.91pre8. He also pointed out that the behaviour of pixmap buttons wasn't what was described in the documentation (already in 1.0.90). If there was a focus pixmap (to be shown instead of the original pixmap while the mouse was on top of the button) it was also shown (and did stay shown) when the button was pressed. b) In the code I introduced to make sure "lower" objects don't get drawn above "higher" objects there was a bug in the de- tection if two objects overlap. That led to a lot of useless redraws of other objects when an object got redrawn. That's it for today. Please tell me when you find more bugs! Otherwise I guess there won't be another pre-release next but a real new release;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sat May 24 10:52:33 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sat, 24 May 2008 16:52:33 +0200 Subject: [XForms] New pre-release 1.0.91pre8 Message-ID: <20080524145233.GA27966@toerring.de> To subscribers of the xforms list Hello, here we go again with another pre-release: http://download.savannah.gnu.org/releases/xforms/xforms-1.0.91pre8.tar.gz What's new? a) Menus and choice object now use normal fonts instead of bold or even bold and italic fonts - they looked much too fat with the reduced border widths. I also made the default background color a tiny bit lighter. b) Alert and message goodies: removed upper limits on the strings that can be passed to them. There's also a new function, called void fl_show_alert2( int c, const char * fmt, ... ) that takes an int (indicating if the alert box is centered on the screen) and a printf()-like format string, followed by as many more aguments as there are format specifiers in the format string. c) Another new function is int fl_get_decoration_sizes( FL_FORM * form, int * top, int * right, int * bottom, int * left ); that you can call with a form and which then returns the widths of the decorations the window manager put around the form window in the four other variables. It returns 0 on success and 1 if it failed. It can fail e.g. because the form is currently not shown on the screen or because it's a form embedded in another form, e.g. as part of a tabfolder. d) When there were overlapping objects and the "lower" object was redrawn the "upper" object did appear to be under the "lower" object. This bug, pointed out by Werner Heisch, has hopefully been removed. e) It could happen that parts of a pixmap got drawn outside of the object it belonged to either because it was larger that the objects bounding box or because its alignment was set to outside. This part of the pixmap then didn't get hidden when the object was hidden. This has now been changed so that only the part that fits into the objects bounding box will get drawn and, when setting the pixmap's alignment an FL_ALIGN_INSIDE is implied. This deviates a bit from the manal where you can read: "Note that although you can place a pixmap outside of the bounding box, it probably is "not a good idea". So the "not so good idea" is now forbidden. In older versions also the additional margins around a pixmap (per default 3 pixels) weren't always correctly drawn if the pixmap wasn't smaller than the objects bounding box. f) Further bugs taken care of: hiding canvases and re-showing tabfolders didn't work correctly (as Rob Carpenter pointed out this led to parts of fdesign not working correctly any- more). Memory access to already deallocated memory in code for handling child objects removed. A few redrawing problems concerning boxes, pointed out by Andrea Scopece, were cleaned up. g) Added a file named 'New_Features.txt' in the main directory with more complete documentation of new functions and other changes. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon May 5 19:54:45 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 6 May 2008 01:54:45 +0200 Subject: [XForms] New pre-release 1.0.91pre7 In-Reply-To: <200805052243.24066.andrea.scopece@tiscali.it> References: <20080505144936.GA23102@toerring.de> <200805052243.24066.andrea.scopece@tiscali.it> Message-ID: <20080505235444.GB5415@toerring.de> To subscribers of the xforms list Hello, On Mon, May 05, 2008 at 10:43:23PM +0200, Andrea Scopece wrote: > My feel is that the library cointain a bit of support for > platform that really are not used anymore. > To cleanup the things there is the need at least to know > what are the platform currently used... > Programmer and Users please: report back some info to list! Yes, that is an issue that needs taken care of in several respects. E.g. on the Savannah project page it's claimed that It should work under X11 R4, R5 & R6. Now I don't know who still got a R4 or R5 release of X11. I definitely don't (and that for years), so I can't test how far this claim is for real. Concerning support for different operating systems at least there don't seem to be those kinds of claims. I guess that OS2 and Windows NT are not really supported anymore. But I have no idea if WIN32 (whatever exactly this is meant to be) works at all - I don't use Windows, so I can't check. And concerning rather old versions of different UNIX flavors there's a similar situation. VMS is another candidate... > > There are quite a number of corner cases, i.e. functions that > > are in but that have never been documented. It's > > difficult to decide what to do in these cases: since the func- > > tion never have "officially" become part of the API one could > > argue that they should be taken out but, on the other hand, > > some existing programs might be using them by now anyway... > > Jens, please could you please list who are that funcs/features ? To be honest, while that's a good question I can't really answer it in detail. I went through the lib/flinternal.h file and the ones below lib/private and grep'ed which functions actually exist at all, which of those were also declared in and in many cases checked against the documentation. But I didn't make any notes on that, so I can't give you a list, sorry... I als haven't gone through all the files below lib/include that make up , but I would take bets that there are also many declarations for functions that just don't exist anymore and quite a number that (at least to my feelings) shouldn't be part of the public API and also haven't been documented as beeing part of the API... > > l) All cases where alert box pops up when there's an internal error > > (most likely due to the caller of a public function not passing > > the correct types of arguments) have been changed to print a > > message to stderr only - I don't think it's proper for a library > > to bother the end user with stuff popping up suddenly with some > > error messages they rather have no idea what they are meant for. > > And actually the whole error handling part of the library is in > > for a rewrite... > I vote for dropping all popups, and returning error by return value, > debug info should be outputted only if requested (cmd line -debug) > and only from functions of the API. There shouldn't be any pop-ups anymore, just error messages going to stderr by default (but that can be redirected to a file or /dev/null or dealt with in other ways by redefining things with fl_set_error_handler()). > Internal errors should/need to be debugged before releasing > the library. Yes, for sure. But all, shit happens;-) And then the library is still not in the state I would like it to be in where errors like improper arguments passed to API functions would get caught in time and wouldn't in turn make internal functions barf. That is something to aim for, but we're definitely not there yet... > > I guess there have been enough new developments by now to permit a > > "real" new release (not 1.1.0 yet but 1.0.91). I also got a bit of > > a feeling that not too much testing is going on (for the last pre- > > releases I have not got much feedback except by two or three people), > > so it may not make much sense to wait any longer - a "real" release > > may stir things up a bit since it could also be noticed by those not > > on the mailing list. Does anyone care to comment? > > My idea, because XForms appear right now like a costant work in progress, > with no real stable-release, is to start a completely new branch (say > 2.0-unstable) and start a rewriting from scratch, collecting the > functionality required, dropping those not used, and implementing > new features. Rewriting things from scratch is a very attractive idea. In principle count me in on that. But (isn't there always a but?) that's going to take a lot of time and work and "old" programs depending on the current version of the XForms API should keep working (my own included;-) and I also guess that's what being a "maintainer" entails. For this reason I may seem to be a bit conservative, but at the moment my primary goals don't go too far beyond getting things to work correctly (I hope may views of that "wrok correctly don't deviate too much from those of others) - that's what I hope I will be able to handle. When I first took a look at the code my reaction was similar to yours, i.e. "get rid of all the old cruft and redo it in a reasonable way", but then I realized what amount of code there is that I don't feel that a "rewrite from scratch" aproach will bear fruits for quite some time. And, on the other hand, in order to attract enough people to get involved for a rewrite (like you perhaps?) I think it could be an advantage to have some- thing that works so that the project doesn't just look like mere vaporware. On a personal note, I had some time to spend on something in- teresting in the last few months since I hadn't had a regular job, but this will probably (and my bank account says "hope- fully";-) change soon. And then I fear I will have to spend more time on other (hopefully also interesting;-) things and less on debugging or even rewriting XForms. What I convinced of is that XForms needs some work-over to have a future at all. There are other toolkits that can be used in- stead and they will be used if there are no new developments to make it attractive again to use and hopefully thus get more people involved. Ok, is there anbody out there on this mailing list that would like to chime in with his/her views? It's not as we would be overwhelmed by the amount of traffic at the moment. I guess Bob's (thanks to him for keeping the mailing list running!) server is going to be able to cope with a bit more;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon May 5 10:49:36 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Mon, 5 May 2008 16:49:36 +0200 Subject: [XForms] New pre-release 1.0.91pre7 Message-ID: <20080505144936.GA23102@toerring.de> To subscribers of the xforms list Hello everybody, not that you get the idea that I have been totally lazy, sitting in the sun and twiddling my thumbs the last days ;-) here's one more pre-release: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91pre7.tar.gz And as usual here's the list of the things that got changed. A lot of this is due to Andrea Scopece, who just joined the mailing list and not only pointed out quite a number of problems but also send in patches! a) The '-flversion' option didn't work. Now hopefully it does. b) There was a bug that resulted in a segmentation fault of the main demo program. c) Resizing of scrollbars works again, but with a twist: verti- cal scrollbars get resized per defaulu in y-direction only, while horizontal ones in x-direction. I guess that's what most people would expect. d) The version information output by the library now contains all information, not only the first three lines. e) Jumping from one input field to another with and Shift- now works correctly and for all types of input fields, including multi-line input fields (that before did nothing on s at all). f) Date input fields handle verification of leap years correctly. g) Hiding a form that contains a canvas doesn't result in an XError anymore when the canvas hasn't been unmapped before. h) When a file selector has a callback installed the field for manually entering a file name isn't shown anymore - that field could not be used anyway. i) Message boxes created by fl_show_message() and fl_show_messages() now can display an unlimited amout of text and they automatically get a size so that the whole text fits in. Moreover, there's a new function fl_show_msg(), that takes a printf()-like format string and then an unspecified number of arguments (as amny as there are format specifiers in the format string). j) Removed limits on numbers of forms, objects and groups fdesign can deal with. Moreover, the browser for groups is now a multi- browser as it looks it should have been from the start. k) Spring cleaning: I started trying to distingish more clearly between things in the library that belong to the published API and those used only internally. Therefor I went through the lib/flinternals.h and lib/private/*.h files, removing function declarations that are also in or those for functions that don't exist anymore and renaming functions and macros not belonging to the public API to start with 'fli_' or 'FLI_' in- stead of 'fl_' and 'FL_'. There are quite a number of corner cases, i.e. functions that are in but that have never been documented. It's difficult to decide what to do in these cases: since the func- tion never have "officially" become part of the API one could argue that they should be taken out but, on the other hand, some existing programs might be using them by now anyway... l) All cases where alert box pops up when there's an internal error (most likely due to the caller of a public function not passing the correct types of arguments) have been changed to print a message to stderr only - I don't think it's proper for a library to bother the end user with stuff popping up suddenly with some error messages they rather have no idea what they are meant for. And actually the whole error handling part of the library is in for a rewrite... I guess there have been enough new developments by now to permit a "real" new release (not 1.1.0 yet but 1.0.91). I also got a bit of a feeling that not too much testing is going on (for the last pre- releases I have not got much feedback except by two or three people), so it may not make much sense to wait any longer - a "real" release may stir things up a bit since it could also be noticed by those not on the mailing list. Does anyone care to comment? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Apr 28 19:54:48 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 29 Apr 2008 01:54:48 +0200 Subject: [XForms] Posting not received: xforms do not compile cleanly on aix 5.3 Message-ID: <20080428235448.GA1750@toerring.de> To subscribers of the xforms list Hello, I just found out that our mailing list is mirrored at http://groups.google.com/group/fa.xforms/ And there's a posting from April 23rd which I didn't receive with the subject line Xforms do not compile cleanly on aix 5.3 Unortunately, I can't reply directly to the author ("Max") without signing in to Google (which I don't want to) nor do I get the authors email address. But I would need some more information to be able to figure out what's going on. So if anybody has an idea how to contact the author please let me know. Best regards, Jens PS: The next pre-release will hopefully come out soon. If you can't wait download the CVS version;-) -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sun Apr 20 09:28:10 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 20 Apr 2008 15:28:10 +0200 Subject: [XForms] New pre-release 1.0.91pre6 Message-ID: <20080420132809.GA11455@toerring.de> To subscribers of the xforms list Hello, I guess it's again time for a new pre-release: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91pre6.tar.gz The most important changes are: a) Since the 0.89 version on calling fl_initialize() the locale for the program was set to the default locale on the machine the pro- gram was running on. Unfortunately, this was never documented and led to trouble in several cases (e.g. because the programs stopped to read in floating point numbers with a decimal point using scanf() etc. when run on a machine with e.g. a French or German default locale setting since there a comma is expected instead). Already some years ago there was a discussion if this should be undone but never got removed. Since I feel that setting the locale behind the users back is a bad idea (perhaps also because figuring out the resulting problems took me a lot of time some years ago when switching to 0.89;-) I now removed it. I hope it doesn't break any existing programs, otherwise please let me know. b) Peter Galbraith pointed out a problem when compiling fdesign and told me what needed changing. It hopefully now works again. c) The C output files created by fdesign included "forms.h" instead of . Fixed. d) A few bugs in the code for the file selectors, buttons and sliders were corrected. e) The formbrowsers scrollbars weren't set reasonably when the form it belongs to was resized. And something I already changed in the last pre-release but forgot to mention: When calling fl_check_forms() or fl_check_forms_only() (which is recommended to be done when doing time intensive calcu- lations from time to time to have the program still react to user interactions) the program was put to sleep for at least 10 ms. This seeemed to me to be a rather long time and I thus reduced it to 1 ms. I haven't seen any adverse effects but please tellme if you do. As usual I would be delighted to get bug reports (and also confirmations that things work as expected). Please note that I may not be able to react to emails immediately during the next week, but don't let that keep you from sending me your comments. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Sun Apr 13 06:22:50 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Sun, 13 Apr 2008 12:22:50 +0200 Subject: [XForms] Tweak needed to build pre-test In-Reply-To: <19621.1208046530@mixed.dyndns.org> References: <19621.1208046530@mixed.dyndns.org> Message-ID: <20080413102250.GA9889@toerring.de> To subscribers of the xforms list Hello Peter, On Sat, Apr 12, 2008 at 08:28:50PM -0400, Peter Galbraith wrote: > I just downloaded the pre-test tar ball and found this small issue: > > In fdesign/fd > > $ grep forms.h * | grep include > > pallette.c:#include "forms.h" > ui_attrib.c:#include "forms.h" > ui_objs.c:#include "forms.h" > ui_theforms.c:#include "forms.h" > > To get a clean build, this should be: > > #include "include/forms.h" > > The same goes for these files in fd/spec : > > browser_spec.c > button_spec.c > choice_spec.c > counter_spec.c > dial_spec.c > freeobj_spec.c > free_spec.c > menu_spec.c > pixmap_spec.c > positioner_spec.c > scrollbar_spec.c > slider_spec.c > twheel_spec.c > xyplot_spec.c Thank you very much for pointing that out! It seemed to built cleanly on my machine (looks like the compiler somehow finds it here without the "include/" in front of it) but I had no- ticed that something strange was going on with "make install", but which I had not understood yet. And that missing "include/" it was! Since I now had a closer look I also realized that for "normal" cases, i.e. when you convert a *.fd file that belongs to a regular project (and not to XForms itself) it should be #include and not #include "include/forms.h" as it used to be. I will add the changes to the CVS version and, of course, it's going into the next pre-release. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From p.galbraith at globetrotter.net Sat Apr 12 20:28:50 2008 From: p.galbraith at globetrotter.net (Peter Galbraith) Date: Sat, 12 Apr 2008 20:28:50 -0400 Subject: [XForms] Tweak needed to build pre-test Message-ID: <19621.1208046530@mixed.dyndns.org> To subscribers of the xforms list Hi, I just downloaded the pre-test tar ball and found this small issue: In fdesign/fd $ grep forms.h * | grep include pallette.c:#include "forms.h" ui_attrib.c:#include "forms.h" ui_objs.c:#include "forms.h" ui_theforms.c:#include "forms.h" To get a clean build, this should be: #include "include/forms.h" The same goes for these files in fd/spec : browser_spec.c button_spec.c choice_spec.c counter_spec.c dial_spec.c freeobj_spec.c free_spec.c menu_spec.c pixmap_spec.c positioner_spec.c scrollbar_spec.c slider_spec.c twheel_spec.c xyplot_spec.c Thanks, -- Peter S. Galbraith GPG key 1024/D2A913A1 - 97CE 866F F579 96EE 6E68 8170 35FF 799E 6623'rd GNU/Linux user at the Counter - http://counter.li.org/ _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Apr 9 21:27:27 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 10 Apr 2008 03:27:27 +0200 Subject: [XForms] New pre-release 1.0.91pre5 Message-ID: <20080410012726.GA9940@toerring.de> To subscribers of the xforms list Hello everybody, I guess it's about time for a new pre-release, so here you go: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91pre5.tar.gz Again, there aren't any dramatic changes. Due to some very constructive criticism by Michal Szymanski I undid some of the changes I made: a) I had made buttons only react to the left mouse button. My idea behind this was to make XForms' behaviour more similar to that of other toolkits with this. But it breaks some existing programs and therefore it's probably better to implement it differently. Per default buttons now again react to each and every mouse button (including the scroll wheel) as it used to be. But to make it possible to change that I added a new function void fl_set_button_mouse_buttons( FL_OBJECT * obj, int mb ) The first argument is a pointer to the button object and the second determines which mouse buttons the button object will react to. It's the inclusive OR of ( 1 << ( FL_MBUTTONx - 1 ) ) where the 'x' in 'FL_MBUTTONx' is a number between 1 and 5, with 1 for the left, 2 for the middle and 3 for the right mouse button. 4 stands for rotating the scroll wheel up and 5 for down. For each of the bits set in 'mb' the button will react to clicks of the corresponding mouse button. Of course, there's also the 'reverse' function that lets you determine which mouse buttons a button reacts to, going by the name of int fl_set_button_mouse_buttons( FL_OBJECT * obj ) The return value has the same meaning as the 'mb' value you pass to the other function. b) The behaviour of the buttons can also be set via fdesign. If you look at the attributes of a button. When you select the button and press 'F1' and then click on the "Spec" tab rider you are able to select which mouse buttons the button will react to. The '.fd' files now contain for buttons that aren't set to the default behaviour (all mouse buttons work) an extra line, starting with 'mbuttons:' and followed by an integer with the value of 'mb' for the button. c) Luckily the older fdesign versions don't seem to mind the extra line for buttons starting with 'mbuttons:'. But to make it easier to compile applications that are sensitive to these changes I added a new option to fdesign: '-xforms-version'. This writes the version of the library fdesign was linked against to stderr in a form like FORMS Library Version 1.0.91pre5 d) Also making one of a group of radio buttons "active" automatically wasn't such a great idea as I had imagined. So I simply removed this, reverting back to the original behaviour. e) Michal Szymanski also found out that if you started an appli- cation with a lot of options the program did crash with a segmentation fault in fl_initialize(). It looks as if this was due to not enough memory getting allocated for the copy of the command line arguments done in a function invoked by fl_initialize(). f) I removed the limitation on both the number of symbols that can be created (formerly 16) and the length of their names (formerly 15 characters). g) I got a bit further in my quest to free all memory allocated by the library at least on fl_finish() - all memory allocated for tabfolders now (hopefully) gets released. h) Finally - shame on my - there was a bug I introduced that re- sulted in a program hanging when a menu entry contained a '%'. Best regards and happy testing, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 27 10:41:35 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 27 Mar 2008 15:41:35 +0100 Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: References: <20080326205031.GA631@toerring.de> Message-ID: <20080327144135.GE30263@toerring.de> To subscribers of the xforms list Hello, On Thu, Mar 27, 2008 at 09:22:15AM +0100, Didier Verkindt wrote: > Concerning your last proposal, I fully support it. Fine;-) I now realized that this behaviour was already in the older versions and only got broken due to my own stupidness. It's working correctly again in the CVS version and will so in the next pre-release - or should that become the next re- lease? Since I didn't get much reports if things are working or not I am not sure how to procede... > Less important but it could be useful: is it possible to add > a new type of slider where the resolution can be chosen directly > from an input field associated to it? Please accept my appologies, but at the moment I still have my hands full with trying to understand and, as far as necessary, correct the code so that I wouldn't like to make any promises I probably would have to break anyway;-) But it might be useful to have a kind of a wish-list: there's already the scrolled canvas Michal Szymanski asked for and now your slider with an editable field for the resolution... BTW, do you know that the slider moves slower when you keep the left mouse button down? I changed that part of the code quite a bit and hope that it works more conveniemtly now. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 27 16:19:20 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 27 Mar 2008 21:19:20 +0100 Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: <20080327135652.GA10730@astrouw.edu.pl> References: <20080326205031.GA631@toerring.de> <20080327135652.GA10730@astrouw.edu.pl> Message-ID: <20080327201920.GB27529@toerring.de> To subscribers of the xforms list Hi Michal, On Thu, Mar 27, 2008 at 02:56:52PM +0100, Michal Szymanski wrote: > I have an application for displaying FITS images, using canvas. > While the mouse pointer is in the image canvas, its coordinates should > be printed in the main app window, both at rest and while moving. I hope I found the solution to the problem (I actually don't really understand yet why it works since I just put back in a line I had removed because it didn't make sense to me). You can download the newest version of lib/forms.c (where the bug were) from the CVS repository at Savannah. Or would it be more convenient if I make a new release out of it? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 27 15:17:46 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 27 Mar 2008 20:17:46 +0100 Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: <20080327135652.GA10730@astrouw.edu.pl> References: <20080326205031.GA631@toerring.de> <20080327135652.GA10730@astrouw.edu.pl> Message-ID: <20080327191745.GA27529@toerring.de> To subscribers of the xforms list Hi Michal, On Thu, Mar 27, 2008 at 02:56:52PM +0100, Michal Szymanski wrote: > There is a problem with events servicing, apparently introduced in the > latest (pre3, or pre2, I did not check the pre2) version. > > I have an application for displaying FITS images, using canvas. > While the mouse pointer is in the image canvas, its coordinates should > be printed in the main app window, both at rest and while moving. > > It has always been working fine, including the first 1.0.91 version > provided by Jens. With the "pre3" version, it does not work. When the > mouse enters the canvas, a single position is printed but then it does > not change when the mouse moves around, unless I click the button or > leave the canvas and enter again. Even then I get only single position > printed. The code did not change at all so it must be something inside > the library. > > The excerpt from the code follows. Thank you for the very precise description of the problem! I will try to figure out what's going wrong immediately and notify you when I hope to have solved it. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From msz at astrouw.edu.pl Thu Mar 27 09:56:52 2008 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Thu, 27 Mar 2008 14:56:52 +0100 Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: References: <20080326205031.GA631@toerring.de> Message-ID: <20080327135652.GA10730@astrouw.edu.pl> To subscribers of the xforms list Hi XFormers, There is a problem with events servicing, apparently introduced in the latest (pre3, or pre2, I did not check the pre2) version. I have an application for displaying FITS images, using canvas. While the mouse pointer is in the image canvas, its coordinates should be printed in the main app window, both at rest and while moving. It has always been working fine, including the first 1.0.91 version provided by Jens. With the "pre3" version, it does not work. When the mouse enters the canvas, a single position is printed but then it does not change when the mouse moves around, unless I click the button or leave the canvas and enter again. Even then I get only single position printed. The code did not change at all so it must be something inside the library. The excerpt from the code follows. any ideas? regards, Michal. -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND ------------------------------------------------------------------ int im_canvas_motion(FL_OBJECT *ob, Window win, int ww, int hh, XEvent *ev, void *d) { FD_image *ui = d; int X, Y, x, y, w ,h; double pixval; if ( pixbuf == NULL ) return 0; mouse_xlib_x = ev->xmotion.x; mouse_xlib_y = ev->xmotion.y; xy_xlib2image(mouse_xlib_x, mouse_xlib_y, &X, &Y); sprintf(position,"%4d %4d", X, Y); fl_set_object_label(ui->position, position); /* cut */ } The handler is registered when application starts, with: void init_canvas(FD_image *fdui) { FL_OBJECT *canvas; canvas = fdui->canvas; fl_add_canvas_handler(canvas, MotionNotify, im_canvas_motion, fdui); /* cut (other handlers) */ } _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From verkindt at lapp.in2p3.fr Thu Mar 27 04:22:15 2008 From: verkindt at lapp.in2p3.fr (Didier Verkindt) Date: Thu, 27 Mar 2008 09:22:15 +0100 (CET) Subject: [XForms] New pre-release 1.0.91pre3 In-Reply-To: <20080326205031.GA631@toerring.de> References: <20080326205031.GA631@toerring.de> Message-ID: To subscribers of the xforms list Hello, Thanks for all this xform revival work! Concerning your last proposal, I fully support it. Less important but it could be useful: is it possible to add a new type of slider where the resolution can be chosen directly from an input field associated to it? Cheers, Didier ----------------------------------------------------------- Didier VERKINDT, LAPP, Ch. de Bellevue, 74941 Annecy-le-Vieux, FRANCE tel:33(0)450091671 or 5573 fax:33(0)450279495 web:lapp.in2p3.fr/~verkindt On Wed, 26 Mar 2008, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hello, > > having a few holidays with rather ugly weather allowed me > to continue so, again, here's something new to play with: > > http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre3.tar.gz > > The most important changes are: > > a) Input objects now lose the focus (and report changes back > to the program) on clicks of other objects that accept a > click with the mouse (buttons, sliders, etc.). This gets > around the problem that if you had an input field, edited > something in there (without hitting the ENTER or TAB key) > and then clicked on some button that's supposed to make > use of what just had got entered into the input field, the > function fl_get_input() still returned the unchanged value > since the input field never lost its focus and thus didn't > accept the changes you made. > > If you move the mouse out of a window with an active input > object and move it into another window keyboard input now > goes to the new window instead of to the one you left. > > Further restructuring of the event handling code. Same > code is now used in xpopup.c and forms.c for dealing > with idling. > > b) Memory gets deallocated also for all objects on call of the > functions fl_free_form() and fl_finish(). I would very much > like to come to a point where XForms doesn't leak memory > anymore - but that's not done yet, at least tabfolders still > pose a problem... > > The code from the file lib/be.c (a kind of primitive garbage > collection) isn't used anymore, it didn't really do what I > guess it was intended to do (and then only when an idle > callback was installed). > > c) Timeouts should be a bit more precise now and not expire > too early anymore (as it's promised in the manual). > > d) Silders (and thus scrollbars) got a rework and some minor > annoyances hopefully have gone. > > e) If available sigaction() is now used instead of signal() > for signal handlers. > > f) Code emitted by fdesign doesn't use fl_calloc() anymore > but instead fl_malloc() (somebody reported to have had a > bit of a problem with that and it didn't make any sense > to zero out the memory anyway). > > I have also another proposal. At the moment the action asso- > ciated with a button gets executed the moment you press down the > left mouse button. Most other toolkits do it differently - the > action only gets executed when the left mouse button is released. > I prefer that behaviour quite a lot since it's then still possible > to move the mouse (with the button still pressed down) away from > the button and release the mouse button only then, thus avoiding > the action coupled to clicking onto the button. This has a few > times saved the day for me when I carelessly clicked somewhere > and only in the very last moment realised that this was a rather > stupid idea... As far as I can see all button types (except touch > buttons for obvious reasons) could be made to work that way. What > do you think? > Best regards, Jens > -- > \ Jens Thoms Toerring ________ jt at toerring.de > \_______________________________ http://toerring.de > _______________________________________________ > To unsubscribe, send any message to > xforms-leave at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 26 16:50:31 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 26 Mar 2008 21:50:31 +0100 Subject: [XForms] New pre-release 1.0.91pre3 Message-ID: <20080326205031.GA631@toerring.de> To subscribers of the xforms list Hello, having a few holidays with rather ugly weather allowed me to continue so, again, here's something new to play with: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre3.tar.gz The most important changes are: a) Input objects now lose the focus (and report changes back to the program) on clicks of other objects that accept a click with the mouse (buttons, sliders, etc.). This gets around the problem that if you had an input field, edited something in there (without hitting the ENTER or TAB key) and then clicked on some button that's supposed to make use of what just had got entered into the input field, the function fl_get_input() still returned the unchanged value since the input field never lost its focus and thus didn't accept the changes you made. If you move the mouse out of a window with an active input object and move it into another window keyboard input now goes to the new window instead of to the one you left. Further restructuring of the event handling code. Same code is now used in xpopup.c and forms.c for dealing with idling. b) Memory gets deallocated also for all objects on call of the functions fl_free_form() and fl_finish(). I would very much like to come to a point where XForms doesn't leak memory anymore - but that's not done yet, at least tabfolders still pose a problem... The code from the file lib/be.c (a kind of primitive garbage collection) isn't used anymore, it didn't really do what I guess it was intended to do (and then only when an idle callback was installed). c) Timeouts should be a bit more precise now and not expire too early anymore (as it's promised in the manual). d) Silders (and thus scrollbars) got a rework and some minor annoyances hopefully have gone. e) If available sigaction() is now used instead of signal() for signal handlers. f) Code emitted by fdesign doesn't use fl_calloc() anymore but instead fl_malloc() (somebody reported to have had a bit of a problem with that and it didn't make any sense to zero out the memory anyway). I have also another proposal. At the moment the action asso- ciated with a button gets executed the moment you press down the left mouse button. Most other toolkits do it differently - the action only gets executed when the left mouse button is released. I prefer that behaviour quite a lot since it's then still possible to move the mouse (with the button still pressed down) away from the button and release the mouse button only then, thus avoiding the action coupled to clicking onto the button. This has a few times saved the day for me when I carelessly clicked somewhere and only in the very last moment realised that this was a rather stupid idea... As far as I can see all button types (except touch buttons for obvious reasons) could be made to work that way. What do you think? Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Mon Mar 31 19:19:12 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 1 Apr 2008 01:19:12 +0200 Subject: [XForms] New pre-release 1.0.91pre4 In-Reply-To: <20080320023426.GA19850@toerring.de> References: <20080320023426.GA19850@toerring.de> Message-ID: <20080331231912.GA11721@toerring.de> To subscribers of the xforms list Hello everybody, since I am not going to have much time this week (and may not even be able to react to emails until the weekend) I decided to come up with a new pre-release with the last bug corrections, bugs I have to admit I introduced myself. They concern the way buttons react and the problem Michal Szymanski pointed out, i.e. not getting events for mouse movements in a canvas. Even though there's nothing really new I guess it's simpler for those that want to do tests to have a "proper" pre-release instead of fishing the changed files out of the CVS repository. The archive to download is http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91pre4.tar.gz As usual, comments, feedback about things that don't work etc. will be much appreciated! And example code that shows the problems will get an even warmer reception;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From Jean-Marc.Lasgouttes at inria.fr Thu Mar 20 05:50:36 2008 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 20 Mar 2008 10:50:36 +0100 Subject: [XForms] Update: 1.0.91pre2 In-Reply-To: <20080320023426.GA19850@toerring.de> (Jens Thoms Toerring's message of "Thu\, 20 Mar 2008 03\:34\:26 +0100") References: <20080320023426.GA19850@toerring.de> Message-ID: To subscribers of the xforms list Jens Thoms Toerring writes: > To subscribers of the xforms list > > Hello again, > > I just found that I didn't realize that some part of fdesign > was broken, which resulted in the demo programs not being created > when compiling from the downloaded pre-release. I hope I now fixed > this bug and that everything compiles cleanly with the new version > I just uploaded. Sorry for the inconvenience... Remember to update the NEWS file eventually. In particular, all changes to the API should be documented in a central place (I thought we had such a file, but cannot find it now). JMarc _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 19 22:34:26 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 20 Mar 2008 03:34:26 +0100 Subject: [XForms] Update: 1.0.91pre2 Message-ID: <20080320023426.GA19850@toerring.de> To subscribers of the xforms list Hello again, I just found that I didn't realize that some part of fdesign was broken, which resulted in the demo programs not being created when compiling from the downloaded pre-release. I hope I now fixed this bug and that everything compiles cleanly with the new version I just uploaded. Sorry for the inconvenience... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 19 17:20:42 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 19 Mar 2008 22:20:42 +0100 Subject: [XForms] New pre-release 1.0.91pre2 Message-ID: <20080319212042.GA21255@toerring.de> To subscribers of the xforms list Hello, I couldn't keep from messing around with the XForms code and made some more changes that concern some sensitive internals which need extensive testing. Therefor I have made up a second pre-release for the coming (hopefully soon;-) 1.0.91 release. It can be downloaded friom http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre2.tar.gz The most important changes are: a) Further cleanup of the central event handling code in lib/forms.c. There was quite a bit of cruft that was so complicated that I hadn't dared to touch it before. This also required changes in the handling of button, choice counter and slider/scrollbar objects etc. To me it looks now as if everythings works fine, but it wouldn't be the first time I would have missed rather obvious bugs... b) Repaired a bug (probably my own) in the code for choice objects. Mouse wheel can now be used to walk through the items of a choice object without having to open the opup window. c) Menus now get highlighted when the mouse is moved on top of them, indicating to the user that something will happen if s/he clicks the mouse. I never did like the titles on the popups of menus and thus added a function fl_set_menu_notitle() that takes two arguments, the menu object and a boolean value to switch the title off (when called with a non-zero value) or on. For FL_PUSH_MENU objects with the no_title flag being set his has the following consequence: they only get opened when the mouse button has been released and they appear just below the menu button, just like FL_PULLDOWN_MENU objects. See the left hand menu in the menu demo program for an example. There were also some inconsitency with the handler that may be associated with a menu is invoked: in some situations it was invoked only when the selected menu item had changed, in others when just an item had been selected (even the same as the one already selected. This has been changed to the second type of behaviour, i.e. the handler is called whenever a menu item has been selected. But I don't know if this is clever and if the other variant should be implemented instead... d) Most objects now can only be used with the left mouse button (and some also with the mouse wheel) unless some special meaning is associated with the middle and right mouse button. In the past most objects also did react to the middle and right mouse button which I always found rather irritating and unusual. I actually once lost quite a bit of work since I accidentally moved the scroll wheel when shifting the mouse around and, thanks to Murphy's law, I hit the "Quit" button of the application... e) Just for the fun of it I have reducded the default border- width to one pixel - but that's easy to set back to the traditional value of 3 or something else. Have fun, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Mar 18 20:27:08 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 19 Mar 2008 01:27:08 +0100 Subject: [XForms] Discussion concerning development Message-ID: <20080319002708.GB3158@toerring.de> To subscribers of the xforms list Hello Jason, On Mon, Mar 17, 2008 at 03:17:22PM -0400, Jason Cipriani wrote: > On Fri, Mar 14, 2008 at 7:16 AM, Jens Thoms Toerring wrote: > I think at this point it may even be save to assume C99 compliance, > which is now almost a decade in the past. I wouldn't go that far - as far as I know C99 never did really get of the ground and there are only very few compilers fully C99 compliant (even gcc didn't claim to be the last time I did look). But I also guess that non-C89 compliant compilers are going to be rather hard to find today;-) > It seems reasonable to me to assume that anybody using a machine that > can run XForms is also using a compiler and libc that is less than 20 > years old at this point. It also seems reasonable to assume that > anybody using a compiler and libc that is *more* than 20 years old has > more issues to worry about than compiling XForms. ;-) > > I am rather strongly opposed to arbitrary limits where- > > ever they can be avoided since todays reasonable limits > > can be a headache tomorrow ("Who will ever need more than > > 600kB of memory?") and would try to change the code as far > > as possible to abvoid them. On the other hand I may not > > be seeing the complete picture and these limits may have > > some beneficial effects I am not aware of. Does anybody > > see some good reasons for keeping them? > > If they are causing problems, no. If they are not causing problems, > even though it *would* be better to have dynamic upper limits, there > is also the question of how much work it is to change it. I do not > know where all the fixed limits are, it has been some time since I dug > into XForms source. I am not going to do much about that right now, it was more of a question if there's some reasonable opposition to that idea. All I want to make sure is that by removing arbitrary limits I don't break too many things. > > Another point I am not too happy about some of the default > > looks of XForms. For example I find that the default border > > width of 3 pixels looks plain ugly... > > I nearly always fl_set_border_width(1) anyway. I also think the > default look is pretty ugly. The default colors are a little mirky as > well, but that may just be a personal preference (and also in contrast > to gnome's brighter default colors) -- I almost always override the > defaults with fl_set_icm_color() to something brighter. I seem to have > settled on the following: > > #define UI_COLOR_LIGHT 255, 255, 255 > #define UI_COLOR_LTMID 224, 224, 224 > #define UI_COLOR_MID 202, 202, 202 > #define UI_COLOR_DARK 128, 128, 128 > #define UI_COLOR_DARKER 96, 96, 96 > #define UI_COLOR_INACTIVE 96, 96, 96 > > fl_set_icm_color(FL_TOP_BCOL, UI_COLOR_LIGHT); > fl_set_icm_color(FL_LEFT_BCOL, UI_COLOR_LIGHT); > fl_set_icm_color(FL_MCOL, UI_COLOR_LTMID); > fl_set_icm_color(FL_COL1, UI_COLOR_MID); > fl_set_icm_color(FL_BOTTOM_BCOL, UI_COLOR_DARK); > fl_set_icm_color(FL_RIGHT_BCOL, UI_COLOR_DARK); > fl_set_icm_color(FL_DARKER_COL1, UI_COLOR_DARKER); > fl_set_icm_color(FL_INACTIVE, UI_COLOR_INACTIVE); Yes, default colors are another point! If there's someone with some graphics design background on the mailing list recommendations will definitely be appreciated! For the next pre-release (hopefully coming tomorrow, but there are still a few issues to be taken care of:-( I am going to set the default borderwidth to 1 just for the fun of it. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Mon Mar 17 15:17:22 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Mon, 17 Mar 2008 15:17:22 -0400 Subject: [XForms] Discussion concerning development In-Reply-To: <20080314111611.GA16214@toerring.de> References: <20080314111611.GA16214@toerring.de> Message-ID: To subscribers of the xforms list On Fri, Mar 14, 2008 at 7:16 AM, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hello, > > going through parts of the code of XForms some things > got me puzzled and I would like to ask about your opinion: > > a) It seems to be assumed that the compiler used to comile > XForms isn't even ANSI C89 compatible. This might have > been a problem at the time the XForms project was star- > ted, but nearly 19 years after this standard came out > is this something we still have to care about? Is there > anybody out there still using a pre-C89 compiler and > where for example realloc() called with a NULL pointer > as the first argument isn't the same as a call of > malloc() (i.e. the libc isn't ANSI C89 compliant)? I think at this point it may even be save to assume C99 compliance, which is now almost a decade in the past. It seems reasonable to me to assume that anybody using a machine that can run XForms is also using a compiler and libc that is less than 20 years old at this point. It also seems reasonable to assume that anybody using a compiler and libc that is *more* than 20 years old has more issues to worry about than compiling XForms. > b) In lots of places fixed upper limits exist, starting with > the maximum number of forms (a limitation I already have > removed), the number of popup menus and there entries, > number of file selectors, line lengths in text browsers > etc. etc. I don't know if these "arbitrary limits" were > introduced because the original authors didn't feel too > comfortable with dynamic memory allocation or if it was > assumed that having fixed sized arrays would simply be > faster (especially in the "old times" when memory allo- > cation handling wasn't that optimized as it tends to be > today). Probably a little bit of both. > I am rather strongly opposed to arbitrary limits where- > ever they can be avoided since todays reasonable limits > can be a headache tomorrow ("Who will ever need more than > 600kB of memory?") and would try to change the code as far > as possible to abvoid them. On the other hand I may not > be seeing the complete picture and these limits may have > some beneficial effects I am not aware of. Does anybody > see some good reasons for keeping them? If they are causing problems, no. If they are not causing problems, even though it *would* be better to have dynamic upper limits, there is also the question of how much work it is to change it. I do not know where all the fixed limits are, it has been some time since I dug into XForms source. > Another point I am not too happy about some of the default > looks of XForms. For example I find that the default border > width of 3 pixels looks plain ugly - ten years ago pronounced > 3D effects may have been the the rage, but nowadays it looks > to me pretty old-fashioned. Would anybody mind if I would re- > duce the default border width from 3 to 2 (I personally would > prefer 1, but that might be a bit too extreme a change)? You > can have kind of a preview of the effects if you start your > application with the "-bw 2" option, which changes the default > from 3 to 2. I nearly always fl_set_border_width(1) anyway. I also think the default look is pretty ugly. The default colors are a little mirky as well, but that may just be a personal preference (and also in contrast to gnome's brighter default colors) -- I almost always override the defaults with fl_set_icm_color() to something brighter. I seem to have settled on the following: #define UI_COLOR_LIGHT 255, 255, 255 #define UI_COLOR_LTMID 224, 224, 224 #define UI_COLOR_MID 202, 202, 202 #define UI_COLOR_DARK 128, 128, 128 #define UI_COLOR_DARKER 96, 96, 96 #define UI_COLOR_INACTIVE 96, 96, 96 fl_set_icm_color(FL_TOP_BCOL, UI_COLOR_LIGHT); fl_set_icm_color(FL_LEFT_BCOL, UI_COLOR_LIGHT); fl_set_icm_color(FL_MCOL, UI_COLOR_LTMID); fl_set_icm_color(FL_COL1, UI_COLOR_MID); fl_set_icm_color(FL_BOTTOM_BCOL, UI_COLOR_DARK); fl_set_icm_color(FL_RIGHT_BCOL, UI_COLOR_DARK); fl_set_icm_color(FL_DARKER_COL1, UI_COLOR_DARKER); fl_set_icm_color(FL_INACTIVE, UI_COLOR_INACTIVE); > The same question also arises for the use of bold, italic fonts > in popups and menus. Again I find them rather ugly and would > propose to use normal, non-italic fonts as the default... Personally, I have no opinion about that. I think the italics are a little harsh so I usually turn them off, otherwise I don't know. Jason _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Fri Mar 14 07:16:11 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Fri, 14 Mar 2008 12:16:11 +0100 Subject: [XForms] Discussion concerning development Message-ID: <20080314111611.GA16214@toerring.de> To subscribers of the xforms list Hello, going through parts of the code of XForms some things got me puzzled and I would like to ask about your opinion: a) It seems to be assumed that the compiler used to comile XForms isn't even ANSI C89 compatible. This might have been a problem at the time the XForms project was star- ted, but nearly 19 years after this standard came out is this something we still have to care about? Is there anybody out there still using a pre-C89 compiler and where for example realloc() called with a NULL pointer as the first argument isn't the same as a call of malloc() (i.e. the libc isn't ANSI C89 compliant)? b) In lots of places fixed upper limits exist, starting with the maximum number of forms (a limitation I already have removed), the number of popup menus and there entries, number of file selectors, line lengths in text browsers etc. etc. I don't know if these "arbitrary limits" were introduced because the original authors didn't feel too comfortable with dynamic memory allocation or if it was assumed that having fixed sized arrays would simply be faster (especially in the "old times" when memory allo- cation handling wasn't that optimized as it tends to be today). I am rather strongly opposed to arbitrary limits where- ever they can be avoided since todays reasonable limits can be a headache tomorrow ("Who will ever need more than 600kB of memory?") and would try to change the code as far as possible to abvoid them. On the other hand I may not be seeing the complete picture and these limits may have some beneficial effects I am not aware of. Does anybody see some good reasons for keeping them? Another point I am not too happy about some of the default looks of XForms. For example I find that the default border width of 3 pixels looks plain ugly - ten years ago pronounced 3D effects may have been the the rage, but nowadays it looks to me pretty old-fashioned. Would anybody mind if I would re- duce the default border width from 3 to 2 (I personally would prefer 1, but that might be a bit too extreme a change)? You can have kind of a preview of the effects if you start your application with the "-bw 2" option, which changes the default from 3 to 2. The same question also arises for the use of bold, italic fonts in popups and menus. Again I find them rather ugly and would propose to use normal, non-italic fonts as the default... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 14:02:21 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 19:02:21 +0100 Subject: [XForms] Using Xform in background without display In-Reply-To: References: <20080313112646.GA9784@toerring.de> <20080313131224.GB9842@toerring.de> Message-ID: <20080313180221.GA17421@toerring.de> To subscribers of the xforms list Hi Didier, On Thu, Mar 13, 2008 at 05:07:01PM +0100, Didier Verkindt wrote: > My application uses Xform for GUI and ROOT for making plots. > And in some cases, I do not want to interact with the application, > I would like to run it in background, producing a ROOT plot that > is written as a jpg file (thanks to ROOT's class TImageDump) > TImageDump *imgdump = new TImageDump(jpgFileName); > gDDCanvas->Paint(); > TImage *img = imgdump->GetImage(); > img->SetImageQuality(img->kImgFast); > img->SetImageCompression(60); > imgdump->Close(); > imgdump->Delete(); None of these functions seem to be from XForms but ROOT (at least as far as I can tell), so if you don't use any XForms functions you don't have to invoke fl_initialize() at all. I think if this is the case it's rather simple. Do something like this (sorry, it's in C and not C++, but I am not that good at C++ and it probably will be nearly the same): int main( int argc, char * argv[ ] ) { int i; for ( i = 1; i < argc; i++ ) if ( ! strcmp( argv[ i ], "-nodisplay" ) ) break; if ( i == argc ) /* "-nodisplay" not found */ fl_initialize( &argc, argv, "Whatever", 0, 0 ); That way you avoid calling fl_initialize() when the program is invoked with the "-nodisplay" option. And that should be fine as long as you don't call any XForms functions after- wards (you will probably find out if you do so anyway since then XForms would complain loudly;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From verkindt at lapp.in2p3.fr Thu Mar 13 12:07:01 2008 From: verkindt at lapp.in2p3.fr (Didier Verkindt) Date: Thu, 13 Mar 2008 17:07:01 +0100 (CET) Subject: [XForms] Using Xform in background without display In-Reply-To: <20080313131224.GB9842@toerring.de> References: <20080313112646.GA9784@toerring.de> <20080313131224.GB9842@toerring.de> Message-ID: To subscribers of the xforms list Hi, My application uses Xform for GUI and ROOT for making plots. And in some cases, I do not want to interact with the application, I would like to run it in background, producing a ROOT plot that is written as a jpg file (thanks to ROOT's class TImageDump) TImageDump *imgdump = new TImageDump(jpgFileName); gDDCanvas->Paint(); TImage *img = imgdump->GetImage(); img->SetImageQuality(img->kImgFast); img->SetImageCompression(60); imgdump->Close(); imgdump->Delete(); which does not need a display, as far as I know. Only fl_initialize prevented me to do this on a machine with no display. According to what you wrote, it seems difficult to have a call to fl_initialize which would not take care of the display's part. I am not happy but thanks for your investigation. If you have any idea to overcome the problem, do not hesitate. I am not a pro of Xform or X servers, so I do not foresee to find the solution by myself. Best regards, Didier ----------------------------------------------------------- Didier VERKINDT, LAPP, Ch. de Bellevue, 74941 Annecy-le-Vieux, FRANCE tel:33(0)450091671 or 5573 fax:33(0)450279495 web:lapp.in2p3.fr/~verkindt On Thu, 13 Mar 2008, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hi Jean-Marc, > > On Thu, Mar 13, 2008 at 12:50:58PM +0100, Jean-Marc Lasgouttes wrote: > > Jens Thoms Toerring writes: > > > Are you actually using anything from XForms when you want the > > > program to run without any graphics output? > > > > I guess the idea is to use flimage. Does this work without a display? > > Mmmm. I have to admit that I didn't went through that part of > XForms more than very superficially yet, so I could be comple- > tely wrong. But a short look at that part of the code shows > that quite a number of Xlib functions are used there, so I > would guess that you can't use that part (which already is > separated out into its own library, libflimage.so) without > having a display (or at least some kind of Xserver that fakes > a display if there's no screen, which using using xvfb might > amount to). > > And, as far as my (very limited) understanding goes, all the > functions in flimage are meant to read in a graphics file and > display it on the screen (e.g. on top of a button etc.) or to > write out an image from an X drawable to a file. In both cases > you would need a display. > > Since Didier wrote that he just wants to write out jpg files > I guess that he will always need to create some X drawable, > draw something onto it and then write it out. But that would > involve an X drawable. But if he just wants to convert e.g. > a gif image to a jpg I would rather recommend to use some- > thing more suitable in that case, e.g. ImageMagick. > > Best regards, Jens > -- > \ Jens Thoms Toerring ________ jt at toerring.de > \_______________________________ http://toerring.de > _______________________________________________ > To unsubscribe, send any message to > xforms-leave at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 09:12:24 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 14:12:24 +0100 Subject: [XForms] Using Xform in background without display In-Reply-To: References: <20080313112646.GA9784@toerring.de> Message-ID: <20080313131224.GB9842@toerring.de> To subscribers of the xforms list Hi Jean-Marc, On Thu, Mar 13, 2008 at 12:50:58PM +0100, Jean-Marc Lasgouttes wrote: > Jens Thoms Toerring writes: > > Are you actually using anything from XForms when you want the > > program to run without any graphics output? > > I guess the idea is to use flimage. Does this work without a display? Mmmm. I have to admit that I didn't went through that part of XForms more than very superficially yet, so I could be comple- tely wrong. But a short look at that part of the code shows that quite a number of Xlib functions are used there, so I would guess that you can't use that part (which already is separated out into its own library, libflimage.so) without having a display (or at least some kind of Xserver that fakes a display if there's no screen, which using using xvfb might amount to). And, as far as my (very limited) understanding goes, all the functions in flimage are meant to read in a graphics file and display it on the screen (e.g. on top of a button etc.) or to write out an image from an X drawable to a file. In both cases you would need a display. Since Didier wrote that he just wants to write out jpg files I guess that he will always need to create some X drawable, draw something onto it and then write it out. But that would involve an X drawable. But if he just wants to convert e.g. a gif image to a jpg I would rather recommend to use some- thing more suitable in that case, e.g. ImageMagick. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From Jean-Marc.Lasgouttes at inria.fr Thu Mar 13 07:50:58 2008 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 13 Mar 2008 12:50:58 +0100 Subject: [XForms] Using Xform in background without display In-Reply-To: <20080313112646.GA9784@toerring.de> (Jens Thoms Toerring's message of "Thu\, 13 Mar 2008 12\:26\:46 +0100") References: <20080313112646.GA9784@toerring.de> Message-ID: To subscribers of the xforms list Jens Thoms Toerring writes: > Are you actually using anything from XForms when you want the > program to run without any graphics output? I guess the idea is to use flimage. Does this work without a display? JMarc _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 07:26:46 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 12:26:46 +0100 Subject: [XForms] Using Xform in background without display Message-ID: <20080313112646.GA9784@toerring.de> To subscribers of the xforms list Hi, > I have developped since several years a data visualization application > that uses Xforms as GUI. In some circumstances, I would like to run this > application in background (producing just jpg files, without user > interaction and without showing any xform window) on a machine which has > no display. But I get stucked on the fl_initialize function. > With the following error message: > Can't open display --No such file or directory > Missing or failed fl_initialize() > > For now, I have overcome the problem by using xvfb when starting the > application. But could the next release of Xform provide an API or a flag > that allows to run temporarily without display? > Or could the next release separate in fl_initialize what is specific xform > init from what is related to the display? That's going to be a bit difficult because XForms is suposed to work with a display. Hardly anything useful can be done without one, and trying to separate out the small number of functions that may be usable without having an open display would probably be a huge amount of work (actually, if that would be possible and any usuful functionality would remain in the resulting subset, it probably should be put into a separate library;-) Are you actually using anything from XForms when you want the program to run without any graphics output? If not, then perhaps a solution like I am using it myself in such circumstances would be to avoid calling fl_initialize() at all. I do that by going through the command line arguments first, looking for a certain option (in my case I use '-nw'). If I find that I don't don't call fl_initialize() (or any other functions from XForms), otherwise I pass on the command line arguments unchanged to fl_initialize(). Having a command line argument that tells fl_initialize() that XForms isn't going to be used sounds a bit strange to me. It would be similar to having a function e.g. in the math library to tell it that no function of this library will ever be used. Or am I misunderstanding what you are trying to do? Regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 07:03:03 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 12:03:03 +0100 Subject: [XForms] Migrating from xforms-0.89 Message-ID: <20080313110303.GA9348@toerring.de> To subscribers of the xforms list Hi, > I have a project which still uses xforms 0.89. I would like to > upgrade, but installing > the new versions results in all sorts of error messages when I compile. Do you get errros when you try to compile the new version of the XForms library or when you try to recompile your program using the new version? In the first case I would be very interested to get a list of all messages! If you're using e.g. a bash like shell you could redirect the output of the configure and make command to files by using e.g. ./configure > configlog 2>&1 make > makelog 2>&1 Please be so kind to send me the resulting files. In the second case it also would be helpful to see what you actually get as error messages. It's a long time since I have been using version 0.89, so I probably don't not re- member most of the changes that happened since then. But I guess that the main changes were: a) The forms.h file to be included by your program was in /usr/X11/include/X11/ Nowadays it's per default in /usr/local/include/ You must make sure that the compiler picks up this new file and not accidentally the old one. Perhaps you will need to pass something like '-I/usr/local/include' to the compiler. b) The library itself also seem to have been in /usr/X11/lib/ but nowadays is per default in /usr/local/lib/ You may have to tell the linker by using something like '-L/usr/local/lib'. c) In version 0.89 Pixmaps were handled by some internal functions is XForms. This has changed and XForms now requires the external Xpm library for this, see e.g. http://koala.ilog.fr/lehors/xpm.html This library needs to be installed on your system and you must explicitely link against it (using e.g. the option '-lXpm' when compiling with gcc). I really don't remember what you had to specify as compiler and linker flags when compiling against 0.89. But nowadays I would probably use someting like -I/usr/local/include -L/usr/local/lib -X11 -lforms -lXpm -lm The API itself hasn't experienced too many changes and I can't remember them. If your problems result from them please post the error messages you got, otherwise it's going to be very figure out what's going wrong;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From verkindt at lapp.in2p3.fr Thu Mar 13 04:18:38 2008 From: verkindt at lapp.in2p3.fr (Didier Verkindt) Date: Thu, 13 Mar 2008 09:18:38 +0100 (CET) Subject: [XForms] Using Xform in background without display In-Reply-To: References: <988FAD2E161E4347BFD7EC93A4D05904022F4B69@xcgaz701.northgrum.com> Message-ID: To subscribers of the xforms list Hi, I am very happy to see that Xforms and this mailing list are still alive. I have developped since several years a data visualization application that uses Xforms as GUI. In some circumstances, I would like to run this application in background (producing just jpg files, without user interaction and without showing any xform window) on a machine which has no display. But I get stucked on the fl_initialize function. With the following error message: Can't open display --No such file or directory Missing or failed fl_initialize() For now, I have overcome the problem by using xvfb when starting the application. But could the next release of Xform provide an API or a flag that allows to run temporarily without display? Or could the next release separate in fl_initialize what is specific xform init from what is related to the display? Thank you, Didier ----------------------------------------------------------- Didier VERKINDT, LAPP, Ch. de Bellevue, 74941 Annecy-le-Vieux, FRANCE tel:33(0)450091671 or 5573 fax:33(0)450279495 web:lapp.in2p3.fr/~verkindt _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Mar 18 18:39:15 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 18 Mar 2008 23:39:15 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <1205809811.47df3293b87de@webmail.minx.net.uk> References: <1205809811.47df3293b87de@webmail.minx.net.uk> Message-ID: <20080318223914.GA30325@toerring.de> To subscribers of the xforms list Hello Chris, On Tue, Mar 18, 2008 at 03:10:11AM +0000, chris at evib.net wrote: > I had, just recently, installed Fedora 8 on my laptop to take away for a 3 > week trip. I hadn't tested the 1.0.90 release of XForms under F8 and found > one of my applications refused to display when using: > > fl_set_input(obj, msgstr); > > The 1.0.91 release cures this problem. As much as I would like to claim that for me I don't think I was responsible for this change for the better;-) Actually, Jean-Marc Lasgouttes and Angus Leeming committed quite a number of changes to the CVS version in the last years which I can build on. And I am rather sure that's one of many problems they already did solve! > However, the initialisation code for a grid which uses code as in the > following fragment (modified from the code generated from the form > definition file): > > fdui->cell00 = obj = fl_add_input(FL_INT_INPUT,x=20,y=40,20,20,""); > fl_set_object_color(obj,FL_MCOL,FL_MCOL); > fl_set_object_lalign(obj,FL_ALIGN_CENTER); > fl_set_object_callback(obj,Grid_Input,cell++); > > steadfastly refuses to change the objects colour regardless of what FL_xxxx > colour is used. Later on, the same sort of code is used to change the cell's > appearance and that works! > > fl_set_object_boxtype(obj, FL_FRAME_BOX); > fl_set_input_cursor_visible(obj, FALSE); > fl_set_object_color(obj, FL_GREEN, FL_GREEN); > fl_set_input(obj, msgstr); > > Strange! Definitely! Unfortunately, I can't reproduce this bug here on my machine by just inserting your example code into one of my programs. Perhaps it's something more complicated than just a bug in the func- tion for settineg an objects colors. In that case it might help me to figure out what's going wrong if you could send me a somewhat longer example. BTW: The indentation of your example code looks a bit as if it was generated by an older version of fdesign. Perhaps you still have two versions of fdesign (or all of XForms) installed on your ma- chine, the old one in /usr/bin and the new one in /usr/local/bin. Please try to get rid of the old installation - if there's a mix- ture of an old and a new versions a lot of things could go wrong... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Mar 18 18:39:15 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 18 Mar 2008 23:39:15 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <1205809811.47df3293b87de@webmail.minx.net.uk> References: <1205809811.47df3293b87de@webmail.minx.net.uk> Message-ID: <20080318223914.GA30325@toerring.de> To subscribers of the xforms list Hello Chris, On Tue, Mar 18, 2008 at 03:10:11AM +0000, chris at evib.net wrote: > I had, just recently, installed Fedora 8 on my laptop to take away for a 3 > week trip. I hadn't tested the 1.0.90 release of XForms under F8 and found > one of my applications refused to display when using: > > fl_set_input(obj, msgstr); > > The 1.0.91 release cures this problem. As much as I would like to claim that for me I don't think I was responsible for this change for the better;-) Actually, Jean-Marc Lasgouttes and Angus Leeming committed quite a number of changes to the CVS version in the last years which I can build on. And I am rather sure that's one of many problems they already did solve! > However, the initialisation code for a grid which uses code as in the > following fragment (modified from the code generated from the form > definition file): > > fdui->cell00 = obj = fl_add_input(FL_INT_INPUT,x=20,y=40,20,20,""); > fl_set_object_color(obj,FL_MCOL,FL_MCOL); > fl_set_object_lalign(obj,FL_ALIGN_CENTER); > fl_set_object_callback(obj,Grid_Input,cell++); > > steadfastly refuses to change the objects colour regardless of what FL_xxxx > colour is used. Later on, the same sort of code is used to change the cell's > appearance and that works! > > fl_set_object_boxtype(obj, FL_FRAME_BOX); > fl_set_input_cursor_visible(obj, FALSE); > fl_set_object_color(obj, FL_GREEN, FL_GREEN); > fl_set_input(obj, msgstr); > > Strange! Definitely! Unfortunately, I can't reproduce this bug here on my machine by just inserting your example code into one of my programs. Perhaps it's something more complicated than just a bug in the func- tion for settineg an objects colors. In that case it might help me to figure out what's going wrong if you could send me a somewhat longer example. BTW: The indentation of your example code looks a bit as if it was generated by an older version of fdesign. Perhaps you still have two versions of fdesign (or all of XForms) installed on your ma- chine, the old one in /usr/bin and the new one in /usr/local/bin. Please try to get rid of the old installation - if there's a mix- ture of an old and a new versions a lot of things could go wrong... Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From Jean-Marc.Lasgouttes at inria.fr Thu Mar 13 09:03:39 2008 From: Jean-Marc.Lasgouttes at inria.fr (Jean-Marc Lasgouttes) Date: Thu, 13 Mar 2008 14:03:39 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <20080313120921.GA9842@toerring.de> (Jens Thoms Toerring's message of "Thu\, 13 Mar 2008 13\:09\:21 +0100") References: <20080313120921.GA9842@toerring.de> Message-ID: To subscribers of the xforms list Jens Thoms Toerring writes: > (Hello, Dr. Zhao, if you're reading > this: As far as I know you still didn't consent to make also > the existing documentation "open source" and there's only > the PostScript version at the moment. I would be grateful > if you would contact either me or one of the other main- > tainers about this.) There is also an html version. JMarc _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Thu Mar 13 08:09:21 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Thu, 13 Mar 2008 13:09:21 +0100 Subject: [XForms] New XForms release: call for testers Message-ID: <20080313120921.GA9842@toerring.de> To subscribers of the xforms list Hi, > Now the very quick try of the new code shows all the above problems > seem to have gone. Thanks, that's good news! > I will do more extensive usage tests of several xforms-apps I use. > Especially regarding the program crashes on mouse scroll in text > browsers that I suffered from quite a bit. I hope that this problem is gone. I actually could reproduce something that looked like it with the fbrowse demo program, which quite often simply exited when the mouse wheel was used. There was some bug in the button press/relase handling code that made fl_do_forms() return an object in cases were it shouldn't have done so. And since the program only expected fl_do_forms() to return when the program is supposed to end this then exited. Perhaps you experienced the same problem and in that case it shouldn't happen anymore. Otherwise just complain;-) > PS. If the XForms is to be revived, I would vote for the long- > promised, never-done scrolled canvas :) Please don't hold your breath on that (and I personally never made such a promise;-) My main motvation is that I have a rather largish program using XForms and I want it to work correctly without any glitches under all circumstances. So at the moment I am mostly concerned with a consolidation of the code base (and there are still enough potential problems to keep me busy for a while;-) I think that should be the main focus until the long-awaited 1.1 release is out. Another point that I find very important is to get some up to date documentation. (Hello, Dr. Zhao, if you're reading this: As far as I know you still didn't consent to make also the existing documentation "open source" and there's only the PostScript version at the moment. I would be grateful if you would contact either me or one of the other main- tainers about this.) But that definitely shouldn't keep you (or anybody else) from creating new widgets etc.! Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From msz at astrouw.edu.pl Wed Mar 12 19:55:53 2008 From: msz at astrouw.edu.pl (Michal Szymanski) Date: Thu, 13 Mar 2008 00:55:53 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <20080312170818.GA13700@toerring.de> References: <20080312170818.GA13700@toerring.de> Message-ID: <20080312235553.GA8465@astrouw.edu.pl> To subscribers of the xforms list Hi XFormers, Great news. I thought the project was dead. I have just been experiencing problems addressed by Jens, ever since I started using machines with newer OSes and X11. I intensively use my image display xforms-application and I noticed that resizing it often resulted in completely messed window. Also, double-click in file selector stopped working altogether (this, however, used to happen sometimes also in old days). Now the very quick try of the new code shows all the above problems seem to have gone. Good job, Jens, thank you. I will do more extensive usage tests of several xforms-apps I use. Especially regarding the program crashes on mouse scroll in text browsers that I suffered from quite a bit. best regards, Michal. PS. If the XForms is to be revived, I would vote for the long-promised, never-done scrolled canvas :) -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND On Wed, Mar 12, 2008 at 06:08:18PM +0100, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hello, > > as promised in my last mail from end of January I have > continued to work on XForms. The most important changes are: > > a) Update of the event handling subsystem, events can't > get lost anymore. > b) Overwork of window resizing - especially noticable > with window managers that update windows while they > are being resized. > c) Code for popups, menus etc. extensively changed, should > now work better and more like we're used to from other > toolkits. Shadows which ever did work cleanly have been > removed. > d) Text browser sliders now should work correctly. > e) Lots of bugs removed that could lead to segmentation > faults, X errors, memory and X resource leaks, missed > redraws, double click selections in file selectors not > always working, programs sometimes unexpectedly exiting > when mouse scroll wheel is used in text browsers etc. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From lab at saao.ac.za Thu Mar 13 03:34:09 2008 From: lab at saao.ac.za (lab at saao.ac.za) Date: Thu, 13 Mar 2008 09:34:09 +0200 Subject: [XForms] Migrating from xforms-0.89 In-Reply-To: <20080312183546.GE10548@toerring.de> References: <20080312170818.GA13700@toerring.de> <20080312183546.GE10548@toerring.de> Message-ID: <20080313093409.taka941s00skgw0s@webmail.saao.ac.za> To subscribers of the xforms list Hi I have a project which still uses xforms 0.89. I would like to upgrade, but installing the new versions results in all sorts of error messages when I compile. Can anyone give me a roadmap of how to migrate? Many thanks Luis Balona ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jason.cipriani at gmail.com Wed Mar 12 18:33:00 2008 From: jason.cipriani at gmail.com (Jason Cipriani) Date: Wed, 12 Mar 2008 18:33:00 -0400 Subject: [XForms] New XForms release: call for testers In-Reply-To: <20080312183546.GE10548@toerring.de> References: <20080312170818.GA13700@toerring.de> <20080312183546.GE10548@toerring.de> Message-ID: To subscribers of the xforms list I am just getting started on a relatively large application that will be using XForms; it does dynamic window updates on resize and is fairly X-intensive. So this is may be a great opportunity to test out this new release. I assure you I'll be stress testing it pretty hard (as usual ;), I'll keep you posted. Jason On Wed, Mar 12, 2008 at 2:35 PM, Jens Thoms Toerring wrote: > To subscribers of the xforms list > > Hello, > > since already a few people asked for it here's a pre- > release you can download directly (without CVS) and which > doesn't require having all the automake tools installed: > > http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre1.tar.gz > > Just unpack, then run configure and make;-) > > > > Best regards, Jens > -- > \ Jens Thoms Toerring ________ jt at toerring.de > \_______________________________ http://toerring.de > _______________________________________________ > To unsubscribe, send any message to > xforms-leave at bob.usuhs.mil or see: > http://cweblog.usuhs.mil/mailman/listinfo/xforms > List Archive: http://bob.usuhs.mil/pipermail/xforms and > http://bob.usuhs.mil/mailserv/list-archives/ > Development: http://savannah.nongnu.org/files/?group=xforms > _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 12 14:35:46 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 12 Mar 2008 19:35:46 +0100 Subject: [XForms] New XForms release: call for testers In-Reply-To: <20080312170818.GA13700@toerring.de> References: <20080312170818.GA13700@toerring.de> Message-ID: <20080312183546.GE10548@toerring.de> To subscribers of the xforms list Hello, since already a few people asked for it here's a pre- release you can download directly (without CVS) and which doesn't require having all the automake tools installed: http://download.savannah.nongnu.org/releases/xforms/xforms-1.0.91.pre1.tar.gz Just unpack, then run configure and make;-) Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Wed Mar 12 13:08:18 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Wed, 12 Mar 2008 18:08:18 +0100 Subject: [XForms] New XForms release: call for testers Message-ID: <20080312170818.GA13700@toerring.de> To subscribers of the xforms list Hello, as promised in my last mail from end of January I have continued to work on XForms. The most important changes are: a) Update of the event handling subsystem, events can't get lost anymore. b) Overwork of window resizing - especially noticable with window managers that update windows while they are being resized. c) Code for popups, menus etc. extensively changed, should now work better and more like we're used to from other toolkits. Shadows which ever did work cleanly have been removed. d) Text browser sliders now should work correctly. e) Lots of bugs removed that could lead to segmentation faults, X errors, memory and X resource leaks, missed redraws, double click selections in file selectors not always working, programs sometimes unexpectedly exiting when mouse scroll wheel is used in text browsers etc. I think it would be time to create a new release, 1.0.91, based on this code. But since all these changes haven't been tested except by myself, I am a bit reluctant to do so and thus would like to ask everybody of you with a bit of time to spare to check out the CVS version and play around with it and report results (both positive and negative;-) To do so just download the CVS version with the command: cvs -d:pserver:anonymous at cvs.sv.gnu.org:/sources/xforms co xforms This will create a directory called 'xforms'. First run the the 'autogen.sh' script in this directory and then compile with the usual 'configure' and make commands. If it would be more convenient for you I could also make a pre-release in which case you woudn't have to have cvs and automake installed on your machine. Just tell me;-) Please note if you link your application against the dynamic library: to make it easier to distinguish from the 1.0.90 version the new version is 'libforms.1.1.0' instead of 'libforms.1.0.0', so you can have both installed but then must either set the sym- bolic link 'libforms.so' accordingly or link explicitely against the new version. Best regards, Jens -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms From jt at toerring.de Tue Jan 29 10:23:02 2008 From: jt at toerring.de (Jens Thoms Toerring) Date: Tue, 29 Jan 2008 16:23:02 +0100 Subject: [XForms] XForms development Message-ID: <20080129152302.GA2495@john.toerring.de> To subscribers of the xforms list Hello, while development of XForms has slowed down a bit I hope it's not dead yet. At least I continue to use XForms for some of my projects and I would rather like to keep it that way. For that reason and since there were some bugs I started to work a bit on the source code, mostly to get rid of a few crashes due to Xerrors and some redrawing problems etc. Jean- Marc Lasgouttes has now given me the opportunity by to upload a new version to the CVS on Savannah. You can find a list of the main changes at http://cvs.savannah.nongnu.org/viewvc/xforms/ChangeLog?revision=1.123&root=xforms&view=markup Of course, there is a rather large chance that I broke many things in the process. Moreover, I can only do tests on my PC- type Linux machine since I don't have access to machines with other architectures or operating systems at the moment. There- fore I would really appreciate it if at least some of you would download the newest version and test it. There are also a few additions to some crucial structures like FL_FORM and FL_OBJECT. While no "normal" programs should access those directly, it could be that some do so anyway and get confused by the changes. Thus I would like to hear if this results in any serious problem. Please also note that this is work in progress. There are still some unresolved issues I hope I will be able to address in the next few days. And probably there are a lotof problems I am not even aware of yet, so input from you about stuff that doesn't work correctly (also in older versions and still in the new CVS version), crashes etc. would be very helpful. If you want to do some tests, the steps are relatively simple. To download the CVS version use the command cvs -d:pserver:anonymous at cvs.sv.gnu.org:/sources/xforms co xforms (This, of course, assumes that you have cvs installed on your machine. I will try to come up with a new 1.0.91 version soon that then can be downloaded as an archive from Savannah, but I would like to have a bit more feedback before doing so in order to avoid disappointing too many people;-) Once you have downloaded the CVS sources (which will create a new subdirectory named 'xforms') go into the 'xforms' subdi- rectory and run the 'autogen.sh' script. To do so you need to have a not too old version of 'automake' installed. Once this script is done you can continue in the normal way to compile the library with configure and make, as described in the READ- ME or INSTALL file. Of course, I also would like to hear about problems when the library and the demo programs get compiled. Perhaps the best way to tell me about them would be to redirect the output of the configure and make process into files and send them to me. My email address is in my signature. Best regards, Jens BTW: Does anybody have the email address of Dr. T.C. Zhao so that we can ask him directly about the documentation which, as far as I remember, he hasn't yet made officially open source? -- \ Jens Thoms Toerring ________ jt at toerring.de \_______________________________ http://toerring.de _______________________________________________ To unsubscribe, send any message to xforms-leave at bob.usuhs.mil or see: http://cweblog.usuhs.mil/mailman/listinfo/xforms List Archive: http://bob.usuhs.mil/pipermail/xforms and http://bob.usuhs.mil/mailserv/list-archives/ Development: http://savannah.nongnu.org/files/?group=xforms