279828 - Provide API for querying version, toolkit info

Status: RESOLVED WONTFIX

(Core Graveyard :: Embedding: APIs, defect)

Description

[jhp (no longer active)]

Embeddors need the ability to query the version number of any installed Mozilla.
 Also, since there are several different toolkits available on Linux (GTK, GTK2,
QT), they also need to be able to query the toolkit used.

We could provide these functions in nsXPCOM.h, such that an embeddor could load
the XPCOM lib and query the info before initting XPCOM.  What do you think?  Is
there any other info an embeddor might need?

Also, someone mentioned that GnomeVFS can be used as an application registry. 
Don't know if Mozilla already has code for this, or if there are any plans to
include it.  Plus, this wouldn't help any system that didn't use Gnome.

Thoughts?

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

I don't think querying the toolkit can be part of xpcom - xpcom doesn't even
know that such a thing as a toolkit exists!


> Also, someone mentioned that GnomeVFS can be used as an application registry. 

bryner added support for that in bug 128668

Comment 2

[Darin Fisher]

biesi: XPCOM is the entry point library, and the method javier is suggesting
could  be very generic:

  const char* NS_GetFeatureString(const char* key)

or something like that.  the implementation could do something wonderful that
avoids having to encode widget specific stuff in mozilla/xpcom.

but having said that, i thought of a pretty major issue:

libxpcom.so ultimately will have a link dependency on libxul.so, which will have
a link dependency on GTK, etc.  so that means that simply loading libxpcom.so
would seem to be problematic.  it's important to link libxpcom.so directly to
libxul.so so that we benefit from DSO preloading.

perhaps a better solution would be to add a data file inside the GRE directory
that can be read by embedders to inspect the various features of that gecko.  we
could even write a small library that would do this for them (perhaps build it
as a static lib).

thoughts?

Comment 3

[jhp (no longer active)]

I'd also thought of having a simple file that has this info, but was thinking
that it would just be a text file that the embedder would parse.  Do you think
it is worthwhile to create something more cryptic that has to be read by calling
a utility library?  Or were you thinking of having it both ways?

As for bug 128668, that seems to be more about mime types and helper apps.  It
seems that GnomeVFS may also offer features equivalent to the Windows registry,
so an app can register information about itself in a central location.  CCing
bryner to get his opinion.

Comment 4

[jhp (no longer active)]

Attachment: work in progress

Darin, is this what you had in mind?

Comment 5

[Darin Fisher]

javier, that's not really what i had in mind, but it seems reasonable.  i figure
there's some overhead in codesize to using a DLL for this, but that's certainly
one way to do it.  a text file would be do-able and small, but perhaps it would
be less friendly to embedders.  my proposal was to include a static lib with the
gecko sdk that embedders could link to that would save them from having to parse
the text file located in the mozilla bin directory.

Comment 6

[jhp (no longer active)]

I was originally thinking about this from the Javaconnect point of view, where a
Java embedder would want to load the library and call the functions before
calling initEmbedding().  But I should be able to make it a static lib and link
it to the JNI library.  I'll try that out.

Comment 7

[jhp (no longer active)]

Attachment: patch

Darin, how's this?  This creates a static lib and installs it into the SDK
along with the header.	Also added comments for both functions.

As I mentioned in the previous comment, for the Javaconnet case, I just linked
this static lib into my JNI lib, and exposed the functions as Java functions
like I normally would.	Works great.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

+	sed -e "s|%MOZILLA_VERSION%|$(MOZILLA_VERSION)|" | \
+	sed -e "s|%MOZILLA_TOOLKIT%|$(MOZ_WIDGET_TOOLKIT)|" \

why not use the C preprocessor? At least MOZILLA_VERSION should already be
defined, and if the toolkit isn't, the makefile could append an appropriate -D
flag to the commandline...

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

actually, will this work? doesn't the patch always return the same answer, only
depending on what the embeddor built with, instead of what mozilla built with?

Comment 10

[jhp (no longer active)]

Ah, bloody hell, quite right.  This was one of the reasons I created a DLL to
begin with, and then promptly forgot.  This would have to be a DLL so the
embedder can look up a Mozilla installation, load this DLL, and find out its
information.  Or just use a text file.

Comment 11

[jhp (no longer active)]

Don't think this is necessary anymore, since a similar functionality is provided by the |GRE_GetGREPathWithProperties| API.