Re: Re: CvsAlert changes

Am Fre, den 12.12.2003 schrieb Jens Miltner um 10:13:
> Am 12.12.2003 um 03:22 schrieb Jerzy Kaczorowski:
> 
> > Jens,
> >
> >> I'd prefer not to try and guess the default button, but rather
> >> always have the OK button the default button.
> >
> > It may be a little bit dangerous. The current logic is assuming a  
> > single OK
> > button for a note type of message and Cancel default button for  
> > question and
> > error messages. The OK will be default for warnings. That choices
> seem  
> > quite
> > reasonable to me at the moment but I am open for discussion here.
> 
> I don't think it's too dangerous: after all there's already an alert  
> popping up, that should be break enough to let the user reflect the  
> action.
> Personally, I find it most annoying if the default behaviour gets in  
> the way of an efficient workflow in the majority of situations...
> If a question is really critical, the calling code should know and
> make  
> sure the default button is the cancel button, but IMHO, for most  
> situations, the fact that an alert requires _some_ input is alert  
> enough so users don't have to toggle away from the default behavior,  
> but just can press Enter to continue.
> (BTW: If users decide to not read an alert, it's their own fault,
> IMO!)
> 
> Think about moving a file to the trash: this is a reversible
> operation  
> (except for maybe gCvs, which immediately removes the file), so OK is 
> perfectly justifiable in that question.

Perhaps there is a possibility to use the 'Move to Trash' functions from
gnome/kde to move the file before removing it. But I have no knowledge
about that yet. This should be something for the todo list.

> 
> And again: I'd rather avoid having the type of the alert decide which 
> buttons should be default. This can create problems on the long run,
> if  
> e.g. someone decides an alert would rather be a warning than a
> question  
> sometime later:
> e.g. someone writes code that questions "Something is wrong with your 
> files. Do you want to continue importing them?" as a question dialog  
> (i.e. Cancel is default). Later on, someone decides this is really a  
> warning rather than a question. -> violà, the default button suddenly 
> is "OK" unless whoever changes the alert type remembers this side  
> effect...
> In general, I think, side effects should be avoided at all costs (and 
> yes, my original suggestion for platform specific default buttons is  
> almost as bad a side effect :-| ).
> 
> If CvsAlert always has a specific default button (I'd vote for "OK",  
> but no matter what, it should not depend on the alert type), then you 
> wouldn't have to remember to adjust the default button when just  
> changing the alert type...
> 
> >
> >> Instead, we might introduce a subclass of CvsAlert, e.g.
> >> CvsCriticalQuestion that will take a message as argument and
> >> make the cancel button the default. That would be just as
> >> convenient, but would leave some defined behavior in the base
> class.
> >
> > I think we don't need to make a new class for that. I have two
> ideas  
> > here:
> >
> > 1. Change our kCvsAlertIconType and for example add two question
> types  
> > to
> > control the default button. That would make sense as it would
> indicate  
> > the
> > importance of the message at the calling place. But we have to  
> > remember not
> > to introduce too many of these to avoid confusion.
> >
> > 2. Create an overload or change the signature of
> CvsAlert::ShowAlert  
> > method
> > and pass the default button there. E.g. overload:
> >
> > kCvsAlertButtonType ShowAlert(const kCvsAlertButtonType
> defaultButton)
> > {
> >     m_defaultButton = defaultButton;
> >     return ShowAlert();
> > }
> >
> > Somehow I like the overload more that having the default parameter  
> > added to
> > the current method. If we used the default parameter we would
> probably  
> > have
> > to define the "neutral" alert button type to indicate that we want
> to  
> > keep
> > the one selected in constructor.
> >
> > Any of the above allows to override an automatically selected
> default  
> > button
> > quite easily.
> 
> Yes, (2) sounds good.
> I'd just suggest to move the real ShowAlert implementation into a  
> virtual protected member (e.g. _ShowAlert) and have the overloaded  
> ShowAlert members call that virtual member with the appropriate
> default  
> button parameter. In that case, the guessing of the default button  
> would move to the ShowAlert() member that doesn't specify the default 
> button...
> 
> >
> >> P.S: I changed the Mac implementation of AskYesNo and
> >> ConfirmMessage to use CvsAlert and I think this could probably
> >> become cross-platform (except for a small portion in AskYesNo
> >> where MacCvs makes sure the log window is visible and frontmost
> >> so it can be read behind the alert).
> >
> > Just FYI: I am planning to eliminate the AskYesNo and place the code
> > directly into the AppGlue where it's called. After all it's just a  
> > couple of
> > lines and doesn't deserve to be a function!
> >
> > I want to limit the number of functions doing essentially the same  
> > thing -
> > showing the alert message. The next candidate is obviously  
> > PromptMessage and
> > maybe even PromptEditMessage.
> 
> I wouldn't mind moving the AskYesNo stuff into the AppGlue, since  
> apparently that's the only place where it's used, but please remember 
> that there's some additional code in there for the Mac implementation 
> that makes sure the log window is visible, not minimized and the
> front  
> window before showing the alert, so users can actually see what the  
> alert refers to. When you move the code, please make sure this goes  
> along ;-)
> 
> >
> >> O.k., I've conditionalized the code to set up the button titles
> >> in MoveToTrash code. (Confirmation dialogs should just never
> >> ask with "Yes" / "No" on the Mac according to the UI guidelines)
> >
> > Can you provide some link to those guidelines? (sounds like I
> better  
> > read
> > that before my next move ;)
> 
> see here:
> <http://developer.apple.com/documentation/UserExperience/Conceptual/
> OSXHIGuidelines/XHIGDialogs/chapter_17_section_2.html#//apple_ref/doc/
> uid/20000962/CJECBHJE>
> 
> (this is the part about dialog & alert general guidelines - you can
> use  
> the "Previous Page", "Next Page" or "Show TOC" links to see more of
> the  
> HI guidelines)
> 
> >
> > In fact if Kalle agrees we could all use the OK/Cancel for moving
> to  
> > trash
> > question. Even thought the Window OS uses Yes/No for the same I can 
> > see how
> > it can be more intuitive with OK/Cancel.
> 
> Whatever seems to match best with what users are used to on the  
> platform, I'd suggest. As I said, alerts with "Yes" and "No" buttons  
> look awkward to Mac users, just as "OK" and "Cancel" may seem strange 
> in this context to Windows users (I don't know, I'm not one of them
> ;-)
> 
> </jum>

best regards,

Kalle
-- 
Karl-Heinz Brünen <[email protected]>


------------------------ 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/