new feature: a clock!

A real bit of frippery.  The wmx code in SVN now has a built-in clock.
 Though it's optional and off by default.

Define CONFIG_CLOCK to True to have wmx display a clock permanently in
the background at the top-left of screen 0, using the same style of
digits as used for channel numbers but a more muted colour.

Chris

[PATCH] wm2: separate preprocessor and linker flags

Use INCS when compiling, LDFLAGS when linking.
Thus changing those variables by giving make arguments
is easier, as they have less side effects.

--- a/Makefile
+++ b/Makefile
 <at>  <at>  -4,20 +4,21  <at>  <at>  INCS	= -I/usr/X11R6/include

 CC	= gcc
 CCC	= g++
-CFLAGS	= -O2 -Wall $(INCS)
+CFLAGS	= -O2 -Wall
+LDFLAGS =
 OBJECTS	= Border.o Buttons.o Client.o Events.o Main.o Manager.o Rotated.o

 .c.o:
-	$(CC) -c $(CFLAGS) $<
+	$(CC) -c $(CFLAGS) $(INCS) $<

 .C.o:
-	$(CCC) -c $(CFLAGS) $<
+	$(CCC) -c $(CFLAGS) $(INCS) $<

 wm2:	$(OBJECTS)
-	$(CCC) -o wm2 $(OBJECTS) $(LIBS)
+	$(CCC) -o wm2 $(CFLAGS) $(LDFLAGS) $(OBJECTS) $(LIBS)

 depend:
-	makedepend -- $(CFLAGS) -- *.C

[PATCH] wm2: allow user to specify CONFIG_NEW_WINDOW_COMMAND at compile time

Do not set CONFIG_NEW_WINDOW_COMMAND if already defined.
This allows changing it's value using -D without patching the source.

--- a/Config.h
+++ b/Config.h
 <at>  <at>  -7,7 +7,9  <at>  <at> 
 #define CONFIG_NASTY_FONT	  "fixed"

 #define CONFIG_EXEC_USING_SHELL   False
+#ifndef CONFIG_NEW_WINDOW_COMMAND
 #define CONFIG_NEW_WINDOW_COMMAND "xterm"
+#endif
 #define CONFIG_EVERYTHING_ON_ROOT_MENU False

 // You can't have CLICK_TO_FOCUS without RAISE_ON_FOCUS but the other

[PATCH] fix char vs const char issues in wm2

String literals are const char, so everything reachable by those
should be const char, too, or modern compilers may complain.

--- a/Manager.C
+++ b/Manager.C
 <at>  <at>  -312,7 +312,7  <at>  <at>  void WindowManager::initialiseScreen()
 }

 
-unsigned long WindowManager::allocateColour(char *name, char *desc)
+unsigned long WindowManager::allocateColour(const char *name, const char *desc)
 {
     XColor nearest, ideal;

diff --git a/Manager.h b/Manager.h
index 0ea2ca5..6db2ac6 100644
--- a/Manager.h
+++ b/Manager.h
 <at>  <at>  -40,7 +40,7  <at>  <at>  public:
     void installCursor(RootCursor);
     void installCursorOnWindow(RootCursor, Window);
     void installColormap(Colormap);
-    unsigned long allocateColour(char *, char *);
+    unsigned long allocateColour(const char *, const char *);

     void considerFocusChange(Client *, Window, Time timestamp);
     void stopConsideringFocus();
diff --git a/Rotated.C b/Rotated.C
index 09fdfe2..e0f09ff 100644

[PATCH] make wm2 64bit clean

execl/execlp expects a 0 pointer as last argument.
Giving it only 0 causes a 0 int (32 bit) as variable argument,
while pointers are 64 bit on 64 bit architectures.

--- a/Manager.C
+++ b/Manager.C
 <at>  <at>  -551,16 +551,16  <at>  <at>  void WindowManager::spawn()
 	    }

 	    if (CONFIG_EXEC_USING_SHELL) {
-		execl(m_shell, m_shell, "-c", CONFIG_NEW_WINDOW_COMMAND, 0);
+		execl(m_shell, m_shell, "-c", CONFIG_NEW_WINDOW_COMMAND, (char*)0);
 		fprintf(stderr, "wm2: exec %s", m_shell);
 		perror(" failed");
 	    }

-	    execlp(CONFIG_NEW_WINDOW_COMMAND, CONFIG_NEW_WINDOW_COMMAND, 0);
+	    execlp(CONFIG_NEW_WINDOW_COMMAND, CONFIG_NEW_WINDOW_COMMAND, (char*)0);
 	    fprintf(stderr, "wm2: exec %s", CONFIG_NEW_WINDOW_COMMAND);
 	    perror(" failed");

-	    execlp("xterm", "xterm", "-ut", 0);
+	    execlp("xterm", "xterm", "-ut", (char*)0);
 	    perror("wm2: exec xterm failed");
 	    exit(1);
 	}

Unable to access SVN

According to the instructions on this page:
http://sourceforge.net/projects/wm2/develop, it should be possible to
access the wm2 SVN repository with the command: "svn co
https://wm2.svn.sourceforge.net/svnroot/wm2 wm2". On my system (Debian
GNU/Linux squeeze/sid) however, that command shows the error:
svn: OPTIONS of 'https://wm2.svn.sourceforge.net/svnroot/wm2': could
not connect to server (https://wm2.svn.sourceforge.net) 

Are others able to access the SVN repository? I'm nearly certain I
have been able to access the repository in the past.

Composite extension

Is there no end to our new-fangledness?

I've had a lengthy period of growing increasingly irritated with recent video 
cards on which conventional window managers like wmx now seem to run much 
slower than compositing managers -- reaching a pinnacle with the latest ATI 
drivers which are both incredibly slow and glitchy for uncomposited use of the 
Shape extension.

Well, now I've just discovered that the solution is incredibly simple -- tell 
the X server to use compositing offscreen storage for all top-level windows, 
and suddenly it renders everything much faster without any further changes to 
the code.

So, I've committed a small change that does exactly that, if the Composite 
extension is found.  It makes wmx as fast as any other window manager on these 
particularly unhelpful video cards.  You can disable it in the config if 
preferred.

Let me know if this causes anyone any real problems.

Chris

wmx-7

At this rate I'm thinking I'll never get around to finishing the
remaining NETWM desktop compliance details as well as I would like,
so I thought I ought to release something.  Hence: presenting wmx-7!
Now available from the usual place.

Major changes since wmx-6 are:

 * Much of the NETWM extended window manager hints protocol is now
supported, making wmx a pleasant window manager to use with a desktop
environment such as GNOME or KDE with all its fripperies.

 * Text in window frames can now be anti-aliased using Xft fonts.

 * You can move windows with Alt-drag anywhere on them (from Damion
Yates and Teemu Voipio back in 2003)

 * Windows will now meet resistance when bumped against each other,
not just against screen edges.

 * A few other changes and fixes from Glyn Faulkner and Zvezdan
Petkovic in particular.

Some things I had wanted to get done for this release, but didn't:

 * Finish up the NETWM extensions, at least for all the things I
routinely use -- the main omissions are full-screen window support and
struts (failure to support struts means that maximised windows
disappear behind taskbars and things).

Full-screen windows?

This is probably a known problem, but in case it isn't, I'd like to
report that full-screen windows don't work very well with (current SVN)
wmx. Here are some examples:

First of all, docks and panels appear above full-screen windows. For
example, running gkrellm (with "Set window type to be a dock or panel"
and "Set sticky state" enabled) and kicker, and then running mplayer in
full-screen mode, mplayer is indeed full-screen but gkrellm and kicker
appear over its window, obscuring its edges.

Other programs don't even turn properly full-screen. For example,
pressing F11 in firefox resizes the window to be full-screen, but it
still has decorations and isn't positioned exactly inside the screen.
Moving it with the mouse seems to fix it, though. Virtualbox exhibits
the same behaviour.

When pressing F11 in eog, the full-screen toolbar appears at the top of
the screen, but the actual image window isn't resized.

Pressing F in xine, the window decorations disappear and the window is
resized to be almost full screen, but not quite - it's a few pixels
smaller.

The only program I found that appears perfectly in full-screen mode is
qiv. Even panels and docks are hidden.

Thanks!

Alexandros

A possible fix for the focus problem when switching channels

As mentioned in http://ml.42.org/wmx/msg00653.html, when switching to an
empty channel (or at least to a channel where nothing is focused) and away
from a Gtk2 app such as firefox, keyboard commands to switch channels stop
working.

As far as I can tell, this is caused by the old active client not getting
deactivated.

The attached patch should fix it.  I also cleaned up a little
parenthesizing, to make sure that that wasn't the problem, but effectively
the fix seems to be deactiving the client and resetting the focus to the
root if the active client is on the wrong channel.

Ben
--

-- 
Ben Stern             UNIX & Networks Monkey             bstern@...
This post does not represent FTI, even if I claim it does.  Neener neener.
UM Linux Users' Group     Electromagnetic Networks      Microbrew Software

diff -rub wmx-6/Channel.C wmx-6pl1/Channel.C
--- wmx-6/Channel.C	2000-05-24 11:46:14.000000000 -0400
+++ wmx-6pl1/Channel.C	2008-03-20 01:30:07.000000000 -0400
 <at>  <at>  -158,12 +158,14  <at>  <at> 

     for (i = 0; i < considering.count(); ++i) {
 	considering.item(i)->flipChannel(False, m_currentChannel);
-	if (considering.item(i)->channel() == m_channels &&
+	if ((considering.item(i)->channel() == m_channels) &&
 	    !considering.item(i)->isSticky()) createNewChannel();

Re: antialiased fonts, Subversion, etc

At the moment I'm using Gmail as a mail aggregator and client, but this list 
actually rejects email from it ("Client host [64.233.166.177] blocked using 
spam.dnsbl.sorbs.net").  That's a bit annoying; I can work around it, but it 
does explain why this mail will look like a new thread instead of having the 
proper reply headers.

Since my last post I've done a little work on the netwm (formerly GNOME) 
compliance branch -- available via Subversion at

 svn co http://wm2.svn.sourceforge.net/svnroot/wm2/branches/wmx-netwm

I am actually running this daily now, using the KDE panel and desktop at work 
and GNOME panel and desktop at home, so if you want to try it out you can 
probably expect it not to fail too hard, too often.  There are many bugs and 
infelicities, but I hope it'll improve at a reasonable rate now.  There's a 
TODO file in the root directory which I make notes in.  At this stage it 
might not be worth reporting bugs in this branch unless they are crashes or 
regressions -- as I am only using the wm with fancy desktop accessories at 
the moment, I might not notice regressions that happen when using it without.

I wonder whether I should also configure the SourceForge Subversion repository 
to send commit notices to this list?  Would that be appreciated, or would it 
disturb the pleasantly close-to-zero traffic level of this list too much?

On 15/12/2007, Alexandros Diamantidis <adia@...> wrote:
> I thought this would allow non-ascii window titles and menu items, and
> indeed non-ascii menu items appear fine, but window titles still appear
> as "incognito" if they contain greek characters. If they only have
> latin-1 characters, they are cut-off at the first non-ascii character.