A solution to prefwindow resizement problems.

Yep, this should work best, and actually is what FX does itself:

style="&prefWindow.styleWin;">

Committed [590].

This needs verification that it does not break mac ;)

*** Ticket #324 marked duplicate of this one ***

Replying to MaierMan:

Yep, this should work best, and actually is what FX does itself: {{{ style="&prefWindow.styleWin;"> }}}

This is no good solution. This is solution proposed by me on BabelZilla?.

Can you test mine solution window size problem? If yes, follow instruction: 1. From original chrome.manifest file remove line 52 2. From chrome\dta.jar\skin\win\ directory remove preferences.css file. If you working on Linux, remove the same file from 'unix' directory. 3. From chrome\dta.jar\content\preferences\ directory remove all files except prefs.js and seamonkey.xul and copy to this directory attached file

Now all panes in the options window should matching to content. Please report me about your remarks. See here:http://www.babelzilla.org/forum/index.php?showtopic=1691&pid=33027&st=120&_entry32856

Replying to Teo:

This is no good solution. ...

This is the best solution.
Furthermore it is the way Firefox does it. http://mxr.mozilla.org/mozilla1.8/source/browser/components/preferences/preferences.xul#78

put-all-into-a-single-xul/sizeToContent() OTOH doesn't work correctly and breaks MacOS.
Oh, and of course you have to put all the stuff into a single xul, what I strongly dislike.

Replying to MaierMan:

This is the best solution.

This is your opinion. IMHO this only simple way. Simple solution add entity and translator will be matching content...

Furthermore it is the way Firefox does it.

It's very old way, but very simply.

put-all-into-a-single-xul/sizeToContent() OTOH doesn't work correctly and breaks MacOS.

Do you checked mine file on Mac?

Oh, and of course you have to put all the stuff into a single xul, what I strongly dislike.

I like. Prefwindow is special window and all code must be written properly, developer have to know all issues this window kind, but all stuff in the single window working together, in the separated window working separately and have to be used constant width and height which is not good for many languages. IMHO developer should write code thus that end user or translator shouldn't anything doing with window size. Window should matching to content automatically.

Replying to Teo:

Replying to MaierMan:

This is the best solution.

This is your opinion. IMHO this only simple way. Simple solution add entity and translator will be matching content...

And since I'm one of the developers my opinion matters a lot ;)

Furthermore it is the way Firefox does it.

It's very old way, but very simply.

You do recognize that this is way was chosen intentionally by Ben when he implemented the prefwindow?
Futhermore:

• https://bugzilla.mozilla.org/show_bug.cgi?id=283697#c128

This effect, btw, can be seen in older dTa versions ;)

put-all-into-a-single-xul/sizeToContent() OTOH doesn't work correctly and breaks MacOS.

Do you checked mine file on Mac?

Did you?
I don't have a mac available actually, but I know that the mac has a fancy animated resize effect (height only) that breaks because of sizeToContent() or hard-coded height.

Oh, and of course you have to put all the stuff into a single xul, what I strongly dislike.

I like. Prefwindow is special window and all code must be written properly, developer have to know all issues this window kind, but all stuff in the single window working together, in the separated window working separately and have to be used constant width and height which is not good for many languages. IMHO developer should write code thus that end user or translator shouldn't anything doing with window size. Window should matching to content automatically.

In and ideal world this might be true. However as it is there is no reliable way to do such auto-resizes, so I settle with the "default" method.

Replying to MaierMan:

Committed [590]. This needs verification that it does not break mac ;)

Will check it in the morning.

Replying to stefano.verna:

Replying to MaierMan:

Committed [590]. This needs verification that it does not break mac ;)

Will check it in the morning.

If it works then please resolve as fixed.