You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@royale.apache.org by hferreira <hf...@solidsoft.pt> on 2018/11/17 13:03:34 UTC

Jewel dependency

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/

Re: Jewel dependency

Posted by hferreira <hf...@solidsoft.pt>.
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/

Re: Jewel dependency

Posted by Carlos Rovira <ca...@apache.org>.
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 (<hf...@solidsoft.pt>)
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/
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: Jewel dependency

Posted by Alex Harui <ah...@adobe.com>.
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" <hf...@solidsoft.pt> 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
    


Re: Jewel dependency

Posted by hferreira <hf...@solidsoft.pt>.
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/

Re: Jewel dependency

Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <hf...@solidsoft.pt> 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/
>

Re: Jewel dependency

Posted by hferreira <hf...@solidsoft.pt>.
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/

Re: Jewel dependency

Posted by Piotr Zarzycki <pi...@gmail.com>.
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 <hf...@solidsoft.pt> 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/
>

Re: Jewel dependency

Posted by Carlos Rovira <ca...@apache.org>.
Hi Hugo

El sáb., 17 nov. 2018 a las 14:03, hferreira (<hf...@solidsoft.pt>)
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

-- 
Carlos Rovira
http://about.me/carlosrovira