Build failed in Jenkins: royale-typedefs #356

See Changes: -- Started by timer Running as SYSTEM [EnvInject] - Loading node environment variables. Building remotely on agent1 in workspace

Build failed in Jenkins: royale-asjs_jsonly #858

See Changes: -- [...truncated 1.17 MB...] [java] var events = require('events'); [java] ^^^ [java] [java] Feb 21, 20

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

I pushed changes that I think has everything working in Jewel by using the same "has" pattern that is used in other component sets. The Lists in the ToDo examples use a regular ItemRendererClassFactory instead of SelectableItemRendererClassFactory that is now used in most other places (List/Dat

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

yes, Jewel has the "structure" and is organized in SASS files, then JewelTheme has the "styling" part and is as well SASS. so Jewel should not need to change, and people should only need to change JewelTheme or create a new theme one using it as a template. I'll add examples to ant tomorrow thank

Re: [royale-asjs] branch develop updated: todomvc-examples: fix compilation, but now renderers show hover/selected states

ok Alex sounds good. Feel free to change what I did to better fit the new standards. about selection and hover at runtime. Most of the times I expect users want hover/select, or just hover or nothing at all. I think it could be some case when a user wants to deactivate something at runtime, and ho

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

On 2/20/20, 11:04 AM, "Carlos Rovira" wrote: forgot to say. Can you add missing examples to ANT? don't know where to do that and checking Jewel don't see the use of SelectableItemRendererClassFactory. all times ItemRendererClassFactory is used I could fix the Ant side, but

Re: [royale-asjs] branch develop updated: todomvc-examples: fix compilation, but now renderers show hover/selected states

There shouldn’t be a need for a SimpleListItemRenderer. Ideally, as I tried to explain below, we would no longer bake in the ClassSelectorListRuntime.. bead into Jewel’s ListItemRenderer. The choice of factories and initializers will take care of it. Every time we create a new class with diff

Jenkins build is back to normal : TourDeFlexMigration #652

See

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

forgot to say. Can you add missing examples to ANT? don't know where to do that and checking Jewel don't see the use of SelectableItemRendererClassFactory. all times ItemRendererClassFactory is used El jue., 20 feb. 2020 a las 20:00, Carlos Rovira () escribió: > Hi Alex, > > remember that Jewel u

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

Hi Alex, remember that Jewel uses SASS to create the CSS. I already pushed a commit with ["warning"]. It's not the first time I warn about it ;) You must to change SASS file. The css is just generated (like other generations in compiler), and is committed since no body added SASS to ANT. Maven has

Re: [royale-asjs] branch develop updated: todomvc-examples: fix compilation, but now renderers show hover/selected states

Hi Alex, just fixed it, but I read this now. Maybe a solution is between both. I think: - Jewel should has List configured by default to use a IR class factory that allows hover/select, since is the most usual. - Todo, should change List bead to a class factory that does not allow ho

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

I replied on this topic on your commit email. So I don't have to copy that into this thread, read what I said in that email and reply on that thread and let's figure out the right thing to do. I am having some weird problem with my Maven build where every time I try to change Jewel's defaults.

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

Hi Alex, I found that TodoMVC examples was not working, so I fixed it removing the non existing properties (hoverable and selectable). But I found Jewel ListItemRenderer has all baked, so I created a SimpleListItemRenderer (in Jewel Simple in the normal prefix for a "base", "basic" or "simple" opt

Re: [royale-asjs] branch develop updated: todomvc-examples: fix compilation, but now renderers show hover/selected states

These examples weren't in the list of examples on the Ant build so I missed them before I pushed. What is the purpose of the "hoverable" and "selectable" APIs in Jewel? The APIs are in the IRuntimeSelectableItemRenderer interface to support runtime disabling of selection visuals, but the Jewel

Re: MXML and warn-public vars

@joshtynj...@apache.org I had trouble wrapping my head around the polarity of this option as well. Public getter/setters and methods are always being renamed, it is when you don't rename public vars that we try to muck with that renaming. I saw your attempt to fix this morning. I agree with

Re: MXML and warn-public vars

On 2/20/20, 6:50 AM, "Carlos Rovira" wrote: Hi Alex, I think this should transparent for the final user and not need to add a compiler option, just configure all the strings that can cause problems, since for what I understand the problem, we can know what strings are

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

I'm not sure I understand what you mean by "control". Before the "has" changes, every ItemRenderer contained or inherited code that had hovered/selected APIs that drew visuals, and the ItemRenderer also "had" a bead like ItemRendererMouseController that set the hovered property on that item ren

Re: MXML and warn-public vars

Sorry, yes, of course it's false. Haven't had my morning tea yet. -- Josh Tynjala Bowler Hat LLC On Thu, Feb 20, 2020 at 7:17 AM Josh Tynjala wrote: > Do you mean -rename-public-vars=true instead of false? False should > preserve the original behavior. > > -- > Josh Tyn

Re: MXML and warn-public vars

Do you mean -rename-public-vars=true instead of false? False should preserve the original behavior. -- Josh Tynjala Bowler Hat LLC On Thu, Feb 20, 2020 at 1:44 AM Alex Harui wrote: > This change is breaking some modules when -rename-public-vars=false. > Let's say the ma

Re: MXML and warn-public vars

Hi Alex, I think this should transparent for the final user and not need to add a compiler option, just configure all the strings that can cause problems, since for what I understand the problem, we can know what strings are problematic, right? Thanks El jue., 20 feb. 2020 a las 10:44, Alex Harui

Re: Beware short id's in modules!

Hi Andrew, this could be on the Module docs page with a ">" so is like a note or tip to take into account (It shows as a yellow zone) El jue., 20 feb. 2020 a las 12:02, Andrew Wetmore () escribió: > Where should this information go in the documentation? Should we have a > "tips and tricks" page

Build failed in Jenkins: TourDeFlexMigration #651

See Changes: -- Started by upstream project "royale-asjs" build number 751 originally caused by: Started by upstream project "royale-asjs_jsonly" build

Re: "has" vs "is": sharing code, swapping out subsystems, and more...

Hi Alex, Could you provide an example how would I control hovering/selecting in item renderer when I don't have build in hover property etc. ? How should I compose such item renderer ? Thanks, Piotr czw., 20 lut 2020 o 03:20 Alex Harui napisał(a): > I pushed the "has" changes. TourDeJewel see

Jenkins build is back to normal : royale-asjs_jsonly #853

See

Re: Beware short id's in modules!

Where should this information go in the documentation? Should we have a "tips and tricks" page to capture stuff like this, maybe in the "get started" category? On Wed, Feb 19, 2020 at 4:45 PM Alex Harui wrote: > To those of you using modules in Royale, we have just noticed that the > minifier is

Re: Beware short id's in modules!

Hi Alex, thanks for pointing that out. Will take into account Carlos El mié., 19 feb. 2020 a las 21:45, Alex Harui () escribió: > To those of you using modules in Royale, we have just noticed that the > minifier is starting to create more collisions than it used to. It could > be that some compi

Re: MXML and warn-public vars

This change is breaking some modules when -rename-public-vars=false. Let's say the main app has some method "foo" that gets renamed. It might accidentally get a minified name that coincides with a public var in the module. For tour de flex, some API gets the minified name "UP". A module has