I think my main point was that we wouldn’t need computeFinalClassNames() which
would be overridden in subclasses.
If there’s simple a _classList:Array which would have something like:
protected function applyClassNames():void
{
element.className = className ? className : “” + “ “ +
_classList.join(“ “).trim();
}
Which could replace the setClassName() method.
The rest was simply how to go about building the _classList.
We’re probably more or less saying the same thing.
> On Feb 26, 2018, at 9:35 PM, Piotr Zarzycki <piotrzarzyck...@gmail.com> wrote:
>
> Harbs,
>
> You simply suggesting to have several functions instead of one which
> computes things?
>
>
>
> On Mon, Feb 26, 2018, 20:21 Harbs <harbs.li...@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 <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>*
>>
>>
>>
