Jeffrey Stedfast wrote:
On Sat, 2003-09-27 at 09:45, Charles Zhang wrote:
Jeffrey Stedfast wrote:
attached is the correct fix.
appologies for including part of another patch, but I didn't feel like
separating them.
changing the bahaviour of the filesel dialog to not allow the user to
hit OK until a valid filename has been selected is:
1. inconsistant with the rest of gnome/evolution
2. confusing to the user (unless maybe you popped up a dialog to tell
them WHY OK wasn't working... either that or maybe gray out the OK
button until something valid has been input? but you'd also need to
handle the case where the user hits Enter in the entry box which has the
same effect as hitting OK)
Thank you, Jeffrey.
It should be my duty to complete it, but wasted you much time.
nah, don't worry about it.
I prefer popping up some dialog to explain some reason, with the filesel
dialog open, because it is convenient and the user can save much time
for it.
or you think this way of solving isn't inconsistant with the rest of
evolution either?
i wouldn't necessarily be against having the filesel dialog stay open
until the user entered a valid filename - but we shouldn't do this for
1.4.x.
unfortunately, I'm not sure we can actually manage to make all the
filesel dialogs behave this way, and so I think we should just make it
do what my patch does and leave it at that.
Thank you, Jeffrey.
You are more responsible and reliable than me.
Then do you think it is worthy making an experiment to test if we can
complete this prompting and behave with the dialog open?
the proper fix, attached below, fixes the error dialog shown to the user
so that it doesn't always show "file exists, overwrite?" even if that is
not the problem.
Jeff
On Fri, 2003-09-26 at 14:21, Jeffrey Stedfast wrote:
[snip]
And if it should be done this way,
Do you think it is necessary to merge these two parts as below?
no, because we don't care how the second dialog is closed, no matter
what we want to free the filename and abort.
But that's the same I think.
we use this condition of "if (resp != GTK_RESPONSE_YES) then {destroy,
return}", here only the first dialog can result a "GTK_RESPONSE_YES"
value.
In this way, we will get the same effect and result as yours, but
simpler and shorter.
The only shortcoming is that it's not clear enough.
What's your opinion?
[snip]
jeff
Best Regards
Charles Zhang
|
