313822 - Make Lightning work on SeaMonkey

Status: VERIFIED FIXED

(Calendar :: Lightning: SeaMonkey Integration, enhancement)

Description

[Ian Neal]

It would be nice to get lightning working on trunk SeaMonkey builds.

Comment 1

[Ian Neal]

Attachment: Provisional Patch v0.1

This patch:
* Makes relevant changes to jar.mn/Makefile.in/contents.rdf files
* Adds extra contents.rdf files for SeaMonkey
* Adds preference overlay and preference files for SeaMonkey
* Adds dtd files for SeaMonkey preference files

PNG files for lightning/themes/classic were just copied from lightning/themes/winstripe
PNG files for lightning/themes/modern were just copied from lightning/themes/pinstripe

I don't think I have missed any other files but if I have, just shout.

To test on SeaMonkey need to checkout calendar project (add calendar to MOZ_CO_PROJECT line) and add the following option to the moz.config
ac_add_options --enable-extensions=default,lightning

Comment 2

[Michiel van Leeuwen (email: mvl+moz@)]

At this stage of lighting development, i think this is a bad idea. It duplicates code, creates more work etc. It will just lead to one of the versions always lagging behind and not working properly.
Let's wait until lighting gets more stable.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

I agree with mvl that accepting this patch as it stands could be problematic and create confusion.  In particular, I see two problems: one is that there's a whole bunch of #ifdef MOZ_XUL_APP glop added, and two is that there would be a whole bunch of files scattered throughout the lightning tree that would only be used for SeaMonkey installs.

Suppose, however, that Lightning supported suite as "tier-2/3" platform, similar to the way that non big-three platforms are supported in the codebase.  This would mean that design would not be done specifically with suite Lighting in mind, and check-ins might well break the suite build of Lightning, and it would not be the core Lightning team's responsibility to fix the SeaMonkey build if this were to happen (though we'd be expected to be responsive to questions from folks who were trying to fix the SeaMonkey support).

As part of this, that Lightning could have a "suite" directory, which contained all the theme, CSS, RDF, and manifest files that were specific to SeaMonkey. Additionally, there could be a README that explained the tiering system, and that someone from SeaMonkey would be responsible for maintaining (or not) the code in that directory.  This would avoid the ifdef nastiness and would also make it clear to developers exactly which files were for what, as well as what sort of maintainence was expected with regard to those files.

Note, however, that I expect Lightning will obtain some toolkit dependencies in fairly short order, and I don't think it makes sense to do much xpfe special-casing in the Lightning core code.  So until suite moves to toolkit, perhaps this is moot.

And, as mvl points out, this would mean that SeaMonkey would lag behind a bit, but no differently than the way it lags behind Firefox or the way lower-tier OS platforms lag behind the big three today.  Indeed, if it turns out that the whoever signs up to be the maintainer of the suite/ subdir ends up being short on time, suite-Lightning could indeed stay broken for some period of time.  Giving suite-Lightning's success this sort of independence from core-Lighting would be ok with me however.

Thoughts?

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 200819 [details] [diff] [review]
Provisional Patch v0.1

Minused in it's current form; probably worth waiting until we have some more discussion in this bug before consing up a new iteration.

Comment 5

[Robert Kaiser]

Lightning would be a very good addition to suite, as long as the lightning/suite integration is well maintained... I hope IanN might take over that part...
As the branches don't have well-working calendar implementations anyways, I think we have enough time on trunk to figure out a way how to deal with that in the future.

Comment 6

[Jesse Molina]

Please support Seamonkey.

Comment 7

[Mark Banner (:standard8)]

Attachment: Makes lightning loadable into suiterunner

This patch adds SeaMonkey to install.rdf. This will allow the building of lightning alongside suiterunner (the in-work XUL version of SeaMonkey).

It should be noted that both suiterunner itself, and lightning integration with suitrunner are highly untested and as such not supported. The patch is intended for developer use only at this stage.

Comment 8

[Robert Kaiser]

Attachment: make it possible for lightning install itself into suiterunner at build time (checked in)

I extended Mark's patch with an added section that makes lightning install itself into suiterunner when built in the same build process. Making this |ifdef MOZ_SUITE| is just a precaution and may not be right, as this should probably be possible for Thunderbird as well.
With this patch, a suiterunner build with |--enable-extensions=default,lightning| lists lightning in Add-Ons and makes it show up in mailnews.
Apart from the ifdef stuff, I believe it's fairly safe to get this patch into trunk. Even if suiterunner is not the default build yet, lightning isn't among the default extensions anyways but it may be good if we are able to give this constellation more testing easily.

Comment 9

[Michiel van Leeuwen (email: mvl+moz@)]

With the patch, does lightning actually work?

Comment 10

[Mark Banner (:standard8)]

(In reply to comment #9)
> With the patch, does lightning actually work?
> 
I installed it the other day (having used the previous patch) and the basic calendar display came up without problems. I haven't used it much since then, but I'll start giving it a hammering when I get back off holiday.

Comment 11

[Robert Kaiser]

"work" is said too much, I think.
It shows up in mailnews sidebar (can give you a screen shot of that if wanted), it lets you view those different tabs it has there, you cn click on different days in the calendar, but it looks like tht's pretty much it.

What's important from my point of view is that it shows up some way, it doesn't break anything, it's visible in the Add-Ons window and it's not in SeaMonkey default builds, but very easy to add and test so we can work on getting it to do what it's supposed to do. I haven't seen it in Thunderbird, so I don't know what's still missing (yet), but it's the first step on getting somewhere - and probably an important step to get developers to build it and make it really work.

Comment 12

[Mark Banner (:standard8)]

(In reply to comment #11)
> "work" is said too much, I think.
> It shows up in mailnews sidebar (can give you a screen shot of that if wanted),
> it lets you view those different tabs it has there, you cn click on different
> days in the calendar, but it looks like tht's pretty much it.

The problem is <menubar id="mail-menubar"> (messenger-overlay-toolbar.xul#97) isn't defined on SeaMonkey, but we should probably separate that into a different bug that blocks this one.

Comment 13

[Robert Kaiser]

Comment on attachment 238561 [details] [diff] [review]
make it possible for lightning install itself into suiterunner at build time (checked in)

OK, with the patch in bug 367239 applied (which is suite-only and should go in soon) this patch here makes lightning really work in suiterunner.
I get the calendar sidebar, the calendar menu and can call up calendar views, create events, etc.

If there are still details left that don't work perfectly yet, I think we should handle those in other bugs.

BTW, I think you might even want to extend the Makefile changes to including TB one day, so you can do a TB build with --enable-extensions=default,lightning and have lightning already installed (globally) when launching up the thunderbird build :)

Comment 14

[Robert Kaiser]

Ian, I think the theming and/or special integration (where needed) items are probably worth a separate bug, I don't want to take over that part actually.

The "make lightning work" part just needs the build changes though, as *stripe is "classic" theming anyways (and suiterunner's default theme is based on *stripe as well).

"make lightning fit into modern theme" and other special suite integration (if needed at all) should be separate steps, IMHO (even though your patch above is probably a good base for that).

Comment 15

[Worcester12345]

(In reply to comment #13)
...
> BTW, I think you might even want to extend the Makefile changes to including TB
> one day, so you can do a TB build with --enable-extensions=default,lightning
> and have lightning already installed (globally) when launching up the
> thunderbird build :)

See Bug 349870 – build/run/integrate Lightning on top of Thunderbird

Comment 16

[Robert Kaiser]

mvl, any chance to get a review on this patch?
With it, Lightning actually works fine in trunk SeaMonkey if one builds with --enable-extensions=default,lightning. Pref panels aren't shown anywhere, but else it seems to be working nicely.

Comment 17

[Simon Paquet [:sipaq]]

Since SeaMonkey support is possible only on the trunk and 0.7 is developed mainly on the 1.8 branch, this does not block 0.7.

Comment 18

[Worcester12345]

(In reply to comment #17)
> Since SeaMonkey support is possible only on the trunk and 0.7 is developed
> mainly on the 1.8 branch, this does not block 0.7.
> 

Then there should be a blocking flag for the next version.

Comment 19

[Simon Paquet [:sipaq]]

Comment on attachment 238561 [details] [diff] [review]
make it possible for lightning install itself into suiterunner at build time (checked in)

Daniel, since mvl dropped the review on this one, this one will get to you.

We'd probably have to discuss, how we'd handle bugs from SeaMonkey users, as SeaMonkey support is only possible on the trunk at the moment (and our focus is on the 1.8 branch) and we do not officially support SeaMonkey yet (due to lack of resources).

Comment 20

[Daniel Boelzle [:dbo]]

(In reply to comment #19)
> We'd probably have to discuss, how we'd handle bugs from SeaMonkey users, as
> SeaMonkey support is only possible on the trunk at the moment (and our focus is
> on the 1.8 branch) and we do not officially support SeaMonkey yet (due to lack
> of resources).

Yes, we should make clear that lightning on trunk is experimental, might break, is generally *unsupported*. However, it makes sense to get the taste of it on SeaMonkey. The patch looks ok, but IMO we shouldn't allow BRANCH builds being installable, i.e

#ifndef MOZILLA_1_8_BRANCH
+    <em:targetApplication>
+      <Description>
+        <!-- seamonkey -->
+        <em:id>{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}</em:id>
+        <em:minVersion>@SEAMONKEY_VERSION@</em:minVersion>
+        <em:maxVersion>@SEAMONKEY_VERSION@</em:maxVersion>
+      </Description>
+    </em:targetApplication>
#endif

Comment 21

[Michiel van Leeuwen (email: mvl+moz@)]

> Yes, we should make clear that lightning on trunk is experimental, might break,
> is generally *unsupported*. However, it makes sense to get the taste of it on
> SeaMonkey.
And we should make it absolutely clear that lightning on seamonkey is even less supported. Problem is: how are you going to do that? Users will not read a note on a webpage. They will file bugs anyway. How are you going to prevent that?

Comment 22

[Simon Paquet [:sipaq]]

(In reply to comment #21)
> And we should make it absolutely clear that lightning on seamonkey is even 
> less supported. Problem is: how are you going to do that? Users will not read 
> a note on a webpage. They will file bugs anyway. How are you going to prevent 
> that?

You can't prevent the filing of bugs, of course, but I don't consider that to be a real problem. The problem is people working on those bugs (fixing, triaging, QA, etc.). And you can prevent people doing that.

So unless anyone important disagrees, no official mention of the inofficial support will be made on the project website, until we decide to officially support Lightning on SeaMonkey.

Second, I will mark all Lightning on SeaMonkey bugs as INVALID unless the reporter can also reproduce these bugs in Lightning on Thunderbird. And I will advise other triagers (ssitter, mschroeder, damian, etc.) to do the same.

Comment 23

[Stefan Sitter [:ssitter]]

It's also possible to change the install.rdf for the release builds as done for Firefox. Nightly builds install in Firefox for testing purpose but for the official release builds this is removed and only Thunderbird is supported.

Comment 24

[Mark Banner (:standard8)]

(In reply to comment #22)
> Second, I will mark all Lightning on SeaMonkey bugs as INVALID unless the
> reporter can also reproduce these bugs in Lightning on Thunderbird. And I will
> advise other triagers (ssitter, mschroeder, damian, etc.) to do the same.

Rather than just blindly marking them invalid, how about INCOMPLETE (i.e. need more info) and also maybe creation of a component somewhere for Lightning on SeaMonkey integration bugs?

Comment 25

[Robert Kaiser]

A separate component for SeaMonkey-Lightning integration would seem to be the cleanest solution for me, including in the description that it is unofficial and unsupported.
Also, as you're apparently editing install.rdf for releases anyways to remove Firefox, removing SeaMonkey for those as well seems to be a good idea.

And in current trunk builds, the integration itself does not work as expected, probably due to the changed way of integration into Thunderbird UI. I hope we'll find someone from the SeaMonkey side to look into that, but most of our regular devs are busy with other things atm. We really want to be abe to use Lightning though, so we'll find a way :)

Comment 26

[Daniel Boelzle [:dbo]]

(In reply to comment #25)
> A separate component for SeaMonkey-Lightning integration would seem to be the
> cleanest solution for me, including in the description that it is unofficial
> and unsupported.
Yes, makes managing those bugs easier; how about "Lightning/Seamonkey Only"?
Users need to cross-verify bugs on Thunderbird/Lightning; we could mark those INCOMPLETE for the time being.

> And in current trunk builds, the integration itself does not work as expected,
> probably due to the changed way of integration into Thunderbird UI. I hope
> we'll find someone from the SeaMonkey side to look into that, but most of our
> regular devs are busy with other things atm. We really want to be abe to use
> Lightning though, so we'll find a way :)
I think that's my foremost concern: We currently have hardly enough resources to keep care of both Sunbird and Lightning (both focussed/released from BRANCH!); so I'd greatly appreciate if somebody from the Seamonkey team could have a look and propose patches to make lightning work on Seamonkey(TRUNK).

Comment 27

[Daniel Boelzle [:dbo]]

Comment on attachment 238561 [details] [diff] [review]
make it possible for lightning install itself into suiterunner at build time (checked in)

r=dbo with comment #20 resolved (ifndef MOZILLA_1_8_BRANCH?)

Comment 28

[Robert Kaiser]

Please don't add this keyword randomly to bugs. I have CVS access myself, I don't need or want anyone else to check in my patches.

Comment 29

[Robert Kaiser]

Comment on attachment 238561 [details] [diff] [review]
make it possible for lightning install itself into suiterunner at build time (checked in)

OK, this first step has been checked in, further work needs to be done to make the UI integration work (again), I'm trying to get someone to look into this.

Comment 30

[Philip Chee]

worcester12345: The Sunbird/Lightning devs have already stated that this bug isn't on their priority list.

Comment 31

[Simon Paquet [:sipaq]]

Since we will release 0.8 (and 0.9 and 1.0) from the MOZILLA_1_8_BRANCH, there is absolutely *no possibility* that we will support SeaMonkey as the SeaMonkey is still XPFE-based on the branch.

Once we move to the trunk (or the MOZILLA_1_9_BRANCH which is probably live by then) things *may* look different.

Comment 32

[Robert Kaiser]

Attachment: adjust SeaMonkey MailNews toolbox and message menu so Lightning can hook into IDs

This patch adds an ID to the Message menu in SeaMonkey MailNews and changes the ID of the toolbox there to match what Thunderbird uses, so Lightning can hook into those. I'll take ui-review as sr here ;-)

Comment 33

[Robert Kaiser]

Attachment: adjust getMailBar() to recognize the SeaMonkey toolbar

And here's another patch: getMailBar() gets adjusted so it recognizes the SeaMonkey MailNews toolbar.

Note that I'm not planning to go all the way fixing this bug, at least not at this moment, I just stumbled over some errors I could still figure out - the remaining obvious problems are harder to figure out for me.

With those two changes, we can already switch to a calendar pane in SeaMonkey though, so they go some of the way at least :)

Comment 34

[Michael Büttner (no reviews TFN)]

Comment on attachment 298009 [details] [diff] [review]
adjust getMailBar() to recognize the SeaMonkey toolbar

r=mickey

Comment 35

[Simon Paquet [:sipaq]]

Robert, I see two issues with your patch:

1. The comment above the section that you're changing is wrong now. It talks 
   about TB 1.x vs. TB 2.x while it should instead talk of TB vs. SM. I would 
   appreciate it, if you could fix this as well.
2. You checked in the patch in attachment 298009 [details] [diff] [review] only on the trunk. 
   mozilla/calendar is under a strict cross-commit policy between trunk and the 
   MOZILLA_1_8_BRANCH. So please commit this change on the branch as well.

Comment 36

[Robert Kaiser]

Simon, thanks, I fixed both of those comments.

Comment 37

[Worcester12345]

(In reply to comment #35)
> Robert, I see two issues with your patch:

> 2. You checked in the patch in attachment 298009 [details] [diff] [review] only on the trunk. 
>    mozilla/calendar is under a strict cross-commit policy between trunk and the 
>    MOZILLA_1_8_BRANCH. So please commit this change on the branch as well.

I think this was based on: 

(In reply to comment #0)
> It would be nice to get lightning working on trunk SeaMonkey builds.

So, does fixing this bug actually make Lightning work on "nightly" "trunk" builds, or not? I filed Bug 414227 – Make Lightning work in Seamonkey trunk as a followup to this one. If the answer to this question was yes, then bug 414227 can just be duped to this one. Thanks.

Comment 39

[Robert Kaiser]

Comment on attachment 298007 [details] [diff] [review]
adjust SeaMonkey MailNews toolbox and message menu so Lightning can hook into IDs

Checked in this patch.

Comment 41

[Worcester12345]

Is this working yet? Can anyone verify as fixed?

Comment 42

[Philip Chee]

> Is this working yet?
No
> Can anyone verify as fixed?
No.

Basically someone needs to volunteer to work on this bug. Until then please avoid adding "are we there yet? are we there yet?" comments to this bug. Thank you.

Comment 44

[Worcester12345]

(In reply to comment #6)
> Please support Seamonkey.

(In reply to comment #14)
> Ian, I think the theming and/or special integration (where needed) items are
> probably worth a separate bug, I don't want to take over that part actually.

(In reply to comment #24)
> (In reply to comment #22)
...
> more info) and also maybe creation of a component somewhere for Lightning on
> SeaMonkey integration bugs?

(In reply to comment #25)
> A separate component for SeaMonkey-Lightning integration would seem to be the
> cleanest solution for me, including in the description that it is unofficial
> and unsupported.
> Also, as you're apparently editing install.rdf for releases anyways to remove
> Firefox, removing SeaMonkey for those as well seems to be a good idea.
> 
> And in current trunk builds, the integration itself does not work as expected,
> probably due to the changed way of integration into Thunderbird UI. I hope
> we'll find someone from the SeaMonkey side to look into that, but most of our
> regular devs are busy with other things atm. We really want to be able to use
> Lightning though, so we'll find a way :)

Based on the progress here, and since there isn't one currently, I submitted the SeaMonkey version of  Bug 401779 -  Ship Thunderbird with integrated Lightning on as default:

Bug 516026 -  Ship SeaMonkey with integrated Lightning on as default

This new bug is to be the placeholder for those future requests for this functionality, and people can be redirected there as to the progress.

Comment 45

[Robert Kaiser]

(In reply to comment #44)
> Bug 516026 -  Ship SeaMonkey with integrated Lightning on as default
> 
> This new bug is to be the placeholder for those future requests for this
> functionality, and people can be redirected there as to the progress.

No. there will not be a *progress* on bug 516026, that one is just a very small last step. The progress is to happen here in the SeaMonkey integration component, and there was actually very recent progress here by bug 460960 being resolved, which make Lightning mostly work on SeaMonkey 2.0b2 and higher.

Some small glitches are still there, so I'm not marking this tracking bug here as fixed, but it's very near right now, and Lightning nightlies can just be installed and used, the main glitches right now it that invitations don't work and preferences not being available, but the calendaring itself just works.

Comment 46

[Worcester12345]

You are correct, and I didn't mean that one to steal the thunder from your work on lightning. That is indeed the final icing on the cake bug, to which possibly others can be marked as blocking. Thanks for the clarification.

Comment 47

[Worcester12345]

Should 527065 block this bug?

Comment 48

[Robert Kaiser]

Worcester12345:
bug 527065 is fixed anyhow, so it doesn't matter - and then, build machines don't change if the Lightning code works on SeaMonkey, which is what this bug is about.

Actually, I'm inclined to mark this bug FIXED now that the current nightlies and upcoming beta of Lightning work with SeaMonkey 2.0.x

Ian, what do you think?

Comment 49

[Ian Neal]

Yes, can be resolved as fixed, as the blocking stuff that was in bug 509324 was done in bug 516453.

Comment 50

[Worcester12345]

Great, thank you! I'm going to go look for the latest nightly to run on the latest nightly "trunk" "Seamonkey".

Comment 51

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8pre) Gecko/20091226 Lightning/1.0b2pre SeaMonkey/2.0.2pre - Build ID: 20091226001038

Well, what is still needed to get this bug VERIFIED? I've been using Lightning in SeaMonkey (comm-1.9.1 nightlies of both) on Linux ever since Sunbird temporarily had not even one build (nightly or hourly) per 24h, and the only flaw I notice is that with several calendars it can take, oh, maybe tens of seconds before the Multiweek (or similar) view is displayed with all its events when the Calendar tab gets focus. I would say that, for me at least, Lightning "works" on SeaMonkey.

Comment 52

[Robert Kaiser]

Tony, as those are official nightlies of both, I'd think that's enough for verification.

Comment 53

[Worcester12345]

Thanks for all your hard work on this everyone. Now, onward and upward, to check the status of bug 516026