1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
# Copyright 2006-2007 Nanorex, Inc. See LICENSE file for details.
"""
scratch6.py
$Id$
"""
# [061025; exploring a graph-editing eg, gets into interesting comments about
# exprs for behaviors, actions, events, potential & actual, command offers,
# and pattern syntax and semantics.]
# you can DND a new edge from one node to another
# using the following behavior, which we might add to some editmodes and not others...
# let's see, what does it say:
# - appearance of the during-drag graphic:
# (a rubberband edge from an existing node to an object showing what would happen if you dropped at that point)
# - dragging thingy, which looks under it to see what it might drop on, looking for:
# - something that edges (of its kind) from nodes (of its kind) can be attached to
# - empty space into which new edges (of its kind) can be drawn (creating new nodes to attach to)
# specifically, in either case (existing or new droptarget), it somehow highlights & has translucent stuff to show what it'd do.
# we're likely to like to do that by:
# - creating a first class feature or object, which is what we'd make real if we dropped
# - but until we drop, "show it as a potential feature or object"
# - for which standard behavior can be used:
# - potential object is shown translucent
# - potential feature (attachment to target) is shown by highlighting target...
# but in reality, the highlighting of the target is more like a special case for DND.
# OTOH, when target is space, we highlight the drop point, not the target, based on what we'll do there.
# so it sounds like these potential actions (putting action and appearance when potential into one thing) do exist,
# but might be specialized for this DND-like use.
# That's ok, they're useful even if always custom --
# they can have statustext, help info, history info, name & accel key, cmdline equivalent, etc, too.
# They are pretty much like a command with some standard type & args (some args symbolic or from env).
# potential actions for use while DNDing an edge, relative to the edge itself:
AttachTo(target)
AttachToNew(space, position, what)
edge.AttachTo(target)
# action is about an edge, thus it's "edge.something"
# capital A is standard for command names, which are special case of type names (command == type of action)
# - the above is still something like a widget expr, since we can instantiate it as a way of actually doing the action!
# - but there is a related expr, maybe a param of that one(??) (or of an instance of it, even if it isn't done yet)
# which shows the potential of doing it, and has the mentioned metainfo about that.
# Q: do we instantiate the action as soon as it's a specific potential action, or only when we do it?
# A: when it's a specific potential action.
# Proof 1: if history mentions the potential action (eg it's shown like this at this time),
# and then we do it, and history mentions that, they need tying together;
# both being same instance (at different lifecycle stages) is the simplest way.
# Proof 2: if each action instance has a random color or whatever,
# we might want to show this in the appearance of the potential action.
# That means we instantiate all the potential actions we show (e.g. as menu items, or translucent alternatives for deposit).
# Note that if we do something, unrelated potential actions now have new starting conditions and might look different;
# sometimes they'd need to become new instances (if the process of making them used something that just changed).
# does that mean that edge.AttachTo(target) is already instantiated? Hmm... edge is, and target is... OTOH,
# I could imagine passing it into something which decides whether to instantiate it... so I guess it's not.
# e.g.
action1 = If(cond, edge.AttachTo(target1), edge.AttachTo(target2))
# note: the thing doing the action could be symbolic:
_thing.AttachTo(target)
# Q: is that the same as this??
AttachTo(target)
# I don't know. [Guess: yes, if we wanted it (or something like it) to be the same as this, when we designed AttachTo.] ####
# Related Q: do some exprheads autocurry, so that Sym(x1) is the same as Sym(x1, _somespecificsymbol), or perhaps more analogously,
# the same as lambda x: Sym(x1,x)?? ####
# (Digr: the latter need not be expanded on each use -- it can be expanded on a symbol, and the resulting expr lexreplaced on each use.
# And the arg/kw signature (len args, keys of kws) to use can be determined at runtime, the first time each signature is used.
# These ideas are mostly mentioned previously in recent notesfiles or papers.)
# Now how might we use some of these potential-action exprs?
# - instantiate some of them, bound to possible user actions (like drop under certain conds (eg on what, in where) with certain modkeys),
# these are still potential since the user actions (events) are possible rather than actual.
# - these have looks -- draw some of them, maybe all the ones in some set that we also "bind to reality", ie to a source of a real event.
# - the fact that they're bound to that event-source which has a present potential existence (the drag before the drop,
# or the menu before the menuitem selection) does two things at once, which we like to have tied together:
# - display the appearance of the potential action (which can now depend on which potential events it's tied to -- it's a bound action)
# - enable this action as the real one to happen, if that possible event happens.
# Note: binding the potential action to a possible event constitutes offering the action. This is visible, and it's a real offer.
# So "real offers should be visible" -- this is why those two things should be tied together.
# so we have: potential action, as expr or instance, bound to possible event (ortho to whether it's expr or instance afterwards, i think ###),
# which if bound to an instance of a possible event is offered to whatever might do that event.
# a possible event expr:
ControlDropOn(Node) # how do we say Node is the type of _target?? (do we??)
# a potential action expr:
AttachTo # edge. ? (target)?
# map from possible events to their actions
# (the word "potential" is often implicit; that's ok since it's really a matter of how the action relates to other things)
{ ControlDropOn(Node) : edge.AttachTo } # this assumes Node is the type of "the arg" and edge.AttachTo is a method to apply to "the arg"
edge.AttachTo # a reasonable "bound method"
ControlDropOn(Node) # a bit weird, since ControlDropOn(thing) (for thing perhaps being of type Node) might be an instance of this type,
# so it's as if we had a pattern language in which any term in an expr can be replaced by a type for that term...
# but this leaves a lot of things implicit unless types and ordinary terms are always distinguishable,
# which seems unlikely if types are firstclass.
# So don't we want to say
ControlDropOn(_:Node) # or the like?
# (digr: i bet that syntax could actually work, if we can use Slice as a pattern-forming operator.
# Whether it *should* work is another matter... no idea. ###)
# hmm -- we might rather say AnythingOfType(Node) rather than <thing that looks like a lexvar of a specific name, even _> of type Node.
# Then we can say that AnythingOfType is a special kind of pattern-forming exprhead, one of a few things treated specially in patterns.
# OTOH maybe ControlDropOn is able, when used as a pattern, to coerce its arg1 into a type?? Which Node already is...
# or even easier, detect that it's a type (of things you can drop on)? After all, a type is an individual, but it isn't
# an individual in the class "things you can drop on" which is what ControlDropOn(arg1) wants in arg1 to be an event.
# So maybe Exrphead(arg1, arg2) with full typedecls for the args has no problem detecting typelike args, re those types,
# and treating them as patterns? I guess there could be problems created by finding recursive types of themselves in lambda calc...
# surely we needn't worry about that in making a heuristic be ANAP? (As Nice As Possible) ####
# Conclusion: I think ControlDropOn(Node) can work if I want it to, when designing ControlDropOn.
|
