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
|
Pasta notes
===========
Layout of stacks and cheese in pan
----------------------------------
The "pan" holds a horizontal array of stacks; each stack may have one or more
noodles in it. In the spaces between or alongside noodle-stacks, the cheese
may be displayed.
Given all this, there are still some questions about when and where cheese
blocks are displayed:
- With only one stack, can any cheese be visible?
- Yes, if noodle self-reference is allowed
- Yes, if two noodles in a stack can reference each other
- With two stacks, how many cheese blocks should be visible?
- In the simplest case, only one, between the two stacks; this is
used for any references between the left and right stacks.
- Show another on the far left, for self-reference in the left stack?
- Show another on the far right, for self-reference in the right stack?
- With three or more stacks?
- The far left/right self-reference blocks could still be shown, but then
the middle stack(s) don't get an isolated self-reference block.
- What happens if the far left stack references the far right stack? The
middle stack(s) would be in the way. Same applies for any stack
referencing another more than 1 stack away.
- Will Pasta allow moving noodles from one stack to another? This seems like a
very useful feature, but could complicate the cheesing algorithm.
I think it's safe to say that noodle self-reference is a possibility (ex.,
calling a function that's defined in the same module), and reference between
two noodles in the same stack is a definite yes (especially for things like
search/replace); so it makes sense to show at least one cheese block at all
times. For consistency, self-references should always be on the same side of
the stack (probably the left, since that's where the line numbers are).
What if every stack automatically gets a cheese block to its left? This cheese
block would be used for all references within that stack, as well as any
references to any stack to the left of it. When a stack is destroyed, its
left-side cheese block goes with it.
In fact, it may make sense for the cheese block to be encapsulated in the
Stack instance itself (rather than managed separately by the app/pan). This
could also solve the problem of horizontal splitters between stacks--the
cheese block could maintain a fixed width alongside each stack, while the
splitter would effectively only change the width of the noodles in the stack.
What if Pasta enforced a rule such as:
If noodle A references noodle B, then A and B must be in neighboring
stacks, or must be in the same stack.
This implies that any noodle moved to another stack could potentially break
cheese connections with a formerly-adjoining stack. Also, self-references
within a stack may become neighbor-references, and vice-versa.
Which comes first?
------------------
If all relationships, open files, and arrangements were handled strictly in the
GUI, it becomes a hassle later to save them, then load them and rebuild them
all--there has to be some ad-hoc conversion from GUI to YAML and back.
If instead all GUI actions directly operated on a YAML-like (or similar) structure,
and the GUI was responsible mainly for rendering that YAML-like structure, then:
- It becomes easier to save and load projects
- The concern of building text relationships is separated from the concern of
drawing them
For example:
- New pan:
project += {'pan_1': []}
project += {'pan_2': []}
- New file in pan_1:
project['pan_1'] += 'untitled'
- Open foo.py in pan_1:
project['pan_1'] += 'foo.py'
- Cheese from foo.py:25 to bar.py:31
project += {'cheese': [('foo.py', 25), ('bar.py', 31)]}
What shall this shared, project-level data structure be called? 'Project' makes
the most sense. There's already a stub Project class left over from
experiments with save/load; it needs to be promoted to be available in a
'global' way, percolating through all levels of the GUI, since many GUI
operations will affect it or render themselves based on it.
Project should have an event handler registry, so whenever it changes, the
appropriate GUI widgets can be notified. It should probably have event handlers
of its own as well, so it can be notified of changes made in the GUI, i.e.
project.file_opened(pan, filename)
project.file_closed(pan, filename)
project.cheese_added(file_a, line_a, file_b, line_b)
project.line_added(filename, line_number)
|