Closed Bug 189353 Opened 22 years ago Closed 19 years ago

BeOS Menu Font does not use OS-wide menu font size preference


(Core Graveyard :: GFX: BeOS, defect)

Not set


(Not tracked)



(Reporter: simontaylor2, Assigned: beos)




(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.3a) Gecko/20021204
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.3a) Gecko/20021204

The font used for the mozilla menu bar and context menus is the same as the font
specified in Be->preferences->menu. However, the font size is not obeyed.

Reproducible: Always

Steps to Reproduce:
1. Load Mozilla
2. Go to Be->Preferences->Menu and change the font size
3. Close and restart mozilla

Actual Results:  
Menu font size did not change

Expected Results:  
Menu font size changes to reflect setting in Menu prefs. Test this expected
behaviour with a Be-native app.

Hopefully pretty easy to fix this one, but I still haven't got a
moz-building-capable computer so I can't try to create a patch myself. Still,
browsing the source online has found what I hope will fix it.

I think the problem is in nsDeviceContextBeOS. mMenuFont is set to have the font
family and style of the user-preference menu font, but the size is never specified. 

From nsDeviceContextBeOS.cpp:
155   menu_info info;
156   get_menu_info(&info);
157   mMenuFont.SetFamilyAndStyle(info.f_family,info.f_style);

the probable fix is to add this one line:

Could someone (paul?) try this out and get it submitted if it works?
Unfortunately i can't test this problem. My chrome is broken for long time,
perhaps something with setting (this RDF thing reminds me sometimes Windows
registry nightmare),
so i don't see menus using menu font at all, and i cannot change themes. 
Btw, half-offtopic - you can ask on BeShare Kancept and/or Zaranthos if they can
provide you with additional harddisk in order to do work on BeZilla. Especially
if you live in US or Canada.
Simon, adding font size in such way in nsDeviceContext*.cpp doesn't help. Size
setting is performing in nsFontMetricsBeOS.cpp in Init() method. Taken from
nsFont properties. And i think maybe better idea is allow Mozilla to handle menu
and other widgets font size itself, as it is set in css/xul. At least it needs
further investigation
OK then.

I did a test, closing mozilla and changing the BeOS menu font. When I reopened
the browser, the menu FONT (typeface) was still the same, however the SIZE was
different. Non-expected behaviour?

All skins seem to use the same menu font, so why can't we load the BeOS-wide
font. Obviously this was done at some point, from the code I copied about

Ps: Got my new hardware now, but the HDD is missing a pin on the interface - it
works, but no DMA. I'll have to send it back and wait another 2 weeks for a
Attached patch Enable OS-wide font setting (obsolete) — Splinter Review
I'm ready to put review here, only problem is what is general rule for Mozilla -
should it use system-wide preferences or not for menu font sizes, or it depends
on theme?
Maybe timeless knows answer?

Ryo, i will send you today duplicates of my mails to koki, as my sources for
gfx/beos, because it seems you still didn't get it.
adding Paul
All the themes I've tried have the same menu font, and changing the menu font 
in the system prefs does alter how mozilla's menu is displayed (size seems to 
vary). So there is a bug - if the font is set in CSS then it's reading it 
wrongly (or getting the size from somewhere system-wide), if the font is meant 
to be the system one, it's not loading it properly.

I don't know about how the other platforms get the menu font, but I think it 
must be the system-wide one. Moz's window looks very strange next to other ones 
with a native BMenu. Also, as there is no way for the user to change the menu 
font inside moz, it becomes an accessibility issue as well.

My vote is to get the system menu font.

ps: Replacement HD FINALLY arrived, so I've got BeOS running on a 20gig 
partition now. I may try d/l a tar and doing a build of moz at some point. (56k 
so that may take some time)
at moment adding other style elements there, something like:
    theFont->GetFamilyAndStyle(&family, &style);   
 //   aFont->name.AssignWithConversion( family ); helping CJK people here, if
they have fonts with Japanese names as system-wide
    aFont->size =
    if((theFont->Face() & B_BOLD_FACE))
    	aFont->weight = NS_FONT_WEIGHT_NORMAL + 1;
    	aFont->weight == NS_FONT_WEIGHT_NORMAL;
    if((theFont->Face() & B_ITALIC_FACE))
    	aFont->style |= NS_FONT_STYLE_ITALIC;
    if((theFont->Face() & B_STRIKEOUT_FACE))
    	aFont->decorations |= NS_FONT_DECORATION_LINE_THROUGH;
    if((theFont->Face() & B_UNDERSCORE_FACE))
    	aFont->decorations |= NS_FONT_DECORATION_UNDERLINE;
Depends on: 218134
Assignee: asa → beos
Component: Browser-General → GFX: BeOS
QA Contact: asa → timeless
btw, experience was bad when i applied patch for menu font size given by Mozilla
in experimental builds - got lot of blame. Some people complained that it is too
big, some - too small. (it was about year ago or more)
Inspite i was totally satisfied with results myself 
I hope it will be fixed soon.
Ever confirmed: true
What's the status on this one?
I'm working at big font metrics patch which will include this one
Comment on attachment 121542 [details] [diff] [review]
Enable OS-wide font setting 

New patch will follow with taking in account more system settings.
I decided that nsDeviceContext can be patched separately without affecting big
metrics patch
Attachment #121542 - Attachment description: Enable OS-wide menu font size → Enable OS-wide font setting
Attachment #121542 - Attachment is obsolete: true
Attached patch patchSplinter Review
Adding more font parameters to transfer to nsFontMetricsBeOS::Init().
It may require some minor changes in future also in nsFontMetrics, but
shouldn't broke it current work.

Also fixing issue for non-set mWidget.

Adding estimation of DPI.

Allowing future use of non-roman font names (corresponding change will made
also in nsFontMetrics, there is already bug for that)
Attachment #174882 - Flags: review?(thesuckiestemail)
Comment on attachment 174882 [details] [diff] [review]

I'm not very good at font-handling, maybe should have different reviewer.
Anyway there is some mixing of tabs and spaces, but otherwise it looks ok.
Attachment #174882 - Flags: review?(thesuckiestemail) → review+
Checked in with stile fixes (tabs and spaces) and unification:
2005-02-20 13:05
"Bug 189353: BeOS Menu Font does not use OS-wide menu font size preference.
BeOS-only, no sr required."
Marking fixed
Closed: 20 years ago
Resolution: --- → FIXED
I think this page may render differently with this patch.
Attached image Also a button problem
This is not because I have monospaced font to 12, but may be because of
HaikuFox-theme. I will check that. Never seen it before.
The button problem is not because of the theme.
Resolution: FIXED → ---

set fonts and sizes for Unicode. livejournal uses UTF-8
The patch seems to have a bug - the value set in preferences is never used. The
calulation to guess a dpi should store the result in OSVal. The preferences
value should be the preferred one.

Correcting this allows the one-pixel scrolling errors to be fixed. The problem
appears when 1440/dpi is an even number - set dpi in preferences to 70 or 74 if
you like the BeOS default of 72 - 96 also works fine (windows default dpi).

The easiest way to set dpi is to filter for screen_res in about:config
yeah, calcuclation should be made fro OS-value, not PrefValue.
Attached patch patchSplinter Review
fixing confusing between osvalue and prefvalue
Attachment #175715 - Flags: review?(simontaylor2)
Comment on attachment 175715 [details] [diff] [review]


I'm not sure how accurate the estimate is, but it seems to be the best we can
do on BeOS.
Attachment #175715 - Flags: review?(simontaylor2) → review+
new revision: 1.31; previous revision: 1.30
Hope now we can close bug
I've tested this here and have not had any problems.  Is there anything I can do
to help get this committed to CVS?
It's already in CVS as far as I can see. Closing bug.
Closed: 20 years ago19 years ago
Resolution: --- → FIXED
Looks like some recent (probably rounding problem) fix didn't pass in branch.
Here menu font size is smaller in SM than in other OS menus. Will look for other bugs and checkins
looks like we still need to apply this to the branch.
(In reply to comment #29)
> looks like we still need to apply this to the branch.
Or not.  Bug 335076 fixes DPI to 85.  This is also set in current branch code.  Not sure what would cause the SeaMonkey issue sergei describes in comment 28.

Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.