yong@metasoft.UUCP (Yongdeng Chen) (03/30/89)
Hi there, I have a drawing program under development. And I am going to use TextWidget to edit the labels and texts. It would be very expensive to keep all the TextWidget around for each text or label. It would also be very expensive to keep on creating and destroying the text widget. So I decided to have just one TextWidget for editing texts and labels. There is no problem if there is only one diagram drawing widget. But, my program will have many diagram drawing widgets from time to time. So I would like to have a function some thing like XtReparentWidget to move the text widget from one diagram drawing widget to another. Has anyone written that function already? If I want to writing my own function for that, what are the short cuts, cautions and advises that I should know ? How messy would that be to write such a function ? Thanks in advance for your suggestions, advises, and answers! __________________________________________________________________ yong%metasoft@bbn.com Yongdeng Chen Meta Software Corporation 150 Cambridge Park Drive Cambridge, MA 02140 (617)576-6920
meo@stiatl.UUCP (Miles O'Neal) (03/31/89)
In article <8903300045.AA28710@metasoft.uucp> yong@metasoft.UUCP (Yongdeng Chen) writes: >Hi there, > So I would like to have a function some thing like >XtReparentWidget to move the text widget from one diagram drawing >widget to another. > Has anyone written that function already? > If I want to writing my own function for that, what are >the short cuts, cautions and advises that I should know ? > How messy would that be to write such a function ? > Thanks in advance for your suggestions, advises, and answers! Wouldn't we all like this one! But, alas, "they" say it's major-league non-trivial. A suggestion (proven in real-life use by actual X11 programmers!): 1) You create the TW (textWidget) as a child of root, pointed to by a global variable. 2) Unmap it. 3) Invocation: a) create/map/whatever the new "pseudo-parent" (PP). b) convert the PP-relative (x,y) for the TW to root-relative (x,y). c) using XtSetValues (), stuff the result of (b) into the TW Args. d) add a callback to or override the actions/translations of the TW with a routine specific to the PP that will perform the necessary processing (the TW ptr being in the Widget field of the callback or action routine). e) if you use a callback, be sure that each PP tells the widget to forget the old callback before adding its own. f) map the TW. 4) the code to unmap/destroy/etc the PP needs to also unmap the TW. You might want to perform (3e) at this point as well. Yes, it's a little hackish, but it works, is very flexible, and should work through all versions of X11 until someone does write a reparenter (probably after some serious reworking of Xt widget-instantiation). If you have problems getting the TW to show above the parent, play around with Raising the PW. You may (at least under X11R2, have to also do XFlush's, clear the event queue, etc, before Raising the TW, to assure that some other event (such as MapRaise the PP) doesn't happen after the Map of the TW in such a way as to interfere. -Miles gatech!stiatl!meo
mike@cosmos.acs.calpoly.edu (Mike Patnode) (04/04/89)
In article <8903300045.AA28710@metasoft.uucp> yong@metasoft.UUCP (Yongdeng Chen) writes: >Hi there, ... (why I want to reparent a widget) A very general, but hacked solution is to copy a widget into the new location, and destroy the old one. I've been working on a specific CopyWidget routine which depends upon our program knowing about all the attributes for each widget. Before I reinvent the wheel, I was wondering if anybody already had some sort of general XtCopyWidget routine which could copy an arbitrary widget. Any ideas on what this would involve. Does the Toolkit contain enough information in itself about each widget? This would be a simple solution to the reparent problem. ------------ Mike "Dodger" Patnode | (n) ..csustan!polyslo!mpatnode Yitbos Innovations Inc. | (s) ..sdsu!polyslo!mpatnode 244 California Blvd | mpatnode@polyslo.CalPoly.EDU San Luis Obispo, Ca 92630 | (805) 541-2048 / 543-9818 / 756-2516
eco@ece-csc.UUCP (ECO) (04/05/89)
Hi. We need to get a copy of the X11R2 version of xterm. We don't have the space to get the whole R2 release just for the xterm software. Could someone out there mail us a copy or point us towards a FTP source? Thanks a million! Amy email: johnson%eceugs@ncsuvx.ncsu.edu
diamant@hpfclp.SDE.HP.COM (John Diamant) (04/06/89)
> I was wondering if anybody already had some > sort of general XtCopyWidget routine which could copy an arbitrary > widget. Any ideas on what this would involve. Does the Toolkit contain > enough information in itself about each widget? This would be a simple > solution to the reparent problem. The Toolkit does contain enough information. The size of a widget w can be obtained as follows: XtClass(w)->core_class.widget_size; With that, you can malloc up a suitable sized chunk of memory and do a raw memory copy using bcopy to the new location. Examples of this appear in the Toolkit code already (in Resources.c). So, a general XtCopyWidget routine, would in fact, be very easy to write (about 4 lines of code). In fact, here it is (untested): Widget XtCopyWidget(w) Widget w; { int widgetSize = XtClass(w)->core_class.widget_size; Widget new = (Widget) XtMalloc(widgetSize); bcopy((char *) w, (char *) new, widgetSize); return new; } John Diamant Software Engineering Systems Division Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
bwarkent@polyslo.CalPoly.EDU (Brian Warkentine) (04/08/89)
In article <9740088@hpfclp.SDE.HP.COM> diamant@hpfclp.SDE.HP.COM (John Diamant) writes: >The Toolkit does contain enough information. The size of a widget w can >be obtained as follows: > > XtClass(w)->core_class.widget_size; > >With that, you can malloc up a suitable sized chunk of memory and do a raw >memory copy using bcopy to the new location. On the contrary, this is not general at all. What if the widget has non-core part data? Also, if such a widget could be created you'd need a mechanism to inform the parent that a child has been created behind it's back. As Mike said in <9941@polyslo.CalPoly.EDU> the solution we've come up with is to destroy one widget and create another, copying all the resources from one to the other. I don't believe it would be a major redesign in the toolkit to provide this, but it would be a hefty chuck of implementation changes to work through. >John Diamant -- Brian Warkentine Cal Poly, San Luis Obispo, CA bwarkent@polyslo.calpoly.EDU ...!ucbvax!voder!polyslo!bwarkent
diamant@hpfclp.SDE.HP.COM (John Diamant) (04/10/89)
> >The Toolkit does contain enough information. The size of a widget w can > >be obtained as follows: > > > > XtClass(w)->core_class.widget_size; > > > >With that, you can malloc up a suitable sized chunk of memory and do a raw > >memory copy using bcopy to the new location. > > On the contrary, this is not general at all. What if the widget has > non-core part data? I don't see how this has anything to do with it. The widget_size is filled in with the size of the entire widget record, not the size of the CorePart, so it will copy all data in the widget. > Also, if such a widget could be created you'd need > a mechanism to inform the parent that a child has been created behind > it's back. Well, yes. It is not general in that sense. In fact, someone else pointed out via mail that this will cause trouble if there are pointers in the structure as both widgets would write to common data. That's true, but I was only attempting to answer a question in the original note which said that the original would be destroyed after the copy was made, so it shouldn't have mattered much. I never understood how this was supposed to solve the reparenting problem. It appears to me that it does not. John Diamant Software Engineering Systems Division Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant