On Tuesday 30 October 2001 4:52 pm, John Levon wrote:
> On Tue, Oct 30, 2001 at 04:25:24PM +0100, Angus Leeming wrote:
>
> > * A better way to browse file lists.
> > Should be able to have multiple instances of the File Browser
> > open, connected to the dialog that posted the "Browse" request.
> >
> > They should not block future action, but should emit a signal when
> > there own Apply button is pressed.
> >
> > They should also control there own destruction. Ie, "hide" destroys
> > the dialog.
> > VAPOURWARE
>
> this already happens in Qt, maybe a little bit ugly though. The FileDialog
contrstructore
> takes a lyxfunc that is sent back to the main core on completion. A special
> _SYNC lyxfunc is used to indicate the core must wait for completion: fixing
> this can be done case-by-case.
Well, my idea was a little different. See what you think...
I press the "browse" button on a dialog.
This causes the dialog to create a FileBrowser instance:
Dialogs d_.showFileBrowser(BrowserParams const &);
When the FileBrowser Apply button is pressed it emits a signal
SigC::signal1<void, string const & returnedFile);
This signal is connected to a slot in the parent dialog (ie the one launching
the FileBrowser). Presumably, we could pass this info to the FileBrowser
through BrowserParams. If not, connect explicitly.
Dialogs::showFileBrowser is probably not a signal but a Dialogs method:
void Dialogs::showFileBrowser(BrowserParams const & bp) const
{
new GUIBrowser<FormsBrowser, xformsBC>(bp);
}
GUIBrowser controls its own destruction on hide().
That way we get totally async file browsing I think.
> Making xforms hadnle async requests shouldn't be too hard.
>
> > GUI-Independence) then drop me a line. I think we could go a long way to
> > finishing off a lot of the GUII stuff in the process.
>
> cool :)
Want some source code? I'm not going to play with this (honest!) till early
December by the look of things.
Angus
