Closed Bug 41741 Opened 24 years ago Closed 24 years ago

support resizable dialogs on the mac

Categories

(SeaMonkey :: UI Design, defect, P3)

Product:
SeaMonkey
Component:
UI Design
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: nbaca, Assigned: sfraser_bugs)

References

Details

(Keywords: helpwanted, platform-parity, Whiteboard: [nsbeta3+]patch, fix in hand) 

Build 2000-06-06-09M16: Mac 9.04

Overview: On the Mac it would be good to make Modal dialogs resizeable. This 
request is prompted by bug# 39202 where the user's fonts were to large to see 
all the text in Mail's Account Settings window. Also, the Windows and Linux 
versions can currently resize modal dialogs.
  At first I thought the request was to make *all* modal dialogs on the Mac 
resizeable, which seems like a very bad thing. But judging from the above-
mentioned bug 39202, I gather the request is only to do that to dialogs that the 
UI designer has explicitly requested be resizeable. Hmmm.
  The problem is that the WDEFs we're using for dialogs don't make resizeable 
windows. I rather think that resizeable dialogs are probably bad Macintosh 
medicine. I believe there aren't any resizeable dialog WDEFs to choose from, so 
to make a dialog resizeable we'd have to switch to a normal document window WDEF. 
Besides adding the big ugly resizing handle to the window, this changes the 
window's overall appearance.
  Changing this code in nsMacWindow.cpp

case eWindowType_dialog:
#if !TARGET_CARBON
  if (aInitData &&
        aInitData->mBorderStyle != eBorderStyle_all &&
        aInitData->mBorderStyle != eBorderStyle_default &&
       (aInitData->mBorderStyle == eBorderStyle_none ||
        !(aInitData->mBorderStyle & eBorderStyle_title)))
  {
    wDefProcID = kWindowModalDialogProc;
    goAwayFlag = false;
  } else {
    wDefProcID = kWindowMovableModalDialogProc;
    goAwayFlag = true; // revisit this below
  }
  hOffset = kDialogMarginWidth;
  vOffset = kDialogTitleBarHeight;
  break;
#endif

to this

case eWindowType_dialog:
#if !TARGET_CARBON
  if (aInitData &&
      aInitData->mBorderStyle != eBorderStyle_all &&
      aInitData->mBorderStyle != eBorderStyle_default)
  {
    if (aInitData->mBorderStyle == eBorderStyle_none ||
       !(aInitData->mBorderStyle & eBorderStyle_title))

      wDefProcID = kWindowModalDialogProc;
    else
      if (aInitData->mBorderStyle & eBorderStyle_resizeh)
        wDefProcID = kWindowGrowDocumentProc;
      else
        wDefProcID = kWindowMovableModalDialogProc;

  goAwayFlag = false;
  } else {
    wDefProcID = kWindowMovableModalDialogProc;
    goAwayFlag = true; // revisit this below
  }
  hOffset = kDialogMarginWidth;
  vOffset = kDialogTitleBarHeight;
  break;
#endif

will do exactly that.
  Personally, I don't particularly like it. But I don't consider myself steeped 
deeply enough in Mac lore any longer to be a judge. cc:ing sfraser for comment. 
Not on that last sentence, though.

There is a Mac UI widget that is used sometimes to allow users to resize a 
dialog; it put some grippy lines in the lower right corner (like the normal 
resize box, but without the square border). I think we should allow something 
similar for XUL dialogs, and allow XUl authors to specify that a dialog is 
resizable. For some dialogs (e.g. those containing long lists, like the subscribe 
dialog), being resizable is almost essential.

To get the resize widget, you need windowProc kWindowDialogDefProcResID with 
variation code 6 (i.e. kWindowMovableModalGrowProc).

if this were implemented, could the prefs dialog on mac be resizeable, as it is
on linux and win32? (i know, it's a pipe dream o'mine... :-)
Keywords: pp
new feature request, ->future
Target Milestone: --- → Future
well, it's making alot of dialogs unusable such as the mail search window..

it's not really a new feature request, because it works correctly on other 
platforms when you pass "resizable" to the window.openDialog call.

Nominating for beta3 because of the usability issue.
changing the title of the bug to more accurately describe the issue (as 
recognized by danm in his comments above)
Summary: Modal dialogs should be resizeable → support resizable dialogs on the mac
Keywords: nsbeta3
Here's a fix:

Index: mozilla/widget/src/mac/nsMacWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/mac/nsMacWindow.cpp,v
retrieving revision 1.62
diff -c -2 -r1.62 nsMacWindow.cpp
*** nsMacWindow.cpp	2000/08/04 14:48:29	1.62
--- nsMacWindow.cpp	2000/08/07 22:05:54
***************
*** 375,379 ****
  					goAwayFlag = false;
  				} else {
! 					wDefProcID = kWindowMovableModalDialogProc;
  					goAwayFlag = true; // revisit this below
  				}
--- 375,379 ----
  					goAwayFlag = false;
  				} else {
! 					wDefProcID = (aInitData->mBorderStyle & 
eBorderStyle_resizeh) ? kWindowMovableModalGrowProc : 
kWindowMovableModalDialogProc;
  					goAwayFlag = true; // revisit this below
  				}

It's not ideal, because it introduces a non-skinnable grippie widget in the 
corner of the window, but it's better than nothing.
Whiteboard: patch
Yes, thank you Simon.  Having some sort of a fix is better than nothing.  Can we 
have your fix?  If so, should we change the target milestone of this bug from 
future back to a more current milestone?
Taking.
Assignee: danm → sfraser
Whiteboard: patch → patch, fix in hand
Keywords: mailtrack
*** Bug 47819 has been marked as a duplicate of this bug. ***
add self to CC:

Well, that patch ain't right, because it makes all dialogs have the resize 
widget. Our mapping of chrome flags to window types is pretty inaccurate, and 
there's a question of whehter to impose platoform rules here (like, should any 
dialog ever have a close box?).

Anyway, here's some code that is better about mapping chrome flags to window 
types. This is in nsMacWindow::StandardCreate(), under the eWindowType_dialog 
case. I welcome a review.

			case eWindowType_dialog:
#if !TARGET_CARBON
        if (aInitData)
        {
          switch (aInitData->mBorderStyle)
          {
            case eBorderStyle_none:
					    wDefProcID = kWindowModalDialogProc;
              break;
              
            case eBorderStyle_all:
              wDefProcID = kWindowMovableModalGrowProc;   // should we add a 
close box (kWindowGrowDocumentProc) ?
              break;
              
            case eBorderStyle_default:
					    wDefProcID = kWindowModalDialogProc;
              break;
            
            default:
              // we ignore the clase flag here, since mac dialogs should never 
have a close box.
              switch(aInitData->mBorderStyle & (eBorderStyle_resizeh | 
eBorderStyle_title))
              {
                // combinations of individual options.
                case eBorderStyle_title:
                  wDefProcID = kWindowMovableModalDialogProc;
                  break;
                                    
                case eBorderStyle_resizeh:
                case (eBorderStyle_title | eBorderStyle_resizeh):
                  wDefProcID = kWindowMovableModalGrowProc;   // this is the only 
kind of resizable dialog.
                  break;
                                  
                default:
                  NS_WARNING("Unhandled combination of window flags");
                  break;
              }
          }
        }
        else
        {
					wDefProcID = kWindowModalDialogProc;
					goAwayFlag = true; // revisit this below
        }
        
        hOffset = kDialogMarginWidth;
        vOffset = kDialogTitleBarHeight;
				break;
#endif

setting to +
Whiteboard: patch, fix in hand → [nsbeta3+]patch, fix in hand
Target Milestone: Future → M18
>there's a question of whehter to impose platoform rules here 

>(like, should any dialog ever have a close box?).



On the Mac, no dialog that has a button that dismisses the dialog should ever 

have a close box (and all modal dialogs should have a button that dismisses the 

dialog).



The problem is that if you allow this kind of widget people do two awful things:



i) Make modal dialogs with no buttons that the user has to close to dismiss 

(ugh!)



ii) Make dialogs with multiple buttons. The close button may be equivelent to one 

of the buttons, or none of them. e.g. OK, Cancel, an clicking close might do 

"Stop the process but don't cancel the work done so far." Can you guess which it 

is by looking at it?






Simon -- your new version makes different assumptions -- no doubt several Mozilla 
dialogs will change their appearance. I imagine you prefer the new appearance. 
(Or does anything actually change in practice?) Consider this a review. It's fine 
with me.

Yes, it changes some dialogs. We'll need to add "titlebar" to some dialogs (e.g. 
common dialogs etc) to have them moveable modal on Mac. I'll do that.
Status: NEW → ASSIGNED
QA Contact: sairuh → jrgm
Checked in. Note that this will cause some dialogs to show now without a titlebar 
on Mac (making them not moveable). When you see this, file a bug on the dialgo 
author to add "titlebar" to the dialog attributes.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
vrfy on mac using opt comm bits 2000.08.25.04.

yep, i've already found a couple of dialogs --i'll file and ref this one...
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
OS: Mac System 9.x
You need to log in before you can comment on or make changes to this bug.