Mozilla build with Xlib toolkit only offers GTK+-specific options...

VERIFIED FIXED in mozilla0.9.1

Status

Core Graveyard
Cmd-line Features
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: Roland Mainz, Assigned: timeless)

Tracking

Trunk
mozilla0.9.1
All
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: mozilla 0.9 branch pardon)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
mozilla-2001-02-10-08-Mtrunk build on Linux/Solaris "offer" GTK+-specific
cmd-line options when build with --enable-toolkit=xlib:
-- snip --
% ./mozilla --help
./run-mozilla.sh ./mozilla-bin --help
MOZILLA_FIVE_HOME=.
 
LD_LIBRARY_PATH=.:/usr/local/staden/lib/solaris-binaries:/usr/local/lib:/usr/local/rvplayer5.0:/usr/local/arb/lib
     LIBRARY_PATH=.:./components
       SHLIB_PATH=.
          LIBPATH=.
       ADDON_PATH=.
      MOZ_PROGRAM=./mozilla-bin
      MOZ_TOOLKIT=
        moz_debug=0
     moz_debugger=
File descriptors set to 512
Usage: ./mozilla-bin [ options ... ] [URL]
       where options include:

GTK options
        --gdk-debug=FLAGS               Gdk debugging flags to set
        --gdk-no-debug=FLAGS            Gdk debugging flags to unset
        --display=DISPLAY               X display to use
        --sync          Make X calls synchronous
        --no-xshm               Don't use X shared memory extension
        --xim-preedit=STYLE
        --xim-status=STYLE
        --gtk-debug=FLAGS               Gtk+ debugging flags to set
        --gtk-no-debug=FLAGS            Gtk+ debugging flags to unset
        --g-fatal-warnings              Make all warnings fatal
        --gtk-module=MODULE             Load an additional Gtk module

Mozilla options
        -height <value>         Set height of startup window to <value>.
        -h or -help             Print this message.
        -installer              Start with 4.x migration window.
        -width <value>          Set width of startup window to <value>.
        -v or -version          Print ./mozilla-bin version.
        -CreateProfile <profile>                Create <profile>.
        -P <profile>            Start with <profile>.
        -ProfileWizard          Start with profile wizard.
        -ProfileManager         Start with profile manager.
        -SelectProfile          Start with profile selection dialog.
        -nosplash               Disable splash screen.
Type Manifest File:
/bigtmp/gisburn/mozilla-2001-02-10-08-Mtrunk/mozilla/objdir_ws6_xlib/dist/bin/components/xpti.dat
        -compose <url>          Start with messenger compose.
        -edit <url>             Start with editor.
        -mail           Start with mail.
        -addressbook            Start with the addressbook.
        -chrome <url>           Load the specified chrome.
        -jsconsole              Start with Javascript Console
        -news           Start with news.
-- snip --

Uhm... assuming this build does not use nor link agaist libGTK&co. - why are the
nGTK+-options here ??

CC: Xlib-guru "blizzard"... :-)
(Assignee)

Comment 1

17 years ago
Created attachment 25045 [details] [diff] [review]
separate GTK and X11 from UNIX
(Assignee)

Comment 2

17 years ago
please review
Assignee: law → timeless
Keywords: approval, mozilla1.0, patch, review
Target Milestone: --- → mozilla0.9
So the X11 only build supports --no-xshm, --xim-* --sync and --display now?

Also, this define before the X11 options is:

+#if XP_X11 || (!NO_X11 && XP_UNIX)

which says "if XP_X11 is defined or ( not NO_X11 and XP_UNIX )"

Huh?  How does that work?  To turn off X11 we define NO_X11?

Dauphin, take me away!
(Assignee)

Comment 4

17 years ago
sorry, the line should be
+#if defined(XP_X11) || (!defined(NO_X11) && defined(XP_UNIX))

in the future i'd hope we would simply define XP_X11. for now, that will fail 
so we'll chain to the || fallthrough case, and when no_x11 is not defined and 
xp_unix is defined we conclude we're building for x11.

as for the x* stuff, if anyone has better conditions for --x*, i'll gladly use 
them.
Status: NEW → ASSIGNED
That double negative is scary.

Comment 6

17 years ago
Created attachment 31456 [details] [diff] [review]
patch to define and use XP_X11

Comment 7

17 years ago
r=cls

Comment 8

17 years ago
r=dr
All of those --display, etc options in the X11 sections are actually still part
of GTK and I'm pretty sure that the Xlib toolkit that we have doesn't support them.
(Assignee)

Comment 10

17 years ago
hrm.  interesting point.

John G: i haven't gotten Qt to build yet, so I haven't tried, but does Qt 
Mozilla support -display?

Blizzard: imo what i did is still an improvement even if it's slightly wrong, 
and I promise to continue to fix it as long as there are technicalities.  
Before this change, we would display those options on XP_UNIX which should 
include Qt, Xlib, and others.

The fact that Xlib and other X11 ports do not support the options should cause 
someone to file a bug report based on theit knowledge or their viewing of this 
help screen.

Comment 11

17 years ago
Hmm, is xp_core.h the right place to #define this? I thought bryner was trying
to stomp out everything in the #include directory.
(Assignee)

Comment 12

17 years ago
Created attachment 31569 [details] [diff] [review]
configure.in define of MOZ_X11
So open the bug for the other options and move the gtk specific ones inside of
the define ( --disable-xshm, --display, etc )

Comment 14

17 years ago
Qt Mozilla supports the use of -display and, AFAIK, other X Toolkit command line
options - at least when built against the X11 version of Qt.  (I just tested
this myself with last night's nightly...)

Comment 15

17 years ago
r=cls on attach 31569

Comment 16

17 years ago
sr=scc

Comment 17

17 years ago
Are you still shooting for 0.9 on this? If so please email drivers@mozilla.org
with a status on you progress. If not please retarget against a later Milestone.
Thanks.

Comment 18

17 years ago
can we live with out this?  trying to reduce noise for 0.9..
(Assignee)

Comment 19

17 years ago
I think that we can do this, especially if someone sr= and a='s bug 20196 which 
should alleviate blizzard's concern.
Keywords: approval, mozilla1.0, review → mozilla0.9.1

Comment 20

17 years ago
I'd like to see this bug get fixed ASAP in 0.9.1, but I don't personally think
this is in any way necessary for 0.9... It's not worth even the most minimal
risk it could pose, this far into the tree closure. I'd suggest taking it off of
chofmann's radar, honestly.

Love,
dr

Comment 21

17 years ago
go into 0.9.1 when the tree opens Wed/Thur and we can revisit taking this
on the branch if its worth the time and effort.   thanks
Target Milestone: mozilla0.9 → mozilla0.9.1
(Assignee)

Comment 22

17 years ago
fix checked in. requesting pardon in a few days for 0.9 branch.
This makes --help output more accurate for various x11 and non x11 ports and 
should have no risk.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: mozilla 0.9 branch pardon
(Reporter)

Comment 23

17 years ago
Uhm... is there a way to implement this in a way that _multiple_ toolkits can be
build and users chooses his/her preferred one at cmd-line (see bug 76201 -
"allow building of multiple widget/gfx ports") ?

Comment 24

17 years ago
Roland: 76201 will likely spin-off several polish bugs like that which you
mention. If you want to pre-empt that, I'd suggest filing a new bug and have it
depend on 76201.
Keywords: verifyme
rubberstamping.
Status: RESOLVED → VERIFIED
(Assignee)

Updated

9 years ago
Component: Cmd-line Features → Cmd-line Features
Keywords: verifyme
Product: Core → Core Graveyard
QA Contact: bugzilla → cmd-line
You need to log in before you can comment on or make changes to this bug.