Alina is nearing the point of getting everything to compile. Now it is time to
get things to "run". And later, we will try to get things to "run and look
good".
I've been distracted by other things, but I hope get back to getting components
to "run". Meaning, they show something on the scree
> IMO, if we all pitched in on emulation
> Perfection can be the enemy of success. Sorry to be so selfish, but I am
> just trying to keep my job.
Fair enough. If I were to pitch in with the emulation, what would you recommend
I work on?
Harbs
> On Jun 6, 2018, at 9:24 PM, Alex Harui wrote:
IMO, if we all pitched in on emulation, we would have many more migrating users
at the end of the year claiming that the UI is still a bit ugly. If we leave
emulation to fewer people, then at the end of the year, we may not have gotten
all of the emulation components up and running and so fewer
Hi Alex,
And I think that approach is perfectly valid. But we tend to think the rest
of us are wrong, and I think that's not the case. Don't you think that if
we solve this king of problems (let's call it "styling problems"), we can
get a more visual Royale to put material online in website and so
IMO, the thing that will have the greatest impact on whether Adobe will
continue to pay me to work full time on Royale is how many active users we have
at the end of the year, not whether we have a really cool way of avoiding type
selector name collisions. So I am asking folks to consider that
FTR, in the other thread about package names, I do not agree that Jewel must
re-use or subclass Basic or Express TLCs. The main point of code re-use is in
the beads. Express can certainly subclass Basic TLCs as its goal is to
pre-aggregate Basic beads. But, IMO, Jewel doesn't have to subclass
I think as well this is important. Very important. We must notice that we
are a multidisciplinar team and we must take advantage of that making each
one work in the areas where they get the most of it. I think if Harbs wants
to make this happen, I think he should do that. For needs, I think MX
emul
> This just seems like too much work for the hopefully seldom case of mixing
> TLC's from various component sets.
Well, I am already doing that… Maybe I’m the exception, but it’s not a
theoretical need. ;-)
It also would enable us to use Basic and Express TLCs in Jewel — without
subclassing at
This just seems like too much work for the hopefully seldom case of mixing
TLC's from various component sets. Remember that in "Terminology and
Concepts", the TLC's are just collections of beads. There should be little
dependencies of the beads on the host strand. Folks should be able to brea
> Button{
> TypeNames: “.jewel.button”;
> }
>
> should not be?
>
> Button{
> TypeNames: “jewel button”;
> }
Yup. You’re right. Typo there… ;-)
> (side question not related what does lookupOnly="true"?, I
> forgot completely about the use or need for that)
Others might have a better explana
Hi Harbs,
I reach to the same conclusion that "typeNames" set in the class code is
not the best way to go, and not PAYG. A rule to follow should be that TLCs
and other classes should never hardcode anything about layout, positioning,
styles or classNames. So I think your strategy is good in concep
While I was trying to figure out how the compiler handles CSS, a new idea came
to me which I think is better than any of the ideas we had until now (if I
might say so myself). ;-p
Basically, we can just use the component manifest file.
One of the issues I was struggling with is that if the type
OK, then I think we are on roughly the same page. Earlier I proposed a map of
package names to short names. However, I just realized that it needs to be a
map of MXML namespaces to short names, and metadata won't work because I think
the rules get chosen by MXML namespace instead of package na
Right.
> On May 31, 2018, at 10:29 AM, Carlos Rovira wrote:
>
> Just an important point here: I understand that in this case, we're talking
> about a metadata analyzed at compiler time, so there's no cost at runtime
> and that metadata will not be preserved. I think that would be great
> improve
Just an important point here: I understand that in this case, we're talking
about a metadata analyzed at compiler time, so there's no cost at runtime
and that metadata will not be preserved. I think that would be great
improvement
I think Alex is thinking in some kind of metadata at runtime, but I
I’m not talking about solving subclassing here.
I’m talking about one thing: How to determine what classnames the compiler
writes to HTML CSS files for specific types.
Carlos and I would both like for the compiler to compile:
j|Button{
background-color: #fff;
}
To:
.jewel.Button{
backgro
There has always been an option to keep/strip metadata in the output. It is
-compiler.keep-as3-metadata.
I don't think I understand what you are proposing with metadata. I thought I'd
shown that there was no easy way to solve what the runtime (ValuesManager)
should do. I thought we'd agreed
Hi,
right, I, in fact, try to use the format "org_apache_royale_html_Button",
but seems very cumbersome to me and for that reason in Jewel I write like
in Semantic ".jewel.button", since this is more friendly with CSS, less
verbose and more flexible
2018-05-29 14:47 GMT+02:00 Harbs :
>
> I like
Sorry for the delay in response here. I was not feeling very well last week… (I
forgot how much work an infant is…) ;-)
I think it’s time to wrap this up.
I don’t think there’s any completely PAYG solution to this problem. I think
conflicts need to be prevented by default.
I like the metadata
I think we are in agreement. My most recent posts were intended to show that
#2 is not easily solvable, if at all, and thus we should not invest time or
energy there.
My only suggestions regarding #1 is that we do not invent a second naming
system, and that whatever we do is PAYG in the sense
I think Harbs is right here.
We should take into account that as we focus on presentation (CSS, styles,
drawings, colors, fonts) things are showing that before passed unnoticed.
And now we have the chance to address all of this to make architecture and
presentation get to its best. Both things are
I’m getting confused.
Let me try and summarize the issues as I understand them:
There are two different types of issues: Compile time issues, and runtime
issues.
Compile time issues are:
1. Compiled css files do not differentiate between different packages. (i.e.
ImageButton type selectors wil
I know I am late to this very, very long discussion, but after wading through
(and even skipping over some of the more “complex” emails), I think this is
become overly complicated. My understanding has been that RadioButton (for
example) in basic.css would provide the beads while .RadioButton (t
On 5/18/18, 2:50 AM, "Harbs" wrote:
And basic.css has:
RadioButton
{
font-size: 12px;
font-family: sans-serif;
}
RadioButton is a Royale Type Selector as it should be. No discussion on
that front (with the exception that the styling should be removed fr
Hi Harbs,
2018-05-18 13:23 GMT+02:00 Harbs :
> A couple of questions/comments:
>
> > On May 18, 2018, at 1:57 PM, Carlos Rovira
> wrote:
> >
> > One more important technical thing about that way is "verbosity" since
> each
> > time you reference that kind of class you are introducing a name that
A couple of questions/comments:
> On May 18, 2018, at 1:57 PM, Carlos Rovira wrote:
>
> One more important technical thing about that way is "verbosity" since each
> time you reference that kind of class you are introducing a name that use
> to be 2-3 time longer, each time.
Are you suggesting
Hi just responding some few things I saw:
"Metadata is possible, but metadata is expensive at runtime."
Depend if is a Metadata to use at compile time or at run time. In this case
we're talking about a compile time metadata. Even at runtime, a metadata
can be or not expensive depending on the sco
>
> It is a bug. In the framework. The defaults.css for Basic has a
> .DynamicDataGrid in it. It shouldn't have that. (There might be another
> framework bug where a ClassReference in .DynamicDataGrid referenced DataGrid
> which bring in DataGridButtonBar which brings in ButtonBar) That's
I picked this post to respond to in order to write one response instead of
several. Comments Inline...
On 5/17/18, 1:39 PM, "Harbs" wrote:
Snipping relevant pieces to make it more legible…
Let me use a concrete example to illustrate what I mean: Try compiling the
DateControl
mmm this one seems not as easy as you post.
If you do that in Jewel, then people wanting to mix with Basic will have a
problem.
I think better things simple and prefer the first scenario, simple and
direct. Think that normaly extending what I call "final" component (and I
said that I don't want to
I love that idea of Metadata in class. +1 to that one :)
2018-05-17 22:39 GMT+02:00 Harbs :
> Snipping relevant pieces to make it more legible…
>
> >
> > I agree #1 and #2 are creating problems, but they are not bugs in the
> compiler. I believe the compiler correctly prunes out any Type Selecto
One more point:
If we go the meta-tags route, we can include in the tag whether to include base
typenames. Something like the following would tell the compiler that the
org.apache.royale.html.Button typename is not being used.
[Typename(name="Button", prefix=“basic”, inherits=“false")]
pu
Snipping relevant pieces to make it more legible…
>
> I agree #1 and #2 are creating problems, but they are not bugs in the
> compiler. I believe the compiler correctly prunes out any Type Selectors
> that are not used. The compiler must carry over any class and id selectors
> since there is
Hi Alex,
2018-05-17 19:36 GMT+02:00 Alex Harui :
> Some comments inline.
>
> On 5/17/18, 4:53 AM, "Harbs" wrote:
>
> OK. Let’s take a step back.
>
> Here’s what I think is the takeaway of the first part of the
> “refactor” discussion. It seems like there are real issues — some of which
Some comments inline.
On 5/17/18, 4:53 AM, "Harbs" wrote:
OK. Let’s take a step back.
Here’s what I think is the takeaway of the first part of the “refactor”
discussion. It seems like there are real issues — some of which have been
partially resolved by Carlos, and none really ha
OK. Let’s take a step back.
Here’s what I think is the takeaway of the first part of the “refactor”
discussion. It seems like there are real issues — some of which have been
partially resolved by Carlos, and none really have to do specifically with a
project refactor.
There are multiple issues
Hi Alex,
I think I need some example code to understand what you try to explain
here. I don't get to follow your explanation. Can you post some sample code
to explain it better?
thanks!
2018-05-16 23:43 GMT+02:00 Alex Harui :
> Typo in there:
>
> "...make the compiler output the class selectors
Typo in there:
"...make the compiler output the class selectors that are supposed to
approximate type selectors..."
Sorry,
-Alex
On 5/16/18, 2:26 PM, "Alex Harui" wrote:
Changing the subject line...
What is the failure case? I think I've gotten lost somewhere.
IMO, the
Changing the subject line...
What is the failure case? I think I've gotten lost somewhere.
IMO, the goal is to approximate Type Selectors (effectively extend Type
Selectors to other types not specified by W3C), and AIUI, order of class
selectors is about specificity and order of appearance in
39 matches
Mail list logo
