Stewart Allen wrote:
>
> On Tue, 11 Mar 1997, Rick Macdonald wrote:
>
> > As the focus follows the mouse from one toplevel window to another, the
> > "Widget" name (and the "Alias") in the "Widget Info" window changes
> > accordingly to the toplevel of the window that the mouse is in, but the
> > "Insert" field doesn't change until you click in another toplevel
> > window.
>
> Rick,
>
> This is undoubtedly an artifact of your window manager (fvwm, I
> presume) and your focus policy.
Yes, I use fvwm on my Linux box. I haven't installed vtcl at work yet
(Solaris 2.4 with CDE). I use fvwm2's "SloppyFocus", which is
focus-follows-mouse policy with the cool additional feature that the
focus does _not_ follow the mouse when the mouse moves somewhere that
doesn't respond to the keyboard anyway, such as the root window. Thus,
you can move the mouse out of the way without losing focus by moving it
to the root. Then, with 24 virtual desktops ;-), I rarely have more than
one window per desktop anyway! Except vtcl has many going...
> I have had a great deal of difficulty
> with toplevel selection and the interaction with tk and window
> managers. Here's the kicker, if you want to consistently select a
> toplevel as insertion point, you must click on the background of the
> toplevel.
This is OK. That what I do and what I expected...
Let me stress that I like the current behaviour of "insertion", it's all
of the other vtcl windows that I'm talking about now (info, geometry,
editor).
> People's expectation, though, is that clicking the titlebar
> of a window makes it active. It's nonintuitive to have the insertion
> point be a window which is not active...
Ahhh...with my focus-follows-mouse policy, I never click on the
titlebar.
> and this is what I struggled
> with from 1.07 to 1.08. The inconsistency arises with window managers
> reporting of window selection to tk. If you click on the titlebar of
> a window that is not active which becomes active, there is no distinct
> event for this. In fact, it generates several events. I've made a
> best-guess approach at this and I'll have to review the code for the
> specifics, but now that I think about it, I can see how it is causing
> you problems. I do not use the focus-follows-mouse policy so I would
> never see this.
Hmm. I appreciate the problem of different window managers, etc.
Being newish to vtcl, I don't know the history of this issue with other
users.
I guess what I'm saying is intuitive for me is that the contents of all
of vtcl's windows (widget info, attribute editor, geometry) are always
one thing only: the last widget that I clicked on. Except for toplevels,
this widget is specifically marked in standard-fashion with the black
squares in the corners. Therefore, window _focus_ is not an issue. The
black-square widget highlighting tells me what has filled the editor
windows, and the "Widget Info - Insert" field tells me what has the
insertion, which is either the widget that I just clicked on or it's
parent, as we discussed already. So, if the only thing that ever resets
any of these windows is
clicking on a widget, it should work with any kind of wm focus policy.
Clicking on a title bar would do nothing, but select that window, just
as passing the mouse through the window with focus-follows-mouse would
simply select that window briefly without changing anything that vtcl
shows in any of its windows.
focus-follows-mouse is certainly dangerous at the moment. Another
example:
Click on a widget, then, on the way to the main menubar, pass through
some other top-level. Select Edit/Delete (or cut). What gets deleted is
not the widget that you clicked on which even has it's black squares in
the corners, but the entire toplevel that the mouse passed over! :-(
Surely most people would agree that the widget with the black-square
highlighting should be the object of attention of _all_ vtcl windows and
menubar actions?
Perhaps part of the current inconsistency is that the black squares
don't go away when I move the mouse into another window? They don't go
away until I actually click somewhere else, or, and this is strange:
- click a widget
- move a mouse into another toplevel
- now grab the titlebar of _any_ toplevel and drag/move. When you
release the mouse button, _then_ the black-square markers get removed
from the original widget clicked. (this is focus-follows-mouse behaviour
only).
OK. I'm at work right now, logged on to my Linux box at home over ISDN.
I just changed my Solaris CDE to be click-to-focus. This appears to
behave much better at first since the focus doesn't change as I move the
mouse around. However, this inconsistency still exists:
- click a widget in one toplevel
- click the titlebar of another toplevel
- Inserting happens back in the first toplevel where the black-squares
are
still highlighting the widget, but Edit/Delete operates on the
toplevel
that had the titlebar clicked.
Unlike focus-follows-mouse, with click-to-focus it's a bit harder to
make the widget-highlight go away after moving the focus to another
toplevel by clicking on the window's titlebar, but you can do it without
clicking some widget by clicking around in other vtcl windows like
attribute editor or the "toplevel" control window. For the most part,
the two focus policies seem to work the same if I substitute clicking
the window title-bar in the click policy for the mouse movement in the
follows policy. Therefore, I feel that all of the above issues are
equally valid points for both environments.
So, am I advocating old behaviour that you've gone away from, or is this
a new model that hasn't come up before?
--
...RickM...
