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 |
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 > |
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 |
Free forum by Nabble | Edit this page |