Wed 14 Oct 2009 12:56:02 AM UTC, comment #16:
Sounds good - I recalled highlightThickness from
some long-ago work (perhaps $dayjob rather than
vile), and once I got pointed at the window frame,
that seemed a possibility.
|
Wed 14 Oct 2009 12:50:46 AM UTC, comment #15:
I tried it today. It looks great and behaves exactly as I was hoping. Many thanks!
|
Tue 13 Oct 2009 11:55:30 PM UTC, comment #14:
Well, I think I've fixed it in 9.7v - please
check. Steve Lembark reported a problem with
select/paste which I think I fixed in 9.7v also,
but that's unconfirmed. (It's all working for me
of course).
|
Tue 13 Oct 2009 12:33:37 AM UTC, comment #13:
Many thanks!
|
Sat 10 Oct 2009 12:37:22 AM UTC, comment #12:
I think the problem is that xvile is mishandling
the highlightThickness resource around the screen
widget. That's moderately hard to rework, but I
can override it (to turn it off).
The window frame would highlight anyway - and
the symptom that I can see doesn't have a workable
focus-highlight on that widget.
Will put that fix in 9.7v
|
Thu 06 Aug 2009 08:44:28 PM UTC, comment #11:
I see - I was thinking entirely of the inter-line spacing
(which has been associated with more than one bug report).
I'll investigate that - thanks
|
Thu 06 Aug 2009 03:46:12 PM UTC, comment #10:
Some small modifications to the preceding narrative:
1. On the top of a character cell on the top row of the text pane the 1px border is not erased by drawing characters.
1.5 BUT if part of the xvile window is obscured, but raised by clicking on the title (under fvwm 2.5.x), top row characters and characters along a side that were obscured prior to the click (not the whole thing, just the part that was obscured and made visible) have no border pixel.
1.75 BUT if the window is refreshed and on top, the border is drawn around the whole text area and not erased by any characters.
2. The cursor (non-blinking block cursor) erases the border wherever they meet.
|
Thu 06 Aug 2009 03:04:46 PM UTC, comment #9:
(Finally got a login, so no more anonymous posting :)
Maybe if I frame the narative a little differently ...
When the xvile window gains the focus, a 1-pixel border is drawn around the text frame, after which (at least to the equivalent effect of "after which") xvile draws the characters, and if any characters are on the border (top row or leftmost or rightmost column), the 1px border gets erased in those character cells. It is also drawn below the command line, but that one never scrolls, and it gets erased character by character when a command is entered.
(I have no knowledge of programming against Motif, so what I'm about to say may have no resemblance to reality. Feel free to laugh, but please do it quietly ...)
It seems that if you widened and lengthened the text frame by two pixels each way and drew the character cells inside that and only scrolled inside that extra border, it would work fine. Of course, I don't know how much it would be worth it, except for legacy support ...
|
Tue 04 Aug 2009 11:47:36 PM UTC, comment #8:
I did investigate (right after your last note),
but didn't discover anything useful. I built
xvile manually (installed the OpenMotif port,
and configured manually). I also modified the
code to pretend that the characters were higher
than the font said (to see the interline spacing
that xvile is supposed to color - and it did
that properly as far as I could tell).
So I'm uncertain whether there's something that
I can work around in xvile's source code, or
whether the problem lies inside Motif (or the
version on Solaris 8). (I have OpenMotif on
two versions of Linux as well as the FreeBSD 6,
and was interested in FreeBSD since malloc's
aren't zero-filled there as they are on Linux).
|
Tue 04 Aug 2009 09:12:35 PM UTC, comment #7:
Tom, I'm back after a prolonged absence due to a family issue. Have you had a chance to get to this yet?
Also, the xvile port on FreeBSD doesn't seem to offer Motif as an i/f option. Do you build it manually to get that? (I have the Motif libs installed for the sake of another port.)
|
Tue 07 Jul 2009 08:54:09 AM UTC, comment #6:
thanks. It occurred to me that I'm not seeing
the problem since Linux memory allocation always
zeros memory - which would cover up a lot of
problems in the X libraries. I can test this on
FreeBSD, which doesn't do that (will see if that
helps).
|
Mon 06 Jul 2009 01:20:13 PM UTC, comment #5:
Sorry for the delay in my reply. (A family member is seriously ill.) These are all my resources related to XVile (minus the font resource so I don't have to try to remember the markup). But even if I comment all the resources, log out, log back in the weird lines are still present.
XVile*background: gray7
XVile*foreground: gray90
XVile.color.fcolor1: gray70
XVile.color.fcolor2: green
XVile.color.fcolor3: sandybrown
XVile.color.fcolor4: lightblue
XVile.color.fcolor5: magenta
XVile.color.fcolor6: cyan
XVile.color.fcolor7: lightgray
XVile.color.fcolor8: gray
XVile.color.fcolor9: indianred1
XVile.color.fcolorA: brightgreen
XVile.color.fcolorB: yellow
XVile.color.fcolorC: brightblue
XVile.color.fcolorD: brightmagenta
XVile.color.fcolorE: brightcyan
XVile.color.fcolorF: white
|
Wed 24 Jun 2009 12:42:12 AM UTC, comment #4:
Do you have any X resources set for xvile?
I can "see" the "same" titlebar coloring if
I suppress my resource settings for xvile.
At the moment I'm not on the machine with Motif,
and Lesstif is not showing me a highlighting
frame in the window. That might be a feature
of Motif, or it might be partly your resource
settings. (It might not be relevant, but I don't
know...).
|
Tue 23 Jun 2009 06:20:50 PM UTC, comment #3:
Sorry about the weirdness of the font thing: Apparently the asterisk is some kind of markup in this system. Here's a try at bypassing that:
XVile*font: -b&h-lucidatypewriter-medium-r-normal-sans-12-*-*-*-*-0-iso8859-1
|
Tue 23 Jun 2009 06:13:38 PM UTC, comment #2:
The font line from .Xdefaults (symlinked to .Xresources) is
XVilefont: -b&h-lucidatypewriter-medium-r-normal-sans-12----*-0-iso8859-1
A little more info: When the focus moves from another window to the xvile window, a highlighting frame appears around the edges of the window, i.e., just inside the window manager's frame. Check the new attachments xvile-before.gif and xvile-after.gif. Then when I use the behavior in the original post, I see the behavior noted.
(file #18310, file #18311)
|
Mon 22 Jun 2009 11:41:41 PM UTC, comment #1:
I haven't seen that for a while, but expect
that the problem may depend on the font choice
(family and size, etc). It would be happening
if xvile and Motif disagree on the height of the
character cells, so that repainting doesn't fill
the inter-line area.
In a quick check with the fonts I've available
on Linux (using OpenMotif), I'm not seeing the
problem. But learning more about the fonts used
in your configuration could help me reproduce the
problem, and improve the layout.
|
Mon 22 Jun 2009 02:59:25 AM UTC, original submission:
When I compile Vile using --with-screen=Motif on Solaris 8 with gcc 3.x, using ^Y to scroll backward, change focus to another window, change focus back to xvile, repeating these steps several times, I get the weird lines as shown in the attachment.
This bug has existed for several years.
|