Mozilla Help Viewer
Greg Marine
was wondering if the Mozilla Help Viewer will remain in XULRunner for
our third-party applications.
Thanks and God Bless <><
Greg
Axel Hecht
> I noticed Firefox 3 uses online documents for its help system now. I
> was wondering if the Mozilla Help Viewer will remain in XULRunner for
> our third-party applications.
Yes, that is to say, I haven't heard of any plans to immediately remove it.
That said, code that is untested might undergo odd changes, and I think
seamonkey is the only tester of that code right now. I might be mistaken
there, though.
Axel
Greg Marine
> Yes, that is to say, I haven't heard of any plans to immediately remove it.
>
> That said, code that is untested might undergo odd changes, and I think
> seamonkey is the only tester of that code right now. I might be mistaken
> there, though.
>
> Axel
Thank you! I know Komodo Edit from Active State uses it and I plan to
use it as well. If I notice anything odd, I'll make sure a bug is
posted and hope it will remain maintained. I mostly do not wish to
make my users be online to view the help. For a Web browser, it makes
sense to have online help because you probably wouldn't be using the
browser if you were offline. (Not to say it never happens, though)
Thanks again!
Greg
Gavin Sharp
> I noticed Firefox 3 uses online documents for its help system now. I
> was wondering if the Mozilla Help Viewer will remain in XULRunner for
> our third-party applications.
Bug 425541 was filed for its removal, though there's been no progress
as of yet. The rationale for removing it is that it would cut down on
unnecessary bloat for the majority of toolkit users that don't use it,
and it isn't something terribly burdensome for Komodo to ship itself.
Do you see things differently?
Gavin
Robert Kaiser
> On Nov 24, 4:31 pm, Axel Hecht<a...@pike.org> wrote:
>> Yes, that is to say, I haven't heard of any plans to immediately remove it.
>>
>> That said, code that is untested might undergo odd changes, and I think
>> seamonkey is the only tester of that code right now. I might be mistaken
>> there, though.
>
> use it as well. If I notice anything odd, I'll make sure a bug is
> posted and hope it will remain maintained. I mostly do not wish to
> make my users be online to view the help. For a Web browser, it makes
> sense to have online help because you probably wouldn't be using the
> browser if you were offline. (Not to say it never happens, though)
There's some serious threat of it being removed in the future, as
mentioned in another post on this thread, but for now it's part of the
platform. SeaMonkey is probably the only remaining user of it on the
Mozilla side, and we're really interested in keeping a help viewer, even
though I see good reasons for improving it further, either as part of
the toolkit or of SeaMonkey. One idea would be to get rid of the RDF
files that include localizable content, which are not that easy to get
right for localizers.
It's interesting to know that there are other users of that code, and
the SeaMonkey team would be happy to collaborate on improving it,
wherever it lives in the long term.
Robert Kaiser
Greg Marine
> There's some serious threat of it being removed in the future, as
> mentioned in another post on this thread, but for now it's part of the
> platform. SeaMonkey is probably the only remaining user of it on the
> Mozilla side, and we're really interested in keeping a help viewer, even
> though I see good reasons for improving it further, either as part of
> the toolkit or of SeaMonkey. One idea would be to get rid of the RDF
> files that include localizable content, which are not that easy to get
> right for localizers.
>
> It's interesting to know that there are other users of that code, and
> the SeaMonkey team would be happy to collaborate on improving it,
> wherever it lives in the long term.
>
> Robert Kaiser
Robert,
Are you on the SeaMonkey development team? Although it appears it
might get removed from the toolkit, I am interested in using it
myself. I've implemented my own help viewer but was planning to switch
to the Mozilla help viewer. Does it contain any platform native code
or is it simply XUL and Javascript? As of now, I do not have any
native XPCOM code to compile for each platform. I'm using XUL and
Javascript. The Mozilla Platform (XULRunner) is an amazing set of
technologies, IMHO.
Thanks,
Greg
Greg Marine
applications. What I did was I took the toolkit.jar, took out the
stuff I didn't need and left in the help viewer. Then I renamed the
jar to help.jar and set it up in my chrome.manifest. Works like a
charm!
Thanks,
Greg
Robert Kaiser
> Are you on the SeaMonkey development team? Although it appears it
> might get removed from the toolkit, I am interested in using it
> myself. I've implemented my own help viewer but was planning to switch
> to the Mozilla help viewer. Does it contain any platform native code
> or is it simply XUL and Javascript? As of now, I do not have any
> native XPCOM code to compile for each platform. I'm using XUL and
> Javascript. The Mozilla Platform (XULRunner) is an amazing set of
> technologies, IMHO.
It's just XUL+JS+CSS, the usual thing ;-)
It uses quite a bit of RDF though, and esp. the RDF files in the help
content are cumbersome to work with, it would be better to have a nicer
format instead with which localizers wouldn't have to edit this RDF stuff.
And yes, I'm on the SeaMonkey team, acting as project coordinator on the
SeaMonkey Council (the project leading committee).
Robert Kaiser
Philip Chee
If there are significant (for certain values of significant) number of
consumers of the help viewer outside of Mozilla, would it not make sense
to have one implementation of the help viewer (in toolkit) instead of
multiple forked implementations floating around?
Secondly the last time this cropped up it was pointed out that there are
extension authors that are/were using the help viewer and now they have
to package it in with their extensions. Probably even /more/ forked
versions floating around.
You know the more I think about it, there should be a toolkit2.jar (e.g.
global2) for all the bits and pieces that Firefox doesn't want but other
toolkit consumers want, if only to prevent forking and improve
maintainability (improvements and fixes don't get lost in someone's
private repository).
Hrm, any comm-central people around? How about a "commkit" and a
"commglobal" package?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]A piano is a piano is a piano. Gertrude Steinway.
* TagZilla 0.066.6
Greg Marine
> If there are significant (for certain values of significant) number of
> consumers of the help viewer outside of Mozilla, would it not make sense
> to have one implementation of the help viewer (in toolkit) instead of
> multiple forked implementations floating around?
>
> Secondly the last time this cropped up it was pointed out that there are
> extension authors that are/were using the help viewer and now they have
> to package it in with their extensions. Probably even /more/ forked
> versions floating around.
>
> You know the more I think about it, there should be a toolkit2.jar (e.g.
> global2) for all the bits and pieces that Firefox doesn't want but other
> toolkit consumers want, if only to prevent forking and improve
> maintainability (improvements and fixes don't get lost in someone's
> private repository).
>
> Hrm, any comm-central people around? How about a "commkit" and a
> "commglobal" package?
>
> Phil
Thank you all for your responses. I would agree that a separate
package would be nice for those of us who use the Mozilla Help Viewer.
This would give projects like mine the choice to use it and those
projects who don't use it won't have to worry about bloat. The more
and more I think about it, the more I'd really like to keep it around.
I really like Phil's comment about forking. It would be best to keep
it in one package or another and be maintained by either the community
or Mozilla itself. To be honest, however, I don't think the help
viewer is much bloat. It seem pretty small to me. Does anyone else
have a thought on this?
Thanks,
Greg
Greg Marine
Thank you for your response. I agree if not many applications use the help
viewer, it should probably be removed as you said it is bloat. I'm a fan of
the fact the Mozilla Platform is so small yet powerful. Up until now, I have
been using my own method of displaying help. I was going to move to the help
viewer because it was available. So, in light of bug 425541, I should
probably just stick with what I'm already doing. Unless there is an easy way
to extract the help viewer to use in my applications? Does it use any native
code I would have to compile for each platform? Or is it strictly XUL and
Javascript?
Thanks again!
Greg
On Mon, Nov 24, 2008 at 5:33 PM, Gavin Sharp <gavin...@gmail.com> wrote:
> On Mon, Nov 24, 2008 at 4:36 PM, Greg Marine <gregm...@gmail.com> wrote:
> > I noticed Firefox 3 uses online documents for its help system now. I
> > was wondering if the Mozilla Help Viewer will remain in XULRunner for
> > our third-party applications.
>
> Bug 425541 was filed for its removal, though there's been no progress
> as of yet. The rationale for removing it is that it would cut down on
> unnecessary bloat for the majority of toolkit users that don't use it,
> and it isn't something terribly burdensome for Komodo to ship itself.
> Do you see things differently?
>
> Gavin
>
Greg Marine
> Gavin,
>
> Thank you for your response. I agree if not many applications use the help
> viewer, it should probably be removed as you said it is bloat. I'm a fan of
> the fact the Mozilla Platform is so small yet powerful. Up until now, I have
> been using my own method of displaying help. I was going to move to the help
> viewer because it was available. So, in light of bug 425541, I should
> probably just stick with what I'm already doing. Unless there is an easy way
> to extract the help viewer to use in my applications? Does it use any native
> code I would have to compile for each platform? Or is it strictly XUL and
> Javascript?
>
> Thanks again!
> Greg
>
>
>
> > On Mon, Nov 24, 2008 at 4:36 PM, Greg Marine <gregmar...@gmail.com> wrote:
> > > I noticed Firefox 3 uses online documents for its help system now. I
> > > was wondering if the Mozilla Help Viewer will remain in XULRunner for
> > > our third-party applications.
>
> > Bug 425541 was filed for its removal, though there's been no progress
> > as of yet. The rationale for removing it is that it would cut down on
> > unnecessary bloat for the majority of toolkit users that don't use it,
> > and it isn't something terribly burdensome for Komodo to ship itself.
> > Do you see things differently?
>
>
> - Show quoted text -
Kindly ignore this post. That was sent last night and just now ended
up in the thread.
Thanks,
Greg
Gavin Sharp
> If there are significant (for certain values of significant) number of
> consumers of the help viewer outside of Mozilla, would it not make sense
> to have one implementation of the help viewer (in toolkit) instead of
> multiple forked implementations floating around?
Yes, of course. The problem, as you've alluded to, is the definition
of "significant". Keeping the code around has some costs, and it's
hard to judge objectively how they compare to the benefits. My current
opinion, based on what people have said in this thread and in the bug,
is that we should keep it.
> You know the more I think about it, there should be a toolkit2.jar (e.g.
> global2) for all the bits and pieces that Firefox doesn't want but other
> toolkit consumers want, if only to prevent forking and improve
> maintainability (improvements and fixes don't get lost in someone's
> private repository).
"stuff Firefox doesn't want but other toolkit consumers want" is the
wrong way to look at it, in my opinion. The toolkit is meant to be
useful for all XUL applications (with a certain bias towards
browser/mail and other Internet-related applications, obviously), and
isn't as tightly coupled to Firefox as you seem to think it is. It
shouldn't be bloated with every component that's used by more than one
project, of course, but it also shouldn't be limited to "what Firefox
needs" (and isn't). The existing way the help viewer is set up is a
good example - Firefox disables the feature during its build, but the
feature still ships as part of XULRunner by default.
If what you're really saying is that there are bits of code that are
useful to products that use comm-central, but aren't generally useful
enough to be added to the toolkit, then of course it makes sense to
share them without involving the toolkit, and I have no opinion about
how you do it or what the package is called :)
Gavin
Greg Marine
> but the feature still ships as part of XULRunner by default.
I was not able to get it working in the latest XULRunner (1.9.0.4).
What I did to get it to work was extract the viewer and put it in my
own chrome. So, are we sure it still ships with XULRunner by default?
I could be wrong, though. If I make any enhancements, I will (of
course) contribute the code to the community under the same license it
falls under.
Thank you, everyone, for your responses and help!
Happy Thanksgiving!!!
Greg
Robert Kaiser
> On Tue, Nov 25, 2008 at 10:33 AM, Philip Chee<phili...@gmail.com> wrote:
>> If there are significant (for certain values of significant) number of
>> consumers of the help viewer outside of Mozilla, would it not make sense
>> to have one implementation of the help viewer (in toolkit) instead of
>> multiple forked implementations floating around?
>
> Yes, of course. The problem, as you've alluded to, is the definition
> of "significant". Keeping the code around has some costs, and it's
> hard to judge objectively how they compare to the benefits. My current
> opinion, based on what people have said in this thread and in the bug,
> is that we should keep it.
I also think that would be a good idea. It's quite small and
well-isolated, so shouldn't be much a of a problem to anyone not using
it, and apparently there are a few users.
Those of us using it might want to collaborate on getting some
improvements into it, I guess, and having it in this central place
should also be a good base for such collaboration.
Robert Kaiser
Greg Marine
> I also think that would be a good idea. It's quite small and
> well-isolated, so shouldn't be much a of a problem to anyone not using
> it, and apparently there are a few users.
> Those of us using it might want to collaborate on getting some
> improvements into it, I guess, and having it in this central place
> should also be a good base for such collaboration.
>
> Robert Kaiser
I would be happy and honored to help collaborate on the Mozilla Help
Viewer. The more I think about it, the more I want for it to be around
and enhancements made. When I extracted it for use in my applications,
I was surprised it was so small. So, IMHO, I don't think it
contributes too much "bloat" in the toolkit. I wonder, though, why I
couldn't get it to work in XULRunner 1.9.0.4 without extracting it and
putting it in my own chrome? If it is still in XULRunner, how do I use
that version? If someone needs more info on what I'm asking, please
let me know.
Thanks,
Greg
Greg Marine
Here is the documentation I'm going by:
https://developer.mozilla.org/En/Help_Viewer/Creating_a_Help_Content_Pack
Thanks,
Greg
Robert Kaiser
> Here is the documentation I'm going by:
> https://developer.mozilla.org/En/Help_Viewer/Creating_a_Help_Content_Pack
I myself have not too much experience in how it works in the details,
and not much time to look into the doc you mention right now, but if it
helps, here's the code used by SeaMonkey with the toolkit help viewer
(we're not running on top of XULRunner but compiling the platform into
our product right now, but that shouldn't make a difference here):
http://mxr.mozilla.org/comm-central/source/suite/locales/en-US/chrome/common/help/
Robert Kaiser