updated with 07/02/04 meeting notes

doc/design_notes.shtml

@@ -55,7 +55,38 @@ out from other viewers in a good way.
 other such stuff, e.g. how about indicating start/end_not_found etc.
 
 
-<h3>Gnome Canvas</h3>I think this might belong in coding_notes.shtml, rather than here.
+
+
+<H2>Wish List</H2>
+
+<P>Record anything here that you would like to be considered but is non-essential.
+
+<ul>
+  <li>Allow user to interactively retitle a window, v. useful when there are lots
+      of fmap windows on a screen.
+  <li>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.
+</ul>
+
+
+
+
+<H1>Design</H1>
+
+
+<H2>Overview</H2>
+
+<P>
+
+<H2>Configuration Files</H2>
+
+<P>If looks like the libgnome gnome-config calls will do this for us, see:
+http://developer.gnome.org/doc/API/2.0/libgnome/libgnome-gnome-config.html
+
+
+
+
+<h3>Gnome Canvas</h3>
 <p>Be a good idea to get rid of the graph package altogether if we can. Gnome Canvas
 seems a good candidate to replace it, but we need to check a few things first:
 <ul>
@@ -87,31 +118,84 @@ seems a good candidate to replace it, but we need to check a few things first:
       not the data pointed to is freed as well as the array itself.
   <li>According to developer.gnome.org/doc/whitepapers/canvas/canvas.html you can choose
       either of two rendering back-ends, an extremely fast one based on Xlib and another
-      based on Libart.  PostScript is mentioned in the same breath as Libart, so I'm
-      investigating further.
+      based on Libart.  PostScript is mentioned in the same breath as Libart.  However,
+      the Libart (anti-aliased) one is quite a bit slower.
       <p>The Xlib model, used via GDK, runs well over networks. The Libart model provides
       a superset of the PostScript imaging model, allowing high-quality displays.
 </ul>
 
-
-<H2>Wish List</H2>
-
-<P>Record anything here that you would like to be considered but is non-essential.
-
-
-
-
-
-<H1>Design</H1>
-
-
-<H2>Overview</H2>
-
-<P>
-
-
-
-
+<H3>Memory usage</H3>
+
+<P>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.
+
+<P>You can see a plot of this data by running gnuplot and displaying the file
+gnome_canvas_mem_usage from this docs directory.
+
+<pre>&gt; gnuplot
+gnuplot&gt; plot "gnome_canvas_mem_usage"
+</pre>
+
+<h3>Meeting Notes - Friday, 7th Feb, 2004</h3>
+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.
+</p><p>
+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.
+</p<p>
+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.
+</><p>
+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.
+</p><p>
+Apparently this means our http can have &lt;stag&gt; content &lt;etag&gt; 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.
+</p>
+<h3>Decisions</h3>
+<ol>
+<li>
+    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.
+</li><li>
+    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.
+</li><li>
+    We will only allow one sequence per Zmap.  If they want another sequence, they'll have to run another Zmap.
+</li><li>
+    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.
+    <p>
+    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'.
+    <p>
+    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.
+    <p>
+    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.
+</li><li>
+    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.
+</li><li>
+    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.
+</li>