Lisp HUG Maillist Archive

Text input pane pixel waste and simple layout borders?

Hello,

I try to fit as many as possible text input panes on single layout.
The default text input pane seems to waste around 7 pixels below the
text (see left-most example). Does anybody have an idea why? To allow
underlining?

Is there a way or trick to prevent this? I tried to wrap the text
input pane in simple-layout, and constrain it to show only 17 pixels.
It seems to do the trick, but now I have a new problem.

Simple-layout also seems to put several pixels border around itself
(black borders on right-most example). So simple-layout seems to
ignore :internal-border, Is there a way to prevent this?

Thanks for any clues.

Best regards,

Mikko Ahonen

(defvar *default-input-font*
     (gp:make-font-description
                              :family "arial"
                              :size 11))

(defmacro in1 ()
  `(make-instance 'capi:text-input-pane
                  :font *default-input-font*
                  :internal-border 0
                  :visible-border nil
                  :background :white
                  :visible-border nil))

(defmacro in2 ()
  `(make-instance 'capi:simple-layout
                  :description (list (make-instance 'capi:text-input-pane
                                                      :font *default-input-font*
                                                      :background :white
                                                      :internal-border 0
                                                      :visible-border nil))
                    :internal-border 0
                    :visible-border nil
                    :background :black
                    :external-min-height 17
                    :external-max-height t
                    :internal-border nil
                    :y-adjust '(:top)))

(capi:contain (make-instance 'capi:row-layout
                             :background :gray
                             :gap 0
                             :description (list (in1)
                                                (in2))))


Re: Text input pane pixel waste and simple layout borders?

On Sunday 22 March 2009 6:01:32 am Mikko Ahonen wrote:

>

> Hello,

>

> I try to fit as many as possible text input panes on single layout.

> The default text input pane seems to waste around 7 pixels below the

> text (see left-most example). Does anybody have an idea why? To allow

> underlining?

I tried your code.

On LWW (using vista), I don't see any wasted pixels on the left, and maybe a line of pixels only on the bottom of the right.

On LWL, I see lots of wastage. The right side is completely wrong - the lower half of the text input pane is wiped out.

I don't know the answer to your question, but

1) Simple-pane is special - the docs say that it is a native window. Somewhere in the docs, there is a caveat about using simple-pane on a pinboard stating that simple-panes will always be on top because they are special.

2) maybe ../examples/capi/elements/grid-impl.lisp gives you another possibility

3) Have you tried the various text doo-dads available on pinboard-layouts (item-pinboard-object, titles, etc)? Maybe you can pack them tighter onto a pinboard manually?

4) You can pack text as closely together as you want (even overlapping) by dropping down into GP and using gp:draw-string. If you really want a text input pane, then you would have to manually implement a keyboard reader (I've done this in the past - it is possible with an output-pane plus an input-model, but becomes painful / boring if you try to implement *every* input gesture known to windows).

5) Knowing that you can draw string anywhere using GP, you might consider building your own drawn-pinboard-object which simply draws the string using gp:draw-string.

pt

Re: Text input pane pixel waste and simple layout borders?

Thanks for your quick reply.

I forgot to mention my platform, I am running LW 5.1.1 on OS X. But I
need a solution that works also on Windows, so your comment was really
helpful. It means that this behavior concerning borders is probably
OS-specific.

I try to avoid implementing my own controls, it takes so much work.

But if nothing else helps, I probably have to go for your idea...
actually another idea based on your idea could be to combine
drawn-pinboard-object, text-input-pane, and gp:draw-string, so when
the object is clicked, it draws text-input-pane, and then removes it
when edit is done. item-pinboard-object does not seem to allow
changing the font.

Best regards,

Mikko Ahonen

On Sun, Mar 22, 2009 at 5:53 PM, Paul Tarvydas
<tarvydas@visualframeworksinc.com> wrote:
> On Sunday 22 March 2009 6:01:32 am Mikko Ahonen wrote:
>
>>
>
>> Hello,
>
>>
>
>> I try to fit as many as possible text input panes on single layout.
>
>> The default text input pane seems to waste around 7 pixels below the
>
>> text (see left-most example). Does anybody have an idea why? To allow
>
>> underlining?
>
> I tried your code.
>
> On LWW (using vista), I don't see any wasted pixels on the left, and maybe a
> line of pixels only on the bottom of the right.
>
> On LWL, I see lots of wastage. The right side is completely wrong - the
> lower half of the text input pane is wiped out.
>
> I don't know the answer to your question, but
>
> 1) Simple-pane is special - the docs say that it is a native window.
> Somewhere in the docs, there is a caveat about using simple-pane on a
> pinboard stating that simple-panes will always be on top because they are
> special.
>
> 2) maybe ../examples/capi/elements/grid-impl.lisp gives you another
> possibility
>
> 3) Have you tried the various text doo-dads available on pinboard-layouts
> (item-pinboard-object, titles, etc)? Maybe you can pack them tighter onto a
> pinboard manually?
>
> 4) You can pack text as closely together as you want (even overlapping) by
> dropping dinto GP and using gp:draw-string. If you really want a text
> input pane, then you would have to manually implement a keyboard reader
> (I've done this in the past - it is possible with an output-pane plus an
> input-model, but becomesown  painful / boring if you try to implement *every*
> input gesture known to windows).
>
> 5) Knowing that you can draw string anywhere using GP, you might consider
> building your own drawn-pinboard-object which simply draws the string using
> gp:draw-string.
>
> pt


Updated at: 2020-12-10 08:41 UTC