On Oct 10, 2013 4:39 PM, "Steve Waterbury" <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
