royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Zarzycki <piotrzarzyck...@gmail.com>
Subject Re: TypeNames vs ClassName
Date Mon, 26 Feb 2018 19:35:03 GMT
Harbs,

You simply suggesting to have several functions instead of one which
computes things?



On Mon, Feb 26, 2018, 20:21 Harbs <harbs.lists@gmail.com> wrote:

> Yes. Very thorough explanation. Thanks.
>
> It seems to me like there should be functions for addClassName() and
> removeClassName() which would add and remove the classNames from a list.
> When the className is computed, the list should be concatenated to
> classNames (and possibly typeNames — although we might not need typeNames
> if there’s a general list). We might also want a clearClassNames() method
> to allow removal of “default” classNames for classes which have such a need.
>
> I do think we also need a className setter so classNames could be
> specified in mxml, but we might be able to do away with typeNames. That
> might simplify things.
>
> My $0.02,
> Harbs
>
>
> > On Feb 26, 2018, at 8:09 PM, Piotr Zarzycki <piotrzarzycki21@gmail.com>
> wrote:
> >
> > Hi Alex,
> >
> > Great reading and explanation. My first thought was to have something
> which
> > computes className together, but currently it is needed for MDL only
> > almost. I went with this additional function Utility.
> > I think there won't be too much time when we will need such ability like
> > switching and adding shadow css classes etc.
> >
> > If other also think about such function I would be happy to implement it.
> > It will really get rid of a lot of dump code and even some workarounds in
> > MDL. Live would be much easier.
> >
> > +1 to have such functions.
> >
> > All of that should land on the Wiki or somewhere in the documentation.
> >
> > Waiting for thoughts from others.
> >
> > Thanks, Piotr
> >
> > 2018-02-26 18:50 GMT+01:00 Alex Harui <aharui@adobe.com.invalid>:
> >
> >> Here's my view of this problem space.  This is my opinion, not marching
> >> orders.  Everything is up for discussion.  This is what the current code
> >> is trying to do, though.  Also, important note:  The order of names in
> the
> >> HTMLElement.className does not matter.  CSS style precedence is
> determined
> >> by the order of declarations in the CSS file.  OK, lots of reading
> ahead:
> >>
> >> HTML and JavaScript do not really have a first-class notion of a Class
> >> like we do in ActionScript.  IOW, no such thing as true subclassing,
> >> especially in a way that supports Reflection APIs like
> >> flash.utils.getQualifiedClassName.  So, there is a fixed set of types in
> >> the browser, such as Button, Input, Div (which, by the way, are
> >> implemented as instances of HTMLButtonElement, HTMLInputElement,
> >> HTMLDivElement and not just Button, Input, Div).  And thus, a fixed set
> of
> >> Type Selectors in CSS.  You can't really make up new Type selectors,
> AFAIK.
> >>
> >> A CSS Class selector is the way that you can distinguish one set of,
> say,
> >> HTMLDivElements, from another set of HTMLDivElements.  Since you can't
> >> make subclasses and new type selectors, you set the HTML class or
> >> JavaScript HTMLElement.className/classList on individual HTML elements
> and
> >> declare them to be of class "BigButton" or whatever.  It is their form
> of
> >> subclassing.
> >>
> >> In Flex/Flash/SWF/ActionScript, folks are used to being able to make a
> >> subclass of Button called BigButton.  And add a Type Selector for it in
> a
> >> CSS file as "BigButton {}" and not ".BigButton {}".  And the Flex/Royale
> >> compilers know that if you don't have a BigButton in the final output,
> it
> >> doesn't output the CSS for BigButton, making your app smaller.  If you
> use
> >> class selectors and ".BigButton" the Flex/Royale compilers do not search
> >> the code to see if some code sets className to "BigButton" and it really
> >> probably never can since you might have code that does:
> >>
> >> var kinds:Array ["Big", "Little", "Puny"];
> >> Foo.className = kinds[i] + "Button";
> >>
> >> So, IMO, in Royale we want to leverage ActionScript types and pretend to
> >> extend the Type Selectors subsystem in CSS.  I think we can't actually
> >> truly do it since the "*" selector will be masked by our fake Type
> >> Selectors, but it should be good enough, and it allows the compiler to
> >> prune CSS that isn't used.
> >>
> >> So, I think we want a convention where each class sets the "typename"
> >> property to itself if it wants to support a fake Type Selector.  I
> >> considered having the compiler auto-generate it but that isn't really
> PAYG
> >> for small lightweight subclasses that won't ever have a fake Type
> Selector.
> >>
> >> Now in Flex, and Royale's SimpleCSSValuesImpl for SWF, Type Selectors
> from
> >> ancestor classes apply to subclasses.  We did that because it was a pain
> >> to have to copy all of Label's Type Selector into a MultilineLabel Type
> >> Selector and that duplication made the CSS file bigger.  So we want to
> >> mimic that on the JS side as well.
> >>
> >> So to make all of that happen, any new "type" of component should set
> >> typeName to itself somewhere.  So Button and DataGrid should just have
> >> typeNames="Button" or typeNames="DataGrid".  But subclasses of these
> types
> >> can append themselves, so MultilineLabel does: typenames+="
> >> MultilineLabel".  That gets appended to Label's typeNames so the
> >> MultilineLabel's final typenames is "Label MultilineLabel".
> >>
> >> Recently, I proposed that the best place to allow appending of typeNames
> >> is in the constructor.  It makes appending easier (after the call to
> >> super()) and eliminates the need for simple subclasses to have to add a
> >> createElement call just to override typenames.
> >>
> >> And that's why I think typeNames should never be set from "outside" the
> >> class and maybe we should make it protected.  It is there to represent a
> >> new Type Name that folks can use to style EVERY instance of that type in
> >> their app without having to make up a new className and try to to miss
> >> setting that className on some MXML/HTML tag.  And similarly the code
> in a
> >> class should never set className on itself, because className should be
> >> reserved to be used by consumers of that component to further
> distinguish
> >> sets of instances of that component from other instances.
> >>
> >> And that's why, when we build complex views, we might make an instance
> of
> >> a TextInput in ComboBoxView and assign it a className.  We want to
> >> distinguish that TextInput from other TextInputs in the users app or in
> >> other views.  So we assign the TextInput in ComboBox a useful className
> >> like ComboBoxTextInput.  We could take the time to actually subclass
> >> TextInput and make a ComboBoxTextInput extends TextInput and then make a
> >> new type selector available in the CSS.  That would be cleaner, but it
> has
> >> a couple of disadvantages:  I think a subclass is more code than a CSS
> >> class selector, and it clutters the documentation.  I did play around
> with
> >> some convention to allow us to prune class selectors by somehow
> >> associating them with a type, but I'm not sure there's a great answer
> >> there.  But if you look in HelloWorld.css you'll see unused class
> >> selectors in there.
> >>
> >> There is no API to allow the consumer of the ComboBox to set classNames
> on
> >> the inner TextInput, so we document (or imply by its being in the CSS)
> >> that there is a class called ComboBoxTextInput.  We do this in order to
> >> not need advanced selector support on the SWF side.  Otherwise, we would
> >> probably build out shadow DOMs and use descendant selectors.
> >>
> >> Then, as if that wasn't complex enough (and you are still reading this),
> >> className is used in the browser as a convenient way to set buckets of
> >> styles on an element.  So lots of code in real web pages are dynamically
> >> changing the className/classList to add "shadow" or "emphasized" or
> things
> >> like that.  IMO, that's because there is no other way to do that in
> >> HTML/JS/CSS.  But because AS classes are not transformable at runtime
> (you
> >> can't turn an instance of Label into MultilineLabel, you have to
> >> instantiate a MultilineLabel and replace the Label instance), and
> because
> >> we have an extensible type selector system, we further want to allow
> >> className to be used to add buckets of style attributes dynamically at
> >> runtime.
> >>
> >> Yes, attributes like "shadow" could modify the typename instead of
> >> className.  In the end it does not matter as long as all strings end up
> in
> >> the HTMLElement.classList, and as I said at the top, the order does not
> >> matter.  The main goal is to list them all.  And, I suppose, to make
> >> changing at runtime easy.  I personally would lean away from having a
> >> shadow attribute change typenames because mentally for me, you can't
> >> change an AS class at runtime.  So, that's why I think className is
> >> better, and I would imagine that folks who don't use Royale would be
> >> setting className to include "shadow" and know that their other code
> can't
> >> just set className.
> >>
> >> Or maybe we just need to put the code that computes the final
> >> className/classList in an overridable method so that components that do
> >> have attributes that affect the classList can have all of that computed
> >> on-demand.  So in UIBase, where we currently set className, we could
> have
> >>
> >> element.className = computeFinalClassNames();
> >>
> >> Where:
> >>
> >> public function computeFinalClassNames():String
> >> {
> >>  return this.className + " " + this.typeNames;
> >> }
> >>
> >> And in MDL, or any component with attributes:
> >>
> >> private var _shadow:String;
> >> public function get shadow():Boolean
> >> {
> >>  return _shadow != null;
> >> }
> >> public function set shadow(value:Boolean):void
> >> {
> >>  _shadow = value ? "mdl-shadow" : null;
> >> }
> >> override public function computeFinalClassNames():String
> >> {
> >>  return super.computeFinalClassNames() + " " + _shadow;
> >> }
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 2/26/18, 5:14 AM, "Harbs" <harbs.lists@gmail.com> wrote:
> >>
> >>> Yes. The changes did break things.
> >>>
> >>> I committed an alternate way of fixing things.
> >>>
> >>> There is a discussion on Github on how strictly we avoid changing
> >>> typeNames:
> >>> https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fgithub.co
> >>> m%2Fapache%2Froyale-asjs%2Fcommit%2Fc01ebc2cc946570006d8f5cea607
> >> 182e16eaf0
> >>> fe%23r27788371&data=02%7C01%7Caharui%40adobe.com%
> >> 7Cb8a821250e814e93f88308d
> >>> 57d1af51c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636552477096186200&
> >>> sdata=%2BwCkmLjlAHyDACH294G4bEutIbK%2FDLsAkkSIhUc3cqA%3D&reserved=0
> >>> <https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fgithub.c
> >>> om%2Fapache%2Froyale-asjs%2Fcommit%2Fc01ebc2cc946570006d8f5cea607
> >> 182e16eaf
> >>> 0fe%23r27788371&data=02%7C01%7Caharui%40adobe.com%
> >> 7Cb8a821250e814e93f88308
> >>> d57d1af51c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636552477096186200
> >>> &sdata=%2BwCkmLjlAHyDACH294G4bEutIbK%2FDLsAkkSIhUc3cqA%3D&reserved=0>
> >>>
> >>> Thoughts?
> >>> Harbs
> >>>
> >>>> On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki <
> piotrzarzycki21@gmail.com>
> >>>> wrote:
> >>>>
> >>>> I just pushed changes to MDL. With couple of exceptions all typeNames
> >>>> landed to constructor. Thanks to that changes some components started
> to
> >>>> work better. I'm wondering whether I do not break anything.
> >>>>
> >>>> Harbs,
> >>>>
> >>>> If you are using something more than MDL Dialog in your application it
> >>>> would be great to get feedback whether I didn't break for you
> anything.
> >>>> :)
> >>>>
> >>>> Thanks, Piotr
> >>>>
> >>>> 2018-02-24 17:53 GMT+01:00 Alex Harui <aharui@adobe.com.invalid>:
> >>>>
> >>>>> Sorry, I wasn't clear.  The function itself can go in Basic or better
> >>>>> yet,
> >>>>> Core, since I don't think it has any dependencies and can be use
> >>>>> anywhere.
> >>>>> I was just saying that I would prefer if none of the Basic components
> >>>>> or
> >>>>> UIBase used your new function.  You should be able to write a Royale
> >>>>> app
> >>>>> with Basic and not bring in that function. Not that it isn't useful,
> >>>>> but
> >>>>> it isn't truly "basic" given that Basic components are supposed to
> have
> >>>>> typeNames.
> >>>>>
> >>>>> My 2 cents,
> >>>>> -Alex
> >>>>>
> >>>>> On 2/24/18, 8:17 AM, "Piotr Zarzycki" <piotrzarzycki21@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> I was going to put it somewhere in the Basic, but I can leave it in
> >>>>>> the
> >>>>>> MDL. The className can be undefined in the case where you wanted to
> >>>>>> add
> >>>>>> something to such "undefinded" string you will got:
> >>>>>>
> >>>>>> "undefined myClass". - I probably cannot escape from that...
> >>>>>>
> >>>>>> Maybe I'm missing some way.
> >>>>>>
> >>>>>> 2018-02-24 17:00 GMT+01:00 Alex Harui <aharui@adobe.com.invalid>:
> >>>>>>
> >>>>>>> Looks ok to me.  Seems like you don't need COMPILE::JS.  It should
> >>>>>>> work
> >>>>>>> on
> >>>>>>> all platforms.  We can have lots of utility functions in
> >>>>>>> org.apache.royale.utils.
> >>>>>>>
> >>>>>>> In terms of optimization (size/performance) a function like this is
> >>>>>>> potentially overkill for the Basic set.  It is fine for MDL since
> MDL
> >>>>>>> has
> >>>>>>> already picked up additional overhead in order to style
> "everything".
> >>>>>>> But
> >>>>>>> I subscribe to what I learned from a wise programmer many years
> ago:
> >>>>>>> If
> >>>>>>> you truly understand the problem space, you can often find a
> smaller,
> >>>>>>> faster solution.  Like I said, if you know that there "must" be at
> >>>>>>> least
> >>>>>>> one string from typenames as the last string, the replacement is
> much
> >>>>>>> easier.  All of the extra null checking and trimming in your
> version
> >>>>>>> is
> >>>>>>> not really needed for the specific problem of replacing from a set
> of
> >>>>>>> string you know about that don't need trimming.
> >>>>>>>
> >>>>>>> My 2 cents,
> >>>>>>> -Alex
> >>>>>>>
> >>>>>>> On 2/24/18, 4:50 AM, "Piotr Zarzycki" <piotrzarzycki21@gmail.com>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Alex,
> >>>>>>>>
> >>>>>>>> I used your suggestion, added some additional things and I end up
> >>>>>>>> with
> >>>>>>>> following utility [1]. Usage will looks like that: [2]. Do you
> >>>>>>>> think it
> >>>>>>>> could be part of the framework ? It's working nicely with MDL.
> >>>>>>>>
> >>>>>>>> [1]
> >>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>> https%3A%2F%2Fpaste.apa
> >>>>>>>> che.org%2FtsaF&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>> 7C91e633a78bea4fc4c89908d
> >>>>>>>> 57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>>>>>> 7C636550734524475642&
> >>>>>>>> sdata=O%2BZn0ajlM6A2Q0tBEBvDDtZZcNQYNOBsCn1kO0fgdPo%3D&reserved=0
> >>>>>>>> [2]
> >>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>> https%3A%2F%2Fpaste.apa
> >>>>>>>> che.org%2Fxbfb&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>> 7C91e633a78bea4fc4c89908d
> >>>>>>>> 57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>>>>>> 7C636550734524475642&
> >>>>>>>>
> sdata=j0n83ksobPZfR0YY7oMBJMU1dzx7fcW%2FNOmLd1S%2BL0o%3D&reserved=0
> >>>>>>>>
> >>>>>>>> Thanks, Piotr
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2018-02-23 21:31 GMT+01:00 Alex Harui <aharui@adobe.com.invalid>:
> >>>>>>>>
> >>>>>>>>> Well, whether you like it or not, the wrapper is mapping a
> >>>>>>>>> space-delimited
> >>>>>>>>> list to the array so if you manipulate the array you have to
> >>>>>>>>> back-calculate the string.  IMO, in HTML, the "class" property
> is a
> >>>>>>>>> string
> >>>>>>>>> and people are used to entering a space-delimited list.  That's
> why
> >>>>>>> we
> >>>>>>>>> have a className property on UIBase.  So that folks have
> something
> >>>>>>>>> similar
> >>>>>>>>> in MXML.
> >>>>>>>>>
> >>>>>>>>> So, unfortunately, your problem can't be as simple as
> manipulating
> >>>>>>>>> classList via its APIs.  Also consider that the classList API
> might
> >>>>>>>>> itself
> >>>>>>>>> be doing a string search in the array.
> >>>>>>>>>
> >>>>>>>>> If you have the string "Piotr Alex Harbs" and want to replace
> Alex
> >>>>>>> with
> >>>>>>>>> Peter and you know that Alex can't be the last item because the
> >>>>>>>>> last
> >>>>>>>>> item
> >>>>>>>>> is the typeName which is never null or "", then a simple
> >>>>>>> String.replace
> >>>>>>>>> call should work.
> >>>>>>>>>
> >>>>>>>>> className = className.replace(oldName + " ", newName + " ");
> >>>>>>>>>
> >>>>>>>>> HTH,
> >>>>>>>>> -Alex
> >>>>>>>>>
> >>>>>>>>> On 2/23/18, 12:21 PM, "Piotr Zarzycki" <
> piotrzarzycki21@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> It's just swapping. If I have following code [1] - it is easier
> to
> >>>>>>>>>> manipulate classList than className which is simple string. What
> >>>>>>>>> utility
> >>>>>>>>>> could look like ? It would be manipulating strings, which is
> less
> >>>>>>>>>> convenient.
> >>>>>>>>>>
> >>>>>>>>>> [1]
> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fpaste.apa
> >>>>>>>>>> che.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>>>> 7C061f7278ca3748bfaee408d
> >>>>>>>>>> 57afb14a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>>>>>>>> 7C636550141162759398&
> >>>>>>>>>> sdata=76W6lkZuIxUbO5mDtenl4g88zmRPsHaA1evyvvk7O08%3D&reserved=0
> >>>>>>>>>>
> >>>>>>>>>> 2018-02-23 21:11 GMT+01:00 Alex Harui <aharui@adobe.com.invalid
> >:
> >>>>>>>>>>
> >>>>>>>>>>> Just compiler.  No need for asjs changes at this time I think.
> >>>>>>>>>>>
> >>>>>>>>>>> I'm still unclear on why you need to manipulate classList
> >>>>>>> directly.
> >>>>>>>>> Is
> >>>>>>>>>>> there some code that is in the JS from Material that
> manipulates
> >>>>>>>>>>> classList?  Or are you just trying to swap out a name on the
> >>>>>>>>> classList?
> >>>>>>>>>>> If the latter, why not just create some utility function that
> >>>>>>>>> operates
> >>>>>>>>>>> on
> >>>>>>>>>>> className and not the underlying element?
> >>>>>>>>>>>
> >>>>>>>>>>> -Aleex
> >>>>>>>>>>>
> >>>>>>>>>>> On 2/23/18, 11:58 AM, "Piotr Zarzycki" <
> >> piotrzarzycki21@gmail.com
> >>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> You did merge vivid compiler changes or also changes from asjs
> >>>>>>>>>>> repository.
> >>>>>>>>>>>>
> >>>>>>>>>>>> As for my work on MDL. I ended up with something like that
> [1].
> >>>>>>> The
> >>>>>>>>>>>> question now how to propagate that code ? This is code for the
> >>>>>>>>>>> component
> >>>>>>>>>>>> which manipulates classList. Should I create some parent
> class ?
> >>>>>>>>>>> General/
> >>>>>>>>>>>> for MDL only, or Bead which will be included into such
> classes ?
> >>>>>>>>>>>> Theoretically bead could listen for initComplete.
> >>>>>>>>>>>>
> >>>>>>>>>>>> [1]
> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>>>> https%3A%2F%2Fpaste.apa
> >>>>>>>>>>>> che.org%2F1dy2&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>>>>>> 7C8e313e7d7f9d4608759f08d
> >>>>>>>>>>>> 57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >>>>>>>>>>> 7C636550127203173382&
> >>>>>>>>>>>> sdata=NkxHZQlHtOeJzWC%2BIyxxst89DlX0CCUa9VeGpztTL2s%
> >>>>> 3D&reserved=0
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Piotr
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2018-02-23 20:53 GMT+01:00 Alex Harui
> <aharui@adobe.com.invalid
> >>>>>> :
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I think I have Maven using the basic.css appropriately.
> There
> >>>>>>> is
> >>>>>>>>> no
> >>>>>>>>>>> way
> >>>>>>>>>>>>> to default to including a SWC in Maven and then not use it
> in a
> >>>>>>>>> child
> >>>>>>>>>>>>> project, so all example poms that aren't MDL need to bring in
> >>>>>>> the
> >>>>>>>>>>>>> BasicTheme.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Also, I had to merge the compiler change from vivid-ui-set
> >>>>>>> branch
> >>>>>>>>> to
> >>>>>>>>>>> get
> >>>>>>>>>>>>> the theme SWC to work in Maven.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Alex
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 2/23/18, 8:04 AM, "Alex Harui" <aharui@adobe.com.INVALID>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> MDL does not want the basic.css theme.  That is why we are
> >>>>>>> moving
> >>>>>>>>>>>>> styles
> >>>>>>>>>>>>>> from Basic:swc's defaults.css to themes/basic.css.  I see
> that
> >>>>>>>>> the
> >>>>>>>>>>>>> Maven
> >>>>>>>>>>>>>> plugin doesn't allow specification of a theme, so that's
> >>>>>>> another
> >>>>>>>>>>> task.
> >>>>>>>>>>>>> I
> >>>>>>>>>>>>>> can do it if nobody wants to take that on.  So, yes, move
> the
> >>>>>>>>> Button
> >>>>>>>>>>>>>> selectors from defaults.css to basic.css if that helps, but
> I
> >>>>>>>>> will
> >>>>>>>>>>> say
> >>>>>>>>>>>>>> that I didn't notice those styles taking effect in my local
> >>>>>>>>> version
> >>>>>>>>>>> of
> >>>>>>>>>>>>>> MDLTabsExample and assumed that mdl had overridden those
> >>>>>>> styles.
> >>>>>>>>> As
> >>>>>>>>>>>>>> Carlos said, in the end we want basic.css to be compliant
> CSS
> >>>>>>> so
> >>>>>>>>>>> don't
> >>>>>>>>>>>>>> move anything with ClassReference as the value without
> >>>>>>> discussing
> >>>>>>>>>>>>> first.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> TypeNames should be set after the call to super().  Look at
> >>>>>>> Label
> >>>>>>>>>>> and
> >>>>>>>>>>>>>> MultilineLabel.  They are working fine for me.  They are
> being
> >>>>>>>>> used
> >>>>>>>>>>> in
> >>>>>>>>>>>>>> RoyaleStore.  There might have been issues before yesterday
> >>>>>>>>> because
> >>>>>>>>>>>>> lots
> >>>>>>>>>>>>>> of Basic components were setting ClassName, but I went and
> >>>>>>>>> cleaned
> >>>>>>>>>>>>> that up
> >>>>>>>>>>>>>> although I could have missed a few.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In complex Views, you have two choices:  Make a subclass or
> >>>>>>>>> assign
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> className.  We should try to set set typeNames.  In fact,
> >>>>>>> maybe
> >>>>>>>>> we
> >>>>>>>>>>>>> should
> >>>>>>>>>>>>>> make typeNames protected.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So, for ComboBoxView, the current code is setting a custom
> >>>>>>>>> className
> >>>>>>>>>>>>> which
> >>>>>>>>>>>>>> is valid.  Users can then style it further by adding a
> >>>>>>>>>>>>> .ComboBoxTextInput
> >>>>>>>>>>>>>> selector to their CSS. However, class selectors are not
> >>>>>>> pruned by
> >>>>>>>>>>> the
> >>>>>>>>>>>>>> compiler.  So in other cases, we have created a real
> subclass
> >>>>>>> (in
> >>>>>>>>>>> this
> >>>>>>>>>>>>>> case "ComboBoxTextInput extends TextInput) and then the CSS
> >>>>>>> would
> >>>>>>>>>>> not
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>>> the "." in front so it would look like a type selector and
> the
> >>>>>>>>>>> compiler
> >>>>>>>>>>>>>> would prune it from apps that don't use a ComboBox.  Not
> sure
> >>>>>>>>> which
> >>>>>>>>>>> is
> >>>>>>>>>>>>>> better/faster,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Regarding Peter's point about Labels in Menus.  The issue
> >>>>>>> isn't
> >>>>>>>>> that
> >>>>>>>>>>>>> Flash
> >>>>>>>>>>>>>> can't handle it.  It is that our SimpleCSSValuesImpl lookup
> >>>>>>>>> doesn't
> >>>>>>>>>>>>> handle
> >>>>>>>>>>>>>> descendant and other advanced selectors.  The techniques for
> >>>>>>>>>>>>> ComboBoxView
> >>>>>>>>>>>>>> is how we avoid requiring a more complex lookup on the SWF
> >>>>>>> side.
> >>>>>>>>>>> The
> >>>>>>>>>>>>> menu
> >>>>>>>>>>>>>> code should not be setting typeNames on other things, only
> >>>>>>>>> itself.
> >>>>>>>>>>> I'm
> >>>>>>>>>>>>>> not sure if on the JS side, avoiding descendant selectors
> >>>>>>> speeds
> >>>>>>>>>>>>> things up
> >>>>>>>>>>>>>> in the browser or not.  We could create an IValuesImpl with
> >>>>>>>>>>> descendant
> >>>>>>>>>>>>>> selector support on the SWF side and probably will someday.
> >>>>>>>>>>> Volunteers
> >>>>>>>>>>>>>> are welcome to take that on.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Of course, I could be wrong...
> >>>>>>>>>>>>>> -Alex
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 2/23/18, 7:37 AM, "Piotr Zarzycki"
> >>>>>>> <piotrzarzycki21@gmail.com
> >>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> A bit more on point 1. and let's take for the example
> simple
> >>>>>>>>>>> Button.
> >>>>>>>>>>>>> We
> >>>>>>>>>>>>>>> have some styles for Button in Basic.css. MDL Button
> extends
> >>>>>>>>>>>>> TextButton -
> >>>>>>>>>>>>>>> some styles naturally has been added from default.css.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If I create theme I should achieve that my theme classes
> will
> >>>>>>>>>>> override
> >>>>>>>>>>>>>>> default.css Button styles and I should be good yes ?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Am I understand it correctly ?
> >>>>>>>>>>>>>>> Thanks, Piotr
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2018-02-23 16:32 GMT+01:00 Piotr Zarzycki
> >>>>>>>>>>> <piotrzarzycki21@gmail.com
> >>>>>>>>>>>> :
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Alex,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I have started to work on MDL and move all typeNames from
> >>>>>>>>>>>>> createElement
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> constructor. Unfortunately something is not right here.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1) I still need to exclude BasicJS.swc:default.css - I did
> >>>>>>> add
> >>>>>>>>>>>>> theme to
> >>>>>>>>>>>>>>>> MaterialDesignLite module maven build - it didn't help.
> >>>>>>>>>>>>>>>> 2) If I cannot setup typeNames and classNames inside my
> >>>>>>>>>>> component,
> >>>>>>>>>>>>> how
> >>>>>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>> I achieve switching some UI parts of the component ? In
> MDL
> >>>>>>>>> it is
> >>>>>>>>>>>>> quite
> >>>>>>>>>>>>>>>> common that if I would like to change component I'm adding
> >>>>>>> to
> >>>>>>>>> it
> >>>>>>>>>>> css
> >>>>>>>>>>>>>>>> class.
> >>>>>>>>>>>>>>>> [1] - This is the example. If I remove line it doesn't
> >>>>>>> work.
> >>>>>>>>>>> There
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>> several places in MDL where we are doing such things. It
> is
> >>>>>>>>>>> common
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>> JS
> >>>>>>>>>>>>>>>> world doing such things.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> typeNames = element.className;
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thoughts ?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> [1]
> >>>>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>>>>>> https%3A%2F%2Fpaste.a
> >>>>>>>>>>>>>>>> p
> >>>>>>>>>>>>>>>> ache.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>>>>>>>> 7Ca44c142f0ddc455c70bf
> >>>>>>>>>>>>>>>> 0
> >>>>>>>>>>>>>>>> 8d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>>>>>> cee1%7C0%7C0%7C636549970664822
> >>>>>>>>>>>>>>>> 4
> >>>>>>>>>>>>>>>> 53&sdata=1sSgdfBy%2BAv%2FsFIYwVFFHvVlhtJ3w3TW%
> >>>>>>>>>>>>> 2FiDEyPVYGmo%3D&reserved=0
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>> Piotr
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki
> >>>>>>>>>>>>> <piotrzarzycki21@gmail.com>:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Peter,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> That is interesting what you are saying. What will happen
> >>>>>>>>> then
> >>>>>>>>>>> if
> >>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>> have class which extends other one. The parent class is
> >>>>>>>>> setting
> >>>>>>>>>>>>>>>>> typeNames
> >>>>>>>>>>>>>>>>> and derived one also before super? The parent one will
> >>>>>>>>> override
> >>>>>>>>>>> it?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I cannot check now how typeNames is implemented.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Piotr
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Fri, Feb 23, 2018, 15:13 Peter Ent
> >>>>>>>>> <pent@adobe.com.invalid>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I have been guilty of this and have been using typeNames
> >>>>>>>>> now.
> >>>>>>>>>>> I've
> >>>>>>>>>>>>>>>>>> found
> >>>>>>>>>>>>>>>>>> that I need to set typeNames before calling super() in
> >>>>>>> the
> >>>>>>>>>>>>>>>>>> constructor. I
> >>>>>>>>>>>>>>>>>> thought it was done afterwards, but if I set typeNames
> >>>>>>> after
> >>>>>>>>>>>>> calling
> >>>>>>>>>>>>>>>>>> super(), the typeName I set does not show up in the HTML
> >>>>>>>>>>> produced.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Also, suppose I have this: A Menu with a label inside of
> >>>>>>> it.
> >>>>>>>>>>>>> People
> >>>>>>>>>>>>>>>>>> will
> >>>>>>>>>>>>>>>>>> want to change the background color of the menu and the
> >>>>>>>>> color
> >>>>>>>>>>> of
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> label's text. If I were doing this in plain HTML/JS/CSS,
> >>>>>>> I
> >>>>>>>>>>> would
> >>>>>>>>>>>>> set
> >>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> selector:  .Menu .Label { color: blue; } but that's not
> >>>>>>>>>>> supported
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> Flash Player. So when I set up the typeName for the
> label
> >>>>>>>>>>> inside
> >>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> Menu should I set it to: Menu_Label or MenuLabel or
> >>>>>>>>> Menu-Label?
> >>>>>>>>>>>>> And
> >>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>> using "." in a selector name a good idea? I would think
> >>>>>>> the
> >>>>>>>>> CSS
> >>>>>>>>>>>>>>>>>> processor
> >>>>>>>>>>>>>>>>>> in the browser would be confused between ".x.y" and ".x
> >>>>>>> .y"
> >>>>>>>>>>> which
> >>>>>>>>>>>>> can
> >>>>>>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>>> be written as ".x.y". Basically, we should have a
> consist
> >>>>>>>>>>> naming
> >>>>>>>>>>>>>>>>>> pattern
> >>>>>>>>>>>>>>>>>> here.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> ‹peter
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 2/23/18, 4:09 AM, "Gabe Harbs" <
> harbs.lists@gmail.com
> >>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> There¹s some edge cases which seem problematic. One
> >>>>>>>>> example:
> >>>>>>>>>>>>>>>>>>> ComboBoxBiew has the following:
> >>>>>>>>>>>>>>>>>>>          input = new TextInput();
> >>>>>>>>>>>>>>>>>>>          input.className = "ComboBoxTextInput";
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>          button = new TextButton();
> >>>>>>>>>>>>>>>>>>>          button.className =
> >>>>>>>>>>>>>>>>>>> "opt_org-apache.royale-html-ComboBox_Button";
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Input and button are both external to the view class,
> >>>>>>> but
> >>>>>>>>> are
> >>>>>>>>>>>>>>>>>> managed by
> >>>>>>>>>>>>>>>>>>> the view class. On the other hand, there is a chance
> >>>>>>> that
> >>>>>>>>> the
> >>>>>>>>>>>>> user
> >>>>>>>>>>>>>>>>>> might
> >>>>>>>>>>>>>>>>>>> wan to style them. I¹m not sure whether className or
> >>>>>>>>>>> typeNames is
> >>>>>>>>>>>>>>>>>> more
> >>>>>>>>>>>>>>>>>>> appropriate hereŠ
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Harbs
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Feb 23, 2018, at 11:03 AM, Gabe Harbs
> >>>>>>>>>>>>> <harbs.lists@gmail.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I¹ll help.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Feb 23, 2018, at 10:50 AM, Alex Harui
> >>>>>>>>>>>>>>>>>> <aharui@adobe.com.INVALID>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Quick note before I shut down for the night.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> UIBase has both a typeNames and className property.
> >>>>>>>>>>>>> TypeNames is
> >>>>>>>>>>>>>>>>>> used
> >>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>> emulate Flex-like type selectors in the CSS lookup.
> >>>>>>> It
> >>>>>>>>>>>>> should be
> >>>>>>>>>>>>>>>>>> set
> >>>>>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>> the constructor and never set from outside the class.
> >>>>>>>>>>> There
> >>>>>>>>>>>>> are
> >>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>> few
> >>>>>>>>>>>>>>>>>>>>> classes in Basic and lots of classes in MDL that
> >>>>>>> should
> >>>>>>>>> be
> >>>>>>>>>>>>>>>>>> upgraded
> >>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>> set
> >>>>>>>>>>>>>>>>>>>>> typeNames in the constructor.  Subclasses can append
> >>>>>>> to
> >>>>>>>>> the
> >>>>>>>>>>>>> base
> >>>>>>>>>>>>>>>>>>>>> class's
> >>>>>>>>>>>>>>>>>>>>> typeNames
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> className is the opposite.  It should never be set
> >>>>>>>>> inside
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> component's
> >>>>>>>>>>>>>>>>>>>>> class.  It is for users of that component to set
> >>>>>>> styles
> >>>>>>>>> on
> >>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> component.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Can we get a volunteer to clean this up?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>> -Alex
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Piotr Zarzycki
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Patreon:
> >>>>>>>>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>>>>>> https%3A%2F%2Fwww.pa
> >>>>>>>>>>>>>>>> t
> >>>>>>>>>>>>>>>> reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%
> 40adobe.com
> >>>>>>>>>>>>> %7Ca44c142f0dd
> >>>>>>>>>>>>>>>> c
> >>>>>>>>>>>>>>>> 455c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>>>>>> cee1%7C0%7C0%7C636549
> >>>>>>>>>>>>>>>> 9
> >>>>>>>>>>>>>>>> 70664822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
> >>>>>>>>>>>>> FFjSWC8LaxmWI%3D&reserve
> >>>>>>>>>>>>>>>> d
> >>>>>>>>>>>>>>>> =0
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>>>>>> https%3A%2F%2Fwww.pa
> >>>>>>>>>>>>>>>> t
> >>>>>>>>>>>>>>>> reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%
> 40adobe.com
> >>>>>>>>>>>>> %7Ca44c142f0dd
> >>>>>>>>>>>>>>>> c
> >>>>>>>>>>>>>>>> 455c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>>>>>> cee1%7C0%7C0%7C636549
> >>>>>>>>>>>>>>>> 9
> >>>>>>>>>>>>>>>> 70664822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
> >>>>>>>>>>>>> FFjSWC8LaxmWI%3D&reserve
> >>>>>>>>>>>>>>>> d
> >>>>>>>>>>>>>>>> =0>*
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Piotr Zarzycki
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Patreon:
> >>>>>>>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>>>>>> https%3A%2F%2Fwww.pat
> >>>>>>>>>>>>>>> r
> >>>>>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> >>>>>>>>>>>>> %7Ca44c142f0ddc4
> >>>>>>>>>>>>>>> 5
> >>>>>>>>>>>>>>> 5c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>>>>>> cee1%7C0%7C0%7C636549970
> >>>>>>>>>>>>>>> 6
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 64822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
> >>>>>>>>>>> FFjSWC8LaxmWI%3D&reserved=
> >>>>>>>>>>>>>>> 0
> >>>>>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>>>>>> https%3A%2F%2Fwww.pat
> >>>>>>>>>>>>>>> r
> >>>>>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> >>>>>>>>>>>>> %7Ca44c142f0ddc4
> >>>>>>>>>>>>>>> 5
> >>>>>>>>>>>>>>> 5c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>>>>>> cee1%7C0%7C0%7C636549970
> >>>>>>>>>>>>>>> 6
> >>>>>>>>>>>>>>> 64822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
> >>>>>>>>>>>>> FFjSWC8LaxmWI%3D&reserved=0>
> >>>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>>
> >>>>>>>>>>>> Piotr Zarzycki
> >>>>>>>>>>>>
> >>>>>>>>>>>> Patreon:
> >>>>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>>>> https%3A%2F%2Fwww.patr
> >>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>>>>>> 7C8e313e7d7f9d46
> >>>>>>>>>>>> 08759f08d57af7d477%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>>>> cee1%7C0%7C0%7C6365501272
> >>>>>>>>>>>
> >>>>>>>>>>>> 03173382&sdata=CTWhfUy0ILGvvx3HwRbmnkSZ3Nf5ay
> >>>>>>>>> lHwldhGDulDOE%3D&reserved=0
> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>>>> https%3A%2F%2Fwww.patr
> >>>>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>>>>>> 7C8e313e7d7f9d46
> >>>>>>>>>>>> 08759f08d57af7d477%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>>>> cee1%7C0%7C0%7C6365501272
> >>>>>>>>>>>> 03173382&sdata=CTWhfUy0ILGvvx3HwRbmnkSZ3Nf5ay
> >>>>>>>>>>> lHwldhGDulDOE%3D&reserved=0>*
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>>
> >>>>>>>>>> Piotr Zarzycki
> >>>>>>>>>>
> >>>>>>>>>> Patreon:
> >>>>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fwww.patr
> >>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>>>> 7C061f7278ca3748
> >>>>>>>>>> bfaee408d57afb14a9%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>> cee1%7C0%7C0%7C6365501411
> >>>>>>>>>
> >>>>>>>>>> 62759398&sdata=rpVtPRF2nJb03vSLEIQiK0K3uzGMs6
> >>>>>>> 6vbTZtOxsVXKs%3D&reserved=0
> >>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>>>> https%3A%2F%2Fwww.patr
> >>>>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>>>> 7C061f7278ca3748
> >>>>>>>>>> bfaee408d57afb14a9%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>>>> cee1%7C0%7C0%7C6365501411
> >>>>>>>>>> 62759398&sdata=rpVtPRF2nJb03vSLEIQiK0K3uzGMs6
> >>>>>>>>> 6vbTZtOxsVXKs%3D&reserved=0>*
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> Piotr Zarzycki
> >>>>>>>>
> >>>>>>>> Patreon:
> >>>>>>>> *https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>> https%3A%2F%2Fwww.patr
> >>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>> 7C91e633a78bea4f
> >>>>>>>> c4c89908d57b853bdf%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>> cee1%7C0%7C0%7C6365507345
> >>>>>>>> 24475642&sdata=dG08yDIsBZVQ1XNIJIjCCqFgQwgmNQ
> >>>>>>> HJQSQ7ds5O%2F38%3D&reserved=0
> >>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>>>> https%3A%2F%2Fwww.patr
> >>>>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
> >>>>>>> 7C91e633a78bea4f
> >>>>>>>> c4c89908d57b853bdf%7Cfa7b1b5a7b34438794aed2c178de
> >>>>>>> cee1%7C0%7C0%7C6365507345
> >>>>>>>> 24475642&sdata=dG08yDIsBZVQ1XNIJIjCCqFgQwgmNQ
> >>>>>>> HJQSQ7ds5O%2F38%3D&reserved=0
> >>>>>>>>> *
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>>
> >>>>>> Piotr Zarzycki
> >>>>>>
> >>>>>> Patreon:
> >>>>>> *https://na01.safelinks.protection.outlook.com/?url=
> >>>>> https%3A%2F%2Fwww.patr
> >>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
> >>>>> 7C0c4af859745d4f
> >>>>>> 1e55fb08d57ba22da3%7Cfa7b1b5a7b34438794aed2c178de
> >>>>> cee1%7C0%7C0%7C6365508588
> >>>>>> 36682085&sdata=vcTmV4sMSk3ZfhGCKd4mX6%2ByAb8saVYLysyZnCX%2FV8M%3D&
> >>>>> reserved
> >>>>>> =0
> >>>>>> <https://na01.safelinks.protection.outlook.com/?url=
> >>>>> https%3A%2F%2Fwww.patr
> >>>>>> eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%
> >>>>> 7C0c4af859745d4f
> >>>>>> 1e55fb08d57ba22da3%7Cfa7b1b5a7b34438794aed2c178de
> >>>>> cee1%7C0%7C0%7C6365508588
> >>>>>> 36682085&sdata=vcTmV4sMSk3ZfhGCKd4mX6%2ByAb8saVYLysyZnCX%2FV8M%3D&
> >>>>> reserved
> >>>>>> =0>*
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Piotr Zarzycki
> >>>>
> >>>> Patreon:
> >>>> *https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fwww.pat
> >>>> reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> >> %7Cb8a821250e81
> >>>> 4e93f88308d57d1af51c%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0%7C6365524
> >>>> 77096186200&sdata=9ERkTTu4TsGRD2j1uIrU1OggCl0EyW
> >> yGL2HD7sl5ALI%3D&reserved
> >>>> =0
> >>>>
> >>>> <https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fwww.pat
> >>>> reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
> >> %7Cb8a821250e81
> >>>> 4e93f88308d57d1af51c%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0%7C6365524
> >>>> 77096186200&sdata=9ERkTTu4TsGRD2j1uIrU1OggCl0EyW
> >> yGL2HD7sl5ALI%3D&reserved
> >>>> =0>*
> >>>
> >>
> >>
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message