Serious bug

[Donald Allen]

On Wed, Jul 8, 2015 at 9:31 AM, Johannes Jordan <jordan at lanrules.de> wrote:
> 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.

Another possibility is that hlwm is doing something that is incorrect.

>
> 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.

I was nodding in agreement with your message until I got to the two
paragraphs just above. You are suggesting that I say to the GTK folks
that I have a GTK application that works correctly with every window
manager except hlwm, which uses an admitted hack, pseudo-tiling, for
dialogs, which disturbs the underlying tiling layout, instead of
floating windows, which don't, so I'm filing a bug report with GTK?
I'm afraid that doesn't make a lot of sense to me.

/Don

>
>
> 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