Closed Bug 33378 Opened 24 years ago Closed 8 years ago

Unix: Default Xt/Intrinsics command-line options not supported by Mozilla...

Categories

(Core Graveyard :: Tracking, defect, P3)

Product:
Core Graveyard
Component:
Tracking
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: roland.mainz, Assigned: roland.mainz)

References

(Depends on 2 open bugs)

Details

(Keywords: helpwanted) 

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.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → 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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
Keywords: helpwanted
-> Roland.Mainz@informatik.med.uni-giessen.de
Assignee: chofmann → Roland.Mainz
Status: REOPENED → NEW
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.
Summary: Unix: Default X11 application command-line options not supported by Mozilla... → Unix: Default Xt/Intrinsics command-line options not supported by Mozilla...
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
QA Contact: leger → Roland.Mainz
Depends on: 20573
Depends on: 187139
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.
Status: NEW → RESOLVED
Closed: 24 years ago → 8 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.