LiteStep.net Forums

RabidVWM will often shift the desktops by 1px down. This adds 1px of a blank row at the top, and a missing bottom row.

Is there any way to get rid of this, and just have it fill its height and width exactly? I would think with VWM desks matching in relative sizes (FI, 40x60 VWM, 2 across, 4 down, 4:3 exactly), it should just work, but it doesn't.
Here's an example (3x actual size): http://doddstech.com/vwm.png
Note that the top and bottom mini-windows are maximized, and jdesk is set to 0,0,0,0 for desk area.

I have noticed the same.

It's ugly to add an extra px for the bottom VWMDeskBorder, since that area doesn't seem to have any events associated with it.

well, that also does not rid the top of a border. However, adding another px to the actual height fixes the problem at the bottom. But since it does not do it at every width value, I'm leary of just using the border as-is, or setting the top border to -1, as certain sizes will display the way you'd think they would--I just haven't found any pattern to them.

Before I could pretty much ignore this, but much of the visual styles for my theme in progress are much higher contrast than I've used before.

Hmm, OK, don't know what this means, really, but here goes:
-Height of the VWM desks do not seem to affect this artifact.
-Width does. Up to a width of 38px per desktop, there is an extra pixel. At 39, it all fits perfectly. Starting at 44px per desktop, the miniwindows are fine vertically, but shifted 1px to the left, leaving a 1px right border. Beginning at 66, that border grows to 2px. I haven't tried any value above 80, as that makes for such a huge VWM :).

values that correct it visually (VWMDeskBorder):
0-38: 0 -1 0 0
39-43: 0 0 0 0
44-65: 1 0 -1 0
66-?: 1 0 -2 0

Here's a quick fix I managed to work up.

; ...start of other script here

*script exec !varSet Cclass 0
*script exec !IfEval ( "%{\1}" > "38" ) !varAdd Cclass 1
*script exec !IfEval ( "%{\1}" > "43" ) !varAdd Cclass 1
*script exec !IfEval ( "%{\1}" > "65" ) !varAdd Cclass 1
*script exec !IfEval ( "%{Cclass}" "%{CclassCheck}" ) !setVWM_desks_correction %{Cclass}
*script ~bang

*script bang !setVWM_desks_correction ; \correction class: 0 (0 -1 0 0), 1 (0 0 0 0), 2 (1 0 -1 0), 3 (1 0 -2 0)...but making that variable was difficult, resulting in corrupted themevars.rc
*script exec !varSet CclassCheck %{\1}
*script exec !IfEval ( "%{\1}" = "0" ) !execute [!varSet vwmDB_l "0"][!varSet vwmDB_t "-1"][!varSet vwmDB_r "0"][!varSet vwmDB_b "0"]
*script exec !IfEval ( "%{\1}" = "1" ) !execute [!varSet vwmDB_l "0"][!varSet vwmDB_t "0"][!varSet vwmDB_r "0"][!varSet vwmDB_b "0"]
*script exec !IfEval ( "%{\1}" = "2" ) !execute [!varSet vwmDB_l "1"][!varSet vwmDB_t "0"][!varSet vwmDB_r "-1"][!varSet vwmDB_b "0"]
*script exec !IfEval ( "%{\1}" = "3" ) !execute [!varSet vwmDB_l "1"][!varSet vwmDB_t "0"][!varSet vwmDB_r "-2"][!varSet vwmDB_b "0"]
; Had issues with !IfEq, so used !IfEval

; Below gets rid of the VWM and its label, and rebuilds both.
*script exec !vwmhide
*script exec !labelhide vwmBox
*script exec !labeldestroy vwmBox
*script exec !varsaveall
*script exec !reload
*script exec !netreloadmodule rabidvwm-1.1.1
*script exec !labelcreate vwmbox
*script ~bang

vwmDeskBorder $vwmDB_l$ $vwmDB_t$ $vwmDB_r$ $vwmDB_b$

And here are the corrections for VWMSelExpand, based on the width of each virtual workspace:
0-38: 0 -1 0 1
39-43: 0 0 0 0
44-65: 0 0 -1 0
66-?: 1 0 -2 0

Note that these are not perfect, and are affected by height!
However, these seem to be affected more by desk ratio than actual height, and work fine (in my testing) from 1:1 down to 3:2. However, vwm sixing gets strange once you go below the actual resolution's height/wodth ratio.
With 5:4 (1280x1024), an extra row is at the bottom with 4:3 or lower. With 4:3 (1024x768), an extra row is added starting at 3:2, so in both cases, unrealistic ratios to use.

I'm pretty sure this has been fixed for the next release... There was some small error in the calculations for a very long time that I no longer remember the specifics of, but this sounds about like it.

When is this next release due? It may be worthwhile to wait for it, rather than correct this, as I don't expect my theme to be ready before the end of September at the earliest.

Soon. Er, hopefully before then. It's pretty sad actually, I've got changes from last December in there...

Hehe :). Well, don't release it early on account of this or anything--I'd rather have a really good updated module than one with rushed errors.