Re: Widget design [was: Should --with-widgets be the default?]

Andy> I am constrained by the specifier implementation. Logically Andy> there should be one per frame but this will not work for Andy> widgets instantiated in a buffer (because you might need to Andy> display a widget in two windows at once). Even if this were Well, so? All this means is that you have to divide the logical (Lisp, specifier) representation of the widget from the ws-object that actually displays it. We can reuse a glyph from a font hundreds of times in a single X window, but we have to blit the pixmap to the screen once for every time the glyph is used. (Consider changing the font of the current face as an example of the kind of thing I'm talking about.) Do we need to keep a copy of the font cached for every instance of that glyph in the window? Of course not; we just keep the character, which is sufficient information to reconstruct each region of the window covered by that glyph. Similarly, an instantiator for a tabs widget glyph in principle could simply be a list of strings. I'm suggesting that we keep a list of already allocated tabs ws-widgets for each Emacs frame == X window. Then the redisplay process becomes (1) grab a free one, (2) set the geometry of the ws-widget, (3) set the number of tabs, (4) set the label strings, and (5) free it when the the Lisp level glyph doesn't need it any more. This would be efficient for the buffers tabs case. There would only ever be one such widget per frame. There should be no problem with geometry negotiation as geometry should not change. (And if there is, we could arrange that "freeing" the widget when the Lisp object doesn't need it doesn't involve unmapping/unmanaging it immediately so that no negotiation would occur except that necessary to deal with changing labels anyway). Step (5) would occur automatically when the frame's current buffer changes, so that when the new buffer went to allocate one of these guys, it would find the previously used one sitting there waiting for it. And everything else you do would be just the same as currently. The point is that the Emacs frame would manage the free list, not the tabs widget itself. As for the tabs widget making sure it always knows which buffer's list of strings is supposed to be used, we have to do that anyway. That's where this thread came from in the first place. Andy> not true you would have to make a decision about what domain Andy> you want to cache widgets in. That decision will inevitably Andy> screw someone without changes to the specifier Andy> implementation. Or to the widget/subwindow implementation. But at this point you have made the decision that a given glyph can only be displayed once in a given Emacs windows, AFAICT. Suppose I want a background of tiled duplicates of a progress gauge? Andy> Que? [I'm at 39,0000 feet on my way to Lison, Portugal and Andy> the in-flight cuisine was very, very good [Not sure about Andy> the plane]]. I meant kept on a free list so they can be reused. As described above. Andy> Maybe. I'm caching on a glyph basis now which I think comes Andy> close to what you are describing. No; that would be like saying you can only use one copy of the letter "A" per Emacs window. We don't cache character bitmaps because blitting a bitmap from a font to the screen is the cheapest possible operation in a graphical window system. We do cache image pixmaps because decoding a PNG (eg) to an X11 pixmap is an expensive operation. But we can blit that pixmap to the screen repeatedly; we don't keep a copy for every frame or window. We only add new pixmaps to the cache (a) if they are instantiated differently (because the device is different) or (b) if the specifier instantiator itself differs (such as buffers that use different colored bullets for the same level of bulleted list). As far as I can tell, once a tab ws-widget has been allocated, changing the number of tabs and labels is very cheap. And I certainly can't see how it is cheaper to unmap one ws-widget, change the other, and map it. So there is no need to cache the ws-widget in the Lisp buffers tab control glyph, only the instantiator, which is a list of strings. When the glyph wants to display itself, it should put itself somewhere where redisplay will find it. Then redisplay will construct a rune for it, which involves (1) asking the Emacs frame if there is a ws-widget waiting for it, and (2) allocating one if not. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."