[pygtk] PyORBit examples page

2004-08-03 Thread Magnus Therning
I've almost finished my translation to Python of the examples in the
ORBit Beginners Documentation (v1.6)[1]. The last one is the
multi-threaded calculator and I am not too sure how useful it'll be to
do (except for my learning :-) so I've left it for now.

I would very much like to have some feedback on it all, suggestions for
improvement are especially welcome.

Also someone sent me a private email offering some help. Unfortunately I
lost the email (I have been known to do some aggressive cleaning of my
inbox at times), I'd love it if you contacted me again.

You can find the page here:
 http://magnus.therning.org/pyorbit_beg_exs.html

These are some of the things I've been pondering, any answers/comments
are welcome:

 1. I had a practical problem with putting Python code on a web page (
got lost) and I went looking for a py2html pretty printer that
didn't create outrageous stuff (basically I want something rather
low-key, and preferably not full html pages with body-tags and all
but rather output that can be included. I found nothing and swapped
to texinfo for the moment. Anyone with a solution to the problem?

 2. (This relates to the NameResolve example) I couldn't get
CORBA.ORB_init() to accept sys.argv (and hence I couldn't register a
name-service with -ORBInitRef NameService=IOR:... on the command
line. I probably made some trivial mistake. Any pointers?

 3. (This relates to the Factory example) With interfaces like this:

 module M {
  interface IA { .. };
  interface IB { IA createA(); };
 };

and Python classes like this:

 class myIA(M__POA):
  ...

 class myIB(M__POA):
  ...

then myIB.createA() can't be naively implemented like this:

 def createA(self):
  return myIA()

 but has to
  1. create, and keep an instance of myIA alive
  2. return that instance's _this()

 Why is it like this? (I guess it has its positive sides to not have
 the CORBA server-side representation of an object keep the instance
 alive, but I can't quite see them.)

 Anyone with an idea of how to kill the server-side Python instance
 immediately? (I currently simply remove it from the list (the list
 is the way I keep the objects alive in the first place) and garbage
 collection will get around to them, can I make sure it happens
 sooner?)

Well, that's it for now. Looking forward to being flooded with responses
;)

/M

1. http://www.gnome.org/projects/ORBit2/orbit-docs/orbit/index.html

-- 
Magnus Therning(OpenPGP: 0xAB4DFBA4)
[EMAIL PROTECTED]
http://magnus.therning.org/

Time is an illusion. Lunchtime doubly so.
 -- Douglas Adams


signature.asc
Description: Digital signature
___
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] PyORBit examples page

2004-08-03 Thread Steve McClure
On Tue, 2004-08-03 at 16:38, Magnus Therning wrote:
 I've almost finished my translation to Python of the examples in the
 ORBit Beginners Documentation (v1.6)[1]. The last one is the
 multi-threaded calculator and I am not too sure how useful it'll be to
 do (except for my learning :-) so I've left it for now.
 
 I would very much like to have some feedback on it all, suggestions for
 improvement are especially welcome.
 
 Also someone sent me a private email offering some help. Unfortunately I
 lost the email (I have been known to do some aggressive cleaning of my
 inbox at times), I'd love it if you contacted me again.
 
 You can find the page here:
  http://magnus.therning.org/pyorbit_beg_exs.html
 
 These are some of the things I've been pondering, any answers/comments
 are welcome:
 
  1. I had a practical problem with putting Python code on a web page (
 got lost) and I went looking for a py2html pretty printer that
 didn't create outrageous stuff (basically I want something rather
 low-key, and preferably not full html pages with body-tags and all
 but rather output that can be included. I found nothing and swapped
 to texinfo for the moment. Anyone with a solution to the problem?

I haven't used it in a while but enscript does a good job and can output
html. Something like enscript --color --pretty-print=python
--language=html -p [output_file] input_file should give you what you
want.

 
  2. (This relates to the NameResolve example) I couldn't get
 CORBA.ORB_init() to accept sys.argv (and hence I couldn't register a
 name-service with -ORBInitRef NameService=IOR:... on the command
 line. I probably made some trivial mistake. Any pointers?
 
  3. (This relates to the Factory example) With interfaces like this:
 
  module M {
   interface IA { .. };
   interface IB { IA createA(); };
  };
 
 and Python classes like this:
 
  class myIA(M__POA):
   ...
 
  class myIB(M__POA):
   ...
 
 then myIB.createA() can't be naively implemented like this:
 
  def createA(self):
   return myIA()
 
  but has to
   1. create, and keep an instance of myIA alive
   2. return that instance's _this()
 
  Why is it like this? (I guess it has its positive sides to not have
  the CORBA server-side representation of an object keep the instance
  alive, but I can't quite see them.)
 
  Anyone with an idea of how to kill the server-side Python instance
  immediately? (I currently simply remove it from the list (the list
  is the way I keep the objects alive in the first place) and garbage
  collection will get around to them, can I make sure it happens
  sooner?)
 
 Well, that's it for now. Looking forward to being flooded with responses
 ;)
 
 /M
 
 1. http://www.gnome.org/projects/ORBit2/orbit-docs/orbit/index.html
-- 
Steve McClure [EMAIL PROTECTED]

___
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

2004-08-03 Thread Graham Ashton
On Wed, 2004-07-28 at 16:54, Doug Quale wrote:
 Christian Robottom Reis [EMAIL PROTECTED] writes:
 
  The issue I raised was fear of namespace conflicts that would be
  introduced by this, but I think it's rather minor.
 
 I don't actually have a strong opinion whether that change would be
 good, bad or indifferent, so I was hoping someone smarter than me
 could give some good arguments one way or the other :)

Smarter? Not me. But I have experienced it both ways. At work we've got
a rather large app (80k lines of Python), a fair chunk of which is GUI
code. We use libglade and some classes that wrap it up in a similar
manner to many of the examples posted here. The basic principle is that
your GUI class inherits from our own GWidget type thing, in which you
write lines like this:

   list_store = self._widget.treeview.get_model()

We had minor disagreement when we initially started with these classes
as to whether that was more sensible than the aesthetically cleaner:

   list_store = self._treeview.get_model()

We approached it conservatively and ended up with _widget everywhere. A
year later I can confirm that it's a right pain in the arse. I don't
know of a single situation where the _widget has protected us from a
name space collision. You could reasonably point out that I wouldn't be
likely to notice as nothing is going to go blow up in my face. Still, I
attribute the lack of evidence to support _widget to the fact that we
try and keep our classes fairly small and directed, and put business
logic and UI control code in different classes (so there's nothing more
than widgets and callbacks in the GUI code in the first place).

I recently started an open soure app of my own and decided to experiment
with a different style. In my own app I would do this:

   list_store = self.treeview.get_model()

So far I'm enjoying the extra simplicity, but then my OS app is still
less than 1k lines. My classes aren't coming out larger or smaller than
they do at work though, and that's surely a more important issue.

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

It's small and clean and plenty good enough for small projects. Apart
from the automatic attribute access I'm a fan of being able to write
multiple classes to manage different parts of a GUI that just happen to
have been layed out in a single glade file. Band Saw's WidgetWrapper
allows you to do this:

  class Window(WidgetWrapper):

def __init__(self):
  WidgetWrapper.__init__(self, 'window1')  # window1 is in glade
  menu = Menu(self)
  ... blah blah ...

  class Menu(WidgetWrapper):

def __init__(self, window):
  WidgetWrapper.__init__(self, 'menu1', window)

The thing to note is that the Menu is passed the window, which already
has a glade.XML object within it. The Menu just re-uses the one that the
Window has already made, saving you the overhead of loading the glade
file twice (and saving you from having two windows pop up in the event
that your top level window is visible by default). Not rocket science,
but very handy.

It's by no means as clever as the one we've got at work, but that's
proprietary and I can't rip it off. It supports clever stuff like window
stacking (i.e. transiency), object tracking (to catch memory leaks) and
other nice goodies. None of it has been that hard to do.

--
Graham

___
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] Help: Problem with pygtk + py2exe

2004-08-03 Thread Jon Doda
Cedric Gustin wrote:
snip
You should also comment out the pygtk.require('2.0') as it is not 
compatible with a py2exe'd application.

All the necessary files will be in the dist subdir but you still have to 
install a GTK+ runtime though...

Works with pygtk-2.2.0 and pygtk-2.3.95 + the GTK+ runtimes from 
dropline (2.2) and gladewin32 (2.4).

Hope it helps.
Thanks, that did the trick.
--
Jon Doda
___
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

2004-08-03 Thread Sridhar R
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/


[pygtk] a widget like gimp's canvas

2004-08-03 Thread Johannes Zellner
Hi,

is there something like gimp's canvas (scrollable drawingarea with rulers
which scroll simulaneously with the drawingarea) for pygtk? -- maybe as
code sample?

-- 
Johannes
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/