[Seaside] Rendering fontawesome tag..

[Esteban Maringolo]

Hi Karsten,

El vie., 22 feb. 2019 a las 4:15, Karsten Kusche (<karsten at heeg.de>) escribió:
>
> Hi Esteban,
>
> For desktop:
> - It uses MVC for building desktop apps, which is way cumbersome for
> my taste, compared with Dolphin's MVP or Pharo's Spec (also MVP
> AFAIU), VW's MVC has a lot of accidental complexity.
>
>
> reading that i think you try to write a GUI in VisualWorks programmatically, just like you’d do in Seaside. If you do that the MVC in VisualWorks indeed is complicated. And because of that, no-one really does that. The complexity comes from knowing how to compose the widgets in Wrappers and how to connect and configure the controller. These are tasks that the UIBuilder and UILookPolicy perform based on UISpec objects (you add the spec to the builder and have it do the work). This task is done automatically when you open an ApplicationModel, where it reads the UISpec from the #windowSpec method. This method is configured in the UIPainter.

> Until here none of the stuff is something a developer typically touches (not even if create your own widget).
> What a developer typically does is configure the UI using UIPainter and here another abstraction kicks in: ValueModels.
>
> The M in MVC in VisualWorks in the Model of the View and the Controller and it’s typically not specific to a widget. The model of a text-widget might seem to be a string, but it’s a ValueModel, just like for a Checkbox, it’s not a boolean but again a ValueModel.

> <snip>

First of all thanks for the detailed explanation.

Of course I'm not trying to build the UI programmatically like I do
with Seaside, although I like to have such flexibility.

(more below)

> On macOS the Cocoa bindings get very close to what you can achieve with ValueModels but it’s not available on iOS. I’ve not seen any other system yet where this kind of abstraction was introduced so you always have to keep your widgets around and tell them when a value was changed. At least on macOS / iOS this is not uniform so you have to know what object you put into which widget. You could use KVO on macOS / iOS but that’s quite messy to setup.

The MVC, although I keep my remarks of being cumbersome, it's still
superior to many things I've seen around.

> When we created seaBreeze we didn’t initially consider ValueModels and every time a value changed we needed to tell the UI to update the appropriate parts of the UI. Once we added support for ValueModels the development became much easier. Now we change a value and the UI picks that information automatically, just like in VisualWorks.
>

> The biggest problem with the VisualWorks UI stuff is that if you don’t know how the ideas are, it appears unreasonably complex and impossible to use. Reading the manual would help, but who does that? Only reading up on certain widgets doesn’t really help understand the underlying concept.

I'm speaking with the experience of being part of the team in my
previous employer that started evaluating VW as al alternative to VSE,
so I read the manual, and helped porting a good set of libraries and
windows/components to VW circa 2005/6, around the time Pollock was the
"next great thing" (which indeed seemed so [1]).
It wasn't the use of ValueModels what we found cumbersome, but
building things like a simple list or dropdown widget. I can't recall
exactly what were the issues (it was +10 years ago), but there were
seasoned developers in the team. With that considered, when Pollock
was cancelled we aborted the exploration of VW and started evaluating
Dolphin.

I'm biased towards Dolphin, but using also ValueModels,
AspectAdaptors, ValueAspectAdaptors and a proper implementation of MVP
we were able to build really complex and reusable MVP triads, some
generated manually and other dynamically from the underlying
metamodel, for a product that today keeps growing organically.
Although the limits are fuzzy, my preferences are MVP > MVVM > MVC.

I understand that the additional complexity of being multiplatform,
but in Dolphin only Views depended on the underlying drawing from the
OS.
OTOH VAST is multiplatform, but in practice it is only Windows GUI,
because Motif rendering is awful.

> Other than that VisualWorks started to improve on the VC part of MVC in recent releases, too. The new ViewEventControllers can be composed instead of having to be subclassed, which makes development of new widgets a whole lot easier, as well as easing the pain when extending the behaviour of existing widgets.

I have to admit that I haven't looked back into the "what's new" post
VW 7.3 or so, I'll be happy to know there were improvements there.

So my take is that for as small/simple GUI app, VW is too complex,
even after reading the manual :)
If it  has to be multiplatform, multiwindow, then it might be only
choice. VW has several other strengths.

But if I had to write a desktop app, I would use Pharo's spec or
Dolphin (with wine in Linux).

ps: I would stop or move this discussion somewhere else since it's not
Seaside related anymore :)

Regards,

[1] https://www.soops.nl/smalltalk/vrijdag/PreparingForPollock.pdf

Esteban A. Maringolo