Re: [gtk-list] Re: Should there be a call to make a window "active"?

[Drazen Kacar <dave srce hr>]

Guy Harris wrote:
> > Window managers intercept map requests from clients and then do whatever
> > they were configured to do. I'm not sure if _NET_ACTIVE_WINDOW is intended
> > to bring a window from another workspace to the current one. If it is,
> > somebody should add a note about that to the spec.
> 
> Would that be something that'd be considered window manager policy, i.e. 
> window managers could bring the window from another workspace to the
> current one, or switch to the workspace containing the window?

I'm not sure. In case of Netscape and some taskbar, I (as a user) would want
bookmarks window to be brought into the current workspace, but if I selected
some regular Netscape window, I'd want a switch to the workspace containing
that window. Both goals cannot be achieved with the same _NET_ACTIVE_WINDOW
request, as currently defined, although there probably should be a way
to issue both kinds of requests, without reconfiguring WM in between. So I'd
say it's an unfinished draft specification.

> > I'd be happier if Netscape (and other similar applications) would create
> > a new window (which would automaticly get a focus if WM was configured to
> > do so), then transfer widgets from the old window to the new one and
> > then destroy the old window. I'm not sure if this is possible with GTK.
> > Probably gtk_container_remove() could be used, but it's currently somewhat
> > underdocumented.
> 
> I presume what you really want is to have the window pop up in your
> current workspace, with the suggestion above being a way of achieving
> that.  It seems like a bit of a cumbersome way of achieving that goal,
> though.

It is cumbersome, but I don't know what else could be done and work nice
with all WMs. Things like focus management and colormap policy are under
WM control and applications shouldn't interfere. There might be some
special cases where it's justified, but I don't think this is one of them.
Particularly because you cannot insure mapping, so you cannot call
XSetInputFocus().

If you just map the window, it would appear in whichever workspace it was
before. If that is a response to user clicking on some kind of "show me
that window now" control, then it's probably not the best response.

Granted, if the user actually wanted a switch to the workspace containing
the window, the method above would do the wrong thing. But then, WMs with
virtual workspaces or desktops should have an easy way of switching, so if
the user wanted a workspace switch, I assume he'd use one of the WM controls,
not an application control.

-- 
 .-.   .-.    I don't work for my employer.
(_  \ /  _)
     |        dave@srce.hr
     |        dave@fly.srk.fer.hr