Suiterunner Update 16
Mark Banner
- (bug 329744) - Profile migrator. See my post from yesterday
(sutierunner update 15a). There is one problem with newsgroup migration
that I'm talking to the Thunderbird devs about as that code was copied
from them.
- (bug 346604) - Two "Using help" documents in suiterunner
- (bug 346605) - Make openHelp() calls call suiterunner help correctly
- (bug 348386) - We're using the xpfe download manager for the time
being, mainly because toolkit is refactoring their download manager at
the moment. Hopefully once toolkit has finished their refactoring we can
pick up their download manager back-end more easily.
- (bug 377105) - The Palm Sync extension is now capable of building and
running with trunk builds again (suiterunner and xpfe). There were
various changes required to get the suiterunner version working - mainly
fixing installation locations and sorting out the branding so that it
would reference SeaMonkey rather Thunderbird - it also should be
packageable as a xpi on its own now. Folks with windows zip builds of
SeaMonkey will probably already have noticed that the first installation
with a new profile brings up a dialog asking if you wish to install the
conduit - just select no if you don't want it.
- (bug 377953) - build suiterunner package/installer via suite/installer
- (bug 381176) - Fixes MAPI preference display in suiterunner.
- (bug 381186) - This fixes up form info (wallet) a bit so that it can
be used in suiterunner builds whilst we're still working on the
transition to toolkit's password manager/satchel.
Locale related checkins (= moving suiterunner towards source l10n):
- (bug 377799) - moved bookmarks chrome to /suite
- (bug 377801) - moved the typeaheadfind locales to /suite
Also related checkins:
- (bug 379818) - Suiterunner no longer builds the xpcom_obsolete
library. This library mainly consisted of old code for handling files,
and was one of the blockers to getting running with libxul or xulrunner,
but also helps to reduce our executable size. David Bienvenu did the
main work for this in completing the mailnews removal of the
xpcom_obsolete dependency.
Work in Progress:
We've got all the reviews necessary to do the transition now (the two
patches on bug 328887) and we are currently looking to do the transition
on trunk to suiterunner sometime this week, baring any major problems.
We're hoping to get the NSIS installer patch checked in before then, but
we probably won't block on it. There's the one newsgroup migration
problem (referenced above) that I'm currently looking into as well.
The following bugs now have approved patches waiting to land at the time
of/very soon after the switch to suiterunner on trunk.
363700 - Software Installation pref pane update for suiterunner
372856 - Remove themes pane from suiterunner builds
I'm also hoping to have an approved patch for bug 381338 - allow import
of bookmarks from other profiles that we support migration from.
Currently this will only be existing SeaMonkey/Netscape profiles as
that's all the profile migrator supports. As we add more application
migration options to the profile migrator, they will automatically
become available if we are able to import bookmarks from that application.
Other Notes:
It has been agreed that the SeaMonkey trunk version number will be
bumped to 2.0a1pre at the time of the switch, so the next release of
SeaMonkey will be 2.0. Basically its felt that the changes that have
happened for suiterunner (and its new features) are big enough for a
major number bump.
Standard8
Serge Gautherie
> - (bug 377105) - The Palm Sync extension is now capable of building and
> running with trunk builds again (suiterunner and xpfe). There were
> various changes required to get the suiterunner version working - mainly
> fixing installation locations and sorting out the branding so that it
> would reference SeaMonkey rather Thunderbird - it also should be
> packageable as a xpi on its own now. Folks with windows zip builds of
> SeaMonkey will probably already have noticed that the first installation
> with a new profile brings up a dialog asking if you wish to install the
> conduit - just select no if you don't want it.
Could there be a (user/hidden/...) "preference" to disable it completely ?
Or would it be enough to have a script delete some extension files ?
Use case: I'm testing (Zip) nightlies, creating profiles as needed,
never had any Palm device/conduit.
Thanks.
Asrail
> - (bug 348386) - We're using the xpfe download manager for the time
> being, mainly because toolkit is refactoring their download manager at
> the moment. Hopefully once toolkit has finished their refactoring we can
> pick up their download manager back-end more easily.
Two words: not anymore.
:D
> Work in Progress:
>
> We've got all the reviews necessary to do the transition now (the two
> patches on bug 328887) and we are currently looking to do the transition
> on trunk to suiterunner sometime this week, baring any major problems.
Reviews done!
> It has been agreed that the SeaMonkey trunk version number will be
> bumped to 2.0a1pre at the time of the switch, so the next release of
> SeaMonkey will be 2.0. Basically its felt that the changes that have
> happened for suiterunner (and its new features) are big enough for a
> major number bump.
Long live SM!
Benoit Renard
> bumped to 2.0a1pre at the time of the switch, so the next release of
> SeaMonkey will be 2.0. Basically its felt that the changes that have
> happened for suiterunner (and its new features) are big enough for a
> major number bump.
I would argue that a new major new Gecko version (1.9), that itself
already has major new features of its own, would mean a major version
bump already. The move to toolkit cemented it, in my opinion. In
summary: I approve. :)
Mark Banner
You can remove the directory extensions/p@m is one way. Forcing the pref
extensions.palmsync.conduitRegistered to true will disable the installer
prompt.
Otherwise we're into extension/addon manager territory and I'd have to
do some digging for that.
Standard8
Serge Gautherie
> You can remove the directory extensions/p@m is one way. Forcing the pref
That works well for me :-)
> extensions.palmsync.conduitRegistered to true will disable the installer
> prompt.
I know how to use prefs.js/user.js once the profile is created.
But is there some equivalent (preferably user.js) at the application
level, which would apply to all (new) profiles ?
> Otherwise we're into extension/addon manager territory and I'd have to
> do some digging for that.
(Don't know anything more about that.)
Asrail
> Mark Banner, 21-05-2007 15:59:
>> - (bug 348386) - We're using the xpfe download manager for the time
>> being, mainly because toolkit is refactoring their download manager at
>> the moment. Hopefully once toolkit has finished their refactoring we
>> can pick up their download manager back-end more easily.
>
> Two words: not anymore.
> :D
Err... counting the number of regressions it throwed, I'm happy we are
not using it yet.
Mark Banner
Any rewrite of a complete component (or implementation of a new one)
like that is bound to cause regressions. Its very hard to do all find
all the test cases/problems when you write the code. Take the profile
migrator patch as well for another example.
This is the reason we have a trunk, nightly builds and testers. I
thought the profile migrator was ok and ready to go - it turns out it
wasn't quite there yet.
Standard8
Robert Kaiser
> We've got all the reviews necessary to do the transition now (the two
> patches on bug 328887) and we are currently looking to do the transition
> on trunk to suiterunner sometime this week, baring any major problems.
Actually, it'll probably get pushed out to next week, see
http://home.kairo.at/blog/2007-05/did_i_say_this_week
Robert Kaiser
Georg Maaß
rv:1.9a5pre) Gecko/2007052512 SeaMonkey/1.5a
This happens in the preferences:
================================
Appearance -> Themes
XML Parsing Error: undefined entity
Location: chrome://communicator/content/pref/pref-themes.xul
Line Number 109, Column 31: <label class="small-margin"><html:a
href="&getNewThemesURL;" id="themesLink"
------------------------------^
Probably the entity refered by &getNewThemesURL; is missing in the DTD.
Navigator -> Languages
The Default Character Encoding menu is little bit too wide. This is only
ugly, but works.
Mail & Newsgroups -> Character Encodings
The Default Character Encoding menu of the Message Display is little bit
too wide. This is only ugly, but works. The Default Character Encoding
menu of the Composing Message is correct width (less entries, the very
wide entries are missing).
Why is there no resizing grip in the lower right corner of the
preferences? This makes it impossible to resize the preferences window
to a larger size. There is also no splitter to make the Category wider
to prevent clipping.
Mark Banner
> This happens in the preferences:
> ================================
> Appearance -> Themes
>
> XML Parsing Error: undefined entity
> Location: chrome://communicator/content/pref/pref-themes.xul
> Line Number 109, Column 31: <label class="small-margin"><html:a
> href="&getNewThemesURL;" id="themesLink"
> ------------------------------^
>
> Probably the entity refered by &getNewThemesURL; is missing in the DTD.
As has I'm fairly sure been noted before, we have yet to remove the
themes pane. There's an approved patch waiting for check-in once we
switch over to suiterunner on trunk but we're not removing it before
then because it'd break the xpfe builds.
> Navigator -> Languages
>
> The Default Character Encoding menu is little bit too wide. This is only
> ugly, but works.
Is this the same on current xpfe builds? If not, its possibly a
regression, if it is then its not a regression so should already be on
file or if not could be filed.
> Mail & Newsgroups -> Character Encodings
>
> The Default Character Encoding menu of the Message Display is little bit
> too wide. This is only ugly, but works. The Default Character Encoding
> menu of the Composing Message is correct width (less entries, the very
> wide entries are missing).
Ditto
> Why is there no resizing grip in the lower right corner of the
> preferences? This makes it impossible to resize the preferences window
> to a larger size. There is also no splitter to make the Category wider
> to prevent clipping.
AFAIK we should have a resizing grip on the preferences window (I can't
test at the moment due to rebuilding). We've never had a splitter to
make the category wider so that is nothing to do with suiterunner.
When reporting problems against suiterunner builds at the moment, please
compare with xpfe builds. If its the same, its not a regression due to
suiterunner, otherwise it is. With this information we'll be able to
track down actual suiterunner regression bugs a lot faster (we do care
about both sets, but at this stage it helps to know which is which).
Standard8
Peter Weilbacher
> Georg Maaß wrote:
>> Why is there no resizing grip in the lower right corner of the
>> preferences? This makes it impossible to resize the preferences window
>> to a larger size. There is also no splitter to make the Category wider
>> to prevent clipping.
>
> AFAIK we should have a resizing grip on the preferences window (I can't
> test at the moment due to rebuilding).
No app (neither toolkit or XPFE based) can resize the options/prefs
dialog on Windows or OS/2. So this is normal. Looking at the various
preferences.dtd files, Mac also seems to have the width fixed but not
the height.
Peter.
Philip Chee
> Georg Maaß wrote:
>> Why is there no resizing grip in the lower right corner of the
>> preferences? This makes it impossible to resize the preferences window
>> to a larger size. There is also no splitter to make the Category wider
>> to prevent clipping.
> AFAIK we should have a resizing grip on the preferences window (I can't
> test at the moment due to rebuilding). We've never had a splitter to
> make the category wider so that is nothing to do with suiterunner.
AFAIK on Win32/XPFE builds there was never a resizing grip (unless you
installed an extension like Mnenhy)
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Georg Maaß
> Georg Maaß wrote:
>>
>> The Default Character Encoding menu is little bit too wide. This is
>> only ugly, but works.
>
>
> Is this the same on current xpfe builds? If not, its possibly a
> regression, if it is then its not a regression so should already be on
> file or if not could be filed.
It is not on nightly trunk.
>> Mail & Newsgroups -> Character Encodings
>>
>> The Default Character Encoding menu of the Message Display is little
>> bit too wide. This is only ugly, but works. The Default Character
>> Encoding menu of the Composing Message is correct width (less entries,
>> the very wide entries are missing).
>
>
> Ditto
dito
So this is a suite runner regression.
>
>> Why is there no resizing grip in the lower right corner of the
>> preferences? This makes it impossible to resize the preferences window
>> to a larger size. There is also no splitter to make the Category wider
>> to prevent clipping.
>
>
> AFAIK we should have a resizing grip on the preferences window (I can't
> test at the moment due to rebuilding). We've never had a splitter to
> make the category wider so that is nothing to do with suiterunner.
Yes, this problem is on trunk too. We need a splitter or horizntal
scrollbars. A splitter is better in my opinion especially in combination
with a resize grip in the lower right corner.
This is not a suite runner regression but a problem of both suiterunner
and trunk.
Karsten Düsterloh
>>> Why is there no resizing grip in the lower right corner of the
>>> preferences? This makes it impossible to resize the preferences window
>>> to a larger size. There is also no splitter to make the Category wider
>>> to prevent clipping.
Well, it's kind of historic. If you read respective code comments of Ben
Goodger, it's even *deliberate*. Alas, it's not stated *why*... :(
The _only_ valid reason I can think of is "fail-safety": in case you
mess up your system horribly, a pref window should be usable even at a
resolution of 640*480.
>> AFAIK we should have a resizing grip on the preferences window (I can't
>> test at the moment due to rebuilding). We've never had a splitter to
>> make the category wider so that is nothing to do with suiterunner.
Right.
> AFAIK on Win32/XPFE builds there was never a resizing grip (unless you
> installed an extension like Mnenhy)
Yes, I think while we probably shouldn't _save_ the dimensions (and
panels should adhere to the given default dimensions!), we definitely
should allow to alter them, so I added that.
Karsten
--
Feel free to correct my English. :)
Neil
> Mark Banner wrote:
>
>> Georg Maaß wrote:
>>
>>> Navigator -> Languages
>>>
>>> The Default Character Encoding menu is little bit too wide. This is
>>> only ugly, but works.
>>
>> Is this the same on current xpfe builds? If not, its possibly a
>> regression, if it is then its not a regression so should already be
>> on file or if not could be filed.
>
> It is not on nightly trunk.
I'm going to assume here that you've been using the Classic theme.
(Unfortunately) Suiterunner doesn't use the Classic theme for the core
XUL widgets, instead it uses the *Stripe themes, which are totally
different.
--
Warning: May contain traces of nuts.
Tony Mechelynck
> On Sat, 26 May 2007 19:21:28 UTC, Karsten Düsterloh wrote:
>
>> in case you mess up your system horribly, a pref window should be
>> usable even at a resolution of 640*480.
>
> easy to mess up the system in such a way that the dimensions are not
> enought to fit the content. See bug 296695 (that was split from bug
> 293427) and others like e.g. bug 241229, bug 199721. Maybe that has all
> changed now with Thebes and the improved units handling.
- All content should be accessible in "some" way
- The OK/Cancel (etc.) buttons should be clickable, and inside the screen even
at lowest resolution.
In some "ugly" circumstances (such as a big chrome font and a low resolution)
scrollbars might be the only solution; but IMHO, if possible the whole content
of the current pane should be displayed.
In my experience, Firefox and Thunderbird suffer more than SeaMonkey from the
"clipped prefs panel" syndrome, where you have to enlarge the popup in order
to see the bottom checkboxes or radio buttons. Let's hope it doesn't get
worse. ;-)
Best regards,
Tony.
--
Electrocution, n.:
Burning at the stake with all the modern improvements.
Philip Chee
> Philip Chee aber hob zu reden an und schrieb:
>>>> Why is there no resizing grip in the lower right corner of the
>>>> preferences? This makes it impossible to resize the preferences window
>>>> to a larger size. There is also no splitter to make the Category wider
>>>> to prevent clipping.
> Well, it's kind of historic. If you read respective code comments of Ben
> Goodger, it's even *deliberate*. Alas, it's not stated *why*... :(
> The _only_ valid reason I can think of is "fail-safety": in case you
> mess up your system horribly, a pref window should be usable even at a
> resolution of 640*480.
>> AFAIK on Win32/XPFE builds there was never a resizing grip (unless you
>> installed an extension like Mnenhy)
> Yes, I think while we probably shouldn't _save_ the dimensions (and
> panels should adhere to the given default dimensions!), we definitely
> should allow to alter them, so I added that.
Since the suite code now has a different ownership structure, perhaps
it's time to relook at this issue. Besides I don't think Ben cares about
the suite anymore having been a prime mover in the creation of Firefox.
Actually doesn't he work for Google these days?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]03h:42m SLEEP? I'm a programmer!
* TagZilla 0.066.6
Benoit Renard
> Goodger, it's even *deliberate*. Alas, it's not stated *why*... :(
> The _only_ valid reason I can think of is "fail-safety": in case you
> mess up your system horribly, a pref window should be usable even at a
> resolution of 640*480.
Ben Goodger strikes again! Grr.
Anyway, as a user who actually has 640x480 as his resolution, I have to
say that the preferences window is very usable for me. :) I just don't
see the title bar. However, with Mail & Newsgroups Account Settings >
Server Settings, the options are too high, and one option is missing
from view. A vertical scroll bar would be a good idea there. ChatZilla
already does it for their preferences window.
Georg Maaß
> In some "ugly" circumstances (such as a big chrome font and a low
> resolution) scrollbars might be the only solution; but IMHO, if possible
> the whole content of the current pane should be displayed.
But this does not happen instead it is clipped.
Georg Maaß
> I'm going to assume here that you've been using the Classic theme.
> (Unfortunately) Suiterunner doesn't use the Classic theme for the core
> XUL widgets, instead it uses the *Stripe themes, which are totally
> different.
>
I used the theme as got from factory, which is classic. I did not change
it. I know the look from the trunk and it is the same look in suite
runner. So I assume its classic.
Karsten Düsterloh
>> panels should adhere to the given default dimensions!), we definitely
>> should allow to alter them, so I added that.
>
> Since the suite code now has a different ownership structure, perhaps
> it's time to relook at this issue.
Since I'm working on "prefwindow goes toolkit" (despite being quite
delayed :-|), you can be assured that I'll keep an eye on it. ;-)
Karsten Düsterloh
> Anyway, as a user who actually has 640x480 as his resolution,
Why? Technical reasons?
I mean, even my i486-DX2/50 supported 800*600 back then, IIRC!?!
> I have to say that the preferences window is very usable for me. :) I
> just don't see the title bar.
That's a bug, then. It should fit completely on screen.
> However, with Mail & Newsgroups Account Settings > Server Settings,
> the options are too high, and one option is missing from view. A
> vertical scroll bar would be a good idea there.
Actually, no. Pref windows should not scroll.
If it doesn't fit on a page, it shouldn't be on just one page.
> ChatZilla already does it for their preferences window.
I know, and I find that quite bad design.
OTOH, I still don't know why actually having small pref dialogs is a
good thing at all - we *are* in fact a browser and capable of displaying
'random' content, so why not make the prefs be shown in a browser
window? It'd already be restricted by the window size (and you could
have scrollbars for free *g*)!
Ricardo Palomares Martinez
>
> OTOH, I still don't know why actually having small pref dialogs is a
> good thing at all
<rant>
One thing I love when I take a look to Firefox preferences is
remembering how Firefox was made to get a simpler interface and now
his preferences window is as complex or more than SeaMonkey's, except
that SeaMonkey has it waaay better structured thanks to the tree
sidebar, whereas in Firefox you get lost in a myriad of buttons
opening dozens of popup windows. :-)
</rant>
> - we *are* in fact a browser and capable of displaying
> 'random' content, so why not make the prefs be shown in a browser
> window? It'd already be restricted by the window size (and you could
> have scrollbars for free *g*)!
I don't know if this could pose any problem to i18n, but it could
worth a shot. Funnily enough, the most overloaded "preferences" panels
to me are in fact the mail & news account manager panels, so putting
them in a browser window would be a SeaMonkey-only solution (not valid
for Thunderbird).
Just my 0.02.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Georg Maaß
> OTOH, I still don't know why actually having small pref dialogs is a
> good thing at all - we *are* in fact a browser and capable of displaying
> 'random' content, so why not make the prefs be shown in a browser
> window? It'd already be restricted by the window size (and you could
> have scrollbars for free *g*)!
I tink the main/news window has more similiarity with the preferences
window and there all the necessary controls like splitter, rezize grip
etc. are available.
What I'm missing is drag and drop in the treeview on the Mac. It does
not work in XULRunner trunk, it does not work in mail/news of SM trunk
(assuming the folders explorer being implemented as treeview) and it
also does not work in SM suiterunner on Mac. Probably this is a general
regression from migration to Kairo, that has not yet been fixed
Benoit Renard
> I mean, even my i486-DX2/50 supported 800*600 back then, IIRC!?!
It's been like that since the beginning, and I'm very sensitive to
change. I do change my resolution when it's necessary, though, and
always find that everything becomes too small for my liking.
> That's a bug, then. It should fit completely on screen.
It's too high for that, though.
> Actually, no. Pref windows should not scroll.
Why not? I admit that having pref windows that don't need to scroll is
nice, though.
Karsten Düsterloh
>
> Why not? I admit that having pref windows that don't need to scroll is
> nice, though.
Little scrollbars in little panes of little dialogs get little attention
by users with little knowledge of where to look...
Karsten Düsterloh
>> we *are* in fact a browser and capable of displaying 'random'
>> content, so why not make the prefs be shown in a browser window?
>
Most other apps are *not* browsers...
> There are probably UI guidelines about that, too.
Not that they jumped at me yet. ;-)
But I didn't do a thorough search for it.
> And looking at applications that (mis)use their main window to also
> display settings (like e.g. ZoneAlarm) immediately makes it clear why
> that is a bad idea. It's really confusing...
Yes, because the primary usage of their main window is not displaying
arbitrary content. But exactly that is the primary task of a browser...
Karsten Düsterloh
> <rant>
> One thing I love when I take a look to Firefox preferences is
> remembering how Firefox was made to get a simpler interface and now
> his preferences window is as complex or more than SeaMonkey's, except
> that SeaMonkey has it waaay better structured thanks to the tree
> sidebar, whereas in Firefox you get lost in a myriad of buttons
> opening dozens of popup windows. :-)
> </rant>
Heh, that's what I said back then (and now still), and of course ;-)
noone cared, because The Fox Does It The New Way And New Is Always Best.
> Funnily enough, the most overloaded "preferences" panels
> to me are in fact the mail & news account manager panels, so putting
> them in a browser window would be a SeaMonkey-only solution (not valid
> for Thunderbird).
That's not quite true, actually.
Thunderbird is in fact a slightly stripped down SeaMonkey with different
UI and such. ;-) It just lacks certain browser-only parts, but backend
functionality like displaying websites is there in theory, else you
won't be able to render its UI, HTML mail, RSS content, use JS or even
compose a message...
Actually, it won't be too hard to make Firefox a Thunderbird extension. ;-)
Georg Maaß
> Little scrollbars in little panes of little dialogs get little attention
> by users with little knowledge of where to look...
Car divers with little knowlege of their car should not maintain the
engine otherwise the car will end as yellow submarine.
A splitter and a resize grip should mostly prevent the need for
scrollbars. Clipping is a bug, if the user can not customize to prevent
clipping.
Karsten Düsterloh
> A splitter and a resize grip should mostly prevent the need for
> scrollbars.
You mean a draggable splitter between the navigation tree and the pref
panels? Okay, noted.
Tony Mechelynck
You can even set Thunderbird to display an arbitrary webpage (in practice), as
follows:
Edit => Preferences => General => Thunderbird Start Page
Enable it and write the URL there, then close the prefs UI.
Select an empty folder in the left pane to avoid unwantedly opening an email.
Make sure the preview pane is on (toggle it by F8 is necessary). Then Go =>
Mail Start Page. Resize the preview pane if necessary, to give it more
real-estate.
You can display "ordinary" web pages that way, or "special" pages such as the
Thunderbird version about: , the Thunderbird build configuration
about:buildconfig , the Config Editor interface about:config , the Easter Egg
from the Book of Mozilla about:mozilla , etc. etc. etc. If the MR Tech Local
Install extension is installed you can even use about:kitchensink .
What it cannot do AFAIK is following a link when you click it and display it
instead of the page linked from. But you can use "Copy Link Location" from the
right-click menu then paste it into the prefs UI as above.
When you're finished using the Thunderbird web browser, click F8 again and
you're back to "normal" mailer operation.
Best regards,
Tony.
--
ARTHUR: This new learning amazes me, Sir Bedevere. Explain again how sheep's
bladders may be employed to prevent earthquakes.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Andy Willis
as in a specially designed dialog box. If this discussion had come up
a few weeks ago I wouldn't have known how bad ZoneAlarm was but having
just spent hours tring to get it to work with a server a coworker
wrote in dotnet before giving up and just rewriting it in C, I now can
attest to how bad a design their approach is.
One of the main reasons I don't like Firefox is their worthless
preferences approach. I do like the idea of allowing it to be resized
without necessarily remembering the size (that could cause some
consternation among new user's not understanding why the size isn't
saved). Browsers are used for various applications to take the place
of stand alone apps and truthfully most of those applications stink.
I'm sure it could be done in the main window but I don't think it
would be as functionally clean.
Andy
Karsten Düsterloh
> I'd be surprised if it can be done as efficiently in the main window
> as in a specially designed dialog box.
I'd be surprised if it won't...
And in fact I wonder what do you mean by "efficiently"?
You can load the pref main window into the browser even now via its
(internal) URL <chrome://communicator/content/pref/pref.xul> (although
it isn't fully functional, because some vital scripting parts don't
understand that environment).
> I do like the idea of allowing it to be resized
> without necessarily remembering the size (that could cause some
> consternation among new user's not understanding why the size isn't
> saved).
Yeah, exactly. Maybe we could save the dimensions, but clip them if we
detect smaller screen dimensions? This needs some thought...
> Browsers are used for various applications to take the place
> of stand alone apps and truthfully most of those applications stink.
But mainly because/when they don't use XUL!
Creating HTML/AJAX based "applications" is usually sucky or clumsy or
gets large indeed.
> I'm sure it could be done in the main window but I don't think it
> would be as functionally clean.
Again, what does "functionally clean" mean?
Andy Willis
context of the user's ease of use. The preferences window is easy and
quick to use and find things. HTML interface is typically not as easy
to work with for such uses.
I agree that XUL makes a large difference and if they were XUL based
and not merely "web based" (ussually HTML).
In fact, having not looked at the pref code, I would have think the
preferences window is XUL code.
It may actually be possible to put the same interface into the main
window, my experience with web based preferences (even for a small
thing such as a router) is not as quick and easy to work with as the
current preferences window. My experience could be coloring my
judgement, maybe the same can be achieved in the browser window... I
just would hate to loose the ease of use now that is the main thing to
my mind that makes it so much better than Firefox.
Andy
Justin Wood (Callek)
I'm still around to help with this Karsten, dispite my IRC "been away"
mode, and my current lack of a build environ.
I assume we'll be going with your design w/ the latest review(s), to my
dismay though :-P
~Justin Wood (Callek)
Manuel Reimer
>> XML Parsing Error: undefined entity
>> Location: chrome://communicator/content/pref/pref-themes.xul
>> Line Number 109, Column 31: <label class="small-margin"><html:a
>> href="&getNewThemesURL;" id="themesLink"
>> ------------------------------^
>>
>> Probably the entity refered by &getNewThemesURL; is missing in the DTD.
> As has I'm fairly sure been noted before, we have yet to remove the
> themes pane. There's an approved patch waiting for check-in once we
> switch over to suiterunner on trunk but we're not removing it before
> then because it'd break the xpfe builds.
Wouldn't it be a better solution to move the themes selection stuff into
there?
CU
Manuel
Tony Mechelynck
It might be interesting to write an extension allowing the prefs UI to be
opened in a tab (like there are extensions like that for the downloads manager
and the addons manager), publish that extension at AMO, and see how successful
it got.
Best regards,
Tony.
--
Women are probably the main cause of free software starvation.
Mark Banner
Possibly, but that would involve writing some possibly complicated code
to insert the extension manager into a pref pane (may be easier once
we've got toolkit prefs fully working).
Anyway, for now we get the free UI from the extension manager. Anyone is
welcome to look at "re-implementing" the themes pane, but for now its dying.
Standard8
Karsten Düsterloh
> I'm still around to help with this Karsten, dispite my IRC "been away"
> mode, and my current lack of a build environ.
Good to know. :)
> I assume we'll be going with your design w/ the latest review(s), to my
> dismay though :-P
The patch attached in the bug is pretty off target by now.
Karsten Düsterloh
> context of the user's ease of use. The preferences window is easy and
> quick to use and find things.
This won't change - did you try loading that URL in the browser?
It looks *exactly* like the pref dialog, only inside the browser!
> HTML interface is typically not as easy to work with for such uses.
Rebuilding the pref dialog in HTML would be truly stupid indeed.
> I agree that XUL makes a large difference and if they were XUL based
> and not merely "web based" (ussually HTML).
I never said "web based". All I mean is loading the XUL in the browser
instead of opening an additional window.
It may be worth looking if it'd be possible to make it work in both
browser and as a dialog...
> In fact, having not looked at the pref code, I would have think the
> preferences window is XUL code.
It is.
> It may actually be possible to put the same interface into the main
> window, my experience with web based preferences (even for a small
> thing such as a router) is not as quick and easy to work with as the
> current preferences window.
Like I said: true, because no XUL there.
> I just would hate to loose the ease of use now that is the main thing to
> my mind that makes it so much better than Firefox.
There's no point in making things worse. ;-)
Georg Maaß
> Georg Maaß aber hob zu reden an und schrieb:
>
>>A splitter and a resize grip should mostly prevent the need for
>>scrollbars.
>
>
> You mean a draggable splitter between the navigation tree and the pref
> panels? Okay, noted.
Yes