Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > PyHtmlGUI Project is looking for developers

Reply
Thread Tools

PyHtmlGUI Project is looking for developers

 
 
phoenixathell@gmx.de
Guest
Posts: n/a
 
      12-26-2005
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

 
Reply With Quote
 
 
 
 
Sybren Stuvel
Guest
Posts: n/a
 
      12-26-2005
http://www.velocityreviews.com/forums/(E-Mail 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
--
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
 
Reply With Quote
 
 
 
 
phoenixathell@gmx.de
Guest
Posts: n/a
 
      12-27-2005
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.

 
Reply With Quote
 
Marco Aschwanden
Guest
Posts: n/a
 
      12-27-2005
A good idea... but I would prefer it being abstracted from Zope...


 
Reply With Quote
 
phoenixathell@gmx.de
Guest
Posts: n/a
 
      12-27-2005
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

 
Reply With Quote
 
phoenixathell@gmx.de
Guest
Posts: n/a
 
      12-27-2005
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

 
Reply With Quote
 
Sybren Stuvel
Guest
Posts: n/a
 
      12-27-2005
(E-Mail 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
--
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
 
Reply With Quote
 
John J. Lee
Guest
Posts: n/a
 
      12-28-2005
(E-Mail Removed) 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

 
Reply With Quote
 
phoenixathell@gmx.de
Guest
Posts: n/a
 
      01-02-2006
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

 
Reply With Quote
 
Sybren Stuvel
Guest
Posts: n/a
 
      01-02-2006
(E-Mail 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
--
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Looking for python/pyramid developers for a project Mathew Python 0 08-23-2011 07:53 PM
Looking for developers for open source eLearning project fabus Javascript 0 06-17-2008 10:04 AM
Looking for developers for open source eLearning project fabus Javascript 0 06-05-2008 09:25 AM
Freeware soft-phone project (looking for developers) Vladimir Karmishin VOIP 2 08-13-2006 04:40 PM
Java Architects / Sr. developers / Developers smanojs@yahoo.com Java 1 01-02-2005 05:04 AM



Advertisments