Re: [pygtk] how to get the glade file

[Mitch Chapman]

Alexandre Fayolle wrote:
> 
> I'm certainly not the first one to encounter the problem. I have an
> application with a gtk gui built using libglade.
> 
> Right now, the glade file is in the same directory as the python file, and
> this works as long as I launch the python script from that directory. I
> would like to make things a bit more less 'hardcoded'. I've come up with
> the following hack. Let's say the python module is called
> my_application.py, and the glade file is my_application.glade. In the
> module I have:
> 
> import my_application # import oneself
> import os.path
> GLADE_FILE = os.path.join(os.path.dirname(my_application.__file__),
>   'my_application.glade')
> 
> It does the job, but I'm not sure that this ios the right way of doing
> things. Any comments ?

Please have a look at PathFinder.py
( 
http://www.linuxjournal.com/modules.php?op=modload&name=NS-lj-issues/issue87&file=4702l2
 )
and the accompanying article about GladeBase, a high-level wrapper
over libglade:
( http://www.linuxjournal.com/article.php?sid=4702 )

PathFinder enables you to store files, e.g. Glade design files, 
in the same directories as your Python modules, and then to find 
them by specifying their paths relative to the Python path.  So
your example could be written so:

import PathFinder

GLADE_FILE = PathFinder.find('my_application.glade')


GladeBase offers several other features.  For instance it
lets you write Controller classes whose Gtk+ signal handlers are
automatically identified and connected at runtime.  It also includes
a stub generator which can read a Glade design file and generate a 
Controller class complete with signal handler stubs for all signals 
defined in the design file.

The article includes all of the source code for GladeBase.
I'm still trying to set up a more permanent home for GladeBase, 
hence the pointers to the article.

-- 
Mitch
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk

Re: [pygtk] A class to add to libglade.py

[Mitch Chapman]

Jonathan Bartlett wrote:
> 
> I'm fairly new to Python, and I just learned pygtk today, so forgive me if
> this is redundant somewhere in pygtk.
> 
> 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

GladeBase is explained in this Linux Journal article:
http://www.linuxjournal.com/article.php?sid=4702

The package includes automatic signal connection and supports
finding/loading Glade files on the Python path.  It also includes
a module, ControllerGenerator.py, (4702l4.txt in the above tarball)
which can generate GladeBase controllers with stubs for all of the 
signals defined in a Glade design file.

-- 
Mitch Chapman
[EMAIL PROTECTED]
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk

Re: [pygtk] Window Stacking Problem

[Mitch Chapman]

Aaron Optimizer Digulla wrote:
> 
> On Wed, Jul 26, 2000 at 11:35:30AM -0600, Mitch Chapman wrote:
> 
> > It may be that I'm solving the wrong problem.  In other words,
> > there may be a better way to present the information that's
> > currently being displayed in these modeless dialogs.  But if
> > y'all have any suggestions for how to solve this specific
> > problem, I'd be grateful.
> 
> The correct solution would be to fix the customer :-)
> The reason why you cannot iconify modal dialogs independently
> of your application is the human brain: Just imagine, your
> working with your app and then suddenly, one of the modal
> dialogs is in your way and you iconify it. Now you do
> what you wanted when the dialog got in your way. After
> some time, you go back to your app and try to continue
> to work with it. But now it "hangs". You try everything
> and after some time kill the app and start it again because
> you didn't remember that there was an iconified modal dialog
> which blocked the "hanging" application.
> 
> Conclusion:
> 
> - Don't use modal dialogs. Disable gadgets instead. This
> gives the user a visual feedback of what is going on
> unlike the modal dialogs. What you can do is you can
> disable the main window of the application. This will
> make the (non-modal) dialogs independent of it and you
> can iconify every window indepently. Also, a user
> will now see right away why he cannot work with the
> application.

Well-put, but my customer wants mode*less* dialogs.
They want to be able to continue working with the main
application after the dialog appears.

Imagine a window full of thumbnail vector images.  A single
left-click on a thumbnail brings up a resizable window
showing a larger view of the window.  The number of
thumbnails, and consequently the number of enlarged views,
can be quite large.  That's what the current specs call for.

Here's the problem scenario:  The user has clicked on a
thumbnail and gotten a larger view.  Now the user wants to
go back to the main window and click on another thumbnail
to get another larger image to compare to the first.  As soon
as they click on the new thumbnail the main window comes
forward, obscuring the original thumbnail.

You and I know that, with most window managers, you can just go
back to the taskbar and bring the original zoomed view forward
again.  And our users know that, too.  But in practice I've seen 
them get confused (not to mention annoyed) when their original
zoomed view "disappears".

The most obvious solution is to make the zoomed views transients
for the main window, so they always stay in front of it.  But
this would force the user to keep dragging the zoomed views out of
the way, so they could see enough of the main window to get at
other thumbnails.  Hence (I think) the request to make the zoomed
views stay in front of, but be separately iconifiable from,
the main window.

We need to look at the usage scenarios in more detail.  For
instance, if the users tend to view only two or three zoomed
views at a time, then it might not be so annoying to make
them transients for the main window.  Screen real estate being
what it is, I can't imagine them trying to look at very many
zoomed views at once.

But a completely different solution might be much better.  This
is what you're saying, and is also what I meant by "solving the 
wrong problem."

For instance, since users seem to be trying to compare zoomed images,
it might make sense to grid the views into a zoom "dock", one which
comes forward every time its content changes, but is not a transient
for the main window.  This would let the user create comparative
views without manually dragging modeless dialogs into position, and
would also get around the problem of screen-blocking transients.

Guess it's time for another prototype.  Thanks for helping
trigger some ideas.

-- 
Mitch Chapman
[EMAIL PROTECTED]

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk

Re: [pygtk] RE: Loading PNGs

[Mitch Chapman]

[EMAIL PROTECTED] wrote:
> 
> On Mon, 31 Jul 2000 10:29:55 +0200, Javi Roman <[EMAIL PROTECTED]> wrote:
> > > I have the following code:
> > >
> > > from gtk import *
> > >
> > > rcfile = """
> > > pixmap_path "/home"
> > > style "back" {
> > >bg_pixmap[NORMAL] = "image.xpm"
> > > }
> > > widget "*mystyle" style "back"
> > > """
> > >
> > > Everything works correctly. But the load of the image is very slow,
> > > therefore I have tried to use the following thing:
> > >
> > > from gtk import *
> > >
> > > rcfile = """
> > > pixmap_path "/home"
> > > style "back" {
> > >bg_pixmap[NORMAL] = "image.png"
> > > }
> > > widget "*mystyle" style "back"
> > > """
> > >
> > > It does not load the PNG image, why?.
> > > In other programs I have seen that they load PNG images without
> > > problems.
> 
> Note: I don't know much about the gtk rc stuff.
> 
> I think what you've seen the other programs use is a gtk-theme-engine,
> not the "regular" rc parsing.

I just did some digging around in the Gtk+ source code, and it looks
as though, by default, Gtk+ knows how to load XPM images only.
>From gtk+-1.2.7/gtk/gtkrc.c\gtk_rc_load_image():

  if(image_loader)
return image_loader(NULL, colormap, NULL,
transparent_color,
filename);
  else
return gdk_pixmap_colormap_create_from_xpm (NULL, colormap, NULL,
transparent_color,
filename);

image_loader is a static GtkImageLoader, visible only within 
gtkrc.c.  It is set via the public function gtk_rc_set_image_loader.
This function is not wrapped by gnome-python, and appears not to be
used by any of the Gtk+ theme engines.  But they all appear to use
their own image loaders.  (This is a guess based on output from nm;
I don't have the sources lying around.)

A "find | grep" through the themes that come with Helix-Gnome shows
that every theme specifies an .XPM file when setting bg_pixmap
resources.
(Okay, some of them specify "".)

In short, if you want to use a PNG file, it looks like you have to
use a theme engine.  

Like acano, I'm not well-versed with theme engines.  If you have a 
Mandrake system, have a look at the gtkrc files under 
/usr/share/themes.

-- 
Mitch Chapman
[EMAIL PROTECTED]

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk

Re: [pygtk] Window Stacking Problem

[Mitch Chapman]

James Henstridge wrote:
> Note that the set_transient_for() hint is a window manager hint, and is
> not interpretted the same by all window managers (some even allow the user
> to control how it is handled, some ignore it), so it may just be your
> window manager that prevents the separate iconification.  Unless you can
> control what window manager is in use, this requirement may be very
> difficult to implement.

As you imply, we can't control the window manager in use.  The short
list is kwm, mwm, IRIX (4dwm?) and whatever the heck Exceed uses.
And in any case, every window manager I've ever used has interpreted 
set_transient_for() as "put this window into the same group
with its master, and iconify them as a group".  So the behavior is
consistently not what I want :)

Thanks for the feedback.  You're making it clear that I need to
rethink presentation of "zoomed" content.

Or maybe we should just upgrade our gnome-python installation.
1.0.53 exposes gdk_window_raise()...

--
Mitch Chapman
Finding a deeper quagmire

P.S. I used to use Sunsoft's Teamware quite a bit.  You could detect
 new Teamware users by sound:  first you'd hear cursing, as they
 discovered Teamware's fondness for transient windows; then you'd
 hear lots of mouse-scraping as they tried to drag those windows
 out of the way.

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk

[pygtk] Window Stacking Problem

[Mitch Chapman]

I'm not sure where to ask this, so will bug you all. :)

I'm working on a pygtk application which has a main window and 
several modeless dialogs.  The customer has requested that the
modeless dialogs always stay in front of the main window, but that
they be separately iconifiable.  (The dialogs just present zoomed
depictions of the same basic type of data.)

The first requirement is easy: just use set_transient_for().
The second requirement is also easy:  just don't use 
set_transient_for().  Does anybody have suggestions for 
accomplishing both of these tasks at once?

It may be that I'm solving the wrong problem.  In other words,
there may be a better way to present the information that's
currently being displayed in these modeless dialogs.  But if
y'all have any suggestions for how to solve this specific
problem, I'd be grateful.

--
Mitch Chapman
[EMAIL PROTECTED]

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk

Re: [pygtk] GtkRadioMenuItem and libglade

[Mitch Chapman]

libglade 0.13 does nothing with the "group" attribute of radio
menu items, so every GtkRadioMenuItem ends up in its own group.

Fortunately, libglade *does* honor the group attribute for
GtkRadioButtons.  Using the code in glade-gtk.c\radiobutton_new()
as an example, I was able to come up with (okay, cut & paste :)
a patch to glade-gtk.c\radiomenuitem_new() which lets
GtkRadioMenuItems be grouped properly.

The attached context diffs show the required changes.  Again, the
changes are for libglade 0.13, for the module glade/glade-gtk.c.

--
Mitch Chapman
[EMAIL PROTECTED]

Harry Henry Gebel wrote:
> 
> I have a set of three menu options I have set as GtkRadioMenuItem in Glade,
> I set each to have group 'search_mode'. When I run the program using
> libglade, all three are turned on as though each was in a different
> group. Am I misunderstanding how to use the 'group' entry in Glade, and if
> so how do I get these three buttons into the same group? I am currently
> using GtkCheckMenuItem and being careful to only have one set at a time,
> but I would rather use GtkRadioMenuItem .
> 
> I am using gtk v 1.2.7, pygtk 0.6.6, libglade 0.12, glade 0.5.8,
> gnome-libs 1.0.54, and pygnome 1.0.53 . I am running Mandrake 7.0 .
> 
> --
> Harry Henry Gebel, Senior Developer, Landon House SBS
> West Dover Hundred, Delaware
> -
> To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]


*** glade-gtk.c.new Tue Jun 20 08:24:56 2000
--- glade-gtk.c.origTue Jun 20 08:25:53 2000
***
*** 23,29 
  #include "config.h"
  #endif
  
- #include 
  #include 
  #include 
  #include 
--- 23,28 
***
*** 1894,1901 
GList *tmp;
char *label = NULL;
gboolean right = FALSE, active = FALSE, toggle = FALSE;
-   GSList *group = NULL;
-   char *group_name = NULL;
  
for (tmp = info->attributes; tmp; tmp = tmp->next) {
GladeAttribute *attr = tmp->data;
--- 1893,1898 
***
*** 1908,1923 
active = attr->value[0] == 'T';
else if (!strcmp(attr->name, "always_show_toggle"))
toggle = attr->value[0] == 'T';
- else if (!strcmp(attr->name, "group")){
-   group_name = attr->value;
-   group = g_hash_table_lookup (xml->priv->radio_groups,
-group_name);
-   if (!group)
-   group_name = g_strdup(group_name);
- }
}
  
!   menuitem = gtk_radio_menu_item_new_with_label(group, "");
if (label){
char *s = label [0] ? _(label) : "";

--- 1905,1914 
active = attr->value[0] == 'T';
else if (!strcmp(attr->name, "always_show_toggle"))
toggle = attr->value[0] == 'T';
}
  
!   /*  -- must do something about radio item groups ... */
!   menuitem = gtk_radio_menu_item_new_with_label(NULL, "");
if (label){
char *s = label [0] ? _(label) : "";

***
*** 1943,1956 
  
if (right)
gtk_menu_item_right_justify(GTK_MENU_ITEM(menuitem));
- 
-   if (group_name) {
-   GtkRadioMenuItem *radio = GTK_RADIO_MENU_ITEM(menuitem);
-   
-   g_hash_table_insert (xml->priv->radio_groups,
-group_name,
-gtk_radio_menu_item_group (radio));
-   } 
gtk_check_menu_item_set_state(GTK_CHECK_MENU_ITEM(menuitem), active);
gtk_check_menu_item_set_show_toggle(GTK_CHECK_MENU_ITEM(menuitem), toggle);
  
--- 1934,1939 

*** glade-gtk.c.new Tue Jun 20 08:24:56 2000
--- glade-gtk.c.origTue Jun 20 08:25:53 2000
***
*** 23,29 
  #include "config.h"
  #endif
  
- #include 
  #include 
  #include 
  #include 
--- 23,28 
***
*** 1894,1901 
GList *tmp;
char *label = NULL;
gboolean right = FALSE, active = FALSE, toggle = FALSE;
-   GSList *group = NULL;
-   char *group_name = NULL;
  
for (tmp = info->attributes; tmp; tmp = tmp->next) {
GladeAttribute *attr = tmp->data;
--- 1893,1898 
***
*** 1908,1923 
active = attr->value[0] == 'T';
else if (!strcmp(attr->name, "always_show_toggle"))
toggle = attr->value[0] == 'T';
- else if (!strcmp(attr->name, "group")){
-  

Re: [pygtk] Which event correspond to window resize !?

[Mitch Chapman]

'configure_event' will (I think) be invoked whenever the window is
resized, moved, or restacked, or whenever its border width changes.

That's assuming 'configure_event' has the same semantics as the X11
ConfigureRequest event.

Rick Ree wrote:
> 
> I connected to the 'size_allocate' event, which seems to work.
> 
> Rick
> 
> On Wed, 10 May 2000 [EMAIL PROTECTED] wrote:
> 
> >
> > Hi,
> >
> >   Can anybody tell me which event occurs when a window is being
> > resized ? (I tried "rsize_event" but with no success")

--
Mitch Chapman
[EMAIL PROTECTED]
-
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

[pygtk] GnomeAbout, gnome.app_id and gnome.app_version

[Mitch Chapman]

[Using gnome-python 1.0.52, libglade 0.12, and
gnome-lib 1.0.14 -- admittedly old, but it came with Mandrake 6.1.]

I'm trying to figure out how to get an application's name
and version to show up in its About dialog.

gnome/__init__.py handles the case where the application is
run as a command whose name ends in .py[oc]? and appears to
hardware the application version number to '0.0'.

So far I can see only one way to override these settings:

import gnome
gnome.app_id = "SomeApp"
gnome.app_version = "0.3 alpha"
import gnome.ui

Is there a better way?

Along the same lines, I'm finding it necessary to import 
gnome.ui before importing libglade.  Otherwise a segmentation
fault occurs.  Paraphrasing (not in front of the development
machine just now):

GnomeUI-CRITICAL **: file gnome-app.c: line 206 (gnome_app_new):
assertion 'appname != NULL' failed.

Is it necessary to explicitly import gnome.ui before importing 
libglade?

--
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Senility [was Re: [pygtk] timeout causes lockup?]

[Mitch Chapman]

Doh!

Just checked, and my Linux box at work has only Gtk+ 1.2.3
installed.  It's the machine at home that has 1.2.6 installed.

Of all the things I've lost in life
I miss my mind the most.

Mitch Chapman wrote:
> 
> On Sun, 27 Feb 2000, you wrote:
> > There were some threading bugs in some early versions of gtk+
> > (specifically with events_pending() and mainiteration()). You should
> > really use gtk+ >= 1.2.4.  I should have this check in the configure
> > script.
> ...
> I'm probably missing something, but the foregoing doesn't seem to
> explain the different behaviors between Linux and Solaris.  Both
> machines have Gtk+ 1.2.6 and pygtk 0.6.2.

--
Mitch
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] timeout causes lockup?

[Mitch Chapman]

On Sun, 27 Feb 2000, you wrote:
> There were some threading bugs in some early versions of gtk+
> (specifically with events_pending() and mainiteration()). You should
> really use gtk+ >= 1.2.4.  I should have this check in the configure
> script.
> 
> The other possible difference between the mandrake is if one was compiled
> with threading and the other wasn't.


I'm probably missing something, but the foregoing doesn't seem to 
explain the different behaviors between Linux and Solaris.  Both
machines have Gtk+ 1.2.6 and pygtk 0.6.2.

Tomorrow I'll try to find out how the software was configured on
Solaris.  Sorry for the stupid question, but when you say "compiled
with threading" are you referring to Gtk+, pygtk, or Python?

Thanks for info.
-- 
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] timeout causes lockup?

[Mitch Chapman]

Here's an excerpt from a module of miscellaneous pygtk functions.
It shows three platform-dependent implementations of an update()
function.  update() is used e.g. to update a progress bar
in the middle of a time-consuming operation -- it's analogous to
the Tkinter update() function.

I haven't bothered looking at Gtk+ or pygtk sources in order to figure 
out why you need threads_(enter|leave) on Solaris but not on Linux.
If somebody could explain the difference I'd be grateful.

One last note:  This code was tested w. pygtk 0.6.2, on all
three platforms.

--
Mitch
[EMAIL PROTECTED]

-snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip-
# On IRIX we're running Gtk+ version 1.2.3.  On Solaris and Linux we're
# running 1.2.6.
# On Linux, when performing a "manual" event loop to update the display,
# you gotta be careful to release the Gtk+ mutex by calling
# threads_(enter|leave).  If you don't, the app will lock up when it
# checks for pending events.
# On IRIX, you can't call threads_enter, because we're using an old
# version of pygtk which doesn't expose the threads_(enter|leave)
# calls.
# On Solaris, you can't call threads_(enter|leave) because if you do
# the app will lock up when it checks for pending events.
#
# This all seems pretty bogus.  But the following code works...

if sys.platform[:5] == "linux":
def update():
"""Update the UI: flush pending rqsts and process pending events."""
gtk.gdk_flush()
gtk.threads_leave()
while gtk.events_pending():
gtk.mainiteration(0)
gtk.threads_enter()

elif sys.platform[:5] == "sunos":
def update():
"""Update the UI: flush pending rqsts and process pending events."""
gtk.gdk_flush()
while gtk.events_pending():
gtk.mainiteration(0)

else:
# For IRIX w. Gtk+ 1.2.3:
def update():
"""Update the UI: flush pending rqsts and process pending events."""
# This solution was recommended on the pygtk mailing list, 
# by Bernhard Herzog <[EMAIL PROTECTED]>, the author of Sketch.
# Speculation is that this is all due to a bug in recent versions
# of Gtk+, e.g. 1.2.3 - 1.2.6.
if hasattr(gtk, "gdk_flush"):
gtk.gdk_flush()
if hasattr(gtk, "threads_leave"):
gtk.threads_leave()
while gtk.events_pending():
gtk.mainiteration(0)
if hasattr(gtk, "threads_enter"):
gtk.threads_enter()
-snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip--snip-


Mitch Chapman wrote:
> 
> On Sat, 26 Feb 2000, Scott Bender wrote:
> > Actually, the hang came after my timeout function completed. It was calling 
>mainiteration(FALSE) to
> > update a progress bar, which was causing the hang. Anyone know why?
> >
> > thanks,
> > - Scott
> 
> I've seen this recently.  The behavior varies depending on what version
> of Gtk+ you're running with, and on what operating system.
> 
> The basic problem is that, on some platforms, even w. Gtk+ 1.2.6,
> you need to surround calls to gtk.events_pending() and
> gtk.mainiteration() with calls to gtk.threads_leave() and
> gtk.threads_enter(). On others (e.g. Solaris) you *shouldn't* do so.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] timeout causes lockup?

[Mitch Chapman]

On Sat, 26 Feb 2000, Scott Bender wrote:
> Actually, the hang came after my timeout function completed. It was calling 
>mainiteration(FALSE) to 
> update a progress bar, which was causing the hang. Anyone know why?
> 
> thanks,
> - Scott

I've seen this recently.  The behavior varies depending on what version
of Gtk+ you're running with, and on what operating system.

The basic problem is that, on some platforms, even w. Gtk+ 1.2.6,
you need to surround calls to gtk.events_pending() and
gtk.mainiteration() with calls to gtk.threads_leave() and
gtk.threads_enter(). On others (e.g. Solaris) you *shouldn't* do so.

I'll trudge in to the office in a bit and forward some relevant code,
showing how to work around the problem on a handful of OS platforms.

-- 
Mitch Chapman
[EMAIL PROTECTED]

P.S.  This probably sounds kind of bogus.  That's why I've not posted
comments on it before -- I'm probably missing something obvious.
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] Destroy event?

[Mitch Chapman]

You'll probably find that connecting to "delete_event" has the
desired result.  I don't know why "destroy_event" doesn't work.

BTW if you do decide to connect to "delete_event" you'll need an extra
argument:

def _kill(window, event, obj):
print "Aaagh!"
gtk.mainquit()

Also BTW thanks for showing how to use pdb.set_trace().  I don't
use pdb much, and have been looking for a function which does what
set_trace() seems to do.

On Mon, 14 Feb 2000, you wrote:
> OK, folks...how come this doesn't report a "destroy_event"?  What am I
> doing wrong?
> [code snipped]

-- 
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

[pygtk] GtkExtra.MenuFactory and option menus

[Mitch Chapman]

If you create an option menu using GtkExtra.MenuFactory, the resulting
menu is "squashed", and initially appears with no default setting.

The reason turns out to be simple, and typical of Gtk+. If you
associate a GtkMenu with a GtkOptionMenu before adding items to the
GtkMenu, the GtkOptionMenu behaves as above.  If you wait until the
GtkMenu is fully populated, the GtkOptionMenu displays a default
selection and has a reasonable size.

I tried a couple of different mods to GtkExtra.MenuFactory, hoping to
apply the above workaround without breaking any existing behavior. 
And failed.  (I haven't tried refactoring MenuFactory into a set of
related classes.  Maybe tomorrow...)

Instead, here's a hacky workaround: a subclass which re-attaches the
GtkMenu to its GtkOptionMenu every time a new menu item is created.

import GtkExtra

class OptionMenuFactory(GtkExtra.MenuFactory):
def create(self, path, accelerator=None, callback=None, *args):
"""Work around a Gtk+ bug:  if you set_menu on a GtkOptionMenu
before the corresponding GtkMenu has been fully populated, the  
result is a 'squished', initially blank option menu.

A better workaround might be to refactor GtkExtra.MenuFactory
into a hierarchy of classes."""
result = apply(GtkExtra.MenuFactory.create,
   (self, path, accelerator, callback) + args)
self._MenuFactory__ret.remove_menu()
self._MenuFactory__ret.set_menu(self._MenuFactory__w)
return result

--
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

[pygtk] pygtk 0.6.2: Bugs involving GtkAdjustments

[Mitch Chapman]

Well, I *think* it's pygtk 0.6.2.  In any case it's in the pygtk version
included with gnome-python-1.0.4.

gtk.py contains a bug in the definition of
GtkSpinButton.get_adjustment().   'sel._o' should be 'self._o' on line
2090.

Also, GtkAdjustment.set_all() causes an exception when invoked:
  File "/usr/local/lib/python1.5/site-packages/gtk.py", line 198, in set_all
page_size)
TypeError: gtk_adjustment_set_all requires exactly 1 argument; 7 given

Here's the code in gtkmodule.c, at line 3698, which generates the
error message:

if (!PyArg_ParseTuple(args, "O!:gtk_adjustment_set_all", &PyGtk_Type,
  &obj, &value, &lower, &upper, &step_increment,
  &page_increment, &page_size))

Looks like the format string for PyArg_ParseTuple() is missing a few
entries.

--
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

Re: [pygtk] How to display a busy cursor?

[Mitch Chapman]

J.W. Bizzaro wrote:
> 
> Mitch Chapman wrote:
> >
> > Is there an easy way to temporarily display a busy cursor over
> > a window?
> > ...I can't figure out how to restore the previous cursor on
> > the window, or even how to find out what the previous cursor is.
> 
> I haven't tried it, but this would be my guess:
> 
> widget.get_window().set_cursor(None)

Alas, no joy:

Traceback (innermost last):
  File "/usr/local/lib/python1.5/site-packages/gtk.py", line 114, in
__call__
ret = apply(self.func, a)
  File "", line 96, in enterTextCB
  File "", line 58, in run
TypeError: GdkWindow.set_cursor, argument 1: expected GdkCursor, None
found


And I can't pass a None to gtk.cursor_new(), either:

Traceback (innermost last):
  File "/usr/local/lib/python1.5/site-packages/gtk.py", line 114, in
__call__
ret = apply(self.func, a)
  File "", line 97, in enterTextCB
  File "", line 58, in run
  File "/usr/local/lib/python1.5/site-packages/gtk.py", line 2495, in
cursor_new
return _gtk.gdk_cursor_new(type)
TypeError: enum values must be integers or strings


-- 
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

[pygtk] How to display a busy cursor?

[Mitch Chapman]

Is there an easy way to temporarily display a busy cursor over
a window?

testgtk.py shows how to set a new cursor on a window.
But I can't figure out how to restore the previous cursor on
the window, or even how to find out what the previous cursor is.

It looks as though Gtk+ lets you restore the default cursor
(which may/may not be the previous cursor) just by setting a 
cursor of NULL on the window.  Dunno how to do this from pygtk.

Thanks for the help.

-- 
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

[pygtk] Which version of gtkglarea?

[Mitch Chapman]

Hi,

I've been trying to build gnome-python-1.0.4 on a Linux 2.0.36
system, and have been having problems integrating the
GtkGlArea widget.

When I try to run one of the demos from pygtk/examples/gl,
I get a runtime link error saying gtk_gl_area_swap_buffers is
undefined.

The latest version of GtkGlArea from http://www.student.oulu.fi/~jlof/gtkglarea/
(v. 1.2.1) defines a gtk_gl_area_swapbuffers (note the missing underscore),
but no gtk_gl_area_swap_buffers.

The same holds true for the latest version from the GNOME CVS
repository.

Which version of GtkGlArea does pygtk 0.6.2 expect to use?

Thanks for the help.
--
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

[pygtk] Getting X Window / pixmap ID

[Mitch Chapman]

Sorry, I should be able to figure this out, but
how do I get the XWindow ID of a GdkWindow or a
GdkPixmap?

Is there a FAQ where I can look this up, or an
archive of the pygtk mailing list?

Thanks for all help.

-- 
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]

[pygtk] get_column_pixtext, null pixmap masks

[Mitch Chapman]

When I invoke get_column_pixtext() on the first column of
a GtkCTree, I get the following message on stderr:

Gdk-CRITICAL **: file gdkwindow.c: line 716: assertion `window != NULL'
failed.

The apparent reason is that the tree returns both a NULL pixmap mask
and a NULL pixmap.  (Yet you must use ...get_pixtext() to get the
text of the first column, because of the cell type.)

gtkmodule's _wrap_gtk_ctree_node_get_pixtext() already checks for
a NULL pixmap mask.  The attached context diff makes it also check
for a NULL pixmap, before attempting to create a PyGdkWindow for
it.

The context diff was created against pygtk 0.6.1, and was 
tested under IRIX 6.5.

-- 
Mitch Chapman
[EMAIL PROTECTED]

*** gtkmodule.c.origWed Jun 23 18:40:25 1999
--- gtkmodule.c Wed Jun 23 18:42:26 1999
***
*** 5451,5457 
  }
  
  static PyObject *_wrap_gtk_ctree_node_get_pixtext(PyObject *self, PyObject *args) {
!   PyObject *ctree, *node, *mask;
int col;
guint8 spacing;
char *text;
--- 5451,5457 
  }
  
  static PyObject *_wrap_gtk_ctree_node_get_pixtext(PyObject *self, PyObject *args) {
!   PyObject *ctree, *node, *mask, *pixmap;
int col;
guint8 spacing;
char *text;
***
*** 5473,5480 
  Py_INCREF(Py_None);
  mask = Py_None;
}
return Py_BuildValue("(siOO)", text, (int)spacing,
!  PyGdkWindow_New(p), mask);
  }
  
  static PyObject *_wrap_gtk_ctree_get_node_info(PyObject *self, PyObject *args) {
--- 5473,5487 
  Py_INCREF(Py_None);
  mask = Py_None;
}
+ 
+   if (p)
+ pixmap = PyGdkWindow_New(p);
+   else {
+ Py_INCREF(Py_None);
+ pixmap = Py_None;
+   }
return Py_BuildValue("(siOO)", text, (int)spacing,
!  pixmap, mask);
  }
  
  static PyObject *_wrap_gtk_ctree_get_node_info(PyObject *self, PyObject *args) {

[pygtk] Reordering GtkC(List|Tree) columns

[Mitch Chapman]

Hi,

We're working on adding behaviors to the column-header buttons
in GtkCList/GtkCTree.  One of the added behaviors is rearranging
columns using drag and drop.

When "moving" a column in this manner, I'd like the column widths
to move along with the column data.  In other words, if the 5th
column is 100 pixels wide, then when I move it to column 2 it
should still be 100 pixels wide.

And there's my problem:  how to find out the width of a column?
Better still, how to find the width of a column `i' in a list/tree 
`lt' such that

w0 = get_column_width(lt, i)
lt.set_column_width(i, w0)
wf = get_column_width(lt, i)
assert (w0 == wf)

I've tried several methods, and they all fail in various ways to 
account for the size of the widget's decorations -- the border width
around the button, the cell spacing within the list/tree, and so on.

Anybody have any suggestions?  Here's what I've tried:

1. Try to get the width of the column header button:
button = lt.get_column_widget(i)["parent"]
width = button["width"]

   This usually returns -1.  No dice.

2. Try to get the width of the window containing the button:
button = lt.get_column_widget(i)["parent"]
window = button.get_window()
# May fail if button is not realized
width = -1
if window:
width = window.width

   This gives the width of the window.  But the button *and* its
   decorations are painted inside the window.  So if I set the 
   column width based on the window.width, the button gets wider.

3. Use the button's requisitioned width:
...
width = button.get_child_requisition()[0]
   This appears to return the last auto-computed width of the
   column.  But the uesr could have manually resized the columns
   after the last auto-size, so this isn't what I want either.

4. Use the button's allocation width:
...
width = button.get_allocation()[2]
   This appears to be the same as method 2, above.  The only
   difference is that, if the widget hasn't been realized, this
   technique returns 1 rather than -1.


Thanks for help.
-- 
Mitch Chapman
[EMAIL PROTECTED]
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]