From 3d0892445878af75aa4c803288bcaf4af1b6b36c Mon Sep 17 00:00:00 2001
From: mh17 <mh17>
Date: Wed, 3 Mar 2010 14:05:59 +0000
Subject: [PATCH] removing old docs
---
doc/obsolete/MAC_G2.README | 87 -----
doc/obsolete/PERFORMANCE.README | 478 ------------------------
doc/obsolete/TODO | 577 -----------------------------
doc/obsolete/design_notes.shtml | 287 --------------
doc/obsolete/issues.html | 46 ---
doc/obsolete/lace.changes | 141 -------
doc/obsolete/porting_install.shtml | 41 --
doc/obsolete/user_guide.shtml | 53 ---
doc/project/2005_03_09.meeting | 106 ------
doc/project/2005_03_23.meeting | 60 ---
doc/project/2005_04_19.meeting | 93 -----
doc/project/2006_01_06.meeting | 165 ---------
doc/project/2007_02_07.meeting | 196 ----------
doc/project/zmap_lace_tasks.txt | 204 ----------
doc/wemap/README | 6 -
doc/wemap/fex.h | 343 -----------------
doc/wemap/fex.idl | 203 ----------
doc/wemap/fex.synopsis.html | 220 -----------
18 files changed, 3306 deletions(-)
delete mode 100755 doc/obsolete/MAC_G2.README
delete mode 100755 doc/obsolete/PERFORMANCE.README
delete mode 100755 doc/obsolete/TODO
delete mode 100755 doc/obsolete/design_notes.shtml
delete mode 100755 doc/obsolete/issues.html
delete mode 100755 doc/obsolete/lace.changes
delete mode 100755 doc/obsolete/porting_install.shtml
delete mode 100755 doc/obsolete/user_guide.shtml
delete mode 100755 doc/project/2005_03_09.meeting
delete mode 100755 doc/project/2005_03_23.meeting
delete mode 100755 doc/project/2005_04_19.meeting
delete mode 100755 doc/project/2006_01_06.meeting
delete mode 100755 doc/project/2007_02_07.meeting
delete mode 100755 doc/project/zmap_lace_tasks.txt
delete mode 100755 doc/wemap/README
delete mode 100755 doc/wemap/fex.h
delete mode 100755 doc/wemap/fex.idl
delete mode 100755 doc/wemap/fex.synopsis.html
diff --git a/doc/obsolete/MAC_G2.README b/doc/obsolete/MAC_G2.README
deleted file mode 100755
index 593ad7e10..000000000
--- a/doc/obsolete/MAC_G2.README
+++ /dev/null
@@ -1,87 +0,0 @@
-
-g2 install and autoconf on mac
-------------------------------
-
-Things we need to manage to get the g2 install to work on the mac.
-It is currently installed in ~zmap/prefix. But other people won't
-have this installed. This needs to be done. We can diable the
-feature in zmap, but that's not really a solution. In addition
-our build needs to check that it is installed and either error and
-go no further or warn and manage the features running without g2.
-
-g2 install
-----------
-
-This seems to be using an *old* version of autoconf.
-
-- configure.in needs renaming to configure.am
-- darwin needs an option in the switch statement.
-- Makefile.in needs renaming to Makefile.am
-- Makefile.am needs rewriting I fear.
-- ranlib needs running on the libg2.a
-
-I'll write some patches for this which will go in a
-patches directory.
-
-So all of the above were true, plus a few more glitches which needed ironing out.
-
-
-Step by Step
-------------
-
-Installing GD
--------------
-
-A little belatedly I found this which is roughly what I did.
-http://www.paginar.net/matias/articles/gd_x_howto.html
-
-I missed out a few bits, so here's what I did in case the omission
-causes issues.
-
-$prefix=/sw
-
-- zlib was already installed
-
-- install of libpng (see ~zmap/packages [cbi1] for tar.gz)
- This just installed using ./configure --prefix=$prefix; make; make install
-
-- install of libjpeg (see ~zmap/packages [cbi1] for tar.gz)
- This was slightly more tricky.
- ./configure --prefix=$prefix
- make all
- make install
- make install-lib
- ranlib $prefix/lib/libjpeg.a
-
-- install of libgd 2.0.33 (see ~zmap/packages [cbi1] for tar.gz)
- ln -s `which glibtool` libtool
- CFLAGS='-I/usr/X11R6/include/freetype2 -I/usr/X11R6/include/fontconfig' \
- ./configure --prefix=$prefix
- make
- make install
-
-
-Modifying G2
-------------
-
-Firstly to get anything to work.
-
-cd g2-0.70
-touch NEWS AUTHORS ChangeLog
-cp $ZMAP_CVS_DIR/src/bootstrap .
-./bootstrap
-
-rm -f configure.in
-configure.ac replaces this and is located in our cvs under g2
-
-rm -f Makefile.in
-Makefile.am replaces this and is also located in cvs under g2
-
-libtoolize
-./bootstrap
-configure needs to find gd, hence /sw/{include,lib}, and libiconv, hence /usr/lib
-CFLAGS=-I/sw/include LDFLAGS='-L/sw/lib -L/usr/lib' ./configure --prefix=$prefix
-make
-make install
-
-This doesn't install perl. When I learn how to do it I will.
diff --git a/doc/obsolete/PERFORMANCE.README b/doc/obsolete/PERFORMANCE.README
deleted file mode 100755
index e0a8f774d..000000000
--- a/doc/obsolete/PERFORMANCE.README
+++ /dev/null
@@ -1,478 +0,0 @@
-Summary of performance stuff....
-
-I started out thinking the memory allocator might be the problem but the memory/timing
-trace showed this not to be so (see [1] below).
-
-
-By interrupting zmap while parsing I realised it was spending a lot of time searching
-through g_datalist structs and I realised that:
-
-
-When adding a feature to a featureset during parsing we basically do:
-
-if (feature not in feature set)
- add feature to feature set
-
-
-this results in the g_datalist code doing two linear searches, one to see if the
-feature is there and then a second one to see if its there when it adds it....
-
-time to parse busy clone = 140s
-
-
-so the first change I made was to add a function to the g_datalist code that just adds
-the feature without checking whether its there, after all we've already done that....
-
-time to parse busy clone = 74s
-
-
-then I added a hash table to the featureset so we could use that to check whether we
-had the feature there instead of stupid g_datalist linear lookup...
-
-time to parse busy clone = 5s
-
-
-See [2] below for overall timings which are interesting.
-
-
-Now the two biggest delays are in getting the data from the server and in making the
-canvas items. We need to look at the latter at some time especially for splitting
-windows.
-
-
-
-
-[1] Memory/timing Output
-
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-../../../zmapView/zmapView.c:zMapViewConnect:266 Open connection - elapsed time: 1.2e-05
-../../../zmapThreads/zmapSlave.c:zmapNewThread:140 In thread, calling handler function - elapsed time: 0.003583
-thread_mem malloc
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-../../../zmapServer/acedb/acedbServer.c:getFeatures:433 In thread, getting features - elapsed time: 0.440321
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:707 In thread, about to ask for features - elapsed time: 0.440428
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:728 In thread, got features and about to parse into context - elapsed time: 7.5291
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:878 In thread, finished parsing features - elapsed time: 146.297
-../../../zmapServer/acedb/acedbServer.c:getFeatures:438 In thread, got features - elapsed time: 146.297
-../../../zmapThreads/zmapSlave.c:zmapNewThread:146 In thread, returned from handler function - elapsed time: 148.698
-../../../zmapView/zmapView.c:getFeatures:2040 Got Features from Thread - elapsed time: 148.751
-../../../zmapView/zmapView.c:mergeAndDrawContext:2003 Merged Features into context and about to display - elapsed time: 148.751
-../../../zmapWindow/zmapWindowDrawFeatures.c:zmapWindowDrawFeatures:211 About to create canvas features - elapsed time: 148.751
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-../../../zmapWindow/zmapWindowDrawFeatures.c:zmapWindowDrawFeatures:376 Finished creating canvas features - elapsed time: 160.058
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-malloc alloc: 1048
-
-
-
-[2] Timings for zmap.
-
-
-without any fixes:
-
-
-../../../zmapView/zmapView.c:zMapViewConnect:266 Open connection - elapsed time: 1.2e-05
-../../../zmapThreads/zmapSlave.c:zmapNewThread:140 In thread, calling handler function - elapsed time: 0.003583
-../../../zmapServer/acedb/acedbServer.c:getFeatures:433 In thread, getting features - elapsed time: 0.440321
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:707 In thread, about to ask for features - elapsed time: 0.440428
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:728 In thread, got features and about to parse into context - elapsed time: 7.5291
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:878 In thread, finished parsing features - elapsed time: 146.297
-../../../zmapServer/acedb/acedbServer.c:getFeatures:438 In thread, got features - elapsed time: 146.297
-../../../zmapThreads/zmapSlave.c:zmapNewThread:146 In thread, returned from handler function - elapsed time: 148.698
-../../../zmapView/zmapView.c:getFeatures:2040 Got Features from Thread - elapsed time: 148.751
-../../../zmapView/zmapView.c:mergeAndDrawContext:2003 Merged Features into context and about to display - elapsed time: 148.751
-../../../zmapWindow/zmapWindowDrawFeatures.c:zmapWindowDrawFeatures:211 About to create canvas features - elapsed time: 148.751
-../../../zmapWindow/zmapWindowDrawFeatures.c:zmapWindowDrawFeatures:376 Finished creating canvas features - elapsed time: 160.058
-
-
-with the g_datalist direct add code added:
-
-../../../zmapView/zmapView.c:zMapViewConnect:266 Open connection - elapsed time: 1.2e-05
-../../../zmapThreads/zmapSlave.c:zmapNewThread:140 In thread, calling handler function - elapsed time: 0.003591
-../../../zmapServer/acedb/acedbServer.c:getFeatures:433 In thread, getting features - elapsed time: 0.392993
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:707 In thread, about to ask for features - elapsed time: 0.393097
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:728 In thread, got features and about to parse into context - elapsed time: 7.58187
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:878 In thread, finished parsing features - elapsed time: 81.2551
-../../../zmapServer/acedb/acedbServer.c:getFeatures:438 In thread, got features - elapsed time: 81.2551
-../../../zmapThreads/zmapSlave.c:zmapNewThread:146 In thread, returned from handler function - elapsed time: 83.5875
-../../../zmapView/zmapView.c:getFeatures:2040 Got Features from Thread - elapsed time: 83.6691
-../../../zmapView/zmapView.c:mergeAndDrawContext:2003 Merged Features into context and about to display - elapsed time: 83.6691
-../../../zmapWindow/zmapWindowDrawFeatures.c:zmapWindowDrawFeatures:211 About to create canvas features - elapsed time: 83.6692
-../../../zmapWindow/zmapWindowDrawFeatures.c:zmapWindowDrawFeatures:376 Finished creating canvas features - elapsed time: 95.0206
-
-
-with the hash lookup added:
-
-../../../zmapView/zmapView.c:zMapViewConnect:266 Open connection - elapsed time: 1.2e-05
-../../../zmapThreads/zmapSlave.c:zmapNewThread:140 In thread, calling handler function - elapsed time: 0.003589
-../../../zmapServer/acedb/acedbServer.c:getFeatures:433 In thread, getting features - elapsed time: 0.40506
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:707 In thread, about to ask for features - elapsed time: 0.405164
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:728 In thread, got features and about to parse into context - elapsed time: 7.94696
-../../../zmapServer/acedb/acedbServer.c:sequenceRequest:878 In thread, finished parsing features - elapsed time: 12.3263
-../../../zmapServer/acedb/acedbServer.c:getFeatures:438 In thread, got features - elapsed time: 12.3263
-../../../zmapThreads/zmapSlave.c:zmapNewThread:146 In thread, returned from handler function - elapsed time: 14.8065
-../../../zmapView/zmapView.c:getFeatures:2040 Got Features from Thread - elapsed time: 14.8171
-../../../zmapView/zmapView.c:mergeAndDrawContext:2003 Merged Features into context and about to display - elapsed time: 14.8171
-../../../zmapWindow/zmapWindowDrawFeatures.c:zmapWindowDrawFeatures:211 About to create canvas features - elapsed time: 14.8172
-../../../zmapWindow/zmapWindowDrawFeatures.c:zmapWindowDrawFeatures:376 Finished creating canvas features - elapsed time: 26.1438
diff --git a/doc/obsolete/TODO b/doc/obsolete/TODO
deleted file mode 100755
index c2cbf0009..000000000
--- a/doc/obsolete/TODO
+++ /dev/null
@@ -1,577 +0,0 @@
-#
-# This TODO list file is parsed by the script makeQuad which expects this file
-# to be in the format:
-#
-#
-# [Categories]
-# Title = ZMap Priorities
-# Across = Important \
-# Not_Important
-# Down = Urgent \
-# Not_Urgent
-#
-#
-# [Some item of your choice]
-# Across = Important
-# Down = Not_Urgent
-# Text = Text describing the item, possibly \
-# running to several lines.
-#
-# There should be only one "Categories" section and you should not alter it without
-# altering all the Across/Down entries in all subsequent sections.
-#
-# Each general section should have a unique header and follow there rules:
-#
-# Across = < Important | Not_Important >
-# Down = < Urgent | Not_Urgent >
-# Text = as many lines as you like but you must use the continuation character "\""
-#
-# NOTE that the section title is the only thing that will be displayed in the
-# frames window so make the title meaningful !!!!
-#
-# Please add new stuff as required _and_ remove obsolete or completed items !
-#
-#
-
-
-# DO NOT CHANGE THIS STANZA WILLY-NILLY.....the Across/Down categories are
-# used in the rest of the file....
-[Categories]
-Title = ZMap Priorities
-Across = Important \
-Not_Important
-Down = Urgent \
-Not_Urgent
-
-
-[Shape Diversity]
-Across = Not_Important
-Down = Not_Urgent
-Text = We could do with supporting more shapes styles of "boxes" \
-e.g. pointing boxes to show strandedness, start/end not found, text \
-on features.... many more I'm sure
-
-[Install package via Autoconf/configure system]
-Across = Important
-Down = Not_Urgent
-Text = We need a pucker install package for zmap \
-we need to sort -rpath stuff on alpha....
-
-[Change reverse strand code to always create foocanvas items]
-Across = Important
-Down = Urgent
-Text = We should always create items whether they are shown or not, \
-but then just hide them. This would require the hash table to "know" whether \
-things were hidden or not for purposes of filtering returned items. \
-BUT, this may not be a good idea BECAUSE it would mean mapping potentially thousands \
-of homols on the reverse strand....
-
-[column ordering]
-Across = Important
-Down = Urgent
-Text = Better system than current right_priority system for the ordering of \
-columns. (Maybe user defined zones like "transcripts", \
-"similarity_features", and named columns are put into a zone or \
-left/right of other named columns, or simply in order of appearance if \
-the named column doesn't exist or isn't specified. Can have "default" \
-zone which is right of all the other zones to contain any columns which \
-don't have a zone defined.) WE DON'T HAVE THIS, SO TALK TO JAMES...
-
-[column control]
-Across = Important
-Down = Not_Urgent
-Text = All columns, including the default ones, can easily be hidden and \
-revealed by the user.
-
-[drag and drop column positions]
-Across = Important
-Down = Urgent
-Text = Ability for user to change the order of columns by dragging to new \
-position. This preference is sticky between sessions.
-
-[multiple methods per column]
-Across = Important
-Down = Urgent
-Text = If multiple different methods are drawn in the same column, it can be \
-chosen whether they are drawn on top of each other, or stack. Could \
-have different types of transcript appearing in the same column (saves \
-screen space), and draw symbols signifying polyA signals and sites on \
-top of the transcripts. DON'T HAVE THIS BUT COULD DO....
-
-[cds colours]
-Across = Important
-Down = Urgent
-Text = Can choose custom colours for fill and outline for boxes, and different \
-ones for CDS regions of transcripts. Colours can be chosen using the \
-standard X colour definitions. WE DON'T USE THIS INFORMATION AND I THINK \
-CURRENTLY ITS NOT DUMPED AS GFF SO WOULD NEED TO ADD TO ACEDB....
-
-[colour by score]
-Across = Important
-Down = Not_Urgent
-Text = Can change the shade of a colour of a feature according to its score. \
-Maybe a gradient from one colour to another? Maybe a 256bit look up \
-table? COULD BE PART OF THE STYLE...ALSO USE WIDTH OF BLOCK...(LOG SCALE)
-
-[better symbols]
-Across = Important
-Down = Urgent
-Text = Can choose a variety of symbols (circles, triangles, stars) for \
-features in a columns. NOT DONE... \
-Feature boxes can have arrow heads/tails at either or both ends.
-
-[better symbols 2]
-Across = Important
-Down = Not_Urgent
-Text = Can change the symbol used to draw a feature depending upon the zoom \
-level. (Not necessary? Could just have features drawn in the same \
-column that are visible at different zoom levels.) ALLELE LIKE THING
-
-[HOMOLS SHOULD USE GAPS ARRAY]
-Across = Important
-Down = Urgent
-Text = HOMOLS SHOULD USE GAPS ARRAY
-
-[text column]
-Across = Important
-Down = Not_Urgent
-Text = Can have labels attached to features, and labels that appear on \
-mouse-over. Labels repel each other so that they don't get drawn on top \
-of each other. ACEDB TEXT COLUMN....WE NEED THIS SOON....
-
-[alternate column types]
-Across = Important
-Down = Not_Urgent
-Text = A graph column type, for displaying properties such as GC content. GC \
-content could be calculated on-the-fly by zMap. Graphs could be \
-histogram, line, or varying shade of a colour (maybe a gradient?). \
-
-[scale]
-Across = Important
-Down = Not_Urgent
-Text = Have the basepair distance scale permanently on the edge of the window \
-like a ruler in a drawing application. \
-
-[focus window red border + user specified border]
-Across = Important
-Down = Not_Urgent
-Text = Currently canvas windows are surrounded by a frame, while this can be \
-coloured red it cannot be made wider and so is almost invisible. Users also \
-want to be able to colour borders separately to show which window is which.
-
-[feature search window]
-Across = Important
-Down = Urgent
-Text = implement the feature search window
-
-[external feature list]
-Across = Important
-Down = Not_Urgent
-Text = we should alllow external programs to \
-supplying a list of objects from an external source rather like the current feature list \
-- would enable user/lace/whatever to select their own sets of features
-
-[empty columns]
-Across = Important
-Down = Not_Urgent
-Text = Currently we can show columns even if empty, this may be good for multiple alignments \
-because otherwise the alignment blocks are likely to be all sorts of different widths. \
-The problem is that this makes the code more complicated which is not great. \
-Perhaps we should think about this again.
-
-
-[stacking of features in a single column]
-Across = Important
-Down = Urgent
-Text = james would like to multiple feature types per column, we need to implement this \
-in a good way, e.g. allow user to specify ordering perhaps ?
-
-
-[long term plans]
-Across = Important
-Down = Not_Urgent
-Text = need another person, must plan for conferences.
-
-
-[document rationalisation]
-Across = Not_Important
-Down = Not_Urgent
-Text = The docs directories need sorting out. We should have a script which ensures \
-that the doxygen generated docs end up in the "docs" directory below src. The \
-makeQuad files should also end up there so we just have the one docs directory. \
-
-
-[install/user guide]
-Across = Important
-Down = Not_Urgent
-Text = We need to start these.
-
-
-[zmap vs. fmap]
-Across = Important
-Down = Urgent
-Text = We don't have: \
- \
-- clear indication of which forward/reverse strand - users want a line to separate... \
- \
-- need scale outside of sequence view - separate window using a canvas which would be resized \
- to line up with selected display.... \
- \
-- recalculate button (fmap can do redraw and recalculate....can we do that....??) \
- \
-- no view of clones making up assembly \
- \
-- no text display with names of stuff \
- \
-- no "columns" button \
- \
-- no "redraw" button \
- \
-- no "dna" button \
- \
-- no "revcomp" button \
- \
-- no individual column button for configuring buttons \
- \
-- On/Off Rev strand \
- \
-- Column hiding on magnification \
- \
-- embl entry display (pfetch -F <seqName>) \
- \
- - Superior feature view \
- - Superior feature list
-
-
-[demos]
-Across = Important
-Down = Not_Urgent
-Text = need to add readpairs demo to our demo set + beef up how demos are run... \
-we also need a das demo.
-
-
-[bugs]
-Across = Important
-Down = Urgent
-Text = Here are some bugs we must fix.... \
- \
- - memory leaking features....need also to have this linked to fTOi mechanism for when things \
- are deleted... \
- - scale \
- - multiple sources \
- - feature list/view (I also think that there should be a way of clicking on \
-a feature in the feature in the feature \
-list window and have the feature viewer popup.
-
-[export features]
-Across = Important
-Down = Not_Urgent
-Text = we should export at least xml and gff3 (but perhaps do gff2 as a stop gap ?
-
-
-[print]
-Across = Important
-Down = Not_Urgent
-Text = we need a way to print displays....check gd library and other methods.
-
-
-[scale display]
-Across = Important
-Down = Not_Urgent
-Text = The scale needs moving into a separate slidable window like the other locators \
-so that it is always visible. It will have to be linked to scrolling in the \
-focus canvas. It will potentially need redrawing/relinking every time focus \
-canvas changes.
-
-
-[DNA display]
-Across = Important
-Down = Urgent
-Text = Need to add display of DNA, should include highlighting of exons etc. when \
-clicked on.
-
-
-[Focus change]
-Across = Important
-Down = Not_Urgent
-Text = The navigator needs to change as the focus changes and the buttons needs \
-to change their sensitivity, this is only partially done.
-
-
-[interaction with features]
-Across = Important
-Down = Not_Urgent
-Text = when you click on a feature in the window that shows the list of features, \
-the position scroll bar is not updated properly...needs the visibility \
-change callback to be called.
-
-
-[Region/Scroll scrollbars]
-Across = Important
-Down = Not_Urgent
-Text = The Region/Scroll scrollbars should be sorted to be the correct width by magic. \
-Can we add a double click to hide/show to the vertical line of dots??
-
-
-[glib logging glitches]
-Across = Important
-Down = Not_Urgent
-Text = if you let glib log routines output the message you get something like: \
-\
-process:554514): ZMap-WARNING **: (zmapAppwindow.c, line 103) - try this for size...\
-\
-\
-the bit upto and including the "**" is supplied by glib, BUT it does not do this if you use your \
-own logging routine which is a bit irritating.... \
-\
-There also seems to be bug in that glib seems to be messing about with fileptrs and hanging \
-on to them so that printf statements either don't appear at all or appear in the logfile\
-sometimes.....
-
-[multiple alignment support]
-Across = Important
-Down = Urgent
-Text = In order to support multiple alignments there will have to be changes to all of \
-zmapControl, zmapView and zmapWindow, it influences all of them. The changes need \
-not be too great if we can substitute a set of alignments for the single alignment \
-that View currently represents....But it will make view more complicated probably. \
- \
-Currently there is fudged code in zmapWindowDrawFeatures() in zmapWindowDrawFeatures.c \
-to allow us to start inserting more than one set of alignment data into a window.
-
-
-[Getting style information from servers]
-Across = Important
-Down = Not_Urgent
-Text = Currently the user has to have a styles file, this is because otherwise we have to query \
-the server and get all the types, this code is not impossible but is not written yet. \
-It needs doing, BUT, the user should still be able to override this with a list of \
-features that they want to see, gives the user control.
-
-
-[PANGO and FONTS]
-Across = Important
-Down = Not_Urgent
-Text = Check requirement of -DPANGO_ENABLE_{BACKEND,ENGINE} also fontconfig, see if we can fix/remove \
-"Fontconfig error: Cannot load default config file" \
-FONTCONFIG_PATH \
-FONTCONFIG_FILE
-
-
-[GFF stuff]
-Across = Important
-Down = Not_Urgent
-Text = Add ability of caller to specify a start/end so this code will filter out anything not in the \
-start/end coords. May not be so easy though....what about clipped features...ugh...actually \
-its not so simple....bother.....we really want to filter as we process but we won't be able \
-to filter some features until we've seen all of them...sigh....yes, its actually quite tricky \
-and tedious... \
- \
-Need to scope how long it will take to do GFF3.....as this is what we really want....
-
-[Long item bug]
-Across = Important
-Down = Urgent
-Text = There is still a bug in the long item code so that it doesn't clip properly
-
-[transcript display]
-Across = Important
-Down = Urgent
-Text = There is bug: transcripts are narrower than their column...why ? Also, we \
-don't display cds and start/stop
-
-
-[file server interface code]
-Across = Important
-Down = Not_Urgent
-Text = the code in this directory is crude currently, here are some things that need doing: \
- \
-- should be able to read files other than GFF.......this will require some restructuring \
- to provide a general file reading interface with specific parsers (preferably the same \
- ones as are used for GFF, XML etc. etc. \
- \
-- error handling is probably less than complete. \
- \
-- there is no way to ask for just some features currently but this also applies to the server \
-interfaces as well....
-
-
-[cancel points in THREADs code]
-Across = Not_Important
-Down = Not_Urgent
-Text = need to introduce pthreads_cancel_points into the code so that a cancel \
-will interrupt at good places....some thought needed here though to ensure \
-that we don't just litter the code with cancel points making it hard to \
-maintain...\
-\
-I think to some extent the main network reading calls get interrupted by \
-a cancel so that makes it all work better.
-
-
-[file utilities in Zmap utils]
-Across = Not_Important
-Down = Not_Urgent
-Text = The fileUtils all need sorting out, they should be rationalised into calls that get \
-files from the .ZMap directory and more general calls that construct path names etc.
-
-
-
-[zmapfeatures merge]
-Across = Important
-Down = Urgent
-Text = The merge needs work, currently it leads memory and is probably not as efficient as it \
-it should be. We should not copy across data but instead move pointers. \
-\
-Main thing is to protect whole GDatas that we move into our new sets and null out ones we \
-don't want. But also, what happens to datastructs of features that we have allocated but \
-no longer need...they should be freed.... \
-
-[ACedb tools: xremote and blixem]
-Across = Important
-Down = Urgent
-Block = SwapPhase II
-Text = The same should be done for a small library to launch blixem \
-given a sequence name/sequences.\
-\
-We will need a parameter/keyword in the config file to point zmap at the file to run\
-blixem, note this might be a cover script that itself runs blixem.
-
-[zmap configuration file]
-Across = Important
-Down = Urgent
-Block = SwapPhase I
-Text = The syntax of the properties in the configuration file needs to be constrained/decided \
-and coded for, probably to include a uri for data sources. Will we still need format. \
-The problem I see is file://... With http:// the header would tell us what it is. However \
-with file the extension is probably the best guess we can make. Does libcurl give us a response \
-callback we could check with?
-
-[zmap vs fmap display]
-Across = Important
-Down = Urgent
-Block = SwapPhase I
-Text = compare and contrast FMap display and ZMap display. Does ZMap look sane? \
-Has it drawn all the information?... Are we missing critical fmap features?
-
-[Bumping]
-Across = Important
-Down = Urgent
-Text = Support multiple types of bumping, still some bugs and need different sorts \
-including on key, and one for genomic_canonical to give assembly like display \
-showing clone overlaps
-
-[Updating]
-Across = Important
-Down = Urgent
-Text = We need to be able to dynamically update the zmap display and features \
-thereon. Need an interface to create, modify and delete objects. This needs \
-to be available to xremote.
-
-[zmap_remote]
-Across = Important
-Down = Urgent
-Block = SwapPhase II
-Text = support external calls via xremote mechanism, to allow external programs to drive zmap. \
-Review xremote code \
- \
-More stuff... \
- \
-> We would like to be able to at least support all of the current xremote \
-> commands, which from my calculations are: \
-> * gif \
-> * seqrecalc \
-> * seqget _SeqName_ \
-> * seqdisplay \
-> * seqdisplay -visible_coords _Start_ _End_ \
-> * seqactions -rev_comp \
-> * parse _FileName_ \
-> * writeaccess -gain \
-> * save \
-> If you know of any more please let me know. We would rather change the \
-> names for these commands, which will probably help with debugging in a \
-> test system if we find old commands coming from otterlace for example. \
- \
- \
-Looks like a complete list of our commands. I intend to replace all the \
-editing that the annotators currently do in tree view with Perl/Tk \
-interfaces, so you don't need to support that. \
- \
-Feel free to change the names and structures of commands. \
- \
-My only concern with xremote is whether we get useful feedback from \
-zMap. We get an exit status from xremote, but we don't get any \
-messages. Can we get feedback actually from the zMap, or is all that \
-xremote can say is that it sent the message to a valid window? It would \
-be nice, for instance, to be able to ask zMap what region it is \
-currently displaying. \
- \
-I assume we will be launching the zMap process from our perl code. \
-Could it just print its X window ID on STDERR, and fork a child that \
-does the actual work (ie: daemon)? This would avoid us messing with the \
-filing system.
-
-
-
-
-[zmap remote sematics]
-Across = Important
-Down = Urgent
-Block = SwapPhase II
-Text = what do we need to support.
-
-[das 1 xml support]
-Across = Important
-Down = Not_Urgent
-Block = ReplacePhase
-Text = Otter wants to get features from ensembl databases. There are das servers to serve this. \
-we should use this to replace the need to download to ace.
-
-[otter xml support]
-Across = Important
-Down = Not_Urgent
-Block = ReplacePhase
-Text = when das 1 works it should be easier to get zmap to understand otter xml
-
-[read features from pipeline database]
-Across = Important
-Down = Not_Urgent
-Block = ReplacePhase
-Text = More replacement of acedb .ace files
-
-
-[otter lace stuff]
-Across = Important
-Down = Urgent
-Block = ReplacePhase
-Text = 1) Lace - > sgifaceserver, Roy needs to check code works or if it needs \
-tweaking. Add -readonly and have zmap and xace launch together. \
- \
-2) Otterlace -> zmap, protocol + support code ready, but actual operations \
-not finished. Roy needs to look @ it.
-
-
-
-[local blast execution]
-Across = Important
-Down = Not_Urgent
-Block = ReplacePhase
-Text = Otter does some local blast searches against a user's database and creates ace files for \
-otter/Fmap. What can we do with regards this?
-
-[editing]
-Across = Important
-Down = Not_Urgent
-Block = editing
-Text = decide on editing mechanism. \
-Do our own interface... <br/>\
-xremote -> DAS2 translation... <br/> \
-xremote -> Otter translation..
-
-[buttons and control level]
-Across = Important
-Down = Not_Urgent
-Text = Sensitivity of buttons is all out of whack. This needs a state reading/setting routine \
-to modify their sensitivity in a similar way to zoom buttons. Menu items of main menu should \
-also be included in this design. (comment unused ones ATM [Urgent]). The display layout is also \
-currently not optimal.
-
diff --git a/doc/obsolete/design_notes.shtml b/doc/obsolete/design_notes.shtml
deleted file mode 100755
index ad809ba30..000000000
--- a/doc/obsolete/design_notes.shtml
+++ /dev/null
@@ -1,287 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
-<HTML>
-<HEAD>
- <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
- <TITLE>ZMap Design</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 1.0.2 (Linux)">
- <META NAME="CREATED" CONTENT="20041209;15311400">
- <META NAME="CHANGED" CONTENT="20041209;15390800">
- <!--#include virtual="/perl/header" -->
- <!--#set var="author" value="edgrif@sanger.ac.uk" -->
-</HEAD>
-
-<BODY LANG="en-GB">
-<BLOCKQUOTE>The purpose of this document is to be a repository for
-all aspects of the design of ZMap.
-</BLOCKQUOTE>
-<BLOCKQUOTE>Pictures are allowed, just include them in the cvs
-directory.
-</BLOCKQUOTE>
-<H1 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Requirements,
-Wish Lists, Suggestions etc.</H1>
-<H2 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Requirements</H2>
-<BLOCKQUOTE>Record anything here that is essential to ZMap.
-</BLOCKQUOTE>
-<H3 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Mapping
-in the client</H3>
-<BLOCKQUOTE>We should strongly consider putting a modified (i.e.
-acedb-less SMap) into the client, this would allow the client to map
-different sorts of data onto its virtual sequence provided it had the
-initial mapping from the new data to its own virtual sequence.
-</BLOCKQUOTE>
-<BLOCKQUOTE>This would be very powerful because it would mean the
-client could accept data from many sources and map it as long as it
-had the extent of the data in the virtual sequence.
-</BLOCKQUOTE>
-<H3 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">How
-to indicate strand</H3>
-<BLOCKQUOTE>In acedb we have traditionally had the down strand to the
-right and the up strand to the left of the scale, this has some
-advantages but could be augmented visually with exons that had pointy
-bits to show their direction etc.
-</BLOCKQUOTE>
-<BLOCKQUOTE>We could go for everything being shown on one side of a
-scale but this seems a bit retrograde to me, the display is actually
-something that marks the fmap out from other viewers in a good way.
-</BLOCKQUOTE>
-<H3 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Richer
-glyph set</H3>
-<BLOCKQUOTE>We need a richer glyph set, perhaps with exon shapes that
-indicate direction and other such stuff, e.g. how about indicating
-start/end_not_found etc.
-</BLOCKQUOTE>
-<H2 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Wish
-List</H2>
-<BLOCKQUOTE>Record anything here that you would like to be considered
-but is non-essential.
-</BLOCKQUOTE>
-<UL>
- <LI><BLOCKQUOTE STYLE="margin-bottom: 0cm">Allow user to
- interactively retitle a window, v. useful when there are lots of
- fmap windows on a screen.
- </BLOCKQUOTE>
- <LI><BLOCKQUOTE>Prevent users from zooming in/out to the point where
- the drawing code breaks, particularly for zooming in where lines
- start to randomly appear/disappear.
- </BLOCKQUOTE>
-</UL>
-<H1 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Design</H1>
-<H2 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Overview</H2>
-<H2 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Layering</H2>
-<BLOCKQUOTE>The code has been arranged in layers, explicit function
-calls (i.e. calls made by coding the name of the function rather than
-by using a pointer to a function) are allowed to layers below but <B>NOT</B>
-to layers above. This is paramount in maintaining the independence of
-layers from one another. Calls can only be made to layers above via
-the callback function mechanism.
-</BLOCKQUOTE>
-<BLOCKQUOTE>Here is an attempt to capture the layering in ZMap, of
-course it will go out of date rapidly but it provides an overview at
-least:
-</BLOCKQUOTE>
-<PRE STYLE="margin-left: 1cm; margin-right: 1cm">zmapApp zmapManager zmapControl
-======= =========== ===========
-
-createAppContext() ---------> zMapManagerCreate()
-
-
-removeZmapRow() <---cb---- removeZmapEntry()
-
-
- zMapManagerAdd() ---------> zMapCreate()
- zMapManagerReset() ---------> zMapReset()
- zMapManagerKill() ---------> zMapDestroy()
-
- zmapDestroyedCB() <---cb---- killZMap()
-
-
-
-
- contd from above..........
-
-
-zmapControl zmapView
-=========== ========
-
-zMapCreate() --------> zMapViewCreate()
- zMapViewConnect()
-
-zmapControlLoadCB()
- --------> zMapViewConnect()
- zMapViewLoad()
-
-zmapControlResetCB()
- --------> zMapViewReset()
-
-
-killViews() --------> zMapViewDestroy()
-
-
-viewKilledCB() <---cb--- checkConnections()</PRE><H2 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">
-Documentation</H2>
-<H3 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Source
-Code docs</H3>
-<BLOCKQUOTE>We are using the <A HREF="www.doxygen.org/index.html">doxygen
-package</A> for documenting our source code. This seems to work well
-and does just about everything we need, it builds and improves on the
-DOC++ package which seems to no longer be under active development.
-</BLOCKQUOTE>
-<BLOCKQUOTE>Some notes about using doxygen:
-</BLOCKQUOTE>
-<UL>
- <LI><BLOCKQUOTE STYLE="margin-bottom: 0cm">doxygen looks for C
- comment blocks that start with " <B>/*!</B> ".
- </BLOCKQUOTE>
- <LI><BLOCKQUOTE>For C language files it is imperative that you
- include either a " <B>/*! \file */</B> " or " <B>/*!
- @defgroup</B> " special comment in each file to be documented
- otherwise doxygen will <B>not</B> process the other comments in the
- file.
- </BLOCKQUOTE>
-</UL>
-<BLOCKQUOTE>A suggested standard is that for each package within ZMap
-(e.g. zmapConfig) the external interface functions are documented in
-the source files where they occur and the external typedefs etc. are
-documented in the public header for the package. This has the
-advantage that all the comments are next to the code that would be
-editted if the interface has to be changed, i.e. function comments
-are next to the functions, typedef comments are next to the typedefs
-and so on.
-</BLOCKQUOTE>
-<BLOCKQUOTE>For an example of this see the documentation of the
-zmapConfig code in <B>include/ZMap/zmapConfig.h</B> and
-<B>zmapConfig/zmapConfig.c</B>. Note the use of the " <B>/*!
-@addtogroup</B> " directive to add the <B>include/ZMap/zmapConfig.h</B>
-documentation to that in <B>zmapConfig/zmapConfig.c</B>.
-</BLOCKQUOTE>
-<H2 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Configuration
-Files</H2>
-<BLOCKQUOTE>The Lexical Scanner package within GLib is used to read
-and write configuration files. The package requires a fair bit of
-work from the applications side to process stanzas and so on but
-using it has the advantage that we do not need to link in any further
-libraries. We could for instance have used the libgnome gnome-config
-calls, (see:
-http://developer.gnome.org/doc/API/2.0/libgnome/libgnome-gnome-config.html)
-but this would have required linking in the whole of the gnome
-application stuff).
-</BLOCKQUOTE>
-<H3 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Memory
-usage</H3>
-<BLOCKQUOTE>An experiment with creating rectangles in a gnome canvas
-showed that memory overhead is quite high. The upshot is that each
-canvas_item rectangle costs about 2600 bytes, this is probably
-because each one is represented by a GObject.
-</BLOCKQUOTE>
-<BLOCKQUOTE>You can see a plot of this data by running gnuplot and
-displaying the file gnome_canvas_mem_usage from this docs directory.
-</BLOCKQUOTE>
-<PRE STYLE="margin-left: 1cm; margin-right: 1cm">> gnuplot
-gnuplot> plot "gnome_canvas_mem_usage"</PRE><H3 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">
-Meeting Notes - Friday, 7th Feb, 2004</H3>
-<BLOCKQUOTE>Rob has made some progress determining what the Zmap and
-Fmap graph calls do and how to replace them with gtk calls, etc. The
-only relevant calls seem to be box, text and line, though there was
-one fmap circle call. This should be fine. He has created a zmap
-which uses gnomecanvas for the navigator and scrollable windows.
-There are issues with the scale bars which need to be addressed and
-there are numerous graph calls still included which need to be
-removed.
-</BLOCKQUOTE>
-<BLOCKQUOTE>He also has a noddy application with a nice-looking scale
-bar with coordinates and a feature consisting of two boxes joined by
-a bent line which also uses the canvas. This is a useful application
-for prototyping aspects of the project. Ed has done lots of work on
-threading and now has an application which has a single thread
-running a rather thin manager with multiple Zmaps, each of which will
-issue a DB thread to handle data manipulation.
-</BLOCKQUOTE>
-<BLOCKQUOTE>He returned from sunnier climes with a DAS2 server
-application which we hope to get set up so we can do some work using
-that as well as AceDB as our data source. He also has ExPat and
-libcurl libraries which do SAX simple Access and gzip and zlib which
-handle compression.
-</BLOCKQUOTE>
-<BLOCKQUOTE>Apparently this means our http can have <stag>
-content <etag> and our start callback routine will get called
-when it encounters the stag, the content routine gets called for the
-content and the end routine gets called for the etag.
-</BLOCKQUOTE>
-<H3 STYLE="margin-left: 1cm; margin-right: 1cm; margin-top: 0cm">Decisions</H3>
-<OL>
- <LI><BLOCKQUOTE STYLE="margin-bottom: 0cm">We decided that when the
- user hits the Split button it will just be the currently active
- window that is split, as in emacs, although the windows themselves
- will be held as a linked list at root level, so there won't be a
- hierarchy of windows in the application; they'll all have the same
- status.
- </BLOCKQUOTE>
- <LI><BLOCKQUOTE STYLE="margin-bottom: 0cm">There must be an
- arbitrary minimum size window which we'll allow to split, and beyond
- that the Split button will be greyed out. This will be controlled by
- some publicised macro I think.
- </BLOCKQUOTE>
- <LI><BLOCKQUOTE STYLE="margin-bottom: 0cm">We will only allow one
- sequence per Zmap. If they want another sequence, they'll have to
- run another Zmap.
- </BLOCKQUOTE>
- <LI><BLOCKQUOTE>We will retain the concept of three levels of
- scrolling. The main sequence will show as some sort of slider bar
- covering the entire height of the navigation panel. This can be
- thought of as range 'a'. The user can scroll within this area but
- the display won't change until buttonup, at which point the lights
- will dim. While moving the scroll bar, a little window should show
- the current coordinate, so they know where they are in the scroll.
- </BLOCKQUOTE>
- <BLOCKQUOTE>Within that is the sequence which has been calculated,
- roughly 3 times the amount that can be displayed in the window. This
- is currently shown as a light grey area within the navigation panel
- and can be thought of as range 'b'.
- </BLOCKQUOTE>
- <BLOCKQUOTE>We're thinking of adding a small scroll bar to this
- greyed are to allow the user to scroll within the calculated part of
- the sequence. We'd need to add extra scroll bars as the user split
- the screen, one per window. The handle would indicate roughly where
- in area 'b' the window display 'c' would be. Ed thinks recalculating
- this area as we scroll would be time-consuming, so we'd have to just
- redo it on buttonup, but I'm not convinced yet. If he's right, we'll
- need a little window showing the current coordinate for each 'c'
- window.
- </BLOCKQUOTE>
- <BLOCKQUOTE STYLE="margin-bottom: 0cm">Finally, there is the range
- actually on display, range 'c'. This is scrolled with the current
- scrolled window scrollbars and the display scrolls as you do it.
- </BLOCKQUOTE>
- <LI><BLOCKQUOTE STYLE="margin-bottom: 0cm">We'll need drag bars on
- the top and bottom of the calculated area b, so the user can stretch
- it, and the code must supplement the SEGS array rather than
- recalculate it from scratch.
- </BLOCKQUOTE>
- <LI><BLOCKQUOTE>When we calculate, we always calculate whole
- objects, so if a feature overlaps into the void, we include it in
- our calculated area, though we don't actually display it. When the
- user stretches the calculated area, we again calculate whole objects
- in both directions, then throw away duplicates, so we never have
- partial or duplicated objects.
- </BLOCKQUOTE>
-</OL>
-<HR>
-<H3>Column Controls</H3>
-<P>Press the button, a list of <!--#include virtual="/perl/footer" -->
-columns comes up, each with a check button. Default is all on. User
-toggles the check buttons to control whether or not a column is
-displayed. On Dismiss, call flagColumnsByCheck() to set flags in the
-ZmapWindow columns array of structures, then call showHideColumns()
-to show or hide them. Then call reOrderColumns() to shuffle the
-visible ones up.</P>
-<P>ShowHideColumns() will now be controlled by the ZmapWindow columns
-array, rather than the mag factor in the types array, so we'll need a
-flagColumnsByMag() function to set things up initially from the types
-array.</P>
-<P>ReOrderColumns() should use the ZmapFeatureType column_order
-variable to determine the order of the columns. A single int should
-be fine for both forward and reverse strands.</P>
-<P>I started to do this 08/12/04 but we decided there were higher
-priority tasks, so I'm abandoning it for now.</P>
-</BODY>
-</HTML>
diff --git a/doc/obsolete/issues.html b/doc/obsolete/issues.html
deleted file mode 100755
index 24c1ff160..000000000
--- a/doc/obsolete/issues.html
+++ /dev/null
@@ -1,46 +0,0 @@
-<HTML>
-
-<HEAD>
-<TITLE>ZMap Issues</TITLE>
-</HEAD>
-
-<BODY>
-<H2>ZMap Issues</H2>
-
-<p>This is a record of stuff that we want not to forget in case we want
-to look at again and make sure it's been properly resolved.
-<hr>
-<ol>
-<li>In zmapbccol.c at line 286 was a call to bumpItem(), but sometimes
- the bc->bump it passes as first parameter is null. bumpItem is a
- macro that executes (w1/bump.c) bumpAdd and it is here that the code
- segfaults when bc->bump is null.
-<font color = "red"> <pre>
-#define bumpItem(_b,_w,_h,_px,_py) bumpAdd(_b,_w,_h,_px,_py,TRUE)
-</pre>
-<font color = "green"><pre>
-BOOL bumpAdd (BUMP bump, int wid, float height,
- int *px, float *py, BOOL doIt)
- /* works by resetting x, y */
-{
- int i, j ;
- int x = *px ;
- float ynew, y = *py ;
-
- if (bump->magic != &BUMP_MAGIC)
- messcrash ("bumpAdd received corrupt bump->magic");
- </pre>
- <font color = "black">
- <p>
- For now, I've put in if(bc->bump) but that might not be right.
- <font color = "green"><pre>
- if (bc->bump)
- bumpItem(bc->bump, 1, seg->x2 - seg->x1, &xoff, &y);
- </pre><font color = "black">
-</li>
-<li>There is no No 2.
-</li>
-</ol>
-<hr>
-</body>
-</html>
diff --git a/doc/obsolete/lace.changes b/doc/obsolete/lace.changes
deleted file mode 100755
index 1d60ddc39..000000000
--- a/doc/obsolete/lace.changes
+++ /dev/null
@@ -1,141 +0,0 @@
-Roy,
-
-
-List of changes to put zmap into lace....
-
-
-1) otter/ensembl-otter/modules/Bio/Otter/Lace/Client.pm
-
-- add zmap port configuration
- (Done rds)
-- add zmap window_id directory configuration
- (Done rds)
-- Methods addded to Client
- (Done edgrif)
-
-- add browser to otterlace options and correctly create the correct objects
-
-
-otter/tk/MenuCanvasWindow/XaceSeqChooser.pm
-
-- launch_zmap() and get_zmap_xwindow_id() added to launch zmap instead of xace.
-
-
-
-otter/PerlModules/Hum/Ace/XaceRemote.pm
-
-- copy to XzmapRemote && s/(x)?ace/zmap/
-
-
-
-
-
-
-Some notes....
-
-XaceSeqChooser.pm and ZMapSeqChooser.pm have a lot of common code which I
-guess will go away if zmap replaces xace. For now I have just copied
-XaceSeqChooser.pm and hacked it to produce ZMapSeqChooser.pm.
-
-
-
-Loci
-----
-
-There is a lot of code to support manipulation of Locus objects and their
-asssociated display in fmap. I assume that this is mostly about showing the
-annotator what they have changed rather than using acedb as a repository of
-edits which then have to be extracted from the acedb database later.
-
-
-Methods
--------
-
-The code adds a method for showing genes if it does not exist in the database,
-it has color=blue and cds_color=midblue. The name comes from Defaults.pm and
-maybe from other places.
-
-I'm not sure from the code I've looked at how the methods are used. Need to find
-this out as we will be dealing with "types" or styles....
-
-
-
-
-
-Xremote Commands used:
-
-Are issued from the xace_remote object which includes the following methods:
-
-Method Purpose
-
-$xr->load_ace(<data to be parsed into acedb>) issues parse command add/modify/delete data
-
-$xr->save tells acedb to save to disk
-
-$xr->send_command(<string>) sends specified string which must be a
- recognised acedb command to acedb
-
-
-
-Functions:
-
-
-Function XaceSeqChooser.pm ZMapSeqChooser.pm
-
-
-update_ace_display 'gif ; seqrecalc' 'recalculate'
-
-We should check how this is used, if its purpose is to simply show a small update to
-perhaps exon boundaries or whatever then we should include in the recalculate command
-the item + coords to be updated and then do that directly in the zmap, not go through
-and recalculate the whole lot again.
-
-The function receives some ace file format data which it sends to acedb to be parsed in,
-it then saves and recalculates the fmap.
-
-
-save_data
-
-tries to do a save of the database and then may restart xace displaying the
-saved data.
-
-
-
-
-attach_xace 'writeaccess -gain' 'writeaccess'
-
-Is this needed for lace ? In the lace system perhaps all updates could be via the otter-lace
-interface.
-
-
-
-
-
-get_zmap_xwindow_id 'writeaccess -gain' 'writeaccess'
-
-Remarks as above.
-
-
-
-
-delete_subsequences 'gif ; seqrecalc' 'recalculate'
-
-Remarks as before, with the addition that this routine makes up a command to be
-parsed into acedb to remove objects and then saves and does a recalculation. To
-duplicate this we would need to do a recalculate but pass over the names of
-things to be removed.
-
-
-
-edit_new_subsequence integers_from_clipboard
-
-An indirect interaction with fmap, xace can be configured so that it puts the coords
-of a feature in the clip board when the feature is selected. We need to replicate
-this function.
-
-
-
-
-
-
-
diff --git a/doc/obsolete/porting_install.shtml b/doc/obsolete/porting_install.shtml
deleted file mode 100755
index b55a10d09..000000000
--- a/doc/obsolete/porting_install.shtml
+++ /dev/null
@@ -1,41 +0,0 @@
-<!--#set var="banner" value="ZMap Developer Docs"-->
-<!--#include virtual="/perl/header"-->
-<!--#set var="author" value="edgrif@sanger.ac.uk" -->
-
-<h1>Porting and Installation Notes</h1>
-
-
-<h2>Mac OSX</h2>
-
-
-<h3>compiles</h3>
-
-<P>The compile environment on the Mac is basically gcc et. al. so all should be
-very straight forward, but.....
-
-<ul>
- <li><b>Linking and expat</b>
- <ul>
- <li><b>Problem</b>we had problems linking with expat for a while because there
- seemed to be a rogue
- copy of expat in the Mac X11 libraries ! As this was back level it messed up our
- code.
- <li><b>Solution</b>This problem seems to have gone away now (OSX 10.3.9)
- </ul>
-</ul>
-
-<h3>DDD</h3>
-
-<P>We had problems with ddd and getting it to find the source code correctly.
-
-<P>In the end we had to comment out the following line in ~/ddd/.init:
-
-<P><pre>set pathname-substitutions
-</pre>
-
-<P>this seems to work now.
-
-
-<p>
-<!--#include virtual="/perl/footer"-->
-
diff --git a/doc/obsolete/user_guide.shtml b/doc/obsolete/user_guide.shtml
deleted file mode 100755
index 92301474d..000000000
--- a/doc/obsolete/user_guide.shtml
+++ /dev/null
@@ -1,53 +0,0 @@
-<pre>
-
-Roy,
-
-Some instructions for running zmap just to get you started....
-
-
-1) Setting up a .ZMap profile
-========================================================================
-
-cd
-
-mkdir .ZMap
-
-cd .ZMap
-
-cp ~edgrif/.ZMap/ZMap.roy ZMap
-
-cp ~edgrif/.ZMap/ZMapTypes.roy ZMapTypes.roy
-
-(note the name of the types file must match that given in the .ZMap/ZMap file)
-
-
-2) Setting up an acedb + database
-========================================================================
-
-cp ~/edgrif/acedb/CODE/acedb/bin.LINUX_4/sgifaceserver /wherever/you/want/to/put/it/
-
-cp -r ~edgrif/acedb/databases/b0250 /wherever/you/want/to/put/it/b0250
-
-
-3) starting the acedb server
-========================================================================
-
-sgifaceserver /wherever/you/want/to/put/it/b0250 20000 0:0
-
-(note that the port number must match that given in the file ~/.ZMap/ZMap
-and you must be running the server on the machine given there.)
-
-
-4) running zmap
-========================================================================
-
-zmap [ [ --start=NNN --end=NNN ] sequence_name ]
-
-
-try this to start:
-
-zmap b0250
-
-
-Ed
-</pre>
diff --git a/doc/project/2005_03_09.meeting b/doc/project/2005_03_09.meeting
deleted file mode 100755
index fac1f9be1..000000000
--- a/doc/project/2005_03_09.meeting
+++ /dev/null
@@ -1,106 +0,0 @@
-ZMap Meeting
-
-Date: 09.03.2005
-
-Present: Richard, Tim, Roy, Ed
-
-
-Aim:
-
-We want to get annotators trying out zmap in the lace system as early as
-possible. zmap will stand or fall by whether it is better to use than
-xace/fmap, its important to design a user interface that implements features
-that annotators will find useful.
-
-
-Overview:
-
-The lace system in essence merges various data sources into an acedb database,
-runs xace on the database allowing the annotators to use fmap to display the
-sequence. The lace system then provides its own GUI for the annotators to edit
-data, this GUI drives xace via the xremote mechanism to update its display and
-the local database as annotations are made.
-
-
-Plan:
-
-From this several requirements emerge for the intial integration of zmap:
-
-- replace xace with the sgifaceserver
-
-- run zmap off the sgifaceserver
-
-- add xremote commands to zmap: zmap already supports some commands but
- requires several more to replicate the existing interface
-
-- add support to call blixem/dotter, this will be using the same mechanism as
- xace does when calling them externally.
-
-
-This in essence would allow the annotators to use zmap for annotation. In
-practice it is certain that there will be missing functions but it will give
-us a system that we can develop in tandem with them.
-
-
-Future:
-
-The merging of data into an acedb database is a weak link in the lace system
-and the longer term aim is to remove any need for it by having zmap extract
-data directly from the mysql, ensembl etc. databases. Once the intial system
-is working these individual data sources can be picked off one by one.
-
-
-Decisions:
-
-It was agreed that being able to display multiple alignments would make zmap
-significantly better than the current fmap and that this should be a priority.
-The display of alignments should not be limited in the number of alignments
-that can be displayed. It was also agreed that display should be of "blocks
-of features" of one or more alignments against a master sequence rather than
-the more familiar but confusing "crossing line displays".
-
-Compara/ensembl can provide data for Dog-Human already and this should be the
-data source for our first experiments with multiple alignment display.
-
-The most straight forward approach to getting multiple alignment data is to
-code a perl DAS server to use the ensembl interface to retrieve the sets of
-features already mapped. The ZMap will interface to this server to make
-requests for the alignment data. In this way we will not have to add mapping
-code or understand the Compara alignment scheme in detail. This would mean
-however that zmap could not swop the reference/alignment sequences around
-without fetching all the data again.
-
-It was agreed that if we do add mapping code to ZMap, then this should be a
-subset of the smap code to do more restricted mapping translations. In
-addition a new function would be needed to map multiple alignments as the
-current code while dealing mapping over gaps expects the mapping as a whole to
-be colinear.
-
-Blixem and dotter will be supported although it would be good to remove the
-need to use blixem simply to verfiy splice site boundaries in relation to
-homologies.
-
-We should look at changing the lace xremote interface so that when edits are
-made, zmap can simply update the single feature updated rather than completely
-refetching the data.
-
-Also that zmap should initially not do any editing, unlike current xace, where
-at least remarks/comments are set using the xace display. This seems like a
-trivial addition to the otterlace interface, that I imagine would be
-relatively easy for anacode to set up. We need to look at how the editting
-cycle works in the current lace/xace setup.
-
-
-Zmap does not currently display a number of datatypes that will be needed, e.g.
-Stops, the frame translations, the actual sequence.
-
-
-We will provide web pages that document:
-
-- the xremote interface between lace and xace
-
-
-- data types (e.g. feature, transcript) and styles/methods
-
-
-- GUI interactions in the context of data types/methods
diff --git a/doc/project/2005_03_23.meeting b/doc/project/2005_03_23.meeting
deleted file mode 100755
index 0557e2955..000000000
--- a/doc/project/2005_03_23.meeting
+++ /dev/null
@@ -1,60 +0,0 @@
-ZMap Meeting
-
-
-Date: 23.03.2005
-
-
-Present: Richard, Ed, Roy
-
-
-Decisions:
-
-It was agreed that we need to work more on the integration of zmap into
-the otterlace system. To this end the launching of both xace and zmap from
-otterlace should be possible. Whilst we have a prototype working,
-which has replaced xace with zmap and a sgifaceserver, it is by no means
-production quality and needs work.
-
-Currently using Compara and a DAS server to dynamically serve align
-features appears to be off the cards at the moment. It was decided a
-static solution, most probably for the NOD/normal mouse comparisons that
-Charlie Steward is working on would be a good start to a) provide the
-data to prototype the display and b) create a visualisation tool for
-Charlie's annotation efforts.
-
-There was some discusion about two way communication between zmap and the
-Perl/Tk layer of otterlace to facilitate a richer user experience. James
-has already requested a feature of the new interface should be to request
-information from zmap and the concept of zmap being able to send otterlace
-information when something changes in zmap sounds like a reasonable
-possibly in terms of implementation.
-
-The demonstration of zmap highlighted a number of issues with respect to
-the GUI interaction.
- - A selected feature should be highlighted in all views
- - A selected feature should have it's "friends" highlighted
- - Zooming and scrolling should be "locked" by default and user
- "unlockable".
- - A v-split should by default lock the vertical scrolling between a pair
- of views
- - A h-split should by default lock the horizontal scrolling between a
- pair of views
- - scrolling should by default be locked between a pair of views
- - the display should be centred on click
- - Rich visualisation should be possible from context menus. e.g. the
- spliting of an intron to display the whole gene, 5' end of the intron
- and 3' end. (see attachment split_intron.png)
- - the currently focused view should be more obviously the currently
- focused view
-
-It was agreed we should provide a release/demonstration version of zmap
-for each meeting.
-
-It was agreed the website needs further organisation/work and that a
-zmap@sanger.ac.uk mail alias/list is a good idea.
-
-Our next meeting will be in three weeks at 1.00pm on the 19th April.
-
-
-
-
diff --git a/doc/project/2005_04_19.meeting b/doc/project/2005_04_19.meeting
deleted file mode 100755
index 41d47ea59..000000000
--- a/doc/project/2005_04_19.meeting
+++ /dev/null
@@ -1,93 +0,0 @@
-ZMap Meeting
-
-
-Date: 23.04.2005
-
-
-Present: Richard, Ed, Roy, Rob
-
-
-ZMap/otterlace:
-
-Roy has a prototype system with lace starting simultaneous xace/zmap processes
-which is good for comparison. He has been working on the atom/property
-communication system as the existing xremote code cannot give us all that we
-want.
-
-Roy has added code to Perl/Tk to do atoms/properties...amazingly this is
-missing from the Tk interface. We have a working system so that James can
-write perl to directly control the atoms/properties to communicate with
-zmap. A substantial improvement over the old system.
-
-
-Compara:
-
-We have not worked on this more.
-
-
-
-zmap GUI:
-
-Ed has been working on locking of windows and this is working, highlighting is
-on the way.
-
-The currently focussed view is more obvious but its hard work with gtk.
-
-The code is now in-place to more quickly do things like the intelligent viewing
-of transcripts.
-
-
-
-ZMap demo code/website/mail:
-
-There is now a ~acedb/ZMap, the demo code for alphas is:
-~acedb/ZMap/ZMap/src/zmap
-
-We now have a "zmap" mail alias set to Ed, Roy and Rob.
-
-Rob will be doing some work to set up web pages for the web site.
-
-
-
-Decisions:
-
-We need to produce a demonstration of zmap working alongside of xace in the
-lace system that is good enough that an annotator can start to try it out. In
-particular this needs to show how zmap will display multiple alignments as
-this is seen as a key factor in annotators wanting to use zmap at all.
-
-Ed will:
-
- - this week send out an email to James, Jen, Tim (cc'ing us) saying
- that we will produce the demonstration zmap, giving an idea of what
- it will do and suggesting/soliciting opinions about who would be
- a good person to test it.
-
- - send Richard an email on 9th May detailing more precisely what the
- demo. zmap will do, how it can be used etc.
-
-We will produce the demo. zmap for the 23rd May to show to Richard in our next
-zmap team meeting on that day. The demo. will need to include facilities that
-the annotators commonly use e.g. blixem.
-
-An obvious annotator would be Charlie as he is working the NOD and Black6
-mouse variants and this would provide a good test of the multiple alignment
-display.
-
-
-We also discussed:
-
-- we need to decide on the semantics of single/double clicking on features
-
-- the feature list needs some enhancements/fixes (e.g. it should centre on the
-feature the user clicked on).
-
-- we could allow the user to supply a list of their own features (like the
-"keyset" concept of acedb), this would not necessarily be features of the same
-type. This would be useful but is not seen as a priority.
-
-
-
-Our next meeting will be in three weeks at 1.00pm on the 23rd May.
-
-
diff --git a/doc/project/2006_01_06.meeting b/doc/project/2006_01_06.meeting
deleted file mode 100755
index 63a5b841e..000000000
--- a/doc/project/2006_01_06.meeting
+++ /dev/null
@@ -1,165 +0,0 @@
-ZMap Meeting
-
-
-Date: 06.01.2006
-
-
-Present: Ed, Roy
-
-
-
-lace system:
-
-status - needs testing for robustness and speed... **EG to install on his account and try it.
-
-problems -
-
-Currently
-
-Actions - **Roy to arrange a meeting with James et al. to dicuss following issues:
-
-1) Does the lace system read any data from the acedb database at the end of the
-session or is the database effectively READONLY ?
-
-2) Unique ids...can James supply these in the data from the database so we can read
-them directly. We already have a slot in our feature data struct for them. This unique
-id may be good to use in a separte hash of unique_ids -> canvas features which could
-unambiguously go from one to the other.
-
-3) Genefinder - can this be run from the perl code and then the results sent across
-to us as a Style + the data ? It makes for this to be done in the lace layer because
-gene finder is principally about interactive annotation.
-
-4) we have a performance problem with the g_dataset, to circumvent this can we reduce
-the number of homols being displayed ?
-
-5) Can we migrate quickly from the dual xace/zmap system to a zmap only system. **RS to check.
-
-6) discuss adding whole columns with James, e.g. genefinder data.
-
-
-
-XML-xremote mechanism:
-
-Currently we do not have the basic functions to add/modify/remove features to support
-this. We need this, and we may also need a function to get the server to parse in
-data. Can be tested via the feature editor. **EG to make sure this works.
-
-We need to review the operations in the XML-xremote interface, **RS to do this.
-
-We will need the xremote mechanism to dynanically add whole columns. This will involve
-operations to do at least:
-
-- adding the column name into our column list so it appears in the correct position
-in the columns.
-
-- adding the style for the column to our set of styles _before_ we are given the column
-itself.
-
-- adding a whole column with data.
-
-
-
-
-ZMap Display:
-
-- transcripts now display the CDS but not start/end not found. This data should be
-dumped in GFF and available. **RS to check this out.
-
-- separate scale window...not done but not a priority.
-
-- 3-frame translation, not done **RS to code this.
-
-- reverse complement, not done **EG to investigate, will users be prepared to put up
-with the hit of refetching the data or should we fudge it locally. Check how acedb does
-this now, I think Simon changed it not to cache data so much.
-
-- DNA highlighting - EG thinks he may have broken it in moving the code for
-the DNA into ordinary feature group. **RS to check.
-
-- mulitple feature types in a single column needs checking to see if it is still
-working. **EG to do this.
-
-- blixem needs to be checked to see it still works. **EG to do this.
-
-
-- methods and columns and things: we had a useful dicussion about these and came
-up with:
-
- - we need to publish a list of "reservered" style/method names for
- columns that are either derived dynamically or special in some way,
- e.g. dna, genefinder output, 3-frame translation. The user can create
- styles with these names and their style will be applied to these specific
- datasets (if available, e.g. the dna may not be available). The user
- cannot use these names for their own columns/data, they are reserved.
-
-
-In addition the rules concerning display will be tightened to be:
-
-- if any column is not in the columns list it will not be displayed.
-
-- if a column is in the columns list but there is no style for it, it will not be
-displayed.
-
-i.e. columns without styles will be removed from the columns list and will
-not be displayed.
-
-
-
-g_dataset problem:
-
-To recap:
-
-the glib g_dataset code grinds almost to a halt while we are processing the GFF
-from the server. We've not been able to profile this well within our threaded
-environment sadly. What we do know is that it seems to spend a lot of time in
-a free routine so it maybe a problem with glibs chunk routines for allocating
-blocks of memory. It may also be, as Roy suggests, that its having to search
-longer and longer lists of blocks...
-
-solution is to write a small program that uses the GFF parser to read in a file,
-this should be simple, in a single threaded program and see where the problem is.
-
-A temporary solution is to try and reduce the enormous number of homols being
-displayed.
-
-
-
-Styles, Features and canvas item drawing....:
-
-this is an old chestnut...what decides how a feature is drawn ? Is it only
-the style ? Is it the feature type (e.g. allele etc.) ? In acedb the feature
-type was the thing that decide it. We wanted to generalise this but there
-is a problem in that if the style is the only thing its hard to make pop-up
-menus and other things that are specific to certain feature types unless
-you add a feature type field to the method/style which means that now the
-style is the feature...and in any case the feature just contain exons etc
-so it is the feature as well...it just doesn't really work...
-
-So this is our sytem which is a blend...
-
-
-Feature drawn shape Style
-
-
-BASIC => read shape from style read shape as basic box,
- splice markers (for genefinder)
- constant shapes (for alleles)
-
-
-TRANSCRIPT => usual transcript shape read for colours
-
-
-ALIGNMENT => usual align shape read for colours
-
-
-This works because there three basic feature types should be enough to allow popup menus etc
-to work well but then we can avoid having endless types fields for alleles etc by having a
-drawing type in the style which will sort all this out.
-
-So in otherwords, the feature type decides what type of main shape the feature will be
-drawn as, but the style allows tailoring of the basic feature types.
-
-
-
-
diff --git a/doc/project/2007_02_07.meeting b/doc/project/2007_02_07.meeting
deleted file mode 100755
index f461d3d85..000000000
--- a/doc/project/2007_02_07.meeting
+++ /dev/null
@@ -1,196 +0,0 @@
-ZMap Meeting
-
-Date: 07.02.2007
-
-Present: James, Leo, Roy, Ed
-
-Overview:
-
-There are currently a few missing links in the interactions between
-zmap and otterlace, specifically, only editing is possible at the
-moment. We should be doing more to support things such as
-highlighting objects in both programs after selection in one or the
-other. This includes multiple selection. In addition there are
-further operations we need to be able to do like opening a new
-sequence in zmap.
-
-
-Discussion:
-
-Currently the xremote interactions are only at edit time and generally
-all follow the same style of xml, namely:
-
-<zmap action="__action__">
- ... data to complete the action ...
-</zmap>
-
-This is fine for editing at the moment, but I can see it all getting a
-little confusing. What action does what? and what information do they
-all require? We need a document or two in cvs that describes what and
-who can each action applies to. The xsd document I initially provided
-is all well and good, but it's a) out of date b) in the zmap cvs (can
-you guys see it) c) incomplete when it comes to finding out what an
-action does. and d) xml :(
-
-So what should go in this file? I've prepared a list of what I know
-each application can provide/do.
-
-
-Action Program Details
----------------------------------------------------------------------
-open zmap (m) opens a zmap feature display window. Requires
- <segment sequence="str" start="int" end="int"/>
-
-close zmap (m) closes zmap. The complete application
-shutdown zmap (m) alias for close.
-
-zoom_in zmap zoom the currently focused window by 2x
-
-zoom_out zmap zoom the currently focused window by 0.5x
-
-create_client zmap register's a client internally with zmap. Req.
- <client id="id" request="str" response="str"/>
-
-create_feature zmap create feature(s) on the zmap display from the
- featureset supplied.
-
-delete_feature zmap deletes feature(s) that already exist on the
- zmap display.
-
-new_view zmap opens a new sequence using the supplied
- information to fetch the data. Requires
- <segment sequence="str" start="int" end="int">
- source{
- url = "url"
- featuresets = "feature sets"
- }
- </segment>
-
-edit otterlace Edit an object in otterlace.
- Requires a featureset.
- ZMap expects a response <response handled="boolean">
-
-register_client otterlace register's a client internally with zmap. Req.
- <client id="id" request="str" response="str"/>
- Why is this not create_client???
-
-
-Additions/Changes are up for discussion.
-
-For the multiple species display is new_view enough?
-
-Here's some RT tickets...
-
-
-RT ticket #20283
-----------------
-Liz,
-
-> When I click on a bit of cDNA evidence and bring up the Zmap Feature
-> Editor Window, it would be really useful if I could highlight the name
-> of the cDNA and so that we can copy and paste into somewhere else (e.g
-> into search box of NCBI EntrezGene website).
->
-> I suppose I could do this from blixem, but, just a thought...
-
-This presents a bit of a quandry......our "feature list" and "feature
-edit" windows are both set up to scroll to and highlight the name that
-you click on, this also results in a brief description of the feature
-being put into the common "edit" buffer in this form:
-
-"Em:BT020903.1" 40645 40742 (98)
-
-This is a hangover from acedb and perahps we should just put the feature
-name in the edit buffer. I'll have a think about it. In the meantime I
-guess you could use the above and delete the bits you dno't want...not
-ideal though, I can see that....
-
-Ed
-----------------
-
-I can't remember why this string is like this. Does it get used by
-xace? Or it just for otterlace to get hold of the data via the
-clipboard. Could we subvert this with xml so that we only stick the
-name in the clipboard?
-
-
-
-
-
-RT ticket #20304
-----------------
-
-I would like single click events that highlight objects in Zmap to be
-passed to otterlace. This will enable us to do things like highlight the
-exon coordinates in a transcript editing window when an exon is clicked
-on, or highlight the name of the transcript in the XaceSeqChooser.
-
-Similarly, I would like to be able to send requests to Zmap to highlight
-(and scroll to reveal, if necessary) objects from otterlace.
-
-James
-
-
-RT ticket #20255
-----------------
-
-One thing that came out of yesterdays zmap demo was the requirement to
-build objects from supporting evidence. This is not a new request, but
-now zmap can do multiple select [ticket #10152] we should work out a way
-to enable this. Firstly I need to do some work to remember what
-currently happens [ticket #20173]. Is there a preferred solution?
-
-
-RT ticket #8588
----------------
-Hi,
-
-At the moment it's possible to create a new object based on the exon of
-the evidence highlighted on the fmap. Would it be possible to do the
-same with zmap.
-
-Also, it was mentioned yesterday that exons of ESTs or cDNAs may be
-linked by lines similar to the intron lines in objects. If this is the
-case, would it be possible to build a new object based on all these
-linked exons instead of just the highlighted one?
-
-thanks
-
-Sarah
-
-
-
-Actions:
---------
-
-1) Investigate checking out from ~zmap/CVS for anacode users. EG
-
-2) Create a synopsis document to accompany the xsd document and keep
- them up to date. RDS
-
-3) Add zoom_to to the xremote protocol. This should accpet either a
- simple range or a feature to which zmap should add a border. RDS
-
-4) otterlace needs to be notified when a zmap view is closed. RDS
-
-5) Although zmap understands the action new_view, this is not enough
- for all the alternatives that exist. It should also be possible to
- close each individual view. Also the open command is very similar
- if not identical so we need to merge these. RDS
-
-6) Views need to be addressable by otterlace. The reply to an open
- command should contain the addressable id. RDS
-
-7) register_client and create_client should be merged to only be
- register_client. RDS, JGRG
-
-8) Single and multiple selects are to be transferred a click at a time
- and will be distinguishable by an attribute. The cut buffer will
- be additively extended for multiple selects. This will be
- bi-directional, so that selections will be mirrored in the two
- progams. RDS, JGRG
-
-9) Check copy / paste from zmap info boxes. EG
-
-10) build a new zmap RDS, EG
-
diff --git a/doc/project/zmap_lace_tasks.txt b/doc/project/zmap_lace_tasks.txt
deleted file mode 100755
index e30cf8299..000000000
--- a/doc/project/zmap_lace_tasks.txt
+++ /dev/null
@@ -1,204 +0,0 @@
-ZMap - items for lace integration
----------------------------------
-
-
-The plan is to put zmap into test_otterlace straight away even though we know
-not everything that is required is implemented yet. Liz/Charlie will be the
-guinea pigs for the test initially. We will meet again in a month to review
-how it's gone and what we need to do next.
-
-
-
-Priorities:
------------
-
-*** Do right now
-** Do this month
-* Think about
-
-
-
-Configuration
--------------
-
-*
-- need to be able to do "per team" configurations of different parts of zmap
-(e.g. of what goes in the cut buffer and in what format).
-
-
-
-Transcript operations
----------------------
-
-
-** EG doing this. <DONE>
-- contextual menu on gene object:
- + show CDS translation in zmap
- + show CDS translation (including *stopcodon) in separate (copy-pastable)
- window
- + export CDS translation (fasta seq saved to file)
- + show CDS sequence (nucleotide seq of CDS incl stop codon) in separate
- (copy-pastable) window
- + export CDS sequence (fasta of nucleotide seq of CDS incl stop codon
- saved to a file)
-
- + export entire mRNA sequence (fasta seq saved to file)
- + show entire mRNA sequence in separate (copy-pastable) window
-
- + export genomic sequence of transcript (fasta seq saved to file)
- (we could colour the genomic span when displayed in a separate
- window to make it obvious which are exons and which introns.
-
-EG acedb has translation code which handles different translation tables, I
-will pinch the code....
-
-I have a comment about showing the size of a protein translation, I think this
-might be in the status line if you click on the translation ?
-<DONE>
-
-
-
-**
-- objects should carry http links so that web pages (e.g. ensemble/pfam) that
-carry more information about them can be displayed.
-
-EG Sequence class has a web_location tag which points to a url object, this is
-quite complex and poorly documented so I will need to look in the code....so
-it maybe very simple for us to add this.
-
-
-*
-- pattern or word search (peptide and nucleotide) of genomic seq as currently
-under "restriction enzyme digest" and highlight results in fmap (currently
-when DNA is shown, highlighted with colored background (different colors for
-forward and reverse match) and also the matches are indicated by printing out
-the search term in a column close to the central yellow divider)
-
-EG This is probably best implemented by lace doing a patten search and then
-sending us the results as a new column + matches that we need to draw as
-"features" in the column.
-
-
-
-Display stuff
--------------
-
-***
-- copy-paste from pfetch text window
-EG I think this is done already via gtk text widget..
-<DONE>
-
-
-**
-- display ORF's
-EG I will hack ace server to allow ORFs to be dumped.
-
-
-
-**
-- need 3 frame translation in the window.
-- show ORFs in all three frames (i.e. show stopcodons)
-- show 3-frame translation of genomic seq (sequence selectable and copyable
-like dna seq above)
-
-
-**
-- clicking on a transcript or exon should highlight that exons dna if the dna
-is displayed (agreed that dna could be highlighted by colouring the
-background).
-- if dna seq is shown, highlight the extent of any box/feature user clicks on.
-
-
-*** EG THIS IS DONE APART FROM THE RESTORE DEFAULT BUTTON, THEY DIDN'T HAVE THIS
-IN ACEDB SO ITS NOT THAT GREAT A PRIORITY...
-- column configuration should be a main button in the zmap window, should be
-able to reset to defaults with single click....perhaps reset should reset the
-whole interface.
-- "configure all columns" button in button bar at top (currently a submenu in
-column contextual menu)
-- "restore global default" button in button bar at top (i.e. restore default
-columns etc.)
-
-
-<DONE>
-- double clicking on an object should display the "properties" window.
-- double click (proper double click !!!) on a feature and get a "property
-inspector" window (like tree display in fmap). Possibly super-user (but not
-user!) configurable
-<DONE>
-
-
-*** RDS_DOING_THIS
-- put the scale by the yellow strand separator
-
-
-
-*** RDS_DOING_THIS
-- cut displayed DNA direct into the cut buffer for access from other
-applications.
-- when dna seq is shown in zmap, select a stretch of sequence -> contextual
-menu item "copy" or it could happen automatically
-
-
-**
-- allow printing of the current zmap to a file
-- postscript printing the zmap
-
-EG acedb does this by steam and we could pinch the code.
-
-
-*** RDS_DOING_THIS
-- clicking on a column will turn the background of that column to light grey
-to emphasise that it has been selected.
-- trial of subtly highlighting entire column background when left-clicking on
-the column background
-<DONE>
-
-***
-- each sub window of a zmap should contain more information in the title which
-should include at least the species.
-
-
-*
-- the current left hand scroll bar should be replaced with a locator which
-shows clone position/direction/overlaps/names in a similar "stepped" display
-as fmap does currently. We could also put a scale in this window.
-- canvas with clone tiling path (with names) on the left and proprtional
-scroll thumb for navigational purposes.
-
-
-**
-- users should be able to lock windows together in positions they choose.
-
-
-
-Blixem
-------
-
-*
-- there should be more communication between blixem and zmap so that things
-clicked on in zmap get highlighted in zmap and vice versa. Probably we need to
-fork blixem so that we can leave behind the old acedb version.
-
-
-
-Genefinder
-----------
-
-*
-we can get the genefinder information from gifaceserver but it requires a
-change to the server to the ORFs output and we need to decide whether to get
-it all at the start or to get some later...
-- genefinder features (start codons (with Kozak score), coding potential,
-splice sites, etc.)
-
-
-
---
- ------------------------------------------------------------------------
-| Ed Griffiths, Acedb development, Informatics Group, |
-| The Morgan Building, Sanger Institute, Wellcome Trust Genome Campus |
-| Hinxton, Cambridge CB10 1HH |
-| |
-| email: edgrif@sanger.ac.uk Tel: +44-1223-496844 Fax: +44-1223-494919 |
- ------------------------------------------------------------------------
diff --git a/doc/wemap/README b/doc/wemap/README
deleted file mode 100755
index 86b76026b..000000000
--- a/doc/wemap/README
+++ /dev/null
@@ -1,6 +0,0 @@
-
-The fex files are the original thinking for the split off fmap.
-
-They are here as a placeholder only, we should take what we want from
-them and ditch the rest.
-
diff --git a/doc/wemap/fex.h b/doc/wemap/fex.h
deleted file mode 100755
index 0271a9feb..000000000
--- a/doc/wemap/fex.h
+++ /dev/null
@@ -1,343 +0,0 @@
-/* File: fex.h
- * Author: Ed Griffiths (edgrif@sanger.ac.uk)
- * and Richard Durbin (rd@sanger.ac.uk)
- * Copyright (c) J Thierry-Mieg and R Durbin, 2002
- *-------------------------------------------------------------------
- * Acedb is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- * or see the on-line version at http://www.gnu.org/copyleft/gpl.txt
- *-------------------------------------------------------------------
- * This file is part of the ACEDB genome database package, written by
- * Richard Durbin (Sanger Centre, UK) rd@sanger.ac.uk, and
- * Jean Thierry-Mieg (CRBM du CNRS, France) mieg@kaa.crbm.cnrs-mop.fr
- *
- * Description: The interface for querying a database to get genome
- * information for displaying a physical map and then
- * annotating the genetic information in that map.
- *
- * The name "fex" is an acronym for "Feature EXchange".
- *
- * This is the interface as seen by the C code in the
- * client program, in some places the CORBA layer will
- * be need to be a little different.
- *
- * HISTORY:
- * Last edited: Jan 29 14:06 2002 (edgrif)
- * Created: Wed Jan 16 15:23:44 2002 (edgrif)
- * CVS info: $Id: fex.h,v 1.1 2003-12-12 14:30:38 edgrif Exp $
- *-------------------------------------------------------------------
- */
-#ifndef FEX_DEF
-#define FEX_DEF
-
-
-
-/*********** basic types ************/
-
-/* ALL_FEATURES is for fexAvailableFeatureSets() */
-/* What about "sequence", atg, and allele as basic feature types ? */
-typedef enum { BASIC_FEATURE, HOMOL_FEATURE, EXON_FEATURE,
- TRANSCRIPT_FEATURE, VARIATION_FEATURE,
- INTRON_FEATURE, BOUNDARY_FEATURE, ALL_FEATURES
- } FexFeatureType ;
-
-typedef enum { NO_STRAND = 0, DOWN_STRAND, UP_STRAND } FexStrand ;
-
-typedef enum { NO_PHASE = 0, PHASE_0, PHASE_1, PHASE_2 } FexPhase ;
-
-/* as in BLAST*, i.e. target is DNA, Protein, DNA translated */
-typedef enum { N_HOMOL, X_HOMOL, TX_HOMOL } FexHomolType ;
-
-typedef enum { CLONE_END, 5_SPLICE, 3_SPLICE } FexBoundaryType ;
-
-typedef enum { OK_STATUS = 0, NO_WRITE_ACCESS, ILLEGAL_FEATURE,
- ILLEGAL_ATTRIBUTE
- } FexStatus ;
-
-/*********** opaque types for server handles ************/
-
-typedef struct DatabaseContext *FexDB ;
-typedef struct SequenceContext *FexSeq ; /* should cache DB handle */
-typedef unsigned int FexID ;
-
-/*********** local types corresponding to CORBA structs ***********/
-
-
-/* Describes the type of features to be found in a particular feature set, */
-/* the set is indentified by its name. The structure can be quizzed to check */
-/* details such as "are these features strand sensitive ?". */
-/* */
-
-typedef struct {
- char *name ; /* e.g. "Genewise predictions" */
- FexFeatureType type ; /* e.g. INTRON_FEATURE */
- char *category ; /* GFF_feature, BioPerl primary_tag */
- char *source ; /* GFF_source = ?? */
- BOOL isStrandSensitive ;
- BOOL isFrameSensitive ; /* phase becomes important */
- BOOL isScore ;
- FexHomolType homolType ; /* for Homols only */
- char *targetDataSource ; /* for Homols only */
- FexBoundaryType boundType ; /* for Boundaries only */
- BOOL isWritable ;
- Array legalAttributeTags ; /* of char*, allowable attributes for this feature set. */
-} FexFeatureSetDataInfo ;
-
-
-/* the following is used to store alignment gap information */
-typedef struct
-{
- int s1, s2 ; /* coords in input space */
- int r1, r2 ; /* coords in output space */
-} FexAlignBlock ; /* this is identical to SMapMap in smap.h */
-
-
-
-/* A feature, it will be of type FeatureType and be indentified uniquely by */
-/* some kind of database id, but also by a text name. */
-
-/* Big decision:
- The primary Feature object is a union, not set of subclasses
- inheriting from a core class.
- This simplifies and helps make transfer protocols efficient for C
- in particular.
- Problems are:
- Efficiency: core feature is 26 bytes assuming 1 byte per enum.
- The biggest union components add 18 extra bytes, and a high
- fraction of the features (e.g. all homols) will need the max
- anyway. It doesn't seem worth separating the data structures and
- duplicating lots of calls, requiring switches etc.
-
- It may turn out to be useful to use the style of struct used for XEvents.
-
- Elegance: in the eye of the beholder, but we'll try to keep it
- clean.
-*/
-
-typedef struct {
- FEXFeatureType type ; /* e.g. INTRON_FEATURE */
- FEXID id ; /* unique DB identifier. */
- char *name ; /* e.g. bA404F10.4.mRNA */
- int x1, x2 ; /* start, end */
- FexStrand strand ;
- FexPhase phase ;
- float score ;
- char *text ; /* What is this for ? */
- union
- {
- struct
- {
- int y1, y2 ; /* targetStart, targetEnd */
- FexStrand targetStrand ;
- FexPhase targetPhase ; /* for TX_HOMOL */
- Array align ; /* of AlignBlock */
- /* if align is null, then ungapped */
- } homol ;
- struct
- {
- int cdsStart, cdsEnd ;
- BOOL startNotFound ; /* is this really a bool ? */
- FexPhase cdsPhase ; /* = NO_PHASE unless startNotFound */
- BOOL endNotFound ; /* is this really a bool ? */
- Array exons ; /* of Feature */
- } transcript ;
- struct
- {
- FexID transcriptID ;
- } exon ;
- } feature ;
-
-} Feature ;
-
-
-
-
-
-/**********************************************/
-
-/* There will need to be a set of "database management" type functions */
-/* I've trivially added a couple here just as a placeholder to remind us */
-/* that these will be required. */
-FexDB fexOpenDatabase(char *locator, char *user, char *password) ;
-void fexCloseDatabase(FexDB db) ;
-BOOL fexCheckWriteAccess(FexDB db) ;
-BOOL fexSetWriteAccess(FexDB db, BOOL access) ;
-
-
-
-/* Ask for all possible feature sets for sequences. */
-Array fexQueryFeatureSets(FexDB db) ;
-
-/* Assume we don't need to ask for all possible basic features. */
-
-
-/* end = 0 for end_of_sequence, so (start, end) = (1,0) for whole sequence */
-FexSeq fexSequence(FexDB db, char* seqName, int start, int end) ;
-
-char* fexDNA(FexSeq context) ; /* returns IUPAC plus '-' for blank */
-
-Array fexQuerySeqFeatSets(FexSeq context) ; /* Array of char* of feature set names */
-
-FexFeatureSetDataInfo *fexFeatSetDataInfo(FexDB db, char *fsetName) ;
- /* Get the info. for just one feature */
- /* set. */
-
-Array fexTypeFeatureSetDataInfo(FEXContext context, FEXFeatureType type) ;
- /* Get info. for all features of a */
- /* certain type. */
-
-/* Get the info. for all feature sets available for a piece of sequence. */
-Array fexAllFeatureSetDataInfo(FexDB db) ;
-
-
-/* Get features by feature set name. */
-Array fexGetFeatures(FexContext context, Array feature_names) ; /* Array of Feature structs */
-
-/* Get features by basic type. */
-Array fexGetFeaturesType(FexContext context, FEXFeatureType type) ;
-
-/* Clear up all of the sequence on the server and locally. */
-void fexDestroySequence(FexSeq context) ;
-
-
-
-
-/*****************************************************************************/
-/********************** search ***************************************/
-
-/* We separated this out from FeatureSet, so can get information on where
- to find the sequence from other sources than the database. I guess the
- fetch thing should also be accessed via URLget, and we should set up
- interfaces for that.
-*/
-
-typedef struct {
- char *urlFormat ; /* printf style format with %s for target name */
- char *fetchFormat ; /* similar format, but to fetch sequence */
- char *removePrefix ; /* prefix to remove from names before substituting in formats */
- /* Apollo has something good here that is a bit more powerful for good reasons */
-} FexTargetDataSource ;
-
-FexTargetDataSource *fexTargetDataSource(FexDB db, char* dataSource) ;
-
-
-
-/*****************************************************************************/
-/********************** drawing ***************************************/
-
-/* We separated this out from FeatureSet, so can get information on how
- to display the features from sources other than the database, perhaps
- a user preference file.
-*/
-
-typedef enum { BY_WIDTH, BY_OFFSET, BY_HISTOGRAM } FexDrawStyle ;
-typedef enum { OVERLAP, BUMP, CLUSTER } FexOverlapStyle ;
-
-
-typedef struct
-{
- Colour outline ; /* Surround/line colour. */
- Colour foreground ; /* Overlaid on background. */
- Colour background ; /* Fill colour. */
- float right_priority ;
- FexDrawStyle drawStyle ;
- FexOverlapStyle overlapStyle ;
- float width ; /* column width */
- float min_mag, max_mag ;
- float min_score, max_score ;
- BOOL showText ;
- BOOL showUpStrand ;
-} FexFeatureSetDrawInfo ;
-
-
-FexFeatureSetDrawInfo *fexFeatureSetDrawInfo(FexDB db, char *feature_set_name) ;
- /* Get a single sets drawing info. */
-Array fexFeatureSetsDrawInfo(FexDB db, Array feature_set_names) ;
- /* Get multiple sets of draw info. */
-
-
-/*****************************************************************************/
-/********************* write back **************************************/
-
-/* In the following, attributes is additional textual information in
- attribute/value per line format (as for .ace files). If you want to
- communicate gene_name hints/info back and forth with the server you
- can use this. Also attributes to be assigned to the gene. The client
- will just neutrally put these up and allow them to be edited, deleted
- and added to, and passed back to the server. The attributeTagList field
- of FexFeatureSetDataInfo lists the fields allowed for each feature set.
-*/
-
-typedef struct
-{
- char *tag ;
- char *value ;
-} Attribute ;
-
-FexStatus fexNewFeature(FexDB db, char *fsetName, FexID *dbidPtr,
- Feature *feature, Array attributes) ;
-
-FexStatus fexReplaceFeature(FexDB db, char *fsetName, FexID dbid,
- Feature *feature, Array attributes) ;
- /* if feature is null, just replace attributes and vice versa */
-
-FexStatus fexKillFeature(FexDB db, FexID dbid, Array attributes) ;
- /* may want to change attributes because "kill" will only archive,
- depending on server behaviour */
-
-/* need also */
-
-Array fexGetAttributes(FexDB db, FexID dbid) ; /* of FexAttribute */
-
-/* Note there is no way to write a gene as such, nor a naked exon.
-
- 010811 RD: Current proposal is as follows
- Within an fset:
-
- In the interface, a "curate" action on a transcript does the followring:
- - if identical to a curated transcript then killTranscript or editAttributes
- - else options are storeTranscript, or replaceTranscript for each that
- it overlaps.
-
- If you store a transcript not overlapping any genes it creates a new gene.
- On the server side, an idea to explore would be that if this new gene
- overlaps one or more history genes then it is marked as having split
- from the most recent that it overlaps.
-
- If you store a transcript overlapping only transcripts from one gene, then
- you can either replace one of those transcripts or create a new one.
-
- If you store a transcript that overlaps multiple current genes then it
- must replace one of the existing transcripts. This is because the new
- transcript will merge all the genes covered, and the requirement to
- replace an existing transcript allows us to determine which gene the
- resulting merge becomes.
-
- Similarly if you were allowed to kill a transcript that acts as a
- bridge, hence creating new genes by splitting, it would not be clear
- which child should keep the parent's name. So I plan to ban such kills,
- requiring a replace action to remove the bridging transcript, so it is
- clear which child inherits the name (the one containing the replaced
- transcript).
-
- Of course all these restrictions would go if the gene identifier model
- was that the products of merges and splits all had new identifiers.
- So I guess the restrictions listed above should be a client option,
- maybe settable via a server. Or perhaps should be rules the server
- uses to reject a curate event.
-*/
-
-/******************* end of file ***********************/
-#endif /* FEX_DEF */
-
diff --git a/doc/wemap/fex.idl b/doc/wemap/fex.idl
deleted file mode 100755
index bd55d9b12..000000000
--- a/doc/wemap/fex.idl
+++ /dev/null
@@ -1,203 +0,0 @@
-//
-// FEX client/server definition.
-//
-// Defines code to open a CORBA connection to a database and then
-// use that connection to ask for feature information.
-//
-
-
-module FEX
-{
-
- //
- // Basic structs and datatypes.
- //
- typedef sequence<string> StrSeq ;
-
-
-
- enum FeatureType { BASIC_FEATURE, HOMOL_FEATURE, EXON_FEATURE, TRANSCRIPT_FEATURE,
- VARIATION_FEATURE, INTRON_FEATURE, BOUNDARY_FEATURE } ;
-
- enum Strand { NO_STRAND = 0, DOWN_STRAND, UP_STRAND } ;
-
- enum Phase { NO_PHASE = 0, PHASE_0, PHASE_1, PHASE_2 } ;
-
- enum HomolSubType { N_HOMOL, X_HOMOL, TX_HOMOL } ;
-
- enum BoundarySubType { CLONE_END, 5_SPLICE, 3_SPLICE } ;
- /* as in BLAST*, i.e. target is DNA, Protein, DNA translated */
-
- // Do we need this ?? not sure...
- enum Status { OK_STATUS, NO_WRITE_ACCESS } ;
-
-
-
-
-
-
-
- // Every feature, and hence set of features, will be of a particular class
- // and will have a name that identifies it to the user.
- //
- struct FeatureSetInfo
- {
- String name ; // Name of feature set, e.g. "Genewise
- // Predicted Genes".
- FeatureType type ; // Type of feature, e.g. IntronExon
-
- // How do these relate to "name" above...talk to rd.
- string category ; /* GFF_feature = BioPerl primary_tag */
- string source ; /* GFF_source = ?? */
-
- boolean isStrandSensitive ;
- boolean isFrameSensitive ; /* phase becomes important */
- boolean isScore ;
-
- HomolSubType homolType ; /* for Homols only */
-
- string targetDataSource ; /* for Homols only */
-
- BoundarySubType boundType ; /* for Boundaries only */
-
- StrSeq attributeList ; /* of char*, allowable attributes for
- this fset */
-
- } ;
-
- typedef sequence<FeatureSetInfo> FeatureSetInfoSeq ;
-
-
-
- // Basic struct defining a single feature such as a gene, or a splice site.
- //
- struct Feature
- {
- DB_ID key ; // key of object in DB
- string name ; // string name of object
- union
- {
- Sequence IntronExon intron_exon ;
- Sequence Homol homol ;
- // etc. etc.
- }
- } ;
-
-
- // Struct holding a set of Features, all of one FeatureType.
- //
- struct FeatureSet
- {
- unsigned long num_features ; // Number of features in this set.
- sequence<Feature> features ; // Basically an array of features.
- } ;
-
-
-
-
- //
- // Interfaces to FEX
- //
- // Note that this interface allows us to get sequence and drawing information
- // independently from different databases. I expect that this bit will need
- // modification to cope with passing DB ids around. The constructors take
- // as one of the parameters the Connection, this is cached in the object
- // so we don't have to keep supplying it for every call.
- //
-
- // In CORBA speak the constructors for the objects will be via a factory
- // object which will do the actual business of construction.
- //
- interface connectDBFactory
- {
- Connection connectDB(in URL where_db_is, in string userid, in string passwd) ;
-
- // N.B. requires a Connection object so it knows which DB to go to, and a
- // Sequence_id/start/end to say which bit of sequence is to be retrieved.
- Sequence getSequence(in Connection db, in Sequence_id id, in int start, in int end) ;
-
-
- DrawMethod getDrawMethod(in Connection db) ;
- } ;
-
-
-
- // The database interface.
- // We use this to open a connection to the database, this can
- // then be used to get hold of features etc.
- interface Connection
- {
- // placeholder, this will need to be some kind of query type operation.
- // We need to somehow find out what at what level we can ask for sequences
- // from the database.
- Sequence_id findSequence(string clone_name) ;
-
-
- boolean checkWriteAccess() ;
- boolean setWriteAccess(boolean access) ;
-
-
- // destructor will close connection and clean up.
- } ;
-
-
-
-
- // The feature interface.
- // Constructor takes a reference to the database, some kind of identifier to
- // say which piece of sequence is required and coordinates.
- interface Sequence
- {
- // Should return names and info. about them, as these correspond to columns
- // in fmap we might as well get them all in one go.
- FeatureSetInfoSeq listAllFeatureSets() ;
-
- // Get info. for all features of a particular type.
- FeatureSetInfoSeq listTypeFeatureSets(in FeatureType type) ;
-
- // Get info. for a single feature type.
- FeatureSetInfo getFeatureSet(in string name) ;
-
-
-
-
-
- } ;
-
-
- //
- // The drawing method interface.
- // Each feature will be drawn with in a particular style according to
- // its FeatureType, in addition the style may have been tailored for
- // feature (e.g. in foreground colour etc.).
- //
- interface DrawMethod
- {
-
-
-
- } ;
-
-
-
-} ;
-
-
-
-
-
-
-
-
-
-
-// Probably we will want to follow X Windows and replace all strings
-// with atoms/keys call them what you want, but lets not worry about this
-// just yet.
-
-
-// NOTES:
-// we need to map a Feature to its FeatureType, how shall we do this ?
-// Perhaps we should introduce a "key" now for this ??
-
-
diff --git a/doc/wemap/fex.synopsis.html b/doc/wemap/fex.synopsis.html
deleted file mode 100755
index 6127bb923..000000000
--- a/doc/wemap/fex.synopsis.html
+++ /dev/null
@@ -1,220 +0,0 @@
-<HTML>
-
-<HEAD>
-<TITLE>FEX Version 0.1 Synopsis</TITLE>
-
-<LINK rel=stylesheet type="text/css"
-href="./wdoc.css"
-title="Style sheet for wdoc developer documents">
-
-</HEAD>
-
-
-<BODY>
-
-<BLOCKQUOTE>
-<DIV ALIGN=CENTER>
- <IMG SRC="./acedb-logo.gif" ALT="[FEX 0.1]" align=middle>
- <H3>
- FEX Version 0.1
- </H3>
-</DIV>
-
-
-<DIV ALIGN=CENTER>
-
-<H1 align=center>
-FEX - A Feature EXchange Interface
-</H1>
-
-<ADDRESS>Originally written by<BR>
-Ed Griffiths <edgrif@sanger.ac.uk>, January 2002</ADDRESS>
-
-</DIV>
-
-<H2>Background</H2>
-
-<P>There is a need for a version of the AceDB fmap that can be used over
-the network. The viewer/annotator could be used against any database that
-could provide the sequence information required by the viewer.
-
-
-
-
-<H2>Overview</H2>
-
-<P>The fex interface is a new interface for accessing sequence data and features,
-it is designed to be independent of any one database.
-
-
-
-<H2>Basic Concepts</H2>
-
-<P>Some basic terms:
-
-<dl>
- <dt><b>"Feature type"</b>
- <dd>the basic types of feature that can appear on a physical map
- such as BASIC_FEATURE, INTRON_FEATURE. Every feature displayed must
- be of one of these types.
- <dt><b>"Feature"</b>
- <dd>a single piece of physical data such as a transcript which
- will be of one of the "Feature type" types. This will have
- have some unique identifier such as a specific gene name.
- <dt><b>"Feature set"</b>
- <dd>a set of "Features" that are grouped together because they
- are not only all of the same "Feature type" type, but are
- related in some other way, e.g. they are all Genewise predictions.
- They are given some name by the curator of the database, these
- correspond to the "methods" in acedb.
-</dl>
-
-
-Possible feature types in giface gff dumping based on a feature name...
-
-seg->type featName
-========= ========
-
-SEQUENCE |
-EXON | (GFF version == 2) && seg->key then put className(seg->key)
-INTRON |
-SEQUENCE "sequence"
-EXON "exon"
-INTRON "intron"
-CODING "coding_exon" (GFF version == 1)
-CODING "CDS" (GFF version == 2)
-HOMOL "similarity"
-FEATURE "feature" (GFF version == 1)
-FEATURE "misc_feature" (GFF version == 2)
-ATG "atg"
-SPLICE3 "splice3"
-SPLICE5 "splice5"
-ASSEMBLY_TAG strnew (seg->data.s, handle)
-ALLELE "deletion"
-ALLELE "variation"
-ALLELE "insertion_site" (GFF version == 1)
-ALLELE "insertion" (GFF version == 2)
-EMBL_FEATURE name(seg->key)
-CLONE_END name(seg->data.k)
-
-
-and for sourceName:
- fMapSegTypeName[type] which could be any of:
- "MASTER", "ASSEMBLY_TAG",
-
- "SEQUENCE", "SEQUENCE_UP",
- "CDS", "CDS_UP",
- "INTRON", "INTRON_UP",
- "EXON", "EXON_UP",
- "EMBL_FEATURE", "EMBL_FEATURE_UP",
- "FEATURE", "FEATURE_UP",
- "ATG", "ATG_UP",
- "SPLICE3", "SPLICE3_UP",
- "SPLICE5", "SPLICE5_UP",
- "CODING", "CODING_UP",
- "TRANSCRIPT", "TRANSCRIPT_UP",
- "SPLICED_cDNA", "SPLICED_cDNA_UP",
- "VIRTUAL_SUB_SEQUENCE_TAG", "VIRTUAL_SUB_SEQUENCE_TAG_UP",
- "VIRTUAL_MULTIPLET_TAG", "VIRTUAL_MULTIPLET_TAG_UP",
- "VIRTUAL_ALIGNED_TAG", "VIRTUAL_ALIGNED_TAG_UP",
- "VIRTUAL_PREVIOUS_CONTIG_TAG", "VIRTUAL_PREVIOUS_CONTIG_TAG_UP",
- "HOMOL", "HOMOL_UP",
- "PRIMER", "PRIMER_UP",
- "OLIGO", "OLIGO_UP",
- "OLIGO_PAIR", "OLIGO_PAIR_UP",
- "TRANS_SEQ", "TRANS_SEQ_UP",
- "ALLELE", "ALLELE_UP",
- "VISIBLE",
- "DNA_SEQ", "PEP_SEQ", "ORF",
- "VIRTUAL_PARENT_SEQUENCE_TAG",
- "VIRTUAL_CONTIG_TAG",
- "CLONE_END"
-ASSEMBLY_TAG "assembly_tag"
-ALLELE "variation" (GFF version == 1)
- "unknown"
- str2tag("GFF_source"), _Text, &sourceName) ;
-
-actually sourceName seems to get set to stuff like: embl_eg
-
-i.e. its from the database and looks like the "method" name ??
-
-Yes, this seems to be it, we should work off the method stuff.
-
-Basically the source stuff is the method and the feature is the basic feature type.
-
-
-
-
-<H2>Using the interface</H2>
-
-<P>A normal scenario for accessing sequence data would be:
-
-<pre><code>{
- FexDB db = NULL ;
- FexSeq seq_context = NULL ;
- unsigned char *dna = NULL ;
- Array feat_set = NULL ;
- Array all_features = NULL ;
-
- db = fexOpenDatabase("some_location", "edgrif", "my_passwd") ;
-
- seq_context = fexSequence(db, "some_sequence", 1, 0) ;
-
- dna = fexDNA(seq_context) ;
-
- feat_set = fexQuerySeqFeatSets(seq_context) ;
-
- /* If the features bit is non-NULL, then just get those features. */
- all_features = fexGetFeatures(seq_context, NULL) ;
-
- fexReleaseContext(seq_context) ;
-}</code>
-</pre>
-
-
-
-
-<H2>In more detail</H2>
-
-<P>I am currently thinking that we can do things in two steps:
-
-<ol>
- <li>construct the sequence which would be essentially sMapCreate()
- <li>construct the fex stuff which would be essentially fexConvert() using sMapMap()
-</ol>
-
-<P>One questions is: can we tell which features are in the section of sequence
-ahead of time, I'm not sure we can. Ah, perhaps we can using the sMapKeys()
-and the idea of having a special tag to indicate which method an object
-references.
-
-
-
-<H2>Drawing Features</H2>
-
-<P>Each type of feature gets drawn with a particular style, the precise details
-of each style are decided from the following sources:
-
-<pre> defaults in the code for each FeatureType
- V
- defaults from the database for each FeatureType
- V
- defaults from the database for a FeatureSet
- V
- actual values for an individual Feature
-</pre>
-
-
-<HR>
-<H3 ALIGN="CENTER">FEX 0.1</H3>
-
-
-<HR>
-<ADDRESS><A href="mailto:edgrif@sanger.ac.uk">Ed Griffiths <edgrif@sanger.ac.uk></A></ADDRESS>
-<!-- hhmts start -->
-Last modified: Mon Jan 21 18:20:22 GMT 2002
-<!-- hhmts end -->
-
-</BLOCKQUOTE>
-</BODY>
-</HTML>
--
GitLab