Closed
Bug 52778
Opened 24 years ago
Closed 23 years ago
Ok/Cancel overlay needs Help button
Categories
(SeaMonkey :: Help Documentation, enhancement, P3)
SeaMonkey
Help Documentation
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: mpt, Assigned: oeschger)
References
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
The Ok/Cancel overlay allows XPToolkit app authors to create platform-compliant
dialogs on Windows, X, and Mac OS. However, it is missing two vital features.
1. Orientation. Dialogs which include commonDialog should be able to specify
either horizontal orientation (the default) or vertical orientation.
Horizontal orientation looks like this:
| ( Other1 ) ( Other2 ) ( Cancel ) (( Ok )) | [X, Mac OS]
+---------------------------------------------------------------+
| [[ Ok ]] [ Cancel ] [ Other1 ] [ Other2 ] | [Windows]
+---------------------------------------------------------------+
Vertical orientation looks like this on all platforms:
----------------------------------------------------------------+
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
----------------------------------------------------------------+
(( Ok )) |
( Cancel ) |
|
( Other1 ) |
( Other2 ) |
(Other3..) |
Vertical orientation is important to provide consistent placement of buttons
(and therefore faster clicking) in dialogs which may vary in height from
instance to instance. An example of this is the cookie confirmation dialog
(bug 23508).
2. The Ok/Cancel overlay needs to take a flag indicating whether a Help button
is present. A window with a Help button looks like this:
| [?] ( Other1 ) ( Other2 ) ( Cancel ) (( Ok )) | [X, Mac OS]
+---------------------------------------------------------------+
<http://developer.apple.com/techpubs/mac/HIGOS8Guide/graphics/HIG_CG-070.gif>
(Note that the Help button has a rectangular border on Mac OS, whereas the
other buttons are rounded. On X, all the buttons would be rectangular.)
| [[ Ok ]] [ Cancel ] [ Other1 ] [ Other2 ] [ Help ] | [Windows]
+---------------------------------------------------------------+
<http://msdn.microsoft.com/library/books/winguide/images\13_07.GIF>
Reporter | ||
Updated•24 years ago
|
Comment 1•24 years ago
|
||
> 1. Orientation.
What makes you think that? I saw code for that, but I don't know the state or
how it is enabled.
> | [?] ( Other1 ) ( Other2 ) ( Cancel ) (( Ok )) | [X, Mac OS]
No, GNOME looks like Windows. See example screenshot
<http://bugzilla.mozilla.org/showattachment.cgi?attach_id=14775>.
Comment 2•24 years ago
|
||
> No, GNOME looks like Windows.
(Of course, it doesn't, I meant just this layout.)
Wrong, as you can see from the screenshot (OK - Apply - Close - Help).
Unix/GTK/GNOME doesn't have strict UI guidelines yet anyway, but common seems to
be the following layout: OK - [Apply -] Custom 1 - Custom 2 - Close - Help.
Comment 3•24 years ago
|
||
One issue per bug report, please. Two features, two reports. Good stuff, but of
course no time now. ->future
Target Milestone: --- → Future
Comment 4•24 years ago
|
||
> One issue per bug report, please.
Narrowing summary to Help button.
Summary: Ok/Cancel overlay needs to support orientation and Help button → Ok/Cancel overlay needs to Help button
Comment 6•24 years ago
|
||
This is required for Help, and for the Security dialogs (see bug 76248). It needs
to be dragged back from Future.
Updated•24 years ago
|
Target Milestone: Future → ---
Updated•24 years ago
|
Summary: Ok/Cancel overlay needs to Help button → Ok/Cancel overlay needs Help button
Comment 7•24 years ago
|
||
Daniel sez Ben touches this most (and we have not- ever), attempting
reassignment.
Assignee: trudelle → ben
Status: ASSIGNED → NEW
Comment 8•24 years ago
|
||
Is this bug being actively worked on? If so, any idea of when it will be fixed.
If this is not going to be fixed, please let me know so I can consider
workarounds for this.
Comment 9•24 years ago
|
||
--> Help
Assignee: ben → oeschger
Component: XP Toolkit/Widgets → Help
QA Contact: jrgm → tpreston
Assignee | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
I don't think this is my bug to accept, so leaving as NEW. Ben, Blake,
Simon...anyone? The attached patch is a sample of what we need to get a help
button into the overlay (since, I think, there will be no <dialog /> soon and we
will continue to use the overlays for the time being).
Note the import of the help script, where openHelp() is not yet but will be
defined as a window-mediator-based way to open the help window, with
context-sensitivity if you want.
help wanted!
Comment 12•24 years ago
|
||
Comments:
+<script type="application/x-javascript" src="chrome://chrome/content/help.js"/>
I don't think we want to load a new JS file for every dialog. help.js should be
loaded by dialogs that want help.
+ <button class="exit-dialog" id="help" label="&helpButton.label;" oncommand=
"openHelp();"/>
This should be an 'onHelp()' function, I think, that will be implemented in the
JS of dialogs that use the 'okCancelHelpButtons' box.
Assignee | ||
Comment 13•23 years ago
|
||
Checked in fix for this yesterday. dialog overlays now have two different sets
of buttons <box id="okCancelHelpButtons" /> and <box
id="okCancelHelpButtonsRight" />.
Dialogs that use these button sets must implement their own doHelpButton()
function. See 46226 for preferences dialog implementation of this.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•