[Pipet Devel] excerpt from CHANGES

[Brad Chapman]

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

The pleasure is all mine--thanks for taking a look at things!

>> 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.

Right, I just did this because they seemed like 3 good ones to try. If 
anyone is using other databases and would like me to get those 
working, just let me know!

>> 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?

Sure, MySQL and PostgreSQL will be a little more of a pain, since they 
require installation and getting them running and all that jazz, so I 
just provided a simple one for Gadfly. Gadfly is written in all 
python, and isn't hard to install and get running. I'll send a 
separate e-mail after this about it with a script to create a really 
simple database. If you try it out, you'll notice that it also reveals 
a current problem I'm having with Gadfly.

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

I basically just looked at dnd.py from the pyGtk examples and tried to 
figure out what was going on there. I really needed to get this 
working in order to get
the database stuff working, so that is what I tried to hit it first 
(plus, I think it is pretty neat to be able to drag and drop things!).
    I have a question on this for you. I would like to add it so that 
you can also drag and drop loci from the workspace into a container 
(as opposed to out of a container onto the workspace). This would also 
allow us to drag loci between different workspaces (notice now how you 
can drag a loci out of a container into any workspace inside the main 
workspace. Pretty neat, and I didn't even have to try to do this). My 
question is, what kind of button press or button press/key stroke 
combo should I use to do this? I was thinking Shift:button1 click 
or Control:button1 click or something like that--do you have a 
preference/opinion on this?
    To do the dnd into containers "properly" we'll also need to make 
deletion of loci possible (otherwise it'll be more like copying loci 
around), but hopefully that shouldn't be too bad.

>> * 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'?

The table is created in a separate document type loci. Basically, my 
idea for getting at a table in a database is this:

1. Open up a container loci and click on the database button to 
connect to a DB.
2. Once connected, the container will be filled with all of the 
databases within the big database.
3. To get at the info in one of these databases, you drag it out onto 
the workspace and this will create a new container for the database, 
filled with all of the tables in the database.
4. Drag one of these tables out into the workspace, and a document 
loci type will be created with the "table_view" widget containg the 
column names and all of the info in the columns.

> 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.

I ?think? what I described above might be what you want, but I'm not 
positive. Let me know. Eventually, what I hope to have is that 
dragging a table onto the workspace just creates a loci with a simple 
widget showing some information about the table (ie. column names and 
type of information they store, number of records, etc.) and then if 
you hook the table up to a viewer, this will show all of the data. 
That way, you can work with a huge table without having to show 
everything in it.
    In terms of the list vs. tree view. I'm just keeping them both 
going so we can decide between them later. They both show exactly the 
same thing now (since I'm not delving into directories or databases 
because it is too slow). I might just switch to the list, but it is 
giving me issues with the drag and drop. Notice how when you drag 
something from a list view the pixmap that is shown is not the one 
from the container, but this random big pixmap that I have no idea 
where it came from. I can't figure out why this is happening...

> 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
> directory.

Do you think we need this for using Loci on a "local" system? It seems 
like you should be able to, and would want to be able to, access all 
of the files/programs on your system from loci. However, when you 
connect to a remote loci, you can only see the directories inside of 
loci home. Am I making any sense? I had an idea about this earlier 
that I posted--I'll resend that right after this.
 
> A 'trash container' is another one we need to make.

Do we want a trash container or do we want to use the delete option 
from the menu?

> 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.

That's true... The reason I added the file selection is so that you 
could get at a file directly if you added a document widget directly 
onto the workspace. Also, I thought this would be needed if you wanted 
to use the document widget to supply a file for command line 
construction.
    WRT the text viewer--that should be no big deal to do, but do you 
want this contained in the "document" widget or as a separate viewer 
widget? It just seems like it might be annoying to have to load the 
contents of a file every time you want to refrence it, especially if 
you have huge text files like some FASTA file or something.

> 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.

I'm not sure, but this might have to do with the problem of the actual 
position of a loci not being identical to it's world coordinates. I 
tried to use c2w() to convert the canvas coordinate refrences to 
world coordinates, but I always get a seg fault when I try to use it. 
Not sure why...

>> 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.

That would be great! At least right now things seem to go fairly 
normally and you don't accidentally end up adding loci to the wrong 
workspace, but a better solution would definately be spectacular :-)

Brad