ened. So I’m assuming the typedefs lib is
loaded.
From: Alex Harui<mailto:aha...@adobe.com.INVALID>
Sent: Sunday, February 18, 2018 10:18 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: Need help with CSS class selector (font-family is always Arial)
How
the typedefs lib is
loaded.
From: Alex Harui<mailto:aha...@adobe.com.INVALID>
Sent: Sunday, February 18, 2018 10:18 AM
To: dev@royale.apache.org<mailto:dev@royale.apache.org>
Subject: Re: Need help with CSS class selector (font-family is always Arial)
How do you know the typedefs ar
How do you know the typedefs are being read by the example?
Did you specify the SWC on the js-external-library-path? See
RoyaleStore_jquery for how to use Jquery typedefs in Royale.
HTH,
-Alex
On 2/17/18, 11:07 PM, "yishayw" wrote:
>The issue is that the typedefs
The issue is that the typedefs (ace-1.2.3.swc) is being read by the example
app, but I can't import ace.Editor in the code.
--
Sent from: http://apache-royale-development.20373.n8.nabble.com/
If the issue is only the font-family that will likely go away when I
remove the * selector and clean up any repercussions. I am hoping to get
to it this week, but others are welcome to beat me to it.
-Alex
On 2/17/18, 8:58 AM, "yishayw" wrote:
>I've created an
I've created an ace-1.2.3.swc but am not able to run a simple example that
uses it.
If anyone has time to look at the ace branches maybe they can help me figure
out why the Ace example isn't compiling...
Thanks.
--
Sent from: http://apache-royale-development.20373.n8.nabble.com/
I'd like to get an idea of what the workflow would be to implement this. Is
there an example in the repo that I can play around with, compile, and see
what happens? Where's the best place to start?
Thanks.
--
Sent from: http://apache-royale-development.20373.n8.nabble.com/
Alex,
I'm pretty sure that some time ago we had discussion about that. Someone
provided some links to the projects in the Apache which share links to the
nightly builds, with appropriate statement on their website. The statement
which we have on the website has been taken from there:
"These
On 1/4/18, 3:19 AM, "Olaf Krueger" wrote:
>Thanks again Alex, it's getting clearer and clearer for me!
>
>I also thought about something similar to your suggestion [1].
>But I thought this would be not a good idea because going this way we have
>to implement the ace JS
I just created new "feature/ace-editor" branch(es) to our Royale repos.
Anybody is invited to help with this stuff ;-)
Thanks,
Olaf
[1] https://github.com/apache/royale-asjs/tree/feature/ace-editor
[2] https://github.com/apache/royale-typedefs/tree/feature/ace-editor
[3]
Thanks again Alex, it's getting clearer and clearer for me!
I also thought about something similar to your suggestion [1].
But I thought this would be not a good idea because going this way we have
to implement the ace JS API twice. Once in ace.as and once in ACEEditor.as.
But I guess this is the
Answers inline...
On 1/4/18, 1:47 AM, "Olaf Krueger" wrote:
>Thanks for this helpful answer Alex, I'll probably start working on this
>tonight.
>
>Two question are left for now:
>
>1)
>The TypeDef is a class that holds methods that represents the JS API.
>My understanding
Thanks for this helpful answer Alex, I'll probably start working on this
tonight.
Two question are left for now:
1)
The TypeDef is a class that holds methods that represents the JS API.
My understanding is that there's no code implemented for each particular
method on AS3 side.
We just implement
One first question comes into my mind:
We have TypeDefs and Royale components.
In case of providing the Ace editor as Royale component, should we still
provide an separate AS3 class or interface as TypeDef in the TypeDef repo
that represents the JS API?
Or should the needed API be part of the
Hi Olaf,
Yes, I am pushing you to create ACEEditor as a fully complaint Royale
component.
You don't have to do it, but doing so would help us make sure that Royale
is capable of such things. IMO, we want all UI widgets to be usable in
MXML and AS and appear to have a consistent lifecycle. The
I could be wrong, but if we replace the * selector with a 'type' selector
per component it should work. That's because a Royale 'type' selector
isn't really a true CSS Type Selector. It is really a Class selector with
the same name as the component's typeNames property.
If you rework
>...or create more TypeSelectors should work
I don't understand this, what do you mean?
My understanding is that applying Type selectors for e.g. a surrounding div
don't help to fix this.
Thanks,
Olaf
--
Sent from: http://apache-royale-development.20373.n8.nabble.com/
The * selector should be in the defaults.css in Basic (or maybe Core). A
* or global selector is how defaults were set up for Flash since Flash did
not make it easy to get browser default stylesheets. Like in Flex, the
app dev can have an fx:Style block and choose different values in its *
This is a short summary of my quick google search and investigation, maybe
this is helpul for others (Of course, I could be wrong!):
Universal selector (*):
Applies style properties to all individual elements.
Replaces inherited style properties, blocks inheritance.
@see
> It looks like inherited properties have lower
>priority than the * selector and that feels like the * selector is too
>powerful.
That's the case, I've created a little CodePen demo in order to validate
this [1].
That said I guess this issue has nothing to do with the ACE editor.
BTW: It
I don’t think moving it to Application is going to help for things like
dialogs. (Or will it?)
> On Jan 2, 2018, at 8:03 PM, Alex Harui wrote:
>
> Maybe, but I hit this with my mock up of the Royale website as well.
> Since a lot of things are composed from other
Maybe, but I hit this with my mock up of the Royale website as well.
Since a lot of things are composed from other smaller pieces, I think we
want defaults where the CSS applied to the outer element of a component
applies to its children. It looks like inherited properties have lower
priority
I’m guessing that the ACE Editor has sub-elements that are picking up the
globals rather than the ones for the ACEEditor element. I have not looked into
this at all…
Harbs
> On Jan 2, 2018, at 5:50 PM, Alex Harui wrote:
>
> I haven't looked at his ACEEditor class,
I haven't looked at his ACEEditor class, but it is also possible that the
following would work.
.ACEEditor {
font-family: monospace;
}
And that should be a goal as well: to have the defaults.css for the
ACEEditor class to use an "ACEEditor" selector (instead of lowercase
"aceEditor"). If the
>Did you try this?
Ha, this works!!!... and I guess it makes sense.
However, I'll check out the type selector tomorrow...
Thanks!
Olaf
--
Sent from: http://apache-royale-development.20373.n8.nabble.com/
Did you try this?
.aceEditor * {
font-family: monospace;
}
> On Jan 2, 2018, at 5:28 PM, Olaf Krueger wrote:
>
> Hi Alex,
>
>> The key piece, I think, is that inherited properties in CSS have a lower
>> importance that *...
>
> Yes, I think that's the problem:
>
> /*
Hi Alex,
>The key piece, I think, is that inherited properties in CSS have a lower
>importance that *...
Yes, I think that's the problem:
/* Generated by Apache Royale Compiler */
* {
font-family: Arial;
border-width: 1px;
font-size: 12px;
}
>IMO, that should be
the
When you have compiled everything, what actually are you seeing in CSS for
this Group and what, are you seeing in the children for that Group ?
Piotr
2018-01-02 22:37 GMT+01:00 Olaf Krueger :
> Still no success... other ideas?
>
> Thanks,
> Olaf
>
>
>
>
>
> --
> Sent
Still no success... other ideas?
Thanks,
Olaf
--
Sent from: http://apache-royale-development.20373.n8.nabble.com/
Hi Olaf,
Try inside js:Group -> https://paste.apache.org/NsUC
Thanks, Piotr
2018-01-02 22:08 GMT+01:00 Olaf Krueger :
> Hi,
> I've successfully captured the ACE editor but there's one issue left [1]:
> It seems to me that the Royale default font-family is always Arial and
30 matches
Mail list logo