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/