Re: [pygtk] gnome-python split proposal
On Sat, 28 Aug 2004 21:22:46 +0100, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote: > I just realized that there is a project called python-gtkextra, so > pygtk-extra is bound to cause some confusion. Any ideas for alternative > names? Does gnome-python-extra sound good? Any other idea? Thanks. > "pygtk-plus" -- Sridhar - http://cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: Re: [pygtk] toggle.set_active( ) will automatically emit the 'toggled' signal. What can I do to stop this?
Nikos Kouremenos <[EMAIL PROTECTED]> wrote: > and just because someone said why I want this.. > I'm writing an GNOME panel applet, where I make use of this code. > http://members.hellug.gr/nkour/dcapplet/ > OK, just curious to ask. Is it going to be nice to write applets in python (or any scripting language). Normal python apps are fine, but an applet is supposed to be run throughout the user session and memory could be wasted for even tiny (applets) apps. -- Sridhar - http://cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] Database Edit/Update/View widget
Just though of sharing this module (which is part of my codehack [1] project) http://cs.annauniv.edu/~rsridhar/pub/python/snippets/database/ dbedit.py : The database edit/update/view widget example.py: an example. please note that this module is not generic. It is specific to my project and more specific to the Twisted networking framework. If your project uses twisted and like to do db interaction in client side, this module may be of use to you. [1] http://cs.annauniv.edu/~rsridhar/pub/projects/codehack/snapshots/ -- Sridhar - http://cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] pyGTK and framebuffers and glade
Kimo Lewis <[EMAIL PROTECTED]> wrote: > I am a newbe and am wanting to write an app for the linux console using > pyGTK and framebuffers and glade. Does anyone know how to make this > environment work? I don't have to use glade, but pyGTK and framebuffers is > a must. > PyGTK has nothing to do with this, only GTK is. www.directfb.org ? -- Sridhar - http://cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Glade XML wrapper and easy callbacks
Graham Ashton <[EMAIL PROTECTED]> wrote: > On Wed, 2004-08-04 at 01:40, Sridhar R wrote: > > Graham Ashton <[EMAIL PROTECTED]> wrote: > > > > > If anybody wants a really simple implementation to this kind of wrapper > > > class feel free to rip off the WidgetWrapper class hierarchy that I've > > > knocked up here (it's tiny): > > > > > > http://cvs.sourceforge.net/viewcvs.py/bandsaw/bandsaw/src/bandsaw.py?view=markup > > > > But the signal connection part is a little bit weak. How do you > > connect signals to some deeply nested widgets in that hierarchy? > > What do you mean by deeply nested? child of child of .. the toplevel widget. (may be wrong terminology). -- Sridhar - http://www.cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Glade XML wrapper and easy callbacks
Graham Ashton <[EMAIL PROTECTED]> wrote: > If anybody wants a really simple implementation to this kind of wrapper > class feel free to rip off the WidgetWrapper class hierarchy that I've > knocked up here (it's tiny): > > http://cvs.sourceforge.net/viewcvs.py/bandsaw/bandsaw/src/bandsaw.py?view=markup But the signal connection part is a little bit weak. How do you connect signals to some deeply nested widgets in that hierarchy? -- Sridhar - http://www.cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Glade XML wrapper and easy callbacks
Doug Quale <[EMAIL PROTECTED]> wrote:
>
> There's one other possibility that I don't really understand, but I'd
> like to look into it. PEAK is a Python framework for enterprise
> applications (http://peak.telecommunity.com/). PEAK implements many
> fascinating ideas. In particular its domain model module does
> something very interesting with metaclasses and nested classes.
> Applied to our area of interest it might look something like this:
>
> class MyApp(GWidget):
>
> class name(Widget.TextEntry):
>
> max_length = 40
>
> def validate(self, ...):
> # some validation code here
>
> # other properties for the name TextEntry widget
>
> class age(Widget.SpinButton):
>
> step = 1
> digits = 0
> lower = 1
> upper = 120
>
> ...
>
> PEAK uses metaclasses to do extensive processing of the nested classes
> so that users of instances of the object see regular looking
> attributes with the same names as the nested classes. This permits
> associating a lot of metadata with each attribute without using an
> absurd number of keyword parameters in the descriptor constructors.
> Compare this to:
>
> class MyApp(GWidget):
>
> def validate_name(self, ...):
> ...
>
> name = Widget.TextEntry('name', max_length=40,
> validate_fn=validate_name,
> ...)
>
> age = Widget.SpinButton('age', step=1, digits=0,
> lower=1, upper=120, ...)
>
>
Well, writing widget classes for each GWidget class is certainly
painful for the programmers. All he can do concisely is to write
lambda functions as wrappers. But surely I'm looking for easy usage
for GTK+ widgets.
Instead of this
txt = button.get_text()
button.set_text(txt)
we can make use of 'property' to do this ..
txt = button.text
button.text = txt
Another important thing is writting proxy widgets doesn't help if UI
is loaded from glade XML.
so putting it in a line, is this discussion all about making the pygtk
api much better and easy to use some which includes the one given
above ?
I have the implementation of StringValidator class that is used in
validation of changeable data in widgets. Look for the python module
in this snapshot
http://cs.annauniv.edu/~rsridhar/pub/pythondevelop/snapshots/
(That was a quick hack, though)
--
Sridhar - http://www.cs.annauniv.edu/~rsridhar
Blog: http://www.livejournal.com/users/sridharinfinity
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Glade XML wrapper and easy callbacks
On 25 Jul 2004 11:19:27 -0500, Doug Quale <[EMAIL PROTECTED]> wrote: > Sridhar R <[EMAIL PROTECTED]> writes: > > > Doug Quale <[EMAIL PROTECTED]> wrote: > > > Sridhar R <[EMAIL PROTECTED]> writes: > > > > > > About class GWidget itself, I have a few thoughts. The __init__() > > > method lets the caller optionally turn off autoconnection of signals. > > > This does no harm, but are there cases in which this is useful? I > > > thought about this but decided that if you derive from a glade > > > controller class you do it because you expect the on_widget__signal() > > > methods to be connected as signal handlers. > > > > It will be useful if the some handlers need to be called before the > > on_widget__signal methods. > > > > super(.. > > connect_my_custom_first_handlers() > > self.autoconnect_signals() > > I see, that makes sense. I hadn't run into that situation myself. It > should be possible instead to override autoconnect_signals() in the > subclass > >def autoconnect_signals(self): >connect_my_custom_first_handlers() >super(...).autoconnect_signals() > > but that certainly isn't better than using a parameter to __init__. > It's probably worse because it requires overriding two methods instead > of just one. > One more way is to have another named method (say 'connect_handlers'), that will be called by base's __init__ before calling autoconnect_signals. -- Sridhar - http://www.cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Glade XML wrapper and easy callbacks
Doug Quale <[EMAIL PROTECTED]> wrote: > Sridhar R <[EMAIL PROTECTED]> writes: > > > I have made an utility class for making the job of using glade XML > > file much easier. Can this be added to pygtk? > > > > Main class: > > http://cs.annauniv.edu/~rsridhar/pub/python/snippets/glade/gwidget.py > > > > Example (not standalone, pulled from source tree): > > http://cs.annauniv.edu/~rsridhar/pub/python/snippets/glade/gwidget-example.py > > > > Thoughts? > > About class GWidget itself, I have a few thoughts. The __init__() > method lets the caller optionally turn off autoconnection of signals. > This does no harm, but are there cases in which this is useful? I > thought about this but decided that if you derive from a glade > controller class you do it because you expect the on_widget__signal() > methods to be connected as signal handlers. It will be useful if the some handlers need to be called before the on_widget__signal methods. super(.. connect_my_custom_first_handlers() self.autoconnect_signals() > > Specifying the glade file and toplevel widget name as class attributes > is inflexible. It's also hard to overide in subclasses since you have > to completely override the __init__() method if you want to specify > the widget name dynamically. I think the glade file and toplevel > widget name should be parameters to __init__(). To override that create similar Class Variables in derived classes too. I used class variables purposedly. For each GWidget class, the GLADE_FILE attribute is supposed to be constant for *all* instances, bcoz the methods are written assuming that glade file, so the glade file can't be changed for different instances as the methods remain the same. > For the signal handler method names I prefer to use > after_widget__signal() instead of on_widget__signal__(). This is just > a matter of taste. Using 'after_' has the disadvantage of taking > another prefix in addition to 'on_', but it is more explicit. One > tiny additional advantage that we don't often think of is that the > on/after prefixes are easier to read aloud than the silent trailing > double underscore. That's probably right. Using 'after_' is more readable than suffix '__' > > Making the widgets available as attributes is a good idea. The > Pythonic way to do this is to set the attribute when it is first > accessed. Subsequent accesses won't trigger __getattr__() so you > don't need a cache: > > def __getattr__(self, attr): > new_widget = self._gladexml.get_widget(attr) > if new_widget is None: > raise AttributeError, 'Widget %r not found' % attr > setattr(self, attr, new_widget) > return new_widget > > Instead of making the widgets available as attributes, I use > __getitem__() to allow dictionary access. This again is a matter of > taste. Dictionary syntax is uglier than attribute syntax but it > avoids the chance of stepping on a name that you want to use for > another purpose. I feel dictionary acess is approriate. I though self.entry1 is much easier than self['entry'] > > The real reason I chose dictionary syntax over attribute syntax is > that I use the widget names as attributes for another purpose. The > Python 2.2+ data descriptor facility allows using descriptors to > provide attribute syntax to get and set widget values. > > class widget(object): > """A Python data descriptor that gets and sets values from widgets. > > Use inside a class that derives from Gwidget to allow getting > and setting widget values as attribute values. This works > only for widget types that have a reasonable notion of value > like gtk.Entry, gtk.SpinButton, gtk.Combo, gtk.ToggleButton, > gtk.Label and gtk.TextView. Widgets that don't have an > obvious value like gtk.TreeView are not supported. (Generally > tree views will be given their own controllers or > subcontrollers.) > """ > > def __init__(self, widget_name): > self.widget_name = widget_name > > def __get__(self, obj, objtype): > widget = obj[self.widget_name] > > if isinstance(widget, gtk.Label): > return widget.get_label() > elif isinstance(widget, gtk.SpinButton): > return widget.get_value() > elif isinstance(widget, gtk.Entry): > return widget.get_text() > elif isinstance(widget, gtk.Combo): > return widget.get_entry().get_text() > elif isinstance(widget, gtk.ToggleButton): &g
[pygtk] Glade XML wrapper and easy callbacks
I have made an utility class for making the job of using glade XML file much easier. Can this be added to pygtk? Main class: http://cs.annauniv.edu/~rsridhar/pub/python/snippets/glade/gwidget.py Example (not standalone, pulled from source tree): http://cs.annauniv.edu/~rsridhar/pub/python/snippets/glade/gwidget-example.py Thoughts? -- Sridhar - http://www.cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] ANNOUNCE: PyGTK 2.3.93 (unstable)
On Fri, 23 Jul 2004 15:22:27 +0300, Nikos Kouremenos <[EMAIL PROTECTED]> wrote: > where did gtk.glade[.XML] go? IIRC, it is now glade.XML , I guess. -- Sridhar - http://www.cs.annauniv.edu/~rsridhar Blog: http://www.livejournal.com/users/sridharinfinity ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] about widget creation in libglade
--- Christian Robottom Reis <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 19, 2004 at 11:49:07PM -0800, Sridhar R
> wrote:
> > No. not multiple, only single. glade.XML()
> creates
> > the widgets immediately. My problem is to
> instruct
> > not to create (a particular widget say gtk.Window
> i.e.
> > toplevel in glade file) the widget immediately.
> So
> > that later I can pass my own widget (here
> gtk.Window
> > instance, a base class instance) to some func in
> > libglade so that it assigns properties acc. to
> glade
> > file and return completely designed (with children
> > added) window.
> >
> >
> > Again I tried this,
> >
> > class MyWind(gtk.Window):
> >
> >def __new__(cls, *args, **k):
> > xml = glade.XML('file.glade')
> > w = xml.get_widget('toplevel_wind')
> > return w
> >
> > def __init__(self):
> >pass
> >
> >
> > But the problem here is self (in __init__) is a
> base
> > class instance.
>
> Well, one way to work around this is to define the
> gtk.Window in your
> code, and have a dummy window defined in Glade that
> you destroy at
> startup:
>
> class MyWindow(gtk.Window): pass
>
> gladewin = xml.get_widget('fake_toplevel')
> win = MyWindow()
> child = gladewin.get_children()[0]
> child.reparent(win)
What about the properties of fake_toplevel windows
defined in glade. Aren't they got lost by default
properties of `win` instance?
> However, note that you'll loose keyboard
> accelerators tied to the fake
> toplevel. I've fought (and solved -- in GTK+ 1.2)
> this issue before; see
> http://bugs.async.com.br/show_bug.cgi?id=840 for
> details.
>
> > Is there any way to convert an base class instance
> to
> > derived class instance???
> > (Note: one cannot set the __class__ attr of
> instances)
>
> Why not? Do you mean any Python instance or just gtk
> instances? :-)
>
> >>> class Foo: pass
> ...
> >>> f = Foo()
> >>> class Bar: pass
> ...
> >>> f.__class__
>
> >>> f.__class__ = Bar
> >>> f.__class__
>
> Take care,
> --
> Christian Robottom Reis | http://async.com.br/~kiko/
> | [+55 16] 261 2331
=
Sridhar R
Email: [EMAIL PROTECTED]
WWW: http://sridhar.has.it
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] about widget creation in libglade
--- Christian Robottom Reis <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 17, 2004 at 04:31:33AM -0800, Sridhar R
> wrote:
> > I think the solution to this problem is libglade
> > should have a function that takes already created
> > widget (window?) as id and sets the properties on
> that
> > widget, then adding the children that widget.
> That
> > widget is commonly a gtk.Window. If libglade has
> such
> > a function them the above example could be written
> as
> > ..
> >
> > class MyWindowGreat(gtk.Window):
> > def __init__(self):
> > super(MyWindow, self).__init__()
> > self.gladexml = glade.XML('my.glade',
> > existing=self)
> > wind =
> self.gladexml.get_widget('main_window')
> > print wind is self # This is prints `True`
>
> How would you specify multiple pre-existing widgets?
No. not multiple, only single. glade.XML() creates
the widgets immediately. My problem is to instruct
not to create (a particular widget say gtk.Window i.e.
toplevel in glade file) the widget immediately. So
that later I can pass my own widget (here gtk.Window
instance, a base class instance) to some func in
libglade so that it assigns properties acc. to glade
file and return completely designed (with children
added) window.
Again I tried this,
class MyWind(gtk.Window):
def __new__(cls, *args, **k):
xml = glade.XML('file.glade')
w = xml.get_widget('toplevel_wind')
return w
def __init__(self):
pass
But the problem here is self (in __init__) is a base
class instance.
Is there any way to convert an base class instance to
derived class instance???
(Note: one cannot set the __class__ attr of instances)
=
Sridhar R
Email: [EMAIL PROTECTED]
WWW: http://sridhar.has.it
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] about widget creation in libglade
Jan Weil wrote:
> Of course you can design top-level windows in glade.
> The only difference is that doing so you don't
> subclass gtk.Window.
> Every time you need one of your toplevel windows you
> call
> g = glade.XML('file', 'toplevelname')
> w = g.get_widget('toplevelname')
> And you get a regular widget for which you can set
> properties afterwards.
>
> I think it only feels less OOP-like which is why I
> usually don't do it that way.
> Actually that means I have to set w's properties
> (like border_width) 'by hand'.But that usually only
> results in adding few more lines of code.
I think python metaclasses CAN SOLVE the problem.
I am justing getting my hands into metaclasses now.
Seems like one can assign a custom __new__ function in
the metaclass so that the widget can be created from
gladeXML inside our new __new__ function.
Have anybody got the solution (program) yet?
I am researching on this now. I'll post it if I
can find the solution.
May be if it worked, then next version of pygtk
should include it. ;-)
=
Sridhar R
Email: [EMAIL PROTECTED]
WWW: http://sridhar.has.it
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] about widget creation in libglade
> I usually design my window using glade.
> I call the child of the uppermost toplevel window
> 'child'.
> Then I subclass gtk.Window and add glade.
> get_widget("child") to it in __init__.
> If I understood you correctly this also solves your
> problem, doesn't it?
Agreed. But what if you have to set properties for
the top-level window. Your solution means one cannot
design top-level windows in glade and that has to be
done manually in the program, after which the `child`
widget as to be gtk_widget_add ed to the created
top-level window.
=
Sridhar R
Email: [EMAIL PROTECTED]
WWW: http://sridhar.has.it
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
[pygtk] about widget creation in libglade
Hi,
I have one doubt regarding libglade. How is it
creating the widgets from glade file. It seems like
the widgets are created during creation of GladeXML
object.
gxml = glade.XML('pathtogladefile')
I am searching for a way to _apply_ glade file to
existing widget (which is already created).
I will make the above point clearer. Look at the
following pygtk example, which doesn't use libglade.
class MyWindow(gtk.Window):
def __init__(self):
super(MyWindow, self).__init__()
# any other stuffs like adding widgets
win = MyWindow()
win.show()
The main advantage of this style is `win` is actually
_is_ a widget (a gtk.Window). So I call win.show()
instead of doing tricks like win.widget.show(). But
is it possible to achieve this advantage, when using
glade file for generating the UI. NO! I tried the
following.
class MyWindow2(gtk.Window):
def __init__(self):
super(MyWindow, self).__init__()
self.gladexml = glade.XML('my.glade')
wind = self.gladexml.get_widget('main_window')
Here there is a confusion. Actually there are _two_
windows in existense. One is `self` and other is
`wind`. To avoid this I should _not_ inherit from
gtk.Window. But this means the advantages of previous
example are lost.
I think the solution to this problem is libglade
should have a function that takes already created
widget (window?) as id and sets the properties on that
widget, then adding the children that widget. That
widget is commonly a gtk.Window. If libglade has such
a function them the above example could be written as
..
class MyWindowGreat(gtk.Window):
def __init__(self):
super(MyWindow, self).__init__()
self.gladexml = glade.XML('my.glade',
existing=self)
wind = self.gladexml.get_widget('main_window')
print wind is self # This is prints `True`
The _definition_ of glade.XML.__init__ looks something
like
(In C)
GladeXML *
glade_xml_new(... , GtkWidget *existing, ...)
{
if (existing == NULL){
existing = gtk_window_new(...)
}
...
}
/* just a thought */
Hopes that clears everything.
Thanks.
=
Sridhar R
Email: [EMAIL PROTECTED]
WWW: http://sridhar.has.it
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
___
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
