On Mon, 8 Nov 1999, Eron Lloyd wrote:
> program I personally think will be highly beneficial, both to me and the
> open-source community - a GUI frontend to the Zope (www.zope.org)
> publishing system. I'm building a product in Zope, and besides wanting
> to learn it's internals, need a tool such as a GUI Adminstration/Editing
> application to make using the system easier.
I think this is a great idea. :)
> I think I'll be alright
> with coding, but need to decide on a GUI frontend. I REALLY want to
> integrate this with GNOME somehow, and want to use PyGTK/GNOME to do so,
> but, being very immature in my experience, need solid documentation and
> tutorials to get on my way. One Python toolkit, WxPython, does provide
> this.
I think my 10 minute guide for Gnome/Gtk+ will help you a lot. :)
http://www.baypiggies.org/10mintig.html
I have just signed a contract to write a somewhat expanded version of this
for www.OpenSourceIT.com.
> Eventually, I'd like to fork the system and interface code, so it can be
> ported to KDE, Win32, etc. WxPython would make this easier, also. I
> played with GLADE and built a prototype, and wonder (I've read) that it
> can generate Python code (using PyGTK). Any help on these matters would
> be greatly appreciated.
I can offer some help on that. But basically, I use a modified version of
the smalltalk concept of model-view-controller. The model is the
data-related class, the view is the GUI class and the controller talks
between them. I add a fourth class, the structure class, which is where
the data is stored independently of how it is ultimately represented on
disk (flat file, database, whatever). So:
model <-----> controller <-----> view
^ ^
| |
v |
structure <- - - - - - - - - - - - - - - - -
That way, to write a new interface, you just have to change the view
classes (you can also easily change the underlying data representation). I
can provide an example, but it's not espcially well documented. I've put a
few files from the in-progress work on Helldesk up on the baypiggies site.
This is a glade rewrite from a cgi-based app. Some of the classes, such
as the person class, were never fleshed out because they were, in
practice, input from a command line.
In practice, you request something of the controller, who talks to the
model and/or the view as it needs.
http://www.baypiggies.org/helldesk/hdControl.py is the controller class.
It is the same regardless of the model or the view -- there would be one
instance per model/view pair.
hdData.py is the superclass for gadfly database derivatives. I'm still
hashing it out (this project got moved to the back burner big time).
hdPersonData.py is the data subclass for a person relation in Helldesk. I
have started to migrate, based on work done in another project, from
keeping information in the form it comes from gadfly into keeping it into
a list of structs.
hdPersonStruct.py is the structure class for storing information in
memory. As it will do the conversions to and from (eventually), it won't
matter how something is stored.
hdPersonGladeView.py is the python code to talk to Glade (a GUI builder
for Gnome) and populate it based on the Gadfly database's contents. Note
how little code there is. (I must say, this impressed the hell out of
others here who had done Gtk+ stuff).
And, because we have to start all the code from somewhere (yeah, I suck, I
hardcoded the location of the database): startHellDesk.py
And, to give an idea of what the whole thing looks like:
http://www.baypiggies.org/helldesk/snapshot.png
BTW, Helldesk will be distributed under a Python-style free license, so
feel free to use any concepts or code you think are useful.
--
_Deirdre * http://www.linuxcabal.net * http://www.deirdre.net
"Mars has been a tough target" -- Peter G. Neumann, Risks Digest Moderator
"That's because the Martians keep shooting things down." -- Harlan Rosenthal
<[EMAIL PROTECTED]>, retorting in Risks Digest 20.60
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
