On 3/13/18, 3:16 PM, "[email protected] on behalf of Carlos Rovira" <[email protected] on behalf of [email protected]> wrote:
>Hi Alex, > >2018-03-13 19:20 GMT+01:00 Alex Harui <[email protected]>: > >> Hi Carlos, >> >> I took a quick look. >> >> 1) I don't see how if the user did: >> >> myComp.className = "Carlos"; >> myComp.className = ""; >> >> >Right this case is missing, we need to add it, but seems simple since is >deal with value == "" Carlos, that was a simple example. What about: myComp.className = "Carlos Piotr Alex"; myComp.className = "Carlos Alex"; The "Piotr" class would need to be removed. > > >> That 'Carlos' would be removed from the classList. >> >> 2) I still don't like that we are calling split and apply on classList >> even for simple assignment of a single className >> >> 3) I don't like that as we aggregate typeNames that we will reset >> className to "" and call split more than once. Not to mention the >> overhead of the extra function calls now that typeNames is not a var and >> now a getter/setter. >> > >ok > >> >> >> That said, I also took another look at the Basic UIBase code and don't >> like it either. Seems like it could be optimized as well and have >> setClassName call computeFinalClassNames. >> >> Regarding performance. I think the key issue is that every change to >> element.className or element.classList can cause a DOM update, so you >> don't want to change element.className or element.classList more than >>once >> during the initialization of the component. I didn't watch the videos >>you >> linked to, but in the first link to a blog post, that person was just >> replacing a one-time setting of className to a string with a call to >> classList.add. But his code is probably pre-parsed into the parameter >> list to classList.add. We have to compute it from a String.split. And >> the current code you have proposed is going to change classList several >> times as we aggregate typeNames. That doesn't seem right. >> > >I think the video is short and explained very well. I think is good to >review it > >But I think is ok to change my code to get a better performant one. Mine >was created only to see >it works, now we need to tune depending on the different entry points as >you say > > >> If you want to use classList everywhere, I think we'd have to shadow it >> with an array so we only set the array of strings on classList as >>needed, >> but classList isn't set up to do a full replacement, AFAICT. >> >> IMO, if you want to continue to pursue use of classList, you would focus >> on just replacing computeFinalClassNames and/or setClassName with >> classList handling and see how it looks. Leave typeNames as a var and >>let >> it aggregate without touching classList. UIBase will eventually call >> setClassName in addedToParent. That is the point in the lifecycle where >> the user might have set some classNames and the typeNames have been >> aggregated and maybe "fab" or "primary" has been set as well. Either >>you >> track everything in a shadow array or you do one big split then. >> >> Do we know if you set className then read classList, doesn't classList >> represent the things set in className? If that's the case, then in >> MDL/Jewel, "fab" and "primary" should just check to see if addedToParent >> has been called and the classNames/classList has been stuffed and if it >> has, just call classList.toggle. >> >> However, IMO, the simplest solution should be to leave UIBase as is. >>MDL >> and Jewel should just have to override computeFinalClassNames to include >> adding "fab"/"primary" to the final set of strings. I don't understand >> why other work would be needed. But the "fab"/"primary" getter setters >> should be able to call classList.toggle instead of >>computeFinalClassNames >> and/or setClassName. >> >> If you want to separately prove that it is faster to call String.split() >> and set classList instead of passing the space-delimited strings to >> className, that's fine too. The difference for us vs the link you >>posted >> is that we MUST start with space-delimited strings coming from the MXML, >> so at least one split() call is required. >> > >I spend some hours trying and >* change typeNames to only one var again, then in addToParent I reset the >className, I think this solves the problem of using typeNames lots of >times >and call split and apply lots of times >* I tried to create again a computedFinalClassNames to handle classList. >* The only problem I see is that if don't see any way to avoid call split >and apply each time you call setClassName since a compute final is needed. >Or I'm missing something? Not sure. I was wondering if you could track which elements in the array belong to typeNames so that portion doesn't need to be re-split. I really don't know. Like maybe when typeNames is first split, remember the number of elements in the split. HTH, -Alex > >Maybe could be good that you write some code (pseudo code) here better to >explain what you propose >since I don't know if I'm understanding your phrases accurately > >It's time for me to go to sleep, tomorrow I'll check if you posted >something to try it > >thanks! > > >> >> Of course, I could be missing something... >> -Alex >> >> On 3/13/18, 10:30 AM, "[email protected] on behalf of Carlos >>Rovira" >> <[email protected] on behalf of [email protected]> wrote: >> >> >Hi Alex, >> > >> >right, I tested it in JewelExample. If you find something that does not >> >conform to what you thinked please let me know to address it. >> >I think it should not be very difficult to handle some isolated case >>with >> >what we have >> > >> >thanks >> > >> > >> > >> >2018-03-13 18:24 GMT+01:00 Alex Harui <[email protected]>: >> > >> >> Hi Carlos, >> >> >> >> Just so I'm clear, you believe that UIBase.as in the jewel-ui-set >>branch >> >> addresses all of these issues? I've just been watching commits, so >>if >> >>you >> >> think that's the case then I will look at the current state of your >> >>UIBase. >> >> >> >> Thanks, >> >> -Alex >> >> >> >> On 3/13/18, 10:14 AM, "[email protected] on behalf of Carlos >> >>Rovira" >> >> <[email protected] on behalf of [email protected]> wrote: >> >> >> >> >Hi Alex, >> >> > >> >> >2018-03-13 17:50 GMT+01:00 Alex Harui <[email protected]>: >> >> > >> >> >> Hi Carlos, >> >> >> >> >> >> I do not think you are considering all of the scenarios in your >> >>proposed >> >> >> code. I'm sad that I have to delineate them again, but I will >>try. >> >> >> >> >> >> 1) In Basic there are two sets of strings: The fixed set from >> >>typeNames >> >> >> that should "never" change. And the className set from the user >>that >> >> >>can >> >> >> not only add, but also remove a set of HTML classes. >> >> >> >> >> >> >> >> >I see the next email so I respond to this in the following, I solved >> >>that >> >> >and explain later >> >> > >> >> > >> >> >> 2) In MDL and I guess Jewel, there is a third set. They are tied >>to >> >> >> properties like you said. "fab" and "primary", and things like >>that. >> >> >> >> >> > >> >> >Yes this will be the normal case in users. People using Jewel or >>other >> >>UI >> >> >set with look and feel will >> >> >use properties as their normal basis in the same way they do now in >>MDL >> >> > >> >> > >> >> >> >> >> >> 3) For PAYG reasons, it would be great if Basic did not have to >> >> >> contemplate the third set. >> >> >> >> >> >> 4) For PAYG reasons, it would be nice if Basic did not have to >>assume >> >> >> conversion to array and call split(). The current code in the >> >>develop >> >> >> branch lets the browser do the split() in native code. >> >> >> >> >> > >> >> >for 3 and 4 what's the best way to left UIBase untouched so I can >>use >> >>my >> >> >code in Jewel? >> >> >Is the actual way of duplicating the code for UIBase in my own >>library >> >>the >> >> >best way? >> >> > >> >> > >> >> >> >> >> >> Then, as a performance consideration, Harbs claims that changing >> >> >>classList >> >> >> is expensive. >> >> >> >> >> > >> >> >I don't will say that there's a low performance, but my guess is >>that >> >>is >> >> >nothing that we should have in consideration, but we can discuss it >> >>later. >> >> > >> >> > >> >> >> >> >> >> So, your proposed solution MUST allow the user to delete/remove >>any >> >> >> strings they added without removing strings added from typeNames >>or >> >>from >> >> >> the "fab"/"primary" properties. >> >> > >> >> > >> >> >That's now working >> >> > >> >> > >> >> >> And allow add/remove of the user's >> >> >> strings before or after changing properties like "fab" and >>"primary". >> >> >> >> >> > >> >> >as we are dealing with a collection this is working and only one >>copy >> >>of >> >> >the string is maintained and outputted, I think in this way >> >> >less errors of this kind should happen >> >> > >> >> > >> >> >> >> >> >> Show us how that will work. I'm pretty sure it is possible. >>Then we >> >> >>will >> >> >> debate the performance aspects. >> >> >> >> >> > >> >> >I have it right now completely working in my branch, so it's a >>matter >> >>to >> >> >try it in JewelExample >> >> > >> >> > >> >> >> >> >> >> Thanks, >> >> >> -Alex >> >> >> >> >> >> On 3/13/18, 6:49 AM, "[email protected] on behalf of Carlos >> >> >>Rovira" >> >> >> <[email protected] on behalf of [email protected]> >> wrote: >> >> >> >> >> >> >So, you if is == you expect that setting className in royale you >> >>remove >> >> >> >all >> >> >> >inclusive typeNames? >> >> >> >Harbs, className is not equal to class in HTML >> >> >> > >> >> >> >2018-03-13 14:08 GMT+01:00 Harbs <[email protected]>: >> >> >> > >> >> >> >> className in Royale == class in HTML. >> >> >> >> >> >> >> >> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira >> >> >><[email protected]> >> >> >> >> wrote: >> >> >> >> > >> >> >> >> > I think we're getting to the point in this discussion. >> >> >> >> > >> >> >> >> > For me as a user, I expect to use className property to >>"add", >> >>and >> >> >>not >> >> >> >> > override all I have >> >> >> >> > for that reason in MDL and now in Royale we decided to create >> >> >> >>properties >> >> >> >> > (that use to be boolean) like "primary" or in MDL "fab" to >>add >> >>or >> >> >> >>remove >> >> >> >> > those properties (since are library properties that are >>managed >> >> >> >> > specifically). >> >> >> >> > I don't want to set primary and then className removes that! >>I >> >> >>think >> >> >> >>that >> >> >> >> > function is not right and will be the cause of many problems. >> >> >> >> > >> >> >> >> > If the user wants to remove all class names, he can do with a >> >> >>method >> >> >> >>that >> >> >> >> > callls element.classList.remove, but the behavior by default >> >> >> >>shouldn't be >> >> >> >> > to use className to get rid of all what we have. >> >> >> >> > >> >> >> >> > If you work with html directly , is normal to write >> >>class="class1 >> >> >> >>class2 >> >> >> >> > ..." and create from scratch >> >> >> >> > >> >> >> >> > in Royale you write mxml and as3 and use className to add >> >> >>additional >> >> >> >> > classes that are not in the api but not to remove the ones >>the >> >> >> >>component >> >> >> >> > set plus the ones the user "switched" on/off due to >>properties >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > 2018-03-13 13:42 GMT+01:00 Harbs <[email protected]>: >> >> >> >> > >> >> >> >> >> No. className is supposed to *replace* the entire classList >> >>minus >> >> >>the >> >> >> >> >> internally managed ones (i.e. typeNames). Your code >>drastically >> >> >> >>changes >> >> >> >> the >> >> >> >> >> current behavior. >> >> >> >> >> >> >> >> >> >> You cannot use add for that and replacing the classList will >> >> >>destroy >> >> >> >> your >> >> >> >> >> custom class names. >> >> >> >> >> >> >> >> >> >>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira >> >> >><[email protected] >> >> >> > >> >> >> >> >> wrote: >> >> >> >> >>> >> >> >> >> >>> Solving the multiple string value problem: >> >> >> >> >>> >> >> >> >> >>> This: <j:TextButton text="PRIMARY" className="myCustomStyle >> >>some >> >> >> >>other" >> >> >> >> >>> primary="true"/> >> >> >> >> >>> >> >> >> >> >>> *<button type="button" class="jewel button textbutton >> >> >>myCustomStyle >> >> >> >> some >> >> >> >> >>> other primary" style="margin: 10px 0px 0px; display: >> >> >> >> >>> block;">PRIMARY</button>* >> >> >> >> >>> >> >> >> >> >>> with this change >> >> >> >> >>> >> >> >> >> >>> COMPILE::JS >> >> >> >> >>> protected function setClassName(value:String):void >> >> >> >> >>> { >> >> >> >> >>> var classes:Array = value.split(" "); >> >> >> >> >>> element.classList.add.apply(element.classList, classes); >> >> >> >> >>> } >> >> >> >> >>> >> >> >> >> >>> I think this was all the problems we have right? >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> 2018-03-13 13:20 GMT+01:00 Carlos Rovira >> >> >><[email protected]>: >> >> >> >> >>> >> >> >> >> >>>> Hi Piotr, >> >> >> >> >>>> >> >> >> >> >>>> that's one of the advantages of a collection, order >>doesn't >> >> >> >>matter! :) >> >> >> >> >>>> >> >> >> >> >>>> <j:TextButton text="PRIMARY" className="myCustomStyle" >> >> >> >> primary="true"/> >> >> >> >> >>>> >> >> >> >> >>>> output: >> >> >> >> >>>> >> >> >> >> >>>> *<button type="button" class="jewel button textbutton >> >> >>myCustomStyle >> >> >> >> >>>> primary" style="margin: 10px 0px 0px; display: >> >> >> >> block;">PRIMARY</button>* >> >> >> >> >>>> >> >> >> >> >>>> this is one of the reason to change, since you'll end >>trying >> >>to >> >> >> >>figure >> >> >> >> >>>> what comes in first or not. >> >> >> >> >>>> >> >> >> >> >>>> Do you need more evidence? >> >> >> >> >>>> >> >> >> >> >>>> Thanks >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki >> >> >> >><[email protected] >> >> >> >> >: >> >> >> >> >>>> >> >> >> >> >>>>> In my example orders matters. Setup first className than >> >>your >> >> >> >> property. >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> On Tue, Mar 13, 2018, 12:39 Harbs <[email protected]> >> >> >>wrote: >> >> >> >> >>>>> >> >> >> >> >>>>>> Hi Carlos, >> >> >> >> >>>>>> >> >> >> >> >>>>>> I definitely appreciate the work you are doing. I’m >>swamped >> >> >>with >> >> >> >> work >> >> >> >> >>>>>> right now, so I don’t have the time to spend helping >>you. >> >> >>(Sorry >> >> >> >> about >> >> >> >> >>>>>> that.) :-( >> >> >> >> >>>>>> >> >> >> >> >>>>>> I think the discussions here are about pretty minor >>points. >> >> >>You >> >> >> >>can >> >> >> >> >>>>>> certainly implement jewel how you think makes sense, >>but if >> >> >>you >> >> >> >>want >> >> >> >> >> to >> >> >> >> >>>>>> make changes to basic in areas which are not broken, >>there >> >> >>needs >> >> >> >>to >> >> >> >> >> be a >> >> >> >> >>>>>> really good reason to do so. >> >> >> >> >>>>>> >> >> >> >> >>>>>> My $0.02, >> >> >> >> >>>>>> Harbs >> >> >> >> >>>>>>> On Mar 13, 2018, at 1:31 PM, Carlos Rovira < >> >> >> >> [email protected]> >> >> >> >> >>>>>> wrote: >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> Hi Piotr, >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> thanks for your words, but is difficult to work on >> >>something >> >> >> >>when >> >> >> >> you >> >> >> >> >>>>>>> believe in your vision and others no, and more over >>when >> >>all >> >> >>the >> >> >> >> >> facts >> >> >> >> >>>>>> you >> >> >> >> >>>>>>> see corroborates that vision. It's difficult to >>maintain >> >>live >> >> >> >>the >> >> >> >> >>>>> moto in >> >> >> >> >>>>>>> that scenario. >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> but anyway for you Kindly words >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> Carlos >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki < >> >> >> >> [email protected] >> >> >> >> >>>>>> : >> >> >> >> >>>>>>> >> >> >> >> >>>>>>>> Carlos, >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> In my opinion you are not facing the wall from US. You >> >>are >> >> >> >>facing >> >> >> >> >> the >> >> >> >> >>>>>> wall >> >> >> >> >>>>>>>> from lack of volounteers who can help, do the job. >> >> >> >> >>>>>>>> Believe me your Jewel effort in my list of tasks is >> >>almost >> >> >>on >> >> >> >>the >> >> >> >> >>>>> Top. I >> >> >> >> >>>>>>>> have to fiinish planned work in TranspiledActionScript >> >>first >> >> >> >>and I >> >> >> >> >>>>> hope >> >> >> >> >>>>>> to >> >> >> >> >>>>>>>> join. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> When it will be - maybe in couple of weeks. In the end >> >> >> >>something >> >> >> >> >>>>> have to >> >> >> >> >>>>>>>> pay the bills and Royale is only fraction of that. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> I contribute in other related areas. I Wish I could >> >> >>contribute >> >> >> >>in >> >> >> >> >>>>> your >> >> >> >> >>>>>> way >> >> >> >> >>>>>>>> or Alex and Peter. >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> Thanks for your work! >> >> >> >> >>>>>>>> Piotr >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki < >> >> >> >> >>>>> [email protected]> >> >> >> >> >>>>>>>> wrote: >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>>> I personally said - Go and try, report back. I have >>gave >> >> >>you >> >> >> >>an >> >> >> >> >> real >> >> >> >> >>>>>>>> world >> >> >> >> >>>>>>>>> examples where classList failed. Try and post the >> >>results. >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira < >> >> >> >> [email protected] >> >> >> >> >>> : >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>>> Hi, >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> it's very hard to me to invest lot of time both in >> >>tryin >> >> >>to >> >> >> >> >> develop >> >> >> >> >>>>>>>>>> something useful in the look and feel field for us >> >>where >> >> >>no >> >> >> >> other >> >> >> >> >>>>> is >> >> >> >> >>>>>>>> doing >> >> >> >> >>>>>>>>>> work, trying to explain and discuss all issues I >>find >> >> >>without >> >> >> >> get >> >> >> >> >>>>> any >> >> >> >> >>>>>>>>>> traction. It's like to face a wall all the time. >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> Maybe I'm wrong with my proposals but other times my >> >> >> >>perception >> >> >> >> is >> >> >> >> >>>>>> that >> >> >> >> >>>>>>>>>> things are settled in a particular way >> >> >> >> >>>>>>>>>> and we don't want to change it since is working in >>the >> >> >> >>current >> >> >> >> >>>>> state. >> >> >> >> >>>>>>>> But >> >> >> >> >>>>>>>>>> I >> >> >> >> >>>>>>>>>> think we always where thinking of change things as >>we >> >> >>evolve >> >> >> >> >>>>> Royale. >> >> >> >> >>>>>>>> We're >> >> >> >> >>>>>>>>>> in a 0.9.2 release, we're not in 1.0, but the way >>we're >> >> >> >>managing >> >> >> >> >>>>> all >> >> >> >> >>>>>>>>>> issues >> >> >> >> >>>>>>>>>> seems to >> >> >> >> >>>>>>>>>> me that we're fine with what we have now and we are >> >> >>freezing >> >> >> >>the >> >> >> >> >>>>> API. >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> In all the issues raised last days only CSS compiler >> >> >>errors >> >> >> >>are >> >> >> >> >>>>> real >> >> >> >> >>>>>>>> bugs, >> >> >> >> >>>>>>>>>> since without that fixes royale can't output >>concrete >> >>CSS >> >> >> >>rules >> >> >> >> (I >> >> >> >> >>>>>> think >> >> >> >> >>>>>>>>>> those not require any discussion) >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> The font injection is maybe another bug (don't know >> >>why a >> >> >> >>class >> >> >> >> in >> >> >> >> >>>>> a >> >> >> >> >>>>>>>> theme >> >> >> >> >>>>>>>>>> is not "visible" by the final app), but can be >> >> >>workarounded >> >> >> >>with >> >> >> >> >> an >> >> >> >> >>>>>> html >> >> >> >> >>>>>>>>>> that setup the font for now. >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> Things like classNames discussion are not critical >>(I >> >> >>know), >> >> >> >> it's >> >> >> >> >>>>>> just a >> >> >> >> >>>>>>>>>> matter to refine the API since I had problems each >> >>time I >> >> >>go >> >> >> >> that >> >> >> >> >>>>>> path, >> >> >> >> >>>>>>>>>> first with MDL and now with Jewel. Maybe I'm the >>only >> >>one >> >> >> >>since >> >> >> >> no >> >> >> >> >>>>>> other >> >> >> >> >>>>>>>>>> has tried what I'm trying to do: Creating Themes. >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> In my opinion, give the users only a way to manage >> >> >>classNames >> >> >> >> vía >> >> >> >> >>>>>>>> string, >> >> >> >> >>>>>>>>>> is insufficient and cumbersome and deserves at a >> >>minimun >> >> >>some >> >> >> >> API >> >> >> >> >>>>>>>> methods >> >> >> >> >>>>>>>>>> since is an important point in how UI is stylized, >>and >> >>how >> >> >> >> >> controls >> >> >> >> >>>>>> and >> >> >> >> >>>>>>>>>> objects in html can be "extended" or diferenciated >> >>(Alex >> >> >> >> explained >> >> >> >> >>>>>> very >> >> >> >> >>>>>>>>>> well the importance of this in the typenames >>thread). >> >>So >> >> >>some >> >> >> >> API >> >> >> >> >>>>> to >> >> >> >> >>>>>>>> ease >> >> >> >> >>>>>>>>>> that is for me very Wellcome since I'm doing that >>work, >> >> >>and >> >> >> >>will >> >> >> >> >> be >> >> >> >> >>>>>> more >> >> >> >> >>>>>>>>>> users doing that work. In this point, I don't think >>we >> >> >>should >> >> >> >> >>>>> shield >> >> >> >> >>>>>> us >> >> >> >> >>>>>>>> in >> >> >> >> >>>>>>>>>> things like PAYG or if that is a bit less >>performant. >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> To close and avoid having much discussion to not >>reach >> >>to >> >> >> >>some >> >> >> >> >>>>>> valuable >> >> >> >> >>>>>>>>>> point: I can try to go with what we have, but >>makes me >> >> >>feel >> >> >> >>not >> >> >> >> >> so >> >> >> >> >>>>>> good >> >> >> >> >>>>>>>>>> about the continuous rejection of my proposals. As >> >>well, >> >> >>you >> >> >> >>are >> >> >> >> >>>>>> saying >> >> >> >> >>>>>>>>>> that we should wait to what users demand...but I'm >>an >> >> >>user of >> >> >> >> the >> >> >> >> >>>>> API, >> >> >> >> >>>>>>>> and >> >> >> >> >>>>>>>>>> my perception as a "zero user" seems to be not >> >>valuable. >> >> >> >>Since I >> >> >> >> >>>>> don't >> >> >> >> >>>>>>>> get >> >> >> >> >>>>>>>>>> traction on this, I'll try to continue with what we >> >>have >> >> >>and >> >> >> >> >> report >> >> >> >> >>>>>> back >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> 2018-03-13 9:24 GMT+01:00 Harbs >> >><[email protected]>: >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>>> +1. >> >> >> >> >>>>>>>>>>> >> >> >> >> >>>>>>>>>>>> On Mar 13, 2018, at 10:08 AM, Alex Harui >> >> >> >> >>>>> <[email protected]> >> >> >> >> >>>>>>>>>>> wrote: >> >> >> >> >>>>>>>>>>>> >> >> >> >> >>>>>>>>>>>> I am so sad and frustrated that we have spent so >>much >> >> >>time >> >> >> >>on >> >> >> >> >>>>>>>>>> managing a >> >> >> >> >>>>>>>>>>>> set of strings. I just don't think we have the >> >>people >> >> >> >>power >> >> >> >> to >> >> >> >> >>>>>>>>>> continue >> >> >> >> >>>>>>>>>>>> to seek perfection until it is truly needed by a >> >>user. >> >> >> >> >>>>>>>>>>> >> >> >> >> >>>>>>>>>>> >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> >> >> >> >> >>>>>>>>>> -- >> >> >> >> >>>>>>>>>> Carlos Rovira >> >> >> >> >>>>>>>>>> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> http%3A%2F%2Fabout.me% >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> 7Ce137bd7a9095473c2bcc08 >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> 7C63656545817565873 >> >> >> >> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%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 >> >> >> %7Ce137bd7a9095 >> >> >> >>473c2bcc08d588e95a01%7Cfa7b1b5a7b34438794aed2c178de >> >> >> cee1%7C0%7C0%7C6365654 >> >> >> >>58175658737&sdata=DNkm0Dce279Klqlmt%2BF7YV7% >> >> >> 2BiDRjzQWyG9GPG1rs2Bw%3D&rese >> >> >> >>rved=0 >> >> >> >> >>>>>>>>> >> >> >> >><https://na01.safelinks.protection.outlook.com/?url= >> >> >> https%3A%2F%2Fwww.pat >> >> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com >> >> >> %7Ce137bd7a9095 >> >> >> >>473c2bcc08d588e95a01%7Cfa7b1b5a7b34438794aed2c178de >> >> >> cee1%7C0%7C0%7C6365654 >> >> >> >>58175658737&sdata=DNkm0Dce279Klqlmt%2BF7YV7% >> >> >> 2BiDRjzQWyG9GPG1rs2Bw%3D&rese >> >> >> >>rved=0>* >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> -- >> >> >> >> >>>>>>> Carlos Rovira >> >> >> >> >>>>>>> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> http%3A%2F%2Fabout.me% >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> 7Ce137bd7a9095473c2bcc08 >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> 7C63656545817565873 >> >> >> >> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>>> -- >> >> >> >> >>>> Carlos Rovira >> >> >> >> >>>> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> http%3A%2F%2Fabout.me% >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> 7Ce137bd7a9095473c2bcc08 >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> 7C63656545817565873 >> >> >> >> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 >> >> >> >> >>>> >> >> >> >> >>>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> -- >> >> >> >> >>> Carlos Rovira >> >> >> >> >>> >> >> >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> http%3A%2F%2Fabout.me% >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> 7Ce137bd7a9095473c2bcc08 >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> 7C63656545817565873 >> >> >> >> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Carlos Rovira >> >> >> >> > >> >> >> >>https://na01.safelinks.protection.outlook.com/?url= >> >> >> http%3A%2F%2Fabout.me% >> >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> 7Ce137bd7a9095473c2bcc08 >> >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> 7C63656545817565873 >> >> >> >> >>>>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> >-- >> >> >> >Carlos Rovira >> >> >> >https://na01.safelinks.protection.outlook.com/?url= >> >> >> http%3A%2F%2Fabout.me%2 >> >> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> >> 7Ce137bd7a9095473c2bcc08d5 >> >> >> >88e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> >> 7C636565458175658737&s >> >> >> >>>data=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 >> >> >> >> >> >> >> >> > >> >> > >> >> >-- >> >> >Carlos Rovira >> >> >https://na01.safelinks.protection.outlook.com/?url= >> >> http%3A%2F%2Fabout.me%2 >> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> >> 7Cce849efb1cf84ab780ae08d5 >> >> >8905f78a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> >> 7C636565581091621628&s >> >> >data=5bptuicHsczeSJ84dMNT8%2FFZG42Ai732OmY8QCEbgXo%3D&reserved=0 >> >> >> >> >> > >> > >> >-- >> >Carlos Rovira >> >https://na01.safelinks.protection.outlook.com/?url= >> http%3A%2F%2Fabout.me%2 >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% >> 7C6de99e3bf5d844c2d09508d5 >> >890825d0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >> 7C636565590443837727&s >> >data=S%2F5fMzHFvlp8PHkdA28CcWSeMvcly1YJXTmDz6l0fUM%3D&reserved=0 >> >> > > >-- >Carlos Rovira >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2 >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C1ca96ed710784d65283408d5 >893021e1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636565762176651455&s >data=BMnY%2BfW6dLZq0xVS3f1jTATtbUEXWOiaWFGRIwwPu7U%3D&reserved=0
