Serious bug

[Johannes Jordan]

Resizes to a window can always happen. A prominent toolkit like GTK
should be able to handle resize requests at all time.

Only the GTK people can decide how important this bug is to them. It is
a funny scenario after all. Both your application and the window manager
do things on their own that are typically done by the user manually
(scrolling and resizing).

That said, we all, or I know at least most of us, agree that we would
greatly benefit from a better solution for dialogs, regardless of this bug.

On 07/08/2015 05:20 PM, Donald Allen wrote:
> On Wed, Jul 8, 2015 at 10:45 AM, Johannes Jordan <jordan at lanrules.de> wrote:
>>
>>
>> On 07/08/2015 04:32 PM, Donald Allen wrote:
>>> Another possibility is that hlwm is doing something that is incorrect.
>>
>> Yes certainly. That's why we need to keep this in mind as I wrote.
>> Probably Thorsten can better comment on that possibility. As I see it,
>> there is not much you can do wrong with sending out window sizes to
>> X. But I don't know enough details on this.
>>
>>
>>> 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.
>>
>> I very well understand that perspective. However, from hlwm's
>> perspective, it looks the opposite. It is resizing windows all the time
>> for a wide enough user base.
> 
> In the case of my application, the dialog causes a tiled window to
> scroll after the dialog is dismissed. The difference here is that the
> dismissal results in the window being scrolled also changing size,
> because the now-defunct dialog was part of the tiling layout.
> 
> My point about filing a bug report with GTK is not that it is
> impossible that it's their bug. It's that I can't imagine them being
> willing to spend any time on trying to find a bug that might not be
> theirs that is caused by a window manager that uses a hack instead of
> implementing floating windows, as all the other tilers (of which I am
> aware) do.
> 
>  I mean, that's the most basic thing a
>> window manager does, right? And it is only a few applications (three
>> that we know of right now) that have problems.
> 
> Yes, resizing is basic. This situation. simultaneous resizing and
> scrolling, is not. It's unusual, almost certainly brought about by
> hlwm's lack of support for floating windows.
> 
>>
>>
>> So you see it goes either way.
>> However I have a follow-up question for you: Does the problem also occur
>> without pseudotiling (i.e., keeping the window managed, but not putting
>> it in pseudotile)? Because my expectation is that it does and the
>> admitted hack has nothing to do with this.
> 
> I would expect the same. I believe the problem lies in disturbing the
> underlying window sizes when a dialog appears. When I get some time to
> do so, I will test this. I am not using hlwm because of this and other
> issues, so it's not a completely simple matter to test, but not a big
> deal either.
> 
>>
>>
>> Anecdotal:
>> I have a problem with KWindowSystem not recognizing window lists
>> provided by hlwm (i.e. the lxqt taskbar shows nothing). Easy to blame on
>> hlwm, "every" other WM works. But then if you look at the root window's
>> properties, you see that the information is there, EHWM compliant. In
>> both cases, it is the clients that do the complicated work and therefore
>> they are easier to fail.
>>
>>
>> Johannes