gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Font constants


From: Fred Kiefer
Subject: Re: Font constants
Date: Mon, 07 Mar 2005 11:51:04 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040906

Fred Kiefer wrote:
Jesse Ross wrote:


Perhaps someone can easily answer this question for me. Do we have font constants, similar to Mac OS X? As I'm doing a new UI theme, I want to make sure I'm using fonts at the appropriate sizes (I know, I know, Alex, 12pt Bitstream Vera Sans) in the right places. Here is Apple's HIG on the issue:

http://developer.apple.com/documentation/UserExperience/Conceptual/ OSXHIGuidelines/XHIGText/chapter_4_section_2.html

Any info or pointers in the right direction would be much appreciated!


As you can see from the document you pointed to, the constants are for Carbon only, which we don't support of course. In Cocoa, and therefore in GNUstep, the methods from the last column should be used. Here a small error must have been made, as some of these methods clearly don't return fonts but font sizes. We currently don't support the systemFontSizeForControlSize: method, although it should be very easy to add. If nobody beats me on that, I will add the method next week. Up to then, you could use the methods smallSystemFontSize and systemFontSize.


I started to implement this method, but noticed that I will need to include NSCell.h into NSFont.h to see the type NSControlSize. Doing so failed because of some complex recursion in the includes. There surely is some trick to work around this by moving one include down a few lines and a type defintion up (or something like this), but I would like to suggest a different solution. NSControlSize and NSControlTint and their placement in NSCell and NSColor always looked strange to me. What about moving them into some new public header file, perhaps called NSAppearance.h? From there it would be easy to include them into any of the offical header file where they are needed. The problem here is of course that we create a new file and have to take care that it wont be used for any other cases. Perhaps we better but a "private" into the file name? I would prefer some quick answers here, so that I am able to go ahead today. Untill I get them I'll try the statement shifting to see if there is a simple solution in there.

Fred




reply via email to

[Prev in Thread] Current Thread [Next in Thread]