janssen@parc.xerox.com (05/29/90)
I'm working on an inset view which parents an X window on top of the xim window. To manage this inset properly, it must get view_Remove `events' properly. I notice that when I embed my inset in a text object, visit the text object with ez, and then switch to another buffer in the same window, the inset does not get a call to view_FullUpdate(view, view_Remove, ...) until one switches *back* to the buffer, in which case one receives the view_Remove, followed immediately by a sequence which corresponds to the non-existent view_Emplace. When one scrolls the text in which my inset is embedded, it receives view_Remove properly. It seems from the code that someone is responsible for calling FullUpdate on textview, with type == view_Remove. What's actually happening is that buffer_RemoveView is being called, which in turn calls view_UnlinkTree, which in turn calls view_LinkTree. It seems to me that view_LinkTree should, when called with a parent of NULL, call view_FullUpdate on itself with a type of view_Remove. Comments? Bill
zs01+@ANDREW.CMU.EDU (Zalman Stern) (06/01/90)
[Bill Janssen proposes that view_LinkTree with a NULL argument should do a view_FullUpdate with type view_Remove.] FullUpdate should only be called by im, another FullUpdate routine, or an Update routine (after the visual area has been cleared). This is necessary since FullUpdate requires that there be a valid graphical context available. Synchronizing update routines to the interaction loop guarantees that the graphic and window system state will be valid. Therefore, a better solution to Bill's problem would be to fix frame to generate a view_Remove FullUpdate on the old view when the view is being switched. It is perhaps plausible that this could be piggy backed on the LinkTree/UnlinkTree protocol, but I'm not sure that it would work in all cases. The main problem here is that the view_Remove protocol (as well as the view_LinkTree, view_InitChildren, etc...) protocols were added after the fact to solve specific problems. All in all niether of them are particularly well integrated or supported (i.e. not all views do view_Remove properly). Sincerely, Zalman Stern | Internet: zs01+@andrew.cmu.edu | Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890 *** Friends don't let friends program in C++ ***
janssen@parc.xerox.com (Bill Janssen) (06/01/90)
Excerpts from ext.andrew: 31-May-90 Re: view_FullUpdate(view, v.. Zalman Stern@andrew.cmu. (1273) > FullUpdate should only be called by im, another FullUpdate routine, or an > Update routine (after the visual area has been cleared). This is necessary > since FullUpdate requires that there be a valid graphical context > available. Synchronizing update routines to the interaction loop guarantees > that the graphic and window system state will be valid. As you note, FullUpdate with view_Remove is really for a different purpose than FullUpdate. Perhaps a valid graphical context is only guaranteed if the type of FullUpdate is view_FullRedraw? > Therefore, a better solution to Bill's problem would be to fix frame to > generate a view_Remove FullUpdate on the old view when the view is being > switched. It is perhaps plausible that this could be piggy backed on the > LinkTree/UnlinkTree protocol, but I'm not sure that it would work in all > cases. Sounds good to me. The protocol problem isn't fixed by this, but it would solve my problem. Bill
zs01+@ANDREW.CMU.EDU (Zalman Stern) (06/02/90)
Bill Janssen <janssen@parc.xerox.com> writes: > [...] > As you note, FullUpdate with view_Remove is really for a different > purpose than FullUpdate. Perhaps a valid graphical context is only > guaranteed if the type of FullUpdate is view_FullRedraw? > [...] The problem with "mandating" this is that many FullUpdate routines don't pay enough attention to the type parameter. Therefore it is likely that calling a FullUpdate routine with type view_Remove while the graphic context is invalid will result in a core dump. Sincerely, Zalman Stern | Internet: zs01+@andrew.cmu.edu | Usenet: I'm soooo confused... Information Technology Center, Carnegie Mellon, Pittsburgh, PA 15213-3890 *** Friends don't let friends program in C++ ***