[Pipet Devel] Gnome stuff

[Brad Chapman]

>
>Well, if you consider the relationship between a program and its library to be
>the same as a wrapper and its 'wrappee', then yes...sort of.  Bonobo is just
>one of the libraries we're using, and we're using it to...
>
>    (1) Include non-python GUIs in the Workspace
>    (2) Include Loci's GUI in other apps, if there is a need to do so
>

Aaaaa, gotcha. Sorry, I was thinking of bonobo as being more than it
actually was (I was thinking of it as covering CORBA, so that you make all
of your interfaces through bonobo, rather than CORBA). I don't consider a
program:library relationship to be the same as a wrapper:wrappee
relationship at all! So, bonobo is just for embedding a component of one
program inside the container of another program. Okay.

>
>Hmmmm.  I understood GConf to be akin to the Windows Registry.  I can't
>imagine trying to put all of our XML into it, especially if the script XML
>includes the GUI XML, etc.
>

Ack. Windows Registry. Bad! Bad! I'll forget I even mentioned GConf!

>
>GFM is, disappointingly, a clone of Windows Explorer running with the Active
>Desktop.  So, the viewers in GFM are 'just' giving you a preview/thumbnail of
>the file in one corner of GFM's window.
>>I never really thought that Loci's 'file system', or the way files and
>directories are shown, would provide previews or thumbnails.  It's an
>interesting idea that we can pursue later.

Okee-dokee. I agree, I don't think it's really necessary to have previews now.

>But for now, I'd like to see each
>directory on the file system be represented as a 'container locus'.  If you
>double-click on such a container, you get a windowlet just like any other
>locus.  But a container's windowlet is a 'list' widget that lists the contents
>of the directory:
>
>        +------+
>        | cont |                 <----- icon
>        | ainer|
>        +------+
>    +---------------+
>    |    file       |
>    |    file       |
>    |    file       |            <------ windowlet
>    |    container  |
>    |    file       |
>    +---------------+
>

Okay--will this be stored directly in the XML representing the workspace
graphical script? For instance if we had a container representation like
the following:

        +-------+
        | my seq|                 <----- icon
        | files |
        +-------+
    +-------------------+
    |    gb file 1      |
    |    gb file 2      |
    |  			|            <------ windowlet
    |    fasta_files    |
    |    phylip_files	|
    +-------------------+

where my_seq_files is a directory I store all of my sequence files in, gb
files 1 and 2 are just genbank formatted files, and fasta_files and
phylip_files are directories with fasta and phylip files, respectively
(sorry, I should be thinking up physics examples instead of bioinformatics
examples!). Then, if we represent this in the XML script (assuming that
this container is located on the main workspace) as:

<container>
 <name>loci_root</name>
 <location>/usr/local/loci/workspace</location>

 <container>
   <name>my_seq_files</name>
   <location>/usr/home/chapmanb/my_seq_files</location>

   <file>
    <name>gb_file_1.gb</name>
   </file>

   <file>
    <name>gb_file_2.gb</name>
   </file>

   <container>
    <name>fasta_files</name>
    ...the contents of the directory
   </container>

   <container>
    <name>phylip_files</name>
    ...the contents of the directory
   </container>
 </container>
</container>

If /usr/local/loci/workspace is where everything is analagous to the root
directory in a web server, this is where the "Loci filesystem" starts. Then
if a user double clicks on the my_seq_files container icon, we would go
through the XML to look for my_seq_files and find it at
loci_root.my_seq_files, which would by default be located at
/usr/local/loci/workspace/my_seq_files. In this example, I figured that the
user would probably have their sequence files located in some home
directory and not on the loci filesystem (/usr/home/chapmanb/my_seq_files,
in this example). So then we have something analagous to a symbolic link,
with /usr/local/loci/workspace/my_seq_files ->
/usr/home/chapmanb/my_seq_files. So my idea here is that the location of a
file or directory would be with respect to the loci_root directory unless
there is a <location> tag directly specifying to look elsewhere.
	Anyways, is this along the lines of what people were thinking for
the representation? I haven't really said anything about how to actually
generate this kind of XML, but I just wanted to make sure I was on the
right track!

>
>For now the 'list' widget just gives the names and icons of the files and
>directories (loci) held by the container.  And you can drag-and-drop loci
>to-and-from the container's list and Workspace!
>

Okay, so if in the above example I wanted to move gb_file_1.gb from the
container to the main workspace, I would drag it into the workspace and in
the real directory structure, the file would move from
/usr/home/chapmanb/my_seq_files/gb_file_1.gb to
/usr/local/loci/workspace/gb_file_1.gb? Do you want the file to actually
move, or just to create a link to the file from inside the
/usr/local/loci/workspace directory system?

>
>For now, I'm sure we're using...
>
>    gnome-libs           (what gnome-python wraps)
>    bonobo
>    orbit
>
>These are 3 distinct packages/parts to Gnome.  There is no need to look beyond
>these, so our use of Gnome is less confusing than you may be thinking.

Okay, that is what I was originally thinking, then I started to confuse
myself by thinking about all of these other gnome programs etc. Thanks for
clarifying!

Brad