royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <>
Subject Re: [Discussion] Package change names (was Re: 0.9.3 Release)
Date Thu, 31 May 2018 08:05:10 GMT
Comments inline.

> On May 31, 2018, at 10:44 AM, Carlos Rovira <> wrote:
> I think there's a cost, don't know if the cost is higher or lower.

My question is whether we would actually be avoiding this cost by pulling the CSS out of Basic.
I don’t know the answer to this question. I suspect that the compiler needs to analyze all
the CSS files in every swc in the libs folder whether they are used or not. If that’s the
case, there’s nothing to gain by pulling out the CSS for at least 90% of the use cases of
Royale. Almost all Royale users will have the full lib of swcs.

> To me is
> not only the cost, is about as well as methodology. For me is incorrect to
> have a CSS always be compiled, no matter what kind of application I'll be
> constructing, even if nothing of that CSS goes into the final Application.
> You're making a useless compilation, that can introduce bugs or not, or you
> must keep and eye always that is not doing wrong things. If you don't put
> that CSS in mandatory SWC, your problems are all gone. I think CSS should
> be *always* in optional SWCs. For me maybe this is the most important
> concept or rule we should follow.

In theory, I agree with you. In practice, I’m not so sure.

The problem with pulling the TLC components out of Basic is that it requires a separate dependency
for use. That makes more work for someone using Maven (for example). Also the likelihood of
NONE of the TLCs to be used by other component sets is slim. I believe that Basic (or Express)
composite components (such as ComboBox, DataGrid, etc.) should be used in Jewel and just the
views should be swapped out. Dictating that Jewel can’t use Basic TLCs simply on principle
is something I have a hard time with.

If using them would have a concrete negative effect on an app, I agree that it would be a
problem, but I think we’ve determined that to not be the case.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message