From snabieel at gmail.com  Thu Jul  2 09:30:09 2015
From: snabieel at gmail.com (Suhaib Nabeil)
Date: Thu, 2 Jul 2015 03:30:09 -0400
Subject: MacBook Pro Retina
Message-ID: <CAGbJrLfCzRdwS4cbdo2iJ+pmKN1ejbRo31g8DDUi83PAR96p3A@mail.gmail.com>

Hello. 1st of all. I really love this wm and its is my main wm. Anyway, I
wanted to try this on a retina laptop so I took my mom's macbook and dual
booted it with Ubuntu 14.04. Next thing I did was installing herbstluftwm.
However, due to the retina display everything was small. picture here:
http://i.imgur.com/RasId88.png

Any suggestions ?

I can work around this by increasing the font size of urxvt terminal,
playing with firefox settings, etc... But I was wondering if implementing
something from your side is easy since Ubuntu already has a scale if we
change it we get a bigger layout (More like zoom in thing). Sorry if I was
mistaken since im not really a programmer.

example: Scale is 2.38 http://i.imgur.com/HCG9b3r.png
if Scale 1.75 http://i.imgur.com/Se0R0So.png


ps: Im using Macbook Pro 11.1
https://help.ubuntu.com/community/MacBookPro11-1/Saucy
Regards,
Suhaib Abdulghani


From jordan at lanrules.de  Thu Jul  2 11:56:33 2015
From: jordan at lanrules.de (Johannes Jordan)
Date: Thu, 2 Jul 2015 11:56:33 +0200
Subject: MacBook Pro Retina
In-Reply-To: <CAGbJrLfCzRdwS4cbdo2iJ+pmKN1ejbRo31g8DDUi83PAR96p3A@mail.gmail.com>
References: <CAGbJrLfCzRdwS4cbdo2iJ+pmKN1ejbRo31g8DDUi83PAR96p3A@mail.gmail.com>
Message-ID: <55950AD1.7050008@lanrules.de>

Hello Suhaib,


I don't know exactly what the Ubuntu slider is doing but the correct
method of adjusting font sizes is to set the DPI (dots per inch) of the
display correctly.

Now, for example, the Pro Retina 13" has 227 dpi and the 15" version 220
dpi according to: https://www.apple.com/de/macbook-pro/specs-retina/

To put that in perspective, a typical DPI value nowadays is below 100
and the X11 default should be 70.

You can find more information about DPI here:
https://wiki.archlinux.org/index.php/Xorg#Display_size_and_DPI

It might be as simple as running 'xrandr --dpi 220' and then restarting
applications.

As herbstluftwm is only a window manager and not a full-blown desktop,
it does not mangle with these settings.


Johannes


On 07/02/2015 09:30 AM, Suhaib Nabeil wrote:
> Hello. 1st of all. I really love this wm and its is my main wm. Anyway, I
> wanted to try this on a retina laptop so I took my mom's macbook and dual
> booted it with Ubuntu 14.04. Next thing I did was installing herbstluftwm.
> However, due to the retina display everything was small. picture here:
> http://i.imgur.com/RasId88.png
> 
> Any suggestions ?
> 
> I can work around this by increasing the font size of urxvt terminal,
> playing with firefox settings, etc... But I was wondering if implementing
> something from your side is easy since Ubuntu already has a scale if we
> change it we get a bigger layout (More like zoom in thing). Sorry if I was
> mistaken since im not really a programmer.
> 
> example: Scale is 2.38 http://i.imgur.com/HCG9b3r.png
> if Scale 1.75 http://i.imgur.com/Se0R0So.png
> 
> 
> ps: Im using Macbook Pro 11.1
> https://help.ubuntu.com/community/MacBookPro11-1/Saucy
> Regards,
> Suhaib Abdulghani
> 


From snabieel at gmail.com  Fri Jul  3 02:39:20 2015
From: snabieel at gmail.com (Suhaib Nabeil)
Date: Thu, 2 Jul 2015 20:39:20 -0400
Subject: MacBook Pro Retina
In-Reply-To: <55950AD1.7050008@lanrules.de>
References: <CAGbJrLfCzRdwS4cbdo2iJ+pmKN1ejbRo31g8DDUi83PAR96p3A@mail.gmail.com>
 <55950AD1.7050008@lanrules.de>
Message-ID: <-69153343340593809@unknownmsgid>

Thank you Johannes. The xrandr command helped a lot except for
chromium. I won't complain though, since chromium looks nice as it is.
That being said, I went to chromium's setting and changed the zoom
from 100% to 175%

Regards,
Suhaib Nabiel

> On Jul 2, 2015, at 5:56 AM, Johannes Jordan <jordan at lanrules.de> wrote:
>
> Hello Suhaib,
>
>
> I don't know exactly what the Ubuntu slider is doing but the correct
> method of adjusting font sizes is to set the DPI (dots per inch) of the
> display correctly.
>
> Now, for example, the Pro Retina 13" has 227 dpi and the 15" version 220
> dpi according to: https://www.apple.com/de/macbook-pro/specs-retina/
>
> To put that in perspective, a typical DPI value nowadays is below 100
> and the X11 default should be 70.
>
> You can find more information about DPI here:
> https://wiki.archlinux.org/index.php/Xorg#Display_size_and_DPI
>
> It might be as simple as running 'xrandr --dpi 220' and then restarting
> applications.
>
> As herbstluftwm is only a window manager and not a full-blown desktop,
> it does not mangle with these settings.
>
>
> Johannes
>
>
>> On 07/02/2015 09:30 AM, Suhaib Nabeil wrote:
>> Hello. 1st of all. I really love this wm and its is my main wm. Anyway, I
>> wanted to try this on a retina laptop so I took my mom's macbook and dual
>> booted it with Ubuntu 14.04. Next thing I did was installing herbstluftwm.
>> However, due to the retina display everything was small. picture here:
>> http://i.imgur.com/RasId88.png
>>
>> Any suggestions ?
>>
>> I can work around this by increasing the font size of urxvt terminal,
>> playing with firefox settings, etc... But I was wondering if implementing
>> something from your side is easy since Ubuntu already has a scale if we
>> change it we get a bigger layout (More like zoom in thing). Sorry if I was
>> mistaken since im not really a programmer.
>>
>> example: Scale is 2.38 http://i.imgur.com/HCG9b3r.png
>> if Scale 1.75 http://i.imgur.com/Se0R0So.png
>>
>>
>> ps: Im using Macbook Pro 11.1
>> https://help.ubuntu.com/community/MacBookPro11-1/Saucy
>> Regards,
>> Suhaib Abdulghani
>>


From jordan at lanrules.de  Wed Jul  8 15:31:55 2015
From: jordan at lanrules.de (Johannes Jordan)
Date: Wed, 8 Jul 2015 15:31:55 +0200
Subject: Serious bug
In-Reply-To: <CAPsTYbwVOAtX2Tz+cW-Bw-pCTG4ia_VNTPP34gidPSMtqQTYGg@mail.gmail.com>
References: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
 <CAPsTYbyCMM7XJd=3n4aghrAupqnToPYP1kpO4Nt8FF6fGRJ0Lg@mail.gmail.com>
 <CAPsTYbxo5edvPw2EHL_K1oLB=8sQdN3h7tAo-HvJN_j5GDT8+g@mail.gmail.com>
 <CAPsTYbwVOAtX2Tz+cW-Bw-pCTG4ia_VNTPP34gidPSMtqQTYGg@mail.gmail.com>
Message-ID: <559D264B.9040404@lanrules.de>

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


From kinleyd at gmail.com  Wed Jul  8 16:19:40 2015
From: kinleyd at gmail.com (Kinley Dorji)
Date: Wed, 8 Jul 2015 20:19:40 +0600
Subject: Serious bug
In-Reply-To: <559D264B.9040404@lanrules.de>
References: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
 <CAPsTYbyCMM7XJd=3n4aghrAupqnToPYP1kpO4Nt8FF6fGRJ0Lg@mail.gmail.com>
 <CAPsTYbxo5edvPw2EHL_K1oLB=8sQdN3h7tAo-HvJN_j5GDT8+g@mail.gmail.com>
 <CAPsTYbwVOAtX2Tz+cW-Bw-pCTG4ia_VNTPP34gidPSMtqQTYGg@mail.gmail.com>
 <559D264B.9040404@lanrules.de>
Message-ID: <CACtZaFKfrvYudOaFto7D4Fg9mvJDhTfiqV8j6+He9kUL4QFesw@mail.gmail.com>

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


From donaldcallen at gmail.com  Wed Jul  8 16:32:10 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Wed, 8 Jul 2015 10:32:10 -0400
Subject: Serious bug
In-Reply-To: <559D264B.9040404@lanrules.de>
References: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
 <CAPsTYbyCMM7XJd=3n4aghrAupqnToPYP1kpO4Nt8FF6fGRJ0Lg@mail.gmail.com>
 <CAPsTYbxo5edvPw2EHL_K1oLB=8sQdN3h7tAo-HvJN_j5GDT8+g@mail.gmail.com>
 <CAPsTYbwVOAtX2Tz+cW-Bw-pCTG4ia_VNTPP34gidPSMtqQTYGg@mail.gmail.com>
 <559D264B.9040404@lanrules.de>
Message-ID: <CAPsTYbyoobfHuDF0pNQeRKoh2t5_X5L9Ezyk7m8vzikES3a5Ug@mail.gmail.com>

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


From jordan at lanrules.de  Wed Jul  8 16:45:37 2015
From: jordan at lanrules.de (Johannes Jordan)
Date: Wed, 8 Jul 2015 16:45:37 +0200
Subject: Serious bug
In-Reply-To: <CAPsTYbyoobfHuDF0pNQeRKoh2t5_X5L9Ezyk7m8vzikES3a5Ug@mail.gmail.com>
References: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
 <CAPsTYbyCMM7XJd=3n4aghrAupqnToPYP1kpO4Nt8FF6fGRJ0Lg@mail.gmail.com>
 <CAPsTYbxo5edvPw2EHL_K1oLB=8sQdN3h7tAo-HvJN_j5GDT8+g@mail.gmail.com>
 <CAPsTYbwVOAtX2Tz+cW-Bw-pCTG4ia_VNTPP34gidPSMtqQTYGg@mail.gmail.com>
 <559D264B.9040404@lanrules.de>
 <CAPsTYbyoobfHuDF0pNQeRKoh2t5_X5L9Ezyk7m8vzikES3a5Ug@mail.gmail.com>
Message-ID: <559D3791.5050100@lanrules.de>



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


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.


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


From donaldcallen at gmail.com  Wed Jul  8 17:20:37 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Wed, 8 Jul 2015 11:20:37 -0400
Subject: Serious bug
In-Reply-To: <559D3791.5050100@lanrules.de>
References: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
 <CAPsTYbyCMM7XJd=3n4aghrAupqnToPYP1kpO4Nt8FF6fGRJ0Lg@mail.gmail.com>
 <CAPsTYbxo5edvPw2EHL_K1oLB=8sQdN3h7tAo-HvJN_j5GDT8+g@mail.gmail.com>
 <CAPsTYbwVOAtX2Tz+cW-Bw-pCTG4ia_VNTPP34gidPSMtqQTYGg@mail.gmail.com>
 <559D264B.9040404@lanrules.de>
 <CAPsTYbyoobfHuDF0pNQeRKoh2t5_X5L9Ezyk7m8vzikES3a5Ug@mail.gmail.com>
 <559D3791.5050100@lanrules.de>
Message-ID: <CAPsTYbwPbUYOHnWZo86Y=ag5S8SVkSpSC=5T3Mb_SHE5LBLAOA@mail.gmail.com>

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


From jordan at lanrules.de  Wed Jul  8 21:02:19 2015
From: jordan at lanrules.de (Johannes Jordan)
Date: Wed, 8 Jul 2015 21:02:19 +0200
Subject: Serious bug
In-Reply-To: <CAPsTYbwPbUYOHnWZo86Y=ag5S8SVkSpSC=5T3Mb_SHE5LBLAOA@mail.gmail.com>
References: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
 <CAPsTYbyCMM7XJd=3n4aghrAupqnToPYP1kpO4Nt8FF6fGRJ0Lg@mail.gmail.com>
 <CAPsTYbxo5edvPw2EHL_K1oLB=8sQdN3h7tAo-HvJN_j5GDT8+g@mail.gmail.com>
 <CAPsTYbwVOAtX2Tz+cW-Bw-pCTG4ia_VNTPP34gidPSMtqQTYGg@mail.gmail.com>
 <559D264B.9040404@lanrules.de>
 <CAPsTYbyoobfHuDF0pNQeRKoh2t5_X5L9Ezyk7m8vzikES3a5Ug@mail.gmail.com>
 <559D3791.5050100@lanrules.de>
 <CAPsTYbwPbUYOHnWZo86Y=ag5S8SVkSpSC=5T3Mb_SHE5LBLAOA@mail.gmail.com>
Message-ID: <559D73BB.2020002@lanrules.de>

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


From donaldcallen at gmail.com  Thu Jul  9 00:03:01 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Wed, 8 Jul 2015 18:03:01 -0400
Subject: Serious bug
In-Reply-To: <559D73BB.2020002@lanrules.de>
References: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
 <CAPsTYbyCMM7XJd=3n4aghrAupqnToPYP1kpO4Nt8FF6fGRJ0Lg@mail.gmail.com>
 <CAPsTYbxo5edvPw2EHL_K1oLB=8sQdN3h7tAo-HvJN_j5GDT8+g@mail.gmail.com>
 <CAPsTYbwVOAtX2Tz+cW-Bw-pCTG4ia_VNTPP34gidPSMtqQTYGg@mail.gmail.com>
 <559D264B.9040404@lanrules.de>
 <CAPsTYbyoobfHuDF0pNQeRKoh2t5_X5L9Ezyk7m8vzikES3a5Ug@mail.gmail.com>
 <559D3791.5050100@lanrules.de>
 <CAPsTYbwPbUYOHnWZo86Y=ag5S8SVkSpSC=5T3Mb_SHE5LBLAOA@mail.gmail.com>
 <559D73BB.2020002@lanrules.de>
Message-ID: <CAPsTYbwOFpMn85fN-QoOfsXmBCGLaBL7dRUywT1fMQR4S6vpfQ@mail.gmail.com>

On Wed, Jul 8, 2015 at 3:02 PM, Johannes Jordan <jordan at lanrules.de> wrote:
> Resizes to a window can always happen. A prominent toolkit like GTK
> should be able to handle resize requests at all time.

Now you presume that the problem is gtk's and not hlwm or Xlib. Which
is unjustified, since you don't know where the problem is.

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

Gtk isn't causing the resizing in this "funny scenario" -- hlwm is. I
repeat for the nth time -- no resizing takes place in this situation
with any other window manager, tiling or otherwise.

As for the scrolling caused by my application being a "funny
scenario", spreadsheet 'find' commands do exactly what my application
does, causing the underlying window to scroll based on what is entered
into a dialog box, as do text editors, word processors and pdf
readers, among others.

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

I do agree about that -- hlwm needs to support floating windows.


From et at ethome.sk  Tue Jul 14 21:16:48 2015
From: et at ethome.sk (Martin "eto" Misuth)
Date: Tue, 14 Jul 2015 21:16:48 +0200
Subject: MacBook Pro Retina
In-Reply-To: <55950AD1.7050008@lanrules.de>
References: <CAGbJrLfCzRdwS4cbdo2iJ+pmKN1ejbRo31g8DDUi83PAR96p3A@mail.gmail.com>
 <55950AD1.7050008@lanrules.de>
Message-ID: <20150714211648.7e3a1fdf@mona>

On Thu, 2 Jul 2015 11:56:33 +0200
Johannes Jordan <jordan at lanrules.de> wrote:

Hehe, welcome to *nix gui "fragmentation".

I was experimenting with hires display too, but gave up in the end and returned 
to "lowres".

Correct way, as Johannes pointed out, should be to set DPI at XOrg level.
The problem with X is that it supposedly defines "mechanisms not policy".

What that means: it is really lower level stuff. And doesn't enforce anything.

More over, X accumulated lot of cruft over the years, and it seems to be
incredibly hard to program for.
As such it has several font subsystems: bitmap and clientside Xft.

Bitmap fonts which urxvt and most "simpler" terminals can use, depend directly
on onscreen pixel sizes.

Then you have so called client side fonts (I hope that is the correct term here)
provided through Xft, where applications themselves manage it's font glyph
cache (seems to me that this is controlled by some complex interaction between
Xft and fontconfig technologies).

The situation is made even more complex by GUI middlemen, called toolkit
libraries (gtk, qt) which do their own thing and each one in different way.

Toolkit libraries can decide on font sizes by pulling DPI size from different
sources: XOrg DPI settings perhaps, config files, and various configuration
management daemons (gnome helpers, kde helpers, xsettingsd and whatnot).

Then there are programs like chromium, firefox, libreoffice and others which
seem to use one DPI source for drawing generic GUI elements (menus and butons),
where they offload decision to GUI toolkit, and yet others more direct ways for
drawing text in document content windows (webpages, documents).

As such any application, depending on a way it's programmed, can mix various
approaches, making you as user almost lose all sanity :).

This can end up being one giant mess of config sources, and many
desktop environments go out of their ways to somehow consolidate it.

herbstluftwm is however window manager only, so it doesn't deal with any of
that.

I personally use mix of xsettingsd, fontconfig and xrandr DPI and after years
got to somewhat workable environment.

It's infuriating, but your best bet is to solve size issues on per application
basis.

eto