Hi Piotr,
Remember that any top-level component is a composition of beads. We
should be able to create most top-level components by take UIBase and
adding beads to the strand.
So, if we find when implementing skinning/themeing that there are
re-usable pieces from Basic great, but what is most important is defining
the HTMLElement topologies. Really, Carlos/Angelo can do most of this
experimenting in pure HTML and CSS. I believe the first test is to define
a set of HTMLElements for each component and two or more CSS files and
show that you can modify every pixel with the CSS files and the
component's mouse and keyboard functionality is "correct" (that you can
click on the label or the box of a checkbox, that you can tab through a
set of radio buttons, etc.
IMO, this is stage 1: For a given set of HTMLElements, you can use CSS to
affect every pixel. Later, we can try to solve issues where the
limitations of CSS (and background-image) somehow doesn't meet our needs.
My 2 cents,
-Alex
On 11/5/17, 10:30 PM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> wrote:
>Alex,
>
>You are saying about simple case where we can extend UIBase for create new
>Button, but what about more sophisticated for example Panel ? Do you want
>us to create from scratch again all of that instead use Basic ? This is
>how
>I see reading your last email or maybe I missing something.
>
>Thanks, Piotr
>
>
>2017-11-06 6:36 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
>
>> I'm not quite sure what the meaning of "based on Basic" means. I think
>> someone is about to go and move a bunch of classes around to better
>> organize our packages and classes, and I think that IUIBase and maybe
>> UIBase should end up back in Core (where it was before Harbs temporarily
>> wrapped the Sprites for SWF output).
>>
>> So, if you are saying that SkinnableCheckbox will extend UIBase, that
>> makes sense. Should it extend Basic Checkbox? Possibly, if the
>>override
>> of createElement is straightforward.
>>
>> IMO, we shouldn't worry about Express or Basic. Just figure out what
>> HTMLElements you need in what positions and sizes to get the visual
>> changes you want. Then once we get it looking right, we can look at how
>> it compares with the other components and decide if we want to
>>restructure
>> anything.
>>
>> I'm not quite sure how CSSCheckbox works. It could be that there is a
>>Div
>> where others have used a Span to hide the <input> and display something
>> else instead, otherwise I would think you couldn't control the visuals
>>of
>> the check via CSS. These are the kinds of things we have to decide on.
>>
>> It is fine to start with some list of components in order to bound the
>> work, but IMO, it is also important to have an understanding of the
>>design
>> principles so that other designers will have a better idea of how to add
>> some other component that isn't on the list someday. I guarantee
>>someone
>> will come up with something new and Carlos/Angelo won't have time to
>> design a default skin for it.
>>
>> When writing framework, I like to stop and consider whether any line of
>> code is going to lock someone into something they might not want.
>>That's
>> why we have beads and multiple component sets. We want everything to be
>> replaceable. I don't know if there is an analogy for Skins/Themes, but
>>I
>> think it would be to stop and consider if the HTMLElement topology 1)
>> allows every pixel to be changed, and 2) if any two HTMLElements
>>overlap,
>> if there are too many limitations imposed by that overlap. If someone
>> wants to Skin with Android, IOS, or even Windows 2.x or an old
>> green-screen terminal, can they?
>>
>> My 2 cents,
>> -Alex
>>
>> On 11/5/17, 1:29 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>> >Basic is going to be the base for anything. I don’t think Express is
>> >going to be very helpful. It should probably just be built out from
>>Basic
>> >components and/or copied from Basic.
>> >
>> >For an example of a styleable component, take a look at CSSCheckbox. I
>> >think that’s a good example of a styleable component. You might be able
>> >to do better, but I had a need for a checkbox which could be styled
>>using
>> >CSS and I created that class. I wanted to use a topcoat-styled
>>checkbox,
>> >which I was able to do using that class like this:
>> >
>> >package com.printui.view.components
>> >{
>> > import org.apache.flex.html.CSSCheckBox;
>> >
>> > public class CheckBox extends CSSCheckBox
>> > {
>> > public function CheckBox(){
>> > super();
>> > className="topcoat-checkbox";
>> > checkClassName="topcoat-checkbox__checkmark";
>> > }
>> > }
>> >}
>> >
>> >I then used that class in my app.
>> >
>> >There might be more elegant ways to specify classes, but this is how I
>> >did it…
>> >
>> >Here’s what it looks like in the app:
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.evern
>> >ote.com%2Fl%2FAI_1QITiAqVCe5rgWuBlfIr3HjEQic1Dh
>> pQB%2Fimage.png&data=02%7C0
>> >1%7C%7Cdfc2dc02415b446e995108d524945950%7Cfa7b1b5a7b34438794aed2c178de
>> cee1
>> >%7C0%7C0%7C636455141932227764&sdata=CCCp3fmlnGFtImPTsEf9JsIXJdkcQV
>> g3zbkIch
>> >2buoc%3D&reserved=0
>> >
>> >Hope this is useful,
>> >Harbs
>> >
>> >> On Nov 5, 2017, at 11:01 PM, Piotr Zarzycki
>><piotrzarzyck...@gmail.com>
>> >>wrote:
>> >>
>> >> I was thinking about that and new component set is the approach
>>which we
>> >> should try, but we need to base on something. My first thoughts was
>> >>that it
>> >> should be Basic, cause I bet that once we start create style for each
>> >> component we will end up with some issue or we would like to create
>>some
>> >> additional features to those controls in order to make that theme
>> >>happen.
>> >> It leads my thought then farther let's say that we will start work in
>> >> following way:
>> >> 1) Basic is our base
>> >> 2) Carlos will prepare some appearance for component
>> >> 3) We are starting to work on that, but it's end up that our
>>component
>> >>need
>> >> some additional feature, which is do not suits for Basic
>> >> 4) We are adds that feature to Express and use in that place Express
>> >> component.
>> >>
>> >> It ends up that our component theme will be mix of Express and Basic
>> >>
>> >> Second approach is - Forget about Express, use Basic only and add to
>> >>Theme
>> >> set features if needed. Express will be always separate set, FAT and
>>it
>> >> will be responsibility for user if he would like to style it. - If
>>our
>> >> implementation will be in Theme enough robust, user should be able to
>> >>use
>> >> in his application Express with some styles from Theme set.
>> >>
>> >> Thoughts ?
>> >> Piotr
>> >>
>> >>
>> >> 2017-11-05 11:21 GMT+01:00 Harbs <harbs.li...@gmail.com>:
>> >>
>> >>> I would suggest starting a new component set with a fresh slate
>>called
>> >>> Themed (or something like that).
>> >>>
>> >>> The Themed component set should give priority to style-ablitity and
>> >>>ease
>> >>> of use over just about every other consideration. I think of
>>Express as
>> >>> more of a middle-of the road approach to make things easier. A
>>Themed
>> >>>set
>> >>> would be more of a replacement for mx and spark.
>> >>>
>> >>> Yes. Definitely make a clear list of supported components. It’s
>> >>>probably
>> >>> more important to have quality of components rather than quantity. A
>> >>>few
>> >>> well constructed components is better than a lot of half-baked ones.
>> >>>More
>> >>> components could always be added.
>> >>>
>> >>> I’m very glad to hear that Angelo is working with you. That’s great
>> >>>news!
>> >>>
>> >>> Harbs
>> >>>
>> >>>> On Nov 5, 2017, at 12:12 PM, Carlos Rovira <
>> >>> carlos.rov...@codeoscopic.com> wrote:
>> >>>>
>> >>>> ok Alex,
>> >>>>
>> >>>> so if I understand correctly, you mean that we create our own set,
>> >>>>with
>> >>>> Basic as base right?
>> >>>> but we should go with Express? It's great that we could create many
>> >>>>sets
>> >>> in
>> >>>> Royale, and I think the Basic use
>> >>>> you commented is very licit and didn't think about that. But we
>>must
>> >>> think
>> >>>> in some *main* set, maybe is Express
>> >>>> and that I want to focus this effort for that concrete set.
>> >>>>
>> >>>> I mean, one important thing here is that we all agree in support a
>> >>> concrete
>> >>>> list of UI controls and components
>> >>>> I plan to make a discuss thread for this, since the theme feature
>>will
>> >>>> affect only to that controls, and if we want to include a new one
>> >>>> we should vote to include it, since it implies to include in
>>design,
>> >>>> implementation and all themes that we want to support.
>> >>>>
>> >>>> I think I'll create a discuss thread with this an other things we
>> >>>>talked
>> >>>> about since this is a huge effort and is important for all the
>> >>>> people that will be involved to work around things discussed, voted
>> >>>>and
>> >>>> approved by all.
>> >>>> We need to be synced here or we'll end working too much for
>>somehitng
>> >>> that
>> >>>> does not get to be useful in the end. I want to ensure this before
>> >>>> to start investing a huge amount of time.
>> >>>>
>> >>>> As well I was contacted by Angelo and talk about all this. He's
>>very
>> >>>> passionate as well on this and we'll seeing how we can combine our
>> >>> efforts
>> >>>> and if someone
>> >>>> more wants to join us.
>> >>>>
>> >>>> I'll be writing the discussion thread in order to plan the effort
>>in
>> >>> short.
>> >>>> Stay tuned :)
>> >>>>
>> >>>> 2017-11-05 8:29 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
>> >>>>
>> >>>>> Hi Carlos,
>> >>>>>
>> >>>>> I think we're pretty much in agreement. Regarding Basic, for me,
>>I
>> >>>>>have
>> >>>>> created plenty of web pages with non-styleable checkboxes. I
>>don't
>> >>>>>care
>> >>>>> that the checkbox looks different on different browsers. I just
>>want
>> >>> the
>> >>>>> smallest simplest output. Just like taking an HTML editor and
>> >>>>>slapping
>> >>> in
>> >>>>> a few tags and calling it done. Would that be production? Sure,
>>if
>> >>>>>I'm
>> >>>>> just want someone to check a box before enabling a download
>>button.
>> >>> IOW,
>> >>>>> it would be for internal customers only.
>> >>>>>
>> >>>>> So, IMO, a Skinnable/Themeable component set would be something
>> >>>>>else. I
>> >>>>> think you will need that extra Span for a Checkbox. IMO, we
>>should
>> >>>>>just
>> >>>>> go and build these new components. And when we get it mostly
>> >>>>>working,
>> >>> we
>> >>>>> can compare against Basic and see if we want to parameterize the
>> >>>>>views
>> >>> in
>> >>>>> the low-level Basic components or not.
>> >>>>>
>> >>>>> My 2 cents,
>> >>>>> -Alex
>> >>>>>
>> >>>>> On 11/4/17, 8:19 AM, "carlos.rov...@gmail.com on behalf of Carlos
>> >>> Rovira"
>> >>>>> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
>> wrote:
>> >>>>>
>> >>>>>> HI Alex,
>> >>>>>>
>> >>>>>>
>> >>>>>> 2017-11-03 17:52 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
>> >>>>>>
>> >>>>>>> Hi Carlos,
>> >>>>>>>
>> >>>>>>> I skimmed through
>> >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>> https%3A%2F%2Fmaterial
>> >>>>>>>
>> >>>>>>>.io%2Fguidelines%2F%23&data=02%7C01%7C%
>> 7Cbb03216ec0b84fcb6ab108d5239
>> >>>>>>>7
>> >>>>> 82e0
>> >>>>>>> %7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >>>>> 7C636454056000808812&sdata=g5
>> >>>>>>> M5cpOsQUPasZfgmUddvnzmY3gF%2B1N%2B7j6Apgyf2Us%3D&reserved=0 last
>> >>> night.
>> >>>>>>>
>> >>>>>>> My impression is that there were two parts to it. First was the
>> >>>>>>> environment/principles section which talked about physical
>>objects
>> >>>>>>>and
>> >>>>>>> light (and motion), and then there were choices of widgets. For
>> >>>>>>> example,
>> >>>>>>> I didn't see anything in the first part that said that a text
>>input
>> >>> had
>> >>>>>>> to
>> >>>>>>> be a single line and couldn't be a box.
>> >>>>>>>
>> >>>>>>
>> >>>>>> Material guidelines could be a great way to start, but trying to
>> >>>>>>give
>> >>>>>> something different.
>> >>>>>> I think that we need to get something that looks great while be
>> >>>>>>clearly
>> >>>>>> different to google material,
>> >>>>>> bootstrap, and others so people could see us as an alternative.
>>That
>> >>> could
>> >>>>>> make people copying us
>> >>>>>> or adopting the whole Apache Royale SDK that is what we want in
>>the
>> >>>>>>end
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> That made me think that we could use our widget set and apply
>> >>>>>>>Material
>> >>>>>>> environment and principles to it. If we decide not to, I would
>> >>>>>>>think
>> >>>>>>> you
>> >>>>>>> would want to have some sort of similar environment/principles
>> >>> document
>> >>>>>>> which seems like a fair amount of work. I think we'd end up
>> >>>>>>>looking
>> >>>>>>> different because we have different widgets and maybe some
>> >>>>>>>different
>> >>>>>>> colors. I'm pretty sure that we don't want to be different so
>>much
>> >>> that
>> >>>>>>> we don't create things that folks want to use. The priority to
>>me
>> >>>>>>>is
>> >>>>>>> just
>> >>>>>>> to prove that you can alter every pixel in every widget we have
>>so
>> >>> that
>> >>>>>>> others can provide custom skins as well. So starting with
>>Material
>> >>>>>>> principles seems like it would save us time, we can get
>>something
>> >>>>>>> released, and can innovate more later.
>> >>>>>>>
>> >>>>>>
>> >>>>>> I think as you that we need a way to make the "presentation" of
>>each
>> >>>>>> component highly customizable.
>> >>>>>> And we need to be different in visualization (art, colors, ...)
>>but
>> >>> not in
>> >>>>>> usability that is what people
>> >>>>>> needs to be consistently
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Maybe a good question for our users is: How many of you used
>>the
>> >>>>>>> default
>> >>>>>>> Flex skins vs a whole new set of skins? If most folks
>>completely
>> >>>>>>> re-skinned to match their corporate branding, it matters less
>>what
>> >>>>>>>our
>> >>>>>>> default is, and more that we can allow folks to customize every
>> >>>>>>>pixel.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> We need both: a skin that will be highly customizable and to
>>change
>> >>> skins
>> >>>>>> to look very very different.
>> >>>>>> People with lees money or time in their Apps will choose the
>>first.
>> >>> People
>> >>>>>> that has more resources will go with the second.
>> >>>>>> Apache Royale needs to support both
>> >>>>>>
>> >>>>>>
>> >>>>>>> The wireframe can be black and white, IMO. I was thinking that
>> >>> "vivid"
>> >>>>>>> would have parameterized colors.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> I started to think that wireframe could end having lots of
>> >>> customization
>> >>>>>> controls. For example:
>> >>>>>>
>> >>>>>> -2-3 main colors as we talked , and the same MDL does
>> >>>>>> -possibilitiy to be solid colors, or gradients
>> >>>>>> -possibility to have backgrounds more or less opaque
>> >>>>>>
>> >>>>>> if we see a concrete component like button:
>> >>>>>>
>> >>>>>> - configurable corners, square to round corners
>> >>>>>> - more blocky (relief) or more flat
>> >>>>>> ...
>> >>>>>>
>> >>>>>> So wireframe could be a concrete configuration of the main theme
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> Since Bootstrap was mentioned, I want to point out that the
>> >>>>>>>Flat.swc
>> >>> is
>> >>>>>>> a
>> >>>>>>> rough approximation of the Flat theme which is a Bootstrap
>>theme.
>> >>>>>>>It
>> >>>>>>> is a
>> >>>>>>> rough approximation because I could not use the Flat CSS file
>> >>>>>>>directly
>> >>>>>>> since it contains much more advanced CSS than we currently
>>support
>> >>>>>>>on
>> >>>>>>> the
>> >>>>>>> SWF side. But it presumed that the Checkbox was a Label with a
>> >>>>>>>Span
>> >>>>>>> that
>> >>>>>>> hides in front of or behind the <input type="check" /> in order
>>to
>> >>> allow
>> >>>>>>> customizing every pixel. Looks like MDL uses the same Span
>>trick
>> >>>>>>>but
>> >>>>>>> maybe without a symbol font.
>> >>>>>>>
>> >>>>>>> Basic is, IMO, truly meant to be Basic. I think the Basic
>>Checkbox
>> >>>>>>> should
>> >>>>>>> not have that extra Span. But it looks to me that a
>> >>>>>>>SkinnableCheckbox
>> >>>>>>> can
>> >>>>>>> add that extra Span and you either give it the same class name
>>that
>> >>>>>>> BootStrap or MDL uses or create our own set of classnames and
>>the
>> >>>>>>>CSS
>> >>>>>>> that
>> >>>>>>> goes with it.
>> >>>>>>>
>> >>>>>>>
>> >>>>>> The problem with Basic could be that if is very very basic and
>>looks
>> >>> with
>> >>>>>> a
>> >>>>>> very basic look (as it is very poorly stylizable), I think
>> >>>>>> People will not use it at all, in this case, I'll don't
>>understand
>> >>>>>>the
>> >>>>>> goal
>> >>>>>> with basic. It's intend ended as a base
>> >>>>>> but to not use in production? For this reason is what I want to
>> >>>>>>know if
>> >>>>>> you
>> >>>>>> think this theme feature could be plugged in basic or not.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> Of course, I could be wrong. This is not my area of expertise
>>at
>> >>>>>>>all.
>> >>>>>>>
>> >>>>>>
>> >>>>>> Hi Alex, maybe UX is not your expertise area, but your help here
>>is
>> >>> very
>> >>>>>> needed since we can get to great ideas in this field, but
>> >>>>>> maybe don't know how to bring it to implementation in Apache
>> >>>>>>Royale. I
>> >>>>>> think that you, Peter, Harbs,... are needed in order to
>> >>>>>> make this happen in the pure arquitecture side or this feature.
>> >>>>>>
>> >>>>>> Thanks
>> >>>>>>
>> >>>>>> -Alex
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On 11/3/17, 1:35 AM, "carlos.rov...@gmail.com on behalf of
>>Carlos
>> >>>>>>> Rovira"
>> >>>>>>> <carlos.rov...@gmail.com on behalf of
>> >>>>>>>carlos.rov...@codeoscopic.com>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>>> Hi Alex,
>> >>>>>>>>
>> >>>>>>>> 2017-11-03 7:39 GMT+01:00 Alex Harui
>><aha...@adobe.com.invalid>:
>> >>>>>>>>
>> >>>>>>>>> Hi Carlos,
>> >>>>>>>>>
>> >>>>>>>>> Looks good to me. Thanks for doing this.
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Thanks :)
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> I'm not sure I understand all of the aspects of this effort.
>>My
>> >>>>>>> current
>> >>>>>>>>> understanding is that Google Material is under the Apache
>>License
>> >>> and
>> >>>>>>>>> thus
>> >>>>>>>>> we can use it if we want to. Am I correct that
>> >>>>>>>>>MaterialDesignLite
>> >>> is
>> >>>>>>>>> one
>> >>>>>>>>> implementation of Google Material and we could create our own
>> >>>>>>>>> implementation and it could be visually different?
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> We can implement our own material in Royale, but I'm afraid
>>that
>> >>> doing
>> >>>>>>>> that
>> >>>>>>>> will not make us
>> >>>>>>>> highlight our solution against the rest of competitors. Another
>> >>>>>>>>point
>> >>>>>>> is
>> >>>>>>>> something I said various times:
>> >>>>>>>> When I did MDL, I notice a huge problem: MDL has its own set of
>> >>>>>>>> components,
>> >>>>>>>> some are in all sets (Button)
>> >>>>>>>> but others not (Card), and they has it's own implementation,
>>what
>> >>> make
>> >>>>>>> it
>> >>>>>>>> almost impossible generalize
>> >>>>>>>> a theme. For this reason I always point that we need our own
>>set
>> >>>>>>>>and
>> >>>>>>> there
>> >>>>>>>> we can implement themes. But other
>> >>>>>>>> *externa* sets will never get this since they have its own
>> >>>>>>> implementation
>> >>>>>>>> and most important once you start to develop
>> >>>>>>>> with MDL you can't go back and change for other. So MDL is for
>>me
>> >>>>>>>> something
>> >>>>>>>> we have until our own set are robust and
>> >>>>>>>> highly configurable in both the things we can do and how can it
>> >>>>>>>>could
>> >>>>>>> be
>> >>>>>>>> represented, and switch between style should be
>> >>>>>>>> really easy to change the global look of an App without much
>> >>>>>>>>hassle.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Also, IIRC, Material has different components than Flex did so
>> >>>>>>>>>we'd
>> >>>>>>> have
>> >>>>>>>>> to invent some new looks anyway. So having a TextInput with
>> >>>>>>>>>borders
>> >>>>>>> all
>> >>>>>>>>> around would just be our flavor of Material.
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> That's what I point above. We must to *freeze* the list of
>> >>>>>>>>components
>> >>>>>>> at
>> >>>>>>>> some time work over a concrete set
>> >>>>>>>> We can then plan in the future include a new component in the
>> >>> official
>> >>>>>>>> set,
>> >>>>>>>> and that will need to work on the themes we already
>> >>>>>>>> have to include the new one.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Regarding colors, it looks like Material is parameterized
>>around
>> >>>>>>>>>a
>> >>>>>>>>> couple
>> >>>>>>>>> of colors. So if we did our skins to work against
>>parameterized
>> >>>>>>> colors
>> >>>>>>>>> then would it really matter what color we choose?
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> That's completly right. I could make wireframe based on two or
>> >>>>>>>>three
>> >>>>>>>> colors
>> >>>>>>>> and as you change it in CSS all controls should tint
>> >>>>>>>> consistently.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Regarding Basic components, right now Checkbox is a
>><label><input
>> >>>>>>>>> type="check"/>caption</label>. AIUI, you cannot style the
>> >>>>>>>>><input>
>> >>> on
>> >>>>>>>>> many
>> >>>>>>>>> browsers, so I think we have to have a different set of
>>elements
>> >>>>>>>>>in
>> >>> a
>> >>>>>>>>> checkbox. It looks like Bootstrap uses:
>> >>>>>>>>>
>> >>>>>>>>> <label><input type="check"/><span />Caption</label>
>> >>>>>>>>>
>> >>>>>>>>> Where the span uses a special symbol font with checked and
>> >>>>>>>>>unchecked
>> >>>>>>>>> boxes.
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>> That's what we need to figure. Should we make themes available
>>in
>> >>>>>>> Basic?
>> >>>>>>>> if
>> >>>>>>>> so, has basic the right implementation?
>> >>>>>>>> If not, and if we don't want to change the actual very basic
>> >>>>>>>> implementation, we need to put some "skin" implementation
>> >>>>>>>> that at least in JS implementation I figure that will change
>>one
>> >>>>>>>>face
>> >>>>>>> (the
>> >>>>>>>> actual basic) with the theme face.
>> >>>>>>>>
>> >>>>>>>> I'm thinking loud, since this is something we should explorer
>>all
>> >>>>>>> together
>> >>>>>>>> mixing the best ideas of people involved
>> >>>>>>>>
>> >>>>>>>> Thanks
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Thanks,
>> >>>>>>>>> Alex
>> >>>>>>>>>
>> >>>>>>>>> On 11/2/17, 5:15 PM, "carlos.rov...@gmail.com on behalf of
>> Carlos
>> >>>>>>>>> Rovira"
>> >>>>>>>>> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org>
>> >>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Hi,
>> >>>>>>>>>>
>> >>>>>>>>>> I want to expose my initial work (very very initial) on two
>> >>>>>>>>>>styles
>> >>>>>>> for
>> >>>>>>>>>> Royale
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> Wireframe:
>> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fsnag.gy%2
>> >>>>>>>>>> FtDFxQT.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa7b1b5a7
>> >>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=%2Fk8YQxC5bDOaC
>> >>>>>>>>>> D8ZfcTzpuqZyBNTKKvkFgqDgnnWZ%2BA%3D&reserved=0
>> >>>>>>>>>>
>> >>>>>>>>>> (Wireframe intention is for quick Royale App prototyping,
>>people
>> >>>>>>> will
>> >>>>>>>>> use
>> >>>>>>>>>> this to start their applications, and then moving to it's own
>> >>>>>>> styling
>> >>>>>>>>> that
>> >>>>>>>>>> could be another royale theme provided by us, or something
>>done
>> >>>>>>>>>>by
>> >>>>>>>>> users.
>> >>>>>>>>>>
>> >>>>>>>>>> Vivid (to put some temporal name):
>> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fsnag.gy%2
>> >>>>>>>>>> FqKShm0.jpg&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa7b1b5a7
>> >>>>>>>>>> b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=kxYE7ylOsXPUEeE
>> >>>>>>>>>> r%2BU3AnSe9zEyqgqmsIAAYW6nVuGs%3D&reserved=0
>> >>>>>>>>>>
>> >>>>>>>>>> (*Please, Notice that only the first button has some styling
>> >>>>>>>>>>here*)
>> >>>>>>>>>> (This theme could be the default theme for royale components
>> >>>>>>>>>>like
>> >>>>>>> halo
>> >>>>>>>>> was
>> >>>>>>>>>> for mx and spark was for spark)
>> >>>>>>>>>>
>> >>>>>>>>>> I want to put in place all the main components, so I would
>>need
>> >>> some
>> >>>>>>>>>> "component list" (Button, TextInput, CheckBox,...and what
>> >>>>>>>>>>more?.),
>> >>>>>>> and
>> >>>>>>>>>> we'll be centering all the effort in only that list of
>> >>>>>>>>>>components.
>> >>>>>>>>>> We need to "paint" all and the code all.
>> >>>>>>>>>>
>> >>>>>>>>>> The concept of theme involve a concrete set of components
>>(and
>> >>>>>>>>>>this
>> >>>>>>>>> bring
>> >>>>>>>>>> us again if we should do this to be pluggable for Basic, or
>>go
>> >>>>>>> directly
>> >>>>>>>>>> with Express, I think even Basic should be able to use a
>>theme
>> >>> maybe
>> >>>>>>>>> using
>> >>>>>>>>>> beads to be PAYG)
>> >>>>>>>>>>
>> >>>>>>>>>> So, before continue tomorrow, I want some feedback on this:
>> >>>>>>>>>>
>> >>>>>>>>>> * I think Wireframe is clearly something Black&White, maybe
>>as I
>> >>>>>>> did,
>> >>>>>>>>> in
>> >>>>>>>>>> some grey scale colors. But for Vivid, I'm still figuring if
>>it
>> >>>>>>> should
>> >>>>>>>>> be
>> >>>>>>>>>> something "flat" and very simple, or go with something more
>> >>>>>>> elaborated
>> >>>>>>>>>> since the thing I did in the example with orange button.
>> >>>>>>>>>>
>> >>>>>>>>>> * I like the look and feel of Google Material, how textfields
>> >>>>>>>>>>looks
>> >>>>>>> and
>> >>>>>>>>>> behaves, the animations, and visual concepts. But the
>>problem is
>> >>>>>>> that
>> >>>>>>>>> all
>> >>>>>>>>>> that visuals are clearly Google Material. Should we create
>> >>> something
>> >>>>>>>>> more
>> >>>>>>>>>> new? This has a problem that maybe we could reach something
>> >>>>>>> great....or
>> >>>>>>>>>> not, and is more work to iterate something until we reach a
>>good
>> >>>>>>> point.
>> >>>>>>>>>> For example, the text input I created has the classic box
>>look,
>> >>>>>>>>>>for
>> >>>>>>> me
>> >>>>>>>>>> Material Design is better with only a bootom line, but the
>> >>>>>>>>>>first is
>> >>>>>>>>> more
>> >>>>>>>>>> generalist, while the second is clearly google, android,... I
>> >>>>>>>>>>could
>> >>>>>>>>> try to
>> >>>>>>>>>> think in something new a see what happens
>> >>>>>>>>>>
>> >>>>>>>>>> * In the other hand, someone would want to join me in this
>> >>>>>>>>>>effort?
>> >>>>>>> If
>> >>>>>>>>> so I
>> >>>>>>>>>> could center in the design part, and other person could work
>> >>>>>>>>>>with
>> >>>>>>> me on
>> >>>>>>>>>> the
>> >>>>>>>>>> example project "RoyaleThemes". The example app is very
>> >>>>>>>>>>important,
>> >>>>>>>>> since
>> >>>>>>>>>> it
>> >>>>>>>>>> could have a playground for every component so we can tweak
>>at
>> >>>>>>>>> runtime. we
>> >>>>>>>>>> could even generate the code to get that look...this could be
>> >>>>>>>>>>like
>> >>>>>>>>>> FlexThemeManager App that we had in the Flex days.
>> >>>>>>>>>>
>> >>>>>>>>>> * About colors for the second again, don't have any
>>preferences
>> >>>>>>> right
>> >>>>>>>>> now,
>> >>>>>>>>>> I put the same colors that use on the web in the first
>>button,
>> >>>>>>>>>>but
>> >>>>>>> as I
>> >>>>>>>>>> said before things (colors and forms) could change
>>dramatically
>> >>>>>>>>>>in
>> >>>>>>> the
>> >>>>>>>>>> second set. In the first one (Wireframe) I think it's ok to
>>go
>> >>>>>>>>>>the
>> >>>>>>> path
>> >>>>>>>>>> exposed in the image example.
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks for your comments on this, we'll be defining what we
>> >>>>>>>>>>want as
>> >>>>>>> we
>> >>>>>>>>>> comment here ok?
>> >>>>>>>>>> I'm done for today,
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> 2017-11-02 14:22 GMT+01:00 Carlos Rovira
>> >>>>>>>>>><carlosrov...@apache.org
>> >>>> :
>> >>>>>>>>>>
>> >>>>>>>>>>> Thanks Harbs!
>> >>>>>>>>>>>
>> >>>>>>>>>>> very useful, I'll be keeping this info as I make some work
>> >>>>>>>>>>>
>> >>>>>>>>>>> Carlos
>> >>>>>>>>>>>
>> >>>>>>>>>>> 2017-11-02 12:13 GMT+01:00 Harbs <harbs.li...@gmail.com>:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> BTW, the kind of thing we should be striving for in
>>theme-able
>> >>>>>>>>>>>> components
>> >>>>>>>>>>>> is something like this:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fvcalend
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>ar.netlify.com%2F&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d5225
>> >>>>>>>>>>>>0
>> >>>>>>>>> 0f48%7Cf
>> >>>>>>>>>
>> >>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >>> 7C636452649612378558&sdata=
>> >>>>>>>>> b3VtV
>> >>>>>>>>>>>> VdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0
>> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fvcalen
>> >>>>>>>>>>>> dar.netlify.com%2F&data=02%7C01%7C%
>> >>> 7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7C
>> >>>>>>>>>
>> >>>>>>>>>> fa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >>> 7C636452649612378558&sdata=
>> >>>>>>>>> b3Vt
>> >>>>>>>>>>>> VVdACL0Z2EVnIFo2%2BgqSFmJMocDL6k%2Ba6A1ewco%3D&reserved=0>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> On Nov 2, 2017, at 12:01 PM, Harbs <harbs.li...@gmail.com>
>> >>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> FYI, I worked out a theming class for my (Royale) InDesign
>> >>>>>>>>> extensions
>> >>>>>>>>>>>> which allows for setting global CSS at runtime. The
>>approach
>> >>>>>>> might
>> >>>>>>>>> be
>> >>>>>>>>>>>> useful in your theming effort:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> https%3A%2F%2Fpaste.a
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>pache.org%2FcOBC&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa
>> >>>>>>>>>>>>
>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=bRWKxm
>> >>>>>>>>>>>> LL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0
>> >>>>>>>>>
>> >>>>>>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>> https%3A%2F%2Fpast
>> >>>>>>>>>>>> e
>> >>>>>>>>> .
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>apache.org%2FcOBC&data=02%7C01%7C%
>> 7C203485b5b9c744aed92608d5225
>> >>>>>>>>>>>>0
>> >>>>>>>>> 0f48%7Cf
>> >>>>>>>>>
>> >>>>>>>>>> a7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >>> 7C636452649612378558&sdata=
>> >>>>>>>>> bRWKx
>> >>>>>>>>>>>> mLL16u%2B48IXYdA%2FoEtLWF3eU%2FIGQzBfcVCar5g%3D&reserved=0>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> (Some of the code is specific to Adobe Extensions.)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Some pointers:
>> >>>>>>>>>>>>> I used inject_html because I needed some overrides in a
>>CSS
>> >>>>>>> file.
>> >>>>>>>>> I
>> >>>>>>>>>>>> might have been able to rework it so the CSS file was not
>> >>>>>>>>>>>>needed.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> There is a function called createStyleSheet which is
>> >>>>>>>>>>>>>commented
>> >>>>>>>>> out.
>> >>>>>>>>>>>> That creates a stylesheet called “royale_theme_styles”.
>>It’s
>> >>>>>>>>>>>>the
>> >>>>>>>>> same
>> >>>>>>>>>>>> as
>> >>>>>>>>>>>> including a blank css file with the same name, but it’s
>>loaded
>> >>>>>>>>>>>> dynamically
>> >>>>>>>>>>>> rather than requiring the file to be included. If that
>> >>>>>>>>>>>>function
>> >>>>>>> is
>> >>>>>>>>> used
>> >>>>>>>>>>>> inject_html is not necessary.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> The order of dynamically loaded CSS has the same rules as
>>CSS
>> >>>>>>>>> loaded
>> >>>>>>>>>>>> via declaring it in HTML and the later ones override the
>> >>>>>>>>>>>>earlier
>> >>>>>>>>> ones.
>> >>>>>>>>>>>> We
>> >>>>>>>>>>>> can probably take advantage of that for different levels of
>> >>>>>>>>> defaults.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> HTH,
>> >>>>>>>>>>>>> Harbs
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Nov 1, 2017, at 8:05 PM, Carlos Rovira
>> >>>>>>>>> <carlosrov...@apache.org
>> >>>>>>>>>>>> <mailto:carlosrov...@apache.org>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> I think I could start to try what Harbs expose, although
>>I
>> >>>>>>> think
>> >>>>>>>>>>>> what I
>> >>>>>>>>>>>>>> will need in the end is to control some SVG parts with
>> >>>>>>> variables.
>> >>>>>>>>>>>> Maybe
>> >>>>>>>>>>>>>> with the showed SVG/CSS relation could be sufficient.
>>I'll
>> >>>>>>>>>>>>>>be
>> >>>>>>>>>>>> showing
>> >>>>>>>>>>>> how
>> >>>>>>>>>>>>>> limitations I find. As well as Alex said having inline
>>SVG
>> >>>>>>>>>>>>>>as
>> >>>>>>>>> HTML
>> >>>>>>>>>>>> would be
>> >>>>>>>>>>>>>> very useful.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> 2017-11-01 18:27 GMT+01:00 Harbs <harbs.li...@gmail.com
>> >>>>>>> <mailto:
>> >>>>>>>>>>>> harbs.li...@gmail.com>>:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I’m not sure. I haven’t seen problems.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> The only issues that come to mind are:
>> >>>>>>>>>>>>>>> 1. There’s no load events on SVG images on Microsoft
>> >>>>>>> browsers.
>> >>>>>>>>>>>>>>> 2. Chrome has issues with SVG, transforms and fractional
>> >>>>>>> pixels.
>> >>>>>>>>>>>>>>> 3. There’s some blending issues that different browsers
>> >>>>>>> handle
>> >>>>>>>>>>>> differently
>> >>>>>>>>>>>>>>> depending on isolation modes.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> There’s likely other issues, but these are ones that
>>I’ve
>> >>>>>>> had to
>> >>>>>>>>>>>> deal
>> >>>>>>>>>>>> with.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> The major gotcha in terms of mixing HTML and SVG is that
>> >>>>>>>>>>>>>>>HTML
>> >>>>>>>>> can
>> >>>>>>>>>>>> not
>> >>>>>>>>>>>> be
>> >>>>>>>>>>>>>>> nested inside SVG without ForeignObject. ForeignObject
>>does
>> >>>>>>> not
>> >>>>>>>>>>>> have
>> >>>>>>>>>>>> full
>> >>>>>>>>>>>>>>> browser support.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Nov 1, 2017, at 7:08 PM, Alex Harui
>> >>>>>>>>> <aha...@adobe.com.INVALID
>> >>>>>>>>>>>> <mailto:aha...@adobe.com.INVALID>> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> A couple of years ago, I thought I had learned that
>>some
>> >>>>>>>>> browsers
>> >>>>>>>>>>>> had
>> >>>>>>>>>>>>>>>> issues with SVG background-images. Maybe psuedo-states
>> >>>>>>>>>>>>>>>>were
>> >>>>>>>>>>>> involved,
>> >>>>>>>>>>>>>>> but
>> >>>>>>>>>>>>>>>> a Button might "blink" as it changed states and loaded
>>an
>> >>>>>>> SVG
>> >>>>>>>>>>>>>>>> background-image. Do we know if that was just a bug in
>> >>>>>>>>>>>>>>>>some
>> >>>>>>>>>>>> browser
>> >>>>>>>>>>>> or
>> >>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>> that still a concern?
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> I think I would like to see a simple set of
>> >>>>>>>>>>>>>>>>HTML/SVG/CSS/JS
>> >>>>>>>>> that
>> >>>>>>>>>>>> shows
>> >>>>>>>>>>>>>>> how
>> >>>>>>>>>>>>>>>> any declarative SVG and JS have to work together to
>>handle
>> >>>>>>>>>>>> resizable
>> >>>>>>>>>>>>>>>> skins/components. Then it might be more obvious what
>> >>>>>>>>>>>>>>>>needs
>> >>>>>>> to
>> >>>>>>>>>>>> change in
>> >>>>>>>>>>>>>>>> the tooling. We allow inline HTML now in MXML. I
>>think
>> >>>>>>>>>>>>>>>>we
>> >>>>>>>>>>>> can/should
>> >>>>>>>>>>>>>>>> allow inline SVG, but for both inline HTML and SVG,
>>id's
>> >>>>>>>>>>>>>>>>in
>> >>>>>>> the
>> >>>>>>>>>>>> inline
>> >>>>>>>>>>>>>>>> content do not become id's to MXML and AS.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> HTH,
>> >>>>>>>>>>>>>>>> -Alex
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> --
>> >>>>>>>>>>> Carlos Rovira
>> >>>>>>>>>>>
>> >>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> http%3A%2F%2Fabout.me%
>> >>>>>>>>>>>
>>2Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa7b1
>> >>>>>>>>>>> b5a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=C7a72gwfH2
>> >>>>>>>>>>> 64wTla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Carlos Rovira
>> >>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>>>> http%3A%2F%2Fabout.me%2
>> >>>>>>>>>> Fcarlosrovira&data=02%7C01%7C%7C203485b5b9c744aed92608d52250
>> >>>>>>>>> 0f48%7Cfa7b1b5
>> >>>>>>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636452649612378558&
>> >>>>>>>>> sdata=C7a72gwfH264w
>> >>>>>>>>>> Tla%2Fl%2FT9fLB5ODZWiSnRqIzGfFCREU%3D&reserved=0
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>>
>> >>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>> http%3A%2F%2Fwww.codeo
>> >>>>>>>> scopic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>> >>>>>>> d8cf%7Cfa7b1b5a7b
>> >>>>>>>> 34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> >>>>>>> sdata=Hm%2B6WIcqQTOHs0
>> >>>>>>>> UppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0>
>> >>>>>>>>
>> >>>>>>>> Carlos Rovira
>> >>>>>>>>
>> >>>>>>>> Director General
>> >>>>>>>>
>> >>>>>>>> M: +34 607 22 60 05
>> >>>>>>>>
>> >>>>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>> http%3A%2F%2Fwww.codeos
>> >>>>>>>> copic.com&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>> >>>>>>> d8cf%7Cfa7b1b5a7b3
>> >>>>>>>> 4438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> >>>>>>> sdata=Hm%2B6WIcqQTOHs0U
>> >>>>>>>> ppUdckW%2FhhyzErprotQUOZNtUtXU%3D&reserved=0
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Conocenos Avant2 en 1 minuto!
>> >>>>>>>> <https://na01.safelinks.protection.outlook.com/?url=
>> >>>>>>> https%3A%2F%2Favant2.e
>> >>>>>>>> s%2F%23video&data=02%7C01%7C%7C6422929d95d1406eaa1c08d52295
>> >>>>>>> d8cf%7Cfa7b1b5a
>> >>>>>>>> 7b34438794aed2c178decee1%7C0%7C0%7C636452949347201523&
>> >>>>>>> sdata=b%2FFMr1Ajit94
>> >>>>>>>> TOU%2BjWNuqeN%2FKAiwo7%2BpEVTx8mWLCSc%3D&reserved=0>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Este mensaje se dirige exclusivamente a su destinatario y puede
>> >>>>>>> contener
>> >>>>>>>> información privilegiada o confidencial. Si ha recibido este
>> >>>>>>>>mensaje
>> >>>>>>> por
>> >>>>>>>> error, le rogamos que nos lo comunique inmediatamente por esta
>> >>>>>>>>misma
>> >>>>>>> vía y
>> >>>>>>>> proceda a su destrucción.
>> >>>>>>>>
>> >>>>>>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>> >>>>>>>> comunicamos
>> >>>>>>>> que sus datos forman parte de un fichero cuyo responsable es
>> >>>>>>> CODEOSCOPIC
>> >>>>>>>> S.A. La finalidad de dicho tratamiento es facilitar la
>>prestación
>> >>>>>>>>del
>> >>>>>>>> servicio o información solicitados, teniendo usted derecho de
>> >>>>>>>>acceso,
>> >>>>>>>> rectificación, cancelación y oposición de sus datos
>>dirigiéndose a
>> >>>>>>>> nuestras
>> >>>>>>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
>> >>> documentación
>> >>>>>>>> necesaria.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Carlos Rovira
>> >>>>>> https://na01.safelinks.protection.outlook.com/?url=
>> >>>>> http%3A%2F%2Fabout.me%2
>> >>>>>> Fcarlosrovira&data=02%7C01%7C%7Cbb03216ec0b84fcb6ab108d52397
>> >>>>> 82e0%7Cfa7b1b5
>> >>>>>> a7b34438794aed2c178decee1%7C0%7C0%7C636454056000808812&
>> >>>>> sdata=wYPMWW1wpTbtm
>> >>>>>> pTt%2F%2FmFuHwgl5nHByLpMuG0lUVba9w%3D&reserved=0
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>
>> >>>>
>> >>>><https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fwww.co
>> >>>>deoscopic.com&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 5950%7Cfa7b
>> >>>>1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
>> sdata=Cszs7Ln
>> >>>>LaXf9z%2F9Dv7l%2Ba%2BxZJM%2FxOMqs8FFbzO061Cc%3D&reserved=0>
>> >>>>
>> >>>> Carlos Rovira
>> >>>>
>> >>>> Director General
>> >>>>
>> >>>> M: +34 607 22 60 05
>> >>>>
>> >>>>
>> >>>>https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fwww.cod
>> >>>>eoscopic.com&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 5950%7Cfa7b1
>> >>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
>> sdata=Cszs7LnL
>> >>>>aXf9z%2F9Dv7l%2Ba%2BxZJM%2FxOMqs8FFbzO061Cc%3D&reserved=0
>> >>>>
>> >>>>
>> >>>> Conocenos Avant2 en 1 minuto!
>> >>>><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Favant
>> >>>>2.es%2F%23video&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 5950%7Cfa
>> >>>>7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455141932227764&
>> sdata=iMuUY
>> >>>>4Y%2FdwWAKXOXR%2BlHO9WIWPnOjdlrTCBjC0t2QUQ%3D&reserved=0>
>> >>>>
>> >>>>
>> >>>> Este mensaje se dirige exclusivamente a su destinatario y puede
>> >>>>contener
>> >>>> información privilegiada o confidencial. Si ha recibido este
>>mensaje
>> >>>>por
>> >>>> error, le rogamos que nos lo comunique inmediatamente por esta
>>misma
>> >>>>vía
>> >>> y
>> >>>> proceda a su destrucción.
>> >>>>
>> >>>> De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>> >>> comunicamos
>> >>>> que sus datos forman parte de un fichero cuyo responsable es
>> >>>>CODEOSCOPIC
>> >>>> S.A. La finalidad de dicho tratamiento es facilitar la prestación
>>del
>> >>>> servicio o información solicitados, teniendo usted derecho de
>>acceso,
>> >>>> rectificación, cancelación y oposición de sus datos dirigiéndose a
>> >>> nuestras
>> >>>> oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la
>> >>>>documentación
>> >>>> necesaria.
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> Piotr Zarzycki
>> >>
>> >> Patreon:
>> >>*https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>>
>>>>reon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 59
>> >>50%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636455141932227764&sdata=
>> >>3KxMJ3IlEbtNDN7WtgzdqILz8LlPRtjjL%2FP61nzmgrM%3D&reserved=0
>> >>
>> >><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>>
>>>>reon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cdfc2dc02415b446e995108d52494
>> 59
>> >>50%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636455141932227764&sdata=
>> >>3KxMJ3IlEbtNDN7WtgzdqILz8LlPRtjjL%2FP61nzmgrM%3D&reserved=0>*
>> >
>>
>>
>
>
>--
>
>Piotr Zarzycki
>
>Patreon:
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cb4af937efcb74c87b31108d524dfe682
>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455466425743017&sdata=Idk
>aCqJCK%2FuapcPqmgJOsWzOqhfIL3rjQOh%2F3NMIV9k%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7C%7Cb4af937efcb74c87b31108d524dfe682
>%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636455466425743017&sdata=Idk
>aCqJCK%2FuapcPqmgJOsWzOqhfIL3rjQOh%2F3NMIV9k%3D&reserved=0>*
