Oh, "Royale Tour", for sure!
On Wed, Jun 6, 2018 at 8:55 PM, Vincent Sotto wrote:
> Great work, now we need a "tour de royale" version
>
> On Thu, Jun 7, 2018 at 2:52 AM, OmPrakash Muppirala
> wrote:
>
> > Thanks for this, Carlos!
> >
> > The snippet only shows 15 lines and then we need to
Great work, now we need a "tour de royale" version
On Thu, Jun 7, 2018 at 2:52 AM, OmPrakash Muppirala
wrote:
> Thanks for this, Carlos!
>
> The snippet only shows 15 lines and then we need to scroll to see the
> rest. Can we make it show all the code by default?
>
> Regards,
> Om
>
> On Wed,
In the case of the controlsPallette, how did it get its size? I could
certainly understand that if you didn't have position!=static, that setting top
on the dockAndOuterContainer would have no effect, but you shouldn't have had
to set y or top in the first place. IIRC, you couldn't use x,y in
Here’s one example very similar to the RoyaleStore problem:
Which produces:
The dockAndOuterContainer needed the y=“40” or it occupies the same space as
the controlPalette. With a default
I could certainly not be understanding how pervasive this problem is. I don't
remember the x and y properties always being in ProductsView. In fact, it is
not in the original FlexStore demo. I wonder if was added later?
I would hope that I could just bring up an HTML editor and use
Hi,
this was in my TODO, since I didn't use debug since many months ago. I
remember this was working when I tried it...I think when I started to work
in making MDL, but I left totally (bad for me). I was trying and get the
breakpoint marked as red, so the breakpoint is recognized, but debugger
I don’t think you realize the full extent of the effect. It’s not just “in
case” someone wants x and y values. It’s also to *prevent the need* to specify
x and y values which shouldn’t need to be specified.
Let’s take a piece of ProductsView in RoyaleStore:
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
Short of making it work in both SWF and JS, couldn't we just make it work in JS
by adding a "debugger" global variable to the JS typedefs? Then it could be
wrapped in COMPILE::JS blocks and used in Royale without changing the compiler.
Just wondering,
-Alex
On 6/6/18, 11:02 AM, "Josh
No, you can't use the debugger statement in ActionScript. I as documented, you
can use a custom HTML template with your Royale app and add it in a
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
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
You might be running into this issue (Debugger will not stop at breakpoints on
startup with Apache Royale):
https://github.com/BowlerHatLLC/vscode-nextgenas/wiki/Common-issues#debugger-will-not-stop-at-breakpoints-on-startup-with-apache-royale
It seems like VSCode can't connect with the
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
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
Harbs is proposing that, like border-box, we apply position:relative to all
elements in the DOM. My understanding is that you can do that via:
.Application * {
position: relative;
}
If it has zero impact on Jewel's use of flexbox then I think it is safe to use.
I just want to make
> 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
I'm all for this kind of changes. Things should be as easy and straight
forward as possible, so if we can simplify something to get the same, this
is better. And we are still on 0.9.x so is not something we *can* do, is
something we *must* do if it enhances the overall solution and is possible.
I
Hi Alex
2018-06-06 17:23 GMT+02:00 Alex Harui :
> This sounds scary to me because it affects the entire DOM, and not very
> PAYG. Maybe Carlos should try it on his Jewel layouts and see if anything
> breaks.
>
What you refer exactly to try? let me know to do it .
--
Carlos Rovira
> ... and not very PAYG.
On the contrary.
The same way we are applying box-sizing: border-box because it is a better
default and prevents extra processing, applying relative instead of static as a
default allows us to make assumptions that lets us use less code.
Yes. It’s a change, but it’s
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
This sounds scary to me because it affects the entire DOM, and not very PAYG.
Maybe Carlos should try it on his Jewel layouts and see if anything breaks.
Some other implementation options would be to:
-Have the x,y setters set position on the parent. I think we used to do this
and decided to
I must say I don't remember exactly. I did many test and research and
compare with what others trying to solve the same in the internet without
using a concrete library that at that time I think we want to avoid. So you
can try to compile with and without and use a compare tool to see what you
get
I understand, but I’m trying to understand what the logic of that line of code
was. What was it trying to do?
I could simply remove the line, but if it’s serving a function, we should
probably fix the RegEx instead.
Thanks,
Harbs
> On Jun 6, 2018, at 3:36 PM, Carlos Rovira wrote:
>
> Hi
Hi Harbs,
that was a simple attempt to minify css code, if that line is not working
you can comment it, and we'll be improving the minifying method.
thanks
2018-06-06 14:27 GMT+02:00 Harbs :
> It’s this code in minifyCSSString:
> cssString = cssString.replaceAll("[a-zA-Z]+#", "#");
>
It’s this code in minifyCSSString:
cssString = cssString.replaceAll("[a-zA-Z]+#", "#");
Why is that code there?
Harbs
> On Jun 6, 2018, at 3:21 PM, Harbs wrote:
>
> I found another problem.
>
> The following CSS is the correct compiled results in the debug css:
>
>
>
I found another problem.
The following CSS is the correct compiled results in the debug css:
.toggleTextButton.selected#subscriptButton {
cursor: pointer;
background-color: transparent;
outline: none;
background-image:
Hi,
just let you know that we're promoting Apache Royale on Facebook:
https://www.facebook.com/ApacheRoyaleSDK/videos/360747917782110/
Please join us there and share your love! :)
Thanks!
--
Carlos Rovira
http://about.me/carlosrovira
> 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
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
Yes. There is a lot to be said for your approach of using strictly classes for
assigning layouts using CSS.
It prevents a lot of the reflowing problems.
I’m interested in seeing how far you can get with it. :-)
Harbs
> On Jun 6, 2018, at 10:58 AM, Carlos Rovira wrote:
>
> Hi Yishay,
> maybe
Hi Yishay,
maybe mixing topics, but I only showing how I'm solving in jewel layouts.
Why I'm creating new layouts? since I see many problems with mixing layout
types (display: block, in other cases flex...), and seems inconsistent, so
I'm trying to base all in Jewel in only one system. Flexbox is
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
FYI, I applied this change to my PrintUI app and it seems like we had applied
quite a few ugly work-arounds to get things to be positioned correctly. We did
not realize at the time that it was due to the default being position: static.
Switching the default to position: relative simplifies
34 matches
Mail list logo
