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

Hi Alex, 2018-06-04 20:15 GMT+02:00 Alex Harui : > Hi Carlos, > > At this point, I think I've addressed all of the compiler issues that > result in unnecessary output or processing. If Harbs is finished with the > framework changes, then I think we can try building Jewel with and without >

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

Hi Carlos, At this point, I think I've addressed all of the compiler issues that result in unnecessary output or processing. If Harbs is finished with the framework changes, then I think we can try building Jewel with and without Basic and see if there are still issues. I have to say that my

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

Hi Harbs, ok, I'll try to make a brief list of some of the classes involved so you and others can have a better understanding of how things can be restructured so we get best of both worlds. Hope to make this today. thanks Carlos 2018-06-02 21:36 GMT+02:00 Harbs : > Hi Carlos, > > I think our

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

Hi Carlos, I think our wires are still crossed. Rather than me trying to address your points below, I think we still need to work on definitions. Let me try like this: A Jewel dependency on “Foundation” is OK for you, but a dependency on “Basic” is not. Right? In your view, which files in

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

Hi Harbs, 2018-06-01 13:07 GMT+02:00 Harbs : > > We both agree that Jewel should have a dependency on “Foundation” or > “Basic”. The only question is TLCs. What practical difference does this > point have? > > All thoughts about why not make TLCs and CSS was exposed several times. I think you

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

Hi Carlos, Comments inline. > > 4. Methodology: Royale should not impose linking of libraries, other that > Language, Test and Core. I think yes. Alex and you think no. We both agree that Jewel should have a dependency on “Foundation” or “Basic”. The only question is TLCs. What practical

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

Hi Harbs 2018-06-01 11:03 GMT+02:00 Harbs : > Hi Carlos, > > Let me try and summarize in a nutshell the difference of opinion. > > 1. Should Jewel need/use Basic TLCs and CSS? You think no. Alex and I > think yes. > 2. Can we reach a point that by fixing all issues, there will be no > runtime

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

Hi Carlos, Let me try and summarize in a nutshell the difference of opinion. 1. Should Jewel need/use Basic TLCs and CSS? You think no. Alex and I think yes. 2. Can we reach a point that by fixing all issues, there will be no runtime penalty of making Basic TLCs a dependency? You think no. Alex

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

Hi Alex, 2018-06-01 8:08 GMT+02:00 Alex Harui : > > > Key word here is *optional* not *mandatory*. Take this in mind, since > while > I have the option to use it or not, I even should have the option to > link > it or not, since there's no obligation or requeriment to use. > >

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

I'm replying to my post again even though it isn't the latest.At the end I address what I think is a misconception that I saw in those more recent posts. > We want these beads, even high level beads, to be re-usable in multiple > components sets. Key word here is

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

Hi Harbs 2018-05-31 15:10 GMT+02:00 Harbs : > I’m not sure if we’re communicating. > > Composite TLCs have many pieces and only some of them are related to View. > DataGrid has 5 class reference and only one is IBeadView. DataGrid uses > DataGridColumnList which has 9 class references. One is

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

I’m not sure if we’re communicating. Composite TLCs have many pieces and only some of them are related to View. DataGrid has 5 class reference and only one is IBeadView. DataGrid uses DataGridColumnList which has 9 class references. One is view and another which might (or might not) need

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

Hi, 2018-05-31 11:35 GMT+02:00 Harbs : > To me, there are two classes of TLCs. > > 1. Simple TLCs are components such as Button, Checkbox, DropDownList etc. > Which are designed to represent a single HTML element. For these components > I completely understand and agree with your decision to

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

To me, there are two classes of TLCs. 1. Simple TLCs are components such as Button, Checkbox, DropDownList etc. Which are designed to represent a single HTML element. For these components I completely understand and agree with your decision to *NOT* subclass Basic TLCs. The styling paradigm is

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

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 clearly sufficient enough (that I think it should be). Why I want all the class definitions overhead

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

Comments inline. > On May 31, 2018, at 10:44 AM, Carlos Rovira wrote: > > I think there's a cost, don't know if the cost is higher or lower. My question is whether we would actually be avoiding this cost by pulling the CSS out of Basic. I don’t know the answer to this question. I suspect that

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

I think there's a cost, don't know if the cost is higher or lower. To me is not only the cost, is about as well as methodology. For me is incorrect to have a CSS always be compiled, no matter what kind of application I'll be constructing, even if nothing of that CSS goes into the final

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

great thanks! :) 2018-05-31 8:50 GMT+02:00 Harbs : > 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

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

The point of analyzing css is one I hadn’t thought of. I’m a bit unclear on how the compiler deals with Framework CSS files. How does the compiler know which CSS files it needs to examine? Most compiler methods use royalelib which points to a folder with all the Royale swcs. Does it make a

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: [Discussion] Package change names (was Re: 0.9.3 Release)

Hi Carlos, I'm replying to all posts on this thread since my last post. 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 it is a significant performance problem? Such a claim should be backed by

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

2018-05-30 16:59 GMT+02:00 Harbs : > Before we go on, I just want to comment on this. > > First of all, Piotr regularly comments on code that I (and others) commit. > He has very often raised good points which prompted me to fix things that > would have otherwise gone unnoticed. I appreciate it

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

Before we go on, I just want to comment on this. First of all, Piotr regularly comments on code that I (and others) commit. He has very often raised good points which prompted me to fix things that would have otherwise gone unnoticed. I appreciate it very much. Alex has called me out on many

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

Hi Harbs, 2018-05-30 15:26 GMT+02:00 Harbs : > I’m taking out two snippets from what you write that I think might help > bring us closer: > > > > Right, that should go to Foundation, not Basic > > What is the difference between “Foundation” and “Basic” other than name? > We already have

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

I’m taking out two snippets from what you write that I think might help bring us closer: > > Right, that should go to Foundation, not Basic What is the difference between “Foundation” and “Basic” other than name? We already have “Foundation”, but we call it “Basic”. If I’m understanding you

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

Hi, Just respond to that part. "Moreover, in the IDE if you hit CTRL+SPACE, when using Jewel, do you want to see 5-6 Button references off all linked UI sets? I don't think so I want the IDE to be quick, and to show only what I chooses, the Jewel Button, an not lots of options that I don't

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

Hi Harbs, 2018-05-30 11:49 GMT+02:00 Harbs : > I’m responding to this email because it has the most points I want to > respond to. > > I’m pulling out the particular quotes that I think are most relevant to > the discussion. > > > > >> 2. A “base” component set to use (or partially use) for

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

I’m responding to this email because it has the most points I want to respond to. I’m pulling out the particular quotes that I think are most relevant to the discussion. > >> 2. A “base” component set to use (or partially use) for composition. >> > > Take into account that Jewel does not

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

Hi Alex, 2018-05-30 5:53 GMT+02:00 Alex Harui : > FWIW, I think there is still a disconnect here. Right, I think we are mostly on consensus about refactoring names and packages and how to deal with CSS names, but the final point (maybe most important) is about the dependency library that I

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

FWIW, I think there is still a disconnect here. After looking at Carlos's diagram with a Foundation layer, maybe the confusion is around how to think about Composition-based instead of Inheritance-based components. There should be no desire to make every component set use only things from a

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 >: >> >> >> 1. How do we define what is “Core"? >> > > *Core*: This classes are needed to build a Royale > > Application. All pieces here are required. No CSS is

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

Hi 2018-05-29 16:00 GMT+02:00 Harbs : > > > 1. How do we define what is “Core"? > *Core*: This classes are needed to build a Royale Application. All pieces here are required. No CSS is present here to wire any concrete relationship between pieces, as well avoiding possible inclussions of CSS

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

Perfect. I think we did a great job on the css part of this discussion. Let’s see if we ca come to a meeting of the minds on the rest. :-) Let’s try and figure out what we all agree and don’t agree on. The important pieces I see are: 1. How do we define what is “Core"? 2. Should package names

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

Sorry for my delayed response to all of this. I’ve been kind of out of it… Can we try and get clear on the problems? I’d really like to figure out what we agree on before we try to nail down a solution. I’d like to start with Alex’s list: > First, the hopefully easy things we can agree on: > -I

Re: 0.9.3 Release

Hi Om, there's many changes since 0.9.2, so I was thinking the same as you. We don't need to go to 0.9.4, we can skip to 0.9.5 or as you say, 0.10.0 thanks 2018-05-26 15:20 GMT+02:00 OmPrakash Muppirala : > I just remembered that we have already pushed a 0.9.3 release to

Re: 0.9.3 Release

Thanks Alex, I committed as well some poms that needed change from 0.9.4 to 0.9.3 snapshot. We'll need to check why this ones are not update to the new version when doing a prepare release. I'll try as well to summarize briefly the discussion about reorganization so people could check easily the

Re: 0.9.3 Release

In case folks are wondering, I deleted the release/0.9.3 branches from all 3 repos. There have been changes made in each of the branches since the branches were cut and there were also issues with the royale-compiler and royale-typedefs branches not having synced version numbers to their

Re: Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

Hi Carlos, Express is not an attempt to emulate Flex APIs. The Emulation Components are. Express is merely designed to pre-compose more beads with less strong-typing in the data handling, in response to user feedback we received. That's why I think Jewel should compose Express beads, in

Re: Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

Hi Alex, I think Jewel born from Basic and started doing the same as Basic do in order to develop the view, CSS, etc... then is evolving to something that is usable directly. For example: in the beginning there was Button and TextButton like in Basic, then I find that only Button (with text

Should Jewel default to Express Beads? (was Re: [Discussion] Package change names (was Re: 0.9.3 Release))

Changing subject in case people have stopped reading. I think the question in the subject should be decided before we continue the package name discussion. After thinking about it more, I really do think that Jewel should default to using Express beads (which might also mean that we need to

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

Hi Alex, I think we are saying the same in essence. I want to reuse beads. So lets take "TextPrompt" bead and have only one in all Royale (always that make the same of course), think that is in a library called "Foundation" that depends from Core but is not core. Seems "Foundation" is a name

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

Hi Carlos, I guess I don't understand why separating beads from TLCs is better. How will that make things better for users or other component set developers? That would effectively double the number of SWCs and each TLC SWC will need its bead SWC. That doesn't sound like a good thing to me,

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

Hi Alex what do you think about separating the part in Basic that is inherently the same as in Jewel (Button, CheckBox, TextInput, List, ...) along with CSS that wire the beads for Basic UI set, and left the fundamental building blocks as something that is not Core but can be reused by Basic and

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

Hi Harbs 2018-05-21 18:35 GMT+02:00 Harbs : > No. Just referencing the Jewel TextPrompt would bring in the class. As > long as the Basic swc is available, it’ll just work. Assuming any piece of > Jewel uses Basic, I think Basic should be declared as a dependency by Jewel >

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

I understand this isn't the latest post on this thread, but it is the easiest one for me to reply to: First, the hopefully easy things we can agree on: -I have no objection to dropping "Bead" off of bead class names -I have no objection to moving all views into a view subfolder as long as

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

No. Just referencing the Jewel TextPrompt would bring in the class. As long as the Basic swc is available, it’ll just work. Assuming any piece of Jewel uses Basic, I think Basic should be declared as a dependency by Jewel in Maven. With other build types, the swc should always be available.

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

Ok, that's good point. But, if users need to refer it in code they will need to import the full package rute plus TextPromptBead right? This could be very confusing right? It's only a suggestion (I think is good)? or do you like more TextPromptBead than TextPrompt? Thanks Carlos 2018-05-21

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

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

Hi Harbs, 2018-05-21 12:52 GMT+02:00 Harbs : > Thank you for this. > > There’s two groups of files that were changed: Interfaces and and Classes. > > In general, I would be more inclined to move interfaces than classes, but > there are some things to consider: > > 1. There

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

Hi Pior, I think if you could take care of ANT files as well it would be great. In this way, when I upload the new 70 theme projects, I'll be doing taking into account your work to make all work directly thanks 2018-05-21 15:57 GMT+02:00 Piotr Zarzycki : > I think

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

I think new one will be more visible, but it doesn't matter to me. I will add Moonshine files to those projects. If any user open project with Moonshine it will just work. I will try to update also VSCode files, unless someone beat me with that. Piotr 2018-05-21 15:51 GMT+02:00 Carlos Rovira

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

Hi Piotr, that's right, right now several people reported problems to try this. Hope as we release they'll have less problems. I want to figure if we can update blog posts with more info, or make a new post and then reference existing post to that one...I'll take a look as I have some time

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

Thank you for this. There’s two groups of files that were changed: Interfaces and and Classes. In general, I would be more inclined to move interfaces than classes, but there are some things to consider: 1. There are still 17 interfaces in Basic. If the 5 that were moved belong in Core, what

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

Alex, I can confirm that this is working. When I added following compiler arguments -theme=${royalelib}/themes/Jewel-Light-NoFlat-Primary-Blue-Theme/src/main/resources/defaults.css My suggestion is that: 1) We should write blog post which describes how to setup all examples in Moonshine and

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

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 16c0dcd643974fe708fd67a3774ea6e35e879811 (in red the changes to better following)

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

I'm too swamped to read this whole thread, but one note: Ant doesn't need to build CSS-only themes. The examples that use them only need to use -theme= HTH, -Alex On 5/20/18, 12:52 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"

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

So great! :) as I said in the my last email, someone should contribute the ANT builds for each theme. In that way, since at some time I'll be uploading the other half of themes, those themes can go with the right ANT build. Think that all Jewel themes are about 140, and I uploaded around 70.

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

Hi Piotr, I never deal with ANT, I left this for others to contribute that build, as well sometimes I contribute the maven build when others only do the ANT one. I suppose that Alex make Jewel-Dark-NoFlat-Emphasized-Blue-Theme works, but only do that one, when we tried Jewel + That theme and

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

Definitely ant build for all themes is broken. There is absolutely no swcs. However I did small experiment - I build specific theme by Maven and it produces for me: */themes/Jewel-Light-NoFlat-Primary-Blue-Theme/target/Jewel-Light-NoFlat-Primary-Blue-Theme-0.9.4-SNAPSHOT-js.swc* I have added in

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

Carlos, If when I checked distribution package of Royale [1] I don't see there Jewel-Dark-NoFlat-Emphasized-Blue-Theme.swc. The only things which I'm seeing is folder frameworks/themes/ Jewel-Dark-NoFlat-Emphasized-Blue-Theme. Where those swcs are ? Have you make them build by ANT ? [1]

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

Great Josh!, this sounds like a solution! Hope Harbs or Piotr can try this and report if is working! :) 2018-05-19 0:38 GMT+02:00 Josh Tynjala : > Please forgive me if I'm missing some context because I'm just skimming > through here. However, I think I may be able to

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

Please forgive me if I'm missing some context because I'm just skimming through here. However, I think I may be able to offer a suggestion. Is the absolute path a location inside the the Royale SDK? If so, then you can use the ${royalelib} token to refer to the path relative to the SDK's

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

what was the way FlashBuilder or IntelliJ work about this? I assume that if Maven is using this is since the compiler supports it, so -theme should work, and IDEs should leverage that compiler argument. Hope Alex could throw some light on this, I remember he tries Jewel some weeks ago successfully

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:

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

Hi Harbs, Were you able to setup project in IDE ? Thanks, Piotr 2018-05-17 15:13 GMT+02:00 Carlos Rovira : > Look foro "Inject a Font" > > 2018-05-17 15:12 GMT+02:00 Harbs : > > > What was the subject? > > > > > On May 17, 2018, at 4:08 PM,

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

Look foro "Inject a Font" 2018-05-17 15:12 GMT+02:00 Harbs : > What was the subject? > > > On May 17, 2018, at 4:08 PM, Carlos Rovira > wrote: > > > > Hi, > > > > I think seems something valid, maybe we should think more about possible > >

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

What was the subject? > On May 17, 2018, at 4:08 PM, Carlos Rovira wrote: > > Hi, > > I think seems something valid, maybe we should think more about possible > colateral issue of that method. You should look as well at a thread where > Alex proposed as well some valid

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

Hi, I think seems something valid, maybe we should think more about possible colateral issue of that method. You should look as well at a thread where Alex proposed as well some valid options 2018-05-17 15:04 GMT+02:00 Harbs : > I just had another thought which might be

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

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

Hi Harbs 2018-05-17 14:40 GMT+02:00 Harbs : > Interesting. > > Why is deferred loading a problem? Adding the font to the header should > have the same effect. Shouldn’t it? > No, this way seems to end with the browser capability to load resources in parallel. > > I

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

Interesting. Why is deferred loading a problem? Adding the font to the header should have the same effect. Shouldn’t it? I don’t think we want font flicker anyway. FWIW, the @import can be added to the theme files by a script too. I’d be interested in knowing what kind of performance hit

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

we have a bug: https://github.com/apache/royale-compiler/issues/28 but as well @import is something we should run away from [1] "You shoud avoid the use of @import because it will defer the loading of the included resource until the file is fetched." [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

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

Font should be easily configurable by the user and I think we have a problem in the compiler to use that kind of css in that article, (I'm recheck this) 2018-05-17 14:04 GMT+02:00 Harbs : > 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)

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)

I think it should be theme_arg=-theme= (not tested by be) 2018-05-17 14:02 GMT+02:00 Harbs : > What compiler option is used to specify a theme? (Assuming the command > line is being used — not Maven, ant or what-have-you.) > > > On May 17, 2018, at 2:57 PM, Carlos Rovira

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

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

What compiler option is used to specify a theme? (Assuming the command line is being used — not Maven, ant or what-have-you.) > On May 17, 2018, at 2:57 PM, Carlos Rovira wrote: > > Hi, > > (renaming to this thread since is not related directly to the old one and > is

Re: 0.9.3 Release

Hi Harbs, just create a new thread from this. check it out! :) 2018-05-17 13:33 GMT+02:00 Harbs : > I see the following in the pom: > > org.apache.royale.framework > Jewel-Light-NoFlat-Primary-Blue-Theme > 0.9.4-SNAPSHOT > swc > theme >

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

Hi, (renaming to this thread since is not related directly to the old one and is more a "doc" email) To setup a theme in jewel, the best is look at JewelExample's pom.xml. I think Alex already make the ANT's files needed to this. IDE should have some way to achieve this like in Flex. I think

Re: 0.9.3 Release

I see the following in the pom: org.apache.royale.framework Jewel-Light-NoFlat-Primary-Blue-Theme 0.9.4-SNAPSHOT swc theme js It looks like there’s no default theme for Jewel. Should that be fixed? How are themes specified to the compiler? > On May

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.

Re: 0.9.3 Release

This is another issue. You cannot build those examples using IDE. I think we should raise on GitHub. I also cannot build those examples in Moonshine. Something needs to be configured. Probably some additional args for compiler related to theme etc. 2018-05-17 13:18 GMT+02:00 Harbs

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

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

Re: 0.9.3 Release

Hi, jsonly build is finaly fixed. Looking at the code fixed seems to me almost dead code and things very old unused now. as well I was not aware since is based on ANT and not maven, that I thought all build process in Royale was based on Maven. anyway, now that build is working for me is a

Re: 0.9.3 Release

Harbs, take into account that I don't use to setup ANT files, only Maven. ANT files needs to be done, I hope others can contribute that work. 2018-05-17 11:55 GMT+02:00 Harbs : > FWIW, it looks to me like the only thing that will not work in the blog > post is needs to be

Re: 0.9.3 Release

Harbs, How did you build the examples? Using VSCode or script ant/maven ? Thanks, Piotr 2018-05-17 11:55 GMT+02:00 Harbs : > 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

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

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

Re: 0.9.3 Release

2018-05-17 11:16 GMT+02:00 Harbs : > Definitely a plan. > Good! :) > > My guess is that if we agree on changing package paths, there will likely > be other classes that should be considered. > For sure I think a 1.0 version should not have "core" packages in "Basic" SWC

Re: 0.9.3 Release

Definitely a plan. My guess is that if we agree on changing package paths, there will likely be other classes that should be considered. My preference would be to have this discussion after we finish the project refactor discussion because I think it’s going to be related to the outcome of

Re: 0.9.3 Release

I think better focus on discussion and have proper solution. Than make the release. 2018-05-17 11:07 GMT+02:00 Carlos Rovira : > Ok, > > what if: > > * I take the time to generate a list of classes with package name changes > * Make a thread with the list to expose it >

Re: 0.9.3 Release

Sure. Same here. But things are much more stable now. As we move closer to “1.0”, I think we should be more careful about breaking changes and documenting them when we decide they are necessary. As far as these specific changes go: We haven’t even come to a conclusion on what (if any) package

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:

Re: 0.9.3 Release

> I only what to said at this regard, that I expect, as we have alll things > working and think about release 1.0, that before that release, is very > normal to change packages and names right? No. I disagree with this. We are at the point where people are using Royale in production. While we

Re: 0.9.3 Release

for me that's ok Piotr too thanks 2018-05-17 10:30 GMT+02:00 Piotr Zarzycki : > Carlos, > > Those changes were not properly discussed. Let's wait till the end of the > discussion and proper fix. I personally prefer wait even another month than > release something what

Re: 0.9.3 Release

Hi Harbs, ok, as I said, package names are not something crucial. It's only something we can put back to their old names. I only what to said at this regard, that I expect, as we have alll things working and think about release 1.0, that before that release, is very normal to change packages and

Re: 0.9.3 Release

Hi, just find the imports with problems, fix them and committed. If there's no others this should fix the release. If you see the commit, the changes are easy, and no more of some secs to do for our users, in case they use this core classes. Let's see what Jenkins reports in the following build

Re: 0.9.3 Release

Hi Piotr, I think we are getting sufficient progress I the discussion thread to still think about a revert. I'm most for change things from this point, that should be the normal way from 0.9.2 to 1.0. We can as well hold a bit the release until we have cleared all this. As I said, if we revert,

  1   2   >