In message <iczhmw6v76....@home.home>,
Dan Espen <dan1es...@gmail.com> wrote:
>I think I did another post dealing with xclock, if not change the above
>like this:
>
>xclock -digital -strftime '%a %b %d %T' -geom 300x50+200+200
> ^^^^^^^^^^^^^^^^^^^^
OK, so, none of the suggestions that I've received regarding this one
simple change have been anyweher near correct. That's probably partly
my fault because I apparently didn't explain what I wanted to do all
that well. (But in my own defense, that wasn't entirely my fault, as
I will explain.)
The default theme for fvwm includes a big box that appears in the lower
right hand corner of the screen. Is there a name for that whole thing?
If so, and if someone would be kind enough to tell me what it is, then
I'll know what to call it in future.
Anyway, that wide but not very tall box includes several different parts:
1) A part where all of the current open windows are listed by name (and
each name is clickable)
2) A square part consisting of a sort of map, divided into four quadrants
that shows you whar part of your four-part virtual desktop you
are currently actually looking at.
3) A third and final square part, the same size as part 2, but which is
itself subdivided into three parts:
3a) A square space where the biff mailbox+flag icon appears.
3b) A square space where a small analog xclock appears.
3c) A double-wide space, just beneath 3a and 3b where an xload
system load graph is *intended* to appear. (This is what
kept on referring to as "the blank space".)
For me, 3c was in fact just a blank space. I just now figured out why. On
FreeBSD, the xload command is in a separate package, all on its own, and that
package is *not* currently listed as dependency of the fvwm package. (I will
be speakingt o the maintainer about this.) As a result, my system was running
without xload even installed. As a result, the space 3c appeared to be just
an empty blank space to me. Onec i installed the xload package and restarted
X and fvwm however, I got a nice pretty load graph in that double-wide space
that I am called 3c.
But I personally am not at all interested in see a load graph. I want, and
wanted, a digital xclock in there.
There is/was alreadyy a line in the default theme file that put the xload
graph into the 3c space:
*FvwmButtons: (2x1 Frame 2 Swallow(UseOld,NoHints,Respawn) "xload" `Exec exec
xload -bg bisque3 -fg black -update 5 -nolabel`)
I ended up simply commenting that out and substituting in the followiing
instead:
*FvwmButtons: (2x1 Frame 2 Swallow(UseOld,NoHints,Respawn) "xclock" `Exec exec
xclock -bg bisque3 -fg black -padding 3 -update 1 -digital -strftime '%a %b
%d'`)
Note that this give me at least part of what I want/wanted. Now at least I am
getting something that looks like:
Wed Jun 05
in that "blank" space that I am calling 3c... in place of the xload load graph,
which I really don't have any interest in.
I am *not* getting all of what I had hoped for, which was the day of week,
the abbreviated month name, and the day of the month PLUS the current HH:MM:SS
(time) but that's simply because the space provide for 3c is not really enough
to hold all of this info, at least not without resducing the point size used
for the digital xclock to the point where it would become unmreadable.
Actually, there is more than enough vertivcal space in the 3c box to hold
*two* lines of text, so in theory , at least, I could do:
xclock -bg bisque3 -fg black -padding 3 -update 1 -digital -strftime '%a %b
%d%n%T'
and thus get something like:
Wed Jun 05
14:35:17
in the space allocated for the 3c box, but there apparently exits what I must
assume is a longstanding bug in xclock -digital where the strftime %n (newline)
conversion specification, which *is* understood, by strftime, and which *is*
documented in the man page for the libc strftime() function, is not being
handled at all properly by the xclock program... yet another thing that I
will be filing a bug report on.
In any case, I would like to suggest to the fvwm maintainers that they do as
I have done and substitute out the xload invocation in the default theme and
replace it, as I have done, with a digital xclock display of the current date.
This is vastly more likely to be useful to the typical end user than a system
load graph. Also, of course, this substitution will reduce the possibility...
which I actually encountered... of the xload program/dependency not even being
present, resulting in a rather curious looking empty space in the default fvwm
theme.
I certainly hate to make any reference to any Microsoft OS when conversing
with any UNIX people... such as all of you folks... but I must not refrain
from noting that on Windows7, at least, the user *does not* see a system load
graph, by default, but *does* see the current date & time in the lower right
hand corner of his/her screen, by default. Obviously, this is useful
information to have on screen at all times.
One last thing... As I previously mentioned, there is a rather self-evident
bug in fvwm which involves minimized windows and their corresponding icons.
Specifically, for reasons that I personally am none too clear on, the icons
representing minimized xterm windows all get nicely lined up against the right
hand margin of the current desktop, while icons representing minimized browser
windows all get nicely lined up against the bottom edge of the current desktop.
This is all well and good unless and until one accumulates a lot of such icons,
of either type. When and if you do, some of those will end up being rendered
*underneath* (and thus partially or totally obscured by) the set of boxes,
created by the default theme, as I described them above.
I would really appreciate it if the maintainers would fix this self-evident
bug. It is most annoying. The minimization/iconization process should not
be hiding minimized window icons underneath the boxes created by the default
theme. That's just wrong, and one would hope that there might be some simple
way to get the window minimization/iconization process to avoid doing this
annoying and clearly wrong thing.
Regards,
rfg
