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)

n. Can you consider that path? > > > > > >> Because I don’t think that removing the dependency is the right thing to > >> do. Again, whether I’m right or wrong will become clearer as Jewel gets > >> completed. If I’m wrong, I’ll be happy to pull out the Basic TLCs >

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

anything more to see that is a good > way. You only need to examine final code in JewelExample, or any other > example code that uses Jewel and not uses Basic (all blog examples, or > remote object example), and you'll see that is the proof that the way works > better. You didn't see nothi

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

is not the case, why you want me to link Basic in Jewel ? > > > > >> 6. If we can’t make all the pieces of Basic truly optional, I’ll help > you > >> pull the Basic TLCs and CSS out into a separate project. > >> > >> > > Ok, my only concern he

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

ll out the Basic TLCs myself. > >> 6. If we can’t make all the pieces of Basic truly optional, I’ll help you >> pull the Basic TLCs and CSS out into a separate project. >> >> > Ok, my only concern here is how to do this plan, since I see many problems > that o

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)

> So maybe we should put this thread on pause and finish up that discussion. > I think we are reaching to a close here, don't see the need to make a pause. More over, we have many users out there that wants to try Jewel and they are waiting for the 0.9.3 r

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)

this thread on pause and finish up that discussion. > I think we are reaching to a close here, don't see the need to make a pause. More over, we have many users out there that wants to try Jewel and they are waiting for the 0.9.3 release to put blog examples in practice. I think we are gaining some

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)

e/ > >>>>> html/beads/IBackgroundBead.as > >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ > >>>> core/beads/IBorderBead.as > >>>>> > >>>>> frameworks/projects/Basic/src/main/royale/org/

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

frameworks/projects/Basic/src/ >>>> main/royale/org/apache/royale/ >>>>> html/beads/ITextFieldView.as(2) >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >>>> core/beads/TextFieldViewBase.as >>>

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

>> main/royale/org/apache/royale/html/supportClasses/DataGroup.as >>> >>> frameworks/projects/Core/src/main/royale/org/apache/royale/ >> core/DataItemRenderer.as >>> >>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/ >>> su

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 <bigosma...@gmail.com>: > I just remembered that we have already pushed a 0.9.

Re: 0.9.3 Release

post samples posted that are using > the > > > actual names, packages and namespaces. If you release 0.9.3 > without all > > > that, we can destroy out credibility since in all posts we have: > > > > > > "The example uses the new Jewel

Re: 0.9.3 Release

e > > actual names, packages and namespaces. If you release 0.9.3 without all > > that, we can destroy out credibility since in all posts we have: > > > > "The example uses the new Jewel UI set that supports themes. Jewel will > be > >

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

s/Core/src/ > main/royale/org/apache/royale/ > > > core/supportClasses/Border.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/ > > > > html/supportClasses

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

main/royale/org/apache/royale/ > > > html > > > > /beads/models/ViewportModel.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/supportClasses/Border.as

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

> > > frameworks/projects/Core/src/main/royale/org/apache/royale/ > > core/MXMLItemRenderer.as > > > > > > frameworks/projects/Basic/src/main/royale/org/apache/royale/ > html/ > > > supportClasses/MXML

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

rameworks/projects/Core/src/main/royale/org/apache/royale/ > > core/DataItemRenderer.as > > > > > > frameworks/projects/Basic/src/main/royale/org/apache/royale/ > html/ > > > supportClasses/DataItemRenderer.as (3) >

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

h > other > > beads 8"models", "controllers"...) to be consistent. > > (2) should go to "core/beads/views" as well > > (3) item renderers that should normaly be used by final users could > go some > &g

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

t; >frameworks/projects/Basic/src/ > main/royale/org/apache/royale/html > > /supportClasses/Viewport.as > > > > Some comments: > > > > (1) "views" should follow the same package structure we have with > other >

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)

hould do this > well and perform some other changes that make all more consistent though > libraries. > > Thanks > > Carlos > > > > > 2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com>: > >

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)

f we agree in the change of packages, we should do this > well and perform some other changes that make all more consistent though > libraries. > > Thanks > > Carlos > > > > > 2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com>: > >> Definitely a p

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)

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

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)

gt; compiler related to theme etc. >>>>>> >>>>>> 2018-05-17 13:18 GMT+02:00 Harbs <harbs.li...@gmail.com>: >>>>>> >>>>>>> VSCode using asconfigc >>>>>>> >>>>>>>> On May 17, 2018, at 12:57 PM, P

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)

or script ant/maven ? > >>>>>> > >>>>>> Thanks, > >>>>>> Piotr > >>>>>> > >>>>>> 2018-05-17 11:55 GMT+02:00 Harbs <harbs.li...@gmail.com >>>>> harbs.li...@gmail.com>>: > >>>>>

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)

ooks 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. >>&

Re: 0.9.3 Release

gt;>> On May 17, 2018, at 12:40 PM, Harbs <harbs.li...@gmail.com> wrote: > >>>>>> > >>>>>> You are right. I missed this. > >>>>>> > >>>>>> What is the minimum change necessary to get this to work? > &g

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

u 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 < > carlosrov...@apache.org > &g

Re: 0.9.3 Release

gt; >>>>>> 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 <carlosrov...@apache.or

Re: 0.9.3 Release

Carlos Rovira <carlosrov...@apache.org >>>> <mailto:carlosrov...@apache.org <mailto:carlosrov...@apache.org>>> >> wrote: >>>>>> >>>>>> I think you missed one important point I >>>>>> posted in other email: All blog post samples post

Re: 0.9.3 Release

ov...@apache.org <mailto:carlosrov...@apache.org>>> > 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 na

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

portant point I >>>> posted in other email: All blog post samples posted that are using the >>>> actual names, packages and namespaces. If you release 0.9.3 without all >>>> that, we can destroy out credibility since in all posts we have: >>>> >>>&g

Re: 0.9.3 Release

sted in other email: All blog post samples posted that are using the >> >> actual names, packages and namespaces. If you release 0.9.3 without all >> >> that, we can destroy out credibility since in all posts we have: >> >> >> >> "The example uses the n

Re: 0.9.3 Release

ssed one important point I > >> posted in other email: All blog post samples posted that are using the > >> actual names, packages and namespaces. If you release 0.9.3 without all > >> that, we can destroy out credibility since in all posts we have: > >> > &g

Re: 0.9.3 Release

r email: All blog post samples posted that are using the > >> actual names, packages and namespaces. If you release 0.9.3 without all > >> that, we can destroy out credibility since in all posts we have: > >> > >> "The example uses the new J

Re: 0.9.3 Release

t; "The example uses the new Jewel UI set that supports themes. Jewel will be >> available in the forthcoming 0.9.3 release of Royale. In the meanwhile you >> can find it in the develop branch." >> >> and the code is tailored with the actual api. >> >> For that reason

Re: 0.9.3 Release

using the > actual names, packages and namespaces. If you release 0.9.3 without all > that, we can destroy out credibility since in all posts we have: > > "The example uses the new Jewel UI set that supports themes. Jewel will be > available in the forthcoming 0.9.3 release of R

Re: 0.9.3 Release

tor discussion because I think it’s going to be related to the outcome > of that. > For me we can do that in parallel but if the rest think the same for me is ok. > > 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 “relea

Re: 0.9.3 Release

of 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 <carlosrov...@apache.org> wrote: > > Ok, > > w

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 <piotrzarzyck...@gmail.com>

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   >