So, there is lots of fun to had with web2py with pyQT. It just depends on the end goal.
I embed web2py within an automation framework, which despite this and a few other pieces, turns out to be pretty light on its feet (not a huge footprint for users to download). So, doing this, web2py comes in VERY handy both in and outside of the web context. the automation (aka 'blueLite') uses DAL to handle the data layer, completely. Since blueLite is almost all python, it makes use of many features of web2py, even outside of a browser. Also, since each instance of blueLite has web2py within its folder structure, anyone making use of blueLite, can also make use of web2py, the full webApp server. The built in applications that come baked in, make good use of the blueLite modules as well. once, I get the one-button-click deployement working, well... imagine having a local web2py server sitting on developers desktops. Distributed development efforts, with the right applications, will gain a lot from a collaboration perspective. This is what I tried this morning, with minimal effort. I can create a pyQT application with different widgets in the mainWindow to handle different scenarios. For example, I can have an interface to blueLite, which by it self is headless, and I can manipulate and execute different features of blueLite and provide data to them through this UI. I can also, have a webView widget (which is just a browser window). With this, I can have a dropdown menu (or anything really) and have it start up and point to the local web2py server, or have point to a remote server simply by choosing it in the drop-down menu. By doing so, this becomes an easy-to-put-together desktop application which makes use of a browser widget, but isn't a browser, because users can't enter a URL. It will only navigate the web2py applications (this is intentional, they can use a full browser to browse the net. As Blackthorn points out, this would make a great DB viewer for users who need to retrive data from either the local or remote DB. Querying DBs (or what ever the action is) with buttons that execute sql queries isn't a hard thing (thanks to Massimo's work), because I don't have to use QT's built-in DB and TAble libraries, I can simply use the DAL as I do with blueLite. My plan is to start with this and see what comes of it. A good and easy way would be to have that desktop app (bundled with blueLite and web2py) and have it work in to ways. 1) with blueLite directly as a desktop app (which already comes with web2py so I can use that to) and 2) still as a desktop app but through a webView widget, so I can access web2py, the webAppserver. I can see where plugin_wiki would be a great place to start since the work involved is just adding those pages to the wiki and have them to whatever is needed, then have the pyQT app point to those pages that display very well within this non- browser browser application. Again, minimal effort, great looking front that does indeed work well with web2py. Why not simply use pyjamas? Because I want to use web2py. web2py is a full framework, pyjamas is not. I could use pyjamas with the app, but then I would use it with web2py, and have pyQT use web2py to get to pyjamas... (no real or immediate benefit there). So, in fact, web2py will now be used in 3 separate environments. As the back end to a headless automation framework, 2) as the great webApp sevrer it is and 3) as a bundled up backend service to a desktop desktop application. Thanks, Mart :) On Jan 20, 10:27 pm, blackthorne <francisco....@gmail.com> wrote: > well, I think he didn't made it clear but I see many ways: > > - create a component for web2py that instead of generating the html/ > css/js source you use to see it in a website, it would generate the > GUI application (controllers+view) as well as linking it to a shared > model. This is a lot of work but would be awesome... > > - create an independent app that communicate with web2py just like you > mentioned. > > - bind a Qt interface to the same hooks currently used by the web > interface that allows you to do pretty much everything web2py > supports. One idea would be to put the admin application with a native > look and extend, in example, monitoring properties (graphs, stats, > plots). Qt is good for that. > > - web 6.0 - my idea (not so web2py specific, but appliable) > > best regards > > On Jan 21, 12:03 am, Stefaan Himpe <stefaan.hi...@gmail.com> wrote: > > > > > > > > > Hello, > > > It's not clear to me how you would combine PyQt (or PySide) with web2py > > in the same application, it doesn't seem to make much sense to me. > > > Provided you could actually make this work, a PyQt UI embedded in a > > web2py application would only be visible on the server (e.g. some google > > data center), not on the client (user of the web application). > > > Of course I could have misunderstood: you could make a PyQt UI that > > requests services from a web2py web application using xmlrpc. > > In that case both applications are completely separate from each other. > > > If you want to make both a web and desktop version of the same > > application (e.g. a bug database that can run both in your web browser, > > or as a standalone desktop program), perhaps pyjamas is something worth > > looking at:http://pyjs.org/ > > > Best regards, > > Stefaan.
