Serious bug

[Donald Allen]

When doing a 'find' with my software, it pops up a dialog box to
collect a regexp from the user, as well as an indication of which
column to search. In hlwn in either vertical or horizontal layout
mode, the dialog gets popped up as a pseudo-tiled window, causing the
size of the register window that will be searched to shrink. When I
click 'ok' on the dialog, it disappears and the remaining windows,
including the account register window, are restored to their former
size. I'm suspicious that there is a bad interaction between what the
window manager and the X server are doing, and what my software does
when the 'find' completes to scroll to the found row (they *are* in
separate processes, after all). Perhaps the scrolling operation is
happening before the window size is restored when the pseudo-tiled
dialog disappears? This problem is reliably reproducible with vertical
or horizontal layouts. But if I switch to the 'max' layout, now the
dialog appears in a non-tiled window (unmanaged?) and so the register
window size is unaffected by the presence of the dialog. In this case,
scrolling to the found row works correctly, every time. Give this new
information, I just tried changing my autostart file like so:

diff --git a/autostart b/autostart
index 292ee5e..75c42c4 100755
--- a/autostart
+++ b/autostart
@@ -174,7 +174,7 @@ hc rule class=Gnome-alsamixer manage=off
 hc rule class=XClock manage=off

 hc rule focus=on # normally focus new clients
-hc rule windowtype~'_NET_WM_WINDOW_TYPE_(DIALOG|UTILITY|SPLASH)' pseudotile=on
+hc rule windowtype~'_NET_WM_WINDOW_TYPE_(DIALOG|UTILITY|SPLASH)' manage=off
 hc rule windowtype='_NET_WM_WINDOW_TYPE_DIALOG' focus=on
 hc rule windowtype~'_NET_WM_WINDOW_TYPE_(NOTIFICATION|DOCK|DESKTOP)' manage=off

Now the problem is gone. The dialog comes up unmanaged, the window
sizes are undisturbed, and the scroll to the found row works
correctly. Pseudo-tiling is clearly not a perfect substitute for
floating window support, at least as it is currently implemented. My
change to my autostart file solves this specific problem, but there
are times when I want to be able to move dialogs, because they might
pop up in a place obscuring something I need to see (e.g., the find
dialog in xpdf). Unmanaged windows can't be moved, so this is not a
perfect solution either.

/Don Allen

On Sat, May 16, 2015 at 10:42 PM, Donald Allen <donaldcallen at gmail.com> wrote:
> The day after I reported this problem, I sent another message saying
> that I'd tried this again and had no trouble. Since that time, I've
> been using xmonad because of other issues I found with hlwm. Today, I
> decided to try again. While reconciling an account with my newcash
> software, I ran into this issue again: transactions located with
> 'find' do not appear in the window, despite the gtk code that is
> supposed to insure that they do. And again, this works correctly with
> every other window manager I've tried. I think there's a real bug
> here.
>
> On Wed, Apr 22, 2015 at 11:10 AM, Donald Allen <donaldcallen at gmail.com> wrote:
>> As always, I'm running herbstluftwm 0.6.2-2 on an up-to-date 64-bit
>> Arch Linux system.
>>
>> I have written my own financial management software (which I will
>> release on github when I finish the documentation) called Newcash.
>> Just as your window manager owes a debt to dwm, my financial manager
>> owes a debt to Gnucash.
>>
>> Newcash is written in C (though I am now pretty far along with a
>> re-write it in Haskell, perhaps for similar reasons that you re-wrote
>> your window manager in C++) and is built on top of gtk+3 and sqlite3.
>> When started, a window containing the tree of accounts appears.
>> Double-click an account and you get an account register, showing all
>> the transactions associated with the selected account. I wanted to add
>> a new transaction that was similar to a transaction from a couple of
>> years ago. So I used the Newcash 'find' command, which provides a
>> regexp search of any transaction field. When you find the transaction
>> you are interested in, you can then duplicate it to create the new
>> one. The duplication saves the trouble of configuring the
>> transaction's splits with the right accounts.
>>
>> When the 'find' routine locates a transaction with a regexp match, it
>> scrolls the register window to it with gtk_tree_view_scroll_to_cell
>> and places the cursor in it with gtk_tree_view_set_cursor.
>>
>> Running herbstluftwm, it appears that the scrolling operation fails,
>> because the highlighted transaction is not shown in the window (I had
>> the two windows -- account tree and account register stacked
>> vertically in one frame). Hunting around a bit and I found it using
>> the mouse wheel.
>>
>> In dwm, xmonad, i3, and fvwm (all window managers I've tried with the
>> same Newcash code), this works properly.
>>
>> This is a serious problem for me, and I cannot use your window manager
>> until it is fixed. If I can help debug this, I'd be happy to do so.
>>
>> /Don