- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [bloc] addressing the moz2d issue

by Norbert Hartl

Hi Alex, thanks for the detailed mail. I can only share my gut feeling. And that is that you want too much at a time. We are still living in bitblt times and we need to escape from that. That means we need to have a proper vectorial support in our graphics backend. Having this we could use Bloc instead of Morphic. Adding proper font support is needed but comes after this. 3D graphics comes even later. etc. etc. All of these features need to be modular anyway. Neither do you want to install all of these on every machine nor should the base image become huge. If these features are modular what is the problem doing them one after the other? If you would do one after the other you would give the community the opportunity to get used to the new stuff and help while you are doing the next thing. To make a long story short. I think by using an extracted version of moz2d you are not only using a monster but one that is not reliable and this is a risk for the overall goal. We all are waiting for vectorial graphics for so long I assume most of us can live without gaussian blur a little bit longer ;) my 2 cents, Norbert > Am 26.01.2017 um 23:45 schrieb Aliaksei Syrel <alex.syrel(a)gmail.com>: > > Hi > > (My previous email was not a joke, I don't try to troll anyone. Let tolls do their job in other places) > Let's forget Moz2D for a moment :) Imagine that it does not exist. It was done just for fun and is even not in pharo repo. (https://github.com/syrel/Moz2D <https://github.com/syrel/Moz2D>). We needed something that works and it was made investing just a few months of time of a single anonymous student during summer exams session and vacations. > > I would like to start maybe one of the most important discussion that will influence Pharo and will dictate how system will look like in a few years. I invite everyone to join this discussion, especially board and consortium members. Because here is where business starts. > > There are some real questions: > Do we need Bloc or Morphic2 or %name your favourite framework%? > How advanced and modern do you want it to be? > What technology stack do we want to use for our new graphical framework? > What platforms and operating systems do we want to support? > How flexible technology stack should be? (some parts may change in the future) > Who will pay for it? > How many engineers can community afford? > Do you know how much other systems invest in graphical frameworks? > It is not a science project, isn't it? > Let me first put my two cents in. > > Low-level UI framework (without widgets) consists of multiple parts: > Vector graphics library to render shapes (fill, stroke, path builder, composition and blending operators) > Font service library (to support different font formats and collect information about local fonts installed in the system) > Text layout engine (this is where glyph positioning magic happens, link above too) > Text shaping engine (for high quality text rendering, to understand the problem => http://behdad.org/text/ <http://behdad.org/text/>) > Complex script library (to support ligatures, split glyphs and other UTF8 stuff, remember https://github.com/minimaxir/big-list-of-naughty-strings <https://github.com/minimaxir/big-list-of-naughty-strings>) > Image processing library (for various image effects, like gaussian blur, morphology filter, gamma, displacement map, just to name a few) > Hardware acceleration. Software rendering is nice, however, modern UIs are full of fancy stuff that require hardware acceleration. > Window and Event management library. With support of borderless and semi-transparent windows + good support of touchpad. > Custom written "Glue" library that allows all components to work together. Since modern libs are implemented in C++ we would need to implement C wrapper and a lot of integration tests. > Make the whole beast cross platform. > > Did I miss something? > > Here are some modern technologies commonly used for mentioned parts: > Skia, Direct2D, CoreGraphics, Cairo > Fontconfig, Freetype2 > HarfBuzz > Pango, OpenType > Graphite2, FriBidi > Imagemagic, SVG filters libraries > Vulkan, OpenGL > wxWidgets, QT, GTK, SDL2 > todo > todo > Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea! > > Let's assume that we stop on Cairo + Pango. According to pango.com <http://pango.com/> > > The integration of Pango with Cairo (http://cairographics.org/ <http://cairographics.org/>) provides a complete solution with high quality text handling and graphics rendering. > > According to the this potential technology stack we will have: > Cairo for vector graphics and rendering of basic shapes > Pango for text rendering > SDL2 for window and events management > What we will not get: > Support of filters; Cairo does not support gaussian blur. 3D transformations, we will not be able to not implement card flip animation. Never reach the same performance if using platform native frameworks (e.g. Direct2D on windows). Cairo will not die, but there is zero progress. > Vulkan support. Never with cairo. Pure OpenGL too (try to compile cairo-gl on mac, good luck!) There is a way to compile it with quartz support. As of version 2.7.9, XQuartz does not provide support for high-resolution Retina displays to X11 apps, which run in pixel-doubled mode on high-resolution displays. (https://bugs.freedesktop.org/show_bug.cgi?id=92777 <https://bugs.freedesktop.org/show_bug.cgi?id=92777>). > Borderless or transparent window with SDL2. Also, did you notice that sdl2 window turns black/white while resizing? There is no way to get a continuous window resize event with SDL2 (https://bugzilla.libsdl.org/show_bug.cgi?id=2077 <https://bugzilla.libsdl.org/show_bug.cgi?id=2077>). The issue is that events stop firing while user is resizing a window because main thread is blocked. Bug is already 3 years old. Indeed SDL2 is used for games, however how often do gamers resize game window? > Stateless API. Must have for a graphical framework like Bloc where canvas state is not shared between visual elements. It means that while rendering users must not clean the state of a canvas after every draw call. > Bloc is not my or Glenn's or Doru's personal property. We suggest, you decide. It would be great if community could invest money and time in a working and appropriate solution. > > P.S. If we would not care, we would agree with you instantly and even not bothered ourselves trying to spend time on finding cheap solution for such a complex problem. > > P.P.S Sorry for a long email :) > > Cheers, > Alex > > On 26 January 2017 at 21:10, Aliaksei Syrel <alex.syrel(a)gmail.com <mailto:alex.syrel@gmail.com>> wrote: > Hi, > > Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order to use them within vector graphics engine) + cross platform OpenGL / Vulkan context/device provider for hardware acceleration + implement Filters for effects (blur, lights, color matrix filters, etc...). > > Without all those technologies bloc WILL progress, from 80's to 00's. Still decades behind :) > > Cheers > > On Jan 26, 2017 20:40, "stepharong" <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: > I think that instead of investigating gtk (yet another library to bind and carry around), > it would be smarter to have Sparta back-end using an accelerated Cairo + pango. > Why? Because > - For example Cairo will not disappear in the future (here you will tell me that it does not have all the full > features.... I think that Bloc should deliver Brick first and focus on this because else it will stay a nice > experiment.) > - We do not have bench with an accelerated compiled version so no idea if this is good enough. > - Cairo is about 1.5 mb vs 20Mb and it is packaged. > > I share the concerns of Esteban about the maintenance of such Mozz2d bundling and he was pretty > clear with me, he will not maintain it nor take any responsibility about pharo using it. > > So having a Cairo Sparta back-end would be a smart move. > Stef > > > > > > Hi, > > Thank you for the intensive set of issues you raised during the Bloc presentation. I think it is worthwhile addressing them more thoroughly, so let me start with the issue that seemed to have caused the most worries: Sparta & Moz2D. > > Please keep in mind that while I am involved to some extent in Bloc, the real credits for the current state go to Glenn and Alex. > > Moz2D (https://github.com/mozilla/moz2d <https://github.com/mozilla/moz2d>, https://wiki.mozilla.org/Platform/GFX/Moz2D <https://wiki.mozilla.org/Platform/GFX/Moz2D>) offers an advanced backend and using it puts us on par with the rendering speed of a web browser, which is a significant added value over what we have now. > > However, as it was noted, it does come with a cost due to the fact that it is not available as standalone with only the features we are interested in. The vector graphics part is actually buildable out of the box. However, the text support needs to be extracted out of Moz2D, and this is where the patching scripts are used. The patches are there only for compilation purposes and not for features and they are applied automatically. You can see it here: > https://github.com/syrel/Moz2D <https://github.com/syrel/Moz2D> > > Alex updated recently the Moz2D version and it worked without problems. Of course, future changes in Moz2D might imply changes in this script as well, and this implies that we will need to maintain that script. And we could imagine applying these patches on the trunk of Moz2D to see if they work, and we can also imagine engaging with the Moz2D owners to see if we can find a middle ground. > > Now, letâs put this into perspective. We are currently using Athens and the Cairo backend. While Cairo is provided as a standalone library it has not seen significant advances since Mozzila shifted its focus towards Moz2D. So, sticking with it might not be an ideal strategy either. > > Furthermore, just like Athens, Sparta is an abstraction that allows us to switch the underlying backend should we need to. Until now we did not find a cross-platform backend that is as advanced and complete as Moz2D, but there is no reason to think that none other will appear in the future. Skia is an alternative but it is only a vector graphic engine without text support, so using it would imply to have another library for the text support. > > Sparta also comes with a reasonable set of tests that is aimed at testing the basic Moz2D functionality to make sure that the assumptions on top of which Sparta is built are correct. > > All in all, I think that the current situation is not ideal, but there is already enough engineering in place to actually make it work. And I definitely think that the potential it opens is rather significant. > > And, if more people look at the scripts, we might find even better and cheaper ways to express it. > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com <http://www.feenk.com/> > > "We cannot reach the flow of things unless we let go." > > > > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ <http://www.opera.com/mail/> > >

Jan. 27, 2017

Re: [Pharo-dev] memoized vs once

by Denis Kudriashov

2017-01-26 23:28 GMT+01:00 Chris Cunningham <cunningham.cb(a)gmail.com>: > On Thu, Jan 26, 2017 at 2:02 PM, stepharong <stepharong(a)free.fr> wrote: > >> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <astares(a)gmx.de> >> wrote: >> >> ... >> >> >>> Instead it is sent to an object that afterwards is a constant within a >>> method >>> (so it will not be evaluated later at runtime again) so IMHO >>> #asMethodConstant >>> instead of #asMethodConst would be better. >>> >> >> I do not understand any of them. >> >> In other words, this is creating a constant inside the method > (#asMethodConstant) instead of making the method return a constant (which > would be your #asConstantMethod). > If I have that right. > In any case, not having the contracted 'Const' would be nice. > Ok, this is done 19611 <https://pharo.fogbugz.com/f/cases/19611/rename-asMethodConst-into-asMethodC…> . Interesting to mention that while #asMethodConstant is defined on Object it also works well when sent to block. In that case BlockNode is replaced by result as literal

Jan. 27, 2017

Re: [Pharo-dev] memoized vs once

by Norbert Hartl

> Am 27.01.2017 um 02:45 schrieb Igor Stasenko <siguctua(a)gmail.com>: > > > > On 27 January 2017 at 02:28, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko <siguctua(a)gmail.com <mailto:siguctua@gmail.com>> wrote: > > > > > > On 27 January 2017 at 01:30, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > >> > >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong <stepharong(a)free.fr <mailto:stepharong@free.fr>> wrote: > >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> > >> > wrote: > >> > > >> >> stepharong wrote: > >> >>> > >> >>> can we rename this selector? > >> >>> asMethodConst should be at least be renamed to asConstantMethod > >> >> > >> >> > >> >> When you use "as {something}" then "something" depicts the result of > >> >> the > >> >> conversion message sent to an object. > >> >> > >> >> Like in #asNumber or #asString which shows to what the receiver will be > >> >> converted. > >> > > >> > > >> > Yes I thought that it was doing that. > >> >> > >> >> > >> >> > >> >> My understanding is that in the case discussed the receiver object is > >> >> NOT converted to a constant unchangeable method, so #asConstantMethod > >> >> would > >> >> not fit as a selector. > >> >> > >> >> Instead it is sent to an object that afterwards is a constant within a > >> >> method > >> >> (so it will not be evaluated later at runtime again) so IMHO > >> >> #asMethodConstant > >> >> instead of #asMethodConst would be better. > >> > > >> > > >> > I do not understand any of them. > >> > >> method constant = constant of a method > > > >> constant method = method that does not change > >> > > are you sure? > > pretty sure. 'method' is the subject. 'constant' is the adjective that > modifies the subject. > Its a bit hard to explain that intrinsic feeling of what is right, > but maybe.... If the adjective follows the subject its usually > separated by little joining words. > http://www.grammar-monster.com/glossary/adjective_definition.htm <http://www.grammar-monster.com/glossary/adjective_definition.htm> > > > maybe it is > > constant method = method that returns constant? > > For me this does not compute. > But I understand rules differ in other languages and its hard to avoid > subtle influences from your primary language. > > heh.. you see my pain! right now i have to deal with C++ > and seeing all these > const Type & foo const.. > and cannot parse it.. > :) > > And still, it could just be my personal bias. > So if you & Stef find it ambiguous, it may be for others and we should > aim to avoid that. > > Well, we have more general term for objects that do not change over their lifetime - immutable. And it is moare precise, > if we're talking in smalltalk context. > So, why borrowing rather alien term into our ecosystem, because i barely heard that anyone > were using it, and saying something like 'constant object' or something like this, when talking smalltalk context. > We use the term immutable for an object that _can not_ be changed and not for objects that _do not_ change. Norbert > Because when you open this 'can' of constant method, what does it means being a constant? > Is is that method's properties won't change, or all object(s) it is pointing to never change as well? > > cheers -ben > > > > > apparently, that's why 'constant' term doesn't fits there, because there's > > so many confusion about it. what are the constant in dynamic system, after > > all? > > > > > -- > Best regards, > Igor Stasenko.

Jan. 27, 2017

Re: [Pharo-dev] [bloc] addressing the moz2d issue

by Hilaire

Seriously?? You really don't want your base system (call it Pharo or Python or Ruby) depends on such a stack. It could very liklely kill the whole base system, particularly true for Pharo where UI is closely tight to the rest of the system. As external third party library, why not? Hilaire Le 26/01/2017 Ã 23:45, Aliaksei Syrel a Ã©crit : > > Low-level UI framework (without widgets) consists of multiple parts: > > 1. Vector graphics library to render shapes (fill, stroke, path > builder, composition and blending operators) > 2. Font service library (to support different font formats and collect > information about local fonts installed in the system) > 3. Text layout engine (this is where glyph positioning magic happens, > link above too) > 4. Text shaping engine (for high quality text rendering, to understand > the problem => http://behdad.org/text/) > 5. Complex script library (to support ligatures, split glyphs and other > UTF8 stuff, > remember https://github.com/minimaxir/big-list-of-naughty-strings > <https://github.com/minimaxir/big-list-of-naughty-strings>) > 6. Image processing library (for various image effects, like gaussian > blur, morphology filter, gamma, displacement map, just to name a few) > 7. Hardware acceleration. Software rendering is nice, however, modern > UIs are full of fancy stuff that require hardware acceleration. > 8. Window and Event management library. With support of borderless and > semi-transparent windows + good support of touchpad. > 9. Custom written "Glue" library that allows all components to work > together. Since modern libs are implemented in C++ we would need to > implement C wrapper and a lot of integration tests. > 10. Make the whole beast cross platform. > > -- Dr. Geo http://drgeo.eu

Jan. 27, 2017

Re: [Pharo-dev] athens dead code?

by Igor Stasenko

On 27 January 2017 at 09:17, stepharong <stepharong(a)free.fr> wrote: > On Fri, 27 Jan 2017 00:31:11 +0100, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > > > On 27 January 2017 at 00:06, stepharong <stepharong(a)free.fr> wrote: > >> >> accept: aVisitor >> ^ aVisitor lineSegment: self >> accept: aVisitor >> ^ aVisitor closeSegment: self >> accept: aVisitor >> ^ aVisitor moveSegment: self >> >> seems to invoke methods that do not exit >> I check AthensLIneSegment is used so I do not understand why the methods >> are broken. >> >> this is a part of visitor api for path segments. > > > I know but where is the visitor? > > if you remove it, then users cannot use it > for iterating trough path segments for converting them etc etc.. > of course, it may be nit used by Athens itself.. but it doesn't means it > is useless. > > > Where is the visitor? Why accept: are not packaged with it? Does it use > DNU trick? > In my imagine there is no implementor of moveSegment: closeSegment: > > > why there should be any, if nobody using this feature, yet? so you don't have a single visitor. you could add a test case for coverage, so it won't bother you that there's no implementors of given selector in image :) iirc, i used it for path transformation(s) code.. which then get removed. -- Best regards, Igor Stasenko.

Jan. 27, 2017

Re: [Pharo-dev] [bloc] addressing the moz2d issue

by stepharong

Thanks for this analysis I call it the reality principle Who will pay for it? How many engineers can community afford? Do you know how much other systems invest in graphical frameworks? It is not a science project, isn't it? There is always a tension between what we can achieve and the goal. Now give 10 M Euros and I have no problem with your vision. Now can you reply to Ronie's email. Stef On Thu, 26 Jan 2017 23:45:17 +0100, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi > > (My previous email was not a joke, I don't try to troll anyone. Let > tolls do their job in other places) > Let's forget Moz2D for a moment :) Imagine that it does not exist. It > was done just for fun and is even not in pharo repo. > (https://github.com/syrel/Moz2D) We needed something that works >and it > was made investing just a few months of time of a single anonymous > student during summer exams session and vacations. > > I would like to start maybe one of the most important discussion that > will influence Pharo and will dictate how system will look like in a few > years. I invite everyone to join this discussion, >especially board and > consortium members. Because here is where business starts. > > There are some real questions: > Do we need Bloc or Morphic2 or %name your favourite framework%? > How advanced and modern do you want it to be? > What technology stack do we want to use for our new graphical framework? > What platforms and operating systems do we want to support? > How flexible technology stack should be? (some parts may change in the > future) > Who will pay for it? > How many engineers can community afford? > Do you know how much other systems invest in graphical frameworks? > It is not a science project, isn't it? > Let me first put my two cents in. > > Low-level UI framework (without widgets) consists of multiple parts: > Vector graphics library to render shapes (fill, stroke, path builder, > composition and blending operators) > Font service library (to support different font formats and collect > information about local fonts installed in the system) > Text layout engine (this is where glyph positioning magic happens, link > above too) > Text shaping engine (for high quality text rendering, to understand the > problem => http://behdad.org/text/) > Complex script library (to support ligatures, split glyphs and other > UTF8 stuff, remember > https://github.com/minimaxir/big-list-of-naughty-strings) > Image processing library (for various image effects, like gaussian blur, > morphology filter, gamma, displacement map, just to name a few) > Hardware acceleration. Software rendering is nice, however, modern UIs > are full of fancy stuff that require hardware acceleration. > Window and Event management library. With support of borderless and > semi-transparent windows + good support of touchpad. > Custom written "Glue" library that allows all components to work > together. Since modern libs are implemented in C++ we would need to > implement C wrapper and a lot of integration >tests. > Make the whole beast cross platform. > > Did I miss something? > > Here are some modern technologies commonly used for mentioned parts: > Skia, Direct2D, CoreGraphics, Cairo > Fontconfig, Freetype2 > HarfBuzz > Pango, OpenType > Graphite2, FriBidi > Imagemagic, SVG filters libraries > Vulkan, OpenGL > wxWidgets, QT, GTK, SDL2 > todo > todo > Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea! > > Let's assume that we stop on Cairo + Pango. According to pango.com > >> The integration of Pango with Cairo (http://cairographics.org/) >> provides a complete solution with high quality text handling and >> graphics rendering. > > According to the this potential technology stack we will have: > Cairo for vector graphics and rendering of basic shapes > Pango for text rendering > SDL2 for window and events management > What we will not get: > Support of filters; Cairo does not support gaussian blur. 3D > transformations, we will not be able to not implement card flip > animation. Never reach the same performance if using platform >native > frameworks (e.g. Direct2D on windows). Cairo will not die, but there is > zero progress. > Vulkan support. Never with cairo. Pure OpenGL too (try to compile > cairo-gl on mac, good luck!) There is a way to compile it with quartz > support. As of version 2.7.9, XQuartz does not >provide support for > high-resolution Retina displays to X11 apps, which run in pixel-doubled > mode on high-resolution displays. > (https://bugs.freedesktop.org/show_bug.cgi?id=92777) > Borderless or transparent window with SDL2. Also, did you notice that > sdl2 window turns black/white while resizing? There is no way to get a > continuous window resize event with SDL2 > >(https://bugzilla.libsdl.org/show_bug.cgi?id=2077) The issue is that > events stop firing while user is resizing a window because main thread > is blocked. Bug is already 3 years >old. Indeed SDL2 is used for games, > however how often do gamers resize game window? > Stateless API. Must have for a graphical framework like Bloc where > canvas state is not shared between visual elements. It means that while > rendering users must not clean the state of a >canvas after every draw > call. > Bloc is not my or Glenn's or Doru's personal property. We suggest, you > decide. It would be great if community could invest money and time in a > working and appropriate solution. > > P.S. If we would not care, we would agree with you instantly and even > not bothered ourselves trying to spend time on finding cheap solution > for such a complex problem. > > P.P.S Sorry for a long email :) > > Cheers, > Alex > > On 26 January 2017 at 21:10, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> Hi, >> >> Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 >> (for fonts) + Graphite (glyphs shaping technology in order to use them >> within vector graphics engine) + cross platform >>OpenGL / Vulkan >> context/device provider for hardware acceleration + implement Filters >> for effects (blur, lights, color matrix filters, etc...). >> >> Without all those technologies bloc WILL progress, from 80's to 00's. >> Still decades behind :) >> >> Cheers >> >> On Jan 26, 2017 20:40, "stepharong" <stepharong(a)free.fr> wrote: >>> I think that instead of investigating gtk (yet another library to bind >>> and carry around), >>> it would be smarter to have Sparta back-end using an accelerated Cairo >>> + pango. >>> Why? Because >>> - For example Cairo will not disappear in the future (here you >>> will tell me that it does not have all the full >>> features.... I think that Bloc should deliver Brick first and >>> focus on this because else it will stay a nice >>> experiment.) >>> - We do not have bench with an accelerated compiled version so >>> no idea if this is good enough. >>> - Cairo is about 1.5 mb vs 20Mb and it is packaged. >>> >>> I share the concerns of Esteban about the maintenance of such Mozz2d >>> bundling and he was pretty >>> clear with me, he will not maintain it nor take any responsibility >>> about pharo using it. >>> >>> So having a Cairo Sparta back-end would be a smart move. >>> Stef >>> >>> >>> >>> >>> >>>> Hi, >>>> >>>> Thank you for the intensive set of issues you raised during the Bloc >>>> presentation. I think it is worthwhile addressing them more >>>> thoroughly, so let me start with the issue that seemed to >>>>have >>>> caused the most worries: Sparta & Moz2D. >>>> >>>> Please keep in mind that while I am involved to some extent in Bloc, >>>> the real credits for the current state go to Glenn and Alex. >>>> >>>> Moz2D (https://github.com/mozilla/moz2d, >>>> https://wiki.mozilla.org/Platform/GFX/Moz2D) offers an advanced >>>> backend and using it puts us on par with the rendering speed of a web >>>> >>>>browser, which is a significant added value over what we have now. >>>> >>>> However, as it was noted, it does come with a cost due to the fact >>>> that it is not available as standalone with only the features we are >>>> interested in. The vector graphics part is actually >>>>buildable out >>>> of the box. However, the text support needs to be extracted out of >>>> Moz2D, and this is where the patching scripts are used. The patches >>>> are there only for compilation >>>>purposes and not for features and >>>> they are applied automatically. You can see it here: >>>> https://github.com/syrel/Moz2D >>>> >>>> Alex updated recently the Moz2D version and it worked without >>>> problems. Of course, future changes in Moz2D might imply changes in >>>> this script as well, and this implies that we will need >>>>to >>>> maintain that script. And we could imagine applying these patches on >>>> the trunk of Moz2D to see if they work, and we can also imagine >>>> engaging with the Moz2D owners to see if we >>>>can find a middle >>>> ground. >>>> >>>> Now, letâs put this into perspective. We are currently using Athens >>>> and the Cairo backend. While Cairo is provided as a standalone >>>> library it has not seen significant advances since >>>>Mozzila >>>> shifted its focus towards Moz2D. So, sticking with it might not be an >>>> ideal strategy either. >>>> >>>> Furthermore, just like Athens, Sparta is an abstraction that allows >>>> us to switch the underlying backend should we need to. Until now we >>>> did not find a cross-platform backend that is as >>>>advanced and >>>> complete as Moz2D, but there is no reason to think that none other >>>> will appear in the future. Skia is an alternative but it is only a >>>> vector graphic engine without text support, >>>>so using it would >>>> imply to have another library for the text support. >>>> >>>> Sparta also comes with a reasonable set of tests that is aimed at >>>> testing the basic Moz2D functionality to make sure that the >>>> assumptions on top of which Sparta is built are correct. >>>> >>>> All in all, I think that the current situation is not ideal, but >>>> there is already enough engineering in place to actually make it >>>> work. And I definitely think that the potential it opens is rather >>>> >>>>significant. >>>> >>>> And, if more people look at the scripts, we might find even better >>>> and cheaper ways to express it. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "We cannot reach the flow of things unless we let go." >>>> >>>> >>>> >>>> >>>> >>> >>> >>> --Using Opera's mail client: http://www.opera.com/mail/ >>> > -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 27, 2017

Re: [Pharo-dev] athens dead code?

by stepharong

On Fri, 27 Jan 2017 00:31:11 +0100, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 27 January 2017 at 00:06, stepharong <stepharong(a)free.fr> wrote: >> >> accept: aVisitor >> ^ aVisitor lineSegment: self >> accept: aVisitor >> ^ aVisitor closeSegment: self >> accept: aVisitor >> ^ aVisitor moveSegment: self >> >> seems to invoke methods that do not exit >> I check AthensLIneSegment is used so I do not understand why the >> methods are broken. >> > this is a part of visitor api for path segments. I know but where is the visitor? > if you remove it, then users cannot use it > for iterating trough path segments for converting them etc etc.. > of course, it may be nit used by Athens itself.. but it doesn't means it > is useless. Where is the visitor? Why accept: are not packaged with it? Does it use DNU trick? In my imagine there is no implementor of moveSegment: closeSegment: > >> >>>> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> > > > > --Best regards, > Igor Stasenko. -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 27, 2017

Re: [Pharo-dev] HandMorph>>#processEvents

by stepharong

Probably a bug. I started to clean this part 4 years ago and my changes got killed by SDL + OS Window and now apparently SDL 20 is not good enough. May be in 3 years from now it will be cleaned, who knows. Stef > Why do we have this twice in processEvents? > > self mouseOverHandler processMouseOver: lastMouseEvent > > ? > > Well, maybe that is not there that things happen but if you spy on > mouseEnter and mouseLeave events, you will notice that they are both > sent **twice** all the time. > > I think that this happens so often that we would benefit from getting > rid of that twice enter/leave thing (and it is really annoying to have > to deal with these two events when you expect only one. I >am not > "entering entering" a rectangle). > > > > processEvents > "Process user input events from the local input devices." > > | evt evtBuf type hadAny | > ActiveEvent ifNotNil: ["Meaning that we were invoked from within an > event response. > Make sure z-order is up to date" > > self mouseOverHandler processMouseOver: lastMouseEvent]. > hadAny := false. > [(evtBuf := Sensor nextEvent) isNil] whileFalse: [evt := nil. "for > unknown event types" > type := evtBuf first. > type = EventTypeMouse ifTrue: [recentModifiers := evtBuf sixth. evt > := self generateMouseEvent: evtBuf]. > type = EventTypeKeyboard ifTrue: [recentModifiers := evtBuf fifth. > evt := self generateKeyboardEvent: evtBuf]. > type = EventTypeDragDropFiles ifTrue: [evt := self > generateDropFilesEvent: evtBuf]. > type = EventTypeWindow > ifTrue:[evt := self generateWindowEvent: evtBuf]. > "All other events are ignored" > (type ~= EventTypeDragDropFiles and: [evt isNil]) ifTrue: [^self]. > evt isNil ifFalse: ["Finally, handle it" > > self handleEvent: evt. > hadAny := true. > > "For better user feedback, return immediately after a mouse event > has been processed." > (evt isMouse and: [evt isMouseWheel not]) ifTrue: [^self]]]. > "note: if we come here we didn't have any mouse events" > mouseClickState notNil ifTrue: ["No mouse events during this cycle. > Make sure click states time out accordingly" > > mouseClickState handleEvent: lastMouseEvent asMouseMove from: self]. > hadAny ifFalse: ["No pending events. Make sure z-order is up to date" > > self mouseOverHandler processMouseOver: lastMouseEvent] > > Clues? > > Phil -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 27, 2017

Re: [Pharo-dev] memoized vs once

by philippe.back＠highoctane.be

Le 27 janv. 2017 05:55, "Ben Coman" <btc(a)openinworld.com> a Ã©crit : On Fri, Jan 27, 2017 at 4:32 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Now, descending to the implementations, I understand that Ben's memorize... > btw, I feel a bit of an impostor having it called "my" memorize. It was Torsten's initiative based on gist by John Cromartie. https://pharo.fogbugz.com/f/cases/14458/Add-BlockClosure-memoized Thx for the link. So, multi arg blocks someone? Phil cheers -ben >

Jan. 27, 2017

Re: [Pharo-dev] memoized vs once

by Ben Coman

On Fri, Jan 27, 2017 at 4:32 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Now, descending to the implementations, I understand that Ben's memorize... > btw, I feel a bit of an impostor having it called "my" memorize. It was Torsten's initiative based on gist by John Cromartie. https://pharo.fogbugz.com/f/cases/14458/Add-BlockClosure-memoized cheers -ben >

Jan. 27, 2017