Closed
Bug 189353
Opened 22 years ago
Closed 19 years ago
BeOS Menu Font does not use OS-wide menu font size preference
Categories
(Core Graveyard :: GFX: BeOS, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: simontaylor2, Assigned: beos)
References
Details
Attachments
(4 files, 1 obsolete file)
2.72 KB,
patch
|
thesuckiestemail
:
review+
|
Details | Diff | Splinter Review |
51.84 KB,
image/png
|
Details | |
7.28 KB,
image/png
|
Details | |
952 bytes,
patch
|
simontaylor2
:
review+
|
Details | Diff | Splinter Review |
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:
mMenuFont.SetSize(info.font_size);
Could someone (paul?) try this out and get it submitted if it works?
Comment 1•22 years ago
|
||
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.
Comment 2•22 years ago
|
||
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
get_menu_font.
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
replacement.
Comment 4•22 years ago
|
||
Comment 5•22 years ago
|
||
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.
Comment 6•22 years ago
|
||
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)
Comment 8•22 years ago
|
||
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->name.Assign(NS_ConvertUTF8toUCS2(family));
theFont->GetHeight(&height);
aFont->size =
NSIntPixelsToTwips(uint32(height.ascent+height.descent+height.leading),
mPixelsToTwips);
if((theFont->Face() & B_BOLD_FACE))
aFont->weight = NS_FONT_WEIGHT_NORMAL + 1;
else
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;
Updated•21 years ago
|
Assignee: asa → beos
Component: Browser-General → GFX: BeOS
QA Contact: asa → timeless
Comment 9•21 years ago
|
||
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
Comment 10•21 years ago
|
||
Confirming.
I hope it will be fixed soon.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 11•20 years ago
|
||
What's the status on this one?
Comment 12•20 years ago
|
||
I'm working at big font metrics patch which will include this one
Comment 13•20 years ago
|
||
Comment on attachment 121542 [details] [diff] [review]
Enable OS-wide font setting
obsoleting.
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
Comment 14•20 years ago
|
||
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 15•20 years ago
|
||
Comment on attachment 174882 [details] [diff] [review]
patch
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+
Comment 16•20 years ago
|
||
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. r=thesuckiestemail@yahoo.se"
Marking fixed
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 17•20 years ago
|
||
I think this page may render differently with this patch.
Comment 18•20 years ago
|
||
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.
Comment 19•20 years ago
|
||
The button problem is not because of the theme.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 20•20 years ago
|
||
per
https://bugzilla.mozilla.org/show_bug.cgi?id=189353#c18
set fonts and sizes for Unicode. livejournal uses UTF-8
Reporter | ||
Comment 21•20 years ago
|
||
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
Comment 22•20 years ago
|
||
yeah, calcuclation should be made fro OS-value, not PrefValue.
Comment 23•20 years ago
|
||
fixing confusing between osvalue and prefvalue
Attachment #175715 -
Flags: review?(simontaylor2)
Reporter | ||
Comment 24•20 years ago
|
||
Comment on attachment 175715 [details] [diff] [review]
patch
Fine.
I'm not sure how accurate the estimate is, but it seems to be the best we can
do on BeOS.
r=simontaylor2@gawab.com
Attachment #175715 -
Flags: review?(simontaylor2) → review+
Comment 25•20 years ago
|
||
nsDeviceContextBeOS.cpp
new revision: 1.31; previous revision: 1.30
Hope now we can close bug
Comment 26•19 years ago
|
||
I've tested this here and have not had any problems. Is there anything I can do
to help get this committed to CVS?
Comment 27•19 years ago
|
||
It's already in CVS as far as I can see. Closing bug.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
Comment 28•17 years ago
|
||
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
Comment 29•17 years ago
|
||
looks like we still need to apply this to the branch.
Comment 30•17 years ago
|
||
(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.
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•