Ever since there was a lightdm update a while back, I have been having issues with the keyboard (HP laptop) - I can enter the user name, but when changing fields to enter the password, there is no input from the keyboard. There seems to be some issues with the drop down menus - change wm's etc ... so maybe some issues with the cordless mouse.

Anyone else having these issues?

Finally got fed up with it and switched to a run level that does not start lightdm. Currently using:

xinit <window manager of choise>

to log in to X. Good news is that memory use has dropped from around 150MB idling to 110MB idling - so maybe a memory issue with lightdm as well.

My youngest - she turned 2 today:

syndaemon

Came across this little app today. I'm sure some of you are on laptops, and one thing that drives me nuts it that the mouse cursor will move as your palm or heel of your hand gets a little too close while typing. This little app takes care of that. It can be run as a daemon so add -

syndaemon -d

to your ~/.fluxbox/startup - or whatever startup file you use.

The result is that the touchpad is disabled when the keyboard is in use. By default, the touchpad will become active 2 seconds after keyboard activity stops. That can be chnaged -

syndaemon -i 1.0 -d

will cause the touchpad to become active after 1 second. There are some other options detailed in the man page. Worked like a charm when I tested it with geany and thunderbird.

The Settings Editor of Xfce indicates that the key binding -

<Control><Shift><Alt>Right

is the binding to move_window_right_key.

I assume this means that the active window a bit to the right when this key binding is used, but I get no result (8C is entered in a terminal). Anyone else having this issue with Xfce?

Also, anyone have a key binding for incrementally moving the active window in Xfce?

Been checking out the latest release of E17 from the Sid repos - there are build scripts available that will get the latest release from git, but I couldn't get them to work; they are possibly obsolete.

E17 has always marketed itself as a low resource window manager that allows for a lot of bling - and although that was pretty much accurate, in the past it was plagued by instability - it would regularly seg fault on my desktop single core AMD-64. Because of the instability, I never really used it as a main window manager; I would tinker with it because it is modular - like Fvwm - and you load the modules you choose which allowed for a lot of customization.

The current build in the repos seems pretty stable. No crashes yet, but I'm using my HP I3 laptop this time. Lowrider over at #! has been running stable E17 on his #! and Arch systems so it looks like the stable release is indeed stable.

Some shots showing resource usage - fluxbox with compton, Xfce with compositing, E17 with compositing, two terminals and conky. For fluxbox and E17 the terminal is urxvt with transparency, for Xfce it's the xfce4-terminal:



The available themes for E17 have improved a lot (more variety) - use to be they were almost all of the glassy/glossy aesthetic or OSX mimics; there are plenty more modern and gray scale color palettes now. Downside to customizing E17 is that it is a major pain to make your own - E17 uses it's own internal theme elements, but non-e17 apps use available gtk themes which is a nice improvement. As with earlier versions of E17, the E17 themes can be mixed and matched to your liking - i.e the clock module from theme X can be used in theme Y. Most of the buggy modules have been dropped from the base install, as the E17 devs seem to be focusing on improving what works.

E17 loads the compositing module by default, so I used the internal argb settings in conky for a transparent conky window.

All in all a big improvement for the E17 developers, but IMO they are a day late and a dollar (euro if you prefer) short. The improvements made to recent versions of Xfce - particularly the compositor - have pretty much made E17 irrelevant as far as having a WM/DE that combines low resources with as much bling as you want. Unless you're really concerned about the additional resources Xfce uses, it's the better choice, But if you want something different to tinker with, by all means give it a spin - or maybe load Bodhi or Elive into VM's - both are debian/ubuntu based; I liked elive when I had it installed, but E17 at that time just wasn't stable enough to keep it around. Never tried Bodhi, but have read good reviews.

cwm is one of those minimalist window managers - no window decorations, but good key binding control. Configured in the $HOME/.cwmrc file; good man pages for cwm and cwmrc. The default window manager for OpenBSD, I believe:



it's pretty good if you like minimalism - just under 100 MB memory idling on VSIDO, or for those occasions when you don't want to be distracted by eye candy.

get the source code from git:

git clone git://github.com/chneukirchen/cwm.git

I haven't used it in a couple years because the aesthetic can be easily duplicated in fluxbox, fvwm, openbox, or tiling wm's like i3 and dwm - all of which have much more functionality, but I'll confess this is the wm I used to train myself to use key bindings for window management instead of the mouse.

You can use a mouse - the default mouse bindings for window movement/resize are the same as fluxbox, and it is conky and panel friendly - tint2 anyway:



that is conky piped to dzen2 - similar to dwm or spectrwm in the first scrot, regular conky window in the second.

Every forum needs a thread about Fvwm so I started one. 

Lightweight, incredibly configurable, stable window manager. Desktop is all Fvwm with FvwmPager, FvwmIconMan, stalonetray, and xclock swallowed by FvwmButtons to create the standard xfce/gnome2 type panel. A function defined in the Fvwm configuration files creates a thumbnail for iconified windows instead of the usual icon:

Vastone likes to say "screenshot or it didn't happen" and it's his forum, so: