[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] gzz/doc/pegboard 1001/PEG_1001.html 1002/PEG_10...
|
From: |
Benja Fallenstein |
|
Subject: |
[Gzz-commits] gzz/doc/pegboard 1001/PEG_1001.html 1002/PEG_10... |
|
Date: |
Tue, 27 Aug 2002 02:07:47 -0400 |
CVSROOT: /cvsroot/gzz
Module name: gzz
Changes by: Benja Fallenstein <address@hidden> 02/08/27 02:07:47
Modified files:
doc/pegboard/1001: PEG_1001.html
doc/pegboard/1002: PEG_1002.html
doc/pegboard/1003: PEG_1003.html
Log message:
Comment
CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1001/PEG_1001.html.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1002/PEG_1002.html.diff?tr1=1.1&tr2=1.2&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1003/PEG_1003.html.diff?tr1=1.2&tr2=1.3&r1=text&r2=text
Patches:
Index: gzz/doc/pegboard/1001/PEG_1001.html
diff -c gzz/doc/pegboard/1001/PEG_1001.html:1.2
gzz/doc/pegboard/1001/PEG_1001.html:1.3
*** gzz/doc/pegboard/1001/PEG_1001.html:1.2 Mon Aug 26 04:08:55 2002
--- gzz/doc/pegboard/1001/PEG_1001.html Tue Aug 27 02:07:46 2002
***************
*** 2,31 ****
<html>
<head>
<title>PEG 1001</title>
!
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
</head>
<body>
!
<h1>PEG 1001: Generic indexing API</h1>
<br>
!
! <p>Replace SearchableText with a more general indexing API where the user
! can specify how to match strings. This change would also make the
<tt>core</tt>
uml diagram accurate: no classes in the package <tt>gzz</tt> would exist that
aren't documented there. The proposed changes include<br>
</p>
!
<ul>
! <li>Split StringSearcher into an Index and Indexer API, one for reading,
the other for writing.</li>
<li>Create classes to represent different index types</li>
! <li>Create a central class <tt>SpaceIndexManager</tt> which can create
an index of the given type for a given space.</li>
<li>Create new package <tt>gzz.index</tt> to hold indexing-related
classes</li>
!
</ul>
The classes in the core APIs (the ones visible to the frontend) would then
be<br>
<ul>
--- 2,40 ----
<html>
<head>
<title>PEG 1001</title>
!
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
</head>
<body>
!
<h1>PEG 1001: Generic indexing API</h1>
+ <p><i>
+ Author: Tuomas Lukka
+ </i></p>
<br>
!
! <p>Replace SearchableText with a more general indexing API where the user
! can specify how to match strings. This change would also make the
<tt>core</tt>
uml diagram accurate: no classes in the package <tt>gzz</tt> would exist that
aren't documented there. The proposed changes include<br>
</p>
!
<ul>
! <li>Split StringSearcher into an Index and Indexer API, one for reading,
the other for writing.</li>
<li>Create classes to represent different index types</li>
! <li>Create a central class <tt>SpaceIndexManager</tt> which can create
an index of the given type for a given space.</li>
<li>Create new package <tt>gzz.index</tt> to hold indexing-related
classes</li>
!
</ul>
+
+ <p>
+ <small>(Benja:) That sounds like premature abstraction to me: I wouldn't know
how to
+ implement this. But if you do, fine.</small>
+ </p>
+
The classes in the core APIs (the ones visible to the frontend) would then
be<br>
<ul>
***************
*** 36,51 ****
</li>
</ul>
Issues<br>
!
<ul>
! <li>How to specify search types? Ignore-case, regex, match only at
beginning,
! match only whole words etc.</li>
<li>How to make index management as general as possible? Or should we
! keep to cell content indexing for now?</li>
! <li>Can we implement Xanalogical text search at the same time, with the
same APIs?<br>
</li>
!
</ul>
<br>
<br>
--- 45,73 ----
</li>
</ul>
Issues<br>
!
<ul>
! <li>How to specify search types? Ignore-case, regex, match only at
beginning,
! match only whole words etc. <br>
! <small>(Benja:) Through the index instance, IMHO, i.e. you create
different index
! instances for the different policies. Or maybe your searcher/indexer
! separation could come in here: you could have different searcher
! policies using the same data store built by a single indexer,
potentially.
! </small>
! </li>
<li>How to make index management as general as possible? Or should we
! keep to cell content indexing for now?<br>
! <small>(Benja:) By using <tt>Object</tt>s as the keys, not <tt>Cell</tt>s,
! and by not making the <tt>String*</tt> classes dependent on
! the zzstructure APIs. I don't think that the spaces should index
! things other than cell content through this interface, though.
! </small>
! </li>
! <li>Can we implement Xanalogical text search at the same time, with the
same APIs?<br>
+ <small>(Benja:) I don't think so.</small>
</li>
!
</ul>
<br>
<br>
Index: gzz/doc/pegboard/1002/PEG_1002.html
diff -c gzz/doc/pegboard/1002/PEG_1002.html:1.1
gzz/doc/pegboard/1002/PEG_1002.html:1.2
*** gzz/doc/pegboard/1002/PEG_1002.html:1.1 Sun Aug 25 04:15:07 2002
--- gzz/doc/pegboard/1002/PEG_1002.html Tue Aug 27 02:07:46 2002
***************
*** 7,12 ****
--- 7,15 ----
</head>
<body>
<h1>PEG 1002: Some deprecations in <tt>gzz</tt></h1>
+ <p><i>
+ Author: Tuomas Lukka
+ </i></p>
<br>
<p>Some crud is still left from the basalt/ era. I'm including here only
the points I'm reasonably certain we can be unanimous about, leaving out
***************
*** 23,33 ****
<tt>setSpan()</tt> and <tt>getSpan()</tt></li>
<li>Remove the specification "This field <i>may</i> be null
in some special cases; see SpacepartCell.", simply saying that it mustn't
! be null</li>
<li>Disable using Cell objects as dimensions; this encourages writing
! inefficient code</li>
<li>Move zzclone() implementations into Space's responsibility; especially
! zzclone(Cell inSlice) is too complicated.</li>
<li>Add <tt>getSpace()</tt> to be consistent with <tt>Dim</tt><br>
</li>
</ul>
--- 26,48 ----
<tt>setSpan()</tt> and <tt>getSpan()</tt></li>
<li>Remove the specification "This field <i>may</i> be null
in some special cases; see SpacepartCell.", simply saying that it mustn't
! be null<br>
! <small>(Benja:) !?! What is the point of making <tt>Cell</tt> subclassable
! if you cannot make ids lazy? For example, we will want this with
! cells in slices, IMO.
! </small>
! </li>
<li>Disable using Cell objects as dimensions; this encourages writing
! inefficient code<br>
! <small>(Benja:) OTOH, <em>most</em> code won't need to be that efficient.
! Only view code is that time-critical, but not e.g. bindings.
! </small>
! </li>
<li>Move zzclone() implementations into Space's responsibility; especially
! zzclone(Cell inSlice) is too complicated.<br>
! <small>(Benja:) Yes, that would be good.
! </small>
! </li>
<li>Add <tt>getSpace()</tt> to be consistent with <tt>Dim</tt><br>
</li>
</ul>
Index: gzz/doc/pegboard/1003/PEG_1003.html
diff -c gzz/doc/pegboard/1003/PEG_1003.html:1.2
gzz/doc/pegboard/1003/PEG_1003.html:1.3
*** gzz/doc/pegboard/1003/PEG_1003.html:1.2 Tue Aug 27 00:32:18 2002
--- gzz/doc/pegboard/1003/PEG_1003.html Tue Aug 27 02:07:46 2002
***************
*** 2,42 ****
<html>
<head>
<title>PEG 1003</title>
!
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
</head>
<body>
!
<h1>PEG 1003: Fix hierarchical <tt>VobScene</tt>s</h1>
!
<p>Hierarchical <tt>VobScene</tt>s need some fixing.<br>
</p>
!
<p>Open issues:<br>
</p>
!
<ul>
! <li>Is the integer identifier of the coordinate system into which to place
a new coordinate system appropriate?</li>
! <li>Should plain coordinate systems be usable as those ints?</li>
!
<ul>
! <li>What are the semantics there? Current, just translate, is not good.
However, using the vob-internal CS is not really nice either, as Vob CSs
usually
! are in pixels, and this would be in 10s or 100s of pixels per unit.</li>
!
</ul>
! <li>The most general use case is the PP-like viewport. How is that
implemented?
! You need</li>
!
<ul>
<li>clipping</li>
! <li>separate coordinate system for the motion of the clipping rectangle
and the contents</li>
!
</ul>
!
</ul>
Possible solutions:<br>
<ul>
--- 2,58 ----
<html>
<head>
<title>PEG 1003</title>
!
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
</head>
<body>
!
<h1>PEG 1003: Fix hierarchical <tt>VobScene</tt>s</h1>
! <p><i>
! Author: Tuomas Lukka
! </i></p>
!
<p>Hierarchical <tt>VobScene</tt>s need some fixing.<br>
</p>
!
<p>Open issues:<br>
</p>
!
<ul>
! <li>Is the integer identifier of the coordinate system into which to place
a new coordinate system appropriate?</li>
! <li>Should plain coordinate systems be usable as those ints?<br>
! <small>(Benja:) "Plain coordinate systems"?</small>
! </li>
!
<ul>
! <li>What are the semantics there? Current, just translate, is not good.
However, using the vob-internal CS is not really nice either, as Vob CSs
usually
! are in pixels, and this would be in 10s or 100s of pixels per unit.<br>
! (Benja:) I think use the parent cs to translate and optionally give a
scale
! when creating the sub-cs, and use the parent for clipping. I think this
! serves well in the usual case.
! </li>
!
</ul>
! <li>The most general use case is the PP-like viewport. How is that
implemented?
! You need
!
<ul>
<li>clipping</li>
! <li>separate coordinate system for the motion of the clipping rectangle
and the contents</li>
!
</ul>
!
! <p>(Benja:) I thought rotation/scaling? The above is extremely easy to do by
! putting two cs into each other, the parent being used for clipping,
! and the child being used for the contents.
! </p>
!
! </li>
!
</ul>
Possible solutions:<br>
<ul>
***************
*** 44,49 ****
--- 60,87 ----
system defines a clip rectangle. How about specifying the coordinate system
to clip to when creating a (any) coordinate system, as well as the coordinate
system into whose coordinates the given coordinate system should go.<br>
+ <small>(Benja:) This doesn't serve well in the usual viewport case, where
+ you have:
+ <ul>
+ <li>A thing you want to view (e.g. a PP paper, the contents
+ of a cell)</li>
+ <li>A place inside that thing where your focus is (you want to
+ view the stuff around the focus)</li>
+ <li>An area on the screen where you want to show the viewport
+ (so that the focus is shown in the middle of the viewport,
+ and as much of the viewed thing is shown around the focus
+ as fits in the viewport).
+ </ul>
+ Calculating the position of the viewed thing relative to the viewport
+ is easier than calculating the absolute position of the viewed thing
+ on the screen: to calculate the position relative to the viewport,
+ you don't need to know the viewport's position, just the focus;
+ to calculate the absolute position on the screen, you need both,
+ essentally translating the focus coordinates by the viewport's.
+ <br><br>
+ Therefore, I think that there is no need to special-case this in
+ the API, as it's easier to do with two nested cs.
+ </small>
</li>
</ul>
<br>
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gzz-commits] gzz/doc/pegboard 1001/PEG_1001.html 1002/PEG_10...,
Benja Fallenstein <=