FileChooser/SaverDialog

Am 05.11.2017 19:31:44 schrieb tim Rowledge <[hidden email]>:

On 05-11-2017, at 3:57 AM, Marcel Taeumel <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
A computer scientist is someone who fixes things that aren't broken.

Am 06.11.2017 18:45:52 schrieb tim Rowledge <[hidden email]>:

> 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; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Legally drunk