summaryrefslogtreecommitdiff
path: root/TODO
blob: 3612697522de32bf47d9d700b0d6d524970a21c2 (plain)
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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
Bugs
	- Infinite recursion - see fixme in "on_changed"

	- The whole "active slide" should be rethought. Probably we
	  need to deal with an activate *range* of slides, in floating
	  point.

	  Thumbnail scrolling should be done whenever the integer
	  rounding of that range changes.

	  The thing we should keep at a fixed position as much as possible
	  then is 

	       - top of first completely visible slide

	       - of if that's not possible, top of first slide with a
                 visible top

	       - which reduces to "top of first slide with visible
                 top"

          This location should survive all resizing. 

- Need to figure out how to deal with sizes. Clearly the desk should
  not know about viewports - it should just be passed a width when it
  needs it.

- Slides should probably not know anything except be passed an
  appropriately transformed cairo_t. However, when items are tiny
  enough, they shouldn't be painted; also staffage may not make sense
  if it would just be a complete clutter, or if there simply isn't
  room for it.


-=-=-


- Think of a better name than oppress 
  	- Populist
	- Demagogue
	- Agitate
	- Vapour
	- Pep Talk
	- Deque

- Features
	- Object Types
	  - Text
	  - Circles/ellipses
	  - Arrows/Lines	(or possibly distinct)
	  - Rectangles
	  - Polygons
	  - Curves
	  - Groups
	  - Images
	  - Helper lines
	  - Mirror (references another item and paints it), changes
	    to this item are reflected in the other.
	  - Post-it notes
	  - Trashcan

	- Objects draggable to screen

	- Objects should connect to each other, like in dia
	- "Mirror this object on all slides"
	- "Create animation from this object"
	  - This will make a 'copy' of the object in such a way
	    that when you change any properties of it, the new object
	    will be animated into place. You can move sub-objects around
	    for example, and an animation path will appear between
	    an original 'ghost' and the new position.
	  "Animate Onto Next Slide"?
	    - Creates the copy on the next slide
	    - If there is no next slide, then it creates one.
	  "Create Animation target"
	  "Duplicate slide with animations"

	- Templates
	  - Is this more than 'mirror on all slides'?

	- Load/Save

	- Display full-screen

	- Deck has an associated screen size (1024x768 say), or
	  it has a paper size.

	- Objects should be in a toolbar and be drag-and-droppable
	  onto the canvas.

	- When you drag and drop a helper line and it gets close to
	  the edges of a slide or to other helper lines, it should
	  display the distance in pixels - or maybe it should display
	  that all the time?

	- Lines and curves should auto-connect to circles and boxes,
	  at first only to the drag points, but later to all of the
	  stroke.

	- Curves should probably be automatically fitted to data points
	  rather than making the user edit bezier control points.

	  See 	  
	 
		An Algorithm for Automatically Fitting Digitized Curves 

	  from graphics gems. Google Scholar knows about a pdf, but the
	  site is down. The autogenerated HTML is difficult to read.

- UI
	- Objects can be selected by clicking on them. If more than one
	  selection mode is available, you can iterate through them by
	  clicking again. 
	    - Unfortunately, this probably won't work for text, where we
	      need more than one selection mode:
	      	   - select for resize (6 dots)
		   - select for rotate (6 arrows)	(Need this?)
		   - select for move (note: drag is
		     also selecting).
	    - Editing the text could be seen as editing one property
	      of the text, so double click to edit could be
	      interesting.

	- Otherwise, there is a 

	- toolbar should be on the left, and in maximized windows should
	  stick to the edge.

	- A drawback of all this drag and drop is that it makes it
	  more difficult to use on a laptops with a crappy pointing
	  device. 

	  And making the slides on a laptop in a hotel room the night
	  before is probably very common.

	- Image cropping.

           When an image is selected, a special selection mode
	   available by clicking again. allows you to drag a crop
	   rectangle around. A scissor is displayed next to it.

- Staffage
	- Things that will not be visible in the final show will be
	  shown in the same color, probably blue, maybe dashed. Post-it
	  notes will have a light blue, translucent background, with a
	  dark blue border. Or yellow, like tooltips?
	  (There might be a reasonable distinction between temporary
	   helper objects created by the app, and user created tings).

- Implementation
	- Objects must be able to
	  - Save themselves, plus generate an SFormat
	  - Draw themselves,
	    - in fullscreen mode
	    - in edition mode
	    - in thumbnail mode
	  - Be selected
	  - Edit themselves, probably
	  - List properties
	  - Draw themselves as a ghost
	  - Paint their dnd source
	    - When dnd begins, an object is created, and a grab
	      is taken, but slide input areas are still active.

	      	 slide_begin_drag (slide, new_object);

	      The slide activates the grab and stores the new object.

	    - on motion the object is invalidated, and has coordinates
	      updated. Maybe there is a simple "move" method.

	    - On release, the new object has "add to slide" called
	      on it, and the object adds itself.

	  - A Deck contains slides, which contain objects

	    A deck can display itself at various size. It can tell its
	    size given a width. It will call back when slides are
	    added or removed, or when things like the page size
	    changes.

	  - When drawing an object, clip to the slide it belongs to.
	    Staffage is not clipped

	  - Raise/Lower of objects should follow this algorithm (lowering)

	    	(a) find all objects that are intersecting the object
		    to be lowered
		(b) Of these, find the topmost one.
		(c) If one is found, lower the current item below it.

	  - When forming a group, the objects within it retain their
	    relative stacking order, but the new group item gets the
	    position of the topmost of the constituent items.

	  - Property box

	    - One box to list all properties of an object?

	      Impress has an impressive array of stuff:

	      - fill (linear/radial/solid) 
	      	- gradient editor (or can we put that in the canvas?)
	      - stroke
	      	- all the same possibly?
		- arrows for lines (but they don't need fill)
	      - Shadow
	      - Gradient editor
	      - Hatching
	      	- Only useful for presentations about x11perf

	      There is no way I'm adding all that.

	      - Can we drag and drop colors and bitmaps,
	        like in nautilus?

	      - Many of the properties can actually be done by 
	        adding a rectangle below it. With good snapping, this
		may be sufficient.

	      - Can we take a group of items and drag it to the
	        toolbar to make a template out of it?

		- An easter egg, but potentially very, very powerful.

		  - Could be added to the menu as well to make it easier
		    to find.

		  - The simple combination of boxes and text may be a
		    special case that interesting enough to be on by
		    default

		  - Or just adopt the ooffice convention of
		    adding/edit text by double clicking. 

	      - Maybe the edge of a rectangle could be edited by
                clicking on it? That would possibly cut down on the
		number of widgets in the property window.

        - Objects can be cutted/copied/pasted of course - the
	  serialization may simply be the sfile serialization (so sfile
	  must grow the ability to serialize/read from memory, which it
	  probably should have anyway).

	  This means the natural way to do the object creation is to
	  just have a prototype object that can be copied as
	  necessary. The properties of that object is then the
	  defaults.

	  (An interesting thing here is that such serializations could
	   be used desktop-wide if someone decides to actually write a
	   worthwhile desktop some day). Ie., cut and paste of complex
	   items, built from rectangles/circles/text etc.

- Undo?
	- Update files in-place?

	- Undo manager. Whenever something changes about an
	  item, an undo object is created and registered with
	  an undo manager. 
	  
	  An undo object contains a description, a callback and
	  sufficient information to undo the operation - including a
	  callback.

		undo_manager_add_undo (manager, 
				       const char *description,
				       callback, 
				       data)

          When the callback is called, it generates another undo object,
	  and adds it to the redo stack:

	       undo_manager_add_redo (manager, desc, callback, data);

	  The redo function will then add an undo object again.

	  When something is added to the undo stack, the redo stack
	  disappears. (Except if the redo function is adding the
	  undo).