Moonshine IDE

[Takeshita Shoichiro]

This is not a question to Apache Royale.  But, since I do not know the
tight place, I’d like to ask it here.

My questions are:

Can Moonshine IDE provide the similar capabilities as Flash Builder 4.7?

And are there any unsupported major functions?

I’d like to know whether we can use Moonshine IDE replacing Flash Builder
when developing/maintaining Flex desktop application (AIR)?

Thanks for your advice.
-- 
Shoichiro Takeshita
武下 祥一郎

Re: IDE for Royale

[QA]

Thanks Harbs :)

On 10/24/19 2:10 AM, Harbs wrote:

Jude, that plugin is pretty cool.

Harbs

On Oct 23, 2019, at 10:06 PM, QA > wrote:


Hi Paul,

I've been attempting to solve the DV problem for while with some 
projects. I designed a DV that exported to MXML and I had some 
success and in some areas I learned some things. It is a work in 
progress but it has been shelved for about a year. It's a long story 
so I'll get right to the main points.


What I got to work well was reading and writing single or multiple 
MXML documents but full applications were much more difficult. 
Because of the nature of Flash I could load in a SWF, traverse the 
Flex component tree and then export MXML but it didn't fit well with 
developers workflow. Developers would have a MXML or AS3 class that 
followed their own code paths or had frameworks that loaded screens 
through code. A full application couldn't easily be represented by a 
design view unless it adhered to a workflow that was compatible to 
the design tool.


For Royale, Alex had a tool that would monitor the MXML files in a 
directory, that you, the developer, would change from time to time in 
your code editor. At the same time your app would be running in the 
browser. As you updated the MXML, your app would be updated giving 
you a real time preview of your code changes. I was looking into what 
it would take to get it all working but I didn't have the time at the 
time but the concept is better suited in my opinion.


If we were to separate out the views from the main project (or the 
compilation phase) or parse them or support parsing them or the 
attributes at runtime a design view would be much simpler to support. 
If the views didn't change much it wouldn't matter as long as you 
keep the views independent.


For example, your designer can come along and say here is the Intro 
Screen.mxml, here is the MainView.mxml, here is the login 
screen.mxml, etc. And then using an agreed upon way to display or 
parse those you could keep the views really separate.


For the last few projects I've been working on Web Export for Adobe 
XD and with some work it could support an Royale export target. It's 
a plugin that takes an artboard or screen and exports it to HTML. 
There's no reason it couldn't support MXML.


Here is the playlist:

https://www.youtube.com/playlist?list=PLFBNT6gqr5u_NvUaLdHziGES_7Rw8-2pX

Here it is supporting some of the Materialize Components (roughly):

https://youtu.be/8V0Tzr6YUtI

You could have a Jewel component set or a basic component set. XD 
supports about 90% of the design features that you're asking for.


Jude

On 10/15/19 10:22 AM, Paul Stearns wrote:

Alex:

Assuming we have containers like canvases with X-Y coordinate 
placement, I would need;


 1. Drag & Drop components.
 2. Resize components.
 3. Anchoring components relative to container.
 4. Component alignment tools (tops, middles, bottoms, lefts,
centers, rights).
 5. Undo/redo.
 6. Cut/Copy/Paste & duplicate components.
 7. Selecting multiple components for drag/drop/cut/copy/paste.
 8. Keyboard arrow use for nudging selected components.


The features described are available in MS VS and Flexbuilder 3 
which we use heavily.


Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588



*From*: Alex Harui 
*Sent*: 10/15/19 1:56 AM
*To*: "users@royale.apache.org" , 
"pa...@compuace.com" 

*Subject*: Re: IDE for Royale

FWIW, past discussions on this topic brought up the fact that the 
standard for “interactive developer-driven placement of widgets” in 
the HTML/JS/CSS world are things like JSFiddle which are considered 
much faster and more “real-time” than the workflow required by Flash 
Builder’s Design View.  FB’s DV was the best Adobe could do because 
that technology required compiling a SWF and re-starting the Flash 
Player usually as a browser plugin.  In the HTML world, you can just 
tweak a number, hit F5 and see it.



That means to me that DV-like things really ought to be more 
JSFiddle-ish.  The big difference is that instead of editing the 
source MXML, compiling, and re-loading in the browser, it might be 
better to build a tool that maps the HTML DOM to the MXML widgets so 
you can either edit in the Browser and some plug-in will offer to 
update your MXML files, or some other kind of plugin watches MXML 
files and updates the DOM in the browser, skipping the 
compile/transpile step if changes are only attributes.  I have a 
prototype of the latter that uses an AIR app to monitor MXML files 
and update a SWF via LocalConnection.  Judah was playing around with 
it, but not sure if he got it to work for JS.



Then the Royale IDE providers may not need to produce a 
DV-equivalent, or can leverage code in our repos to provide 
something like it.  DV was a pain 

Re: IDE for Royale

[QA]

You want a visual editor program in your virtual SWF OS? You might be 
able to load in Radiate  or reuse 
some of the work. There is a browser version and a desktop version. The 
source is Apache 2.0. You can test it here, 
https://velara3.github.io/ImageEditor/. It's not complete. If I was to 
work on it again there are some sections I'd do different. And there's 
no debugger. There's Royale debugger but that won't run in the browser. 
IIRC Josh T has helped the Moonshine guys setup debugging through a web 
socket.


Where will your virtual desktop run?

On 10/23/19 5:07 PM, Paul Stearns wrote:

Jude:

Actually I think my needs are fairly simple from a development point 
of view.


I really only work on one module at a time, and am looking for a 
visual editor.


If you want to see a sample of an application I have setup for 
beginning my leap into the unknown;


The URL is http://flex.yozyo.net/production


To login, you can use either;


U: dmanager
P: mpassword


U:duser
P:UPASSWORD

You will notice there is a virtual desktop with "programs" you can 
load using the menu bar. Since each "program" (actually individual SWF 
files) is self contained, there really is little to do other than 
visual editing of static components on panels. The MXML panels seldom 
contain anything other than static components. We sometimes will 
hide/overlay components, but we do that in actionscript and test it at 
run time.


If anything would be useful other than a WYSIWYG editor, that is a 
debugger, which allows stepping through code, seeing variables real 
time and trapping errors.


Paul R. Stearns
Advanced Consulting Enterprises, Inc.

15280 NW 79th Ct.
Suite 250
Miami Lakes, Fl 33016

Voice: (305)623-0360 x107
Fax: (305)623-4588



*From*: QA 
*Sent*: 10/23/19 3:06 PM
*To*: users@royale.apache.org
*Subject*: Re: IDE for Royale

Hi Paul,

I've been attempting to solve the DV problem for while with some 
projects. I designed a DV that exported to MXML and I had some success 
and in some areas I learned some things. It is a work in progress but 
it has been shelved for about a year. It's a long story so I'll get 
right to the main points.


What I got to work well was reading and writing single or multiple 
MXML documents but full applications were much more difficult. Because 
of the nature of Flash I could load in a SWF, traverse the Flex 
component tree and then export MXML but it didn't fit well with 
developers workflow. Developers would have a MXML or AS3 class that 
followed their own code paths or had frameworks that loaded screens 
through code. A full application couldn't easily be represented by a 
design view unless it adhered to a workflow that was compatible to the 
design tool.


For Royale, Alex had a tool that would monitor the MXML files in a 
directory, that you, the developer, would change from time to time in 
your code editor. At the same time your app would be running in the 
browser. As you updated the MXML, your app would be updated giving you 
a real time preview of your code changes. I was looking into what it 
would take to get it all working but I didn't have the time at the 
time but the concept is better suited in my opinion.


If we were to separate out the views from the main project (or the 
compilation phase) or parse them or support parsing them or the 
attributes at runtime a design view would be much simpler to support. 
If the views didn't change much it wouldn't matter as long as you keep 
the views independent.


For example, your designer can come along and say here is the Intro 
Screen.mxml, here is the MainView.mxml, here is the login screen.mxml, 
etc. And then using an agreed upon way to display or parse those you 
could keep the views really separate.


For the last few projects I've been working on Web Export for Adobe XD 
and with some work it could support an Royale export target. It's a 
plugin that takes an artboard or screen and exports it to HTML. 
There's no reason it couldn't support MXML.


Here is the playlist:

https://www.youtube.com/playlist?list=PLFBNT6gqr5u_NvUaLdHziGES_7Rw8-2pX

Here it is supporting some of the Materialize Components (roughly):

https://youtu.be/8V0Tzr6YUtI

You could have a Jewel component set or a basic component set. XD 
supports about 90% of the design features that you're asking for.


Jude

On 10/15/19 10:22 AM, Paul Stearns wrote:

Alex:

Assuming we have containers like canvases with X-Y coordinate 
placement, I would need;


 1. Drag & Drop components.
 2. Resize components.
 3. Anchoring components relative to container.
 4. Component alignment tools (tops, middles, bottoms, lefts,
centers, rights).
 5. Undo/redo.
 6. Cut/Copy/Paste & duplicate components.
 7. Selecting multiple components for drag/drop/cut/copy/paste.
 8. Keyboard arrow use for nudging selected components.


The features described are available in MS VS 

Re: IDE for Royale

[Carlos Rovira]

Paul,
currently we have debugger in Royale and you can stop in a break point and
check values.
IDEs should get better in this field, but what we have already is usable
actually.
In JS you need yo add source-maps when compile your library and project.


El mié., 23 oct. 2019 a las 23:10, Paul Stearns ()
escribió:

> Jude:
>
> Actually I think my needs are fairly simple from a development point of
> view.
>
> I really only work on one module at a time, and am looking for a visual
> editor.
>
> If you want to see a sample of an application I have setup for beginning
> my leap into the unknown;
>
> The URL is http://flex.yozyo.net/production
>
>
> To login, you can use either;
>
>
> U: dmanager
> P: mpassword
>
>
> U:duser
> P:UPASSWORD
>
> You will notice there is a virtual desktop with "programs" you can load
> using the menu bar. Since each "program" (actually individual SWF files) is
> self contained, there really is little to do other than visual editing of
> static components on panels. The MXML panels seldom contain anything other
> than static components. We sometimes will hide/overlay components, but we
> do that in actionscript and test it at run time.
>
> If anything would be useful other than a WYSIWYG editor, that is a
> debugger, which allows stepping through code, seeing variables real time
> and trapping errors.
>
> Paul R. Stearns
> Advanced Consulting Enterprises, Inc.
>
> 15280 NW 79th Ct.
> Suite 250
> Miami Lakes, Fl 33016
>
> Voice: (305)623-0360 x107
> Fax: (305)623-4588
>
> --
> *From*: QA 
> *Sent*: 10/23/19 3:06 PM
> *To*: users@royale.apache.org
> *Subject*: Re: IDE for Royale
>
> Hi Paul,
>
> I've been attempting to solve the DV problem for while with some projects.
> I designed a DV that exported to MXML and I had some success and in some
> areas I learned some things. It is a work in progress but it has been
> shelved for about a year. It's a long story so I'll get right to the main
> points.
>
> What I got to work well was reading and writing single or multiple MXML
> documents but full applications were much more difficult. Because of the
> nature of Flash I could load in a SWF, traverse the Flex component tree and
> then export MXML but it didn't fit well with developers workflow.
> Developers would have a MXML or AS3 class that followed their own code
> paths or had frameworks that loaded screens through code. A full
> application couldn't easily be represented by a design view unless it
> adhered to a workflow that was compatible to the design tool.
>
> For Royale, Alex had a tool that would monitor the MXML files in a
> directory, that you, the developer, would change from time to time in your
> code editor. At the same time your app would be running in the browser. As
> you updated the MXML, your app would be updated giving you a real time
> preview of your code changes. I was looking into what it would take to get
> it all working but I didn't have the time at the time but the concept is
> better suited in my opinion.
>
> If we were to separate out the views from the main project (or the
> compilation phase) or parse them or support parsing them or the attributes
> at runtime a design view would be much simpler to support. If the views
> didn't change much it wouldn't matter as long as you keep the views
> independent.
>
> For example, your designer can come along and say here is the Intro
> Screen.mxml, here is the MainView.mxml, here is the login screen.mxml, etc.
> And then using an agreed upon way to display or parse those you could keep
> the views really separate.
>
> For the last few projects I've been working on Web Export for Adobe XD and
> with some work it could support an Royale export target. It's a plugin that
> takes an artboard or screen and exports it to HTML. There's no reason it
> couldn't support MXML.
>
> Here is the playlist:
>
> https://www.youtube.com/playlist?list=PLFBNT6gqr5u_NvUaLdHziGES_7Rw8-2pX
>
> Here it is supporting some of the Materialize Components (roughly):
>
> https://youtu.be/8V0Tzr6YUtI
>
> You could have a Jewel component set or a basic component set. XD supports
> about 90% of the design features that you're asking for.
>
> Jude
> On 10/15/19 10:22 AM, Paul Stearns wrote:
>
> Alex:
>
> Assuming we have containers like canvases with X-Y coordinate placement, I
> would need;
>
>
>1. Drag & Drop components.
>2. Resize components.
>3. Anchoring components relative to container.
>4. Component alignment tools (tops, middles, bottoms, lefts, centers,
>rights).
>5. Undo/redo.
>6. Cut/Copy/Paste & duplicate components.
>7. Selecting multiple components for drag/drop/cut/copy/paste.
>8. Keyboard arrow use for nudging selected components.
>
>
> The features described are available in MS VS and Flexbuilder 3 which we
> use heavily.
>
> Paul R. Stearns
> Advanced Consulting Enterprises, Inc.
>
> 15280 NW 79th Ct.
> Suite 250
> Miami Lakes, Fl 33016
>
> Voice: (305)623-0360 x107
> 

Re: IDE for Royale

[Harbs]

Jude, that plugin is pretty cool.

Harbs

> On Oct 23, 2019, at 10:06 PM, QA  wrote:
> 
> Hi Paul,
> 
> I've been attempting to solve the DV problem for while with some projects. I 
> designed a DV that exported to MXML and I had some success and in some areas 
> I learned some things. It is a work in progress but it has been shelved for 
> about a year. It's a long story so I'll get right to the main points.
> 
> What I got to work well was reading and writing single or multiple MXML 
> documents but full applications were much more difficult. Because of the 
> nature of Flash I could load in a SWF, traverse the Flex component tree and 
> then export MXML but it didn't fit well with developers workflow. Developers 
> would have a MXML or AS3 class that followed their own code paths or had 
> frameworks that loaded screens through code. A full application couldn't 
> easily be represented by a design view unless it adhered to a workflow that 
> was compatible to the design tool. 
> For Royale, Alex had a tool that would monitor the MXML files in a directory, 
> that you, the developer, would change from time to time in your code editor. 
> At the same time your app would be running in the browser. As you updated the 
> MXML, your app would be   updated giving you a real time preview of your 
> code changes. I was looking into what it would take to get it all working but 
> I didn't have the time at the time but the concept is better suited in my 
> opinion. 
> If we were to separate out the views from the main project (or the 
> compilation phase) or parse them or support parsing them or the attributes at 
> runtime a design view would be much simpler to support. If the views didn't 
> change much it wouldn't matter as long as you keep the views independent. 
> For example, your designer can come along and say here is the Intro 
> Screen.mxml, here is the MainView.mxml, here is the login screen.mxml, etc. 
> And then using an agreed upon way to display or parse those you could keep 
> the views really separate. 
> For the last few projects I've been working on Web Export for Adobe XD and 
> with some work it could support an Royale export target. It's a plugin that 
> takes an artboard or screen and exports it to HTML. There's no reason it 
> couldn't support MXML. 
> 
> Here is the playlist:
> https://www.youtube.com/playlist?list=PLFBNT6gqr5u_NvUaLdHziGES_7Rw8-2pX 
> 
> Here it is supporting some of the Materialize Components (roughly): 
> https://youtu.be/8V0Tzr6YUtI 
> You could have a Jewel component set or a basic component set. XD supports 
> about 90% of the design features that you're asking for. 
> Jude
> On 10/15/19 10:22 AM, Paul Stearns wrote:
>> Alex:
>> 
>> Assuming we have containers like canvases with X-Y coordinate placement, I 
>> would need;
>> 
>> Drag & Drop components.
>> Resize components.
>> Anchoring components relative to container.
>> Component alignment tools (tops, middles, bottoms, lefts, centers, rights).
>> Undo/redo.
>> Cut/Copy/Paste & duplicate components.
>> Selecting multiple components for drag/drop/cut/copy/paste.
>> Keyboard arrow use for nudging selected components.
>> 
>> The features described are available in MS VS and Flexbuilder 3 which we use 
>> heavily.
>> 
>> Paul R. Stearns
>> Advanced Consulting Enterprises, Inc.
>> 
>> 15280 NW 79th Ct.
>> Suite 250
>> Miami Lakes, Fl 33016
>> 
>> Voice: (305)623-0360 x107
>> Fax: (305)623-4588
>> 
>> 
>> From: Alex Harui  
>> Sent: 10/15/19 1:56 AM
>> To: "users@royale.apache.org"  
>>  , 
>> "pa...@compuace.com"   
>> 
>> Subject: Re: IDE for Royale
>> FWIW, past discussions on this topic brought up the fact that the standard 
>> for “interactive developer-driven placement of widgets” in the HTML/JS/CSS 
>> world are things like JSFiddle which are considered much faster and more 
>> “real-time” than the workflow required by Flash Builder’s Design View.  FB’s 
>> DV was the best Adobe could do because that technology required compiling a 
>> SWF and re-starting the Flash Player usually as a browser plugin.  In the 
>> HTML world, you can just tweak a number, hit F5 and see it.
>> 
>>  
>> That means to me that DV-like things really ought to be more JSFiddle-ish.  
>> The big difference is that instead of editing the source MXML, compiling, 
>> and re-loading in the browser, it might be better to build a tool that maps 
>> the HTML DOM to the MXML widgets so you can either edit in the Browser and 
>> some plug-in will offer to update your MXML files, or some other kind of 
>> plugin watches MXML files and updates the DOM in the browser, skipping the 
>> compile/transpile step if changes are only attributes.  I have a prototype 
>> of the latter that uses an AIR app to