Provide API for querying version, toolkit info

RESOLVED WONTFIX

Status

()

Core
Embedding: APIs
RESOLVED WONTFIX
14 years ago
13 years ago

People

(Reporter: jhp (no longer active), Assigned: Adam Lock)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

14 years ago
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?
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
OS: Linux → All

Comment 2

14 years ago
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?
(Reporter)

Comment 3

14 years ago
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.
(Reporter)

Comment 4

14 years ago
Created attachment 174425 [details] [diff] [review]
work in progress

Darin, is this what you had in mind?

Comment 5

14 years ago
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.
(Reporter)

Comment 6

14 years ago
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.
(Reporter)

Comment 7

14 years ago
Created attachment 175161 [details] [diff] [review]
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.
Attachment #174425 - Attachment is obsolete: true
+	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...
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?
(Reporter)

Comment 10

14 years ago
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.
(Reporter)

Comment 11

13 years ago
Don't think this is necessary anymore, since a similar functionality is provided by the |GRE_GetGREPathWithProperties| API.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.