Hi,
On 28.01.2014 17:57, wu, sa wrote:
> Is it possible to force windows spawned by
> programs/processes/scripts, to stick to its parents workspace/tag?
What exactly do you mean by programs/processes/scripts? Script sounds like a
shell script to me and shell scripts don't really have a tag.
> I have some programs/scripts, which run for a while and at some point
> spawn (and sometimes keep spawning) windows..., e.g.
> plotting/rendering stuff that just takes time.
>
> Normally, these new windows just appear on the tag I currently work on,
> which is really annoying...
>
> As far as I have experienced, the download dialogs of the chromium
> browser already do what I want: automatically stick to the tag, where
> chromium is running, regardless of where my focus currently resides.
If you want me to guess: Chromium's download dialog have the WM_TRANSIENT_FOR
property set and pointing to chromium's main window. This tells awesome that the
dialog belongs to chromium and the following code from awful.tag then does just
what you want:
capi.client.connect_signal("manage", function(c, startup)
-- If we are not managing this application at startup,
-- move it to the screen where the mouse is.
-- We only do it for "normal" windows (i.e. no dock, etc).
if not startup and c.type ~= "desktop" and c.type ~= "dock" then
if c.transient_for then
c.screen = c.transient_for.screen
if not c.sticky then
c:tags(c.transient_for:tags())
end
[snip]
(If a new client has transient_for set, move it to the screen and tag of its
transient_for)
> Is there some way to configure awesome to do this for every new window?
Nope, because awesome always does this. However, it seems like whatever
programs/processes/scripts you are using don't set the WM_TRANSIENT_FOR
property. If this is the case:
How would awesome know that the clients belong together?
> And no, I don't want to force all windows of one particular program to
> one predetermined tag.
>
> Thank you all and Best regards from Bonn,
> Sa.
Cheers from Oldenburg,
Uli
--
<alanc> I think someone had a Xprint version of glxgears at one point,
but benchmarking how many GL pages you can print per second
was deemed too silly to merge
--
To unsubscribe, send mail to [email protected].
