From edu at thorsten-wissmann.de  Sun Apr 12 17:45:20 2015
From: edu at thorsten-wissmann.de (Thorsten =?iso-8859-1?Q?Wi=DFmann?=)
Date: Sun, 12 Apr 2015 17:45:20 +0200
Subject: Binary trees?
In-Reply-To: <CAPsTYbzsCHn4aQDwgz6Q7REKyX=XrNHikKeGkHNXDoguA+pQMQ@mail.gmail.com>
References: <CAPsTYbzsCHn4aQDwgz6Q7REKyX=XrNHikKeGkHNXDoguA+pQMQ@mail.gmail.com>
Message-ID: <20150412154520.GA13969@hoth.localdomain>

Hi Donald,

On Sun, Apr 12, 2015 at 11:27:12AM -0400, Donald Allen wrote:
> Why does the man page for the window manager say "The basic tiling
> concept is that the layout is represented by a binary tree."

The layout is represented by a binary tree of frames, i.e. only the
frames form the binary tree. Or more specifically: a binary tree of
frames with lists of windows (and other properties stored) in the
leaves.

Furthermore, the layout is rigid in the sense that it is only modified
by user-interaction and not by appearing or disappearing windows.

Btw: e.g. i3 is different here: their layout of containers (their word
for frames) is not binary but n-ary, i.e. you can have a frame with
three subframes in it.

Hope, that helps. :-)

Cheers,
Thorsten

P.S.: the current (and long-term) address of the mailing list is

    hlwm at lists.herbstluftwm.org

> If I start three xterms in an empty frame, they get stacked
> vertically. If it then do a layout command, I get
>
> dca at franz:~$ herbstclient layout
> ??? vertical: 0x800022 0xc00022 0x1e00022 [FOCUS]
>
> The vertical frame has three children, not possible in a binary tree.
> Using n-ary trees makes sense, and that appears to be what you are
> doing. But the man page says otherwise. Please explain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20150412/e5acab0a/attachment.sig>

From donaldcallen at gmail.com  Sun Apr 12 18:05:37 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Sun, 12 Apr 2015 12:05:37 -0400
Subject: Binary trees?
In-Reply-To: <20150412154520.GA13969@hoth.localdomain>
References: <CAPsTYbzsCHn4aQDwgz6Q7REKyX=XrNHikKeGkHNXDoguA+pQMQ@mail.gmail.com>
 <20150412154520.GA13969@hoth.localdomain>
Message-ID: <CAPsTYbxsREWpBhjrM_1pfk2SLC_Av33azsBKcFom6NjR1s5u2A@mail.gmail.com>

Thank you both. I understand now -- the tree consists only of frames,
not frames and windows, as I thought (and as is the case with i3).

Speaking of i3, I would comment that while i3 is very well done, I
find that a weakness is that to achieve the layout you want, you have
to have a good mental model of its internal behavior as you add
windows and move them around. This is not easily achieved and I have,
on occasion, become terribly frustrated with it, because I've had to
fight with it to get it to do what I want and haven't always won. I
think the problem is the complexity of that internal behavior. It is
not easily explained and I don't think the documentation overcomes
that difficulty.

I don't have a lot of experience yet with your effort, but there have
been no layout battles thus far.

Again, thanks for the explanations.

/Don

On Sun, Apr 12, 2015 at 11:45 AM, Thorsten Wi?mann
<edu at thorsten-wissmann.de> wrote:
> Hi Donald,
>
> On Sun, Apr 12, 2015 at 11:27:12AM -0400, Donald Allen wrote:
>> Why does the man page for the window manager say "The basic tiling
>> concept is that the layout is represented by a binary tree."
>
> The layout is represented by a binary tree of frames, i.e. only the
> frames form the binary tree. Or more specifically: a binary tree of
> frames with lists of windows (and other properties stored) in the
> leaves.
>
> Furthermore, the layout is rigid in the sense that it is only modified
> by user-interaction and not by appearing or disappearing windows.
>
> Btw: e.g. i3 is different here: their layout of containers (their word
> for frames) is not binary but n-ary, i.e. you can have a frame with
> three subframes in it.
>
> Hope, that helps. :-)
>
> Cheers,
> Thorsten
>
> P.S.: the current (and long-term) address of the mailing list is
>
>     hlwm at lists.herbstluftwm.org
>
>> If I start three xterms in an empty frame, they get stacked
>> vertically. If it then do a layout command, I get
>>
>> dca at franz:~$ herbstclient layout
>> ??? vertical: 0x800022 0xc00022 0x1e00022 [FOCUS]
>>
>> The vertical frame has three children, not possible in a binary tree.
>> Using n-ary trees makes sense, and that appears to be what you are
>> doing. But the man page says otherwise. Please explain.


From donaldcallen at gmail.com  Mon Apr 13 15:18:25 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Mon, 13 Apr 2015 09:18:25 -0400
Subject: A suggestion
Message-ID: <CAPsTYbzeb47SVjuu5+3A-kzBcHtnONNaD0gBESk7jnxQPKpfCQ@mail.gmail.com>

In the man page, the set_layout command is described as

set_layout LAYOUT

Sets the layout algorithm in the current frame to LAYOUT. For the list
of layouts, check the list of layout algorithms above.

I think this could be improved. Instead of "check the list of layout
algorithms above.", it could be explicit, saying "see the TILING
ALGORITHM section above".

Also, the Tiling Algorithm section lists the four layouts in the form
n: <layout name>. Is the LAYOUT argument to set_layout specified as
the integer or the name? The description of set_layout doesn't say. I
found out by experimentation that it's the name, after first
specifying the integer and finding that it did not work,  but the type
of the argument should be given explicitly. This is done in the
description of the default_frame_layout setting for example,
indicating that it is an integer. I would also comment that it's
inconsistent to specify the default layout by integer, but set the
layout by name.


From donaldcallen at gmail.com  Mon Apr 13 21:37:25 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Mon, 13 Apr 2015 15:37:25 -0400
Subject: Minor bug
Message-ID: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>

Simplest case: a tag, one frame and an xterm in it. I am running panel.sh,
to display tags, window title, date and time. For xterm, the window title
is the shell prompt string and current directory. If you simply exit from
the shell, say with ctrl-d, the window title remains in the panel. Switch
to another tag and then back to the original tag, and the title gets
updated correctly. I note that panel.sh does look for the
window_title_changed event, so I'm guessing that the window manager itself
is failing to generate the event in this case, but I haven't researched
this carefully so it's just a guess.

Note that if you have two xterms in the frame with different current
directories and thus different window titles, if you exit from one, the
window title in the panel gets updated correctly.

This is not an xterm-specific problem -- I'm just using xterm as a simple
way to reproduce this. If you have just a browser in a frame and close it,
the same problem occurs.

I'm running herbstluftwm 0.6.2-2 on an up-to-date 64-bit Arch Linux system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20150413/957e26cf/attachment.htm>

From matiaslina at opmbx.org  Tue Apr 14 05:53:36 2015
From: matiaslina at opmbx.org (Matias Linares)
Date: Tue, 14 Apr 2015 00:53:36 -0300
Subject: Minor bug
In-Reply-To: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
References: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
Message-ID: <20150414035336.GA6210@archlinux.enhwi-n3>

Yeah, Here's happen the same (Arch Linux and herbstluftwm 0.6.2-2). I've been
looking at the code from the repo but it seems that it's not the same version
that they are working on[1][2] (our wm is written in C instead of C++) so I don't
know if a patch would be helpful.

[1] http://herbstluftwm.org/archive/msg00410.html
[2] https://github.com/herbstluftwm/herbstluftwm

On Mon, Apr 13, 2015 at 03:37:25PM -0400, Donald Allen wrote:
> Simplest case: a tag, one frame and an xterm in it. I am running panel.sh,
> to display tags, window title, date and time. For xterm, the window title
> is the shell prompt string and current directory. If you simply exit from
> the shell, say with ctrl-d, the window title remains in the panel. Switch
> to another tag and then back to the original tag, and the title gets
> updated correctly. I note that panel.sh does look for the
> window_title_changed event, so I'm guessing that the window manager itself
> is failing to generate the event in this case, but I haven't researched
> this carefully so it's just a guess.
> 
> Note that if you have two xterms in the frame with different current
> directories and thus different window titles, if you exit from one, the
> window title in the panel gets updated correctly.
> 
> This is not an xterm-specific problem -- I'm just using xterm as a simple
> way to reproduce this. If you have just a browser in a frame and close it,
> the same problem occurs.
> 
> I'm running herbstluftwm 0.6.2-2 on an up-to-date 64-bit Arch Linux system.


From me at the-compiler.org  Tue Apr 14 06:20:34 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 14 Apr 2015 06:20:34 +0200
Subject: Minor bug
In-Reply-To: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
References: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
Message-ID: <20150414042034.GE1788@tonks>

* Donald Allen <donaldcallen at gmail.com> [2015-04-13 15:37:25 -0400]:
> Simplest case: a tag, one frame and an xterm in it. I am running panel.sh,
> to display tags, window title, date and time. For xterm, the window title
> is the shell prompt string and current directory. If you simply exit from
> the shell, say with ctrl-d, the window title remains in the panel. Switch
> to another tag and then back to the original tag, and the title gets
> updated correctly. I note that panel.sh does look for the
> window_title_changed event, so I'm guessing that the window manager itself
> is failing to generate the event in this case, but I haven't researched
> this carefully so it's just a guess.
> 
> Note that if you have two xterms in the frame with different current
> directories and thus different window titles, if you exit from one, the
> window title in the panel gets updated correctly.
> 
> This is not an xterm-specific problem -- I'm just using xterm as a simple
> way to reproduce this. If you have just a browser in a frame and close it,
> the same problem occurs.
> 
> I'm running herbstluftwm 0.6.2-2 on an up-to-date 64-bit Arch Linux system.

Indeed - the panel is listening for the window_title_changed hook
(which is only emitted when the current window changes its title) and
for the focus_changed hook.

I opened an issue here:
https://github.com/herbstluftwm/herbstluftwm/issues/40

Thanks!

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20150414/f79210ad/attachment.sig>

From me at the-compiler.org  Tue Apr 14 06:28:46 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 14 Apr 2015 06:28:46 +0200
Subject: Minor bug
In-Reply-To: <20150414035336.GA6210@archlinux.enhwi-n3>
References: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
 <20150414035336.GA6210@archlinux.enhwi-n3>
Message-ID: <20150414042846.GF1788@tonks>

* Matias Linares <matiaslina at opmbx.org> [2015-04-14 00:53:36 -0300]:
> Yeah, Here's happen the same (Arch Linux and herbstluftwm 0.6.2-2). I've been
> looking at the code from the repo but it seems that it's not the same version
> that they are working on[1][2] (our wm is written in C instead of C++) so I don't
> know if a patch would be helpful.

herbstluftwm switched[1] from C to C++ some while ago.

Right now it's very C-like C++ (as in, the minimum needed to get it to
work was changed, based on the C source), but there's the winterbreeze
branch[2] which is the "real" C++ OOP rewrite.

A patch for the issue[3] for the current master branch would be much
appreciated! If someone starts working on it just let us know, so we
don't end up doing duplicated work.

Florian

[1] https://github.com/herbstluftwm/herbstluftwm/commit/7ab51d33e9d4dd18aab7c42f53f45fa08b5e3b6b
[2] https://github.com/herbstluftwm/herbstluftwm/tree/winterbreeze
[3] https://github.com/herbstluftwm/herbstluftwm/issues/40

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20150414/2f3bb655/attachment.sig>

From me at the-compiler.org  Tue Apr 14 06:30:37 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Tue, 14 Apr 2015 06:30:37 +0200
Subject: A suggestion
In-Reply-To: <CAPsTYbzeb47SVjuu5+3A-kzBcHtnONNaD0gBESk7jnxQPKpfCQ@mail.gmail.com>
References: <CAPsTYbzeb47SVjuu5+3A-kzBcHtnONNaD0gBESk7jnxQPKpfCQ@mail.gmail.com>
Message-ID: <20150414043037.GG1788@tonks>

* Donald Allen <donaldcallen at gmail.com> [2015-04-13 09:18:25 -0400]:
> In the man page, the set_layout command is described as
> 
> set_layout LAYOUT
> 
> Sets the layout algorithm in the current frame to LAYOUT. For the list
> of layouts, check the list of layout algorithms above.
> 
> I think this could be improved. Instead of "check the list of layout
> algorithms above.", it could be explicit, saying "see the TILING
> ALGORITHM section above".
> 
> Also, the Tiling Algorithm section lists the four layouts in the form
> n: <layout name>. Is the LAYOUT argument to set_layout specified as
> the integer or the name? The description of set_layout doesn't say. I
> found out by experimentation that it's the name, after first
> specifying the integer and finding that it did not work,  but the type
> of the argument should be given explicitly. This is done in the
> description of the default_frame_layout setting for example,
> indicating that it is an integer. I would also comment that it's
> inconsistent to specify the default layout by integer, but set the
> layout by name.

I've added this to [1] as it's very similiar to what's described
there.

[1] https://github.com/herbstluftwm/herbstluftwm/issues/24

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20150414/19f7b2f7/attachment.sig>

From matiaslina at opmbx.org  Tue Apr 14 20:35:39 2015
From: matiaslina at opmbx.org (Matias Linares)
Date: Tue, 14 Apr 2015 15:35:39 -0300
Subject: Minor bug
In-Reply-To: <20150414042846.GF1788@tonks>
References: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
 <20150414035336.GA6210@archlinux.enhwi-n3>
 <20150414042846.GF1788@tonks>
Message-ID: <20150414183539.GA16494@archlinux.enhwi-n3>

On Tue, Apr 14, 2015 at 06:28:46AM +0200, Florian Bruhin wrote:
> herbstluftwm switched[1] from C to C++ some while ago.
>
> Right now it's very C-like C++ (as in, the minimum needed to get it to
> work was changed, based on the C source), but there's the winterbreeze
> branch[2] which is the "real" C++ OOP rewrite.

Yes, but the arch repos are getting the C version[1] not the C-like version. Maybe
the PKGBUILD of the community repo it's outdated.

> A patch for the issue[3] for the current master branch would be much
> appreciated! If someone starts working on it just let us know, so we
> don't end up doing duplicated work.

I'll try to make the patch, but it will take me a some time (Never read the
herbstluftwm code before). If I have any news I'll let you know :).

Matias Linares,

[1]
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/herbstluftwm


From matiaslina at opmbx.org  Tue Apr 14 21:42:33 2015
From: matiaslina at opmbx.org (Matias Linares)
Date: Tue, 14 Apr 2015 16:42:33 -0300
Subject: Minor bug
In-Reply-To: <20150414042846.GF1788@tonks>
References: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
 <20150414035336.GA6210@archlinux.enhwi-n3>
 <20150414042846.GF1788@tonks>
Message-ID: <20150414194233.GA8691@archlinux.enhwi-n3>

Well, I spoke to soon. I just send the patch to github :)

Greetings,

Matias Linares.


From me at the-compiler.org  Sat Apr 18 20:44:00 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sat, 18 Apr 2015 20:44:00 +0200
Subject: Attachment filtering test post
Message-ID: <20150418184400.GG429@tonks>

Hi,

due to the viruses sent to the ML recently (sorry!) I told mailman to
filter .zip attachments. However the docs aren't really clear on
whether the whole message is discarded or only the attachment. Let's
try.

Nothing to see here, move along ;)

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not_empty.zip
Type: application/zip
Size: 169 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20150418/c4230f76/attachment.zip>

From me at the-compiler.org  Sat Apr 18 20:46:17 2015
From: me at the-compiler.org (Florian Bruhin)
Date: Sat, 18 Apr 2015 20:46:17 +0200
Subject: Fwd: Attachment filtering test post
Message-ID: <20150418184617.GH429@tonks>

Whoops, now I turned off filtering completely... Another one.

Sorry for the noise!

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/


From donaldcallen at gmail.com  Sun Apr 19 19:34:47 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Sun, 19 Apr 2015 13:34:47 -0400
Subject: Minor bug
In-Reply-To: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
References: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
Message-ID: <CAPsTYbykfE=2PHrz5711b8vFwutGNVtRfwmjQnNZ52jCr_qOMg@mail.gmail.com>

There is a similar, though perhaps unrelated, bug:

Go to an empty tag. Start an xterm. Then do a 'split bottom'. Now
you've got the xterm above the new empty frame. The title of xterm
window is in the panel. Move the cursor to the empty panel (I have an
' hc set focus_follows_mouse 1' in my autostart). The title in the
panel does not change, nor does the focus -- it remains in the xterm.
But if you do a 'focus down' command, the focus does move to the empty
frame (because of my configuration, the background changes in the
frame; also the cursor in the xterm changes to an outline of a
rectangle and the window title in the panel goes blank; this is the
behavior I would expect from moving the mouse to the empty frame).
Clicking in the empty frame, by the way, does not help matters.

Again, I'm running herbstluftwm 0.6.2-2 on an up-to-date 64-bit Arch
Linux system.


From jordan at lanrules.de  Mon Apr 20 13:01:13 2015
From: jordan at lanrules.de (Johannes Jordan)
Date: Mon, 20 Apr 2015 13:01:13 +0200
Subject: Minor bug
In-Reply-To: <CAPsTYbykfE=2PHrz5711b8vFwutGNVtRfwmjQnNZ52jCr_qOMg@mail.gmail.com>
References: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
 <CAPsTYbykfE=2PHrz5711b8vFwutGNVtRfwmjQnNZ52jCr_qOMg@mail.gmail.com>
Message-ID: <5534DC79.6040700@lanrules.de>

I think this is an example that shows that manually fulfilling hooks is
a cumbersome design.

The object tree already works correctly in this example (clients.focus
disappears). A workaround for the panel could be to poll
clients.focus.title.

In winterbreeze this issue is gone as hooks are based on the object
tree. To fix the current master, one might want to skim through all
places where changes to clients.focus appear.

On 04/19/2015 07:34 PM, Donald Allen wrote:
> There is a similar, though perhaps unrelated, bug:
> 
> Go to an empty tag. Start an xterm. Then do a 'split bottom'. Now
> you've got the xterm above the new empty frame. The title of xterm
> window is in the panel. Move the cursor to the empty panel (I have an
> ' hc set focus_follows_mouse 1' in my autostart). The title in the
> panel does not change, nor does the focus -- it remains in the xterm.
> But if you do a 'focus down' command, the focus does move to the empty
> frame (because of my configuration, the background changes in the
> frame; also the cursor in the xterm changes to an outline of a
> rectangle and the window title in the panel goes blank; this is the
> behavior I would expect from moving the mouse to the empty frame).
> Clicking in the empty frame, by the way, does not help matters.
> 
> Again, I'm running herbstluftwm 0.6.2-2 on an up-to-date 64-bit Arch
> Linux system.
> 


From donaldcallen at gmail.com  Mon Apr 20 14:07:47 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Mon, 20 Apr 2015 08:07:47 -0400
Subject: Minor bug
In-Reply-To: <CAPsTYbykfE=2PHrz5711b8vFwutGNVtRfwmjQnNZ52jCr_qOMg@mail.gmail.com>
References: <CAPsTYbxL3Rg5G7gZHMiEqztpECMvrUO5MuAueM7Xb3wCanQSkg@mail.gmail.com>
 <CAPsTYbykfE=2PHrz5711b8vFwutGNVtRfwmjQnNZ52jCr_qOMg@mail.gmail.com>
Message-ID: <CAPsTYbxX8EFBMgNAc9C32J-7Uxt-HZUkVptpT7eUqw7ZDhkSOA@mail.gmail.com>

(I'm cobbling a reply here, as I had not yet subscribed to this
mailing list and therefore didn't receive a copy of the message below.
I am now subscribed.)

Johannes Jordan wrote:

I think this is an example that shows that manually fulfilling hooks is

a cumbersome design.

The object tree already works correctly in this example (clients.focus
disappears). A workaround for the panel could be to poll
clients.focus.title.

In winterbreeze this issue is gone as hooks are based on the object
tree. To fix the current master, one might want to skim through all
places where changes to clients.focus appear.

My response:

I don't think it's necessary to fix the current master, given the
existence of a branch on which this problem has already been
addressed, apparently by some re-design. I'd much rather see the
developers devote their time to the code on that branch. I can wait
for its release, especially since there's a simple workaround for this
small issue.

/Don

On Sun, Apr 19, 2015 at 1:34 PM, Donald Allen <donaldcallen at gmail.com> wrote:
> There is a similar, though perhaps unrelated, bug:
>
> Go to an empty tag. Start an xterm. Then do a 'split bottom'. Now
> you've got the xterm above the new empty frame. The title of xterm
> window is in the panel. Move the cursor to the empty panel (I have an
> ' hc set focus_follows_mouse 1' in my autostart). The title in the
> panel does not change, nor does the focus -- it remains in the xterm.
> But if you do a 'focus down' command, the focus does move to the empty
> frame (because of my configuration, the background changes in the
> frame; also the cursor in the xterm changes to an outline of a
> rectangle and the window title in the panel goes blank; this is the
> behavior I would expect from moving the mouse to the empty frame).
> Clicking in the empty frame, by the way, does not help matters.
>
> Again, I'm running herbstluftwm 0.6.2-2 on an up-to-date 64-bit Arch
> Linux system.


From donaldcallen at gmail.com  Wed Apr 22 17:10:05 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Wed, 22 Apr 2015 11:10:05 -0400
Subject: Serious bug
Message-ID: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>

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  Thu Apr 23 13:16:14 2015
From: donaldcallen at gmail.com (Donald Allen)
Date: Thu, 23 Apr 2015 07:16:14 -0400
Subject: Serious bug
In-Reply-To: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
References: <CAPsTYbzD+VnBfLo4w6tBxPtRVYEeFEsFvEmd+Evga4D0KG-=wA@mail.gmail.com>
Message-ID: <CAPsTYbwKyq4iM2yZ_xRmB3Bk=fXnb+Rn0bREVrxaPBxVvTOb2g@mail.gmail.com>

It's a new day. I just powered up and booted my system and decided to
try Newcash with your window manager again, with different layouts.
With the same window layout as yesterday, I did the same 'find' that
failed yesterday. Today it works correctly. I tried it with various
layouts and there was no problem. Yesterday, the system had been up
for hours, as had the window manager, when I had the problem I
reported. Beyond that fact, anything I would say, e.g., memory leak,
would be pure speculation.

Given today's result, I will continue to use your window manager and,
of course, will watch carefully to see if yesterday's symptom
reappears.

/Don

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