Closed Bug 178910 Opened 22 years ago Closed 21 years ago

beos.js in libprefs is currently underused.

Categories

(SeaMonkey :: Preferences, defect)

x86
BeOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sergei_d, Assigned: sergei_d)

Details

(Keywords: qawanted)

Attachments

(1 file, 2 obsolete files)

It looks weird, but nobody had any care about setting BeOS-specific defaults via
beos.js (it affects fresh/clean installs)
Attached patch Patch (obsolete) — Splinter Review
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.
Though, don't know where beos.js must be initially in source tree.
.
Assignee: ben → sergei_d
why are tool tips turned off by default?
Keywords: qawanted
QA Contact: sairuh → nobody
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)
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?
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.
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 :-)
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.
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
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
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.
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.
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.
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-
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. 
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
workaround for inverted shortcut/menu key assignments.
workaround for	bug 128452
setting OS-native folder for downloads
Attachment #109955 - Attachment is obsolete: true
Comment on attachment 136834 [details] [diff] [review]
Revitalizing old patch

review request
Attachment #136834 - Flags: review?(dbaron)
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 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+
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 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);
Shame on me.
Will correct it with next addition to beos.js:)
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: