pyQT & web2py

[mart]

Hi,

has anyone considered using pyQT within their apps? and if yes, any
comments on its use?

Thanks,
Mart :)

[blackthorne]

yes, I fully recommend it. i think it's the best way of developing gui
in a portable and native-respectful way. you also have Pyside.

Qt creator is great. you can use Qt designer with pyuic for
translation.

make your questions, I will try to answer even though it is fairly
offtopic.

[mart]

This is great to hear! I was looking at making a few pieces (with a
UI) that would have both web version and non-web version! So, I made a
note that "blackthorne" knows all about this when I get stuck! :)


Thanks for that!
Mart :)

[blackthorne]

wrong note!
I like it, I consider it the best way of making GUI's for many reasons
but I am beginner on it.

However, I think it may be interesting the creation of systems with
multiple interfaces.
In fact, I had the idea of the "web 6.0" :) as I called it, by
defining metadata threw the web that dynamically generates native
interfaces using Qt as you surf the web. Websites would appear as real
and coherent applications in your system.
Recently, Apple did something like this with the iPhone OS.

Anyway, feel free to contact me but you may have better luck by trying
the #Pyqt channel on irc.freenode.net

Best regards

[Stefaan Himpe]

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.

[blackthorne]

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

[mart]

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 :)

[Jason Brower]

What product are you making. It really depends on the product you are
making as how you plan on making a gui that uses web2py tools.
I personally have made a web2py server that calls a wine program that
has a qt user interface and and a specially modified twisted server.
What is that, like 5 different programs?!) Each run seporatly but may
need to pull data from each other at times. It is certainly possible,
it's one of the reasons I chose web2py, because it was written in
python, and python can do just about anything. :P
Best Regards,
Jason Brower

[mart]

Hey,

Its in-house (mostly all python) automation framework for
builds&releases, and other process specific tasks (and acts a the
interface between test and releas automation). Its all up and running
as it is, and is doing a great job. So, I;m doing some feature
development now that the foundation is up and running. The way I made
layout the code structure means there is no separation beween blueLite
(the automation) and web2py.. one can work on its own independently
from the other if needed (but made to work together). I can launch
web2py (the web app0 and serve applications, and those applications
that act as front end to blueLite make reference to the blueLite
modules s well.

So, it came as a surprise a little while when different team had asked
to use the framework, but the ask mad lit of sense to. Since the whole
thing is basically "dump to ds and run", new uses are coming up. Teams
use it for continues build/integration in their sandboxes, dev folks
use it on there desktop or laptop, and this a support fully, because
they try to match as close as possible the actual production
environment, and that often starts with the tooling. Some of the folks
that want to make use of it and that are not that technical, find that
having to launch a webApp + browser intimidated (even though its
not)... so, pyQT can quell that "fear" of os the unknown for them. its
the same thing really, but... the idea of having the ability to verify
dev/build data on someone's desktop is quite appealing to them. The
setup os the same, but the server part becomes invisible... almost
like giving someone a placebo... as long as they believe it ;) So, s
mentioned, when we will be able to dump a fully deployable web2py (as
in dump and deploy, one click), things should start to get
interesting :)

so it ends up like this:

they use a browser (that doesn't look like a browser - actually a
browser that doesn't enable browsing), and they are happy... the only
requirement is that they install python, which they can download
internally n=on the corporate network, with a nice page with very
simple instruction, to the letter (which always makes me giggle,
because some are so focused on the litte detail that don;t make much
of a difference ;)).

You ever hear of the Peter principle? this is it, at its best! :)

Mart :)

[mart]

sorry, for the bad spelling... i usually dont re-read anything I type,
because then have to correct spelling, but this time I shoulda...

[Richard Vézina]

Peter's principles 

I should reread it...

Richard

[Jason Brower]

It sounds like you could start the QT interface from web2py if you wanted. :P  But I think the best think would be to have two programs, the Interface (Web, QT, Mobile app (nokia supports qt) etc...) and then an application that communicates with that for the automation stuff. It would have an interface that would be universally accessable from a network. (I use amp in twisted, but you may xml or something) and your interfaces would read that.  You could have web2py do that serving of that data and that would simply things a bit.
Best Regards,
Jason Brower

[mart]

@ Richard - yes, this one : http://en.wikipedia.org/wiki/Peter_Principle

@ Jason - yes. In a more traditional build & release infrastructure,
that kind of setup does make sense... However, this place isn't really
traditional, actually far from it ;) I'd be happy to show you how
web2py is used within the automation and why it makes the most sense
(for them and their particularities).

Thanks,

Mart :)





On Jan 21, 2:05 pm, Jason Brower <encomp...@gmail.com> wrote:
> It sounds like you could start the QT interface from web2py if you
> wanted. :P  But I think the best think would be to have two programs,
> the Interface (Web, QT, Mobile app (nokia supports qt) etc...) and then
> an application that communicates with that for the automation stuff. It
> would have an interface that would be universally accessable from a
> network. (I use amp in twisted, but you may xml or something) and your
> interfaces would read that.  You could have web2py do that serving of
> that data and that would simply things a bit.
> Best Regards,
> Jason Brower
>

> On 01/21/2011 08:58 PM, Richard V�zina wrote:
>
>
>
>
>
>
>
> > Peter's principles