graphics-intensive social web

1.16: addx/architecture/graphic intensive social web:
. one way to make remote games is like mvc:
the objects are very compactly encoded at main;
there are no graphics transmitted;
instead,
the matrix describes typical shapes and positions
then updates are sent as difference matrices
which are added to the local absolute matrices,
then the local graphics engine fleshes out these codes,
first into user's preferred forms and themes,
eg, the 3-d polygon compositions,
then ray tracing from these
into the screen graphics .
. it still requires a fast large local machine,
but the networking is not the bottleneck .

concurrent search and replace

1.16: adde/search and replace:
. a concurrent search and replace (s&r)
takes a tab-tab-enter list of targets and replacements,
this way user doesn't have to worry about
ordering multiple s&r's in the case where
one replacement might contain the target of another
ie, you want only original content to be replaced,
not anything put there by the
current list of replacements .
. this can also apply session-wide:
the s&r dialog would show all your previous s&r's
and show what's been morph'd during this session .
. there's 3 classes of text to apply changes to:
{ original, s&r-morph'd, new text }.

. what if a list of searches is given
and one target is a substring of the other?
warn user you'll be doing search of largest first,
[don't warn about this again] is default true ...

1.26: eg, if I can have the s&r set:
phil -> philosophy
philip -> philosopher;
and then what it should do is check for both targets
and case:
# no match? move on;
# only one match? apply map;
# both match? apply superstring's map .

first-class gui

1.10: adde/first-class dialogs:
. in addition to being able to see the
entirety of any path of a wizard
without having to fill it out,
you can treat dialogs like files,
and do a [save as] on partially filled dialogs,
then when given a dialog,
you can use [open file] to complete the dialog .

1.17: adde/gui/what's going on?!:
. what seems to be a copy ctrl-c of the firefox address bar,
is not taking the first time,
go back and switch windows, and ctrl-c again and it works?
it needs a confirmation that this happened
like a tiny brief popup of the time .

1.20: adde/gui/receptivity:
. ubuntu.gnome.firefox surprises me with
the way it shows the cursor:
. if you lower the cursor into the firefox address box,
the entire cursor can be in the box (including the tip)
and it still doesn't turn into
the I-bar that indicates insertion;
I am intuitively used to putting the cursor near the bar,
and without noticing it turn into the I-bar
expecting the mouse-down to put me into
editing the address bar .
. ubuntu.gnome is too finicky !
it should work like this:
if you do a mouse-down in a place that doesn't respond,
it should be finding the closest thing you likely meant;
if there is more than one thing nearby,
it should use a list of nearby things,
or a magnified window of the graphics
showing where usable things are
vs where your cursor is .

1.31: adde/pervasive shortcuts:
. all the radio buttons and checkboxes
should be large eno to contain keys
to tell you how to mark them by keyboard .

byte-sized pointers

1.18: adda/dstr/byte-sized pointers:
. keep pointers small by seeing large lists
as subtrees;
one of the node types of a tree is
"(this subtree root declares a new subheap:
it includes access to a 256-size array of tree node).
. how does that scale? it does because
root of huge subtree had its own subheap
where all terminal nodes were tagged as
(this is a sys'ptr [32bit c pointer]
-- not a pair of byte-sized tree ptrs [byte'ptr])
[1.31:
. as the tree progresses downward with fanout,
it eventually consumes 256 nodes;
any tree-building further down
must be done from a new-subheap node`type
(ie, a node whose purpose is to declare that
the following subtree is based in a new subheap).
. lets say that a tree uses
2 subheaps worth of nodes;
then if the tree is balanced,
it can be built with only 2 new-subheap nodes
by putting the left and right subtrees
each in their own subheap;
if the tree is not balanced,
then space efficiency requires that subheaps be shareable,
so that many smaller subtrees can be
impl'd on the same subheap .
. to make best use of space,
the use of new-subheap node`types
must be minimized because they are overhead .]

. when having a ptr to subtree,
it needs a record:
sys`ptr to the subheap,
byte'ptr to where in the subheap subtree is rooted .

. when building trees from text, [1.31:
or when trees can be modified? ..]
then we need speed more than mem'
whereas figuring out how to pack for byte-ptr's
would be very time-consuming;
so, then these sort of trees should be word-sized .
. both sizes are distinguished from sys'pointers
with the term "(local ptr):
whereas a system pointer is logically a machine address
(practically an index into a process module),
a local ptr is always an index into the current subheap .
1.31:
. our tree node has less than 16 variants,
so the tag can fit in 4bits (a half-byte, nibble,
-- addressing a byte to extract the {hi,lo} 4bits );
the node's data will be sizes larger than a nibble,
and the tag should be at the beginning
to tell us what the rest of the node looks like;
so, in order to accommodate mem'allignment requirements,
without wasteful padding after the tag,
the subheap will have 2 forks
so that tags and data can each be
in their own arrays .

. a subheap supporting byte-ptr's
can hold only 256 nodes,
in turn needing a 128-byte chunk for the 256 * 4bit tags .
. these nodes are word sized:
#branch: (tag, left.byte-ptr, right.byte-ptr);
#leaf: (tag, symbol.word-ptr).

. subheaps are composed of chunks;
so, if a subheap is not enirely used,
it's not entirely alloc'd either .
. both byte-ptr and word-ptr subheaps
can use the same size chunks, 128 bytes,
to match the minimum chunk needed for tags .
. therefore 256*2byte data nodes = 128*2*2 = 4 chunks .
. if less than half of nodes are used,
then it can save on 2 chunks of 128 bytes .

. finally, a byte-ptr subheap needs to be
an array of 5 sys'pointers for access to the
1 tag chunk + 4 data chunks,
plus
whatever else is needed for variant tagging,
or part of an efficiency hack .

. if a large structure has a known minimum at init' time,
then it can be given a superchunk,
which is some arbitrary multiple of contiguous chunks .