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 fo
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
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
John J. Lee wrote:
> "Paul Boddie" <[EMAIL PROTECTED]> 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
John J. Lee wrote:
> "Paul Boddie" <[EMAIL PROTECTED]> 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
"Paul Boddie" <[EMAIL PROTECTED]> 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 we
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
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] 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
John J. Lee schrieb:
> Sybren Stuvel <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] 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 r
Sybren Stuvel <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] 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-s
[EMAIL PROTECTED] 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
--
The problem with the world i
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
[EMAIL PROTECTED] writes:
> 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
> incooper
[EMAIL PROTECTED] 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 othe
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
independ
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 Zop
A good idea... but I would prefer it being abstracted from Zope...
--
http://mail.python.org/mailman/listinfo/python-list
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 appli
[EMAIL PROTECTED] 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 b
19 matches
Mail list logo
