The future of Seamonkey?

[rsx11m]

wyatt8740, I am quite sure this will not work. Would need at least a ton of dependant libs which I am also quite sure are not even available on Windows. Building under Windows needs at least VS2015 Community and the Windows 10 SDK.

Well, he says he wants to build with Cygwin which would add that POSIX layer and provide GCC and X11. While they are doing a fairly good job maintaining Cygwin, like you I doubt a bit though that all necessary development packages would be available in the Cygwin repository for a successful SM build (but I've never tried that myself).

[wyatt8740]

I am fully aware I'd have to build many packages from source; that is not an issue for me.

wyatt8740, I am quite sure this will not work. Would need at least a ton of dependant libs which I am also quite sure are not even available on Windows. Building under Windows needs at least VS2015 Community and the Windows 10 SDK. Everything else is either experimental, unsupported or plain black magic. If your PC is capable install Virtualbox and CentOS 7 x64 in an vm. Then you can build for Linux.

I'm not trying to build for linux, or for regular 'win32'; I'm trying to build for cygwin.

And are you serious that in 2016 you can't do a windows build of the Mozilla suite with MinGW? That's... a little disappointing.
(Note that I am _not_ trying to build for normal native windows using WinAPI for the UI and the rest of it. I am trying to build X11 seamonkey for a cygwin unix-like environment.

I've built cross compiler toolchains and the like before, so I am pretty confident in my skills in this respect.

[frg]

>> I'm not trying to build for linux, or for regular 'win32'; I'm trying to build for cygwin.

Yes we know. Compiler, autoconf etc. are not the problem. But there are a lot of dependencies eg. gnome3 which might not be available and which you would need to compile yourself. And if something goes worng with the build you are likely on your own because no one else can reproduce it. Personally I would just stick to a stock build environment unless you have a lot of time to burn and nothing better to do.

>> And are you serious that in 2016 you can't do a windows build of the Mozilla suite with MinGW? That's... a little disappointing.

It might be possible or it might not. I would search google for Firefox build environments. If you can build FF with it you can likely build Seamonkey too.

FRG

[rsx11m]

gnome3 which might not be available and which you would need to compile yourself.

Nah, GTK3 is supported by the current Cygwin distribution. https://cygwin.com/cgi-bin2/package-grep.cgi lets you search for specific packages. Also, glib2 and pango are around, so it looks promising, though I would expect a bit of a performance drop relative to native Windows builds (but again, I didn't try it).

It might be possible or it might not. I would search google for Firefox build environments. If you can build FF with it you can likely build Seamonkey too.

I'm not sure if it makes any difference, going directly with a SM build would prompt you for the same libraries if they aren't present.

[wyatt8740]

Nah, GTK3 is supported by the current Cygwin distribution. https://cygwin.com/cgi-bin2/package-grep.cgi lets you search for specific packages. Also, glib2 and pango are around, so it looks promising, though I would expect a bit of a performance drop relative to native Windows builds (but again, I didn't try it).

Yeah, there probably would be some performance drop (especially if unix mozilla uses fork(), which is painfully slow on cygwin), but I mainly just want to see if I can do it. :)

I remember having a lot of problems trying to do a X11 build for OSX a few years ago, but I was a lot less experienced then.

[LuvKomputrs]

Know I've asked this question before....any ETA on the stable release for SeaMonkey 2.45?
Still have 2.40 stable release on my computer which has Windows 7.
Got SeaMonkey 2.45 on a USB stick to try it out until the stable release is released.
Other than the search engine bug...SeaMonkey 2.45 is working very nicely for me.

[tonymec]

Know I've asked this question before....any ETA on the stable release for SeaMonkey 2.45?
Still have 2.40 stable release on my computer which has Windows 7.
Got SeaMonkey 2.45 on a USB stick to try it out until the stable release is released.
Other than the search engine bug...SeaMonkey 2.45 is working very nicely for me.

AFAIK, the 2.45 release will happen as soon as the developers, who are few in number, and none of which is paid for working on SeaMonkey, are able to build for all four platfoms (W32, L32, L64 and Mac) from a single source and free of any serious known bugs. Peferably in more languages than just en-US.

You may want to read the minutes of the fortnightly SeaMonkey Status Meetings.

In the meantime, 2.45 en-US pre-releases are available at:

• L32: http://ftp.mozilla.org/pub/seamonkey/tinderbox-builds/comm-release-linux/
• L64: http://ftp.mozilla.org/pub/seamonkey/tinderbox-builds/comm-release-linux64/
• Mac: http://ftp.mozilla.org/pub/seamonkey/tinderbox-builds/comm-release-macosx64/
• W32: http://ftp.mozilla.org/pub/seamonkey/tinderbox-builds/comm-release-trunk-win32/

In each case, select the numbered subdirectory with the highest number, after scrolling to the bottom of the page if necessary.

Notes:

• The W32 builds will also run on W64 OSes, with the help of the WOW64 subsystem which is part of the OS.
• The Mac builds are "universal binaries" containing both a 32-bit executable and a 64-bit one.

[Lemon Juice]

We've been waiting long for the release but SM 2.45 appears pretty exciting - it includes Lightning and the developer tools! As a result of the developer tools we gain better compatibility with some extensions, for example GreaseMonkey (after using the converter) has an internal script editor, which didn't work in SeaMonkey, because it was using the Scratchpad. Now that we have the Scratchpad as part of the dev tools GreaseMonkey's editor started working.

[tonymec]

We've been waiting long for the release but SM 2.45 appears pretty exciting - it includes Lightning and the developer tools! As a result of the developer tools we gain better compatibility with some extensions, for example GreaseMonkey (after using the converter) has an internal script editor, which didn't work in SeaMonkey, because it was using the Scratchpad. Now that we have the Scratchpad as part of the dev tools GreaseMonkey's editor started working.

Yes indeed. IIUC, the Developer Tools had to be included because it had become necessary for some parts of SeaMonkey itself (don't ask me which ones), and Lightning was included in the SeaMonkey distribution because Thunderbird had done it and the SeaMonkey developers thought that it was a cool idea, avoiding any future mismatches between SeaMonkey and Lightning versions (Lightning is a binary extension, remember, and it will only work with an application built on the exact same version of XPCOM).

Of course, anyone not wanting Lightning may disable it, but not remove it, in the Add-ons Manager.

[barbaz]

Of course, anyone not wanting Lightning may disable it, but not remove it, in the Add-ons Manager.

So this is different from the other default add-ons which can removed but then would get reinstalled at the next SeaMonkey update?

[Bozz]

Of course, anyone not wanting Lightning may disable it, but not remove it, in the Add-ons Manager.

So this is different from the other default add-ons which can removed but then would get reinstalled at the next SeaMonkey update?

With Thunderbird, I delete it from the Program installation folder before the first run so it's not there at all.

Is SeaMonkey any different so that it can't be deleted before the first run?

[rsx11m]

It's definitely different between trunk nightly builds and aurora/beta/release builds (Lightning is considered "external" on trunk nightlies and thus disabled by default on the first run, that's independent of the signing-requirement issue which should be solved by now). I'd think that it's the same arrangement as with Thunderbird (in particular, it's not a single XPI but a whole folder full of individual files that's coming with the installation).

[Bozz]

I'd think that it's the same arrangement as with Thunderbird (in particular, it's not a single XPI but a whole folder full of individual files that's coming with the installation).

Yep...that's how it is with Thunderbird so I should be able to remove it the same way. Yes?

[tonymec]

Of course, anyone not wanting Lightning may disable it, but not remove it, in the Add-ons Manager.

So this is different from the other default add-ons which can removed but then would get reinstalled at the next SeaMonkey update?

With Thunderbird, I delete it from the Program installation folder before the first run so it's not there at all.

Is SeaMonkey any different so that it can't be deleted before the first run?

Well, you could delete the extension's subdirectory, and all of its contents, from the extensions/ subdirectory of your application directory, but I don't recommend it, since you would have to reinstall the whole of SeaMonkey if at any future time you wanted to use Lightning. It's much easier to just disable it; and what I meant is that the Add-ons Manager provides no way to remove it, just like it doesn't have a [Remove] button on the Default and Modern themes.

This said, if you really want to uninstall Lightning, remove (for instance on Linux) /usr/local/seamonkey/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103} and all its contents while SeaMonkey is not running. Mutatis mutandis on other platforms; and not /usr/local/seamonkey/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi which is the placeholder for the default theme.

[Bozz]

Thanks tonymec. I have no need for a calendar so all is good with removing it.