bugGNUstep - Bugs: bug #22655, Clicking on non-editable text...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #22655: Clicking on non-editable text field changes text to bold

Submitted by:  Nicola Pero <nico>
Submitted on:  Tue 18 Mar 2008 06:09:49 PM UTC  
 
Category: Gui/AppKitSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: Nicola Pero <nico>
Open/Closed: Closed

Thu 20 Mar 2008 11:45:49 AM UTC, comment #2:

Well, in my case it's not begin moved vertically - I took
screenshots and compared them pixel-by-pixel. In the "bold"
version exactly the same pixels are being drawn, but just
"darker". ;-)

I would say that the problem is that there are two
pieces of code drawing the same anti-alias string over itself.

Both NSCell -drawInteriorWithFrame: and the field editor
are drawing the string; and the semi-transparent pixels
become darker if you write them twice.

That's really impressive because it means that all the
transparency stuff is working well. :-)

Anyway, I committed a fix to subversion which fixes this problem
by having the cell not draw when there is a already a field
editor being used to draw. That works nicely for me.

Thanks

Nicola Pero <nico>
Project MemberIn charge of this item.
Wed 19 Mar 2008 10:25:59 PM UTC, comment #1:

A careful analysis shows that it is not just bold, using xlib with a not-AA font reveals that selecting text draws it shifted by a small amount vertically, creating the illusion of thicker text. Fred knows about that, we discovered it at Alpenstep!!

Riccardo Mottola <rmottola>
Project Member
Tue 18 Mar 2008 06:09:49 PM UTC, original submission:

If I click on a non-editable textfield the font changes to
bold (it should do nothing).

I looked at it carefully and what is actually happening is that
the text is rewritten without anti-alias, so pixels which were
a shade of grey are displayed completely black. The visual
effect is then that of the font going from normal to bold, but
it would be more correct to say that it's going from
anti-alias to non-anti-alias (or is it the transparency
which gets lost ?).

I suppose it means that the field editor is not writing using
the same font or method as the original cell was.

This happens with both the xlib and art backends.

Thanks

Nicola Pero <nico>
Project MemberIn charge of this item.

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rmottola (Posted a comment)
  • -unavailable- added by nico (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 20 Mar 2008 11:45:49 AM UTCnicoAssigned toNone=>nico
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1