Peter, That's right, input range is what MDL and other uses and has good support in browsers so it's the best option for HTML. In the other hand I steel have to implement vertical version that seems to be done with a transformation of the component (or at least is what is most people do).
Thanks 2018-04-18 16:32 GMT+02:00 Peter Ent <p...@adobe.com.invalid>: > In my spare time I've been playing around with components that just build > HTML without SWF and it does make it easier. I saw the range input and > that's a great way IMO to handle the browser side. > > —peter > > On 4/16/18, 12:38 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: > > >Hi Peter, > > > >that's mainly the problem. As Alex said in some moment, I'll be happy if > >we > >approach the SWF in two phase, > >one that at least show minimal bounding boxes, interaction and events > >working ok. Then go the "skinning" phase. > > > >We should have to look at some particularities. For example Slider in > >Jewel > >is done like in MDL with an input range, > >that makes lots for you, but in Flash there's no such control, so the > >current basic implementation is ok (two buttons, one > >for track and one for thumb), but again our ISliderView interface is not > >right anymore since in JS we don't need "track" > >and "thumb" since input range does not has that parts, although in CSS > >there's something similar > > > >Thanks, for looking the virtual list bug! :) > > > > > > > >2018-04-16 17:40 GMT+02:00 Peter Ent <p...@adobe.com.invalid>: > > > >> Sure, I'll be happy to look at the bug. > >> > >> I was asking about SWF because I was toying with the idea of a SWF-free > >> framework and how much time is spent to get the SWF side working when > >>the > >> browser just does so much for you. Not everything of course, but > >>sometimes > >> simple things for the browser is a good chunk of work for SWF. > >> > >> —peter > >> > >> On 4/16/18, 11:36 AM, "carlos.rov...@gmail.com on behalf of Carlos > >>Rovira" > >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: > >> > >> >Hi Peter, > >> > > >> >thanks! I really didn't look too much at SWF. I really would like to do > >> >but > >> >it's a huge amount of work to deal with HTML only. > >> >But I don't want to left SWF version undone, and I try to think on it > >>in > >> >order to give a revision at some time and see what's failing and what > >>not. > >> >Another thing in the same boat are for example transitions and effects > >>(at > >> >least CSS for JS). I think we need all components working and good > >> >looking, > >> >then we can start looking to see more things in terms of effects and > >> >transitions. At least this is my plan so I can deal with all of it. > >> > > >> >Peter, one thing I need from you is if you can take a look at this bug > >> >[1], > >> >I'm now dealing with lists, and virtual list are very important. > >> > > >> >thanks! > >> > > >> >[1] Virtual List handles final items incorrectly > >> ><https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Fgithub.c > >> > >>>om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent% > 40adobe.com > >> %7 > >> >C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7 > >> >C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW% > >> 2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ > >> >frY%3D&reserved=0> > >> > > >> ><https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Fgithub.c > >> > >>>om%2Fapache%2Froyale-asjs%2Fissues%2F177&data=02%7C01%7Cpent% > 40adobe.com > >> %7 > >> >C67df4df73179488905ab08d5a3afd574%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7 > >> >C0%7C636594897951239437&sdata=vEgd35Vs%2B6DW% > >> 2BtWsYk0U9cQOCmJwGuYGnRvgPcqJ > >> >frY%3D&reserved=0> > >> > > >> > > >> > > >> >2018-04-16 15:52 GMT+02:00 Peter Ent <p...@adobe.com.invalid>: > >> > > >> >> There's been a huge amount of email surrounding Jewel - which is > >> >>terrific. > >> >> I haven't been able to digest all of it, but one question I have is, > >>how > >> >> much did you need to write to support SWF vs HTML/JS? Is that is in > >>the > >> >> framework (eg, Core, Basic) sufficient to support Jewel? > >> >> > >> >> ‹peter > >> >> > >> >> On 4/16/18, 4:15 AM, "carlos.rov...@gmail.com on behalf of Carlos > >> >>Rovira" > >> >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> > wrote: > >> >> > >> >> >Hi, > >> >> > > >> >> >maybe the decision was as well to support SWF? didn't look still to > >>how > >> >> >SWF > >> >> >does its duty but > >> >> >as JS has already ":hover", JS side doesn't need to deal with that > >> >>since > >> >> >CSS make that directly for you. > >> >> > > >> >> >Anyway.I'm in favor to move that part of the code off from > >> >> >UIItemRendererBase, so people could "plug-in" what they want > >> >> > > >> >> >About Layout I still need to look at how layouts are done in that > >>part > >> >> > > >> >> >I could raise a "refactoring ticket" so we could look at it at some > >> >>point > >> >> >if it's ok for all > >> >> > > >> >> >thanks > >> >> > > >> >> > > >> >> >2018-04-16 4:16 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > >> >> > > >> >> >> I didn't do most of this code. Although even if I did, it might > >>be > >> >>time > >> >> >> for some refactoring. Thinking about it briefly: > >> >> >> > >> >> >> Adding the ability to subclass in MXML is introduced at several > >> >>points > >> >> >>in > >> >> >> the SDK. We should be choosing not to weigh down the lowest-level > >> >> >>classes > >> >> >> with MXML capability (at least for now). > >> >> >> > >> >> >> I think UIItemRendererBase doesn't need to have the MXML > >>capability. > >> >> >>That > >> >> >> way, AS-based ItemRenderers will be a bit lighter and faster. > >> >> >> I think that the reason there are selectedColor, highlightColor, > >>and > >> >> >> downColor properties is for backward compatibility with Flex item > >> >> >> renderers and maybe because there is no "down" or "selected" > >> >> >>pseudo-states > >> >> >> in CSS, but I agree those can be moved off of UIItemRendererBase > >>to > >> >>some > >> >> >> other class. And the implementation of those color properties > >>could > >> >>just > >> >> >> set styles or class selectors. > >> >> >> > >> >> >> I think assignable layout is not required in item renderers. > >>Simple > >> >> >>ones > >> >> >> can just set x,y,width,height. So maybe MXMLItemRenderer should > >>add > >> >> >>the > >> >> >> code that calls MXMLDataInterpreter and MXMLItemRendererWithLayout > >> >>would > >> >> >> add the assignable layout support. > >> >> >> > >> >> >> Thoughts? > >> >> >> -Alex > >> >> >> > >> >> >> On 4/15/18, 9:36 AM, "Yishay Weiss" <yishayj...@hotmail.com> > >>wrote: > >> >> >> > >> >> >> >I think we need to accept that there are some assumptions made in > >> >>base > >> >> >> >classes that will not apply to every case. This is the tension > >> >>between > >> >> >> >PAYG and reusability which has been discussed before. As Alex > >> >>suggested > >> >> >> >you can always create a different implementation for > >> >> >> >ISelectableItemRenderer (or IItemRenderer). > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >What I find confusing is that MXMLItemRenderer does not > >>explicitly > >> >> >> >implement IMXMLDocument, and that most of the mxml related code > >>is > >> >> >> >actually in UIItemRendererBase. Alex, maybe you can explain what > >>the > >> >> >> >reasoning was for that? > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >________________________________ > >> >> >> >From: carlos.rov...@gmail.com <carlos.rov...@gmail.com> on > behalf > >> of > >> >> >> >Carlos Rovira <carlosrov...@apache.org> > >> >> >> >Sent: Sunday, April 15, 2018 2:29:20 PM > >> >> >> >To: dev@royale.apache.org > >> >> >> >Subject: Re: ItemRenderer is not PAYG > >> >> >> > > >> >> >> >Hi, > >> >> >> > > >> >> >> >the hierarchy chain is "UIItemRendererBase > DataItemRenderer > > >> >> >> >MXMLItemRenderer" > >> >> >> > > >> >> >> >ListItemRenderer extend from MXMLItemRenderer (if that's not the > >> >>right > >> >> >> >class let me know), since users will want to create mainly MXML > >>item > >> >> >> >renderers. > >> >> >> > > >> >> >> >So UIItemRendererBase is buried in the chain and I don't see a > >>way > >> >>to > >> >> >>get > >> >> >> >rid of it unless I create the same chain. > >> >> >> > > >> >> >> >Being said that, this is not critical for me, I can live with > >>those > >> >> >> >properties buried in the code, but I want to put this here to > >> >>signal a > >> >> >> >point when I see PAYG is not begin followed. > >> >> >> > > >> >> >> >For me people that wants to use colors in code should "aggregate > >>it" > >> >> >>in a > >> >> >> >PAYG way, and people that wants css should do the same on its > >>way. > >> >> >> >In other words, people using Jewel will have code in their apps > >>that > >> >> >>will > >> >> >> >be never used, and I think that's what we're trying to avoid > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >2018-04-15 8:54 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > >> >> >> > > >> >> >> >> There is no obligation to use UIItemRendererBase for Jewel > >> >> >> >>ItemRenderers. > >> >> >> >> If you run into places where we assume UIItemRendererBase and > >>not > >> >> >> >> IItemRenderer, that's either a bug or requires a different > >> >> >>controller or > >> >> >> >> view. > >> >> >> >> > >> >> >> >> Let us know what you run into. > >> >> >> >> > >> >> >> >> -Alex > >> >> >> >> > >> >> >> >> On 4/14/18, 8:33 AM, "carlos.rov...@gmail.com on behalf of > >>Carlos > >> >> >> >>Rovira" > >> >> >> >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> > >> >> wrote: > >> >> >> >> > >> >> >> >> >Hi, > >> >> >> >> > > >> >> >> >> >this base class > >> >> >> >> > > >> >> >> >> >UIItemRendererBase > >> >> >> >> > > >> >> >> >> >has properties for all colors (hover, selected, and more) and > >>a > >> >> >> >>"useColor" > >> >> >> >> >property, and updateRenderer() method is switching "useColor" > >> >> >> >> > > >> >> >> >> >as a low level class, I think this class should not have all > >>this > >> >> >>info, > >> >> >> >> >since most people will never use. > >> >> >> >> > > >> >> >> >> >In Basic I think is possible, but in Jewel colors, shapes and > >> >> >>effects > >> >> >> >> >comer > >> >> >> >> >from CSS. > >> >> >> >> > > >> >> >> >> >In this case I think 95% of users will never go that way of > >> >>setting > >> >> >> >>colors > >> >> >> >> >when the can do simply this: > >> >> >> >> > > >> >> >> >> >.jewel.item { > >> >> >> >> >cursor: pointer; > >> >> >> >> >padding: 8px; > >> >> >> >> >flex-shrink: 0; > >> >> >> >> >flex-grow: 1; > >> >> >> >> >} > >> >> >> >> >.jewel.item:hover { > >> >> >> >> >color: #FFFFFF; > >> >> >> >> >background: #24a3ef; > >> >> >> >> >} > >> >> >> >> >.jewel.item:active, .jewel.item.selected { > >> >> >> >> >color: #FFFFFF; > >> >> >> >> >background: #0f88d1; > >> >> >> >> >} > >> >> >> >> > > >> >> >> >> >without wiring a single line between logic and css. > >> >> >> >> > > >> >> >> >> >So I think useColors, and colors should be refactored to a > >>bead > >> >>or > >> >> >> >> >something that will not compromise the high level UI sets that > >> >>will > >> >> >> >>never > >> >> >> >> >use this kind of properties. > >> >> >> >> > > >> >> >> >> >Although I'm creating a ItemRenderer from scratch, my problem > >> >>here's > >> >> >> >>that > >> >> >> >> >there's so much hierarchy here and many other classes in the > >>tree > >> >> >>that > >> >> >> >> >depends. > >> >> >> >> > > >> >> >> >> >Creating a class extending "leaf" class nodes are easy, but > >>when > >> >> >> >>problems > >> >> >> >> >arise in the middle of the hierarchy chain, we have a problem > >> >>that > >> >> >>is > >> >> >> >> >difficult to solve > >> >> >> >> > > >> >> >> >> >thanks > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> >-- > >> >> >> >> >Carlos Rovira > >> >> >> >> >https://na01.safelinks.protection.outlook.com/?url= > >> >> >> >> http%3A%2F%2Fabout.me%2 > >> >> >> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> >> >> >> 7C6594b31e04554af2d97808d5 > >> >> >> >> >a21d2617%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> >> >> 7C636593168509138978&s > >> >> >> >> > >>>data=q1GZeXydbyaKPui4RFXJG4%2FlUdCrTcioiycbxGE5FD4%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% > >> >> >> 7Cecb978ca4324470249b508d5 > >> >> >> >a2ef021a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> >> 7C636594069925131582&s > >> >> >> >data=j8lkf7TFiiHpBsMnwJCjhLzCdZ8IOr4amxJuuhWrpRk%3D&reserved=0 > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> >-- > >> >> >Carlos Rovira > >> >> >https://na01.safelinks.protection.outlook.com/?url= > >> >> http%3A%2F%2Fabout.me%2 > >> >> >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com% > >> >> 7C9a4a4dfff1ae47fb5fd108d5a3 > >> >> >723be6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> 7C636594633390366154&sda > >> >> >ta=%2FnR1xBBCZ0Z9nHhSgYvlwzHXTq2c4GYlLAyw6CL%2FikA%3D&reserved=0 > >> >> > >> >> > >> > > >> > > >> >-- > >> >Carlos Rovira > >> >https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2 > >> >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com% > >> 7C67df4df73179488905ab08d5a3 > >> >afd574%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> 7C636594897951239437&sda > >> >ta=yHn%2BfuKivMYAoiaqxrWxEyhY8ykpi1Gqoq8wIr3mgzo%3D&reserved=0 > >> > >> > > > > > >-- > >Carlos Rovira > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2 > >Fcarlosrovira&data=02%7C01%7Cpent%40adobe.com% > 7C42790cf9f852488c70bd08d5a3 > >b8889e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636594935315481671&sda > >ta=GQBkm9%2BteqUn4xPPq26P08rXczAPUI0%2BYKCtIaT2swI%3D&reserved=0 > > -- Carlos Rovira http://about.me/carlosrovira
