Re: Container change

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: >

Re: Container change

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,

Re: Container change

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 >

Re: Container change

, Harbs > On May 10, 2018, at 12:17 PM, Carlos Rovira wrote: > > Through this thread I exposed lots of technical advantages. I think I > should not express once again all said

Re: Container change

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 al

Re: Container change

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

Re: Container change

cloudapp.azure.com:8080/> Thanks, Harbs

Re: Container change

* 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

In that case, it’s something which needs to be fixed. I’m also wondering whether there is a problem with typenames stepping on each other. This is likely to be a problem if more than one component set is used in the same app. Harbs > On May 10, 2018, at 1:09 PM, Carlos Rovira wr

Re: Container change

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

eek 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

Re: Container change

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 o

Re: Container change

: 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 s

Re: Container change

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: > >

Re: Container change

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, Car

Re: Container change

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 s

Re: Container change

greed 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:0

Re: Container change

. 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 <mailto:harbs.li...@gmail.com>>: > >> Top posting to make it easier

Re: Container change

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 <mailto:aha...@adobe.com.invalid>>: > >> Wow! Good thing I slept through this... >> >> Let's try to calm thing

Re: Are we repeating our recent history?

to do, then please try to find the words to convince others of that. Alex asked some good targeted questions. That seems like the right place to figure this out. I hope we resolve this soon, Harbs > On May 11, 2018, at 12:53 PM, Carlos Rovira wrote: > > Hi, > > in writing th

Re: [DISCUSS] Explanation of the changes

that. Ultimately, the more we rely on each other, the better the quality of the end product will be — even if it takes us longer to get there… ;-) I hope this makes my position clearer and I look forward to other thoughts. Thanks, Harbs > On May 12, 2018, at 11:09 AM, Carlos Rovira wr

Re: [DISCUSS] Explanation of the changes

anything different than what I meant to project the entire time. I am taking more care with my words and I’m making every attempt to use Greg’s rule about not using pronouns. It seems to be working well… ;-) More tomorrow. Best, Harbs > On May 13, 2018, at 10:02 PM, Carlos Rovira wrote: >

Re: [DISCUSS] Explanation of the changes

or might not be an argument to separate Jewel because of problem 1a. I have more to say on this topic, but I don’t want to interject my thoughts before discussion is started on it. Can we agree on this problem and try to find the right solution to it? Thanks, Harbs > On May 13, 2018,

Re: [DISCUSS] Explanation of the changes

” instead of “Button”. It’s possible that the correct solution is that any component set which does not want to inherit from Basic must specify a different typename. (Like what you did.) Again: I’m not trying to pin down solutions yet. I’m first trying to pin down the problems. Thanks, Harbs >

Re: [DISCUSS] Explanation of the changes

to see if there are other options that might be a more complete solution. Does this make sense? Harbs > On May 14, 2018, at 3:40 PM, Carlos Rovira wrote: > > Hi Harbs, > > 2018-05-14 14:23 GMT+02:00 Harbs : > >> I think I still did not make myself clear. >> >

Re: [DISCUSS] Explanation of the changes

rg/royale/svg "; @namespace j "library://ns.apache.org/royale/jewel "; j|TextButton { padding-top:10px; } Are you saying that this will work? If yes, please exp

Re: [DISCUSS] Explanation of the changes

agree that it’s a compromise and not the ideal way to solve the problem? If we could make j|Button{} work, wouldn’t that be better? Thanks, Harbs > On May 14, 2018, at 7:25 PM, Carlos Rovira wrote: > > I'll give you working examples that I tried for this so you can test > you

Re: [DISCUSS] Explanation of the changes

y goes into which package and project, but I don’t think we’re up to that yet. Thanks, Harbs > On May 15, 2018, at 9:29 AM, Alex Harui wrote: > > Hi, > > I'm finding this thread to be hard to follow. It seems to be focusing a lot > on mixing what I call "top-level c

Re: [DISCUSS] Explanation of the changes

ughts? Are there reasons I’m missing why these solutions will not work? Thanks, Harbs > On May 15, 2018, at 8:34 AM, Carlos Rovira wrote: > > Hi Harbs, > > 2018-05-14 23:37 GMT+02:00 Harbs <mailto:harbs.li...@gmail.com>>: > >> So, we are saying the same th

Re: [DISCUSS] Explanation of the changes

class name… Harbs > On May 15, 2018, at 11:52 AM, Harbs wrote: > > I just tried an experiment of giving an MDL Button a classname of “Button” in > addition to all the MDL classes. Interestingly, the mdl class names overrode > the Button one. I’m really not sure why because

Re: [DISCUSS] Explanation of the changes

OK. Great! It looks like we’re agreeing on these points too. (It seems like I was right that we agree on most points) :-) To add a bit of clarity: We are using (some) MDL in our app, and we had requirements to modify the default MDL styling. I found this very difficult to do and I ended up mes

Re: [DISCUSS] Explanation of the changes

y. There’s no reason why someone (on the application level) could not decide to set styling across *all* component sets by then using .FooComponent{ */some more styling*/ }. Thoughts? Thanks, Harbs > On May 15, 2018, at 1:38 PM, Carlos Rovira wrote: > >> Point #2 starts dow

Re: [DISCUSS] Explanation of the changes

lex Harui wrote: > > Certain typenames match up against HTMLElement names and are thus valid Type > selectors so are not transformed into Class Selectors. > > -Alex > > On 5/15/18, 2:09 AM, "Harbs" wrote: > >Interesting. It looks to me like a bug.

Re: [DISCUSS] Explanation of the changes

Sure. I wonder if we should handle different namespaces differently. Maybe the following two namespaces should get proper type selectors, while any others would get class selectors? http://www.w3.org/1999/xhtml library://ns.apache.org/royale/html Harbs > On May 15, 2018, at 6:52 PM, A

Re: 0.9.3 Release

Can we make sure the release does not have any breaking changes currently in develop? > On May 16, 2018, at 2:58 AM, OmPrakash Muppirala wrote: > > On Mon, May 14, 2018 at 12:56 PM, Alex Harui > wrote: > >> Update: I’ve been trying to get the release script to work o

Re: 0.9.3 Release

really care how we do that. Thanks, Harbs > On May 16, 2018, at 7:54 PM, OmPrakash Muppirala wrote: > > On Wed, May 16, 2018, 9:42 AM Harbs wrote: > >> Can we make sure the release does not have any breaking changes currently >> in develop? > > > The fixes n

Re: 0.9.3 Release

secs than previous releases and I don’t *think* that alone should break existing apps... Harbs > On May 16, 2018, at 10:25 PM, OmPrakash Muppirala > wrote: > > So we just revert back develop to the last known good build? Sorry, I > don't want to trample on anyone's chang

Re: 0.9.3 Release

different *swcs* (I really need to turn off auto-correct…) > On May 16, 2018, at 10:33 PM, Harbs wrote: > > different secs

Re: [DISCUSS] Explanation of the changes

C with an HTMLButtonElement as its element > (or sub-element) will still be affected by any Button type selector in some > CSS file. Or maybe I don't fully understand what you are proposing. > > -Alex > > On 5/16/18, 9:41 AM, "Harbs" wrote: > >Sure. I

Re: 0.9.3 Release

Having trouble getting this email to “take”... It looks like it does have issues. I just pulled the 0.9.3 branch. I get a lot of these warnings when I compile the framework: [java] /Apache/royale-asjs/frameworks/projects/DragDrop/src/main/royale/org/apache/royale/html/beads/ButtonBarReorde

Re: 0.9.3 Release

my app, and I get runtime errors due to missing components. This seems to be due to HTML not subclassing Group. Here’s an example of elements which go AWAL: https://paste.apache.org/s9og <https://paste.apache.org/s9og> Everything below “ul" is missing. Harbs > On May 16, 2018, at

Re: 0.9.3 Release

Is there a list of classes which had their package paths changed? At the very least, those should be changed back. Preferably returned to their original projects. HTML can probably simply be reverted. I’m not sure what else (if anything) needs to be fixed. Thanks, Harbs > On May 17, 2018,

Re: 0.9.3 Release

. Thanks, Harbs > On May 17, 2018, at 10:48 AM, Alex Harui wrote: > > Bummer. I checked the logs and you are correct. I thought I'd made the > branches before those changes. > > I will probably see if the Maven release plugin will let me create branches > from a particu

Re: 0.9.3 Release

will likely happen before that discussion is finished. IMO, it’s better to release less features than release breaking changes which might be reverted. Thanks, Harbs > On May 17, 2018, at 11:05 AM, Carlos Rovira wrote: > > Hi Harbs, > > that was returned to the old way, actua

Re: 0.9.3 Release

don’t know. Changing package paths is not something we should do lightly, and if we do make changes, it should only happen in a single release and all changes should be carefully considered. There has not been nearly enough discussion on that yet. Thanks, Harbs > On May 17, 2018, at 11:10

Re: 0.9.3 Release

While we can make breaking changes if they are warranted, they should be kept to an absolute minimum and be carefully considered and well documented if we do. My $0.02, Harbs > On May 17, 2018, at 11:32 AM, Carlos Rovira wrote: > > Hi Harbs, > > ok, as I said, package names a

Re: 0.9.3 Release

Yes. It definitely makes sense to me. Let’s get the 0.9.3 release out without breaking changes. If we decide to keep Carlos’ changes and/or modify them, there’s no reason it cannot go into 0.9.4. Thanks, Harbs > On May 17, 2018, at 11:30 AM, Piotr Zarzycki > wrote: > > Carlos

Re: 0.9.3 Release

names should change yet, and including those changes in a release is premature. If we do change package names, I’m of the opinion that they should be decided on and all happen at once to minimize impact on end-users. Does that help clarify things? Thanks, Harbs > On May 17, 2018, at 11:49

Re: 0.9.3 Release

that. Either way, I don’t think discussion should hold up the 0.9.3 release. We’re already past due for a release. We want to “release early and release often”… ;-) Thanks, Harbs > On May 17, 2018, at 12:07 PM, Carlos Rovira wrote: > > Ok, > > what if: > > * I take the ti

Re: 0.9.3 Release

You are right. I missed this. What is the minimum change necessary to get this to work? > On May 17, 2018, at 12:24 PM, Carlos Rovira wrote: > > I think you missed one important point I > posted in other email: All blog post samples posted that are using the > actual names, packages and namesp

Re: 0.9.3 Release

FWIW, it looks to me like the only thing that will not work in the blog post is needs to be and needs to be Although when I compile styles are definitely missing. Yeah. Jewel is definitely missing important pieces… :-( Harbs > On May 17, 2018, at 12:40 PM, Harbs wrote: > >

Re: 0.9.3 Release

VSCode using asconfigc > On May 17, 2018, at 12:57 PM, Piotr Zarzycki > wrote: > > Harbs, > > How did you build the examples? Using VSCode or script ant/maven ? > > Thanks, > Piotr > > 2018-05-17 11:55 GMT+02:00 Harbs <mailto:harbs.li...@gmail.com>

Re: 0.9.3 Release

Please make the list and we’ll take the discussion from there. > On May 17, 2018, at 2:01 PM, Carlos Rovira wrote: > > anyway, now that build is working for me is a matter of making the list of > package name changes if you like

Re: 0.9.3 Release

Oh. I guess that’s why the styling did not work. Carlos, what compiler options are needed for Jewel? Harbs > On May 17, 2018, at 2:23 PM, Piotr Zarzycki wrote: > > This is another issue. You cannot build those examples using IDE. I think > we should raise on GitHub. I also cannot

Re: 0.9.3 Release

May 17, 2018, at 2:26 PM, Harbs wrote: > > Oh. I guess that’s why the styling did not work. > > Carlos, what compiler options are needed for Jewel? > > Harbs > >> On May 17, 2018, at 2:23 PM, Piotr Zarzycki >> wrote: >> >> This is another issue. Yo

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

to prevent basic Button CSS from being unnecessarily included.0 * We will need a lookup of “standard” prefixes for the compiler to use so it knows what typenames to use for different packages. Harbs > On May 17, 2018, at 12:26 AM, Alex Harui wrote: > > Changing the subject line... >

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

royale compiler processing. > > One more thing, we have as in MDL the use of an html template: > > > ${basedir}/target/javascript/bin/js-debug/jewel-example-index-template.html > > > but only to get the FONT: > > https://fonts.googleapis.com/css?family=Lato:400,70

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

Why not just include the font in the CSS file?[1] [1]https://css-tricks.com/snippets/css/using-font-face/ > On May 17, 2018, at 2:57 PM, Carlos Rovira wrote: > > One more thing, we have as in MDL the use of an html template: > > > ${based

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

More specifically, I believe including this in the css would negate the need for an HTML template: @import url('https://fonts.googleapis.com/css?family=Lato:400,700’); > On May 17, 2018, at 3:04 PM, Harbs wrote: > > Why not just include the font in the CSS file?[1] >

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

Thanks. FWIW, the compiler option seems to be “theme”. If the full path needs to be specified, this is a problem. Is there any way to specify a theme by just the theme name? (Question for however might know the answer.) Harbs > On May 17, 2018, at 3:11 PM, Carlos Rovira wrote: > >

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

@import has relative to a standard link. I think avoiding html template is a good thing. Another angle on this problem might be to allow adding links via the compiler automatically. Not sure exactly what form that might take though. My $0.02, Harbs > On May 17, 2018, at 3:16 PM, Carlos Rov

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

I just had another thought which might be even more flexible: Maybe the compile could parse @includes from CSS and insert them as links in the header HTML automatically. Thanks, Harbs > On May 17, 2018, at 3:52 PM, Carlos Rovira wrote: > >> >> Another angle on this problem

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

tions > > 2018-05-17 15:04 GMT+02:00 Harbs : > >> I just had another thought which might be even more flexible: >> >> Maybe the compile could parse @includes from CSS and insert them as links >> in the header HTML automatically. >> >> Thanks, >

Re: BinaryData compress/uncompress methods (like ByteArray) missing

Yes. The big issue with compression is that it adds a lot of code. The most commonly used JS library for compression is pako.[1] I’m using that personally. We don’t want to include something like this in BinaryData because it adds a lot of bulk. HTH, Harbs [1]http://nodeca.github.io/pako

Re: BinaryData compress/uncompress methods (like ByteArray) missing

Hah! I forgot I wrote that class… ;-) Yes. Pako is a zlib port. Thanks, Harbs > On May 17, 2018, at 4:22 PM, Carlos Rovira wrote: > > I see we already has Compressionutils that uses pako, this uses zlib? > > thanks > > 2018-05-17 15:17 GMT+02:00 Carlos Rovira : >

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

asic.Button{ } [Typename(name="org_apache_royale_html_Button")] public class Button extends ButtonBase would tell the compiler that the selector for this class should look like: .org_apache_royale_html_Button{ } If there’s no meta-tag at all, the behavior would stay as it is today and you’d get: .ImageButton{ } and Button{ } This feels like the smallest change to the compiler and leaves the component sets to decide for themselves how to best handle possible conflicts. Thoughts? Harbs

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

One more point: If we go the meta-tags route, we can include in the tag whether to include base typenames. Something like the following would tell the compiler that the org.apache.royale.html.Button typename is not being used. [Typename(name="Button", prefix=“basic”, inherits=“false")] pu

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

copy HTML > Type Selectors in some cases already. > > We could try to find all subclasses of classes that have Type Selectors that > don't have their own Type Selector and have the compiler auto-copy that base > class Type Selector (or add the subclass to the list of classes for that > selector. I think we *should* have inheritance (like we have today) unless a subclass specifically disables it using metadata or what-have-you. Thanks, Harbs P.S. I’m going to be off-line for a couple of days.

Re: BinaryData compress/uncompress methods (like ByteArray) missing

used these classes extensively, and they work very well. Thanks, Harbs > On May 18, 2018, at 2:09 PM, Carlos Rovira wrote: > > I talk about "drawing things" that was something > more related to the Flash API.

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

ill make possible the most flexible way of handling this an a solution > that since to fit all visions. Agreed. I was suggesting that the default remains as it is today, and we be careful about including metadata in Framework classes. Thanks, Harbs

Re: BinaryData compress/uncompress methods (like ByteArray) missing

logic for Transforms which work in conjunction with the Graphics classes. HTH, Harbs > On May 18, 2018, at 3:01 PM, Carlos Rovira wrote: > > Thanks Harbs, > > to understand better about the code you said, this is done creating a > Canvas where the drawing is done? If so

Re: How to setup Jewel Theme in a project(Was Re: 0.9.3 Release)

No. Specifying the themes seems to be a major problem. It’s possible to specify a theme using additional compiler options in asconfig, but I’m not prepared to specify an absolute path. This needs a solution… Harbs > On May 18, 2018, at 3:56 PM, Piotr Zarzycki wrote: > > Hi Harbs,

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

superclass CSS dependencies. I *think* your main points have to do with issue #2. Are we on the same page here, or am I missing something? Harbs > On May 19, 2018, at 2:50 AM, Alex Harui wrote: > > > > On 5/18/18, 2:50 AM, "Harbs" wrote: >And bas

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

used somewhere). Harbs > On May 21, 2018, at 11:29 AM, Carlos Rovira wrote: > > Hi, > > as we talked I take the time to make a list of package name changes. > Finally 20 classes were changed from package. > Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e87981

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

Commenting on this one item (before I respond to the rest). If all you want to do is add , you can do this: Express does this a lot. Harbs > On May 21, 2018, at 5:47 PM, Carlos Rovira wrote: > > In the other hand as I notice before, we can use this to refactor packages > and n

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

han the class name. One example is where the class name is org.apache.royale.html.beads.ApplicationParametersBead. I don’t know if this a good idea but it’s what I did… ;-) Harbs > On May 21, 2018, at 7:21 PM, Carlos Rovira wrote: > > Ok, that's good point. > > But, if us

Re: [royale-asjs] branch feature/revert-refactor updated: Item Renderer firing itemChanged when mouse is dragged over item renderer and released

This change looks correct to me and fixed the bug as I observed it. Any idea why was mouse up used instead of click in the first place? I assume the same fix should be applied to the swf block? Harbs > On May 27, 2018, at 2:24 PM, ha...@apache.org wrote: > > This is an automated e

Re: [royale-asjs] branch feature/revert-refactor updated: Item Renderer firing itemChanged when mouse is dragged over item renderer and released

ugh it looks like your fix is good. I hope to check it once all stuff > back to normal in develop. > > Thanks, > Piotr > > 2018-05-27 13:26 GMT+02:00 Harbs : > >> This change looks correct to me and fixed the bug as I observed it. >> >> Any idea why wa

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

could somehow strip out the bracket metadata, I prefer that. Using metadata would allow different component sets to make their own decisions. Thanks, Harbs > On May 21, 2018, at 7:41 PM, Alex Harui wrote: > > I think we are in agreement. My most recent posts were intended to show t

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

los, do you agree as well? (I would be willing to help out with a rename, but I want to make sure it doesn't cause too much disruption. Thanks, Harbs > On May 23, 2018, at 12:43 AM, Alex Harui wrote: > > Hi Carlos, > > I guess I don't understand why separating beads f

Re: [Discussion] Summarizing all discussion about Royale organization and structure

> On May 29, 2018, at 4:48 PM, Olaf Krueger 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 o

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

a new package. I’d rather wait to discuss this until we have some clarity on the ones above. Can you think of any other questions we should be asking ourselves? Thanks, Harbs > On May 29, 2018, at 4:41 PM, Carlos Rovira wrote: > > Hi, > > completely. > > two things: &g

Re: [Discussion] Summarizing all discussion about Royale organization and structure

visuals (i.e. subcomponents) Beads that modify visuals Beads that add or remove functionality Harbs > On May 29, 2018, at 5:26 PM, Carlos Rovira wrote: > > About beads: Right now all beads are mixed and the major problem I > experience is to know what beads already exists and wher

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

> On May 29, 2018, at 5:34 PM, Carlos Rovira wrote: > > Hi > > 2018-05-29 16:00 GMT+02:00 Harbs <mailto:harbs.li...@gmail.com>>: >> >> >> 1. How do we define what is “Core"? >> > > *Core*: This classes are needed to build a Royal

Re: [Discussion] Summarizing all discussion about Royale organization and structure

Do you have ideas for a naming structure? > On May 29, 2018, at 5:50 PM, Carlos Rovira wrote: > > +1 Agree. > > 2018-05-29 16:35 GMT+02:00 Harbs : > >> I agree that beads could use organization. >> >> Model view and controller are easy ones. The res

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

in a common library > that the rest can use (i.e: Foundation.swc) It seems that your main point comes back to CSS. If we can’t fix the bugs related to the CSS, then I completely agree with you. We can’t have Basic CSS causing lots of classes and CSS to be included in apps for no good reas

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

continue as Piotr proposed in a fork and abandone Royale as others > did? Or can we go forward and take the best of what all think? Definitely work this through. :-) I think we can come to an agreement. I think we’re not so far apart. Thanks, Harbs

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

away from this discussion feeling like we're making the right decisions. Are we on the same page here? I think this is important. Thanks, Harbs > On May 30, 2018, at 5:17 PM, Carlos Rovira wrote: > > I think so... but hope this resolves soon, I think this discussions should >

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

I’m planning on working on this. I think it’s very solvable. > On May 31, 2018, at 9:02 AM, Carlos Rovira wrote: > >> >> I believe we still need a volunteer to change the royale-asjs code to >> eliminate use of class selectors in its defaults.css files. >> > > I think this should be done by

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

which acts as a compiler directive to specify exactly what to output. If you have another suggestion on how we can achieve that goal, that’s fine too. Makes sense? Harbs > On May 31, 2018, at 12:30 AM, Alex Harui wrote: > > There has always been an option to keep/strip metadata in t

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

ms or less, I don’t think it’s worth worrying about. Thanks, Harbs > On May 31, 2018, at 9:02 AM, Carlos Rovira wrote: > >> I see a claim that there is a problem because of the compiler parsing a >> CSS file from a SWC where that CSS will not be used. Is there proof that >

Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)

think that would be great > improvement > > I think Alex is thinking in some kind of metadata at runtime, but I > understand this is not the case. > > thanks > > 2018-05-31 8:58 GMT+02:00 Harbs <mailto:harbs.li...@gmail.com>>: > >> I’m not talking about s

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

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

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

? Harbs > On May 31, 2018, at 12:12 PM, Carlos Rovira wrote: > > Hi Harbs, > > concreting more over if Jewel should or not extend Basic TLCs. That I think > is the real point now to discuss. I'm sure it should not be the case. To > sum to all that I exposed, it was not

Re: [Discussion] Package change names (was Re: 0.9.3 Release)

I’m right and they will. I don’t see how restructuring Basic is necessary until we’re sure of the outcome of that. Thoughts? Harbs > On May 31, 2018, at 2:10 PM, Carlos Rovira wrote: > >> 2, Composite TLCs are components such as ComboBox, DataGrid, possibly >> ImageButon e

Restructuring Composite Components

we add interfaces (i.e. IButton) and declare the classes using interfaces? I mean something similar to IItemRenderer. Maybe just use ValuesManager to just lookup some other “name”? We’re currently doing something similar with ColumnClassName in DynamicDataGrid. Other ideas? Thanks, Harbs

Re: Restructuring Composite Components

primarily trying to figure out the best way to declare the “skin pieces” of the view. Harbs > On May 31, 2018, at 5:17 PM, Piotr Zarzycki wrote: > > Hi Harbs, > > What if ComboBox will extend DataContainer? It will be at some point list > itself. Than the rest responsibility i

Re: Restructuring Composite Components

An additional wrinkle in this problem is wether there’s any way to specify the parts of the view using MXML, or it has to be in CSS. If they are beads, that problem is simplified. If not, is there a way to add to ValueManager via MXML? Harbs > On May 31, 2018, at 6:09 PM, Harbs wrote: >

Re: Royale - BlazeDS working

Very impressive! Great work! :-) Harbs > On May 31, 2018, at 9:51 PM, Carlos Rovira wrote: > > Forgot to share the info in Github page :) > > https://github.com/apache/royale-asjs/wiki/Apache-Royale-communication-with-AMF-and-RemoteObject > > <https://github.com

Descendent selector issue

-color: #d8d8d8; border: 1px solid #808080; padding: 4px; } does get omitted if ToggleTextButton is not used. Is it correct to assume that this is a bug and if the parent/ancestor the selector is not used, the CSS should be omitted? Harbs

<    4   5   6   7   8   9   10   11   12   13   >