PyHtmlGUI Project is looking for developers

Discussion in 'Python' started by phoenixathell@gmx.de, Dec 26, 2005.

  1. Guest

    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
     
    , Dec 26, 2005
    #1
    1. Advertising

  2. 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
    --
    The problem with the world is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
     
    Sybren Stuvel, Dec 26, 2005
    #2
    1. Advertising

  3. Guest

    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.
     
    , Dec 27, 2005
    #3
  4. A good idea... but I would prefer it being abstracted from Zope...
     
    Marco Aschwanden, Dec 27, 2005
    #4
  5. Guest

    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
     
    , Dec 27, 2005
    #5
  6. Guest

    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
     
    , Dec 27, 2005
    #6
  7. 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
    --
    The problem with the world is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
     
    Sybren Stuvel, Dec 27, 2005
    #7
  8. John J. Lee Guest

    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
    > 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
     
    John J. Lee, Dec 28, 2005
    #8
  9. Guest

    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
     
    , Jan 2, 2006
    #9
  10. 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 is stupidity. Not saying there should be a
    capital punishment for stupidity, but why don't we just take the
    safety labels off of everything and let the problem solve itself?
    Frank Zappa
     
    Sybren Stuvel, Jan 2, 2006
    #10
  11. John J. Lee Guest

    Sybren Stuvel <> writes:

    > 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
     
    John J. Lee, Jan 2, 2006
    #11
  12. Guest

    John J. Lee schrieb:

    > Sybren Stuvel <> writes:
    >
    > > 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
     
    , Jan 3, 2006
    #12
  13. Paul Boddie Guest

    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
     
    Paul Boddie, Jan 4, 2006
    #13
  14. Fuzzyman Guest

    Fuzzyman, Jan 5, 2006
    #14
  15. John J. Lee Guest

    "Paul Boddie" <> 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
     
    John J. Lee, Jan 8, 2006
    #15
  16. Paul Boddie Guest

    John J. Lee wrote:
    > "Paul Boddie" <> 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, Jan 9, 2006
    #16
  17. Paul Boddie Guest

    John J. Lee wrote:
    > "Paul Boddie" <> 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, Jan 9, 2006
    #17
  18. Veri Guest

    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
     
    Veri, Jan 19, 2006
    #18
  19. Fuzzyman Guest

    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
     
    Fuzzyman, Jan 19, 2006
    #19
  20. Veri Guest

    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
     
    Veri, Jan 19, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    424
    The Abrasive Sponge
    Jan 2, 2005
  2. Replies:
    0
    Views:
    612
  3. Mathew
    Replies:
    0
    Views:
    240
    Mathew
    Aug 23, 2011
  4. fabus
    Replies:
    0
    Views:
    95
    fabus
    Jun 5, 2008
  5. fabus
    Replies:
    0
    Views:
    124
    fabus
    Jun 17, 2008
Loading...

Share This Page