On Oct 10, 2013 4:39 PM, "Steve Waterbury" <water...@pangalactic.us> wrote: > > On 10/10/2013 04:59 PM, Łukasz Mach wrote: >> >> W dniu 10.10.2013 19:37, Steve Waterbury pisze: >> [...] >>>> >>>> >>>> Also, some part of pyjs/pyjamas library can be used by native python >>>> code. Eg. in pyjd, when is fixed, or in new style of desktop pyjamas >>>> (that one which uses qt/wxgtk...) >>> >>> >>> I don't understand this idea -- there are way more mature and >>> powerful python desktop gui technologies that use wx/qt, >>> such as pyface / enaml. >> >> >> But do they give you the same python code working on both: desktop and web? > > > No, but way better desktop capabilities -- pyjd isn't in > the same league. That's why I suggested using pyjs to > translate apps from those frameworks to the web, rather > than the other way around. > > Full disclosure: these are comments from one who *uses* > pyjs/pyjd, rather than a developer of pyjs/pyjd. Obviously, > if you are developing pyjd, you will (and should) make decisions > based on your own judgment -- I'm just providing my opinion as a > user's perspective. > > I believe that having a web app and/or UI and a desktop > UI generated from the same code is potentially a worthy > goal and possibly even a killer app, but I think starting with > one of the existing qt/wx frameworks or metaframeworks would be > the best approach -- for example, think of the fans that pyjs > would have if it could generate a web interface from some > *existing* qt or wx apps ... the mind boggles.
This has already been done actually; probably in the old ML of pyjamas-dev, but at one point pyjd was backed by GTK/QT... There were however, major deficiencies in that the widgets provided simply cannot achieve the same richness/flexibility as HTML/CSS... The specifics are detailed in the archives. Now, I know that pyjs-on-QT-or-GTK is actually the reverse of what you said! alas, GTK-on-pyjs has *also* been done -- see the pygtkweb directory... It implements the GTK API thus allowing a GTK app to be translated to pyjs counterparts. This code however has been unmaintained/unused for some time, so its state/usefulness is unknown (I've been tempted to kill it at least 3 times that I recall). Ultimately, I think that path leads to a can of worms, with an explosion of APIs that need support -- we'd then need to track and maintain compat with an ever growing list of versions and libraries -- which do we support? And which versions? Only the latest? What about foreign bugs? ...do we faithfully duplicate them? By focusing on the DOM (which by itself is a lot to chew) that scope is clearly defined and contained. -- C Anthony [mobile] -- --- You received this message because you are subscribed to the Google Groups "Pyjs.org Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyjs-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
