Spec dynamic layout without dynamic widgets

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Spec dynamic layout without dynamic widgets

hernanmd
Hi guys,

A comment from building Spec layouts for widgets (Pharo 6 but maybe
applicable to Pharo >= 7): I have built a Spec widget which could have
two layouts: #buttonsOnTopSpec and #buttonsOnBottomSpec :

SpcLabeledActionsList new
   openWithSpec: #buttonsOnTopSpec;
   yourself.

SpcLabeledActionsList new
   openWithSpec: #buttonsOnBottomSpec;
   yourself.

Now if you would have to set such list as a widget in
#initializeWidgets, the building process follows its path to
#private_buildWithSpec which hardcodes the spec layout to the
#defaultSpecSelector (the one containing <spec: #default> pragma).

The problem subclassing from DynamicComposableModel / Presenter is
that is trying to solve two problems at once:

1) Dynamic adding/removing widgets
2) Dynamic configuration of layout

In this case I just need the 2), and I would have to remove inst. vars
and accessors in ~20 classes because the dynamic widgets dictionary
now stores all widgets, or interject a weirdo between
ComposableModel/Presenter and DynamicComposableModel/Presenter.

What would you do?

Cheers,

Hernán

Reply | Threaded
Open this post in threaded view
|

Re: Spec dynamic layout without dynamic widgets

Stephane Ducasse-3
Hi hernan

On Sat, Jan 13, 2018 at 10:31 PM, Hernán Morales Durand
<[hidden email]> wrote:

> Hi guys,
>
> A comment from building Spec layouts for widgets (Pharo 6 but maybe
> applicable to Pharo >= 7): I have built a Spec widget which could have
> two layouts: #buttonsOnTopSpec and #buttonsOnBottomSpec :
>
> SpcLabeledActionsList new
>    openWithSpec: #buttonsOnTopSpec;
>    yourself.
>
> SpcLabeledActionsList new
>    openWithSpec: #buttonsOnBottomSpec;
>    yourself.


We started to revisit Spec with Pavel and we got distracted. I really
think that Spec
needs a good pass to redesign some parts. You may encounter one missing hooks.
I should add the new hook that we introduce before forgetting.
And I should have a look at Peter attemps to rewritte the interpreter.


> Now if you would have to set such list as a widget in
> #initializeWidgets, the building process follows its path to
> #private_buildWithSpec which hardcodes the spec layout to the
> #defaultSpecSelector (the one containing <spec: #default> pragma).
>
> The problem subclassing from DynamicComposableModel / Presenter is
> that is trying to solve two problems at once:
>
> 1) Dynamic adding/removing widgets
> 2) Dynamic configuration of layout
>
> In this case I just need the 2), and I would have to remove inst. vars
> and accessors in ~20 classes because the dynamic widgets dictionary
> now stores all widgets, or interject a weirdo between
> ComposableModel/Presenter and DynamicComposableModel/Presenter.

Do you have the code somewhere because this is really a scenario that
dynamicModel
should support.
I'm thinking aloud... may be we should add a variable holding the spec
to be used
and the initializeWidgets should use it when set.

Does it make sense?


>
> What would you do?
>
> Cheers,
>
> Hernán
>

Reply | Threaded
Open this post in threaded view
|

Re: Spec dynamic layout without dynamic widgets

hernanmd
Hi Stef,

2018-01-14 8:53 GMT-03:00 Stephane Ducasse <[hidden email]>:

> Hi hernan
>
> On Sat, Jan 13, 2018 at 10:31 PM, Hernán Morales Durand
> <[hidden email]> wrote:
>> Hi guys,
>>
>> A comment from building Spec layouts for widgets (Pharo 6 but maybe
>> applicable to Pharo >= 7): I have built a Spec widget which could have
>> two layouts: #buttonsOnTopSpec and #buttonsOnBottomSpec :
>>
>> SpcLabeledActionsList new
>>    openWithSpec: #buttonsOnTopSpec;
>>    yourself.
>>
>> SpcLabeledActionsList new
>>    openWithSpec: #buttonsOnBottomSpec;
>>    yourself.
>
>
> We started to revisit Spec with Pavel and we got distracted. I really
> think that Spec
> needs a good pass to redesign some parts. You may encounter one missing hooks.
> I should add the new hook that we introduce before forgetting.
> And I should have a look at Peter attemps to rewritte the interpreter.
>

I think one of the challenges is to add support for a good layout
model (there was a thread about layout recently).

Or do you mean rewrite the interpreter for efficency issues?

>
>> Now if you would have to set such list as a widget in
>> #initializeWidgets, the building process follows its path to
>> #private_buildWithSpec which hardcodes the spec layout to the
>> #defaultSpecSelector (the one containing <spec: #default> pragma).
>>
>> The problem subclassing from DynamicComposableModel / Presenter is
>> that is trying to solve two problems at once:
>>
>> 1) Dynamic adding/removing widgets
>> 2) Dynamic configuration of layout
>>
>> In this case I just need the 2), and I would have to remove inst. vars
>> and accessors in ~20 classes because the dynamic widgets dictionary
>> now stores all widgets, or interject a weirdo between
>> ComposableModel/Presenter and DynamicComposableModel/Presenter.
>
> Do you have the code somewhere because this is really a scenario that
> dynamicModel
> should support.

Yep, you can install it in Pharo 6 with:

Metacello new
    smalltalkhubUser: 'hernan' project: 'SpecUIAddOns';
    configuration: 'SpecUIAddOns';
    version: #bleedingEdge;
    load: 'Core'

SpcEditableActionList example2.
SpcEditableActionList example3.

> I'm thinking aloud... may be we should add a variable holding the spec
> to be used
> and the initializeWidgets should use it when set.
>
> Does it make sense?
>

Yes, it does. I did something similar, but I don't want to touch
ComposableModel. So in the SpecUIAddOns I added a class
SpcDynamicLayoutPresenter holding a layoutSpecSelector which is used
in #private_buildWithSpec.

Cheers,

Hernán