Camillo Bruni-3 wrote
> Just image that the UIManager should also work on the CommandLine
After browsing UICommandLineManager>>#chooseFrom:lines:title:, I see where
we are headed - mimicking the headful interactions via stdin/out. Very cool!
Camillo Bruni-3 wrote
> Returning any window on UIManager is wrong I think, we should only define
> the
> request interface there
In light of the above, I agree that returning a window doesn't make sense.
And, "defining the request interface" seems okay for simple requests like
the one above, but for e.g. selecting from the filesystem, there are just
too many options. We already have 8 such messages in UIManager and it
doesn't expose all the combinations. I think in cases of this complexity, it
would be better to return a helper object, so client code could write:
UIManager default fileChooser
title: 'Choose Xyz';
selectDirectory: myDefaultDirectory;
openInWorld. "maybe a generic #open would be nicer"
which would return FileDialogWindow for Morphic, or for the command line, a
polymorphic object interacting via stdin/out. My main point is that
FileDialogWindow already defines an API for selecting files and it's
wasteful and error-prone to duplicate it in UIManager.
Does that approach sound better?
-----
Cheers,
Sean
--
View this message in context:
http://forum.world.st/UI-Mess-tp4710579p4710601.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
