TwoPointOne-TwoThings...

[vladmir]

I wonder where they are storing all this data for each website visited -- seems to be a goldmine for identity theft.

Profile -> content-prefs.sqlite

http://kb.mozillazine.org/Profile_folder_-_Firefox
"content-prefs.sqlite - 3.0 and above - Individual settings for pages"

viewtopic.php?f=38&t=684805

[Johnfull]

Thanks, again, Vlad!
It's old information from 2008, and Zoom is now non-functional with SM 2.1.
To remove the profile data for site-specific zoom settings would make it necessary to input them again.
I hope someone creates a way to keep the global zoom without the need to store all that site-specific data.
NoSquint displays at the bottom of the screen as 100% regardless of the actual zoom setting. Is that a clue?...

[rsx11m]

As I see it's impossible to change in WinXP SM 2.1 and 2.2 in about:config
toolkit.zoomManager.zoomValues
It always resets to "user set"
0.5,0.75,0.9,1,1.2,1.5,2

This string is actually set as a localization property and reset every time (it's also used to define the menu entries in View > Zoom). It can be overridden by placing a custom-strings.txt file in the installation chrome folder, thus C:\Program Files\SeaMonkey\chrome with something like the following content (here adding 300% and 400% zoom levels to the list):

Code: Select all

chrome%3A//communicator/locale/viewZoomOverlay.properties#values=50,75,90,100,120,150,200,300,400
chrome%3A//communicator/locale/viewZoomOverlay.properties#accessKeys=5,7,9,z,1,0,2,3,4
chrome%3A//communicator/locale/viewZoomOverlay.properties#valueOther=500

This will still not allow you to go beyond 300% unless you also set zoom.maxPercent high enough (that's the cutoff you can type in for "Other", it won't add further Ctrl+ steps). Restart SeaMonkey to make both changes effective.

Unfortunately, the default/original zoom value seems to be hardwired as 100% in the toolkit zoom manager, no pref to change it, and it won't obey any zoom.minPercent setting, which is only effective for Ctrl+/- changes.

[Johnfull]

This is scarey-technical. It looks like you're saying there is a code change that will allow a global value higher than 100%,
but then it looks like you're saying it's hard-wired in the toolkit programming. Which is it, or did I miss what you were saying?
It seems that 'toolkit' has taken a lot of control away from developers in the name of shortcuts. Am I right on that? It seems
that toolkit programming language was the reason that Thunderbird broke the font preference and it is now beyond repair.
If toolkit language is so much better, shouldn't someone devise a way to make repairs when it's used? It's all beyond my
own ability to understand, but someone should...right?...

[rsx11m]

Toolkit is the Gecko framework to implement various functionalities, thus applications can just use it or develop their own implementations. SeaMonkey has replace quite a few code pieces with Toolkit functions by now, partly because they may work better, mostly because maintaining the old code wasn't feasible due to the lack of resources.

The zoomValues preference is a toolkit setting, but SeaMonkey has it hard-wired to the localized string, that was part of bug 386363 Remember zoom value on a site-specific basis (Port fix for bug 378549 to SeaMonkey). You can override any string (label) that SeaMonkey uses by a custom-strings.txt definition, that's the only trick I've used here to get it work. There is also bug 621823 pending to make this easier configurable, the prime argument for not doing it right away was the need to assign access keys to each of the zoom levels (a rather weak argument as it would be sufficient to define those for the default zoom levels only).

Then I also found bug 539417 Reset Zoom (Ctrl+0) does nothing if zoom.MinPercent > 100, which has apparently the same cause of "zoom=1" being hard-wired in the reset function so that minPercent isn't obeyed. I've commented there for now, let's see if there is any response from the Toolkit people (it was filed as a Core bug and apparently got lost).

[Johnfull]

Thanks.
That's a lot of bugs.
Were they part of FireFox all along and we just didn't find out till SeaMonkey adopted their code?
If so, they may claim that it's too deeply buried in the shortcut toolkit code to ever repair -- like the mail font bug(s).

I appreciate you saying that we adopt the pre-digested code out of necessity rather than by choice.
That gets back to my question about feedback to the developers -- do they know SeaMonkey users are using their code now?

Also, is there a way that NoSquint will ever work again, considering these bug patches?
A new bug report could say that NoSquint is erroneously shown to work whereas it displays 100% and is
unchangeable despite the site-specific change to some other value. I don't know if bug reports are issued
for that sort of thing -- erroneous readings in the add-on manager...

[rsx11m]

Were they part of FireFox all along and we just didn't find out till SeaMonkey adopted their code?

The ZoomManager not handling a reset value correctly if 100% isn't in the MIN-MAX range is a native Toolkit bug which SeaMonkey "inherited" by adopting that code. Apparently nobody envisioned that someone may use the minimum as a means to make the page better visible by default. I've identified a few starting points in that bug which may or may not require respective follow-up fixes on the SeaMonkey side, depending on how the Toolkit issue is solved.

do they know SeaMonkey users are using their code now?

Unless the SeaMonkey people raise their voice that they need something different in that code, the Toolkit people don't necessarily have to know. Certain details can be overridden by the application using it, so the way how ZoomManager is used by Firefox and by SeaMonkey may be different (from what I see in the code, SeaMonkey adopted the code in a fairly identical way, including the hard-wired zoom=1 default). On the other hand, such "on-top-off" changes imply that you'll have to maintain them yourself if the underlying Toolkit code changes, so it's a mixed story.

I can't comment on NoSquint = not using it myself.

[Johnfull]

OK, thanks.
Maybe the author of NoSquint will find a way to get it to work with 2.1.
It's pretty amazing that SeaMonkey still looks so much like SeaMonkey and isn't anything like it used to be, code-wise.
It reminds me of 'Invasion of the Body Snatchers' -- but in a good way...?...

[raj_bhaskar]

I appreciate that it's zoom levels that you're looking to change the default for, but could a workaround be to use the minimum font size in Prefs -> Appearance -> Fonts.

Also, has anyone filed a bug to be able to change the global default font zoom level?

[Johnfull]

I used minimum fonts (18) for years, but found NoSquint superior because the entire page is enlarged proportionately.
This is much better on newer models with wide aspect displays. It's similar to Acrobat Reader allowing 'page width' display.
The work-around for me is to go to View for each and every website that I visit and input 150%. The values are remembered,
which gives me pause as to the bloated nature of such a list, but at least I get the display that I wanted with some effort.
Meanwhile, NoSquint is supposedly working -- the icon in the bottom righthand corner is there, but is always displaying 100%
and is unchangeable. FireFox should try to implement a display option for wide aspect displays, I think. Easier said than done?...

[vladmir]

rsx11m

This string is actually set as a localization property and reset every time (it's also used to define the menu entries in View > Zoom).

OK, thanks as I see - in:
omni.jar\\chrome\en-US\locale\en-US\communicator\viewZoomOverlay.properties
or
omni.jar\chrome\ru\locale\ru\communicator\viewZoomOverlay.properties

It can be overridden by placing a

It's easy to change viewZoomOverlay.properties

Johnfull

Maybe the author of NoSquint will find a way to get it to work with 2.1

No. His answer: "Since I don't use Seamonkey, no. Hopefully someone else from the community will port it, as was the case for previous versions of Seamonkey."

[rsx11m]

There is also bug 621823 pending to make this easier configurable,

I've just posted a patch there to uncouple the Ctrl+/- preference from the localized list of menu items as the simplest solution to allow manipulation of the zoom levels, let's see if Neil likes it this way. Anything else would probably require rather awkward solutions.

It's easy to change viewZoomOverlay.properties

Yes, but hacking the omni.jar will cause partial updates to fail, then its asking for the full update and will overwrite your changes, thus you'd have to do it every time whereas the custom-strings.txt solution persists through updates.

[Johnfull]

Thank goodness I wasn't able to find the omni.jar file myself. I'm desperate enough to start changing things willy-nilly.
Does FireFox operate this same way? If not, is it because the 'black box' of ToolKit code has inputs and outputs and
SeaMonkey is using the wrong ones (ports)? I don't even know that that is, but I've seen it discussed in the bug reports.
Why don't we just port everything the way FireFox does and then our bugs will be the same as their bugs and we can all
bitch at the same developers in unison? Just a thought...

[rsx11m]

Johnfull, don't hack omni.jar unless you know what you are doing. It contains most of the "brains" of SeaMonkey (and other Gecko/XUL applications like Firefox), and even though you can open it with any ZIP tool, it's easy to make the program no longer work if changing something (on purpose or by accident) and writing back a bad copy...

Why don't we just port everything the way FireFox does

Thankfully there are still many differences between SeaMonkey and Firefox or Thunderbird!

[Johnfull]

"...Thankfully there are still many differences between SeaMonkey and Firefox or Thunderbird!"

You've said elsewhere that no one here is a SeaMonkey developer, except Phil Chee, (who is waiting to win the lottery).
You also mention filing bug reports, but most of us are not tech-savvy enough to do that -- I speak for myself, at least.
Why don't the developers of SeaMonkey read the forum? It seems that they would want the feedback.
Do you have any idea of what they want to do next? Is this phase of replacement of code with chunks of ToolKit from
Fx and TrdBrd going to go on until there are not those thankful differences any longer?
A lot of us are hangers-on from the Netscape 4.7 glory days and we miss the ease and ergonomic structure.
Should we all be humming the theme from 'The Way We Were' as we try to find our way around yet another new iteration?
Or maybe Joni Mitchell's 'Chinese Cafe': "...how long, how long?..."