Rendering fontawesome tag..
Locked
 
|
I’d like to use fontawesome in my project, and to do so, you just render this:
but for some reason, I cannot find the i tag. is it called something else, like alternate or emphasis ? ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering fontawesome tag..
|
|
It's not there. I have a FontAwesome wrapper, including its FileLibrary for v 4.7.0, done for VW. Let me port it to Pharo and I'll share it with you. Meanwhile you can do (html tag: 'i') class: 'fa fa-ticket-alt'. Regards. El jue., 21 de feb. de 2019 01:06, sergio ruiz <[hidden email]> escribió:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
hahhaahha.. i did this.. but i felt dirty while i was doing it.. thanks for the share! ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Esteban A. Maringolo
I am sort of looking at VW right now.. do you use it to create desktop apps, or only web? Thanks! On February 20, 2019 at 11:11:17 PM, Esteban Maringolo ([hidden email]) wrote:
---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering fontawesome tag..
|
|
Don't, stay with Pharo or GemStone :) In my case it's for a web app. Esteban A. Maringolo El jue., 21 feb. 2019 a las 11:03, sergio ruiz (<[hidden email]>) escribió:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
That’s kind of a harsh statement, isn’t it? I’d be interested in reasons for your (I guess) opinion. VW has been a very progressive environment and I remember Cincom has been ahead of the pack in innovations in the mid 2000‘s ...
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering fontawesome tag..
|
|
El jue., 21 feb. 2019 a las 11:30, Joachim Tuchel
(<[hidden email]>) escribió: > > That’s kind of a harsh statement, isn’t it? I’d be interested in reasons for your (I guess) opinion. Yeap, It might be, I'm just wanting him to save time. But in my opinion the reasons are many: For the web, which concerns this mailing list: 1. Seaside is bundled, but seems unmaintained e.g. Seaside-Core references pmm.787, which seems to be from 2013 <http://smalltalkhub.com/#!/~Seaside/Seaside31/versions/Seaside-Core-pmm.787> I had to manually port several libraries to make it work decently or with modern stuff, the process for a new release isn't specified and the way to load Seaside isn't granular 2. The previous point makes sense because their "promoted" way of developing web apps is the AppeX framework with the SiouX http server. 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. It has is strenghts in some industrial grade libraries (X.509/ASN.1, and other stuff) but I've seen some of these in Pharo lately. > VW has been a very progressive environment and I remember Cincom has been ahead of the pack in innovations in the mid 2000‘s ... Yeap, it was. Now I think it isn't. Esteban A. Maringolo _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Esteban A. Maringolo
I a looking at VW for writing desktop apps.. we currently use Qt, which I really don’t have a problem with.. but if we could crank out small, in house desktop apps in pharo, i would be totally into that.. On February 21, 2019 at 9:17:02 AM, Esteban Maringolo ([hidden email]) wrote:
---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering fontawesome tag..
|
|
In reply to this post by Esteban A. Maringolo
Hi Esteban,
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.
The idea here is to introduce a uniform model to be used by all the widgets. ValueModels react to #value and #value:. They also solve the loose-coupling problem that the model shouldn’t know about the view(s) that display the model. In addition the views
can still be informed by their model when the model changes (they use the so called „Dependency" mechanism, which is a very lightweight observer pattern).
The result of this Model architecture is that in your ApplicationModel, where you describe your UI, you only need to provide the ValueModels and don’t need to care about the Views and Controllers anymore. You want to change the value that’s shown by a
widget, you update the ValueModel’s value and the view automatically redraws itself. Same goes the other way around, if the controller modifies the value, it updates the ValueModel and you can access the new value from the ApplicationModel. You can even registers
to the dependency mechanism to be informed as soon as a value changes.
ValueModel is a class hierarchy and the most basic subclass is ValueHolder (the default, if you create a simple UI). The ValueHolder implements the #value/#value: contract simply by having an instance variable and providing accessors to it. There’s one
addition: in #value: it triggers the dependency mechanism by calling „self changed: #value“.
More sophisticated ValueModels are AspectAdaptors, which allow you to quickly connect a widget to an attribute of a domain model. If you have a Person with a #name attribute, you can create an AspectAdaptor that will send #name when it is asked for its
#value and it’ll send #name: when #value: is called. In addition, it supports the same dependency mechanism from its domain model, so if the the Person’s #name is changed, the Person can say: „self changed: #name“ and the AspectAdaptor will notice that its
value has changed and it’ll propagate this information via „self changed:#value“ to be picked up by the views.
There are also subclasses of ValueModel that cover the following problems:
- provide a read-only value model for derived attributes that update automatically when the underlying value changes.
- connect the contents of a widget with the attribute of an object that’s selected in a list of objects. That allows you to update a bunch of widgets without writing a single line of code, you just configure their connection and you’re done.
- implement accept/cancel by buffering the user provided input before it is sent back to the domain model. That way you don’t need to keep a copy of your domain model around just to not modify the domain model instantly when the user changes a value.
The best part is: you can configure most of that directly from the UIPainter and don’t need to manually create the correct ValueModel in code.
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. 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. 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. 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.
Kind Regards Karsten _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Rendering fontawesome tag..
|
|
Hi Karsten,
El vie., 22 feb. 2019 a las 4:15, Karsten Kusche (<[hidden email]>) 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 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |