3.19: addx/privacy rights/reporting errors:
. if an error should be reported to the coder
the report should be generated in such a way that
the user can see it contains no personal data;
or, it should say it does contain data
and ask if it is too sensitive .
Showing posts with label gui. Show all posts
Showing posts with label gui. Show all posts
2013-03-09
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
adde/gui/backed by vcs (version control system)
23: adde/gui/message window/priority treed
2012-11-16
model-view and composite tech
[thought I blogged this 9.2, but found as draft;
then found a note that the reason it was draft
was a concern that the body was still too buggy;
nevertheless, the first part is still interesting .]
7.17: web.adda/architecture/MVC vs MVVM:
8.31: summary:
. in trying to find an explanation of
the essential differences between
all the variants of the MVC architecture,
it was most helpful to see Alexy Shelest's
2009`MVC vs MVP and MVVM:
first he reminds us of MVC's original definition:
"( the “Gang of Four” book
doesn't refer to MVC as a design pattern
but as a “set of classes to build a user interface”
that uses design patterns such as
Observer, Strategy, and Composite.
It also uses Factory Method and Decorator,
but the main MVC relationship is defined by
the Observer and Strategy patterns. ).
[8.31:
. then, Shelest had an interesting summary of
the historical evolution of MV-architectures, eg:
then found a note that the reason it was draft
was a concern that the body was still too buggy;
nevertheless, the first part is still interesting .]
7.17: web.adda/architecture/MVC vs MVVM:
8.31: summary:
. in trying to find an explanation of
the essential differences between
all the variants of the MVC architecture,
it was most helpful to see Alexy Shelest's
2009`MVC vs MVP and MVVM:
first he reminds us of MVC's original definition:
"( the “Gang of Four” book
doesn't refer to MVC as a design pattern
but as a “set of classes to build a user interface”
that uses design patterns such as
Observer, Strategy, and Composite.
It also uses Factory Method and Decorator,
but the main MVC relationship is defined by
the Observer and Strategy patterns. ).
[8.31:
. then, Shelest had an interesting summary of
the historical evolution of MV-architectures, eg:
"( Potel questioned the need for the MVC's Controller;. after reading that, I wrote this:
He noticed that modern user interfaces
already provide most of the Controller functionality
within the View class,
and therefore the Controller seems a bit redundant.).
. I didn't get mvc either, and promptly redefined it:
subrograms should not be controlling a gui interface,
rather they should be designed primarily for
use by other subprograms,
just as unix tools are meant to be .
(well, unix takes a shortcuts by
making its tool language a character string
that could also be readable by humans
but that was a security blunder because of parsing errors
that confuse critical datatypes like
{filenames, command names}).
. so, anyway, back to how humans fit in:
in order for a human to interact with
a subprogram that speaks type-tagged binary,
the human needs an agent who will
convert this robot speak into a gui .
. this agent is the Controller of the Model subprogram,
and it creates a View the human can interact with .]
2012-11-11
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 .]
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 .]
2012-11-10
signaling in gui systems
8.12: adda/cstr/signals/signaling in gui systems:
how is the gui related to the signal?
. as a summary of 2012/07/gui-notification-systems
I was thinking gui's should be impl'd with
gui-optimized signals,
rather than the general signal system,
but then I wondered if that idea was
keeping mvc in mind,
so that generally all IPC (interprocess communications)
would be seeing the same windows that a
human can see with the help of a gui agent .
how is the gui related to the signal?
. as a summary of 2012/07/gui-notification-systems
I was thinking gui's should be impl'd with
gui-optimized signals,
rather than the general signal system,
but then I wondered if that idea was
keeping mvc in mind,
so that generally all IPC (interprocess communications)
would be seeing the same windows that a
human can see with the help of a gui agent .
2012-09-23
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 .
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 .
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.--. this is the same idea I just mentioned,
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. )
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
[ 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)
Light Table --a new IDE concept
. 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 .]
aside from the view's detail modes
(nodes-view vs thumbnails vs fullview)]
stcredzero/"I told you so!"
. 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
. 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[ an implementation of Victor's idea .]
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
[ 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 together9.8: web: chris-granger.com`
undergraduate and post-graduate students
for learning, networking,
and sharing their passion for software.
Light Table --a new IDE concept
Despite the dramatic shift toward[9.8:
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.
. 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 illuminationLight Table at news.ycombinator.com:
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 .
One thing Light Table could pick up / learn--[. I think he's refering to the call tree idea
is the ability to scale as function set grows,
to gain a kind of fractal navigability.
aside from the view's detail modes
(nodes-view vs thumbnails vs fullview)]
stcredzero/"I told you so!"
Smalltalkers have been doing [LightTable]shykes:
--[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 .
. Dan Ingalls, the father of Smalltalk,Field (programming environment)
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.
. 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 educoursera -- cheap edu
khanacadamy -- free videos
2012-09-21
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 .
. 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 .
. 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 .
2012-08-03
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 .
. 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 .
2012-07-05
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 ?
. 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 ?
2012-07-02
gui notification systems
6.4: adda/gui notification systems:
[. the original version of the gui pointer,
is a sort of additional type:
x.gui.t -- x is a gui pointer to type t .
. that way, you could pass x around,
and all type mgts then know
that in addition to performing the requested operation,
they should also be notifying the gui system
if the operation entailed a modification .
. the point is to be like QT's signaling system:
what is special about a gui'd obj
is that any modification triggers a signal to the
notification center,
which keeps a list of things to do in response .
. my revision of QT's idea was to
make gui notification a special case
so that instead of giving every object
the ability to emit notifications,
we are establishing a relationship directly with gui mgt
rather than going through a notification system .
. the gui type is an obj header that all type mgt's understand,
and it has any additional info that might be needed
in order to identify an object to the gui system .
. the type mgt needs to know
what operations can cause modifications
or it needs to compare before&after values
if any of it's outputable's are gui typed .
. not sure I was thinking of all that when I
designed the following ...]
. seems like the simplest gui system is to have
a gui ptr for each window you intend to export,
then the gui system knows to follow this pointer
and print whatever happens to be there .
. that way you don't have to decide at design time
what will be displayed .
[. to provide this feature of dynamism
combined with a gui system notfication service,
you simply mov from (x.gui.t) to (x.t; p.gui`= x)
and the system understands gui.types like p to be
dynamically type-tagged . ]
. if repointing the gui ptr dynamically,
and if we are translating adda to c,
then how is switching the gui ptr translated
into dynamically created gui views?
. our c datastructures must include type-tags;
if the type doesn't come with a type tag,
then the compiler has to do the boxing
(this is possible because
all symbols refering to untagged obj's
must be statically typed ).
. this complicates efficiency because
if the gui ptr can be dynamically changed,
then anything it might be repointed to
will have to be fully boxed (have type-tags included).
[. and obj's that are statically typed,
cannot be type-tagged;
so how are we getting notifications to happen?
. the compiler needs to know what will be gui'd;
if we want to do that dynamically,
then we'll need to compile dynamically
(eg, that means compiling to addm or python
instead of to a native lang like c or obj'c ).
. once the compiler knows what's getting gui'd,
then it knows when gui'd obj's are being assigned to
statically typed out.mode parameters
and it can notify gui mgt
after that parameter's procedure is done operating .]
6.30: needs a type-tag:
. gui-notify (is-mirrored) is like read-only subtype;
if modified {is-rom: raise error, is-mirrored: notify gui}
maybe there needs to be some additional implicit params
that provide bits for every subtype:
esp'ly is-rom, and is-mirrored?
. obj's don't need a read-only bit because
that is part of static typing,
but is-mirrored is a dynamic subtype
since we want the run-time to control what's mirrored and when;
thus any obj's that can be mirrored
will needs polymorph typetag indicating whether
gui needs to be notified when obj may have been modified .
6.30: keeping the mvc pattern in mind:
. the mvc pattern means that
programs don't use a gui directly,
they are designed to be used by other programs,
and if a human user needs access to a program
then we pair it with a gui-producing agent .
. keeping the mvc pattern in mind,
the parts we've referred to as being "(gui'd)
are generally known as the exported obj's
or the content of ipc* channels
*: (ipc: interprocess communications).
. just as human users have a window into an export,
other controllers have a buffer,
like what is offered by a file server
(rather than loading the whole file in memory,
it places the first unread chunk into a buffer)
what buffers have in common with user windows
is an indication of which segment is being buffered
(the starting offset, and the buffer size).
7.1: how is an obj's mirrors identified?:
. if we allow the mem system to be virtualized,
then when c provides the address of an obj,
we can no longer use that as an obj id,
because pages (and their obj's) are sharing physical addresses;
therefore, we need some way to identify obj's
in order for the notification system to work
(once some type mgt finds modifications require notification
the notification system needs to know
which obj in which channel needs to be updated;
so, it either has to map an obj id to these things,
or it needs to include with each mirrored obj
a notification id).
. if the notification bit were an entire word
then not only is this easy to read,
but also non-zero values can serve as notification id's .
. however, the whole point of it being a bit
is that this is something that has to happen to every obj type
(is this a mirrored subtype or not?)
so it should to be very space-efficient .
. if it's found to need notification,
then how is the system managing obj identity ?
is it the c-detectable address of the obj? .
[. the original version of the gui pointer,
is a sort of additional type:
x.gui.t -- x is a gui pointer to type t .
. that way, you could pass x around,
and all type mgts then know
that in addition to performing the requested operation,
they should also be notifying the gui system
if the operation entailed a modification .
. the point is to be like QT's signaling system:
what is special about a gui'd obj
is that any modification triggers a signal to the
notification center,
which keeps a list of things to do in response .
. my revision of QT's idea was to
make gui notification a special case
so that instead of giving every object
the ability to emit notifications,
we are establishing a relationship directly with gui mgt
rather than going through a notification system .
. the gui type is an obj header that all type mgt's understand,
and it has any additional info that might be needed
in order to identify an object to the gui system .
. the type mgt needs to know
what operations can cause modifications
or it needs to compare before&after values
if any of it's outputable's are gui typed .
. not sure I was thinking of all that when I
designed the following ...]
. seems like the simplest gui system is to have
a gui ptr for each window you intend to export,
then the gui system knows to follow this pointer
and print whatever happens to be there .
. that way you don't have to decide at design time
what will be displayed .
[. to provide this feature of dynamism
combined with a gui system notfication service,
you simply mov from (x.gui.t) to (x.t; p.gui`= x)
and the system understands gui.types like p to be
dynamically type-tagged . ]
. if repointing the gui ptr dynamically,
and if we are translating adda to c,
then how is switching the gui ptr translated
into dynamically created gui views?
. our c datastructures must include type-tags;
if the type doesn't come with a type tag,
then the compiler has to do the boxing
(this is possible because
all symbols refering to untagged obj's
must be statically typed ).
. this complicates efficiency because
if the gui ptr can be dynamically changed,
then anything it might be repointed to
will have to be fully boxed (have type-tags included).
[. and obj's that are statically typed,
cannot be type-tagged;
so how are we getting notifications to happen?
. the compiler needs to know what will be gui'd;
if we want to do that dynamically,
then we'll need to compile dynamically
(eg, that means compiling to addm or python
instead of to a native lang like c or obj'c ).
. once the compiler knows what's getting gui'd,
then it knows when gui'd obj's are being assigned to
statically typed out.mode parameters
and it can notify gui mgt
after that parameter's procedure is done operating .]
6.30: needs a type-tag:
. gui-notify (is-mirrored) is like read-only subtype;
if modified {is-rom: raise error, is-mirrored: notify gui}
maybe there needs to be some additional implicit params
that provide bits for every subtype:
esp'ly is-rom, and is-mirrored?
. obj's don't need a read-only bit because
that is part of static typing,
but is-mirrored is a dynamic subtype
since we want the run-time to control what's mirrored and when;
thus any obj's that can be mirrored
will needs polymorph typetag indicating whether
gui needs to be notified when obj may have been modified .
6.30: keeping the mvc pattern in mind:
. the mvc pattern means that
programs don't use a gui directly,
they are designed to be used by other programs,
and if a human user needs access to a program
then we pair it with a gui-producing agent .
. keeping the mvc pattern in mind,
the parts we've referred to as being "(gui'd)
are generally known as the exported obj's
or the content of ipc* channels
*: (ipc: interprocess communications).
. just as human users have a window into an export,
other controllers have a buffer,
like what is offered by a file server
(rather than loading the whole file in memory,
it places the first unread chunk into a buffer)
what buffers have in common with user windows
is an indication of which segment is being buffered
(the starting offset, and the buffer size).
7.1: how is an obj's mirrors identified?:
. if we allow the mem system to be virtualized,
then when c provides the address of an obj,
we can no longer use that as an obj id,
because pages (and their obj's) are sharing physical addresses;
therefore, we need some way to identify obj's
in order for the notification system to work
(once some type mgt finds modifications require notification
the notification system needs to know
which obj in which channel needs to be updated;
so, it either has to map an obj id to these things,
or it needs to include with each mirrored obj
a notification id).
. if the notification bit were an entire word
then not only is this easy to read,
but also non-zero values can serve as notification id's .
. however, the whole point of it being a bit
is that this is something that has to happen to every obj type
(is this a mirrored subtype or not?)
so it should to be very space-efficient .
. if it's found to need notification,
then how is the system managing obj identity ?
is it the c-detectable address of the obj? .
2012-05-31
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 .
. 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 .
2012-05-01
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 .
. 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 .
editor has modes of display like finder
4.18: adde/editor has modes of display like finder:
. the editor has modes of display like the mac finder does;
an editor's usual state is large icon mode,
where you choose how the text and image panes are
tiled together in a layout .
. the other views relevant to an editor are:
subtitles tree, listview of panes,
and any number of other customized layout views
for adjusting the #columns and paging length
to fit the various window dimensions
(1024x726, half, quarter, ipod-sized ).
5.1:
. the small icon mode makes it easier to do
layout changes from a bird's eye view,
seeing several pages at once .
. the editor has modes of display like the mac finder does;
an editor's usual state is large icon mode,
where you choose how the text and image panes are
tiled together in a layout .
. the other views relevant to an editor are:
subtitles tree, listview of panes,
and any number of other customized layout views
for adjusting the #columns and paging length
to fit the various window dimensions
(1024x726, half, quarter, ipod-sized ).
5.1:
. the small icon mode makes it easier to do
layout changes from a bird's eye view,
seeing several pages at once .
unicode inputting
4.17: adde/unicode inputting:
. the editor should make it easy to type unicode:
menu#0 brings up the submenus
which arrange the unicodes in pages .
. each menu shows the key matrix map:
ie, what a key on the keyboard is launching,
either another menu,
or a unicode character in this situation;
that is, after it brings up the main menu,
the next key takes you to another key map,
and eventually the submenus get to a leaf menu,
where the key matrix map shows which
unicode character is currently assigned to each key .
5.1:
. the unicode menu system should also include
a recent-keys menu and a favorites menu .
. the editor should make it easy to type unicode:
menu#0 brings up the submenus
which arrange the unicodes in pages .
. each menu shows the key matrix map:
ie, what a key on the keyboard is launching,
either another menu,
or a unicode character in this situation;
that is, after it brings up the main menu,
the next key takes you to another key map,
and eventually the submenus get to a leaf menu,
where the key matrix map shows which
unicode character is currently assigned to each key .
5.1:
. the unicode menu system should also include
a recent-keys menu and a favorites menu .
converting attribute-text to html
4.29: adde/gui/converting attribute-text to html:
. a pyqt text object uses a system of fragments to express
each change in the text's combinations of attributes in
(color, bold shade, underline, italics, superscript, subscript );
but when converting to html,
you want to combine contiguous modes;
eg, say you have 3 words, 1,2,3,
with u=underline, and b=bold;
so, when pyqt gives you:
1(u), 2(b,u), 3(u)
your html writer should be converting that to:
u(1, b(2), 3) .
. a pyqt text object uses a system of fragments to express
each change in the text's combinations of attributes in
(color, bold shade, underline, italics, superscript, subscript );
but when converting to html,
you want to combine contiguous modes;
eg, say you have 3 words, 1,2,3,
with u=underline, and b=bold;
so, when pyqt gives you:
1(u), 2(b,u), 3(u)
your html writer should be converting that to:
u(1, b(2), 3) .
2012-03-29
menu-driven coding
3.5: adde/menu-driven coding/current vars list:
. when an interactive coding session is adding vars,
the menu is updated to show what's currently defined
-- this is part of the menu-driven coding capability
for the memory impaired .
. when an interactive coding session is adding vars,
the menu is updated to show what's currently defined
-- this is part of the menu-driven coding capability
for the memory impaired .
2012-02-28
kindle++ (emulating a book)
2.23: adde/kindle++ (emulating a book):
. to be like a book
kindle needs a virtual sideview of the book
so you see an array of pages,
then you open book at a page .
. you can cursor down approximates page,
and then brushing sideways provides
fine adjustment of page selection .
. it can show recent and frequent pages as being wider,
and it can show page number and subtitles of current page
which would be even better than a book .
[2.28:
. you can have a toc not of the book's content
but of all your notes and starred pages .]
. to be like a book
kindle needs a virtual sideview of the book
so you see an array of pages,
then you open book at a page .
. you can cursor down approximates page,
and then brushing sideways provides
fine adjustment of page selection .
. it can show recent and frequent pages as being wider,
and it can show page number and subtitles of current page
which would be even better than a book .
[2.28:
. you can have a toc not of the book's content
but of all your notes and starred pages .]
2012-02-27
efficiently panning large documents
2011.9.15: adde/gui/efficiently panning large documents:
. when a window is much smaller than
the document of a network graph,
do you have to keep the whole bit-image in memory?
[9.18:
. the ideal is having a small engine that is
generating a small data set as-needed,
expanding from drawing instructions
into bit maps,
rather than sending expanded pages to off-ram storage;
then again,
speedy solid-state drives are getting common,
and energy is getting precious ... .]
. for saving energy,
a network graph is stored as an image;
for save space and hard drive accesses,
it would be a list of nodes with attributes:
(inout edges, global position, ...).
. a search function given window area
would return any nodes within that region .
. I had this mem-saving scheme for drawing it:
rather than allow panning,
move to birdseye view (zoom out some),
then set your zoom-in box to go there;
the window sized image is kept in memory,
but few or no closups are cached .
. this idea is not that important on a fast computer;
because, you can respond on the fly:
. whichever way the user is panning
find the sections about to be exposed,
and create the images just in time .
. for each section,
you need to know which nodes are in that section,
and then to draw the edges,
you need to know the nodes that connect to
your drawn nodes;
the edge path is a style of line
{linear, Bézier curve, ...}
between the global positions of 2 nodes
which is then mapped across any needed section
but drawn only on currently existing sections
(those expected to be viewed soon).
9.16: edges as objects:
. to help speed things up
by quickly finding per-section edge lists,
you could have an edges list too;
each edge would know:
# the locations of its end-point nodes;
# the points that define how it curves;
# a list of the sections
that the edge's line runs through .
9.16: space walking:
. if you have nodes and edges in 3-d,
then you may want to follow an edge
and see things nearby along the way;
this can be done with some of the previous ideas:
. a line function is a series of global position points,
and for each point you figure the 3-d region,
then you know the nearby regions,
and finally,
you can search the edges list for a region,
to get a list of every edge intersecting that region .
9.16: web.adde/gui/terminology:
. how is the graphics industry using "(sector)?
Portal rendering:
. when a window is much smaller than
the document of a network graph,
do you have to keep the whole bit-image in memory?
[9.18:
. the ideal is having a small engine that is
generating a small data set as-needed,
expanding from drawing instructions
into bit maps,
rather than sending expanded pages to off-ram storage;
then again,
speedy solid-state drives are getting common,
and energy is getting precious ... .]
. for saving energy,
a network graph is stored as an image;
for save space and hard drive accesses,
it would be a list of nodes with attributes:
(inout edges, global position, ...).
. a search function given window area
would return any nodes within that region .
. I had this mem-saving scheme for drawing it:
rather than allow panning,
move to birdseye view (zoom out some),
then set your zoom-in box to go there;
the window sized image is kept in memory,
but few or no closups are cached .
. this idea is not that important on a fast computer;
because, you can respond on the fly:
. whichever way the user is panning
find the sections about to be exposed,
and create the images just in time .
. for each section,
you need to know which nodes are in that section,
and then to draw the edges,
you need to know the nodes that connect to
your drawn nodes;
the edge path is a style of line
{linear, Bézier curve, ...}
between the global positions of 2 nodes
which is then mapped across any needed section
but drawn only on currently existing sections
(those expected to be viewed soon).
9.16: edges as objects:
. to help speed things up
by quickly finding per-section edge lists,
you could have an edges list too;
each edge would know:
# the locations of its end-point nodes;
# the points that define how it curves;
# a list of the sections
that the edge's line runs through .
9.16: space walking:
. if you have nodes and edges in 3-d,
then you may want to follow an edge
and see things nearby along the way;
this can be done with some of the previous ideas:
. a line function is a series of global position points,
and for each point you figure the 3-d region,
then you know the nearby regions,
and finally,
you can search the edges list for a region,
to get a list of every edge intersecting that region .
9.16: web.adde/gui/terminology:
. how is the graphics industry using "(sector)?
Portal rendering:
In computer-generated imagery
and real-time 3D computer graphics,
portal rendering is an algorithm
for visibility determination.
For example,
consider a 3D computer game environment,
which may contain many polygons,
only a few of which may be visible on screen
at a given time.
A portal system is based on using
the partitioning of space
to form generalizations about
the visibility of objects within those spaces.
Regions of map space are divided into
polygonal, generally convex, areas called sectors.
Adjacent sectors are linked to one another via
shared dividing polygons termed portals.
Approaches that pre-compute visibility for sectors
are referred to as PVS (potentially visible set) methods.
Subscribe to:
Posts (Atom)
