dialogging exceptions

7.28: adda/cstr/dialogging exceptions/
syntax and fleshing out semantics:
. in adda, dialogging exceptions are
the kind of exceptions which are not call-killing:
they simply give the caller a chance to
fix things in the event of a missing resource:
eg, if a service finds a parameter missing
such as when a file is found to be unreachable,
it will give the caller's file-missing handler
a chance to assign a new file url to an address .
[7.29:
. dialogging exceptions are basically like
implicit parameters that accept a procedure for
what to do in the case of an exceptional situation;
ie, in the usual exception,
the service is quitting and that kills
the whole block that called that service;
so control jumps to the block's exception handlers;
whereas, in the case of dialogging exceptions,
the service is not quitting;
it merely calls an exception handler .]

. for dialogging exceptions,
the handler is expected to return a resource;
so we need syntax for an exception's
returning a value;
it's like a signal but you need a
pointer or inout param because
it's not just reading but writing to the param .
. what if the handler can't help?
if the param is a pointer
it can return nil to indicate failure
indicating the handler is of no help,
so the service then knows to
clean up and throw a returning exception
or give some other indication of failure .
[8.8:
. it's just like a dialog is to the user;
and in that situation,
the user can either find the resourse
and ok the dialog, or cancel it .
. for our example, the service declares:
FileNotFound( f/.filename ).dialog;
-- notice the arg is a pointer type;
and then the handler responds like this:
# a return would be ( f/`= $the/find.txt; );
-- the "(/) is dereferencing the pointer;
and, the target is assigned a literal filename .
# a cancel would be ( f`= none )
-- the pointer itself is assigned no address .
ipc:
. how are we dealing with
pointers that are sent across processes
(ie, how is an arbitrary pointer being thread safe?);
well, in the case of exceptions there are no surprises;
because, it's by invitation only:
the exception raiser is providing an address
for the caller to put a patch into .

8.9: ok,cancel as dialog-local keywords:
. another idea is that the handler's parameter
needs to be an out-mode not a pointer;
and, to handle the dialog
it assigns to the parameter and calls ok;
if the handler has nothing to return,
then it calls cancel to
allow for the service to clean up,
and then it can either propagate an exception
or make a change in strategy,
and then exit from the enclosing block,
or enter some tagged block; eg,

( --. begin a block containing a dialog handler .
...
[service that needs a file](f)
-- call the service that may dialog later .
;
on FileNotFound( out f.filename ).dialog:
( f`= [find a new file];
[file was found] ? ok
else: ( cancel; raise MissingResource )
)-FileNotFound
) --end of block with a dialog handler .]

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? .

first-class gui

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

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

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

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