[squeak-dev] Merge Request: PluggableWidgetSpec >> #available

Marcel Taeumel marcel.taeumel at hpi.de
Tue Nov 23 10:34:46 UTC 2021


Hi Christoph --

This idea might be similar to what tree widgets have: #getChildren, #hasChildren. At least this is what you example suggested via #output and #outputAvailable.

The implementor of a tree widget expects #hasChildren to be cheaper than #getChildren and can hence consider this when providing visual cues (i.e., the triangle/chevron to expand a tree item).

***

Considering "dynamic content" ... well ... it's a different beast. Well, TableLayout can deal with it, but our tools mostly use ProportionalLayout, which is not so dynamic when hiding or showing widgets.

Hmm... it seems like you want to combine #visible and #disableLayout into a new operation and call that #available. That wording seems too close to #enabled, which we use in buttons/sliders.

***

-1

Here is what I would do:
- Split up this idea into (a) a new operation on all morphs and (b) support via MorphicToolBuilder
- Mayble think of your "available" as an extended version of "visible" ... which I called "fully visible" in Widgets/Vivide (i.e. #hideFull, #showFull)
- Before exposing this via ToolBuilder, think about how to make the commonly used ProportionalLayout more dynamic (because you can always build tools in Morphic the old-fashioned way without using the ToolBuilder)

I think that it is worth pursuing this (rather bigger) topic because we also wanted to have an expandable file-save dialog for quite some time now. Maybe this could be a useful example for this idea.

Best,
Marcel

Am 22.10.2021 20:18:24 schrieb christoph.thiede at student.hpi.uni-potsdam.de <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi all,

this changeset adds a new property to PluggableWidgetSpecs, #available. It can be used to show tool contents dynamically based on the result of a message send. Consider this toolbuilder method:

    ^ aBuilder pluggablePanelSpec new
        layout: #vertical;
        children: (OrderedCollection new
            add: (aBuilder pluggableTextSpec new
                model: self;
                getText: #input;
                setText: #input:;
                yourself);
            add: (aBuilder pluggableTextSpec new
                model: self;
                available: #outputAvailable;
                getText: #output;
                yourself);
            yourself)
        yourself

Demo: ["available.gif"]
Another helpful example could be dynamic displaying of a single button in a panel without needing to rebuild the entire panel (which is overhead and might remove relevant state).

Changeset summary:
- PluggableWidgetSpec >> #available[:] accessors
- getAvailableSelector accessors and relevant #update: logic for almost all Morphic tool-buildable widget classes such as PluggableButtonMorphPlus, PluggableListMorphPlus, etc.
- Patch in MorphicToolBuilder to set getAvailableSelector
- Morph >> #makeAvailable:: Shows/hides and enables/disables the layout of a morph at the same time. I often use this together; see [1 [https://forum.world.st/Morphic-equivalent-of-display-none-tp5114410p5114419.html]] for further information.
- DemoTool that you can see above for quick demonstration. In any case I think a very simple example for the toolbuilding method would not harm in the MorphicExtras-Demos category.

I request to review and merge or discuss this proposal. :-)

Note: I do *not* ask to hide many buttons in our default Trunk tools, which would be a major UX change which for sure would have many disadvantages. But I see some advantages in providing this behavior for other tools which follow different UX guidelines.

Best,
Christoph

[1] https://forum.world.st/Morphic-equivalent-of-display-none-tp5114410p5114419.html [https://forum.world.st/Morphic-equivalent-of-display-none-tp5114410p5114419.html]

---
Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211123/b9f74336/attachment-0001.html>


More information about the Squeak-dev mailing list