About beads: Right now all beads are mixed and the major problem I experience is to know what beads already exists and where I can find that code. For that reason, my proposal is to have a "bead" package, and then organize beads in sub packages: "views", "models", "controllers", then for controls: "ui" and inside "textinput", "button", "slider", and so...if a bead is cross control, then goes to "ui" directly (i.e: Disabled). if is cross controls and components, can go to "beads" directly. In that way a user can visit beads/ui/textinput and take a quick look of what behaviors we already implemented and support. Regargid drop of "Bead" in the name, it does not bring us nothing but size and verbosity since we write: <j:beads><j:SomeBehaviour/></j:beads> so we now "SomeBehaviour" is a bead.
How to do this? little by little. is not something we can work in a day, so we need to divide the problem and go diligently to complete this task. It will be made in a branch and then as tested be merged. People already royale are Wellcome to express thoughts about this in order to take into account (it is preferable to remain silent and get the problem as we release). People will need to make adjustments, but this will happen sooner or later if we want to stabilize on 1.0 some day. Thanks 2018-05-29 15:54 GMT+02:00 Harbs <[email protected]>: > > > On May 29, 2018, at 4:48 PM, Olaf Krueger <[email protected]> wrote: > > > > Hi Carlos, > > > > thanks for summarizing all this stuff. > > > > @all > > I have not followed all the discussions, but I would like to ask if that > > what Carlos has presented is consensual. > > Foundation Is what Carlos is proposing as a new way of organizing things. > I think we need a lot of discussion before we can decide on something like > that. > > > > >> Remove "Bead" ending from beads to make it all less verbose. > > > > Are there still any other ways of recognizing a bead then? > > Or doesn't it matter if something is a bead or whatever other? > > I think all beads should be in some kind of bead package path. > > > > >> I offer my time to make this happen. > > > > Maybe I am wrong, but I guess these changes affect every existing Royale > > application and I could imagine that during this refactoring others maybe > > ran into merge conflicts. > > Do you have a strategy how this refactoring could be done as "quiet as > > possible"? > > > > Thanks, > > Olaf > > > > > > > > > > > > -- > > Sent from: http://apache-royale-development.20373.n8.nabble.com/ > > -- Carlos Rovira http://about.me/carlosrovira
