Currently, the the transparency of windows is determined by the absolute stacking order rather than how recently a window has been used. The transparency should be based on how recently a window has been used instead.

Some programs, such as Firefox, move their windows at startup (or during other operations) so that the title-bar / handle-bar is completely above the top of the usable screen, inaccessible. Right-clicking the program's button in the taskbar, choosing 'Move' and using the arrow keys will bring it back down.

Is there any reason to allow the window's decorations to be higher than the top of the screen? If not, would it be possible to keep that from happening, or allow at least a small amount of the title-bar / handle-bar to be seen so it can be grabbed easily?

I am aware of the 'pignore' option in the Group section as a workaround for some programs, but from a usability standpoint, having the title-bar / handle-bar completely passed the top of the screen can slow the user down, make them cry, cause worldwide catastrophes, etc

Thanks :-)

I have had a request to pass on, whether you could see your way to add:

[quote]
like a right-click on the minimize button will toggle shade in these newer versions (I like multifunction titlebar buttons; Idea: m2 for max vertical and m3 for max horizontal on the max button would be nice). [/quote]

Maybe using for m2 the centre-click and left-click, and for m3 the right-click and left-click?

what do you think?

configure.in script uses '==' operators in several place but it's bash extension and doesn't work with other shells. Formal '=' is preferred especially on non Linux environments.

diff --git a/configure.in b/configure.in
index 4795fb1..1742e3d 100644
--- a/configure.in
+++ b/configure.in
@@ -200,7 +200,7 @@ if test "$enable_cairo" != "no" ; then
         AC_MSG_WARN([unable to use Cairo, Cairo support disabled]) ],
       [ $CAIRO_LDFLAGS ])
 fi
-if test "$enable_cairo" == "no" ; then
+if test "$enable_cairo" = "no" ; then
    if test "$enable_rsvg" != "no" ; then
       AC_MSG_WARN([disabling rsvg because Cairo is disabled])
       enable_rsvg="no"
@@ -232,13 +232,13 @@ if test "$enable_rsvg" != "no" ; then
         AC_MSG_WARN([unable to use rsvg, rsvg support disabled]) ],
       [ $RSVG_LDFLAGS ])
 fi
-if test "$enable_rsvg" == "no" ; then
+if test "$enable_rsvg" = "no" ; then
    if test "$enable_cairo" != "no" ; then
       AC_MSG_WARN([disabling Cairo because rsvg is disabled])
       enable_cairo="no"
    fi
 fi
-if test "$enable_rsvg" == "yes" ; then
+if test "$enable_rsvg" = "yes" ; then
    LDFLAGS="$LDFLAGS $CAIRO_LDFLAGS"
    CFLAGS="$CFLAGS $CAIRO_CFLAGS"
    AC_DEFINE(USE_CAIRO, 1, [Define to use Cairo]) ],
@@ -416,7 +416,7 @@ fi
 AC_ARG_ENABLE(xmu,
    AC_HELP_STRING([--disable-xmu], [disable Xmu support]),
    [],
-   [  if test `uname` == "IRIX" -o `uname` == "IRIX64" ; then
+   [  if test `uname` = "IRIX" -o `uname` = "IRIX64" ; then
          AC_MSG_WARN([disabling Xmu (it is broken on IRIX)])
          enable_xmu="no"
       fi

I wonder if this is possible to do add a setting that:

If your JWM is set to have only one Virtual Window, application windows cannot slide outside of that Visable part of the window!

I have had a number of complaints over your new window 'hover control' buttons, however I have also had just as many complements on the change. Personally, I love the idea of having different hover controls to show the buttons are active!

I was wondering if you could add a setting so that they could pick either the new ones or use the system default instead.

That should quieten both groups.

JWM is an absolutely great WM! I have created a nice-looking config that makes JWM look professional and well-polished. JWM's RAM usage is really great, even compared to Fluxbox or other 'lightweight' WM's.

The only issue I have right now is I need windows to be placed centered (x and y) on the screen when they are initially placed. I tried hacking the source and was able to get most windows to center, but full-screen and maximized windows would resize to tiny little windows.

A config option, or even advice about where to hack around to make all windows center would be really appreciated. If not, thanks for making JWM anyway! :-)

Will B.

hi, I wanted to get bigger icons in my taskbars, but to just have someting wich looks more "heavy metal" (means more cool than cool itself) I added a piece of code to simulate a pressed button, try it with some buttons having border set to false « border="false" »

in traybutton.c, at the draw function
/** Draw a tray button. */
void Draw(TrayComponentType *cp, int active)
{

ButtonNode button;
TrayButtonType *bp;
int labelx;

bp = (TrayButtonType*)cp->object;

JXSetForeground(display, rootGC, colors[COLOR_TRAY_BG]);
JXFillRectangle(display, cp->pixmap, rootGC, 0, 0, cp->width, cp->height);

ResetButton(&button, cp->pixmap, rootGC);
if(active) {
button.type = BUTTON_TRAY_ACTIVE;
} else {
button.border = bp->border;
button.type = BUTTON_TRAY;
}
button.width = cp->width - 3;
button.height = cp->height - 3;
button.x = 1;
button.y = 1;
DrawButton(&button);

/* Compute the offset of the text. */
if(bp->label) {
if(!bp->icon) {
labelx = 2 + cp->width / 2;
labelx -= GetStringWidth(FONT_TRAYBUTTON, bp->label) / 2;
} else {
labelx = cp->width;
labelx -= GetStringWidth(FONT_TRAYBUTTON, bp->label) + 4;
}
} else {
labelx = cp->width;
}
labelx -= BUTTON_SIZE;

if(bp->border==0){/nicoo/ // borderless
if(bp->icon) { /nicoo/
switch(button.type){ /nicoo/
case BUTTON_TRAY_ACTIVE : /nicoo/
PutIcon(bp->icon, cp->pixmap, 1, 1, /nicoo/
cp->width-1, cp->height-1); /nicoo/
break; /nicoo/

        default : /*nicoo*/
        PutIcon(bp->icon, cp->pixmap, 0, 0, /*nicoo*/
           cp->width, cp->height); /*nicoo*/
     }
  } /*nicoo*/

  }else{/*nicoo*/
     if(bp->icon) {
     PutIcon(bp->icon, cp->pixmap, BUTTON_SIZE, BUTTON_SIZE,
        labelx - BUTTON_SIZE, cp->height - BUTTON_SIZE * 2);
  }

  if(bp->label) {
     RenderString(cp->pixmap, FONT_TRAYBUTTON, COLOR_TRAYBUTTON_FG,
                  labelx + 2,
                  cp->height / 2 - GetStringHeight(FONT_TRAYBUTTON) / 2,
                  cp->width - labelx, bp->label);

}
} /nicoo/

}
feel free to reuse, no garantee, I'M NOT A REAL CODER.
I added /nicoo/ to help myself and everydude else to see what I've done, If you want to reuse something, you can remove these comments.

n.b. : I know this is note an issue, but "pull request" seems to be inactivated

n.b. 2 : I made some other minors "hacks" like using icons in border, I also deactivated some stuffs I don't like, examples : having tooltip when I pass over the clock, deactivated many menu functions (I don't like menus) and so. Most of my stuffs are hardcoded so it can be annoying for most dudes.

just for propaganda : http://www.zimagez.com/zimage/capturedcran-20042013-142549.php

\m/ -- nicoo -- \m/

When configured with fribidi, JWM will cut off the end of bi-directional text.

Joe, could we have a setting in configuration to be able to assign the name of the configuration file, as well as the location (as we can do) for the system configuration file please, rather than as at present it's using a preconfigured set name. The file and it's location would already exist so you don't have to supply it.

The current method is causing an ocassional problem when upgrading in puppy in that it's starting with your system.jwmrc and not puppy's default /etc/xdg/root.jwmrc or /root/.jwmrc until the system has been rebooted.

Some have requested the ability for JWM to support custom icons for the minimize, maximize, and close window buttons. JWM currently draws these, but it would be possible for JWM to load them the same way JWM loads other icons. JWM would need to fall back on the current method if the icons could not be loaded for some reason.
Note that JWM used to support XPM icons, but that was removed since only fixed size XPMs were supported.

I have had a request to build an iconless version for a 'ram-only' puppy.

configure works I believe as it ends with:

Confirm:  yes
Icon:     no
Cairo:    no
RSVG:     no
PNG:      no
JPEG:     no
XPM:      no
XFT:      yes
XRender:  yes
FriBidi:  yes
Shape:    yes
Xmu:      yes
Xinerama: yes
Debug:    no

but it bombs out at the start of 'make' with:

make

cd src ; make all ; cd ..
make[1]: Entering directory /mnt/sda7/build-pet-jwm/jwm2-noicons-702/src' gcc -c -mtune=native -O2 -pipe -fomit-frame-pointer -I/usr/X11R7/include -I/usr/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include -I/usr/include/fribidi -DLOCALEDIR=\"/usr/share/locale\" background.c background.c:307:35: error: macro "LoadNamedIcon" passed 2 arguments, but takes just 1 background.c: In function ‘LoadImageBackground’: background.c:307: error: ‘LoadNamedIcon’ undeclared (first use in this function) background.c:307: error: (Each undeclared identifier is reported only once background.c:307: error: for each function it appears in.) make[1]: *** [background.o] Error 1 make[1]: Leaving directory/mnt/sda7/build-pet-jwm/jwm2-noicons-702/src'
cd po ; make all ; cd ..
make[1]: Entering directory /mnt/sda7/build-pet-jwm/jwm2-noicons-702/po' make[1]: Leaving directory/mnt/sda7/build-pet-jwm/jwm2-noicons-702/po'

Any ideas?

rounded trays same way as rounded buttons probally easy to do sharing same code :).
i know i am asking for alot a features here lately i know you wana get a stable JWM release but if you can implement them in the future that will be fantastic.

tested on racy 5.4.91 (kernel 3.8.0)

Everything looks good in normal mode.

With kcompmgr -n enabled .. toggling max-full, max-v and max-h leaves remnants on the display. If compiled with Shape disabled, there are no remnants (but windows lose the rounded corners Neutral ).

This is however not happening with rox-filer so it may be a kcompmgr problem.

This has it's own thread, I'll leave it to you to decide if it's possible or not.

http://www.murga-linux.com/puppy/viewtopic.php?t=80206&sid=4c25d92935f040499bc5eccbdc6a0df6

one of the things i miss from my times with other WMs and his very usefull specially if i use multiple screens to do some work his draging the window to another screen o even in same screen and if i droped the window at the very top end of the desktop the window wil auto maximize to full screen.

maybe this his something you like to implement it will be a usefull time saver.

from one of our puppy builders\users:

currently a jwm --help gets:

jwm --help

JWM vgit-686 by Joe Wingbermuehle
compiled options: confirm fribidi icons png shape xft xinerama xpm xrender
system configuration: /usr/etc/system.jwmrc
usage: jwm [ options ]

Could it be expanded for quick use of the options to something like:

jwm --help

JWM vgit-686 by Joe Wingbermuehle
compiled options: confirm fribidi icons png shape xft xinerama xpm xrender
system configuration: /usr/etc/system.jwmrc
usage: jwm -display {display} -exit -h -p -restart -reload -v

wont overlap windows wen his set to be on top.
also jwm wont alow the dock to come out off autohide wen we put the mouse in the edge of the screen.
not shure if his a WM issue or cairo-dock itself?

I don't know if this is a bug or just the way JWM focuses on things:

If I open a window and then minimize it, JWM keybindings will not work until I unminimize said window or open a new window.
So, say I right-click the minimized window in the tray and close it... then keybindings won't work until I open another application.

If your JWM is set to have multiple Virtual Windows (say a 4x4).

If you start an app in the top left window and slide it towards another window so that part of the app window goes 'off-screen', that part appears automatically in the adjacent window that was slid against.

It would also need I think to have a small (1<>2 characters) overlap portion. I don't mean slide it across with the mouse moving it into the next Virtual Window and changing to use that virtual window, but 'push' it towards that window so it can be 'grabbed' when you later change to that window.

I also think there would be a need to have 'grab' points in the bottom corners so you could pull the app window downward.

post 703 (I will backtest later), a minimized app window that is killed rather than closed is also killing the background and icons thereon. To fix seems to need a restart X server, jwm -restart or reload does nothing.

The official Puppy Linux releases have up now used JWM version 574,
which I have been pretty happy with.

People have been telling me how much work you have done on JWM since
then, and have been urging me to upgrade.

So, I compiled 779 today, and gave it a quick test. Looks good, except:

I opened a text file in Geany text editor, then minimized it to the tray.
I then clicked on another text file, and nothing happened ...at first
I thought, what have I broken?... then I realised that Geany had
opened the file (Geany is a tabbed editor that can open many files),
but it stayed in the tray.

In all versions of JWM that I have ever used, up to 574, we have had
no problem with Geany. When a new text file is opened, Geany will
restore immediately from the tray, or come to the front if already
restored.
This behaviour is so engrained in our minds, we need that behaviour.

Could you please look into this? Was this change of behaviour deliberate?

Using the latest official release of JWM (2.1), I ran into a bug in the DoMatch() function (wildcard at end of pattern failed), and I was going to submit a bug report and patch. But a look at the latest GIT shows that this function has been replaced with calls to standard C library functions for matching regular expressions.

So, happily, no bug report or patch is needed. But I would suggest that the documentation for "Group Settings" be updated to reflect this change. Currently config.shtml for 2.2 just says, "A wild card, '*' may be used," which describes the old behavior. No mention is made of regular expressions.

As it is now, a user who configures a Group so that a program with the Name "oo" is forced to open on desktop:2 would be surprised when a program with the Name "foobar" is also forced to open on desktop:2.

I'm getting reports that every jwm -restart is growing the size of the jwm in memory by about 1meg.

It can be confirmed by using top.

I think there's an issue with the XML lexer while parsing commands in .jwmrc containing escapes. This may be caused by line 267 in lex.c: x += strlen(temp);
that makes x skip only the length of the final escaped string (which may not corresponds to the length actually parsed by the previous ReadElementValue() in case escapes were present on line buffer).

This is just a quick patch I did to fix the issue on my side:

--- ./jwm-2.1.0/bak/lex.c   2013-04-11 11:39:15.433070700 +0200
+++ ./jwm-2.1.0/src/lex.c   2013-04-11 17:22:23.606026716 +0200
@@ -103,7 +103,7 @@
 static int IsSpace(char ch, int *lineNumber);
 static char *ReadElementName(const char *line);
 static char *ReadElementValue(const char *line,
-   const char *file, int *lineNumber);
+   const char *file, int *lineNumber, int *offset);
 static char *ReadAttributeValue(const char *line, const char *file,
    int *lineNumber);
 static int ParseEntity(const char *entity, char *ch,
@@ -117,7 +117,7 @@
    AttributeNode *ap;
    char *temp;
    int inElement;
-   int x;
+   int x, offset;
    int found;
    int lineNumber;

@@ -261,9 +261,9 @@
                }
             }
          } else {
-            temp = ReadElementValue(line + x, fileName, &lineNumber);
+            temp = ReadElementValue(line + x, fileName, &lineNumber, &offset);
             if(temp) {
-               x += strlen(temp);
+               x += offset;
                if(current) {
                   if(current->value) {
                      current->value = Reallocate(current->value,
@@ -403,7 +403,7 @@
 }

 /** Get the value of the current element. */
-char *ReadElementValue(const char *line, const char *file, int *lineNumber) {
+char *ReadElementValue(const char *line, const char *file, int *lineNumber, int *offset) {
    char *buffer;
    char ch;
    int len, max;
@@ -433,6 +433,7 @@
          buffer = Reallocate(buffer, max + 1);
       }
    }
+   *offset = x;
    buffer[len] = 0;
    Trim(buffer);

I have TaskList maxwidth="200" and have done for some time. I am running 737 and just noticed that in longer than 200px wide names the text spills over the right hand end. Should be easy to reproduce.

one of the things i like about JWM his because only loads one lib and that makes it load realy fast something that other desktops just cant do.

But for some time now am thinking how about if we could build widgets or anything we wanted with javascrip or even style it with css (maybe an opcion in compile time for people that prefer only standard JWM or a more juicy one) this will make JWM alot more versatile (it still be faster that any other desktop) and maybe call some more devs atencion to help improve it??

Built with the latest jwm-653 for Mage2 (i'm one of BarryK's Puppy Linux Builders).

Problem is that the "maximum<>Medium" window size changeover will not return to the 'medium' sized window if there is more than one window open. One application window (say for geany) is ok. Open a second application window (say rox) and it will change up to maximum, but will not 'go back' to the medium size until the first window has been closed or it is reduced using the menubar's resize . However the first application window has no problems.

Not sure what else you need?

scsijon
[email protected]

Hello.

Since version jwm-662 (commit ba6f5fa) I noticed an unusual orange (#CC7700) line border around highlighted menu item. I prefer dark blue active background (#02305A) and white active foreground (white).

Would it be possible to set this border color value in a theme?

A workaround that works for me

I modify the value in src/color.c before compiling:

From:
{ COLOR_MENU_ACTIVE_OL, "#CC7700" }

To:
{ COLOR_MENU_ACTIVE_OL, "#000000" }

After compiling the border around highlighted menu item is black as it was in jwm-661.

Other than that JWM is working perfectly on my laptop as well as on my ten years old desktop PC both running Puppy Linux.

Thanks for your excellent work.

With Kind Regards from an old JWM fan since it's preTrayButton times,

Leon Zobec

To reproduce: open geany, shade geany, switch desktops, and then open a document in geany.
This currently causes strange things. What is happening is that geany is signaling the existing instance to become active. JWM then attempts to make it active, but does not change its desktop. JWM should make sure the application is on the current desktop (moving it if necessary) and that the application is not shaded.

Hi Joe, I'm not sure that it really counts as an "issue", but autoreconf produces an unhealthy looking error on my system, even though it produces a working configure script:

# autoreconf configure.in:448: warning: AM_PROG_MKDIR_P is m4_require'd but not m4_defun'd aclocal.m4:1760: AM_PO_SUBDIRS is expanded from... aclocal.m4:57: AM_GNU_GETTEXT is expanded from... configure.in:448: the top level autoreconf: configure.in: AM_GNU_GETTEXT is used, but not AM_GNU_GETTEXT_VERSION configure.in:448: warning: AM_PROG_MKDIR_P is m4_require'd but not m4_defun'd aclocal.m4:1760: AM_PO_SUBDIRS is expanded from... aclocal.m4:57: AM_GNU_GETTEXT is expanded from... configure.in:448: the top level configure:5023: error: possibly undefined macro: AM_PROG_MKDIR_P If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /usr/bin/autoconf failed with exit status: 1

this his what am using in the configuration file for a left tray (autohide="true" halign="left" valign="center" layout="horinzontal") i suggest that the (autohide feature should have instead of "true" his "left" "right" "top" "bottom" so we can chose wich side off the screen the menu appears back again!

I have a user or two that use set placements for certain applications.

The clearest explanation is from jasper who uses precise on a 1024x768 screen (http://www.murga-linux.com/puppy/viewtopic.php?p=706900, fifth post down on page10 of the puppy thread).

After installing jwm 768 and Restarting X both abiword
and dillo open their 936 x 702 windows in a new position
(some 25 pixels right of their pre-768-installation point).

PS I used 936 x 702 because if I made my dillo or abiword
less than full screen windows with other than a 4 x 3 ratio
they only opened in the exact position I wanted on exactly

every second opening.

Also, If he uses a slightly smaller pixel size it works (further down the puppy page).
Testing with snapshot 775 has not fixed the problem.

As I can't attach for some reason, the last post on page 5 of my puppy thread contains the request from 'f00.

http://www.murga-linux.com/puppy/viewtopic.php?t=83949&start=60

It would allow assignment of desktops to functions, such as development, internet, userapps, systemapps.

I think it may even allow the individual rox-filer background icons to be set for individual desktops.

Now, that I would love to see!

If an application un-maps and re-maps a window, as soon as the
window below it is raised, JWM 587..589 will crash at client.c
in RaiseClient(): Assert(np->prev); Looks like it started on
commit d3daff4, earlier versions don't have this problem.

Here is a small demo client to reproduce the problem:

/************************************************/
#include <X11/Xlib.h>

int main(int argc, char *argv[])
{
  XEvent ev;
  Display*dpy=XOpenDisplay(NULL);
  int id=DefaultScreen(dpy);
  XSetWindowAttributes att={0};
  Window win=XCreateWindow( dpy,RootWindow(dpy,id),16,16,96,72,0,
                            CopyFromParent,InputOutput,
                            XDefaultVisual(dpy,id),CWEventMask,&att );
  XMapWindow(dpy, win);
  XSync(dpy,0);
  while (1) {
    XUnmapWindow(dpy, win);
    XMapWindow(dpy, win);
    while (XPending(dpy)) { XNextEvent(dpy, &ev); }
    sleep(1); 
  }
  return 0;
}
/************************************************/

Hi, I've looked without success into placing the min max and close window button on the left of windows, or even better for me, on cloning them so they're both at the top left and top right. Maybe it's already possible and I just don't know how.

Fluxbox and Icewm handle this in a quite elegant way, where you can specify something like

TitleButtonsLeft="xmi"
TitleButtonsRight="s"

where x is close, m is maximise, s is shade, etc.

Anyways, thanks a lot for all the work on this awesome window manager!
Alex

Currently, when dragging windows in JWM, they stick to the edge of the screen and only after a configurable time out does JWM change desktops. The proposal is to have JWM change desktops immediately if the ALT key is pressed while moving a window.

Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567557

Resizing windows using the resize widget on the lower-right corner (usually part of a status-bar) causes the whole window to jump upwards by at least 10 to 14 pixels and resize continues with the mouse well below the window (see images below).

Problem can be reproduced by clicking (and holding) and dragging within a window using a similar resize widget.

Resizing windows from the outer lower-right border corner works correctly.

This is happening from all builds of JWM built from git (around 2013-03-21) to the present. Edit: This issue is not happening with JWM 2.1.0-3 included with Debian Wheezy.

Apps used to test: midori, thunar, pcmanfm, geany

Image 1 showing starting point of widget resize:

Image 2 showing window has jumped upward and resize now continues while mouse is well below the window:

reported by one of our puppy people, could you comment please joe.

my puppy thread for jwm is http://www.murga-linux.com/puppy/viewtopic.php?p=680002#680002

comment first appears in the 8th window from monsie

There is also a memory useage size problem mentioned, do you want a separate bug?

thanks

I assume the following behavior change is not on purpose:

Up to and including JWM 768 the tray was always on the topmost layer. Newly created windows did not overlap it, and if they did (or were manually moved towards the tray), then they ended up being partly behind the tray. Since JWM 771, windows can start up (or be manually moved) such that they are on top of the tray, making the tray inaccessible. Screenshots are attached.

Note: Some of the changes between JWM 768 and 771 concerned transient windows. Therefore I opened and closed the editor's "Save As ..." dialogue. On closing the dialogue, the tray came to the foreground.

I am transferring an open bug (plus patch) from SourceForge here, see:

http://sourceforge.net/p/jwm/bugs/24/

In short, jwm's round window / tray- & taskbar button / menu highlight corners are a matter of taste. Some (like me) prefer the more old-school, rectangular corners.

The round window corners are easy to remove, "./configure --disable-shape" gets rid of them. The other round corners can be made to disappear with the same method ("./configure --disable-shape") after the simple patch below has been applied.

I propose to integrate the patch into jwm because people likely want round corners either everywhere or nowhere, and that is what the patch achieves.

The patch still applies cleanly to the current jwm version 768.

--- jwm-579/src/button.c
+++ jwm-579-new/src/button.c
@@ -102,7 +102,11 @@

       /* Draw the outline. */
       JXSetForeground(display, gc, outlinePixel);
+#ifdef USE_SHAPE
       DrawRoundedRectangle(drawable, gc, x, y, width, height, 3);
+#else
+      JXDrawRectangle (display, drawable, gc, x, y, width, height);
+#endif

    }

quoting 'session' from puppylinux thread (p10)

OK, I have a tiny usability bug worth mentioning: If two+ windows share one application entry in the tray (ex. mtpaint w/ settings toolbar), you cannot minimize the windows with a left-click in the tray.

regards

Hi, getting multiple problems with building 729.

when l,ooked at, they all feed back to a error statement that says:

Line 5: @MKDIR_P@: Command not found

Maybe when you did your cleanup, you did one too many :-)

regards
scsijon

There is currently no way to modify mouse bindings in JWM.

Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497465

Currently JWM ignores the urgency hint field of WM_HINTS. JWM should indicate when a window has the urgency hint set (perhaps flash the border and task bar button(s)).

Currently the color of menu borders is computed based on the background color of the menu. This request is to allow that color to be customizable.
My proposal is to make the "Outline" tag in "MenuStyle" specify the menu border color (currently it specifies the color of the active item) and add "ActiveOutline" to specify the color of the active item. The color in "Outline" or "ActiveOutline" could be extended to support two colors separated by a colon so that the top/left border could be a different color than the bottom/left border.

Hi Joe,

Freshly downloaded and rebuilt jwm twice just to be sure.

xerrs.log is now giving an error, although it is not visably affecting operation. and I did have other apps running to test the previous error with 653 (which has gone away).

geany: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

Not sure if it's important or not, I shall play this afternoon and see if it's trackable.

sorry

Relates to version 686, version 679 was ok.

I am in testing getting a problem where on opening a number of different apps, that the app opens ok, but it's clearly not loading the config file associated to the application. It's like the loss of a path and it can't find either /root or individual config files in the applications path.

Easiest example to explain is Geany, where it opens, but has the default settings, as if it hasn't read it's config file. As if it's started the Geany Application but not included any variables or configs.

Also continually happens with almost all apps (openoffice, Libreoffice, Firefox, etc.) after it's happened once with other apps.

A jwm -reboot fixes nothing, nor does just dropping to shell and restarting jwm, it requires a full shutdown/reboot to fix the problem!