FileChooser/SaverDialog

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; [hidden email]; 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; [hidden email]; 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 <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IML: Invoke Murphy's Laws

here's a made-up example

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?

> On 31-10-2017, at 3:50 AM, Bob Arning <[hidden email]> 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; [hidden email]; 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 <[hidden email]> 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; [hidden email]; 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 31-10-2017, at 10:37 AM, tim Rowledge [hidden email] 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RDRI: Rotate Disk Right Immediate

> On 02-11-2017, at 4:01 AM, Bob Arning <[hidden email]> 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; [hidden email]; 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 <[hidden email]> 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

that will work. example attached (needed one change to PluggableDialogWindow)

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.

> On 02-11-2017, at 2:19 PM, Bob Arning <[hidden email]> 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; [hidden email]; 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; [hidden email]; 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.

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; [hidden email]; http://www.rowledge.org/tim
"Daddy, what does FORMATTING DRIVE C mean?"

> On 03-11-2017, at 8:13 PM, Bob Arning <[hidden email]> 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; [hidden email]; 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?

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 <[hidden email]> 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; [hidden email]; 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.

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.

... 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. :-)