Re: Re: CvsAlert changes

Karl-Heinz Brünen <[email protected]>
Newsgroups gmane.comp.version-control.cvs.gui.devel
Message-ID <[email protected]>
Hi,


Am Fre, den 12.12.2003 schrieb Jerzy Kaczorowski um 03:22:
> 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.
> 
> >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.

IMO the overloaded function seems to be the better solution. what do you
mean exactly with "neutral" alert 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.

That a good idea. There are two (or more) function doing the same thing.
E.g. gcvs uses AskYesNo (as all platforms) in AppGlue.cpp to post cvs
questions (Yes/No) and uses CvsAlert in UCvsFrame.cpp for query if a
running cvs should be stopped.

AFAICS the frontends use PromptMessage/PromptEditMessage only for Python
support

> 
> 
> >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 ;)

There are several HIG (human interface guideline) for different Linux
GUIs on the net. This links goes direct to the dialog/alert chapters.

Gnome:
http://developer.gnome.org/projects/gup/hig/1.0/windows.html#alert-windows

KDE:
http://developer.kde.org/documentation/standards/kde/style/dialogs/simple.html


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

Feel free to convert this. As you can see from the HIGs gnome apps
usually uses Ok/Cancel for questions. KDE prefers Yes/No. So you can see
we are absolut free on your choice. But as we uses GnomeToolKit for the
unix port, i think we should follow the gnome HIG. 

Much to my regret, i have to anounce, that we didn't follow the HIG yet.
I have a featuire request for that on my list. 
Perhaps if i got some time after implementing python support, i will
give it a try.


best Regards,

Kalle

> 
> Best Regards,
> Jerzy
> 
>                         Yahoo! Groups Sponsor
>                                           ADVERTISEMENT
>                                              click here
> 
> To unsubscribe from this group, send an email to:
> [email protected]
> 
> 
> 
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
-- 
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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.