On Tue, Dec 18, 2012 at 10:21 AM, Stephen Waterbury <[email protected]> wrote: > > On 12/18/2012 10:55 AM, Lex Berezhny wrote: >> On Tue, Dec 18, 2012 at 10:16 AM, Steve Waterbury >> <[email protected] <mailto:[email protected]>> wrote: >> >> Perhaps not abandoned, but it seems to be "somnolescent" (sleeping). >> I don't mind -- I am trying to learn other libraries. As it is >> right now, you can do a lot with pyjs. But I don't see it moving >> into new areas, such as richer widgets -- perhaps things are happening >> that I don't see. >> >> >> Richer widgets shouldn't be in pyjs core. Pyjs is a compiler plus a set >> of base widgets to build upon. It's so easy to create widgets with Pyjs >> that it seems it would take more time to learn someones complex API for >> richer widgets and try to customize it to do what you want then to just >> create one yourself. Here is a tip: use plain HTML and CSS to prototype >> your widgets, once you get it to look the way you want, build up the >> same DOM that your html represents with Pyjs and voila: lean widgets >> that do exactly what you want and with unlimited customization and you >> know how it works intimately. >> >> Here are some examples of sophisticated Widgets i built by prototyping >> with HTML/CSS first and then adding behavior with Pyjs: >> https://github.com/damoti/damoti-client > > Nice work. I have done widgets like that, too. A specific > example of something that I think should be in the core is a > more powerful base grid (table) widget. The current pyjs > grid is basically an HTML table, very limited and not very > easily extensible. Compare, for example, to the qooxdoo > Table widget: > > http://demo.qooxdoo.org/2.1/demobrowser/#table~Table.html > > I think you will see immediately what I mean.
yes the default stuff can be improved... i like the idea of a nice default CSS as suggested in another thread, but it must not be 1-to-1 per widget, and the CSS must load *before* the widget, else its pretty pointless (unstyled widget is not only ugly, it can break layout, trigger multiple reflows, and is ultimately jarring to UX) so far my favorite idea there is a base.css with everything, as loading a few more KiB is moot compared to latency of round trip HTTP. things are certainly quiet, but that's not really too alarming IMO, as it happens often over the years (activity peaks follow interest piques), not only here, but most projects i've been [semi-]involved in... even if the project is clearly in use (kombu/librabbitmq come to mind) *my* indefinite agenda is to cut much more fat from the repo, and pull the widget library out completely, along with more end-to-end improvements of the *developer* experience... eg. making it simpler to accomplish <insert-here>. this is the reason most work (of my own at least) is almost 100% refactor/rearchitect... and even though i know the repo pretty well i try to be conservative so as not to break anything, so work can be slow. ...alas, a proper release sort of fell to the wayside when i got bombarded by more-pressing duties over the last month or two, but i know there is OOB chatter amidst -- some endeavoring folks actively trying to cement pyjs and gain outside sponsorship... ...eg, i have an internal demo of uWSGI in 2 days that will indirectly demo pyjs (by design, ive already done a primary talk on pyjs :) rest assured; there is no danger here. ...however, neither the widget set itself nor it's presentation is high priority for me (or some others it seems) now, or in future (could always change as context/reqs change).... frankly, im not particularly interested in twiddling that to death... i'm much more interested in the translator architecture and low level operations that make it all possible, proving a solid and enduring platform *others* may trust with their own work/libs/toolkits. i do/will usually accept incoming contribs to improve widgets, providing they align/will-align with core changes. -- C Anthony --
