Re: GtkFileChooser problem

[rbd <rbd soest hawaii edu>]

Hi all,

I have done some further experimentation with regard to my GtkFileChooser 
problem and discovered that the piece of my code that seems to be 
triggering this problem is the call to gtk_file_chooser_set_current_name() 
-- if I remove that then I do not get the error described in my last 
message.

Looking closer at the documentation I see a statement that says this 
function should not be used when an existing file is being specified, so I 
will take responsibility for ignoring that warning. I have to say, 
however, that this seems to me to be an unacceptable restriction -- why 
shouldn't I be able to initialize the text entry field at the top of the 
dialog to a completely clear and unambiguous presentation of the default 
name that will be returned by the dialog? And, why does a 
GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER dialog which is supposedly designed 
to work with either pre-existing or yet-to-be-created filesystem objects 
(i) try to create something that already exists and then (ii) complain 
when that creation attempt fails, whether or not I call 
gtk_file_chooser_set_current_name() to set the text entry field?

I have noticed other inconsistent and weird behavior in the UI of this 
widget through my further experimentation today:

(1) When I do use gtk_file_chooser_set_current_name() to initialize the 
text entry field as shown in my original code, when I click the dialog's 
OK response button I get the error I have described. But if instead of 
clicking that button I activate the cursor in the text entry field and hit 
RETURN (without making any change to that field), everything works fine. 
Why is only clicking the OK button problematic?

(2) Independently of whether or not I use 
gtk_file_chooser_set_current_name() to initialize the text entry field to 
the name of a pre-existing current working directory (CWD), I have noticed 
that the OK response button will often be grayed out (and hence 
unclickable) even when the final path component of that CWD is selected in 
the dialog's large directory contents subwindow when the dialog is first 
mapped. Often I can fix this only by clicking on different directory 
contents subwindow objects (i.e., other subdirectories), perhaps several 
times, and then re-clicking on the subdirectory object which corresponds 
to my CWD (and which was originally selected). Only then does the OK 
response button get activated and become clickable.

I can appreciate that this widget may require a complicated 
implementation, and that in particular it may be difficult to properly 
correlate the text entry field with the directory contents subwindow. I 
have to say, however, that I think it would be worthwhile to get rid of 
the confusing limitations and behaviors noted above.

If there is further documentation on these issues somewhere that would 
help me to understand and avoid them better I would very much like to see 
it.

Thanks!

Roger Davis
Univ. of Hawaii