android - Pros and Cons for Haxe and Kivy -


i'm looking develop application ios, android, windows phone , desktop no matter if it's web or standalone. have experience haxe + nme or kivy can share in detail?

i've been looking can deploy platforms , these 2 best options seem have found. i'm not looking make game though. it's more app lot of touch listeners on images. touch image hide this, create that, , lot of math behind scenes. need pathfinding library pretty engines i've worked in had a-star pathfinding library. need slideview library users can swap pages on smartphone desktop. information can share on following topic appreciated. in advance reading , provided. sorry trouble

long time haxe user here, though use haxe web-app projects, not nme much. until nme's main focus has been (far , away) gaming. there has been few recent efforts create nice ui toolkits building on nme's cross platform strengths:

https://github.com/realyuniquename/stablexui - demo (works on html5, flash, native desktop&mobile)
https://github.com/ianharrigan/haxeui

but recent additions, if you're looking tried , tested solution kivy (never heard of before, looks cool!) looks has bit more maturity , bit more polish going it.

in terms of performance , overall reliability, haxe/nme great, it's getting native-feeling ui widgets pain point. other though, it's amazing language work :) python's pretty though... each own!

at time of writing, people experimenting using native ui (there talk @ upcoming conference objective c target, , java , c# targets becoming more mature, there 3 main mobile platforms covered) option if want native ui components, though it's not ready yet, me hoping might become reality on next year or :)

good luck project either way! if choose go haxe/nme, sure ask questions (either here, nme forums, or haxe mailing list) people can on way.


Comments

Post a Comment

Popular posts from this blog

linux - xterm copying to CLIPBOARD using copy-selection causes automatic updating of CLIPBOARD upon mouse selection -

i've tried various ways coerce xterm (versions 285 , 292) copy selection clipboard clipboard whenever press ctrl-shift-c. promising way far has been, in ~/.xresources, put this: xterm*vt100.translations: #override \ ctrl shift <keypress> c: copy-selection(clipboard) \n\ ctrl shift <keypress> v: insert-selection(clipboard) ctrl-shift-v works perfectly, copying has nuance... if restart xterm, highlighting text puts things in primary clipboard; expected, proper, default behavior. if hit ctrl-shift-c, copies current selection clipboard clipboard. the bug, however, if highlight text after first time pressed ctrl-shift-c, you'll see highlighting copies both primary and clipboard. cannot figure out how stop xterm updating clipboard upon selection... , doesn't make sense me in first place. i said, @ specific point in time, copy selection clipboard... yet starts updating automatically upon selection after doing once... anyone have workaround...
Read more

c++ - qgraphicsview horizontal scrolling always has a vertical delta -

Image
i've subclassed qgraphicsview custom canvas used in cad application. i've reimplemented qgraphicsview::wheelevent check keyboard modifiers control key and, if control key pressed, zoom. i'm trying implement horizontal scroll when user holds shift , uses wheel. the problem i'm having horizontal scrolling always scrolls 0.279. not huge problem, hugely annoying , points else being wrong. so, here questions: is right way implement horizontal scrolling? if not, is? how eliminate delta of 0.279? thanks in advance. code , sample output below void myview::zoom(int delta) { double factor = pow(1.2, delta/abs(delta)); this->scale(factor, factor); } void myview::scrollhorizontal(int level) { qpointf center = maptoscene(viewport()->rect().center()); qdebug() << "center: " << center.x() << ", " << center.y(); centeron(qpointf(center.x() - level, center.y())); } void myview::wheelevent(qwheeleve...
Read more