You are not logged in.
Here's what I want to do:
$ export DESIRED_VIRTUAL_DESKTOP=3
$ gimp &That should open Gimp and all its child windows on virtual desktop number 3.
I guess one could script something using wmctrl looping in the background, but looks cumbersome.
Offline
feklee, this is the third thread you've opened with a vague reference to the same question. Please clarify your real intent. It seems every single one of your thread is a form of X-Y problem - and I am only now getting a vague idea what you really want to do [1].
As for environment variables, that could never work. That's not how environment variables work - the WM would never see the change in that variable. Any acrobatics you could imagine to allow a window manager to see environment variables would be the hardest possible way to solve the problem. Window properties on the other hand are probably exactly what you want ... maybe ... but I don't really know what you are trying to do.
[1] Please see the following:
http://www.perlmonks.org/?node_id=542341
http://www.catb.org/~esr/faqs/smart-que … dp42947840
-- reopened upon request and moderator discussion --
Last edited by Trilby (2015-04-07 00:54:16)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Please clarify your real intent.
For a specific user, whose habits I'm accustomed with, I am in the process of setting up a particular desktop environment, and I'm looking for the bits and pieces. I don't expect one window manager to do all that is needed. My plan is to decide on a window manager that does one thing best, then augment it with 3rd party tools. Creating a single forum post with lots of different questions makes no sense, at least from my perspective.
As for environment variables, that could never work. That's not how environment variables work - the WM would never see the change in that variable.
Well, just figured out a way to get the environment of the process that created the window with ID 0xa00022:
$ cat /proc/$(xprop -id 0xa00022 _NET_WM_PID | sed "s/.*= //")/environOne could start from there, or perhaps there's a WM that already has something related built in.
reopened upon request and moderator discussion
Thanks!
Offline
In i3 you can do the following:
i3-msg 'workspace number 9; exec /usr/bin/spotify'which executes Spotify on workspace number 9.
Further you can assign window classes to specific workspaces: https://faq.i3wm.org/question/2135/open … and-focus/
Not sure about other WMs though.
Last edited by MK13 (2015-04-07 15:27:19)
Offline
In i3 you can do the following:
i3-msg 'workspace number 9; exec /usr/bin/spotify'which executes Spotify on workspace number 9.
Further you can assign window classes to specific workspaces: https://faq.i3wm.org/question/2135/open … and-focus/
Not sure about other WMs though.
I think most modern WMs do this. I know that openbox and Kwin (the KDE4 version at least) have this possibility and I would be surprised to find a full featured tiling WM (like i3, xmonad or awesome) without this possibility. Don't hold me to this though, as I did not test all WMs, nor did I ever set up something like this (out of my own free will).
Also keep in mind that sending a window to a specific workspace after opening via a keyboard short-cut can be set up quite easily.
Offline
Also keep in mind that sending a window to a specific workspace after opening via a keyboard short-cut can be set up quite easily.
If it was for me, then that would be a good solution. However, it's not for me. I am setting up a window manager for another user, and I want to avoid that he opens an application on one desktop, and then it appears on another one, or any child windows. On every desktop there will be a shell to start applications, and inside of this shell I could set a per-desktop environment variable, for example $DESKTOP_NUMBER.
Offline
However, it's not for me. I am setting up a window manager for another user, and I want to avoid that he opens an application on one desktop, and then it appears on another one, or any child windows.
I think you better think about application specific workspaces. Then e.g. texteditors open on the "text" workspace, the browser windows on the "www" workspace, and so on.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' | alias ENGLISH='LANG=C.UTF-8 ' |
Offline
I am setting up a window manager for another user, and I want to avoid that he opens an application on one desktop, and then it appears on another one, or any child windows. On every desktop there will be a shell to start applications, and inside of this shell I could set a per-desktop environment variable, for example $DESKTOP_NUMBER.
Please explain why you want to do this and what the situation is. Maybe we can come up with a better/easier solution.
A few comments you can think about:
Most window managers will open pop up windows in the same workspace as the parent window. So, it might be easier to just tell the user to only open the needed program where they need it.
The method you want to employ seems to take the learning experience away from the user. This means that they will always lean on you to help them with problems. Maybe you will be better off to just teach them an easy WM/DE?
The introduced complexity of a script or WM config will cause problems along the way (and goes against the Arch Way
)
I think you better think about application specific workspaces. Then e.g. texteditors open on the "text" workspace, the browser windows on the "www" workspace, and so on.
This is probably easier (and more predictable) than setting up a script to move windows around. The only problem I have with doing this kind of stuff is that new programs will have "undefined" behaviour from the users point of view.
Offline
I think most modern WMs do this. I know that openbox and Kwin (the KDE4 version at least) have this possibility and I would be surprised to find a full featured tiling WM (like i3, xmonad or awesome) without this possibility. Don't hold me to this though, as I did not test all WMs, nor did I ever set up something like this (out of my own free will).
XMonad is certainly happy with it, here's a snippet of config:
, appName =? "mail" --> doF (W.shift workspace4 )
, appName =? "mutt" --> doF (W.shift workspace4 )
, className =? "Mutt" --> doF (W.shift workspace4 )
, appName =? "irc" --> doF (W.shift workspace2 )
, className =? "irssi" --> doF (W.shift workspace2 )
, appName =? "irssi" --> doF (W.shift workspace2 )
, appName =? "music" --> doF (W.shift workspace5 )
, className =? "mpd" --> doF (W.shift workspace5 )
, appName =? "spotify.exe" --> doF (W.shift workspace5 )(It happens to be that workspace 2 is named 'irc', 4 is 'mail' and 5 is 'music'.)
I've also got a one-liner bash executable called 'music', which runs:
urxvtc -title mpd -hold -name music -e /usr/bin/bash -c 'while true; do ncmpcpp; clear; echo -n "Restarting ncmpcpp in "; for x in {3..1}; do echo -n $x"..."; sleep 1; done; done'The '-name' argument provides the necessary match with appName in the XMonad config. (I presume that screen/tmux/etc. could be another option for something like this.)
Offline
Most window managers will open pop up windows in the same workspace as the parent window.
Thanks for pointing that out. I just executed in wish:
sleep 5; tk_messageBox -message "Hello world!" -type okThen I switched to another virtual desktop in FVWM, and - yes - once the message box appeared, it showed up on the same desktop as the original wish window. In fact FVWM switched me to this desktop, a behavior I believe that can be deactivated.
Offline