Pavel Sanda wrote: > since i had problem to get confirmed this problem under different archs > (some desktop managers use managers like klipper etc) i tried > to debug what is going on now.
klipper is crap, and any selection debugging with a running klipper is useless, because klipper messes everything up with some nonworking heuristics. > and many identical follow - all these messages appear during just by the > mouse selection of one single char 's' in point 1. > > for point 2 i got just single > GuiApplication.cpp(1446): X requested selection. > BufferView.cpp(1491): requestSelection: xsel_cache.set: 1 > > > two questions : > 1. i dont understand why we get those milions X requests only in case > we run two instances. > this point could also explain some hard to catch bugs with slow > performance because this X request appear only in this way. Fist some background: The X selection is stuffed on request. If you select something in an application the application advertises that it now owns the selection, and what formats (mime types) it supports. All other applications running on the same X server then have to deselect their selection (Actually some people do not want that deselection, and not all applications implement it, but this is the original design by the X people, and IMO a good one). This advertising is only a boolean flag, the contents of the selection is not sent to the X server. If you want to paste the selection contents in some application (primary selection by middle mouse button or secondary selection aka clipboard by C-c) the receiving application sends a request for the selection contents to the application owning the selection through the X server. The application owning the selection then sends the selection contents to the X server in the requested format. In contrast to the X selection the Qt model of the selection and clipboard behaves exactly like the clipboard of windows and OS X, i.e. there is no handshake but instead of the owner advertising it is simply filled with the selected contents. Therefore LyX does not use the Qt method of filling the selection, but implements the asyncronus way with some tricks (which are IIRC well documented in the code). Otherwise the selection of large parts of the text would be too slow. Filling the clipboard is done the qt way, because that happens only on explicit user request, and there is no performance problem. There should be a lot more details about this stuff in the list archives. Your observations could be explained with excessive selection polling by the second LyX instance. The reason could be that the second LyX instance detects LyX contents in the first LyX instance that it wants to syncronize. If this is true it is probably caused by the persistent selection feature, and it is a bug, because it is worse than using the stupid qt selection model. I don't know how the selection is currently supposed to work in LyX. When I implemented the original support of formatted selection/clipboard between different LyX instances I used only one selection request in the scenario you described. > 2. i don't clearly understand the purpose BufferView::xsel_cache and > there is no commentary in the code. i have just found we use some dirty > tricks with selection for performance reasons, but still don't > understand the whole machinery. but its clear that the working case > have xsel_cache.set bit == 0. IIRC xsel_cache is used to get the cursor slices of the selection when another application requests the selection. I am not sure whether such a cache is really needed, I believe that it is only useful if you want to get the selection after it was already deselected. Georg
