This is the problem. Also for twm one needs to learn and discover it by carefully reading the man pages.
This is the reason because I do not use cwm, I never found the time to learn it. Also the reason because
I do not use fvwm in FreeBSD: it is not nicely configured like in OpenBSD and I do not know how to
configure it. But fvwm is too big.
jwm seems not to have a big screen like vtwm or fvwm, but 4 (or more?) independent desktops. Perhaps
it is like cwm with its grouped windows? It is a different principle.
f.move This function drags an outline of the selected window (or the
window itself if the OpaqueMove variable is set) until the in-
voking pointer button is released, at which time the window is
raised (subject to RaiseOnStart, MoveDelta, and NoRaiseOnMove).
Double clicking within the number of milliseconds given by Con- strainedMoveTime warps the pointer to the center of the window
and constrains the move horizontally or vertically, depending
on pointer movement. To abort the move, press another button
before releasing the invoking button.
f.movescreen
Moves a window (or possibly the real screen) inside the desktop
display. To abort the move, press another button before releas-
ing the invoking button. By default, the bindings using the desktop context are defined as:
Button1 = : desktop : f.movescreen
Button2 = : desktop : f.movescreen
This is useful if you want to reset the default keyboard and
pointer bindings via NoDefaultMouseOrKeyboardBindings and use
some of your own for the virtual desktop, e.g.:
NoDefaultMouseOrKeyboardBindings
Button1 = : desktop : f.movescreen
Button2 = : desktop : f.warp
Button3 = : desktop : f.iconify
This function is not useful under any context other than "desk-
top".
f.panelmovegeomstring
This function moves the selected window to the location denoted
by the extended geometry specification geomstring as described
in IconManagerGeometry. Geometry aliases left, right, top, bottom (e.g. "left@pointer", "top@1", etc.) denote the window
is to be moved and aligned to the left, right, top or bottom
edge on the specified target panel. A relative shift by (X,Y)
of the selected window can be specified by "[01]x[01]+X+Y@P"
analogously to the description in f.panelzoom below.
f.panelzoomgeomstring
This function enlarges the selected window as denoted by the
extended geometry specification geomstring described in Icon- ManagerGeometry. Accepted are left, right, top, bottom, verti- cal, horizontal, full and maximize as geometry aliases in order
to perform a zoom operation analogous to f.leftzoom, ..., f.maximize but restricted to the target panel specified by @P
of geomstring.
The non-aliased geometry string is used to denote relative zoom
by (X,Y) pixels and has the form "[01]x[01]+X+Y@P", i.e. W, H
having values 0 or 1 denoting if the X or Y component (or both)
is to be considered in the following zoom operation. If X (or Y) is positive, the right (or bottom) edge of the selected win-
dow is moved that many pixels to the right (or bottom). If X
(or Y) is negative, the left (or top) edge of the selected win-
dow is moved that many pixels to the left (or top) accordingly.
If X (or Y) is zero, then the corresponding window edge, left
or right (top or bottom) depending on the '-' or '+' of X (or Y), is taken to the appropriate panel edge. The special value "-0-0" of geomstring can be used to restore the original window
size and location after repeated execution of the geometry-
based zooming. Analogously "+0+0" overwrites the saved origi-
nal size/location with the current values of the window size
and location. (For values e.g. "0x0+0+0@next" the window is
only moved to the specified panel without changing its size,
keeping its relative location as on the source panel if possi-
ble.)
This information is difficult for me to understand and implement, as I don't see the connection between that and trying it with my mouse (which it seems the bindings can be adjusted to be keyboard). This is something that needs more focus in a topic for window manager caveats.
On most window managers, the number of workspaces can be adjusted. I usually adjust mine from 4 to 2. In my JWM screenshot as well as other screenshots, I have 2 workspaces. On a few there's 2 workspaces on 2 monitors, where 2 monitors are on each workspace.
JWM has grouped windows. To access specific menu options from each process within the group, I'll right-click an application group in the taskbar, and right-click again so more options show up to the specific running application.
"alacritty" was in the Conky panel on the right. Now I realize that Alacritty was running as shown, but not displayed. Thanks for letting me know, there's also Polybar.
I'm planning to do it when I finish some minor changes but overall looks exactly the same[1]. In regards to experience, this something between x11/i3 and x11/dwm with some x11/bspwm influence but this is a relatively product and still is green, and soon a major code refactor should land too.
[1]except I'm not using conky because of a annoying bug (just a few people suffer).
dillo2, Ultima Online through wine, aumix, urxvt, mplayer
(These ScrotWM screenshots are at an image hosting site, as they are in the original post.) purgatori
Here is ctwm (x11-wm/ctwm). The configuration of these twm derivatives always daunted me, but my config is starting to take shape with a few growing pains. This is a serious BSD-compatible alternative to fvwm and is more like a successor to twm instead. Even NetBSD uses it now!
The Trinity Desktop Environment has this really handy tool for editing XML files called kxmleditor. It does not seem to exist since Plasma. I bring up such a thing because it would probably really help with configuring JWM
MCWM and ITTYWM shown in these screenshots are in libxcb. Most of the terminals in these images are xterm, with one on each showing an example of jbxvt which is in libxcb. For these (as well as other window managers), The Alt key is used with the mouse to move and resize windows (as well as on other traditional window managers). .xsession is used for these, and they're made to somewhat match settings I have on JWM. These background terminals and other windows/applications aren't locked into place, but it still represents my settings from another window manager. The window manager I was using was getting slow.
MCWM
In x11-wm/mcwm, windows are locked within the confines of each monitor. It won't let windows partially go off screen, and the Windowskey with other keys is needed to move windows across different monitors. There's another inconvenience that windows (especially newly opened windows) can cover other windows, so they may have to be moved to access the windows under them. This screenshot uses an instance xterm as the last launched program, so when this terminal is exited from, it quits the window manager. This is the recommended way to use MCWM, so that there'll always be a terminal available while this window manager is running. RES RAM: 1,792K (1.8M) not including required terminal emulator. (A previous statistic from last month on my computer had RES RAM of MCWM at 2.7M)
ITTYWM
x11-wm/ittywm allows windows to go partially offscreen, and the mouse can drag windows to different screens without needing keyboard shortcuts. Also, there may be difficultly switching to type in different terminals. TinyWM, which this window manager is based on doesn't have this problem. This screenshot can use xterm as the last launched program, so when this is exited from, the window manager will close. However, in this screenshot, the window manager was launched lastly. As of trying IttyWM last month, RES RAM: 2.4M. (For comparison, TinyWM had a RES RAM of 3.4M.)
As for other libxcb (Thread libxcb-x-c-binding-library.81694) window managers, I want to check out MMWM (Modern Minimalistic WM) and FrankenWM, which aren't in ports at this time. FrankenWM is a floating WM based on 2BWM, MonsterWM and MonsterWM-XCB and has inspiration from DWM and BSPWM. MMWM is based on FrankenWM and 2BWM. The experimental 2BWM is based on MCWM, so this influence is in these window managers. FrankenWM is said to be stable.
https://github.com/pbizopoulos/fswm is a full screen window manager in libxcb with an MIT license. It seems to be no more than 3 months old. Previously, I found GlennWM as a fullscreen window manager (not in ports) which has cleaner code than the existing AntiWM, but these 2 aren't in libxcb.
What is shown in the screenshot: Emacs built-in Eshell (Emacs shell), Emacs built-in world clock, Emacs built-in calendar and Firefox open, EXWM has gaps turned on through the exwm-outer-gaps package (gaps around edge of Emacs).
EXWM is cool because, you can use Emacs as normal, but inside Emacs buffers you can have normal applications like Firefox or Pulseaudio volume control opened inside of them, it turns Emacs into a Xorg window manager, and you can manage Emacs buffers with Xorg applications inside of them as you usually do with normal Emacs buffers.
View attachment 14737
Here is ctwm (x11-wm/ctwm). The configuration of these twm derivatives always daunted me, but my config is starting to take shape with a few growing pains. This is a serious BSD-compatible alternative to fvwm and is more like a successor to twm instead. Even NetBSD uses it now!
This thread is particularly for window managers available under a permissive license, but cool nonetheless. I like Emacs but Im more used to JOE keybindings. ?
Some were moved to Thread freebsd-screen-shots.8877, because the theme was non-viral licenses overall, written as BSD-like: Window Managers with permissive or file-based copyleft licenses. Also, didn't mention CDDL, which there are no window managers of in Ports. The ones moved are still great screenshots though. One above included Spectrwm, i3, and likely Xmonad.
The one above with Fluxbox is a good addition here. There's some there that match the theme here.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
