I think apache-royals would be better, since avoids confusing people. If I
came to this project for the first time, and try to search in npm, and find
"royale", although this was the right and only package, I'll be ask me if
there's the right one.
With apache-royale, there's no confusion problems
We always have option of using apache-royale as package name.
On Mon, Oct 30, 2017 at 11:32 AM, Harbs wrote:
> It’s a shame that “royale” seems to already be taken on npm.
>
> I would vote for two packages:
>
> 1. To install *everything* (i.e. swf, js, node, etc. and future targets
> when/if we
Some Metadata is kept in the output, but events probably aren't.
One issue to consider are whether a container of beads should be have
metadata about the events dispatched by its beads since the changing of
beads could make that metadata incorrect. IMO, this has been a problem in
Flex forever. M
It’s a shame that “royale” seems to already be taken on npm.
I would vote for two packages:
1. To install *everything* (i.e. swf, js, node, etc. and future targets when/if
we add them):
npm install apache-royale -g
2. To install js-only:
npm install apache-royale-js -g
If we see a demand for
Hi Om,
If I could choose one, I think I'll with 3, in order to have one solid
command line, and the some possible configurations via params...
But if is finaly option 3 (one command line + option args), I'll prefer
something that that not comprise outputs (in the future we could add
webasm, swift,
I’m not talking about adding events. I’m talking about adding metadata for
*existing events* so they could be addressed in MXML.
> On Oct 30, 2017, at 8:18 PM, Piotr Zarzycki wrote:
>
> If you decide to add event that's fine with me. :) It is just the matter of
> thinking about those Basic com
So, "npm install" downloads a tarball from npmjs.org. The package usually
contains the code we want others to use. It also contains a "package.json"
file which specify all its dependencies. These dependencies (and their
sub-dependencies) are all downloaded from npmjs.org as part of "npm
install"
If you decide to add event that's fine with me. :) It is just the matter of
thinking about those Basic components from my sight. I have started to look
at them as something which should be closer to HTML than to the old Flex
world. Rest of the features should be provided by beads - if it is possibl
Why? Unless it adds overhead, it seems to me like any event that can be added
using addEventListener() should be addressable using MXML.
I’m just not sure from a technical perspective whether the MXML meta tags add
overhead if not used.
> On Oct 30, 2017, at 8:02 PM, Piotr Zarzycki wrote:
>
>
Hi Harbs,
Some time ago there were discussion on Flex Dev which makes me realize that
we should add event tags as long as they are reflecting some native HTML
api, unless we are in express. For example we are using in many places
"change" event which is I believe quite common in JS world, but I wo
This does raise a good question:
Should we be adding MXML meta tags for all supported events? It seems like a
desirable thing to have, and there are currently very few event tags. I’m not
clear on whether the meta-tags effect the end result of code size.
Harbs
> On Oct 30, 2017, at 7:38 PM, Gi
I saw this too, then it seemed to go away after a restart of FB.
HTH,
-Alex
On 10/30/17, 2:26 AM, "Yishay Weiss" wrote:
>I’m trying to build a Royale flash app in FB and am getting the following
>stack trace in the FB log
>
>
>
>java.lang.NullPointerException
>
>at
>com.adobe.fl
Om,
Can you explain to us what our options are? Essentially, the JS-only
package will be a subset of a package that can output both SWF and JS and
will probably have slightly different default settings in, for example, a
frameworks/royale-config.xml file.
It is looking like we can create a zip p
Currently the composite view (DataGridView) has some code designed to propagate
the data change event to its subviews (DataGridColumnList). I think we need to
move this code to a separate bead. Then we’ll have finer control over whether
or not changes in runtime are reflected in the view. I’ll t
The initial versions of Basic data providers and their like were not
intended to be complete. Some of it is still proof of concept. The stuff
that's there is really meant for a more static viewing rather than being
dynamic. Plus there is no code to support virtualized lists of any sort.
With the f
Hi Om,
I think that would be great!
If we end having multiple products as Alex suggested, I think we should
have as well multiple NPM installs.
So for me is ok to sync products we deliver with NPM installations flavors
Thanks
2017-10-30 10:58 GMT+01:00 Yishay Weiss :
> You’re likely to do mo
Peter,
Can you please look at this?
For some reason my change seems to have broken the beads which draw the drag
image and the drop indicator. It looks to me like the beads are added, but they
are not behaving the same.
Thanks,
Harbs
> On Oct 30, 2017, at 1:01 AM, ha...@apache.org wrote:
>
>
Hi Alex,
notice that the actual preview site is only that. We told about to get the
site to some compromise point when we could evaluate it.
As I get to that point, folks agree about the direction of the site. We are
know seeing how to put this working for us. It seems that current talk with
Greg
You’re likely to do most of the maintenance work, so it’s up to you… As far as
users go there are some users writing client code in AIR and server code in
node (in fact I’m involved in such a project right now). So I wouldn’t make
sweeping assumptions.
From: o
Royale currently compiles to both JS and to Flash, so you can choose your
dependencies. There’s work being done to package a more specialized version
which compiles to JS only, and I think that’s what the discussion is referring
to.
From: Dany Dhondt
Sent: M
Just as an outsider: isn’t the whole point of royale to get rid of flash
dependency? I’m eagerly waiting for the first full royale release to finally
start converting my projects to html/js but the last thing I want is any
dependency towards flash/swf. So I’m in favor of a jsonly package
Dany
I’m trying to build a Royale flash app in FB and am getting the following stack
trace in the FB log
java.lang.NullPointerException
at
com.adobe.flexbuilder.util.FlashPlayerVersion.compareTo(FlashPlayerVersion.java:373)
at
com.adobe.flexbuilder.project.compile
On Mon, Oct 30, 2017 at 1:19 AM, Harbs wrote:
> Why not publish both versions?
>
It looks like the js only is going to be just a zip file. That makes for
easy maintenance.
The swf version has a bunch of dependencies to be downloaded.
Not a big deal, just thinking out loud if we really need to
Why not publish both versions?
> On Oct 30, 2017, at 10:15 AM, OmPrakash Muppirala
> wrote:
>
> I was wondering if we should publish the apache.royale-jsonly verson via
> npm instead of the full version with swf support.
> After all, users coming in vial npm would most likely not expect swf
> s
I was wondering if we should publish the apache.royale-jsonly verson via
npm instead of the full version with swf support.
After all, users coming in vial npm would most likely not expect swf
support.
Any thoughts on this proposal?
Thanks,
Om
25 matches
Mail list logo
