Re: Re: CvsAlert changes

And yet another thing (while we're working on CvsAlert):

Mac OS X introduced the paradigm of document-modal dialogs & alerts:  
the dialog window is attached to it's parent window and there is a  
modality with respect to the parent window, i.e. the parent window is  
blocked, but all other windows remain accessible. This is very  
convenient for e.g. confirmations when closing windows, error alerts  
that only affect a single window, etc.

However, the drawback with this is that the window handling needs to be  
asynchronous. This is especially a problem when it's a confirmation of  
some kind. Think of e.g. the 'move to trash' confirmation: if it was  
document-modal, the actual move-to-trash operation can only proceed  
after the window was dismissed by the user with OK, but since it's  
document-modal, the application code can't easily remain in a modal  
loop.

Those document-modal windows (aka "Sheets") are used quite often in Mac  
OS X and actually using app-modal dialogs where document-modal dialogs  
would do kind of marks an application as not quite Mac OS X-ish :(

My suggestion now is to allow CvsAlert to be called asynchronously by  
implementing a member ShowAlertAsync where a completion callback can be  
passed (preferably a functor) which will be called with the alert  
result when the alert is dismissed:

	struct AlertCompletion {
		virtual void operator()(CvsAlert* dismissedAlert);
	};	
	void ShowAlertAsync(OSWindowRef parentWindow, AlertCompletion  
*callback);

Creating an async CvsAlert would then be a shoot-and-forget kind of  
operation:
	
	(new CvsAlert("Some Message"))->ShowAlertAsync(parentWin, new  
MyAlertCompletionThatDoesSomethingFancy);

or, for a simple doc-modal error alert:
	(new CvsAlert("An error occured"))->ShowAlertAsync(parentWin);

For the other platforms, the code would just handle the alert modal and  
call the completion callback immediately.

This would be a great step towards making MacCvs even more native look  
and feel on Mac OS X.

</jum>

Am 10.12.2003 um 20:47 schrieb Jens Miltner:

> One more observation / request:
>
> I saw that e.g. for the alert asking to confirm moving files to the
> trash, you specified BUTTONTITLE_YES and BUTTONTITLE_NO as the button
> titles.
> However, on the Mac, questions of this kind (i.e. confirming
> operations) are not asked with "Yes" and "No" buttons, but rather with
> "OK" and "Cancel" buttons. (Of course this requires that the wording of
> the question itself is such that it's clear what OK and Cancel
> means...)
>
> As a solution for the problem, we could either conditionalize the setup
> of the button titles where CvsAlert is called (e.g. in
> CvsCmdMoveToTrash) or we could define some constants for default
> confirmation button titles and inside CvsAlert, the correct button
> title would be picked. (I'd prefer the second option).
> This doesn't rule out the need for conditional code where CvsAlert is
> called, because the wording of the prompt might need to be different on
> the platforms, but for many cases it might avoid conditional code at
> the calling side...
>
> </jum>
>
> Am 10.12.2003 um 20:22 schrieb Jens Miltner:
>
>>
>> Am 10.12.2003 um 04:42 schrieb Jerzy Kaczorowski:
>>
>>> I just commited my changes to CvsAlert API. The function is replaced
>>> with
>>> the class. The contructor looks similiar to the function but it
>>> attempts to
>>> guess default button depending on the icon type and there is no
>>> problem how
>>> to layout the parameters. It will also try to eliminate the Cancel
>>> button
>>> title if the message is a "note" type.
>>>
>>> All that can be adjusted using the Get/Set methods if necessary.
>>>
>>> Additionally there is a preliminary support for "Don't show this
>>> again"
>>> checkbox which I will be putting to use soon. I still need to make
>>> some
>>> small resizing work in WinCvs alert dialog code (CCVSAlert_MAIN) but
>>> common
>>> CvsAlert class is unlikely to change any more so you can go ahead and
>>> fix
>>> the build for gCvs and MacCvs.
>>>
>>> I copied the function code into the CvsAlert::ShowAlert method. It
>>> should be
>>> easy to fix the build by replacing the parameters with the CvsAlert
>>> class
>>> members. The messages are stored as std::string values so you can  
>>> test
>>> the
>>> buttons and messages using the .empty() instead of checking the
>>> pointer
>>> against the NULL.
>>
>> Just one modification I'd suggest: make CvsAlert::ShowAlert a const
>> member function. That would allow streamlined code like e.g.
>> 	CvsAlert("Some message").ShowAlert();
>> for basic error messages.
>>
>> And another thing I noticed: there's a const std::string m_empty  
>> member
>> in the CvsAlert class, but IMO, this could be a static member and
>> shared between all instances of CvsAlert?
>
> </jum>
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------ Yahoo! Groups Sponsor  
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
> Printer at MyInks.com. Free s/h on orders $50 or more to the US &  
> Canada.
> http://www.c1tracking.com/l.asp?cid=5511
> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
> --------------------------------------------------------------------- 
> ~->
>
> To unsubscribe from this group, send an email to:
> [email protected]
>
>
>
> Your use of Yahoo! Groups is subject to  
> http://docs.yahoo.com/info/terms/
>
>
>
</jum>


[Non-text portions of this message have been removed]


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
Printer at MyInks.com. Free s/h on orders $50 or more to the US & Canada.
http://www.c1tracking.com/l.asp?cid=5511
http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/