Hi Harbs, 2018-05-30 15:26 GMT+02:00 Harbs <harbs.li...@gmail.com>:
> 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 you want we can callit Basic and BasicUI or something, I choose Foundation since for me fits perfectly with what does, but the name is secondary. > > 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. > CSS is main point, but as well Button, Slider, TextInput. All leaf implementations that make Basic to be Basic, and that are not needed by other UI sets like Jewel. MDL or CreateJS still needs them, so it can link Basic UI SWC, or make the same Jewel has done. Since this is now optional and not mandatory. > > 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? Since is not only CSS, and is absurd make people using Jewel to invest time processing all CSS files that he will never use. I think there's plenty of technical things I put on the table that this dependency fix, while the old one doesn't. > I don’t think we care that much whether we call it “Basic” or > “Foundation”. Right? > Right! It's only a name I bring to make my explanation more easy to follow. In this point I'm very flexible. I prefer Foundation since I think fits better, while Basic seems to me "the most basic implementation", but, for me the name is not blocking. The only point blocking (for me) of all points we discussed this month is trying to make Jewel link Basic. > > > > >> > >> 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. > If you want I can search for it. I think it was about 2 months or so when he point that UIBase should go to Core, and then in the same days, we discussed as well about making component to not extend Basic ones, that was that make me remove Basic dependency from Jewel. Moreover, when I moved UIBase to Core no body was surprised since it was just proposed and validated by Alex. > > > 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. > I think we should do both, but separation make fixing bugs not so crucial and as well make all better, since we promote "options" and not "obligations", so that makes Royale more flexible and powerful. > > > > > 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. > So for making this possible, I doubt it could be done only by bug fixing, and although you get to fix all bugs...think about processing all that CSS for nothing...that's pointless. > > > 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. > To make us understand TLC, the rest I want to reuse it! :) is what I call Foundation, but we can call it whatever you want if you don't like foundation name, but let's separate TLCs and CSS in its own library, I'll never use it! so let's avoid extra useless processing right? :) > > > 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. > > I think so... but hope this resolves soon, I think this discussions should be more agile and we shouldn't be looking with magnifying glass others changes. For example, I trust changes done by Alex, Piotr and yours....do you think I'm analyzing Combobox changes...no, don't understand a month of discussion something that should be more coding than writing mails. So hope we'll be getting to a close too :) Thanks -- Carlos Rovira http://about.me/carlosrovira
