HTag : "H(tml)Tag"
A new python library to create UI (or UI toolkit), which render nativly in anything which can render html/js/css. Thoses can be a browser, a pywebview, an android/apk, or anything based on cef, depending on an htag 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 a desktop app :
- You can use the Runner, which will run the UI in a local chrome in "app mode" (headless).
- You can use the PyWebView runner, which will run the UI in a pywebview container
- For a android app : See htagapk
- For a web app : You can use the htagweb.
- For a html app (think SPA (run in an html context (no python!))):
- you can use the PyScript runner, which will run completly in client side
- you can use the htag for brython, which will run completly in client side
But yes … the promise is here : it's a GUI toolkit for building "beautiful" applications for mobile, web, and desktop from a single codebase.
Announcement on reddit (22/07/14)
Well tested:
- Pytests on core at 99%
- Real Selenium TESTS in github CI/CD every days
To have a look
- htag.glitch.me: A htag app, hosted on glitch.com, running with htagweb. Many examples from simpler to complex ones, in tutorial spirit.
- pyscript/demo: A htag app in a simple html page, running with pyscript runner. Many examples in a REPL mode (you can try/edit/run them). (ONLY HTML needed)
ROADMAP to 1.0.0
- tests tests
- the "0.100.x" version introduce a "new event mechanism" ("ev") : need to find a solution if it will be mandatory for 1.0.0 (don't know yet), to not break my (more than) 200 apps ;-) ... currently both are available (depending of the parameter name)
- the "0.90.x" version is important, because all previous runners (using starlette/uvicorn/tornado) are gone, and are simulated/faked with a new Runner ! So compatibility shouldn't be breaked with htag <0.90 ! But they will be removed in 1.0.
- polish the new Runner Runner and docs !
setup minimal docs, with that ;-)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.init with the old system (like this: it's unmaintable) -
introduce a virtual tag/placeholder -
DISPLAY 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 habits
-
rename "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 )
History
At the beginning, there was guy, which was/is the same concept as python-eel, but more advanced. One day, I've discovered remi, and asked my self, if it could be done in a guy way. The POC was very good, so I released a version of it, named gtag. It worked well despite some drawbacks, but was too difficult to maintain. So I decided to rewrite all from scratch, while staying away from guy (to separate, rendering and runners)... and htag was born. The codebase is very short, concepts are better implemented, and it's very easy to maintain.