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

[John J. Lee]

Sybren Stuvel <sy*******@YOUR thirdtower.com. imagination> writes:

ph***********@g mx.de 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?

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

[phoenixathell]

John J. Lee schrieb:

Sybren Stuvel <sy*******@YOUR thirdtower.com. imagination> writes:

ph***********@g mx.de 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?

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]

ph***********@g mx.de wrote:

John J. Lee schrieb:

I guess this is 'rendering' in a more general/abstract sense than
'graphical rendering'.
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]

"Paul Boddie" <pa**@boddie.or g.uk> writes:
[...]

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]

John J. Lee wrote:

"Paul Boddie" <pa**@boddie.or g.uk> writes:
[...]

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}?

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]

John J. Lee wrote:

"Paul Boddie" <pa**@boddie.or g.uk> writes:
[...]

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}?

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]

Veri wrote:

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

Have a nice day,

Peter

[Veri]

Fuzzyman wrote:

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

All the best,

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