Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Alina is nearing the point of getting everything to compile. Now it is time to get things to "run". And later, we will try to get things to "run and look good". I've been distracted by other things, but I hope get back to getting components to "run". Meaning, they show something on the

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

> IMO, if we all pitched in on emulation > Perfection can be the enemy of success. Sorry to be so selfish, but I am > just trying to keep my job. Fair enough. If I were to pitch in with the emulation, what would you recommend I work on? Harbs > On Jun 6, 2018, at 9:24 PM, Alex Harui

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

IMO, if we all pitched in on emulation, we would have many more migrating users at the end of the year claiming that the UI is still a bit ugly. If we leave emulation to fewer people, then at the end of the year, we may not have gotten all of the emulation components up and running and so

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Hi Alex, And I think that approach is perfectly valid. But we tend to think the rest of us are wrong, and I think that's not the case. Don't you think that if we solve this king of problems (let's call it "styling problems"), we can get a more visual Royale to put material online in website and

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

IMO, the thing that will have the greatest impact on whether Adobe will continue to pay me to work full time on Royale is how many active users we have at the end of the year, not whether we have a really cool way of avoiding type selector name collisions. So I am asking folks to consider that

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

FTR, in the other thread about package names, I do not agree that Jewel must re-use or subclass Basic or Express TLCs. The main point of code re-use is in the beads. Express can certainly subclass Basic TLCs as its goal is to pre-aggregate Basic beads. But, IMO, Jewel doesn't have to

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

I think as well this is important. Very important. We must notice that we are a multidisciplinar team and we must take advantage of that making each one work in the areas where they get the most of it. I think if Harbs wants to make this happen, I think he should do that. For needs, I think MX

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

> This just seems like too much work for the hopefully seldom case of mixing > TLC's from various component sets. Well, I am already doing that… Maybe I’m the exception, but it’s not a theoretical need. ;-) It also would enable us to use Basic and Express TLCs in Jewel — without subclassing

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

This just seems like too much work for the hopefully seldom case of mixing TLC's from various component sets. Remember that in "Terminology and Concepts", the TLC's are just collections of beads. There should be little dependencies of the beads on the host strand. Folks should be able to

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

> Button{ > TypeNames: “.jewel.button”; > } > > should not be? > > Button{ > TypeNames: “jewel button”; > } Yup. You’re right. Typo there… ;-) > (side question not related what does lookupOnly="true"?, I > forgot completely about the use or need for that) Others might have a better

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Hi Harbs, I reach to the same conclusion that "typeNames" set in the class code is not the best way to go, and not PAYG. A rule to follow should be that TLCs and other classes should never hardcode anything about layout, positioning, styles or classNames. So I think your strategy is good in

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

While I was trying to figure out how the compiler handles CSS, a new idea came to me which I think is better than any of the ideas we had until now (if I might say so myself). ;-p Basically, we can just use the component manifest file. One of the issues I was struggling with is that if the

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

OK, then I think we are on roughly the same page. Earlier I proposed a map of package names to short names. However, I just realized that it needs to be a map of MXML namespaces to short names, and metadata won't work because I think the rules get chosen by MXML namespace instead of package

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Right. > On May 31, 2018, at 10:29 AM, Carlos Rovira wrote: > > Just an important point here: I understand that in this case, we're talking > about a metadata analyzed at compiler time, so there's no cost at runtime > and that metadata will not be preserved. I think that would be great >

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Just an important point here: I understand that in this case, we're talking about a metadata analyzed at compiler time, so there's no cost at runtime and that metadata will not be preserved. I think that would be great improvement I think Alex is thinking in some kind of metadata at runtime, but

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

I’m not talking about solving subclassing here. I’m talking about one thing: How to determine what classnames the compiler writes to HTML CSS files for specific types. Carlos and I would both like for the compiler to compile: j|Button{ background-color: #fff; } To: .jewel.Button{

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

There has always been an option to keep/strip metadata in the output. It is -compiler.keep-as3-metadata. I don't think I understand what you are proposing with metadata. I thought I'd shown that there was no easy way to solve what the runtime (ValuesManager) should do. I thought we'd agreed

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Hi, right, I, in fact, try to use the format "org_apache_royale_html_Button", but seems very cumbersome to me and for that reason in Jewel I write like in Semantic ".jewel.button", since this is more friendly with CSS, less verbose and more flexible 2018-05-29 14:47 GMT+02:00 Harbs : > > I like

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Sorry for the delay in response here. I was not feeling very well last week… (I forgot how much work an infant is…) ;-) I think it’s time to wrap this up. I don’t think there’s any completely PAYG solution to this problem. I think conflicts need to be prevented by default. I like the metadata

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

I think we are in agreement. My most recent posts were intended to show that #2 is not easily solvable, if at all, and thus we should not invest time or energy there. My only suggestions regarding #1 is that we do not invent a second naming system, and that whatever we do is PAYG in the sense

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

I’m getting confused. Let me try and summarize the issues as I understand them: There are two different types of issues: Compile time issues, and runtime issues. Compile time issues are: 1. Compiled css files do not differentiate between different packages. (i.e. ImageButton type selectors

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

I know I am late to this very, very long discussion, but after wading through (and even skipping over some of the more “complex” emails), I think this is become overly complicated. My understanding has been that RadioButton (for example) in basic.css would provide the beads while .RadioButton

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

On 5/18/18, 2:50 AM, "Harbs" wrote: And basic.css has: RadioButton { font-size: 12px; font-family: sans-serif; } RadioButton is a Royale Type Selector as it should be. No discussion on that front (with the exception that the

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Hi Harbs, 2018-05-18 13:23 GMT+02:00 Harbs : > A couple of questions/comments: > > > On May 18, 2018, at 1:57 PM, Carlos Rovira > wrote: > > > > One more important technical thing about that way is "verbosity" since > each > > time you reference

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

A couple of questions/comments: > On May 18, 2018, at 1:57 PM, Carlos Rovira wrote: > > One more important technical thing about that way is "verbosity" since each > time you reference that kind of class you are introducing a name that use > to be 2-3 time longer, each

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Hi just responding some few things I saw: "Metadata is possible, but metadata is expensive at runtime." Depend if is a Metadata to use at compile time or at run time. In this case we're talking about a compile time metadata. Even at runtime, a metadata can be or not expensive depending on the

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

> > It is a bug. In the framework. The defaults.css for Basic has a > .DynamicDataGrid in it. It shouldn't have that. (There might be another > framework bug where a ClassReference in .DynamicDataGrid referenced DataGrid > which bring in DataGridButtonBar which brings in ButtonBar)

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

I picked this post to respond to in order to write one response instead of several. Comments Inline... On 5/17/18, 1:39 PM, "Harbs" wrote: Snipping relevant pieces to make it more legible… Let me use a concrete example to illustrate what I mean: Try

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

mmm this one seems not as easy as you post. If you do that in Jewel, then people wanting to mix with Basic will have a problem. I think better things simple and prefer the first scenario, simple and direct. Think that normaly extending what I call "final" component (and I said that I don't want

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

I love that idea of Metadata in class. +1 to that one :) 2018-05-17 22:39 GMT+02:00 Harbs : > Snipping relevant pieces to make it more legible… > > > > > I agree #1 and #2 are creating problems, but they are not bugs in the > compiler. I believe the compiler correctly

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

One more point: If we go the meta-tags route, we can include in the tag whether to include base typenames. Something like the following would tell the compiler that the org.apache.royale.html.Button typename is not being used. [Typename(name="Button", prefix=“basic”, inherits=“false")]

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Snipping relevant pieces to make it more legible… > > I agree #1 and #2 are creating problems, but they are not bugs in the > compiler. I believe the compiler correctly prunes out any Type Selectors > that are not used. The compiler must carry over any class and id selectors > since there

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Hi Alex, 2018-05-17 19:36 GMT+02:00 Alex Harui : > Some comments inline. > > On 5/17/18, 4:53 AM, "Harbs" wrote: > > OK. Let’s take a step back. > > Here’s what I think is the takeaway of the first part of the > “refactor” discussion. It

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Some comments inline. On 5/17/18, 4:53 AM, "Harbs" wrote: OK. Let’s take a step back. Here’s what I think is the takeaway of the first part of the “refactor” discussion. It seems like there are real issues — some of which have been partially resolved by

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

OK. Let’s take a step back. Here’s what I think is the takeaway of the first part of the “refactor” discussion. It seems like there are real issues — some of which have been partially resolved by Carlos, and none really have to do specifically with a project refactor. There are multiple

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

Hi Alex, I think I need some example code to understand what you try to explain here. I don't get to follow your explanation. Can you post some sample code to explain it better? thanks! 2018-05-16 23:43 GMT+02:00 Alex Harui : > Typo in there: > > "...make the compiler

Re: [DISCUSS] Explanation of the changes

I'm not sure that making different namespaces be interpreted in different ways would be good. That kind of things would be things that people coming would need to now or they will find problems when using Royale. In the other hand that kind of things (this work in this way for A but works in this

Re: [DISCUSS] Explanation of the changes

I guess it depends. As long as the styling is set by class selectors, it will work because class selectors trump type selectors. I think it would at least be better than what we have now. > On May 16, 2018, at 10:42 PM, Alex Harui wrote: > > Would that work? I

Re: [DISCUSS] Explanation of the changes

Would that work? I think any TLC with an HTMLButtonElement as its element (or sub-element) will still be affected by any Button type selector in some CSS file. Or maybe I don't fully understand what you are proposing. -Alex On 5/16/18, 9:41 AM, "Harbs" wrote:

Re: Terminology and Concepts (was Re: [DISCUSS] Explanation of the changes)

For others who are maybe also a bit lost like me, maybe this helps: - This is the wiki page [1] - TLCs = Top-Level-Components Olaf [1] https://github.com/apache/royale-asjs/wiki/Terminology-and-Concepts -- Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Terminology and Concepts (was Re: [DISCUSS] Explanation of the changes)

Very interesting Alex, I think this is not working now in Jewel now, but we should get to it. Maybe that would need even to take into account the SWF version that I'm not focusing, as I get some time I'll try to see what is missing and try to make this work thanks Carlos 2018-05-15 17:40

Re: [DISCUSS] Explanation of the changes

The goal of typenames is to do the best job we can of emulating Type Selectors. I understand it isn't perfect, but the browser does have Type Selectors and we can't really stop people from expecting Type Selectors to work, and wishing it would work on the rest of Royale. On 5/15/18, 8:37 AM,

Re: [DISCUSS] Explanation of the changes

Makes sense, but there’s two problems with that: 1. That makes the assumption that components of a specific name implement the HTML component of the same name. 2. Classes take precedence over element selectors, so that styling is too easily overridden. > On May 15, 2018, at 6:11 PM, Alex

Re: [DISCUSS] Explanation of the changes

Certain typenames match up against HTMLElement names and are thus valid Type selectors so are not transformed into Class Selectors. -Alex On 5/15/18, 2:09 AM, "Harbs" wrote: Interesting. It looks to me like a bug. The theme CSS compiles into this:

Re: [DISCUSS] Explanation of the changes

Hi Harbs, complety true. I think this is, at least for what I can see about my investigations, the most flexible way. And this is nothing new, I borrowed it from Semantic UI set, and for now it seems to work flawlessly :) Thanks Carlos 2018-05-15 13:26 GMT+02:00 Harbs :

Re: [DISCUSS] Explanation of the changes

This makes sense. I liked the way you used style composition in Jewel to piece together functionality. It’s very elegant. The only thing I would comment is that we can still use prefixing to prevent conflicts: "jewel jewel-Button primary" or “jewel jewel-Button emphasized”. It seems to me like

Re: [DISCUSS] Explanation of the changes

OK. Great! It looks like we’re agreeing on these points too. (It seems like I was right that we agree on most points) :-) To add a bit of clarity: We are using (some) MDL in our app, and we had requirements to modify the default MDL styling. I found this very difficult to do and I ended up

Re: [DISCUSS] Explanation of the changes

Right, we solved many bugs the last month like this. It was already one or two that was not clearly fixed or not, since the test Alex did worked by when I tried to use wasn't. Don't remember if this was one of them. Please check the issues, and see if it relates to some open CSS bug. I think the

Re: [DISCUSS] Explanation of the changes

2018-05-15 10:52 GMT+02:00 Harbs : > Excellent! I think we’re finally on the same page. :-) > > We agree that j|Button would theoretically be better, but we are unsure > whether we can practically achieve that goal in a manner that would be > acceptable. It might be that

Re: [DISCUSS] Explanation of the changes

Interesting. It looks to me like a bug. The theme CSS compiles into this: Button { border: 1px solid #808080; padding: 4px; background-color: #f8f8f8; margin: 0px; border-radius: 2px; } Button:hover { border: 1px solid #808080; padding: 4px;

Re: [DISCUSS] Explanation of the changes

Excellent! I think we’re finally on the same page. :-) We agree that j|Button would theoretically be better, but we are unsure whether we can practically achieve that goal in a manner that would be acceptable. It might be that the current solution is the best we can do with all things

Re: [DISCUSS] Explanation of the changes

> I'm finding this thread to be hard to follow. Agreed. There are many different points and things have gotten quite confusing. That’s why I’m trying to concentrate on one issue at a time. That should enable us to take things in bite size pieces. I think it has been successful so far. I feel

Re: [DISCUSS] Explanation of the changes

Hi, I'm finding this thread to be hard to follow. It seems to be focusing a lot on mixing what I call "top-level components" from more than one component set, which is a valid scenario, and exposes some valid bugs, but I'm not sure how often it will be used. I also think there is some

Re: [DISCUSS] Explanation of the changes

Hi Harbs, 2018-05-14 23:37 GMT+02:00 Harbs : > So, we are saying the same thing. > > This will not work: > j|Button > { > border: 5px solid black; > } > > But this will: > .jewel.button > { > border: 5px solid black; > } > > That’s what I meant when I said the user must

Re: [DISCUSS] Explanation of the changes

So, we are saying the same thing. This will not work: j|Button { border: 5px solid black; } But this will: .jewel.button { border: 5px solid black; } That’s what I meant when I said the user must know the default classnames that Jewel uses. I consider this to be a problem. (Not a

Re: [DISCUSS] Explanation of the changes

I think we have zeroed in on the point of 1a. Great! :-) I don’t understand what you mean here. I don’t understand how component styles could be assigned. To be clear I mean something like this: http://ns.adobe.com/mxml/2009 "

Re: [DISCUSS] Explanation of the changes

2018-05-14 15:25 GMT+02:00 Harbs : > > ok, is very difficult to separate things in this case, > > > Yes. I agree. Thanks for bearing with me. :-) > > We might come around to your solutions in the end, but without discussing > it, we are closing off other options which might

Re: [DISCUSS] Explanation of the changes

I think I still did not make myself clear. I’m not talking about someone only using Jewel. I am talking about an application which uses BOTH a Jewel Panel *AND* a Basic Panel (or Button, TextInput, etc.). The problem I’m discussing has nothing to do with whether Jewel extends Basic or not. I’m

Re: [DISCUSS] Explanation of the changes

Hi Harbs, 2018-05-14 10:14 GMT+02:00 Harbs : > Hi Carlos, > > I’d like to work on getting this discussion as focused as possible. Once > we’re clear on the problems, it’s much easier to find a solution which is > acceptable to everyone. I think part of the miscommunication

Re: [DISCUSS] Explanation of the changes

I’m glad to hear it. There is a lot of text in your email, and I need the time to read it properly and address the points. I hope to do that tomorrow. I think there is still some unclarity on some of the points (both ways). I’m glad the discussion is back on track. I would like to just say that

Re: [DISCUSS] Explanation of the changes

Hi Harbs, 2018-05-13 10:40 GMT+02:00 Harbs : > I specifically waited to respond to this until some of the heat cooled > off. I have no question that there is a bit of a language barrier here and > both sides are not making themselves completely understood. > I could in

Re: [DISCUSS] Explanation of the changes

Hi Om, 2018-05-13 9:11 GMT+02:00 OmPrakash Muppirala : > It took a while for me to catch up on the series of threads on this topic. > From what I see, on a high level, https://snag.gy/KW36yn.jpg seems to be a > better setup than https://snag.gy/JqO2ZI.jpg. That is , Jewel

Re: [DISCUSS] Explanation of the changes

I specifically waited to respond to this until some of the heat cooled off. I have no question that there is a bit of a language barrier here and both sides are not making themselves completely understood. I’m a bit disappointed that we’re moving towards a vote before I believe we’ve gotten to

Re: [DISCUSS] Explanation of the changes

It took a while for me to catch up on the series of threads on this topic. >From what I see, on a high level, https://snag.gy/KW36yn.jpg seems to be a better setup than https://snag.gy/JqO2ZI.jpg. That is , Jewel must extend from Core and not extend Basic. Ideally we would follow these sets of

Re: [DISCUSS] Explanation of the changes

Hi Yishay, 2018-05-12 20:17 GMT+02:00 Yishay Weiss : > Hi Carlos, > > Thanks for your detailed post. > > I don’t have time right now to address all of the points you raised, but > what you wrote in the following extract strikes me as inaccurate. > > >For example Jewel

RE: [DISCUSS] Explanation of the changes

Hi Carlos, Thanks for your detailed post. I don’t have time right now to address all of the points you raised, but what you wrote in the following extract strikes me as inaccurate. >For example Jewel Slider is based on input range, while Basic Slider is >build with two buttons. So even ISlider

Re: [DISCUSS] Explanation of the changes

I'll be opening a [Vote] thread on Monday so we can decide upon this if we must to revert changes. Thanks 2018-05-12 10:09 GMT+02:00 Carlos Rovira : > Hi, > > I'm trying here to explain with more tools the problems we had until now > and the solution I did he past