[Pipet Devel] excerpt from CHANGES

J.W. Bizzaro bizzaro at geoserve.net
Wed Feb 9 00:58:10 EST 2000

First, thanks for the continued work on the project, Brad.

> 2/8/00 Brad
> * Got all of the below database stuff working for MySQL, PostgreSQL and
> Gadfly (at least, it seems to be working okay for my simple examples).
> Shouldn't be too hard to add more dbs if people want them...

So, you have list and tree views of MySQL, PostgreSQL and Gadfly?  Very nice.

> 2/7/00 Brad
> * Can now drag and drop databases and tables.

I don't use a DBMS on my system.  Could we provide a small, test
database/table for the 3 you wrapped?

I noticed the DnD, and I'm pleased to see that you tackled the problem first,
since I have no experience with it.

> * Created a table_view widget (just a CList with mutliple columns--it
> appears that that is the most widely used widget to display database
> contents). Dragging a table out of a container onto the desktop shows its
> contents in the table view widget.

Does the table show up as a file in the 'filesystem view' or as an icon in the
'database view'?

Also, I think we should have one 'view' per container.  'Filesystem' and
'database' are really 2 different container types.  We need to think on a much
lower level than we are.  Instead of one program called 'container' that has
many different functions, we need to have many different containers that have
one function each.

> * Got the list and tree representations working for viewing database
> contents.
> * file_select widgets now update their xml to try and keep the xml current
> with the file located in the selection widget.

Again, per our earlier conversations, the Loci user will be limited to what
part of the filesystem he/she can access.  By default, we want 4 filesystem
containers on the workspace (akin to disk dirves on a Mac desktop):

    (1) $LOCIHOME/back/public/container/
    (2) $LOCIHOME/back/private/container/
    (3) $HOME/loci/back/public/container/
    (4) $HOME/loci/back/private/container/

They appear on the workspace everytime Loci is started, and they cannot be
deleted/trashed.  And for security, the user CANNOT change to a parent

A 'trash container' is another one we need to make.

> 2/6/00 Brad
> * Now you can view database information in a container in tree view only.
> * Started working on dragging databases and tables out of a container onto
> the desktop.
> 2/4/00 Brad
> * Changed up the buttons on container to get ready to add database info to
> containers.
> * Started adding database connection utilities. Right now I'm working with
> MySQL and MySQLdb since I've already got MySQL with tables filled on my
> computer. So far, there is a basic database selection window that pops up.
> A connection is then established with the database.
> * Did some internal stuff to get more working. Will continue on this...
> 2/1/00 Brad
> * Added drag and drop stuff so that you can now drag items out of a
> container unto any workspace. A new locus will be created for the dragged
> item on the workspace that it is dragged to. The locus contains the
> information from the dragged item in the container. For now, this only
> works for documents and containers (since containers can only currently
> hold documents and containers).

I like it!  It's just what I was thinking about :-)

About document loci: It'd be nice if text documents had a 'text viewer'
(non-editable editor) widget in the windowlet by default.  You have the
filename in the windowlet and a way to change the file affiliation of the
locus.  But, by the design model I've been beating everyone over the head
with, the user should not be able to change affiliation.  Just like in the
Mac, if you have an icon representing a particular file, you can't change it
so that it represents something else.

> 1/31/00 Brad
> * Did a lot of messing around with the problem of losing clicks from
> internal windowlets to the main workspace. Discovered the problem, and
> thought up a solution:
> Problem: What is happening is that the events from a windowlet gui are
> being passed on to the parent widget (the main workspace) and then are
> being taken care of again by a second event handler.

BUT, here's the catch: This doesn't always happen.  It seems there is an
invisible event-catching box that doesn't always line up with the windowlet. 
Try clicking all around on some windowlets.  Sometimes there is a corner that
won't let the super-workspace catch the event.

> To add onto this
> problem, the coordinates (ie. event.x, event.y) of the event in the
> mainworkspace are the same as the coordinates in the internal workspace,
> so the main workspace recieves an event that it thinks is happening on a
> location in its workspace that is not behind the windowlet window, but at
> the relative position in its window that the event happened in the
> windowlet window. Ugly problem!


> Although this happens for every click on
> the windowlet, currently the only problem it causes is with the button 3
> click to open a menu. Two menus will be opened--one for the internal
> windowlet, and then one for the main workspace.

I know, that stinks.  It looks like the pop-up menu got stuck.

> Solution: Attached an event handler to the gui which returns TRUE if
> a button 3 click is recieved. This prevents the signal from being
> propogated past the initial menu click.


> Problem with the Solution: This solution also prevents button 3 clicks from
> being propogated to loci within an internal windowlet. So we can't use a
> button 3
> click for anything specific to a loci, or within a GUI.

Well, I'll try to take a crack at the problem.

                      |           J.W. Bizzaro           |
                      |                                  |
                      | http://bioinformatics.org/~jeff/ |
                      |                                  |
                      |        BIOINFORMATICS.ORG        |
                      |           The Open Lab           |
                      |                                  |
                      |    http://bioinformatics.org/    |

More information about the Pipet-Devel mailing list