SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I wouldn't think so (or not very easily at all), since you would also need some facility for telling the WM what to do with the application window you were currently in.... basically you're trying to move the window you're in to another workspace, from the window you're in (since you can't very well switch to another desktop and leave the terminal window on the desktop you've left behind).
It may be possible, but definitely not under every WM, so I would first investigate the facilities of the WM you are using, and also the devilspie application. Using a combination of the two, you might be able to create an alias for the keybinding that switches desktops.
But it really seems like a lot of work when you can just move the window to another desktop with a keybinding or the mouse.
Just being curious what desktop are you using? The fact that you mention GnomeTerminal implies Gnome...
It is unlikely that you will be able to do it from a shell for the reasons motub outlined. FVWM has a command line console (FvwmConsole) that allows you to type in direct commands to the window manager, perhaps Gnome, or whatever desktop you are using, has something similar?
EDIT: Use preview button, use preview button, use preview button... must remember.
You don't have to, you know; if Gnome is installed, you can use gnome-terminal under any WM you like, and the panel and apps as well. I use gnome-terminal as the default terminal, along with gnome-panel, under Openbox3, and gnome-terminal under Fvwm (don't need the panel there, as the "fake" ones configured in the rc file are adequate).
If you could do this at all, one of those two would be the places to start looking (fluxbox experts can chime in here as well, as can pekwm, kahakai, and waimea users-- I'm just not as familiar with those WMs as I am with Openbox3 and, to a lesser extent, Fvwm). It does seem to me, though, that since desktops on fvwm seem to be more like "viewports" than differentiated desktops (though those are also available), than they are under DEs like GNOME or KDE, that a WM such as fvwm is more likely to be able to do this (if it is at all doable), than GNOME would.
Well I don't know af any way to do it from Gnome, I also did a little googling but did not find anything.
Motub it is a little off topic but FVWM allows pages, as in Pages in Gnome and KDE, and can even use the Gnome or KDE Pager. Pages are what you are referring to as "viewports." FVWM also supports multiple Desktops. The distinction between the two is that for any active desktop FVWM will have all pages mapped to memory, regardless as to whether a particular page has anything on it. If, however a desktop does not have any active windows then it will not be in resident memory. Put another way a single 2x100 page desktop will use more memory than 50 2x2 pages desktops provided at least some desktops do not have windows. I assume some other WMs have a similar setup, but in Gnome and KDE I always stayed on a single 2x2 desktop so I am not sure.
If you know how program in C you can always simulate keystroke with xlib to do ctrl + alt + arrow key.
man XKeysymToKeycode
and look at the /usr/X11R6/include/X11/extensions/XTest.h file closely for XTestFakeKeyEvent()
and take a look at
/usr/X11R6/include/X11/keysymdef.h to see the char codes in X
Mephisto, what's the difference between a page and a desktop, then (I really don't know)?
The thing I was thinking of (which I do know, but confuses the heck out of me), is that on Fvwm I can have a 3x3 page desktop (Desktop 0), which performs similarly to the pages on a GNOME or OB desktop, but if I then went to Desktop 1 in Fvwm, I would (presumably) get another 9 pages on that desktop, which-- afaik, I can't do in GNOME.
I do get it at this point what pages or viewports are in relation to the (virtual) desktop as a whole, but since most of the DEs/WMs just call them "desktops" to save my delicate sensibilities, I never know whether I'm actually using separate desktops, or just one with a lot of pages/viewports. Which clearly impacts on switching between them, even from my limited experience of trying to configure FvwmBacker to put different wallpaper on different pages on the same desktop, and also is related in some way (afaict) to EWHM compatibility and other relevant standards.
But am I mistaken in thinking that how the WM handles the various issues of multiple desktops (and whether they're really desktops, or "only" pages) has an impact on whether what Melinda wants to do is even possible, as well as how she would accomplish it (meaning that the methodology would change depending on how the WM managed the issue)?
Quick answer is that you can't have an application window span multiple desktops. On the other hand an application window can span multiple pages. Along a similar vein your physical screen (monitor) will always be on one desktop, though, again, it can display parts of up to 4 pages (based on geometry not a limitation of the system). Other than that it is just a matter of the way FVWM handles memory allocation and semantics.
As far as Melinda's question (sorry for going of topic again) as far as I know there is not a way to do it with any existing program. It might exist but the few times this question has been asked (found 2 others who asked for the EXACT same thing) there was no response at all. I am assuming that Gnome users have come in here and don't know of a way to do it.
If you bind the commands to specific keystrokes you could, as Cedrick suggested, write a commandline program to perform the operation. It would not even be particularly hard to write. Bind it to a config file rather than static keytrokes and it might even be useful for those quirky situations where you need to feed commands to an X session remotely.
EDIT: Don't count FvwmBacker into your cost of switching desktops, that is simply the pain of writing an image to root. Turn off FvwmBacker and simply write a wallpaper to the background at init and you'll see what I mean. FVWM does not handle changing wallpaper images particularly well, either between pages or desktops. It handles gradients and solids better but what's the fun in that?
While I feel it would amost be borderline massochistic to do this way you might be able to accomplish what you want using a bash script and xtrapin. I might be wrong, never even heard of xtrapin before oh, 5 minutes ago. But looking through the man page it looks thoretically doable.,
Here is the reason why I ask very weird question:
First look over here: http://wallpapoz.sf.net
Here is how I do it: my daemon program check every seconds the output ( stdout ) of this program:
xprop -root _NET_CURRENT_DESKTOP
Basiclly it will tell you where ( workspace /virtual desktop ) you are in now. So when user change the workspace the value of xprop blabla will change then my daemon program will change the wallpaper. Ok, it is simple. But it is hell stupid. It take too much cpu usage. So I decided to change the algorithm beside improving the user interface of my program.
I have 2 idea to reduce cpu usage:
1. I make my daemon program sleep or in wait condition. If the user change the wallpaper, "somehow" it send signal to daemon program. Daemon wake up and change the wallpaper. I want to do this way. But hell, yeah, I don't know how to do it. I have read the source of workspace switcher. I got no clue. I have send email to the programmer of workspace switcher. No luck. I gave up.
2. I make another workspace switcher. The idea is simple. When you click ( assume you have 4 workspace ) one of the rectangle of my workspace switcher clone program ( I make the similar user interface ), it will execute ( forking maybe ) "the command to change the workspace". Without forking "the command to change the workspace," I don't know how to change the workspace.
Thank you.
I think after reading this thread ( especially Cedrik suggestion ), I can do it by the second way although I want it so bad to do by first way. Do you know how to do by first way ( send signal )?
OK, this is funny--- you mean this is all about getting per-workspace wallpaper as well?
Maybe we just all should give up and use KDE.
Or, as I'm now starting to think, create a gigantic mural wallpaper of the set of walls you want to use, and then when you switch pages/viewports/desktops, the wallpaper would seem to change as well (but all that would really happen is that the viewable area of the merged wallpaper would change, so you'd be seeing a different wallpaper background, but it would really just be a different part of the same one).
Of course that would require a static (virtual) desktop size, and a static number of pages, but it's starting to sound easier than pretty much every other option I've come across.
Melinda, why don't you try reducing the NICENESS value of your daemon so it doesn't work at such a high priority (thus taking up less CPU)?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.