|
| From: | Doug Stewart |
| Subject: | Re: GUI font and cursor location |
| Date: | Sun, 29 Jul 2012 07:11:23 -0400 |
On Sun, Jul 29, 2012 at 1:32 AM, Doug Stewart <address@hidden> wrote:Hi.On Sat, Jul 28, 2012 at 11:29 AM, Michael Goffioul <address@hidden> wrote:
On Sat, Jul 28, 2012 at 2:07 PM, Doug Stewart <address@hidden> wrote:OK here is the GIT patch see attached file.On Sat, Jul 28, 2012 at 6:16 AM, Doug Stewart <address@hidden> wrote:
Michael, HiOn Sat, Jul 28, 2012 at 5:26 AM, Michael Goffioul <address@hidden> wrote:
On Sat, Jul 28, 2012 at 10:05 AM, Jacob Dawid <address@hidden> wrote:Michael,The fact that _fontWidth and fw are different is due to the fact that you're using a non-monospace font (otherwise they would be equal). Non-monospace fonts are not suited for rendering in a terminal.Michael.that's not true. The problems occur with monospaced fonts. There actually was a bug with computing the right cell size, as you mentioned, an Jen fixed it.Obviously, my above statement implicitly assumed you're doing the computation right (in which case I believe _fontWidth == fw for a monospace font). But this doesn't change my impression that _fontWidth and _fontHeight must be integers.Michael.We have a simple fix and will send it soon. We only were testing and working in Ubuntu so I am not sure what is happening (or will happen) in windows
The problem is very demonstrate-able by running the qterminal by itself and using different default font sizes. Then fill one line of the qteminal display screen with characters, and watch the cursor location and character locations as you use the left and right arrow keys to move back and forth on the line.I'm not going to argue forever about this, but I don't think turning _fontWidth/_fontHeight to double and changing computation to push rounding at the very end is the right approach. There's a reason those 2 fields are integer, and it's to build a regular grid of characters. My feeling is that the cursor alignment problem is due to something else. Note also that qterminal is based on Konsole code, and if you check current Konsole code, they're still using integer values [1][2]. Do you experience the same problem in Konsole?Michael.The changes that we made are quite simple to take back out. So if you can fix it the "right way" then definitely take our changes back out.If this fix doesn't work for some situation, then I would like to see the situation, but there will be no hesitation to take it out if it is not working.DougYou didn't answer my question. Do you see similar problems when using the same font in Konsole as you do on octave GUI?Michael.
| [Prev in Thread] | Current Thread | [Next in Thread] |