> On Thu, 18 Jul 2002 [EMAIL PROTECTED] wrote: > > > > On Wed, 17 Jul 2002, Christopher A Len wrote: > > > > > > > Is there a way to lock the viewport from panning to other areas of the > > > > virtual desktop? Normally, I run 1152x864 desktop and 1152x864 viewport. > > > > However, I want to be able to zoom in on a window (eg change viewport to > > > > 640x480 or 800x600), and keep the viewport from scrolling when the pointer > > > > hits the screen edge. Is there a way to do this? I tried scroll lock, it > > > > had no effect. My keyboard map is us104. Any feedback would be > > > > appreciated. I cant imagine something like this hasn't been implemented > > > > yet... > > > > > > > > > > We've discussed this years ago. It's possibly not difficult to > > > implement either. Nobody seemed to care enough about it to do this > > > though. Somebody would have to care enough about it to volunteer > > > to do the work. You perhaps? > > > > I actually had this working in my tree at home a couple of years ago. > > That is, I could move the viewport, press ScrollLock, and then the viewport > > was locked in that position until ScrollLock was pressed again. There > > were some complications though: > > > > 1) There needed to be a way to configure which key controlled the viewport lock > > > > 2) A client-side interface would have been useful. For example, a window manager > > could receive an event when the viewport was locked and remap the positions of > > windows to fit within the visable viewport. Or it could have initiated the > > viewport lock. Maybe allowing a client to enable/disable the effect of the > > ScrollLock key would have been nice. > > > > 3) How do you mix it with Xinerama or even plain multi-head configs? Should > > moving the mouse to the edge of the viewport trigger a switch to another screen? > > > > It's not clear what the best behavior is. Also, when one modeswitches, > that modeswitch goes into effect on the head the pointer is on at that > time. The Scroll-lock key, however, would imply a global action, not > a head-specific action. Maybe another hotkey would be better than the > scroll-lock key.
Ah, yes, I thought of that at the time, but had forgotten about that problem. It could be resolved by a good implementation of a client lib (item #2 above) together with a client that allowed you to configure what triggered a viewport lock on each screen. Alternatively, I suppose you could just (un-)lock whichever screen had the pointer at the time, but this kind of thing leads to parts of the server needing access to data structures that aren't intended to be accessed by other parts. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
