Re: Container change

[Alex Harui]

One additional point added below:

On 5/10/18, 2:36 PM, "Alex Harui"  wrote:

Hi Carlos,

I don't think folks are as highly concerned about moving the 
ApplicationBase/ContainerBase/GroupBase classes into Core.  I disagree that 
GroupBase can go away, but that can be discussed later.

It is your "unique requisite" as you put it, that is the main issue.  There 
is no technical reason to change the patterns we've been using to try to ensure 
that Jewel doesn't link in Basic.  If every component set tries to be 
independent of every other component set, then lots of beads will be copied, 
and that does not scale.

If it turns out that the HTML components need 100% of what is in Group, 
then it should be fine for HTML's NodeBaseElement ot extend Basic's Group, just 
like Express components can extend Basic components.

So let's just focus on this one point.  What is the technical reason that 
component sets should not leverage other component sets?  Why would we want 
proliferation of copies of beads over time?

If the technical reason is that you found that it added unnecessary classes to 
the application, that should be seen as a bug, and not as a reason to 
prioritize component set independence over scalable patterns.  We want, in all 
use cases, to only bring in classes that are needed.  But principles of PAYG, 
DRY, and things like that should be first principles.  Component set 
independence should only happen if it makes sense in the application of those 
first principles.

Thanks,
-Alex

On 5/10/18, 2:22 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex

I think you still doesn't understand what I did. I'll try to expone it
again with other examples. I was not moving beads, I was moving
implementations that seems to me core (i.e: ApplicationBase, 
ContainerBase,
DataContainerBase, GroupBase...). Since Application, Container,
DataContainer, Group,seems to me  final implementations, like we 
show
many times (think about Application in Flat, MDL, CreateJS, and so... )

More data: After stay in FlexJS and Royale each day, I have a clear 
sense
of what is Basic. And for me is the library that includes all 
componentes,
controls and its more basic way. But it a Button in Basic is not like 
let's
say GroupBase, or ArraySelectionModel that are in Core since are needed 
in
UI sets (Basic, Jewel, ...). So Basic, assembles the "basic building
blocks" that are not needed to be used (extending, composing, or other
things) in the library Jewel.
In the other hand the user can decide, on its own to link in a final
application, Jewel and Basic, for whatever reason. What I don't want, 
and
is my *unique* requisite in all this discussion, is that Jewel link 
Basic
in order to be able to be built. Since nothing in Jewel required 
nothing in
Basic. And this is by design in Jewel.

HTML shouldn't since as you saw, having NodeBaseElement extends Group 
and
Group being part of Basic, made directly that HTML library pull all the
contents of Basic (I sent the mvn dependecy:tree that probes that in 
other
thread), and that by default was making that all examples that depends 
from
HTML, was not linking in explicit way Basic, since HTML brings that, 
what
for me is a defect in a build clearly (and this is not philosophical, is
something clearly technical, that hopes people understand as is, and 
will
not make me repeat one hundred times again or explain the same since no
body read when I wrote this)

About beads: Some beads was moved as well, since Jewel needs them and 
seems
to me very Core i.e: LayoutChangeNotifier, or events like 
ItemAddedEvent.
ItemRemovedEvent,... for me those classes are clearly Core, since other 
UI
sets will need them.

I for example did some temporal thing i.e: Copied MultilineLabel in 
Jewel.
But I'll be removing classes like this since my plan is not to have a
control called MultilineLabel, don't like that concept in Jewel. My 
plan is
to make a bead for label to create multi line. So things like this are 
what
I say that are temporal, but first I needed to reach a state when all
builds correctly without the need of Basic (again this is the most
important concept to me), and other "temporal" things will be done if we
end this kind of large discussion.

I'm all for "trying to define the patterns that will scale with us 
forever"
, but it seems very complicated in this way, since each movement in this
way will make people update their code 

Re: Container change

[Alex Harui]

Hi Carlos,

I don't think folks are as highly concerned about moving the 
ApplicationBase/ContainerBase/GroupBase classes into Core.  I disagree that 
GroupBase can go away, but that can be discussed later.

It is your "unique requisite" as you put it, that is the main issue.  There is 
no technical reason to change the patterns we've been using to try to ensure 
that Jewel doesn't link in Basic.  If every component set tries to be 
independent of every other component set, then lots of beads will be copied, 
and that does not scale.

If it turns out that the HTML components need 100% of what is in Group, then it 
should be fine for HTML's NodeBaseElement ot extend Basic's Group, just like 
Express components can extend Basic components.

So let's just focus on this one point.  What is the technical reason that 
component sets should not leverage other component sets?  Why would we want 
proliferation of copies of beads over time?

Thanks,
-Alex

On 5/10/18, 2:22 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex

I think you still doesn't understand what I did. I'll try to expone it
again with other examples. I was not moving beads, I was moving
implementations that seems to me core (i.e: ApplicationBase, ContainerBase,
DataContainerBase, GroupBase...). Since Application, Container,
DataContainer, Group,seems to me  final implementations, like we show
many times (think about Application in Flat, MDL, CreateJS, and so... )

More data: After stay in FlexJS and Royale each day, I have a clear sense
of what is Basic. And for me is the library that includes all componentes,
controls and its more basic way. But it a Button in Basic is not like let's
say GroupBase, or ArraySelectionModel that are in Core since are needed in
UI sets (Basic, Jewel, ...). So Basic, assembles the "basic building
blocks" that are not needed to be used (extending, composing, or other
things) in the library Jewel.
In the other hand the user can decide, on its own to link in a final
application, Jewel and Basic, for whatever reason. What I don't want, and
is my *unique* requisite in all this discussion, is that Jewel link Basic
in order to be able to be built. Since nothing in Jewel required nothing in
Basic. And this is by design in Jewel.

HTML shouldn't since as you saw, having NodeBaseElement extends Group and
Group being part of Basic, made directly that HTML library pull all the
contents of Basic (I sent the mvn dependecy:tree that probes that in other
thread), and that by default was making that all examples that depends from
HTML, was not linking in explicit way Basic, since HTML brings that, what
for me is a defect in a build clearly (and this is not philosophical, is
something clearly technical, that hopes people understand as is, and will
not make me repeat one hundred times again or explain the same since no
body read when I wrote this)

About beads: Some beads was moved as well, since Jewel needs them and seems
to me very Core i.e: LayoutChangeNotifier, or events like ItemAddedEvent.
ItemRemovedEvent,... for me those classes are clearly Core, since other UI
sets will need them.

I for example did some temporal thing i.e: Copied MultilineLabel in Jewel.
But I'll be removing classes like this since my plan is not to have a
control called MultilineLabel, don't like that concept in Jewel. My plan is
to make a bead for label to create multi line. So things like this are what
I say that are temporal, but first I needed to reach a state when all
builds correctly without the need of Basic (again this is the most
important concept to me), and other "temporal" things will be done if we
end this kind of large discussion.

I'm all for "trying to define the patterns that will scale with us forever"
, but it seems very complicated in this way, since each movement in this
way will make people update their code bases, and seems this is something
people here don't want to do.


2018-05-10 21:29 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I don't have a particular problem that you made a commit that broke
> things.   That happens from time to time.   I trust that if you knew up
> front it would break things you would have started it in a branch.  What 
is
> the problem is what happened afterward.
>
> I think there are at least 4 of us who still are not understanding you, or
> don't agree with your conclusions.  This means that we are not
> communicating well.  Either you are right, and you haven't found the words
> or data to convince us or vice versa.   And the 86 prior emails contained
> very little data.  Let's see if we can work from more concrete examples 
and

Re: Container change

[Carlos Rovira]

Hi Alex

I think you still doesn't understand what I did. I'll try to expone it
again with other examples. I was not moving beads, I was moving
implementations that seems to me core (i.e: ApplicationBase, ContainerBase,
DataContainerBase, GroupBase...). Since Application, Container,
DataContainer, Group,seems to me  final implementations, like we show
many times (think about Application in Flat, MDL, CreateJS, and so... )

More data: After stay in FlexJS and Royale each day, I have a clear sense
of what is Basic. And for me is the library that includes all componentes,
controls and its more basic way. But it a Button in Basic is not like let's
say GroupBase, or ArraySelectionModel that are in Core since are needed in
UI sets (Basic, Jewel, ...). So Basic, assembles the "basic building
blocks" that are not needed to be used (extending, composing, or other
things) in the library Jewel.
In the other hand the user can decide, on its own to link in a final
application, Jewel and Basic, for whatever reason. What I don't want, and
is my *unique* requisite in all this discussion, is that Jewel link Basic
in order to be able to be built. Since nothing in Jewel required nothing in
Basic. And this is by design in Jewel.

HTML shouldn't since as you saw, having NodeBaseElement extends Group and
Group being part of Basic, made directly that HTML library pull all the
contents of Basic (I sent the mvn dependecy:tree that probes that in other
thread), and that by default was making that all examples that depends from
HTML, was not linking in explicit way Basic, since HTML brings that, what
for me is a defect in a build clearly (and this is not philosophical, is
something clearly technical, that hopes people understand as is, and will
not make me repeat one hundred times again or explain the same since no
body read when I wrote this)

About beads: Some beads was moved as well, since Jewel needs them and seems
to me very Core i.e: LayoutChangeNotifier, or events like ItemAddedEvent.
ItemRemovedEvent,... for me those classes are clearly Core, since other UI
sets will need them.

I for example did some temporal thing i.e: Copied MultilineLabel in Jewel.
But I'll be removing classes like this since my plan is not to have a
control called MultilineLabel, don't like that concept in Jewel. My plan is
to make a bead for label to create multi line. So things like this are what
I say that are temporal, but first I needed to reach a state when all
builds correctly without the need of Basic (again this is the most
important concept to me), and other "temporal" things will be done if we
end this kind of large discussion.

I'm all for "trying to define the patterns that will scale with us forever"
, but it seems very complicated in this way, since each movement in this
way will make people update their code bases, and seems this is something
people here don't want to do.


2018-05-10 21:29 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I don't have a particular problem that you made a commit that broke
> things.   That happens from time to time.   I trust that if you knew up
> front it would break things you would have started it in a branch.  What is
> the problem is what happened afterward.
>
> I think there are at least 4 of us who still are not understanding you, or
> don't agree with your conclusions.  This means that we are not
> communicating well.  Either you are right, and you haven't found the words
> or data to convince us or vice versa.   And the 86 prior emails contained
> very little data.  Let's see if we can work from more concrete examples and
> data to try to close out this discussion.
>
> We are trying to define the patterns that will scale with us forever.
> Moving beads from Basic to Core because you want to use them elsewhere is
> not a pattern that scales.  I think you did not take into consideration the
> differences between the old Flex model and this new composition-centric
> model in Royale.  Separation of one project from another in a composition
> model should not be a high priority.  What is more important is good
> organization of the choices for composition.  Otherwise we will end up with
> another problem similar to UIComponent in Flex.


Right, and if you read my interventions I stated this at least three times
though all this large thread. That I copied a class (bead, support class,
or whatever) to make possible compilation without Basic, and sometimes for
temporal reasons, doesn't mean the I want to make a 15k UIComponent class.
There's no point on that. I'm totally in favor on how UIBase is designed
and how beads and strands work. Copying a bead, to use instead another,
doesn't make Jewel to have a UIComponent monolith class, so I don't see the
point on this here. In contrast having a unused library (Basic) linked for
nothing makes a complete difference of 40% more in size what means classes,
css, and styles linked for nothing, and making the Application have
potentially 

Re: Container change

[Alex Harui]

Hi Carlos,

I don't have a particular problem that you made a commit that broke things.   
That happens from time to time.   I trust that if you knew up front it would 
break things you would have started it in a branch.  What is the problem is 
what happened afterward.

I think there are at least 4 of us who still are not understanding you, or 
don't agree with your conclusions.  This means that we are not communicating 
well.  Either you are right, and you haven't found the words or data to 
convince us or vice versa.   And the 86 prior emails contained very little 
data.  Let's see if we can work from more concrete examples and data to try to 
close out this discussion.

We are trying to define the patterns that will scale with us forever.  Moving 
beads from Basic to Core because you want to use them elsewhere is not a 
pattern that scales.  I think you did not take into consideration the 
differences between the old Flex model and this new composition-centric model 
in Royale.  Separation of one project from another in a composition model 
should not be a high priority.  What is more important is good organization of 
the choices for composition.  Otherwise we will end up with another problem 
similar to UIComponent in Flex.  The Core library will contain thousands of 
classes that are similar just because someone wanted to re-use that code.  
Instead, we want Basic to contain beads that are simple, Express to contain 
"aggregations", and sets like Jewel and MDL can contain beads specific to those 
component sets.

A bead like a ToolTip bead can probably never go in Core.  It has "an opinion" 
about how and when to generate and dismiss a tooltip.  Look around and you will 
see other ways that ToolTips are handled.  The Basic Tooltip bead is a simple 
implementation that can be a sufficient default for a lot of component sets.  
But it isn't so universal that it should go in Core.

I think I will stop there and see if we can agree on this one point.  Maybe 
we'll have to end up taking a vote, but this is the pattern I think is best for 
Royale and I hope to convince you of that.

Thanks,
-Alex

On 5/10/18, 11:01 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Alex,

2018-05-10 18:50 GMT+02:00 Alex Harui :

> Wow!  Good thing I slept through this...
>
> Let's try to calm things down a bit.  I think we have agreement that this
> work should have been handled differently, but I really think this
> disagreement, like many disagreements is being escalated by poor
> communication.  Sometimes it is hard to realize that you haven't really
> explained yourself well.  You know the problem so well, and are probably
> trying to write a shorter email and/or have limited time to write, but it
> makes things worse instead of better.
>

I don't really think communication was bad. I'm in this project and FlexJS
form its beginning and I think I follow it always and I think my thinking
about what is basic was right. My opinion about this refactor, is that
maybe I did  huge commit and for such commit I should be done some
emailing, but other time we all commit without asking, so while it would be
better, really I didn't do nothing bad, but maybe wanting to make this
project advance as fast as possible.

Then as a refactor like this suppose changes in applications that use the
framework, Harbs instead of think in the positive thing of remove
dependencies between libraries, was worried about his application not
compiling. And here we are 86 emails asserting that we are not
understanding right the essence of Core and Basic. And what I think is that
team mates here instead of work for continue moving things to make this
project progress are trying to divert the attention talking about
philosophical point of view, and I think the refactor gets technical things
done clearly (separation and less size), while the philosophical seems more
to me in stay in what we had and not wanting to move due to applications
breaking. I'll understand that position with a framework more finished, but
in a 0.9.3 version, I think we have room, and we discussed a lot of this in
the past weeks, but I think many of the people not agreeing was the same
that didn't follow that discussion and now they think all this is wrong,
again due to personal interests.

As I did the refactor I was very close to the email to see if something was
broken, since although maven was ok in all aspect, I though something more
could be happen, and as you all see I was hard working to fix things as
people let me know. But what I think is a bad practice in a project is
talking about revert unilaterally a huge work that had many hours behind,
since I'll never dare to propose something like 

Re: Container change

[Carlos Rovira]

Hi Harbs,

2018-05-10 20:44 GMT+02:00 Harbs :

> Hi Carlos,
>
> I’d like to be clear about one thing:
>
> I have had my app break *many* times while we’ve been developing Royale
> and changing things. That’s OK. That’s part of the cost of working on the
> bleeding edge. I’m fine adjusting things to invest in improving our
> framework.
>
> I only have trouble if the changes are not warranted. I’m not convinced
> that these changes were warranted. We also agreed about a half a year ago
> that all breaking changes should be done in a feature branch. That’s
> something we’ve been pretty good at in general lately. We all agree that it
> was a mistake to make these changes on the develop branch, but mistakes
> happen and and let’s work with that.
>

If you see the I really did a feature branch...only that it was only one
commit and then merged. then I did one commit more for a thing I forget,
and then I was fixing things you and others say.


>
> Instead of pointing fingers, let’s try to focus on the technical reasons
> for refactoring and figuring out how and where refactoring should be done
> (if at all). If a refactor breaks my app(s), I’ll deal with it. But, let’s
> please first come to an agreement on what is best to do on technical merit.
>
>
but I expressed largely about the technical merit, for 90 emails in this
thread. You talk about this philosophic and I pointed you many tangible
technical reasons, and in opposite, you only give me philosophical reason
on your part...



> I’m making an effort to be quiet now to get input from others. I think
> I’ve already said pretty much what I’ve had to say.
>

I spent all the they with this, and I'm really upset on how my work is
saw...


>
> If you want my response on specific points, please let me know and I’ll
> respond to them.
>
> Thanks,
> Harbs
>
> > On May 10, 2018, at 9:01 PM, Carlos Rovira 
> wrote:
> >
> > Hi Alex,
> >
> > 2018-05-10 18:50 GMT+02:00 Alex Harui >:
> >
> >> Wow!  Good thing I slept through this...
> >>
> >> Let's try to calm things down a bit.  I think we have agreement that
> this
> >> work should have been handled differently, but I really think this
> >> disagreement, like many disagreements is being escalated by poor
> >> communication.  Sometimes it is hard to realize that you haven't really
> >> explained yourself well.  You know the problem so well, and are probably
> >> trying to write a shorter email and/or have limited time to write, but
> it
> >> makes things worse instead of better.
> >>
> >
> > I don't really think communication was bad. I'm in this project and
> FlexJS
> > form its beginning and I think I follow it always and I think my thinking
> > about what is basic was right. My opinion about this refactor, is that
> > maybe I did  huge commit and for such commit I should be done some
> > emailing, but other time we all commit without asking, so while it would
> be
> > better, really I didn't do nothing bad, but maybe wanting to make this
> > project advance as fast as possible.
> >
> > Then as a refactor like this suppose changes in applications that use the
> > framework, Harbs instead of think in the positive thing of remove
> > dependencies between libraries, was worried about his application not
> > compiling. And here we are 86 emails asserting that we are not
> > understanding right the essence of Core and Basic. And what I think is
> that
> > team mates here instead of work for continue moving things to make this
> > project progress are trying to divert the attention talking about
> > philosophical point of view, and I think the refactor gets technical
> things
> > done clearly (separation and less size), while the philosophical seems
> more
> > to me in stay in what we had and not wanting to move due to applications
> > breaking. I'll understand that position with a framework more finished,
> but
> > in a 0.9.3 version, I think we have room, and we discussed a lot of this
> in
> > the past weeks, but I think many of the people not agreeing was the same
> > that didn't follow that discussion and now they think all this is wrong,
> > again due to personal interests.
> >
> > As I did the refactor I was very close to the email to see if something
> was
> > broken, since although maven was ok in all aspect, I though something
> more
> > could be happen, and as you all see I was hard working to fix things as
> > people let me know. But what I think is a bad practice in a project is
> > talking about revert unilaterally a huge work that had many hours behind,
> > since I'll never dare to propose something like this. Moreover when we
> all
> > can have all the things we want at the same time. Or I don't see any
> > overlapping interest here.
> >
> >
> >
> >>
> >> So, couple of things to consider (actually more than a couple of
> things):
> >>
> >> -I still think we are missing a clear, detailed, technical analysis of
> 

Re: Container change

[Harbs]

Hi Carlos,

I’d like to be clear about one thing:

I have had my app break *many* times while we’ve been developing Royale and 
changing things. That’s OK. That’s part of the cost of working on the bleeding 
edge. I’m fine adjusting things to invest in improving our framework.

I only have trouble if the changes are not warranted. I’m not convinced that 
these changes were warranted. We also agreed about a half a year ago that all 
breaking changes should be done in a feature branch. That’s something we’ve 
been pretty good at in general lately. We all agree that it was a mistake to 
make these changes on the develop branch, but mistakes happen and and let’s 
work with that.

Instead of pointing fingers, let’s try to focus on the technical reasons for 
refactoring and figuring out how and where refactoring should be done (if at 
all). If a refactor breaks my app(s), I’ll deal with it. But, let’s please 
first come to an agreement on what is best to do on technical merit.

I’m making an effort to be quiet now to get input from others. I think I’ve 
already said pretty much what I’ve had to say.

If you want my response on specific points, please let me know and I’ll respond 
to them.

Thanks,
Harbs

> On May 10, 2018, at 9:01 PM, Carlos Rovira  wrote:
> 
> Hi Alex,
> 
> 2018-05-10 18:50 GMT+02:00 Alex Harui  >:
> 
>> Wow!  Good thing I slept through this...
>> 
>> Let's try to calm things down a bit.  I think we have agreement that this
>> work should have been handled differently, but I really think this
>> disagreement, like many disagreements is being escalated by poor
>> communication.  Sometimes it is hard to realize that you haven't really
>> explained yourself well.  You know the problem so well, and are probably
>> trying to write a shorter email and/or have limited time to write, but it
>> makes things worse instead of better.
>> 
> 
> I don't really think communication was bad. I'm in this project and FlexJS
> form its beginning and I think I follow it always and I think my thinking
> about what is basic was right. My opinion about this refactor, is that
> maybe I did  huge commit and for such commit I should be done some
> emailing, but other time we all commit without asking, so while it would be
> better, really I didn't do nothing bad, but maybe wanting to make this
> project advance as fast as possible.
> 
> Then as a refactor like this suppose changes in applications that use the
> framework, Harbs instead of think in the positive thing of remove
> dependencies between libraries, was worried about his application not
> compiling. And here we are 86 emails asserting that we are not
> understanding right the essence of Core and Basic. And what I think is that
> team mates here instead of work for continue moving things to make this
> project progress are trying to divert the attention talking about
> philosophical point of view, and I think the refactor gets technical things
> done clearly (separation and less size), while the philosophical seems more
> to me in stay in what we had and not wanting to move due to applications
> breaking. I'll understand that position with a framework more finished, but
> in a 0.9.3 version, I think we have room, and we discussed a lot of this in
> the past weeks, but I think many of the people not agreeing was the same
> that didn't follow that discussion and now they think all this is wrong,
> again due to personal interests.
> 
> As I did the refactor I was very close to the email to see if something was
> broken, since although maven was ok in all aspect, I though something more
> could be happen, and as you all see I was hard working to fix things as
> people let me know. But what I think is a bad practice in a project is
> talking about revert unilaterally a huge work that had many hours behind,
> since I'll never dare to propose something like this. Moreover when we all
> can have all the things we want at the same time. Or I don't see any
> overlapping interest here.
> 
> 
> 
>> 
>> So, couple of things to consider (actually more than a couple of things):
>> 
>> -I still think we are missing a clear, detailed, technical analysis of the
>> claim of less code linked in by not having a dependency on Basic.  For
>> sure, if you subclass a Basic component, you will get many more things
>> linked in, but I hope that using a bead from Basic does not result in lots
>> of additional unused classes.  If it does, that is probably worth fixing.
>> Carlos, since this is your claim, please provide the data.  Include a bead
>> from Basic and tell us what additional classes were added.
>> 
> 
> Alex, I didn't say that a bead from Basic will link additional classes,
> what I say is that linking Basic was inserting 40% of more size, while apps
> work the same. Let me first ask about what's the point on doing this? I
> have clear that Jewel doesn't need to depend on Basic since cover the 

Re: Container change

[Carlos Rovira]

Hi Alex,

2018-05-10 18:50 GMT+02:00 Alex Harui :

> Wow!  Good thing I slept through this...
>
> Let's try to calm things down a bit.  I think we have agreement that this
> work should have been handled differently, but I really think this
> disagreement, like many disagreements is being escalated by poor
> communication.  Sometimes it is hard to realize that you haven't really
> explained yourself well.  You know the problem so well, and are probably
> trying to write a shorter email and/or have limited time to write, but it
> makes things worse instead of better.
>

I don't really think communication was bad. I'm in this project and FlexJS
form its beginning and I think I follow it always and I think my thinking
about what is basic was right. My opinion about this refactor, is that
maybe I did  huge commit and for such commit I should be done some
emailing, but other time we all commit without asking, so while it would be
better, really I didn't do nothing bad, but maybe wanting to make this
project advance as fast as possible.

Then as a refactor like this suppose changes in applications that use the
framework, Harbs instead of think in the positive thing of remove
dependencies between libraries, was worried about his application not
compiling. And here we are 86 emails asserting that we are not
understanding right the essence of Core and Basic. And what I think is that
team mates here instead of work for continue moving things to make this
project progress are trying to divert the attention talking about
philosophical point of view, and I think the refactor gets technical things
done clearly (separation and less size), while the philosophical seems more
to me in stay in what we had and not wanting to move due to applications
breaking. I'll understand that position with a framework more finished, but
in a 0.9.3 version, I think we have room, and we discussed a lot of this in
the past weeks, but I think many of the people not agreeing was the same
that didn't follow that discussion and now they think all this is wrong,
again due to personal interests.

As I did the refactor I was very close to the email to see if something was
broken, since although maven was ok in all aspect, I though something more
could be happen, and as you all see I was hard working to fix things as
people let me know. But what I think is a bad practice in a project is
talking about revert unilaterally a huge work that had many hours behind,
since I'll never dare to propose something like this. Moreover when we all
can have all the things we want at the same time. Or I don't see any
overlapping interest here.



>
> So, couple of things to consider (actually more than a couple of things):
>
> -I still think we are missing a clear, detailed, technical analysis of the
> claim of less code linked in by not having a dependency on Basic.  For
> sure, if you subclass a Basic component, you will get many more things
> linked in, but I hope that using a bead from Basic does not result in lots
> of additional unused classes.  If it does, that is probably worth fixing.
> Carlos, since this is your claim, please provide the data.  Include a bead
> from Basic and tell us what additional classes were added.
>

Alex, I didn't say that a bead from Basic will link additional classes,
what I say is that linking Basic was inserting 40% of more size, while apps
work the same. Let me first ask about what's the point on doing this? I
have clear that Jewel doesn't need to depend on Basic since cover the same
things, since for me both are UI sets, only that Basic was the library more
developed since until now was the focus. For me what Harbs call "building
blocks" are what a UI Set needs to have.


>
> -With composition, a tree/hierarchy of classes becomes much less
> important.  You should be able to mix and match beads from different SWCs
> if they conform to expected interface contracts.  Those
> contracts/interfaces, and a few base implementations of those contracts are
> what is supposed to go in Core (and in the ".core." package.  But the beads
> can go where it organizationally makes sense and it does not make a bead
> "Core" by having some other SWC us it.  Basic beads are supposedly the
> simplest versions that work cross-platform.
>

for example in Basic a concrete bead can add an attribute to a Basic
Component. In Jewel the same bead can solve the problem adding a class to
the positioner. For that reason, normaly Jewel needs its own ecosystem. I
already worked many weeks (and before many months when creating MDL) and
have the experience that others doesn't have here to know the problems I
found, and remember that we discussed some weeks ago about if Jewel will be
better subclassing UIBase instead its counter part control or component in
Basic, and then my conclusion in that thread was that it was better to
subclass UIBase.

Antoher thing is that I don't want a future change in a control in Basic
could introduce a bad 

Re: Container change

[Alex Harui]

Wow!  Good thing I slept through this...

Let's try to calm things down a bit.  I think we have agreement that this work 
should have been handled differently, but I really think this disagreement, 
like many disagreements is being escalated by poor communication.  Sometimes it 
is hard to realize that you haven't really explained yourself well.  You know 
the problem so well, and are probably trying to write a shorter email and/or 
have limited time to write, but it makes things worse instead of better.

So, couple of things to consider (actually more than a couple of things):

-I still think we are missing a clear, detailed, technical analysis of the 
claim of less code linked in by not having a dependency on Basic.  For sure, if 
you subclass a Basic component, you will get many more things linked in, but I 
hope that using a bead from Basic does not result in lots of additional unused 
classes.  If it does, that is probably worth fixing.  Carlos, since this is 
your claim, please provide the data.  Include a bead from Basic and tell us 
what additional classes were added.

-With composition, a tree/hierarchy of classes becomes much less important.  
You should be able to mix and match beads from different SWCs if they conform 
to expected interface contracts.  Those contracts/interfaces, and a few base 
implementations of those contracts are what is supposed to go in Core (and in 
the ".core." package.  But the beads can go where it organizationally makes 
sense and it does not make a bead "Core" by having some other SWC us it.  Basic 
beads are supposedly the simplest versions that work cross-platform.

-If you need to extend a bead, subclassing or utility functions are preferred 
in order to reduce maintenance overhead of having copies of code.

-I still think we are missing a clear, detailed, example of a Jewel bead that 
is a different implementation of a Basic bead that required copying code from 
the Basic bead.

-A good teammate tries to maximize his/her positive impact on the rest of the 
team, and minimize the negative impact, and cares less about personal goals.

So, let's get some real data, and see if we can reach agreement on the 
semantics of what Core is.  Then we can discuss how we'd reorganize the SWCs.

Thanks,
-Alex


On 5/10/18, 7:09 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Harbs

2018-05-10 15:55 GMT+02:00 Harbs :

> Carlos,
>
> It’s impossible to move the entire Basic (non-components) into Core.
> Besides the fact that there’s no reason to inflate Core that much, there’s
> many pieces (in beads, renderers, etc.) which rely on things which are
> *not* Core.
>
> Core has 0 dependencies on other projects (except Language — I think).
> Many pieces of Basic have dependencies on other pieces such as 
Collections,
> Binding, Network, etc.
>
> Ideally, the library swcs should be as small as possible. You are
> proposing making Core bigger. I oppose that idea. Basic is quite large. I
> would support an idea of breaking Basic into smaller pieces although I 
have
> higher priority things on my list personally.
>

I really prefer to stick like its now and simple fix the JSOnly build. I
think is the fastest thing we can do. I was talking about this since you
propose to break basic in two. and maybe is not needed at least at this
time. If I continue to work on Jewel and find more things that I need from
Basic (and that should be basic we can talk about that)


>
> When Alex and others have been saying that Basic is just another component
> set, I believe that was just referring to the components in Basic. The
> building blocks in Basic are another story altogether. The vast majority 
of
> Basic is the building blocks and not the components. If folks like the 
idea
> of moving the Basic components into their own swc, that’s something I’d
> support. Moving building blocks into Core to prevent dependencies is *not*
> something I support. Your refactor is by no means comprehensive and I 
don’t
> want to go down the path of making it so.
>

but not doing so will left the Jewel project again with the same problems,
just because you have a philosophical point of view. Since in this concrete
point, mine is technical in its totality.


>
> You also changed package names and that deserves a separate discussion. If
> changing the package names makes things clearer, I’d support that. I’m not
> sure that it does. Besides moving things from html to core, you removed
> beads from package names. Many pieces still have the html path and there’s
> currently no consistency that I can see.
>

package names can be reverted, I think that's not completely needed. I did
to avoid the actual 

Re: Container change

[Carlos Rovira]

Hi Harbs

2018-05-10 15:55 GMT+02:00 Harbs :

> Carlos,
>
> It’s impossible to move the entire Basic (non-components) into Core.
> Besides the fact that there’s no reason to inflate Core that much, there’s
> many pieces (in beads, renderers, etc.) which rely on things which are
> *not* Core.
>
> Core has 0 dependencies on other projects (except Language — I think).
> Many pieces of Basic have dependencies on other pieces such as Collections,
> Binding, Network, etc.
>
> Ideally, the library swcs should be as small as possible. You are
> proposing making Core bigger. I oppose that idea. Basic is quite large. I
> would support an idea of breaking Basic into smaller pieces although I have
> higher priority things on my list personally.
>

I really prefer to stick like its now and simple fix the JSOnly build. I
think is the fastest thing we can do. I was talking about this since you
propose to break basic in two. and maybe is not needed at least at this
time. If I continue to work on Jewel and find more things that I need from
Basic (and that should be basic we can talk about that)


>
> When Alex and others have been saying that Basic is just another component
> set, I believe that was just referring to the components in Basic. The
> building blocks in Basic are another story altogether. The vast majority of
> Basic is the building blocks and not the components. If folks like the idea
> of moving the Basic components into their own swc, that’s something I’d
> support. Moving building blocks into Core to prevent dependencies is *not*
> something I support. Your refactor is by no means comprehensive and I don’t
> want to go down the path of making it so.
>

but not doing so will left the Jewel project again with the same problems,
just because you have a philosophical point of view. Since in this concrete
point, mine is technical in its totality.


>
> You also changed package names and that deserves a separate discussion. If
> changing the package names makes things clearer, I’d support that. I’m not
> sure that it does. Besides moving things from html to core, you removed
> beads from package names. Many pieces still have the html path and there’s
> currently no consistency that I can see.
>

package names can be reverted, I think that's not completely needed. I did
to avoid the actual mess of "core" and "html" packages around Basic and
Core. My opinion is that Core should have only "core" package and Basic
should have only "basic" (and not "core" nor "html")
But this is not critical for me, and I can live with it, but this rise one
clear thing, that if the build works, you only need to change you
Application in a few places where the package changed. And that should be
possible so Royale has a better organization of packages.



>
> My $0.02,
> Harbs
> > On May 10, 2018, at 4:33 PM, Carlos Rovira 
> wrote:
> >
> > 2018-05-10 14:30 GMT+02:00 Harbs >:
> >
> >> Top posting to make it easier on the eyes:
> >>
> >>> For me 3,5,7 are not something about "philosophy", are pure technical
> >>> structuration of code. If you want to left as is, is because you're
> >> talking
> >>> from an Application ser not from an archictecture point of view or with
> >> the
> >>> team member hat.
> >>
> >> Maybe philosophical was not the best word, but my point remains. Your
> >> arguments are centered around the fact that you believe Basic to be a
> >> component set similar to Jewel. Others have been disagreeing with this
> >> point of view.
> >>
> >> I have been working on the assumption that Core is really bare-bones
> >> functionality which is not directly related to any specific way of
> >> implementing anything.
> >>
> >
> > Until now the concept was that Basic was an UI set, and for that reason
> > HTML was separated, since was the set of html tags like span, h1-h6, div.
> > So Core and Basic words in your understanding wants to refer to the same
> > and if what you want to left in Basic is not UI components, then that
> seems
> > to be Core classes that in fact other sets like Jewel could need, so as I
> > said, I think is better to have one single Core library for all that is
> > core or basic (in the means of core)
> >
> >
> >>
> >> Basic is “core” in the same way that DataBinding, Network Collection,
> etc.
> >> is “core”. The assumption is that almost all applications - no matter
> which
> >> component set is being used will require Basic. To me, Basic means
> “basic
> >> functionality” and not “basic components”. Maybe it was a mistake to
> have
> >> Basic include Components at all because that’s what seems to be causing
> the
> >> disconnect here. I don’t think it’s practical or desirable to move all
> the
> >> “core” pieces of Basic to Core.
> >>
> >
> > notice that "basic functionality" can be easily think about it as "core
> > functionality", I think we are talking about the same.
> >
> >
> >
> >>
>  #2 AFAICT 

Re: Container change

[Harbs]

Carlos,

It’s impossible to move the entire Basic (non-components) into Core. Besides 
the fact that there’s no reason to inflate Core that much, there’s many pieces 
(in beads, renderers, etc.) which rely on things which are *not* Core.

Core has 0 dependencies on other projects (except Language — I think). Many 
pieces of Basic have dependencies on other pieces such as Collections, Binding, 
Network, etc.

Ideally, the library swcs should be as small as possible. You are proposing 
making Core bigger. I oppose that idea. Basic is quite large. I would support 
an idea of breaking Basic into smaller pieces although I have higher priority 
things on my list personally.

When Alex and others have been saying that Basic is just another component set, 
I believe that was just referring to the components in Basic. The building 
blocks in Basic are another story altogether. The vast majority of Basic is the 
building blocks and not the components. If folks like the idea of moving the 
Basic components into their own swc, that’s something I’d support. Moving 
building blocks into Core to prevent dependencies is *not* something I support. 
Your refactor is by no means comprehensive and I don’t want to go down the path 
of making it so.

You also changed package names and that deserves a separate discussion. If 
changing the package names makes things clearer, I’d support that. I’m not sure 
that it does. Besides moving things from html to core, you removed beads from 
package names. Many pieces still have the html path and there’s currently no 
consistency that I can see.

My $0.02,
Harbs
> On May 10, 2018, at 4:33 PM, Carlos Rovira  wrote:
> 
> 2018-05-10 14:30 GMT+02:00 Harbs  >:
> 
>> Top posting to make it easier on the eyes:
>> 
>>> For me 3,5,7 are not something about "philosophy", are pure technical
>>> structuration of code. If you want to left as is, is because you're
>> talking
>>> from an Application ser not from an archictecture point of view or with
>> the
>>> team member hat.
>> 
>> Maybe philosophical was not the best word, but my point remains. Your
>> arguments are centered around the fact that you believe Basic to be a
>> component set similar to Jewel. Others have been disagreeing with this
>> point of view.
>> 
>> I have been working on the assumption that Core is really bare-bones
>> functionality which is not directly related to any specific way of
>> implementing anything.
>> 
> 
> Until now the concept was that Basic was an UI set, and for that reason
> HTML was separated, since was the set of html tags like span, h1-h6, div.
> So Core and Basic words in your understanding wants to refer to the same
> and if what you want to left in Basic is not UI components, then that seems
> to be Core classes that in fact other sets like Jewel could need, so as I
> said, I think is better to have one single Core library for all that is
> core or basic (in the means of core)
> 
> 
>> 
>> Basic is “core” in the same way that DataBinding, Network Collection, etc.
>> is “core”. The assumption is that almost all applications - no matter which
>> component set is being used will require Basic. To me, Basic means “basic
>> functionality” and not “basic components”. Maybe it was a mistake to have
>> Basic include Components at all because that’s what seems to be causing the
>> disconnect here. I don’t think it’s practical or desirable to move all the
>> “core” pieces of Basic to Core.
>> 
> 
> notice that "basic functionality" can be easily think about it as "core
> functionality", I think we are talking about the same.
> 
> 
> 
>> 
 #2 AFAICT includes #4. As I mentioned the fact that there can be
 conflicting typenames is a problem. Removing Basic as a dependency will
>> not
 solve that problem because clients can (and likely will) bring in Basic
>> as
 part of their application.
 
>>> 
>>> There's much difference in obligation to link a library and decision to
>>> make part of your solution. We as Royale PMCs should make the best for
>> not
>>> obligate, the user is how could want then to use Jewel, MDL and Basic all
>>> together. Is up to them.
>> 
>> I’m not sure what you are trying to say here. My point is that an
>> application bringing in Basic should not cause Jewel components to break. I
>> assume you’d agree with me on that.
>> 
> 
> I agree that If I link Basic that should not make a difference.
> But the point is that not only makes a difference linking things I don't
> want, but that I'm obligated to link that library, and I shouldn't since
> right now Basic is more than a Core library is a library that has core+ui
> components+css, so that is completely wrong by design.
> 
> 
>> 
 I really don’t understand your point with #6. Why do application
 developers need to think about dependencies? Is it because of Maven
 dependencies? If so, that seems to be a Maven problem which should be
>> 

Re: Container change

[Carlos Rovira]

2018-05-10 14:30 GMT+02:00 Harbs :

> Top posting to make it easier on the eyes:
>
> > For me 3,5,7 are not something about "philosophy", are pure technical
> > structuration of code. If you want to left as is, is because you're
> talking
> > from an Application ser not from an archictecture point of view or with
> the
> > team member hat.
>
> Maybe philosophical was not the best word, but my point remains. Your
> arguments are centered around the fact that you believe Basic to be a
> component set similar to Jewel. Others have been disagreeing with this
> point of view.
>
> I have been working on the assumption that Core is really bare-bones
> functionality which is not directly related to any specific way of
> implementing anything.
>

Until now the concept was that Basic was an UI set, and for that reason
HTML was separated, since was the set of html tags like span, h1-h6, div.
So Core and Basic words in your understanding wants to refer to the same
and if what you want to left in Basic is not UI components, then that seems
to be Core classes that in fact other sets like Jewel could need, so as I
said, I think is better to have one single Core library for all that is
core or basic (in the means of core)


>
> Basic is “core” in the same way that DataBinding, Network Collection, etc.
> is “core”. The assumption is that almost all applications - no matter which
> component set is being used will require Basic. To me, Basic means “basic
> functionality” and not “basic components”. Maybe it was a mistake to have
> Basic include Components at all because that’s what seems to be causing the
> disconnect here. I don’t think it’s practical or desirable to move all the
> “core” pieces of Basic to Core.
>

notice that "basic functionality" can be easily think about it as "core
functionality", I think we are talking about the same.



>
> >> #2 AFAICT includes #4. As I mentioned the fact that there can be
> >> conflicting typenames is a problem. Removing Basic as a dependency will
> not
> >> solve that problem because clients can (and likely will) bring in Basic
> as
> >> part of their application.
> >>
> >
> > There's much difference in obligation to link a library and decision to
> > make part of your solution. We as Royale PMCs should make the best for
> not
> > obligate, the user is how could want then to use Jewel, MDL and Basic all
> > together. Is up to them.
>
> I’m not sure what you are trying to say here. My point is that an
> application bringing in Basic should not cause Jewel components to break. I
> assume you’d agree with me on that.
>

I agree that If I link Basic that should not make a difference.
But the point is that not only makes a difference linking things I don't
want, but that I'm obligated to link that library, and I shouldn't since
right now Basic is more than a Core library is a library that has core+ui
components+css, so that is completely wrong by design.


>
> >> I really don’t understand your point with #6. Why do application
> >> developers need to think about dependencies? Is it because of Maven
> >> dependencies? If so, that seems to be a Maven problem which should be
> fixed
> >> there.
> >>
> >
> > Not App developers, We are how need to be careful on this. In the same
> way
> > we are pushing hard on PAYG, to avoid mistake of the past like 15k lines
> > UIComponent class, We need to always be careful and don't make unneeded
> > relations. And Basic -Jewel is totally unneeded.
>
> Well, Basic *was* needed before you made your changes and the assumption
> is that it usually *will* be needed because it’s the basic building blocks
> of applications. Moving things to Core as component sets need them seems
> like a bad thing to do. Why do we need to be careful about including Basic?
> This seems more like a philosophical argument than a technical one.
>

I found in my refactor that many examples have Basic dependency missing ( I
think that can be mainly the problem with JSONLY build failing), that was
due to HTML pulling Basic. That means that the build was a wrong
configuration and as HTML left away its Basic dependency projects that
really need Basic was failing, so I added it specifically. So here there's
nothing philosophical, but a problem about structure and organizations.


>
> >>
> >> Please explain why you think $8 is true. What about the refactoring will
> >> reduce the size of applications?
> >>
> >
> > I explained just in a Yshay response. copying the entire email response
> > here. But rather to make me repeat or copy I though you read all this
> > thread carefully:
>
> OK. So this goes back to the CSS. I thought you were talking about code.
>
> I already agreed with you that unnecessary copying of CSS is bad. I just
> think it’s something which should be solved in the compiler. Can you think
> of a reason why it can’t/shouldn’t be a compiler problem?
>

As I said in my explanation to Yishay, before the refactor I was using the
"building blocks" in 

Re: Container change

[Harbs]

Top posting to make it easier on the eyes:

> For me 3,5,7 are not something about "philosophy", are pure technical
> structuration of code. If you want to left as is, is because you're talking
> from an Application ser not from an archictecture point of view or with the
> team member hat.

Maybe philosophical was not the best word, but my point remains. Your arguments 
are centered around the fact that you believe Basic to be a component set 
similar to Jewel. Others have been disagreeing with this point of view.

I have been working on the assumption that Core is really bare-bones 
functionality which is not directly related to any specific way of implementing 
anything.

Basic is “core” in the same way that DataBinding, Network Collection, etc. is 
“core”. The assumption is that almost all applications - no matter which 
component set is being used will require Basic. To me, Basic means “basic 
functionality” and not “basic components”. Maybe it was a mistake to have Basic 
include Components at all because that’s what seems to be causing the 
disconnect here. I don’t think it’s practical or desirable to move all the 
“core” pieces of Basic to Core.

>> #2 AFAICT includes #4. As I mentioned the fact that there can be
>> conflicting typenames is a problem. Removing Basic as a dependency will not
>> solve that problem because clients can (and likely will) bring in Basic as
>> part of their application.
>> 
> 
> There's much difference in obligation to link a library and decision to
> make part of your solution. We as Royale PMCs should make the best for not
> obligate, the user is how could want then to use Jewel, MDL and Basic all
> together. Is up to them.

I’m not sure what you are trying to say here. My point is that an application 
bringing in Basic should not cause Jewel components to break. I assume you’d 
agree with me on that.

>> I really don’t understand your point with #6. Why do application
>> developers need to think about dependencies? Is it because of Maven
>> dependencies? If so, that seems to be a Maven problem which should be fixed
>> there.
>> 
> 
> Not App developers, We are how need to be careful on this. In the same way
> we are pushing hard on PAYG, to avoid mistake of the past like 15k lines
> UIComponent class, We need to always be careful and don't make unneeded
> relations. And Basic -Jewel is totally unneeded.

Well, Basic *was* needed before you made your changes and the assumption is 
that it usually *will* be needed because it’s the basic building blocks of 
applications. Moving things to Core as component sets need them seems like a 
bad thing to do. Why do we need to be careful about including Basic? This seems 
more like a philosophical argument than a technical one.

>> 
>> Please explain why you think $8 is true. What about the refactoring will
>> reduce the size of applications?
>> 
> 
> I explained just in a Yshay response. copying the entire email response
> here. But rather to make me repeat or copy I though you read all this
> thread carefully:

OK. So this goes back to the CSS. I thought you were talking about code.

I already agreed with you that unnecessary copying of CSS is bad. I just think 
it’s something which should be solved in the compiler. Can you think of a 
reason why it can’t/shouldn’t be a compiler problem?

Thanks,
Harbs

> On May 10, 2018, at 3:02 PM, Carlos Rovira  wrote:
> 
> 2018-05-10 13:41 GMT+02:00 Harbs  >:
> 
>> Hi Carlos,
>> 
>> Thank you for summarizing your reasons. I appreciate it.
>> 
>> Please allow me to categorize your reasons. Please let me know if I’m not
>> categorizing them correctly.
>> 
>> When I mentioned reason #1, I think it includes:
>> #3, #5 and #7
>> 
> 
> For me 3,5,7 are not something about "philosophy", are pure technical
> structuration of code. If you want to left as is, is because you're talking
> from an Application ser not from an archictecture point of view or with the
> team member hat.
> 
> 
>> 
>> #2 AFAICT includes #4. As I mentioned the fact that there can be
>> conflicting typenames is a problem. Removing Basic as a dependency will not
>> solve that problem because clients can (and likely will) bring in Basic as
>> part of their application.
>> 
> 
> There's much difference in obligation to link a library and decision to
> make part of your solution. We as Royale PMCs should make the best for not
> obligate, the user is how could want then to use Jewel, MDL and Basic all
> together. Is up to them.
> 
> 
>> 
>> I really don’t understand your point with #6. Why do application
>> developers need to think about dependencies? Is it because of Maven
>> dependencies? If so, that seems to be a Maven problem which should be fixed
>> there.
>> 
> 
> Not App developers, We are how need to be careful on this. In the same way
> we are pushing hard on PAYG, to avoid mistake of the past like 15k lines
> UIComponent class, We need to always 

Re: Container change

[Carlos Rovira]

Harbs,

I think your proposal is the same like putting classes on Core and left
Basic with components.
In your proposal people will need to link Core+Basic and people using basic
components will link BasicComponents.
but that's the same that I did just that Core is like Core+Basic, if we
think that what I put from Basic into Core was really core, that
was gran part of the conversations with Alex through this weeks.

I think we'll get less headaches if we have only Core than split into two,
since if folks needs all those classes, they'll need to link all...and so
that's fits better for me under the name "Core".




2018-05-10 13:47 GMT+02:00 Harbs :

> FWIW, If you were proposing to pull the Basic components out into a
> separate swc instead of moving the building blocks into Core, that would
> make more sense to me.
>
> (i.e. We could have Basic.swc which would be the building block and
> BasicComponents.swc which would contain just the actual components (i..e
> Button, Label, List etc.) The conflicting CSS would go in there.)
>
> As I mentioned I think the CSS problem is something which needs to be
> solved independent of the refactor.
>
> My $0.02,
> Harbs
>
> > On May 10, 2018, at 2:41 PM, Harbs  wrote:
> >
> > Hi Carlos,
> >
> > Thank you for summarizing your reasons. I appreciate it.
> >
> > Please allow me to categorize your reasons. Please let me know if I’m
> not categorizing them correctly.
> >
> > When I mentioned reason #1, I think it includes:
> > #3, #5 and #7
> >
> > #2 AFAICT includes #4. As I mentioned the fact that there can be
> conflicting typenames is a problem. Removing Basic as a dependency will not
> solve that problem because clients can (and likely will) bring in Basic as
> part of their application.
> >
> > I really don’t understand your point with #6. Why do application
> developers need to think about dependencies? Is it because of Maven
> dependencies? If so, that seems to be a Maven problem which should be fixed
> there.
> >
> > Please explain why you think $8 is true. What about the refactoring will
> reduce the size of applications?
> >
> > As I mentioned earlier, Basic is not simply a component set. It’s also a
> set of building-blocks which can and should be used in other component
> sets. Devision between Core and Basic is not as clear-cut as you seem to be
> asserting that it is. After your refactor the building blocks seem to be
> split between Core and Basic.
> >
> > Thanks,
> > Harbs
> >
> >> On May 10, 2018, at 2:13 PM, Carlos Rovira 
> wrote:
> >>
> >> Hi Harbs
> >>
> >> after 75 emails on this thread, understand that I don't want to again
> write
> >> it, since this is making me waste lots of time in this discussion.
> >>
> >> 3) Having the need to link a library that should not be used, is that
> >> something is wrong, so it's not about 1) it's about things are not
> setting
> >> correctly, and this refactor tries to fix that at least to put a point
> in
> >> wich we can make things better.
> >> 4) aside 2, some classes are linked via CSS as well (Application, Group,
> >> Container, Button, Slider, and many more
> >> 5) Having Basic to be a core dependency, makes it Core in itself, so why
> >> the separation Core- Basic if I'm obligated to link it?
> >> 6) Making Basic not present in libraries that doesn't need it, makes
> people
> >> obligated by design to avoid extend Basic classes making the effect but
> >> time that things mess between libraries, and obligates SDK developers to
> >> think about the using of classes, since if we need some, maybe that
> will be
> >> Core and not Basic
> >> 7) Basic is only another UI set at the same level or sibling like Jewel,
> >> MDL, CreateJS, Flat, and more we want to do, until now was very needed,
> but
> >> if we want to make Royale to serve general purpose, making it to be
> present
> >> always is not the right way to go.
> >> 8) reduced size in final jewel applications.
> >>
> >> I think for sure I put more things on the plate, but can't invest now
> the
> >> time to go all 75 emails to retrieve it
> >>
> >>
> >>
> >> 2018-05-10 12:48 GMT+02:00 Harbs :
> >>
> >>> The only reasons I seem to have seen are:
> >>> 1. A philosophical opposition to having Basic as a dependency.
> >>> 2. Not wanting Basic CSS included in a Jewel project.
> >>>
> >>> Unless I’m missing something, #1 I simply disagree with.
> >>> #2 sounds like a valid argument, but it seems to me more like something
> >>> which needs to be fixed in the compiler. CSS not used by an app should
> not
> >>> be included and I think we need a way of avoiding typename conflicts
> >>> between component sets.
> >>>
> >>> Are there other arguments which I missed?
> >>>
> >>> Since Carlos does not seem to want to explain himself again, I’m asking
> >>> others on the list:
> >>>
> >>> Do others understand why Carlos feels the refactor is important?
> >>>
> >>> Thanks,
> >>> Harbs

Re: Container change

[Carlos Rovira]

2018-05-10 13:41 GMT+02:00 Harbs :

> Hi Carlos,
>
> Thank you for summarizing your reasons. I appreciate it.
>
> Please allow me to categorize your reasons. Please let me know if I’m not
> categorizing them correctly.
>
> When I mentioned reason #1, I think it includes:
> #3, #5 and #7
>

For me 3,5,7 are not something about "philosophy", are pure technical
structuration of code. If you want to left as is, is because you're talking
from an Application ser not from an archictecture point of view or with the
team member hat.


>
> #2 AFAICT includes #4. As I mentioned the fact that there can be
> conflicting typenames is a problem. Removing Basic as a dependency will not
> solve that problem because clients can (and likely will) bring in Basic as
> part of their application.
>

There's much difference in obligation to link a library and decision to
make part of your solution. We as Royale PMCs should make the best for not
obligate, the user is how could want then to use Jewel, MDL and Basic all
together. Is up to them.


>
> I really don’t understand your point with #6. Why do application
> developers need to think about dependencies? Is it because of Maven
> dependencies? If so, that seems to be a Maven problem which should be fixed
> there.
>

Not App developers, We are how need to be careful on this. In the same way
we are pushing hard on PAYG, to avoid mistake of the past like 15k lines
UIComponent class, We need to always be careful and don't make unneeded
relations. And Basic -Jewel is totally unneeded.


>
> Please explain why you think $8 is true. What about the refactoring will
> reduce the size of applications?
>

I explained just in a Yshay response. copying the entire email response
here. But rather to make me repeat or copy I though you read all this
thread carefully:

"I think the problem is that Basic UI set links things through CSS, so If I
have Application, Group, View, Button all this components and more has CSS
that links beads (ViewBeads, ModelBeads, ControllerBeads, and more)

In Jewel until the refactor the components where sublcassing Basic ones,
and this made all this classes go in the Jewel Application, and that not
only introduced more size but makes the behaviour unexpected since I find
css styles and linked classes modifying the Jewel Behavior.

Now that Jewel is not depending on Basic anymore, since it should be, all
works perfect.

I think this is key, in a tree graph we should envision, Core as the root
of the tree, and when coming to UI sets that in royale we coincide in
having many of them, one should not depend from the other. And by design
that's important, and will prevent people in the future to come back to
make relations between them. In fact Alex, said many times the errors
coming from 15k lines of code in UIComponent in Flex. If we left UI sets
depend at library level, people can start to make that kind of extension,
and that should not be doable by design."



>
> As I mentioned earlier, Basic is not simply a component set. It’s also a
> set of building-blocks which can and should be used in other component
> sets. Devision between Core and Basic is not as clear-cut as you seem to be
> asserting that it is. After your refactor the building blocks seem to be
> split between Core and Basic.
>

That's not what I talked in the past in this mailing list. Alex said that
people would want to use Basic for things very basic and more complex UI
sets for other things. In fact Jewel born to be more visual attractive, so
for Jewel, all building block regarding UI should be from itself, and
prevent to mix with things in Basic that will (or could) evolve in other
way.

My refactor was searching a goal, separation. But as many things can not be
final. After it, we can think a bit more on how things are settle now, and
continue to improve it, to make Core real core, and Basic a UI set that
could be has it's own essence without make it to mix in other libraries
that should not need it.
I think we should continue improving this instead of wanting again to have
a mess between all this libraries and packages mixed in libraries like core
and html.

But for this to happen, we must focus in why the JSONLY build is different
from the main one, and if ANT fails, that shouldn't, that I'm still don't
know if we have a problem there

thanks



>
> Thanks,
> Harbs
>
> > On May 10, 2018, at 2:13 PM, Carlos Rovira 
> wrote:
> >
> > Hi Harbs
> >
> > after 75 emails on this thread, understand that I don't want to again
> write
> > it, since this is making me waste lots of time in this discussion.
> >
> > 3) Having the need to link a library that should not be used, is that
> > something is wrong, so it's not about 1) it's about things are not
> setting
> > correctly, and this refactor tries to fix that at least to put a point in
> > wich we can make things better.
> > 4) aside 2, some classes are linked via CSS as well (Application, Group,
> > 

Re: Container change

[Harbs]

FWIW, If you were proposing to pull the Basic components out into a separate 
swc instead of moving the building blocks into Core, that would make more sense 
to me.

(i.e. We could have Basic.swc which would be the building block and 
BasicComponents.swc which would contain just the actual components (i..e 
Button, Label, List etc.) The conflicting CSS would go in there.)

As I mentioned I think the CSS problem is something which needs to be solved 
independent of the refactor.

My $0.02,
Harbs

> On May 10, 2018, at 2:41 PM, Harbs  wrote:
> 
> Hi Carlos,
> 
> Thank you for summarizing your reasons. I appreciate it.
> 
> Please allow me to categorize your reasons. Please let me know if I’m not 
> categorizing them correctly.
> 
> When I mentioned reason #1, I think it includes:
> #3, #5 and #7
> 
> #2 AFAICT includes #4. As I mentioned the fact that there can be conflicting 
> typenames is a problem. Removing Basic as a dependency will not solve that 
> problem because clients can (and likely will) bring in Basic as part of their 
> application.
> 
> I really don’t understand your point with #6. Why do application developers 
> need to think about dependencies? Is it because of Maven dependencies? If so, 
> that seems to be a Maven problem which should be fixed there.
> 
> Please explain why you think $8 is true. What about the refactoring will 
> reduce the size of applications?
> 
> As I mentioned earlier, Basic is not simply a component set. It’s also a set 
> of building-blocks which can and should be used in other component sets. 
> Devision between Core and Basic is not as clear-cut as you seem to be 
> asserting that it is. After your refactor the building blocks seem to be 
> split between Core and Basic.
> 
> Thanks,
> Harbs
> 
>> On May 10, 2018, at 2:13 PM, Carlos Rovira  wrote:
>> 
>> Hi Harbs
>> 
>> after 75 emails on this thread, understand that I don't want to again write
>> it, since this is making me waste lots of time in this discussion.
>> 
>> 3) Having the need to link a library that should not be used, is that
>> something is wrong, so it's not about 1) it's about things are not setting
>> correctly, and this refactor tries to fix that at least to put a point in
>> wich we can make things better.
>> 4) aside 2, some classes are linked via CSS as well (Application, Group,
>> Container, Button, Slider, and many more
>> 5) Having Basic to be a core dependency, makes it Core in itself, so why
>> the separation Core- Basic if I'm obligated to link it?
>> 6) Making Basic not present in libraries that doesn't need it, makes people
>> obligated by design to avoid extend Basic classes making the effect but
>> time that things mess between libraries, and obligates SDK developers to
>> think about the using of classes, since if we need some, maybe that will be
>> Core and not Basic
>> 7) Basic is only another UI set at the same level or sibling like Jewel,
>> MDL, CreateJS, Flat, and more we want to do, until now was very needed, but
>> if we want to make Royale to serve general purpose, making it to be present
>> always is not the right way to go.
>> 8) reduced size in final jewel applications.
>> 
>> I think for sure I put more things on the plate, but can't invest now the
>> time to go all 75 emails to retrieve it
>> 
>> 
>> 
>> 2018-05-10 12:48 GMT+02:00 Harbs :
>> 
>>> The only reasons I seem to have seen are:
>>> 1. A philosophical opposition to having Basic as a dependency.
>>> 2. Not wanting Basic CSS included in a Jewel project.
>>> 
>>> Unless I’m missing something, #1 I simply disagree with.
>>> #2 sounds like a valid argument, but it seems to me more like something
>>> which needs to be fixed in the compiler. CSS not used by an app should not
>>> be included and I think we need a way of avoiding typename conflicts
>>> between component sets.
>>> 
>>> Are there other arguments which I missed?
>>> 
>>> Since Carlos does not seem to want to explain himself again, I’m asking
>>> others on the list:
>>> 
>>> Do others understand why Carlos feels the refactor is important?
>>> 
>>> Thanks,
>>> Harbs
>>> 
 On May 10, 2018, at 1:32 PM, Carlos Rovira 
>>> wrote:
 
> Can we please keep this discussion about the technical reasons for a
> refactor and whether or not it’s the right thing to do? If you have
>>> strong
> technical reasons why Basic should not be a dependency please explain
>>> them.
> 
 
 Harbs, I'll explained lots of time, and you keep ask the same. What did
>>> you
 not understand of the things I expressed so many time?
>>> 
>>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> http://about.me/carlosrovira
> 

Re: Container change

[Carlos Rovira]

2.- Is not right.

The classes copied, will have another implementation for Jewel purposes,
and others are concrete implementations that every UI set should have since
the base clase is in Core (and eventually could as well follow is own
implementation path).


2018-05-10 13:39 GMT+02:00 Piotr Zarzycki :

>  Harbs,
>
> Here is how I understand that :
> 1. It supposed to be easier maintain if Jewel will be without basic.
> 2. Less code in particular classes copied from Basic.
> 3. It seems to be less size when Basic is outside.
>
> The understand what actually Basic is coming from the point when you really
> write some real world application. Then you realize that is not only UI
> library.
>
> Does that enough to make such a bit changes ? Is it really necessary. Is it
> a technical reasons ?
>
> Piotr
>
>
> 2018-05-10 12:48 GMT+02:00 Harbs :
>
> > The only reasons I seem to have seen are:
> > 1. A philosophical opposition to having Basic as a dependency.
> > 2. Not wanting Basic CSS included in a Jewel project.
> >
> > Unless I’m missing something, #1 I simply disagree with.
> > #2 sounds like a valid argument, but it seems to me more like something
> > which needs to be fixed in the compiler. CSS not used by an app should
> not
> > be included and I think we need a way of avoiding typename conflicts
> > between component sets.
> >
> > Are there other arguments which I missed?
> >
> > Since Carlos does not seem to want to explain himself again, I’m asking
> > others on the list:
> >
> > Do others understand why Carlos feels the refactor is important?
> >
> > Thanks,
> > Harbs
> >
> > > On May 10, 2018, at 1:32 PM, Carlos Rovira 
> > wrote:
> > >
> > >> Can we please keep this discussion about the technical reasons for a
> > >> refactor and whether or not it’s the right thing to do? If you have
> > strong
> > >> technical reasons why Basic should not be a dependency please explain
> > them.
> > >>
> > >
> > > Harbs, I'll explained lots of time, and you keep ask the same. What did
> > you
> > > not understand of the things I expressed so many time?
> >
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

Hi Carlos,

Thank you for summarizing your reasons. I appreciate it.

Please allow me to categorize your reasons. Please let me know if I’m not 
categorizing them correctly.

When I mentioned reason #1, I think it includes:
#3, #5 and #7

#2 AFAICT includes #4. As I mentioned the fact that there can be conflicting 
typenames is a problem. Removing Basic as a dependency will not solve that 
problem because clients can (and likely will) bring in Basic as part of their 
application.

I really don’t understand your point with #6. Why do application developers 
need to think about dependencies? Is it because of Maven dependencies? If so, 
that seems to be a Maven problem which should be fixed there.

Please explain why you think $8 is true. What about the refactoring will reduce 
the size of applications?

As I mentioned earlier, Basic is not simply a component set. It’s also a set of 
building-blocks which can and should be used in other component sets. Devision 
between Core and Basic is not as clear-cut as you seem to be asserting that it 
is. After your refactor the building blocks seem to be split between Core and 
Basic.

Thanks,
Harbs

> On May 10, 2018, at 2:13 PM, Carlos Rovira  wrote:
> 
> Hi Harbs
> 
> after 75 emails on this thread, understand that I don't want to again write
> it, since this is making me waste lots of time in this discussion.
> 
> 3) Having the need to link a library that should not be used, is that
> something is wrong, so it's not about 1) it's about things are not setting
> correctly, and this refactor tries to fix that at least to put a point in
> wich we can make things better.
> 4) aside 2, some classes are linked via CSS as well (Application, Group,
> Container, Button, Slider, and many more
> 5) Having Basic to be a core dependency, makes it Core in itself, so why
> the separation Core- Basic if I'm obligated to link it?
> 6) Making Basic not present in libraries that doesn't need it, makes people
> obligated by design to avoid extend Basic classes making the effect but
> time that things mess between libraries, and obligates SDK developers to
> think about the using of classes, since if we need some, maybe that will be
> Core and not Basic
> 7) Basic is only another UI set at the same level or sibling like Jewel,
> MDL, CreateJS, Flat, and more we want to do, until now was very needed, but
> if we want to make Royale to serve general purpose, making it to be present
> always is not the right way to go.
> 8) reduced size in final jewel applications.
> 
> I think for sure I put more things on the plate, but can't invest now the
> time to go all 75 emails to retrieve it
> 
> 
> 
> 2018-05-10 12:48 GMT+02:00 Harbs :
> 
>> The only reasons I seem to have seen are:
>> 1. A philosophical opposition to having Basic as a dependency.
>> 2. Not wanting Basic CSS included in a Jewel project.
>> 
>> Unless I’m missing something, #1 I simply disagree with.
>> #2 sounds like a valid argument, but it seems to me more like something
>> which needs to be fixed in the compiler. CSS not used by an app should not
>> be included and I think we need a way of avoiding typename conflicts
>> between component sets.
>> 
>> Are there other arguments which I missed?
>> 
>> Since Carlos does not seem to want to explain himself again, I’m asking
>> others on the list:
>> 
>> Do others understand why Carlos feels the refactor is important?
>> 
>> Thanks,
>> Harbs
>> 
>>> On May 10, 2018, at 1:32 PM, Carlos Rovira 
>> wrote:
>>> 
 Can we please keep this discussion about the technical reasons for a
 refactor and whether or not it’s the right thing to do? If you have
>> strong
 technical reasons why Basic should not be a dependency please explain
>> them.
 
>>> 
>>> Harbs, I'll explained lots of time, and you keep ask the same. What did
>> you
>>> not understand of the things I expressed so many time?
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Hi Harbs

after 75 emails on this thread, understand that I don't want to again write
it, since this is making me waste lots of time in this discussion.

3) Having the need to link a library that should not be used, is that
something is wrong, so it's not about 1) it's about things are not setting
correctly, and this refactor tries to fix that at least to put a point in
wich we can make things better.
4) aside 2, some classes are linked via CSS as well (Application, Group,
Container, Button, Slider, and many more
5) Having Basic to be a core dependency, makes it Core in itself, so why
the separation Core- Basic if I'm obligated to link it?
6) Making Basic not present in libraries that doesn't need it, makes people
obligated by design to avoid extend Basic classes making the effect but
time that things mess between libraries, and obligates SDK developers to
think about the using of classes, since if we need some, maybe that will be
Core and not Basic
7) Basic is only another UI set at the same level or sibling like Jewel,
MDL, CreateJS, Flat, and more we want to do, until now was very needed, but
if we want to make Royale to serve general purpose, making it to be present
always is not the right way to go.
8) reduced size in final jewel applications.

I think for sure I put more things on the plate, but can't invest now the
time to go all 75 emails to retrieve it



2018-05-10 12:48 GMT+02:00 Harbs :

> The only reasons I seem to have seen are:
> 1. A philosophical opposition to having Basic as a dependency.
> 2. Not wanting Basic CSS included in a Jewel project.
>
> Unless I’m missing something, #1 I simply disagree with.
> #2 sounds like a valid argument, but it seems to me more like something
> which needs to be fixed in the compiler. CSS not used by an app should not
> be included and I think we need a way of avoiding typename conflicts
> between component sets.
>
> Are there other arguments which I missed?
>
> Since Carlos does not seem to want to explain himself again, I’m asking
> others on the list:
>
> Do others understand why Carlos feels the refactor is important?
>
> Thanks,
> Harbs
>
> > On May 10, 2018, at 1:32 PM, Carlos Rovira 
> wrote:
> >
> >> Can we please keep this discussion about the technical reasons for a
> >> refactor and whether or not it’s the right thing to do? If you have
> strong
> >> technical reasons why Basic should not be a dependency please explain
> them.
> >>
> >
> > Harbs, I'll explained lots of time, and you keep ask the same. What did
> you
> > not understand of the things I expressed so many time?
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

Carlos,

The branch is just a branch. I will gladly throw the branch away once this is 
resolved. What I named the branch is not important.

Whether we revert develop or fix it depends on the outcome of our discussion 
here. You clearly feel that the refactor is the right thing to do and I’m 
perfectly willing to be convinced. But to be convinced you need to do the 
convincing…

We’re not going to come to an agreement on how to move forward until there’s 
consensus on whether to fix the refactor or revert it.

Thanks,
Harbs

> On May 10, 2018, at 1:47 PM, Carlos Rovira  wrote:
> 
> Ok Harbs,
> 
> for me that branch should not be a "reverting" branch, but a way to fix the
> things the refactor causes :
> 
> 1.- JSONLY: I don't know why that build breaks, and how can I test it
> localy. If I know I can help fixing that for sure.
> 
> 2.- ANT: is working or not? doesn't make clear to me. If not works, here I
> prefer the help of the people that controls ANT, since I'm not
> 
> 3.- After all that is working 1 (or 1 & 2, is 2 is break), then your
> application should work without problem in the same way it did.
> 
> So for me this is not a problem of a refactor, this is only showing some
> deficiencies in our build system.
> 
> At the end we should get what you want and what I need to continue Jewel
> working.
> 
> Sorry that this is making so much noise and build breaks, but although I
> admit my mistake in the way I do this, this is arising a problem that was
> sleeping inside our builds.
> 
> If someone let me know how I can try to build JSONLY localy I can see
> what's going on in this maven build, and help (as a team) to fix the actual
> problems.
> 
> thanks
> 
> 
> 
> 2018-05-10 12:40 GMT+02:00 Harbs :
> 
>> The only reverting I did was in a feature branch so I can continue
>> working. I don’t think that’s aggressive at all…
>> 
>> Harbs
>> 
>>> On May 10, 2018, at 1:32 PM, Carlos Rovira 
>> wrote:
>>> 
 
 We’re pushing back on these changes and simply standing your ground and
 claiming others are not being good team members is not fair.
 
>>> 
>>> Harbs, you are doing a very aggressive thing reverting my work. A work
>> that
>>> was done with several hours.
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: Container change

[Harbs]

The only reasons I seem to have seen are:
1. A philosophical opposition to having Basic as a dependency.
2. Not wanting Basic CSS included in a Jewel project.

Unless I’m missing something, #1 I simply disagree with.
#2 sounds like a valid argument, but it seems to me more like something which 
needs to be fixed in the compiler. CSS not used by an app should not be 
included and I think we need a way of avoiding typename conflicts between 
component sets.

Are there other arguments which I missed?

Since Carlos does not seem to want to explain himself again, I’m asking others 
on the list:

Do others understand why Carlos feels the refactor is important?

Thanks,
Harbs

> On May 10, 2018, at 1:32 PM, Carlos Rovira  wrote:
> 
>> Can we please keep this discussion about the technical reasons for a
>> refactor and whether or not it’s the right thing to do? If you have strong
>> technical reasons why Basic should not be a dependency please explain them.
>> 
> 
> Harbs, I'll explained lots of time, and you keep ask the same. What did you
> not understand of the things I expressed so many time?

Re: Container change

[Carlos Rovira]

Ok Harbs,

for me that branch should not be a "reverting" branch, but a way to fix the
things the refactor causes :

1.- JSONLY: I don't know why that build breaks, and how can I test it
localy. If I know I can help fixing that for sure.

2.- ANT: is working or not? doesn't make clear to me. If not works, here I
prefer the help of the people that controls ANT, since I'm not

3.- After all that is working 1 (or 1 & 2, is 2 is break), then your
application should work without problem in the same way it did.

So for me this is not a problem of a refactor, this is only showing some
deficiencies in our build system.

At the end we should get what you want and what I need to continue Jewel
working.

Sorry that this is making so much noise and build breaks, but although I
admit my mistake in the way I do this, this is arising a problem that was
sleeping inside our builds.

If someone let me know how I can try to build JSONLY localy I can see
what's going on in this maven build, and help (as a team) to fix the actual
problems.

thanks



2018-05-10 12:40 GMT+02:00 Harbs :

> The only reverting I did was in a feature branch so I can continue
> working. I don’t think that’s aggressive at all…
>
> Harbs
>
> > On May 10, 2018, at 1:32 PM, Carlos Rovira 
> wrote:
> >
> >>
> >> We’re pushing back on these changes and simply standing your ground and
> >> claiming others are not being good team members is not fair.
> >>
> >
> > Harbs, you are doing a very aggressive thing reverting my work. A work
> that
> > was done with several hours.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

The only reverting I did was in a feature branch so I can continue working. I 
don’t think that’s aggressive at all…

Harbs

> On May 10, 2018, at 1:32 PM, Carlos Rovira  wrote:
> 
>> 
>> We’re pushing back on these changes and simply standing your ground and
>> claiming others are not being good team members is not fair.
>> 
> 
> Harbs, you are doing a very aggressive thing reverting my work. A work that
> was done with several hours.

Re: Container change

[Carlos Rovira]

Harbs,

I think so, for that reason, I don't see nothing good, In me investing all
time a day during latest months, and working hard, and you comming from a
disconnected stated to see that you application is breaking and then making
such agresive thing like to revert the work of a team member. I think
that's not good, and even is like you are doing things for your own
interest instead for the general purpose.

For me this situation is not acceptable at all, and you'll never see me
doing such kind of things.

I don't know why JSONLY build is broken, but seems that something is wrong
in the way it's setup, so I think we should invest time in see what ' going
wrong in that build instead of discussing a beneficial refactor in this
project.





2018-05-10 12:22 GMT+02:00 Harbs :

> I was referring to the js-only build:
> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/
> royale-asjs_jsonly/  8080/job/royale-asjs_jsonly/>
>
> Like I mentioned, I have not been following the lists as closely as I
> usually do the last week or two. I certainly did not realize you were doing
> a major refactor.
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

2018-05-10 12:03 GMT+02:00 Harbs :

> A true team will work *together*.
>

together for me is to fix the problems we have due to this refactor. Not
revert something since my personal application break. Maybe we have
different ways to think about a team.


>
> I’ve been asking you many times already to explain *why* you think a
> refactor is important.
>

and I explained many times, not 2 or 3, 4 or 5 in different sentences and
with different words


>
> You seem to have a different opinion than me (and I think others) on what
> Basic *is*. I see nothing wrong with having component sets depend on Basic.
>

But I see it key due to all the things I explained in this thread. Since
you don't mind about this why are you opposing to something I find
critical? if you use Basic and Basic works the same, don't understand you
opposition that others will continue our path. And now better since I don't
think to touch Basic, so you'll never find it broken by me.


>
> You went ahead and made changes without first gathering consensus. We’re
> asking you to justify that your changes were warranted and if there is not
> consensus for those changes to revert your changes.
>

I made a huge commit, ok. But we are all doing the same all the time. We
want to have consensus with every commit we have?
If not let me know why my commit is not good and your is.


>
> We’re pushing back on these changes and simply standing your ground and
> claiming others are not being good team members is not fair.
>

Harbs, you are doing a very aggressive thing reverting my work. A work that
was done with several hours.


>
> Can we please keep this discussion about the technical reasons for a
> refactor and whether or not it’s the right thing to do? If you have strong
> technical reasons why Basic should not be a dependency please explain them.
>

Harbs, I'll explained lots of time, and you keep ask the same. What did you
not understand of the things I expressed so many time?


>
> There also seems to be a disconnect on package *names* and project swcs.
>

But Maven is working perfectly? Why are you saying that? I can send to this
pass a current build SUCCESS in every all projects in the repo.



>
> Thanks,
> Harbs
>
> > On May 10, 2018, at 12:56 PM, Carlos Rovira 
> wrote:
> >
> > A true team will say "hey! something is wrong lets fix it", since is more
> > easy to fix from the actual point, than revert to that commit.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

I was referring to the js-only build:
http://apacheroyaleci.westus2.cloudapp.azure.com:8080/job/royale-asjs_jsonly/ 


Like I mentioned, I have not been following the lists as closely as I usually 
do the last week or two. I certainly did not realize you were doing a major 
refactor.

> On May 10, 2018, at 1:17 PM, Carlos Rovira  wrote:
> 
> Hi Harbs,
> 
> I'm with you that wasn't the right way to do, Was my first huge refactor,
> and I think it was aligned with what I talked with you all, special with
> Alex, but as well with Peter and you in some emails about that we want to
> make a refactor. And for me this was only a part of that, and expect others
> like Alex or Peter will be doing the things they have in mind. For this
> refactor I only reach the separation goal.
> 
> I think other time I'll be creating a thread, but I think is not the way to
> go now. Since the bad is done, we should try to fix instead of going back.
> And I think we'll find the problems that we are facing now.
> 
> builds seems ok to me since only #737 and #741 (latest) are failing, so
> build was ok for many days after I did the refactor. So is ANT what is
> failing for you localy? if so, the way to fix this is try to fix ANT build
> 
> 
> 
> 2018-05-10 11:52 GMT+02:00 Harbs  >:
> 
>>> On May 10, 2018, at 12:45 PM, Carlos Rovira 
>> wrote:
>> 
>> 
>>> sorry that you are frustrated. But any change we'll do to refactor
>> things,
>>> will have the same effect in your application code base
>> 
>> If there’s a good reason for a refactor, then I agree with you. You have
>> yet to convince us that is the case.
>> 
>> Please let’s focus on your reasons for doing so. I simply don’t understand
>> why you think it’s important.
>> 
>> Whether you are right or wrong, making such major changes to the develop
>> branch without first building consensus that it’s the right thing to do is
>> the wrong way to go about it.
>> 
>>> Right now, Maven build is green in all parts (frameworks, projects,
>> themes,
>>> examples)
>> 
>> The Azure build has been failing for 4 days (I believe since you did your
>> refactor work):
>> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/ <
>> http://apacheroyaleci.westus2.cloudapp.azure.com:8080/ 
>> >
>> 
>> 
>> Thanks,
>> Harbs
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira 

Re: Container change

[Carlos Rovira]

Piotr,

I admit I was wrong in the way I did the refactor, but not intentionally as
I said I think it was consensus with needs of refactors, the mine, and
others I saw commented to "possible do". So the problem was the way I did,
ok. I know for the next.We're all human, and can make mistakes. Now, the
way to solve it or me is not to revert, to fix an application outside the
project broken, but to see what's going on, and fix it.

In the end other refactor will have the same implications! so although we
discussed it, the refactor will end in something similar and in Harbs
having to update their codebase to adapt to it.

2018-05-10 12:03 GMT+02:00 Piotr Zarzycki :

> Carlos,
>
> I didn't want you to move outside the project. I meant that you can use
> your own forked version and still contribute here, but let's not focus on
> it.
>
> Harbs did revert your changes because not only his app was broken, but also
> because there were no proper discussion. Apart of that Alex brings what's
> the idea behind the Basic. It's not only a UI library, but also pieces
> which are doing much more things. Harbs said it in the previous email too.
> Once you start building your app you will notice that.
>
> Thanks, Piotr
>
>
> 2018-05-10 11:56 GMT+02:00 Carlos Rovira :
>
> > Hi Piotr,
> >
> > If you want that I move on from this project I can do that. And maybe
> that
> > will means that this project has something wrong or strange at its Core.
> > Since I'll be the fourth or five contributor that will move on from this
> > project due to discrepancies with some PMC members. So maybe those
> > contributors wasn't the problem.
> >
> > What I see really discouraging is that Harbs will revert the change since
> > is breaking his app.
> >
> > A true team will say "hey! something is wrong lets fix it", since is more
> > easy to fix from the actual point, than revert to that commit.
> >
> > But you were clear with your proposal of me to fork Royale in other
> > project...Just let me know and I'll move on.
> >
> >
> >
> > 2018-05-10 10:49 GMT+02:00 Piotr Zarzycki :
> >
> > > +1.
> > >
> > > In my opinion it should be done in the following way.
> > > 1) Refactoring in separate branch
> > > 2) Announce on dev list
> > > 3) Wait until someone look into that - if it passed 48h gentle
> reminder.
> > -
> > > The time in this project is rather longer in case of changes.
> > >
> > > Btw. I know couple of projects which forked Flex SDK and guys change it
> > for
> > > the project purpose. If you really wanted to have it totally separated
> > you
> > > can have your own SDK. - It's a pain, but you can move forward faster
> > > instead of waiting or discuss with others on something.
> > >
> > > I really wanted to use Jewel for the new project as part of
> > > Transpiledactionscript and this what is happening do not help. I'm not
> > > talking about code changes, but rather time spent on that after those
> > > changes.
> > >
> > > Piotr
> > >
> > > On Thu, May 10, 2018, 10:35 AM Harbs  wrote:
> > >
> > > > Let me just say that I’m *very* frustrated right now.
> > > >
> > > > I’m busy chasing down all kinds of odd issues caused by a refactoring
> > > that
> > > > we didn’t agree on.
> > > >
> > > > I really don’t have the time to be doing so right now… :-(
> > > >
> > > > Carlos, you REALLY should have:
> > > > a) properly discussed this all *before* you made these changes.
> > > > b) done this on a feature branch.
> > > >
> > > > At this point, I’d like to just revert all the refactoring changes.
> > > >
> > > > Harbs
> > > >
> > > > > On May 10, 2018, at 9:08 AM, Piotr Zarzycki <
> > piotrzarzyck...@gmail.com
> > > >
> > > > wrote:
> > > > >
> > > > > In that point I'm feeling that Even if couple of PMC members or
> > > > committers
> > > > > have some resistance, changes are being done no matter what.
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

> On May 10, 2018, at 1:08 PM, Carlos Rovira  wrote:
> 
>> Please explain the following:
>> 1. What is the advantage of removing the Basic library swc as a dependency
>> from component sets?
>> 
> 
> This was fully explained, please, revisit the thread, since I give
> different responses some time repeating itself. The last one just few
> minutes ago responding all this threads

Well, could you please do me a favor and explain it again? I can’t seem to find 
it. I think we’re most likely to come to an agreement if we could have all the 
arguments in one place.

> 
>> 2. What (if anything) is the advantage of changing package names?
>> 
> 
> My intention here was to put things in "core". This could be a wrong
> decision, due to all of you don't want to change references in you final
> applications, but as refactor I think is ok to have Core classes in "core"
> package, and not a mixture of things in Core and Basic where some are in
> "core" and others are in "html", what seems completely wrong and very
> confusing. I changed some to the old namespace to try to help in that, but
> seems nothing of this serves.

Even after your refactor, we still have the html package, so I’m not really 
sure I understand what you’re accomplishing. Maybe this goes back to the 
disconnect on what Basic is.

Thanks,
Harbs

Re: Container change

[Carlos Rovira]

That's what seems to haven...40% of a 160kbs is many code to remove from a
compilation...

2018-05-10 11:29 GMT+02:00 Harbs :

> I don’t remember seeing this argument before. (Maybe I missed it. I have
> not been following the list as well as I usually do with the new baby and
> all…)
>
> My impression was that CSS from secs are only copied over if the component
> is actually used. Is that wrong?
>
> Harbs
>
> > On May 10, 2018, at 12:24 PM, Carlos Rovira 
> wrote:
> >
> > I think the problem is that Basic UI set links things through CSS
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

A true team will work *together*.

I’ve been asking you many times already to explain *why* you think a refactor 
is important.

You seem to have a different opinion than me (and I think others) on what Basic 
*is*. I see nothing wrong with having component sets depend on Basic.

You went ahead and made changes without first gathering consensus. We’re asking 
you to justify that your changes were warranted and if there is not consensus 
for those changes to revert your changes.

We’re pushing back on these changes and simply standing your ground and 
claiming others are not being good team members is not fair.

Can we please keep this discussion about the technical reasons for a refactor 
and whether or not it’s the right thing to do? If you have strong technical 
reasons why Basic should not be a dependency please explain them.

There also seems to be a disconnect on package *names* and project swcs.

Thanks,
Harbs

> On May 10, 2018, at 12:56 PM, Carlos Rovira  wrote:
> 
> A true team will say "hey! something is wrong lets fix it", since is more
> easy to fix from the actual point, than revert to that commit.

Re: Container change

[Piotr Zarzycki]

Carlos,

I didn't want you to move outside the project. I meant that you can use
your own forked version and still contribute here, but let's not focus on
it.

Harbs did revert your changes because not only his app was broken, but also
because there were no proper discussion. Apart of that Alex brings what's
the idea behind the Basic. It's not only a UI library, but also pieces
which are doing much more things. Harbs said it in the previous email too.
Once you start building your app you will notice that.

Thanks, Piotr


2018-05-10 11:56 GMT+02:00 Carlos Rovira :

> Hi Piotr,
>
> If you want that I move on from this project I can do that. And maybe that
> will means that this project has something wrong or strange at its Core.
> Since I'll be the fourth or five contributor that will move on from this
> project due to discrepancies with some PMC members. So maybe those
> contributors wasn't the problem.
>
> What I see really discouraging is that Harbs will revert the change since
> is breaking his app.
>
> A true team will say "hey! something is wrong lets fix it", since is more
> easy to fix from the actual point, than revert to that commit.
>
> But you were clear with your proposal of me to fork Royale in other
> project...Just let me know and I'll move on.
>
>
>
> 2018-05-10 10:49 GMT+02:00 Piotr Zarzycki :
>
> > +1.
> >
> > In my opinion it should be done in the following way.
> > 1) Refactoring in separate branch
> > 2) Announce on dev list
> > 3) Wait until someone look into that - if it passed 48h gentle reminder.
> -
> > The time in this project is rather longer in case of changes.
> >
> > Btw. I know couple of projects which forked Flex SDK and guys change it
> for
> > the project purpose. If you really wanted to have it totally separated
> you
> > can have your own SDK. - It's a pain, but you can move forward faster
> > instead of waiting or discuss with others on something.
> >
> > I really wanted to use Jewel for the new project as part of
> > Transpiledactionscript and this what is happening do not help. I'm not
> > talking about code changes, but rather time spent on that after those
> > changes.
> >
> > Piotr
> >
> > On Thu, May 10, 2018, 10:35 AM Harbs  wrote:
> >
> > > Let me just say that I’m *very* frustrated right now.
> > >
> > > I’m busy chasing down all kinds of odd issues caused by a refactoring
> > that
> > > we didn’t agree on.
> > >
> > > I really don’t have the time to be doing so right now… :-(
> > >
> > > Carlos, you REALLY should have:
> > > a) properly discussed this all *before* you made these changes.
> > > b) done this on a feature branch.
> > >
> > > At this point, I’d like to just revert all the refactoring changes.
> > >
> > > Harbs
> > >
> > > > On May 10, 2018, at 9:08 AM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com
> > >
> > > wrote:
> > > >
> > > > In that point I'm feeling that Even if couple of PMC members or
> > > committers
> > > > have some resistance, changes are being done no matter what.
> > >
> > >
> >
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Container change

[Harbs]

> On May 10, 2018, at 12:45 PM, Carlos Rovira  wrote:


> sorry that you are frustrated. But any change we'll do to refactor things,
> will have the same effect in your application code base

If there’s a good reason for a refactor, then I agree with you. You have yet to 
convince us that is the case.

Please let’s focus on your reasons for doing so. I simply don’t understand why 
you think it’s important.

Whether you are right or wrong, making such major changes to the develop branch 
without first building consensus that it’s the right thing to do is the wrong 
way to go about it.

> Right now, Maven build is green in all parts (frameworks, projects, themes,
> examples)

The Azure build has been failing for 4 days (I believe since you did your 
refactor work):
http://apacheroyaleci.westus2.cloudapp.azure.com:8080/ 



Thanks,
Harbs

Re: Container change

[Carlos Rovira]

Hi Piotr,

If you want that I move on from this project I can do that. And maybe that
will means that this project has something wrong or strange at its Core.
Since I'll be the fourth or five contributor that will move on from this
project due to discrepancies with some PMC members. So maybe those
contributors wasn't the problem.

What I see really discouraging is that Harbs will revert the change since
is breaking his app.

A true team will say "hey! something is wrong lets fix it", since is more
easy to fix from the actual point, than revert to that commit.

But you were clear with your proposal of me to fork Royale in other
project...Just let me know and I'll move on.



2018-05-10 10:49 GMT+02:00 Piotr Zarzycki :

> +1.
>
> In my opinion it should be done in the following way.
> 1) Refactoring in separate branch
> 2) Announce on dev list
> 3) Wait until someone look into that - if it passed 48h gentle reminder. -
> The time in this project is rather longer in case of changes.
>
> Btw. I know couple of projects which forked Flex SDK and guys change it for
> the project purpose. If you really wanted to have it totally separated you
> can have your own SDK. - It's a pain, but you can move forward faster
> instead of waiting or discuss with others on something.
>
> I really wanted to use Jewel for the new project as part of
> Transpiledactionscript and this what is happening do not help. I'm not
> talking about code changes, but rather time spent on that after those
> changes.
>
> Piotr
>
> On Thu, May 10, 2018, 10:35 AM Harbs  wrote:
>
> > Let me just say that I’m *very* frustrated right now.
> >
> > I’m busy chasing down all kinds of odd issues caused by a refactoring
> that
> > we didn’t agree on.
> >
> > I really don’t have the time to be doing so right now… :-(
> >
> > Carlos, you REALLY should have:
> > a) properly discussed this all *before* you made these changes.
> > b) done this on a feature branch.
> >
> > At this point, I’d like to just revert all the refactoring changes.
> >
> > Harbs
> >
> > > On May 10, 2018, at 9:08 AM, Piotr Zarzycki  >
> > wrote:
> > >
> > > In that point I'm feeling that Even if couple of PMC members or
> > committers
> > > have some resistance, changes are being done no matter what.
> >
> >
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Harbs,

sorry that you are frustrated. But any change we'll do to refactor things,
will have the same effect in your application code base: You'll need to
adapt you code to the changes. That was that always people do when this
kind of changes comes.

If you want to go back, that means we'll freeze in the past and all
discussion in the end will make the same effect.

Right now, Maven build is green in all parts (frameworks, projects, themes,
examples), so I think is more easy for all of us to go forward, and
simply fix you Application. Why don't you want to help on this? Why the
best way is revert a project framework to solve an application case?

Simply don't understand that way of proceed and seems very hard with the
work done for others to make this project better.




2018-05-10 10:34 GMT+02:00 Harbs :

> Let me just say that I’m *very* frustrated right now.
>
> I’m busy chasing down all kinds of odd issues caused by a refactoring that
> we didn’t agree on.
>
> I really don’t have the time to be doing so right now… :-(
>
> Carlos, you REALLY should have:
> a) properly discussed this all *before* you made these changes.
> b) done this on a feature branch.
>
> At this point, I’d like to just revert all the refactoring changes.
>
> Harbs
>
> > On May 10, 2018, at 9:08 AM, Piotr Zarzycki 
> wrote:
> >
> > In that point I'm feeling that Even if couple of PMC members or
> committers
> > have some resistance, changes are being done no matter what.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Hi Alex,



2018-05-10 9:48 GMT+02:00 Alex Harui :

> If we had more time, MXML would generate the adding of a bead.  Then you
> could use just about any class in MXML.
>

I think that would be very good, since will make royale more consistent
right?


>
> Having something support being an MXML root tag requires the APIs in Group
> that call MXMLDataInterpreter at the two points in the lifecycle, and in
> most cases an "mxmlContent" property referenced by the [DefaultProperty]
> metadata.
>
> Yes, you can say that MXML also requires addElement and States requires a
> states property and addElementAt, removeElement, but those APIs are
> available on most base classes anyway.
>
> I think that's it, although I may be forgetting something.
>
> Group is supposed to be the simplest "container" that supports assignable
> layout.  If we do a major refactor I would probably push to rename it to
> Container and call Container something else like
> ContainerWithWrappedContent.  In Royale I wanted us to have a clear
> distinction between controls and containers and it isn't clear that Group
> is a "container", but not a Container (org.apache.royale.html).  While
> UIBase has an addElement/removeElement API, I also hoped to tweak ASDoc to
> hide those APIs from application developers.  The component/library
> developer needs to use addElement to construct a complex component, but the
> application developer should not be calling addElement on controls, only on
> containers.  And the application developer should not be using what is now
> Container unless they need to wrap the children to add fancy borders,
> titlebars and other chrome.
>

I still does not understand why we have Group and Container, I think Peter
said that was due to SWF needs, but as in other parts of the SDK we should
not have classes of general purpose if the motivation is serve one concrete
output (in this case SWF).


>
> Unfortunately, ListBase currently subclasses GroupBase but is a control.
>

But in a refactor that's seems right to refactor right?


>
> IMO, you have to look at what the value add is of each class in order to
> decide what to use for a base class.   It isn't clear that "HTML"
> components need to support states and transitions, for example.
>

I'm with Harbs that HTML should  support states and transitions (and
transitions maybe most for SWF needs, since in HTML transitions are all in
CSS, and maybe that should be the same for CSS...)



>
> My 2 cents,
> -Alex
>
>
> On 5/9/18, 11:31 PM, "Harbs"  wrote:
>
> I don’t care that it should extend Group specifically, but it does
> need to extend (or implement) a "Group-esque” component. Without that, HTML
> element components can’t contain other elements in MXML.
>
> Which pieces are required for it to contain other elements in MXML?
> Not 100% sure about that.
>
> As far as what it needs? Not 100% sure but definitely:
> addElement
> addElementAt
> removeElement
>
> Pretty sure about DefaultProperty.
>
> Not sure about:
> Layout pieces
> States
> Transitions
> IMXMLDocument
>
> Various events? Dunno.
>
> I’d guess that Layout is probably something we *do* want to have.
> Requiring that to be specified using standard css doesn’t feel very
> “Royale-like” to me.
> States should likely be included as well to allow HTML elements to be
> modified by states.
> I don’t know why Transitions are included in Group in the first place,
> so I can’t comment on that.
>
> IMXMLDocument: Is that needed only for making it a base for an MXML
> file? Should HTML Element components have the ability to be used as a base
> for MXML? I don’t know the answers to this.
>
> Harbs
>
> > On May 10, 2018, at 2:19 AM, Alex Harui 
> wrote:
> >
> > On the other hand, I don't agree with Yishay's and Harb's concerns
> about the NodeElementBase having to subclass Group in order to get MXML
> children.  The ability to specify children in MXML can be added to any
> class.  What else does NodeElementBase.as use from Group/GroupBase?
>
>
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Hi Harbs,

in the point you are discussing here, I'm with you, and as well proposed a
way to fix it in the other emails: Extract States/MXML functionality in
Core so Group and HTML elements can use it. GroupBase seems not a class
that should remain since seems does not apport nothing at the moment. I
think as well HTML needs States, or said in other way. Al most all visual
components declarable vía MXML, should be, since for users will be very
strange that some could do it and other not...
It's a matter of consistency all over Royale.


2018-05-10 8:31 GMT+02:00 Harbs :

> I don’t care that it should extend Group specifically, but it does need to
> extend (or implement) a "Group-esque” component. Without that, HTML element
> components can’t contain other elements in MXML.
>
> Which pieces are required for it to contain other elements in MXML? Not
> 100% sure about that.
>
> As far as what it needs? Not 100% sure but definitely:
> addElement
> addElementAt
> removeElement
>
> Pretty sure about DefaultProperty.
>
> Not sure about:
> Layout pieces
> States
> Transitions
> IMXMLDocument
>
> Various events? Dunno.
>
> I’d guess that Layout is probably something we *do* want to have.
> Requiring that to be specified using standard css doesn’t feel very
> “Royale-like” to me.
> States should likely be included as well to allow HTML elements to be
> modified by states.
> I don’t know why Transitions are included in Group in the first place, so
> I can’t comment on that.
>
> IMXMLDocument: Is that needed only for making it a base for an MXML file?
> Should HTML Element components have the ability to be used as a base for
> MXML? I don’t know the answers to this.
>
> Harbs
>
> > On May 10, 2018, at 2:19 AM, Alex Harui 
> wrote:
> >
> > On the other hand, I don't agree with Yishay's and Harb's concerns about
> the NodeElementBase having to subclass Group in order to get MXML
> children.  The ability to specify children in MXML can be added to any
> class.  What else does NodeElementBase.as use from Group/GroupBase?
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Hi Piotr, for further changes of this kind I'll be commenting first for
sure.
But I think the problem is that will be many discussion for nothing, since
I'm seeing a problem changing things at 0.9.2, only because an Application
that was build in 0.8 is being broken. I remember Jumbo (Flex4 days), where
we was working with alpha sdk and by the time Flex4 comes with all the API
fixed, people had to move their code bases to comply with the release
version.

We at this group seems to stick with things done 2-3 years ago, and that's
for me what makes me feel bad, since I'm investing lots of time to get this
kind of response.



2018-05-10 8:08 GMT+02:00 Piotr Zarzycki :

> In that point I'm feeling that Even if couple of PMC members or committers
> have some resistance, changes are being done no matter what. I'm starting
> to be a bit farther from the project because of that. Really valid points
> in Alex's response.
>
> 2018-05-10 1:19 GMT+02:00 Alex Harui :
>
> > Hi Carlos,
> >
> > IMO, you are getting resistance from other committers because you are
> > recommending changes that don't have sufficient technical merit.  What is
> > the technical advantage to the Jewel project not having a dependency on
> the
> > Basic project?  I continue to think you are too fixated on project
> > dependencies when the only thing that matters is class dependencies.  Get
> > the class dependencies right and don't worry about project dependencies.
> > It is pretty rare that copying code is a recommended practice, especially
> > for Royale where we are trying to use composition.  Also, you are
> > recommending copying "just-in-case" a Jewel class diverges from a Basic
> > class.  In Royale, those divergences should be managed via composition,
> > refactoring, and subclassing, and not copying, and only when divergence
> is
> > actually required, not just-in-case.
> >
> > I don't have any problem with changing package names of some classes at
> > this point in time, but we still want the organization of the libraries
> to
> > make sense.  So if you put Group in the Core library regardless of which
> > package it is in, you are saying that just about every implementation of
> a
> > random group of child objects will want to just the implementation in
> > Group.as.  I'm not sure that's true, and that kind of thing deserves
> > discussion before it happens.  Just because some other project wants to
> use
> > a class that is currently in Basic does not mean that class should be in
> > Core.
> >
> > On the other hand, I don't agree with Yishay's and Harb's concerns about
> > the NodeElementBase having to subclass Group in order to get MXML
> > children.  The ability to specify children in MXML can be added to any
> > class.  What else does NodeElementBase.as use from Group/GroupBase?
> >
> > I also want to remind folks that all of the classes that are in Basic but
> > in the org.apache.royale.core package used to be in the Core project
> before
> > we had to fork them for the element-wrapping experiment.  So, IMO, it is
> > fine to move every class from Basic that is in org.apache.royale.core
> back
> > to Core if we still agree that almost every implementation will leverage
> > that contract or functionality.  But Group isn't one of those classes.
> > Should it be?  I don't have a set opinion right now, but I'm leaning
> > towards no.  Group has a particular opinion about its lifecycle.  We'd
> have
> > to agree that it would be rare for someone to not want that lifecycle.
> >
> > Another thing to note is that some aspects of what is in GroupBase is due
> > to trying to save time by avoiding making changes to the compiler's
> > handling of states and transitions.
> >
> > We could stop and do a major refactor/reorganization.  I'd rather not
> > spend the time on that right now, but I'd also rather not spend the time
> > dealing with confusion and disagreement over what goes in what
> > project/library.  Just because we reference libraries like Collections
> and
> > Network from other libraries as fundamental building blocks does not make
> > them Core, just "shared" or "reused".  I hesitate to use the word
> "common"
> > because too many things fall under that word.  Collections and Network
> are
> > just an implementation tuned towards Flex-familiar users.  It is not
> clear
> > that every Royale app will need or want to use their code.
> >
> > Thanks,
> > -Alex
> >
> > On 5/9/18, 10:13 AM, "carlos.rov...@gmail.com on behalf of Carlos
> > Rovira" 
> > wrote:
> >
> > Now, all that makes more sense...
> >
> > So is ANT what is failing, but that should not be that way, since
> > there's
> > no changes to interdependencies of libraries. If ANT was working
> > before now
> > should work as well. If not I think is time to get what could be
> wrong
> > in
> > ANT building. I could remove some Basic 

Re: Container change

[Harbs]

I don’t remember seeing this argument before. (Maybe I missed it. I have not 
been following the list as well as I usually do with the new baby and all…)

My impression was that CSS from secs are only copied over if the component is 
actually used. Is that wrong?

Harbs

> On May 10, 2018, at 12:24 PM, Carlos Rovira  wrote:
> 
> I think the problem is that Basic UI set links things through CSS

Re: Container change

[Harbs]

I think this is the disconnect.

While Basic *does* have components, it’s not *just* components. It’s also the 
Basic building blocks *for* components which might or might not be part of 
Basic.

The comparison we keep using is lego. While Basic does have some pieces of lego 
pre-constructed, it also has the basic pieces which can be put together in 
different ways by other component sets.

> On May 10, 2018, at 12:17 PM, Carlos Rovira  wrote:
> 
> Jewel is like Basic in terms of design, all based on composition, beads,
> and strands. and simply since it is a UI library, should not depend on
> another UI library that does exactly the same.

Re: Container change

[Carlos Rovira]

-1 totally

I want to respond each email to reach this one.

I'll go step by step




2018-05-10 10:49 GMT+02:00 Piotr Zarzycki :

> +1.
>
> In my opinion it should be done in the following way.
> 1) Refactoring in separate branch
> 2) Announce on dev list
> 3) Wait until someone look into that - if it passed 48h gentle reminder. -
> The time in this project is rather longer in case of changes.
>
> Btw. I know couple of projects which forked Flex SDK and guys change it for
> the project purpose. If you really wanted to have it totally separated you
> can have your own SDK. - It's a pain, but you can move forward faster
> instead of waiting or discuss with others on something.
>
> I really wanted to use Jewel for the new project as part of
> Transpiledactionscript and this what is happening do not help. I'm not
> talking about code changes, but rather time spent on that after those
> changes.
>
> Piotr
>
> On Thu, May 10, 2018, 10:35 AM Harbs  wrote:
>
> > Let me just say that I’m *very* frustrated right now.
> >
> > I’m busy chasing down all kinds of odd issues caused by a refactoring
> that
> > we didn’t agree on.
> >
> > I really don’t have the time to be doing so right now… :-(
> >
> > Carlos, you REALLY should have:
> > a) properly discussed this all *before* you made these changes.
> > b) done this on a feature branch.
> >
> > At this point, I’d like to just revert all the refactoring changes.
> >
> > Harbs
> >
> > > On May 10, 2018, at 9:08 AM, Piotr Zarzycki  >
> > wrote:
> > >
> > > In that point I'm feeling that Even if couple of PMC members or
> > committers
> > > have some resistance, changes are being done no matter what.
> >
> >
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

I just created a feature branch which reverted back to the last change on the 
4th and I applied my changes on that (as well as one of Alex’s — his second 
commit didn’t apply).

I’m using that branch for the meanwhile until this mess is straightened out so 
I can continue working.

Harbs

> On May 10, 2018, at 11:49 AM, Piotr Zarzycki  
> wrote:
> 
> +1.
> 
> In my opinion it should be done in the following way.
> 1) Refactoring in separate branch
> 2) Announce on dev list
> 3) Wait until someone look into that - if it passed 48h gentle reminder. -
> The time in this project is rather longer in case of changes.
> 
> Btw. I know couple of projects which forked Flex SDK and guys change it for
> the project purpose. If you really wanted to have it totally separated you
> can have your own SDK. - It's a pain, but you can move forward faster
> instead of waiting or discuss with others on something.
> 
> I really wanted to use Jewel for the new project as part of
> Transpiledactionscript and this what is happening do not help. I'm not
> talking about code changes, but rather time spent on that after those
> changes.
> 
> Piotr
> 
> On Thu, May 10, 2018, 10:35 AM Harbs  wrote:
> 
>> Let me just say that I’m *very* frustrated right now.
>> 
>> I’m busy chasing down all kinds of odd issues caused by a refactoring that
>> we didn’t agree on.
>> 
>> I really don’t have the time to be doing so right now… :-(
>> 
>> Carlos, you REALLY should have:
>> a) properly discussed this all *before* you made these changes.
>> b) done this on a feature branch.
>> 
>> At this point, I’d like to just revert all the refactoring changes.
>> 
>> Harbs
>> 
>>> On May 10, 2018, at 9:08 AM, Piotr Zarzycki 
>> wrote:
>>> 
>>> In that point I'm feeling that Even if couple of PMC members or
>> committers
>>> have some resistance, changes are being done no matter what.
>> 
>> 

Re: Container change

[Piotr Zarzycki]

+1.

In my opinion it should be done in the following way.
1) Refactoring in separate branch
2) Announce on dev list
3) Wait until someone look into that - if it passed 48h gentle reminder. -
The time in this project is rather longer in case of changes.

Btw. I know couple of projects which forked Flex SDK and guys change it for
the project purpose. If you really wanted to have it totally separated you
can have your own SDK. - It's a pain, but you can move forward faster
instead of waiting or discuss with others on something.

I really wanted to use Jewel for the new project as part of
Transpiledactionscript and this what is happening do not help. I'm not
talking about code changes, but rather time spent on that after those
changes.

Piotr

On Thu, May 10, 2018, 10:35 AM Harbs  wrote:

> Let me just say that I’m *very* frustrated right now.
>
> I’m busy chasing down all kinds of odd issues caused by a refactoring that
> we didn’t agree on.
>
> I really don’t have the time to be doing so right now… :-(
>
> Carlos, you REALLY should have:
> a) properly discussed this all *before* you made these changes.
> b) done this on a feature branch.
>
> At this point, I’d like to just revert all the refactoring changes.
>
> Harbs
>
> > On May 10, 2018, at 9:08 AM, Piotr Zarzycki 
> wrote:
> >
> > In that point I'm feeling that Even if couple of PMC members or
> committers
> > have some resistance, changes are being done no matter what.
>
>

Re: Container change

[Harbs]

Let me just say that I’m *very* frustrated right now.

I’m busy chasing down all kinds of odd issues caused by a refactoring that we 
didn’t agree on.

I really don’t have the time to be doing so right now… :-(

Carlos, you REALLY should have:
a) properly discussed this all *before* you made these changes.
b) done this on a feature branch.

At this point, I’d like to just revert all the refactoring changes.

Harbs

> On May 10, 2018, at 9:08 AM, Piotr Zarzycki  wrote:
> 
> In that point I'm feeling that Even if couple of PMC members or committers
> have some resistance, changes are being done no matter what.

Re: Container change

[Harbs]

I’m not sure who originally based HTML element off Group, but all I did (when I 
worked on completing the HTML component set) was to simplify the classes and 
complete set. Admittedly, not all of them based Group originally, but I think 
that was an oversight. I can’t think of any HTML elements which can’t contain 
others.

I don’t have a strong opinion regarding states and transitions, but I think the 
answer to that depends on how “core” that functionality is to MXML. My leaning 
is that at least states is pretty “core” and if an MXML file has states, all 
the children :containers” should in turn support them. I think that should 
include HTML elements. It seems pretty reasonable to be able to do something 
like this:


I’m not sure why transitions is part of Group, so I don’t have anything 
intelligent to say there.

Harbs

> On May 10, 2018, at 10:48 AM, Alex Harui  wrote:
> 
> If we had more time, MXML would generate the adding of a bead.  Then you 
> could use just about any class in MXML.
> 
> Having something support being an MXML root tag requires the APIs in Group 
> that call MXMLDataInterpreter at the two points in the lifecycle, and in most 
> cases an "mxmlContent" property referenced by the [DefaultProperty] metadata.
> 
> Yes, you can say that MXML also requires addElement and States requires a 
> states property and addElementAt, removeElement, but those APIs are available 
> on most base classes anyway.
> 
> I think that's it, although I may be forgetting something.
> 
> Group is supposed to be the simplest "container" that supports assignable 
> layout.  If we do a major refactor I would probably push to rename it to 
> Container and call Container something else like ContainerWithWrappedContent. 
>  In Royale I wanted us to have a clear distinction between controls and 
> containers and it isn't clear that Group is a "container", but not a 
> Container (org.apache.royale.html).  While UIBase has an 
> addElement/removeElement API, I also hoped to tweak ASDoc to hide those APIs 
> from application developers.  The component/library developer needs to use 
> addElement to construct a complex component, but the application developer 
> should not be calling addElement on controls, only on containers.  And the 
> application developer should not be using what is now Container unless they 
> need to wrap the children to add fancy borders, titlebars and other chrome.
> 
> Unfortunately, ListBase currently subclasses GroupBase but is a control.
> 
> IMO, you have to look at what the value add is of each class in order to 
> decide what to use for a base class.   It isn't clear that "HTML" components 
> need to support states and transitions, for example.
> 
> My 2 cents,
> -Alex
> 
> 
> On 5/9/18, 11:31 PM, "Harbs"  wrote:
> 
>I don’t care that it should extend Group specifically, but it does need to 
> extend (or implement) a "Group-esque” component. Without that, HTML element 
> components can’t contain other elements in MXML.
> 
>Which pieces are required for it to contain other elements in MXML? Not 
> 100% sure about that.
> 
>As far as what it needs? Not 100% sure but definitely:
>addElement
>addElementAt
>removeElement
> 
>Pretty sure about DefaultProperty.
> 
>Not sure about:
>Layout pieces
>States
>Transitions
>IMXMLDocument
> 
>Various events? Dunno.
> 
>I’d guess that Layout is probably something we *do* want to have. 
> Requiring that to be specified using standard css doesn’t feel very 
> “Royale-like” to me.
>States should likely be included as well to allow HTML elements to be 
> modified by states.
>I don’t know why Transitions are included in Group in the first place, so 
> I can’t comment on that.
> 
>IMXMLDocument: Is that needed only for making it a base for an MXML file? 
> Should HTML Element components have the ability to be used as a base for 
> MXML? I don’t know the answers to this.
> 
>Harbs
> 
>> On May 10, 2018, at 2:19 AM, Alex Harui  wrote:
>> 
>> On the other hand, I don't agree with Yishay's and Harb's concerns about the 
>> NodeElementBase having to subclass Group in order to get MXML children.  The 
>> ability to specify children in MXML can be added to any class.  What else 
>> does NodeElementBase.as use from Group/GroupBase?
> 
> 
> 

Re: Container change

[Alex Harui]

If we had more time, MXML would generate the adding of a bead.  Then you could 
use just about any class in MXML.

Having something support being an MXML root tag requires the APIs in Group that 
call MXMLDataInterpreter at the two points in the lifecycle, and in most cases 
an "mxmlContent" property referenced by the [DefaultProperty] metadata.

Yes, you can say that MXML also requires addElement and States requires a 
states property and addElementAt, removeElement, but those APIs are available 
on most base classes anyway.

I think that's it, although I may be forgetting something.

Group is supposed to be the simplest "container" that supports assignable 
layout.  If we do a major refactor I would probably push to rename it to 
Container and call Container something else like ContainerWithWrappedContent.  
In Royale I wanted us to have a clear distinction between controls and 
containers and it isn't clear that Group is a "container", but not a Container 
(org.apache.royale.html).  While UIBase has an addElement/removeElement API, I 
also hoped to tweak ASDoc to hide those APIs from application developers.  The 
component/library developer needs to use addElement to construct a complex 
component, but the application developer should not be calling addElement on 
controls, only on containers.  And the application developer should not be 
using what is now Container unless they need to wrap the children to add fancy 
borders, titlebars and other chrome.

Unfortunately, ListBase currently subclasses GroupBase but is a control.

IMO, you have to look at what the value add is of each class in order to decide 
what to use for a base class.   It isn't clear that "HTML" components need to 
support states and transitions, for example.

My 2 cents,
-Alex


On 5/9/18, 11:31 PM, "Harbs"  wrote:

I don’t care that it should extend Group specifically, but it does need to 
extend (or implement) a "Group-esque” component. Without that, HTML element 
components can’t contain other elements in MXML.

Which pieces are required for it to contain other elements in MXML? Not 
100% sure about that.

As far as what it needs? Not 100% sure but definitely:
addElement
addElementAt
removeElement

Pretty sure about DefaultProperty.

Not sure about:
Layout pieces
States
Transitions
IMXMLDocument

Various events? Dunno.

I’d guess that Layout is probably something we *do* want to have. Requiring 
that to be specified using standard css doesn’t feel very “Royale-like” to me.
States should likely be included as well to allow HTML elements to be 
modified by states.
I don’t know why Transitions are included in Group in the first place, so I 
can’t comment on that.

IMXMLDocument: Is that needed only for making it a base for an MXML file? 
Should HTML Element components have the ability to be used as a base for MXML? 
I don’t know the answers to this.

Harbs

> On May 10, 2018, at 2:19 AM, Alex Harui  wrote:
> 
> On the other hand, I don't agree with Yishay's and Harb's concerns about 
the NodeElementBase having to subclass Group in order to get MXML children.  
The ability to specify children in MXML can be added to any class.  What else 
does NodeElementBase.as use from Group/GroupBase?

Re: Container change

[Harbs]

I don’t care that it should extend Group specifically, but it does need to 
extend (or implement) a "Group-esque” component. Without that, HTML element 
components can’t contain other elements in MXML.

Which pieces are required for it to contain other elements in MXML? Not 100% 
sure about that.

As far as what it needs? Not 100% sure but definitely:
addElement
addElementAt
removeElement

Pretty sure about DefaultProperty.

Not sure about:
Layout pieces
States
Transitions
IMXMLDocument

Various events? Dunno.

I’d guess that Layout is probably something we *do* want to have. Requiring 
that to be specified using standard css doesn’t feel very “Royale-like” to me.
States should likely be included as well to allow HTML elements to be modified 
by states.
I don’t know why Transitions are included in Group in the first place, so I 
can’t comment on that.

IMXMLDocument: Is that needed only for making it a base for an MXML file? 
Should HTML Element components have the ability to be used as a base for MXML? 
I don’t know the answers to this.

Harbs

> On May 10, 2018, at 2:19 AM, Alex Harui  wrote:
> 
> On the other hand, I don't agree with Yishay's and Harb's concerns about the 
> NodeElementBase having to subclass Group in order to get MXML children.  The 
> ability to specify children in MXML can be added to any class.  What else 
> does NodeElementBase.as use from Group/GroupBase?

Re: Container change

[Piotr Zarzycki]

In that point I'm feeling that Even if couple of PMC members or committers
have some resistance, changes are being done no matter what. I'm starting
to be a bit farther from the project because of that. Really valid points
in Alex's response.

2018-05-10 1:19 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> IMO, you are getting resistance from other committers because you are
> recommending changes that don't have sufficient technical merit.  What is
> the technical advantage to the Jewel project not having a dependency on the
> Basic project?  I continue to think you are too fixated on project
> dependencies when the only thing that matters is class dependencies.  Get
> the class dependencies right and don't worry about project dependencies.
> It is pretty rare that copying code is a recommended practice, especially
> for Royale where we are trying to use composition.  Also, you are
> recommending copying "just-in-case" a Jewel class diverges from a Basic
> class.  In Royale, those divergences should be managed via composition,
> refactoring, and subclassing, and not copying, and only when divergence is
> actually required, not just-in-case.
>
> I don't have any problem with changing package names of some classes at
> this point in time, but we still want the organization of the libraries to
> make sense.  So if you put Group in the Core library regardless of which
> package it is in, you are saying that just about every implementation of a
> random group of child objects will want to just the implementation in
> Group.as.  I'm not sure that's true, and that kind of thing deserves
> discussion before it happens.  Just because some other project wants to use
> a class that is currently in Basic does not mean that class should be in
> Core.
>
> On the other hand, I don't agree with Yishay's and Harb's concerns about
> the NodeElementBase having to subclass Group in order to get MXML
> children.  The ability to specify children in MXML can be added to any
> class.  What else does NodeElementBase.as use from Group/GroupBase?
>
> I also want to remind folks that all of the classes that are in Basic but
> in the org.apache.royale.core package used to be in the Core project before
> we had to fork them for the element-wrapping experiment.  So, IMO, it is
> fine to move every class from Basic that is in org.apache.royale.core back
> to Core if we still agree that almost every implementation will leverage
> that contract or functionality.  But Group isn't one of those classes.
> Should it be?  I don't have a set opinion right now, but I'm leaning
> towards no.  Group has a particular opinion about its lifecycle.  We'd have
> to agree that it would be rare for someone to not want that lifecycle.
>
> Another thing to note is that some aspects of what is in GroupBase is due
> to trying to save time by avoiding making changes to the compiler's
> handling of states and transitions.
>
> We could stop and do a major refactor/reorganization.  I'd rather not
> spend the time on that right now, but I'd also rather not spend the time
> dealing with confusion and disagreement over what goes in what
> project/library.  Just because we reference libraries like Collections and
> Network from other libraries as fundamental building blocks does not make
> them Core, just "shared" or "reused".  I hesitate to use the word "common"
> because too many things fall under that word.  Collections and Network are
> just an implementation tuned towards Flex-familiar users.  It is not clear
> that every Royale app will need or want to use their code.
>
> Thanks,
> -Alex
>
> On 5/9/18, 10:13 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> Now, all that makes more sense...
>
> So is ANT what is failing, but that should not be that way, since
> there's
> no changes to interdependencies of libraries. If ANT was working
> before now
> should work as well. If not I think is time to get what could be wrong
> in
> ANT building. I could remove some Basic dependencies in Maven and saw
> that
> by removing Group dependency from NodeBaseElement, some other projects
> need
> Basic. I think that's what you should look at. Add Basic to those
> projects
> that was getting the code due to HTML Basic dependency.
>
> What we have here is not a problem of a refactor, but a hidden problem
> in
> the way we build with ANT.
>
> Or at least is what I see for what Piotr says in his email. I don't
> have
> ANT setting up in my system, and I always build with maven to ensure
> all is
> working.
>
> Carlos
>
>
> 2018-05-09 18:58 GMT+02:00 Piotr Zarzycki :
>
> > We are building by ant IDE packages. This is what is failing. It's
> failing
> > for several days already.
> >
> > On Wed, May 9, 2018, 6:32 PM Carlos Rovira 
> > wrote:
> 

Re: Container change

[yishayw]

Carlos Rovira-2 wrote
>  This
> have many advantages, the most visible is a 40% drop  off in Apps file
> size
> that uses Jewel, since Basic things that never was used are there any
> more.
> Another thing is that Basic things that could mess the intended behaviour
> in Jewel will never happen since is not present anymore.

This is what I don't understand. Why would moving classes between packages
make a difference in app size? As I understand it, the compiler resolves the
dependency tree without caring which packages are involved.




--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Container change

[Alex Harui]

Hi Carlos,

IMO, you are getting resistance from other committers because you are 
recommending changes that don't have sufficient technical merit.  What is the 
technical advantage to the Jewel project not having a dependency on the Basic 
project?  I continue to think you are too fixated on project dependencies when 
the only thing that matters is class dependencies.  Get the class dependencies 
right and don't worry about project dependencies.  It is pretty rare that 
copying code is a recommended practice, especially for Royale where we are 
trying to use composition.  Also, you are recommending copying "just-in-case" a 
Jewel class diverges from a Basic class.  In Royale, those divergences should 
be managed via composition, refactoring, and subclassing, and not copying, and 
only when divergence is actually required, not just-in-case.

I don't have any problem with changing package names of some classes at this 
point in time, but we still want the organization of the libraries to make 
sense.  So if you put Group in the Core library regardless of which package it 
is in, you are saying that just about every implementation of a random group of 
child objects will want to just the implementation in Group.as.  I'm not sure 
that's true, and that kind of thing deserves discussion before it happens.  
Just because some other project wants to use a class that is currently in Basic 
does not mean that class should be in Core.

On the other hand, I don't agree with Yishay's and Harb's concerns about the 
NodeElementBase having to subclass Group in order to get MXML children.  The 
ability to specify children in MXML can be added to any class.  What else does 
NodeElementBase.as use from Group/GroupBase?

I also want to remind folks that all of the classes that are in Basic but in 
the org.apache.royale.core package used to be in the Core project before we had 
to fork them for the element-wrapping experiment.  So, IMO, it is fine to move 
every class from Basic that is in org.apache.royale.core back to Core if we 
still agree that almost every implementation will leverage that contract or 
functionality.  But Group isn't one of those classes.  Should it be?  I don't 
have a set opinion right now, but I'm leaning towards no.  Group has a 
particular opinion about its lifecycle.  We'd have to agree that it would be 
rare for someone to not want that lifecycle.

Another thing to note is that some aspects of what is in GroupBase is due to 
trying to save time by avoiding making changes to the compiler's handling of 
states and transitions.

We could stop and do a major refactor/reorganization.  I'd rather not spend the 
time on that right now, but I'd also rather not spend the time dealing with 
confusion and disagreement over what goes in what project/library.  Just 
because we reference libraries like Collections and Network from other 
libraries as fundamental building blocks does not make them Core, just "shared" 
or "reused".  I hesitate to use the word "common" because too many things fall 
under that word.  Collections and Network are just an implementation tuned 
towards Flex-familiar users.  It is not clear that every Royale app will need 
or want to use their code.

Thanks,
-Alex

On 5/9/18, 10:13 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Now, all that makes more sense...

So is ANT what is failing, but that should not be that way, since there's
no changes to interdependencies of libraries. If ANT was working before now
should work as well. If not I think is time to get what could be wrong in
ANT building. I could remove some Basic dependencies in Maven and saw that
by removing Group dependency from NodeBaseElement, some other projects need
Basic. I think that's what you should look at. Add Basic to those projects
that was getting the code due to HTML Basic dependency.

What we have here is not a problem of a refactor, but a hidden problem in
the way we build with ANT.

Or at least is what I see for what Piotr says in his email. I don't have
ANT setting up in my system, and I always build with maven to ensure all is
working.

Carlos


2018-05-09 18:58 GMT+02:00 Piotr Zarzycki :

> We are building by ant IDE packages. This is what is failing. It's failing
> for several days already.
>
> On Wed, May 9, 2018, 6:32 PM Carlos Rovira 
> wrote:
>
> > Hi Piotr,
> >
> > 2018-05-09 16:48 GMT+02:00 Piotr Zarzycki :
> >
> > > Carlos,
> > >
> > > From all of discussion I see only one advantage splitting Jewel from
> > Basic.
> > > Results in size of package. That's why I'm asking about copied 
classes.
> > It
> > > looks like we will have many copies of everything. If I create useful
> > Bead

Re: Container change

[Carlos Rovira]

Now, all that makes more sense...

So is ANT what is failing, but that should not be that way, since there's
no changes to interdependencies of libraries. If ANT was working before now
should work as well. If not I think is time to get what could be wrong in
ANT building. I could remove some Basic dependencies in Maven and saw that
by removing Group dependency from NodeBaseElement, some other projects need
Basic. I think that's what you should look at. Add Basic to those projects
that was getting the code due to HTML Basic dependency.

What we have here is not a problem of a refactor, but a hidden problem in
the way we build with ANT.

Or at least is what I see for what Piotr says in his email. I don't have
ANT setting up in my system, and I always build with maven to ensure all is
working.

Carlos


2018-05-09 18:58 GMT+02:00 Piotr Zarzycki :

> We are building by ant IDE packages. This is what is failing. It's failing
> for several days already.
>
> On Wed, May 9, 2018, 6:32 PM Carlos Rovira 
> wrote:
>
> > Hi Piotr,
> >
> > 2018-05-09 16:48 GMT+02:00 Piotr Zarzycki :
> >
> > > Carlos,
> > >
> > > From all of discussion I see only one advantage splitting Jewel from
> > Basic.
> > > Results in size of package. That's why I'm asking about copied classes.
> > It
> > > looks like we will have many copies of everything. If I create useful
> > Bead
> > > and you need it you will copy it.
> > >
> >
> > just explain a bit more in my response to Yishay email few seconds ago,
> > you'll see is not only about size
> > Thre's much more involved.
> >
> >
> > >
> > > After all you did the changes, so discussion is closed.
> > >
> > > It will be good if you could look into the failing build after those
> > > changes if they were the cause.
> > >
> >
> > I'm watching closely that builds doesn't break. Seems right now the build
> > is broke, but just the previous one was successful and there's not code
> > changes between, so I suppose is something not related to the code. I
> > always pass maven to all framework and examples when something that
> implies
> > moving classes or changing names or packages are in place, ensuring that
> > all compiles without problems.
> >
> >
> > > In my opinion if we reach 1.0 some day - Every changes in Core should
> be
> > > voted or waited till review on separate branch.
> > >
> >
> > That's completely right. 1.0 means a before and after. We are working
> hard
> > to make all things assemble nicely and work flawlessly. And as we think
> we
> > get that point, for me will be the right moment to make a 1.0 release.
> And
> > that means that any change should be more difficult to do, and will need
> > more consensus. Anyway, in that case, that would means for all of us the
> > same that is happen now. Changes use to imply that applications should
> > update to work accordingly to those ones. But in our case the changes are
> > very easy to do. Think in Java, and how difficult is change from Java 5
> > -6-7-8... or Spring Framework... it's very very difficult compared to a
> few
> > changes here. But our code is still beta quality, and we can expect to
> stay
> > without change a single line of code, and expect our user base grows.
> > That's utopic from all  points of view.
> >
> > Thanks
> >
> >
> >
> >
> > >
> > > Thanks,
> > > Piotr
> > >
> > >
> > > 2018-05-09 16:37 GMT+02:00 yishayw :
> > >
> > > > Hi Carlos,
> > > >
> > > > Just to get one thing out of the way, I changed NodeElementBase to
> > extend
> > > > Group, not because I'm sure that's the way it should be permanently,
> > but
> > > > because leaving your change as it was, was breaking our app which had
> > > > previously worked.
> > > >
> > > > Changes in base classes are always tricky, so I think it's a good
> thing
> > > > that
> > > > there's discussion and people feel obliged to voice their opinions
> and
> > > ask
> > > > questions. I think this should be encouraged.
> > > >
> > > > Personally, I don't feel I have a clear understanding of your
> > motivation
> > > > here. What difference does it actually make to you which packages
> > depend
> > > on
> > > > which? Can you give a specific example from Jewel where this makes a
> > > > difference?
> > > >
> > > > Excellent progress so far with Jewel, I think it's a difference
> maker.
> > > >
> > > > Yishay
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > *
> > >
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

If HTML needs Group, that means Group is core, and that means it needs to
go to Core. If not, I can use HTML without link Basic, and btw, bringing
lots of things that Jewel Apps will never need and interfiere with the
normal behavior.



2018-05-09 18:40 GMT+02:00 Harbs :

> I see things a bit differently than you.
>
> Basic actually has two different “parts”. One is the Components (i.e.
> Label, List, Dropdown, etc.) and the other is “core” functionality and
> optional functionality (i.e. UIBase, Group, many beads, views etc.)
>

As I stated many mails ago in this thread, maybe the problem is that we
need a intermediate library between Core and Basic, but I think if that
would be needed something more simple is to make it go to Core. Or said in
other words...If we have "core" package and basic and "html" package in
Core, that is a clue that something is wrong in the separation we are
trying to do.


>
> The first part of Basic is not really core, but the second part is. I
> don’t see the benefit of pulling out the “core” part of Basic and put it
> into the Core library. I definitely don’t see a benefit to duplicating
> these core pieces in other component sets.
>

I don't want to duplicate. duplication is only a colateral behavior of the
refactor. Some of that clases will evolve with Jewel since will serve to
what Jewel tries to do. Others maybe could be removed if we refine more
this refactor. Others are simple the implementation of some core class and
is normal to have one for UI set



>
> My $0.02,
> Harbs
>
> > On May 9, 2018, at 7:15 PM, Carlos Rovira 
> wrote:
> >
> > Regarding the motivations: Royale has many libraries that are somewhat
> the
> > core. One is Core (of course) and then others orbit but are optional
> > (Collections, Binding, Network,...) depending of your needs you link one
> or
> > another.
> >
> > Then we have ui sets (Basic, Jewel, MDL, CreateJS, Flat,...). Until now
> all
> > sets was Basic dependent.
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Piotr Zarzycki]

We are building by ant IDE packages. This is what is failing. It's failing
for several days already.

On Wed, May 9, 2018, 6:32 PM Carlos Rovira  wrote:

> Hi Piotr,
>
> 2018-05-09 16:48 GMT+02:00 Piotr Zarzycki :
>
> > Carlos,
> >
> > From all of discussion I see only one advantage splitting Jewel from
> Basic.
> > Results in size of package. That's why I'm asking about copied classes.
> It
> > looks like we will have many copies of everything. If I create useful
> Bead
> > and you need it you will copy it.
> >
>
> just explain a bit more in my response to Yishay email few seconds ago,
> you'll see is not only about size
> Thre's much more involved.
>
>
> >
> > After all you did the changes, so discussion is closed.
> >
> > It will be good if you could look into the failing build after those
> > changes if they were the cause.
> >
>
> I'm watching closely that builds doesn't break. Seems right now the build
> is broke, but just the previous one was successful and there's not code
> changes between, so I suppose is something not related to the code. I
> always pass maven to all framework and examples when something that implies
> moving classes or changing names or packages are in place, ensuring that
> all compiles without problems.
>
>
> > In my opinion if we reach 1.0 some day - Every changes in Core should be
> > voted or waited till review on separate branch.
> >
>
> That's completely right. 1.0 means a before and after. We are working hard
> to make all things assemble nicely and work flawlessly. And as we think we
> get that point, for me will be the right moment to make a 1.0 release. And
> that means that any change should be more difficult to do, and will need
> more consensus. Anyway, in that case, that would means for all of us the
> same that is happen now. Changes use to imply that applications should
> update to work accordingly to those ones. But in our case the changes are
> very easy to do. Think in Java, and how difficult is change from Java 5
> -6-7-8... or Spring Framework... it's very very difficult compared to a few
> changes here. But our code is still beta quality, and we can expect to stay
> without change a single line of code, and expect our user base grows.
> That's utopic from all  points of view.
>
> Thanks
>
>
>
>
> >
> > Thanks,
> > Piotr
> >
> >
> > 2018-05-09 16:37 GMT+02:00 yishayw :
> >
> > > Hi Carlos,
> > >
> > > Just to get one thing out of the way, I changed NodeElementBase to
> extend
> > > Group, not because I'm sure that's the way it should be permanently,
> but
> > > because leaving your change as it was, was breaking our app which had
> > > previously worked.
> > >
> > > Changes in base classes are always tricky, so I think it's a good thing
> > > that
> > > there's discussion and people feel obliged to voice their opinions and
> > ask
> > > questions. I think this should be encouraged.
> > >
> > > Personally, I don't feel I have a clear understanding of your
> motivation
> > > here. What difference does it actually make to you which packages
> depend
> > on
> > > which? Can you give a specific example from Jewel where this makes a
> > > difference?
> > >
> > > Excellent progress so far with Jewel, I think it's a difference maker.
> > >
> > > Yishay
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> > >
> >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> >
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: Container change

[Piotr Zarzycki]

Me neither.

On Wed, May 9, 2018, 6:40 PM Harbs  wrote:

> I see things a bit differently than you.
>
> Basic actually has two different “parts”. One is the Components (i.e.
> Label, List, Dropdown, etc.) and the other is “core” functionality and
> optional functionality (i.e. UIBase, Group, many beads, views etc.)
>
> The first part of Basic is not really core, but the second part is. I
> don’t see the benefit of pulling out the “core” part of Basic and put it
> into the Core library. I definitely don’t see a benefit to duplicating
> these core pieces in other component sets.
>
> My $0.02,
> Harbs
>
> > On May 9, 2018, at 7:15 PM, Carlos Rovira 
> wrote:
> >
> > Regarding the motivations: Royale has many libraries that are somewhat
> the
> > core. One is Core (of course) and then others orbit but are optional
> > (Collections, Binding, Network,...) depending of your needs you link one
> or
> > another.
> >
> > Then we have ui sets (Basic, Jewel, MDL, CreateJS, Flat,...). Until now
> all
> > sets was Basic dependent.
>
>

Re: Container change

[Harbs]

I don’t understand this.

HTML needs Group which is in Basic. That’s not a separation (and I don’t see 
why it should be).

> On May 9, 2018, at 7:15 PM, Carlos Rovira  wrote:
> 
> In the way I solved, now HTML works as expected and still we're maintaining
> the separation with Basic.

Re: Container change

[Carlos Rovira]

Hi Yishayw,

right, I for that reason I said you were right. Sometimes when a refactor
is done, maybe some side case is not seen at the time of doing it. That was
the case for nesting in html. For that reason I do my best to solve it
ASAP.

In the way I solved, now HTML works as expected and still we're maintaining
the separation with Basic. I only say that we should not fear changes,
since use to be for the good, and changes should involve to adapt to them.
We're no in 0.9.3 to 0.9.4 and still with low user base, so, now is the
time to make the changes to structure and organization we need. Alex,
Peter, and others have comment in the recent past about that, and that's
the reason of a change like this one.

I'm doing my best to try to not break things, but only say, that in case I
break something, I expect you all have patience and help me to fix it,
while keeping the motivation of the changes.

Regarding the motivations: Royale has many libraries that are somewhat the
core. One is Core (of course) and then others orbit but are optional
(Collections, Binding, Network,...) depending of your needs you link one or
another.

Then we have ui sets (Basic, Jewel, MDL, CreateJS, Flat,...). Until now all
sets was Basic dependent. I started Jewel in that way. Then after much
conversations with Alex, I see that was not the right way to go, and prefer
to extend UIBase, instead of the control in Basic (in case it exits). Alex
said many times that Basic was only a ui set, and as we evolve others could
be developed. Now, that's real, and Jewel is no more Basic dependent. This
have many advantages, the most visible is a 40% drop  off in Apps file size
that uses Jewel, since Basic things that never was used are there any more.
Another thing is that Basic things that could mess the intended behaviour
in Jewel will never happen since is not present anymore. Other is that I
can develop freely Jewel without having to deal with Basic and possible
things I could break to make Jewel work.

That at the cost of a few little problems like we are having. But expect we
solve it all, or maybe we could find one or another in the following
days...at least after several days, seems there's no big problems with this
refactor, only few ones.

thanks for your kinky works about Jewel! :)

Carls





2018-05-09 16:37 GMT+02:00 yishayw :

> Hi Carlos,
>
> Just to get one thing out of the way, I changed NodeElementBase to extend
> Group, not because I'm sure that's the way it should be permanently, but
> because leaving your change as it was, was breaking our app which had
> previously worked.
>
> Changes in base classes are always tricky, so I think it's a good thing
> that
> there's discussion and people feel obliged to voice their opinions and ask
> questions. I think this should be encouraged.
>
> Personally, I don't feel I have a clear understanding of your motivation
> here. What difference does it actually make to you which packages depend on
> which? Can you give a specific example from Jewel where this makes a
> difference?
>
> Excellent progress so far with Jewel, I think it's a difference maker.
>
> Yishay
>
>
>
>
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Piotr Zarzycki]

Carlos,

>From all of discussion I see only one advantage splitting Jewel from Basic.
Results in size of package. That's why I'm asking about copied classes. It
looks like we will have many copies of everything. If I create useful Bead
and you need it you will copy it.

After all you did the changes, so discussion is closed.

It will be good if you could look into the failing build after those
changes if they were the cause.

In my opinion if we reach 1.0 some day - Every changes in Core should be
voted or waited till review on separate branch.

Thanks,
Piotr


2018-05-09 16:37 GMT+02:00 yishayw :

> Hi Carlos,
>
> Just to get one thing out of the way, I changed NodeElementBase to extend
> Group, not because I'm sure that's the way it should be permanently, but
> because leaving your change as it was, was breaking our app which had
> previously worked.
>
> Changes in base classes are always tricky, so I think it's a good thing
> that
> there's discussion and people feel obliged to voice their opinions and ask
> questions. I think this should be encouraged.
>
> Personally, I don't feel I have a clear understanding of your motivation
> here. What difference does it actually make to you which packages depend on
> which? Can you give a specific example from Jewel where this makes a
> difference?
>
> Excellent progress so far with Jewel, I think it's a difference maker.
>
> Yishay
>
>
>
>
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Container change

[yishayw]

Hi Carlos,

Just to get one thing out of the way, I changed NodeElementBase to extend
Group, not because I'm sure that's the way it should be permanently, but
because leaving your change as it was, was breaking our app which had
previously worked.

Changes in base classes are always tricky, so I think it's a good thing that
there's discussion and people feel obliged to voice their opinions and ask
questions. I think this should be encouraged.

Personally, I don't feel I have a clear understanding of your motivation
here. What difference does it actually make to you which packages depend on
which? Can you give a specific example from Jewel where this makes a
difference?

Excellent progress so far with Jewel, I think it's a difference maker.

Yishay

 





--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Container change

[Carlos Rovira]

Harbs,

I solved that is some emails after my proposal about GroupBase. I think all
is ok now

Thanks!


El El mié, 9 may 2018 a las 16:03, Harbs  escribió:

>
> > On May 9, 2018, at 1:47 PM, Carlos Rovira 
> wrote:
> >
> > was Harbs how told me that NodeElementBase was not need to extend Group.
> > Then I changed it and looking into examples for this change didn't see
> > problems.
>
> I said that I wasn’t sure why it extended Group. I didn’t mean that I was
> sure it didn’t need to extend it. Sorry about that...
>
> > Is normal something arise now, so NodeElementBase must extends some kind
> of
> > Group. Did you try to simply try to extend GroupBase that is in core?
>
> I didn’t try, but looking at the code, it does not look GroupBase will
> work. The mxml initialization code is in Group. I’m pretty sure that’s
> going to be needed for using Div in mxml with children elements.

-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

> On May 9, 2018, at 1:47 PM, Carlos Rovira  wrote:
> 
> was Harbs how told me that NodeElementBase was not need to extend Group.
> Then I changed it and looking into examples for this change didn't see
> problems.

I said that I wasn’t sure why it extended Group. I didn’t mean that I was sure 
it didn’t need to extend it. Sorry about that...

> Is normal something arise now, so NodeElementBase must extends some kind of
> Group. Did you try to simply try to extend GroupBase that is in core?

I didn’t try, but looking at the code, it does not look GroupBase will work. 
The mxml initialization code is in Group. I’m pretty sure that’s going to be 
needed for using Div in mxml with children elements.

Re: Container change

[Carlos Rovira]

Piotr,

I'm trying to get a new UI set that had the best quality I can. I think if
I need to copy a bead will be for a good reason to make it happen. A copy
of a class that at first moment could be equal to other one, can get very
different as time passed. The important thing here is if people should link
a different UI set to make work the choose UI set. For me the response is
clearly: Not. If people start mixing, should be due to other reasons,
mainly, the need of using something they don't have in a particular UI set.

I'm not questioning things others are doing, but seems my actions use to be
questioned. Maybe since I'm touching many things since I want this project
to make significant progress and for tha reason I'm investing full time on
this. Maybe is normal some things will be questioned, but I think is better
to think with an open mind and try to see the bigger picture. At the end we
want a great technology in place, and I'm sure that each one here has
different things in mind. But is important to keep in mind that no body is
in the possession of the truth, and is most important to work as a team
than starting to question each things others do. I don't like to do that
with others, so I hope you guys don't do the same with me.

Sincerily, don't think this kind of conversations will make us go forward.

Thanks

Carlos



2018-05-09 15:44 GMT+02:00 Piotr Zarzycki :

> Do you think that in the future you will also start copying Beads not only
> UI classes ?
>
> 2018-05-09 15:36 GMT+02:00 Carlos Rovira :
>
> > Hi Piotr,
> >
> > 4 or 5 I think. some are temporal, others are necessary since are the
> > implementation of a particular UI set. At this time that class can be
> > somewhat identical to the Basic one, but there are plans for some of them
> > to be modified fo Jewel particular purposes
> >
> > 2018-05-09 13:24 GMT+02:00 Piotr Zarzycki :
> >
> > > Carlos,
> > >
> > > How many classes you had to copy from Basic to Jewel so far ?
> > >
> > > Piotr
> > >
> > > 2018-05-09 13:15 GMT+02:00 Carlos Rovira :
> > >
> > > > I fixed this. Now we have what we all want.
> > > > thanks
> > > >
> > > > 2018-05-09 13:01 GMT+02:00 Carlos Rovira :
> > > >
> > > > > btw,
> > > > >
> > > > > for a change like this I think you should pass maven to ensure
> > nothing
> > > > > broken:
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: GoogleMaps .
> > *SUCCESS*
> > > > > [  1.042 s]
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: HTML ...
> > *FAILURE*
> > > > > [  0.321 s]
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: HTML5 ..
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: JQuery .
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: Language ...
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: Material Design Lite
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: Mobile .
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: Reflection .
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: Network 
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: Storage 
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: XML 
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: Text ...
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: TLF 
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: RoyaleSite .
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: MXRoyale ...
> > *SKIPPED*
> > > > >
> > > > > [*INFO*] Apache Royale: Framework: Libs: Jewel 0.9.4-SNAPSHOT
> > *SKIPPED*
> > > > >
> > > > > GroupBase is not a solution since doesn't have the nesting
> > > functionality.
> > > > > I think we have only one way: Pass Group to Core, since is really
> > Core
> > > > >
> > > > >
> > > > >
> > > > > 2018-05-09 12:47 GMT+02:00 Carlos Rovira  >:
> > > > >
> > > > >> Hi
> > > > >>
> > > > >> the problem was that HTML library was baking Basic library only
> due
> > to
> > > > >> "NodeElementBase extends Group"
> > > > >> was Harbs how told me that NodeElementBase was not need to extend
> > > Group.
> > > > >> Then I changed it and looking into examples for this change didn't
> > see
> > > > >> problems.
> > > > >>
> > > > >> Is normal something arise now, so NodeElementBase must extends
> some
> > > kind
> > > > >> of Group. Did you try to simply try to extend GroupBase that is in
> > > core?
> > > > >>
> > > > >> @Harbs, about to revert I think you refer to this concrete one?
> > right?
> > > > >>
> > > > >> We 

Re: Container change

[Piotr Zarzycki]

Do you think that in the future you will also start copying Beads not only
UI classes ?

2018-05-09 15:36 GMT+02:00 Carlos Rovira :

> Hi Piotr,
>
> 4 or 5 I think. some are temporal, others are necessary since are the
> implementation of a particular UI set. At this time that class can be
> somewhat identical to the Basic one, but there are plans for some of them
> to be modified fo Jewel particular purposes
>
> 2018-05-09 13:24 GMT+02:00 Piotr Zarzycki :
>
> > Carlos,
> >
> > How many classes you had to copy from Basic to Jewel so far ?
> >
> > Piotr
> >
> > 2018-05-09 13:15 GMT+02:00 Carlos Rovira :
> >
> > > I fixed this. Now we have what we all want.
> > > thanks
> > >
> > > 2018-05-09 13:01 GMT+02:00 Carlos Rovira :
> > >
> > > > btw,
> > > >
> > > > for a change like this I think you should pass maven to ensure
> nothing
> > > > broken:
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: GoogleMaps .
> *SUCCESS*
> > > > [  1.042 s]
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: HTML ...
> *FAILURE*
> > > > [  0.321 s]
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: HTML5 ..
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: JQuery .
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: Language ...
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: Material Design Lite
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: Mobile .
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: Reflection .
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: Network 
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: Storage 
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: XML 
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: Text ...
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: TLF 
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: RoyaleSite .
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: MXRoyale ...
> *SKIPPED*
> > > >
> > > > [*INFO*] Apache Royale: Framework: Libs: Jewel 0.9.4-SNAPSHOT
> *SKIPPED*
> > > >
> > > > GroupBase is not a solution since doesn't have the nesting
> > functionality.
> > > > I think we have only one way: Pass Group to Core, since is really
> Core
> > > >
> > > >
> > > >
> > > > 2018-05-09 12:47 GMT+02:00 Carlos Rovira :
> > > >
> > > >> Hi
> > > >>
> > > >> the problem was that HTML library was baking Basic library only due
> to
> > > >> "NodeElementBase extends Group"
> > > >> was Harbs how told me that NodeElementBase was not need to extend
> > Group.
> > > >> Then I changed it and looking into examples for this change didn't
> see
> > > >> problems.
> > > >>
> > > >> Is normal something arise now, so NodeElementBase must extends some
> > kind
> > > >> of Group. Did you try to simply try to extend GroupBase that is in
> > core?
> > > >>
> > > >> @Harbs, about to revert I think you refer to this concrete one?
> right?
> > > >>
> > > >> We should continue looking if more problems arise, and try to go
> > fixing
> > > >> them. Sometimes the solution I did will be not right, in other
> cases,
> > > can
> > > >> be a matter of adapt you applications. Have in mind, that Apache
> > Royale,
> > > >> can be modeled against a single Application (yours) and must have
> the
> > > >> general purpose in mind over the personal interest. So for me it's a
> > > matter
> > > >> of balance. The key point to pursue finaly is that we need
> separation
> > of
> > > >> Basic ui set from the rest of Royale to avoid to make people be
> > charged
> > > >> with things that are not really Core.
> > > >>
> > > >> Thanks
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> 2018-05-09 11:29 GMT+02:00 yishayw :
> > > >>
> > > >>> I changed it back so NodeElementBase extends Group. Let's continue
> > this
> > > >>> discussion, but we need our app to work...
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Sent from: http://apache-royale-development.20373.n8.nabble.com/
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Carlos Rovira
> > > >> http://about.me/carlosrovira
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> >
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki

Re: Container change

[Carlos Rovira]

Hi Piotr,

4 or 5 I think. some are temporal, others are necessary since are the
implementation of a particular UI set. At this time that class can be
somewhat identical to the Basic one, but there are plans for some of them
to be modified fo Jewel particular purposes

2018-05-09 13:24 GMT+02:00 Piotr Zarzycki :

> Carlos,
>
> How many classes you had to copy from Basic to Jewel so far ?
>
> Piotr
>
> 2018-05-09 13:15 GMT+02:00 Carlos Rovira :
>
> > I fixed this. Now we have what we all want.
> > thanks
> >
> > 2018-05-09 13:01 GMT+02:00 Carlos Rovira :
> >
> > > btw,
> > >
> > > for a change like this I think you should pass maven to ensure nothing
> > > broken:
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: GoogleMaps . *SUCCESS*
> > > [  1.042 s]
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: HTML ... *FAILURE*
> > > [  0.321 s]
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: HTML5 .. *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: JQuery . *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: Language ... *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: Material Design Lite *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: Mobile . *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: Reflection . *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: Network  *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: Storage  *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: XML  *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: Text ... *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: TLF  *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: RoyaleSite . *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: MXRoyale ... *SKIPPED*
> > >
> > > [*INFO*] Apache Royale: Framework: Libs: Jewel 0.9.4-SNAPSHOT *SKIPPED*
> > >
> > > GroupBase is not a solution since doesn't have the nesting
> functionality.
> > > I think we have only one way: Pass Group to Core, since is really Core
> > >
> > >
> > >
> > > 2018-05-09 12:47 GMT+02:00 Carlos Rovira :
> > >
> > >> Hi
> > >>
> > >> the problem was that HTML library was baking Basic library only due to
> > >> "NodeElementBase extends Group"
> > >> was Harbs how told me that NodeElementBase was not need to extend
> Group.
> > >> Then I changed it and looking into examples for this change didn't see
> > >> problems.
> > >>
> > >> Is normal something arise now, so NodeElementBase must extends some
> kind
> > >> of Group. Did you try to simply try to extend GroupBase that is in
> core?
> > >>
> > >> @Harbs, about to revert I think you refer to this concrete one? right?
> > >>
> > >> We should continue looking if more problems arise, and try to go
> fixing
> > >> them. Sometimes the solution I did will be not right, in other cases,
> > can
> > >> be a matter of adapt you applications. Have in mind, that Apache
> Royale,
> > >> can be modeled against a single Application (yours) and must have the
> > >> general purpose in mind over the personal interest. So for me it's a
> > matter
> > >> of balance. The key point to pursue finaly is that we need separation
> of
> > >> Basic ui set from the rest of Royale to avoid to make people be
> charged
> > >> with things that are not really Core.
> > >>
> > >> Thanks
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> 2018-05-09 11:29 GMT+02:00 yishayw :
> > >>
> > >>> I changed it back so NodeElementBase extends Group. Let's continue
> this
> > >>> discussion, but we need our app to work...
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Sent from: http://apache-royale-development.20373.n8.nabble.com/
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Carlos Rovira
> > >> http://about.me/carlosrovira
> > >>
> > >>
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Piotr Zarzycki]

Carlos,

How many classes you had to copy from Basic to Jewel so far ?

Piotr

2018-05-09 13:15 GMT+02:00 Carlos Rovira :

> I fixed this. Now we have what we all want.
> thanks
>
> 2018-05-09 13:01 GMT+02:00 Carlos Rovira :
>
> > btw,
> >
> > for a change like this I think you should pass maven to ensure nothing
> > broken:
> >
> > [*INFO*] Apache Royale: Framework: Libs: GoogleMaps . *SUCCESS*
> > [  1.042 s]
> >
> > [*INFO*] Apache Royale: Framework: Libs: HTML ... *FAILURE*
> > [  0.321 s]
> >
> > [*INFO*] Apache Royale: Framework: Libs: HTML5 .. *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: JQuery . *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: Language ... *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: Material Design Lite *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: Mobile . *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: Reflection . *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: Network  *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: Storage  *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: XML  *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: Text ... *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: TLF  *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: RoyaleSite . *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: MXRoyale ... *SKIPPED*
> >
> > [*INFO*] Apache Royale: Framework: Libs: Jewel 0.9.4-SNAPSHOT *SKIPPED*
> >
> > GroupBase is not a solution since doesn't have the nesting functionality.
> > I think we have only one way: Pass Group to Core, since is really Core
> >
> >
> >
> > 2018-05-09 12:47 GMT+02:00 Carlos Rovira :
> >
> >> Hi
> >>
> >> the problem was that HTML library was baking Basic library only due to
> >> "NodeElementBase extends Group"
> >> was Harbs how told me that NodeElementBase was not need to extend Group.
> >> Then I changed it and looking into examples for this change didn't see
> >> problems.
> >>
> >> Is normal something arise now, so NodeElementBase must extends some kind
> >> of Group. Did you try to simply try to extend GroupBase that is in core?
> >>
> >> @Harbs, about to revert I think you refer to this concrete one? right?
> >>
> >> We should continue looking if more problems arise, and try to go fixing
> >> them. Sometimes the solution I did will be not right, in other cases,
> can
> >> be a matter of adapt you applications. Have in mind, that Apache Royale,
> >> can be modeled against a single Application (yours) and must have the
> >> general purpose in mind over the personal interest. So for me it's a
> matter
> >> of balance. The key point to pursue finaly is that we need separation of
> >> Basic ui set from the rest of Royale to avoid to make people be charged
> >> with things that are not really Core.
> >>
> >> Thanks
> >>
> >>
> >>
> >>
> >>
> >> 2018-05-09 11:29 GMT+02:00 yishayw :
> >>
> >>> I changed it back so NodeElementBase extends Group. Let's continue this
> >>> discussion, but we need our app to work...
> >>>
> >>>
> >>>
> >>> --
> >>> Sent from: http://apache-royale-development.20373.n8.nabble.com/
> >>>
> >>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >>
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: Container change

[Carlos Rovira]

I fixed this. Now we have what we all want.
thanks

2018-05-09 13:01 GMT+02:00 Carlos Rovira :

> btw,
>
> for a change like this I think you should pass maven to ensure nothing
> broken:
>
> [*INFO*] Apache Royale: Framework: Libs: GoogleMaps . *SUCCESS*
> [  1.042 s]
>
> [*INFO*] Apache Royale: Framework: Libs: HTML ... *FAILURE*
> [  0.321 s]
>
> [*INFO*] Apache Royale: Framework: Libs: HTML5 .. *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: JQuery . *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: Language ... *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: Material Design Lite *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: Mobile . *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: Reflection . *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: Network  *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: Storage  *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: XML  *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: Text ... *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: TLF  *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: RoyaleSite . *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: MXRoyale ... *SKIPPED*
>
> [*INFO*] Apache Royale: Framework: Libs: Jewel 0.9.4-SNAPSHOT *SKIPPED*
>
> GroupBase is not a solution since doesn't have the nesting functionality.
> I think we have only one way: Pass Group to Core, since is really Core
>
>
>
> 2018-05-09 12:47 GMT+02:00 Carlos Rovira :
>
>> Hi
>>
>> the problem was that HTML library was baking Basic library only due to
>> "NodeElementBase extends Group"
>> was Harbs how told me that NodeElementBase was not need to extend Group.
>> Then I changed it and looking into examples for this change didn't see
>> problems.
>>
>> Is normal something arise now, so NodeElementBase must extends some kind
>> of Group. Did you try to simply try to extend GroupBase that is in core?
>>
>> @Harbs, about to revert I think you refer to this concrete one? right?
>>
>> We should continue looking if more problems arise, and try to go fixing
>> them. Sometimes the solution I did will be not right, in other cases, can
>> be a matter of adapt you applications. Have in mind, that Apache Royale,
>> can be modeled against a single Application (yours) and must have the
>> general purpose in mind over the personal interest. So for me it's a matter
>> of balance. The key point to pursue finaly is that we need separation of
>> Basic ui set from the rest of Royale to avoid to make people be charged
>> with things that are not really Core.
>>
>> Thanks
>>
>>
>>
>>
>>
>> 2018-05-09 11:29 GMT+02:00 yishayw :
>>
>>> I changed it back so NodeElementBase extends Group. Let's continue this
>>> discussion, but we need our app to work...
>>>
>>>
>>>
>>> --
>>> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>>>
>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

btw,

for a change like this I think you should pass maven to ensure nothing
broken:

[*INFO*] Apache Royale: Framework: Libs: GoogleMaps . *SUCCESS* [
1.042 s]

[*INFO*] Apache Royale: Framework: Libs: HTML ... *FAILURE* [
0.321 s]

[*INFO*] Apache Royale: Framework: Libs: HTML5 .. *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: JQuery . *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: Language ... *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: Material Design Lite *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: Mobile . *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: Reflection . *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: Network  *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: Storage  *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: XML  *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: Text ... *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: TLF  *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: RoyaleSite . *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: MXRoyale ... *SKIPPED*

[*INFO*] Apache Royale: Framework: Libs: Jewel 0.9.4-SNAPSHOT *SKIPPED*

GroupBase is not a solution since doesn't have the nesting functionality. I
think we have only one way: Pass Group to Core, since is really Core



2018-05-09 12:47 GMT+02:00 Carlos Rovira :

> Hi
>
> the problem was that HTML library was baking Basic library only due to
> "NodeElementBase extends Group"
> was Harbs how told me that NodeElementBase was not need to extend Group.
> Then I changed it and looking into examples for this change didn't see
> problems.
>
> Is normal something arise now, so NodeElementBase must extends some kind
> of Group. Did you try to simply try to extend GroupBase that is in core?
>
> @Harbs, about to revert I think you refer to this concrete one? right?
>
> We should continue looking if more problems arise, and try to go fixing
> them. Sometimes the solution I did will be not right, in other cases, can
> be a matter of adapt you applications. Have in mind, that Apache Royale,
> can be modeled against a single Application (yours) and must have the
> general purpose in mind over the personal interest. So for me it's a matter
> of balance. The key point to pursue finaly is that we need separation of
> Basic ui set from the rest of Royale to avoid to make people be charged
> with things that are not really Core.
>
> Thanks
>
>
>
>
>
> 2018-05-09 11:29 GMT+02:00 yishayw :
>
>> I changed it back so NodeElementBase extends Group. Let's continue this
>> discussion, but we need our app to work...
>>
>>
>>
>> --
>> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Hi

the problem was that HTML library was baking Basic library only due to
"NodeElementBase extends Group"
was Harbs how told me that NodeElementBase was not need to extend Group.
Then I changed it and looking into examples for this change didn't see
problems.

Is normal something arise now, so NodeElementBase must extends some kind of
Group. Did you try to simply try to extend GroupBase that is in core?

@Harbs, about to revert I think you refer to this concrete one? right?

We should continue looking if more problems arise, and try to go fixing
them. Sometimes the solution I did will be not right, in other cases, can
be a matter of adapt you applications. Have in mind, that Apache Royale,
can be modeled against a single Application (yours) and must have the
general purpose in mind over the personal interest. So for me it's a matter
of balance. The key point to pursue finaly is that we need separation of
Basic ui set from the rest of Royale to avoid to make people be charged
with things that are not really Core.

Thanks





2018-05-09 11:29 GMT+02:00 yishayw :

> I changed it back so NodeElementBase extends Group. Let's continue this
> discussion, but we need our app to work...
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[yishayw]

I changed it back so NodeElementBase extends Group. Let's continue this
discussion, but we need our app to work...



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Container change

[Harbs]

Simply put, NodeElementBase needs to extend Group and not UIBase.

The reason for this (which I forgot when we discussed it earlier) is that all 
HTML elements can have nested elements. Group initializes children, while 
UIBase does not.

Carlos, are you going to revert this change, or should we do it?

Thanks,
Harbs

> On May 9, 2018, at 12:18 PM, yishayw  wrote:
> 
> If we want HTML elements to contain other elements they need to extend Group
> or something similar. We depend on that in various places in our app.
> 
> Carlos, how are we supposed to nest HTML elements now?
> 
> Thanks.
> 
> 
> 
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Container change

[yishayw]

If we want HTML elements to contain other elements they need to extend Group
or something similar. We depend on that in various places in our app.

Carlos, how are we supposed to nest HTML elements now?

Thanks.



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Container change

[Alex Harui]

Hi Carlos,

IMO, there is no good technical reason to eliminate Jewel's dependencies on 
Basic.  Especially if it results in duplicating code.

There are probably some classes that could use some refactoring to use 
interfaces more.  So it's been good to see you move things from Basic to Core 
to see what some of those are, and to better understand what Jewel was using 
from Basic to make sure that Jewel doesn't drag in stuff that Jewel doesn't 
need.

But Beads in Basic are simply intended to be the simplest implementation of 
some functionality for JS and SWF.  And if that's all that Jewel needs for one 
of its components, then it should be ok.  It is not, IMO, ok, to just make a 
copy to avoid having a project dependency.  I don’t think you should be worried 
about what projects Jewel depends on.  The only thing that really matters is, 
when you build a Jewel app, did any classes from Basic get linked in that you 
don't need?  If so, that should be cleaned up.

My 2 cents,
-Alex

On 5/7/18, 9:22 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" 
 wrote:

Hi Peter, Alex,

I'm with you in that concept, but to be real Basic should be really an
agnostic UI set and not needed always. And that was that happen before the
refactor I did.
So Maybe the problem is just about to refactor some classes to use
interfaces instead of specific implementations. I think we can have all, to
have a real core library, and to make Basic, Jewel, and other UI sets
siblings and doesn't need one to the other by default (that should be a
decision of the user to mix them).

For example, we had UIBase part of Basic until I refactored to Core some
days ago...I think we all agree that was needed, but as well there's a
"core" package with in Basic that had many Core functionality, I only
refactored what needed to make the actual separation.

Maybe we need an intermediate library between Core and the rest of UI
sets... don't know.

I think Alex and you know build that so maybe you know better than me the
changes to be made, and as we talked in the last weeks, we still needed
some changes to be made in some parts like you and Alex suggested (maybe
each of you know what want to improve).

What I really need with this change is not to depend from Basic. I get to
that way with this refactor, maybe it should be refined to make all
concepts we all want, and can't be a work of what I did, maybe a team work
between us.

Thanks

Carlos



2018-05-07 17:00 GMT+02:00 Peter Ent :

> I agree, to some extent, with Alex on this. One of the reasons I played
> around with the Simple project was that I thought Core was pretty much 
good
> as-is. I thought IUIBase needed some more stuff, but Core is pretty
> universal. As such, I was able to build a new framework on top of it (with
> the minor changes). If you move things like ContainerBase into it, it 
makes
> Core less adaptable to future ideas.
>
> For me, the real power of Royale is the compiler + Core. With that, you
> can go in many directions. Plus, if one day there is an ActionScript to
> Swift or ActionScript to WebAssembly, you would want Core to be as
> universal as possible.
>
> I strongly urge you to keep Core as agnostic as possible. Or make
> something underneath it.
>
> —peter
>
> > On May 7, 2018, at 1:25 AM, Alex Harui  wrote:
> >
> > For something to be in Core, it really should be a "universal
> implementation", meaning it contains code that just about every component
> set will need.
> >
> > I don't think Container is universal.  ContainerBase might be.
> > ItemRendererMouseController and DataItemRenderer?  Not sure.
> >
> > FWIW, trying to eliminate all dependencies from Jewel to Basic doesn't
> make sense to me.  Especially if it is going to result in duplication of
> code.  So what if Jewel components want to use some Basic class?  
Sometimes
> a Basic implementation is all you need.
> >
> > My 2 cents,
> > -Alex
> >
> > On 5/6/18, 10:28 AM, "carlos.rov...@gmail.com  carlos.rov...@gmail.com> on behalf of Carlos Rovira" <
> carlos.rov...@gmail.com  on behalf of
> carlosrov...@apache.org > wrote:
> >
> >Hi Harbs,
> >
> >just commited a change that return the controller to Basic to html
> package
> >let me now if that fixes your problem
> >
> >thanks
> >
> >Carlos
> >
> >
> >2018-05-06 12:25 GMT+02:00 Carlos Rovira :
> >
> >> Just returned Container to Basic without problem.
> >>
> >> But seems 

Re: Container change

[Carlos Rovira]

Hi Peter, Alex,

I'm with you in that concept, but to be real Basic should be really an
agnostic UI set and not needed always. And that was that happen before the
refactor I did.
So Maybe the problem is just about to refactor some classes to use
interfaces instead of specific implementations. I think we can have all, to
have a real core library, and to make Basic, Jewel, and other UI sets
siblings and doesn't need one to the other by default (that should be a
decision of the user to mix them).

For example, we had UIBase part of Basic until I refactored to Core some
days ago...I think we all agree that was needed, but as well there's a
"core" package with in Basic that had many Core functionality, I only
refactored what needed to make the actual separation.

Maybe we need an intermediate library between Core and the rest of UI
sets... don't know.

I think Alex and you know build that so maybe you know better than me the
changes to be made, and as we talked in the last weeks, we still needed
some changes to be made in some parts like you and Alex suggested (maybe
each of you know what want to improve).

What I really need with this change is not to depend from Basic. I get to
that way with this refactor, maybe it should be refined to make all
concepts we all want, and can't be a work of what I did, maybe a team work
between us.

Thanks

Carlos



2018-05-07 17:00 GMT+02:00 Peter Ent :

> I agree, to some extent, with Alex on this. One of the reasons I played
> around with the Simple project was that I thought Core was pretty much good
> as-is. I thought IUIBase needed some more stuff, but Core is pretty
> universal. As such, I was able to build a new framework on top of it (with
> the minor changes). If you move things like ContainerBase into it, it makes
> Core less adaptable to future ideas.
>
> For me, the real power of Royale is the compiler + Core. With that, you
> can go in many directions. Plus, if one day there is an ActionScript to
> Swift or ActionScript to WebAssembly, you would want Core to be as
> universal as possible.
>
> I strongly urge you to keep Core as agnostic as possible. Or make
> something underneath it.
>
> —peter
>
> > On May 7, 2018, at 1:25 AM, Alex Harui  wrote:
> >
> > For something to be in Core, it really should be a "universal
> implementation", meaning it contains code that just about every component
> set will need.
> >
> > I don't think Container is universal.  ContainerBase might be.
> > ItemRendererMouseController and DataItemRenderer?  Not sure.
> >
> > FWIW, trying to eliminate all dependencies from Jewel to Basic doesn't
> make sense to me.  Especially if it is going to result in duplication of
> code.  So what if Jewel components want to use some Basic class?  Sometimes
> a Basic implementation is all you need.
> >
> > My 2 cents,
> > -Alex
> >
> > On 5/6/18, 10:28 AM, "carlos.rov...@gmail.com  carlos.rov...@gmail.com> on behalf of Carlos Rovira" <
> carlos.rov...@gmail.com  on behalf of
> carlosrov...@apache.org > wrote:
> >
> >Hi Harbs,
> >
> >just commited a change that return the controller to Basic to html
> package
> >let me now if that fixes your problem
> >
> >thanks
> >
> >Carlos
> >
> >
> >2018-05-06 12:25 GMT+02:00 Carlos Rovira :
> >
> >> Just returned Container to Basic without problem.
> >>
> >> But seems to me that this change should not make any problem at all for
> >> anyone, since is in the same package (core) and all examples build
> without
> >> problem, so any other App should as well build without any change.
> >>
> >>
> >>
> >>
> >> 2018-05-06 12:00 GMT+02:00 Carlos Rovira :
> >>
> >>> Hi
> >>>
> >>> dealing with ItemRendererMouseController there's a dependency in
> >>> DataItemRenderer, and that was needed to move to Core, since is core in
> >>> itself. Thinking about it that controller seems to have a very core
> >>> functionality, so IMHO is that is better to upgrade Apps changing
> "html"
> >>> package to "core". If I'm not missing something that change should be
> >>> very straight forward to do (I made lots of this in examples, and use
> to be
> >>> one or two places)
> >>>
> >>> I'll go to revise Container
> >>>
> >>>
> >>>
> >>> 2018-05-06 11:39 GMT+02:00 Carlos Rovira :
> >>>
>  Hi Piotr,
> 
>  I'm using HTML only for some headings, at the moment, but as Harbs
> said
>  in the other thread about HTML, it was depending from Group and that
> wasn't
>  needed, and that make HTML pull the complete Basic dependency when not
>  required, and that's made lots of CSS be linked.
> 
>  So HTML for me was only used to use some H3, headings, and SPAN
> 
>  In the other hand the controller seems to me more from Basic so I
> think
>  is ok to return it to Basic, it doesn't nothing to do 

Re: Container change

[Peter Ent]

I agree, to some extent, with Alex on this. One of the reasons I played around 
with the Simple project was that I thought Core was pretty much good as-is. I 
thought IUIBase needed some more stuff, but Core is pretty universal. As such, 
I was able to build a new framework on top of it (with the minor changes). If 
you move things like ContainerBase into it, it makes Core less adaptable to 
future ideas. 

For me, the real power of Royale is the compiler + Core. With that, you can go 
in many directions. Plus, if one day there is an ActionScript to Swift or 
ActionScript to WebAssembly, you would want Core to be as universal as possible.

I strongly urge you to keep Core as agnostic as possible. Or make something 
underneath it.

—peter

> On May 7, 2018, at 1:25 AM, Alex Harui  wrote:
> 
> For something to be in Core, it really should be a "universal 
> implementation", meaning it contains code that just about every component set 
> will need.
> 
> I don't think Container is universal.  ContainerBase might be.
> ItemRendererMouseController and DataItemRenderer?  Not sure.
> 
> FWIW, trying to eliminate all dependencies from Jewel to Basic doesn't make 
> sense to me.  Especially if it is going to result in duplication of code.  So 
> what if Jewel components want to use some Basic class?  Sometimes a Basic 
> implementation is all you need.
> 
> My 2 cents,
> -Alex
> 
> On 5/6/18, 10:28 AM, "carlos.rov...@gmail.com 
>  on behalf of Carlos Rovira" 
>  on behalf of 
> carlosrov...@apache.org > wrote:
> 
>Hi Harbs,
> 
>just commited a change that return the controller to Basic to html package
>let me now if that fixes your problem
> 
>thanks
> 
>Carlos
> 
> 
>2018-05-06 12:25 GMT+02:00 Carlos Rovira :
> 
>> Just returned Container to Basic without problem.
>> 
>> But seems to me that this change should not make any problem at all for
>> anyone, since is in the same package (core) and all examples build without
>> problem, so any other App should as well build without any change.
>> 
>> 
>> 
>> 
>> 2018-05-06 12:00 GMT+02:00 Carlos Rovira :
>> 
>>> Hi
>>> 
>>> dealing with ItemRendererMouseController there's a dependency in
>>> DataItemRenderer, and that was needed to move to Core, since is core in
>>> itself. Thinking about it that controller seems to have a very core
>>> functionality, so IMHO is that is better to upgrade Apps changing "html"
>>> package to "core". If I'm not missing something that change should be
>>> very straight forward to do (I made lots of this in examples, and use to be
>>> one or two places)
>>> 
>>> I'll go to revise Container
>>> 
>>> 
>>> 
>>> 2018-05-06 11:39 GMT+02:00 Carlos Rovira :
>>> 
 Hi Piotr,
 
 I'm using HTML only for some headings, at the moment, but as Harbs said
 in the other thread about HTML, it was depending from Group and that wasn't
 needed, and that make HTML pull the complete Basic dependency when not
 required, and that's made lots of CSS be linked.
 
 So HTML for me was only used to use some H3, headings, and SPAN
 
 In the other hand the controller seems to me more from Basic so I think
 is ok to return it to Basic, it doesn't nothing to do with HTML.
 
 In the end some last fixes are normal in a refactor like this.
 
 thanks! :)
 
 2018-05-06 10:09 GMT+02:00 Piotr Zarzycki :
 
> I'm a bit afraid to pull down changes. :) Let's think a bit more about
> that. Carlos wanted to totally separate each module. He didn't want to
> have
> dependency in Jewel from Basic.
> 
> As I understand he was using HTML module which seems to be dependent on
> Basic as well.
> 
> His changes are get rid off Basic things not only from Jewel, but also
> from
> HTML which makes Jewel clear - Am I right Carlos?
> 
> If yes - what does that mean that such controller like
> ItemRendererMouseController is in HTML?
> 
> Is it mean that it does use only HTML module thing not Basic at all? It
> is
> JS only controller?
> 
> Piotr
> 
> On Sun, May 6, 2018, 10:02 AM Harbs  wrote:
> 
>> Actually my whole app is broken now… :-(
>> 
>>> On May 6, 2018, at 10:14 AM, Harbs  wrote:
>>> 
>>> org.apache.royale.html.beads.controllers.ItemRendererMouseController
> was
>> changed to the core package as well (which also broke my app)
>>> 
>>> I did not notice discussion about this. Why the package name
> change? How
>> many more changes were there like this?
>>> 
>>> Harbs
>>> 
 On May 6, 2018, at 10:07 AM, Harbs  wrote:
 
 

Re: Container change

[Carlos Rovira]

Hi Alex,

2018-05-07 7:25 GMT+02:00 Alex Harui :

> For something to be in Core, it really should be a "universal
> implementation", meaning it contains code that just about every component
> set will need.
>

that's what I tried, and was what I have in mind. So I think we're aligned
in concept


>
> I don't think Container is universal.  ContainerBase might be.
>

Right, Container is now in Basic and ContainerBase is in Core. I think
that's how it should be.


> ItemRendererMouseController and DataItemRenderer?  Not sure.
>

As this is a bit unclear for all I refactored to
ItemRendererMouseController to IBeadController, that I think is better and
returned ItemRendererMouseController to basic, and Jewel has now it's own
copy. My personal thinking is that ItemRendererMouseController should be in
core, since I don't see much specialization here and don't see the reason
to have this code duplicated, but Harbs and Yishay complain about package
refactor, but I think we should still expect some changes of this style as
we approach a 1.0 version, and then probably will settle.
Since are changes very easy to do in final Apps, I think we should balance
a bit to have the best organization now, since more later could be very
complicated to do such thing. So time is now, and although we see our app
break, think that solution should be easy to fix.

For DataItemRenderer since I didn't see complains I left in Core, since it
had more implications. But if people complains I can invest time to return
to Basic.


>
> FWIW, trying to eliminate all dependencies from Jewel to Basic doesn't
> make sense to me.  Especially if it is going to result in duplication of
> code.  So what if Jewel components want to use some Basic class?  Sometimes
> a Basic implementation is all you need.
>

Here I not agree, and surprises me since I read lots of emails from you
talking that "we'll be creating more UI sets", that's what we did we some
experiments (Flat,CreateJS), and full set (MDL), and now (Jewel). So Basic
should be just other one. That's at least what I understand from your words
through this years.

Jewel born from Basic since at that moment I was thinking in make all
components inherit Basic, and as well for a matter of convenience and make
it work sooner. In fact, Jewel is the work done on Basic on steroids, is
just a continuation.

But as we talked and developed, it was clear that Jewel should take its own
path, and I think is not good (or a bad design for us) if we obligate the
user to link a library that is only there due to the code not well
organized. We talked a lot in the last weeks that we need to pass UIBase to
Core, and the same happen with other classes that are clearly Core. If
people wants to use in its Application Jewel and then need some Basic
functionality, he can do...but I don't want people to be obligated to do
that.

A part from that in doing this, I get 40% less size in Jewel Applications,
and that means that we have code in CSSs and JS that was linked and not
used. I don't want Jewel users to carry things they really need, I think we
all wanted that.

Thanks.

Carlos



>
> My 2 cents,
> -Alex
>
> On 5/6/18, 10:28 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira" 
> wrote:
>
> Hi Harbs,
>
> just commited a change that return the controller to Basic to html
> package
> let me now if that fixes your problem
>
> thanks
>
> Carlos
>
>
> 2018-05-06 12:25 GMT+02:00 Carlos Rovira :
>
> > Just returned Container to Basic without problem.
> >
> > But seems to me that this change should not make any problem at all
> for
> > anyone, since is in the same package (core) and all examples build
> without
> > problem, so any other App should as well build without any change.
> >
> >
> >
> >
> > 2018-05-06 12:00 GMT+02:00 Carlos Rovira :
> >
> >> Hi
> >>
> >> dealing with ItemRendererMouseController there's a dependency in
> >> DataItemRenderer, and that was needed to move to Core, since is
> core in
> >> itself. Thinking about it that controller seems to have a very core
> >> functionality, so IMHO is that is better to upgrade Apps changing
> "html"
> >> package to "core". If I'm not missing something that change should
> be
> >> very straight forward to do (I made lots of this in examples, and
> use to be
> >> one or two places)
> >>
> >> I'll go to revise Container
> >>
> >>
> >>
> >> 2018-05-06 11:39 GMT+02:00 Carlos Rovira :
> >>
> >>> Hi Piotr,
> >>>
> >>> I'm using HTML only for some headings, at the moment, but as Harbs
> said
> >>> in the other thread about HTML, it was depending from Group and
> that wasn't
> >>> needed, and that make HTML pull the complete Basic dependency when
> not
> >>> 

Re: Container change

[Carlos Rovira]

Hi Harbs,

just commited a change that return the controller to Basic to html package
let me now if that fixes your problem

thanks

Carlos


2018-05-06 12:25 GMT+02:00 Carlos Rovira :

> Just returned Container to Basic without problem.
>
> But seems to me that this change should not make any problem at all for
> anyone, since is in the same package (core) and all examples build without
> problem, so any other App should as well build without any change.
>
>
>
>
> 2018-05-06 12:00 GMT+02:00 Carlos Rovira :
>
>> Hi
>>
>> dealing with ItemRendererMouseController there's a dependency in
>> DataItemRenderer, and that was needed to move to Core, since is core in
>> itself. Thinking about it that controller seems to have a very core
>> functionality, so IMHO is that is better to upgrade Apps changing "html"
>> package to "core". If I'm not missing something that change should be
>> very straight forward to do (I made lots of this in examples, and use to be
>> one or two places)
>>
>> I'll go to revise Container
>>
>>
>>
>> 2018-05-06 11:39 GMT+02:00 Carlos Rovira :
>>
>>> Hi Piotr,
>>>
>>> I'm using HTML only for some headings, at the moment, but as Harbs said
>>> in the other thread about HTML, it was depending from Group and that wasn't
>>> needed, and that make HTML pull the complete Basic dependency when not
>>> required, and that's made lots of CSS be linked.
>>>
>>> So HTML for me was only used to use some H3, headings, and SPAN
>>>
>>> In the other hand the controller seems to me more from Basic so I think
>>> is ok to return it to Basic, it doesn't nothing to do with HTML.
>>>
>>> In the end some last fixes are normal in a refactor like this.
>>>
>>> thanks! :)
>>>
>>> 2018-05-06 10:09 GMT+02:00 Piotr Zarzycki :
>>>
 I'm a bit afraid to pull down changes. :) Let's think a bit more about
 that. Carlos wanted to totally separate each module. He didn't want to
 have
 dependency in Jewel from Basic.

 As I understand he was using HTML module which seems to be dependent on
 Basic as well.

 His changes are get rid off Basic things not only from Jewel, but also
 from
 HTML which makes Jewel clear - Am I right Carlos?

 If yes - what does that mean that such controller like
 ItemRendererMouseController is in HTML?

 Is it mean that it does use only HTML module thing not Basic at all? It
 is
 JS only controller?

 Piotr

 On Sun, May 6, 2018, 10:02 AM Harbs  wrote:

 > Actually my whole app is broken now… :-(
 >
 > > On May 6, 2018, at 10:14 AM, Harbs  wrote:
 > >
 > > org.apache.royale.html.beads.controllers.ItemRendererMouseController
 was
 > changed to the core package as well (which also broke my app)
 > >
 > > I did not notice discussion about this. Why the package name
 change? How
 > many more changes were there like this?
 > >
 > > Harbs
 > >
 > >> On May 6, 2018, at 10:07 AM, Harbs  wrote:
 > >>
 > >> Why did Container become org.apache.royale.core.Container instead
 of
 > org.apache.royale.html.Container?
 > >>
 > >> Why is Container Core at all?
 > >>
 > >> This change broke my app. While it’s not a big deal to fix it, I
 don’t
 > understand why the change. Unless we decide on a wholesale change of
 > components, this seems like a gratuitous breaking change for no good
 reason.
 > >>
 > >> Harbs
 > >
 >
 >

>>>
>>>
>>>
>>> --
>>> Carlos Rovira
>>> http://about.me/carlosrovira
>>>
>>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Just returned Container to Basic without problem.

But seems to me that this change should not make any problem at all for
anyone, since is in the same package (core) and all examples build without
problem, so any other App should as well build without any change.




2018-05-06 12:00 GMT+02:00 Carlos Rovira :

> Hi
>
> dealing with ItemRendererMouseController there's a dependency in
> DataItemRenderer, and that was needed to move to Core, since is core in
> itself. Thinking about it that controller seems to have a very core
> functionality, so IMHO is that is better to upgrade Apps changing "html"
> package to "core". If I'm not missing something that change should be
> very straight forward to do (I made lots of this in examples, and use to be
> one or two places)
>
> I'll go to revise Container
>
>
>
> 2018-05-06 11:39 GMT+02:00 Carlos Rovira :
>
>> Hi Piotr,
>>
>> I'm using HTML only for some headings, at the moment, but as Harbs said
>> in the other thread about HTML, it was depending from Group and that wasn't
>> needed, and that make HTML pull the complete Basic dependency when not
>> required, and that's made lots of CSS be linked.
>>
>> So HTML for me was only used to use some H3, headings, and SPAN
>>
>> In the other hand the controller seems to me more from Basic so I think
>> is ok to return it to Basic, it doesn't nothing to do with HTML.
>>
>> In the end some last fixes are normal in a refactor like this.
>>
>> thanks! :)
>>
>> 2018-05-06 10:09 GMT+02:00 Piotr Zarzycki :
>>
>>> I'm a bit afraid to pull down changes. :) Let's think a bit more about
>>> that. Carlos wanted to totally separate each module. He didn't want to
>>> have
>>> dependency in Jewel from Basic.
>>>
>>> As I understand he was using HTML module which seems to be dependent on
>>> Basic as well.
>>>
>>> His changes are get rid off Basic things not only from Jewel, but also
>>> from
>>> HTML which makes Jewel clear - Am I right Carlos?
>>>
>>> If yes - what does that mean that such controller like
>>> ItemRendererMouseController is in HTML?
>>>
>>> Is it mean that it does use only HTML module thing not Basic at all? It
>>> is
>>> JS only controller?
>>>
>>> Piotr
>>>
>>> On Sun, May 6, 2018, 10:02 AM Harbs  wrote:
>>>
>>> > Actually my whole app is broken now… :-(
>>> >
>>> > > On May 6, 2018, at 10:14 AM, Harbs  wrote:
>>> > >
>>> > > org.apache.royale.html.beads.controllers.ItemRendererMouseController
>>> was
>>> > changed to the core package as well (which also broke my app)
>>> > >
>>> > > I did not notice discussion about this. Why the package name change?
>>> How
>>> > many more changes were there like this?
>>> > >
>>> > > Harbs
>>> > >
>>> > >> On May 6, 2018, at 10:07 AM, Harbs  wrote:
>>> > >>
>>> > >> Why did Container become org.apache.royale.core.Container instead
>>> of
>>> > org.apache.royale.html.Container?
>>> > >>
>>> > >> Why is Container Core at all?
>>> > >>
>>> > >> This change broke my app. While it’s not a big deal to fix it, I
>>> don’t
>>> > understand why the change. Unless we decide on a wholesale change of
>>> > components, this seems like a gratuitous breaking change for no good
>>> reason.
>>> > >>
>>> > >> Harbs
>>> > >
>>> >
>>> >
>>>
>>
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Hi

dealing with ItemRendererMouseController there's a dependency in
DataItemRenderer, and that was needed to move to Core, since is core in
itself. Thinking about it that controller seems to have a very core
functionality, so IMHO is that is better to upgrade Apps changing "html"
package to "core". If I'm not missing something that change should be
very straight forward to do (I made lots of this in examples, and use to be
one or two places)

I'll go to revise Container



2018-05-06 11:39 GMT+02:00 Carlos Rovira :

> Hi Piotr,
>
> I'm using HTML only for some headings, at the moment, but as Harbs said in
> the other thread about HTML, it was depending from Group and that wasn't
> needed, and that make HTML pull the complete Basic dependency when not
> required, and that's made lots of CSS be linked.
>
> So HTML for me was only used to use some H3, headings, and SPAN
>
> In the other hand the controller seems to me more from Basic so I think is
> ok to return it to Basic, it doesn't nothing to do with HTML.
>
> In the end some last fixes are normal in a refactor like this.
>
> thanks! :)
>
> 2018-05-06 10:09 GMT+02:00 Piotr Zarzycki :
>
>> I'm a bit afraid to pull down changes. :) Let's think a bit more about
>> that. Carlos wanted to totally separate each module. He didn't want to
>> have
>> dependency in Jewel from Basic.
>>
>> As I understand he was using HTML module which seems to be dependent on
>> Basic as well.
>>
>> His changes are get rid off Basic things not only from Jewel, but also
>> from
>> HTML which makes Jewel clear - Am I right Carlos?
>>
>> If yes - what does that mean that such controller like
>> ItemRendererMouseController is in HTML?
>>
>> Is it mean that it does use only HTML module thing not Basic at all? It is
>> JS only controller?
>>
>> Piotr
>>
>> On Sun, May 6, 2018, 10:02 AM Harbs  wrote:
>>
>> > Actually my whole app is broken now… :-(
>> >
>> > > On May 6, 2018, at 10:14 AM, Harbs  wrote:
>> > >
>> > > org.apache.royale.html.beads.controllers.ItemRendererMouseController
>> was
>> > changed to the core package as well (which also broke my app)
>> > >
>> > > I did not notice discussion about this. Why the package name change?
>> How
>> > many more changes were there like this?
>> > >
>> > > Harbs
>> > >
>> > >> On May 6, 2018, at 10:07 AM, Harbs  wrote:
>> > >>
>> > >> Why did Container become org.apache.royale.core.Container instead of
>> > org.apache.royale.html.Container?
>> > >>
>> > >> Why is Container Core at all?
>> > >>
>> > >> This change broke my app. While it’s not a big deal to fix it, I
>> don’t
>> > understand why the change. Unless we decide on a wholesale change of
>> > components, this seems like a gratuitous breaking change for no good
>> reason.
>> > >>
>> > >> Harbs
>> > >
>> >
>> >
>>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Hi Piotr,

I'm using HTML only for some headings, at the moment, but as Harbs said in
the other thread about HTML, it was depending from Group and that wasn't
needed, and that make HTML pull the complete Basic dependency when not
required, and that's made lots of CSS be linked.

So HTML for me was only used to use some H3, headings, and SPAN

In the other hand the controller seems to me more from Basic so I think is
ok to return it to Basic, it doesn't nothing to do with HTML.

In the end some last fixes are normal in a refactor like this.

thanks! :)

2018-05-06 10:09 GMT+02:00 Piotr Zarzycki :

> I'm a bit afraid to pull down changes. :) Let's think a bit more about
> that. Carlos wanted to totally separate each module. He didn't want to have
> dependency in Jewel from Basic.
>
> As I understand he was using HTML module which seems to be dependent on
> Basic as well.
>
> His changes are get rid off Basic things not only from Jewel, but also from
> HTML which makes Jewel clear - Am I right Carlos?
>
> If yes - what does that mean that such controller like
> ItemRendererMouseController is in HTML?
>
> Is it mean that it does use only HTML module thing not Basic at all? It is
> JS only controller?
>
> Piotr
>
> On Sun, May 6, 2018, 10:02 AM Harbs  wrote:
>
> > Actually my whole app is broken now… :-(
> >
> > > On May 6, 2018, at 10:14 AM, Harbs  wrote:
> > >
> > > org.apache.royale.html.beads.controllers.ItemRendererMouseController
> was
> > changed to the core package as well (which also broke my app)
> > >
> > > I did not notice discussion about this. Why the package name change?
> How
> > many more changes were there like this?
> > >
> > > Harbs
> > >
> > >> On May 6, 2018, at 10:07 AM, Harbs  wrote:
> > >>
> > >> Why did Container become org.apache.royale.core.Container instead of
> > org.apache.royale.html.Container?
> > >>
> > >> Why is Container Core at all?
> > >>
> > >> This change broke my app. While it’s not a big deal to fix it, I don’t
> > understand why the change. Unless we decide on a wholesale change of
> > components, this seems like a gratuitous breaking change for no good
> reason.
> > >>
> > >> Harbs
> > >
> >
> >
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Carlos Rovira]

Hi,

sure, some of the classes can be in "html" instead of "core", but as the
lib is "Core" I though it was the right choice. If it's only a matter of
package change in applications like a did in all the examples affected, I
think this means only a few changes.

For Container I want to return in the next hours to Basic since I think it
should be in Basic, but ContainerBase in "Core" is ok.

For the controller, I can return as well to basic and make a copy for Jewel.

Let me know if you find more problems like this. I think a refactor like
this is very beneficial for us, and we all should think that use to be no
transparent and although I tried to do my best some things should arise.
In the other hand, I fixed many things that was working due to some
coincidences like many projects without Basic library dependency that was
compiling magically

2018-05-06 10:42 GMT+02:00 yishayw :

>
>
> Piotr Zarzycki wrote
> > If yes - what does that mean that such controller like
> > ItemRendererMouseController is in HTML?
>
> It's only there by name, the source is under Basic (which makes sense to
> me,
> I think controllers are part of the component set).
>
> I'm not sure why it can't be named
> org.apache.royale.basic.beads.controllers.ItemRendererMouseController.
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>



-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[yishayw]

Piotr Zarzycki wrote
> If yes - what does that mean that such controller like
> ItemRendererMouseController is in HTML?

It's only there by name, the source is under Basic (which makes sense to me,
I think controllers are part of the component set).

I'm not sure why it can't be named
org.apache.royale.basic.beads.controllers.ItemRendererMouseController.



--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: Container change

[Piotr Zarzycki]

I'm a bit afraid to pull down changes. :) Let's think a bit more about
that. Carlos wanted to totally separate each module. He didn't want to have
dependency in Jewel from Basic.

As I understand he was using HTML module which seems to be dependent on
Basic as well.

His changes are get rid off Basic things not only from Jewel, but also from
HTML which makes Jewel clear - Am I right Carlos?

If yes - what does that mean that such controller like
ItemRendererMouseController is in HTML?

Is it mean that it does use only HTML module thing not Basic at all? It is
JS only controller?

Piotr

On Sun, May 6, 2018, 10:02 AM Harbs  wrote:

> Actually my whole app is broken now… :-(
>
> > On May 6, 2018, at 10:14 AM, Harbs  wrote:
> >
> > org.apache.royale.html.beads.controllers.ItemRendererMouseController was
> changed to the core package as well (which also broke my app)
> >
> > I did not notice discussion about this. Why the package name change? How
> many more changes were there like this?
> >
> > Harbs
> >
> >> On May 6, 2018, at 10:07 AM, Harbs  wrote:
> >>
> >> Why did Container become org.apache.royale.core.Container instead of
> org.apache.royale.html.Container?
> >>
> >> Why is Container Core at all?
> >>
> >> This change broke my app. While it’s not a big deal to fix it, I don’t
> understand why the change. Unless we decide on a wholesale change of
> components, this seems like a gratuitous breaking change for no good reason.
> >>
> >> Harbs
> >
>
>

Re: Container change

[Harbs]

Actually my whole app is broken now… :-(

> On May 6, 2018, at 10:14 AM, Harbs  wrote:
> 
> org.apache.royale.html.beads.controllers.ItemRendererMouseController was 
> changed to the core package as well (which also broke my app)
> 
> I did not notice discussion about this. Why the package name change? How many 
> more changes were there like this?
> 
> Harbs
> 
>> On May 6, 2018, at 10:07 AM, Harbs  wrote:
>> 
>> Why did Container become org.apache.royale.core.Container instead of 
>> org.apache.royale.html.Container?
>> 
>> Why is Container Core at all?
>> 
>> This change broke my app. While it’s not a big deal to fix it, I don’t 
>> understand why the change. Unless we decide on a wholesale change of 
>> components, this seems like a gratuitous breaking change for no good reason.
>> 
>> Harbs
> 

Re: Container change

[Carlos Rovira]

Hi Harbs,

I'm seeing as well that Container can return to Basic, and ContainerBase be
in Core. I think it was part of the hard fight I had to do to deal with the
refactoring.
ItemRendererMouseController not sure, maybe can be as well in Basic and a
copy in Jewel... I'll be in my computer in an hour or so and can look at it.

As I said in my email, normaly this problems can be fixed just upgrading
package namespaces to the new ones. I think some isolated issues can arise
like this, but I think this change is important, more thinking to reach a
1.0 and settle the API for many time, so for that reason I want to do this
now that Jewel is still with few components.

btw, just to notice, I'm seeing all jewel examples reduced to 40% in size
thanks to this change. Since Basic was carrying a lot of unused stuff.



2018-05-06 9:14 GMT+02:00 Harbs :

> org.apache.royale.html.beads.controllers.ItemRendererMouseController was
> changed to the core package as well (which also broke my app)
>
> I did not notice discussion about this. Why the package name change? How
> many more changes were there like this?
>
> Harbs
>
> > On May 6, 2018, at 10:07 AM, Harbs  wrote:
> >
> > Why did Container become org.apache.royale.core.Container instead of
> org.apache.royale.html.Container?
> >
> > Why is Container Core at all?
> >
> > This change broke my app. While it’s not a big deal to fix it, I don’t
> understand why the change. Unless we decide on a wholesale change of
> components, this seems like a gratuitous breaking change for no good reason.
> >
> > Harbs
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Container change

[Harbs]

org.apache.royale.html.beads.controllers.ItemRendererMouseController was 
changed to the core package as well (which also broke my app)

I did not notice discussion about this. Why the package name change? How many 
more changes were there like this?

Harbs

> On May 6, 2018, at 10:07 AM, Harbs  wrote:
> 
> Why did Container become org.apache.royale.core.Container instead of 
> org.apache.royale.html.Container?
> 
> Why is Container Core at all?
> 
> This change broke my app. While it’s not a big deal to fix it, I don’t 
> understand why the change. Unless we decide on a wholesale change of 
> components, this seems like a gratuitous breaking change for no good reason.
> 
> Harbs