|Welcome !||Nicolas Cannasse||5/8/12 2:16 AM|
Welcome to [haxenext] group, a place where we will discuss how to bring
Haxe to the next level.
As I explained in my invitation this is an open group, feel free to
invite anybody interested in helping in making Haxe grow and become more
popular. We are especially looking for people investing in Haxe with a
In order to get started I have a simple question to ask you :
What would be for you the top 3 things that we need to fix/improve
to make Haxe more popular ? (in order of decreasing importance)
Please be very precise while answering this question. For instance
"improving the website" is bit too much abstract.
You're welcome also to provide an actual action-plan proposal that we
could follow in order to make it happen.
Based on your answers we will discuss what needs to be done first, and how.
Thank you !
|Re: Welcome !||Franco Ponticelli||5/8/12 6:10 AM|
|Re: Welcome !||Cauê Waneck||5/8/12 10:26 PM|
What would be for you the top 3 things that we need to fix/improve
Okay, you asked for detailed ;)
For beginners / developers:
Site communication strategies
New targets strategies
|Re: [haxenext] Re: Welcome !||Cauê Waneck||5/8/12 10:30 PM|
Maybe we already have that? Isn't ASWing running on NME? Maybe it's running on Jeash too?
IMHO It would be great to have something close to ASWing, since the Flash guys are used to it, the Java guys are used to it (by the way, it seems to me that the API is close enough to be compatible with Java almost out-of-the-box), and if we get it to run well on NME/Jeash, we've got a cross-target way to do GUI!
|Re: Welcome !||Cauê Waneck||5/8/12 10:34 PM|
We could call this section either "Open source" or "Never gonna let you go!"
|Re: [haxenext] Re: Welcome !||elsassph||5/9/12 2:22 AM|
I think this point ("you can't shut haxe down") could actually be a weakness unless you have an official, strong and opinionated group of maintainers. Which haxe doesn't really have for now.
A recurring question is about using SWCs and JS libraries. Flash and JS are all about libraries and interop (assimilate!) is what really allows people to switch to haxe.
- for AS3 it should be highlighted very early in the doc (both for SWF and NME),
- for JS there's a real need for a solution somewhat matching the simplicity of "get a JS lib, drop and use in the project" (porting JS libraries to haxe is NOT a solution imho).
On a related note people should stop porting AS3/JS code to haxe unless they actually plan to maintain their port forever. haxelib is nice but too much stuff here seem half backed, not maintained or compete with other ports: it needs some kind of official curation work.
Finally as a JS dev myself, it was quite frustrating to use haxe; this lang is pretty much anti-JS in every possible ways, and figuring the right way to do the usual "all untyped" way of JS is hard. BTW in regard to the recent discussion about events, the doc on haxe.org seems a bit misleading: http://haxe.org/doc/js/events - no word about automatic function closures and, to add to the confusion, the page is suggesting Distill as some kind of officially-supported/recommended event binding solution.
|Re: [haxenext] Re: Welcome !||Cauê Waneck||5/9/12 4:50 AM|
Well, I think you're right, it doesn't belong there. But anyhow our PR should handle this kind of thought and make an answer for it. There is some belief that the whole Haxe project depends on Nicolas, and it's not like that. First of all, there are more devs working on the Haxe code base than Nicolas; Also, working with Haxe actually makes you less vulnerable to possible technology changes than the opposite. The last good example we have is Adobe with Flash, or Oracle with Java (which didn't give up, but many Java devs are migrating away from the platform).
The code being open-source is an extra security in that sense.
That's also a good point. Use libraries from Flash, JS, Java and C# natively!
That would be cool, but it would be a lot of work, IMHO, specially to extract types from it.
|Re: [haxenext] Re: Welcome !||elsassph||5/9/12 6:28 AM|
The point is that I'm suggesting that haxe.org would present "people behind haxe", which means some people should decide to stand up for haxe as official maintainers (with suppleants preferably) for the various aspects of haxe ecosystem. This group would look as (if not more) serious as any company-supported technology. This is probably not an easy/light task but I believe this is needed eventually. Also those people would do some curation in their field to voice how things should be done (but you can do your way if you know more).
One point that needs doc is casting I think. There's a quick mention in http://haxe.org/ref/Dynamic but I believe it would be worth a full page with many samples where it's meaningful. It was really bothering me until I went to use unsafe casting most of the time, thank you.
Now "selling" haxe to JS devs requires to let go some control. JS devs are used to work in an untyped world and being too strict adds a lot of friction and confusion. For instance I believe the compiler could only issue warnings (unless requiring "strict typing") for JS externs. In a related note, in an era of jQuery-like libraries, stdjs is probably too impressive for newcomers as it basically requires people to have read the W3C specs (ie. 1% of JS devs).
That said there are ways to (approximately) type JS libraries:
- JS Doc:
- Google Closure (based on JS doc):
I believe for JS externs the compiler could only issue warnings (unless specifying some "force strict typing" directive). JS devs are used to work in an untyped world and being too strict adds a lot of friction and confusion.
Oh and haxe-js should really highlight the code mapping stuff.
|Re: Welcome !||Peter Halacsy||5/9/12 12:43 PM|
my top things
is this really for multiplatform? or a safe platform like .net or java? who are our competitors? who are our target groups
find the strategy
2. some collaboration policies
is this a very democratic community? who makes the decision? is this design by committee?
3. top priority projects based on #1 and #2
if we are the competitor of java, then we should have project compete with scala and hadoop
if it's a multiplatform tool then we need to work on nme
if it's a type safe web language then we need gwt like stuff
so I would like the decision makers set the priorities for a year. And define projects.
sorry these are not features etc, but I believe having a common goal, shared value and clear strategy are the most important
|Re: [haxenext] Re: Welcome !||Nicolas Cannasse||5/9/12 2:54 PM|
> 1.position haxeThis is indeed very important. So far Haxe can make... everything. And
trying to be everything is a good way to become nothing :)
Haxe have many different usages, such as :
- NME : targeted at mobile games with an emphasis on performances and
crossplatformability. Strong technical aspects, but I think still very
far in terms of getting-started/documentation/overall workflow compared
to competing frameworks
- JS apps : OO + flexible typing greatly help building JS apps "in the
large", help with teams, maintainability, scalability. OTOH the
traditional JS world is more about dynamically typing. Thanks to
overloads we can now "speak JS" better (such as JQuery) but it will
still be hard to convince JS natives to jump on board. Much more easy
for people coming from Java/AS3 or other structured languages.
- Flash dev : a lot of people come from here, Haxe being better and more
performant than AS3. That's however not enough to bring the masses,
unless we also sell them HTML5/mobile compatibility (with NME). Still
focused on gaming, we don't have something like Flex.
- Web dev : not that much used compared to others, but we have strong
selling points with SPOD for ORM, Temploc/Erazor for templates. Still we
don't have a complete standard customizable framework well documented
such as RubyOnRails.
- Interoperability : the ability to use the same language on both client
and server on both flash/js, etc. is quite unique. It will surely help
people to move 100% Haxe but I guess it's a hard selling point for a
I guess it depends which decisions we're talking about. As for the
language itself, I will keep the veto in order to guarantee that it does
not become bloated or get some incompatible features.
However we've been opening up the development much more in the past year
and we have new compiler contributors such as Bruno (JS modern and
source mapping), Caue (C#/Java) and Simon (macros and other compiler
I guess we are on a nice road to increase the contributors. We've been
discussing GitHub at some point but I still think that might make too
many people keep their own fork with their own changes, which is not the
best for a common language which require more stability.
As for the other decisions, so far we have not any process since we
don't have an official body either. I'm fine with something much more
The question I have here, is what would be the exact impact of such
decisions ? For instance let's say we decide that building a
crossplatform IDE is the best strategical move. Who actually write it ?
Does companies give some time or money for it ? Do we have enough people
involved for it right now ?
Having a strategy is very important, but we need also to ensure that we
have ways to apply it in practice.
|Re: Welcome !||misprintt||5/10/12 5:26 PM|
My top three are:
1. Reduce barriers for JS developers to get on board
2. Overhaul Haxelib (popularity/featured libs, best practise guidelines, specific platform/haxe version compliance)
3. Make working with native code as seamless (and friendly as possible)
1. Reduce barrier for JS developers
2. Overhaul Haxelib
It's already been mentioned that Haxelib is littered with undocumented, unsupported and sometimes misleading libraries.
It takes a lot of time for developers to sort through and find appropriate libraries – many people end up on the mailing list looking for support/clarification on a library, many developers end up reinventing their own solution to existing problems (out of ignorance or frustration). Furthermore, every library represents the idiosyncratic conventions of the individual developer – often this clashes with user's own conventions and other libraries (IMO a big factor in the 'reinvent the wheel' mentality)
This all ends up reinforcing a common negative perception of open source platforms – immature, fractured and unreliable ecosystem
3. Working with native should be as easy as possible.
I feel that it is important that 'leveraging native' is an integral part of Haxe's value proposition.
This is applicable across all targets - there is so much existing code out there in native languages that doesn't need to be reinvented/ported. Maintaining externs for large native APIs adds an overhead when those APIs are constantly evolving.
Anything we can do to make this more automated, or more forgiving is a good thing.
Some ideas around this:
|Re: [haxenext] Re: Welcome !||misprintt||5/10/12 5:36 PM|
I believe the benefits of moving to GitHub greatly out-way the risks of fragmentation.
We want to encourage contribution - and this provides an easy, safe, controlled way to do so. There will always be the occasional developer who wants to go down their own path, but most want to see the platform grow stronger.
|Re: [haxenext] Re: Welcome !||Peter Halacsy||5/10/12 11:26 PM|
On Fri, May 11, 2012 at 2:26 AM, misprintt <domdel...@gmail.com> wrote:
although I like this project this is a very good example of having no strategy. WHY this projects and why not 3 other? Is this the right for the bright future?
|Re: [haxenext] Re: Welcome !||Peter Halacsy||5/10/12 11:30 PM|
On Wed, May 9, 2012 at 11:54 PM, Nicolas Cannasse <ncan...@motion-twin.com> wrote:
basically I like this.
this is like mono / .net / java. No?
today the website says: haxe is a multiplatform. But if it's not the key advantage than we should reposition
I think we can do at least 2 things. Both are kinda focusing
1. we tell everyone in the community that flash ide is the most important. The best people doesn't work on other projects. We ask everyone to contribute. We focus/motivate the community
2. we raise money for the project. Companies would love this as the project is accountable. Prezi give $50K and if there is no ide in 6 month won't give more money anymore.
|Re: [haxenext] Re: Welcome !||elsassph||5/11/12 1:27 AM|
I'm not convinced by a crossplatform haxe IDE project:
- from scratch, would be a many years project with uncertain outcome,
- based on an existing IDE: why not, but remember ASDT? as soon as FDT appeared with kick-ass AS2 support the project died.
User adoption will drive commercial IDEs development - I think IntelliJ and FDT are starting to measure they have a market here and the best way to push them to improve is to buy licenses.
User adoption is driven by haxe being an answer to a very practical, immediate, need:
- cross-mobile dev: NME (in good way, needs polishing),
- Flash-like JS: haxe-js (needs evangelists/curation, doc, samples, easier/better externs for Easel/Sencha/etc.),
and haxe's problem is friction for newcomers,
- RoR-like: needs an official, complete, ready to use, framework and samples.
IMHO Flash target and cross-platform aspects of haxe are low hanging fruits for people *already sold* to haxe.
Peter, if a company is ready to invest for specific features why not contract directly with people to do it?
BTW Nicolas, I'm available to develop HSS support in FlashDevelop ;)
|Re: [haxenext] Re: Welcome !||Peter Halacsy||5/11/12 1:35 AM|
On Fri, May 11, 2012 at 10:27 AM, Philippe Elsass <philipp...@gmail.com> wrote:I'm not convinced by a crossplatform haxe IDE project:
my email and thread were not about ide but about the need of strategy and roadmap based on strategy
|Re: [haxenext] Re: Welcome !||elsassph||5/11/12 2:46 AM|
Well that's why I think the strategy is to capture immediate needs: mobile and Flash>JS Flashers/Flexers reconversion.
But in both cases what would be the ROI for companies to invest?
|Re: [haxenext] Re: Welcome !||Peter Halacsy||5/11/12 3:21 AM|
On Fri, May 11, 2012 at 11:46 AM, Philippe Elsass <philipp...@gmail.com> wrote:Well that's why I think the strategy is to capture immediate needs: mobile and Flash>JS Flashers/Flexers reconversion.
first: what do you need to do?
|Re: Welcome !||e-cat||5/30/12 9:04 AM|
On Tuesday, May 8, 2012 12:16:50 PM UTC+3, Nicolas Cannasse wrote:
I have been following haXe development for several years now, mostly on #haxe @ freenode.net, and in these years it has matured from an exotic language to my next tool of choice.
There's just one (1) top thing that we desperately need to improve, and this is documentation. For example, I tried to play a little with haxe.web.Dispatch, and the documentation on the site is not missing or incomplete - it is misleading. Functions it mentions are working differently than expected, features are missing or working differently. I understand, that the reason for this is the rapid development the platform is undergoing, and this is a good thing - but we absolutely need to have the documentation, and, most importantly, working examples stay up to date. One can't properly grok complex concepts like templates and haxe's enums and macros and reflection without good examples.
The rest is, well, nice to have. A good widget/controls library for NME, that would allow not only games, but applications development - and applications need tables, buttons, scroll bars and entry fields, which currently have to be hand-drawn. More databases support. Java or .net target. But nothing compares to good, comprehensive tutorials on how to implement those things.
I will track my progress as I explore the intricacies of this platform and will attempt to write down some notes and examples in the hope to provide this much needed aspect.
As to the format - despite niceties of wiki-like engines, great examples of working documentation projects are Microsoft's MSDN library and Adobe's Flash documentation.
|Re: Welcome !||Frank Bos||5/30/12 2:34 PM|
I also agree that number one priority is Documentation for Haxe. Microsoft's MSDN is amazing for languages that support overloading but for non-overloading languages like Haxe the as3 documentation is better. Adobe has documentation + examples for the most used classes. Check for example the docs on TextField ( http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/text/TextField.html ).
Haxe nme also lacks on this point. It is an amazing framework and tool to work cross platform. The problem is that most documentation can be found in the code itself. The people behind Haxe NME did an amazing job trying to mirror the air/flash api's but on some points it is lacking documentation on missing functionality.
|Documentation (Was: Welcome !)||Nicolas Cannasse||5/30/12 2:42 PM|
I agree that documentation is important, but it's also somehow hard to
do : library/compiler developers are usually to busy to write it, and
are not maybe the best for it since they know already things too much
well and are not maybe the best "teachers".
Does anyone here have an idea how we could actually make a better
documentation - in terms of practical process ? If that needs some
funding, I guess we can make it happen once the Foundation is setup.
|Re: Documentation (Was: Welcome !)||Frank Bos||5/30/12 2:47 PM|
I guess you need some people dedicated to writing documentation like
Adobe has several language evangalist only this will cost some money :
(. If everything works out I am graduated in a few weeks and will have
some free spare time maybe I could write documentation a few hours a
week will keep in touch.
On May 30, 11:42 pm, Nicolas Cannasse <ncanna...@motion-twin.com>
> Le 30/05/2012 23:34, Frank Bos a écrit :> >http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/fl...
|Re: [haxenext] Re: Documentation (Was: Welcome !)||Nicolas Cannasse||5/30/12 2:54 PM|
Le 30/05/2012 23:47, Frank Bos a �crit :
> I guess you need some people dedicated to writing documentation likeAn Haxe Evangelist program might be interesting to put together. Do
somebody have an idea what kind of things Adobe require and which kind
of compensation evangelist get in return ?
|Re: [haxenext] Documentation (Was: Welcome !)||raould||5/30/12 4:45 PM|
On Wed, May 30, 2012 at 2:42 PM, Nicolas Cannassewhile i love the idea of real docs, i also guess there isn't much in
the way of resources / people / money / time to dedicate to doc making
and maintenance. so i'd say that personally i'd rather have really
well fleshed-out tests. unit and integration. that would give us
samples, and would help overall quality.
|Re: [haxenext] Documentation (Was: Welcome !)||singmajesty||5/30/12 7:56 PM|
Documentation is valuable. Samples, recipes and blog posts are also a form
of documentation which can help provide results quickly. Thorough
documentation takes a lot of time, but in the end is valuable. NME could
use a lot of documentation, especially for introducing the concepts from
Flash we may take for granted, such as the display list, events and other
aspects of the API.
I agree that you ideally want teachers -- these should be people who are
experienced in the topic, but are also able to turn around and share that
knowledge with others. The best kind of teachers, in my opinion, are those
who have a foot in both sides of the subject. They are knowledgeable
enough to provide clear "best practices" and insight on the vital
knowledge required to use the language or framework. However, they
obviously need time to spend writing blog posts, samples and
documentation, and should (hopefully!) enjoy their time while they do so..
I think there are two kinds of documentation. You need "Get Started"
material to launch developers into full working samples of various
functionality, but then you also need the comprehensive material (the
encyclopedia of sorts) that really covers everything.
I have been thinking about this subject, and have decided that the best
approach to the "dictionary" style documentation is to generate it from
the code. This would be a matter of time to markup comments throughout
each class, but also put a priority on generating readable, accessible
documentation using haxedoc, chxdoc or whichever library is used to create
We still need to be able to support inline examples, match documentation
for method parameters, create nicer, easier to navigate and read
templates, and other aspects on the technical end to support
dictionary-style documentation that's worth reading.
|Re: [haxenext] Documentation (Was: Welcome !)||Jason O'Neil||5/30/12 8:07 PM|
For the "dictionary" style documentation I think in-code documentation
is definitely the easiest to maintain and keep up to date and so I
would like to see this path taken.
The Xml output haxe generates (and haxedoc uses) could be passed in a
more useful way. A few ideas:
* Understanding basic Javadoc syntax, so we can style parameter
* Passing comments as Markdown, so we can style, add links, add code
If we allowed the in-code documentation to be more expressive, as well
as comments on the API page (now enabled for standard library on
haxe.org) we could start getting a more thorough documentation. I also
think any improvements we make for documenting the standard API should
be available to haxelib projects that upload their XML file.
TLDR: I'm all for in-code documentation + comments.
On Thu 31 May 2012 10:56:37 WST, Joshua Granick wrote:
> Documentation is valuable. Samples, recipes and blog posts are also a
> form of documentation which can help provide results quickly. Thorough
> documentation takes a lot of time, but in the end is valuable. NME
> could use a lot of documentation, especially for introducing the
> concepts from Flash we may take for granted, such as the display list,
> events and other aspects of the API.
> I agree that you ideally want teachers -- these should be people who
> are experienced in the topic, but are also able to turn around and
> share that knowledge with others. The best kind of teachers, in my
> opinion, are those who have a foot in both sides of the subject. They
> are knowledgeable enough to provide clear "best practices" and insight
> on the vital knowledge required to use the language or framework.
> However, they obviously need time to spend writing blog posts, samples
> and documentation, and should (hopefully!) enjoy their time while they
> do so..
> I think there are two kinds of documentation. You need "Get Started"
> material to launch developers into full working samples of various
> functionality, but then you also need the comprehensive material (the
> encyclopedia of sorts) that really covers everything.
> I have been thinking about this subject, and have decided that the
> best approach to the "dictionary" style documentation is to generate
> it from the code. This would be a matter of time to markup comments
> throughout each class, but also put a priority on generating readable,
> accessible documentation using haxedoc, chxdoc or whichever library is
> used to create the output.
> We still need to be able to support inline examples, match
> documentation for method parameters, create nicer, easier to navigate
> and read templates, and other aspects on the technical end to support
> dictionary-style documentation that's worth reading.
> On Wed, 30 May 2012 14:42:39 -0700, Nicolas Cannasse
> <ncan...@motion-twin.com> wrote:
>> Le 30/05/2012 23:34, Frank Bos a écrit :
>>> I also agree that number one priority is Documentation for Haxe.
>>> Microsoft's MSDN is amazing for languages that support overloading but
>>> for non-overloading languages like Haxe the as3 documentation is
>>> Adobe has documentation + examples for the most used classes. Check for
>>> example the docs on TextField (
>>> Haxe nme also lacks on this point. It is an amazing framework and tool
>>> to work cross platform. The problem is that most documentation can be
>>> found in the code itself. The people behind Haxe NME did an amazing job
>>> trying to mirror the air/flash api's but on some points it is lacking
>>> documentation on missing functionality.
>> I agree that documentation is important, but it's also somehow hard
>> to do : library/compiler developers are usually to busy to write it,
>> and are not maybe the best for it since they know already things too
>> much well and are not maybe the best "teachers".
>> Does anyone here have an idea how we could actually make a better
>> documentation - in terms of practical process ? If that needs some
>> funding, I guess we can make it happen once the Foundation is setup.
|Re: Welcome !||Tim Keir||5/30/12 9:42 PM|
One area possibly scaring off new adopters is the false positive virus warning from certain common AntiVirus vendors (e.g. Norton). I know it's stated on the download page, but making the user decide to trust an open source community they might not be familiar with yet over a reputable software company (e.g. Symantec) is a tall ask.
I have Norton AV installed on my work computer as part of company policy. In the past disabling the AV while you installed was straight forward but with the 2.09 release (or possibly an AV software update) it not only gave a false positive for the Haxe installer, but after disabling AV and successfully installing it and using Haxe for the rest of the day, upon my next reboot it had silently deleted the haxe.exe as it seemed to have kept track that the "compromised" installer had installed it. After re-installing it and manually whitelisting haxe.exe, neko.exe, etc I was up and running again. Certainly not a smooth experience if this was the first time I had tried Haxe. I've emailed Symantec but I haven't heard back.
Is this false positive issue fixable by a change in the way the installer is set up or is contacting the AV vendors the only solution?
On Tuesday, 8 May 2012 19:16:50 UTC+10, Nicolas Cannasse wrote:
On Tuesday, 8 May 2012 19:16:50 UTC+10, Nicolas Cannasse wrote:
On Tuesday, 8 May 2012 19:16:50 UTC+10, Nicolas Cannasse wrote:
|Re: [haxenext] Re: Welcome !||singmajesty||5/30/12 11:58 PM|
Have you experienced any problems with the NME installer?
|Re: [haxenext] Re: Welcome !||Tim Keir||5/31/12 12:39 AM|
Good point, the NME installer is built upon the Haxe installer isn't it?
I don't believe so, the NME installer exe certainly doesn't trigger any warnings in Norton. I had already white listed C:/Motion-Twin when I installed NME so not sure whether installing without would change anything. I'll give it a go tomorrow at work and let you know.
Have you experienced any problems with the NME installer?
|Re: [haxenext] Re: Welcome !||Nicolas Cannasse||5/31/12 1:19 AM|
Le 31/05/2012 06:42, Tim Keir a écrit :I've removed the two warnings about virus warning and the other about
installation path. I think Joshua 2.09 installer is fixing both issues
which were only related to the old installer.
|Re: [haxenext] Documentation (Was: Welcome !)||Skial Bainn||5/31/12 1:38 AM|
I wrote Hocco which is a port of Docco, which allows you to write github style markdown. Take a look at the generated output for Hocco's twin source. Hocco was actually very easy and quick to write, which surprised me.
It uses pygments and markdown2 python libraries on google app engine, as I wanted everything to be contained in the library.
It could/should be updated to use either Jason's mdown lib or Nicolas's markaxe lib, which would get rid of the markdown2 server. It hasn't yet been tested against the latest haxe release, so it might not work any more.
But something better can easily be built, so Hocco should be seen as a proof of concept.
|Re: [haxenext] Documentation (Was: Welcome !)||Nicolas Cannasse||5/31/12 1:42 AM|
Le 31/05/2012 05:07, Jason O'Neil a écrit :Check http://haxe.org/manual/documentation, and in particular chxDoc
|Re: Welcome !||Andras Csizmadia||5/31/12 6:09 AM|
"What would be for you the top 3 things that we need to fix/improve0. Background and needs: I'm a senior multimedia developer, mostly i'm creating flash web applications / interactive solutions for online media campaigns.
The interesting thing for me in HaXe is to create RIAs targeting both desktop and mobile browsers, using only one core codebase. So i can compile my software to Flash or HTML5 JS application, and use fallback techniques to solve flash on mobile issues (Thats why NME started me to really dig into the HaXe language).
Also making native mobile/desktop apps and games is an interest. I've some experience with Adobe AIR and i'm not impressed by it's performance in many use cases.
1. "Integrate the brands": Create an organization on GitHub like "Haxe" and put HaXe sources there, also NME sources.
For me it's a bit confusing to think with more brands at once and sell them to my clients (HaXe, NME, Jeash, Neash) so i would consider a name like HaXe SDK ("target any platform natively") which consists of the compiler + official nme framework.
According to this, close obsolete domains and redirect users to a centralized area to be communicate or report bugs (i like haxenme.atlassian.org). Make it more strict for the users where to report bugs, right now there are around 5-10 places where i found issue reports.
(+ Maybe integrate NME installer with Haxe)
2. Impressive examples for the clients. I like:
Of course haxe showcase would be different kind. Ideally every example on every targeted would look like and work as same as its realistic.
Actuate example: https://s3.amazonaws.com/data.tumblr.com/tumblr_lodu03EdFK1qzljg6o1_1280.jpg
3. Big focus on JS HTML5 output, improve Jeash part of NME as fast as possible.
I want some kind of a way to easily implement a complex! design layout (made by a creative guy in .psd format).
My usual workflow with flash:
1. Optimize the psd (flatten and change layers which cannot be imported to Flash IDE)
2. Import psd into flash
3. Structure design object trees, make classes from view pages
4. Compile FLA to SWC
5. Use SWC classes in Flash AS3 only project as a Views
If i want to cross compile a Flash and JS project i want to have some common practice to do this. (Pixel precise design is a standard in many companies).
|Re: Welcome !||Andras Csizmadia||5/31/12 6:41 AM|
FYI, i like this new concept of Flex:
|Re: [haxenext] Re: Welcome !||singmajesty||5/31/12 8:07 AM|
For a long time, the Haxe installer has been written in Neko, and compiled for Windows, Mac and Linux.
The first version of the NME installer was built on the same code, but there were some issues (virus warnings, proxy issues on Mac, incompatibility on Linux) that led to the creation of new, specific installers for each platform.
The NME installer, for a few versions now, has been using the Nullsoft Scriptable Install System, or NSIS, which is the same installer used by FlashDevelop. The Mac installer uses Apple's PackageMaker, and the Linux installer is a bash script.
The current Haxe installer for Windows may be using NSIS, similar to NME. I'm not sure if you've received warnings with the previous version (which is like a console window) or the newer one (which has multiple steps, similar to normal Windows installs)
|Re: Welcome !||airfoil||5/31/12 1:13 PM|
I've been following Haxe on and off for a few years, but over the last 7 months or so I've been actively following development (mainly due to NME). The biggies for me are:
* A standard UI Toolkit/Framework - This is the one thing that's kept kept me from completely adopting Haxe for a UI heavy game that I've been working on. I've written some of the game logic in Haxe and I've really enjoyed it. I started down the path of writing UI widgets that I needed, but I'd rather just write my game. The allure of my app running natively on the desktop and mobile keeps me interested in Haxe and NME, but I'm evaluating other languages/frameworks and at some point I have to stop evaluating and start shipping.
* With respect to documentation, more discussion and examples for macros. I kind of "get it", but I'd really like a deeper understanding of how things work. I learn best by seeing well explained examples and going from there. A cookbook style presentation for macros would be awesome.
* Finally, "Why should I use Haxe?" or "Haxe for $LANGUAGE Programmers" article(s) would be great as well. What are the compelling reasons for using Haxe? As someone who's worked with numerous languages over the years I can see the pros and cons relatively easily. For someone who isn't as experienced it would be great to provide them with compelling reasons for using Haxe. I also agree that Haxe needs some evangelists out front speaking at conferences, making blog posts, and pushing the language to the next level. I've made a few posts on Hacker News and other places trying to spread the word, but I think Haxe needs the "Haxe Guy" that's known for evangelizing the language and tools.
|Re: Welcome !||Philipp Klose||6/4/12 7:06 AM|
In my opinion it would be great to improve these following things:
|Re: [haxenext] Re: Welcome !||Cauê Waneck||6/5/12 5:37 AM|
Cloud9-like Haxe is an awesome idea and would be an awesome project to tackle!
Maybe we could invest on that? I mean, finance its development? I'd be happy to donate money for this project.
|Re: [haxenext] Re: Welcome !||Philipp Klose||6/5/12 8:37 AM|
I already spend a lot of time on researching, checking out the possibilities. It shouldn't be that hard.
My choices would be
Any other suggestions/ideas?
Last time I spend a lot of time with coffee-script and PHP and I am slowly moving back to Haxe as development language. I'm really sick of Gedit as my current Haxe "IDE" so this will happen sooner or later. If there are some resources provided to speed this up I would be very happy about that.
|Re: [haxenext] Re: Welcome !||Franco Ponticelli||6/5/12 8:42 AM|
I agree with your choices except for ExtJS. It is a wonderful library but the changes it requires to the generated JS scare me ... maybe it is irrational.
In any case I think you can cover most of your needs with JQuery UI and the new coming release adds interesting new widgets.
p.s. Reinventing the wheel and do it all Haxe (using Domtools?) is still my first choice ;) ... except for ACE which is too big of a project and too specific to justify a rewriting.
|Re: [haxenext] Re: Welcome !||Philipp Klose||6/5/12 9:16 AM|
Reinventing the wheel is something the Haxe-people are really fond of ;-)
I based my choices on "which would be the fasted way to get something I could work with". I've used ExtJS a few times before (but never in combination with Haxe) and once you figured how things work it is just "write some GUI" instead of "mess with the DOM" which is why I like it. I don't really understand what scares you about it, although you are right most stuff could be done with jQueryUI.
More interesting. What features are required/needed? Maybe we should start some kind of list of what people expect from a Haxe specific GUI!
It started one here: https://gist.github.com/2876010
|Re: [haxenext] Re: Welcome !||Juraj Kirchheim||6/6/12 1:50 AM|
On Tue, Jun 5, 2012 at 5:42 PM, Franco PonticelliMy first choice too. I am actually working on my own wheel when I find
the time and hope to have some results within the coming months.
Still, I think any haxe-based cross-platform solution (even based on
externals to ACE and Ext) would be a huge step forward to better
tooling, since it would allow us to all work together and all benefit
from it. Also I think it's a powerful sign of maturity, if a language
provides a high-quality IDE (which takes time, but getting started is
the first step) written with the language itself, so this might
further help in selling Haxe.