31–40 of 44 posts
How is the ui problem is usually tackled with haxe? I tried googling a bit, but didn't come up with a conclusive answer.
Cross-platform tools often have a single user interface that tends to look foreign on every platform (sencha touch), or they force you to code a different ui for every targeted platform (titanium?). How is the ui problem is usually tackled with haxe? I tried googling a bit, but didn't come up with a conclusive answer.
Many of the companies using Haxe are game studios, and so they just invent their own UI and it doesn't matter if it doesn't feel "native".
In terms of the two approaches you mentioned: both can be used. There are various projects to "reinvent" a basic UI toolkit that works on NME, the cross platform graphics layer. These libraries would do what you mentioned first - have a consistent experience across platforms, but one that is foreign and probably not as polished. No libraries have really gained a huge amount of support for this yet, though it seems there are a few trying.
The other approach - integrating with native UI - is also possible using Externs, which link in with an underlying system. I'm not sure how much use this has had. Some iOS features have externs, and on the desktop wxWidgets externs are around so this approach is possible. If you were to do this I guess you'd try to abstract away as many differences as you can, so that you need as little conditional compilation as possible. Not sure who is trying this at the moment.
As I said though, UI toolkits is definitely not a strong point. My main development with Haxe is for JS / HTML, so I just use standard bootstrap / jQuery elements, which feel "web native" I suppose.
Earlier quoted context omitted.
> VMs can have bugs and nuances that aren't captured in their specification So can compilers. Adding the additional translation layer of javac or equivalent increases the potential of being affected by bugs in third-party code. Let P be the probability of encountering a bug in the JVM, and Q be the probability of encountering a bug in javac. If we multiply the complements, (1-Q)x(1-P) we have the probability of final…
> Adding the additional translation layer increases the potential of bugs > the implementation has information that could be used to generate better bytecode These are theoreticals. Let me analogize. Some algorithms have a worst-case big O that is significantly worse than the average case. So even though the algorithm could have very poor performance in certain situations, it's better for the "real-world" cases that…
What do you gain? As far as I can tell, there is only loss.
> the need for flexibility that drives Haxe, and you aren't gaining additional flexibility from bytecode.
Exactly what flexibility does this provide?
Earlier quoted context omitted.
Or advanced anything else for that matter. Cannese is a really bright programmer though; man built a programming language with an interesting runtime, and manages to use them for his one-man game studio. Not bad.
Nicolas "Cannasse" just left his company, I'm not sure what he's up to next. It should be interesting to see.
Cross-platform tools often have a single user interface that tends to look foreign on every platform (sencha touch), or they force you to code a different ui for every targeted platform (titanium?). How is the ui problem is usually tackled with haxe? I tried googling a bit, but didn't come up with a conclusive answer.
The short answer is that Haxe isn't very good here yet. Many of the companies using Haxe are game studios, and so they just invent their own UI and it doesn't matter if it doesn't feel "native". In terms of the two approaches you mentioned: both can be used. There are various projects to "reinvent" a basic UI toolkit that works on NME, the cross platform graphics layer. These libraries would do what you mentioned fir…
Earlier quoted context omitted.
As a student of compilers myself, it's my understanding that producing bytecode is as easy as--if not vastly easier than--producing code in another language, and that this is particularly true when the target language is high-level. The only exception to this I can envision is when the source language maps easily and completely to every single target language, in which case the source language must be the least commo…
> it's my understanding that producing bytecode is as easy as--if not vastly easier than--producing code in another language Maybe true for unoptimized code. However, Java and C# compilers have received years of work to make efficient use of their respective VMs; standing on their shoulders makes some sense.
The documentation looks absolutely horrible. I can find in many ways how it can compile to multiple targets, but no easy way to find out how it actually looks like. Any "hello world" example that does not contain language reference? Maybe "a gentle introduction to haxe" before "compiler metadata"?
Cross-platform tools often have a single user interface that tends to look foreign on every platform (sencha touch), or they force you to code a different ui for every targeted platform (titanium?). How is the ui problem is usually tackled with haxe? I tried googling a bit, but didn't come up with a conclusive answer.
Earlier quoted context omitted.
Nicolas "Cannasse" just left his company, I'm not sure what he's up to next. It should be interesting to see.
Where did you hear/read this?