Closed
Bug 178910
Opened 22 years ago
Closed 21 years ago
beos.js in libprefs is currently underused.
Categories
(SeaMonkey :: Preferences, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: sergei_d, Assigned: sergei_d)
Details
(Keywords: qawanted)
Attachments
(1 file, 2 obsolete files)
1.13 KB,
patch
|
dbaron
:
review+
asa
:
approval1.6b+
|
Details | Diff | Splinter Review |
It looks weird, but nobody had any care about setting BeOS-specific defaults via
beos.js (it affects fresh/clean installs)
Assignee | ||
Comment 1•22 years ago
|
||
beos.js patch.
Sets common BeOS fonts for western encoding,
BeOS-specific menu/shortcut key assignments (required by majority of
BeOS-users),
default download-folder.
Assignee | ||
Comment 2•22 years ago
|
||
Though, don't know where beos.js must be initially in source tree.
Assignee | ||
Comment 5•22 years ago
|
||
tooltips off???
That's my personal very subjective preference.
I dislike if something unwanted and unrequested permanently pops on the way with
"deep-wisdom" messages like "This is internet. Type address here and click Go
button on the right to go into internet".
Feel free to drop out all what you wanna.
Removed some of the personal preferences that Sergei had added, and changed
the menuAccessKey to be the "Windows" (meta) key. On BeOS, menu access is
obtained by pressing "Alt-Esc", but, I don't think we can do that in mozilla.
This way, at least the menuAccess and generalAccess keys will not interfere
with eachother.
Attachment #105472 -
Attachment is obsolete: true
Attachment #109955 -
Flags: review?(sergei_d)
Assignee | ||
Comment 7•22 years ago
|
||
i don't think font settings should be removed.
Those are native default BeOS fonts, so it is not my personal choice.
We need some reasonable defaults to avoid confusing by novices,
there is even bug BeOS filed by Kai Lahman on this topic.
I got also other users complaints about this situation.
Maybe only thing which should be changed here about those fonts - set it
according to freshly installed BeOS 5.0 system fonts.
Do the fonts really need to be modified in this file? I just removed my
preference directory, and re-ran mozilla. The initial fonts choosen for me were:
Proportional Serif
Serif Baskerville
Sans-serif Arial
Cursive CommercialScript
Fantasy 32768 NO
Monospace Courier New
These seem like reasonable choices to me. And, the reason they were choosen, is
due to a patch Sergei had created and that was applied earlier, correct?
Assignee | ||
Comment 9•22 years ago
|
||
Paul, look into macprefs.js, os2pref.js, winpref.js, unix.js, photon,js, openvms.js.
All these files contain font-name settings.
Maybe we should look there (using as example) even to add something else to beos.js.
Comment 10•22 years ago
|
||
I don't have an objection to the fonts, I was just asking if they were needed,
since the patch was applied, that you created, for choosing better font
defaults. Plus, even if we choose some for people, based on an r5 system, whose
to say those fonts will be available. They could be deleted, or, when OBOS,
B.E.OS, Zeta, ..., makes a release, will we know if these fonts will exist? I
guess what I'm really saying, is I like what your previous patch to the gfx kit
did, which was to try and make guesses as to the best font, instead of
hard-coding the defaults. Unless, that is, if we still try to pick a "best fit"
font, when one of the ones we choose here does not exist, which I have not tried.
And, just because someone else did it, does not mean we have to :-)
Comment 11•22 years ago
|
||
Sergei, does the download directory setting work for you? It seems to be
getting removed from my prefs.js file when I shut down mozilla.
Assignee | ||
Comment 12•22 years ago
|
||
About fonts.
Our reality is BeOS 5 PE/PRO. As you said yourself, we don't support yet
Dano/BONE/etc officially:) So those PE fonts are our reality.
And about my font guessing patch Zeta still has poor (as original BeOS) toolset
and API for appearance, so if they add some exotic fonts, we will be forced
change code again to add sniffing rules for those new font names. And if OBOS
adds appearance control functionality, we should add code anyway to use its API:)
So i still think we need default font settings in agreement with R5.
And about download folder - it works with patch for bug
http://bugzilla.mozilla.org/show_bug.cgi?id=177720
applied
Assignee | ||
Comment 13•22 years ago
|
||
and again about tooltips
http://bugzilla.mozilla.org/show_bug.cgi?id=185440
Try to perform query in Bugzilla for tooltips, btw, and you will be surprised
with number of complaints
Comment 14•22 years ago
|
||
Ok, I then need to look at my BeOS install CD to see what fonts come with it.I'll update the patch, once that is done.
Comment 15•22 years ago
|
||
As for the tooltip crashes, they were most likely due to the thread safetiness
issues surrounding reference counting within the BeOS port. IIRC, tooltips are
each separate windows, and such, under BeOS, have their own threads. Since
thread counting was not atomic, it caused problems with adding/releasing of
references to the tooltips. If you do have them disabled currently, please, try
turning them back on, and see if there is a problem. I have a feeling, there
will not be.
Assignee | ||
Comment 16•22 years ago
|
||
Tooltips are of eWindowType_popup.
Overall popup-windows handling in BeOS is far from being perfect.
And even worse - we haven't any control over tooltips (and have some for pop-up
menus and drop-down lists) in BeOS widget code.
As far we have crashes with pop-ups, we still are in danger with tooltips.
And users report that we do.
Plus tooltips specifical issues (though, those are in work permanently by
people dealing with "higher level" code, mostly JS) - lost keyboard handling,
lost focus, simultaneous appearing of several tooltips etc etc.
Though, i'm really not persistent on to leave this option in beos.js in main tree.
(I can do it in my StripZilla builds to allow less bugginess and more stabilty
while i'm still thinking about better pop-up code in libwidget and waiting
impovements from JS developers)
Now about fonts.
Maybe original BeOS names differs little bit from names provided in my patch
with missing "BT" in names, or something alike - i use myself full (i18n)
BitStream fonts supplied with some Corel's product. Those are same fonts, but
with Pan-European glyphs.
Assignee | ||
Comment 17•22 years ago
|
||
Comment on attachment 109955 [details] [diff] [review]
removed "personal" preferences, changed menuAccessKey
winkey (224) as default is bad idea. There is still big number of 101-key
keyboard around. For such keyboards BeOS assigns 224 to right-control, so
depending on keymap, one of two things happens:
1) Menus are unaccessible via shortcuts
2)Users cannot type essential symbols, like @ [ ] etc
Attachment #109955 -
Flags: review?(sergei_d) → review-
Comment 18•22 years ago
|
||
Ok, do you have a better solution?
One thing for sure, if you don't reset the generalAccesskey to be something
other than "Alt" when changing the accesskey to "Alt", pages like BugZilla,
which use accesskeys, get in the way of other shortcuts. (Bug#128452)
As for the menuaccess key, I don't use it often. The BeOS way of access a menu
is "Alt-Esc", but, we can't do that currently with mozilla, AFAIK.
Assignee | ||
Comment 19•22 years ago
|
||
This idea
http://bugzilla.mozilla.org/show_bug.cgi?id=128452#c16
is in my initial patch.
pref("ui.key.generalAccessKey", 17);
pref("ui.key.menuAccessKey", 17);
and some people
http://bugzilla.mozilla.org/show_bug.cgi?id=128452#c19
have opinion that it is not so bad idea:
"Sounds like a fine default by me. While there are still potential conflicts
between these two uses, at least the conflicts will be relatively consistent
across platforms, and hence likely to be avoided by page authors."
But as far as this isn't implemented in code, we can do it in platformpref.js
Assignee | ||
Comment 20•21 years ago
|
||
workaround for inverted shortcut/menu key assignments.
workaround for bug 128452
setting OS-native folder for downloads
Assignee | ||
Updated•21 years ago
|
Attachment #109955 -
Attachment is obsolete: true
Assignee | ||
Comment 21•21 years ago
|
||
Comment on attachment 136834 [details] [diff] [review]
Revitalizing old patch
review request
Attachment #136834 -
Flags: review?(dbaron)
Attachment #136834 -
Flags: review?(dbaron) → review+
Assignee | ||
Comment 22•21 years ago
|
||
Comment on attachment 136834 [details] [diff] [review]
Revitalizing old patch
approval requested.
Patch is platform-specific and don't affect mozilla at whole.
(So sr isn't neccessary)
Attachment #136834 -
Flags: approval1.6b?
Comment 23•21 years ago
|
||
Comment on attachment 136834 [details] [diff] [review]
Revitalizing old patch
a=asa (on behalf of drivers) for checkin to 1.6beta
Attachment #136834 -
Flags: approval1.6b? → approval1.6b+
Comment 24•21 years ago
|
||
Checking in beos.js;
/cvsroot/mozilla/modules/libpref/src/beos/beos.js,v <-- beos.js
new revision: 1.15; previous revision: 1.14
done
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 25•21 years ago
|
||
Comment on attachment 136834 [details] [diff] [review]
Revitalizing old patch
You forgot to change this comment :-P
>+ * The menuAccessKey is now the "windows" key
>+ */
>+pref("ui.key.accelKey", 18);
>+pref("ui.key.generalAccessKey", 17);
>+pref("ui.key.menuAccessKey", 17);
Assignee | ||
Comment 26•21 years ago
|
||
Shame on me.
Will correct it with next addition to beos.js:)
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•