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!
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.
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.
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.
Hmm, is xp_core.h the right place to #define this? I thought bryner was trying to stomp out everything in the #include directory.
So open the bug for the other options and move the gtk specific ones inside of the define ( --disable-xshm, --display, etc )
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...)
r=cls on attach 31569
Are you still shooting for 0.9 on this? If so please email email@example.com with a status on you progress. If not please retarget against a later Milestone. Thanks.
can we live with out this? trying to reduce noise for 0.9..
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
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
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
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
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") ?
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.
Status: RESOLVED → VERIFIED
Component: Cmd-line Features → Cmd-line Features
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.