royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: TypeNames vs ClassName
Date Mon, 26 Feb 2018 19:21:42 GMT
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
View raw message