1.1
When I enter the full screen mode, how can I switch back from
full screen mode? In which bindings section I must enter the
"enter_fullscreen FALSE" command?
1.2 How do I specify programs to run when Ion starts up?
Start them from .xinitrc, .xsession or whatever file you started Ion from depending on your configuration.
1.3 How do I get these programs to show up in the frames they were previously in?
Short answer: you can't. Without session management support from both the applications and the WM it is not otherwise possible to uniquely identify windows and programs between sessions. Few applications and even fewer that should be of any interest to Ion users properly support session management. While there is a session management module for Ion1, Ion2 doesn't have one.
Long answer: In Ion2, it is possible to use winprops to map window classes to certain frames. This, however, will not work for individual windows and will affect programs started while Ion is running. See the section on winprops in the document "Ion: Configuring and extending with Lua" for details on setting up the winprops.
1.4 How do I save frame layout?
Ion does it automatically for you.
1.5 How do I move windows between workspaces?
You do this as you would move windows between frames on the same workspace:
1.6 How do I change the background image in Ion (PWM2)?
That is not a feature a window manager should have! There are dozens of excellent specialised programs that can you can use to set the background, for example, the display -window root command of ImageMagick.
1.6 How do I create a "floating workspace"/WFloatWS.
RTFM.
F9: Go to existing workspace or create new (query). If a non-existent workspace was entered, the type of the workspace to be created will be queried as well.
1.7 Ion uses the same Alt+n (n=1,2,...,0) keys for changing workspaces as Irssi channels. How can I change that?
The easiest solution: use Esc n in irssi instead. In a terminal emulator, Alt/Meta+key actually often sends the Esc key combination to the application, so these two are the same. Alternatively modify Irssi's settings or Ion's settings. To modify Ion's settings, copy ETCDIR/ion-bindings.lua to ~/.ion2 and modify the bindings that call WScreen.switch_nth.
1.8 Can I restart Ion remotely? Sending it SIGHUP kills it.
Try SIGUSR1. Ion should not restart with SIGHUP as it is not a daemon, and may have a controlling tty depending on how it has been started.
2.1 I want my system monitoring programs visible on all workspaces. Will Ion support sticky windows? Will there be a dock?
There's a simple stays-on-top dock module, but one that adapts to the workspace layout should also be written. (There have been numerous attempts at a too simple patch that only reserves a band of the screen for such programs.) General sticky windows will most likely not be supported as they do not really fit the Ion workspace model.
2.2 How can I have Ion perform this particular action I have in mind?
Ion2: The document "Ion: Configuring and extending with Lua" should help you find a solution to your problem. Use the Index or List of functions to search for what you have in mind.
Ion1: Read doc/functions.txt carefully. If what you have in mind is not found there, it probably isn't possible in that version of Ion.
2.3 I want a feature in Ion. Will it be implemented?
The best way to get your wanted feature in Ion is to first ask if I'm willing to include it and then write a patch yourself -- unless the feature is simple enough so that I can write it in a few minutes. "Big" features will almost always be requested to be implemented as modules if at all possible.
2.4 Will Ion support the mouse?
It does.
2.5 Will Ion support shaped and/or borderless windows on floating frame workspaces?
Absolutely not. It is the window manager's job to manage and decorate windows in a consistent manner, not the application's. All those shaped and skinned multimedia players that want to override the window manager are brain-damaged usability hindrances and should not be used by anyone.
2.6 How well does Ion support Extended WM Hints/KDE/Gnome?
See this posting on the Ion mailing list.
2.7 It would be nice to be able to nest a "floating workspace" within a tiled frame.
Ion can do this, and a lot more! There are very few limits in what kind of objects can be placed within others. To create a nested WFloatWS, you can enter the following code int he Mod1+F3 (in the default bindings setup) Lua code query:
_:attach_new({type="WFloatWS"})(In the Lua code query, "_" is a reference to the frame in which the query was opened.)
3.1 My XTerm is 80x24 while the frame is much bigger/Program Y doesn't resize to fit the frame.
This is (most likely) a bug in the program in question. It seems that some programs expect the initial size of their windows to be that requested and ignore early size change events. But this is exactly what Ion does. Inform the authors of the program in question that their software if broken and not complying with the ICCCM. In case of XTerm the problem is due to an internal race condition between two processes. There is a fix to xterm but it seems that every second release of XFree86 is broken again. See the Wiki for more information and the patch.
3.2 Wouldn't it make more sense if windows were attached to the frame where the program was started from instead of the current frame?
Indeed it would. There's just no generally viable way to do this without application support.
3.3 When I open a dialog from application A Ion starts quickly switching between this dialog and the main window.
The application is flawed and tries to manage its dialog windows instead of letting the window manager do its job: the dialog doesn't have the transient_for hint set and when Ion displays this window, it unmaps (hides) the main window. The broken application now thinks that the user wants to hide the whole application instead of just the main window and therefore unmaps the dialog. But as the dialog is unmapped Ion switches back to the main window and now the application wants to show the dialog too. We have a loop.
See the configuration manual for details setting up the "acrobatic" winprop to fix this.
Also see entry 3.8 for another kind of flashing problem.
3.4 Why doesn't mozilla/netscape/whatever -remote work? Why xprop and xwininfo do not work on transients?
The browsers seem to check the first (lowest) window in each window manager frame for whether it is owned by a previous instance of the program. Xprop and xwininfo also use the lowest window in the window manager frame that was clicked on for the window to display information on. Ion arranges for the viewed main window to be the lowest so that the window info application will work for the main window but being stupid will fail for transients. Similarly the browsers will fail if they have no window visible in any frame. Why the window info tools don't find the child window of the WM frame that was actually clicked on and why the browsers look for their windows in such a manner (as far as I know, the ICCCM sets no limits on how many client windows are allowed in a single WM frame or how many levels of WM windows there are) and don't use e.g. root window properties is beyond me.
Instead of mozilla -remote, you could use the gnome-moz-remote tool. It seems to use a saner method for locating an already running Gecko browser and should work with Mozilla Firefox/Firebird/Phoenix, Galeon and maybe other Gecko-based browsers as well.
3.5 Dialogs appear in the wrong frame or alone as a new main window instead of at the bottom of another window that the dialog is supposed to have sprung from.
Again, blame the program in question for not setting the transient_for hint correctly. You should ask the authors of the program in question to fix it, but in the meanwhile, you could experiment with the transient_mode winprop. (Note that Ion does not and will not support the "Extended WM hints" brain-damaged in-violation-of-ICCCM multi-parent transient notion.)
3.6 Dragging windows from floating to other workspaces doesn't seem to work. I'm using the default bindings.
You're trying to do this using the left mouse button, right? On floating frames the left button is bound to move the frame, not drag tabs. You must use the middle button to drag tabs from floating frames. (No, there's no inconsistency in bindings; middle button drag also works on tiled frames, but since they can't be moved, so does the left button.)
3.7 When I drag a tab from frame to another, the screen becomes cluttered. I'm using the XFree86 'nv' driver.
This is a bug in the driver. Switch to the proprietary drivers, disable acceleration or see if the problem has been fixed in a newer version of XFree86.
3.8 A program is not responding to anything after having mapped (made visible) a window under Ion. Either graphics are also not updated on the window or they're flashing rapidly.
The program may be fighting with Ion over window size. The ICCCM says:
The response of the client to being resized should be to accept the size it has been given [by the window manager, if any] and to do its best with it. Clients must not respond to being resized by attempting to resize themselves to a better size. If the size is impossible to work with, clients are free to request to change to the Iconic state.Thus, if this fight is the source of trouble, the program is not conforming to the ICCCM. It is therefore seriously broken and should be fixed.
3.9 Focus does not seem to be set correctly when there are multiple Mozilla (Firefox) windows in a frame.
Get gtk1 version of the program. Either gtk2 or Mozilla/gtk2 is broken and does not handle the WM_TAKE_FOCUS protocol correctly.