Pharo needs you

> Hey Stef,
>
> This discussion got me to thinking about fonts and system-dependent
> resources. I wrote SSH and SSL long time back because though there were
> both performance issues and validation issues, it was all in the image
> and totally platform-independent. I still hold this opinion, in belief
> that a few different styles of optimizations are available: JIT, crypto
> plugins, shared data. The reasoning is that comm data is platform
> independent.
>
> The situation with fonts is different. Fonts are licensed and I smile in
> the thought that they are types, the only types you could ever possibly
> want. :)  Different platforms have different sets of these types and
> they should be available to us, in image.
>
> Now, that's a lot of work that you may want to spent on other
> activities. Ok, could we combine font work with another value? Yeah, I
> think so, at least if I were in your shoes. My burning question is "What
> is the best way/structure/form to differentiate platforms specifics from
> polymorphic interfaces?". I think it is much easier when the form &
> structure of the content is platform-independent and is your data-driven
> case. Yet in the access, this is platform-dependent and you want it to
> be so. Therefor the upper interface - of the access classes - ought to
> pass platform-independent instances.
>
> The conclusion I come to is that the platform-dependent code must
> translate across that semantic barrier and talk Smalltalk. Implementing
> a case study is highly useful, I would think. An in-image font builder
> could publish annotated platform-independent glyph definitions, our
> fonts, through platform-dependent libraries, reading these assets off
> the system.
>
> NB: regarding crypto plugins: I'll attach the Cryptography mcz again
> along with a CryptographyPlugins mcz. If anyone wanted to try to get
> those working in Pharo, that would be educational. This has an
> interesting example how to plug platform-dependent plugins in. In fact,
> Fuel validation could be used on crypto plugins and different
> implementations could be tried using other languages. What's the best?
> May be Haskel, right? If some students got into writing crypto plugins
> that would also be high value, to me anyways, but I feel it's for us all.
>
> Thanks so much ^^
> Robert
>
> On 10/13/2015 05:14 PM, stepharo wrote:
>> Thanks Aliaksei.
>>
>> I think that in the future we should be radically with hardcoded fonts
>> and color.
>> I think that a widget should have color and font as variables that we
>> can set up from the outside.
>> What is your take on this.
>>
>> Stef
>>
>>
>> Le 12/10/15 23:34, Aliaksei Syrel a écrit :
>>>
>>> Thanks for pointing out such usecase, Stef! This is indeed important
>>>
>>> On Oct 12, 2015 9:16 PM, "stepharo"
>>> <<mailto:[hidden email]>[hidden email]> wrote:
>>>
>>>     Hi guys
>>>
>>>     We are working like mad on the mooc and I'm stuck because to
>>>     produce cool videos I cannot get the correct fonts
>>>     because the widgets are not using font size :(
>>>     Look at the attachment.
>>>     This is how one day we pay our sloppiness.
>>>     So I will reduce the font size but it sucks.
>>>     Stef
>>>
>>