PyHtmlGUI Project is looking for developers

[phoenixathell]

Hi all,

the PyHtmlGUI Project (http://www.sourceforge.net/projects/pyhtmlgui)
is looking for developers that want to join.

The aim of the project is to create a web application framework. The
API of PyHtmlGUI wants to be close to Trolltechs famous Qt API but
incooperates the idea of a text based renderengine instead of the pixel
based one. The obviouse target is html/css but through xml rendering
process nearly every textual output could be generated.

So far we finished a proof-of-concept prototype that is available via
CVS from sourceforge. Now we would like to extend this prototype to a
full useable framework. But therefore we would like to have more
developer involved. On the one hand because of time issues on the other
hand to get new ideas and comments for the project.

What skills you should have to join ?

Well, you should at least be able to program in python .

But of course a very big plus is knowledge about Qt because the basic
idea is to transfer Qt's API to PyHtmlGUI. But it is not necessary that
you are a Qt guru. And if you don't have the slightest idea what Qt is
you could still help us with bugfixing and unittesting.

The bottom line is that we are looking for people that can help us to
create a great web application framework.

How can you join ?

Just write me a email.


Greetings,
Ingo

 

[Sybren Stuvel]

(e-mail address removed) enlightened us with:

The aim of the project is to create a web application framework. The
API of PyHtmlGUI wants to be close to Trolltechs famous Qt API but
incooperates the idea of a text based renderengine instead of the
pixel based one. The obviouse target is html/css but through xml
rendering process nearly every textual output could be generated.

Why is your project better than simply embedding a KHTML control in a
GUI?

Just write me a email.

Just check this group for replies.

Sybren

 

[phoenixathell]

Because embedding KHTML means that you have a GUI application that runs
on a special operation system.

But what we propose is that you can write a web application in the same
way like your GUI application and it appears like a "normal" GUI. Web
application means in these case that you have a application that has a
browser as a frontend client. The idea itself is a little bit like XUL
for mozilla. But there you are dependent to the mozilla browser.

Our main goal is plattform independence. Because our user are using os
x, linux and windows side by side and therefore we needed a os
independent system. As we started Qt was not around as open source for
windows.

Now you could ask why we didn't choose something like LAMP. The answer
is quite simple, we didn't want to fiddle around with html and some
embedded stuff or even worse with cgi scripts. So the result is a kind
of a abstraction layer that handles the normal web stuff but can be
programmed like a gui.

As a result the application programmer doesn't have to bother if it is
a web application delivered through a webserver or if it is a gui
application delivered through X11 or other pixel painting engines.

 

[Marco Aschwanden]

A good idea... but I would prefer it being abstracted from Zope...

 

[phoenixathell]

Hi Sybren,

the idea of pyhtmlgui is that you can develop a web application the
same way like a standard gui application. So what you get is a widget
tree (buttons, forms, title bars, etc.) on the server side and a gui on
the client side. The server in our case would be something like Apache
or Zope webserver (in fact at the moment we only support Zope, but we
want to extend it to Apache as well). The client is a browser. So the
whole application is design as a thin-client-fat-server architecture.

KHTML is just a rendering engine like IE or gecko that renders incoming
html/css pages. That means that you need a plattform dependened program
where you embedd KHTML control. But than you are limited to a plattform
and you will have trouble to port the program to other systems. And the
biggest point is that the program is executed on the clients machine
whereas in our case the program is executed on the server and only the
htmlgui is delivered to the client.

Our dream is that established web applications like phpmyadmin or
squirrelmail will get a interface that can be recognized between
different applications. Through this approach you can expect that the
behaviour will be the same. That was pretty much the same idea behind
KDE or even more evil Windows.

So far every web application project used its own interface because
there is no common framework. What we see now is a growing development
of content managment systems. But these frameworks are limited to the
task of content managment. We propose a more general view of web
applications.


I hope that answers your question.

Greetings,
Ingo

 

[phoenixathell]

Hi Marco,

that is one of our goals. But so far we didn't had the time to do it.

PyHtmlGUI is already complete independent from Zope but it still needs
some kind of request handling (another small script). One of our next
steps will be to create a abstraction of the request handling to be
independent of the web server.

Ingo

 

[Sybren Stuvel]

(e-mail address removed) enlightened us with:

the idea of pyhtmlgui is that you can develop a web application the
same way like a standard gui application. So what you get is a
widget tree (buttons, forms, title bars, etc.) on the server side
and a gui on the client side.

Ah, okay - it's the other way around than what I thought ;-)

I would love to be able to create an app using a real GUI toolkit, and
then transparently be able to create it online.

Sybren

 

[John J. Lee]

the PyHtmlGUI Project (http://www.sourceforge.net/projects/pyhtmlgui)
is looking for developers that want to join.

The aim of the project is to create a web application framework. The
API of PyHtmlGUI wants to be close to Trolltechs famous Qt API but
incooperates the idea of a text based renderengine instead of the pixel
based one. The obviouse target is html/css but through xml rendering
process nearly every textual output could be generated.

So far we finished a proof-of-concept prototype that is available via
CVS from sourceforge. Now we would like to extend this prototype to a

[...]

This is great news.

I hope you manage to keep it pragmatic enough that people can always
be confident of getting their work done, but without losing the
benefits of abstraction.

I wonder how you're dealing with client-side code (ie. JavaScript)?
Have you looked at crackajax or PyPy?


John

 

[phoenixathell]

Hi John,

I wonder how you're dealing with client-side code (ie. JavaScript)?

At the moment we don't work with javascript. But it should not be to
hard to create a JavaScript Renderer similar to the css one we already
have.

Have you looked at crackajax or PyPy?

Not really close so far. On of our aims is the avoidance of scripting
languages on the client side. But it could be that these will change a
bit in the future. Some of the parameter checking functionality could
be done on the client side. So i guess we will have a closer look.

Greetings,
Ingo

 

[Sybren Stuvel]

(e-mail address removed) enlightened us with:

At the moment we don't work with javascript. But it should not be to
hard to create a JavaScript Renderer similar to the css one we already
have.

Isn't CSS for rendering, and JavaScript for client-side scripting?

Sybren

 

[John J. Lee]

(e-mail address removed) enlightened us with:

Isn't CSS for rendering, and JavaScript for client-side scripting?

I guess this is 'rendering' in a more general/abstract sense than
'graphical rendering'.


John

 

[phoenixathell]

I guess this is 'rendering' in a more general/abstract sense than
'graphical rendering'.


John

Exactly. In these case rendering means that you traverse a tree with
widget objects and every is "rendered" to a text representation of
itself. So if you traverse the object tree in the right order you will
get a complet text representation of such a object tree.

If you familiar with GUI programming then you can compare it to the
graphical rendering where you get a pixel representation of your form
elements (again a tree of widget objects).

Bottom line, PyHtmlGUI generates on the fly one or more text
representations from a object tree (e.g. Html, CSS, XML and maybe also
JavaScript).

Ingo

 

[Paul Boddie]

Exactly. In these case rendering means that you traverse a tree with
widget objects and every is "rendered" to a text representation of
itself. So if you traverse the object tree in the right order you will
get a complet text representation of such a object tree.

From my experimentation with PyQt so far, it would appear that Qt

Designer provides such a representation that various tools and the
QWidgetFactory can then employ to recreate widgets in the Qt
environment. Of course, it's entirely possible to take the Qt Designer
..ui file and generate an alternative representation instead, and in my
XSLTools distribution [1] you'll find an XSL stylesheet which does
this, along with various as-yet-undocumented modules and programs which
provide a Web front-end to somewhat restricted PyQt form-based
programs.

The big challenge is reconciling event-based frameworks, where you get
to handle events individually and to change the user interface at any
time, with Web-based environments, where you could potentially receive
a batch of updates occurring and where you only get one chance to
update the user interface, all within the same framework. Of course,
many would advocate using "AJAX" techniques and dropping support for
conventional Web interactions, but I think that such advocacy and the
resulting applications threaten the usability of the Web for fairly
large groups of people.

Paul

[1] http://www.python.org/pypi/XSLTools

 

[Fuzzyman]

This is a *great* idea. Shame you've chosen Qt as your GUI API though.
;-)

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[John J. Lee]

many would advocate using "AJAX" techniques and dropping support for
conventional Web interactions, but I think that such advocacy and the
resulting applications threaten the usability of the Web for fairly
large groups of people.

That may well be true in practice, but I don't see any intrinsic
reason for it. Do you {,care}?


John

 

[Paul Boddie]

That may well be true in practice, but I don't see any intrinsic
reason for it. Do you {,care}?

As I've probably said before, it's tempting for some people to demand
JavaScript for their Web applications whilst claiming that JavaScript
implementations are ready for serious use. Yet, aside from some of the
more hyped toolkits managing either to crash my
not-particularly-incapable browser or failing to do anything visible,
there's still a lot to be said for simple, "old school" Web
interactions. Would I prefer a silky drag-and-drop experience on an
Internet banking site, or would I rather be presented with the
pertinent facts for a transaction with some buttons on the page to
either confirm or cancel my actions? The latter approach quite probably
reduces the "what's going on now?" factor amongst large sections of
society familiar (but not intimately so) with computers - ie. more than
95% of users, I'd imagine. In attempting to replicate some dubious user
interface metaphor from their Mac, I imagine that most of the more
vocal "AJAX" advocates forget this.

Paul

 

[Paul Boddie]

That may well be true in practice, but I don't see any intrinsic
reason for it. Do you {,care}?

As I've probably said before, it's tempting for some people to demand
JavaScript for their Web applications whilst claiming that JavaScript
implementations are ready for serious use. Yet, aside from some of the
more hyped toolkits managing either to crash my
not-particularly-incapable browser or failing to do anything visible,
there's still a lot to be said for simple, "old school" Web
interactions. Would I prefer a silky drag-and-drop experience on an
Internet banking site, or would I rather be presented with the
pertinent facts for a transaction with some buttons on the page to
either confirm or cancel my actions? The latter approach quite probably
reduces the "what's going on now?" factor amongst large sections of
society familiar (but not intimately so) with computers - ie. more than
95% of users, I'd imagine. In attempting to replicate some dubious user
interface metaphor from their Mac, I imagine that most of the more
vocal "AJAX" advocates forget this.

Paul

 

[Veri]

Good Morning everybody.

Maybe it didn't get clear in the previous discussion: We didn't choose
Qt as GUI API, we build an own GUI which is able to produce XML and
html output, but whose structure is close to Qt. We even built a basic
factory which produces PyHtmlGUI widgets from a Qt Designer .ui file,
but it is still in development.
The GUI is used by another project (a data management framework for
Zope) which hasn't been anounced yet, but could generally be used for
any python based webapplication (it enfolds its full capacity when it
comes to forms, dialogs and wizards).
The lack of client-side functionality (Javascript etc.) didn't cause
any urgent problems, so we decided to postpone that, but since there
are almost no constraints on widget customization, it is even now
possible to build in javascript while building a layout, we just didn't
try.
The main goal of the project is to have a real GUI creating html and
thus to avoid something like dtml, jsp or php etc., where you have to
fiddle code into html. It's the other way around and since the css
update it is even looking nice

Have a nice day,

Peter

 

[Fuzzyman]

Good Morning everybody.

Maybe it didn't get clear in the previous discussion: We didn't choose
Qt as GUI API, we build an own GUI which is able to produce XML and
html output, but whose structure is close to Qt. We even built a basic
factory which produces PyHtmlGUI widgets from a Qt Designer .ui file,
but it is still in development.
The GUI is used by another project (a data management framework for
Zope) which hasn't been anounced yet, but could generally be used for
any python based webapplication (it enfolds its full capacity when it
comes to forms, dialogs and wizards).
The lack of client-side functionality (Javascript etc.) didn't cause
any urgent problems, so we decided to postpone that, but since there
are almost no constraints on widget customization, it is even now
possible to build in javascript while building a layout, we just didn't
try.
The main goal of the project is to have a real GUI creating html and
thus to avoid something like dtml, jsp or php etc., where you have to
fiddle code into html. It's the other way around and since the css
update it is even looking nice

So you'e creating a Python API to a GUI, which generates HTML
interfaces with appropriate callbacks to the relevant widgets. This API
*resembles* the Qt API.

What would be nice is a compatibility layer which means that the same
application could be created for the Web or the desktop, just using the
appropriate GUI toolkit (web or desktop). This wasa what I thought you
were doing. With appropriate AJAX type calls it's not unfeasible.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

 

[Veri]

So you'e creating a Python API to a GUI, which generates HTML
interfaces with appropriate callbacks to the relevant widgets. This API
*resembles* the Qt API.
Exactly.

What would be nice is a compatibility layer which means that the same
application could be created for the Web or the desktop, just using the
appropriate GUI toolkit (web or desktop). This wasa what I thought you
were doing. With appropriate AJAX type calls it's not unfeasible.

The mentioned compatibility layer are the Renderer and a
RequestHandler. Instead of rendering html it would be possible to
render pixelbased widgets, the renderer could use any other
python-GUI-API to produce the layouts. But I don't really see why this
could be neccessary at the moment. Whatever works for the web can be
used via browser on the desktop as well. But it could be great to have
it the other way around. Imagine some Qt-based desktop application
being accessible via browser.

Peter