I’ve just added the initial experimental file chooser & saver modal dialogs to the Tools package.
Please try them out and find bugs or places where things could be nicer. If they work out we can replace a fair bit of really ugly code.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Original Sin is hard to find, but the digitally enhanced version is readily available.
Things I already know would be nice enhancements -
multi-column list for the filenames - name/size/date, sortable by clicking on the label of the column initial state for the saver to be just the text field and a more-here indicator that would open the directory tree/file list views add handling of any serverDirectories in use
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim To succeed in politics, it is often necessary to rise above your principles.
On 28-10-2017, at 3:02 PM, tim Rowledge tim@rowledge.org wrote: initial state for the saver to be just the text field and a more-here indicator that would open the directory tree/file list views
Trying to make a dialogwindow paneMorph accept a sequence of morphs and lay them out is proving wierd. And the spec side of dealing with a dialog window seems to need a fair bit of work too, since we’re not really using (so far as I can tell) any of the ‘standard’ buttons provided. As best I can work out for the moment the resizing of the child morphs gets manipulated by the dialog, no matter what I wanted them to be.
Indeed I’m not completely convinced I should be trying to do this via ToolBuilder anyway since it does seem to restrict that range of actions a bit. Maybe the better way is to have a plain Morph built dialog and use UiManager to decide on whether we make a morph or an mvc widget.
Since I can’t find any example code that actually uses dialogs with changing children morphs, I have to ask if anyone has actually done it before?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IML: Invoke Murphy's Laws
On 31-10-2017, at 3:50 AM, Bob Arning arning315@comcast.net wrote:
here's a made-up example
Thanks Bob; a nice illustration of the sort of thing I want to get. I think that you’ve demonstrated that the building of PluggableDialogWindow combined with my attempt to fit ‘my’ bits within the paneMorph oddity are an issue. I’ll see if I can build a simple illustrative example of that.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Cave ne ante ullas catapultas ambules = If I were you, I wouldn't walk in front of any catapults.
On 31-10-2017, at 10:37 AM, tim Rowledge tim@rowledge.org wrote:
I’ll see if I can build a simple illustrative example of that.
Pardon the delay but it was a busy night (Lasers!!!!) and afternoon (flying!) but finally here is a trivialised example of the current issue with using a child-building-selector with ToolBuilder and PluggableDialogWindow.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RDRI: Rotate Disk Right Immediate
Here is a version (revised to work in 5.1) that fixes your layout problem
On 11/2/17 12:21 AM, tim Rowledge wrote:
On 31-10-2017, at 10:37 AM, tim Rowledge tim@rowledge.org wrote: I’ll see if I can build a simple illustrative example of that.
Pardon the delay but it was a busy night (Lasers!!!!) and afternoon (flying!) but finally here is a trivialised example of the current issue with using a child-building-selector with ToolBuilder and PluggableDialogWindow.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RDRI: Rotate Disk Right Immediate
On 02-11-2017, at 4:01 AM, Bob Arning arning315@comcast.net wrote:
Here is a version (revised to work in 5.1) that fixes your layout problem
Yup, sticking a panel in there makes the layout work better; but by doing that we don’t have a working children update since that relies on the paneMorph having the children.. well actually I guess one could make the getChildWidget method return the children wrapped in morph and so on. I’ll try it later.
As a work-around it’s plausible but it doesn’t lead to an explanation of what on earth is making it go wrong in the first place. The paneMorph is a BorderedMorph instance with corner grips, which in itself seems a bit odd - I mean, why a set of grips wrapped around the inner content? It’s not like using them to resize the dialog actually works properly - try increasing the size and then reducing it. Better to do that with the more ordinary window resizing grips. What about the BorderedMorph is breaking the submorph layout? Maybe I’ll try out changing the paneMorph as well.
The only actual usage of the children->symbol pattern is in FileList where it is used for the file type specific button row; but that is within a panel and not the ‘fake panel’ provided in DialogWindow.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VDP: Violate Design Parameters
On 11/2/17 4:45 PM, tim Rowledge wrote:
On 02-11-2017, at 4:01 AM, Bob Arning arning315@comcast.net wrote:
Here is a version (revised to work in 5.1) that fixes your layout problem
Yup, sticking a panel in there makes the layout work better; but by doing that we don’t have a working children update since that relies on the paneMorph having the children.. well actually I guess one could make the getChildWidget method return the children wrapped in morph and so on. I’ll try it later.
As a work-around it’s plausible but it doesn’t lead to an explanation of what on earth is making it go wrong in the first place. The paneMorph is a BorderedMorph instance with corner grips, which in itself seems a bit odd - I mean, why a set of grips wrapped around the inner content?
in #buildPluggableDialog:
widget paneMorph wantsPaneSplitters ifTrue: [ widget paneMorph addCornerGrips"addEdgeGrips". widget paneMorph grips do: [:ea | ea drawCornerResizeHandles: true]].
this offers the ability to resize the submorphs of the paneMorph like you resize the panes in a browser
It’s not like using them to resize the dialog actually works properly - try increasing the size and then reducing it. Better to do that with the more ordinary window resizing grips. What about the BorderedMorph is breaking the submorph layout?
#buildPluggablePanel: does self setLayout: aSpec layout in: widget. #buildPluggableDialog: does *not* do the same for its paneMorph
Maybe I’ll try out changing the paneMorph as well.
The only actual usage of the children->symbol pattern is in FileList where it is used for the file type specific button row; but that is within a panel and not the ‘fake panel’ provided in DialogWindow.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VDP: Violate Design Parameters
On 02-11-2017, at 2:19 PM, Bob Arning arning315@comcast.net wrote: The paneMorph is a BorderedMorph instance with corner grips, which in itself seems a bit odd - I mean, why a set of grips wrapped around the inner content? in #buildPluggableDialog:
widget paneMorph wantsPaneSplitters ifTrue: [ widget paneMorph addCornerGrips"addEdgeGrips". widget paneMorph grips do: [:ea | ea drawCornerResizeHandles: true]].
this offers the ability to resize the submorphs of the paneMorph like you resize the panes in a browser
Absolutely - allowing movable splitters between sub-morphs of the pane is a good idea. Putting drag-handles on the corners of the panemorph doesn’t seem quite as useful since the dialog is (properly, in my view) shrinkwrapped around its content and so the drag-handles usurp the normal window border dragging (which admittedly seems to be turned off for dialogs, which is probably not so good) and worst of all, it doesn’t work very well. It looks like one of the other morphs involved is not resizing horizontally when you reduce the width, so you get a narrower panemorph but the window as a whole stays at the larger width.
It’s not like using them to resize the dialog actually works properly - try increasing the size and then reducing it. Better to do that with the more ordinary window resizing grips. What about the BorderedMorph is breaking the submorph layout?
#buildPluggablePanel: does self setLayout: aSpec layout in: widget. #buildPluggableDialog: does *not* do the same for its paneMorph
Hmm, interesting. I just added that and it makes the very plausible difference. Nice catch.
Other observations to throw into the mix - PluggableDialogSpec over-rides #horizontalResizing and #verticalResizing to insist both are #rigid, which puzzles me. Versions suggests both are Marcel choices - do you remember why Marcel? Ah, well that’s fun; if I remove that over-ride so I can have #shrinkWrap for the vertical resizing of my panemorph, then all the ‘normal’ dialogs used for the ListChoosers are broken. Despite the code appearing to add the size/split handles, they don’t actually appear, which is odd until you notice that the #update: method which is used to get the child morphs removes all the submorphs before fetching the new ones - asnd so carefully deletes the handles. Blerk.
Y’know, there are time when I think we’ve managed to make a lot of broken code.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Business ethics
Amongst other ‘fun’ issues, I can’t seem to spot how to make an input field have a sensible height - ie one that gives the chosen font decent room whilst not being far too large. (This is via ToolBuilder operations by the way, not raw morph access. )
If I make the panemorph of a dialogwindow have a vResizing of #shrinkWrap instead of the forced #rigid previously mentioned then I can set the listDirection to vertical and add an input field and a list and even get them is the right sort of places. Unfortunately there are then two curious problems: a) the list size is stupid unless I force a minimumSize: XXX on the spec b) the input field is 2 pixels high even if I *do* give it a minimumimum size.
I’d have thought it would make sense for an input field to default to a vertical size based on the font, since pretty much the by-definition purpose is to allow a single short line of text input. And similarly I would have thought that a list might benefit from an easy way to specify a minimum height (and may maximum?) based on a number of lines.
What I’m trying to do now (getting well away from my original quest for a nicer snapshot/quit dialog) is make the typical users of pluggabledialog work even when the panemorph size is not fudged. It would be nice to have the ListChooser look good for a short list of senders/implementors (by shrinking vertically a bit) instead of the somewhat clunky (mis)use of the dialogwindow buttons - something that really ticks me when the code decides to make horizontal buttons instead of vertical. Also it would be nice for ListChooser to be able to grow a bit vertically when there is a long list to show, without going berserk and making a screen height monster.
Right now I’m thinking the dialog stuff needs some fairly serious rework. I don;t want to just tromp all over it a break other people’s stuff though, so if you’ve been using PluggableDialogWindow etc, let me know where/how/what-for. Or if you have idea for improving it.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Daddy, what does FORMATTING DRIVE C mean?"
Attached is something a bit closer to the target. It's not clear to me if the ToolBuilder is intended to do what you want here. I supports a subset of Morphic and sometimes even ignores its own specs, so it will solve some problems rather easily and others, perhaps, not at all. Remind me why you are interested in using the ToolBuilder.
On 11/3/17 5:07 PM, tim Rowledge wrote:
Amongst other ‘fun’ issues, I can’t seem to spot how to make an input field have a sensible height - ie one that gives the chosen font decent room whilst not being far too large. (This is via ToolBuilder operations by the way, not raw morph access. )
If I make the panemorph of a dialogwindow have a vResizing of #shrinkWrap instead of the forced #rigid previously mentioned then I can set the listDirection to vertical and add an input field and a list and even get them is the right sort of places. Unfortunately there are then two curious problems: a) the list size is stupid unless I force a minimumSize: XXX on the spec b) the input field is 2 pixels high even if I *do* give it a minimumimum size.
I’d have thought it would make sense for an input field to default to a vertical size based on the font, since pretty much the by-definition purpose is to allow a single short line of text input. And similarly I would have thought that a list might benefit from an easy way to specify a minimum height (and may maximum?) based on a number of lines.
What I’m trying to do now (getting well away from my original quest for a nicer snapshot/quit dialog) is make the typical users of pluggabledialog work even when the panemorph size is not fudged. It would be nice to have the ListChooser look good for a short list of senders/implementors (by shrinking vertically a bit) instead of the somewhat clunky (mis)use of the dialogwindow buttons - something that really ticks me when the code decides to make horizontal buttons instead of vertical. Also it would be nice for ListChooser to be able to grow a bit vertically when there is a long list to show, without going berserk and making a screen height monster.
Right now I’m thinking the dialog stuff needs some fairly serious rework. I don;t want to just tromp all over it a break other people’s stuff though, so if you’ve been using PluggableDialogWindow etc, let me know where/how/what-for. Or if you have idea for improving it.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Daddy, what does FORMATTING DRIVE C mean?"
On 03-11-2017, at 8:13 PM, Bob Arning arning315@comcast.net wrote:
Attached is something a bit closer to the target.
A bit closer, yeah, but it’s just plain wrong that we need to add a panel inside a morph that is supposed to be a sorta-panel. I mean, yes, make it work and all but a tool intended to be a major part of the system ought to make this stuff simple and intelligible.
It's not clear to me if the ToolBuilder is intended to do what you want here. I supports a subset of Morphic and sometimes even ignores its own specs, so it will solve some problems rather easily and others, perhaps, not at all. Remind me why you are interested in using the ToolBuilder.
Because it’s supposed to be the tool builder for common tools, I guess. Sure we could go with the make-a-morph widget and let UiManager split between morph and mvc and whatever but it seems counter to the aim I think ToolBuilder was supposed to have - making the common tools in a way that allowed them to be built for any plausible framework. Flexible modal dialogues seem like something we ought to handle nicely. If it takes extending the toolbuilder then I guess I’d say we should do just that.
In the beginning this is all about wanting to make the snapshot saveas nicer. We need to do that to make more sense in the all-in-one system, where saving to the original place is nonsensical. There’s quite a lot of places where a dialogue with the options of lists, buttons, inputs etc make sense and it would be nice to do it well.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Resistance is useless! (If << 1 ohm)
My hunch is that one major way things are made simple and intelligible is by limiting the choices available. Increasing the choices available probably probably comes at the expense of simplicity. I can look in the image and see what the things ToolBuilder is currently doing reasonably well, but I get no sense of how far it was intended to go. Is it for building tools? What is a tool? Is a fileChooser a tool? Is a spreadsheet a tool? How about Photoshop? Seems like you draw a line somewhere and say things on the left belong to TB and things on the right are done another way. OR, you say the goal of TB is to manage the creation of every pixel on the screen. I'm wondering if your fileChooser is perhaps to the right of a plausibly drawn line. Hard to answer that without knowing what the fileChooser ends up being. One approach would be to get it working to your satisfaction in Morphic and then ask the question of how much TB would need to change to take over the job. Make it work then make it right, ya know?
On 11/4/17 7:44 PM, tim Rowledge wrote:
A bit closer, yeah, but it’s just plain wrong that we need to add a panel inside a morph that is supposed to be a sorta-panel. I mean, yes, make it work and all but a tool intended to be a major part of the system ought to make this stuff simple and intelligible.
On 04-11-2017, at 5:47 PM, Bob Arning arning315@comcast.net wrote:
My hunch is that one major way things are made simple and intelligible is by limiting the choices available. Increasing the choices available probably probably comes at the expense of simplicity.
Yup. The trick is to find a way for the simple to use tool to do the things you need. Which if you think about it is pretty much the major job of engineering.
I can look in the image and see what the things ToolBuilder is currently doing reasonably well, but I get no sense of how far it was intended to go. Is it for building tools? What is a tool? Is a fileChooser a tool? Is a spreadsheet a tool? How about Photoshop?
Just imagine if it had been nicely documented…
Seems like you draw a line somewhere and say things on the left belong to TB and things on the right are done another way. OR, you say the goal of TB is to manage the creation of every pixel on the screen. I'm wondering if your fileChooser is perhaps to the right of a plausibly drawn line. Hard to answer that without knowing what the fileChooser ends up being.
I think I want to see the toolbuilder able to handle all the widgets that seem sensible for building applications; so not an entire photoshop UI perhaps but certainly file loading/saving dialogs, choices for this and that. I suppose one wouldn’t expect to include complex image processing specific widgets necessarily but it ought to be possible to add them if you want.
One of the nice aspects of toolbuilder is the way it provides clear widget options - ask for a button and you get a button without having to check out every damn button related morph class - did you know there are *40* classes with ‘button’ in the name?
One approach would be to get it working to your satisfaction in Morphic and then ask the question of how much TB would need to change to take over the job. Make it work then make it right, ya know?
Point.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never forget: 2 + 2 = 5 for extremely large values of 2.
That's the lack of options I was talking about. What if one of those 40 that TB did *not* give you was just the ticket? That said, you can probably make a quick list of the morphs *does* use and consider that your Beginner's Guide to Morphic. Then maybe add a few more morphs that seem particularly useful.
On 11/4/17 9:04 PM, tim Rowledge wrote:
One of the nice aspects of toolbuilder is the way it provides clear widget options - ask for a button and you get a button without having to check out every damn button related morph class - did you know there are *40* classes with ‘button’ in the name?
Hi, there.
Here is some context about the current state of Squeak's dialog implementation.
Last year, I worked on UI themes and hence touched the sources of all relevant widgets. In the course of understanding and changing the existing implementations, I took the opportunity to clean-up and simplify things. The biggest construction sites included windows, menus, buttons, and dialogs. The biggest clean-up was a consistent use of the #setDefaultParameters-pattern, which has been there for a long time.
Until then, Squeak has had three kinds of dialogs: FillInTheBlankMorph, UserDialogBoxMorph, and SystemWindows that where "modal children" of other system windows. I merged the first two kinds and harmonized their visual appearance.
...became...
I largely ignored system windows that where effectively treated as dialogs, which is (1) modal ownership and sometimes (2) modally exclusive user input. Two common candidates of these are the font-chooser dialog and the file/folder-chooser dialog:
As you can see, a conversion to a visual dialog-like appearance might entail some changes in DialogWindow and PluggableDialogWindow(Spec). Yet, I think there are still (1) title, (2) description, (3) opt. resizable content, and (4) a button bar --- like in all other dialogs. One could even think of making those modally exclusive ... but the need for copying necessary information from another morph to fulfill the dialogs request is too common.
Why do I write this? A dialog is no regular window because: 1. It poses a single request and therefore looks different. 2. It is modal in a sense that it can (a) belong to a window/dialog and (b) interrupt a complex job with user input and (c) closing it means aborting a job not just closing a view on objects. 3. It has a programming interface that is more like "request" and not like "open/show".
Consequently, file/folder choosers and font choosers should be real dialogs: code-wise and graphics-wise:
Simple user requests don't need interactive content. Some might not have a description but only that content. Some might only have a title and the buttons. The message of title / description is debatable. I think that titles should be more generic like "Choose file" and descriptions should be more context specific to explain what kind of file is required. So that titles can be one-lines and descriptions be multi-liners.
Best, Marcel
Am 05.11.2017 02:19:45 schrieb Bob Arning arning315@comcast.net: That's the lack of options I was talking about. What if one of those 40 that TB did *not* give you was just the ticket? That said, you can probably make a quick list of the morphs *does* use and consider that your Beginner's Guide to Morphic. Then maybe add a few more morphs that seem particularly useful.
On 11/4/17 9:04 PM, tim Rowledge wrote:
One of the nice aspects of toolbuilder is the way it provides clear widget options - ask for a button and you get a button without having to check out every damn button related morph class - did you know there are *40* classes with ‘button’ in the name?
...oh, I almost forgot the list choosers:
... became ...
... and ...
... and ...
But the very last is only a workaround for the existing abuse of pop-up menus for what should have been done by a drop-down list widget, which we do not have at the moment. :-)
Best, Marcel
Am 05.11.2017 12:57:23 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi, there.
Here is some context about the current state of Squeak's dialog implementation.
Last year, I worked on UI themes and hence touched the sources of all relevant widgets. In the course of understanding and changing the existing implementations, I took the opportunity to clean-up and simplify things. The biggest construction sites included windows, menus, buttons, and dialogs. The biggest clean-up was a consistent use of the #setDefaultParameters-pattern, which has been there for a long time.
Until then, Squeak has had three kinds of dialogs: FillInTheBlankMorph, UserDialogBoxMorph, and SystemWindows that where "modal children" of other system windows. I merged the first two kinds and harmonized their visual appearance.
...became...
I largely ignored system windows that where effectively treated as dialogs, which is (1) modal ownership and sometimes (2) modally exclusive user input. Two common candidates of these are the font-chooser dialog and the file/folder-chooser dialog:
As you can see, a conversion to a visual dialog-like appearance might entail some changes in DialogWindow and PluggableDialogWindow(Spec). Yet, I think there are still (1) title, (2) description, (3) opt. resizable content, and (4) a button bar --- like in all other dialogs. One could even think of making those modally exclusive ... but the need for copying necessary information from another morph to fulfill the dialogs request is too common.
Why do I write this? A dialog is no regular window because: 1. It poses a single request and therefore looks different. 2. It is modal in a sense that it can (a) belong to a window/dialog and (b) interrupt a complex job with user input and (c) closing it means aborting a job not just closing a view on objects. 3. It has a programming interface that is more like "request" and not like "open/show".
Consequently, file/folder choosers and font choosers should be real dialogs: code-wise and graphics-wise:
Simple user requests don't need interactive content. Some might not have a description but only that content. Some might only have a title and the buttons. The message of title / description is debatable. I think that titles should be more generic like "Choose file" and descriptions should be more context specific to explain what kind of file is required. So that titles can be one-lines and descriptions be multi-liners.
Best, Marcel
Am 05.11.2017 02:19:45 schrieb Bob Arning arning315@comcast.net: That's the lack of options I was talking about. What if one of those 40 that TB did *not* give you was just the ticket? That said, you can probably make a quick list of the morphs *does* use and consider that your Beginner's Guide to Morphic. Then maybe add a few more morphs that seem particularly useful.
On 11/4/17 9:04 PM, tim Rowledge wrote:
One of the nice aspects of toolbuilder is the way it provides clear widget options - ask for a button and you get a button without having to check out every damn button related morph class - did you know there are *40* classes with ‘button’ in the name?
Thanks for reminding me about this one. It so bothers me that I have just reverted my image to the old MenuMorph implementation.
On 11/5/17 7:20 AM, Marcel Taeumel wrote:
... and ...
But the very last is only a workaround for the existing abuse of pop-up menus for what should have been done by a drop-down list widget, which we do not have at the moment. :-)
On 05-11-2017, at 3:57 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote: Last year, I worked on UI themes and hence touched the sources of all relevant widgets. In the course of understanding and changing the existing implementations, I took the opportunity to clean-up and simplify things.
Always a good thing to do, and mostly it worked pretty well.
The biggest construction sites included windows, menus, buttons, and dialogs. The biggest clean-up was a consistent use of the #setDefaultParameters-pattern, which has been there for a long time.
Just goes to show how complex a lot of this has become - I haven’t even noticed that in all the spelunking I’ve been doing on this.
Until then, Squeak has had three kinds of dialogs: FillInTheBlankMorph, UserDialogBoxMorph, and SystemWindows that where "modal children" of other system windows. I merged the first two kinds and harmonized their visual appearance.
That works well as a concept. I like the ‘fairly generic’ dialogue idea with optional bits that make it simple to build specific dialogues as needed. Where I am seeing problems is with some less common aspects that ought to work.
For example, the panemorph is used as if it were a panel morph that can swap out its contents as part of an update message, but clearly it isn’t actually working very well. The BorderedMorph is initially set up to have resize handles, which kinda-sorta works as a UI thing except that some other part of the dialog structure prevents the window from shrinking, even if you try to shrink it back after stretching. Similarly if the BorderedMorph gets re-childed by the update it loses the resize handles which is sub-optimal. And something about the layout related settings prevents adding child morphs in a way that is consistent with typical usage. We’re also not really taking advantage of some stuff in the dialogwindow class, in that buttons get ‘manually’ added even though there is a somewhat nicer way to add them; this is largely something that could be improved in the toolbuilder code I think.
I largely ignored system windows that where effectively treated as dialogs, which is (1) modal ownership and sometimes (2) modally exclusive user input. Two common candidates of these are the font-chooser dialog and the file/folder-chooser dialog:
As you can see, a conversion to a visual dialog-like appearance might entail some changes in DialogWindow and PluggableDialogWindow(Spec). Yet, I think there are still (1) title, (2) description, (3) opt. resizable content, and (4) a button bar --- like in all other dialogs.
I think that font/style choosing and file load/save dialogues should exists and be modal and in the general style of the simpler dialogues, which is why I’ve been making the new file load/save dialog things using the dialogwindow class(es). There is also a place for non-modal equivalents of some of those sorts of dialog - I suppose at that point they should be called something else - as tools that can be kept open to affect fonts/styles/colours/etc or even embedded in some bigger context as part of a tool (photoSqueakShop, anyone?).
One could even think of making those modally exclusive ... but the need for copying necessary information from another morph to fulfill the dialogs request is too common.
Sorry, don’t understand what you mean there.
Why do I write this? A dialog is no regular window because:
- It poses a single request and therefore looks different.
- It is modal in a sense that it can (a) belong to a window/dialog and (b) interrupt a complex job with user input and (c) closing it means aborting a job not just closing a view on objects.
- It has a programming interface that is more like "request" and not like "open/show”.
I mostly agree here. I suspect that there is some terminology confusion in that dialog and modal window get mixed quite thoroughly in many contexts. Simple requests for a string or simple choice from a few buttons and so on are pretty clearly candidates for a ModalDialogWidget but a modal doohickey for choosing a place to save a snapshot shares many aspects even though it will be a much more complex UI.
Maybe we can find a nice refactoring that helps us to encompass the full range. I initially tried working with the PluggableDialogWindow stuff because it looked like a reasonably clean approach through ToolBuilder and perhaps that wasn’t the best way.
Consequently, file/folder choosers and font choosers should be real dialogs: code-wise and graphics-wise:
a) That’s pretty much what I’m aiming for b) I’d say that dialogues - as in widgets opened modally from some other UI that must be used or closed before it can proceed - ought not have the window title stuff, to avoid confusion. They’re not regular windows, let’s not have them look like regular windows. c) we should make them open in a sensible place more often; we can put them anywhere so let’s make it easy to put them where the user’s attention lies. The prime example of bad placing is the save/quit confirmation dialog.
Simple user requests don't need interactive content. Some might not have a description but only that content. Some might only have a title and the buttons. The message of title / description is debatable. I think that titles should be more generic like "Choose file" and descriptions should be more context specific to explain what kind of file is required. So that titles can be one-lines and descriptions be multi-liners.
This is all true but doesn’t really need to affect the outer layers. The addition of lists to a simple [a bit of text] [buttonA] [buttonB] doesn’t require a completely different class.
If we had it arranged [optional title text] [optional inner ui] [row of buttons] then I think we’d be covered for pretty much everything. After all the only essential part of a dialog type UI is at least one button!
And you’re dead right about the need for a proper drop-down menu for implementors/senders type usage. It would, in combination with the Browser button bar, allow for much better factoring of those huge menus I was complaining about.
So now the only major question is what we want to do and who can take part in doing it?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A computer scientist is someone who fixes things that aren't broken.
If a dialog asks you for a URL and that thing is in a workspace window nearby, it should be possible to copy that to the clipboard w/o having to close the dialog. Modally exclusive dialogs wouldn't allow that.
You do not have to use the tool builder to construct your save dialog. Actually, I suggest not to use tool builder for know until you know what you want. Just put it in a subclass of DialogWindow.
Best, Marcel Am 05.11.2017 19:31:44 schrieb tim Rowledge tim@rowledge.org:
On 05-11-2017, at 3:57 AM, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote: Last year, I worked on UI themes and hence touched the sources of all relevant widgets. In the course of understanding and changing the existing implementations, I took the opportunity to clean-up and simplify things.
Always a good thing to do, and mostly it worked pretty well.
The biggest construction sites included windows, menus, buttons, and dialogs. The biggest clean-up was a consistent use of the #setDefaultParameters-pattern, which has been there for a long time.
Just goes to show how complex a lot of this has become - I haven’t even noticed that in all the spelunking I’ve been doing on this.
Until then, Squeak has had three kinds of dialogs: FillInTheBlankMorph, UserDialogBoxMorph, and SystemWindows that where "modal children" of other system windows. I merged the first two kinds and harmonized their visual appearance.
That works well as a concept. I like the ‘fairly generic’ dialogue idea with optional bits that make it simple to build specific dialogues as needed. Where I am seeing problems is with some less common aspects that ought to work.
For example, the panemorph is used as if it were a panel morph that can swap out its contents as part of an update message, but clearly it isn’t actually working very well. The BorderedMorph is initially set up to have resize handles, which kinda-sorta works as a UI thing except that some other part of the dialog structure prevents the window from shrinking, even if you try to shrink it back after stretching. Similarly if the BorderedMorph gets re-childed by the update it loses the resize handles which is sub-optimal. And something about the layout related settings prevents adding child morphs in a way that is consistent with typical usage. We’re also not really taking advantage of some stuff in the dialogwindow class, in that buttons get ‘manually’ added even though there is a somewhat nicer way to add them; this is largely something that could be improved in the toolbuilder code I think.
I largely ignored system windows that where effectively treated as dialogs, which is (1) modal ownership and sometimes (2) modally exclusive user input. Two common candidates of these are the font-chooser dialog and the file/folder-chooser dialog:
As you can see, a conversion to a visual dialog-like appearance might entail some changes in DialogWindow and PluggableDialogWindow(Spec). Yet, I think there are still (1) title, (2) description, (3) opt. resizable content, and (4) a button bar --- like in all other dialogs.
I think that font/style choosing and file load/save dialogues should exists and be modal and in the general style of the simpler dialogues, which is why I’ve been making the new file load/save dialog things using the dialogwindow class(es). There is also a place for non-modal equivalents of some of those sorts of dialog - I suppose at that point they should be called something else - as tools that can be kept open to affect fonts/styles/colours/etc or even embedded in some bigger context as part of a tool (photoSqueakShop, anyone?).
One could even think of making those modally exclusive ... but the need for copying necessary information from another morph to fulfill the dialogs request is too common.
Sorry, don’t understand what you mean there.
Why do I write this? A dialog is no regular window because: 1. It poses a single request and therefore looks different. 2. It is modal in a sense that it can (a) belong to a window/dialog and (b) interrupt a complex job with user input and (c) closing it means aborting a job not just closing a view on objects. 3. It has a programming interface that is more like "request" and not like "open/show”.
I mostly agree here. I suspect that there is some terminology confusion in that dialog and modal window get mixed quite thoroughly in many contexts. Simple requests for a string or simple choice from a few buttons and so on are pretty clearly candidates for a ModalDialogWidget but a modal doohickey for choosing a place to save a snapshot shares many aspects even though it will be a much more complex UI.
Maybe we can find a nice refactoring that helps us to encompass the full range. I initially tried working with the PluggableDialogWindow stuff because it looked like a reasonably clean approach through ToolBuilder and perhaps that wasn’t the best way.
Consequently, file/folder choosers and font choosers should be real dialogs: code-wise and graphics-wise:
a) That’s pretty much what I’m aiming for b) I’d say that dialogues - as in widgets opened modally from some other UI that must be used or closed before it can proceed - ought not have the window title stuff, to avoid confusion. They’re not regular windows, let’s not have them look like regular windows. c) we should make them open in a sensible place more often; we can put them anywhere so let’s make it easy to put them where the user’s attention lies. The prime example of bad placing is the save/quit confirmation dialog.
Simple user requests don't need interactive content. Some might not have a description but only that content. Some might only have a title and the buttons. The message of title / description is debatable. I think that titles should be more generic like "Choose file" and descriptions should be more context specific to explain what kind of file is required. So that titles can be one-lines and descriptions be multi-liners.
This is all true but doesn’t really need to affect the outer layers. The addition of lists to a simple [a bit of text] [buttonA] [buttonB] doesn’t require a completely different class.
If we had it arranged [optional title text] [optional inner ui] [row of buttons] then I think we’d be covered for pretty much everything. After all the only essential part of a dialog type UI is at least one button!
And you’re dead right about the need for a proper drop-down menu for implementors/senders type usage. It would, in combination with the Browser button bar, allow for much better factoring of those huge menus I was complaining about.
So now the only major question is what we want to do and who can take part in doing it?
tim -- tim Rowledge; tim@rowledge.org [mailto:tim@rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim] A computer scientist is someone who fixes things that aren't broken.
On 06-11-2017, at 12:12 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
If a dialog asks you for a URL and that thing is in a workspace window nearby, it should be possible to copy that to the clipboard w/o having to close the dialog. Modally exclusive dialogs wouldn't allow that.
I think that argues for a different level of modal, one based on the originating window/application, and yes it would be very useful. How could we do that?
Could it be as simple as locking the originating window so it gets no events passed to it? A quick test by inspecting a random browser and locking it suggests it might be a good starting point. Obviously that won’t be enough if there are several windows involved but I guess if you are making an application like that you will probably be tracking multiple windows anyway and have some idea of what to do. I wonder if system modal widgets might be done by locking the top pasteupmorph… ehh, probably it would interfere with the dialog getting any events unless we did something drastic like adding a new top layer morph blahblahblah. I can certainly lock the World, wait 5 secs and unlock it, so maybe there is a way.
You do not have to use the tool builder to construct your save dialog. Actually, I suggest not to use tool builder for know until you know what you want. Just put it in a subclass of DialogWindow.
Oh, I know, but I actually thought that what I wanted was so simple and obvious that it should be easy. Hopefully it will be easy sometime soon.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Legally drunk
For now, you can "un-modal" every modal dialog via the menu in the upper right corner. Should work for the careful user. :-)
Best, Marcel Am 06.11.2017 18:45:52 schrieb tim Rowledge tim@rowledge.org:
On 06-11-2017, at 12:12 AM, Marcel Taeumel wrote:
If a dialog asks you for a URL and that thing is in a workspace window nearby, it should be possible to copy that to the clipboard w/o having to close the dialog. Modally exclusive dialogs wouldn't allow that.
I think that argues for a different level of modal, one based on the originating window/application, and yes it would be very useful. How could we do that?
Could it be as simple as locking the originating window so it gets no events passed to it? A quick test by inspecting a random browser and locking it suggests it might be a good starting point. Obviously that won’t be enough if there are several windows involved but I guess if you are making an application like that you will probably be tracking multiple windows anyway and have some idea of what to do. I wonder if system modal widgets might be done by locking the top pasteupmorph… ehh, probably it would interfere with the dialog getting any events unless we did something drastic like adding a new top layer morph blahblahblah. I can certainly lock the World, wait 5 secs and unlock it, so maybe there is a way.
You do not have to use the tool builder to construct your save dialog. Actually, I suggest not to use tool builder for know until you know what you want. Just put it in a subclass of DialogWindow.
Oh, I know, but I actually thought that what I wanted was so simple and obvious that it should be easy. Hopefully it will be easy sometime soon.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Legally drunk
On Mon, Nov 6, 2017 at 9:45 AM, tim Rowledge tim@rowledge.org wrote:
On 06-11-2017, at 12:12 AM, Marcel Taeumel marcel.taeumel@hpi.de
wrote:
If a dialog asks you for a URL and that thing is in a workspace window
nearby, it should be possible to copy that to the clipboard w/o having to close the dialog. Modally exclusive dialogs wouldn't allow that.
I think that argues for a different level of modal, one based on the originating window/application, and yes it would be very useful. How could we do that?
Could it be as simple as locking the originating window so it gets no events passed to it? A quick test by inspecting a random browser and locking it suggests it might be a good starting point.
Maybe the 'model dialog' is instead always on top of the calling outer most morph that isn't the world (or project)?
Or make modal be 'always on top' in Squeak? The other windows are still active - you can't can't hide the model morph. Or a slight variation - always on top, but tied to the calling morph. If the calling morph is a system window that could be minimized, it would also minimize the modal morph; similar with un-minimize. As long as the modal isn't minimized, it is on top, too.
-cbc
On 11/5/17, Bob Arning arning315@comcast.net wrote:
My hunch is that one major way things are made simple and intelligible is by limiting the choices available.
+1
This is the aim of ToolBuilder.
Increasing the choices available probably probably comes at the expense of simplicity. I can look in the image and see what the things ToolBuilder is currently doing reasonably well,
+1
but I get no sense of how far it was intended to go. Is it for building tools? What is a tool? Is a fileChooser a tool? Is a spreadsheet a tool? How about Photoshop? Seems like you draw a line somewhere and say things on the left belong to TB and things on the right are done another way. OR, you say the goal of TB is to manage the creation of every pixel on the screen. I'm wondering if your fileChooser is perhaps to the right of a plausibly drawn line. Hard to answer that without knowing what the fileChooser ends up being.
One approach would be to get it working to your satisfaction in Morphic and then ask the question of how much TB would need to change to take over the job. Make it work then make it right, ya know?
Yes. A useful (intermediate only?) goal is to get a reworked and configurable FileChooser/SaverDialog dialog and have duplication of code removed (FileList2). Not necessarily done with ToolBuilder [1].
--Hannes
[1] ToolBuilder http://wiki.squeak.org/squeak/5607
On 11/4/17 7:44 PM, tim Rowledge wrote:
A bit closer, yeah, but it’s just plain wrong that we need to add a panel inside a morph that is supposed to be a sorta-panel. I mean, yes, make it work and all but a tool intended to be a major part of the system ought to make this stuff simple and intelligible.
On 07-11-2017, at 12:09 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
Yes. A useful (intermediate only?) goal is to get a reworked and configurable FileChooser/SaverDialog dialog and have duplication of code removed (FileList2). Not necessarily done with ToolBuilder [1].
Take a look at FileChooserDialog/FileSaverDialog and see if it works for you. Any ideas for test cases, improvements, whatever, happily considered. Currently I’d describe the visuals as very plain but adequate. I think the file list ought to be a three column view with sort-order buttons at the top of each, for example.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The colder the X-ray table, the more of your body is required on it.
On 07-11-2017, at 9:49 AM, tim Rowledge tim@rowledge.org wrote: . I think the file list ought to be a three column view with sort-order buttons at the top of each, for example.
Turned out to be reasonably simple to hack a PluggableMultiColumnListMorph into ToolBuilder and make a decent 3 column file list. It *doesn’t* have any moving splitters, nor sorting buttons etc, both of which would be very nice. The PluggableMultiColumnListMorph does not seem to have had much love in many years and doesn’t get a lot of use that I can find. The horizontal scrolling appeared to not work, for example, and it looks like that is because someone decided to force it not to. Some futzing with LazyListMorph>>#hUnadjustedScrollRange and friends seems to have solved that (so far!) though the ‘double it just in case’ fudge at the end of the method makes it a bit ugly.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Sanitary landfill
On 11/7/17, tim Rowledge tim@rowledge.org wrote:
On 07-11-2017, at 12:09 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
Yes. A useful (intermediate only?) goal is to get a reworked and configurable FileChooser/SaverDialog dialog and have duplication of code removed (FileList2). Not necessarily done with ToolBuilder [1].
Take a look at FileChooserDialog/FileSaverDialog and see if it works for you.
Yes, I loaded it a few days ago (from where?). It worked fine and the ToolBuilder code is very readable.
The only problem I noticed is that the dialog is not resizable and this is what you have been discussing so far in this thread.
The folder or dirrectory hierarchy is not fully visible if you have long directory names. Maybe just using a scroll pane for the directory hierarchy would be sufficient.
Any ideas for test cases, improvements, whatever, happily considered. Currently I’d describe the visuals as very plain but adequate. I think the file list ought to be a three column view with sort-order buttons at the top of each, for example.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The colder the X-ray table, the more of your body is required on it.
On 08-11-2017, at 1:44 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
The only problem I noticed is that the dialog is not resizable and this is what you have been discussing so far in this thread.
Yup, this is due to the slightly odd use of the BorderedMorph with resize handles (rather than the over all window having resize ability) combined with how the submorphs of the BorderedMorph (which included those resize handles….) get completely replaced when the directory/file views get added.
The folder or dirrectory hierarchy is not fully visible if you have long directory names. Maybe just using a scroll pane for the directory hierarchy would be sufficient.
I get a horizontal scroller for the directory tree - do you?
Here’s a changeset (since the changes cover several packages and I don’t want to update them pointlessly) that adds the multi-column filelist. If anyone can see how to add movable splitters that would be nice to know. DItto the sort on a column stuff.
Based on 17447 update level so beware if you are at a very different state.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Foolproof operation: All parameters are hard coded.
OK, for the brave, here is a version that ties saveAs… to a new file saver dialog.
I’ve succeeded in making it scan directories for filenames somewhat less frequently, which speeds up opening a bit on slower machines. I’m not a big fan of the way the directory tree is handled; I don’t see why we would really go up to the root(s) [1] and then show all its subdirectories and then open & show everything on the path back down to where our default directory is. Might it not be nicer to show only the path upwards and the current directory? Or some other less expensive operation?
tim [1] On some systems finding all the plausibly connected roots can be a very slow operation involving spinning up CD drives etc to test for an inserted disc or whatever.
-- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: VDP: Violate Design Parameters
And now the dialogs are in the latest packages *except* for the hooking up to saveAs…
To try that out, simply edit
SmalltalkImage>getFileNameFromUserSuggesting: aName "Ask the user for a new image name" | newName | newName := UIManager default filenameSaverRequest: 'New File Name?' translated initialAnswer: aName. newName ifNil: [^nil]. ((FileDirectory default fileOrDirectoryExists: (self fullNameForImageNamed: newName)) or: [FileDirectory default fileOrDirectoryExists: (self fullNameForChangesNamed: newName)]) ifTrue: [ (self confirm: ('{1} already exists. Overwrite?' translated format: {newName})) ifFalse: [^nil]]. ^newName
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- FUI GENERIS - What's mine is mine
For the saveAs operation, I would want to be able to edit the default file name, and that appears in the edit box at the top of the FileSaver window, so this is good. I also might want to save in a different directory, and the directory navigator on the lower left side lets me do that, also good.
If I highlight a specific file on the lower right side, that becomes the new suggested file name in the top edit box. This makes sense if the file I select is foo.image but not if it is foo.changes or foo.cs or foo.txt.
I think that I would expect the dialog (lower right side) to present only the file names that I can legitimately select (because they end in '.image'). Or I would expect it to "grey out" the entries that I am not permitted to use, such that only file names that end in '.image' can be highlighted and thus moved into the top file name edit box.
I think I would also expect the suggested file name that initially appears in the top edit box to also be highlighted in the panels below. If my current image name is 'foo.image' then I would expect 'foo.image' to appear both in the edit box on the top, and also as the selected file in the lower right navigator pane. Then, if I navigate to another directory and select some other file named 'bar.image', I expect 'bar.image' to appear in the text edit box at the top. But if I navigate to a directory and select 'bar.st', I expect the FileSave to say "I'm sorry Dave, I'm afraid I can't do that".
Dave
On Fri, Nov 10, 2017 at 04:39:46PM -0800, tim Rowledge wrote:
And now the dialogs are in the latest packages *except* for the hooking up to saveAs???
To try that out, simply edit
SmalltalkImage>getFileNameFromUserSuggesting: aName "Ask the user for a new image name" | newName | newName := UIManager default filenameSaverRequest: 'New File Name?' translated initialAnswer: aName. newName ifNil: [^nil]. ((FileDirectory default fileOrDirectoryExists: (self fullNameForImageNamed: newName)) or: [FileDirectory default fileOrDirectoryExists: (self fullNameForChangesNamed: newName)]) ifTrue: [ (self confirm: ('{1} already exists. Overwrite?' translated format: {newName})) ifFalse: [^nil]]. ^newName
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- FUI GENERIS - What's mine is mine
By the way I should say that I meant this as constructive input from a user's first impression point of view, I have not actually looked at any of the code. I just pasted in Tim's getFileNameFromUserSuggesting snippet to see what it looks like when I do an image "save as". It looks good, and I am just trying to offer my dumb-user first reactions.
Dave
On Fri, Nov 10, 2017 at 08:53:59PM -0500, David T. Lewis wrote:
For the saveAs operation, I would want to be able to edit the default file name, and that appears in the edit box at the top of the FileSaver window, so this is good. I also might want to save in a different directory, and the directory navigator on the lower left side lets me do that, also good.
If I highlight a specific file on the lower right side, that becomes the new suggested file name in the top edit box. This makes sense if the file I select is foo.image but not if it is foo.changes or foo.cs or foo.txt.
I think that I would expect the dialog (lower right side) to present only the file names that I can legitimately select (because they end in '.image'). Or I would expect it to "grey out" the entries that I am not permitted to use, such that only file names that end in '.image' can be highlighted and thus moved into the top file name edit box.
I think I would also expect the suggested file name that initially appears in the top edit box to also be highlighted in the panels below. If my current image name is 'foo.image' then I would expect 'foo.image' to appear both in the edit box on the top, and also as the selected file in the lower right navigator pane. Then, if I navigate to another directory and select some other file named 'bar.image', I expect 'bar.image' to appear in the text edit box at the top. But if I navigate to a directory and select 'bar.st', I expect the FileSave to say "I'm sorry Dave, I'm afraid I can't do that".
Dave
On Fri, Nov 10, 2017 at 04:39:46PM -0800, tim Rowledge wrote:
And now the dialogs are in the latest packages *except* for the hooking up to saveAs???
To try that out, simply edit
SmalltalkImage>getFileNameFromUserSuggesting: aName "Ask the user for a new image name" | newName | newName := UIManager default filenameSaverRequest: 'New File Name?' translated initialAnswer: aName. newName ifNil: [^nil]. ((FileDirectory default fileOrDirectoryExists: (self fullNameForImageNamed: newName)) or: [FileDirectory default fileOrDirectoryExists: (self fullNameForChangesNamed: newName)]) ifTrue: [ (self confirm: ('{1} already exists. Overwrite?' translated format: {newName})) ifFalse: [^nil]]. ^newName
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- FUI GENERIS - What's mine is mine
On 10-11-2017, at 5:53 PM, David T. Lewis lewis@mail.msen.com wrote:
For the saveAs operation, I would want to be able to edit the default file name, and that appears in the edit box at the top of the FileSaver window, so this is good. I also might want to save in a different directory, and the directory navigator on the lower left side lets me do that, also good.
That is the idea.
If I highlight a specific file on the lower right side, that becomes the new suggested file name in the top edit box. This makes sense if the file I select is foo.image but not if it is foo.changes or foo.cs or foo.txt.
Yes, for the case where one knows what kind of file is being saved it should be limiting the options - I *think* that would work with setting the pattern appropriately. The saver doesn’t currently use the pattern at all. I suppose we’d want to parse and ‘correct’ any typed in filename to match that limit. Suggestions on expected behaviour welcomed.
There’s probably a case for allowing a no-new-file or no-old-file test too; at least to the extent that trying to choose an existing file can raise a warning of the ‘are you sure?’ kind.
I think that I would expect the dialog (lower right side) to present only the file names that I can legitimately select (because they end in '.image'). Or I would expect it to "grey out" the entries that I am not permitted to use, such that only file names that end in '.image' can be highlighted and thus moved into the top file name edit box.
Perhaps solvable in the same changes as above?
I think I would also expect the suggested file name that initially appears in the top edit box to also be highlighted in the panels below. If my current image name is 'foo.image' then I would expect 'foo.image' to appear both in the edit box on the top, and also as the selected file in the lower right navigator pane. Then, if I navigate to another directory and select some other file named 'bar.image', I expect 'bar.image' to appear in the text edit box at the top. But if I navigate to a directory and select 'bar.st', I expect the FileSave to say "I'm sorry Dave, I'm afraid I can't do that”.
I made it highlight any file matching the typed in name but maybe it isn’t working for the initial startup. Ah, nope.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim No, I don't explode cats. It's way too difficult to coax them into the microwave - http://tinyurl.com/yp3hgr
On 10-11-2017, at 5:53 PM, David T. Lewis lewis@mail.msen.com wrote: If I highlight a specific file on the lower right side, that becomes the new suggested file name in the top edit box. This makes sense if the file I select is foo.image but not if it is foo.changes or foo.cs or foo.txt.
I think that I would expect the dialog (lower right side) to present only the file names that I can legitimately select (because they end in '.image'). Or I would expect it to "grey out" the entries that I am not permitted to use, such that only file names that end in '.image' can be highlighted and thus moved into the top file name edit box.
I added setting a pattern list in the creation methods and it works ok; I’d prefer to have the file list able to show everything and grey out the invalid ones but that’s a job for anyone wanting to improve the multicolumn list stuff.
What is eluding me right now is a good heuristic to handle a typed in filename that doesn’t match the pattern. Obviously we can do what we want in the #inputText: method to test the proposed name but I’m just blanking on what that might be. Test against the list of patterns I suppose is a start … and what it if doesn’t? What’s the way to tell an input field to sound the klaxons and flash disaster-red to alert the user that they are an idiot?
I think I would also expect the suggested file name that initially appears in the top edit box to also be highlighted in the panels below. If my current image name is 'foo.image' then I would expect 'foo.image' to appear both in the edit box on the top, and also as the selected file in the lower right navigator pane.
OK, easily fixed and definitely an improvement.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RDRI: Rotate Disk Right Immediate
The latest status of the File dialogs is in the alpha trunk as of 17544 and details, plus a filein to hook them up to ‘normal’ file choose/save methods is downloadable from http://wiki.squeak.org/squeak/2758
Please give it a try and report problems. Next step would be to see about replacing the horrible StandardFileMenu stuff.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: HALT: No-Op
that will work. example attached (needed one change to PluggableDialogWindow)
On 11/2/17 4:45 PM, tim Rowledge wrote:
Yup, sticking a panel in there makes the layout work better; but by doing that we don’t have a working children update since that relies on the paneMorph having the children.. well actually I guess one could make the getChildWidget method return the children wrapped in morph and so on. I’ll try it later.
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
Chris Cunningham -
David T. Lewis -
H. Hirzel -
Marcel Taeumel -
tim Rowledge