Re: HiDPI in Terminal.app

2017-08-02 Thread Riccardo Mottola

Hi Steven,


On 07/20/17 07:39, Fred Kiefer wrote:

Thank you for your patch. I am sure it works but it does not address the 
underlying issue. The real problem is that DPSshow ignores the current 
transformation of the window and sets a mirrored identity matrix as the 
transformation. This works well in some cases but is clearly wrong. We should 
move ll application code away from this out dated interface. And I will have to 
find a way to fix the behaviour, while keeping at least some of the differences 
that DPSshow has to the regular text display code, e.g. not respecting any 
rotations.


I have seen that Fred has commited a fix to the GNUstep backend. Might 
you want to check if it helps your issue?


In the meanwhile I am working with him on a more extended Terminal 
engine update, but that is a little more complex and will take some more 
time. I will make the changes public as soon as I make a release of the 
existing Terminal, just for safety, as discussed on in this thread before.


Riccardo

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep


Re: HiDPI in Terminal.app

2017-07-20 Thread Fred Kiefer

> Am 20.07.2017 um 09:37 schrieb Riccardo Mottola :
> 
> Hi Fred,
> 
> 
> Fred Kiefer wrote:
>> Thank you for your patch. I am sure it works but it does not address the 
>> underlying issue. The real problem is that DPSshow ignores the current 
>> transformation of the window and sets a mirrored identity matrix as the 
>> transformation. This works well in some cases but is clearly wrong. We 
>> should move ll application code away from this out dated interface. And I 
>> will have to find a way to fix the behaviour, while keeping at least some of 
>> the differences that DPSshow has to the regular text display code, e.g. not 
>> respecting any rotations.
> 
> do you mean that DPSShow() is broken and you might fix it, but in long run we 
> should rewrite TerminalView (and many other applications) not to youse DP 
> functions?

Ye, exactly.

> Sounds a challenge for us, I'll seek your help.

Actually no, it should be a rather simple change but I am willing to help with 
it.

> Maybe the best would be to make a minor release of Terminal before doing such 
> a major change.

Yes one before the change and another one on the next day after the change :-)
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep


Re: HiDPI in Terminal.app

2017-07-20 Thread Riccardo Mottola

Hi Fred,


Fred Kiefer wrote:

Thank you for your patch. I am sure it works but it does not address the 
underlying issue. The real problem is that DPSshow ignores the current 
transformation of the window and sets a mirrored identity matrix as the 
transformation. This works well in some cases but is clearly wrong. We should 
move ll application code away from this out dated interface. And I will have to 
find a way to fix the behaviour, while keeping at least some of the differences 
that DPSshow has to the regular text display code, e.g. not respecting any 
rotations.


do you mean that DPSShow() is broken and you might fix it, but in long 
run we should rewrite TerminalView (and many other applications) not to 
youse DP functions?


Sounds a challenge for us, I'll seek your help.
Maybe the best would be to make a minor release of Terminal before doing 
such a major change.


Riccardo

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep


Re: HiDPI in Terminal.app

2017-07-19 Thread Fred Kiefer
Thank you for your patch. I am sure it works but it does not address the 
underlying issue. The real problem is that DPSshow ignores the current 
transformation of the window and sets a mirrored identity matrix as the 
transformation. This works well in some cases but is clearly wrong. We should 
move ll application code away from this out dated interface. And I will have to 
find a way to fix the behaviour, while keeping at least some of the differences 
that DPSshow has to the regular text display code, e.g. not respecting any 
rotations.

Fred



> Am 17.07.2017 um 21:25 schrieb Steven R. Baker :
> 
> Heya,
> 
> I've been hacking on Terminal.app a bit, to try and get it working in HiDPI.  
> The problem is that the cell size seems to be set correctly according to the 
> scale, but when the characters are rendered they are *not* scaled.  You wind 
> up with a large character cell, with a character in the bottom left corner of 
> it, and gaps everywhere.
> 
> I think I have it working, but the solution doesn't feel right. You can see 
> it here: 
> https://github.com/srbaker/gap/commit/8fe99150704a10d6b3b6b70947361376dcc3c819
>  If this *is* appropriate, I'll generate a patch and sign the copyright 
> assignment stuff, etc.
> 
> Some explanation, so you can follow along my thinking.  In TerminalView.m, 
> the characterCellSize class method sets the size of a character cell 
> correctly.  I suspect that this because boundingRectForFont knows the scale 
> factor, but the DPSshow() call (around line 728 in my edited file, inside 
> drawRect:) does *not* know what the scale factor is because it doesn't know 
> the scale factor.
> 
> I feel like the correct thing to do here is to handle scaling in DPS, but at 
> this point I'm quite over my head.  Thoughts, please. I'm willing to do the 
> work, but I just feel like I'm barking up the wrong tree here...
> 
> Cheers!
> 
> -Steven
> 
> 
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep


HiDPI in Terminal.app

2017-07-17 Thread Steven R. Baker

Heya,

I've been hacking on Terminal.app a bit, to try and get it working in 
HiDPI.  The problem is that the cell size seems to be set correctly 
according to the scale, but when the characters are rendered they are 
*not* scaled.  You wind up with a large character cell, with a character 
in the bottom left corner of it, and gaps everywhere.


I think I have it working, but the solution doesn't feel right. You can 
see it here: 
https://github.com/srbaker/gap/commit/8fe99150704a10d6b3b6b70947361376dcc3c819 
If this *is* appropriate, I'll generate a patch and sign the copyright 
assignment stuff, etc.


Some explanation, so you can follow along my thinking.  In 
TerminalView.m, the characterCellSize class method sets the size of a 
character cell correctly.  I suspect that this because 
boundingRectForFont knows the scale factor, but the DPSshow() call 
(around line 728 in my edited file, inside drawRect:) does *not* know 
what the scale factor is because it doesn't know the scale factor.


I feel like the correct thing to do here is to handle scaling in DPS, 
but at this point I'm quite over my head.  Thoughts, please. I'm willing 
to do the work, but I just feel like I'm barking up the wrong tree here...


Cheers!

-Steven



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep