Some questions about Jewel Navigation

[Piotr Zarzycki <pi...@gmail.com>]

Hi Carlos,

I have started playing using Jewel lately more serious and have two
questions related to Jewel Navigation component.

I'm displaying horizontal navigation like that [1]. Because Navigation is
actually list my background color is white. The question is how to make my
navigation transparent component transparent? I know that I could make some
css trick, but maybe you have a better solution.

Another question is - Did you notice that Navigation component fire change
event two times - whenever you click on the item ?

[1] https://paste.apache.org/I9kp

Thanks,
-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Binding Events issues (was Re: Some questions about Jewel Navigation)

[Alex Harui <ah...@adobe.com.INVALID>]

Hi Carlos,

The binding system in Flex and Royale has always relied on caught exceptions, so when debugging you often have to turn off "Pause on caught exceptions" which can make things challenging if you are trying to catch some other caught exception.  It would be an interesting question to see the cost of adding null checks in all binding generated code.  The null check might be faster than the catch.

There are always times when binding works despite the compiler warning.  The warning is just saying there is at least one scenario where your binding won't work right and if you don't encounter that scenario you are fine.  But it will be true in Royale JS output that there are more scenarios where it won't work than in SWF.

-Alex

On 12/13/18, 1:33 AM, "Carlos Rovira" <ca...@apache.org> wrote:

    Hi Alex
    
    El jue., 13 dic. 2018 a las 2:00, Alex Harui (<ah...@adobe.com.invalid>)
    escribió:
    
    >
    > 1) What error do you get with null/undefined in renderers?
    
    
    Really, the error doesn't show clearly on browsers. I could see that in
    Google Chrome going to Sources and in the right panel check "Pause on
    caught exceptions"
    
    I fixed this in Tour De Jewel (JewelExample), so to see that again you can
    go to
    
    NavigationIconLinkItemRenderer.mxml
    
    And in the bindings remove:
    
    <js:FontIcon text="{navlink ? navlink.icon : ''}" material="true"
    visible="{navlink
    ? navlink.icon != null : false}"/>
    
    <html:Span text="{navlink ? navlink.label : ''}"/>
    
    remove the ternaries and left as it should be
    
    Running that in the old state and checking the before mentioned option in
    chrome will make Tour de Jewel stops at the beginning as each renderer is
    instantiated and throwing an error.
    
    
    The binding subsystem should have try/catch blocks in the appropriate
    > places.  Maybe we are missing something, or maybe there is a bug, or maybe
    > there is such a huge cost to automatically protecting against
    > null/undefined that it is worth folks being a bit more careful about that
    > in Royale.
    
    
    In the case above, I'm taking care, but IMHO, from a user point of view, I
    should not have to write a safeguard in each binding. If that's is always
    required *always*, it seems frameworks responsibility, saving lots of
    safeguards in users code. This seems to me more PAYG.
    
    
    > Flex did try to evaluate binding expression often whereas Royale will
    > apply binding at different times to improve performance.  Item renderers
    > are a classic example.  In Flex, bindings were evaluated twice before the
    > data property ever set and a third time when the data finally got set.  In
    > Royale, if you use ItemRendererDataBinding, it only gets evaluated once.
    > So dig into this a bit more and show us the stack trace (assuming that's
    > the issue).
    >
    
    Yes, I think is the right way to go, don't thing this issue is a problem
    with the how many times Royale should check the data, but just how to deal
    with nulls/undefined.
    
    
    >
    > 2) There is no limitation in Royale on the maximum level of nested
    > bindings, but you are probably right that things might work in Flex that
    > don't work in Royale, again because Flex evaluated binding expressions
    > quite often, which we don't want to do in Royale for performance reasons.
    > However, in Flex, and Royale, there is always a chance that you could
    > change something deep "too late" and then it wouldn't work.  But if you
    > have your change events propagating properly, you can bind to any level in
    > Royale.  If you have a failure case let's take a look at that as well.  The
    > compiler should be telling you that it can't bind to something.
    >
    >
    That's right, I though it was a nested limitation. Knowing is not that is a
    huge help. I can check in other ways. I'll be warned when I get the next
    binding issue and we can check it.
    
    In the other hand, I remember to see few days ago some bugs in bindings, I
    think was the compiler warn about a binding that could not be done, but was
    working, or something like that. Can't remember right now. Again I'll be
    alert and report here where I find something similar. I think there's still
    some final little bugs to address in bindings, Maybe Greg could give us
    more detail on this, if he has some time.
    
    I think we're a month to work hard in our app to finish, so maybe at the
    middle of January we can share more here about our experience and what
    things we found through our journey so we can think fixes to that
    
    
    -- 
    Carlos Rovira
    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7Cc154f8b23bda4728346108d660de072c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802904085592501&amp;sdata=LCQ%2Fd%2BGtT86gyV0qw7Ptfge8LSzvweGudkf%2Bz2AgnLA%3D&amp;reserved=0
    

Re: Binding Events issues (was Re: Some questions about Jewel Navigation)

[Carlos Rovira <ca...@apache.org>]

Hi Alex

El jue., 13 dic. 2018 a las 2:00, Alex Harui (<ah...@adobe.com.invalid>)
escribió:

>
> 1) What error do you get with null/undefined in renderers?


Really, the error doesn't show clearly on browsers. I could see that in
Google Chrome going to Sources and in the right panel check "Pause on
caught exceptions"

I fixed this in Tour De Jewel (JewelExample), so to see that again you can
go to

NavigationIconLinkItemRenderer.mxml

And in the bindings remove:

<js:FontIcon text="{navlink ? navlink.icon : ''}" material="true"
visible="{navlink
? navlink.icon != null : false}"/>

<html:Span text="{navlink ? navlink.label : ''}"/>

remove the ternaries and left as it should be

Running that in the old state and checking the before mentioned option in
chrome will make Tour de Jewel stops at the beginning as each renderer is
instantiated and throwing an error.


The binding subsystem should have try/catch blocks in the appropriate
> places.  Maybe we are missing something, or maybe there is a bug, or maybe
> there is such a huge cost to automatically protecting against
> null/undefined that it is worth folks being a bit more careful about that
> in Royale.


In the case above, I'm taking care, but IMHO, from a user point of view, I
should not have to write a safeguard in each binding. If that's is always
required *always*, it seems frameworks responsibility, saving lots of
safeguards in users code. This seems to me more PAYG.


> Flex did try to evaluate binding expression often whereas Royale will
> apply binding at different times to improve performance.  Item renderers
> are a classic example.  In Flex, bindings were evaluated twice before the
> data property ever set and a third time when the data finally got set.  In
> Royale, if you use ItemRendererDataBinding, it only gets evaluated once.
> So dig into this a bit more and show us the stack trace (assuming that's
> the issue).
>

Yes, I think is the right way to go, don't thing this issue is a problem
with the how many times Royale should check the data, but just how to deal
with nulls/undefined.


>
> 2) There is no limitation in Royale on the maximum level of nested
> bindings, but you are probably right that things might work in Flex that
> don't work in Royale, again because Flex evaluated binding expressions
> quite often, which we don't want to do in Royale for performance reasons.
> However, in Flex, and Royale, there is always a chance that you could
> change something deep "too late" and then it wouldn't work.  But if you
> have your change events propagating properly, you can bind to any level in
> Royale.  If you have a failure case let's take a look at that as well.  The
> compiler should be telling you that it can't bind to something.
>
>
That's right, I though it was a nested limitation. Knowing is not that is a
huge help. I can check in other ways. I'll be warned when I get the next
binding issue and we can check it.

In the other hand, I remember to see few days ago some bugs in bindings, I
think was the compiler warn about a binding that could not be done, but was
working, or something like that. Can't remember right now. Again I'll be
alert and report here where I find something similar. I think there's still
some final little bugs to address in bindings, Maybe Greg could give us
more detail on this, if he has some time.

I think we're a month to work hard in our app to finish, so maybe at the
middle of January we can share more here about our experience and what
things we found through our journey so we can think fixes to that


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

Re: Binding Events issues (was Re: Some questions about Jewel Navigation)

[Alex Harui <ah...@adobe.com.INVALID>]

I'm first going to answer Greg's question from the other thread since it is probably wise to rename this thread.

Greg asked: "Am I right in interpreting what you say as being that there should be more
event types for binding at the component level? (not just 'change', but
selectedIndexChanged, and selectedItemChanged as well?)"

I would say yes, as long as we are careful about PAYG.  As with any change we want to look at how much code gets added "just-in-case".  What I mean by that is that we don't want to go through the code and blindly add more change events.  Let's look at the actual implementation patterns:

-IMO, the "change" interaction event (or similarly named event) should be dispatched by a Controller, not the model.
-A model is not required to dispatch change events.  The simplest "dumbest" model will take an array of strings that is not supplied "late" by a server and thus the lifecycle can promise that the model is ready to go when the view needs it, and will not change at runtime.
-Other models can change at runtime and should dispatch binding change events if needed.  By default, that would be "somePropertyChanged" (note that Flex used "somePropertyChange", I personally don't care about the tense) but not all properties must fire a uniquely named event.  SelectedItem and SelectedIndex are usually related so a single "selectionChange" event should be dispatched.  There may be other situations where a bunch of properties change and then there is some final property change that "commits" it, and maybe only that property needs to dispatch an event.  We don't want to dispatch a ton of events just-in-case if we can avoid it.  Nor do we want to carry code around that dispatches those events.  The pattern of using hasEventListener can be used but doesn't seem lightweight enough to be used everywhere.  Because everything is replaceable in Royale, if someone needs a model that dispatches more events, they can always create such a model.  We want to find the balance between handling the right percentage of cases for the right amount of code.  The Flex philosophy was more about trying to handle nearly 100% of case by adding as much code as we had time for.  But that results in too much just-in-case code.

So that's where the code goes, but then you need [Bindable("eventName")] metadata.  The cost of Bindable metadata in JS is significant, but it all ends up in a data structure that can be removed from the code by Closure Compiler.  But if it any code in a compilation needs the Metadata, then all of it is kept in every class in the compilation.  But if you already have one metadata on an API, adding a second isn't much more expensive than adding that string to the output.  So I think it shouldn't be a huge impact to add both "selectionChange" and "change" as metadata on an API.

OK, now to Carlos's questions:

1) What error do you get with null/undefined in renderers?  The binding subsystem should have try/catch blocks in the appropriate places.  Maybe we are missing something, or maybe there is a bug, or maybe there is such a huge cost to automatically protecting against null/undefined that it is worth folks being a bit more careful about that in Royale.  Flex did try to evaluate binding expression often whereas Royale will apply binding at different times to improve performance.  Item renderers are a classic example.  In Flex, bindings were evaluated twice before the data property ever set and a third time when the data finally got set.  In Royale, if you use ItemRendererDataBinding, it only gets evaluated once.  So dig into this a bit more and show us the stack trace (assuming that's the issue).

2) There is no limitation in Royale on the maximum level of nested bindings, but you are probably right that things might work in Flex that don't work in Royale, again because Flex evaluated binding expressions quite often, which we don't want to do in Royale for performance reasons.  However, in Flex, and Royale, there is always a chance that you could change something deep "too late" and then it wouldn't work.  But if you have your change events propagating properly, you can bind to any level in Royale.  If you have a failure case let's take a look at that as well.  The compiler should be telling you that it can't bind to something.

HTH,
-Alex

On 12/12/18, 2:19 PM, "Carlos Rovira" <ca...@apache.org> wrote:

    Hi Alex,
    
    regarding Binding Events, our experience is that is a bit more hard to work
    with them in Royale than in Flex. The main issues we are experiencing are:
    
    1.- In almost all renderers we need to check for null/undefined while in
    flex is not needed:
    
    text="{optionPack ? optionPack.description : ''}"
    
    the getter in that renderer is
    
    [Bindable(event="dataChange")]
                public function get optionPack():Base7OptionPack
                {
                    return data as Base7OptionPack;
                }
    
    migrated from Flex 100% equal
    
    I expect to bind in the following way:
    
    text="{optionPack.description}"
    
    I think our user code will be more PAYG if renderers consider it self the
    nulls/undefineds, instead to make users to make consider in almost any
    binding.
    
    
    2.- Level of nested bindings
    
    I think the maximum level of nested properties accessed in a binding is
    around 3.
    
    So {foo.woo.zoo} can work but {foo.woo.zoo.noo} will not, while in flex
    workd
    
    I think that's the two main issue we see in this real world Apache Royale
    project we are immerse now.
    
    Thanks
    
    
    El mié., 12 dic. 2018 a las 22:54, Alex Harui (<ah...@adobe.com.invalid>)
    escribió:
    
    > I may have missed something, and DispatchChangeOnStartup is a proper bead,
    > especially for a first attempt, but theoretically, it shouldn't be needed.
    >
    > There are different categories of events in Flex and Royale.  I'm not sure
    > there is a complete list of categories, but ones that pop to mind are:
    >
    > 1) Low-level interaction events
    > 2) Higher-level interaction events
    > 3) Binding events.
    >
    > Things like mouseDown and mouseUp are low-level interaction events.  CLICK
    > and CHANGE are higher-level interaction events.  They imply that some
    > series of interactions occurred (CLICK= mouseDown+mouseUp).  ITEM_CLICK is
    > even higher level, it implies that a click occurred on an ItemRenderer and
    > not, say, the scrollbar button in a List.  Thus, writing code to dispatch
    > CHANGE events outside of controller logic is roughly equivalent to faking
    > mouse and keyboard events.  Sometimes you gotta do it, but usually it
    > implies that something else isn't quite right.
    >
    > Sometimes it helps to think about whether such a thing was needed in Flex
    > and how similar setups worked there.  It could be Royale is missing
    > something, or something isn't quite right yet.  In fact, the Royale binding
    > system is trying to be less aggressive and thus have less overhead than
    > Flex, but theoretically, the flow of binding events should propagate
    > properly to all concerned, so it would be interesting to really understand
    > why such a thing was needed.  Maybe something is truly only needed at
    > startup, but often these things end up being needed elsewhere "later" like
    > on state changes or module loads.
    >
    > The binding system in Royale can handle multiple events.  Models are PAYG,
    > so some models expect runtime changes and simpler ones don't to save on
    > cost.  But for models that expect runtime changes (required for any model
    > representing asynchronous data loading), the binding events should
    > propagate appropriately.  Flex used (or maybe overused) VALUE_COMMIT
    > events.  We can do that, but right now the pattern is to make a unique
    > event name.  So selectedIndex should dispatch selectedIndexChanged no
    > matter how it got changed and that should propagate through other
    > bindings.  When the dataProvider changes, if that affects the
    > selectedIndex, then the model should set the selectedIndex and dispatch
    > selectedIndexChanged.  There shouldn't be a need to dispatch "change" until
    > someone interacts with the component.  Differentiating between the two
    > usually helps make setup code simpler.  You can assign initial values to
    > things without reacting everywhere to the change.
    >
    > Of course, I could be wrong.
    > HTH,
    > -Alex
    >
    >
    
    -- 
    Carlos Rovira
    https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C845fdb43a0214bc4cce908d6607fda10%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802499588879997&amp;sdata=vpjGbNp1WeCJ2gziDUrZRBWzRv%2FcKAvdlPUt5oPiwTk%3D&amp;reserved=0
    

Binding Events issues (was Re: Some questions about Jewel Navigation)

[Carlos Rovira <ca...@apache.org>]

Hi Alex,

regarding Binding Events, our experience is that is a bit more hard to work
with them in Royale than in Flex. The main issues we are experiencing are:

1.- In almost all renderers we need to check for null/undefined while in
flex is not needed:

text="{optionPack ? optionPack.description : ''}"

the getter in that renderer is

[Bindable(event="dataChange")]
            public function get optionPack():Base7OptionPack
            {
                return data as Base7OptionPack;
            }

migrated from Flex 100% equal

I expect to bind in the following way:

text="{optionPack.description}"

I think our user code will be more PAYG if renderers consider it self the
nulls/undefineds, instead to make users to make consider in almost any
binding.


2.- Level of nested bindings

I think the maximum level of nested properties accessed in a binding is
around 3.

So {foo.woo.zoo} can work but {foo.woo.zoo.noo} will not, while in flex
workd

I think that's the two main issue we see in this real world Apache Royale
project we are immerse now.

Thanks


El mié., 12 dic. 2018 a las 22:54, Alex Harui (<ah...@adobe.com.invalid>)
escribió:

> I may have missed something, and DispatchChangeOnStartup is a proper bead,
> especially for a first attempt, but theoretically, it shouldn't be needed.
>
> There are different categories of events in Flex and Royale.  I'm not sure
> there is a complete list of categories, but ones that pop to mind are:
>
> 1) Low-level interaction events
> 2) Higher-level interaction events
> 3) Binding events.
>
> Things like mouseDown and mouseUp are low-level interaction events.  CLICK
> and CHANGE are higher-level interaction events.  They imply that some
> series of interactions occurred (CLICK= mouseDown+mouseUp).  ITEM_CLICK is
> even higher level, it implies that a click occurred on an ItemRenderer and
> not, say, the scrollbar button in a List.  Thus, writing code to dispatch
> CHANGE events outside of controller logic is roughly equivalent to faking
> mouse and keyboard events.  Sometimes you gotta do it, but usually it
> implies that something else isn't quite right.
>
> Sometimes it helps to think about whether such a thing was needed in Flex
> and how similar setups worked there.  It could be Royale is missing
> something, or something isn't quite right yet.  In fact, the Royale binding
> system is trying to be less aggressive and thus have less overhead than
> Flex, but theoretically, the flow of binding events should propagate
> properly to all concerned, so it would be interesting to really understand
> why such a thing was needed.  Maybe something is truly only needed at
> startup, but often these things end up being needed elsewhere "later" like
> on state changes or module loads.
>
> The binding system in Royale can handle multiple events.  Models are PAYG,
> so some models expect runtime changes and simpler ones don't to save on
> cost.  But for models that expect runtime changes (required for any model
> representing asynchronous data loading), the binding events should
> propagate appropriately.  Flex used (or maybe overused) VALUE_COMMIT
> events.  We can do that, but right now the pattern is to make a unique
> event name.  So selectedIndex should dispatch selectedIndexChanged no
> matter how it got changed and that should propagate through other
> bindings.  When the dataProvider changes, if that affects the
> selectedIndex, then the model should set the selectedIndex and dispatch
> selectedIndexChanged.  There shouldn't be a need to dispatch "change" until
> someone interacts with the component.  Differentiating between the two
> usually helps make setup code simpler.  You can assign initial values to
> things without reacting everywhere to the change.
>
> Of course, I could be wrong.
> HTH,
> -Alex
>
>

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

Re: Some questions about Jewel Navigation

[Greg Dove <gr...@gmail.com>]

There shouldn't be a need to dispatch "change" until someone interacts with
the component.  Differentiating between the two usually helps make setup
code simpler.  You can assign initial values to things without reacting
everywhere to the change.

The issue in general was related to binding, which was based on change
events. And the broader context is in relation to porting legacy flex code
while minimizing the changes to the code.
Am I right in interpreting what you say as being that there should be more
event types for binding at the component level? (not just 'change', but
selectedIndexChanged, and selectedItemChanged as well?)



On Thu, Dec 13, 2018 at 10:54 AM Alex Harui <ah...@adobe.com.invalid>
wrote:

> I may have missed something, and DispatchChangeOnStartup is a proper bead,
> especially for a first attempt, but theoretically, it shouldn't be needed.
>
> There are different categories of events in Flex and Royale.  I'm not sure
> there is a complete list of categories, but ones that pop to mind are:
>
> 1) Low-level interaction events
> 2) Higher-level interaction events
> 3) Binding events.
>
> Things like mouseDown and mouseUp are low-level interaction events.  CLICK
> and CHANGE are higher-level interaction events.  They imply that some
> series of interactions occurred (CLICK= mouseDown+mouseUp).  ITEM_CLICK is
> even higher level, it implies that a click occurred on an ItemRenderer and
> not, say, the scrollbar button in a List.  Thus, writing code to dispatch
> CHANGE events outside of controller logic is roughly equivalent to faking
> mouse and keyboard events.  Sometimes you gotta do it, but usually it
> implies that something else isn't quite right.
>
> Sometimes it helps to think about whether such a thing was needed in Flex
> and how similar setups worked there.  It could be Royale is missing
> something, or something isn't quite right yet.  In fact, the Royale binding
> system is trying to be less aggressive and thus have less overhead than
> Flex, but theoretically, the flow of binding events should propagate
> properly to all concerned, so it would be interesting to really understand
> why such a thing was needed.  Maybe something is truly only needed at
> startup, but often these things end up being needed elsewhere "later" like
> on state changes or module loads.
>
> The binding system in Royale can handle multiple events.  Models are PAYG,
> so some models expect runtime changes and simpler ones don't to save on
> cost.  But for models that expect runtime changes (required for any model
> representing asynchronous data loading), the binding events should
> propagate appropriately.  Flex used (or maybe overused) VALUE_COMMIT
> events.  We can do that, but right now the pattern is to make a unique
> event name.  So selectedIndex should dispatch selectedIndexChanged no
> matter how it got changed and that should propagate through other
> bindings.  When the dataProvider changes, if that affects the
> selectedIndex, then the model should set the selectedIndex and dispatch
> selectedIndexChanged.  There shouldn't be a need to dispatch "change" until
> someone interacts with the component.  Differentiating between the two
> usually helps make setup code simpler.  You can assign initial values to
> things without reacting everywhere to the change.
>
> Of course, I could be wrong.
> HTH,
> -Alex
>
>
> On 12/12/18, 10:55 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
>     I made changes to address some issues, but I no doubt used the wrong
>     pattern, sorry guys.
>     I have mainly focused on non-UI code in the past, or custom UI
> components
>     without beads in some other work I did last year so 'beads' is still
>     something I am getting used to (although composition in general is
> not).
>
>     I never wrote any actual beads before DispatchChangeOnStartup, that
> was the
>     first bead I ever wrote and may still not be 'right', it was a quick
> fix
>     for a specific case and I did not have time to go back and
> review/refactor
>     what I did elsewhere to get the lists working for programmatic changes.
>
>     Piotr, thanks for looking into this. In terms of 'double dispatch' I
> also
>     remember seeing somewhere that there are some overrides that dispatch
>     events but call the super setter that also dispatches the same event.
> I did
>     not have time to look into that in more detail. That could be in
> renderers
>     with 'dataChange' iirc ... not related to what you are looking at, but
> that
>     just made me think of it.
>
>     I will be happy to look more into these things and contribute more to
> Jewel
>     in time, when I also get some free time.
>
>
>
>
>     On Thu, Dec 13, 2018 at 1:24 AM Piotr Zarzycki <
> piotrzarzycki21@gmail.com>
>     wrote:
>
>     > Yep - I just did quick look into the bead and it's essentially have
> those
>     > things which are currently baked into Model. I hopefully remove that
> one
>     > and replace things using bead in Jewel Example.
>     >
>     > Thanks for adding that!
>     > Piotr
>     >
>     > śr., 12 gru 2018 o 13:04 Carlos Rovira <ca...@apache.org>
>     > napisał(a):
>     >
>     > > Hi Piotr,
>     > >
>     > > just migrated the bead I talked (DispatchChangeOnStartup) from our
>     > project
>     > > to royale so you can have all the pieces and help you to diagnose
> the
>     > > problem
>     > >
>     > > As I said you Greg did the latest changes on this components so I
> should
>     > as
>     > > well read the changes since I didn't have to analyze since that was
>     > working
>     > > in our app in many parts flawlessly.
>     > >
>     > > thanks for taking care and good luck
>     > >
>     > > :)
>     > >
>     > > El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (<
>     > > piotrzarzycki21@gmail.com>) escribió:
>     > >
>     > > > Hi Carlos,
>     > > >
>     > > > Comments inline.
>     > > >
>     > > > śr., 12 gru 2018 o 10:44 Carlos Rovira <
> carlos.rovira@codeoscopic.com>
>     > > > napisał(a):
>     > > >
>     > > > > Hi Piotr,
>     > > > >
>     > > > > This month Greg and I made some changes to get selectedIndex
> and
>     > > > > selectedItem work in List, ComboBox and DropDownList. Since
>     > Navigation
>     > > > is a
>     > > > > List in essence, is involved in this changes. We should see
> how to
>     > > avoid
>     > > > > the duplicated event without lost the current workflow that
> now is
>     > > > working
>     > > > > properly like it was in flex days. Was hard to reach to that
> point.
>     > > > >
>     > > > > About options, we already have a bead to dispatch a change
> event on
>     > > > startup
>     > > > > in our project that we must pass to Jewel library. But I think
> is not
>     > > > what
>     > > > > we want here. We want setting selectedIndex/selectedItem in
> mxml
>     > should
>     > > > put
>     > > > > the component in proper state. I think that's what you refer
> when
>     > talk
>     > > > > about getting to work "programmatically" right?
>     > > > >
>     > > > >
>     > > > *Generally yes those actions should put component in proper
> state, but
>     > I
>     > > > just feeling that those state should not be achieved through
> model
>     > which
>     > > > dispatch "change" event. "change" event is to tell user that
> someone
>     > > > interact with component from UI. If developer interacting
> through code
>     > > > selectedIndexChanged and selectedItemChanged should probably
> come with
>     > > > help.*
>     > > >
>     > > >
>     > > > > Basically I think we have all needed beads in place, So I'll
> try the
>     > > > > removal option. But I think that event was copied from Basic
> version,
>     > > so
>     > > > > maybe is right (can ensure right now). You can try to do it
> yourself.
>     > > You
>     > > > > should check Jewel Example (Tour de Jewel) and specially List,
>     > ComboBox
>     > > > and
>     > > > > DropDownList sections along Navigation (that is used in the
> drawer)
>     > and
>     > > > > check you don't see regressions when doing changes. See how the
>     > > examples
>     > > > > behave actually, and since debugger now works perfectly, you
> can put
>     > > > break
>     > > > > points to see where's the problem and how to diagnose the right
>     > > solution.
>     > > > >
>     > > > >
>     > > > *Yes ArrayListSelectionModel is essentially copy of Basic one,
> but you
>     > > have
>     > > > added there code which dispatch "change" event plus property
> which
>     > > > generally allows you to do this or not
>     > > (dispatchChangeOnDataProviderChange)
>     > > > - That whole part even if should exists - should be probably
> exposed to
>     > > > separate bead. *
>     > > > *I'm surprised that you don't have any problems using in your
>     > > applications
>     > > > Bead for dispatch "change" event +
> ListSingleSelectionMouseController
>     > > (it
>     > > > also dispatch that event) + model - All are able to dispatch
> change in
>     > > > almost the same cases!*
>     > > >
>     > > > *Ok I think I will have to work on that with all cautious to
> current
>     > > code.*
>     > > >
>     > > >
>     > > > > Thanks! :)
>     > > > >
>     > > > >
>     > > > >
>     > > > >
>     > > > > El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
>     > > > > piotrzarzycki21@gmail.com>) escribió:
>     > > > >
>     > > > > > Carlos,
>     > > > > >
>     > > > > > I just looked into the problem with double call of change
> event.
>     > You
>     > > > are
>     > > > > > using as default ListSingleSelectionMouseController - in
> navigation
>     > > > > > component which is calling "change" event once someone is
> clicking
>     > on
>     > > > > item.
>     > > > > >
>     > > > > > However you are doing it again from ArrayListSelectionModel
> which
>     > > > > probably
>     > > > > > shouldn't happen. This model is calling only
> selectedItemChanged,
>     > > > > > *selectedIndexChanged. *
>     > > > > >
>     > > > > > I'm assuming you are calling "change" event in
>     > > ArrayListSelectionModel
>     > > > > > cause you wanted to know whether someone has changed
> selectedItem
>     > and
>     > > > > > selectedIndex programmatically . If that was the case you
> should
>     > > > create a
>     > > > > > bead which listening for events from model and react in
> specific
>     > way.
>     > > > > >
>     > > > > > My proposition is:
>     > > > > > 1) Remove call of change event from Jewel
> ArrayListSelectionModel
>     > > > > > 2) Create a bead if you need for operation of programmatic
> change -
>     > > in
>     > > > > that
>     > > > > > case do not use in parallel
> ListSingleSelectionMouseController
>     > > > > >
>     > > > > > Thoughts ?
>     > > > > >
>     > > > > > Thanks,
>     > > > > > Piotr
>     > > > > >
>     > > > > > wt., 11 gru 2018 o 22:13 Carlos Rovira <
> carlosrovira@apache.org>
>     > > > > > napisał(a):
>     > > > > >
>     > > > > > > Hi Piotr,
>     > > > > > >
>     > > > > > > but .nav will not do anything. As I write before the right
> things
>     > > > > should
>     > > > > > be
>     > > > > > >
>     > > > > > > .jewel.navigation
>     > > > > > > background-color: transparent
>     > > > > > >
>     > > > > > > This in you App css will win over the one in the theme.
>     > > > > > >
>     > > > > > > Didn't try, but that should work, at least is what I do
> when I
>     > want
>     > > > > some
>     > > > > > > quick change to try or something temporal, or even could
> be a
>     > final
>     > > > > > change
>     > > > > > > too depending on the case.
>     > > > > > >
>     > > > > > >
>     > > > > > > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
>     > > > > > > piotrzarzycki21@gmail.com>) escribió:
>     > > > > > >
>     > > > > > > > I have tried to do point #2 from your options, but when I
>     > declare
>     > > > my
>     > > > > > own
>     > > > > > > > class:
>     > > > > > > >
>     > > > > > > > .nav {
>     > > > > > > > background-color: #ffffff
>     > > > > > > > }
>     > > > > > > >
>     > > > > > > > It's being override by those one from framework. Maybe I
> have
>     > to
>     > > > > > > inherited
>     > > > > > > > from framework classes ?
>     > > > > > > >
>     > > > > > > > Thanks, Piotr
>     > > > > > > >
>     > > > > > > > wt., 11 gru 2018 o 20:44 Carlos Rovira <
>     > carlosrovira@apache.org>
>     > > > > > > > napisał(a):
>     > > > > > > >
>     > > > > > > > > Hi Piotr,
>     > > > > > > > >
>     > > > > > > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
>     > > > > > > > > piotrzarzycki21@gmail.com>) escribió:
>     > > > > > > > >
>     > > > > > > > > > Hi Carlos,
>     > > > > > > > > >
>     > > > > > > > > > I have started playing using Jewel lately more
> serious and
>     > > have
>     > > > > two
>     > > > > > > > > > questions related to Jewel Navigation component.
>     > > > > > > > > >
>     > > > > > > > > > I'm displaying horizontal navigation like that [1].
> Because
>     > > > > > > Navigation
>     > > > > > > > is
>     > > > > > > > > > actually list my background color is white. The
> question is
>     > > how
>     > > > > to
>     > > > > > > make
>     > > > > > > > > my
>     > > > > > > > > > navigation transparent component transparent? I know
> that I
>     > > > could
>     > > > > > > make
>     > > > > > > > > some
>     > > > > > > > > > css trick, but maybe you have a better solution.
>     > > > > > > > > >
>     > > > > > > > > >
>     > > > > > > > > each component use to have a css in Jewel and other
> one in
>     > > > > JewelTheme
>     > > > > > > > (95%
>     > > > > > > > > of cases)
>     > > > > > > > > I still need to write some wiki for all of this
>     > > > > > > > > In the meanwhile, search for file "_navigation.sass".
> The one
>     > > in
>     > > > > > Jewel
>     > > > > > > > has
>     > > > > > > > > definitions for beads and use to have some
>     > > > > > > > > standard css for things regarding "structure"
>     > > > > > > > > in the _navigation.sass in JewelTheme instead you'll
> not find
>     > > > > almost
>     > > > > > > any
>     > > > > > > > > Royale bead, and css more related to colors,
> animations,
>     > fonts,
>     > > > > > sizes,
>     > > > > > > > > ....so more "theme" things that people would want to
> change.
>     > > > > > > > >
>     > > > > > > > > There you'll find
>     > > > > > > > >
>     > > > > > > > > // Navigation variables
>     > > > > > > > > .jewel.navigation
>     > > > > > > > > background-color: #ffffff
>     > > > > > > > >
>     > > > > > > > > So, you can do in many ways:
>     > > > > > > > >
>     > > > > > > > > 1) Create your own theme with the same structure as
>     > JewelTheme
>     > > > and
>     > > > > > just
>     > > > > > > > > change this navigation thing
>     > > > > > > > > 2) just do in your app in you css, since that will be
> taken
>     > > > instead
>     > > > > > the
>     > > > > > > > > JewelTheme
>     > > > > > > > >
>     > > > > > > > > Notice that this will change when we implement full
> dark
>     > mode,
>     > > > that
>     > > > > > > > > navigation still doesn't support since
>     > > > > > > > > that component was made after I make dark mode and
> still
>     > don't
>     > > > have
>     > > > > > > that
>     > > > > > > > > implemented in SASS so
>     > > > > > > > > compiling SASS will generate a light/dark theme and/or
>     > > > flat/noflat
>     > > > > > > theme
>     > > > > > > > >
>     > > > > > > > > Another question is - Did you notice that Navigation
>     > component
>     > > > fire
>     > > > > > > > change
>     > > > > > > > > > event two times - whenever you click on the item ?
>     > > > > > > > > >
>     > > > > > > > > >
>     > > > > > > > > Thanks for reporting, I didn't notice, please feel
> free to
>     > fix
>     > > > > that,
>     > > > > > > just
>     > > > > > > > > take into account that navigation renderer
> preventdefault to
>     > > > avoid
>     > > > > > > trying
>     > > > > > > > > to open a web page. I see this in the way google
> material
>     > > solved
>     > > > > > > > navigation
>     > > > > > > > > things
>     > > > > > > > > but maybe could be a better way to do it
>     > > > > > > > >
>     > > > > > > > > Thanks!
>     > > > > > > > >
>     > > > > > > > > Carlos
>     > > > > > > > >
>     > > > > > > > >
>     > > > > > > > >
>     > > > > > > > > --
>     > > > > > > > > Carlos Rovira
>     > > > > > > > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=e2ZQbKg%2FXUEIWAlQw9ETRBUg848T9WuhCablQtswPpE%3D&amp;reserved=0
>     > > > > > > > >
>     > > > > > > >
>     > > > > > > >
>     > > > > > > > --
>     > > > > > > >
>     > > > > > > > Piotr Zarzycki
>     > > > > > > >
>     > > > > > > > Patreon: *
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
>     > > > > > > > <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
> >*
>     > > > > > > >
>     > > > > > >
>     > > > > > >
>     > > > > > > --
>     > > > > > > Carlos Rovira
>     > > > > > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=e2ZQbKg%2FXUEIWAlQw9ETRBUg848T9WuhCablQtswPpE%3D&amp;reserved=0
>     > > > > > >
>     > > > > >
>     > > > > >
>     > > > > > --
>     > > > > >
>     > > > > > Piotr Zarzycki
>     > > > > >
>     > > > > > Patreon: *
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
>     > > > > > <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
> >*
>     > > > > >
>     > > > >
>     > > > >
>     > > > > --
>     > > > >
>     > > > > <
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=eOroBUQP4blbUxXbxFazya1rs82Cz7cxJFmVEzoU7uw%3D&amp;reserved=0
> >
>     > > > >
>     > > > > Carlos Rovira
>     > > > >
>     > > > > Presidente Ejecutivo
>     > > > >
>     > > > > M: +34 607 22 60 05
>     > > > >
>     > > > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=eOroBUQP4blbUxXbxFazya1rs82Cz7cxJFmVEzoU7uw%3D&amp;reserved=0
>     > > > >
>     > > > >
>     > > > > Conócenos en 1 minuto! <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=LGfF9Q0nxjkPpihQ1oO4qxE%2FwCL6Yzzg2fFyU%2FusKD8%3D&amp;reserved=0
> >
>     > > > >
>     > > > >
>     > > > > AVISO LEGAL: La información contenida en este correo
> electrónico, y
>     > en
>     > > su
>     > > > > caso en los documentos adjuntos, es información privilegiada
> para uso
>     > > > > exclusivo de la persona y/o personas a las que va dirigido. No
> está
>     > > > > permitido el acceso a este mensaje a cualquier otra persona
> distinta
>     > a
>     > > > los
>     > > > > indicados. Si Usted no es uno de los destinatarios, cualquier
>     > > > duplicación,
>     > > > > reproducción, distribución, así como cualquier uso de la
> información
>     > > > > contenida en él o cualquiera otra acción u omisión tomada en
> relación
>     > > con
>     > > > > el mismo, está prohibida y puede ser ilegal. En dicho caso, por
>     > favor,
>     > > > > notifíquelo al remitente y proceda a la eliminación de este
> correo
>     > > > > electrónico, así como de sus adjuntos si los hubiere. En
> cumplimiento
>     > > de
>     > > > la
>     > > > > legislación española vigente en materia de protección de datos
> de
>     > > > carácter
>     > > > > personal y del RGPD 679/2016 le informamos que sus datos están
> siendo
>     > > > > objeto de tratamiento por parte de CODEOSCOPIC S.A. con
> CIFA85677342,
>     > > con
>     > > > > la finalidad del mantenimiento y gestión de relaciones
> comerciales y
>     > > > > administrativas. La base jurídica del tratamiento es el interés
>     > > legítimo
>     > > > de
>     > > > > la empresa. No se prevén cesiones de sus datos, salvo que
> exista una
>     > > > > obligación legal. Para ejercitar sus derechos puede dirigirse a
>     > > > CODEOSCOPIC
>     > > > > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
>     > > (MADRID), o
>     > > > > bien por email adpd@codeoscopic.com, con el fin de ejercer sus
>     > > derechos
>     > > > de
>     > > > > acceso, rectificación, supresión (derecho al olvido),
> limitación de
>     > > > > tratamiento, portabilidad de los datos, oposición, y a no ser
> objeto
>     > de
>     > > > > decisiones automatizadas, indicando como Asunto: “Derechos Ley
>     > > Protección
>     > > > > de Datos”, y adjuntando fotocopia de su DNI. Delegado de
> protección
>     > de
>     > > > > datos:dpd@codeoscopic.com
>     > > > >
>     > > >
>     > > >
>     > > > --
>     > > >
>     > > > Piotr Zarzycki
>     > > >
>     > > > Patreon: *
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
>     > > > <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
> >*
>     > > >
>     > >
>     > >
>     > > --
>     > > Carlos Rovira
>     > >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=e2ZQbKg%2FXUEIWAlQw9ETRBUg848T9WuhCablQtswPpE%3D&amp;reserved=0
>     > >
>     >
>     >
>     > --
>     >
>     > Piotr Zarzycki
>     >
>     > Patreon: *
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
>     > <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
> >*
>     >
>
>
>

Re: Some questions about Jewel Navigation

[Alex Harui <ah...@adobe.com.INVALID>]

I may have missed something, and DispatchChangeOnStartup is a proper bead, especially for a first attempt, but theoretically, it shouldn't be needed.

There are different categories of events in Flex and Royale.  I'm not sure there is a complete list of categories, but ones that pop to mind are:

1) Low-level interaction events
2) Higher-level interaction events
3) Binding events.

Things like mouseDown and mouseUp are low-level interaction events.  CLICK and CHANGE are higher-level interaction events.  They imply that some series of interactions occurred (CLICK= mouseDown+mouseUp).  ITEM_CLICK is even higher level, it implies that a click occurred on an ItemRenderer and not, say, the scrollbar button in a List.  Thus, writing code to dispatch CHANGE events outside of controller logic is roughly equivalent to faking mouse and keyboard events.  Sometimes you gotta do it, but usually it implies that something else isn't quite right.

Sometimes it helps to think about whether such a thing was needed in Flex and how similar setups worked there.  It could be Royale is missing something, or something isn't quite right yet.  In fact, the Royale binding system is trying to be less aggressive and thus have less overhead than Flex, but theoretically, the flow of binding events should propagate properly to all concerned, so it would be interesting to really understand why such a thing was needed.  Maybe something is truly only needed at startup, but often these things end up being needed elsewhere "later" like on state changes or module loads.

The binding system in Royale can handle multiple events.  Models are PAYG, so some models expect runtime changes and simpler ones don't to save on cost.  But for models that expect runtime changes (required for any model representing asynchronous data loading), the binding events should propagate appropriately.  Flex used (or maybe overused) VALUE_COMMIT events.  We can do that, but right now the pattern is to make a unique event name.  So selectedIndex should dispatch selectedIndexChanged no matter how it got changed and that should propagate through other bindings.  When the dataProvider changes, if that affects the selectedIndex, then the model should set the selectedIndex and dispatch selectedIndexChanged.  There shouldn't be a need to dispatch "change" until someone interacts with the component.  Differentiating between the two usually helps make setup code simpler.  You can assign initial values to things without reacting everywhere to the change.

Of course, I could be wrong.  
HTH,
-Alex


On 12/12/18, 10:55 AM, "Greg Dove" <gr...@gmail.com> wrote:

    I made changes to address some issues, but I no doubt used the wrong
    pattern, sorry guys.
    I have mainly focused on non-UI code in the past, or custom UI components
    without beads in some other work I did last year so 'beads' is still
    something I am getting used to (although composition in general is not).
    
    I never wrote any actual beads before DispatchChangeOnStartup, that was the
    first bead I ever wrote and may still not be 'right', it was a quick fix
    for a specific case and I did not have time to go back and review/refactor
    what I did elsewhere to get the lists working for programmatic changes.
    
    Piotr, thanks for looking into this. In terms of 'double dispatch' I also
    remember seeing somewhere that there are some overrides that dispatch
    events but call the super setter that also dispatches the same event. I did
    not have time to look into that in more detail. That could be in renderers
    with 'dataChange' iirc ... not related to what you are looking at, but that
    just made me think of it.
    
    I will be happy to look more into these things and contribute more to Jewel
    in time, when I also get some free time.
    
    
    
    
    On Thu, Dec 13, 2018 at 1:24 AM Piotr Zarzycki <pi...@gmail.com>
    wrote:
    
    > Yep - I just did quick look into the bead and it's essentially have those
    > things which are currently baked into Model. I hopefully remove that one
    > and replace things using bead in Jewel Example.
    >
    > Thanks for adding that!
    > Piotr
    >
    > śr., 12 gru 2018 o 13:04 Carlos Rovira <ca...@apache.org>
    > napisał(a):
    >
    > > Hi Piotr,
    > >
    > > just migrated the bead I talked (DispatchChangeOnStartup) from our
    > project
    > > to royale so you can have all the pieces and help you to diagnose the
    > > problem
    > >
    > > As I said you Greg did the latest changes on this components so I should
    > as
    > > well read the changes since I didn't have to analyze since that was
    > working
    > > in our app in many parts flawlessly.
    > >
    > > thanks for taking care and good luck
    > >
    > > :)
    > >
    > > El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (<
    > > piotrzarzycki21@gmail.com>) escribió:
    > >
    > > > Hi Carlos,
    > > >
    > > > Comments inline.
    > > >
    > > > śr., 12 gru 2018 o 10:44 Carlos Rovira <ca...@codeoscopic.com>
    > > > napisał(a):
    > > >
    > > > > Hi Piotr,
    > > > >
    > > > > This month Greg and I made some changes to get selectedIndex and
    > > > > selectedItem work in List, ComboBox and DropDownList. Since
    > Navigation
    > > > is a
    > > > > List in essence, is involved in this changes. We should see how to
    > > avoid
    > > > > the duplicated event without lost the current workflow that now is
    > > > working
    > > > > properly like it was in flex days. Was hard to reach to that point.
    > > > >
    > > > > About options, we already have a bead to dispatch a change event on
    > > > startup
    > > > > in our project that we must pass to Jewel library. But I think is not
    > > > what
    > > > > we want here. We want setting selectedIndex/selectedItem in mxml
    > should
    > > > put
    > > > > the component in proper state. I think that's what you refer when
    > talk
    > > > > about getting to work "programmatically" right?
    > > > >
    > > > >
    > > > *Generally yes those actions should put component in proper state, but
    > I
    > > > just feeling that those state should not be achieved through model
    > which
    > > > dispatch "change" event. "change" event is to tell user that someone
    > > > interact with component from UI. If developer interacting through code
    > > > selectedIndexChanged and selectedItemChanged should probably come with
    > > > help.*
    > > >
    > > >
    > > > > Basically I think we have all needed beads in place, So I'll try the
    > > > > removal option. But I think that event was copied from Basic version,
    > > so
    > > > > maybe is right (can ensure right now). You can try to do it yourself.
    > > You
    > > > > should check Jewel Example (Tour de Jewel) and specially List,
    > ComboBox
    > > > and
    > > > > DropDownList sections along Navigation (that is used in the drawer)
    > and
    > > > > check you don't see regressions when doing changes. See how the
    > > examples
    > > > > behave actually, and since debugger now works perfectly, you can put
    > > > break
    > > > > points to see where's the problem and how to diagnose the right
    > > solution.
    > > > >
    > > > >
    > > > *Yes ArrayListSelectionModel is essentially copy of Basic one, but you
    > > have
    > > > added there code which dispatch "change" event plus property which
    > > > generally allows you to do this or not
    > > (dispatchChangeOnDataProviderChange)
    > > > - That whole part even if should exists - should be probably exposed to
    > > > separate bead. *
    > > > *I'm surprised that you don't have any problems using in your
    > > applications
    > > > Bead for dispatch "change" event +  ListSingleSelectionMouseController
    > > (it
    > > > also dispatch that event) + model - All are able to dispatch change in
    > > > almost the same cases!*
    > > >
    > > > *Ok I think I will have to work on that with all cautious to current
    > > code.*
    > > >
    > > >
    > > > > Thanks! :)
    > > > >
    > > > >
    > > > >
    > > > >
    > > > > El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
    > > > > piotrzarzycki21@gmail.com>) escribió:
    > > > >
    > > > > > Carlos,
    > > > > >
    > > > > > I just looked into the problem with double call of change event.
    > You
    > > > are
    > > > > > using as default ListSingleSelectionMouseController - in navigation
    > > > > > component which is calling "change" event once someone is clicking
    > on
    > > > > item.
    > > > > >
    > > > > > However you are doing it again from ArrayListSelectionModel which
    > > > > probably
    > > > > > shouldn't happen. This model is calling only selectedItemChanged,
    > > > > > *selectedIndexChanged. *
    > > > > >
    > > > > > I'm assuming you are calling "change" event in
    > > ArrayListSelectionModel
    > > > > > cause you wanted to know whether someone has changed selectedItem
    > and
    > > > > > selectedIndex programmatically . If that was the case you should
    > > > create a
    > > > > > bead which listening for events from model and react in specific
    > way.
    > > > > >
    > > > > > My proposition is:
    > > > > > 1) Remove call of change event from Jewel ArrayListSelectionModel
    > > > > > 2) Create a bead if you need for operation of programmatic change -
    > > in
    > > > > that
    > > > > > case do not use in parallel ListSingleSelectionMouseController
    > > > > >
    > > > > > Thoughts ?
    > > > > >
    > > > > > Thanks,
    > > > > > Piotr
    > > > > >
    > > > > > wt., 11 gru 2018 o 22:13 Carlos Rovira <ca...@apache.org>
    > > > > > napisał(a):
    > > > > >
    > > > > > > Hi Piotr,
    > > > > > >
    > > > > > > but .nav will not do anything. As I write before the right things
    > > > > should
    > > > > > be
    > > > > > >
    > > > > > > .jewel.navigation
    > > > > > > background-color: transparent
    > > > > > >
    > > > > > > This in you App css will win over the one in the theme.
    > > > > > >
    > > > > > > Didn't try, but that should work, at least is what I do when I
    > want
    > > > > some
    > > > > > > quick change to try or something temporal, or even could be a
    > final
    > > > > > change
    > > > > > > too depending on the case.
    > > > > > >
    > > > > > >
    > > > > > > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
    > > > > > > piotrzarzycki21@gmail.com>) escribió:
    > > > > > >
    > > > > > > > I have tried to do point #2 from your options, but when I
    > declare
    > > > my
    > > > > > own
    > > > > > > > class:
    > > > > > > >
    > > > > > > > .nav {
    > > > > > > > background-color: #ffffff
    > > > > > > > }
    > > > > > > >
    > > > > > > > It's being override by those one from framework. Maybe I have
    > to
    > > > > > > inherited
    > > > > > > > from framework classes ?
    > > > > > > >
    > > > > > > > Thanks, Piotr
    > > > > > > >
    > > > > > > > wt., 11 gru 2018 o 20:44 Carlos Rovira <
    > carlosrovira@apache.org>
    > > > > > > > napisał(a):
    > > > > > > >
    > > > > > > > > Hi Piotr,
    > > > > > > > >
    > > > > > > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
    > > > > > > > > piotrzarzycki21@gmail.com>) escribió:
    > > > > > > > >
    > > > > > > > > > Hi Carlos,
    > > > > > > > > >
    > > > > > > > > > I have started playing using Jewel lately more serious and
    > > have
    > > > > two
    > > > > > > > > > questions related to Jewel Navigation component.
    > > > > > > > > >
    > > > > > > > > > I'm displaying horizontal navigation like that [1]. Because
    > > > > > > Navigation
    > > > > > > > is
    > > > > > > > > > actually list my background color is white. The question is
    > > how
    > > > > to
    > > > > > > make
    > > > > > > > > my
    > > > > > > > > > navigation transparent component transparent? I know that I
    > > > could
    > > > > > > make
    > > > > > > > > some
    > > > > > > > > > css trick, but maybe you have a better solution.
    > > > > > > > > >
    > > > > > > > > >
    > > > > > > > > each component use to have a css in Jewel and other one in
    > > > > JewelTheme
    > > > > > > > (95%
    > > > > > > > > of cases)
    > > > > > > > > I still need to write some wiki for all of this
    > > > > > > > > In the meanwhile, search for file "_navigation.sass". The one
    > > in
    > > > > > Jewel
    > > > > > > > has
    > > > > > > > > definitions for beads and use to have some
    > > > > > > > > standard css for things regarding "structure"
    > > > > > > > > in the _navigation.sass in JewelTheme instead you'll not find
    > > > > almost
    > > > > > > any
    > > > > > > > > Royale bead, and css more related to colors, animations,
    > fonts,
    > > > > > sizes,
    > > > > > > > > ....so more "theme" things that people would want to change.
    > > > > > > > >
    > > > > > > > > There you'll find
    > > > > > > > >
    > > > > > > > > // Navigation variables
    > > > > > > > > .jewel.navigation
    > > > > > > > > background-color: #ffffff
    > > > > > > > >
    > > > > > > > > So, you can do in many ways:
    > > > > > > > >
    > > > > > > > > 1) Create your own theme with the same structure as
    > JewelTheme
    > > > and
    > > > > > just
    > > > > > > > > change this navigation thing
    > > > > > > > > 2) just do in your app in you css, since that will be taken
    > > > instead
    > > > > > the
    > > > > > > > > JewelTheme
    > > > > > > > >
    > > > > > > > > Notice that this will change when we implement full dark
    > mode,
    > > > that
    > > > > > > > > navigation still doesn't support since
    > > > > > > > > that component was made after I make dark mode and still
    > don't
    > > > have
    > > > > > > that
    > > > > > > > > implemented in SASS so
    > > > > > > > > compiling SASS will generate a light/dark theme and/or
    > > > flat/noflat
    > > > > > > theme
    > > > > > > > >
    > > > > > > > > Another question is - Did you notice that Navigation
    > component
    > > > fire
    > > > > > > > change
    > > > > > > > > > event two times - whenever you click on the item ?
    > > > > > > > > >
    > > > > > > > > >
    > > > > > > > > Thanks for reporting, I didn't notice, please feel free to
    > fix
    > > > > that,
    > > > > > > just
    > > > > > > > > take into account that navigation renderer preventdefault to
    > > > avoid
    > > > > > > trying
    > > > > > > > > to open a web page. I see this in the way google material
    > > solved
    > > > > > > > navigation
    > > > > > > > > things
    > > > > > > > > but maybe could be a better way to do it
    > > > > > > > >
    > > > > > > > > Thanks!
    > > > > > > > >
    > > > > > > > > Carlos
    > > > > > > > >
    > > > > > > > >
    > > > > > > > >
    > > > > > > > > --
    > > > > > > > > Carlos Rovira
    > > > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=e2ZQbKg%2FXUEIWAlQw9ETRBUg848T9WuhCablQtswPpE%3D&amp;reserved=0
    > > > > > > > >
    > > > > > > >
    > > > > > > >
    > > > > > > > --
    > > > > > > >
    > > > > > > > Piotr Zarzycki
    > > > > > > >
    > > > > > > > Patreon: *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
    > > > > > > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0>*
    > > > > > > >
    > > > > > >
    > > > > > >
    > > > > > > --
    > > > > > > Carlos Rovira
    > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=e2ZQbKg%2FXUEIWAlQw9ETRBUg848T9WuhCablQtswPpE%3D&amp;reserved=0
    > > > > > >
    > > > > >
    > > > > >
    > > > > > --
    > > > > >
    > > > > > Piotr Zarzycki
    > > > > >
    > > > > > Patreon: *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
    > > > > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0>*
    > > > > >
    > > > >
    > > > >
    > > > > --
    > > > >
    > > > > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=eOroBUQP4blbUxXbxFazya1rs82Cz7cxJFmVEzoU7uw%3D&amp;reserved=0>
    > > > >
    > > > > Carlos Rovira
    > > > >
    > > > > Presidente Ejecutivo
    > > > >
    > > > > M: +34 607 22 60 05
    > > > >
    > > > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.codeoscopic.com&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=eOroBUQP4blbUxXbxFazya1rs82Cz7cxJFmVEzoU7uw%3D&amp;reserved=0
    > > > >
    > > > >
    > > > > Conócenos en 1 minuto! <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Favant2.es%2F%23video&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=LGfF9Q0nxjkPpihQ1oO4qxE%2FwCL6Yzzg2fFyU%2FusKD8%3D&amp;reserved=0>
    > > > >
    > > > >
    > > > > AVISO LEGAL: La información contenida en este correo electrónico, y
    > en
    > > su
    > > > > caso en los documentos adjuntos, es información privilegiada para uso
    > > > > exclusivo de la persona y/o personas a las que va dirigido. No está
    > > > > permitido el acceso a este mensaje a cualquier otra persona distinta
    > a
    > > > los
    > > > > indicados. Si Usted no es uno de los destinatarios, cualquier
    > > > duplicación,
    > > > > reproducción, distribución, así como cualquier uso de la información
    > > > > contenida en él o cualquiera otra acción u omisión tomada en relación
    > > con
    > > > > el mismo, está prohibida y puede ser ilegal. En dicho caso, por
    > favor,
    > > > > notifíquelo al remitente y proceda a la eliminación de este correo
    > > > > electrónico, así como de sus adjuntos si los hubiere. En cumplimiento
    > > de
    > > > la
    > > > > legislación española vigente en materia de protección de datos de
    > > > carácter
    > > > > personal y del RGPD 679/2016 le informamos que sus datos están siendo
    > > > > objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342,
    > > con
    > > > > la finalidad del mantenimiento y gestión de relaciones comerciales y
    > > > > administrativas. La base jurídica del tratamiento es el interés
    > > legítimo
    > > > de
    > > > > la empresa. No se prevén cesiones de sus datos, salvo que exista una
    > > > > obligación legal. Para ejercitar sus derechos puede dirigirse a
    > > > CODEOSCOPIC
    > > > > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
    > > (MADRID), o
    > > > > bien por email adpd@codeoscopic.com, con el fin de ejercer sus
    > > derechos
    > > > de
    > > > > acceso, rectificación, supresión (derecho al olvido), limitación de
    > > > > tratamiento, portabilidad de los datos, oposición, y a no ser objeto
    > de
    > > > > decisiones automatizadas, indicando como Asunto: “Derechos Ley
    > > Protección
    > > > > de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección
    > de
    > > > > datos:dpd@codeoscopic.com
    > > > >
    > > >
    > > >
    > > > --
    > > >
    > > > Piotr Zarzycki
    > > >
    > > > Patreon: *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
    > > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0>*
    > > >
    > >
    > >
    > > --
    > > Carlos Rovira
    > > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=e2ZQbKg%2FXUEIWAlQw9ETRBUg848T9WuhCablQtswPpE%3D&amp;reserved=0
    > >
    >
    >
    > --
    >
    > Piotr Zarzycki
    >
    > Patreon: *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0
    > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&amp;data=02%7C01%7Caharui%40adobe.com%7C41ccecc7e9264ec2c96208d660636413%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636802377327546488&amp;sdata=H2nrXZb0wrgl1L7j1ueTDvDRlhrGYz6MVLyTW6Yy3SI%3D&amp;reserved=0>*
    >
    

Re: Some questions about Jewel Navigation

[Greg Dove <gr...@gmail.com>]

I made changes to address some issues, but I no doubt used the wrong
pattern, sorry guys.
I have mainly focused on non-UI code in the past, or custom UI components
without beads in some other work I did last year so 'beads' is still
something I am getting used to (although composition in general is not).

I never wrote any actual beads before DispatchChangeOnStartup, that was the
first bead I ever wrote and may still not be 'right', it was a quick fix
for a specific case and I did not have time to go back and review/refactor
what I did elsewhere to get the lists working for programmatic changes.

Piotr, thanks for looking into this. In terms of 'double dispatch' I also
remember seeing somewhere that there are some overrides that dispatch
events but call the super setter that also dispatches the same event. I did
not have time to look into that in more detail. That could be in renderers
with 'dataChange' iirc ... not related to what you are looking at, but that
just made me think of it.

I will be happy to look more into these things and contribute more to Jewel
in time, when I also get some free time.




On Thu, Dec 13, 2018 at 1:24 AM Piotr Zarzycki <pi...@gmail.com>
wrote:

> Yep - I just did quick look into the bead and it's essentially have those
> things which are currently baked into Model. I hopefully remove that one
> and replace things using bead in Jewel Example.
>
> Thanks for adding that!
> Piotr
>
> śr., 12 gru 2018 o 13:04 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
> > Hi Piotr,
> >
> > just migrated the bead I talked (DispatchChangeOnStartup) from our
> project
> > to royale so you can have all the pieces and help you to diagnose the
> > problem
> >
> > As I said you Greg did the latest changes on this components so I should
> as
> > well read the changes since I didn't have to analyze since that was
> working
> > in our app in many parts flawlessly.
> >
> > thanks for taking care and good luck
> >
> > :)
> >
> > El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > Hi Carlos,
> > >
> > > Comments inline.
> > >
> > > śr., 12 gru 2018 o 10:44 Carlos Rovira <ca...@codeoscopic.com>
> > > napisał(a):
> > >
> > > > Hi Piotr,
> > > >
> > > > This month Greg and I made some changes to get selectedIndex and
> > > > selectedItem work in List, ComboBox and DropDownList. Since
> Navigation
> > > is a
> > > > List in essence, is involved in this changes. We should see how to
> > avoid
> > > > the duplicated event without lost the current workflow that now is
> > > working
> > > > properly like it was in flex days. Was hard to reach to that point.
> > > >
> > > > About options, we already have a bead to dispatch a change event on
> > > startup
> > > > in our project that we must pass to Jewel library. But I think is not
> > > what
> > > > we want here. We want setting selectedIndex/selectedItem in mxml
> should
> > > put
> > > > the component in proper state. I think that's what you refer when
> talk
> > > > about getting to work "programmatically" right?
> > > >
> > > >
> > > *Generally yes those actions should put component in proper state, but
> I
> > > just feeling that those state should not be achieved through model
> which
> > > dispatch "change" event. "change" event is to tell user that someone
> > > interact with component from UI. If developer interacting through code
> > > selectedIndexChanged and selectedItemChanged should probably come with
> > > help.*
> > >
> > >
> > > > Basically I think we have all needed beads in place, So I'll try the
> > > > removal option. But I think that event was copied from Basic version,
> > so
> > > > maybe is right (can ensure right now). You can try to do it yourself.
> > You
> > > > should check Jewel Example (Tour de Jewel) and specially List,
> ComboBox
> > > and
> > > > DropDownList sections along Navigation (that is used in the drawer)
> and
> > > > check you don't see regressions when doing changes. See how the
> > examples
> > > > behave actually, and since debugger now works perfectly, you can put
> > > break
> > > > points to see where's the problem and how to diagnose the right
> > solution.
> > > >
> > > >
> > > *Yes ArrayListSelectionModel is essentially copy of Basic one, but you
> > have
> > > added there code which dispatch "change" event plus property which
> > > generally allows you to do this or not
> > (dispatchChangeOnDataProviderChange)
> > > - That whole part even if should exists - should be probably exposed to
> > > separate bead. *
> > > *I'm surprised that you don't have any problems using in your
> > applications
> > > Bead for dispatch "change" event +  ListSingleSelectionMouseController
> > (it
> > > also dispatch that event) + model - All are able to dispatch change in
> > > almost the same cases!*
> > >
> > > *Ok I think I will have to work on that with all cautious to current
> > code.*
> > >
> > >
> > > > Thanks! :)
> > > >
> > > >
> > > >
> > > >
> > > > El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
> > > > piotrzarzycki21@gmail.com>) escribió:
> > > >
> > > > > Carlos,
> > > > >
> > > > > I just looked into the problem with double call of change event.
> You
> > > are
> > > > > using as default ListSingleSelectionMouseController - in navigation
> > > > > component which is calling "change" event once someone is clicking
> on
> > > > item.
> > > > >
> > > > > However you are doing it again from ArrayListSelectionModel which
> > > > probably
> > > > > shouldn't happen. This model is calling only selectedItemChanged,
> > > > > *selectedIndexChanged. *
> > > > >
> > > > > I'm assuming you are calling "change" event in
> > ArrayListSelectionModel
> > > > > cause you wanted to know whether someone has changed selectedItem
> and
> > > > > selectedIndex programmatically . If that was the case you should
> > > create a
> > > > > bead which listening for events from model and react in specific
> way.
> > > > >
> > > > > My proposition is:
> > > > > 1) Remove call of change event from Jewel ArrayListSelectionModel
> > > > > 2) Create a bead if you need for operation of programmatic change -
> > in
> > > > that
> > > > > case do not use in parallel ListSingleSelectionMouseController
> > > > >
> > > > > Thoughts ?
> > > > >
> > > > > Thanks,
> > > > > Piotr
> > > > >
> > > > > wt., 11 gru 2018 o 22:13 Carlos Rovira <ca...@apache.org>
> > > > > napisał(a):
> > > > >
> > > > > > Hi Piotr,
> > > > > >
> > > > > > but .nav will not do anything. As I write before the right things
> > > > should
> > > > > be
> > > > > >
> > > > > > .jewel.navigation
> > > > > > background-color: transparent
> > > > > >
> > > > > > This in you App css will win over the one in the theme.
> > > > > >
> > > > > > Didn't try, but that should work, at least is what I do when I
> want
> > > > some
> > > > > > quick change to try or something temporal, or even could be a
> final
> > > > > change
> > > > > > too depending on the case.
> > > > > >
> > > > > >
> > > > > > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> > > > > > piotrzarzycki21@gmail.com>) escribió:
> > > > > >
> > > > > > > I have tried to do point #2 from your options, but when I
> declare
> > > my
> > > > > own
> > > > > > > class:
> > > > > > >
> > > > > > > .nav {
> > > > > > > background-color: #ffffff
> > > > > > > }
> > > > > > >
> > > > > > > It's being override by those one from framework. Maybe I have
> to
> > > > > > inherited
> > > > > > > from framework classes ?
> > > > > > >
> > > > > > > Thanks, Piotr
> > > > > > >
> > > > > > > wt., 11 gru 2018 o 20:44 Carlos Rovira <
> carlosrovira@apache.org>
> > > > > > > napisał(a):
> > > > > > >
> > > > > > > > Hi Piotr,
> > > > > > > >
> > > > > > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > > > > > > piotrzarzycki21@gmail.com>) escribió:
> > > > > > > >
> > > > > > > > > Hi Carlos,
> > > > > > > > >
> > > > > > > > > I have started playing using Jewel lately more serious and
> > have
> > > > two
> > > > > > > > > questions related to Jewel Navigation component.
> > > > > > > > >
> > > > > > > > > I'm displaying horizontal navigation like that [1]. Because
> > > > > > Navigation
> > > > > > > is
> > > > > > > > > actually list my background color is white. The question is
> > how
> > > > to
> > > > > > make
> > > > > > > > my
> > > > > > > > > navigation transparent component transparent? I know that I
> > > could
> > > > > > make
> > > > > > > > some
> > > > > > > > > css trick, but maybe you have a better solution.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > each component use to have a css in Jewel and other one in
> > > > JewelTheme
> > > > > > > (95%
> > > > > > > > of cases)
> > > > > > > > I still need to write some wiki for all of this
> > > > > > > > In the meanwhile, search for file "_navigation.sass". The one
> > in
> > > > > Jewel
> > > > > > > has
> > > > > > > > definitions for beads and use to have some
> > > > > > > > standard css for things regarding "structure"
> > > > > > > > in the _navigation.sass in JewelTheme instead you'll not find
> > > > almost
> > > > > > any
> > > > > > > > Royale bead, and css more related to colors, animations,
> fonts,
> > > > > sizes,
> > > > > > > > ....so more "theme" things that people would want to change.
> > > > > > > >
> > > > > > > > There you'll find
> > > > > > > >
> > > > > > > > // Navigation variables
> > > > > > > > .jewel.navigation
> > > > > > > > background-color: #ffffff
> > > > > > > >
> > > > > > > > So, you can do in many ways:
> > > > > > > >
> > > > > > > > 1) Create your own theme with the same structure as
> JewelTheme
> > > and
> > > > > just
> > > > > > > > change this navigation thing
> > > > > > > > 2) just do in your app in you css, since that will be taken
> > > instead
> > > > > the
> > > > > > > > JewelTheme
> > > > > > > >
> > > > > > > > Notice that this will change when we implement full dark
> mode,
> > > that
> > > > > > > > navigation still doesn't support since
> > > > > > > > that component was made after I make dark mode and still
> don't
> > > have
> > > > > > that
> > > > > > > > implemented in SASS so
> > > > > > > > compiling SASS will generate a light/dark theme and/or
> > > flat/noflat
> > > > > > theme
> > > > > > > >
> > > > > > > > Another question is - Did you notice that Navigation
> component
> > > fire
> > > > > > > change
> > > > > > > > > event two times - whenever you click on the item ?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > Thanks for reporting, I didn't notice, please feel free to
> fix
> > > > that,
> > > > > > just
> > > > > > > > take into account that navigation renderer preventdefault to
> > > avoid
> > > > > > trying
> > > > > > > > to open a web page. I see this in the way google material
> > solved
> > > > > > > navigation
> > > > > > > > things
> > > > > > > > but maybe could be a better way to do it
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > Carlos
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Carlos Rovira
> > > > > > > > http://about.me/carlosrovira
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Piotr Zarzycki
> > > > > > >
> > > > > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > > > > <https://www.patreon.com/piotrzarzycki>*
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Carlos Rovira
> > > > > > http://about.me/carlosrovira
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Piotr Zarzycki
> > > > >
> > > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > > <https://www.patreon.com/piotrzarzycki>*
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > <http://www.codeoscopic.com>
> > > >
> > > > Carlos Rovira
> > > >
> > > > Presidente Ejecutivo
> > > >
> > > > M: +34 607 22 60 05
> > > >
> > > > http://www.codeoscopic.com
> > > >
> > > >
> > > > Conócenos en 1 minuto! <https://avant2.es/#video>
> > > >
> > > >
> > > > AVISO LEGAL: La información contenida en este correo electrónico, y
> en
> > su
> > > > caso en los documentos adjuntos, es información privilegiada para uso
> > > > exclusivo de la persona y/o personas a las que va dirigido. No está
> > > > permitido el acceso a este mensaje a cualquier otra persona distinta
> a
> > > los
> > > > indicados. Si Usted no es uno de los destinatarios, cualquier
> > > duplicación,
> > > > reproducción, distribución, así como cualquier uso de la información
> > > > contenida en él o cualquiera otra acción u omisión tomada en relación
> > con
> > > > el mismo, está prohibida y puede ser ilegal. En dicho caso, por
> favor,
> > > > notifíquelo al remitente y proceda a la eliminación de este correo
> > > > electrónico, así como de sus adjuntos si los hubiere. En cumplimiento
> > de
> > > la
> > > > legislación española vigente en materia de protección de datos de
> > > carácter
> > > > personal y del RGPD 679/2016 le informamos que sus datos están siendo
> > > > objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342,
> > con
> > > > la finalidad del mantenimiento y gestión de relaciones comerciales y
> > > > administrativas. La base jurídica del tratamiento es el interés
> > legítimo
> > > de
> > > > la empresa. No se prevén cesiones de sus datos, salvo que exista una
> > > > obligación legal. Para ejercitar sus derechos puede dirigirse a
> > > CODEOSCOPIC
> > > > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
> > (MADRID), o
> > > > bien por email adpd@codeoscopic.com, con el fin de ejercer sus
> > derechos
> > > de
> > > > acceso, rectificación, supresión (derecho al olvido), limitación de
> > > > tratamiento, portabilidad de los datos, oposición, y a no ser objeto
> de
> > > > decisiones automatizadas, indicando como Asunto: “Derechos Ley
> > Protección
> > > > de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección
> de
> > > > datos:dpd@codeoscopic.com
> > > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > <https://www.patreon.com/piotrzarzycki>*
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>

Re: Some questions about Jewel Navigation

[Piotr Zarzycki <pi...@gmail.com>]

Yep - I just did quick look into the bead and it's essentially have those
things which are currently baked into Model. I hopefully remove that one
and replace things using bead in Jewel Example.

Thanks for adding that!
Piotr

śr., 12 gru 2018 o 13:04 Carlos Rovira <ca...@apache.org> napisał(a):

> Hi Piotr,
>
> just migrated the bead I talked (DispatchChangeOnStartup) from our project
> to royale so you can have all the pieces and help you to diagnose the
> problem
>
> As I said you Greg did the latest changes on this components so I should as
> well read the changes since I didn't have to analyze since that was working
> in our app in many parts flawlessly.
>
> thanks for taking care and good luck
>
> :)
>
> El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
> > Hi Carlos,
> >
> > Comments inline.
> >
> > śr., 12 gru 2018 o 10:44 Carlos Rovira <ca...@codeoscopic.com>
> > napisał(a):
> >
> > > Hi Piotr,
> > >
> > > This month Greg and I made some changes to get selectedIndex and
> > > selectedItem work in List, ComboBox and DropDownList. Since Navigation
> > is a
> > > List in essence, is involved in this changes. We should see how to
> avoid
> > > the duplicated event without lost the current workflow that now is
> > working
> > > properly like it was in flex days. Was hard to reach to that point.
> > >
> > > About options, we already have a bead to dispatch a change event on
> > startup
> > > in our project that we must pass to Jewel library. But I think is not
> > what
> > > we want here. We want setting selectedIndex/selectedItem in mxml should
> > put
> > > the component in proper state. I think that's what you refer when talk
> > > about getting to work "programmatically" right?
> > >
> > >
> > *Generally yes those actions should put component in proper state, but I
> > just feeling that those state should not be achieved through model which
> > dispatch "change" event. "change" event is to tell user that someone
> > interact with component from UI. If developer interacting through code
> > selectedIndexChanged and selectedItemChanged should probably come with
> > help.*
> >
> >
> > > Basically I think we have all needed beads in place, So I'll try the
> > > removal option. But I think that event was copied from Basic version,
> so
> > > maybe is right (can ensure right now). You can try to do it yourself.
> You
> > > should check Jewel Example (Tour de Jewel) and specially List, ComboBox
> > and
> > > DropDownList sections along Navigation (that is used in the drawer) and
> > > check you don't see regressions when doing changes. See how the
> examples
> > > behave actually, and since debugger now works perfectly, you can put
> > break
> > > points to see where's the problem and how to diagnose the right
> solution.
> > >
> > >
> > *Yes ArrayListSelectionModel is essentially copy of Basic one, but you
> have
> > added there code which dispatch "change" event plus property which
> > generally allows you to do this or not
> (dispatchChangeOnDataProviderChange)
> > - That whole part even if should exists - should be probably exposed to
> > separate bead. *
> > *I'm surprised that you don't have any problems using in your
> applications
> > Bead for dispatch "change" event +  ListSingleSelectionMouseController
> (it
> > also dispatch that event) + model - All are able to dispatch change in
> > almost the same cases!*
> >
> > *Ok I think I will have to work on that with all cautious to current
> code.*
> >
> >
> > > Thanks! :)
> > >
> > >
> > >
> > >
> > > El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
> > > piotrzarzycki21@gmail.com>) escribió:
> > >
> > > > Carlos,
> > > >
> > > > I just looked into the problem with double call of change event. You
> > are
> > > > using as default ListSingleSelectionMouseController - in navigation
> > > > component which is calling "change" event once someone is clicking on
> > > item.
> > > >
> > > > However you are doing it again from ArrayListSelectionModel which
> > > probably
> > > > shouldn't happen. This model is calling only selectedItemChanged,
> > > > *selectedIndexChanged. *
> > > >
> > > > I'm assuming you are calling "change" event in
> ArrayListSelectionModel
> > > > cause you wanted to know whether someone has changed selectedItem and
> > > > selectedIndex programmatically . If that was the case you should
> > create a
> > > > bead which listening for events from model and react in specific way.
> > > >
> > > > My proposition is:
> > > > 1) Remove call of change event from Jewel ArrayListSelectionModel
> > > > 2) Create a bead if you need for operation of programmatic change -
> in
> > > that
> > > > case do not use in parallel ListSingleSelectionMouseController
> > > >
> > > > Thoughts ?
> > > >
> > > > Thanks,
> > > > Piotr
> > > >
> > > > wt., 11 gru 2018 o 22:13 Carlos Rovira <ca...@apache.org>
> > > > napisał(a):
> > > >
> > > > > Hi Piotr,
> > > > >
> > > > > but .nav will not do anything. As I write before the right things
> > > should
> > > > be
> > > > >
> > > > > .jewel.navigation
> > > > > background-color: transparent
> > > > >
> > > > > This in you App css will win over the one in the theme.
> > > > >
> > > > > Didn't try, but that should work, at least is what I do when I want
> > > some
> > > > > quick change to try or something temporal, or even could be a final
> > > > change
> > > > > too depending on the case.
> > > > >
> > > > >
> > > > > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> > > > > piotrzarzycki21@gmail.com>) escribió:
> > > > >
> > > > > > I have tried to do point #2 from your options, but when I declare
> > my
> > > > own
> > > > > > class:
> > > > > >
> > > > > > .nav {
> > > > > > background-color: #ffffff
> > > > > > }
> > > > > >
> > > > > > It's being override by those one from framework. Maybe I have to
> > > > > inherited
> > > > > > from framework classes ?
> > > > > >
> > > > > > Thanks, Piotr
> > > > > >
> > > > > > wt., 11 gru 2018 o 20:44 Carlos Rovira <ca...@apache.org>
> > > > > > napisał(a):
> > > > > >
> > > > > > > Hi Piotr,
> > > > > > >
> > > > > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > > > > > piotrzarzycki21@gmail.com>) escribió:
> > > > > > >
> > > > > > > > Hi Carlos,
> > > > > > > >
> > > > > > > > I have started playing using Jewel lately more serious and
> have
> > > two
> > > > > > > > questions related to Jewel Navigation component.
> > > > > > > >
> > > > > > > > I'm displaying horizontal navigation like that [1]. Because
> > > > > Navigation
> > > > > > is
> > > > > > > > actually list my background color is white. The question is
> how
> > > to
> > > > > make
> > > > > > > my
> > > > > > > > navigation transparent component transparent? I know that I
> > could
> > > > > make
> > > > > > > some
> > > > > > > > css trick, but maybe you have a better solution.
> > > > > > > >
> > > > > > > >
> > > > > > > each component use to have a css in Jewel and other one in
> > > JewelTheme
> > > > > > (95%
> > > > > > > of cases)
> > > > > > > I still need to write some wiki for all of this
> > > > > > > In the meanwhile, search for file "_navigation.sass". The one
> in
> > > > Jewel
> > > > > > has
> > > > > > > definitions for beads and use to have some
> > > > > > > standard css for things regarding "structure"
> > > > > > > in the _navigation.sass in JewelTheme instead you'll not find
> > > almost
> > > > > any
> > > > > > > Royale bead, and css more related to colors, animations, fonts,
> > > > sizes,
> > > > > > > ....so more "theme" things that people would want to change.
> > > > > > >
> > > > > > > There you'll find
> > > > > > >
> > > > > > > // Navigation variables
> > > > > > > .jewel.navigation
> > > > > > > background-color: #ffffff
> > > > > > >
> > > > > > > So, you can do in many ways:
> > > > > > >
> > > > > > > 1) Create your own theme with the same structure as JewelTheme
> > and
> > > > just
> > > > > > > change this navigation thing
> > > > > > > 2) just do in your app in you css, since that will be taken
> > instead
> > > > the
> > > > > > > JewelTheme
> > > > > > >
> > > > > > > Notice that this will change when we implement full dark mode,
> > that
> > > > > > > navigation still doesn't support since
> > > > > > > that component was made after I make dark mode and still don't
> > have
> > > > > that
> > > > > > > implemented in SASS so
> > > > > > > compiling SASS will generate a light/dark theme and/or
> > flat/noflat
> > > > > theme
> > > > > > >
> > > > > > > Another question is - Did you notice that Navigation component
> > fire
> > > > > > change
> > > > > > > > event two times - whenever you click on the item ?
> > > > > > > >
> > > > > > > >
> > > > > > > Thanks for reporting, I didn't notice, please feel free to fix
> > > that,
> > > > > just
> > > > > > > take into account that navigation renderer preventdefault to
> > avoid
> > > > > trying
> > > > > > > to open a web page. I see this in the way google material
> solved
> > > > > > navigation
> > > > > > > things
> > > > > > > but maybe could be a better way to do it
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > Carlos
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Carlos Rovira
> > > > > > > http://about.me/carlosrovira
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Piotr Zarzycki
> > > > > >
> > > > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > > > <https://www.patreon.com/piotrzarzycki>*
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > > http://about.me/carlosrovira
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Piotr Zarzycki
> > > >
> > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > <https://www.patreon.com/piotrzarzycki>*
> > > >
> > >
> > >
> > > --
> > >
> > > <http://www.codeoscopic.com>
> > >
> > > Carlos Rovira
> > >
> > > Presidente Ejecutivo
> > >
> > > M: +34 607 22 60 05
> > >
> > > http://www.codeoscopic.com
> > >
> > >
> > > Conócenos en 1 minuto! <https://avant2.es/#video>
> > >
> > >
> > > AVISO LEGAL: La información contenida en este correo electrónico, y en
> su
> > > caso en los documentos adjuntos, es información privilegiada para uso
> > > exclusivo de la persona y/o personas a las que va dirigido. No está
> > > permitido el acceso a este mensaje a cualquier otra persona distinta a
> > los
> > > indicados. Si Usted no es uno de los destinatarios, cualquier
> > duplicación,
> > > reproducción, distribución, así como cualquier uso de la información
> > > contenida en él o cualquiera otra acción u omisión tomada en relación
> con
> > > el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
> > > notifíquelo al remitente y proceda a la eliminación de este correo
> > > electrónico, así como de sus adjuntos si los hubiere. En cumplimiento
> de
> > la
> > > legislación española vigente en materia de protección de datos de
> > carácter
> > > personal y del RGPD 679/2016 le informamos que sus datos están siendo
> > > objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342,
> con
> > > la finalidad del mantenimiento y gestión de relaciones comerciales y
> > > administrativas. La base jurídica del tratamiento es el interés
> legítimo
> > de
> > > la empresa. No se prevén cesiones de sus datos, salvo que exista una
> > > obligación legal. Para ejercitar sus derechos puede dirigirse a
> > CODEOSCOPIC
> > > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid
> (MADRID), o
> > > bien por email adpd@codeoscopic.com, con el fin de ejercer sus
> derechos
> > de
> > > acceso, rectificación, supresión (derecho al olvido), limitación de
> > > tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
> > > decisiones automatizadas, indicando como Asunto: “Derechos Ley
> Protección
> > > de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
> > > datos:dpd@codeoscopic.com
> > >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Some questions about Jewel Navigation

[Carlos Rovira <ca...@apache.org>]

Hi Piotr,

just migrated the bead I talked (DispatchChangeOnStartup) from our project
to royale so you can have all the pieces and help you to diagnose the
problem

As I said you Greg did the latest changes on this components so I should as
well read the changes since I didn't have to analyze since that was working
in our app in many parts flawlessly.

thanks for taking care and good luck

:)

El mié., 12 dic. 2018 a las 10:55, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:

> Hi Carlos,
>
> Comments inline.
>
> śr., 12 gru 2018 o 10:44 Carlos Rovira <ca...@codeoscopic.com>
> napisał(a):
>
> > Hi Piotr,
> >
> > This month Greg and I made some changes to get selectedIndex and
> > selectedItem work in List, ComboBox and DropDownList. Since Navigation
> is a
> > List in essence, is involved in this changes. We should see how to avoid
> > the duplicated event without lost the current workflow that now is
> working
> > properly like it was in flex days. Was hard to reach to that point.
> >
> > About options, we already have a bead to dispatch a change event on
> startup
> > in our project that we must pass to Jewel library. But I think is not
> what
> > we want here. We want setting selectedIndex/selectedItem in mxml should
> put
> > the component in proper state. I think that's what you refer when talk
> > about getting to work "programmatically" right?
> >
> >
> *Generally yes those actions should put component in proper state, but I
> just feeling that those state should not be achieved through model which
> dispatch "change" event. "change" event is to tell user that someone
> interact with component from UI. If developer interacting through code
> selectedIndexChanged and selectedItemChanged should probably come with
> help.*
>
>
> > Basically I think we have all needed beads in place, So I'll try the
> > removal option. But I think that event was copied from Basic version, so
> > maybe is right (can ensure right now). You can try to do it yourself. You
> > should check Jewel Example (Tour de Jewel) and specially List, ComboBox
> and
> > DropDownList sections along Navigation (that is used in the drawer) and
> > check you don't see regressions when doing changes. See how the examples
> > behave actually, and since debugger now works perfectly, you can put
> break
> > points to see where's the problem and how to diagnose the right solution.
> >
> >
> *Yes ArrayListSelectionModel is essentially copy of Basic one, but you have
> added there code which dispatch "change" event plus property which
> generally allows you to do this or not (dispatchChangeOnDataProviderChange)
> - That whole part even if should exists - should be probably exposed to
> separate bead. *
> *I'm surprised that you don't have any problems using in your applications
> Bead for dispatch "change" event +  ListSingleSelectionMouseController (it
> also dispatch that event) + model - All are able to dispatch change in
> almost the same cases!*
>
> *Ok I think I will have to work on that with all cautious to current code.*
>
>
> > Thanks! :)
> >
> >
> >
> >
> > El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > Carlos,
> > >
> > > I just looked into the problem with double call of change event. You
> are
> > > using as default ListSingleSelectionMouseController - in navigation
> > > component which is calling "change" event once someone is clicking on
> > item.
> > >
> > > However you are doing it again from ArrayListSelectionModel which
> > probably
> > > shouldn't happen. This model is calling only selectedItemChanged,
> > > *selectedIndexChanged. *
> > >
> > > I'm assuming you are calling "change" event in ArrayListSelectionModel
> > > cause you wanted to know whether someone has changed selectedItem and
> > > selectedIndex programmatically . If that was the case you should
> create a
> > > bead which listening for events from model and react in specific way.
> > >
> > > My proposition is:
> > > 1) Remove call of change event from Jewel ArrayListSelectionModel
> > > 2) Create a bead if you need for operation of programmatic change - in
> > that
> > > case do not use in parallel ListSingleSelectionMouseController
> > >
> > > Thoughts ?
> > >
> > > Thanks,
> > > Piotr
> > >
> > > wt., 11 gru 2018 o 22:13 Carlos Rovira <ca...@apache.org>
> > > napisał(a):
> > >
> > > > Hi Piotr,
> > > >
> > > > but .nav will not do anything. As I write before the right things
> > should
> > > be
> > > >
> > > > .jewel.navigation
> > > > background-color: transparent
> > > >
> > > > This in you App css will win over the one in the theme.
> > > >
> > > > Didn't try, but that should work, at least is what I do when I want
> > some
> > > > quick change to try or something temporal, or even could be a final
> > > change
> > > > too depending on the case.
> > > >
> > > >
> > > > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> > > > piotrzarzycki21@gmail.com>) escribió:
> > > >
> > > > > I have tried to do point #2 from your options, but when I declare
> my
> > > own
> > > > > class:
> > > > >
> > > > > .nav {
> > > > > background-color: #ffffff
> > > > > }
> > > > >
> > > > > It's being override by those one from framework. Maybe I have to
> > > > inherited
> > > > > from framework classes ?
> > > > >
> > > > > Thanks, Piotr
> > > > >
> > > > > wt., 11 gru 2018 o 20:44 Carlos Rovira <ca...@apache.org>
> > > > > napisał(a):
> > > > >
> > > > > > Hi Piotr,
> > > > > >
> > > > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > > > > piotrzarzycki21@gmail.com>) escribió:
> > > > > >
> > > > > > > Hi Carlos,
> > > > > > >
> > > > > > > I have started playing using Jewel lately more serious and have
> > two
> > > > > > > questions related to Jewel Navigation component.
> > > > > > >
> > > > > > > I'm displaying horizontal navigation like that [1]. Because
> > > > Navigation
> > > > > is
> > > > > > > actually list my background color is white. The question is how
> > to
> > > > make
> > > > > > my
> > > > > > > navigation transparent component transparent? I know that I
> could
> > > > make
> > > > > > some
> > > > > > > css trick, but maybe you have a better solution.
> > > > > > >
> > > > > > >
> > > > > > each component use to have a css in Jewel and other one in
> > JewelTheme
> > > > > (95%
> > > > > > of cases)
> > > > > > I still need to write some wiki for all of this
> > > > > > In the meanwhile, search for file "_navigation.sass". The one in
> > > Jewel
> > > > > has
> > > > > > definitions for beads and use to have some
> > > > > > standard css for things regarding "structure"
> > > > > > in the _navigation.sass in JewelTheme instead you'll not find
> > almost
> > > > any
> > > > > > Royale bead, and css more related to colors, animations, fonts,
> > > sizes,
> > > > > > ....so more "theme" things that people would want to change.
> > > > > >
> > > > > > There you'll find
> > > > > >
> > > > > > // Navigation variables
> > > > > > .jewel.navigation
> > > > > > background-color: #ffffff
> > > > > >
> > > > > > So, you can do in many ways:
> > > > > >
> > > > > > 1) Create your own theme with the same structure as JewelTheme
> and
> > > just
> > > > > > change this navigation thing
> > > > > > 2) just do in your app in you css, since that will be taken
> instead
> > > the
> > > > > > JewelTheme
> > > > > >
> > > > > > Notice that this will change when we implement full dark mode,
> that
> > > > > > navigation still doesn't support since
> > > > > > that component was made after I make dark mode and still don't
> have
> > > > that
> > > > > > implemented in SASS so
> > > > > > compiling SASS will generate a light/dark theme and/or
> flat/noflat
> > > > theme
> > > > > >
> > > > > > Another question is - Did you notice that Navigation component
> fire
> > > > > change
> > > > > > > event two times - whenever you click on the item ?
> > > > > > >
> > > > > > >
> > > > > > Thanks for reporting, I didn't notice, please feel free to fix
> > that,
> > > > just
> > > > > > take into account that navigation renderer preventdefault to
> avoid
> > > > trying
> > > > > > to open a web page. I see this in the way google material solved
> > > > > navigation
> > > > > > things
> > > > > > but maybe could be a better way to do it
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Carlos
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Carlos Rovira
> > > > > > http://about.me/carlosrovira
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Piotr Zarzycki
> > > > >
> > > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > > <https://www.patreon.com/piotrzarzycki>*
> > > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > <https://www.patreon.com/piotrzarzycki>*
> > >
> >
> >
> > --
> >
> > <http://www.codeoscopic.com>
> >
> > Carlos Rovira
> >
> > Presidente Ejecutivo
> >
> > M: +34 607 22 60 05
> >
> > http://www.codeoscopic.com
> >
> >
> > Conócenos en 1 minuto! <https://avant2.es/#video>
> >
> >
> > AVISO LEGAL: La información contenida en este correo electrónico, y en su
> > caso en los documentos adjuntos, es información privilegiada para uso
> > exclusivo de la persona y/o personas a las que va dirigido. No está
> > permitido el acceso a este mensaje a cualquier otra persona distinta a
> los
> > indicados. Si Usted no es uno de los destinatarios, cualquier
> duplicación,
> > reproducción, distribución, así como cualquier uso de la información
> > contenida en él o cualquiera otra acción u omisión tomada en relación con
> > el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
> > notifíquelo al remitente y proceda a la eliminación de este correo
> > electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de
> la
> > legislación española vigente en materia de protección de datos de
> carácter
> > personal y del RGPD 679/2016 le informamos que sus datos están siendo
> > objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
> > la finalidad del mantenimiento y gestión de relaciones comerciales y
> > administrativas. La base jurídica del tratamiento es el interés legítimo
> de
> > la empresa. No se prevén cesiones de sus datos, salvo que exista una
> > obligación legal. Para ejercitar sus derechos puede dirigirse a
> CODEOSCOPIC
> > S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
> > bien por email adpd@codeoscopic.com, con el fin de ejercer sus derechos
> de
> > acceso, rectificación, supresión (derecho al olvido), limitación de
> > tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
> > decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
> > de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
> > datos:dpd@codeoscopic.com
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>


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

Re: Some questions about Jewel Navigation

[Piotr Zarzycki <pi...@gmail.com>]

Hi Carlos,

Comments inline.

śr., 12 gru 2018 o 10:44 Carlos Rovira <ca...@codeoscopic.com>
napisał(a):

> Hi Piotr,
>
> This month Greg and I made some changes to get selectedIndex and
> selectedItem work in List, ComboBox and DropDownList. Since Navigation is a
> List in essence, is involved in this changes. We should see how to avoid
> the duplicated event without lost the current workflow that now is working
> properly like it was in flex days. Was hard to reach to that point.
>
> About options, we already have a bead to dispatch a change event on startup
> in our project that we must pass to Jewel library. But I think is not what
> we want here. We want setting selectedIndex/selectedItem in mxml should put
> the component in proper state. I think that's what you refer when talk
> about getting to work "programmatically" right?
>
>
*Generally yes those actions should put component in proper state, but I
just feeling that those state should not be achieved through model which
dispatch "change" event. "change" event is to tell user that someone
interact with component from UI. If developer interacting through code
selectedIndexChanged and selectedItemChanged should probably come with
help.*


> Basically I think we have all needed beads in place, So I'll try the
> removal option. But I think that event was copied from Basic version, so
> maybe is right (can ensure right now). You can try to do it yourself. You
> should check Jewel Example (Tour de Jewel) and specially List, ComboBox and
> DropDownList sections along Navigation (that is used in the drawer) and
> check you don't see regressions when doing changes. See how the examples
> behave actually, and since debugger now works perfectly, you can put break
> points to see where's the problem and how to diagnose the right solution.
>
>
*Yes ArrayListSelectionModel is essentially copy of Basic one, but you have
added there code which dispatch "change" event plus property which
generally allows you to do this or not (dispatchChangeOnDataProviderChange)
- That whole part even if should exists - should be probably exposed to
separate bead. *
*I'm surprised that you don't have any problems using in your applications
Bead for dispatch "change" event +  ListSingleSelectionMouseController (it
also dispatch that event) + model - All are able to dispatch change in
almost the same cases!*

*Ok I think I will have to work on that with all cautious to current code.*


> Thanks! :)
>
>
>
>
> El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
> > Carlos,
> >
> > I just looked into the problem with double call of change event. You are
> > using as default ListSingleSelectionMouseController - in navigation
> > component which is calling "change" event once someone is clicking on
> item.
> >
> > However you are doing it again from ArrayListSelectionModel which
> probably
> > shouldn't happen. This model is calling only selectedItemChanged,
> > *selectedIndexChanged. *
> >
> > I'm assuming you are calling "change" event in ArrayListSelectionModel
> > cause you wanted to know whether someone has changed selectedItem and
> > selectedIndex programmatically . If that was the case you should create a
> > bead which listening for events from model and react in specific way.
> >
> > My proposition is:
> > 1) Remove call of change event from Jewel ArrayListSelectionModel
> > 2) Create a bead if you need for operation of programmatic change - in
> that
> > case do not use in parallel ListSingleSelectionMouseController
> >
> > Thoughts ?
> >
> > Thanks,
> > Piotr
> >
> > wt., 11 gru 2018 o 22:13 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> > > Hi Piotr,
> > >
> > > but .nav will not do anything. As I write before the right things
> should
> > be
> > >
> > > .jewel.navigation
> > > background-color: transparent
> > >
> > > This in you App css will win over the one in the theme.
> > >
> > > Didn't try, but that should work, at least is what I do when I want
> some
> > > quick change to try or something temporal, or even could be a final
> > change
> > > too depending on the case.
> > >
> > >
> > > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> > > piotrzarzycki21@gmail.com>) escribió:
> > >
> > > > I have tried to do point #2 from your options, but when I declare my
> > own
> > > > class:
> > > >
> > > > .nav {
> > > > background-color: #ffffff
> > > > }
> > > >
> > > > It's being override by those one from framework. Maybe I have to
> > > inherited
> > > > from framework classes ?
> > > >
> > > > Thanks, Piotr
> > > >
> > > > wt., 11 gru 2018 o 20:44 Carlos Rovira <ca...@apache.org>
> > > > napisał(a):
> > > >
> > > > > Hi Piotr,
> > > > >
> > > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > > > piotrzarzycki21@gmail.com>) escribió:
> > > > >
> > > > > > Hi Carlos,
> > > > > >
> > > > > > I have started playing using Jewel lately more serious and have
> two
> > > > > > questions related to Jewel Navigation component.
> > > > > >
> > > > > > I'm displaying horizontal navigation like that [1]. Because
> > > Navigation
> > > > is
> > > > > > actually list my background color is white. The question is how
> to
> > > make
> > > > > my
> > > > > > navigation transparent component transparent? I know that I could
> > > make
> > > > > some
> > > > > > css trick, but maybe you have a better solution.
> > > > > >
> > > > > >
> > > > > each component use to have a css in Jewel and other one in
> JewelTheme
> > > > (95%
> > > > > of cases)
> > > > > I still need to write some wiki for all of this
> > > > > In the meanwhile, search for file "_navigation.sass". The one in
> > Jewel
> > > > has
> > > > > definitions for beads and use to have some
> > > > > standard css for things regarding "structure"
> > > > > in the _navigation.sass in JewelTheme instead you'll not find
> almost
> > > any
> > > > > Royale bead, and css more related to colors, animations, fonts,
> > sizes,
> > > > > ....so more "theme" things that people would want to change.
> > > > >
> > > > > There you'll find
> > > > >
> > > > > // Navigation variables
> > > > > .jewel.navigation
> > > > > background-color: #ffffff
> > > > >
> > > > > So, you can do in many ways:
> > > > >
> > > > > 1) Create your own theme with the same structure as JewelTheme and
> > just
> > > > > change this navigation thing
> > > > > 2) just do in your app in you css, since that will be taken instead
> > the
> > > > > JewelTheme
> > > > >
> > > > > Notice that this will change when we implement full dark mode, that
> > > > > navigation still doesn't support since
> > > > > that component was made after I make dark mode and still don't have
> > > that
> > > > > implemented in SASS so
> > > > > compiling SASS will generate a light/dark theme and/or flat/noflat
> > > theme
> > > > >
> > > > > Another question is - Did you notice that Navigation component fire
> > > > change
> > > > > > event two times - whenever you click on the item ?
> > > > > >
> > > > > >
> > > > > Thanks for reporting, I didn't notice, please feel free to fix
> that,
> > > just
> > > > > take into account that navigation renderer preventdefault to avoid
> > > trying
> > > > > to open a web page. I see this in the way google material solved
> > > > navigation
> > > > > things
> > > > > but maybe could be a better way to do it
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Carlos
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Carlos Rovira
> > > > > http://about.me/carlosrovira
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Piotr Zarzycki
> > > >
> > > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > > <https://www.patreon.com/piotrzarzycki>*
> > > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
> >
>
>
> --
>
> <http://www.codeoscopic.com>
>
> Carlos Rovira
>
> Presidente Ejecutivo
>
> M: +34 607 22 60 05
>
> http://www.codeoscopic.com
>
>
> Conócenos en 1 minuto! <https://avant2.es/#video>
>
>
> AVISO LEGAL: La información contenida en este correo electrónico, y en su
> caso en los documentos adjuntos, es información privilegiada para uso
> exclusivo de la persona y/o personas a las que va dirigido. No está
> permitido el acceso a este mensaje a cualquier otra persona distinta a los
> indicados. Si Usted no es uno de los destinatarios, cualquier duplicación,
> reproducción, distribución, así como cualquier uso de la información
> contenida en él o cualquiera otra acción u omisión tomada en relación con
> el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
> notifíquelo al remitente y proceda a la eliminación de este correo
> electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la
> legislación española vigente en materia de protección de datos de carácter
> personal y del RGPD 679/2016 le informamos que sus datos están siendo
> objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
> la finalidad del mantenimiento y gestión de relaciones comerciales y
> administrativas. La base jurídica del tratamiento es el interés legítimo de
> la empresa. No se prevén cesiones de sus datos, salvo que exista una
> obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC
> S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
> bien por email adpd@codeoscopic.com, con el fin de ejercer sus derechos de
> acceso, rectificación, supresión (derecho al olvido), limitación de
> tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
> decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
> de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
> datos:dpd@codeoscopic.com
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Some questions about Jewel Navigation

[Carlos Rovira <ca...@codeoscopic.com>]

Hi Piotr,

This month Greg and I made some changes to get selectedIndex and
selectedItem work in List, ComboBox and DropDownList. Since Navigation is a
List in essence, is involved in this changes. We should see how to avoid
the duplicated event without lost the current workflow that now is working
properly like it was in flex days. Was hard to reach to that point.

About options, we already have a bead to dispatch a change event on startup
in our project that we must pass to Jewel library. But I think is not what
we want here. We want setting selectedIndex/selectedItem in mxml should put
the component in proper state. I think that's what you refer when talk
about getting to work "programmatically" right?

Basically I think we have all needed beads in place, So I'll try the
removal option. But I think that event was copied from Basic version, so
maybe is right (can ensure right now). You can try to do it yourself. You
should check Jewel Example (Tour de Jewel) and specially List, ComboBox and
DropDownList sections along Navigation (that is used in the drawer) and
check you don't see regressions when doing changes. See how the examples
behave actually, and since debugger now works perfectly, you can put break
points to see where's the problem and how to diagnose the right solution.

Thanks! :)




El mar., 11 dic. 2018 a las 23:49, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:

> Carlos,
>
> I just looked into the problem with double call of change event. You are
> using as default ListSingleSelectionMouseController - in navigation
> component which is calling "change" event once someone is clicking on item.
>
> However you are doing it again from ArrayListSelectionModel which probably
> shouldn't happen. This model is calling only selectedItemChanged,
> *selectedIndexChanged. *
>
> I'm assuming you are calling "change" event in ArrayListSelectionModel
> cause you wanted to know whether someone has changed selectedItem and
> selectedIndex programmatically . If that was the case you should create a
> bead which listening for events from model and react in specific way.
>
> My proposition is:
> 1) Remove call of change event from Jewel ArrayListSelectionModel
> 2) Create a bead if you need for operation of programmatic change - in that
> case do not use in parallel ListSingleSelectionMouseController
>
> Thoughts ?
>
> Thanks,
> Piotr
>
> wt., 11 gru 2018 o 22:13 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
> > Hi Piotr,
> >
> > but .nav will not do anything. As I write before the right things should
> be
> >
> > .jewel.navigation
> > background-color: transparent
> >
> > This in you App css will win over the one in the theme.
> >
> > Didn't try, but that should work, at least is what I do when I want some
> > quick change to try or something temporal, or even could be a final
> change
> > too depending on the case.
> >
> >
> > El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > I have tried to do point #2 from your options, but when I declare my
> own
> > > class:
> > >
> > > .nav {
> > > background-color: #ffffff
> > > }
> > >
> > > It's being override by those one from framework. Maybe I have to
> > inherited
> > > from framework classes ?
> > >
> > > Thanks, Piotr
> > >
> > > wt., 11 gru 2018 o 20:44 Carlos Rovira <ca...@apache.org>
> > > napisał(a):
> > >
> > > > Hi Piotr,
> > > >
> > > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > > piotrzarzycki21@gmail.com>) escribió:
> > > >
> > > > > Hi Carlos,
> > > > >
> > > > > I have started playing using Jewel lately more serious and have two
> > > > > questions related to Jewel Navigation component.
> > > > >
> > > > > I'm displaying horizontal navigation like that [1]. Because
> > Navigation
> > > is
> > > > > actually list my background color is white. The question is how to
> > make
> > > > my
> > > > > navigation transparent component transparent? I know that I could
> > make
> > > > some
> > > > > css trick, but maybe you have a better solution.
> > > > >
> > > > >
> > > > each component use to have a css in Jewel and other one in JewelTheme
> > > (95%
> > > > of cases)
> > > > I still need to write some wiki for all of this
> > > > In the meanwhile, search for file "_navigation.sass". The one in
> Jewel
> > > has
> > > > definitions for beads and use to have some
> > > > standard css for things regarding "structure"
> > > > in the _navigation.sass in JewelTheme instead you'll not find almost
> > any
> > > > Royale bead, and css more related to colors, animations, fonts,
> sizes,
> > > > ....so more "theme" things that people would want to change.
> > > >
> > > > There you'll find
> > > >
> > > > // Navigation variables
> > > > .jewel.navigation
> > > > background-color: #ffffff
> > > >
> > > > So, you can do in many ways:
> > > >
> > > > 1) Create your own theme with the same structure as JewelTheme and
> just
> > > > change this navigation thing
> > > > 2) just do in your app in you css, since that will be taken instead
> the
> > > > JewelTheme
> > > >
> > > > Notice that this will change when we implement full dark mode, that
> > > > navigation still doesn't support since
> > > > that component was made after I make dark mode and still don't have
> > that
> > > > implemented in SASS so
> > > > compiling SASS will generate a light/dark theme and/or flat/noflat
> > theme
> > > >
> > > > Another question is - Did you notice that Navigation component fire
> > > change
> > > > > event two times - whenever you click on the item ?
> > > > >
> > > > >
> > > > Thanks for reporting, I didn't notice, please feel free to fix that,
> > just
> > > > take into account that navigation renderer preventdefault to avoid
> > trying
> > > > to open a web page. I see this in the way google material solved
> > > navigation
> > > > things
> > > > but maybe could be a better way to do it
> > > >
> > > > Thanks!
> > > >
> > > > Carlos
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Rovira
> > > > http://about.me/carlosrovira
> > > >
> > >
> > >
> > > --
> > >
> > > Piotr Zarzycki
> > >
> > > Patreon: *https://www.patreon.com/piotrzarzycki
> > > <https://www.patreon.com/piotrzarzycki>*
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>


-- 

<http://www.codeoscopic.com>

Carlos Rovira

Presidente Ejecutivo

M: +34 607 22 60 05

http://www.codeoscopic.com


Conócenos en 1 minuto! <https://avant2.es/#video>


AVISO LEGAL: La información contenida en este correo electrónico, y en su
caso en los documentos adjuntos, es información privilegiada para uso
exclusivo de la persona y/o personas a las que va dirigido. No está
permitido el acceso a este mensaje a cualquier otra persona distinta a los
indicados. Si Usted no es uno de los destinatarios, cualquier duplicación,
reproducción, distribución, así como cualquier uso de la información
contenida en él o cualquiera otra acción u omisión tomada en relación con
el mismo, está prohibida y puede ser ilegal. En dicho caso, por favor,
notifíquelo al remitente y proceda a la eliminación de este correo
electrónico, así como de sus adjuntos si los hubiere. En cumplimiento de la
legislación española vigente en materia de protección de datos de carácter
personal y del RGPD 679/2016 le informamos que sus datos están siendo
objeto de tratamiento por parte de CODEOSCOPIC S.A. con CIFA85677342, con
la finalidad del mantenimiento y gestión de relaciones comerciales y
administrativas. La base jurídica del tratamiento es el interés legítimo de
la empresa. No se prevén cesiones de sus datos, salvo que exista una
obligación legal. Para ejercitar sus derechos puede dirigirse a CODEOSCOPIC
S.A., domiciliada enPaseo de la Habana, 9-11, 28036 de Madrid (MADRID), o
bien por email adpd@codeoscopic.com, con el fin de ejercer sus derechos de
acceso, rectificación, supresión (derecho al olvido), limitación de
tratamiento, portabilidad de los datos, oposición, y a no ser objeto de
decisiones automatizadas, indicando como Asunto: “Derechos Ley Protección
de Datos”, y adjuntando fotocopia de su DNI. Delegado de protección de
datos:dpd@codeoscopic.com

Re: Some questions about Jewel Navigation

[Piotr Zarzycki <pi...@gmail.com>]

Carlos,

I just looked into the problem with double call of change event. You are
using as default ListSingleSelectionMouseController - in navigation
component which is calling "change" event once someone is clicking on item.

However you are doing it again from ArrayListSelectionModel which probably
shouldn't happen. This model is calling only selectedItemChanged,
*selectedIndexChanged. *

I'm assuming you are calling "change" event in ArrayListSelectionModel
cause you wanted to know whether someone has changed selectedItem and
selectedIndex programmatically . If that was the case you should create a
bead which listening for events from model and react in specific way.

My proposition is:
1) Remove call of change event from Jewel ArrayListSelectionModel
2) Create a bead if you need for operation of programmatic change - in that
case do not use in parallel ListSingleSelectionMouseController

Thoughts ?

Thanks,
Piotr

wt., 11 gru 2018 o 22:13 Carlos Rovira <ca...@apache.org> napisał(a):

> Hi Piotr,
>
> but .nav will not do anything. As I write before the right things should be
>
> .jewel.navigation
> background-color: transparent
>
> This in you App css will win over the one in the theme.
>
> Didn't try, but that should work, at least is what I do when I want some
> quick change to try or something temporal, or even could be a final change
> too depending on the case.
>
>
> El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
> > I have tried to do point #2 from your options, but when I declare my own
> > class:
> >
> > .nav {
> > background-color: #ffffff
> > }
> >
> > It's being override by those one from framework. Maybe I have to
> inherited
> > from framework classes ?
> >
> > Thanks, Piotr
> >
> > wt., 11 gru 2018 o 20:44 Carlos Rovira <ca...@apache.org>
> > napisał(a):
> >
> > > Hi Piotr,
> > >
> > > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > > piotrzarzycki21@gmail.com>) escribió:
> > >
> > > > Hi Carlos,
> > > >
> > > > I have started playing using Jewel lately more serious and have two
> > > > questions related to Jewel Navigation component.
> > > >
> > > > I'm displaying horizontal navigation like that [1]. Because
> Navigation
> > is
> > > > actually list my background color is white. The question is how to
> make
> > > my
> > > > navigation transparent component transparent? I know that I could
> make
> > > some
> > > > css trick, but maybe you have a better solution.
> > > >
> > > >
> > > each component use to have a css in Jewel and other one in JewelTheme
> > (95%
> > > of cases)
> > > I still need to write some wiki for all of this
> > > In the meanwhile, search for file "_navigation.sass". The one in Jewel
> > has
> > > definitions for beads and use to have some
> > > standard css for things regarding "structure"
> > > in the _navigation.sass in JewelTheme instead you'll not find almost
> any
> > > Royale bead, and css more related to colors, animations, fonts, sizes,
> > > ....so more "theme" things that people would want to change.
> > >
> > > There you'll find
> > >
> > > // Navigation variables
> > > .jewel.navigation
> > > background-color: #ffffff
> > >
> > > So, you can do in many ways:
> > >
> > > 1) Create your own theme with the same structure as JewelTheme and just
> > > change this navigation thing
> > > 2) just do in your app in you css, since that will be taken instead the
> > > JewelTheme
> > >
> > > Notice that this will change when we implement full dark mode, that
> > > navigation still doesn't support since
> > > that component was made after I make dark mode and still don't have
> that
> > > implemented in SASS so
> > > compiling SASS will generate a light/dark theme and/or flat/noflat
> theme
> > >
> > > Another question is - Did you notice that Navigation component fire
> > change
> > > > event two times - whenever you click on the item ?
> > > >
> > > >
> > > Thanks for reporting, I didn't notice, please feel free to fix that,
> just
> > > take into account that navigation renderer preventdefault to avoid
> trying
> > > to open a web page. I see this in the way google material solved
> > navigation
> > > things
> > > but maybe could be a better way to do it
> > >
> > > Thanks!
> > >
> > > Carlos
> > >
> > >
> > >
> > > --
> > > Carlos Rovira
> > > http://about.me/carlosrovira
> > >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > <https://www.patreon.com/piotrzarzycki>*
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Some questions about Jewel Navigation

[Carlos Rovira <ca...@apache.org>]

Hi Piotr,

but .nav will not do anything. As I write before the right things should be

.jewel.navigation
background-color: transparent

This in you App css will win over the one in the theme.

Didn't try, but that should work, at least is what I do when I want some
quick change to try or something temporal, or even could be a final change
too depending on the case.


El mar., 11 dic. 2018 a las 22:04, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:

> I have tried to do point #2 from your options, but when I declare my own
> class:
>
> .nav {
> background-color: #ffffff
> }
>
> It's being override by those one from framework. Maybe I have to inherited
> from framework classes ?
>
> Thanks, Piotr
>
> wt., 11 gru 2018 o 20:44 Carlos Rovira <ca...@apache.org>
> napisał(a):
>
> > Hi Piotr,
> >
> > El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> > piotrzarzycki21@gmail.com>) escribió:
> >
> > > Hi Carlos,
> > >
> > > I have started playing using Jewel lately more serious and have two
> > > questions related to Jewel Navigation component.
> > >
> > > I'm displaying horizontal navigation like that [1]. Because Navigation
> is
> > > actually list my background color is white. The question is how to make
> > my
> > > navigation transparent component transparent? I know that I could make
> > some
> > > css trick, but maybe you have a better solution.
> > >
> > >
> > each component use to have a css in Jewel and other one in JewelTheme
> (95%
> > of cases)
> > I still need to write some wiki for all of this
> > In the meanwhile, search for file "_navigation.sass". The one in Jewel
> has
> > definitions for beads and use to have some
> > standard css for things regarding "structure"
> > in the _navigation.sass in JewelTheme instead you'll not find almost any
> > Royale bead, and css more related to colors, animations, fonts, sizes,
> > ....so more "theme" things that people would want to change.
> >
> > There you'll find
> >
> > // Navigation variables
> > .jewel.navigation
> > background-color: #ffffff
> >
> > So, you can do in many ways:
> >
> > 1) Create your own theme with the same structure as JewelTheme and just
> > change this navigation thing
> > 2) just do in your app in you css, since that will be taken instead the
> > JewelTheme
> >
> > Notice that this will change when we implement full dark mode, that
> > navigation still doesn't support since
> > that component was made after I make dark mode and still don't have that
> > implemented in SASS so
> > compiling SASS will generate a light/dark theme and/or flat/noflat theme
> >
> > Another question is - Did you notice that Navigation component fire
> change
> > > event two times - whenever you click on the item ?
> > >
> > >
> > Thanks for reporting, I didn't notice, please feel free to fix that, just
> > take into account that navigation renderer preventdefault to avoid trying
> > to open a web page. I see this in the way google material solved
> navigation
> > things
> > but maybe could be a better way to do it
> >
> > Thanks!
> >
> > Carlos
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> <https://www.patreon.com/piotrzarzycki>*
>


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

Re: Some questions about Jewel Navigation

[Piotr Zarzycki <pi...@gmail.com>]

I have tried to do point #2 from your options, but when I declare my own
class:

.nav {
background-color: #ffffff
}

It's being override by those one from framework. Maybe I have to inherited
from framework classes ?

Thanks, Piotr

wt., 11 gru 2018 o 20:44 Carlos Rovira <ca...@apache.org> napisał(a):

> Hi Piotr,
>
> El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
> piotrzarzycki21@gmail.com>) escribió:
>
> > Hi Carlos,
> >
> > I have started playing using Jewel lately more serious and have two
> > questions related to Jewel Navigation component.
> >
> > I'm displaying horizontal navigation like that [1]. Because Navigation is
> > actually list my background color is white. The question is how to make
> my
> > navigation transparent component transparent? I know that I could make
> some
> > css trick, but maybe you have a better solution.
> >
> >
> each component use to have a css in Jewel and other one in JewelTheme (95%
> of cases)
> I still need to write some wiki for all of this
> In the meanwhile, search for file "_navigation.sass". The one in Jewel has
> definitions for beads and use to have some
> standard css for things regarding "structure"
> in the _navigation.sass in JewelTheme instead you'll not find almost any
> Royale bead, and css more related to colors, animations, fonts, sizes,
> ....so more "theme" things that people would want to change.
>
> There you'll find
>
> // Navigation variables
> .jewel.navigation
> background-color: #ffffff
>
> So, you can do in many ways:
>
> 1) Create your own theme with the same structure as JewelTheme and just
> change this navigation thing
> 2) just do in your app in you css, since that will be taken instead the
> JewelTheme
>
> Notice that this will change when we implement full dark mode, that
> navigation still doesn't support since
> that component was made after I make dark mode and still don't have that
> implemented in SASS so
> compiling SASS will generate a light/dark theme and/or flat/noflat theme
>
> Another question is - Did you notice that Navigation component fire change
> > event two times - whenever you click on the item ?
> >
> >
> Thanks for reporting, I didn't notice, please feel free to fix that, just
> take into account that navigation renderer preventdefault to avoid trying
> to open a web page. I see this in the way google material solved navigation
> things
> but maybe could be a better way to do it
>
> Thanks!
>
> Carlos
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
<https://www.patreon.com/piotrzarzycki>*

Re: Some questions about Jewel Navigation

[Carlos Rovira <ca...@apache.org>]

Hi Piotr,

El mar., 11 dic. 2018 a las 17:37, Piotr Zarzycki (<
piotrzarzycki21@gmail.com>) escribió:

> Hi Carlos,
>
> I have started playing using Jewel lately more serious and have two
> questions related to Jewel Navigation component.
>
> I'm displaying horizontal navigation like that [1]. Because Navigation is
> actually list my background color is white. The question is how to make my
> navigation transparent component transparent? I know that I could make some
> css trick, but maybe you have a better solution.
>
>
each component use to have a css in Jewel and other one in JewelTheme (95%
of cases)
I still need to write some wiki for all of this
In the meanwhile, search for file "_navigation.sass". The one in Jewel has
definitions for beads and use to have some
standard css for things regarding "structure"
in the _navigation.sass in JewelTheme instead you'll not find almost any
Royale bead, and css more related to colors, animations, fonts, sizes,
....so more "theme" things that people would want to change.

There you'll find

// Navigation variables
.jewel.navigation
background-color: #ffffff

So, you can do in many ways:

1) Create your own theme with the same structure as JewelTheme and just
change this navigation thing
2) just do in your app in you css, since that will be taken instead the
JewelTheme

Notice that this will change when we implement full dark mode, that
navigation still doesn't support since
that component was made after I make dark mode and still don't have that
implemented in SASS so
compiling SASS will generate a light/dark theme and/or flat/noflat theme

Another question is - Did you notice that Navigation component fire change
> event two times - whenever you click on the item ?
>
>
Thanks for reporting, I didn't notice, please feel free to fix that, just
take into account that navigation renderer preventdefault to avoid trying
to open a web page. I see this in the way google material solved navigation
things
but maybe could be a better way to do it

Thanks!

Carlos



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