Hi,
I tried to remove (commit d8ae342bb12e1006caed480dba7e3d91bab589da) and
seems all ok since is managed in the beads.
If is wrong feel free to revert
thanks
El vie., 21 feb. 2020 a las 12:11, Carlos Rovira (<carlosrov...@apache.org>)
escribió:
> Hi Alex,
> thanks for the changes all have more sense that way now.
> One question about Jewel ListItemRenderer.as
> in line 56
> addClass("selectable");
> that should remain?
> I guess it must be removed (like in "NavigationLinkItemRenderer" and "
> TabBarButtonItemRenderer"
> right?
>
> El jue., 20 feb. 2020 a las 23:03, Alex Harui (<aha...@adobe.com.invalid>)
> escribió:
>
>> 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" <carlosrov...@apache.org> 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
>> (<aha...@adobe.com.invalid>)
>> escribió:
>>
>> >
>> >
>> > On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrov...@apache.org>
>> 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 (<
>> > carlosrov...@apache.org>)
>> > 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
>> > (<aha...@adobe.com.invalid>)
>> > > 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" <
>> carlosrov...@apache.org>
>> > 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
>> > >> (<aha...@adobe.com.invalid>)
>> > >> 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" <
>> > piotrzarzyck...@gmail.com>
>> > >> 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
>> > <aha...@adobe.com.invalid>
>> > >> > 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" <
>> > carlosrov...@apache.org
>> > >> >
>> > >> > 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
>> > >> > > (<aha...@adobe.com.invalid>)
>> > >> > > 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"
>> > >> <aha...@adobe.com.INVALID>
>> > >> > 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" <
>> > >> greg.d...@gmail.com>
>> > >> > 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
>> > >> > > > <aha...@adobe.com.invalid> 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&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> >
>> > >> > --
>> > >> >
>> > >> > Piotr Zarzycki
>> > >> >
>> > >> > Patreon: *
>> > >> >
>> > >>
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0
>> > >> > <
>> > >> >
>> > >>
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0
>> > >> > >*
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >> --
>> > >> Carlos Rovira
>> > >>
>> > >>
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
>> > >>
>> > >>
>> > >>
>> > >
>> > > --
>> > > Carlos Rovira
>> > >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
>> > >
>> > >
>> >
>> > --
>> > Carlos Rovira
>> >
>> >
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0
>> >
>> >
>> >
>>
>> --
>> Carlos Rovira
>>
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0
>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>
--
Carlos Rovira
http://about.me/carlosrovira
