Re: [XForms] file selector with callback

[Michal Szymanski]

Hi Jens,

> As I already wrote at least to me it looks to that selecting a
> directory should be handled by the program when in callback-mode,
> e.g. by simply calling fl_set_directory() (or do whatever else
> may make sense in that situation).
> 
> So I changed things so that (in callback-mode):
> 
> a) The directory name is now passed back to the program
>    tha invoked the file selector

If I noticed that properly (based on e.g. pmbrowse demo), the name WAS
passed to the callback (the application was complaining about the file
not being the valid image etc.), so that does not need a change (???)
What should be decided is whether the file selector itself should
"change to that directory" and display its contents or it should be left
entirely to the appliccation. Now it seems to be done inconsistently:
internally the FS changes the directory but only displays it after
Dismiss is clicked.

Personally I would vote for both: name is sent to the callback AND the
FS changes/displays the new directory by itself. Thus, the application
has the possibility to fully controll the user choice, including
directories and, at the same time, the user sees consistent behavior in
treating directories by FS, no matter with or without a callback. Also,
I guess that the great majority of cases with FS is to look for a
"plain" file: in that case the callback could just silently ignore the
directories returned from FS and wait for a "file".

> b) The 'Dismiss" button got renamed to "Close" and isn't
>    a FL_RETURN_BUTTON anymore but a FL_NORMAL_BUTTON.
>    It gets triggered by e.g. the <ESC> key.
> c) When you press <RETURN> with a line selected in the
>    browser this file (or directory) name gets passed
>    back to the calling program.

Sounds reasonable.

> Concerning the missing input field: We had an input field in
> older versions but it never had any effect at all for a file
> selector in callback mode, and that's why I threw it out. That
> it couldn't do anything was because the "Dismiss" button was
> triggered by <RETURN>, so there was no event at which anything
> from that input field could have been returned to the caller.
> I am now considering to enable it again and return it's con-
> tent (unless it's empty) back) to the caller when <RETURN>
> is pressed (if it's empty but something is selected in the
> browser I would return what's selected in the browser). Does
> that sound reasonable?

Again, fine for me.

Actually, IMHO, the FS should look pretty the same in both cases,
including RETURN button (which would return and close in non-CB case,
just return (the file name) in CB case). Possibly with Cancel changed to
Close. The real difference being actually only the "modality" (thanks
for explanation) and, obviously, the possibility to select many files
(in a sequence) without closing the FS window.

regards, Michal.
-- 
  Michal Szymanski (msz at astrouw dot edu dot pl)
  Warsaw University Observatory, Warszawa, POLAND