I hadn't noticed this until just now, when I looked more closely at the Release Notes: Mozilla's bookmarks have been overhauled. Bookmarks now include a root level folder, the ability to have two differently named bookmarks pointing at the same location, site icons in the Bookmark Manager and Bookmarks Sidebar, and separators now have support for labels.
So site icons seem to work everywhere except the Bookmarks menu. Cool!
Thanks to the magic of XUL and XBL, you *can* change key bindings. See http://mozilla.org/unix/customizing.html, the "Key Bindings" section, for info on how to change things around to suit you better.
Oh, and don't be fooled by the 'unix' in the URL - most of the info on that page is completely cross-platform.
The GTK2 builds are done by Chris Blizzard, a mozilla.org staff member who works at RedHat. There weren't any (that I could find) done for RC2 or RC3, but I'm still hopeful that we'll see one for 1.4 final. Perhaps he's waiting for http://bugzilla.mozilla.org/show_bug.cgi?id=201209 to be fixed. (-moz-opacity makes things invisible in GTK2 port)
Re:Problems I have with Mozilla 1.3
on
Mozilla 1.4 Released
·
· Score: 4, Insightful
It could also be argued that IE is the most broken browser out there. Specs *are* important - no specs mean a fragmentation of the web, different vendors just randomly inventing 'html'. That means that page development time goes up exponentially, as developers now have as many different targets as there are browsers, instead of one target, the w3c spefification.
Actually, there is a spellchecker available for Mozilla - http://spellchecker.mozdev.org. It's planned to be included into Mozilla at some point - hopefully soon.
What you are seeing is the correct (well, intended) behavior. There have been issues with favicons/site icons for some time, since before 1.0. They've been pulled out, put back in, and pulled out again. http://bugzilla.mozilla.org/show_bug.cgi?id=113574 goes over most of the issues, and can point you at most of the other relevant bugs.
As I recall, however, Mozilla Firebird *does* do favicons in the bookmark menu.
Yes, new versions of Mozilla should always be installed into a clean directory. Installing over top of previous versions is known to cause problems.
From the relnotes: Note: It is recommended that you uninstall previous versions of Mozilla before installing Mozilla 1.4. This will not delete your bookmarks, history, cookies and other information which is stored in your profile directory.
Wow, this sounds like the perfect phone for stagehands!!! Integrated flashlight, so we can see what we're doing backstage, and an integrated sound meter(!!) so that when the venue manager tells me that the band is too loud, I can whip out my phone and say "Look! 93dB! Within contract limits!!" The FM tuner would come in handy on those long city-to-city bus rides, too...
You might want to check your helper apps: Edit > Preferences > Navigator > Helper Applications. Often, something in there will be wrong (don't know what, exactly, never seen it firsthand), and cause that incorrect naming thing. Clearing the appropriate apps/associations, and then resetting them correctly has solved the problem for a few people I've talked to.
I wrote a filter that moves mail marked as junk to the jumk mail folder. Works every time.:)
Re:Lemme get this straight . . .
on
Mozilla 1.4 RC1
·
· Score: 2, Interesting
Since we're getting things straight... XPFE *IS* XUL. The Phirebird folks also use XUL, only they use it differently and, some would argue, better. The XUL that describes the XPFE UI is rather monolithic, having been around for quite a while, and hacked on heavily for all that time. The Firebird XUL tends to be much leaner - due, in large part, to the componentization (I think I just made that word up) which is at the core of the new Mozilla roadmap.
I think that the main cause of the percieved speed difference (apart from the removal of Mail, IRC, and whatnot) is that the Phirebirdnix developers learned lessons from Mozilla's use of XUL, and wrote much cleaner code. That's what I've heard, anyway.:)
Re:The MOST important change
on
Mozilla 1.4 RC1
·
· Score: 5, Informative
Well...*mostly*. From the release notes:
"# Due to the nature of C++ compilers, libraries built with GCC will likely be incompatible with libraries built with MSVC. For example, XPCOM plugins will not work. This includes the Java plugin. # Due to the use of MSVC-specific code in the tree and the relative immaturity of the w32api, certain functionality will not be available in the GCC build. The dependency tree for bug 203303 tracks the list of MinGW GCC-specific issues."
No Java, and other, unspecified, non-working bits. Hmm...I think I'll wait until it's a little older before I try to build on Win32.
Mozilla and Firebird both use the exact same engine - Gecko. And since Firebird is built off of the same trunk as Mozilla, the version, and hence capabilities, of Gecko are the same. Almost all of the differences between the Mozilla Application Suite and Mozilla Firebird (to use the correct terms) are UI and removal of non-browser components.
Ok, not reading artiles before posting is common, and I guess by now I can deal with it - but not even reading a *comment* before moderating it!? People - you just modded up to +3 a link to www.teenmaidensonline.com! Good lord!! I guess bashing.NET is just a sure way to get modded up...
I think you're wrong, and here's why: First, I'd like to address your "stability and adoption" comments. Stability - Phoenix is, at the very least, as stable as Mozilla, and anecdotal evidence I've seen suggests that it may, in fact, be far more stable. Adoption is certainly not an issue - it's not like mozlla.org is saying "Hey, our previous product sucked, try this new one!" - they're merely integrating similar, better technology into an existing product, and removing some of the not-so-great parts. As for the lack of a migration path - remember, Phoenix is based on the same technologies (Gecko, XUL, XBL) as Mozilla, so development-wise, that all stays pretty much the same. The main difference for developers will be the new code ownershp model, about which I can only say "It's about time!" So, while the "resistant-to-change, mozilla-loving" part of me agrees with you, the logical, wants-the-best-for-Mozilla part knows that this is the rigt path for the project.
This is completely freaking me out. I can only wonder at how a radical re-design this is going to turn out to be, from both a developer's and end-user's standpoint. The Mozilla project has, by all accounts, been an incredible success, and has been adopted by some major entities, eg. Sun, HP, IBM, Red Hat. By making this radical a change this soon after 1.0, do we risk alienating users and developers? I mean, now that people have gotten used to Mozilla, we turn around and dump something hugely different in their laps? My fear is that commercial entities, along with the pro-Mozilla-the suite camp, will continue development on Mozilla Classic (the 1.4 branch), while the Phoenix folks work on NGMozilla...a fork. Hold onto your hats, folks.
But the other three apps have largely been ignored for some time. They have a basic level of capability but haven't been refined significantly in some time. Well, I think that other components (both those you mention, and others that may not even exist yet) may benefit greatly from this change in direction. It seems to me that a major point of this is to allow people to work on, say, MailNews, without having to worry about breaking the entire suite, which will have the inevitable effect of increased development on said components. As far as Mozilla has come, this has the potential to allow it to go much further.
Favicons (site icons) have been disabled in the Personal Toolbar and the Bookmarks menu for a while, due to caching issues. They're still in Phoenix, and possible some of the third-party extensions at mozdev. A search of the n.p.mozilla newsgroups turned up this guide to restoring them. I haven't tried it, though, so I have no idea if it works, or what it may screw up. For details of the caching issues - see bug 120466
Hmm..I thought Titania was that new processor from Intel...how the hell you make nanotubes from CPUs, though, was kind of confusing me..
Well, the obvious solution is to get rid of all the Windows machines on the network. Presto, problem solved!
ummm.
:(
http://cryptome.org
and
http://cartome.org
Damn, I've just Slashdotted Cryptome...
It's been on CNN and CNBC since this morning.
I hadn't noticed this until just now, when I looked more closely at the Release Notes: Mozilla's bookmarks have been overhauled. Bookmarks now include a root level folder, the ability to have two differently named bookmarks pointing at the same location, site icons in the Bookmark Manager and Bookmarks Sidebar, and separators now have support for labels.
So site icons seem to work everywhere except the Bookmarks menu. Cool!
Thanks to the magic of XUL and XBL, you *can* change key bindings. See http://mozilla.org/unix/customizing.html, the "Key Bindings" section, for info on how to change things around to suit you better.
Oh, and don't be fooled by the 'unix' in the URL - most of the info on that page is completely cross-platform.
The GTK2 builds are done by Chris Blizzard, a mozilla.org staff member who works at RedHat. There weren't any (that I could find) done for RC2 or RC3, but I'm still hopeful that we'll see one for 1.4 final. Perhaps he's waiting for http://bugzilla.mozilla.org/show_bug.cgi?id=201209 to be fixed. (-moz-opacity makes things invisible in GTK2 port)
It could also be argued that IE is the most broken browser out there. Specs *are* important - no specs mean a fragmentation of the web, different vendors just randomly inventing 'html'. That means that page development time goes up exponentially, as developers now have as many different targets as there are browsers, instead of one target, the w3c spefification.
Actually, there is a spellchecker available for Mozilla - http://spellchecker.mozdev.org. It's planned to be included into Mozilla at some point - hopefully soon.
:)
However, no AOL icons available, sorry.
Just checking, did you do a clean install, or install over an older version?
Regardless of that, perhaps some of the lovely folks in #mozillazine on irc.mozilla.org can help you out.
What you are seeing is the correct (well, intended) behavior. There have been issues with favicons/site icons for some time, since before 1.0. They've been pulled out, put back in, and pulled out again. http://bugzilla.mozilla.org/show_bug.cgi?id=113574 goes over most of the issues, and can point you at most of the other relevant bugs.
As I recall, however, Mozilla Firebird *does* do favicons in the bookmark menu.
Yes, new versions of Mozilla should always be installed into a clean directory. Installing over top of previous versions is known to cause problems.
From the relnotes: Note: It is recommended that you uninstall previous versions of Mozilla before installing Mozilla 1.4. This will not delete your bookmarks, history, cookies and other information which is stored in your profile directory.
Wow, this sounds like the perfect phone for stagehands!!! Integrated flashlight, so we can see what we're doing backstage, and an integrated sound meter(!!) so that when the venue manager tells me that the band is too loud, I can whip out my phone and say "Look! 93dB! Within contract limits!!"
:)
The FM tuner would come in handy on those long city-to-city bus rides, too...
Now if it only had a rope wrench*
*rope wrench = knife.
You might want to check your helper apps: Edit > Preferences > Navigator > Helper Applications. Often, something in there will be wrong (don't know what, exactly, never seen it firsthand), and cause that incorrect naming thing. Clearing the appropriate apps/associations, and then resetting them correctly has solved the problem for a few people I've talked to.
hth.
I wrote a filter that moves mail marked as junk to the jumk mail folder. Works every time. :)
Since we're getting things straight...
XPFE *IS* XUL. The Phirebird folks also use XUL, only they use it differently and, some would argue, better. The XUL that describes the XPFE UI is rather monolithic, having been around for quite a while, and hacked on heavily for all that time. The Firebird XUL tends to be much leaner - due, in large part, to the componentization (I think I just made that word up) which is at the core of the new Mozilla roadmap.
I think that the main cause of the percieved speed difference (apart from the removal of Mail, IRC, and whatnot) is that the Phirebirdnix developers learned lessons from Mozilla's use of XUL, and wrote much cleaner code. That's what I've heard, anyway. :)
Well...*mostly*. From the release notes:
"# Due to the nature of C++ compilers, libraries built with GCC will likely be incompatible with libraries built with MSVC. For example, XPCOM plugins will not work. This includes the Java plugin.
# Due to the use of MSVC-specific code in the tree and the relative immaturity of the w32api, certain functionality will not be available in the GCC build. The dependency tree for bug 203303 tracks the list of MinGW GCC-specific issues."
No Java, and other, unspecified, non-working bits. Hmm...I think I'll wait until it's a little older before I try to build on Win32.
Mozilla and Firebird both use the exact same engine - Gecko. And since Firebird is built off of the same trunk as Mozilla, the version, and hence capabilities, of Gecko are the same. Almost all of the differences between the Mozilla Application Suite and Mozilla Firebird (to use the correct terms) are UI and removal of non-browser components.
Ok, not reading artiles before posting is common, and I guess by now I can deal with it - but not even reading a *comment* before moderating it!? People - you just modded up to +3 a link to www.teenmaidensonline.com! Good lord!! .NET is just a sure way to get modded up...
I guess bashing
Finally, they've invented Rearden Metal. I've been waiting for this. :)
I think you're wrong, and here's why:
First, I'd like to address your "stability and adoption" comments. Stability - Phoenix is, at the very least, as stable as Mozilla, and anecdotal evidence I've seen suggests that it may, in fact, be far more stable. Adoption is certainly not an issue - it's not like mozlla.org is saying "Hey, our previous product sucked, try this new one!" - they're merely integrating similar, better technology into an existing product, and removing some of the not-so-great parts.
As for the lack of a migration path - remember, Phoenix is based on the same technologies (Gecko, XUL, XBL) as Mozilla, so development-wise, that all stays pretty much the same. The main difference for developers will be the new code ownershp model, about which I can only say "It's about time!"
So, while the "resistant-to-change, mozilla-loving" part of me agrees with you, the logical, wants-the-best-for-Mozilla part knows that this is the rigt path for the project.
This is completely freaking me out.
I can only wonder at how a radical re-design this is going to turn out to be, from both a developer's and end-user's standpoint. The Mozilla project has, by all accounts, been an incredible success, and has been adopted by some major entities, eg. Sun, HP, IBM, Red Hat. By making this radical a change this soon after 1.0, do we risk alienating users and developers? I mean, now that people have gotten used to Mozilla, we turn around and dump something hugely different in their laps?
My fear is that commercial entities, along with the pro-Mozilla-the suite camp, will continue development on Mozilla Classic (the 1.4 branch), while the Phoenix folks work on NGMozilla...a fork.
Hold onto your hats, folks.
But the other three apps have largely been ignored for some time. They have a basic level of capability but haven't been refined significantly in some time.
Well, I think that other components (both those you mention, and others that may not even exist yet) may benefit greatly from this change in direction. It seems to me that a major point of this is to allow people to work on, say, MailNews, without having to worry about breaking the entire suite, which will have the inevitable effect of increased development on said components.
As far as Mozilla has come, this has the potential to allow it to go much further.
Favicons (site icons) have been disabled in the Personal Toolbar and the Bookmarks menu for a while, due to caching issues. They're still in Phoenix, and possible some of the third-party extensions at mozdev.
A search of the n.p.mozilla newsgroups turned up this guide to restoring them. I haven't tried it, though, so I have no idea if it works, or what it may screw up.
For details of the caching issues - see bug 120466