[9fans] Acme huge bar

[9fans] Acme huge bar

[hugo rivera]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

Hi all,
Sometimes while resizing windows in Acme, I get a very thick bar on
top one of the windows.
Perhaps something is not being assigned the right value somewhere.
There is an image showing the fat bar attached.
Bye,

--
Hugo

[-- Attachment #2: acmebar.jpg --]
[-- Type: image/jpeg, Size: 7185 bytes --]

Re: [9fans] Acme huge bar

[Matthew O'Gorman]

[-- Attachment #1: Type: text/plain, Size: 133 bytes --]

its because you dont want half a line of text shown.  it can only resize and
have the thin bar for full increments of text.

Mog

[-- Attachment #2: Type: text/html, Size: 140 bytes --]

Re: [9fans] Acme huge bar

[hugo rivera]

OK, I get it, but maybe Acme can force you to show full lines of text
instead of increasing the bar width?
It just looks a little odd, but nevermind, isn't that important

2009/2/26, Matthew O'Gorman <mog-lists@rldn.net>:
> its because you dont want half a line of text shown.  it can only resize and
> have the thin bar for full increments of text.
>
> Mog
>


--
Hugo

Re: [9fans] Acme huge bar

[erik quanstrom]

On Thu Feb 26 12:24:36 EST 2009, mog-lists@rldn.net wrote:

> its because you dont want half a line of text shown.  it can only resize and
> have the thin bar for full increments of text.
>
> Mog
>

i think this is still a bug.  the slop should not be part of the tag
it should be part of the frame and wherever it is,  it should be
background color, not black.

- erik

Re: [9fans] Acme huge bar

[sqweek]

2009/2/27 erik quanstrom <quanstro@quanstro.net>:
> On Thu Feb 26 12:24:36 EST 2009, mog-lists@rldn.net wrote:
>
>> its because you dont want half a line of text shown.  it can only resize and
>> have the thin bar for full increments of text.
>>
>> Mog
>>
>
> i think this is still a bug.  the slop should not be part of the tag
> it should be part of the frame and wherever it is,  it should be
> background color, not black.
>
> - erik

 I kind of like black in that it makes it obvious. In p9p the slop is
the background colour, but when the mouse is over it your keypresses
go nowhere instead of to the frame. Of course this probably qualifies
as another bug :)
-sqweek

Re: [9fans] Acme huge bar

[ron minnich]

On Thu, Feb 26, 2009 at 8:58 AM, hugo rivera <uair00@gmail.com> wrote:
> Hi all,
> Sometimes while resizing windows in Acme, I get a very thick bar on
> top one of the windows.


I'm curious, are your tag fonts different than your text fonts? It
almost seems so from the picture.

ron

Re: [9fans] Acme huge bar

[hugo rivera]

yes.
The tag fonts are $PLAN9/font/luc/unicode.7.font and the window fonts
are $PLAN9/font/fixed/unicode.6x13.font, from plan9port.
They look neat, if you ask me.

2009/2/27, ron minnich <rminnich@gmail.com>:
> On Thu, Feb 26, 2009 at 8:58 AM, hugo rivera <uair00@gmail.com> wrote:
>  > Hi all,
>  > Sometimes while resizing windows in Acme, I get a very thick bar on
>  > top one of the windows.
>
>
>
> I'm curious, are your tag fonts different than your text fonts? It
>  almost seems so from the picture.
>
>
>  ron
>
>


--
Hugo

Re: [9fans] Acme huge bar

[Anthony Sorace]

do you do that by executing Font in each window?

IIRC, acme tries to move the tag bar a line at a time, but does so
using the sizes of your tag bar font (-f). you'll see this behavior
occurs because the different heights on the fonts mean you can't
satisfy both of them with whole-row-only moves. acme won't ever
display part of a line of text.

doesn't address whether the gap should be black or not, but that's why
it exists.

Re: [9fans] Acme huge bar

[erik quanstrom]

> IIRC, acme tries to move the tag bar a line at a time, but does so
> using the sizes of your tag bar font (-f). you'll see this behavior
> occurs because the different heights on the fonts mean you can't
> satisfy both of them with whole-row-only moves. acme won't ever
> display part of a line of text.
>
> doesn't address whether the gap should be black or not, but that's why
> it exists.

i don't understand why different fonts would cause this.
why is there need for slop in the tag?  one doesn't need
any relationship between the tag text and the frame text
so all the slop can be eliminated from the tag and added
to the frame.

- erik

Re: [9fans] Acme huge bar

[Paul Lalonde]

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

When I did the expanding tags I wound up choosing to leave them black
since they aren't part of any frame.

Not totally satisfactory, but the layout logic was baroque enough
that disturbing it further didn't  make much sense.

I know that a few others have improved that code since I first
submitted it, and might have more feedback.

Paul

On Feb 27, 2009, at 10:45 AM, Anthony Sorace wrote:

> doesn't address whether the gap should be black or not, but that's why
> it exists.

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

iD8DBQFJqJe2pJeHo/Fbu1wRAiMQAJwKgBpLx231NVIwHMEh/3TKFk/SPgCcDT5S
ycFRw3uRxZOF5y0ZSwVCop4=
=MvLX
-----END PGP SIGNATURE-----

Re: [9fans] Acme huge bar

[hugo rivera]

yes, I execute Font for each window I want to.
OK, got the point, thanks.

2009/2/27 Anthony Sorace <anothy@gmail.com>:
> do you do that by executing Font in each window?
>
> IIRC, acme tries to move the tag bar a line at a time, but does so
> using the sizes of your tag bar font (-f). you'll see this behavior
> occurs because the different heights on the fonts mean you can't
> satisfy both of them with whole-row-only moves. acme won't ever
> display part of a line of text.
>
> doesn't address whether the gap should be black or not, but that's why
> it exists.
>
>



--
Hugo

Re: [9fans] Acme huge bar

[ron minnich]

On Fri, Feb 27, 2009 at 9:26 AM, hugo rivera <uair00@gmail.com> wrote:
> yes.
> The tag fonts are $PLAN9/font/luc/unicode.7.font and the window fonts
> are $PLAN9/font/fixed/unicode.6x13.font, from plan9port.
> They look neat, if you ask me.

If you watch what acme does as you resize the window you can see it
fits the vertical size to a multiple of font size. Same for the tag
line. If you start with one configuration of your fonts, with the tag
being around 16% larger than the window font, the reason for the black
line changing size after a resize should be pretty obvious. This
doesn't strike me as a bug. It's doing what you asked it to do, as
well as satisfying other constraints.

ron

Re: [9fans] Acme huge bar

[Akshat Kumar]

[-- Attachment #1: Type: text/plain, Size: 246 bytes --]

I doubt that is the reason.  The tag-line will just jump the whole
line of text if such a resize takes place.  You would not get a black
line to hide it -- at least, that is the case in acme on native Plan
9.  Where are you using it?


ak

[-- Attachment #2: Type: message/rfc822, Size: 3317 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 133 bytes --]

its because you dont want half a line of text shown.  it can only resize and
have the thin bar for full increments of text.

Mog

[-- Attachment #2.1.2: Type: text/html, Size: 140 bytes --]