Serious bug

[Kinley Dorji]

+1 Johannes Jordan.

On Wed, Jul 8, 2015 at 7:31 PM, 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.
>
> 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
>