Migration from Spec to Spec2
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
Thank you for blazing that trail.
On Jan 24, 2020, at 11:14 AM, Kasper Ãsterbye <kasper.osterbye@gmail.com> 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 <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 <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
Hi Kasper,
Le 24 janv. 2020 à 20:14, Kasper Ãsterbye <kasper.osterbye@gmail.com> 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/28fb65151a6341f26b912... 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.
El 24 ene 2020, a las 21:52, Christophe Demarey <christophe.demarey@inria.fr> escribió:
Hi Kasper,
Le 24 janv. 2020 à 20:14, Kasper Ãsterbye <kasper.osterbye@gmail.com <mailto:kasper.osterbye@gmail.com>> 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/28fb65151a6341f26b912... <https://github.com/pharo-project/pharo-launcher/commit/28fb65151a6341f26b912...> 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 ]
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... <https://developer.gnome.org/gtk3/stable/GtkTreeView.html#GtkTreeView--s-even...>
I will try to do a PR next week for this.
Regards, Christophe.
Le 27 janv. 2020 à 13:36, Guillermo Polito <guillermopolito@gmail.com> a écrit :
Be careful, this is no solution but a patch that will work in some cases only, it is an architectural violation.
Yes, true. I needed the functionality fast and was proposed to use this solution as workaround for now. For now, there is no clear strategy how to support alternate colors right both for morphic / gtk.
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).
Yes :) I do not know if there is a plan to support this soon. Maybe it is not part of the presenter api but rather the style?
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... <https://developer.gnome.org/gtk3/stable/GtkTreeView.html#GtkTreeView--s-even...>
I will try to do a PR next week for this.
Regards, Christophe.
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
Yeap, sorry Kasper, I was more concentrated on answering to Christophe than to you ^^.
El 29 ene 2020, a las 9:08, Kasper Ãsterbye <kasper.osterbye@gmail.com> 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.
Well, this could be done only for features supported by old spec but not new spec, right? Otherwise this would require foreseeing all possible features before implementing them. Take also into account that even if Spec1 supported a feature, it does not mean Spec2 will support it, or that it will be supported in the same way. The main reason being that Spec1 was super tied to morphic, but really not everything that can be done with morphic will be doable with Spec2, amongst others, because there are other backends than morphic.
Best,
Kasper
participants (4)
-
Christophe Demarey -
Guillermo Polito -
Kasper Ãsterbye -
Todd Blanchard