We have FileDialogWindow, which is a cool little class which implements all the cool things you may want to do when selecting a file, for example: - answer either a directory, file, file entry, etc. - set an initial directory - set the sorting block Life is good. <rant> Then, we take the entire domain of opening files and cram it into UITheme's chooseXyzFileAbcIn:j:k:l: methods. UITheme is also a nice little class... with 570 instance methods... wait, wth! Okay, but forgetting polymorph's design for a moment... Then, we take the handful of options that UITheme gives us and funnel those through UIManager, which exposes... 3. So out of the entire domain of selecting files, we have three safe options available. This doesn't seem to work. </rant> Naively, it seems to me that much of the original power could be retained if things were reversed a bit. For example, instead of implementing file selection functionality in three places (FileDialogWindow, UITheme, and UIManager), could we do: 1. FileDialogWindow implements the API for selecting files 2. UITheme only returns an appropriately-themed object (wth are "services" doing in UITheme anyway?!) 3. UIManager subclasses return either (via e.g. "UIManager default fileDialogWindow"): a) The themed object or b) a Dummy object that no-ops #1's API I'd be willing to give it a try if any of that sounds promising or if someone has a better idea. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Mess-tp4710579.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On 2013-09-26, at 12:29, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
We have FileDialogWindow, which is a cool little class which implements all the cool things you may want to do when selecting a file, for example: - answer either a directory, file, file entry, etc. - set an initial directory - set the sorting block
Life is good.
<rant> Then, we take the entire domain of opening files and cram it into UITheme's chooseXyzFileAbcIn:j:k:l: methods. UITheme is also a nice little class... with 570 instance methods... wait, wth! Okay, but forgetting polymorph's design for a moment...
Then, we take the handful of options that UITheme gives us and funnel those through UIManager, which exposes... 3.
So out of the entire domain of selecting files, we have three safe options available.
This doesn't seem to work. </rant>
Naively, it seems to me that much of the original power could be retained if things were reversed a bit. For example, instead of implementing file selection functionality in three places (FileDialogWindow, UITheme, and UIManager), could we do:
1. FileDialogWindow implements the API for selecting files 2. UITheme only returns an appropriately-themed object (wth are "services" doing in UITheme anyway?!) 3. UIManager subclasses return either (via e.g. "UIManager default fileDialogWindow"): a) The themed object or b) a Dummy object that no-ops #1's API
I'd be willing to give it a try if any of that sounds promising or if someone has a better idea.
Just image that the UIManager should also work on the CommandLine, everything else I couldn't agree more ;). Returning any window on UIManager is wrong I think, we should only define the request interface there. Of corse the MorphicUIManager can have its internal helper method to return the request window to lower the load on UITHeme.
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.
Thanks, Sean, I'm happy that after Erwan suggestion of an issue, someone took charge of cleaning that :) My own position is that current Pharo has unified the filesystem issue with FileReference, and that I'm not impressed by moving ten variants of an API for choosing files from one class to another. But that's just me :) I think at the core we have a single method which returns FileReferences, and which has four parameters: title, start path, pattern, name (no need for an open). I'll move some of the API complexity in the pattern object, so that it may be able to make the distinction between files and directory, and of course extensions (with a reflective method to list the possible extensions). The pattern should be easy to create :), i.e. nil, '*.png', #isADirectory, whatever. All parameters may be nil, and like that there isn't any dependency on Morphic or the command line. answer := UIManager default chooseFileReference: 'Select a file' path: aFileReference pattern: '*.png' name: nil (name: is for those Save As dialogs where you already have a pre-existing file name) Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Sean P. DeNigris [sean@clipperadams.com] Date d'envoi : jeudi 26 septembre 2013 20:24 Ã : pharo-dev@lists.pharo.org Objet : Re: [Pharo-dev] UI Mess 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.
Goubier Thierry wrote
answer := UIManager default chooseFileReference: 'Select a file' path: aFileReference pattern: '*.png' name: nil
I can't tell if that captures the full options of fileDialogWindow without a bit more investigation, but that would be a great improvement over the current mess. I feel that whatever we do should be coupled with moving the open/answer logic into that single entry point and out of UITheme. UITheme should only provide the morph. ----- Cheers, Sean -- View this message in context: http://forum.world.st/UI-Mess-tp4710579p4710620.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 26/09/2013 21:54, Sean P. DeNigris a écrit :
Goubier Thierry wrote
answer := UIManager default chooseFileReference: 'Select a file' path: aFileReference pattern: '*.png' name: nil
I can't tell if that captures the full options of fileDialogWindow without a bit more investigation, but that would be a great improvement over the current mess. I feel that whatever we do should be coupled with moving the open/answer logic into that single entry point and out of UITheme. UITheme should only provide the morph.
I'd do a change for a single entry point in UIManager, the theme also providing a single entry point for creating the dialog. Sounds doable without many changes to the dialog code itself. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
On 2013-09-26, at 15:50, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Thanks, Sean, I'm happy that after Erwan suggestion of an issue, someone took charge of cleaning that :)
My own position is that current Pharo has unified the filesystem issue with FileReference, and that I'm not impressed by moving ten variants of an API for choosing files from one class to another. But that's just me :)
I think at the core we have a single method which returns FileReferences, and which has four parameters: title, start path, pattern, name (no need for an open). I'll move some of the API complexity in the pattern object, so that it may be able to make the distinction between files and directory, and of course extensions (with a reflective method to list the possible extensions). The pattern should be easy to create :), i.e. nil, '*.png', #isADirectory, whatever. All parameters may be nil, and like that there isn't any dependency on Morphic or the command line.
answer := UIManager default chooseFileReference: 'Select a file' path: aFileReference pattern: '*.png' name: nil
(name: is for those Save As dialogs where you already have a pre-existing file name)
I would also say that spans over the most common options. Convert #pattern: to #filter: which takes a block over the shown file reference and you can implement almost everything ;)
Le 27/09/2013 01:14, Camillo Bruni a écrit :
On 2013-09-26, at 15:50, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Thanks, Sean, I'm happy that after Erwan suggestion of an issue, someone took charge of cleaning that :)
My own position is that current Pharo has unified the filesystem issue with FileReference, and that I'm not impressed by moving ten variants of an API for choosing files from one class to another. But that's just me :)
I think at the core we have a single method which returns FileReferences, and which has four parameters: title, start path, pattern, name (no need for an open). I'll move some of the API complexity in the pattern object, so that it may be able to make the distinction between files and directory, and of course extensions (with a reflective method to list the possible extensions). The pattern should be easy to create :), i.e. nil, '*.png', #isADirectory, whatever. All parameters may be nil, and like that there isn't any dependency on Morphic or the command line.
answer := UIManager default chooseFileReference: 'Select a file' path: aFileReference pattern: '*.png' name: nil
(name: is for those Save As dialogs where you already have a pre-existing file name)
I would also say that spans over the most common options. Convert #pattern: to #filter: which takes a block over the shown file reference and you can implement almost everything ;)
The block idea is good, but I'd prefer something that the GUI can query for some information, such as the list of file patterns (which is often listed in those file open, file save as dialog boxes). Hence the FilePattern idea. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
If you remember a while ago I was thinking that the theme could be managed like settings (ie encapsulated in the widgets and that the widgets could encapsulate their default for theme), but sadly I was wrong because a theme oftn requires specific computation. So probably we should have a widget and some object that represents the theme strategy. Ideally I would like to get rid of the UIManager theme idea but this is difficult and it requires a bit of prototyping. So if one of you want to try to see on a typical case how a design could work. It would be really great. Setf
For the theme idea, I allways have in mind the structure used in VisualWorks which is to have decorator wrappers (and a few specifics like scrollbars) for each theme, and the core GUI stays the same. Morphs aren't designed that way (except for scrollbars) so it looks harder. But maybe composing would work (a morph may have a border and delegates some behavior to the border: drawing, bounds, etc... Changing the theme would mean changing the border class. In a few cases, it would mean changing the morph class completely (i.e. scrollbars)). Designing and testing that sounds like long, hard work :( For the UIManager theme thing, I would couple that to Smalltalk, something as simple as : Smalltalk ui (command line or gui) and: Smalltalk ui theme (if someone want to write an ascii-art Morphic theme :)) (I used to write dialog boxes and menu bars in ascii for a VT100 terminal a long, long time ago). Thierry Le 26/09/2013 22:14, Stéphane Ducasse a écrit :
If you remember a while ago I was thinking that the theme could be managed like settings (ie encapsulated in the widgets and that the widgets could encapsulate their default for theme), but sadly I was wrong because a theme oftn requires specific computation. So probably we should have a widget and some object that represents the theme strategy. Ideally I would like to get rid of the UIManager theme idea but this is difficult and it requires a bit of prototyping. So if one of you want to try to see on a typical case how a design could work. It would be really great.
Setf
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (5)
-
Camillo Bruni -
GOUBIER Thierry -
Goubier Thierry
-
Sean P. DeNigris -
Stéphane Ducasse