openware supporting graphics editing

21.7.16: web.adde/graphics/openware supporting graphics editing:

. see what other open source graphics editors are doing 

from these lists:

https://en.wikipedia.org/wiki/Comparison_of_raster_graphics_editors

https://en.wikipedia.org/wiki/Comparison_of_3D_computer_graphics_software

https://en.wikipedia.org/wiki/Comparison_of_vector_graphics_editors

https://en.wikipedia.org/wiki/Comparison_of_3D_computer_graphics_software

(eg, are there free algorithms for simulating

watercolor and oil paints?)

user-defined painting tools

 21.7.16: adde/graphics/user-defined painting tools:

. all the painting tools in the graphics editor

come with high-level instructions (adda code)

that users can copy and modify 

for coding their own tools.

. your brush can have a parameters page of your own design 

not just the usual tool width, flow density, etc.

. each tool is launching a subprogram

that can have any number of novel parameters.

graphics editor ideas inspired by painting apps

adde/graphics 2020.12.20 .. 12.31

skipping versioning for small edits

4.26: adde/versioning/skipping versioning for small edits:
. while inputting a string,
when the normal rules of versioning are in play,
stopping to do a correction should
cause the string input to be terminated,
then the new command is a string replace .

. one way around that is [word modify mode]
that can suspend the versioning system
until you are finished editing a particular word;
and, it reduces the damage of the modification
to just a particular word,
so that the versioning system is less needed . 5.13:
. it doesn't consider the word saved by versioning
until you are actually getting into the next word .

converting messy data formats

adde/universal conversion via screen scraping
adde/convert clonespy links
adde/browser/filename cleaner

user interface ideas

1.19: adde/gui/window resize needs a quick mode
adde/gui/backed by vcs (version control system)
23: adde/gui/message window/priority treed

avoiding the dangling pointer

1.16: adde/fs/bookmarks/avoiding the dangling pointer:
. mac spends a megabyte per bookmark,
but it can't find the moved file
even when it's inside the same volume as the link ?
. all it needs is a checksum of the file,
and then if it's not at the path indicated,
it reports that this could take a while,
unless you know where it is;
and, it offers to cancel this backgrounded search job .
. it looks for a file of the same name,
then checks it has the same checksum .
. here's how to find the file in the case where
it was edited and no longer has the same checksum:
a bookmark can include a list of keywords,
and like google we can produce a list of files
that gives a decending-order best fit
of all files that contain more of those keywords .
. a more thorough way is more expensive,
and requires all file moves happen via the file mgt
who then has to provide a system for
knowing when a file has been linked in the past,
and has subsequently been both moved and edited .
todo:
. I think that design has been discussed earlier;
need to merge that with this idea .

API-GUI equivalence

8.7: adda/api-gui equivalence:
intro:
. every aspect of a subprogram's gui
should be mapping to some feature of
the subprogram's interface (API);
so how is the API specifying
an array of menus with submenus?
sometimes there is menu-izing naturally formed by
an app inheriting from a service type,
like the file menu is,
for apps that use the file system .
. a datatype's operations are going under the Edit.menu;
because, that's the general term for the current datatype .
. a View.menu would belong to the human's agent
that was providing various ways to
format the display of data; [11.11:
but, a subprogram's API might have multiple views too .]

adde influenced by Bret Victor, Chris Granger

9.8: 9.23: adde/adde influenced by
Bret Victor and Chris Granger:

. Granger's write-up of Light Table
-- and the Victor video that inspired it --
have me wanting something new for adde:

. as it runs your code,
it opens all the files being called by main,
and also opens a simulation of the code
( some of that idea is already embodied
in the adda feature where all types
have an associated graphical image,
and you just have to start debug mode
in order to see the image of
every variable in main .
)
. once you get some working code,
it is constantly rerunning your test case
with every change to your code .
. so we get not only continuous testing,
but also continuous simulation of the testing;
and, of course,the simulation and the code are linked;
so, selecting one selects the other .

"(In light mode, Light Table lets you
see called functions not just by
highlighting their calls in your code,
but also by showing you their code to the side.
We shouldn't have to constantly
navigate back and forth to see this .
)
. this works for small files,
but for much larger ones
I would like a combination of this and
Apple's idea of being able to
open and close a file simply by
toggling the space bar .
. in my combination,
the main is opened on the left;
then for each file used by main,
it opens that file only partially,
just to show a thumbnail view of say 5 lines
to show the function's header info:
the signature and the summary string .
. when you click on the thumbnail, it opens fully,
when you arrow down, that full view is
filled with the next thumbnail's file .

. the programmability of this is important:
the layout editor should have a language for
describing not only how windows are arranged,
but also how they are behaving .
. the first time I had that idea
was wondering how to tell the editor
that we need 3 windows to be columns,
such that text being added
flows first into the first column,
with overflow going to next column, etc .
. we might have other behaviors,
so, how do we let the user design that,
and create a command for it ?

. in a composite doc' we have the choice of
whether regions overlap or not .
. when I open a thumbnail,
it covers other thumbnails,
but it doesn't cover other subwindows
like that of the simulation or the main text .

. an alternative behavior for a subwindow
is that instead of an open file
being allowed to overlap the thumbnails,
it pushes them aside,
and the region becomes scrollable,
so that I can see a stream of open files
mixed in with a stream of thumbnails .

. there are subwindows with dedicated purposes:
the project's folder system, the simulation,
the main, and the subprograms main calls .
. there are a lot of subprogram subwindows
so we can toggle them as all thumbnails,
all open, or opening only the
currently running subprogram .
. if your center of attention is not main
but something main called,
then you want main's region thumbnailed,
just like a stack of activation records:
closing your currently active file
means seeing the stack of thumbnails
that it jumped out from .

Granger's Code with a little illumination:

"( Here I find a bug where I wasn't passing x correctly.
I type (greetings ["chris"]) and immediately see
all the values filled in
not just for the current function
but all the functions that it uses as well. )

--. this is the same idea I just mentioned,
that of showing the activation stack:
we're showing not just the code,
but wherever there was a
variable name in the code,
now there is a named box with a value in it
-- and of course,
every var in the code is instantiated
so there are values at
every mention of that variable .
. variables should be
toggle-able between the image and code:
an array may represent a picture,
or a list of (rgb) color vectors .

. another dimension of toggling
is the outliner feature:
all code and values are {collapsible, expandable}
and you can do this symbolically too:
there are not only commands like close all,
but such things as:
open only what names match (this pattern) .

. watching the Granger video again,
I see he does automatic filing of functions:
you can start off in one editor window,
and then when we start code for a new function,
it buds into a new editor window too;
and -- my idea here --
when you have nested functions
then you should have nested editor windows,
and of course,
they can be resized with scrolling bars,
or made so control-arrows and page{up,down}
can do the scrolling .
. the outliner menu includes
several massive window controls;
eg, we can say:
recently used windows are 25 lines high,
or say:
all windows are 10 lines long until I
focus on it for a full view .
calltree:
. a primary feature seen from the vid,
is that when the side region is showing the
files that are called by the main region,
they become part of the debugger show:
ie, when you start launching main's test program,
the files to the side turn into instantiations of
the function`bodies that main enters;
so, -- my question here --
what should it do if you have recursions,
and multiple instances of a subprogram?
the 2 obviously possible behaviors are:
# show all instantiations;
# show the current instantiations .
. in the [show current] alternative,
as the new instance is created,
you see the new instance
overwriting the previous instance .
. after the instance is done,
it is re-overwritten by the prior instance .
. in the [show all] alternative,
we need to show a call tree
perhaps expressed as dots for each node,
and then you use [birds eye view]:
drawing a box around the part you want
or using the pinch gesture
on the part of the call tree
that you want to see thumbnails of
(thumbnails are opened in the usual way).
. from the call tree's [nodes as points] view
you can also use arrow keys to
turn nodes into files or thumbnails,
one node at a time:
up= parent node, down= 1st child node;
{right,left}= nearby sibling nodes .
. we can use the finder with opener, eg:
open all the instances of subprogram x .

CP4E hero Bret Victor

9.8: news.adde/light table and bret victor:

. Bret Victor's video has a cp4e mission
and shows off the new tools he's built
that help us develope our creative ideas .

. amazing what he's done;
he has an IDE where you can click on any var,
and it turns into the widget needed to adjust it;
but then it's also
re-running your code after every change;
so, if your program generates a picture,
his scripts are custom GUI's for
painting particular classes of pictures
where you paint by both coding
and by adjusting code parameters
-- all by GUI! (as you do edits,
the page is sprouting widgets to help you).
. when you slide a for-loop var,
the program is re-running for every
value in the for-loop's change range
which is causing an animation effect
-- a new way to experiment with video .

. even more amazing,
this IDE creates a complete mapping
between the subpicture being drawn
and the line of code that drew it;
so clicking in the picture
causes the editor to highlight a line of code,
and conversely, selecting a line of code
highlights the subpictures it drew .

. now, speaking of animation,
the next thing needed for visualization
is to create trails for specific subpictures,
so that as you modify a parameter,
it immediately shows how that is affecting
the path of the trail .
. first he's pausing at the
end of the interesting time interval,
then he's using rewind to get to the
beginning of his time interval of interest;
and finally when he's adjusting parameters now,
for each new parameter change,
it's drawing a new trail specific to the
time interval of interest .

. why are there symbols in a schematic?
because it's the easiest way to pen them,
Victor notices ( and there's the icon effect
-- creating instant recall of the concept );
but now that schematics are in computers,
we should be using their dynamic expression:
so, in an electronics diagram,
we could replace the symbols with
little videos of the analog signals
that are generated at that symbol's node .

. likewise, computers can make coding so easy
that any one can do it;
indeed, it seems that the best coders
are just those who are best at
imagining a computer's working internals,
but we have the computer to do this for us,
so why don't we?!
. for example he shows another IDE,
this one being tuned for coding instead of drawing
in which the editor has 2 areas:
on one side is the code,
and on the other is a simulation of the code;
ie, the simulation has a list of all the locals
that are so far declared in your function,
-- and it does this in real time:
eg, as you write the function's header,
the simulation shows the parameters as undefined;
then you can modify the simulation
by instantiating any undefined variables
(so the assignment happens only in the simulation,
not your code), and then as you have code
assigning a complex expression to a var,
the simulation tries to eval that assignment;
and, this way you are testing as you code
-- every time you hit enter,
it's relaunching the build&run
for per-line-of-code testing (quick!).
. if you add a loop to your code,
then all the var's being affected by the loop
are placed in a matrix
with vars in the columns,
and iterations per row (or vice versa).

. he then gives us a history of people who
had a passion for using computers to
help people with making full use of their brains;
pointing out that this work is important because
people need these dynamic tools
to unleash their full human potential .
. he was especially impressed at
those who made computers child's play;
and reminded the audience's budding techies
that we can choose as our identity
to have a social conscience,
and not just a technical expertise .

pioneers of cp4e:
(computer programming 4 everybody)

# Larry "nomodes.com" Tesler:
. not just the developer of copy&paste
but the one realizing we could do better than
obstructive modal versions of copy&paste:
he recognized a wrong
that was unrecognized by the culture .

# Doug Engelbart -- enabling mankind:
. propent of realtime human-computer interaction
not just the inventor of the mouse:
he wanted to solve mankind's urgent problems with
computer-assisted knowledge workers .

# Alan Kay -- enabling children:
. everything he did for windows, menus, and oop,
was to enable children to be computer literate
to make them more enlightened adults!
. he studied those who studied how children think,
in order to help them use computers .
[. in 2006, Kay's Viewpoints Research Institute
was funded by USA's NSF for the proposal:
Steps Toward the Reinvention of Programming:
A compact and Practical Model of
Personal Computing as a Self-exploratorium [pdf]
(see comments of it:
. they critiqued him for bucking the trend of
taking advantage of cheaper hardware
by filling it with more features and bling;
but ironically, that attitude
still hadn't been able to provide all children
with a computer that would help them learn
-- children's computers need to be
as cheap as calculators;
but instead we insist on continuing to
code above the child's price point .]

# Richard Stallman -- freedomware:
. the king of fighting to change culture
for the good of mankind .

9.8: web: i-programmer.info`
Alex Armstrong 10 March 2012`
A Better Way To Program

This video will change the way
you think about programming.
The argument is clear and impressive
- it suggest that we really are building programs with
one hand tied behind our backs.
After you have watched the video
you will want the tools [that he has] demonstrated.

We often focus on programming languages
and think that we need a
better language to program better.
Bret Victor gave a talk that demonstrated
that this is probably only a
tiny part of the problem.
The key is probably interactivity.
Don't wait for a compile to complete
to see what effect your code has on things
- if you can see it in real time
then programming becomes much easier.
Currently we are programming with
one arm tied behind our backs
because the tools that we use
separate us from what we write and what happens.
Interactivity makes code understandable.
Moving on, the next idea is that
instead of reading code and understanding it,
seeing what the code does is understanding it.
Programmers can only understand their code by
pretending to be computers and running it in their heads.
As this video shows, this is incredibly inefficient
and, as we generally have a computer in front of us,
why not use it to help us understand the code?
...
if you watch just one video this year
make it this one.
Update:
See Light Table - a Realization of a New Way to Code

[ an implementation of Victor's idea .]
[ it was funded by a kickstarter page .]
You can now try Light Table
via the Light Table Playground!

9.8: web: Bret Victor
. Bret Victor's inspiring resume
and his many cool writings .
. Bret Victor`Inventing on Principle [vid]
from CUSEC 2012 (Canadian University
Software Engineering Conference)

-- a three-day event that brings together
undergraduate and post-graduate students
for learning, networking,
and sharing their passion for software.

9.8: web: chris-granger.com`
Light Table --a new IDE concept

Despite the dramatic shift toward
simplification in software interfaces,
the world of development tools
continues to shrink our workspace
with feature after feature
in every release.
Even with all of these things at our disposal,
we're stuck in a world of files
and forced organization
- why are we still looking all over the place
for the things we need when we're coding?
Why is everything just static text?

Bret Victor hinted at the idea that
we can do much better than we are now
- we can provide instant feedback,
we can show you how your changes affect a system.
And I discovered he was right.
...
 all of this culminates in the ability to see
 how values flow through our entire codebase.
 Here I find a bug where I wasn't passing x correctly.
 I type (greetings ["chris"])
 and immediately see all the values filled in
 not just for the current function
 but all the functions that it uses as well.

Light Table is based on a very simple idea:
we need a real work surface to code on,
not just an editor and a project explorer.
We need to be able to
move things around, keep clutter down,
and bring information to the foreground
in the places we need it most.

Light table is based on
a few guiding principles:
You should never have to look for documentation
Files are not the best representation of code,
just a convenient serialization.
Editors can be anywhere
and show you anything - not just text.
Trying is encouraged
- changes produce instantaneous results
We can shine some light on related bits of code

Docs everywhere
When you're looking at new code
it's extremely valuable to be able to
quickly see documentation left behind by the author.
Normally to do so you'd have to
navigate to the definition of the function,
but lightable ghosts this information in to the side.
Want to know what partial does?
Just put your cursor on top of it.
This makes sure you never have to worry about
forgetting things like argument order ever again.

. we should be able to search all our documentation
in place to quickly see what it is.
Don't remember what was in the noir.core namespace?
It's one ctrl-f away.

This is especially handy for finding
functions you may not even know exist
and seeing their docs right there.
No need to look at some other generated documentation.

Instant feedback
.  to try things out, we can do better
than lispers' REPL - we can do it
in place and instantaneously.
For example we can type in (3 + 4)
and immediately we are shown the result
- no ctrl-enter or anything else.

Light Table takes this idea as far as it can
and doesn't just show you variables to the side,
but actually shows you how the code is filled in.
This lets you see how values flow through
arbitrarily complex groups of functions.

This level of real-time evaluation and visualization
basically creates a real-time debugger,
allowing you to quickly try various inputs
and watch it flow through your code.
There's no faster way to catch bugs
than to watch your program work.

We built drafting tables for a reason
. desktop windows aren't a good abstraction
for what we do as software engineers .
Other engineers have large tables
where they can scatter around
drawings, tools, and other information .
A drafting table is a better abstraction:
We shouldn't need to limit ourselves
to a world where the smallest moveable unit
is a file - our code has much more
complex interactions that we can better see
when we can organize things conceptually.
. We saw an example of this with Code Bubbles,
but why can't we embed a running game ?
Then we can interrogate it,
and have our environment answer them for us.

[9.8:
. an image in the article at this point
shows a desktop where a folder full of files
is represented by a box
whose title is named after the folder
with file names inside the box .
. the right side has boxes of code;
so, for each function you inspect,
it also shows you called function`bodies .)
--
. this reminds of composite editing,
where the editor holds the entire desktop;
so, it serves as desktop layouts that can be
suspended and resumed as if a vmware .
. desktops and their windows
can be edited the same as
when an editor embeds images in text .
. the first compound docs I saw
were ms`office embedded objects:
you could mix & match Word's text columns,
Excel's spreadsheet windows, and various images .
. browsers have this feature (the embed tag);
but browsers are short on editing abilities,
and editors need to be integrated with the OS;
such that I can open a file,
and it unleashes a desktop of windows
all arranged in the way they were before .
. also, the layout editor needs to
control the border style of its windows;
eg, embedded graphics in text
should often have no border at all .
. a 1st class composite document
has everything we like about vmware,
but instead of windowing OS's
our compositing app is windowing apps .]

Code with a little illumination
There's no reason our tools can't
help us understand how things are organized .
In light mode, Light Table lets you
see what functions are called by
the one you're currently working on,
not just by highlighting ones in your code,
but by also showing you their code to the side.
We shouldn't have to constantly
navigate back and forth to see this .

Finally, all of this culminates
in the ability to see not just how
things I type into a scratch editor evaluate,
but how values flow through our entire codebase.
Here I find a bug where I wasn't passing x correctly.
I type (greetings ["chris"]) and immediately see
all the values filled in
not just for the current function
but all the functions that it uses as well.

What languages will it support?
. The first two are Javascript and Clojure,
.... we hit $300k! Python will be the
third language supported out of the gate.
. additionally,
new languages can happen through plugins.

Will it be open source?
. a firm believer in open source software
and open source technologies.
we can guarantee you that Light Table will be
built on top of the technologies that are
freely available to us today.
As such, we believe it only fair that
the core of Light Table
be open sourced once it is launched.
At some level, this is an experiment in
how open source and business can mix
- it will be educational for us all.

What's a license then?
. In order to download packaged distributions,
you'll need a license. Preliminarily,
we're thinking, for individuals,
licenses will be based on a model of:
"pay as much as you can of
what you believe it is worth".
. This gives everyone access to the tools
to help shape our future,
but also helps us stick around to
continue making the platform awesome.
We think what we build will be worth at least $50,
and so that's what we've used for our rewards.

Is it a standalone app?
. there's an instance of webkit as the UI layer
-- completely an implementation detail.
It will run locally on virtually any platform
and out of the gate will support
the big three (linux/mac/windows).

Can I script/extend it?
. It will be scriptable in Javascript
(and many other languages can be
translated into Javascript).
Ultimately the goal of the platform
is to be a highly extensible work surface
- even the initial core languages
will be written as plugins.
This allows us to build development interfaces
we haven't even imagined yet.

What about key bindings?
. by using the awesome CodeMirror editor,
this is something that is easily adapted.
If you're looking for a way to contribute,
help improve CodeMirror
and its emacs/vim plugins!
--[
CodeMirror is a JavaScript component
that provides a code editor in the browser.
When a mode is available for your language
[c, python, go, js, ...]
it will color your code,
and optionally help with indentation.
. rich programming API and a CSS theming
for customizing CodeMirror
and extending it with new functionality.
. it's used by Mergely which is a
powerful online diff and merge editor
(Browser-based differencing tool)
that highlights changes in text.
It can be embedded within your own Web application
to compare files, text, C, C++, Java,
HTML, XML, CSS, and javascript.]

How can I help in the meantime?
. The better CodeMirror is,
the better all internet editors can be!
Past that, help us spread the word.
The more money we get
the more people I can involve in the project,
the more languages we can support,
and the more powerful the entire platform.
There's tremendous potential
-- we haven't even scratched the surface yet!

About the Developer:
. helped design the future of Visual Studio,
and released numerous open source
libraries and frameworks.
. for Microsoft was the Program Manager for
the C# and VB IDE
-- countless hours behind a one way mirror
learning how people develop things.
Since then steeped in the world of
startups and OSS.
. worked with the guys at ReadyForZero
to build readyforzero.com,
created the Noir web framework,
built the SQL abstraction layer Korma,
and released a host of ClojureScript libraries
to make client side development a breeze
- many of which are now featured in
the canonical books for Clojure.
Even more recently,
built Bret Victor's live game editor
after watching his inspiring
"Inventing on Principle" presentation .

Light Table at news.ycombinator.com:

briantrice

One thing Light Table could pick up / learn
is the ability to scale as function set grows,
to gain a kind of fractal navigability.

--[. I think he's refering to the call tree idea
aside from the view's detail modes
(nodes-view vs thumbnails vs fullview)]
stcredzero/"I told you so!"

Smalltalkers have been doing [LightTable]
--[the right thing]-- since the 80's
(If only we could have communicated
about this as well as Mr. Granger).
The first and the last points [under Also:]
were satisfied by lightning-fast searches of
"senders" and "implementers" .
1980's smalltalk:
- Smallest unit of code is the function.
- Able to get instant feedback on code changes.
- Multiple editors with just one function in it.
Show code in an "area of concern" not just in a file.
- The coding environment can show also
results, app windows, graphics, other tools.
- Can save the configuration of the above.
Also:
- You should never have to look for documentation
- Files are not the best representation of code,
 just a convenient serialization.
- Editors can be anywhere
and show you anything - not just text.
- changes produce instaneous results
- We can shine some light on related bits of code .

shykes:

. Dan Ingalls, the father of Smalltalk,
has picked up the baton again,
this time using Javascript.
Check out the MIT-licensed Lively Kernel
-- a new approach to Web programming
. the live demo at JSConf was jaw-dropping;
completely in line with the Smalltalk legacy .
It provides a complete platform for Web applications,
including dynamic graphics, network access,
and development tools.

Field (programming environment)
. embraces most (if not all)
of Light Table's principles.
--
As always, the multi-media programming environments
are miles ahead and nobody knows about them.
Field[by The OpenEnded Group] is amazing.
{Max/MSP, Pd, ...} are a different paradigm altogether,
but have had live editing, documentation a click away, etc
and have been in heavy use for 20+ years.

list of multi-media programming environments?
. the big names are Max/MSP, Pure Data,
vvvv, QuartzComposer, SuperCollider,
ChucK, Processing, openFrameworks,
Cinder, and Field[The OpenEnded Group].
But there are many more smaller projects
such as Lubyk, Overtone, LuaAV,
Faust, Plask, Impromptu and Fluxus.
I also want to plug NoFlo, which is a
'flow-based programming' library for node.js,
which integrates with a visual editor.


gfodor, vdm, nickik:
recommend some reading materials?
Victor's writings
The Design of Design (see part 4)
simplicity’s virtues over easiness’
Alan Kay`Programming and Scaling [vid]
Viewpoints Research Institute
Mindstorms: Children, Computers, And Powerful Ideas
PLATO Learning System [vid]
udacity -- cheap edu
coursera -- cheap edu
khanacadamy -- free videos

editing trees

7.22: adde/gui/editing trees:
. how do we sync a tree with the editor's
textual representation of the tree?
as lines are added to the text,
the line numbers change
but the tree nodes never change
without needing to rebuild the text too.
. there are 3 objects at work here:
the tree, the array of strings,
and an intermediate that's like wordcode,
in that it's a string of ptrs to tree nodes
that are in turn printable as words or symbols .
. at each line we have a ptr to the tree
but a line serves several nodes .
9.5:
. the ptr heading each line of text
is pointing to the root of the subtree
that is on that line .
. if we change that line or insert lines below it,
those changes are happening to that subtree
indicated by the root node;
therefore, to reflect any changes to the text,
we need reparse only that subtree ... ?!
actually,
there are 2 cases of tree:
# prefix:
. in the presentation of a folder system,
all the child nodes are below the parent's .
. that is a very simple and easy case,
as was expected above .
# infix:
. in the presentation of math formulae,
and programming code, such as adda,
we have expressions like (a+b),
where if all these expression tree nodes
are on separate lines,
then you see the root in the middle of the page,
not at the top . a further complication is that
the same text line can be representing
2 different subtrees: eg,
line#1: a*
line#2: b + c*d;
. in that example, line#1 and #2
share pieces of subtree#(a*b),
and line#2 represents parts of 2 subtrees,
so if line#2 is edited,
then there are possibly 2 subtrees to reparse .

9.5: the real-time complication:
. the text editing has to be very responsive;
therefore, we can't map each word
to a subwindow corresponding to a subtree;
instead, we have to let the user edit plain text,
and then have some way of mapping
text changes back to tree changes .
. to minimize reparsing,
we have to map character positions to tree nodes,
and then track how character modifications
have effected our text-to-tree map .

9.5: typical conditions simplifying:
. one simplifier provided by typical conditions
is tree size limits:
the expression trees that are complicated,
are usually only a few lines long;
they are separated by sequence operators,
or list delimiters .
. in the case of programming,
the effect of one tree change
can effect the parsing of another;
because, a symbol's meaning can change
either by deleting or creating a declaration
which will have a scope beyond the current tree
extending throughout the enclosing declare block .
. if there's a decl'deletion,
then we have to notice what type was being declared;
because, sometimes the type is determining
how we parsed the expression trees
that were surrounding that symbol;
eg, a declaration tells us whether or not
a symbol can be used as an infix operator,
or whether it was an atom or a function .
. much of syntax is only allowed for
certain types of symbols and not for others;
so, can we find a symbol of the same name
in an enclosing scope, and of the same type,
or a type change that won't matter ?
we may have to reparse the entire enclosing scope .
. if there's a decl'creation,
we must ensure that this scope
doesn't already declare this symbol .
. if there's a decl'modification,
we must ensure that type change doesn't matter,
else we have to reparse the entire enclosing scope .

dialog fields that auto-copy pastebuffer

7.20: adde/gui/dialog fields that auto-copy pastebuffer:
. when a menu needs additional information,
it launches a dialog .
. often we get the needed info by cut&paste;
so, one shortcut for filling a dialog
is having it listen for the next
cut or copy {ctrl-c, ctrl-x}
then automatically copy the pastebuffer
into the current field,
and finally, transfer dialog focus
to the field where the paste just happened .
. when it does this automation
it also switches itself to the forefront
(but not on top of all other windows;
instead it's alongside the current window
resizing it if needed)
so you'll be reminded in case you forgot
that you were in the middle of a dialog .
document access during a dialog:
. the dialog was launched from a home document;
and we may need access to the home document
because that may be where we can
copy what needs to go into the dialog .
. but if the home document is modified,
that could change the dialog's selection;
and then the dialog is no longer valid,
because it was for a menu item
that may no longer apply to
what's left of the original selection .
. the user should still be able to modify
other parts of the home document
(parts not selected during the dialog).
so, adde must be able to detect
whether just the selection has changed;
eg, put a tag in the doc,
showing where the selection starts,
and the tag includes the size of selection,
along with the hash value .
(if the selection has been changed,
then the selection tag will be gone,
or the hash will be different).

7.20: adde/gui/dual help-run menu items:
. the [?]-icon beside each menu item
is there to show the doc's for an item
rather than launch the item .

building menus per selection's type

7.20: adde/gui/building menus per selection's type:

. when any content is selected,
the menu should reflect appropriate commands;
and, that will typically be depending on
the selection's datatype,
but there can be several:
. all code can be seen as a character string,
then there are generic types
and finally there could be specific types;
eg, select a list, and maybe there's some
type that is based on a list (its literals use
a constrained version of list syntax).
9.5: eg,
when you've imported type spreadsheet,
and have selected a list of lists,
then one of the available menu options
is a list of spreadsheet commands
that treat lists of lists
as if they were spreadsheet tables .

automated menuization:
[9.5: intro:
. menuization means the process of
converting a module's interface
into a human-usable menu that is
just as powerful as the module's API
(application programmer's interface).
]
. any module menuization can be automated
from reading a module's code,
so how to know when a module is a typedef,
and the definition includes value literals
that match words in the current selection?
any subtle cases? .
...
. one thing that helps adde identify types:
it tries to parse as much into adda as possible;
so if that parsing found any type info,
the code will already be tagged with type info,
and all operations related to that type
would be presented in the current menu .
9.5:
. one thing adde can do when the selection contains
english words that match imported type literals
is tag those words as being of that type
rather than english type (being of english type
means the exact meaning of the word
can be found in an english dictionary).
. given a selection, the menu can help you find
the meanings of each word,
according to every imported dictionary
including the value literals of typedefs .
. eg, if you selected green after importing trafficlight,
then one definition of that would be
trafficlight`image#3 .

7.22: automated menuization/handling non-terminals:
. part of auto-menu-ization needs to deal with
the params of control types:
eg, when the menu provides an if-then stmt,
it inserts a string with params like this:
if<truth> then <subprogram>;
then if you select <truth>
the menu needs to show all this:
[current truth vars...], [make new truth var];
[functions that output truth...];
[operations that inout truth ...], etc .
. say you replace <truth> with
<truth> = <truth>
then you repeat the process .
. it should use a context menu tip too:
the moment you select a <truth> text
the right menu is open,
and your mouse focus is in it .
-- that would be like writing only better .
9.5:
. while there are <VAR> texts in place,
the editor is in a different mode:
where the tab and other navigation keys
are hopping between <VAR>s,
and the enter.key is opening the menu .
. when the menu is closed,
then the focus is on the
newest left-most <VAR> .
. the up-arrow.key goes up the expression tree;
down goes to the left-most child node;
right-arrow.key, and tab.key move linearly right,
left-arrow.key moves linearly left to next <VAR> .
. the esc.key toggles between {text, <VAR>} modes .

7.23: automated menuization/handling non-terminals:
. we could do the same thing for
teaching natural language to foreigners,
helping them build expressions in a 2nd lang .

interactive adda sessions

7.19: adde/interactive adda sessions:
. rather than the usual terminal interaction,
there are 3 boxes (input, output, and hist)
. hist (short for history) is a text list of
what went into the input box recently .
. it's both a sequence of text lines,
so, you can edit it;
and it's also a sequence of statements,
so you can set your cursor on any statement
and do a {ctrl-r, menu/run}
to have the selected statement copied to input
where it then gets run .
[7.19: 9.5:
. the interaction file can be decomposed by
saving the current interaction sequence
as a subprogram named x:
it then saves it in a file named x`body,
like any other subrogram definition;
and, back at the hist file,
the sequence that had just been saved
is turned into a subprogram definition .]

. the hist window is also an outline editor,
so, for each subprogram definition,
the body of the subprogram can be collapsed
into the name of the subprogram .
. you can either see things as a tree,
or see just one node of the tree .

. each interactive symbol definition
is stored as a file in a folder named
interactive.adda; and when you're done,
you can save the session to folder x,
so then it copies interactive.adda to x.adda .
. if x already exists, you can either
merge hist with the selected
or have hist replace it .
9.5:
. merging is useful when your interactions are
developing pieces of a library;
replacements would useful for keeping track of
recent interactions,
eg, by naming sessions after days of the week,
you could always keep 7 days of session history .

vocabulary size conversion

7.11: adde/vocabulary size conversion:
. if you'd rather not learn a large collection of library calls
it should convert imported source code
by expanding each 5-dollar word
into a paragraph of 5-cent words .
. this could have the side-affect of running slower
because the 5-dollar words are
packing a lot of code into a c module .
. so it might be useful to implement it
only at the presentation layer;
ie, if you don't modify the expansion,
then it converts the expansion back to its 5-dollar word .
9.5:
. another way of putting that,
is that addx should be giving you a dual library
where everything is visible as adda code,
but it's mostly impl'd in c code,
unless you change the c's adda twin,
in which case it compiles that adda change into c,
and then, of course, into a binary .
. notice how Python does it differently:
it auto'compiles your scripting to Python bytecode;
but porting to C requires manual effort .
. the reason for this is that most Python code
makes extensive use of the Python virtual machine,
and there is efficient translation from Python to C;
rather, it takes human skill to sort out
where the hotspots are, and how to untangle them
for separation into a C file .
. adda, on the other hand,
encourages explicit typing;
and, if the user has done that,
then conversion to C should be easy and useful .
. adde should be tracking user's
adda file modifications,
and not bothering to C-translate it
until the user seems to be done tweaking it .

gui notification systems

5.18: adde/gui/notification systems:

. all processes can inter-communicate;
but, processes are also hierarchical,
eg, apps represent root processes,
while owning a set of subprocesses;
so, intercommunication happens only between
siblings and ancestors (parents, grandparents, etc).

. the gui display is seen by apps
as a list of pointers to obj's that draw images .
. making an obj gui-visible means
adding a link to this gui list .
. since most app windows are a
tree-like arrangement of objects,
the gui list items are usually trees (lists of lists).
. the first on this list corresponds to
the front-most window;
apps can change the order of this window list
unless barred by the user;
but, of course, the user controls
only the top level of this list,
since the trees underneath belong to
particular apps not the user .
. in either case, it is the owner who decides
who can see or modify their possessions .

. if x.app (an app named x)
gives embedding rights to y.app,
then x.app accepts offers to
list a given item in its own gui sublist;
this allows apps to work together on
generating parts for the same window .
. the default capability is to allow nothing
(no reading and no modification);
so, by default, when reading the gui list,
non-self sublists appear to have no parts,
just a link for contacting the owner .

. the system is following an mvc pattern;
so, when putting an obj in a gui sublist,
what is actually posted there
is an image (view of mvc)
of the obj (model of mvc);
ie, each datatype can draw an image;
and, each time a gui'd object is modified,
this must cause the object to emit a signal
that will result in the obj's gui image being updated .
. finally, a gui image update must
signal to the gui mgt
to recopy that image to the screen buffer
and recopy every overlapping image,
or somehow avoid overwriting overlapping images .
todo: need ideas from QT how to arrange it  .

juggling user expectations

6.18: adde/mail/bcc info during a forward:
. how to build a mail system that
impl's blind carbon copy with no leaks?
. say you have that bcc'd email sent
and then you start to forward your view of it;
it shows both who it was sent to
and who it was cc'd to, but not the bcc's?
. wouldn't we want to give you the option?
(ie, you'd have to edit bcc if abstain)
but what if the naive user is not expecting it
even while the power user is demanding it ?
. do you notify the user that bcc is apparent in forward ?
require dialog before creating the forwarding process ?

integrating terminal with gui

5.16: adde/gui/integrating terminal with gui:
. the terminal (aka, command line interface(cli))
can be integrated with the gui features
by printing a stream of windows instead of lines .
. the subwindows roll out of view like lines
but you can drag them out of the cli window
and then they stay pinned .
. these windows are titled command`output#nnn .

5.16: adde/gui/numeric presentations:
. the structures have a natural default
graphic representation,
but numbers have some options
if it doesn't show 3  significant digits,
then we move from decimal notation (n.nn)
to engineering version of scientific notation (n.n e n)
(with exponent a multiple of 3 and we show 6..7 digits )
0.00nnn -> n.nnn e -3
0.000nnnn -> 0.nnnn e -3
0.000,00n -> n.nnn e -6
. if users change the default,
we ask if it should be acct-wide,
it works like a calculator
with format options including
fixed, number of frac digits, sci, eng,
or mixed whole + fractions .

tooltips explaining disabled menu items

4.21: adde/tooltips/explaining disabled menu items:
. part of greying -out menu items should be to
have a menu item's tooltip explaining why it is not enabled,
common reasons include: doc is not modified, no selection,
and selection not of relevant type .

save without crash-corrupting log file

4.21: adde/journaling/save without crash-corrupting log file:
. when saving the user's commands log,
each save needs to re-open and re-close the file;
because, a crash when a file is open might corrupt it .
. this could be done using a pair of files;
or we could use the platform's way of writing to a file buffer;
and then atomically set the save-file's pointer to point at buffer;
or (copy saved; append the command; close the copy;
    rename copy as saved).