Wow, I caused quite a comotion here :) I hadn't considered the
implications of multi-headed consoles when I thought about this. However,
think about this way. The primary purpose of the viewport lock is to keep
from scrolling the current window off the screen, right? If so, then why
not make the scroll lock global? No viewports scroll with the scroll lock
ON, and the current viewport the pointer is over will scroll with the
lock OFF. When the scroll lock is ON, the viewport will not scroll the
virtual desktop when the pointer hits the viewport edge. Instead it will
either (1) not scroll on a single head console, or (2) hop to the next
head/monitor on a multiheaded console. I know this makes two features to
implement, not one, however. As for using the scroll lock key vs a hotkey
sequence, I only hold to using the "scroll lock" key because of how intuitive
it is to users, and because we are basically trying to implement what
the scroll lock key does in a virtual console already.
I am new (<1 week) to this mailing list and know next to nothing about the
code to the X server. I certainly dont mean to be making tons of work for
others ;) Let me know where I can help...
On another note, somebody earlier this week mentioned that they were
working on this. Here's the message for those that missed it:
Date: Wed, 17 Jul 2002 23:33:43 +0200
From: Lionel Ulmer <[EMAIL PROTECTED]>
Subject: Re: [Xpert]Interest in writing code for pan/scroll locking the
viewport in X
Well, what a coincidence, I just started to work on that on monday
(without reading this thread as I need this for a project of mine)...
I should have a patch ready tomorrow (or on Friday, depending on my
free time :-) ).
What I planned to do is to add a function called 'XF86VidModeLockViewPort'
that would enable one to prevent the viewport to scroll when the mouse it
at the border of the screen (if the parameter is True, if False, let
the scrolling happen).
Lionel
-Chris Len
[EMAIL PROTECTED]
Student Systems Manager
Information & Media Technology
Azusa Pacific University
> To: [EMAIL PROTECTED]
> From: [EMAIL PROTECTED]
> Subject: Re: [Xpert]pan locking / sroll locking the viewport in X
> Date: Thu, 18 Jul 2002 21:31:11 -0700
> Reply-To: [EMAIL PROTECTED]
>
> > 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
