royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Coming back to discussion over separating libs (Was Re: No Touch support?)
Date Thu, 05 Jul 2018 09:39:12 GMT
I think the discussion was mainly done and that we agree in almost all
things but one: Should Jewel link Basic? For me it's clear that no.
Should Jewel use code in basic, clearly yes. So that left us with only 3
options:

1.- Make Jewel link Basic. But I against this solution due to many points I
exposed in lots of emails before.

2.- Separate Basic in two: Foundation (that's beads, supportClasses, and so
on, no CSS here) and Basic (TLCs, CSS,...). I think this is the middle
point where we should go as a community that wants to hear all voices and
respect all visions. For DG case, Jewel will end taking the needed common
pieces from Foundation.

3.- Duplicate code. I think the worst solution since no body wants it.

For me this discussion can't give us more, since we all know how others
think and is not about one think is better that the other, is clear as well
that all are valid solutions, but we need to take a path to continue our
way. The path should not be one fixed solution 100%, but a mixture of
various since we are community and fixed things could make people not be
happy at all with the solution, and end leaving. We have a huge historial
of leaves to make this happen again and some community things to talk about
yet that we said will do after closing this discussion.

IMHO, point 2 is the middle solution and for me the recommended to take.

Just my 2ctns

Carlos


2018-07-05 11:14 GMT+02:00 Piotr Zarzycki <piotrzarzycki21@gmail.com>:

> Hi,
>
> Someone could start work on DataGrid, but the discussion about not using
> Basic/Express in Jewel has not been finished. I don't see how actually is
> create that sophisticated component without inheriting those one from
> Express.
>
> Piotr
>
> --
Carlos Rovira
http://about.me/carlosrovira

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