[Pipet Devel] Re: [Pipet Devel] Re: window sill

Brad Chapman chapmanb at arches.uga.edu
Wed Apr 5 11:16:43 EDT 2000

Brad wrote:
> > Will the info button be replacing the "help" window thingy that I
> > started using, or in addition to that?
Jeff wrote:
> I want to define 2 types of 'help': One is a message about the particular
> node.  The other, since a node can be made up of a network of nodes, is a
> message about the node SELECTED WITHIN the window of the node.  This I would
> call 'context-sensitive help', since it will change according to the context.
> The Info button will contain only the first type of 'help' (for now).  And the
> message will have to be truncated, since the Info button can be only so large.

That sounds very snazzy :-)

> > > (When I say 'parent', I mean a node that contains a network of
> > > nodes, one of which being the node in question.)
> > 
> > This is a really cool idea, but will the old windowlet with the
> > network GUI get recycled by python memory collection if it gets popped
> > out of a parent window? Just throwing that out, I really have no idea
> > how memory collection works in pyGtk. Maybe it will still be fine as
> > long as you maintain a reference to it.
> The Gtk object, that is the 'view' in the window, will not be thrown out.  I
> can just use 'show' and 'hide'.

Okay... I just thought you would have to remove a child window before you
could insert another one in the windowlet. I thought you would get one of
those wonderful gnome error messages about the parent node already having
a child (since they can't have more than one, can they?). But then again,
I might be smoking crack...

> >     Also, I was having a lot of problems getting windows to refresh
> > properly after resetting the contents of a windowlet...
> Just now or a while ago?  You mentioned this a couple months ago.

Then, now, still, whenever. I never fixed it, I just had a stupid
workaround by closing the window when I changed the windowlet, so they the
user would have to open it back up and it would refresh automatically :-)
Of course, this cheap hack won't work for your ideas. If you can make
stuff refresh I would be so happy to learn how, because I tried calling
all kinds of different refresh calls and couldn't get any of them to do
anything for it. If you want to try it out, maybe you could try and make
the main Loci window refresh after selecting a file (while it is waiting
for the file info to come back from the definition layer). Right now it
sits in a really ugly state (looking like it is locked up), and I couldn't
seem to get a refresh to fix this, so I just had to give up before I spent
my whole life on it. I am stuck :-<

> > Can you describe this view? What does it look like?
> This is the composite GUI I keep yammering about.  It contains Gtk widgets
> arranged according to the heirarchy of the network (if there is one) contained
> in the node.

Is this what you are proposing will replace the GtkCTree view? Will be
have to code our own widget for this?

[...snip... my poor description of zoom...]
> I don't understand.  You just tried to code this feature?  What is the 'text
> box'?

I did code this feature, and then killed it because it sucked :-< There is
a zoom command for the canvas which is supposed to provide "automatic"
zooming, but I couldn't make it work. By the text box, I mean the little
text thingy with the name of the widget (under the widget shape and little
people picture :).

> As long as VSh (or the Gnome front) remains running, this information will not
> go away.  The problem is when the program is shut down and restarted.  If the
> user wants to reload a network, the middleware may have linkage information
> stored, but the front end will not have x/y positions stored...at least not
> now.
> We do need to come up with a way to store this user interface information.  I
> most certainly don't want to MIX user interface information with the
> information the core needs, but we can keep it along side or parallel to the
> core information...perhaps as separate files.

I see... I guess this is something that will have to come later on. Let me
just stick with remembering one thing (the links) at a time :-)


More information about the Pipet-Devel mailing list