[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug/lack of documentation for {editor-view}:add-button-in-menu




In article <27222@sophia.inria.fr>, Guido.Bosch@loria.fr (Guido Bosch) writes:
=> 
=> [ two functions that essentially call {editor-view}:add-button-in-menu.
=>   first function does a {link}:attach to the button after the call
=>   second function does a {link}:attach to the button before the call ]
=> 
=> My guess: the actually inserted button is in fact a copy of the one
=> provided to {editor-view}:add-button-in-menu. In the first case, the
=> links are attached to the original *after* the insertion of a copy of
=> it.  -->> BUG

i would like to explain first what i think the function should look like, then
a bit about how the various gfxobj are combined, and finally i'll explain why 
your second function just happens to work.

Note that in the doc (The Core (volume 3), "The Editor-view Structure", pages 7 
& 8) it says that both the :add-menu and :add-button-in-menu functions return the
object that is added.   Thus, the general form of the code should be:

	(de my-add-a-button (....)
	    (lets ((rank (if buttonrank (car buttonrank)))
		   (button-added ({editor-view}:add-button-in-menu ... rank)))
 		  ({link}:attach button-added 'ctedit ...)
		  ({link}:attach button-added 'ctview ...)
		  button-added))

You are right in your supposition that your first function attachs the links to 
the original object and *not* the object that is inserted.  Note however that we
don't insert a copy but rather a different object.  In fact, it is a "gadget"
corresponding to the "widget" you intended to add, if i can use these Xtoolkit
terms.  That is, a widget is a windowed object, while a gadget is an object that
does not have its own window.  In the gfxobj system, we use gadgets in two
places, for buttons in menus and for pulldowns in a menubar.  (In the latter
case, the gadget is just the "title" part that is used to reveal the menu.) 
This decision was made because the behavior of a graphical object in response
to mouse events is attached to the window, and, while the phsyically a menu may 
resemble a column of buttons, its behavior is not that of the individual buttons.
Thus, it seemed natural to decide that the subcomponents of a menu are gadgets 
not widgets.  To make things easier on the user, however, this transformation is 
done automatically.  There is but one function to call for creating a button and 
this button can then be used alone, combined with other objects, or put in a menu.

And then there is the problem of linking together objects ... this part of the 
system is "ad hoc" as it says in "The Editor-view Structure" (pg.8).  The links
actually use a property field that is attached to all objects and store a list
of  key-value pairs.  The gadgets are also created with a property field and
thus when a transformation is done from widget to gadget this property field is
simply copied.  That is why your second function works, all the properties that
were previously set are copied, however, properties set after you've added the
corresponding gadget clearly cannot be caught.

	Hope this clears things up
	janet