477845 - Build a standalone Composer

Status: RESOLVED WONTFIX

(Composer Graveyard :: Build Config, enhancement)

Description

[Serge Gautherie (:sgautherie)]

Kaze, as you wrote iirc today,
you suggest the first step toward bug 477840 to be this bug.

You currently build KompoZer on top of a (modified) Gecko 1.8.1 (from cvs).

Is it (still) possible to build a standalone Composer from (Hg) comm-central ?
If not, we would need to find out which minimal patch would allow to achieve this ?

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

hey guys, don't tell me both of you know nothing about BlueGriffon...

Comment 2

[Robert Kaiser]

(In reply to comment #1)
> hey guys, don't tell me both of you know nothing about BlueGriffon...

Are there any plans to make the BlueGriffon codebase work with SeaMonkey? If not, then we can safely ignore it for now.

What the project here is about is basically to make a SeaMonkey Composer standalone app, possibly rebranded, i.e. one which shares as much UI and core as possible with SeaMonkey, so both can profit from current developments in both that UI and the core.

Comment 3

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #2)

> What the project here is about is basically to make a SeaMonkey Composer
> standalone app, possibly rebranded, i.e. one which shares as much UI and core
> as possible with SeaMonkey, so both can profit from current developments in
> both that UI and the core.

I don't understand what is a 'standalone Seamonkey' composer. Standalone means
isolated app ; Seamonkey means a set of apps bundled in the same executable.
You cannot have both at the same time, can you?

Do you want to make (a) Semonkey composer evolve along thr Kompozer path (b)
extract it from the Seamonley suite (c) make a standalone app out of it sharing
code with Semonkey ?

If that's what you want, I don't recommend it. I can predict you a rather
fast divergence between the two codebases. As I see it, a standalone gecko-based
web editor has to be a totally independant xulrunner-app. It's the only way
we can remain rather independant from the evolutions of Firefox or Seamonkey.
And we _must_ remain independant because we don't have enough time or money
to give to the evolutions of such a standalone tool at this time. So we will
be unable to follow FF or SM.

BlueGriffon is a xulrunner-based app. It's based off the trunk. The only code
addition to the core right now is the ftp stack, that dougt r+ recently. Should
end up in the trunk. I still contains a few bits from Nvu, like helper functions
that you just cannot rewrite in another way, but the very vast majority of the
code is totally new. The mac os x build will look MUCH better than Nvu on mac
because mac is now my primary platform.

Despite of he recent additions to Kompozer - very nice job Fabien, congrats ! -
Kompozer as it is is a dead end. Extensions to the "core editor tool" will be
reusable, modulo a minor changes, in any gecko-based editor, of course.
But I don't really understand why you want here a SM-based standalone editor
while BlueGriffon, tri-licensed MPL+GPL+LGPL is already on track as a pure
xulrunner client.

Comment 4

[Zibi Braniecki [:zbraniecki][:gandalf]]

daniel: I presume Kairo was asking if in predictable future it will be possible to get Seamonkey composer benefit from BlueGriffon development.

Having ability to launch it as a standalone is a minor thing. But Seamonkey is and will be using *some* composer. For now it's the composer code that exists in the editor/ at hg.mozilla.org and frankly I don't expect it to change anytime soon.

Comment 5

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> Is it (still) possible to build a standalone Composer from (Hg) comm-central ?

Iirc, last time I checked it looked like it's probably not possible, though there were "remnants" of this option.

> If not, we would need to find out which minimal patch would allow to achieve
> this ?

In order to figure out how to restore the previous option,
the SeaMonkey team probably needs to try and build KompoZer from
http://kompozer.sourceforge.net/dev/
and see what the c-c build config (may) currently lacks.

Fabien, hints from your team would help, if you have some...

Comment 6

[Fabien Cazenave [:kaze]]

(In reply to comment #5)
> In order to figure out how to restore the previous option,
> the SeaMonkey team probably needs to try and build KompoZer from
> http://kompozer.sourceforge.net/dev/
> and see what the c-c build config (may) currently lacks.
> 
> Fabien, hints from your team would help, if you have some...

Serge, I'm not sure building KompoZer from its current SVN repo would help much. In KompoZer 0.8, a lot of code from mozilla/editor/ui has been duplicated in mozilla/composer/ (this is inherited from Nvu), and that's precisely what we should avoid if we want to join our efforts, imho. Besides, KompoZer 0.8 still relies on Gecko 1.8.1. :-/

I think Robert has already quite a sharp idea of where we'd need some #ifdef to build a standalone SeaMonkey Composer - to be confirmed during tomorrow's SeaMonkey meeting.

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> I think Robert has already quite a sharp idea of where we'd need some #ifdef to
> build a standalone SeaMonkey Composer - to be confirmed during tomorrow's
> SeaMonkey meeting.

KaiRo confirmed he would work on this.

Comment 8

[Robert Kaiser]

A short update on where we currently are with this:
1) Fabien will file a bug to get hg access
2) We will create a clone of comm-central on either his or my personal hg space as a playground to use for getting things going there.
3) I will try to get the build system parts going, Fabien will look into the chrome part. The plan is to build KompoZer with --enable-application=editor (or composer if editor grows too complicated) from comm-central.
4) Once we have a first stage working on that clone repo, we'll get changes reviewed and either merge back or do patches to land on comm-central.
5) From there (i.e. when this bug is fixed) we'll continue development to get that KompoZer up to the features it should have, etc. - this will fully happen in followups.

Comment 9

[Fabien Cazenave [:kaze]]

Attachment: patch v0.2

Comment 10

[Fabien Cazenave [:kaze]]

Here's a patch proposal. This patch creates a /composer directory and allows to build a standalone Composer with --enable-application=composer.

I don't consider this patch as finished yet:
*) the installers won't work (they're a copy of SeaMonkey's installer files), I'd appreciate some help on this;
*) the "Preferences" window works okay but should be replaced by a Thunderbird-like one;
*) the "Validate" window has been disabled because there's no built-in browser to fire any more: I'll have to design a new window to call the validation service.

However, the Composer builds fine and the changes in /editor and /suite are minimal (check the #ifdef MOZ_STANDALONE_COMPOSER): there shouldn't be any impact on other comm-central applications.

Comment 11

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)

> I don't consider this patch as finished yet:

(You can just attach follow-up patch, in follow-up bugs if need be.)

> *) the installers won't work (they're a copy of SeaMonkey's installer files),
> I'd appreciate some help on this;

I would suggest to leave this out for another bug:
*It's not useful to check in SM-specific code to replace it with KZ code soon.
*You/We will most probably want a bug 521523 (-like) setup.

> However, the Composer builds fine

That's great :-)

Comment 12

[Fabien Cazenave [:kaze]]

(In reply to comment #11)
> (In reply to comment #10)
> I would suggest to leave this out for another bug:
> *It's not useful to check in SM-specific code to replace it with KZ code soon.
> *You/We will most probably want a bug 521523 (-like) setup.

If that helps this bug to land sooner, I'll remove the installers and finish the work on the "Preferences" and "Validate" windows ASAP.

Comment 13

[Serge Gautherie (:sgautherie)]

Comment on attachment 424017 [details] [diff] [review]
patch v0.2

r? for repo layout and ifdef vars choice (only).

Comment 14

[Robert Kaiser]

Comment on attachment 424017 [details] [diff] [review]
patch v0.2

Clearing out review request, it doesn't make sense coming from Serge and at this stage.

1) A review request should always and only come from the developer that is planning to fix all review comments

2) There needs to be a clear patch of where this is to land if it's reviewed.

Both are not in place here yet. We need much more than just my OK for landing anything like this on comm-central, we need at least an approval from the Thunderbird side of the world as well, probably from dmose.
Also, we need a plan of how regular builds are being done, and we need things to be tested.
And we need a clear plan of what patches are needed in which order to get things working as planned.

Also, in this case, I really would like to see where KompoZer is in being an official Mozilla project, as usually only official projects land in the core repositories.

IMHO, we are in a too early stage and have too many question marks to actually review anything in reasonable manner here. Also, when the request comes, I want it to come from Fabien, as I expect he will be the other fixing any review nits.
It's good to have the work in progress public and for everyone to try and comment on, though.

Comment 15

[Serge Gautherie (:sgautherie)]

(In reply to comment #14)

> 1) A review request should always and only come from the developer that is
> planning to fix all review comments

Eh, it's the first patch from Fabien and my purpose was to show him how to actually proceed!
I obviously don't mean to touch his patch.

> 2) There needs to be a clear patch of where this is to land if it's reviewed.

Why? I was not intending to land this very patch anywhere:
my request is to confirm what I understood was agreed by mail, so Fabien knows "officially" he has a good base to continue his work.

> we need at least an approval from the
> Thunderbird side of the world as well, probably from dmose.

No problem: making sure we agree on the SeaMonkey team just felt the right first step before asking the Thunderbird team...

> Also, we need a plan of how regular builds are being done, and we need things
> to be tested.

Well, it would seem we (= c-c current users) only care about the shared part in the short term.
The KompoZer part will be kaze's in the first place and can happen later than right now.

> And we need a clear plan of what patches are needed in which order to get
> things working as planned.

My proposed plan with what was said in this bug:
1- review layout and vars.
2- review code (at least the shared part, I assume the KompoZer part is mostly left to its own team.)
3- do the installer part in a separate bug (that's KompoZer only!).
4- fix additional KompoZer issues in a separate bug (that's KompoZer only!).

In another, a lighter patch than the current one should be enough to resolve this very bug.

> Also, in this case, I really would like to see where KompoZer is in being an
> official Mozilla project, as usually only official projects land in the core
> repositories.

I can agree with that!
That's why Callek set up a user repo in the meantime.
And even if this doesn't land in Callek's repo yet, Fabien can just work on its own repo.

> IMHO, we are in a too early stage and have too many question marks to actually
> review anything in reasonable manner here.

My request is exactly to answer one of these question marks, no more no less...

> It's good to have the work in progress public and for everyone to try and
> comment on, though.

That's exactly was I asked you for: a comment about a specific aspect of this patch (which you can +/-/clear as you prefer)!

Comment 16

[Robert Kaiser]

(In reply to comment #15)
> My proposed plan with what was said in this bug:

Please let me as the c-c build system owner, dmose as probably the main Thunderbird c-c module peer, and kaze as the KopoZer owner work out a plan, please. There are many things to work out right now, we need firm plans in a few directions with this, and review or official landing on c-c is a good way down in those lists - once we even have them - I'm sure.
Let's not rush this all. I know kaze has some need to have real things up for FOSDEM, and as I said I fully appreciate having WIP up here in the bug, but I don't see us being ready for reviewing or landing in c-c yet. Prototyping/incubating in a user or incubator repo is a different thing, and I'm fine with that, but we are not yet ready for more than this.
And I for myself won't be in a state to even try, let enough review, any of those patches before next week, probably even FOSDEM.

Comment 17

[Fabien Cazenave [:kaze]]

Attachment: mozconfig

Comment 18

[Fabien Cazenave [:kaze]]

Here's the .mozconfig I've used to build the standalone Composer on my GNU/Linux box (Ubuntu 8.04).

The --disable-necko-wifi line shouldn't be required: I've added it only because I couldn't get the corresponding dev packages on the official Ubuntu repos.

The --disable-mailnews line might be required at the moment. I'll check that, and I'll modify the patch if needed so the standalone Composer can be built with a single --enable-application=composer line.

Comment 19

[Fabien Cazenave [:kaze]]

Attachment: patch v0.3

Here's a new version of the patch. It builds fine on Linux and MacOSX (gcc-4.2) with a simple .mozconfig file:

  mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../standaloneComposer
  ac_add_options --enable-application=composer

Warning, I still haven't tested it on Windows.

Comment 20

[Stefan [:stefanh]]

With Fabiens mozconfig in attachment #424102 [details] and the latest patch, I now get a complete build af a standalone composer (Mac OS 10.5.8) :-)

There are a couple of things that hits me, though:

It seems that there sometimes are some problems with loading one of the xpcom components - get this in the error console:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: file:///Users/Stefan/objdir-composer/mozilla/dist/KompoZer.app/Contents/MacOS/components/nsSuiteGlue.js :: <TOP_LEVEL> :: line 45"  data: no]

Failed to load XPCOM component: /Users/Stefan/objdir-composer/mozilla/dist/KompoZer.app/Contents/MacOS/components/nsSuiteGlue.js

I also don't get the application icon, but that should just be a missing icon path somewhere.

I tried to produce a debug build, but it hangs on startup for some reason.

Comment 21

[Stefan [:stefanh]]

(In reply to comment #20)

> I also don't get the application icon, but that should just be a missing icon
> path somewhere.

Forget about this, it works fine.

Comment 22

[Serge Gautherie (:sgautherie)]

I submitted the patch to Try as SeaMonkey:
Linux and MacOSX: passed; Windows: N/A (Try has a bug...).

I submitted the patch to Try as KompoZer ... but made a mistake that seems to have "hang" Try :-/
I'll try again when the various Try (itself) issues are fixed :-|

***

I tried the patch on my local Windows:
{
make[5]: Entering directory `objdir/composer/branding'
make[5]: *** No rule to make target `icons/windows/editorWindow.ico', needed by `libs'.  Stop.
}

Fwiw,
{
http://mxr.mozilla.org/comm-central/search?string=editorWindow.ico&case=1&find=%2Fsuite%2Finstaller%2Fwindows%2Fpackages
/suite/installer/windows/packages
    * line 397 -- bin\chrome\icons\default\editorWindow.ico
}

It's not obvious to me why/how this is happening, but I'll just retry with '--disable-installer' for now...

Comment 23

[Serge Gautherie (:sgautherie)]

(In reply to comment #22)
> It's not obvious to me why/how this is happening

Found it, patch has:
{
+DESKTOP_ICONS = \
+	editorWindow \
+	$(NULL) 
+
+ifeq (windows,$(MOZ_WIDGET_TOOLKIT))
+# Windows icons
+DESKTOP_ICONS += \
+	kompozer \
+	$(NULL)
+endif
}
but contains 'icons/windows/kompozer.ico' only.

Comment 24

[Serge Gautherie (:sgautherie)]

(In reply to comment #20)
> It seems that there sometimes are some problems with loading one of the xpcom
> components - get this in the error console:
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]" 
> nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame ::
> file:///Users/Stefan/objdir-composer/mozilla/dist/KompoZer.app/Contents/MacOS/components/nsSuiteGlue.js
> :: <TOP_LEVEL> :: line 45"  data: no]
> 
> Failed to load XPCOM component:
> /Users/Stefan/objdir-composer/mozilla/dist/KompoZer.app/Contents/MacOS/components/nsSuiteGlue.js

I assume these are not related to KompoZer:
I have noticed them on SeaMonkey 'Linux comm-central-trunk debug test mochitest-other' too.
(NB: Filing/Fixing this build is "work in progress".)

Comment 25

[Fabien Cazenave [:kaze]]

Attachment: patch v0.4.1

Updated to the latest comm-central code. Still a few rough edges to fix.

Comment 26

[Fabien Cazenave [:kaze]]

Attachment: patch v0.5

updated to the latest comm-central trunk (SM 2.3).

The Windows build is fixed. I get an error for debug builds on Linux (autocomplete…), I have to work on this.

Comment 27

[Fabien Cazenave [:kaze]]

ooops: SM 2.5a1, not 2.3 (Gecko 8).

Comment 28

[Fabien Cazenave [:kaze]]

Attachment: debug build -- error

Here’s the error I get when trying to make a debug version with --enable-tests.
Help would be very appreciated, as my skills concerning the build system are very limited…

Comment 29

[Fabien Cazenave [:kaze]]

Attachment: patch v0.5.1

Now supports debug builds if tests are disabled (--disable-tests).

Comment 30

[Stefan [:stefanh]]

Comment on attachment 553162 [details] [diff] [review]
patch v0.5.1

Drive-by comment:
+pref("browser.hiddenWindowChromeURL",            "chrome://editor/content/hiddenWindow.xul");

It doesn't looks like you provide this file. Did you forget to hg add it?

Comment 31

[Sylvestre Ledru [:Sylvestre]]

Composer isn't maintained anymore. Closing these bugs (no activity for a while)