Migration from Spec to Spec2

On Jan 24, 2020, at 11:14 AM, Kasper Østerbye <[hidden email]> wrote:

 Cheers all,

There was a mail about Spec2 documentation on this list in the last few days. I had a Spec program, and wanted to see how to migrate it to Spec2. 

The before and after is the master and the Spec2Migration branches of: https://github.com/kasperosterbye/ovina

I decided to write down an account of all my struggles in making this migration. That account is on: https://github.com/kasperosterbye/ovina/blob/Spec2Migration/SpectoSpec2.md

Beware - it is LONG.

In the end, I draw the following conclusions:

• Class comments on which classes to use instead of the depricated ones should be mandatory!
• Spotter is a real help
• Changing terminology is a true pest - in particular since the terminology of a library is used in the applications - in my case Tab became Page.
• The new library has not yet implemented all parts of the old one (but I am sure it has implemented new stuff as well).
• The SpDemo class is not only good, it is a template for others to follow.
• Do not silently delete features. Be brave and include a method oddRowColor with a comment saying it is not going to be implemented in this version, and why.

Some of them refer to specifics of the code. 

Overall I can say, that earlier today, Estaban wrote:

"Widgets API is more or less compatible, chances are that your components will work out of the box or it will be rewritten by a deprecation rule.

What is not compatible and there I not auto migration is the layout. You will need to rewrite those.”

I am afraid to say, that was not my experience :-)

Best,

Kasper

Le 24 janv. 2020 à 20:14, Kasper Østerbye <[hidden email]> a écrit :

• Do not silently delete features. Be brave and include a method oddRowColor with a comment saying it is not going to be implemented in this version, and why

El 24 ene 2020, a las 21:52, Christophe Demarey <[hidden email]> escribió:

Hi Kasper,

Le 24 janv. 2020 à 20:14, Kasper Østerbye <[hidden email]> a écrit :

• Do not silently delete features. Be brave and include a method oddRowColor with a comment saying it is not going to be implemented in this version, and why

I add the same issue and I wrote a small fix for TablePresenter.

See https://github.com/pharo-project/pharo-launcher/commit/28fb65151a6341f26b912a1d2d1034779a49727d

I have only a few changes but I add to copy FTTableContainerMorph and FTSelectableMorph to add an instance variable on each. Except that, I had 4 methods to implement a basic row color alternance.

You can use it as follow in an SpPresenter:

self newTable

items: #(1 2 3);

whenBuiltDo: [ :table | table widget alternateRowsColor ]

I will try to do a PR next week for this.

Regards,

Christophe.

Le 27 janv. 2020 à 13:36, Guillermo Polito <[hidden email]> a écrit :

Be careful, this is no solution but a patch that will work in some cases only, it is an architectural violation.

Widgets should never be accessed from presenters directly.

The support for row color should be exposed from the presenter, and the widget should use it (if supported).

I remember with Pablo we did a POC to see how this would be supported both by Gtk and morphic and we kind of conclude that the row color should be specified in the datasource.

This allows each row (and cells in case of tables) to have its (their) own background color.

Gtk (and morphic too) then also have support for alternate row colors, but it is different.

While morphic’s depend on the underlying theme, in Gtk we can further specialize the colors.

See for example:

https://developer.gnome.org/gtk3/stable/GtkTreeView.html#GtkTreeView--s-even-row-color

I will try to do a PR next week for this.

Regards,

Christophe.

El 29 ene 2020, a las 9:08, Kasper Østerbye <[hidden email]> escribió:

Thanks for all the feedback on zebra stribes.

What I meant as the learning experience was not so much the stribes themselves, but the fact that I could not find them. The reason I could not find them is because they are not there. I knew that Spec2 is not completely done, so I am not surprised that they were not there.

What I meant to say was that a method “beZebraStriped” could be put in, with an error message saying “not implemented yet”. Then I could stop looking around. And that goes for any aspect not yet implemented.

Best,

Kasper