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