> Web-browser, advanced e-mail, newsgroup and feed client, IRC chat, and HTML editing made simple—all your Internet needs in one application.
emacs on xul
In all seriousness though I have a hard time imagining why anyone would want this ... both from a developer standpoint and a user standpoint. The recent change history is a bunch of "most of ABC other Mozilla product's code has been pulled in for X.Y.Z version, go read those notes to see what is new" and describes cherry-picking bugfixes from arbitrary versions of Firefox (60, 72, ...?)
Sounds like an absolute maintenance nightmare (or perhaps a labor of masochistic love, depending on how you look at it) of constantly cherry picking other upstream stuff into one single app for what looks like a relatively small gain. If you had no choice (ie, what linux distribution maintainers spend a lot of time on) sure, go for it, but I can use Firefox, Thunderbird, etc... as standalone apps and still have them connected using my local OS and regular old open web technologies.
> The current Mozilla Gecko codebase has seen a flow of constant major changes and api removals in the last 2 years and is no longer really usable for our needs. By the end of the year the SeaMonkey project is expected to be completely independent of Mozilla
Wow, that’s... something. Keeping a browser engine of that size maintained independently is going to be quite a task.
Plus there are a bunch of CSS improvements and the like in the last five years. If you don’t keep up with the competition your users are going to see broken sites eventually.
Always glad to see interest in SeaMonkey spread! I am writing this from an instance installed on Slackware. I use it as my daily driver at work, switching to Firefox occasionally when I need to sync with things I do on other machines.
I don't really use it often but I love that it still comes with Composer for WYSIWYG html. It's been a while but when I used it a lot about 5-7 years ago it wrote really clean, standard compliant html which made it great for quickly prototyping look and feel before diving into writing any code for new pages/sites.
Having used the stock Slackware version, which is usually just a bit behind, I'm excited to see what "our biggest release in a few years and incorporates many changes and fixes from the underlying platform code" looks like!
> I don't really use it often but I love that it still comes with Composer for WYSIWYG html.
I tried it for the first time a few weeks ago (I never do web/HTML stuff). Seamonkey Composer crashed when I tried inserting a <video> element.
> Having used the stock Slackware version, which is usually just a bit behind, I'm excited to see what "our biggest release in a few years and incorporates many changes and fixes from the underlying platform code" looks like!
According to the release notes (http://www.seamonkey-project.org/releases/seamonkey2.53.1/) it is mainly features removal and breakage :-/ The least one can cay is that they are not chatty about the positive changes and features those underlying changes may have brought.
Yeah, I went and read some stuff on Wikipedia about it after posting. Apparently Composer is considered unsupported now and only gets occasional updates because it's used as the underlying html editor in Mail.
And yes, I was mildly disappointed when I downloaded and ran this as I saw no real visual difference or changes to the UI and preferences.
So I guess Composer is not much of an option for "real" work these days. Still cool to see an alternative browser out there that's at least mostly capable of handling the "modern" web...
Just installed. Looks like it's still in the xul/xpi era. Was hoping that this could be reasonably secure alternative to Waterfox and that I'd be able to install xul/xpi extensions. Seems not.
Care to elaborate? I still mourn the death of XUL. The extensions that really meant something are now gone or available in versions that are much worse than their predecessors.
Here's a random writeup I found after some googling. I'm pretty sure that I've recently read a better description of how and why they removed XUL, but I can't find any specific overviews that seem better than this one:
The short version is that XUL is a mozilla-specific implementation of functionality that can be accomplished with standard html5/CSS/etc., and thus using specifically XUL to handle the UI is inefficient from a developer standpoint, which can also introduce bugs, etc. as developers are forced to work on/use a technology with which they're not familiar.
XUL is being replaced with (was replaced with?) the standard HTML5 engine, which is continually being improved, updated, secured, optimized, etc. IIRC, there's no reason that an extension couldn't do what it did in XUL, so the likelihood is that the lack of those extensions isn't directly related to Mozilla removing XUL, but rather extension developers re-implementing their extensions in HTML5 for Chrome, which is a vastly more common platform for browser extensions in my experience, instead of re-implementing their extensions in HTML5 for Firefox.
> IIRC, there's no reason that an extension couldn't do what it did in XUL
XUL extensions were given full access to the XUL DOM for the entire browser, whereas WebExtensions are limited in their sandbox to known extension points rather than having full HTML DOM access to the entire browser.
Also, while WebExtensions still have access to messaging channels to websites/native code/outside applications, it is indirect (and permissions/sandbox mediated). XUL extensions' XPCOM (like Microsoft's COM) gave a much direct path both in to the HTML DOM of individual websites and outward for native platform code to be written in languages like C/C++.
(All of the above of which include additional reasons why XUL/XPCOM may be security liabilities if your goal is a secure browser: free reign of the browser DOM, website DOM, and easier access to native code.)
> there's no reason that an extension couldn't do what it did in XUL
The XUL-webextension transition resulted in a huge loss of API surface. This cost us vim keybindings, tree style tabs, the ability to modify the new tab page, and probably some other things that I'm forgetting. While they eventually added some replacements, it's still not 100% back to where it was (ex. tree style tabs now works, but can't hide the original tab bar).
It's complicated. Initially there was Mozilla Suite. Mozilla Suite consisted of a browser, a mail and an IRC client. Then Firefox came out as a simpler browser, without all that unnecessary stuff. And the mail component from Mozilla Suite became Thunderbird. But the Mozilla community liked the old Mozilla Suite, so they kept developing it after Mozilla gave up on it, under the name SeaMonkey. So today SeaMonkey Mail and Thunderbird still share lots of code, but technically speaking they aren't the same thing.
(Confusingly, there were many more versions of Netscape after 4, but Mozilla Suite didn't really derive from them. Netscape 6 and 7 were just contemporary versions of Mozilla Suite with some Netscape badging slapped on. Netscape 8 was based on early versions of Firefox, dropped the other non-browser "suite" components, and was only released for Windows. Netscape 9 was also a browser-only thing, but went back to being cross-platform.)
In comm-central, there are three overarching directories [1]: mailnews, mail, and suite. The first directory is essentially all of the backend logic corresponding to the implementation of mail protocols, database logic, etc. The latter two directories are Thunderbird- and SeaMonkey-specific code, and almost entirely consist of the GUI display and GUI driver code, although there are some product-only components.
[1] There's a few more directories that are split out of mailnews, due more to historical reasons than any sane code split.
I’ve never been a SeaMonkey user but I’ve always been impressed that it’s still being developed and used, it’s really cool in a time when we’re moving to a new age of browser engine monoculture.
Yup, got it. But from a internet forum perspective, it's going to be the same discussion. Submissions about incremental releases almost always turn out to be generic discussions about the project in general. Certainly the distinction between a beta and a final release doesn't show up as significant in threads, though of course it's quite significant from the project's point of view.
emacs on xul
In all seriousness though I have a hard time imagining why anyone would want this ... both from a developer standpoint and a user standpoint. The recent change history is a bunch of "most of ABC other Mozilla product's code has been pulled in for X.Y.Z version, go read those notes to see what is new" and describes cherry-picking bugfixes from arbitrary versions of Firefox (60, 72, ...?)
Sounds like an absolute maintenance nightmare (or perhaps a labor of masochistic love, depending on how you look at it) of constantly cherry picking other upstream stuff into one single app for what looks like a relatively small gain. If you had no choice (ie, what linux distribution maintainers spend a lot of time on) sure, go for it, but I can use Firefox, Thunderbird, etc... as standalone apps and still have them connected using my local OS and regular old open web technologies.