What’s the recommended pattern for getting the “data host” from an itemRenderer 
now that itemRendererParent/itemRendererOwnerView is no longer a “thing”?

I have the following code in an itemRenderer which inherits from 
DataItemRenderer:

(itemRendererParent.host.parent as PagePalette).showMenuHandler(myValueEvent);

> On Feb 24, 2020, at 7:02 PM, Alex Harui <[email protected]> wrote:
> 
> It seemed like a separate concern.  Right now there are two highly used 
> ItemRendererClassFactory, but several Initializers.
> 
> -Alex
> 
> On 2/24/20, 3:06 AM, "Harbs" <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>    Why is IItemRendererInitializer separate from IItemRendererClassFactory?
> 
>> On Feb 21, 2020, at 12:03 AM, Alex Harui <[email protected]> wrote:
>> 
>> I pushed changes that I think has everything working in Jewel by using the 
>> same "has" pattern that is used in other component sets.
>> 
>> The Lists in the ToDo examples use a regular ItemRendererClassFactory 
>> instead of SelectableItemRendererClassFactory that is now used in most other 
>> places (List/DataGrid/Table)
>> 
>> The recommended pattern for disabling selection in a list is whether you 
>> choose a ClassFactory that attaches a Selection Bead to each renderer.  
>> There was an exception to that rule in one of the Table examples because it 
>> wanted only certain renderers to not have selection. I added a bead that 
>> turns off the selection for that case.  IMO, how to deal with such an 
>> exception will be based more on what percentage of the renderers need 
>> selection.  If most do, then add a Selection Bead to all renderers but 
>> disable selection where you don't want it.  If most do not want selection, 
>> then add the bead where you need it.
>> 
>> Thanks,
>> -Alex
>> 
>> On 2/20/20, 11:28 AM, "Carlos Rovira" <[email protected] 
>> <mailto:[email protected]> <mailto:[email protected] 
>> <mailto:[email protected]>>> wrote:
>> 
>>   yes, Jewel has the "structure" and is organized in SASS files, then
>>   JewelTheme has the "styling" part and is as well SASS.
>>   so Jewel should not need to change, and people should only need to change
>>   JewelTheme or create a new theme one using it as a template.
>> 
>>   I'll add examples to ant tomorrow
>> 
>>   thanks
>> 
>> 
>>   El jue., 20 feb. 2020 a las 20:17, Alex Harui (<[email protected] 
>> <mailto:[email protected]>>)
>>   escribió:
>> 
>>> 
>>> 
>>> On 2/20/20, 11:04 AM, "Carlos Rovira" <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>>   forgot to say. Can you add missing examples to ANT? don't know where
>>> to do
>>>   that
>>>   and checking Jewel don't see the use of
>>> SelectableItemRendererClassFactory.
>>>   all times ItemRendererClassFactory is used
>>> 
>>> I could fix the Ant side, but I don't have time.  It think all you need to
>>> do is add it to the examples/build.xml
>>> 
>>> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't
>>> sure if the selection was supposed to be changeable at runtime.  I think
>>> you've confirmed that it isn't so we can change to use
>>> SelectableItemRendererClassFactory
>>> 
>>> I knew the themes were generated by SASS, but I didn't realize the Jewel
>>> one was as well.
>>> 
>>> -Alex
>>> 
>>>   El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (<
>>> [email protected] <mailto:[email protected]>>)
>>>   escribió:
>>> 
>>>> Hi Alex,
>>>> 
>>>> remember that Jewel uses SASS to create the CSS. I already pushed a
>>> commit
>>>> with ["warning"]. It's not the first time I warn about it ;)
>>>> You must to change SASS file. The css is just generated (like other
>>>> generations in compiler), and is committed since no body added SASS
>>> to ANT.
>>>> Maven has a sass plugin to compile SASS.
>>>> 
>>>> I saw you response and commented there
>>>> 
>>>> Thanks
>>>> 
>>>> Carlos
>>>> 
>>>> 
>>>> El jue., 20 feb. 2020 a las 19:55, Alex Harui
>>> (<[email protected] <mailto:[email protected]>>)
>>>> escribió:
>>>> 
>>>>> I replied on this topic on your commit email.
>>>>> 
>>>>> So I don't have to copy that into this thread, read what I said in
>>> that
>>>>> email and reply on that thread and let's figure out the right thing
>>> to do.
>>>>> I am having some weird problem with my Maven build where every time
>>> I try
>>>>> to change Jewel's defaults.css something overwrites it.  I'm trying
>>> to
>>>>> figure out what is going on there.
>>>>> 
>>>>> -Alex
>>>>> 
>>>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <[email protected] 
>>>>> <mailto:[email protected]>>
>>> wrote:
>>>>> 
>>>>>   Hi Alex,
>>>>> 
>>>>>   I found that TodoMVC examples was not working, so I fixed it
>>> removing
>>>>> the
>>>>>   non existing properties (hoverable and selectable).
>>>>>   But I found Jewel ListItemRenderer has all baked, so I created a
>>>>>   SimpleListItemRenderer (in Jewel Simple in the normal prefix
>>> for a
>>>>> "base",
>>>>>   "basic" or "simple" option) that hast the minimum required.
>>>>> 
>>>>>   So at least in Jewel if people wants hoverable and selectable
>>>>> renderers use
>>>>>   the normal ListItemRenderer.
>>>>>   If don't want that indicators, use SimpleListItemRenderer. If
>>> you
>>>>> want just
>>>>>   show hover, but not selected state, then extend Simple version
>>> and
>>>>> add "
>>>>>   ClassSelectorListRuntimeSelectableItemRendererBead" and
>>> configure to
>>>>> have
>>>>>   just "hoverable" to true ¿ok?
>>>>> 
>>>>>   Hope I understand ok how it works. Let me know if something is
>>> not as
>>>>>   expected.
>>>>> 
>>>>>   Thanks
>>>>> 
>>>>>   Carlos
>>>>> 
>>>>> 
>>>>> 
>>>>>   El jue., 20 feb. 2020 a las 18:06, Alex Harui
>>>>> (<[email protected] <mailto:[email protected]>>)
>>>>>   escribió:
>>>>> 
>>>>>> I'm not sure I understand what you mean by "control".
>>>>>> 
>>>>>> Before the "has" changes, every ItemRenderer contained or
>>> inherited
>>>>> code
>>>>>> that had hovered/selected APIs that drew visuals, and the
>>>>> ItemRenderer also
>>>>>> "had" a bead like ItemRendererMouseController that set the
>>> hovered
>>>>> property
>>>>>> on that item renderer, and the List's controller would set the
>>>>> selected
>>>>>> property.
>>>>>> 
>>>>>> Now, every ItemRenderer "has" a bead that has the
>>> hovered/selected
>>>>>> properties, and the ItemRendererMouseController and the
>>> Lists's
>>>>> controllers
>>>>>> get that bead instead of talking to the ItemRenderer
>>> directly.  I
>>>>> guess
>>>>>> that's the new way of thinking for has/composition vs
>>>>> is/inheritance:  a
>>>>>> component doesn't have to have all of its APIs glued to its
>>> API
>>>>> surface.
>>>>>> We mainly do that for convenience in MXML, but for more
>>> internal
>>>>> stuff like
>>>>>> this, loose-coupling via has/composition shared more code and
>>>>> increases
>>>>>> configurability, but does add some runtime overhead in its
>>> raw form.
>>>>>> Hopefully we can optimize that away.
>>>>>> 
>>>>>> HTH,
>>>>>> -Alex
>>>>>> 
>>>>>> On 2/20/20, 5:01 AM, "Piotr Zarzycki" <
>>> [email protected] <mailto:[email protected]>>
>>>>> wrote:
>>>>>> 
>>>>>>   Hi Alex,
>>>>>> 
>>>>>>   Could you provide an example how would I control
>>>>> hovering/selecting in
>>>>>> item
>>>>>>   renderer when I don't have build in hover property etc. ?
>>> How
>>>>> should I
>>>>>>   compose such item renderer ?
>>>>>> 
>>>>>>   Thanks,
>>>>>>   Piotr
>>>>>> 
>>>>>>   czw., 20 lut 2020 o 03:20 Alex Harui
>>> <[email protected] <mailto:[email protected]>>
>>>>>> napisał(a):
>>>>>> 
>>>>>>> I pushed the "has" changes.  TourDeJewel seems to be
>>> working
>>>>>> correctly for
>>>>>>> me.
>>>>>>> 
>>>>>>> The principle of "has" is similar to inheritance vs
>>>>> composition.
>>>>>> Just
>>>>>>> like top-level components like List are composed of many
>>>>> beads, the
>>>>>> item
>>>>>>> renderers are now composed of more beads as well.  That
>>>>> reduces the
>>>>>>> requirement to add code to a class in order to "be/is"
>>>>> something.
>>>>>>> 
>>>>>>> There used to be copies of code that drew hover and
>>> selected
>>>>> states
>>>>>> on
>>>>>>> the item renderers in each new kind of item renderer
>>> that
>>>>> couldn't
>>>>>> inherit
>>>>>>> from an item renderer that could draw selected and
>>> hovered
>>>>> states.
>>>>>> Now,
>>>>>>> the itemrenderers compose their selection visuals.   A
>>> single
>>>>> item
>>>>>> renderer
>>>>>>> like StringItemRenderer can be composed with no
>>> selection
>>>>> drawing at
>>>>>> all,
>>>>>>> or with solid color selection drawing or with alternate
>>> color
>>>>>> selection
>>>>>>> drawing or something new.    And that means that some
>>> new
>>>>> kind of
>>>>>> item
>>>>>>> renderer, like a TextInput can become an item renderer
>>> more
>>>>> easily,
>>>>>> by
>>>>>>> composing a selection visuals bead instead of having to
>>> add
>>>>> all of
>>>>>> that
>>>>>>> code.
>>>>>>> 
>>>>>>> Another place I started using "has" but didn't fully
>>> replace
>>>>> the old
>>>>>> code
>>>>>>> was in handling itemRendererParent, which is now called
>>>>>>> itemRendererOwnerView (to try to make it more clear
>>> that isn't
>>>>>> always the
>>>>>>> parent of the item renderer and is sometimes an internal
>>>>>>> datagroup/container).  Turns out a lot of our renderers
>>>>> didn't need
>>>>>> to know
>>>>>>> the itemRendererParent, so in many cases we no longer
>>> figure
>>>>> it out
>>>>>> and
>>>>>>> assign it.  But in cases where it is needed, the
>>> property is
>>>>>> currently left
>>>>>>> baked into the renderer, but in some new cases, it is
>>>>> composed.  An
>>>>>>> ItemRendererOwnerViewBead is added to the strand
>>> instead of
>>>>> added to
>>>>>> a
>>>>>>> class and contains the reference to the ownerView.
>>> Maybe
>>>>> someday
>>>>>> we'll
>>>>>>> fully remove the old pattern, not sure.
>>>>>>> 
>>>>>>> Ideally we would do more "has" than "is".  It could
>>> allow us
>>>>> to
>>>>>> eliminate
>>>>>>> much of the required code to be a top tag in an MXML
>>> document.
>>>>>>> 
>>>>>>> Other changes in this branch were to add "Initializers"
>>> so the
>>>>>>> RendererFactories didn't bake in code for specific item
>>>>> renderers,
>>>>>> and to
>>>>>>> create a few base classes with overrides so there is
>>> less
>>>>> code to
>>>>>> maintain.
>>>>>>> 
>>>>>>> There should be little if any impact to application
>>> code.  It
>>>>> should
>>>>>>> mainly affect the internals of how item renderer-based
>>> things
>>>>> are
>>>>>> created.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> -Alex
>>>>>>> 
>>>>>>> On 2/17/20, 4:33 PM, "Carlos Rovira" <
>>> [email protected] <mailto:[email protected]>
>>>>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>>   Hi Alex,
>>>>>>> 
>>>>>>>   if will be of help if you point us to different
>>> links
>>>>> where we
>>>>>> can
>>>>>>> learn
>>>>>>>   about this modifications, since I at least can just
>>>>> imagine what
>>>>>> is all
>>>>>>>   about, but will need to get deeper in the concepts
>>> to
>>>>> understand
>>>>>> the
>>>>>>>   changes and to apply this patterns.
>>>>>>> 
>>>>>>>   In Jewel each "list component has its own type of
>>>>> renderer, so
>>>>>> for
>>>>>>> example
>>>>>>>   List uses ListItemRenderer and DataGrid has
>>>>>> DataGridItemRenderer, since
>>>>>>>   usually at that component level the user needs
>>> similar
>>>>>> infrastructure
>>>>>>> like
>>>>>>>   hoverable, selectable...and some (not much) more,
>>> don't
>>>>> know
>>>>>> right now
>>>>>>> how
>>>>>>>   all this will fit with the "has" new
>>> pattern....I'll try
>>>>> it.
>>>>>>> 
>>>>>>>   Just one important thing. There's actual users and
>>>>> clients using
>>>>>> Jewel
>>>>>>> and
>>>>>>>   other UI sets and are with very short times for
>>> their
>>>>>> migrations, so
>>>>>>> just
>>>>>>>   want to ask you to test as much as possible, since
>>> TDJ
>>>>> has many
>>>>>>> examples
>>>>>>>   now. Other thing you can test is new TodoMVC to see
>>> how it
>>>>>> behaves,
>>>>>>> since
>>>>>>>   it uses a List with IRs. So we can ensure (as much
>>> as we
>>>>> can)
>>>>>> the merge
>>>>>>>   left things working (as much as we can)
>>>>>>> 
>>>>>>>   Thanks for working on this, will try all of this
>>> tomorrow
>>>>>>> 
>>>>>>>   Carlos
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>   El lun., 17 feb. 2020 a las 22:35, Alex Harui
>>>>>>> (<[email protected] <mailto:[email protected]>>)
>>>>>>>   escribió:
>>>>>>> 
>>>>>>>> I've pushed the "has" branch that contains a
>>>>> refactoring of
>>>>>> the item
>>>>>>>> renderers.  Tour De Jewel and MDL Example seem to
>>> be
>>>>> working
>>>>>> as is
>>>>>>> Basic
>>>>>>>> List Example and MX AdvancedDataGrid.
>>>>>>>> 
>>>>>>>> "has" is really just calls to getBeadByType.  If
>>> we
>>>>> start to
>>>>>> see
>>>>>>>> performance issues, then we'll look into
>>> optimizing.
>>>>> The
>>>>>> motivation
>>>>>>> to
>>>>>>>> switch to "has" came from several bugs about
>>> using MX
>>>>>> Label/CheckBox
>>>>>>> as
>>>>>>>> item renderers.  In Royale, the ItemRenderers
>>> were in
>>>>> control
>>>>>> of the
>>>>>>>> visuals of their rollover and selected state.
>>> That is
>>>>> a more
>>>>>> proper
>>>>>>>> encapsulation than the way it was in Flex where
>>> the
>>>>> lists drew
>>>>>> the
>>>>>>> rollover
>>>>>>>> and selected states and it was hard to override
>>> the
>>>>> visuals
>>>>>> for a
>>>>>>> custom
>>>>>>>> item renderer.  But in the develop branch Royale
>>> code,
>>>>> it would
>>>>>>> require
>>>>>>>> that custom itemrenderers implement a lot of APIs
>>>>> related to
>>>>>>> rollover and
>>>>>>>> selected visuals.  Instead we can now reuse/share
>>> code
>>>>> for
>>>>>> visuals
>>>>>>> between
>>>>>>>> different renderers because a renderer now can
>>> "has" a
>>>>>>> rollover/selection
>>>>>>>> implementation instead of being one.
>>>>>>>> 
>>>>>>>> There are more pieces involved, but there is more
>>>>> sharing of
>>>>>> code.
>>>>>>> Along
>>>>>>>> the way I found that there were some not-so-PAYG
>>>>> patterns
>>>>>> being used
>>>>>>> in MDL
>>>>>>>> and Jewel renderers that might deserve further
>>>>> modification.
>>>>>> There
>>>>>>> are
>>>>>>>> "hoverable" and "selectable" APIs that appear to
>>> be
>>>>> used to
>>>>>>> permanently
>>>>>>>> turn off selection and hover visuals.  In
>>> general, I
>>>>> think
>>>>>> there is
>>>>>>> better
>>>>>>>> use of PAYG and composition when functionality is
>>>>> "built up"
>>>>>> and not
>>>>>>>> "turned off", so with the "has" pattern the
>>> renderers
>>>>> can be
>>>>>> added
>>>>>>> to a
>>>>>>>> list without any selection visuals at all (for a
>>>>> non-selectable
>>>>>>> list) or
>>>>>>>> re-composed with custom visuals that only support
>>>>> hoverable,
>>>>>> for
>>>>>>> example.
>>>>>>>> I left it "hoverable/selectable" in the API
>>> surface for
>>>>> now,
>>>>>> but
>>>>>>> something
>>>>>>>> to think about going forward.
>>>>>>>> 
>>>>>>>> I’m going to run a few more tests before merging
>>> and
>>>>> pushing to
>>>>>>> develop.
>>>>>>>> 
>>>>>>>> -Alex
>>>>>>>> 
>>>>>>>> On 1/15/20, 10:44 PM, "Alex Harui"
>>>>> <[email protected] <mailto:[email protected]>>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>   You are welcome to try and see how many cache
>>> hits
>>>>> it
>>>>>> gets.  I
>>>>>>> think
>>>>>>>> in renderers, we ask once per renderer.  I'm not
>>> sure
>>>>> there is
>>>>>> a
>>>>>>> faster way
>>>>>>>> to do the first lookup of "is", but for "has" we
>>> could
>>>>> change
>>>>>> the
>>>>>>> lookup
>>>>>>>> and save time.
>>>>>>>> 
>>>>>>>>   On 1/15/20, 10:38 PM, "Greg Dove" <
>>>>> [email protected] <mailto:[email protected]>>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>       For the  'something is ISomeInterface'
>>>>>>>>       I had wondered in the past if these types
>>> of
>>>>> lookups
>>>>>> could be
>>>>>>>> incrementally
>>>>>>>>       cached on the 'is' target (after first
>>> lookup),
>>>>> that
>>>>>> might
>>>>>>> make
>>>>>>>> sense for
>>>>>>>>       interfaces, which are the deepest checks I
>>>>> think?
>>>>>>>>       caching result (could optionally create
>>> the Map)
>>>>>>>> 
>>>>> ISomeInterface['implMap'].set(something.constructor,
>>>>>>> isResult )
>>>>>>>> 
>>>>>>>>       then earlier in the interface checks, it
>>> could
>>>>> do
>>>>>> something
>>>>>>> like:
>>>>>>>>        if (ISomeInterface['implMap']  &&
>>>>>>>> 
>>>>> ISomeInterface['implMap'].has(something.constructor) )
>>>>>> return
>>>>>>>> 
>>>>> ISomeInterface['implMap'].get(something.constructor)
>>>>>>>> 
>>>>>>>>       I realize its extra code, but it should be
>>>>> quite a bit
>>>>>>> faster over
>>>>>>>> time I
>>>>>>>>       think.
>>>>>>>> 
>>>>>>>>       On Thu, Jan 16, 2020 at 7:20 PM Alex Harui
>>>>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Several different threads have brought
>>> up
>>>>> issues with
>>>>>>> sharing
>>>>>>>> code between
>>>>>>>>> component sets.  Other threads have
>>> offered
>>>>>> different and
>>>>>>> clever
>>>>>>>> ways to
>>>>>>>>> do various things like how MXML is
>>> applied to
>>>>> a
>>>>>> component.
>>>>>>>> Meanwhile, over
>>>>>>>>> in MX emulation, I was starting to copy
>>> some
>>>>> code
>>>>>> from
>>>>>>> Basic to
>>>>>>>> MXRoyale to
>>>>>>>>> get the various MX components to be
>>> valid item
>>>>>> renderers.
>>>>>>>> MXRoyale is
>>>>>>>>> using Basic's item renderer architecture
>>>>> which is
>>>>>> better
>>>>>>>> encapsulated:  the
>>>>>>>>> renderer draws its hovered and selected
>>>>> state.  In
>>>>>> Flex,
>>>>>>> the
>>>>>>>> List draws
>>>>>>>>> over the renderer, which makes it hard
>>> to
>>>>> customize
>>>>>> the
>>>>>>> way the
>>>>>>>> renderer
>>>>>>>>> will look when hovered and selected.
>>>>>>>>> 
>>>>>>>>> It finally occurred to me that one of
>>> the
>>>>> reasons we
>>>>>> end up
>>>>>>>> copying code
>>>>>>>>> is because we are still using too many
>>> "is"
>>>>> checks
>>>>>> instead
>>>>>>> of
>>>>>>>> "has"
>>>>>>>>> checks.  I'm not even sure we have any
>>> "has"
>>>>> checks
>>>>>> in the
>>>>>>> Royale
>>>>>>>>> framework.  I was afraid of the
>>> overhead of a
>>>>> "has"
>>>>>> check,
>>>>>>> but
>>>>>>>> I'm starting
>>>>>>>>> to change my mind because:
>>>>>>>>> 
>>>>>>>>> 1) The "is" check actually runs a fair
>>> amount
>>>>> of
>>>>>> code,
>>>>>>>> especially for
>>>>>>>>> (comp is ISomeInterface)
>>>>>>>>> 2) The length of bead arrays don't seem
>>> too
>>>>> long.
>>>>>>>>> 
>>>>>>>>> A "has" check calls
>>>>> getBeadByType(ISomeInterface),
>>>>>> so it
>>>>>>>> actually will run
>>>>>>>>> the (bead is ISomeInterface) on
>>> potentially
>>>>> the
>>>>>> entire
>>>>>>> strand
>>>>>>>> array/vector,
>>>>>>>>> although we could speed that up by
>>> annotating
>>>>> beads
>>>>>> or
>>>>>>> keeping
>>>>>>>> track of
>>>>>>>>> what is on the strand.  But the code
>>>>> sharing/reuse
>>>>>>> potential of
>>>>>>>> this
>>>>>>>>> pattern seems significant to me.
>>>>>>>>> 
>>>>>>>>> For example, it could change how hard
>>> it is
>>>>> to make a
>>>>>>> component
>>>>>>>> usable as
>>>>>>>>> a top tag in MXML.  Instead of the
>>> component
>>>>> having
>>>>>> to
>>>>>>> implement
>>>>>>>> certain
>>>>>>>>> methods, the component could have a bead
>>>>> installed
>>>>>> and the
>>>>>>>>> MXMLDataInterpreter could talk to that
>>> bead
>>>>> instead
>>>>>> of the
>>>>>>>> component.
>>>>>>>>> 
>>>>>>>>> In the case of the item renderers,
>>> instead of
>>>>>> testing if
>>>>>>> the
>>>>>>>> renderer "is"
>>>>>>>>> ISelectableLIstItemRenderer, it could
>>> ask if
>>>>> the
>>>>>> created
>>>>>>> widget
>>>>>>>> "has" an
>>>>>>>>> ISelectableLIstItemRenderer bead and the
>>>>> logic in
>>>>>> that
>>>>>>> bead can
>>>>>>>> be reused
>>>>>>>>> in both Basic and MXRoyale without being
>>>>> copied.
>>>>>>>>> 
>>>>>>>>> Some code, like Container overrides of
>>>>> addElement
>>>>>> probably
>>>>>>> can't
>>>>>>>> be
>>>>>>>>> refactored into a "has".  But I wonder
>>> how
>>>>> many other
>>>>>>> things
>>>>>>>> could.  I'm
>>>>>>>>> not sure I would move everything that
>>> could
>>>>> be moved
>>>>>> into a
>>>>>>>> shared bead.
>>>>>>>>> We'd have to think about the overhead
>>> on small
>>>>>> components
>>>>>>> and
>>>>>>>> apps.  But
>>>>>>>>> for MXML support and Item Renderer
>>> support,
>>>>> it seems
>>>>>> to
>>>>>>> make
>>>>>>>> sense.
>>>>>>>>> 
>>>>>>>>> Anyway, I will look into refactoring
>>> the item
>>>>>> renderer
>>>>>>> code in
>>>>>>>> a  few days
>>>>>>>>> unless feedback indicates otherwise.
>>> Bugs
>>>>> like #676
>>>>>> and
>>>>>>> #681
>>>>>>>> inspired this
>>>>>>>>> post.
>>>>>>>>> 
>>>>>>>>> Of course, I could be wrong...
>>>>>>>>> -Alex
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>>   --
>>>>>>>   Carlos Rovira
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%3D&amp;reserved=0>
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=uVMuLeg2PCM83LdcsV4uFaEwULp7pLUpnjYUAvw45S0%3D&amp;reserved=0>>
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>>   --
>>>>>> 
>>>>>>   Piotr Zarzycki
>>>>>> 
>>>>>>   Patreon: *
>>>>>> 
>>>>> 
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&amp;reserved=0>
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&amp;reserved=0>>
>>>>>>   <
>>>>>> 
>>>>> 
>>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913766531&amp;sdata=49KiQxEH5tWTlgykACytbqjBPiaNAzGbExMW1erknr4%3D&amp;reserved=0>
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=xR9hDvBawl6sQwSD95C27PGQD6pwIj9qZ4BRXwKgjYU%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=xR9hDvBawl6sQwSD95C27PGQD6pwIj9qZ4BRXwKgjYU%3D&amp;reserved=0>>
>>>>>>> *
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>>   --
>>>>>   Carlos Rovira
>>>>> 
>>>>> 
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0>
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0>>
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Carlos Rovira
>>>> 
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0>
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0>>
>>>> 
>>>> 
>>> 
>>>   --
>>>   Carlos Rovira
>>> 
>>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0>
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0
>>>  
>>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0>>
>>> 
>>> 
>>> 
>> 
>>   -- 
>>   Carlos Rovira
>>   
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0
>>  
>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0>
>>  
>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0
>>  
>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C9e8243e128974cd78e0408d7b919997d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637181391913776525&amp;sdata=SJafbi5y5b4zzBblBm2vrWmtgm6fhJR6JehgsgJShpQ%3D&amp;reserved=0>>

Reply via email to