[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#16013: 24.3.50; Rows in height is interpreted as pixels.
From: |
Jan Djärv |
Subject: |
bug#16013: 24.3.50; Rows in height is interpreted as pixels. |
Date: |
Sun, 12 Jan 2014 12:13:42 +0100 |
Hello.
12 jan 2014 kl. 10:54 skrev martin rudalics <rudalics@gmx.at>:
> > Toolkit Initial frame Subsequent frame
> > -------------------------------------------
> > Gtk+ 2/Gtk+ 3 50/80 50/80
> > Gnustep 50/80 49/80
BTW NS on OSX is 50/80 for both cases, so the GNUStep value 49/50 is probably
GNUStep specific, I'll check that.
> > Lucid 50/80 53/80 (Toolbar 3 lines).
> > Motif 50/80 53/80 (Toolbar 3 lines).
> > No toolkit 50/80 53/80 (Toolbar 3 lines, menu bar
> > is 1)
> >
> > Columns are correct in all cases so that is progress.
> > Rows correct only for Gtk.
> > Values for Lucid/Motif is with toolbar, i.e. there are 47 lines
> > excluding toolbar for Lucid/Motif on initial fra,e. Ditto for no toolkit
> > + 1 menu bar line.
> >
> >
> > Looks like toolbar is counted on initial frame, but not on subsequent
> > frames for Lucid/Motif/No toolkit.
>
> I'm still too silly to understand. Should the initial frame have 53
> rows (maybe 54 for the non-toolkit version) or should the subsequent
> frames all have 50 rows?
>
> I frequently asked on this list what `frame-height' and especially the
> "number of lines available for display" stands for, but never got an
> answer I could understand.
This has been inconsistent historically, i.e. Lucid/Motif/No toolkit counts
differently than Gtk/NS.
I think the Gtk count makes more sense. If a user requests 50 lines he
probably means 50 editable lines, not 47. So I think we should not count tool
bar or menu bar.
The documentation says
"The height of the frame contents, in characters."
I don't think menu and tool bar is content.
This may break some lisp code that counts lines and does it differently for the
two cases. I don't know if there are any such code though.
BTW what values does the frame parameter height have now that pixelwise resize
may show partial lines? A floating point value?
Jan D.
- bug#16013: 24.3.50; Rows in height is interpreted as pixels., martin rudalics, 2014/01/11
- bug#16013: 24.3.50; Rows in height is interpreted as pixels., Jan Djärv, 2014/01/11
- bug#16013: 24.3.50; Rows in height is interpreted as pixels., martin rudalics, 2014/01/16
- bug#16013: 24.3.50; Rows in height is interpreted as pixels., martin rudalics, 2014/01/16
- bug#16013: 24.3.50; Rows in height is interpreted as pixels., Jan Djärv, 2014/01/18
- bug#16013: 24.3.50; Rows in height is interpreted as pixels., martin rudalics, 2014/01/18
- bug#16013: 24.3.50; Rows in height is interpreted as pixels., martin rudalics, 2014/01/29