I’m taking out two snippets from what you write that I think might help bring us closer: > > Right, that should go to Foundation, not Basic
What is the difference between “Foundation” and “Basic” other than name? We already have “Foundation”, but we call it “Basic”. If I’m understanding you correctly, the only difference between them is defaults.css and basic.css in themes. Other than that *everything* in Basic could be considered “Foundation”. Even top level components in Basic could be considered “Foundation” because they are designed to be bare-bones. Any components that don’t fit that description in Basic need to be fixed. Why are we making such a big deal over two css files? Right now, they are causing inflated application sizes. But we’ve determined that to be a bug In Basic. We need to fix the bug regardless. As long as they don’t cause the application size to increase (and I’m proposing they shouldn’t), why do we care? I don’t think we care that much whether we call it “Basic” or “Foundation”. Right? >> >> I think we have a disconnect here. >> >> Let’s take UIBase for example. UIBase has a lot of opinions on how things >> should be implemented. It gets its children from HTML nodes. It assumes >> that layout parents are not necessarily the immediate ones. It makes >> assumptions on what events need to be dispatched. etc. I don’t think that >> UIBase and friends belong in Core. In fact not every IUIBase even currently >> in the app are UIBase subclasses. IUIBase belongs in Core because it >> defines the function of a IUIBase. UIBase does not because it makes >> implementation assumptions. >> > > Here you and Alex think differently. I put UIBase in Core since was what > Alex suggested. Finaly I think we all think almost the same, but is > impossible to agree in 100% of things. Maybe, maybe not. I don’t remember Alex suggesting this, but I could have missed it. I don’t think there is any absolute right and wrong here, but we *do* need definitions we can all agree on. If UIBase (for example) should go in Core, then we need a definition that we can agree on and document which fits that and makes it clear exactly what should and what shouldn’t go in Core. > What we need to do is to move forward and continue build. We need to think > about what is important for each one so we can get the best of us (not > 100%). I for example was more for Core - Jewel, then you proposed > Foundation (not me, it was you, remember? I only put a name that seems > appropriate to me), so for me is ok. I was actually proposing something slightly different. I was proposing pulling the top level components of Basic (or CSS) into a separate library. I was only proposing that if we can’t fix the CSS issues which I think we can. > > What I'll never be in agreement is in having CSS that is processing bead > linking as a mandatory dependency for all the technical reasons exposed I completely agree with you on this. I thought that was clear from the CSS discussion. > I think that is not in opposite of the rest of things you want, only for > one of them, make all UI sets extend Basic classes, but I have a design > rule in Jewel that is not extend Basic classes, so how we deal with that? Basic classes, or Basic Top Level Components? I don’t see any reason why you should be avoiding anything other than TLCs which are specified in CSS and has different typeNames than Jewel ones. > Should I continue as Piotr proposed in a fork and abandone Royale as others > did? Or can we go forward and take the best of what all think? Definitely work this through. :-) I think we can come to an agreement. I think we’re not so far apart. Thanks, Harbs
