Re: [pygtk] PyGTK Faq
Christian> Sounds reasonable. Would you (anybody, really) have a Christian> suggestion of sections for us? Right now I have: Christian> 1. General Information and Availability Christian> 2. Widget Issues Christian> 3. Themes and Styles Christian> 4. Signal handling Christian> 5. Miscellaneous Christian> I understand that Widget Issues is pretty bad naming (I was Christian> aware at the time) but I wanted to get started and these Christian> things (naming..) hamper work. But now I think I am prepared Christian> to change it sooner than later. So what should I do? Christian> a) have a section for each widget? Christian> b) have a section for groups of widgets? Christian> c) have one big section like i do now? I'd go with b, perhaps patterning it after the section breakdown in the Gtk ref manual table of contents. I think having a 1.2 vs. 1.3 section might be a good idea as well. If nothing else, it might get people to realize the API has changed significantly. Skip ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] PyGTK Faq
On Mon, 28 Jan 2002, Skip Montanaro wrote: > One thing that might help to generate more input and to lessen your load is > to add questions without answers when you realize they are faqs (should be a > lot lower effort on your part than trying to come up with answers as well). > Every now and again (monthly?) post a list of what questions lack answers. I have assorted a number of emails that answer things and I just have to stick them in as questions. > > I'd be willing to help. Send me the password when you think of it. One Okay. > thing that's worth noting about the FAQ wizard is that it's relatively > difficult to reorganize things if a section grows too large, so it helps to > have a reasonable structure set up before questions start flowing in. Sounds reasonable. Would you (anybody, really) have a suggestion of sections for us? Right now I have: 1. General Information and Availability 2. Widget Issues 3. Themes and Styles 4. Signal handling 5. Miscellaneous I understand that Widget Issues is pretty bad naming (I was aware at the time) but I wanted to get started and these things (naming..) hamper work. But now I think I am prepared to change it sooner than later. So what should I do? a) have a section for each widget? b) have a section for groups of widgets? c) have one big section like i do now? Maybe signal handling will end up being pretty short I need to add a section for libglade issues, I suppose? Any suggestions? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] .show()ing a TreeView deadlocks still.
I'm using lastest Gtk1.3 and pygtk-1.99 from CVS. Pygtk is compiled with threads enabled. If i call gtk.threads_init then .show()ing a gtk.TreeView deadlocks. (gdb) bt #0 0x4015ea0e in sigsuspend () from /lib/libc.so.6 #1 0x400fe629 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 0x401006c6 in __pthread_alt_lock () from /lib/libpthread.so.0 #3 0x400fcd82 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0x40602596 in gdk_event_prepare (source=0x8070378, timeout=0xb7ec) at gdkevents-x11.c:1708 #5 0x402c0048 in g_main_context_prepare (context=0x80703a8, priority=0xb82c) at gmain.c:1921 #6 0x402c0682 in g_main_context_iterate (context=0x80703a8, block=1, dispatch=1, self=0x8091290) at gmain.c:2209 #7 0x402c0e3a in g_main_loop_run (loop=0x81c24c0) at gmain.c:2449 #8 0x40477c2b in gtk_main () at gtkmain.c:812 #9 0x40378027 in _wrap_gtk_main (self=0x0) at gtk.override:1929 #10 0x4008bed7 in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.2.so.0.0 #11 0x4008a4c1 in Py_MakePendingCalls () from /usr/lib/libpython2.2.so.0.0 #12 0x4008b594 in PyEval_EvalCodeEx () from /usr/lib/libpython2.2.so.0.0 #13 0x4008d89a in PyEval_EvalCode () from /usr/lib/libpython2.2.so.0.0 #14 0x400ab524 in PyOS_setsig () from /usr/lib/libpython2.2.so.0.0 #15 0x400ab4cf in PyOS_setsig () from /usr/lib/libpython2.2.so.0.0 #16 0x400ab15d in PyRun_FileExFlags () from /usr/lib/libpython2.2.so.0.0 #17 0x400a9bcf in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.2.so.0.0 #18 0x400aacf7 in PyRun_AnyFileExFlags () from /usr/lib/libpython2.2.so.0.0 #19 0x400b1097 in Py_Main () from /usr/lib/libpython2.2.so.0.0 #20 0x08048624 in main () #21 0x4014e65f in __libc_start_main () from /lib/libc.so.6 It is very easy to reproduce (i stuck in a code snippet last post) Any ideas? -- Tom Morton ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] PyGTK Faq
> Skip Montanaro <[EMAIL PROTECTED]> writes: > > > >> Where is the faq ... > > Christian> I'm working on one in my spare time (which is why it is still > Christian> so short) at http://www.async.com.br/faq/pygtk/ > > Christian, > > One thing that might help to generate more input and to lessen your load is > to add questions without answers when you realize they are faqs (should be a > lot lower effort on your part than trying to come up with answers as well). > Every now and again (monthly?) post a list of what questions lack answers. > > I'd be willing to help. Send me the password when you think of it. One > thing that's worth noting about the FAQ wizard is that it's relatively > difficult to reorganize things if a section grows too large, so it helps to > have a reasonable structure set up before questions start flowing in. > Otherwise everything will wind up in one section. (Witness the Python FAQ.) > > Skip > ___ > pygtk mailing list [EMAIL PROTECTED] > http://www.daa.com.au/mailman/listinfo/pygtk That sounds like a good suggestion, I would be glad to contribute if I find something on the list that I actually know. -- Steve McClure 430 10th St NW Racemi Suite N-210 http://www.racemi.com Atlanta, GA 30318 [EMAIL PROTECTED] voice/fax: 404-892-5850 ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] PyGTK Faq
>> Where is the faq ... Christian> I'm working on one in my spare time (which is why it is still Christian> so short) at http://www.async.com.br/faq/pygtk/ Christian, One thing that might help to generate more input and to lessen your load is to add questions without answers when you realize they are faqs (should be a lot lower effort on your part than trying to come up with answers as well). Every now and again (monthly?) post a list of what questions lack answers. I'd be willing to help. Send me the password when you think of it. One thing that's worth noting about the FAQ wizard is that it's relatively difficult to reorganize things if a section grows too large, so it helps to have a reasonable structure set up before questions start flowing in. Otherwise everything will wind up in one section. (Witness the Python FAQ.) Skip ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] PyGTK Faq
On Mon, 21 Jan 2002, Markus Schaber wrote: > > 1)Where is the faq or basic documentation, such as a listing of modules > > and a package/module hierarchy? From digging through the archive, I'm > > guessing not. > > For python, you should find this on www.python.org. > > For gtk, www.gtk.org has the pointers. > > I don't know of any greater pygtk specific documentation, except the one > that comes with the package, and some examples in some python tutorials. I'm working on one in my spare time (which is why it is still so short) at http://www.async.com.br/faq/pygtk/ If anybody is willing to volunteer to help add stuff, i'm happy to comply and help. Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] A class to add to libglade.py
On Tue, 22 Jan 2002, Mitch Chapman wrote: > > Anyway, I was thinking of how to use Python in the context of a RAD, using > > Glade as the GUI-builder. The signal autoconnect is nice, but it would be > > even better if the user didn't have to create the dictionary, and all of > > the functions were bound to an object instance. Anyway, I came up with > > the following class that you can just stick in libglade.py: > > Also see the GladeBase package (which I *really* need to > turn into a proper project, and update w. recently received > contributions...). It's available here in the form of several > source code listings: > ftp://ftp.ssc.com/pub/lj/listings/issue87/4702.tgz Code dupes rock. I also developed something similar for Kiwi, though I also provide making selected widgets into members of a view instance (so you can use view.clist or view.entry for instance). Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 272 3330 | NMFL ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
