From mboxrd@z Thu Jan  1 00:00:00 1970
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <271F21C8-C3F6-4283-B442-CFF27F93B16D@telus.net>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
From: Paul Lalonde <plalonde@telus.net>
Date: Fri, 12 Jan 2007 11:38:22 -0800
Subject: [9fans] Resizing acme tags in plan9
Topicbox-Message-UUID: 02575dbe-ead2-11e9-9d60-3106f5b1d025

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The P9P version of acme has had multi-line tags for a while now, but
there is still a "bug" lurking in the implementation; it's a bit of a
semantic issue with allocating lines of pixels to the various
windows, which I'll get to below.  The bug manifests as occasional
black lines between windows in a column, and minor confusion when a
bunch of collapsed (tag-only) windows cluster at the bottom of a
column.  I'll explain the confusion in a bit.  The bug only manifests
if you mix fonts within a column.

When I implemented the resizing tags, I chose to never let a change
in the tag size change the layout of a column; doing otherwise causes
seriously non-intuitive and annoying behaviour as windows below your
current window move around.  Instead, tags are limited to using up
the current window's space.  Sounds simple enough.  But when the tag
and the body don't use the same height of font, you wind up with some
wasted lines of pixels at the bottom of the body: space left over
from expanding the tag where a line of the different-sized font no
longer fits.  And you *really* don't want to re-flow the rest of the
column to fit, as tag changes then move around other windows.

Now, as background, note that acme does a good job of allocating rows
of pixels to windows; there's only ever a surplus at the bottom of a
column in Rob's version, but my hack changes that.  And a lot of the
layout algorithm relies on that close packing, and being able to
calculate how many lines a set of windows takes up (body lines * body
font height + tag height + borders), which is no longer accurate
after I've gone and mashed the tags.  Grumble.  And that count
getting out of sync with reality (by having lots of these "void"
sections in a column) causes the bottom-of-column loss of windows.

And that makes it sound like I could just fix this code.  But the
layout code is subtle and quick to anger - it does a greedy pass
through the windows and makes a lot of assumptions interchanging line
counts with window heights - Acme's layout is definitely line-
oriented, not panel-oriented.  And that is commingled with the column
layout heuristics, which are tuned in that code and I don't believe
described anywhere else.

But I want my multi-line tags in Acme on Plan9, especially now that
it's running so sweetly on my MacBookPro.

So I'm willing over the next few months to re-build the column layout
code to handle the tags properly, but I don't know what people expect
in column layout.  I'm willing to take reports both of behaviours
people expect, like, and would like to see, as I try to make
something with expanding tags that's good enough to replace the
current Acme in the Plan9 distro.

Thoughts from anyone?  Words of wisdom?

Thanks,
     Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFp+OupJeHo/Fbu1wRAtC6AJ0c7Qr1cJps964E4CE5dtio0oZXnwCgr87R
EamQ3kuYjnxgcKcYYlKP4OM=
=L/oM
-----END PGP SIGNATURE-----