Jewel dependency

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Jewel dependency

hferreira
Basic cannot work without Jewel. It is correct ?
Jewel it's like a UI implementation using Basic like mx ou spark for Flex,
correct ?

So, what happens if I'm using Jewel and at some point I would like to
completely change my UI aspect ?

Or Jewel is the first implement, a set of UI with a default skin that I can
change with CSS ?




--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Jewel dependency

Piotr Zarzycki
Hugo,

First was Basic. Later Carlos introduce Jewel which is separate UI set and not using Basic at all. I mean here that Jewel is not using Basic components. 

If you would like to use emulation + Jewel for good looking that probably require some work. 

In theory each component should work in the way that you can switch between his Beads View and achieve new look for it.

I imagine that your big application you would like to first get compiled using emulation and then - Using those components make it visible and working. That last part require work - No matter in which direction you go.

Piotr

On Sat, Nov 17, 2018, 2:03 PM hferreira <[hidden email]> wrote:
Basic cannot work without Jewel. It is correct ?
Jewel it's like a UI implementation using Basic like mx ou spark for Flex,
correct ?

So, what happens if I'm using Jewel and at some point I would like to
completely change my UI aspect ?

Or Jewel is the first implement, a set of UI with a default skin that I can
change with CSS ?




--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Jewel dependency

hferreira
Jewel which is separate UI set and not using Basic at all
> OK, like mx and spark in the Flex framework ?

emulation + Jewel for good looking that probably require some work
> As the first approach no.

first get compiled using emulation and then - Using those components make it
visible and working.
> Yes, that was my first idea.

That last part require work - No matter in which direction you go.
> No doubt.

I'm doing all this questions, because I'm new to Apache Royale world and
whant to know more to understand the approach that is different from how is
used to Flex SDK.

I already did a few tests on the last days with latest Royale build +
emulation + small ports of Flex code and it's very easy to port code and
build with few changes however almost nothing happens because we are on the
early days of the emulation. I know that now.

My first ideia was in fact to port to Roayle/Flex emulation and latter
perhaps move to Jewel or just leave it on the emulation forever.

I don't have the knowlege to help on the emulation process, so I have 2
choices now:
1. Wait and came back here in a few months and see where is the emulation
point;
2. Forget the emulation 1 to 1 and jump directly to Jewel, starting a new
aside project, recreating and testing every view.

Independent of the selected choice, I came to the conclusing that I should
learn Royale framework and the Joewel component on my spare time and then
start playing around with Royale/Jowel and see what is missing to my current
needs.
Only then, I should decide the best way for me.



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Jewel dependency

Piotr Zarzycki
I believe you could think like that like mx and spark, but probably going deeper it can be a bit more.

I see this like that - If you jump and learn emulation components and how to create and make them visible for your needs - You earn deeper knowledge what is behind the stage. You will gain the power of changing those components to your needs. 

And the most important more of your code won't need as much changes. 

However Jewel only approach is definitely also has partially that advantage, cause Carlos probably saves some code from his old app and uses in new one. 

Let's see what he can tell us about Jewel. ;) 

Piotr

On Sat, Nov 17, 2018, 3:22 PM hferreira <[hidden email]> wrote:
Jewel which is separate UI set and not using Basic at all
> OK, like mx and spark in the Flex framework ?

emulation + Jewel for good looking that probably require some work
> As the first approach no.

first get compiled using emulation and then - Using those components make it
visible and working.
> Yes, that was my first idea.

That last part require work - No matter in which direction you go.
> No doubt.

I'm doing all this questions, because I'm new to Apache Royale world and
whant to know more to understand the approach that is different from how is
used to Flex SDK.

I already did a few tests on the last days with latest Royale build +
emulation + small ports of Flex code and it's very easy to port code and
build with few changes however almost nothing happens because we are on the
early days of the emulation. I know that now.

My first ideia was in fact to port to Roayle/Flex emulation and latter
perhaps move to Jewel or just leave it on the emulation forever.

I don't have the knowlege to help on the emulation process, so I have 2
choices now:
1. Wait and came back here in a few months and see where is the emulation
point;
2. Forget the emulation 1 to 1 and jump directly to Jewel, starting a new
aside project, recreating and testing every view.

Independent of the selected choice, I came to the conclusing that I should
learn Royale framework and the Joewel component on my spare time and then
start playing around with Royale/Jowel and see what is missing to my current
needs.
Only then, I should decide the best way for me.



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Jewel dependency

hferreira
And the most important more of your code won't need as much changes.
> Yes. In a framework change perspective is the cheapest approach but for
> now is not there iet (let's see in a near future), meanwhile I will check
> Royale without emulation.








--
Sent from: http://apache-royale-users.20374.n8.nabble.com/
Reply | Threaded
Open this post in threaded view
|

Re: Jewel dependency

Alex Harui-2
IT was my hope that more of the experienced committers on Royale would help get the emulation components to run and train the newcomers.  Unfortunately, that has not happened so far, and I don't have enough time to do all of it myself in short order.  I keep hoping our committers will step up and help.  AIUI, some of our committers are available for contract work, so if you pay them to help make the emulation components run, that may be an option.

In the Adobe Flex days, Adobe poured big money into developing a free SDK.  There is no company pouring big money into Royale.  Those who need may need to "pay" by putting their own time into the development or hiring folks to do put in the time.

My 2 cents,
-Alex

On 11/17/18, 8:04 AM, "hferreira" <[hidden email]> wrote:

    And the most important more of your code won't need as much changes.
    > Yes. In a framework change perspective is the cheapest approach but for
    > now is not there iet (let's see in a near future), meanwhile I will check
    > Royale without emulation.
   
   
   
   
   
   
   
   
    --
    Sent from: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-users.20374.n8.nabble.com%2F&amp;data=02%7C01%7Caharui%40adobe.com%7C533d1fecc941479c727608d64ca65634%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636780674645998809&amp;sdata=v2YDinMiSSXk0jdSKO29gkO8EbPZPLjhPK44DICliMs%3D&amp;reserved=0
   

Reply | Threaded
Open this post in threaded view
|

Re: Jewel dependency

Carlos Rovira-2
In reply to this post by hferreira
Hi Hugo

El sáb., 17 nov. 2018 a las 14:03, hferreira (<[hidden email]>) escribió:
Basic cannot work without Jewel. It is correct ?

No. Basic works on its own, is like the minimum expression of pieces to build a royale application. Jewel is based on that *basic* pieces, but tries to be separated from basic. Jewel main dependency on Basic is UIBase, that is like UIComponent in Flex.

Jewel is an UI set that support themes. I started creating Jewel since I love flex, but think that we need a fresh UI set since more than 15 years has passed since Flex was created. Today we need to have things from flex, but as well new things like new kind of components (Drawer, TopBarApp, Wizard,...) and features like responsiveness and adaptiveness. So I want best of both world, a flex development model with all the good points and be able to create an app that works across multiple browsers and devices without the need for the developer to make anything, so for example if you open a ComboBox, the popup list will show as normal on desktop browser size, but thanks to css we can make it slide from bottom in phones, and things like that.
 
Jewel it's like a UI implementation using Basic like mx ou spark for Flex,
correct ?

is a UI implementation based on the principles of Basic, but both are UI sets.
Basic keeps PAYG at 100% since Jewel is PAYG, but doesn't try to be very exhaustive (maybe at 90%) and is evolving to be in a point where PAYG is a core concept but looking into be usable for development, so if a bead that now is composed is used most of the time, maybe in future versions could be defined by default like in Express. So Jewel is not black or white, sometimes is good some breaking I the rules.
 

So, what happens if I'm using Jewel and at some point I would like to
completely change my UI aspect ?

Jewel is designed with themes in mind. I created a system of jewel themes, but you can create something completely different.
It's using SASS and JewelTheme is a "master" theme. Then since is based on variables, the rest of themes (about 144 I think) are generated. So Jewel themes are a combination of 12 colors, light/dark modes and flat/no flat modes.

I ccmmitted half of that themes and since I'm working on making Jewel work right and be ok in production, I'm updating themes, but still need more work for versions like flat or dark modes. In our repo we have 12 colors/light themes working and dark is committed, but I'm sure that needs work to look really dark.
 

Or Jewel is the first implement, a set of UI with a default skin that I can
change with CSS ?


Jewel uses JewelTheme as the "master" theme. You can duplicate and start to work in other visuals, you only need to use the structure
JewelTheme uses SASS to generate css (sass generation is only set up when use maven). The css in JewelTheme wires the needed beads and some aspect of css that are needed.

If you use some concrete theme (not the master), is done to combine up to 3 themes. For example if you want light, but blue as main color, and red for secondary and green for emphasys, you can uses the 3 themes that make that combination works. The same can be generated by you just updating some few SASS vars in JewelTheme (for that reason is a "master" theme).

HTH

--
Reply | Threaded
Open this post in threaded view
|

Re: Jewel dependency

Carlos Rovira-2
In reply to this post by hferreira
My experience working with Jewel is that we are with all the needed pieces to go to production, but we find many things to fix or improve as we go, but still need some more key points at least for our case. Some examples are: DateChooser needs to develop a "year" view, still didn't have time to do that. Or I need an autocomplete feature for combobox. But for example ComboBox is working right and show good.

we talked to make Jewel be the face of MX / SPARK some day, since in theory we can swap beads and Royale can instantiate in mxml for example an UIBase with the beads that create a component and that should work. But that's theory right now. Hope we reach that point some day, but I think first we need to improve emulation and improve jewel.

as well jewel needs time to evolve since making something work takes time. I first use to make it work in actual browsers, then go to IE11 and normally things doesn't work and need to make changes to make work on IE11. Then probably if we start some day to use jewel visuals in mx/spark, we'll need to change things in jewel, but depending on how many time it will cost us to reach that point, we could end making some new code based on Jewel, since probably will need changes that could break things for other users.

One last thing. I know for sure, that if you want to migrate some app you'll need to get involved in royale (using either emulation or jewel) and not look at it as something only "to use". It will be very rare that we can develop all the things you'll need, so you'll end having to contribute and use.

HTH

Carlos


El sáb., 17 nov. 2018 a las 15:22, hferreira (<[hidden email]>) escribió:

I don't have the knowlege to help on the emulation process, so I have 2
choices now:
1. Wait and came back here in a few months and see where is the emulation
point;
2. Forget the emulation 1 to 1 and jump directly to Jewel, starting a new
aside project, recreating and testing every view.

Independent of the selected choice, I came to the conclusing that I should
learn Royale framework and the Joewel component on my spare time and then
start playing around with Royale/Jowel and see what is missing to my current
needs.
Only then, I should decide the best way for me.



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/


--
Reply | Threaded
Open this post in threaded view
|

Re: Jewel dependency

hferreira
It will be very rare that we can develop all the things you'll need, so
you'll end having to contribute and use.
> No doubt at this point mas first I need to understand and catch up, that's
> why I putted so many questions.

I still don't know if the way for me is emulation or not but I will worry
about that later.



--
Sent from: http://apache-royale-users.20374.n8.nabble.com/