future of haxe

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

future of haxe

MartinLindelof
was talking to a c++ and as3 dev about haxe, and my endeavors with this "new" language. I asked him why he hadn't explored it?
he told me it seemed to be to new and have a uncertain future, if nicolas abandons it the whole platform will die.

have anyone of you gotten this feedback? for me i don't see it as a future scenario nor that it will go under if nicolas abandons it.

yet I tried to get him to try it out, for me it's such a treat. So thanks Nicolas and all you guys porting new targets, and building haxe!

-- 
Martin Lindelöf
www.medborgarplatsen.com

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Nicolas Cannasse
Le 11/07/2011 14:51, Martin Lindelöf a écrit :
> was talking to a c++ and as3 dev about haxe, and my endeavors with this
> "new" language. I asked him why he hadn't explored it?
> he told me it seemed to be to new and have a uncertain future, if
> nicolas abandons it the whole platform will die.

haXe has been alive since 2005 (see http://haxe.org/com/news) and many
people are now contributing to the core compiler (Franco, Hugh, Cauê,
...) Since it's open source, I'm sure that several people would be able
to take over in the unbelievable case I would stop working on it.

haXe is working perfectly fine so far, with near-zero show-stoppers
bugs, so the technology itself is already very solid. Motion-Twin and
several other companies are relying on haXe for their daily work so
there's a good incentive at pushing it further.

Your friend could also compare with other languages. Adobe has been
abandoning both AS1 and AS2 in past years, so I don't think commercial
companies are good at keeping a language alive.

Actually that's quite the contrary : since they NEED to sell you
something new they HAVE to deprecate "old stuff" at some point.

Best,
Nicolas

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

MarcWeber
In reply to this post by MartinLindelof
> have anyone of you gotten this feedback? for me i don't see it as a
> future scenario nor that it will go under if nicolas abandons it.

Don't think HaXe is going to die soon because some companies have
settled on it. The question to ask is: how much will it differ from a
stalled project?

If you look closer you'll see that a lot of indivdiuals do dedicate time
to the project. But the quality of the results differ. Eg if you look at
the old object mappings you'll see that the implementation for each
platform differ a lot - and that there is a lot of duplicate code making
me rewrite it .. But that's only a small fraction of what HaXe is about.

There are some reasons why I didn't dive deeper into HaXe compiler
development:

- my trivial patch about install.ml was rejected even though I'm sure it
  helps devs to understand the build process

- no pattern matching planned? (is this still correct?)

- the discussion about monads stalled which is *the* feature to get work
  work done such as implementing parser combinator libraries etc.
  This would help implementing "HAML" like dialects much.

- I think that macros should be powerful enough to generate classes -
  not function (contents) only (is this still true that this can't be
  done?)

- for flash there are no high quality GUI libraries (comparable to Flex
  or the like) yet. Some people seem to think its not necessary to have
  them. (I'm not a flash dev - this broke my neck for a small project in
  the past ..)

- I'd like to understand more about urweb details before settling on
  either language.

- It was not designed to generate efficient functional code.
  Writing guaranteed side effect free code is kind of hard.

But this is only my very personal view. Probably those topics don't
matter that much to game devs. And HaXe was written for developing
games AFAIK.

FDT started supporting HaXe which in turns means that if there is a huge
risk in getting started with HaXe a lot of companies are taking it.

Whether its worth using HaXe depends heavily on the use case. So there
is no easy answer.

If you start using HaXe you can compile quite a lot to .as3 - so not all
work would be lost when switching back to actionscript (probably others
should tell about their experience).

Last but not least: Look at technology. Its changing that fast. Given
that you may have to use new tools in the near future in any case.
Settling on HaXe gives you chance that all you have to do is rewrite the
code generator within HaXe.

However there are also a lot of competing projects. Eg there exist
closed source F# compiler generating JS. Scala's .class files can
be compiled to JS. ocaml, urweb, ruby, python, .. all can be compiled to
JS in some way AFAIK. HaXe's strength is that its OO nature is close to
the backends.

My experience with HaXe is limited. So make sure to read all replies :)

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

MartinLindelof
@marc

my experience is also limited, have only ported a lib to haxe but from that ordeal I learnt a lot. it was from java -> haXe so most stuf was similar.
getting into pureMVC for haxe for my next project which is my next website. (targeting flash, but hopefully learning enough haxe/js to make it a html5 site drawing to canvas)

but basically I'm convinced that haXe will be around for a long long time, I've ditched the stuf in as3 I had, and now have all my utils and in the process of building my tools explicit for haxe.

the issue I get when talking about haXe has been this, "what if" it goes under.
anyways. you're replies and @nicolas have given me some meat on the bone to argument for a haXe migration to other as3/c++ devs.



-- 
Martin Lindelöf
www.medborgarplatsen.com

On Monday, July 11, 2011 at 3:24 PM, Marc Weber wrote:

have anyone of you gotten this feedback? for me i don't see it as a
future scenario nor that it will go under if nicolas abandons it.

Don't think HaXe is going to die soon because some companies have
settled on it. The question to ask is: how much will it differ from a
stalled project?

If you look closer you'll see that a lot of indivdiuals do dedicate time
to the project. But the quality of the results differ. Eg if you look at
the old object mappings you'll see that the implementation for each
platform differ a lot - and that there is a lot of duplicate code making
me rewrite it .. But that's only a small fraction of what HaXe is about.

There are some reasons why I didn't dive deeper into HaXe compiler
development:

- my trivial patch about install.ml was rejected even though I'm sure it
helps devs to understand the build process

- no pattern matching planned? (is this still correct?)

- the discussion about monads stalled which is *the* feature to get work
work done such as implementing parser combinator libraries etc.
This would help implementing "HAML" like dialects much.

- I think that macros should be powerful enough to generate classes -
not function (contents) only (is this still true that this can't be
done?)

- for flash there are no high quality GUI libraries (comparable to Flex
or the like) yet. Some people seem to think its not necessary to have
them. (I'm not a flash dev - this broke my neck for a small project in
the past ..)

- I'd like to understand more about urweb details before settling on
either language.

- It was not designed to generate efficient functional code.
Writing guaranteed side effect free code is kind of hard.

But this is only my very personal view. Probably those topics don't
matter that much to game devs. And HaXe was written for developing
games AFAIK.

FDT started supporting HaXe which in turns means that if there is a huge
risk in getting started with HaXe a lot of companies are taking it.

Whether its worth using HaXe depends heavily on the use case. So there
is no easy answer.

If you start using HaXe you can compile quite a lot to .as3 - so not all
work would be lost when switching back to actionscript (probably others
should tell about their experience).

Last but not least: Look at technology. Its changing that fast. Given
that you may have to use new tools in the near future in any case.
Settling on HaXe gives you chance that all you have to do is rewrite the
code generator within HaXe.

However there are also a lot of competing projects. Eg there exist
closed source F# compiler generating JS. Scala's .class files can
be compiled to JS. ocaml, urweb, ruby, python, .. all can be compiled to
JS in some way AFAIK. HaXe's strength is that its OO nature is close to
the backends.

My experience with HaXe is limited. So make sure to read all replies :)

Marc Weber

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

jlm@justinfront.net
Martin

I get all the same responses, but you will find the resistances is sometimes short term, the important thing is to give them enough info on using haXe and it's capabilities, any knowledge they have on haXe will be out of date so bring them up to speed, then it's just a matter of time.  I think we often expect to be able to convert new users... but really just sowing a seed is often enough.  My current belief is that user groups will be a good solution to uptake, I know the haXe meet gave lots of attendees a boost.  I aim to go along to the next meh meeting, hope they plan one soon?  Wondering if there are people in the west country (uk) that would be interested in a meeting in Bath or Bristol, also I am interested in getting some speakers together for LFPUG in london and for the oxford adobe group.

 
On 11 Jul 2011, at 14:33, Martin Lindelöf wrote:

@marc

my experience is also limited, have only ported a lib to haxe but from that ordeal I learnt a lot. it was from java -> haXe so most stuf was similar.
getting into pureMVC for haxe for my next project which is my next website. (targeting flash, but hopefully learning enough haxe/js to make it a html5 site drawing to canvas)

but basically I'm convinced that haXe will be around for a long long time, I've ditched the stuf in as3 I had, and now have all my utils and in the process of building my tools explicit for haxe.

the issue I get when talking about haXe has been this, "what if" it goes under.
anyways. you're replies and @nicolas have given me some meat on the bone to argument for a haXe migration to other as3/c++ devs.



-- 
Martin Lindelöf
www.medborgarplatsen.com

On Monday, July 11, 2011 at 3:24 PM, Marc Weber wrote:

have anyone of you gotten this feedback? for me i don't see it as a
future scenario nor that it will go under if nicolas abandons it.

Don't think HaXe is going to die soon because some companies have
settled on it. The question to ask is: how much will it differ from a
stalled project?

If you look closer you'll see that a lot of indivdiuals do dedicate time
to the project. But the quality of the results differ. Eg if you look at
the old object mappings you'll see that the implementation for each
platform differ a lot - and that there is a lot of duplicate code making
me rewrite it .. But that's only a small fraction of what HaXe is about.

There are some reasons why I didn't dive deeper into HaXe compiler
development:

- my trivial patch about install.ml was rejected even though I'm sure it
helps devs to understand the build process

- no pattern matching planned? (is this still correct?)

- the discussion about monads stalled which is *the* feature to get work
work done such as implementing parser combinator libraries etc.
This would help implementing "HAML" like dialects much.

- I think that macros should be powerful enough to generate classes -
not function (contents) only (is this still true that this can't be
done?)

- for flash there are no high quality GUI libraries (comparable to Flex
or the like) yet. Some people seem to think its not necessary to have
them. (I'm not a flash dev - this broke my neck for a small project in
the past ..)

- I'd like to understand more about urweb details before settling on
either language.

- It was not designed to generate efficient functional code.
Writing guaranteed side effect free code is kind of hard.

But this is only my very personal view. Probably those topics don't
matter that much to game devs. And HaXe was written for developing
games AFAIK.

FDT started supporting HaXe which in turns means that if there is a huge
risk in getting started with HaXe a lot of companies are taking it.

Whether its worth using HaXe depends heavily on the use case. So there
is no easy answer.

If you start using HaXe you can compile quite a lot to .as3 - so not all
work would be lost when switching back to actionscript (probably others
should tell about their experience).

Last but not least: Look at technology. Its changing that fast. Given
that you may have to use new tools in the near future in any case.
Settling on HaXe gives you chance that all you have to do is rewrite the
code generator within HaXe.

However there are also a lot of competing projects. Eg there exist
closed source F# compiler generating JS. Scala's .class files can
be compiled to JS. ocaml, urweb, ruby, python, .. all can be compiled to
JS in some way AFAIK. HaXe's strength is that its OO nature is close to
the backends.

My experience with HaXe is limited. So make sure to read all replies :)

Marc Weber

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Fei Yin
In reply to this post by MarcWeber
Hi ! Marc,

For flash , I think we can use flex GUI library as well if you want to
. And there is another powerful GUI library ASwing has haXe port at
http://www.aswing.org/?cat=26 , and it supports flash target , and CPP
. So ,there already is good GUI library for flash platform in haXe .

2011/7/11 Marc Weber <[hidden email]>:

>> have anyone of you gotten this feedback? for me i don't see it as a
>> future scenario nor that it will go under if nicolas abandons it.
>
> Don't think HaXe is going to die soon because some companies have
> settled on it. The question to ask is: how much will it differ from a
> stalled project?
>
> If you look closer you'll see that a lot of indivdiuals do dedicate time
> to the project. But the quality of the results differ. Eg if you look at
> the old object mappings you'll see that the implementation for each
> platform differ a lot - and that there is a lot of duplicate code making
> me rewrite it .. But that's only a small fraction of what HaXe is about.
>
> There are some reasons why I didn't dive deeper into HaXe compiler
> development:
>
> - my trivial patch about install.ml was rejected even though I'm sure it
>  helps devs to understand the build process
>
> - no pattern matching planned? (is this still correct?)
>
> - the discussion about monads stalled which is *the* feature to get work
>  work done such as implementing parser combinator libraries etc.
>  This would help implementing "HAML" like dialects much.
>
> - I think that macros should be powerful enough to generate classes -
>  not function (contents) only (is this still true that this can't be
>  done?)
>
> - for flash there are no high quality GUI libraries (comparable to Flex
>  or the like) yet. Some people seem to think its not necessary to have
>  them. (I'm not a flash dev - this broke my neck for a small project in
>  the past ..)
>
> - I'd like to understand more about urweb details before settling on
>  either language.
>
> - It was not designed to generate efficient functional code.
>  Writing guaranteed side effect free code is kind of hard.
>
> But this is only my very personal view. Probably those topics don't
> matter that much to game devs. And HaXe was written for developing
> games AFAIK.
>
> FDT started supporting HaXe which in turns means that if there is a huge
> risk in getting started with HaXe a lot of companies are taking it.
>
> Whether its worth using HaXe depends heavily on the use case. So there
> is no easy answer.
>
> If you start using HaXe you can compile quite a lot to .as3 - so not all
> work would be lost when switching back to actionscript (probably others
> should tell about their experience).
>
> Last but not least: Look at technology. Its changing that fast. Given
> that you may have to use new tools in the near future in any case.
> Settling on HaXe gives you chance that all you have to do is rewrite the
> code generator within HaXe.
>
> However there are also a lot of competing projects. Eg there exist
> closed source F# compiler generating JS. Scala's .class files can
> be compiled to JS. ocaml, urweb, ruby, python, .. all can be compiled to
> JS in some way AFAIK. HaXe's strength is that its OO nature is close to
> the backends.
>
> My experience with HaXe is limited. So make sure to read all replies :)
>
> Marc Weber
>
> --
> haXe - an open source web programming language
> http://haxe.org
>



--
Yin Fei
>From Icebirds.net

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

MarcWeber
Hi Fei Yin,

I know that I'm not a flash guru.

aswing: I've had a look at the commit log. And it looked to me that
upstream stalled. That made me wonder .. But you're right. Maybe I
didn't spend enough time on that code.

flex: I didn't manage to use it from HaXe. Even if I did there would
have been the issue about how to include the required classes only.
You can't embed the full code - the result would be too large.

There are various issues. If you want I can try to digg up what others
told me that time.

> So ,there already is good GUI library for flash platform in haXe .
Those I had a look at didn't pleasure me at all. They were written for
older flash targets. And in order to support new widgets you would have
had to add code in a non modular way. (Talking about arctic here).

Yous should consider keeping those lines of an email you reply to only.
(Eg ctrl-sthift-end entf will delete the quoted tail of the mail)

The authors of haxball.com wrote their own gui library AFAIK. There must
have been a reason.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Lee Sylvester
I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI control, I tend to roll my own there and then.  It's not efficient, but 12 years writing Flash apps means I get it done quickly and exactly as I need it in any given situation.  One great thing about haXe is, if I want to avoid rolling my own control, I can wrap an existing Flash control by externing just those methods I'll interact with.  I can integrate really complex controls in minutes. The trick is not to go overboard.  Don't extern everything, just the methods and properties you need.  The rest can remain black boxed if you want.

Lee



On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:

> Hi Fei Yin,
>
> I know that I'm not a flash guru.
>
> aswing: I've had a look at the commit log. And it looked to me that
> upstream stalled. That made me wonder .. But you're right. Maybe I
> didn't spend enough time on that code.
>
> flex: I didn't manage to use it from HaXe. Even if I did there would
> have been the issue about how to include the required classes only.
> You can't embed the full code - the result would be too large.
>
> There are various issues. If you want I can try to digg up what others
> told me that time.
>
>> So ,there already is good GUI library for flash platform in haXe .
> Those I had a look at didn't pleasure me at all. They were written for
> older flash targets. And in order to support new widgets you would have
> had to add code in a non modular way. (Talking about arctic here).
>
> Yous should consider keeping those lines of an email you reply to only.
> (Eg ctrl-sthift-end entf will delete the quoted tail of the mail)
>
> The authors of haxball.com wrote their own gui library AFAIK. There must
> have been a reason.
>
> Marc Weber
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Tarwin Stroh-Spijer
I've never used Flex UI stuff before. I know there's good reasons for it but there's always things like ASwing or MinimalComps. I know if you're making RIA then it can be good to use these but generally I find everyone wants completely different interations and looks so it can be best to simply have, as stated above, a good library of abstracted class you can use.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________


On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]> wrote:
I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI control, I tend to roll my own there and then.  It's not efficient, but 12 years writing Flash apps means I get it done quickly and exactly as I need it in any given situation.  One great thing about haXe is, if I want to avoid rolling my own control, I can wrap an existing Flash control by externing just those methods I'll interact with.  I can integrate really complex controls in minutes. The trick is not to go overboard.  Don't extern everything, just the methods and properties you need.  The rest can remain black boxed if you want.

Lee



On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:

> Hi Fei Yin,
>
> I know that I'm not a flash guru.
>
> aswing: I've had a look at the commit log. And it looked to me that
> upstream stalled. That made me wonder .. But you're right. Maybe I
> didn't spend enough time on that code.
>
> flex: I didn't manage to use it from HaXe. Even if I did there would
> have been the issue about how to include the required classes only.
> You can't embed the full code - the result would be too large.
>
> There are various issues. If you want I can try to digg up what others
> told me that time.
>
>> So ,there already is good GUI library for flash platform in haXe .
> Those I had a look at didn't pleasure me at all. They were written for
> older flash targets. And in order to support new widgets you would have
> had to add code in a non modular way. (Talking about arctic here).
>
> Yous should consider keeping those lines of an email you reply to only.
> (Eg ctrl-sthift-end entf will delete the quoted tail of the mail)
>
> The authors of haxball.com wrote their own gui library AFAIK. There must
> have been a reason.
>
> Marc Weber
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

singmajesty
I call it the "magic wand" approach


Instead of functionality first, appearance second, like most components,  
you turn the equation on its head. First you create the functionality (key  
to most projects) then you "wave the magic wand" to make it come to life  
with the behavior you want it to have.



On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer  
<[hidden email]> wrote:

> I've never used Flex UI stuff before. I know there's good reasons for it  
> but
> there's always things like ASwing or MinimalComps. I know if you're  
> making
> RIA then it can be good to use these but generally I find everyone wants
> completely different interations and looks so it can be best to simply  
> have,
> as stated above, a good library of abstracted class you can use.
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: +61 3 8060 5321
> _______________________
>
>
> On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester  
> <[hidden email]>wrote:
>
>> I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
>> control, I tend to roll my own there and then.  It's not efficient, but  
>> 12
>> years writing Flash apps means I get it done quickly and exactly as I  
>> need
>> it in any given situation.  One great thing about haXe is, if I want to
>> avoid rolling my own control, I can wrap an existing Flash control by
>> externing just those methods I'll interact with.  I can integrate really
>> complex controls in minutes. The trick is not to go overboard.  Don't  
>> extern
>> everything, just the methods and properties you need.  The rest can  
>> remain
>> black boxed if you want.
>>
>> Lee
>>
>>
>>
>> On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:
>>
>> > Hi Fei Yin,
>> >
>> > I know that I'm not a flash guru.
>> >
>> > aswing: I've had a look at the commit log. And it looked to me that
>> > upstream stalled. That made me wonder .. But you're right. Maybe I
>> > didn't spend enough time on that code.
>> >
>> > flex: I didn't manage to use it from HaXe. Even if I did there would
>> > have been the issue about how to include the required classes only.
>> > You can't embed the full code - the result would be too large.
>> >
>> > There are various issues. If you want I can try to digg up what others
>> > told me that time.
>> >
>> >> So ,there already is good GUI library for flash platform in haXe .
>> > Those I had a look at didn't pleasure me at all. They were written for
>> > older flash targets. And in order to support new widgets you would  
>> have
>> > had to add code in a non modular way. (Talking about arctic here).
>> >
>> > Yous should consider keeping those lines of an email you reply to  
>> only.
>> > (Eg ctrl-sthift-end entf will delete the quoted tail of the mail)
>> >
>> > The authors of haxball.com wrote their own gui library AFAIK. There  
>> must
>> > have been a reason.
>> >
>> > Marc Weber
>> >
>> > --
>> > haXe - an open source web programming language
>> > http://haxe.org
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Lee Sylvester
I think you mean, "first you create the appearance" ;-) This is my approach also. It makes a lot of sense in a Flash app.  To do it the other way always takes longer, unless you don't care about look and feel.

Lee

Sent from my iPad

On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]> wrote:

> I call it the "magic wand" approach
>
>
> Instead of functionality first, appearance second, like most components, you turn the equation on its head. First you create the functionality (key to most projects) then you "wave the magic wand" to make it come to life with the behavior you want it to have.
>
>
>
> On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:
>
>> I've never used Flex UI stuff before. I know there's good reasons for it but
>> there's always things like ASwing or MinimalComps. I know if you're making
>> RIA then it can be good to use these but generally I find everyone wants
>> completely different interations and looks so it can be best to simply have,
>> as stated above, a good library of abstracted class you can use.
>>
>>
>> Tarwin Stroh-Spijer
>> _______________________
>>
>> Touch My Pixel
>> http://www.touchmypixel.com/
>> phone: +61 3 8060 5321
>> _______________________
>>
>>
>> On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]>wrote:
>>
>>> I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
>>> control, I tend to roll my own there and then.  It's not efficient, but 12
>>> years writing Flash apps means I get it done quickly and exactly as I need
>>> it in any given situation.  One great thing about haXe is, if I want to
>>> avoid rolling my own control, I can wrap an existing Flash control by
>>> externing just those methods I'll interact with.  I can integrate really
>>> complex controls in minutes. The trick is not to go overboard.  Don't extern
>>> everything, just the methods and properties you need.  The rest can remain
>>> black boxed if you want.
>>>
>>> Lee
>>>
>>>
>>>
>>> On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:
>>>
>>> > Hi Fei Yin,
>>> >
>>> > I know that I'm not a flash guru.
>>> >
>>> > aswing: I've had a look at the commit log. And it looked to me that
>>> > upstream stalled. That made me wonder .. But you're right. Maybe I
>>> > didn't spend enough time on that code.
>>> >
>>> > flex: I didn't manage to use it from HaXe. Even if I did there would
>>> > have been the issue about how to include the required classes only.
>>> > You can't embed the full code - the result would be too large.
>>> >
>>> > There are various issues. If you want I can try to digg up what others
>>> > told me that time.
>>> >
>>> >> So ,there already is good GUI library for flash platform in haXe .
>>> > Those I had a look at didn't pleasure me at all. They were written for
>>> > older flash targets. And in order to support new widgets you would have
>>> > had to add code in a non modular way. (Talking about arctic here).
>>> >
>>> > Yous should consider keeping those lines of an email you reply to only.
>>> > (Eg ctrl-sthift-end entf will delete the quoted tail of the mail)
>>> >
>>> > The authors of haxball.com wrote their own gui library AFAIK. There must
>>> > have been a reason.
>>> >
>>> > Marc Weber
>>> >
>>> > --
>>> > haXe - an open source web programming language
>>> > http://haxe.org
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

singmajesty
Ah, no... I meant "magic wand," because I have libraries set up for  
different UI behaviors. It wouldn't be as "magic" if I was writing the  
behavior myself each time.

For example, the scrollbar takes a scroll handle, scroll track and  
optionally an up button and down button. Viola, it scrolls and acts like a  
scrollbar, regardless of the size or shape of the graphics.

Once you have the library in place, going from appearance to full  
functionality is like Mickey in the Sorcerer's Apprentice, turning mops  
and buckets into his minions ;)



On Wed, 13 Jul 2011 23:20:08 -0700, Lee Sylvester <[hidden email]>  
wrote:

> I think you mean, "first you create the appearance" ;-) This is my  
> approach also. It makes a lot of sense in a Flash app.  To do it the  
> other way always takes longer, unless you don't care about look and feel.
>
> Lee
>
> Sent from my iPad
>
> On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]>  
> wrote:
>
>> I call it the "magic wand" approach
>>
>>
>> Instead of functionality first, appearance second, like most  
>> components, you turn the equation on its head. First you create the  
>> functionality (key to most projects) then you "wave the magic wand" to  
>> make it come to life with the behavior you want it to have.
>>
>>
>>
>> On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer  
>> <[hidden email]> wrote:
>>
>>> I've never used Flex UI stuff before. I know there's good reasons for  
>>> it but
>>> there's always things like ASwing or MinimalComps. I know if you're  
>>> making
>>> RIA then it can be good to use these but generally I find everyone  
>>> wants
>>> completely different interations and looks so it can be best to simply  
>>> have,
>>> as stated above, a good library of abstracted class you can use.
>>>
>>>
>>> Tarwin Stroh-Spijer
>>> _______________________
>>>
>>> Touch My Pixel
>>> http://www.touchmypixel.com/
>>> phone: +61 3 8060 5321
>>> _______________________
>>>
>>>
>>> On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester  
>>> <[hidden email]>wrote:
>>>
>>>> I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
>>>> control, I tend to roll my own there and then.  It's not efficient,  
>>>> but 12
>>>> years writing Flash apps means I get it done quickly and exactly as I  
>>>> need
>>>> it in any given situation.  One great thing about haXe is, if I want  
>>>> to
>>>> avoid rolling my own control, I can wrap an existing Flash control by
>>>> externing just those methods I'll interact with.  I can integrate  
>>>> really
>>>> complex controls in minutes. The trick is not to go overboard.  Don't  
>>>> extern
>>>> everything, just the methods and properties you need.  The rest can  
>>>> remain
>>>> black boxed if you want.
>>>>
>>>> Lee
>>>>
>>>>
>>>>
>>>> On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:
>>>>
>>>> > Hi Fei Yin,
>>>> >
>>>> > I know that I'm not a flash guru.
>>>> >
>>>> > aswing: I've had a look at the commit log. And it looked to me that
>>>> > upstream stalled. That made me wonder .. But you're right. Maybe I
>>>> > didn't spend enough time on that code.
>>>> >
>>>> > flex: I didn't manage to use it from HaXe. Even if I did there would
>>>> > have been the issue about how to include the required classes only.
>>>> > You can't embed the full code - the result would be too large.
>>>> >
>>>> > There are various issues. If you want I can try to digg up what  
>>>> others
>>>> > told me that time.
>>>> >
>>>> >> So ,there already is good GUI library for flash platform in haXe .
>>>> > Those I had a look at didn't pleasure me at all. They were written  
>>>> for
>>>> > older flash targets. And in order to support new widgets you would  
>>>> have
>>>> > had to add code in a non modular way. (Talking about arctic here).
>>>> >
>>>> > Yous should consider keeping those lines of an email you reply to  
>>>> only.
>>>> > (Eg ctrl-sthift-end entf will delete the quoted tail of the mail)
>>>> >
>>>> > The authors of haxball.com wrote their own gui library AFAIK. There  
>>>> must
>>>> > have been a reason.
>>>> >
>>>> > Marc Weber
>>>> >
>>>> > --
>>>> > haXe - an open source web programming language
>>>> > http://haxe.org
>>>>
>>>> --
>>>> haXe - an open source web programming language
>>>> http://haxe.org
>>>>
>>
>>
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Tarwin Stroh-Spijer
Yeah we work the sane way. The only "strange" thing you might find is
you have to export each different style (if needed) as a different
class- simply fixed by extending your base with an empty class (this
is for Flash @:bind at least)

On Thursday, July 14, 2011, Joshua Granick <[hidden email]> wrote:

> Ah, no... I meant "magic wand," because I have libraries set up for different UI behaviors. It wouldn't be as "magic" if I was writing the behavior myself each time.
>
> For example, the scrollbar takes a scroll handle, scroll track and optionally an up button and down button. Viola, it scrolls and acts like a scrollbar, regardless of the size or shape of the graphics.
>
> Once you have the library in place, going from appearance to full functionality is like Mickey in the Sorcerer's Apprentice, turning mops and buckets into his minions ;)
>
>
>
> On Wed, 13 Jul 2011 23:20:08 -0700, Lee Sylvester <[hidden email]> wrote:
>
>
> I think you mean, "first you create the appearance" ;-) This is my approach also. It makes a lot of sense in a Flash app.  To do it the other way always takes longer, unless you don't care about look and feel.
>
> Lee
>
> Sent from my iPad
>
> On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]> wrote:
>
>
> I call it the "magic wand" approach
>
>
> Instead of functionality first, appearance second, like most components, you turn the equation on its head. First you create the functionality (key to most projects) then you "wave the magic wand" to make it come to life with the behavior you want it to have.
>
>
>
> On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:
>
>
> I've never used Flex UI stuff before. I know there's good reasons for it but
> there's always things like ASwing or MinimalComps. I know if you're making
> RIA then it can be good to use these but generally I find everyone wants
> completely different interations and looks so it can be best to simply have,
> as stated above, a good library of abstracted class you can use.
>
>
> Tarwin Stroh-Spijer
> _______________________
>
> Touch My Pixel
> http://www.touchmypixel.com/
> phone: +61 3 8060 5321
> _______________________
>
>
> On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]>wrote:
>
>
> I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
> control, I tend to roll my own there and then.  It's not efficient, but 12
> years writing Flash apps means I get it done quickly and exactly as I need
> it in any given situation.  One great thing about haXe is, if I want to
> avoid rolling my own control, I can wrap an existing Flash control by
> externing just those methods I'll interact with.  I can integrate really
> complex controls in minutes. The trick is not to go overboard.  Don't extern
> everything, just the methods and properties you need.  The rest can remain
> black boxed if you want.
>
> Lee
>
>
>
> On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:
>
>> Hi Fei Yin,
>>
>> I know that I'm not a flash guru.
>>
>> aswing: I've had a look at the commit log. And it looked to me that
>> upstream stalled. That made me wonder .. But you're right. Maybe I
>> didn't spend enough time on that code.
>>
>> flex: I didn't manage to use it from HaXe. Even if I did there would
>> have been the issue about how to include the required classes only.
>> You can't embed the full code - the result would be too large.
>>
>> There are various issues. If you want I can try to digg up what others
>> told me that time.
>>
>>> So ,there already is good GUI library for flash platform in haXe .
>> Those I had a look at didn't pleasure me at all. They were written for
>> older flash targets. And in order to support new widgets you would have
>> had to add code in a non modular way. (Talking about arctic here).
>>
>> Yous should consider keeping those lines of an email you reply to only.
>> (Eg ctrl-sthift-end entf will delete the quoted tail of the mail)
>>
>> The authors of haxball.com wrote their own gui library AFAIK. There must
>> have been a reason.
>>
>> Marc Weber
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
>
>
> --
> Using Opera's revoluti

--


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: +61 3 8060 5321
_______________________

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Simon Asselbergs
In reply to this post by singmajesty
Hi Joshua,

That sounds a bit like a kind of Law, I would say "it depends" . It depends on the kind of project and businessprocesses. It's certainly not "The Law" :p
But it's true when i comes to components that at least they should be easy to configure, tweak and compose (!!). A basic good set of simple components for majority of basic interfaces is nice, a framework and some extra batteries even better. However for most RIA's some good skinning options are vital...

Simon

On Thu, Jul 14, 2011 at 7:27 AM, Joshua Granick <[hidden email]> wrote:
I call it the "magic wand" approach


Instead of functionality first, appearance second, like most components, you turn the equation on its head. First you create the functionality (key to most projects) then you "wave the magic wand" to make it come to life with the behavior you want it to have.



On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:

I've never used Flex UI stuff before. I know there's good reasons for it but
there's always things like ASwing or MinimalComps. I know if you're making
RIA then it can be good to use these but generally I find everyone wants
completely different interations and looks so it can be best to simply have,
as stated above, a good library of abstracted class you can use.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321
_______________________


On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]>wrote:

I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
control, I tend to roll my own there and then.  It's not efficient, but 12
years writing Flash apps means I get it done quickly and exactly as I need
it in any given situation.  One great thing about haXe is, if I want to
avoid rolling my own control, I can wrap an existing Flash control by
externing just those methods I'll interact with.  I can integrate really
complex controls in minutes. The trick is not to go overboard.  Don't extern
everything, just the methods and properties you need.  The rest can remain
black boxed if you want.

Lee



On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:

> Hi Fei Yin,
>
> I know that I'm not a flash guru.
>
> aswing: I've had a look at the commit log. And it looked to me that
> upstream stalled. That made me wonder .. But you're right. Maybe I
> didn't spend enough time on that code.
>
> flex: I didn't manage to use it from HaXe. Even if I did there would
> have been the issue about how to include the required classes only.
> You can't embed the full code - the result would be too large.
>
> There are various issues. If you want I can try to digg up what others
> told me that time.
>
>> So ,there already is good GUI library for flash platform in haXe .
> Those I had a look at didn't pleasure me at all. They were written for
> older flash targets. And in order to support new widgets you would have
> had to add code in a non modular way. (Talking about arctic here).
>
> Yous should consider keeping those lines of an email you reply to only.
> (Eg ctrl-sthift-end entf will delete the quoted tail of the mail)
>
> The authors of haxball.com wrote their own gui library AFAIK. There must
> have been a reason.
>
> Marc Weber
>
> --
> haXe - an open source web programming language
> http://haxe.org

--
haXe - an open source web programming language
http://haxe.org



--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

singmajesty
In reply to this post by Tarwin Stroh-Spijer
When I work in Flash, I work like this...


1.) Create an "important" object, like a sliding panel

2.) Export the MovieClip as a class, usually named something like  
"SlidingPanel_Display"

3.) Create a new class that extends SlidingPanel_Display, and customize  
the thing with custom functionality

4.) "replaceObject (Display.SlidingPanel, new SuperDuperSlidingPanel ());"



For something like a scrollbar, I don't usually need the objects to be  
their own classes. I just do something like "new ScrollBarUI  
(Display.ScrollHandle, Display.ScrollTrack, Display.ScrollUp,  
Display.ScrollDown);" and manage it like an object. However, in cases  
where I really want to have a custom class, I use a format like above -- I  
never have to compile to replace empty classes.

At runtime, my "important object" is going to be a "dumb" instance -- it  
looks right, but it doesn't have any of the "super duper" functionality I  
used to extend it. So once the project begins, I run a replaceObject()  
script, which removes the plain instance and replaces it with a new  
instance of my custom class. Since it extends the same object, it looks  
the same, but now it has the special functionality I am looking for.


If anyone is interested in this approach, I can paste the contents of my  
replaceObject() script, but basically it copies x, y, alpha, filters,  
parent, and optionally rounds off the position, so it will sit on even  
pixels and look a bit sharper.



On Thu, 14 Jul 2011 06:31:48 -0700, Tarwin Stroh-Spijer  
<[hidden email]> wrote:

> Yeah we work the sane way. The only "strange" thing you might find is
> you have to export each different style (if needed) as a different
> class- simply fixed by extending your base with an empty class (this
> is for Flash @:bind at least)
>
> On Thursday, July 14, 2011, Joshua Granick <[hidden email]>  
> wrote:
>> Ah, no... I meant "magic wand," because I have libraries set up for  
>> different UI behaviors. It wouldn't be as "magic" if I was writing the  
>> behavior myself each time.
>>
>> For example, the scrollbar takes a scroll handle, scroll track and  
>> optionally an up button and down button. Viola, it scrolls and acts  
>> like a scrollbar, regardless of the size or shape of the graphics.
>>
>> Once you have the library in place, going from appearance to full  
>> functionality is like Mickey in the Sorcerer's Apprentice, turning mops  
>> and buckets into his minions ;)
>>
>>
>>
>> On Wed, 13 Jul 2011 23:20:08 -0700, Lee Sylvester  
>> <[hidden email]> wrote:
>>
>>
>> I think you mean, "first you create the appearance" ;-) This is my  
>> approach also. It makes a lot of sense in a Flash app.  To do it the  
>> other way always takes longer, unless you don't care about look and  
>> feel.
>>
>> Lee
>>
>> Sent from my iPad
>>
>> On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]>  
>> wrote:
>>
>>
>> I call it the "magic wand" approach
>>
>>
>> Instead of functionality first, appearance second, like most  
>> components, you turn the equation on its head. First you create the  
>> functionality (key to most projects) then you "wave the magic wand" to  
>> make it come to life with the behavior you want it to have.
>>
>>
>>
>> On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer  
>> <[hidden email]> wrote:
>>
>>
>> I've never used Flex UI stuff before. I know there's good reasons for  
>> it but
>> there's always things like ASwing or MinimalComps. I know if you're  
>> making
>> RIA then it can be good to use these but generally I find everyone wants
>> completely different interations and looks so it can be best to simply  
>> have,
>> as stated above, a good library of abstracted class you can use.
>>
>>
>> Tarwin Stroh-Spijer
>> _______________________
>>
>> Touch My Pixel
>> http://www.touchmypixel.com/
>> phone: +61 3 8060 5321
>> _______________________
>>
>>
>> On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester  
>> <[hidden email]>wrote:
>>
>>
>> I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
>> control, I tend to roll my own there and then.  It's not efficient, but  
>> 12
>> years writing Flash apps means I get it done quickly and exactly as I  
>> need
>> it in any given situation.  One great thing about haXe is, if I want to
>> avoid rolling my own control, I can wrap an existing Flash control by
>> externing just those methods I'll interact with.  I can integrate really
>> complex controls in minutes. The trick is not to go overboard.  Don't  
>> extern
>> everything, just the methods and properties you need.  The rest can  
>> remain
>> black boxed if you want.
>>
>> Lee
>>
>>
>>
>> On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:
>>
>>> Hi Fei Yin,
>>>
>>> I know that I'm not a flash guru.
>>>
>>> aswing: I've had a look at the commit log. And it looked to me that
>>> upstream stalled. That made me wonder .. But you're right. Maybe I
>>> didn't spend enough time on that code.
>>>
>>> flex: I didn't manage to use it from HaXe. Even if I did there would
>>> have been the issue about how to include the required classes only.
>>> You can't embed the full code - the result would be too large.
>>>
>>> There are various issues. If you want I can try to digg up what others
>>> told me that time.
>>>
>>>> So ,there already is good GUI library for flash platform in haXe .
>>> Those I had a look at didn't pleasure me at all. They were written for
>>> older flash targets. And in order to support new widgets you would have
>>> had to add code in a non modular way. (Talking about arctic here).
>>>
>>> Yous should consider keeping those lines of an email you reply to only.
>>> (Eg ctrl-sthift-end entf will delete the quoted tail of the mail)
>>>
>>> The authors of haxball.com wrote their own gui library AFAIK. There  
>>> must
>>> have been a reason.
>>>
>>> Marc Weber
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>
>>
>>
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>>
>>
>> --
>> Using Opera's revoluti
>


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Baluta Cristian
I don't know how the discussion got here, but I have skins :P . I create a skin class with some predefinite fields and i pass it to the scrollbar, button, slider or whatever, which will display and arrange them as needed. 

new Button(x, y, new Skin("label", colors));


On Thu, Jul 14, 2011 at 7:01 PM, Joshua Granick <[hidden email]> wrote:
When I work in Flash, I work like this...


1.) Create an "important" object, like a sliding panel

2.) Export the MovieClip as a class, usually named something like "SlidingPanel_Display"

3.) Create a new class that extends SlidingPanel_Display, and customize the thing with custom functionality

4.) "replaceObject (Display.SlidingPanel, new SuperDuperSlidingPanel ());"



For something like a scrollbar, I don't usually need the objects to be their own classes. I just do something like "new ScrollBarUI (Display.ScrollHandle, Display.ScrollTrack, Display.ScrollUp, Display.ScrollDown);" and manage it like an object. However, in cases where I really want to have a custom class, I use a format like above -- I never have to compile to replace empty classes.

At runtime, my "important object" is going to be a "dumb" instance -- it looks right, but it doesn't have any of the "super duper" functionality I used to extend it. So once the project begins, I run a replaceObject() script, which removes the plain instance and replaces it with a new instance of my custom class. Since it extends the same object, it looks the same, but now it has the special functionality I am looking for.


If anyone is interested in this approach, I can paste the contents of my replaceObject() script, but basically it copies x, y, alpha, filters, parent, and optionally rounds off the position, so it will sit on even pixels and look a bit sharper.




On Thu, 14 Jul 2011 06:31:48 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:

Yeah we work the sane way. The only "strange" thing you might find is
you have to export each different style (if needed) as a different
class- simply fixed by extending your base with an empty class (this
is for Flash @:bind at least)

On Thursday, July 14, 2011, Joshua Granick <[hidden email]> wrote:
Ah, no... I meant "magic wand," because I have libraries set up for different UI behaviors. It wouldn't be as "magic" if I was writing the behavior myself each time.

For example, the scrollbar takes a scroll handle, scroll track and optionally an up button and down button. Viola, it scrolls and acts like a scrollbar, regardless of the size or shape of the graphics.

Once you have the library in place, going from appearance to full functionality is like Mickey in the Sorcerer's Apprentice, turning mops and buckets into his minions ;)



On Wed, 13 Jul 2011 23:20:08 -0700, Lee Sylvester <[hidden email]> wrote:


I think you mean, "first you create the appearance" ;-) This is my approach also. It makes a lot of sense in a Flash app.  To do it the other way always takes longer, unless you don't care about look and feel.

Lee

Sent from my iPad

On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]> wrote:


I call it the "magic wand" approach


Instead of functionality first, appearance second, like most components, you turn the equation on its head. First you create the functionality (key to most projects) then you "wave the magic wand" to make it come to life with the behavior you want it to have.



On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:


I've never used Flex UI stuff before. I know there's good reasons for it but
there's always things like ASwing or MinimalComps. I know if you're making
RIA then it can be good to use these but generally I find everyone wants
completely different interations and looks so it can be best to simply have,
as stated above, a good library of abstracted class you can use.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321
_______________________


On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]>wrote:


I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
control, I tend to roll my own there and then.  It's not efficient, but 12
years writing Flash apps means I get it done quickly and exactly as I need
it in any given situation.  One great thing about haXe is, if I want to
avoid rolling my own control, I can wrap an existing Flash control by
externing just those methods I'll interact with.  I can integrate really
complex controls in minutes. The trick is not to go overboard.  Don't extern
everything, just the methods and properties you need.  The rest can remain
black boxed if you want.

Lee



On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:

Hi Fei Yin,

I know that I'm not a flash guru.

aswing: I've had a look at the commit log. And it looked to me that
upstream stalled. That made me wonder .. But you're right. Maybe I
didn't spend enough time on that code.

flex: I didn't manage to use it from HaXe. Even if I did there would
have been the issue about how to include the required classes only.
You can't embed the full code - the result would be too large.

There are various issues. If you want I can try to digg up what others
told me that time.

So ,there already is good GUI library for flash platform in haXe .
Those I had a look at didn't pleasure me at all. They were written for
older flash targets. And in order to support new widgets you would have
had to add code in a non modular way. (Talking about arctic here).

Yous should consider keeping those lines of an email you reply to only.
(Eg ctrl-sthift-end entf will delete the quoted tail of the mail)

The authors of haxball.com wrote their own gui library AFAIK. There must
have been a reason.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org




--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Using Opera's revoluti



--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

MartinLindelof
anyone else using puremvc? I'm just starting to learn it, reading tuts, and have coded some simple boilerplate template with textmate so I can setup a project with a click.
I'm going all in on puremvc, I've had "my own" interp of MVC but, I think it's better to use something so wide spread.

-- 
Martin Lindelöf
www.medborgarplatsen.com

On Thursday, July 14, 2011 at 6:56 PM, Baluta Cristian wrote:

I don't know how the discussion got here, but I have skins :P . I create a skin class with some predefinite fields and i pass it to the scrollbar, button, slider or whatever, which will display and arrange them as needed. 

new Button(x, y, new Skin("label", colors));


On Thu, Jul 14, 2011 at 7:01 PM, Joshua Granick <[hidden email]> wrote:
When I work in Flash, I work like this...


1.) Create an "important" object, like a sliding panel

2.) Export the MovieClip as a class, usually named something like "SlidingPanel_Display"

3.) Create a new class that extends SlidingPanel_Display, and customize the thing with custom functionality

4.) "replaceObject (Display.SlidingPanel, new SuperDuperSlidingPanel ());"



For something like a scrollbar, I don't usually need the objects to be their own classes. I just do something like "new ScrollBarUI (Display.ScrollHandle, Display.ScrollTrack, Display.ScrollUp, Display.ScrollDown);" and manage it like an object. However, in cases where I really want to have a custom class, I use a format like above -- I never have to compile to replace empty classes.

At runtime, my "important object" is going to be a "dumb" instance -- it looks right, but it doesn't have any of the "super duper" functionality I used to extend it. So once the project begins, I run a replaceObject() script, which removes the plain instance and replaces it with a new instance of my custom class. Since it extends the same object, it looks the same, but now it has the special functionality I am looking for.


If anyone is interested in this approach, I can paste the contents of my replaceObject() script, but basically it copies x, y, alpha, filters, parent, and optionally rounds off the position, so it will sit on even pixels and look a bit sharper.




On Thu, 14 Jul 2011 06:31:48 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:

Yeah we work the sane way. The only "strange" thing you might find is
you have to export each different style (if needed) as a different
class- simply fixed by extending your base with an empty class (this
is for Flash @:bind at least)

On Thursday, July 14, 2011, Joshua Granick <[hidden email]> wrote:
Ah, no... I meant "magic wand," because I have libraries set up for different UI behaviors. It wouldn't be as "magic" if I was writing the behavior myself each time.

For example, the scrollbar takes a scroll handle, scroll track and optionally an up button and down button. Viola, it scrolls and acts like a scrollbar, regardless of the size or shape of the graphics.

Once you have the library in place, going from appearance to full functionality is like Mickey in the Sorcerer's Apprentice, turning mops and buckets into his minions ;)



On Wed, 13 Jul 2011 23:20:08 -0700, Lee Sylvester <[hidden email]> wrote:


I think you mean, "first you create the appearance" ;-) This is my approach also. It makes a lot of sense in a Flash app.  To do it the other way always takes longer, unless you don't care about look and feel.

Lee

Sent from my iPad

On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]> wrote:


I call it the "magic wand" approach


Instead of functionality first, appearance second, like most components, you turn the equation on its head. First you create the functionality (key to most projects) then you "wave the magic wand" to make it come to life with the behavior you want it to have.



On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:


I've never used Flex UI stuff before. I know there's good reasons for it but
there's always things like ASwing or MinimalComps. I know if you're making
RIA then it can be good to use these but generally I find everyone wants
completely different interations and looks so it can be best to simply have,
as stated above, a good library of abstracted class you can use.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" value="+61380605321" target="_blank">+61 3 8060 5321
_______________________


On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]>wrote:


I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
control, I tend to roll my own there and then.  It's not efficient, but 12
years writing Flash apps means I get it done quickly and exactly as I need
it in any given situation.  One great thing about haXe is, if I want to
avoid rolling my own control, I can wrap an existing Flash control by
externing just those methods I'll interact with.  I can integrate really
complex controls in minutes. The trick is not to go overboard.  Don't extern
everything, just the methods and properties you need.  The rest can remain
black boxed if you want.

Lee



On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:

Hi Fei Yin,

I know that I'm not a flash guru.

aswing: I've had a look at the commit log. And it looked to me that
upstream stalled. That made me wonder .. But you're right. Maybe I
didn't spend enough time on that code.

flex: I didn't manage to use it from HaXe. Even if I did there would
have been the issue about how to include the required classes only.
You can't embed the full code - the result would be too large.

There are various issues. If you want I can try to digg up what others
told me that time.

So ,there already is good GUI library for flash platform in haXe .
Those I had a look at didn't pleasure me at all. They were written for
older flash targets. And in order to support new widgets you would have
had to add code in a non modular way. (Talking about arctic here).

Yous should consider keeping those lines of an email you reply to only.
(Eg ctrl-sthift-end entf will delete the quoted tail of the mail)

The authors of haxball.com wrote their own gui library AFAIK. There must
have been a reason.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org

--
haXe - an open source web programming language
http://haxe.org




--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Using Opera's revoluti



--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org



--
Băluță Cristian
http://ralcr.com
http://imagin.ro
--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

RE: future of haxe

Lee Sylvester

I’ve used it lots.  It’s a great MVC, but it’s bloated.  RobotLegs is by far a better MVC.

 

Lee

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Lindelöf
Sent: 15 July 2011 09:48
To: The haXe compiler list
Subject: Re: [haXe] future of haxe

 

anyone else using puremvc? I'm just starting to learn it, reading tuts, and have coded some simple boilerplate template with textmate so I can setup a project with a click.

I'm going all in on puremvc, I've had "my own" interp of MVC but, I think it's better to use something so wide spread.


-- 
Martin Lindelöf
www.medborgarplatsen.com

On Thursday, July 14, 2011 at 6:56 PM, Baluta Cristian wrote:

I don't know how the discussion got here, but I have skins :P . I create a skin class with some predefinite fields and i pass it to the scrollbar, button, slider or whatever, which will display and arrange them as needed. 

 

new Button(x, y, new Skin("label", colors));

 

On Thu, Jul 14, 2011 at 7:01 PM, Joshua Granick <[hidden email]> wrote:

When I work in Flash, I work like this...


1.) Create an "important" object, like a sliding panel

2.) Export the MovieClip as a class, usually named something like "SlidingPanel_Display"

3.) Create a new class that extends SlidingPanel_Display, and customize the thing with custom functionality

4.) "replaceObject (Display.SlidingPanel, new SuperDuperSlidingPanel ());"



For something like a scrollbar, I don't usually need the objects to be their own classes. I just do something like "new ScrollBarUI (Display.ScrollHandle, Display.ScrollTrack, Display.ScrollUp, Display.ScrollDown);" and manage it like an object. However, in cases where I really want to have a custom class, I use a format like above -- I never have to compile to replace empty classes.

At runtime, my "important object" is going to be a "dumb" instance -- it looks right, but it doesn't have any of the "super duper" functionality I used to extend it. So once the project begins, I run a replaceObject() script, which removes the plain instance and replaces it with a new instance of my custom class. Since it extends the same object, it looks the same, but now it has the special functionality I am looking for.


If anyone is interested in this approach, I can paste the contents of my replaceObject() script, but basically it copies x, y, alpha, filters, parent, and optionally rounds off the position, so it will sit on even pixels and look a bit sharper.





On Thu, 14 Jul 2011 06:31:48 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:


Yeah we work the sane way. The only "strange" thing you might find is
you have to export each different style (if needed) as a different
class- simply fixed by extending your base with an empty class (this
is for Flash @:bind at least)

On Thursday, July 14, 2011, Joshua Granick <[hidden email]> wrote:

Ah, no... I meant "magic wand," because I have libraries set up for different UI behaviors. It wouldn't be as "magic" if I was writing the behavior myself each time.

For example, the scrollbar takes a scroll handle, scroll track and optionally an up button and down button. Viola, it scrolls and acts like a scrollbar, regardless of the size or shape of the graphics.

Once you have the library in place, going from appearance to full functionality is like Mickey in the Sorcerer's Apprentice, turning mops and buckets into his minions ;)



On Wed, 13 Jul 2011 23:20:08 -0700, Lee Sylvester <[hidden email]> wrote:


I think you mean, "first you create the appearance" ;-) This is my approach also. It makes a lot of sense in a Flash app.  To do it the other way always takes longer, unless you don't care about look and feel.

Lee

Sent from my iPad

On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]> wrote:


I call it the "magic wand" approach


Instead of functionality first, appearance second, like most components, you turn the equation on its head. First you create the functionality (key to most projects) then you "wave the magic wand" to make it come to life with the behavior you want it to have.



On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:


I've never used Flex UI stuff before. I know there's good reasons for it but
there's always things like ASwing or MinimalComps. I know if you're making
RIA then it can be good to use these but generally I find everyone wants
completely different interations and looks so it can be best to simply have,
as stated above, a good library of abstracted class you can use.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" target="_blank">+61 3 8060 5321
_______________________


On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]>wrote:


I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
control, I tend to roll my own there and then.  It's not efficient, but 12
years writing Flash apps means I get it done quickly and exactly as I need
it in any given situation.  One great thing about haXe is, if I want to
avoid rolling my own control, I can wrap an existing Flash control by
externing just those methods I'll interact with.  I can integrate really
complex controls in minutes. The trick is not to go overboard.  Don't extern
everything, just the methods and properties you need.  The rest can remain
black boxed if you want.

Lee



On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:


Hi Fei Yin,

I know that I'm not a flash guru.

aswing: I've had a look at the commit log. And it looked to me that
upstream stalled. That made me wonder .. But you're right. Maybe I
didn't spend enough time on that code.

flex: I didn't manage to use it from HaXe. Even if I did there would
have been the issue about how to include the required classes only.
You can't embed the full code - the result would be too large.

There are various issues. If you want I can try to digg up what others
told me that time.


So ,there already is good GUI library for flash platform in haXe .

Those I had a look at didn't pleasure me at all. They were written for
older flash targets. And in order to support new widgets you would have
had to add code in a non modular way. (Talking about arctic here).

Yous should consider keeping those lines of an email you reply to only.
(Eg ctrl-sthift-end entf will delete the quoted tail of the mail)

The authors of haxball.com wrote their own gui library AFAIK. There must
have been a reason.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org




--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Using Opera's revoluti

 



--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org




--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org

 


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

Trevor Burton
I MUCH prefer RL over PMC

but i do remember hearing from someone about it's poorer performance on mobile platforms due to its reliance on reflection. i didn't run the tests myself so can't comment and i can't remember off the top of my head who mentioned it but i do remember thinking they were a reliable source.

Just a point to mention, really, but from a development point of view RobotLegs just makes life soooo much easier

T

On Fri, Jul 15, 2011 at 11:58 AM, Lee Sylvester <[hidden email]> wrote:

I’ve used it lots.  It’s a great MVC, but it’s bloated.  RobotLegs is by far a better MVC.

 

Lee

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Lindelöf
Sent: 15 July 2011 09:48
To: The haXe compiler list
Subject: Re: [haXe] future of haxe

 

anyone else using puremvc? I'm just starting to learn it, reading tuts, and have coded some simple boilerplate template with textmate so I can setup a project with a click.

I'm going all in on puremvc, I've had "my own" interp of MVC but, I think it's better to use something so wide spread.


-- 
Martin Lindelöf
www.medborgarplatsen.com

On Thursday, July 14, 2011 at 6:56 PM, Baluta Cristian wrote:

I don't know how the discussion got here, but I have skins :P . I create a skin class with some predefinite fields and i pass it to the scrollbar, button, slider or whatever, which will display and arrange them as needed. 

 

new Button(x, y, new Skin("label", colors));

 

On Thu, Jul 14, 2011 at 7:01 PM, Joshua Granick <[hidden email]> wrote:

When I work in Flash, I work like this...


1.) Create an "important" object, like a sliding panel

2.) Export the MovieClip as a class, usually named something like "SlidingPanel_Display"

3.) Create a new class that extends SlidingPanel_Display, and customize the thing with custom functionality

4.) "replaceObject (Display.SlidingPanel, new SuperDuperSlidingPanel ());"



For something like a scrollbar, I don't usually need the objects to be their own classes. I just do something like "new ScrollBarUI (Display.ScrollHandle, Display.ScrollTrack, Display.ScrollUp, Display.ScrollDown);" and manage it like an object. However, in cases where I really want to have a custom class, I use a format like above -- I never have to compile to replace empty classes.

At runtime, my "important object" is going to be a "dumb" instance -- it looks right, but it doesn't have any of the "super duper" functionality I used to extend it. So once the project begins, I run a replaceObject() script, which removes the plain instance and replaces it with a new instance of my custom class. Since it extends the same object, it looks the same, but now it has the special functionality I am looking for.


If anyone is interested in this approach, I can paste the contents of my replaceObject() script, but basically it copies x, y, alpha, filters, parent, and optionally rounds off the position, so it will sit on even pixels and look a bit sharper.





On Thu, 14 Jul 2011 06:31:48 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:


Yeah we work the sane way. The only "strange" thing you might find is
you have to export each different style (if needed) as a different
class- simply fixed by extending your base with an empty class (this
is for Flash @:bind at least)

On Thursday, July 14, 2011, Joshua Granick <[hidden email]> wrote:

Ah, no... I meant "magic wand," because I have libraries set up for different UI behaviors. It wouldn't be as "magic" if I was writing the behavior myself each time.

For example, the scrollbar takes a scroll handle, scroll track and optionally an up button and down button. Viola, it scrolls and acts like a scrollbar, regardless of the size or shape of the graphics.

Once you have the library in place, going from appearance to full functionality is like Mickey in the Sorcerer's Apprentice, turning mops and buckets into his minions ;)



On Wed, 13 Jul 2011 23:20:08 -0700, Lee Sylvester <[hidden email]> wrote:


I think you mean, "first you create the appearance" ;-) This is my approach also. It makes a lot of sense in a Flash app.  To do it the other way always takes longer, unless you don't care about look and feel.

Lee

Sent from my iPad

On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]> wrote:


I call it the "magic wand" approach


Instead of functionality first, appearance second, like most components, you turn the equation on its head. First you create the functionality (key to most projects) then you "wave the magic wand" to make it come to life with the behavior you want it to have.



On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:


I've never used Flex UI stuff before. I know there's good reasons for it but
there's always things like ASwing or MinimalComps. I know if you're making
RIA then it can be good to use these but generally I find everyone wants
completely different interations and looks so it can be best to simply have,
as stated above, a good library of abstracted class you can use.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" target="_blank">+61 3 8060 5321
_______________________


On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]>wrote:


I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
control, I tend to roll my own there and then.  It's not efficient, but 12
years writing Flash apps means I get it done quickly and exactly as I need
it in any given situation.  One great thing about haXe is, if I want to
avoid rolling my own control, I can wrap an existing Flash control by
externing just those methods I'll interact with.  I can integrate really
complex controls in minutes. The trick is not to go overboard.  Don't extern
everything, just the methods and properties you need.  The rest can remain
black boxed if you want.

Lee



On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:


Hi Fei Yin,

I know that I'm not a flash guru.

aswing: I've had a look at the commit log. And it looked to me that
upstream stalled. That made me wonder .. But you're right. Maybe I
didn't spend enough time on that code.

flex: I didn't manage to use it from HaXe. Even if I did there would
have been the issue about how to include the required classes only.
You can't embed the full code - the result would be too large.

There are various issues. If you want I can try to digg up what others
told me that time.


So ,there already is good GUI library for flash platform in haXe .

Those I had a look at didn't pleasure me at all. They were written for
older flash targets. And in order to support new widgets you would have
had to add code in a non modular way. (Talking about arctic here).

Yous should consider keeping those lines of an email you reply to only.
(Eg ctrl-sthift-end entf will delete the quoted tail of the mail)

The authors of haxball.com wrote their own gui library AFAIK. There must
have been a reason.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org




--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Using Opera's revoluti

 



--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org




--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org

 


--
haXe - an open source web programming language
http://haxe.org



--
---------------------------
Trevor Burton


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: future of haxe

tom rhodes
any news on the haxe robot legs inspired stuff?


On 15 July 2011 13:19, Trevor Burton <[hidden email]> wrote:
I MUCH prefer RL over PMC

but i do remember hearing from someone about it's poorer performance on mobile platforms due to its reliance on reflection. i didn't run the tests myself so can't comment and i can't remember off the top of my head who mentioned it but i do remember thinking they were a reliable source.

Just a point to mention, really, but from a development point of view RobotLegs just makes life soooo much easier

T


On Fri, Jul 15, 2011 at 11:58 AM, Lee Sylvester <[hidden email]> wrote:

I’ve used it lots.  It’s a great MVC, but it’s bloated.  RobotLegs is by far a better MVC.

 

Lee

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Martin Lindelöf
Sent: 15 July 2011 09:48
To: The haXe compiler list
Subject: Re: [haXe] future of haxe

 

anyone else using puremvc? I'm just starting to learn it, reading tuts, and have coded some simple boilerplate template with textmate so I can setup a project with a click.

I'm going all in on puremvc, I've had "my own" interp of MVC but, I think it's better to use something so wide spread.


-- 
Martin Lindelöf
www.medborgarplatsen.com

On Thursday, July 14, 2011 at 6:56 PM, Baluta Cristian wrote:

I don't know how the discussion got here, but I have skins :P . I create a skin class with some predefinite fields and i pass it to the scrollbar, button, slider or whatever, which will display and arrange them as needed. 

 

new Button(x, y, new Skin("label", colors));

 

On Thu, Jul 14, 2011 at 7:01 PM, Joshua Granick <[hidden email]> wrote:

When I work in Flash, I work like this...


1.) Create an "important" object, like a sliding panel

2.) Export the MovieClip as a class, usually named something like "SlidingPanel_Display"

3.) Create a new class that extends SlidingPanel_Display, and customize the thing with custom functionality

4.) "replaceObject (Display.SlidingPanel, new SuperDuperSlidingPanel ());"



For something like a scrollbar, I don't usually need the objects to be their own classes. I just do something like "new ScrollBarUI (Display.ScrollHandle, Display.ScrollTrack, Display.ScrollUp, Display.ScrollDown);" and manage it like an object. However, in cases where I really want to have a custom class, I use a format like above -- I never have to compile to replace empty classes.

At runtime, my "important object" is going to be a "dumb" instance -- it looks right, but it doesn't have any of the "super duper" functionality I used to extend it. So once the project begins, I run a replaceObject() script, which removes the plain instance and replaces it with a new instance of my custom class. Since it extends the same object, it looks the same, but now it has the special functionality I am looking for.


If anyone is interested in this approach, I can paste the contents of my replaceObject() script, but basically it copies x, y, alpha, filters, parent, and optionally rounds off the position, so it will sit on even pixels and look a bit sharper.





On Thu, 14 Jul 2011 06:31:48 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:


Yeah we work the sane way. The only "strange" thing you might find is
you have to export each different style (if needed) as a different
class- simply fixed by extending your base with an empty class (this
is for Flash @:bind at least)

On Thursday, July 14, 2011, Joshua Granick <[hidden email]> wrote:

Ah, no... I meant "magic wand," because I have libraries set up for different UI behaviors. It wouldn't be as "magic" if I was writing the behavior myself each time.

For example, the scrollbar takes a scroll handle, scroll track and optionally an up button and down button. Viola, it scrolls and acts like a scrollbar, regardless of the size or shape of the graphics.

Once you have the library in place, going from appearance to full functionality is like Mickey in the Sorcerer's Apprentice, turning mops and buckets into his minions ;)



On Wed, 13 Jul 2011 23:20:08 -0700, Lee Sylvester <[hidden email]> wrote:


I think you mean, "first you create the appearance" ;-) This is my approach also. It makes a lot of sense in a Flash app.  To do it the other way always takes longer, unless you don't care about look and feel.

Lee

Sent from my iPad

On 14 Jul 2011, at 06:27, "Joshua Granick" <[hidden email]> wrote:


I call it the "magic wand" approach


Instead of functionality first, appearance second, like most components, you turn the equation on its head. First you create the functionality (key to most projects) then you "wave the magic wand" to make it come to life with the behavior you want it to have.



On Wed, 13 Jul 2011 21:05:59 -0700, Tarwin Stroh-Spijer <[hidden email]> wrote:


I've never used Flex UI stuff before. I know there's good reasons for it but
there's always things like ASwing or MinimalComps. I know if you're making
RIA then it can be good to use these but generally I find everyone wants
completely different interations and looks so it can be best to simply have,
as stated above, a good library of abstracted class you can use.


Tarwin Stroh-Spijer
_______________________

Touch My Pixel
http://www.touchmypixel.com/
phone: <a href="tel:%2B61%203%208060%205321" target="_blank">+61 3 8060 5321
_______________________


On Thu, Jul 14, 2011 at 8:38 AM, Lee Sylvester <[hidden email]>wrote:


I do a lot of GUI app dev for Flash in haXe.  Whenever I need a GUI
control, I tend to roll my own there and then.  It's not efficient, but 12
years writing Flash apps means I get it done quickly and exactly as I need
it in any given situation.  One great thing about haXe is, if I want to
avoid rolling my own control, I can wrap an existing Flash control by
externing just those methods I'll interact with.  I can integrate really
complex controls in minutes. The trick is not to go overboard.  Don't extern
everything, just the methods and properties you need.  The rest can remain
black boxed if you want.

Lee



On 13 Jul 2011, at 23:26, Marc Weber <[hidden email]> wrote:


Hi Fei Yin,

I know that I'm not a flash guru.

aswing: I've had a look at the commit log. And it looked to me that
upstream stalled. That made me wonder .. But you're right. Maybe I
didn't spend enough time on that code.

flex: I didn't manage to use it from HaXe. Even if I did there would
have been the issue about how to include the required classes only.
You can't embed the full code - the result would be too large.

There are various issues. If you want I can try to digg up what others
told me that time.


So ,there already is good GUI library for flash platform in haXe .

Those I had a look at didn't pleasure me at all. They were written for
older flash targets. And in order to support new widgets you would have
had to add code in a non modular way. (Talking about arctic here).

Yous should consider keeping those lines of an email you reply to only.
(Eg ctrl-sthift-end entf will delete the quoted tail of the mail)

The authors of haxball.com wrote their own gui library AFAIK. There must
have been a reason.

Marc Weber

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org




--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org



--
Using Opera's revoluti

 



--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org




--
Băluță Cristian
http://ralcr.com
http://imagin.ro

--
haXe - an open source web programming language
http://haxe.org

 


--
haXe - an open source web programming language
http://haxe.org



--
---------------------------
Trevor Burton


--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
12