Serious bug

[Johannes Jordan]

Hello Donald,


first of all sorry you didn't get a reply yet (that I am aware of). I
think what you describe is an important issue that is hard to track down
properly. I also feel that your input is very much appreciated. While
nobody is working on this right now, it should come handy at a later
stage to know about this.

First of all, yes the pseudotile mode is a hack and eventually we need a
better solution to the problem of windows that just don't fit the
regular tiling, like most dialogs.

However I think the problem you are having is not related to
pseudotiling. Rather, it is related to the sudden geometry changes that
hlwm is forcing on clients. These happen whenever the tiling changes,
and your description sounds like that being the problem, not the dialog
itself.

There are other applications that have problems with hlwm's behavior.
For example Wesnoth, see my bug report at: https://gna.org/bugs/?23318
They use SDL.

Also Mysql Workbench has a similiar problem. In their case, the new
dialog is not properly setup when the window is spawned in tiling mode
and the buttons are not clickable. It is a Java application.


So I don't really know where the problem originates. Maybe hlwm does
something that in theory is correct, but unexpected, and that's where
some applications fail. I haven't seen problems with the Gtk3 apps I am
using but they are rare.

I think you should file a bug report with the GTK3 people. Maybe they
will take the time to look into this from their perspective.


Best,
Johannes

On 05/19/2015 05:37 PM, Donald Allen wrote:
> 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