Package: htag
HTag : "H(tml)Tag"A new python library to create UI (or UI toolkit), which render nativly in anything which can renderhtml/js/css.
Thoses can be a browser, a pywebview, an android/apk, or anything based on cef, depending on anhtag runner!
As it's based on html/js rendering: you can easily mix powerful JS libs with powerful PY3 libs : and make powerful python apps !For adesktop app:You can use thePyWebView runner, which will run the UI in a pywebview containerYou can use theChromeApp runner, which will run the UI in a local chrome in "app mode" (headless).For aandroid app: You can use theAndroidApp runner, which will run the UI in a kiwi webview thru tornado webserver, and can be embedded in an apk (recipes)For apyscript app: you can use thePyScript runner, which will run completly in client sideFor aweb app: You can use thehtagweb.But yes … the promise is here :it's a GUI toolkit for building "beautiful" applications for mobile, web, and desktop from a single codebase.DOCUMENTATIONDEMO/TUTORIALChangelogAvailable on pypi.orgAnnouncement on reddit (22/07/14)Well tested:Pytests on core at 99%RealSelenium TESTS in github CI/CDTo have a lookhtag.glitch.me: A htag app, hosted on glitch.com, running withhtagweb. Many examples from simpler to complex ones, in tutorial spirit.pyscript/demo: A htag app in a simple html page, running withpyscript runner. Many examples in a REPL mode (you can try/edit/run them). (ONLY HTML needed)ROADMAP to 1.0.0IMPORTANT: TheAndroidApp runnercould/would disappear from the main htag package (so nested dependancies kivy & co, too). Because there is another/clever/better way to make an androidapp, using buildozer/p4a with its 'webview' bootstrap (but need to clarify that everywhere where htag/android is involved ;-( )the "0.60.x" is the pre-version before 1.0.0 (htag core will not change anymore). I need to fix some runners before.tests testssetup minimal docs, withthat;-)top level api could change (Tag() -> create a Tag, Tag.mytag() -> create a TagBase ... can be a little bit ambiguous)manage "query params" from url to initialize Tags/routesI don't really like the current way to generate js in interaction : need to found something more solid.the current way to initiate the statics is odd (only on real (embedded) Tag's) : should find a better way (static like gtag ?!)and more technicals :~~better js try/catch to sort js/py error + try/catch on http com error (for thoses which kill session webhttp/pye) ~~getStateImage is non sense coz it's str'ing (why not returning the str ?!)mix the Tag.initwith the old system (like this: it's unmaintable)introduce a virtual tag/placeholderDISPLAY a warning (or exception in STRICT_MODE), when a render method use a "tag creation" (ex: Tag.div("hello")), because it will always be rendered !!!!! -> bad habitsrename "tag" to "self" for js statements (keep the twos, for compatibility reasons)Make it possibles -> NOT POSSIBLE currently ... abandonned ;-)self.js = self.bind( self.starting , b'window.innerWidth') # doesn't work currentlyself.js = self.bind.starting( b'window.innerWidth' ) # work (only reason to keep the "old form")perhapsself( js_statement)->self.call( js_statement )... less confusing !thus, to avoidself( self.bind.method(*a,**k) ), you can writeself.call.<method>( *a,**k )HistoryAt the beginning, there wasguy, which was/is the same concept aspython-eel, but more advanced.
One day, I've discoveredremi, and asked my self, if it could be done in aguy way. The POC was very good, so I released
a version of it, namedgtag. It worked well despite some drawbacks, but was too difficult to maintain. So I decided to rewrite all
from scratch, while staying away fromguy(to separate,renderingandrunners)... andhtagwas born. The codebase is very short, concepts are better implemented, and it's very easy to maintain.