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 <piotrzarzyck...@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 <aha...@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.li...@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 <piotrzarzyck...@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 <aha...@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" <piotrzarzyck...@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 <aha...@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" <piotrzarzyck...@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 <aha...@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" <piotrzarzyck...@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 <aha...@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" <
>> piotrzarzyck...@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 <aha...@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" <aha...@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"
>>>>>>> <piotrzarzyck...@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
>>>>>>>>>>> <piotrzarzyck...@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
>>>>>>>>>>>>> <piotrzarzyck...@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
>>>>>>>>> <p...@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.li...@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.li...@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I¹ll help.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Feb 23, 2018, at 10:50 AM, Alex Harui
>>>>>>>>>>>>>>>>>> <aha...@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>*
