manatlan <[EMAIL PROTECTED]> wrote:
> I was a fan of "SimpleGladeApp/tepache way" to build a pygtk app.
> I've build a new efficient/dynamic way to build a pygtk app ...
> Here is an example :
> =================================================
> class Fen(GladeApp):
> """
> Window win
> .title="Hello"
> @delete_event
> VBox
> HBox
> Label jo
> .label="kokotte"
> entry myEntry
> .text="kuku"
> gtkBuTTon b2
> .label="33"
> @clicked
> Label jo
> .label="koko"
> Button b
> .label="3"
> @clicked
> """
> def init(self,m):
> self.jo.set_text(m)
> pass
> def on_b_clicked(self,*a):
> self.quit(3)
> def on_b2_clicked(self,*a):
> self.quit(33)
> def on_win_delete_event(self,*args):
> self.quit(4)
> f=Fen("koko2")
> print f.loop()
> =================================================
> How it works :
> in fact, the __doc__ is converted as a "glade file"
> the tree of object is indented (like python way)
> you can see some common pygtk widget ...
> line starting with a dot is an property of the parent object.
> line starting with a @ is a declaration of a event of the parent
> object.
> widgets are not case sensitive, and can start with "Gtk". If a second
> word is provided it will be used as an "id", otherwise an unique id
> will be build according the type of widget.
> the window is created with glade, widgets are provided as attributs of
> the instance, and signals are autoconnected on method
> "on_[widgetId]_[event](self,*args)" (if a signal is missing in your
> class, it warns you at run time) ....
> It will not replace the use of glade-3 for complex widget ... but I
> think it's an easy way to code very easily/quickly a simple pygtk
> window/form.
> I think it could be really useful/handly for beginners too.
> for people which are involved in pygtk/python/gui ... i'd like to hear
> your comments/ideas ...
> Rq:
> i don't provide the code now, but it will be released in next version
> of "GladeApp" ( http://manatlan.infogami.com/GladeApp )
> it works already, but i need to make "packing properties available"
> too ...
I'd be a little leery of overloading the __doc__ strings in this
way. (They are overloaded enough when used for doctest strings ...
but those can serve a legitimate documentary purpose and other doctests
can be stored separately).
Perhaps it would make sense to standardize on a defined member name
such as: GTK__Glade. The rest of your code could remain the same.
Are there any other Python projects using other "magically introspected
strings" approaches? I thought I saw something being used by some
"programming by contract" or some AOP (aspect oriented programming) tools
that might be using something like this.
--
Jim Dennis,
Starshine: Signed, Sealed, Delivered
--
http://mail.python.org/mailman/listinfo/python-list
