[Pipet Devel] excerpt from CHANGES

[Brad Chapman]

Hey Jeff;
    Good to hear from you. Thanks much for looking at my changes! I 
was trying to get them in better order before I wrote about them. I 
just cvsed a bunch of changes which will hopefully make things clearer 
about what I am trying to do. I'll comment on those below.

>Thanks for taking out the .pyc files.  I didn't get around to it.

Oh yeah, no problem. I've just been pulling them out a little at a 
time when I cvs. That makes more sense anyways than having to cvs just 
to remove them.

>* Added a new module for printing out comments as XML comments.
>
>	comment(object1, object2, [...])
>
>  replaces use of print function.  The idea is that this function
>  can be turned on and off from the command-line (not implemented 
yet).

Cool, I'll start using this for all my prints.

>> Big problem here: the internal widgets of a workspace don't always 
redraw,
>> which can leave things looking ugly--need to find a way to fix this.
> 
> There is a Gtk or Gdk function to force a widget to redraw.  I can't 
recall
> it off-hand.  

I remember trying to force a redraw using *.queue_draw_area() (a 
function in GtkWidget) but didn't have any luck. Even if I could 
manage to force a redraw when a locus is created in an internal 
windowlet (which would be so nice) there is still a problem of 
redrawing under normal circumstances (ie. when a composite GUI is 
being moved around). The loci in the internal windowlet seem to redraw 
fine, but not the GUI windowlets of the loci in the windowlet (man, 
that's confusing!) do not. It seems like there must be a way to 
connect the GUI to the internal windowlet GnomeCanvas so it will 
redraw with them, but I'm not sure how...

>BTW, we've always had this problem with the windowlet not catching
> _windowlet_ events but workspace events.  It seems the event box and
> windowlet positions are not always the same.  Any ideas?

Well, I was trying to fix this, and it seems like there are two 
problems. The first is the discrepency between the world_x, world_y 
and the actual positions on the screen. I was looking into this and it 
seems like the problem might be the difference between canvas 
coordinates and world coordinates. World coordinates are specified as 
a double, so they are very precise, while canvas coordinates (which 
are used when the loci moves) are integers. So it seems like every 
time a loci moves, its canvas position and world coordinates get 
further and further apart. I tried to use the GnomeCanvas function c2w 
to convert canvas to world coordinates, but I kept getting a seg fault 
whenever I used the function. I'm not sure if it's my problem or a 
pyGnome problem. So I'm not sure what to do about the position 
difference problem.
    The second problem is that there appears to be "competition" 
between the gui windowlet and the main workspace for clicks. I *tried* 
to force the gui to be selected whenever the mouse was over it or 
there was a click on it by connecting gui events to a handler that set 
the loci as selected (if you notice, the way I connected gui 
windowlets to mouse movement causes a huge amount of <!-- clicked on 
composite -->s to be printed to the screen. Sorry about that!). But, 
if you left click on a gui there will be two selection events. The gui 
windowlet is initially selected by its own event handlers, but then 
the main workspace is selected by its handlers. When this second 
selection of the main workspace occurs, that selection event wins out.
    What I'll try later today is to have the workspace ignore all 
clicks within
the region defined by the locus.group.window_widget, when a gui 
windowlet is shown. I'll write the results in the CHANGE log 
tommorrow. Maybe this might work...

>> * Tried to fix the problems with scrolling, so that you no longer 
lose
>> the loci off the screen. Now the scrollbars and workspace size
>> automatically increase when a loci is moved toward the bottom or the
>> right. The loci is stopped from moving when it attempts to go to 
the top
>> or left of the screen.
> 
> Great!  That was one of the things I've been wanting to do.

I was just getting really annoyed because I was stupidly losing my 
loci all the time, so I decided to add this. 

> I noticed the mouse cursor 'slips away' from the locus too.

Yeah, I don't know how much this affects the "actual position" versus 
world position problem. I'm not experienced enough in writing GUIs to 
know this.

>> Also, need to find a way to make the screen scroll automagically 
when the
>> widget is moved.
> 
> It looks like the workspace starts to scroll but then stops.

Yeah, I think this might just be a jerking motion caused by the 
resizing of the scrollbars and workspace. If you look at the scroll 
bars, you'll notice they never move when the canvas and scroll area is 
being resized. I'd like to have them move along with the position of 
the loci, so that it is always in view in the window. I can't seem to 
find a way to programmatically make the scroll bars move. Any ideas?

> Hmmm.  Is the windowlet that looks like a control-panel meant to 
_help_ the
> user select loci used in command-line construction, or is it used to 
actually
> construct the command-line?

Okay, I think things will be a lot clearer about what I was trying to 
do if you look at the recently updated loci that I just cvsed today. 
The idea I had is that the control-panel thingy is like a "model" of 
the command line. If you want to take a look, try it out with gbparse 
(in the seqManip module)--this is the only program that works right.
    Basically, every button in the control-panel is a portion of the 
command line. This command line is specified in the xml file for a 
program via "request" tags. If you look at the xml file for gbparse 
(in back.private.library.xml.seqManip) you can probably get an idea 
about what I'm thinking of. Basically, my idea to port a program is to 
have a description, the flags available, and then a set of tags called 
<commandline> in which you spell out the command line via request 
tags. This mechanism allows information about each item in the command 
line to be specified via <info> tags. Right now I'm using these tags 
as the information to put in a tooltip for the buttons in the 
control-panel. So if you hold the mouse over a button in the 
control-panel, you can see a description of why you would want to 
click that button.
    So, I was hoping the control-panel would give the natural idea to 
start clicking the buttons in order. If you click the first button, 
you will be an info window with a description of the program. Right 
now this is a really ugly window with the information in the 
<description> tags spit into a
text_box. My ultimate thought for this is that the <description> 
information could be tagged up like an html file, so this window could 
have links to web sites, bolded items, bullets, etc. Anyways, once 
your done reading this, click on okay, and then proceed to the next 
item in the control-panel list. When you click on this it will open up 
an option loci (Note: I just added this loci--feel free to change it 
to make it fit in with your vision of how the loci should look) with 
the flags for the program to be set. When you're done with this, click 
on the next button, and you'll get a file selection widget (which I 
just made--I hope it's what you were thinking of as a simple widget) 
where you can select the input file for the program.
    Well, I hope this gives the general idea of what I was thinking. 
What do people think? Like it, hate it? Changes? If anyone wants to 
try it out, please notice that I changed the DOM stuff to use 4DOM, so 
you'll need to install that (the web site for 4DOM is in the INSTALL 
file). Thanks much for listening!

Brad