Default X application command-line options not supported by Mozilla: Examples (I don't know if this are all...): -bg -background -bd -bordercolor -bw -borderwidth -display -fn -font -fg -foreground -geometry -iconic -name -rv -reverse +rv -selectionTimeout -synchonous +synchonous -title -xnllanguage -xrm The bug may also be named "Mozilla isn't a good X citizen..." because there are several other issues like this one. Should I try to dig them out and list them there ?

who is, or who are, the best owner(s) for this bug. pav? syd? blizzard, any ideas?

Most important options: "-display" (to redirect mozilla to another display) "-iconic" (start Mozilla in iconic mode - please test if this works with -mail/-news etc. options, too) "-name" (give the X application a name) "-title" (set window title) "-xrm" (set resource value)

BTW: Does our BuggyZilla ( =:-) ) support the X11 Release 6 session management protocol (and/or the Inter-Client Communications and Conventions Manual (ICCCM) session management protocol) ?

Interesting bug. The command line args you refer to are Xt Intrinisics handled arguments. We ar not an Xt application, we are (at the moment) a Gtk+ application, and in the future we will be Xlib. At this point, we support the Gtk+ arguments implicitly, although, many of these are going to be ignored since we are using GFX to render our widgets, not Gtk+ (we are using Gtk+ mostly as a bloated Xlib). When we go to Xlib, about all the user will be able to do is set the DISPLAY environment variable (analogous to the -display argument you mention above). We we do need to be concerned with being a "good X citizen" is defined in the ICCCM, e.g., selection protocols and the like. I haven't done a wholesale review of our compliance there, assume that mostly we are ok -- if there are problems with our compliance, we should open a bug and address them. In my view, it is ICCCM that defines how good a citizen we are. Marking INVALID.

AFAIK most applications support the -display, -iconic and -xrm options. The term "Mozilla isn't a good X citizen" comes from a coworker who's working with Unix for at least 20 years. Some things are simply traditional, not not supporting them breaks this - unwritten - standard. And IMHO Mozilla currently looks more than a Win32 App. than a X11/Unix. app. - it's getting big and bigger in GUI functionality and less and "lesser" controlable from command line ;-(

Where may I get the ICCCM from ?

First, we can certainly have support for any command line arg we like. --display currently is the Gtk+ analogue to -display, but as you well know we could add support for -display, -iconic, etc, if need be. I don't think -xrm will ever be supported, this corresponds to X Resources which are *entirely* an Xt thing. ICCCM can be found at the back of O'Reilly Volume 0, Xlib Protocol Specification if you happen to have that book. Better, get it directly from here: ftp://ftp.x.org/pub/R6.4/xc/doc/hardcopy/ICCCM/ I would gather that X11R6.4 is current enough, that was about the time the X Consortium fell apart and was handed over to the Open Group, and to the best of my knowledge, there have been no changes to the spec since then. To me, -iconic seems relevant to the ICCCM because it has something to say about being iconic. See below. I'm reopening this bug as a placeholder for things ICCCM-related. I propose we take a look at what it means to be ICCCM compliant, and if there happen to be command line args that correspond to ICCCM-isms (the "good citizen" aspect of your bug report) that interesect standard Xt command line arg set (the "command line args" aspect of your bug report) we can/should consider implementing them.

ICCCM C.3.1 ("Saving client state") - is this implemented in Mozilla ? User logs out (from desktop) and later logs in and all browser, main, news, addressbook and editor (with content !!) windows are still there... There's a confusing (for me) issue in http://www.opengroup.org/desktop/cde/cde.data.sheet.htm - section "Session Manager": -- snip -- CDE 2.1 supports the X11 Release 6 session management protocol. The Inter-Client Communications and Conventions Manual (ICCCM) session management protocol in CDE Release 1.X is still supported to ensure backward compatibility for older applications. -- snip -- What's the differnce between "ICCCM session management" and the "X11 Release 6 session management protocol" ? Any references (URLs) about the "X11R6 session management protocol" out there ? ---- Stupid question: Has XPToolkit something which works like Xt's resources ?

Putting on help wanted radar.

-> Roland.Mainz@informatik.med.uni-giessen.de

MAybe we should change the "summary" to something ICCCM-related (see syd@netscape.com 's comment). We should be little bit carefull as some of the things liked in ICCM may be outdated (like session management which has been replaced by libSM, the X session management library). On my currentToDo-listed related for this RFE/bug: - X session management is a _must_ for Unix Mozilla, most desktop environments have implemented this feature. Should I file a seperate RFE/bug for this ?(BTW: See ftp://ftp.x.org/pub/unsupported/test/xsm/xsmclient.c for a example code.) - I still like to get X resources and editres support build into the Xp toolkit, including the nice -xrm command line option...

Are command line options in the ICCCM?

No, AFAIK those options are not part of the ICCCM. But I think it is a mistake not adding Xt-support to Mozilla's toolkit (see http://www.rahul.net/kenton/40errs.html#Error1) on unix-platforms. (Toolkits like GTK+ which don't implement Xt-support (yet) are no excuse... :-))) Question: Is it difficult to add Xt-support to the current XPtoolkit implementation ?

It's a little more difficult than just "adding Xt-support" as you put it since it is an entirely different widget toolkit.

Agreed. But if I remember there's an Xt-addon for GTK+ in development (but I don't remeber the URL ;-(( ). How does it work - and can we use the same way for XPtoolkit ?

Is that an addon that lets you run an Xt widget in GTK's mainloop or run a GTK app in Xt's mainloop?

If I remember correctly (... but don't kill me if I'm wrong here =:-) it runns GTK widgets in Xt mainloop and adds the abillity to add entries in ~/.Xdefaults etc. for those GTK+ widgets...

If we are going to allow people to do these sorts of things, e.g., set font, bg color, etc., we need an XP way to do it that GFX widgets understand on all platforms, not platform specific flags to support legacy apps, IMHO. Changes the summary to reflect reality better.

BTW: Such a support for Xt-like customizing would be a great benefit for Unix system adminstrators (or experienced unix users) to customize the behaviour of Mozilla (should I say: The Mozilla Application Platform !? :-)) ) on a per-user basis without changes in the XUL etc. files itself... Adding vote - I'm an administrator, too :-)

What about bug 33146 ("editres support")... can this be implemented in one step with the Xt support ?

Q: What should be do with this bug ? I would still vote for a way to access/modify XP-Widgets via Xt-resources and a way to integrate XP-Widgets within a Xt application. Comments ?

Updating QA Contact

Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE. If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work being tracked. The Core: Tracking component will no longer be used.