Serious bug

[Donald Allen]

Reading the man page a bit more, particularly the Rules section, made
me realize that I can be a bit more selective about unmanaged dialogs:

diff --git a/autostart b/autostart
index 292ee5e..8a86ac9 100755
--- a/autostart
+++ b/autostart
@@ -174,7 +174,8 @@ 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)' class=Newcash manage=off
+hc rule windowtype~'_NET_WM_WINDOW_TYPE_(DIALOG|UTILITY|SPLASH)'
class not =Newcash pseudotile=on
 hc rule windowtype='_NET_WM_WINDOW_TYPE_DIALOG' focus=on
 hc rule windowtype~'_NET_WM_WINDOW_TYPE_(NOTIFICATION|DOCK|DESKTOP)' manage=off

By the way, I hope you are realizing that my messages are intended
constructively. I like the design of hlwm very much. The use of the
shell for configuration, rather than rolling your own makes a lot of
sense. I am also a fan of manual tiling (I spent some time working
with musca some years ago, but gave up because there were just too
many bugs and the developer had abandoned it). I'm not a fan of C++;
I'm very much in Linus Torvalds' camp on this one. But if you can
manage to produce quality software in the language, more power to you
(have you folks looked at Go? http://golang.org ). So I'm generally
enthusiastic about your work and would like to help iron out the
kinks.

/Don Allen

On Tue, May 19, 2015 at 9:40 AM, Donald Allen <donaldcallen at gmail.com> wrote:
> 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