rbcurse-core 0.0.5 → 0.0.6
Sign up to get free protection for your applications and to get access to all the features.
- data/NOTES +2151 -0
- data/VERSION +1 -1
- data/lib/rbcurse/core/include/chunk.rb +13 -1
- data/lib/rbcurse/core/util/rdialogs.rb +14 -2
- data/rbcurse-core.gemspec +3 -2
- metadata +3 -2
data/NOTES
ADDED
@@ -0,0 +1,2151 @@
|
|
1
|
+
NOTES
|
2
|
+
=====
|
3
|
+
/// vim:ts=4:sw=4:tw=80:ai:formatoptions=tcqnl:
|
4
|
+
/// this was posted with appenddiary.sh
|
5
|
+
|
6
|
+
Subject: Update rubyforge
|
7
|
+
-------------------------
|
8
|
+
|
9
|
+
To update the file named index.html on rubyforge use this. password is in
|
10
|
+
rubyforge config file.
|
11
|
+
|
12
|
+
scp index.html rkumar@rubyforge.org:/var/www/gforge-projects/rbcurse
|
13
|
+
|
14
|
+
* * *
|
15
|
+
|
16
|
+
Subject: subwin benefit
|
17
|
+
-----------------------
|
18
|
+
Date: 2009-10-09 23:32
|
19
|
+
|
20
|
+
Just found out after playing with subwins that they don't let you write onto
|
21
|
+
the window below. Perfect for us for components that overwrite!! However, no
|
22
|
+
way to hide a subwin for later display
|
23
|
+
|
24
|
+
* * *
|
25
|
+
|
26
|
+
Subject: Upgrading widgets
|
27
|
+
--------------------------
|
28
|
+
Date: 2009-11-02 14:45
|
29
|
+
|
30
|
+
1. We need to use `create_buffer` either in constructor or repaint or whenever
|
31
|
+
you are likely to have a width and height. Recommended in beginning of
|
32
|
+
repaint().
|
33
|
+
Use `safe_create_buffer`
|
34
|
+
|
35
|
+
2. Use `@buffer_modified = true` in repaint
|
36
|
+
|
37
|
+
3. Ensure `print_border` and `printstring` are getting correct coordinates. Most
|
38
|
+
errors happen here.
|
39
|
+
|
40
|
+
4. Replace @form.window with @graphic
|
41
|
+
|
42
|
+
5. `set_form_col` needs to call `setrowcol` as in rtextarea.
|
43
|
+
Also, you need to add cols_panned and rows_panned so the widget knows
|
44
|
+
how much it as been panned, and keeps the cursor in correct place.
|
45
|
+
|
46
|
+
6. `set_form_row` needs to call setrowcol as in rtextarea. See above entry
|
47
|
+
for details.
|
48
|
+
|
49
|
+
7. Need to add the following in initialization of container such as rscrollpane
|
50
|
+
or rsplitpane:
|
51
|
+
`should_create_buffer true`
|
52
|
+
|
53
|
+
Also when creating a widget to put inside a container, use this line (see
|
54
|
+
samples below), as this needs to happen at construction time.
|
55
|
+
(This is in the application file when creating an instance, not the widget class).
|
56
|
+
|
57
|
+
8. Remove any `dsl_accessor` on height or width since this will override widget.
|
58
|
+
If you create a method, call `super()`. You need to create a method called
|
59
|
+
height and width in order to pass delta down to children components if
|
60
|
+
applicable, also call `super`.
|
61
|
+
|
62
|
+
9. You may have to `print_borders()` in `repaint()`, checking for `@repaint_all` (see
|
63
|
+
rtextview.rb). i.e, don't print just once in constructor, since when the
|
64
|
+
object is placed inside a splitpane, its size can change.
|
65
|
+
|
66
|
+
if @should_create_buffer
|
67
|
+
$log.debug " overriding editors comp with GRAPHIC #{@graphic} " editor.component.override_graphic(@graphic) # 2010-01-05 00:36 TRYING OUT BUFFERED
|
68
|
+
end
|
69
|
+
|
70
|
+
See testscrollp.rb or testscrollta.rb for working sample.
|
71
|
+
|
72
|
+
* * *
|
73
|
+
|
74
|
+
|
75
|
+
Subject: Scrollpane's form
|
76
|
+
--------------------------
|
77
|
+
Date: 2009-12-27 20:08
|
78
|
+
|
79
|
+
Since scrollpane's child object has no form, scrollpane needs to have its own form
|
80
|
+
and hand it to child object. However, set_form was overwriting the existing @graphic
|
81
|
+
so nothing was printed.
|
82
|
+
Had to put a check so graphic (buffer) not overwritten. Now the child object does
|
83
|
+
print correctly with a form object. No crashing regarding nil form.
|
84
|
+
|
85
|
+
1. Container objects such as scrollpane and splitpane which have widgets
|
86
|
+
with nil forms require to create a form using existing graphic object
|
87
|
+
as window and hand that to the child objects.
|
88
|
+
|
89
|
+
* * * * * * * *
|
90
|
+
|
91
|
+
Subject: Moving cursor in ScrollPane's child
|
92
|
+
--------------------------------------------
|
93
|
+
Date: 2009-12-28 23:19
|
94
|
+
|
95
|
+
Since child has its own form, had to hack an if clause in child object
|
96
|
+
(ListScrollable in the case of Textarea) to modify parent forms row and col.
|
97
|
+
Also added a parent_form in form.
|
98
|
+
|
99
|
+
However, this needs to be done in scrollpane or other higher up place, so i
|
100
|
+
don't have to keep doing it.
|
101
|
+
|
102
|
+
ALso what if there are multiple objects in a heirarchy. Splitpane contains
|
103
|
+
another Splitpane which contains some object. The setting must bubble up all the
|
104
|
+
way.
|
105
|
+
|
106
|
+
* * * * * * * *
|
107
|
+
|
108
|
+
Subject: class Form - set_form_rowcol
|
109
|
+
-------------------------------------
|
110
|
+
Date: 2009-12-29 15:28
|
111
|
+
|
112
|
+
Form should have a method rather than allow direct setting.
|
113
|
+
This method can percolate up to a parent form if not the same as current.
|
114
|
+
|
115
|
+
* * * * * * * *
|
116
|
+
|
117
|
+
Subject: More on scrollpane and other widgets
|
118
|
+
---------------------------------------------
|
119
|
+
Date: 2009-12-30 18:03
|
120
|
+
|
121
|
+
I have added a Form.rows_panned and cols_panned, so that a form know
|
122
|
+
how much its objects have been panned by. Otherwise there was no way
|
123
|
+
of Textarea knowing it had been panned. It would keep resetting the
|
124
|
+
cursor to the wrong value. rows_panned allows it to account for panning
|
125
|
+
so the cursor can flash at where insertion is happening.
|
126
|
+
See Scrollpane, handle_keys, around line 224.
|
127
|
+
|
128
|
+
* * * * * * * *
|
129
|
+
|
130
|
+
Subject: Scrollpane's cursor out of bounds - known bug
|
131
|
+
------------------------------------------------------
|
132
|
+
Date: 2009-12-31 09:42
|
133
|
+
|
134
|
+
I've tried various ways to handle this - currently a variable named
|
135
|
+
outofbounds. However, some little logic error causes the cursor
|
136
|
+
to lose synch with the caret (insertion point).
|
137
|
+
|
138
|
+
So until I can sort that out, we live with the cursor going cruising
|
139
|
+
across the screen, although it does remain very true to the insertion
|
140
|
+
point so no data can get mucked up.
|
141
|
+
|
142
|
+
* * * * * * * *
|
143
|
+
|
144
|
+
Subject: more thoughts on cursor display
|
145
|
+
----------------------------------------
|
146
|
+
Date: 2009-12-31 17:14
|
147
|
+
|
148
|
+
I deleted the todo item regarding widgets maintain cursor display
|
149
|
+
themselves, but now i think the insertion point is specfic to some
|
150
|
+
widgets not all, and that the widget should perhaps maintain it
|
151
|
+
themselves.
|
152
|
+
|
153
|
+
Most widgets highlight a line or item within. There is no editing
|
154
|
+
happening. On a GUI there really is no cursor. However, textfields and
|
155
|
+
textareas do have an insertion point (caret?). If they maitain their own
|
156
|
+
insertion points, then when they are hidden or panned, the cursor would
|
157
|
+
get hidden automatically since i assume its painted onto the buffer or
|
158
|
+
pad.
|
159
|
+
|
160
|
+
For example, tabbedpanes work just fine in these widgets since they take
|
161
|
+
care fo their ownfocssing and selection.
|
162
|
+
|
163
|
+
* * * * * * * *
|
164
|
+
|
165
|
+
Subject: Textarea overwrite problem
|
166
|
+
-----------------------------------
|
167
|
+
Date: 2010-01-03 17:54
|
168
|
+
|
169
|
+
I think it's like this.. (reference test2.rb sample program)
|
170
|
+
|
171
|
+
Textarea uses a pad, which does a `prefresh` onto screen.
|
172
|
+
All the other widgets (unbuffered) write to a window which does a
|
173
|
+
`wrefresh`. This refresh overwrites the write that `prefresh` did.
|
174
|
+
|
175
|
+
Acco to the manpage, certain optimizations are done with what is
|
176
|
+
already there on the screen. My guess is that a window wrefresh does not
|
177
|
+
disturb what is on the right, but it does overwrite what's on the left.
|
178
|
+
|
179
|
+
Now, scrollpane and splitpane use a `buffer_to_screen` passing their own
|
180
|
+
graphic object, so the main window is written onto. I need to confirm
|
181
|
+
this by placing something on the right. Here, since textarea was not a
|
182
|
+
child or embedded object, a `pad.refresh` was done.
|
183
|
+
|
184
|
+
I think i need to ensure that a `copy_pad_to_win` is done in these cases,
|
185
|
+
by passing a graphic object. At least the source of this bug is now
|
186
|
+
clear to me now.
|
187
|
+
|
188
|
+
* * * * * * * *
|
189
|
+
|
190
|
+
Subject: Thoughts on the buffered (pad) approach
|
191
|
+
------------------------------------------------
|
192
|
+
Date: 2010-01-05 12:03
|
193
|
+
|
194
|
+
Buffering all widgets means that there will be a huge number of pads
|
195
|
+
beign created for a screen that has a lot of fields. Lots of copying and
|
196
|
+
possibilities of errors.
|
197
|
+
|
198
|
+
In ordinary cases, there should be only one window, as in the old
|
199
|
+
version. The buffered approach is only required if a scrollpane or
|
200
|
+
splitpane is being used, even there only what is embedded will create its
|
201
|
+
own buffer. That simplifies the whole thing. The usual execution path
|
202
|
+
will be the old simple one.
|
203
|
+
|
204
|
+
It may make more sense for the container to pass a buffer to the child
|
205
|
+
and so on, rather than each level creating a buffer and copying to the
|
206
|
+
higher level. That may totally eliminate having to create buffered
|
207
|
+
objects, just have scrollpane and splitpane create a buffer and hand it
|
208
|
+
down. I need to think this over, why did i not think of this before.
|
209
|
+
|
210
|
+
The reason for this is that each level does not know what will be
|
211
|
+
displayed and what will be truncated. So it writes things out full,
|
212
|
+
or as much is the widget coordinates. The next level does the relevant
|
213
|
+
truncation. So the current approach is correct, however, when it can be
|
214
|
+
avoided and one window used, only one should be. This will be in 99%
|
215
|
+
cases. In anycase, listbox, textarea and textview and table implement
|
216
|
+
their own scrolling, so one really does not need scrollpane for them.
|
217
|
+
Scrollpane may be needed when we create a scrollable form.
|
218
|
+
|
219
|
+
So we can have a `should_buffer(boolean)`, which goes the buffer route (if
|
220
|
+
set true by parent), else things continue with a form.window as before.
|
221
|
+
|
222
|
+
added later 2010-01-05 13:24 :
|
223
|
+
Regarding conditional buffering, what if some component containing components,
|
224
|
+
such as a listbox or table containing editor components is place in a form which
|
225
|
+
is placed in a scrollpane. The scrollpane can set `should_buffer` for the child,
|
226
|
+
but what of all the lower components ? Should this be passed down ?
|
227
|
+
|
228
|
+
* * * * * * * *
|
229
|
+
|
230
|
+
Subject: Implementing a scrollable form
|
231
|
+
---------------------------------------
|
232
|
+
Date: 2010-01-05 12:34
|
233
|
+
|
234
|
+
Two approaches come to mind:
|
235
|
+
|
236
|
+
1. Create a form using a pad (i/o of a window). Form will have to
|
237
|
+
handle scroll keys if child does not handle them.
|
238
|
+
Ensure that pad writes onto physical screen, not a window (like it
|
239
|
+
used to).
|
240
|
+
|
241
|
+
2. Create the usual window and scrollpane.
|
242
|
+
Make the child a form-widget -- a widget that contains a form, sends
|
243
|
+
messages to form. However, the form should be based on a pad.
|
244
|
+
|
245
|
+
In both cases, a form is based on a pad, so objects can be placed in
|
246
|
+
a larger area than the physical screen.
|
247
|
+
|
248
|
+
* * * * * * * *
|
249
|
+
|
250
|
+
Subject: form.setrowcol and rowcol
|
251
|
+
----------------------------------
|
252
|
+
Date: 2010-01-05 21:11
|
253
|
+
|
254
|
+
i began setting both row and col from `set_form_row`, but it does not know
|
255
|
+
the current col. `rowcol` seems to return the position where printing
|
256
|
+
should start, or the cursor should be positioned on entry first time.
|
257
|
+
|
258
|
+
So i am now passing nil for c, so col is not disturbed.
|
259
|
+
test2.rb's listbox is now editing fine, cursor is moving when editing.
|
260
|
+
However, in scrollpane with pads etc, the cursor is not moving.
|
261
|
+
|
262
|
+
* * * * * * * *
|
263
|
+
|
264
|
+
Subject: embedded splitpanes
|
265
|
+
----------------------------
|
266
|
+
Date: 2010-01-07 19:19
|
267
|
+
|
268
|
+
*Case*: splitpane within another splitpane.
|
269
|
+
|
270
|
+
*Examples*: ruby doc or java doc. Now think text mode, no mouse, no
|
271
|
+
dragging. Open ruby docs or java docs in `links`.
|
272
|
+
|
273
|
+
Lets take a realistic scenario of a splitpane which contains a splitpane
|
274
|
+
as one (or both) components. We've defined some key/s to resize a
|
275
|
+
splitpane, but now which splitpane gets the key. How does the user
|
276
|
+
specify which level the key pertains to.
|
277
|
+
|
278
|
+
In textual browsers such as links, "frames" have been used. So you are
|
279
|
+
inside a frame. Your key pertains to that frame and you tab between
|
280
|
+
frames. Using splitpanes, when you are in a component you are inside a
|
281
|
+
splitpane too. So in the case of a splitpane within another, you are in
|
282
|
+
2 splitpanes.
|
283
|
+
|
284
|
+
When you tab into a splitpane, I'd like to make it easy and put the
|
285
|
+
focus inside the first component. You can switch between components. But
|
286
|
+
you are never really focussed on the splitpane. Any keys not processed
|
287
|
+
by the child components are passed up to the splitpane. Thats how it
|
288
|
+
does resizing, or changing orientation.
|
289
|
+
|
290
|
+
The other option is that you first focus on the splitpane, and then tab
|
291
|
+
once more to the first component. Ugh ! But it allows you use simple
|
292
|
+
keys like plus and minus to resize. Thus in a multilevel scrollpane,
|
293
|
+
you'd need many tabs to get to the actual component.
|
294
|
+
|
295
|
+
There's a third option, i do as before, but give a special key to go to
|
296
|
+
outer splitpane, so conditionally focus can go onto splitpane.
|
297
|
+
|
298
|
+
* * * * * * * *
|
299
|
+
|
300
|
+
Subject: repaint_all
|
301
|
+
--------------------
|
302
|
+
Date: 2010-01-08 20:29
|
303
|
+
|
304
|
+
I have added repaint_all and repaint_required in class Widget.
|
305
|
+
Sometime a parent wants to tell its child to repaint, and there's no
|
306
|
+
way. The only way was to fire a handler.
|
307
|
+
|
308
|
+
Also added a repaint_all, so if some widgets want to print a border or
|
309
|
+
clear area only on a major change (like dimension change), they can use
|
310
|
+
this flag. Calling repaint_all, sets repaint_required also. The latter
|
311
|
+
is for usual data changes.
|
312
|
+
|
313
|
+
* * * * * * * *
|
314
|
+
|
315
|
+
Subject: Splitpane and cascading dimension changes to child
|
316
|
+
-----------------------------------------------------------
|
317
|
+
Date: 2010-01-09 20:37
|
318
|
+
|
319
|
+
**Splitpane**, moving divider.
|
320
|
+
|
321
|
+
Now by default, changes to width and height are *not* cascaded to child
|
322
|
+
components.
|
323
|
+
However, as and when the divider is increased beyond size of first
|
324
|
+
component, the first component will enlarge and automatically its buffer
|
325
|
+
is resized.
|
326
|
+
|
327
|
+
I've also worked on preventing the crash. Essentially, the screen_buffer
|
328
|
+
should not become less than the components pane. This can happen in 2
|
329
|
+
ways, one is the buffer is resized whenever component increases. I was
|
330
|
+
(by oversight) overriding widget's height having defined a dsl_accessor
|
331
|
+
in textview.
|
332
|
+
|
333
|
+
However, if you don't want to resize the buffer, then one should not
|
334
|
+
call `set_screen_max_row_col` if it exceeds the warning condition. This
|
335
|
+
warning is if one is creating a new widget, if it crashes on `copywin`
|
336
|
+
and Height is more than `smaxrow()` then you'll have a crash. So resize
|
337
|
+
at that time by simply increasing the widgets height, or else put a
|
338
|
+
check in widget so that the method is not called for this condition.
|
339
|
+
|
340
|
+
* * * * * * * *
|
341
|
+
|
342
|
+
Subject: maxlen in rtextview
|
343
|
+
----------------------------
|
344
|
+
Date: 2010-01-10 19:28
|
345
|
+
|
346
|
+
Made a change in rtextview.
|
347
|
+
In the constructor, maxlen if nil was set to width-2.
|
348
|
+
So, if width was changed later maxlen would remain the same. And maxlen
|
349
|
+
is used as the length (width) of the content to print.
|
350
|
+
|
351
|
+
I've never changed the width at runtime, till today, from splitpane, and
|
352
|
+
this came out. So now unless you explicitly set maxlen, it must remain
|
353
|
+
nil and be set locally in each method as width-2.
|
354
|
+
|
355
|
+
I supposed the same has to be done in rtextarea.
|
356
|
+
|
357
|
+
* * * * * * * *
|
358
|
+
|
359
|
+
Subject: copy_pad_to_win
|
360
|
+
------------------------
|
361
|
+
Date: 2010-01-11 23:47
|
362
|
+
|
363
|
+
More and more scenarios are coming up when copy_pad_to_win can either
|
364
|
+
return a -1 and do nothing, or print less that it should be.
|
365
|
+
|
366
|
+
I can't correct more of these in the method, since that would break some
|
367
|
+
other situation. I have added warnings, though. One will have to check
|
368
|
+
the log file and see what warnings have been printed. If none, then we
|
369
|
+
have a new scenario, and the data has to be inspected to figure out.
|
370
|
+
|
371
|
+
* * * * * * * *
|
372
|
+
|
373
|
+
Subject: regarding create_buffer in repaint
|
374
|
+
-------------------------------------------
|
375
|
+
Date: 2010-01-12 12:54
|
376
|
+
|
377
|
+
If a widget calls `create_buffer` in repaint, it uses some default values
|
378
|
+
such as for top and left (0,0). To change these values, from a parent
|
379
|
+
component such as splitpane, means i change after `repaint()` so the first
|
380
|
+
paint is off by one row and col. The subsequent paint is okay.
|
381
|
+
|
382
|
+
I need to be able to pass values to a widget prior to `repaint()`, so its
|
383
|
+
`create_buffer` can be influenced.
|
384
|
+
|
385
|
+
* * * * * * * *
|
386
|
+
|
387
|
+
Subject: cursor positioning form#setrowcol
|
388
|
+
------------------------------------------
|
389
|
+
Date: 2010-01-12 22:53
|
390
|
+
|
391
|
+
Since i currently go up a heirarchy of forms, passing up the row and col
|
392
|
+
to be set, i cannot add the col and row offsets of the parent
|
393
|
+
(enclosing) widgets.
|
394
|
+
Had i gone up a heirarchy of widgets, I could have added their offsets.
|
395
|
+
|
396
|
+
In any case, i think I need to add them as parents, in methods like
|
397
|
+
`child()` or `first_component`. Then a method will be needed to pass values
|
398
|
+
up, and when no parent then set in its form. Each level adds its offset.
|
399
|
+
|
400
|
+
OTOH, another option would be when setting a child component, to once and for
|
401
|
+
all pass down cumulative offsets. Thus, one will not have to keep adding.
|
402
|
+
However, it is inefficient, is it not to propogate each cursor move up. Won't
|
403
|
+
that be slow ?
|
404
|
+
For that matter, won't this copying buffer be slow. Is there no faster way out?
|
405
|
+
|
406
|
+
|
407
|
+
In the case of multiple embedded components, can we not pass down the offsets
|
408
|
+
and boundaries when setting or moving so that each component writes directly,
|
409
|
+
and the cursor can be set easily without passing up ? There is a one time
|
410
|
+
passing down on creation, and moving or resizing. Each component knows its own
|
411
|
+
absolute position on the form, and there's basically only one form (except maybe
|
412
|
+
for tabbed panes).
|
413
|
+
|
414
|
+
Buffers means that scrollpanes for example only scroll a buffer, the widget does
|
415
|
+
not have to redraw repeatedly. Repainting is higher level code with many type
|
416
|
+
conversions, slicing, formatting etc, scrolling is merely a low-level copywin()
|
417
|
+
call. however, copywin() seems a lot more prone to error (new situations).
|
418
|
+
|
419
|
+
Direct painting without a buffer means constant repainting on scrolling, like
|
420
|
+
happens when we use TextViews and listboxes inbuilt scrolling.
|
421
|
+
Otoh, it means each component has to implement scrolling. With a scrollpane, we
|
422
|
+
can have scrollpane do the job, although the child has to write onto a pad.
|
423
|
+
* * * * * * * *
|
424
|
+
|
425
|
+
Subject: update to cursor positioning
|
426
|
+
-------------------------------------
|
427
|
+
Date: 2010-01-13 18:26
|
428
|
+
|
429
|
+
Just studied the code to see how each textview knows where to print
|
430
|
+
inside splitpanes. Each component's `@col` is set to where printing has to
|
431
|
+
start, that's all. I was mistakenly using `@orig_col` which is never
|
432
|
+
updated.
|
433
|
+
Now its fine, which means I don't need `widget#setformrowcol`, the earlier
|
434
|
+
`form#setrowcol` is fine. Don;t use orig_col in setting cursor,
|
435
|
+
applies to rtextarea.rb, too.
|
436
|
+
|
437
|
+
* * * * * * * *
|
438
|
+
|
439
|
+
Subject: speed of splitpane, copying buffers
|
440
|
+
--------------------------------------------
|
441
|
+
Date: 2010-01-14 15:44
|
442
|
+
|
443
|
+
One can type fast in a textarea as is and see updates immediately. But
|
444
|
+
when the textarea is inside a splitpane, due to the buffer copying
|
445
|
+
happening, fast typing updates take time to show up.
|
446
|
+
|
447
|
+
Sequence would be as follows:
|
448
|
+
1. textarea buffer copies onto splitpane buffer
|
449
|
+
2. Splitpane buffer copies to main form window (earlier it would copy to
|
450
|
+
screen directly)
|
451
|
+
3. form.window does a wrefresh.
|
452
|
+
|
453
|
+
Each time you type a character, it goes through the above. We need to
|
454
|
+
get the innermost widget buffer to write directly to the form.window
|
455
|
+
somehow.
|
456
|
+
|
457
|
+
Also a quick cursor movement, shows the cursor flashing on row below now
|
458
|
+
and then, although when you move the cursor slowly, it move fine.
|
459
|
+
|
460
|
+
* * * * * * * *
|
461
|
+
|
462
|
+
Subject: slitpanes in a mouseless CUI environment
|
463
|
+
-------------------------------------------------
|
464
|
+
Date: 2010-01-15 13:02
|
465
|
+
|
466
|
+
The issue here is navigating between panes, if you have splitpanes
|
467
|
+
embedded between splitpanes. Typically, control goes to the first
|
468
|
+
component, and switching happens between the 2 panes of the first
|
469
|
+
component.
|
470
|
+
I've defined TAB to do a switch on the outer component, but that only
|
471
|
+
delays or reduces the problem.
|
472
|
+
|
473
|
+
We need another component, more like vim's splits. You can split it as
|
474
|
+
many times. Each split returns 2 handles. You can split the handle. You
|
475
|
+
can place a component in the handle. Once it is all in one component,
|
476
|
+
one can reorder and exchange positions too.
|
477
|
+
|
478
|
+
Expanding contracting can de done with current split in focus. With
|
479
|
+
embedded splitpanes, we don't know which level the user is intending the
|
480
|
+
resize (or motion) key for.
|
481
|
+
|
482
|
+
* * * * * * * *
|
483
|
+
|
484
|
+
Subject: cursor positioning in mult splitpanes
|
485
|
+
----------------------------------------------
|
486
|
+
Date: 2010-01-15 23:26
|
487
|
+
|
488
|
+
When placing textviews inside 2 splitpanes, a funny thing happened, i found that
|
489
|
+
the cursor was always on 5,5, no matter where the outer split was placed. Appa,
|
490
|
+
we need to add the outer windows left and top offsets.
|
491
|
+
|
492
|
+
I have done that, and now the cursor is in the right place regardless of whether
|
493
|
+
there are 2 or 1 splitpanes.
|
494
|
+
|
495
|
+
Now both setformrowcol and setrowcol are correct. However, i think the form
|
496
|
+
route of setrowcol is better since a form's offset won't get duplicated.
|
497
|
+
|
498
|
+
* * * * * * * *
|
499
|
+
|
500
|
+
Subject: container widgets
|
501
|
+
--------------------------
|
502
|
+
Date: 2010-01-16 23:57
|
503
|
+
|
504
|
+
Widgets such as splitpane, scrollpane, viewport and any future widgets should be
|
505
|
+
able to pass changes to dimensions down to their children.
|
506
|
+
|
507
|
+
So they should have a `height` and `width` method that adds the delta to the
|
508
|
+
child, or relevant children. and calls `super`, so that buffers can be
|
509
|
+
rebuilt.
|
510
|
+
|
511
|
+
* * * * * * * *
|
512
|
+
|
513
|
+
Subject: scrolling and wrefresh
|
514
|
+
-------------------------------
|
515
|
+
Date: 2010-01-19 12:26
|
516
|
+
|
517
|
+
Suggested optimizations to pad and `wclear.`
|
518
|
+
Currently, i have to do a `wclear` everytime i scroll a pad or else
|
519
|
+
previously displayed data if often not cleared off and remains.
|
520
|
+
**Can this extra clearing be avoided**. i once tried `clr_to_bot` but
|
521
|
+
did not seem to work.
|
522
|
+
|
523
|
+
This happens when we scroll past last row (or last col in horizontal
|
524
|
+
scrolling).
|
525
|
+
|
526
|
+
Options to reduce or obviate `wclear:`
|
527
|
+
|
528
|
+
1. Get scroll exactly so that no empty rows or columns shown. Very
|
529
|
+
dicey.
|
530
|
+
|
531
|
+
2. `wclear` only after a point when reaching the end. Setting some flag.
|
532
|
+
e.g. when `number of rows < scrollatrow().`
|
533
|
+
|
534
|
+
3. Don't clear entire window, but only the region you don't paint over.
|
535
|
+
Try clear to bottom again.
|
536
|
+
|
537
|
+
4. Define pad larger (extra rows by size of widget) so that there's
|
538
|
+
alway that much blank rows there. Same for width.
|
539
|
+
If displaying 100 rows in a 10 row widget, define pad as 110, so when
|
540
|
+
scrolling last page, there's always blank space ahead. This should
|
541
|
+
totally obviate `wclear`.
|
542
|
+
|
543
|
+
* * * * * * * *
|
544
|
+
|
545
|
+
Subject: scrollpane updates
|
546
|
+
---------------------------
|
547
|
+
Date: 2010-01-19 19:40
|
548
|
+
|
549
|
+
A scrollpane only clears and repaints the entire area if its size is
|
550
|
+
changed or it is scrolled. In such cases, the `repaint_all` variable is set
|
551
|
+
to true.
|
552
|
+
|
553
|
+
In all other cases, it only copies the child's buffer up. This is
|
554
|
+
required otherwise changes to the child will not show up at all. Thus,
|
555
|
+
changes to `rviewport` and `rscrollpane` have been made.
|
556
|
+
|
557
|
+
The awful flashing has stopped, however all test programs that use
|
558
|
+
Scrollpane have to be retested -- YAY !
|
559
|
+
|
560
|
+
Isn't testing over and over again such fun.
|
561
|
+
|
562
|
+
* * * * * * * *
|
563
|
+
|
564
|
+
Subject: cursor display by widget itself
|
565
|
+
----------------------------------------
|
566
|
+
Date: 2010-01-20 22:21
|
567
|
+
|
568
|
+
Would be so cool if widgets could display cursor themselves as a mark or
|
569
|
+
attribute.
|
570
|
+
That has pros and cons:
|
571
|
+
|
572
|
+
- At a terminal level, one cannot change cursor color or attributes. It
|
573
|
+
would be programmed.
|
574
|
+
|
575
|
+
+ OTOH, we would not have to test and ensure that cursor is being set
|
576
|
+
when an object is embedded and does not have access to the top form
|
577
|
+
that is setting the cursor.
|
578
|
+
|
579
|
+
- But, when the cursor moves, we would have to erase the cursor and add
|
580
|
+
it elsewhere. that could resul in a cursor left behind in one widget
|
581
|
+
when we jump to another.
|
582
|
+
|
583
|
+
+ In scrolling the mark would just move along. No programming required.
|
584
|
+
|
585
|
+
- if a widget forgets to erase or set cursor on events like on_enter
|
586
|
+
on_leave, we could have multiple cursors.
|
587
|
+
|
588
|
+
Perhaps editable widgets such as textarea or ones that allow cursor
|
589
|
+
movement like listbox and textview could at least show an insertion
|
590
|
+
point or caret of some sort. So even if cursor always hangs around at
|
591
|
+
top left corner of active widget, the insertion point can be shown as an
|
592
|
+
underline or something. (UL's don't work in all TERMS).
|
593
|
+
|
594
|
+
Let's think about some kind of mark that is independent of the cursor.
|
595
|
+
One huge headache for scrollpanes, textareas etc would be taken care
|
596
|
+
off. Issue is, does TA or TV really know where the insertion point is.
|
597
|
+
Yes, @current_index and @curpos (i think).
|
598
|
+
|
599
|
+
* * * * * * * *
|
600
|
+
|
601
|
+
Subject: cursor positioning
|
602
|
+
---------------------------
|
603
|
+
Date: 2010-01-20 23:06
|
604
|
+
|
605
|
+
If a listbox can paint the row with selection, then surely it can paint
|
606
|
+
hte curpos position with a red background for cursor (this can be
|
607
|
+
defined at the widget level and overridden per widget if need be).
|
608
|
+
|
609
|
+
Similarly, textareas have a search highlighting. And i do have
|
610
|
+
current_index and curpos. That can be used for setting a cursor upon
|
611
|
+
repaint. Worth a try. Should help in the long run.
|
612
|
+
|
613
|
+
In any case, its high time a widget is informed of its exact coordinates
|
614
|
+
no matter how deep it is. Parents can inform children of row and col
|
615
|
+
changes. Then the child can itself call wmove and not have to set
|
616
|
+
attributes. Also for that the form that is painting, its value should be
|
617
|
+
sent (but btw, if the embedded component sets wmove, that will be erased
|
618
|
+
when the buffer copying happens).
|
619
|
+
|
620
|
+
* * * * * * * *
|
621
|
+
|
622
|
+
Subject: tabbedpanes vs other containers
|
623
|
+
----------------------------------------
|
624
|
+
Date: 2010-01-21 18:49
|
625
|
+
|
626
|
+
Other containers contain an object, so they call its on_enter or
|
627
|
+
set_form_row so that cursor is correctly set no matter how deep the
|
628
|
+
level of containment.
|
629
|
+
|
630
|
+
However, `TabbedPane` contains a form. The caller can set what he wants on
|
631
|
+
that form. Thus, i am finding that the usual technique that `SplitPanes`
|
632
|
+
used for setting the cursor is failing here.
|
633
|
+
|
634
|
+
This does mean that tabbedpanes can have complete forms inside them with
|
635
|
+
multiple buttons, checkboxes etc -- that is absolutely necessary.
|
636
|
+
|
637
|
+
* * * * * * * *
|
638
|
+
|
639
|
+
Subject: vim like splitpanes
|
640
|
+
----------------------------
|
641
|
+
Date: 2010-01-22 19:39
|
642
|
+
|
643
|
+
Don't know if I've put this down already. Splitpanes within splitpanes
|
644
|
+
is a bit slow if you intend doing very fast typing within a textarea, for
|
645
|
+
example.
|
646
|
+
|
647
|
+
Also since there is no mouse, which split do you intend widening or
|
648
|
+
resizing -- a bit of a pain. Setting up sizes of the splits can also be
|
649
|
+
dicey at present. For a mouseless environment, perhaps vim editor like
|
650
|
+
splits are better. There is only one level for starters.
|
651
|
+
|
652
|
+
To create splits, take the first pane, split it. You get 2 objects
|
653
|
+
(panes). Split them any way you want. You have handles to each split or
|
654
|
+
buffer. Place any object you want in each window. Whichever window the
|
655
|
+
cursor is on is the one that resizing commands apply to. There is only
|
656
|
+
one level so its easy. Again using TAB to cycle between splits will
|
657
|
+
work. Similarly, it should be possible to rearrange, kill, add etc at
|
658
|
+
will. Or to move to the left or right or top tab.
|
659
|
+
|
660
|
+
The splits could have scrolling built in, so we don't lose 2 rows and
|
661
|
+
cols showing the scrollbars. Scrollbars could be fitted into the split
|
662
|
+
itself.
|
663
|
+
|
664
|
+
* * * * * * * *
|
665
|
+
|
666
|
+
Subject: form parameter in widget creation
|
667
|
+
------------------------------------------
|
668
|
+
Date: 2010-01-22 19:50
|
669
|
+
|
670
|
+
I am wondering whether the **form parameter** in `Widget` is clunky. Since
|
671
|
+
it's often set to nil, in embedded objects, or if you wish to create a
|
672
|
+
widget first and hand it off to some other form or list or tabbedpane.
|
673
|
+
|
674
|
+
The way of creating objects in a DSL'ish way is a bit goofy since I had
|
675
|
+
problems putting my head around not being able to overload constructors
|
676
|
+
in ruby.
|
677
|
+
|
678
|
+
This (removing form) would be a major change since it would break
|
679
|
+
everything but for future users it could be neater. A form may be added
|
680
|
+
to, rather than widgets take the form param and add themselves.
|
681
|
+
|
682
|
+
This internally breaks code too, since many objects just expect a form
|
683
|
+
to be present when created of when some methods are called.
|
684
|
+
|
685
|
+
This means that the constructor params can have what's actually needed to
|
686
|
+
work. Currently even I don't know what's absolutely needed for an object
|
687
|
+
to work. What are the minimal requirements ? "Just run it and if it
|
688
|
+
crashes with a null pointer assignment, then you know something has to
|
689
|
+
be set." That sucks, and embarasses me since I've done *a lot* better in
|
690
|
+
the past (in other languages).
|
691
|
+
|
692
|
+
However, i think that's the way to go.
|
693
|
+
|
694
|
+
* * * * * * * *
|
695
|
+
|
696
|
+
Subject: cursor handling internally
|
697
|
+
-----------------------------------
|
698
|
+
Date: 2010-01-23 20:23
|
699
|
+
|
700
|
+
I've got textarea to handle cursor painting by itself, BUT ...
|
701
|
+
that means each time the widget will have to be copied (for all cursor
|
702
|
+
motion) even when the screen does not scroll. Currently, when we use
|
703
|
+
window's `wmove`, we do not need to repaint or copy_pad at all.
|
704
|
+
|
705
|
+
Any write to the graphic object (when in buffered mode) requires the
|
706
|
+
buffer to be copied, and that means setting buffer_modified to true.
|
707
|
+
|
708
|
+
Also note that all cursor motion requires the footer to be painted.
|
709
|
+
Currently, some movements are forgetting to do that, and some are - but
|
710
|
+
they are repainting the whole textarea just to paint the footer (row and
|
711
|
+
col in footer).
|
712
|
+
|
713
|
+
We should set another flag for updating the footer only. (see `addcol`
|
714
|
+
and `addrowcol`).
|
715
|
+
|
716
|
+
I am thinking of making this method paint_internal_cursor conditional.
|
717
|
+
|
718
|
+
* * * * * * * *
|
719
|
+
|
720
|
+
Subject: aah the tabbedpane cursor offset issue
|
721
|
+
-----------------------------------------------
|
722
|
+
Date: 2010-01-26 20:10
|
723
|
+
|
724
|
+
How daft of me! The tabbedpane's own row and col were resulting in the
|
725
|
+
textarea not being able to calculate the correct cursor offset.
|
726
|
+
So we do have to look at parent objects and their own row and col, do
|
727
|
+
we? But what of scrollpanes and splitpanes ?
|
728
|
+
|
729
|
+
So basically while setting cursor, i need to add parent's row and col,
|
730
|
+
too.
|
731
|
+
|
732
|
+
* * * * * * * *
|
733
|
+
|
734
|
+
Subject: microemacs user setup tabbedpane
|
735
|
+
-----------------------------------------
|
736
|
+
Date: 2010-01-30 00:06
|
737
|
+
|
738
|
+
Micremacs has user setup tabbedpanes. (Use F1)
|
739
|
+
Left and right keys are used to move from one tab to another.
|
740
|
+
|
741
|
+
Tab jumps to form associated with a tab. Tab does not cycle between
|
742
|
+
tabs. IN some fields, where there are selectable values (combos) a "v"
|
743
|
+
is shown but i am not clear how to access that list. Pressing Enter
|
744
|
+
opens up the config file. (Use spacebar)
|
745
|
+
|
746
|
+
* * * * * * * *
|
747
|
+
|
748
|
+
Subject: tabbedpanes and scrollpanes
|
749
|
+
------------------------------------
|
750
|
+
Date: 2010-02-02 23:04
|
751
|
+
|
752
|
+
I've spent more than 2 days battling a scrollpane inside a tabbedpane.
|
753
|
+
It wont print anything. I know what's going on, but unable to fix it.
|
754
|
+
Its simple but i am unable to catch it.
|
755
|
+
|
756
|
+
When i place a textarea directly in a tabbedpane (TP), it takes TP's
|
757
|
+
tab form. It does not create its own buffer. It writes to TP's form/pad
|
758
|
+
which is then copied to TP's own window. This works.
|
759
|
+
|
760
|
+
But when i place a textview inside a scrollpane and place that inside a
|
761
|
+
TP, it takes the TPs form, but then creates a form and pad, required for
|
762
|
+
the child. The TV writes to its own pad, which is then copied to
|
763
|
+
Viewport, to Scrollpane, to TP. But at this point, the tab form which
|
764
|
+
was given to Scrollpane and not used, kicks in and writes to TP.
|
765
|
+
|
766
|
+
So whatever was written to TP is overwritten by the unused TP tab
|
767
|
+
form/pad. Scrollpane should use this, but it creates its own buffer. If
|
768
|
+
i mess with this, all those other programs could go for a toss.
|
769
|
+
|
770
|
+
* * * * * * * *
|
771
|
+
|
772
|
+
Subject: scrollpane tabbedpane update
|
773
|
+
-------------------------------------
|
774
|
+
Date: 2010-02-03 19:06
|
775
|
+
|
776
|
+
I've finally got something displaying and working .. textview inside a
|
777
|
+
scrollpane inside a tabbedpane.
|
778
|
+
If the form given to a scrollpane has a pad as a window, then we use the
|
779
|
+
pad, if its a window, we do the usual create_buffer crap.
|
780
|
+
|
781
|
+
However, sadly the positioning is slightly off, the borders and not
|
782
|
+
printing fully (left and top not there). I've played around with the
|
783
|
+
`row` and `col`, but seems scrollpanes row and col have no impact. Its a
|
784
|
+
tricky situation since I have created a second form on the same pad.
|
785
|
+
|
786
|
+
I cannot set the same form as that passed in since then the mainform
|
787
|
+
would own the child inside scrollpane. So its very hackish really - not
|
788
|
+
clean. Getting messy -- we need to overhaul this whole new buffered
|
789
|
+
stuff - too much copying of buffers and breaking my nut over `copywin`.
|
790
|
+
|
791
|
+
Need to simplify.
|
792
|
+
|
793
|
+
* * * * * * * *
|
794
|
+
|
795
|
+
Subject: return values for form: false vs UNHANDLED
|
796
|
+
---------------------------------------------------
|
797
|
+
Date: 2010-02-04 19:12
|
798
|
+
|
799
|
+
Sometimes some methods like `down`, `up` etc return a `false` if they cannot go
|
800
|
+
down or up or scroll. However, when the `ret` is returned up, repainting
|
801
|
+
still happens. A form typically won't repaint if the return of
|
802
|
+
`handle_key` is `:UNHANDLED`. So, in scrollpane, I've had to convert
|
803
|
+
`ret` to `:UNHANDLED` if false, so no useless repainting happens.
|
804
|
+
|
805
|
+
* * * * * * * *
|
806
|
+
|
807
|
+
Subject: scrollpane inside tabbepanes PROBLEMS
|
808
|
+
----------------------------------------------
|
809
|
+
Date: 2010-02-04 20:52
|
810
|
+
|
811
|
+
Okay, I've got an idea what's happening.
|
812
|
+
This largely is since I've put in an ugly hack to take the PAD of a
|
813
|
+
parent form, if its a PAD (not a window). Otherwise, what I was
|
814
|
+
printing on Scrollpane's pad was getting overwritten by the TAB's pad
|
815
|
+
which was never written to.
|
816
|
+
|
817
|
+
1) `ScrollPane` does a `wclear` of the pad. This erases everything earlier
|
818
|
+
put on the pad, including the border.
|
819
|
+
|
820
|
+
2) Since Scrollpane does not know its picked up some other pad, its
|
821
|
+
border height and width are not correct. They would be fine if it had
|
822
|
+
created its own pad.
|
823
|
+
|
824
|
+
The options are:
|
825
|
+
|
826
|
+
1. Hack further so that this case is taken care of.
|
827
|
+
2. Do the sensible thing. Create own pad, and somehow copy scrollpane's
|
828
|
+
pad onto it at the end.
|
829
|
+
|
830
|
+
Even though i could not get #2 done, I think I should look into that now,
|
831
|
+
so the code is not mysterious and impossible to understand or maintain.
|
832
|
+
|
833
|
+
Also, I've got to simplify ScrollPane *completely*.
|
834
|
+
|
835
|
+
* * * * * * * *
|
836
|
+
|
837
|
+
Subject: maintaining logs and keystrokes
|
838
|
+
----------------------------------------
|
839
|
+
Date: 2010-02-07 11:48
|
840
|
+
|
841
|
+
Maybe one way of my tracking down when something breaks, which is
|
842
|
+
happening and is nerve-wrackig since its all UI stuff...
|
843
|
+
|
844
|
+
Maintain the log file. Also somehow mark what keystrokes we run.
|
845
|
+
That way when things break, i can run the same program with same keys
|
846
|
+
and compare. Keystrokes actually are already mentioned in file, but it
|
847
|
+
would be easier to put them separately.
|
848
|
+
|
849
|
+
Maybe i could just mail the log files to myself with a comment.
|
850
|
+
|
851
|
+
* * * * * * * *
|
852
|
+
|
853
|
+
Subject: reworking cursor positioning
|
854
|
+
-------------------------------------
|
855
|
+
Date: 2010-02-07 20:44
|
856
|
+
|
857
|
+
Two approaches:
|
858
|
+
|
859
|
+
1. Pass absolute coordinates down all the way, so widget can set abs
|
860
|
+
coords for cursor.
|
861
|
+
This still needs to go all the way up. Also any changes need to be
|
862
|
+
cascaded all the way down.
|
863
|
+
|
864
|
+
I am trying this.
|
865
|
+
|
866
|
+
2. A window or pad should print its own cursor. Why pass it to higher
|
867
|
+
forms. That way only absolute position within a pad or window is
|
868
|
+
required which is quite simple.
|
869
|
+
Also changes can be passed down quite easily.
|
870
|
+
However, when a pad prints cursor, control will come back to setpos
|
871
|
+
of main form, and it will move the cursor.
|
872
|
+
So it an inner pad or window is setting cursor, the main should not.
|
873
|
+
|
874
|
+
Somehow, mainform should know whether it should set cursor or not.
|
875
|
+
|
876
|
+
Actually this sounds simpler than option 1.
|
877
|
+
|
878
|
+
The danger of allowing widgets to set the cursor is that if multiple
|
879
|
+
are being updated in a loop, they will all set the cursor, and only
|
880
|
+
the last will show up.
|
881
|
+
Maybe the selected field can have an attrib, manages_cursor - if yes,
|
882
|
+
main form does nothig, assuming either a cursor is not needed, or
|
883
|
+
that widget has a form and is handling cursors. Containers will have
|
884
|
+
a true value.
|
885
|
+
|
886
|
+
* * * * * * * *
|
887
|
+
|
888
|
+
Subject: Major change: buffered version, splitpane, scrollpane NOW
|
889
|
+
------------------------------------------------------------------
|
890
|
+
Date: 2010-02-10 11:09
|
891
|
+
|
892
|
+
Too much breakage, too much debugging -- I need to redo the buffered
|
893
|
+
approach largely meaning that:
|
894
|
+
|
895
|
+
1. `SplitPane` and `ScrollPane` will have an almost complete rewrite.
|
896
|
+
|
897
|
+
2. Window and Widget will be touched, in terms of repainting - only the
|
898
|
+
buffered portion, so the classic version of rbcurse should not be
|
899
|
+
affected.
|
900
|
+
|
901
|
+
3. Yesterday, looking at the show_caret routine (carelessly tacked on
|
902
|
+
recently) in `Listscrollable`, I saw some glaring flaws, fixed it and
|
903
|
+
now Textviews and Textareas show their own caret (cursor) correctly,
|
904
|
+
no matter where they are placed. However, what one needs to do when
|
905
|
+
using this, is display it only on_enter, and hide it when on_exit.
|
906
|
+
|
907
|
+
Also, do remember that using this forces a `repaint` even when you move
|
908
|
+
the cursor inside the textarea. The original cursor routine does not
|
909
|
+
involve repainting unless scrolling happens due to movement.
|
910
|
+
|
911
|
+
However, it does solve a HUGE headache regarding cursor display in
|
912
|
+
complex setups like scrollpanes within a splitpane within another
|
913
|
+
splitpane.
|
914
|
+
|
915
|
+
To detail point 1.
|
916
|
+
|
917
|
+
### Current approach to using buffers (ncurses' Pad):
|
918
|
+
|
919
|
+
1. Too many pads which results in slow response, too much copying which
|
920
|
+
is very prone to bugs, too much impact of change.
|
921
|
+
Its too complex.
|
922
|
+
|
923
|
+
2. Copying pads from inner to outer widgets is too messy, very hard to
|
924
|
+
debug errors, slow.
|
925
|
+
|
926
|
+
3. Need to avoid or minimize pad usage.
|
927
|
+
|
928
|
+
### Alternatives:
|
929
|
+
|
930
|
+
1. **No pad**
|
931
|
+
- This means that we `repaint` each time scrolling happens
|
932
|
+
- Widget takes care of cropping and can make errors. Responsibility
|
933
|
+
is on each widget to crop. Cropping has to be from both sides, not
|
934
|
+
just right.
|
935
|
+
Typically, this cropping will happen for each line of a multi-line
|
936
|
+
widget. In the `copywin()` case, the widget writes without checking
|
937
|
+
len or cropping. The lower level `copywin()` takes care of cropping
|
938
|
+
so that's more efficient.
|
939
|
+
|
940
|
+
This does obviate the recreating of pads that happens due to
|
941
|
+
resizing or even setting the parent object's dimensions.
|
942
|
+
|
943
|
+
2. Use only **one pad** for the widget that's actually writing such as
|
944
|
+
`Textarea` or `Listbox`.
|
945
|
+
|
946
|
+
This widget is passed the coordinates to crop and the target window
|
947
|
+
(typically `form.window`).
|
948
|
+
It uses `prefresh()` to write onto form.window using coordinates.
|
949
|
+
Most likely this code can be put in superclass `Widget` so there are no
|
950
|
+
errors.
|
951
|
+
The container such as `Splitpane` and `Scrollpane` merely pass down
|
952
|
+
their bounds, so it doesn't matter how many levels there are. Only
|
953
|
+
bounds are being passed down and calculated.
|
954
|
+
|
955
|
+
Now its possibly that the container *suggests* to inner object to use a
|
956
|
+
pad. The inner object can if its programmed to, use a pad and use the
|
957
|
+
cropping, or it can just paint to the target. In the case of optional
|
958
|
+
pads, the widget will have code to crop each line, so that code will
|
959
|
+
exist even with a pad.
|
960
|
+
|
961
|
+
After that, the `Scrollpane` will put its border or scrollbars directly
|
962
|
+
onto `form.window` using the bounds it has. Similarly the higher level
|
963
|
+
`Splitpane` will paint its own border or divider etc onto the
|
964
|
+
`form.window` and so on.
|
965
|
+
|
966
|
+
|
967
|
+
### Tasks:
|
968
|
+
|
969
|
+
1. push all existing code to rbcurse19 branch
|
970
|
+
|
971
|
+
2. create a new branch for this change
|
972
|
+
|
973
|
+
3. Have `SplitPane` and `ScrollPane` push their dimensions down and paint onto
|
974
|
+
`@form.window` directly.
|
975
|
+
|
976
|
+
4. Have final widget (`TextArea`, `TextView`, `Listbox`) respect the
|
977
|
+
dimensions passed in, and refresh `Pad` onto actual target
|
978
|
+
(`@form.window`).
|
979
|
+
|
980
|
+
* * * * * * * *
|
981
|
+
|
982
|
+
Subject: method rowcol and offset fields
|
983
|
+
----------------------------------------
|
984
|
+
Date: 2010-02-11 21:56
|
985
|
+
|
986
|
+
method rowcol() is supposed to return the location where form would
|
987
|
+
place the cursor by default. So it takes row + row_offset.
|
988
|
+
row_offset usually is 1 by default, if you have a border.
|
989
|
+
|
990
|
+
However, there's some issue with placing an item inside a Scrollpane and
|
991
|
+
perhaps others. The buffer is copied with an offset of 1. So rowcol by
|
992
|
+
itself does not yield the correct cursor position.
|
993
|
+
|
994
|
+
If i add 1 to this, many other routines start printing one off. rowcol
|
995
|
+
has been used rather extensively because somewhere down the line, i
|
996
|
+
forgot its purpose (not having thought it necessary to document it).
|
997
|
+
|
998
|
+
So i've added a pad_offset in textview, for the pad cases. I know i am
|
999
|
+
redoing it and already started hacking.
|
1000
|
+
|
1001
|
+
* * * * * * * *
|
1002
|
+
|
1003
|
+
Subject: changes to buffered objects
|
1004
|
+
------------------------------------
|
1005
|
+
Date: 2010-02-11 23:21
|
1006
|
+
|
1007
|
+
Based on what I've done to TextView, to be done to TextArea, ListBox.
|
1008
|
+
|
1009
|
+
1. No references to @form.
|
1010
|
+
win_left and win_top store window's offsets.
|
1011
|
+
|
1012
|
+
2. target_window passed if form not passed.
|
1013
|
+
|
1014
|
+
3. move create_buffer to paint.
|
1015
|
+
Also, paint buffer here only, no passing up.
|
1016
|
+
|
1017
|
+
4. accept buffering_params hash and use for copywin
|
1018
|
+
|
1019
|
+
|
1020
|
+
5. For textarea, suppress borders.
|
1021
|
+
|
1022
|
+
-----
|
1023
|
+
|
1024
|
+
Containers should set should_buffer and pass bounds.
|
1025
|
+
Containers themselves do not create buffers. Just pass down.
|
1026
|
+
Containers only draw their borders etc.
|
1027
|
+
Move this drawing to after the inner object has painted. Paint onto
|
1028
|
+
window. Pass down ext_offset + col_offset.o
|
1029
|
+
|
1030
|
+
Since container are writing to window, add row and col to print-border
|
1031
|
+
and other print statements.
|
1032
|
+
|
1033
|
+
* * * * * * * *
|
1034
|
+
|
1035
|
+
Subject: ext_offsets explanation
|
1036
|
+
--------------------------------
|
1037
|
+
Date: 2010-02-13 10:33
|
1038
|
+
|
1039
|
+
`ext_row_offset` and `ext_col_offset` are essentially for a widget to be
|
1040
|
+
able to place the cursor. This is exactly how to set this variable.
|
1041
|
+
|
1042
|
+
A form, when adding a widget puts its `window.top` and `window.left` as row
|
1043
|
+
and col offset respectively.
|
1044
|
+
|
1045
|
+
In cases, where an object contains another object such as `ScrollPane` or
|
1046
|
+
`SplitPane`, ext_row_offset is set to row + ext_row_offset of parent
|
1047
|
+
class.
|
1048
|
+
|
1049
|
+
child.ext_row_offset = @row + @ext_row_offset.
|
1050
|
+
|
1051
|
+
Thus, this contains the starting point of the widget in absolute terms.
|
1052
|
+
This should not be used by any other programs as this is only to cater
|
1053
|
+
to `set_form_row` and `set_form_col` and could change to accomodate these 2
|
1054
|
+
methods.
|
1055
|
+
|
1056
|
+
However, the above assignment is at present the correct assignment.
|
1057
|
+
|
1058
|
+
* * * * * * * *
|
1059
|
+
|
1060
|
+
Subject: vimsplits or splitpane with subwins
|
1061
|
+
--------------------------------------------
|
1062
|
+
Date: 2010-02-13 20:14
|
1063
|
+
|
1064
|
+
I was just checking out `subwins` today and one thing led to another. I
|
1065
|
+
basically have a very barebones vim-splitty thing which has subwins for
|
1066
|
+
each split - `VimSplit`.
|
1067
|
+
It splits in half, yes, i need to allow moving. I've been wasting time
|
1068
|
+
putting text in each split.
|
1069
|
+
So each split returns 2 subwins. You can either attach a component to a
|
1070
|
+
split, so all keys go to it.
|
1071
|
+
Or else create a form with that window.
|
1072
|
+
Or create a widget with the window, and send keys to it. Attaching a
|
1073
|
+
widget to the window is best since it takes care of everything after
|
1074
|
+
that.
|
1075
|
+
|
1076
|
+
We still have to deal with setting the cursor, not sure if set_form_col
|
1077
|
+
is meant to deal witha subwin. Also its easy to use subwins.wmove but in
|
1078
|
+
our real application, the subwins wmove will get erased by the later
|
1079
|
+
windows that refresh.
|
1080
|
+
|
1081
|
+
* * * * * * * *
|
1082
|
+
|
1083
|
+
Subject: subwin does not resize and move
|
1084
|
+
----------------------------------------
|
1085
|
+
Date: 2010-02-13 23:05
|
1086
|
+
|
1087
|
+
subwins were working great for my splitpane (vimsplit) till i needed to
|
1088
|
+
implement the pane movement. That requires moving and resizing subwins.
|
1089
|
+
This was not happening since the coords are relative to the parent
|
1090
|
+
window, and somehow this link is lost. The moved window lands up with
|
1091
|
+
its relative coordinates as absolute coords now.
|
1092
|
+
|
1093
|
+
The man page says that subwindows resizing and movement should be
|
1094
|
+
avoided. Another page says:
|
1095
|
+
|
1096
|
+
> The subwindow functions (subwin, derwin, mvderwin, wsyncup, wsyncdown,
|
1097
|
+
> wcursyncup, syncok) are flaky, incompletely implemented, and not well
|
1098
|
+
> tested.
|
1099
|
+
|
1100
|
+
I could delete and recreate 2 new windows when a split pane's split is
|
1101
|
+
moved, but the reference to the window would change, and programs using
|
1102
|
+
that ref would keep referring a destroyed window.
|
1103
|
+
|
1104
|
+
It was too good to be true. I guess I have to go back to `pads` and `copywin` which
|
1105
|
+
I've learned to hate.
|
1106
|
+
|
1107
|
+
* * * * * * * *
|
1108
|
+
|
1109
|
+
Subject: subwins > derwin
|
1110
|
+
-------------------------
|
1111
|
+
Date: 2010-02-14 12:06
|
1112
|
+
|
1113
|
+
Okay, i've got ncurses subwins to resize and move, since they have absolute
|
1114
|
+
coordinates (unlike derwins) which lose their orientation. However, my
|
1115
|
+
scrollbar repainting is sucking since i need to paint it on the
|
1116
|
+
underlying window/subwin.
|
1117
|
+
|
1118
|
+
Somehow it prints a line 2 times - duh. Will have to see how far i can
|
1119
|
+
go with approach.
|
1120
|
+
|
1121
|
+
* * * * * * * *
|
1122
|
+
|
1123
|
+
Subject: splitpane nonbuffer change
|
1124
|
+
-----------------------------------
|
1125
|
+
Date: 2010-02-14 18:34
|
1126
|
+
|
1127
|
+
Due to removing buffers, now some methods that had relative coords such
|
1128
|
+
as hline and vline need absolute coordinate, by adding row and col
|
1129
|
+
respectively.
|
1130
|
+
|
1131
|
+
* * * * * * * *
|
1132
|
+
|
1133
|
+
Subject: giving up on splitpanes without buffers
|
1134
|
+
------------------------------------------------
|
1135
|
+
Date: 2010-02-15 00:17
|
1136
|
+
|
1137
|
+
Okay, i am not having fun with subwindows. Too much existing code it has
|
1138
|
+
to work with.
|
1139
|
+
|
1140
|
+
Not having buffers at all is tough, since one can easily print outside
|
1141
|
+
the widget while moving it. Especially the boundaries.
|
1142
|
+
|
1143
|
+
So i might have to just go back to the dreaded buffered version. Only
|
1144
|
+
problem is going back to that version that worked perfectly except for
|
1145
|
+
the one condition in which a scrollpane was inside a splitpane, and only
|
1146
|
+
the cursor was a tad off.
|
1147
|
+
|
1148
|
+
Have to find that version!
|
1149
|
+
|
1150
|
+
* * * * * * * *
|
1151
|
+
|
1152
|
+
Subject: changed to SplitPane (rfed16 version)
|
1153
|
+
----------------------------------------------
|
1154
|
+
Date: 2010-02-16 09:27
|
1155
|
+
|
1156
|
+
Currently, Splitpane was in a sorry state meaning mostly the values
|
1157
|
+
passed by higher functions for locating both the comps and their cursor
|
1158
|
+
values. Parameters passed were based on how things were working inside
|
1159
|
+
and it made no sense.
|
1160
|
+
|
1161
|
+
I've tried to make the parameters logical and sensible, and the inside
|
1162
|
+
functioning should work with those parameters rather than the other way
|
1163
|
+
round.
|
1164
|
+
|
1165
|
+
Similarly, width and height should also make sense in all cases.
|
1166
|
+
Somewhere values of row and col were relative, some places absolute.
|
1167
|
+
|
1168
|
+
Now in setrowcol of widget, i do not add ext_offsets. programs can add
|
1169
|
+
it.
|
1170
|
+
|
1171
|
+
RULE: All widgets should maintain absolute coordinates for row and col, even
|
1172
|
+
for internal objects. It is upto the Pad to remove @top and @left.
|
1173
|
+
|
1174
|
+
* * * * * * * *
|
1175
|
+
|
1176
|
+
Subject: changing width and height
|
1177
|
+
----------------------------------
|
1178
|
+
Date: 2010-02-16 20:49
|
1179
|
+
|
1180
|
+
Wherever an object changes its childs dimensions, it should now also
|
1181
|
+
call `set_buffering` to update `:bottom` and `:right` (or :top and :left),
|
1182
|
+
since we are now using `buffer_to_window` in `Widget` which takes explicit
|
1183
|
+
values from this hash.
|
1184
|
+
|
1185
|
+
Earlier, `Pad` picked up values from the pad, and otherwin and then tried
|
1186
|
+
to make sense of what to use. Thus coincidentally some things worked,
|
1187
|
+
some did not.
|
1188
|
+
|
1189
|
+
Now that our wrapper for `copywin` does no magic, callers are forced to
|
1190
|
+
pass correct values, which means there is complete clarity into waht is
|
1191
|
+
happening at the callers end, the rules for printing a widget in complex
|
1192
|
+
circumstances is becoming clear and less random or coincidental.
|
1193
|
+
|
1194
|
+
* * * * * * * *
|
1195
|
+
|
1196
|
+
Subject: cursor positioning
|
1197
|
+
---------------------------
|
1198
|
+
Date: 2010-02-17 00:25
|
1199
|
+
|
1200
|
+
I can't believe this. It seems I am not longer using ext_offsets any
|
1201
|
+
longer??
|
1202
|
+
I am setting the absolute coords of child components in scrollpane and
|
1203
|
+
splitpanes, which is kinda good, because its simple and no magic
|
1204
|
+
involved. No having 2 sets of coordinates around.
|
1205
|
+
|
1206
|
+
Also, it seems widgtes are using buffer_to_window, which also uses
|
1207
|
+
absolute coordinates for the screen.
|
1208
|
+
|
1209
|
+
Lastly, textview and textarea in set_form_row, don't use ext_offsets.
|
1210
|
+
They were earlier added in widget, later commented out to be added in
|
1211
|
+
indvidial programs. But everythings working without it, so i am free of
|
1212
|
+
one more hassle to look after.
|
1213
|
+
|
1214
|
+
* * * * * * * *
|
1215
|
+
|
1216
|
+
Subject: scrollpanes inside splitpanes
|
1217
|
+
--------------------------------------
|
1218
|
+
Date: 2010-02-17 10:14
|
1219
|
+
|
1220
|
+
The issue with placing a scrollpane a splitpane, esp in the second pane
|
1221
|
+
of a split.
|
1222
|
+
Currently, a SPLP sets its second components (C2's) row and col and
|
1223
|
+
other buffer parameters only after its divider has been set.
|
1224
|
+
Thus, when there is SPLP inside another SPLP, even the inner SPLP is
|
1225
|
+
able to inform its child of location when its divider is recomputed.
|
1226
|
+
|
1227
|
+
However, scrollpane informs its child of its location at the point of
|
1228
|
+
assignment. When the SCRP is the 2nd component in a SPLP, it doesn't yet
|
1229
|
+
have any row and col etc. When that is later updated, it currently has
|
1230
|
+
no means to update its child.
|
1231
|
+
|
1232
|
+
When SCRP's row and col are updated, or its set_buffering is called, it
|
1233
|
+
must further update the same for its child. Earlier that was not
|
1234
|
+
required since each pad was printing to a relative location.
|
1235
|
+
|
1236
|
+
* * * * * * * *
|
1237
|
+
|
1238
|
+
Subject: Now quite some success with splits and scrolls combined
|
1239
|
+
----------------------------------------------------------------
|
1240
|
+
Date: 2010-02-17 14:38
|
1241
|
+
|
1242
|
+
with testsplit3a.rb working (**rfed16** branch), resizing etc is working fine,
|
1243
|
+
finally splitpanes and scrollpanes are in decent shape.
|
1244
|
+
There are still some programs not displaying okay .. 3b 3_1 -- have to
|
1245
|
+
see what's there.
|
1246
|
+
|
1247
|
+
Were those 2 ever working ? or was it only a cursor issue in them that
|
1248
|
+
wrecked everything and made me abandon rbcurse19 branch. I wonder how
|
1249
|
+
that branch is doing.
|
1250
|
+
|
1251
|
+
I think i need to start git tagging. Anyway, i am also taking snapshots.
|
1252
|
+
I need to start releasing gems or atleast tgz's on github.
|
1253
|
+
|
1254
|
+
* * * * * * * *
|
1255
|
+
|
1256
|
+
Subject: broken status
|
1257
|
+
----------------------
|
1258
|
+
Date: 2010-02-17 22:23
|
1259
|
+
|
1260
|
+
Please note that consequent to the simplified buffering, and the way of
|
1261
|
+
calling it from containers the following are broken:
|
1262
|
+
|
1263
|
+
1. listbox (e.g. testscrolllb.rb, testsplit3b.rb)
|
1264
|
+
2. table
|
1265
|
+
3. tabbedpane (container) (e.g. testtpane.rb)
|
1266
|
+
|
1267
|
+
Any program calling buffer_to_screen for a child is broken. The child
|
1268
|
+
now does a buffer_to_window using absolute coordinates.
|
1269
|
+
|
1270
|
+
Containers such as SplitPane and ScrollPane are now passing absolute row
|
1271
|
+
and col to child, and updating exact top, left, bottom and right.
|
1272
|
+
|
1273
|
+
I don't think children should be using ext_col_offset or ext_row_offset.
|
1274
|
+
|
1275
|
+
* * * * * * * *
|
1276
|
+
|
1277
|
+
Subject: splitpane = cascade changes is on (rfed16 branch)
|
1278
|
+
----------------------------------------------------------
|
1279
|
+
Date: 2010-02-18 09:43
|
1280
|
+
|
1281
|
+
In RFED16, i've cut down on `Pad` usage, splitpanes and scrollpanes do not
|
1282
|
+
use pads themselves. Only the final object inserted in it such as a text
|
1283
|
+
are uses a Pad.
|
1284
|
+
|
1285
|
+
Thus there can be cropping issues when a splitpane or scrollpane writes
|
1286
|
+
outside the box. Thus, i switched on `cascade_changes` (which i had
|
1287
|
+
switched off). That's why there's no printing out of the boundary. That means
|
1288
|
+
that any change in the splitpane dimensions or resizing the split,
|
1289
|
+
causes the internal object to resize. Earlier they would not reduce,
|
1290
|
+
since cropping was happening.
|
1291
|
+
|
1292
|
+
Since there is no pad now, it is necessary that splitpane and scrollpane
|
1293
|
+
are never bigger than the splitpane they are on. I had earlier noted
|
1294
|
+
that `cascade_changes` defeats the purpose of a splitpane, however do not
|
1295
|
+
that the internal object is Pad based and can still exceed the
|
1296
|
+
`Splitpane` boundary.
|
1297
|
+
|
1298
|
+
Or rather. If you place a textarea in a splitpane, splitpane will resize
|
1299
|
+
the textarea (since `cascade_changes` in on). However, if you place a
|
1300
|
+
`Textarea` in a scrollpane, and the scrollpane inside a splitpane, then
|
1301
|
+
the `Textarea` is not resized. Only the object directly inside a splitpane
|
1302
|
+
is.
|
1303
|
+
|
1304
|
+
* * * * * * * *
|
1305
|
+
|
1306
|
+
Subject: More on splitpanes
|
1307
|
+
---------------------------
|
1308
|
+
Date: 2010-02-18 20:08
|
1309
|
+
|
1310
|
+
Great news. I've got sample testsplit3_1.rb working which is an example
|
1311
|
+
with 2 splitpanes inside an outer splitpane.
|
1312
|
+
This exposed an issue, that since the second component's (right or
|
1313
|
+
bottom) coordinates are determined not when attached but only when the
|
1314
|
+
divider is set, therefore its too late for it to coomunicate that to
|
1315
|
+
some inner components.
|
1316
|
+
|
1317
|
+
Basically, if your second component is something other than another
|
1318
|
+
Splitpane, its okay. However, in this example, the second is a SplitPane
|
1319
|
+
for the first time, and it seems to get its parameters a bit too late.
|
1320
|
+
|
1321
|
+
|
1322
|
+
So before it repaints the children i update the locations. This is
|
1323
|
+
required even for the first since the first could be the first of the
|
1324
|
+
second - lol. Otherwise, both components on the right were printing at
|
1325
|
+
0th column.
|
1326
|
+
|
1327
|
+
So there could be some more such missing cases, when i put the outer
|
1328
|
+
splitpane as horizontal. But hopefully earlier programs will not break
|
1329
|
+
since i am not touching existing paths.
|
1330
|
+
|
1331
|
+
I've still gotta fix TabbedPanes which are broken, I fixed Listboxes
|
1332
|
+
last night, but only lightly tested - surely there must be breaks
|
1333
|
+
somewhere.
|
1334
|
+
Also, gotta fix Tables. Things looking upbeat with the new "simpler
|
1335
|
+
approach" (see branch RFED16 of rbcurse).
|
1336
|
+
|
1337
|
+
* * * * * * * *
|
1338
|
+
|
1339
|
+
Subject: Fixed breakage in Table. Check testscrolltable.rb
|
1340
|
+
----------------------------------------------------------
|
1341
|
+
Date: 2010-02-19 12:32
|
1342
|
+
|
1343
|
+
Done the tiny changes to `Table`. Working now.
|
1344
|
+
Also, `Scrollpane` increases size of child if child is smaller.
|
1345
|
+
|
1346
|
+
Now to fix `TabbedPanes`, more work involved here since each situation has
|
1347
|
+
to be taken care of in terms of sizing of child. However, hopefully will
|
1348
|
+
be simpler than `Splitpane`.
|
1349
|
+
|
1350
|
+
* * * * * * * *
|
1351
|
+
|
1352
|
+
Subject: scrollpane relevance in terminal apps
|
1353
|
+
----------------------------------------------
|
1354
|
+
Date: 2010-02-22 20:38
|
1355
|
+
|
1356
|
+
Just wondering if scrollpanes have any meaning in a mouseless
|
1357
|
+
environment. The scrollbars have 3 functions:
|
1358
|
+
|
1359
|
+
1. used to drag down. But for that they have to get focus.
|
1360
|
+
I don't make scrollbars focussable since that puts focus on too many
|
1361
|
+
objects. I've seen demos of some curses toolkits that did, besides
|
1362
|
+
being very low quality and buggy, focus was going to too many objects,
|
1363
|
+
it was irritating.
|
1364
|
+
|
1365
|
+
2. show how much more of a document there is.
|
1366
|
+
|
1367
|
+
3. presence of scrollbars indicates to user that he can scroll
|
1368
|
+
vertically or horizontally.
|
1369
|
+
|
1370
|
+
In a mouseless environment, no focus to scrollbar. Keys are used to
|
1371
|
+
scroll. However, we still need to indicate to user that he can scroll.
|
1372
|
+
Also user may want to know percentage of screen.
|
1373
|
+
On a terminal, scrollpanes are taking valuable rows and cols due to
|
1374
|
+
boundary and bars.
|
1375
|
+
|
1376
|
+
Since scrollbars result in added complexity especially wrt placement and
|
1377
|
+
cursor location, can we do away with scrollpanes as a widget and have
|
1378
|
+
them added onto other widgets.
|
1379
|
+
They would just place themselves where the object allows, on the objects
|
1380
|
+
own border. That eliminates a lot of testing.
|
1381
|
+
|
1382
|
+
scrolling can be an option to widgets. they then include this
|
1383
|
+
capability. Needs to be thought out, since Scrollpanes result in insdie
|
1384
|
+
object creating a buffer.
|
1385
|
+
|
1386
|
+
* * * * * * * *
|
1387
|
+
|
1388
|
+
Subject: double key mapping like vim
|
1389
|
+
------------------------------------
|
1390
|
+
Date: 2010-02-24 15:17
|
1391
|
+
|
1392
|
+
The earlier Mapper than i had written was quite good, but integrating that to
|
1393
|
+
get multiple keys into rbcurse would have meant a lot of rework, and perhaps not have
|
1394
|
+
fitted in, with control going to multiple objects and heirarchies of
|
1395
|
+
objects, whereas Mapper takes over control.
|
1396
|
+
|
1397
|
+
So i've got a simple thing going, you can test out "gg" in any textview
|
1398
|
+
and it takes you to the start of the document.
|
1399
|
+
|
1400
|
+
Usually, we check for bindings after going through a case statement.
|
1401
|
+
This means if i've got a binding to "gg" on a listbox but listbox moves
|
1402
|
+
focus to first element with "g", my binding is never invoked.
|
1403
|
+
|
1404
|
+
One could do as follows:
|
1405
|
+
Make a call to process_key first, outside the case structure. If
|
1406
|
+
:UNHANDLED is returned, we go into case.
|
1407
|
+
|
1408
|
+
If the user presses, g once, but not a second time, return :UNHANDLED.
|
1409
|
+
if getch returns a -1, return UNHANDLED, not nil.
|
1410
|
+
|
1411
|
+
That way a double key binding can work, even with a single key binding.
|
1412
|
+
e.g. currently I have "jj" bound to ESC in Vim, but if i type any
|
1413
|
+
character other than j after a j or wait, then a j is typed.
|
1414
|
+
|
1415
|
+
So its a thought. In anycase, if the user wishes to override a binding,
|
1416
|
+
we should evaluate bindings first.
|
1417
|
+
|
1418
|
+
* * * * * * * *
|
1419
|
+
|
1420
|
+
Subject: regarding multiplier in embedded components
|
1421
|
+
----------------------------------------------------
|
1422
|
+
Date: 2010-02-26 13:40
|
1423
|
+
|
1424
|
+
When i have a textarea inside a scrollpane, and i do C-u, who gets the
|
1425
|
+
numeric argument of 4 or 16, the scrollpane or textarea. Currently,
|
1426
|
+
since the scrollpane passes the key to textarea, so textarea increments
|
1427
|
+
multiplier.
|
1428
|
+
Then i press scroll (M-n), but the scrollpanes multiplier is still
|
1429
|
+
unset.
|
1430
|
+
This means that we cannot have a multiplier at an object level -- it
|
1431
|
+
must be a global app level thing. Each object uses the global arguments
|
1432
|
+
and resets after usage.
|
1433
|
+
But where do i trap the C-u key ??
|
1434
|
+
|
1435
|
+
* * * * * * * *
|
1436
|
+
|
1437
|
+
Subject: Undo in text widgets
|
1438
|
+
-----------------------------
|
1439
|
+
Date: 2010-03-06 10:09
|
1440
|
+
|
1441
|
+
1. trap insert and delete events
|
1442
|
+
2. keep a list of
|
1443
|
+
* row
|
1444
|
+
* curpos
|
1445
|
+
* string/char added or deleted
|
1446
|
+
* action: ADD or DEL
|
1447
|
+
|
1448
|
+
@current_position in list
|
1449
|
+
|
1450
|
+
3. Undo() - moves up the list and does the opposite
|
1451
|
+
4. Redo() - moves down the list and does the same action
|
1452
|
+
|
1453
|
+
* * * * * * * *
|
1454
|
+
|
1455
|
+
Subject: entry of string
|
1456
|
+
------------------------
|
1457
|
+
Date: 2010-03-06 20:57
|
1458
|
+
|
1459
|
+
I've brought back entry of a string inside an application.
|
1460
|
+
Until now if one wanted to adhoc ask the user for a string (such as a
|
1461
|
+
search string), one used the dialogs. However, if one wishes to keep the
|
1462
|
+
"gui" to a minimum, `rbgetstr` (from module Io, io.rb) does the job.
|
1463
|
+
|
1464
|
+
It allows user to abort using `C-c`, or get specific help using `C-g`. Or
|
1465
|
+
use the arrow keys or backtab. However, i need to work in
|
1466
|
+
tab-completion, as well as perhaps history.
|
1467
|
+
|
1468
|
+
The main issue is coordinates to prompt. The widget often will not know
|
1469
|
+
where on the screen it should prompt. Dialog boxes solve this by opening
|
1470
|
+
their own window and then erasing it. Here to keep things simple, i just
|
1471
|
+
write on the form.window. The app should define the coordinates perhaps.
|
1472
|
+
|
1473
|
+
In the test, textview writes on its own lower border.
|
1474
|
+
|
1475
|
+
Perhaps, I'll bring back askyesno etc == for which currently the dialog
|
1476
|
+
box options exist.
|
1477
|
+
|
1478
|
+
* * * * * * * *
|
1479
|
+
|
1480
|
+
Subject: "most"-like menus
|
1481
|
+
--------------------------
|
1482
|
+
Date: 2010-03-06 21:03
|
1483
|
+
|
1484
|
+
For menu's we already have 2 ways:
|
1485
|
+
|
1486
|
+
1. a menu bar just like the **Links** browser with sub options, hotkeys, actions etc.
|
1487
|
+
To see this press F2 in test2.rb.
|
1488
|
+
|
1489
|
+
2. Popup-menus - Similar to the above, popup over a component to show
|
1490
|
+
its options. to see this, iirc the todo app example, if it still
|
1491
|
+
works.
|
1492
|
+
|
1493
|
+
3. "Pine"-like option labels at the bottom of the screen. Absolutely
|
1494
|
+
identical -- check the rfe.rb example. This is usually for options
|
1495
|
+
that stay around forever. One can always superimpose another set when
|
1496
|
+
one wants, as moving into a component. This menu shows what's
|
1497
|
+
available, so usually in a data entry app, only control and alt-keys
|
1498
|
+
would be shown.
|
1499
|
+
This is only a display, and does not take over control or focus. It's
|
1500
|
+
like having a cheat-sheet of key-bindings at the bottom of the
|
1501
|
+
screen.
|
1502
|
+
|
1503
|
+
4. I recently have been using most as a pager. It has a simple menu
|
1504
|
+
system available on pressing ":". I've copied it shamefully, so one
|
1505
|
+
can quickly set up multi-level menus with actions (procs or symbols)
|
1506
|
+
attached. The API may need work on. Since the location of this menu
|
1507
|
+
needs to be provided by application and not a widget. Currently,
|
1508
|
+
textview provides a location at 23,0.
|
1509
|
+
Unlike the pine-like labels, this prompts and takes control, so any
|
1510
|
+
letter can be defined per level.
|
1511
|
+
To see this, try any example with a textview and press "m" for menu.
|
1512
|
+
Try testsplit3.rb. I may change the mapping "m" shortly ?
|
1513
|
+
|
1514
|
+
So depending on the kind of application we have, we can choose the kind
|
1515
|
+
of menu system we want.
|
1516
|
+
|
1517
|
+
* * * * * * * *
|
1518
|
+
|
1519
|
+
Subject: undo facility - more on it
|
1520
|
+
-----------------------------------
|
1521
|
+
Date: 2010-03-08 18:09
|
1522
|
+
|
1523
|
+
currently the undo is independent of the textarea and uses the event
|
1524
|
+
object. however, it hardcodes access to the data structures of textarea.
|
1525
|
+
|
1526
|
+
Textarea should make an undo object and pass that. this object would
|
1527
|
+
have an undo and redo method which it has implemented. Also the object
|
1528
|
+
will maintain state of whether it can undo or redo. the undo object may
|
1529
|
+
have an array not just one value.
|
1530
|
+
|
1531
|
+
this way undo's can be clubbed. perhaps a block delete using a number
|
1532
|
+
can create an array of actions rather than separate actions. Hopefully,
|
1533
|
+
typing several chars can also be clubbed into one object to reduce
|
1534
|
+
memory.
|
1535
|
+
|
1536
|
+
* * * * * * * *
|
1537
|
+
|
1538
|
+
Subject: making rbcurse friendlier
|
1539
|
+
----------------------------------
|
1540
|
+
Date: 2010-08-26 19:45
|
1541
|
+
|
1542
|
+
I am wondering whether creating rbcurse widgets or apps requires too
|
1543
|
+
much boiler plate code.
|
1544
|
+
|
1545
|
+
Can I make it simpler. The problem i faced (coming from Java) was
|
1546
|
+
inability to have multiple constructors. So the user, and even I, don't
|
1547
|
+
know for sure what all a widget requires to run.
|
1548
|
+
|
1549
|
+
Can widget creation be made simpler.
|
1550
|
+
|
1551
|
+
I have an idea also for generating widgets and an app through a command
|
1552
|
+
line interface. Later i can also write a ncurses app in rbcurse that can
|
1553
|
+
generate apps. User can select and place widgets, he can see them as he
|
1554
|
+
creates them. He can move them around etc. Finally, he can generate the
|
1555
|
+
code for the widgets on screen.
|
1556
|
+
|
1557
|
+
* * * * * * * *
|
1558
|
+
|
1559
|
+
Subject: other screen patterns
|
1560
|
+
------------------------------
|
1561
|
+
Date: 2010-08-27 21:39
|
1562
|
+
|
1563
|
+
List entry view: Show a simple entry form directly above the total list of items
|
1564
|
+
http://welie.com/patterns/showPattern.php?patternID=list-entry-view
|
1565
|
+
|
1566
|
+
View: much like Hotmail.
|
1567
|
+
http://welie.com/patterns/showPattern.php?patternID=list-entry-view
|
1568
|
+
|
1569
|
+
Product Comparison: Sort of pivot table like, perhaps color columns
|
1570
|
+
http://welie.com/patterns/showPattern.php?patternID=comparison
|
1571
|
+
|
1572
|
+
Directory Navigation
|
1573
|
+
http://welie.com/patterns/showPattern.php?patternID=directory
|
1574
|
+
|
1575
|
+
http://welie.com/patterns/showPattern.php?patternID=doormat
|
1576
|
+
http://welie.com/patterns/showPattern.php?patternID=paging
|
1577
|
+
|
1578
|
+
* * * * * * * *
|
1579
|
+
|
1580
|
+
Subject: some fresh ideas for widgets
|
1581
|
+
-------------------------------------
|
1582
|
+
Date: 2010-08-27 21:45
|
1583
|
+
|
1584
|
+
I was glancing at this
|
1585
|
+
[article](http://designingwebinterfaces.com/designing-web-interfaces-12-screen-patterns)
|
1586
|
+
from reddit about Screen Patterns, and the 3 list widget was mentioned
|
1587
|
+
as Column Browse. Also Master Detail.
|
1588
|
+
|
1589
|
+
## Column Browse
|
1590
|
+
|
1591
|
+
So I think why not create widgets out of this so that users don't have
|
1592
|
+
to mess around with multiple SplitPanes to do this. (Note that the
|
1593
|
+
problem in multiple embedded SplitPanes is that the user does not know
|
1594
|
+
how to traverse to a specific one. In an environment with a mouse, user
|
1595
|
+
can click on some area. Here, if there's no mouse this becomes a
|
1596
|
+
problem.
|
1597
|
+
|
1598
|
+
If I create a widget with 2/3 lists, it will be easier to
|
1599
|
+
programmatically refer to them, and to traverse them.
|
1600
|
+
|
1601
|
+
## Spreadsheet widget
|
1602
|
+
|
1603
|
+
Someone also wrote to me about needing to write a Spreadsheet using
|
1604
|
+
ncurses. And the Table widget is close to that. It can be configured (or
|
1605
|
+
extended) to give quite a bit of functionality of a SS. However,
|
1606
|
+
everytime someone wishes to reuse a SS, he would have to copy the code
|
1607
|
+
-- if he has it.
|
1608
|
+
|
1609
|
+
So why not create a separate Spreadsheet class with just code for SS.
|
1610
|
+
|
1611
|
+
* * * * * * * *
|
1612
|
+
|
1613
|
+
Subject: another take on Vimsplit widget
|
1614
|
+
----------------------------------------
|
1615
|
+
Date: 2010-08-27 23:23
|
1616
|
+
|
1617
|
+
Remember the vimsplit widget. Lets do another take in which we keep one
|
1618
|
+
level of components only. Perhaps i can tile them in one orientation,
|
1619
|
+
and allow user to expand/contract -- should be easy since only one
|
1620
|
+
level. We can find some way to have multiple orientations.
|
1621
|
+
This will be easy to code for user, and also to modify
|
1622
|
+
programmatically at run time.
|
1623
|
+
|
1624
|
+
One can even take the MultiContainer and put a tiling feature in it.
|
1625
|
+
**Convert to tiles**.
|
1626
|
+
|
1627
|
+
Which makes me wonder, if i can use Multicontainer to rewrite
|
1628
|
+
TabbedPane ? Tabbedpane had become very complex. But oh wait, TabbedPane
|
1629
|
+
can have forms in it, which MC cannot have. That's where the complexity
|
1630
|
+
came in.
|
1631
|
+
|
1632
|
+
So in the new vimsplit, splitting while sitting on a split, will not
|
1633
|
+
create a child split, but only an outer split, but half the size of the
|
1634
|
+
current split, or share out the sizes. Traversal will be easy.
|
1635
|
+
|
1636
|
+
If we allow splits to be defined with abso coords then we can have
|
1637
|
+
complex splits. Or perhaps a way of giving preferred size, so it can
|
1638
|
+
expand fully in one direction.
|
1639
|
+
|
1640
|
+
* * * * * * * *
|
1641
|
+
|
1642
|
+
Subject: ffi-ncurses ?
|
1643
|
+
----------------------
|
1644
|
+
Date: 2010-08-30 12:37
|
1645
|
+
|
1646
|
+
there is some talk of ncurses installation which is hindering people
|
1647
|
+
from using rbcurse.
|
1648
|
+
|
1649
|
+
Perhaps we should try moving to ffi-ncurses after all. I heard it was
|
1650
|
+
slow. Is there some way of making it optional, whether a user wishes to
|
1651
|
+
use ffi or ruby-ncurses. For example, i read that mutt can be compiled
|
1652
|
+
for ncurses or slang.
|
1653
|
+
|
1654
|
+
* * * * * * * *
|
1655
|
+
|
1656
|
+
Subject: on_enter
|
1657
|
+
-----------------
|
1658
|
+
Date: 2010-09-02 12:12
|
1659
|
+
|
1660
|
+
i think Form calls `on_enter` of a widget and also fires its `:ENTER`.
|
1661
|
+
However, looking at the on_enter of some widget;s looks like they also
|
1662
|
+
fire :ENTER. So things could get fired 2 times.
|
1663
|
+
|
1664
|
+
* * * * * * * *
|
1665
|
+
|
1666
|
+
Subject: making rbcurse easier
|
1667
|
+
------------------------------
|
1668
|
+
Date: 2010-09-05 10:57
|
1669
|
+
|
1670
|
+
Currently making an application in rbcurse, requires a lot of boiler
|
1671
|
+
plate code. Various methods to be called to setup ... heck even I can't
|
1672
|
+
remember them!
|
1673
|
+
|
1674
|
+
I am trying out a wrapper for rbcurse. Much like a file.open block which
|
1675
|
+
does the dirty work of opening and closing a file while the user only
|
1676
|
+
supplies a block.
|
1677
|
+
|
1678
|
+
Then i need to make wrappers for fields and other widgets so they can be
|
1679
|
+
made easily. This way basic screens can be developed rather easily.
|
1680
|
+
|
1681
|
+
The wrapper is called app.rb and it currently resides in examples since
|
1682
|
+
it is very much in progress and trial. it will keep changing, so its
|
1683
|
+
going to remain in examples till it grows up. If you use it, rename it
|
1684
|
+
first, let me know of any improvements or fixes or changes or ideas.
|
1685
|
+
|
1686
|
+
* * * * * * * *
|
1687
|
+
|
1688
|
+
Subject: shoes changed
|
1689
|
+
----------------------
|
1690
|
+
Date: 2010-09-05 15:08
|
1691
|
+
|
1692
|
+
In rbcurse, we use the block to initialize... shoes uses the block as a
|
1693
|
+
changed action. Is that not better, since there is already a config for
|
1694
|
+
doing the setting. Why 2 ways of setting ?
|
1695
|
+
|
1696
|
+
Is it too late to change, or shall we go this way in the App wrapper.
|
1697
|
+
Internally we can bind to CHANGED. or should i have a changed method
|
1698
|
+
which does this.
|
1699
|
+
|
1700
|
+
* * * * * * * *
|
1701
|
+
|
1702
|
+
Subject: uniformity and less surprises
|
1703
|
+
--------------------------------------
|
1704
|
+
Date: 2010-09-07 20:17
|
1705
|
+
|
1706
|
+
we need more uniformity and less surprise. Let 'text' be the one method
|
1707
|
+
with 'def text' and 'def text =', in buttons rename text to label, so
|
1708
|
+
text can be the answer. Same for all widgets. getvalue and get_value etc
|
1709
|
+
sucks.
|
1710
|
+
If a Variable passed in take its value.
|
1711
|
+
thanks to the DSL approach there's this whole get_ set_ nonsense.
|
1712
|
+
|
1713
|
+
We need to move out the DSLish crap everywhere, even if that means a new
|
1714
|
+
major revision.
|
1715
|
+
|
1716
|
+
* * * * * * * *
|
1717
|
+
|
1718
|
+
Subject: testing of widgets
|
1719
|
+
---------------------------
|
1720
|
+
Date: 2010-09-19 10:59
|
1721
|
+
|
1722
|
+
If we keep the model separate, we can test the model out. Helps if the
|
1723
|
+
model is complex like a tree, but what if the model is an inbuilt one
|
1724
|
+
such as a list ?
|
1725
|
+
|
1726
|
+
If the widget keeps UI separate, which includes ncurses, then we can run
|
1727
|
+
tests on it from command line. However, widgets are instantiated with
|
1728
|
+
form and window.!!! How to do change this ?
|
1729
|
+
|
1730
|
+
|
1731
|
+
Can i create objects without passing a form ? and then call methods on
|
1732
|
+
it, like setting data, set_value, add etc. See that events are fired,
|
1733
|
+
exceptions are raised ?
|
1734
|
+
|
1735
|
+
actually even form is okay, but window printing is the issue. we need to
|
1736
|
+
prevent that, windowless form that handles keys sent by a program. but
|
1737
|
+
no ncurses loaded or displayed.
|
1738
|
+
|
1739
|
+
* * * * * * * *
|
1740
|
+
|
1741
|
+
Subject: temporarily leaving ncurses
|
1742
|
+
------------------------------------
|
1743
|
+
Date: 2010-09-20 13:23
|
1744
|
+
|
1745
|
+
If i want to run some command, temporarily leave ncurses using
|
1746
|
+
def_prog_mode do stuff and then return. SEE:
|
1747
|
+
http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/misc.html#TEMPLEAVE
|
1748
|
+
|
1749
|
+
I think vim does this when you type :ls . One can use this to display
|
1750
|
+
bindings, events etc.
|
1751
|
+
|
1752
|
+
* * * * * * * *
|
1753
|
+
|
1754
|
+
Subject: repainting of containers
|
1755
|
+
---------------------------------
|
1756
|
+
Date: 2010-09-22 18:15
|
1757
|
+
|
1758
|
+
Seem to be screwing this up. Either I am painting all in repaint which
|
1759
|
+
is not good. Yet, i do not know which are updated. Perhaps one component
|
1760
|
+
has been externally updated, and the container does not know. So its
|
1761
|
+
repaint required is still false.
|
1762
|
+
|
1763
|
+
So ... if `repaint_required` is true, it should repaint the borders, the
|
1764
|
+
components, resize etc.
|
1765
|
+
|
1766
|
+
If `repaint_required` is *false*, it still must call `repaint()` on all
|
1767
|
+
components, which will repaint if they have been modified. I've done
|
1768
|
+
this in rvimsplit.
|
1769
|
+
|
1770
|
+
* * * * * * * *
|
1771
|
+
|
1772
|
+
Subject: Listbox and CellRenderer
|
1773
|
+
---------------------------------
|
1774
|
+
Date: 2010-09-23 22:25
|
1775
|
+
|
1776
|
+
Often what is displayed in a listbox is quite different from the data in
|
1777
|
+
the list provided. Such as filenames in the list, but a long list is
|
1778
|
+
dislpayed.
|
1779
|
+
There are several ways to handle this.
|
1780
|
+
I am not addressing obvious performance vs memory issues here. Only
|
1781
|
+
implementation issues and their diffculties wrt display and app
|
1782
|
+
programming.
|
1783
|
+
|
1784
|
+
1. Keep file names in list. But use the cell renderer to show complete
|
1785
|
+
info. The repaint method truncates and treats the values from list,
|
1786
|
+
so scrolling can't happen. The main program has a false idea of line
|
1787
|
+
length. So cell renderers should only be used for format or color the
|
1788
|
+
data, changes in length etc should not happen. Else we will have to
|
1789
|
+
rewrite repaint and do length and scolling in renderer.
|
1790
|
+
|
1791
|
+
2. Keep the formatted data in the list. This makes it difficult to do
|
1792
|
+
work on firing the list. We don't have the filenames. We would have
|
1793
|
+
to maintain a backing store. There are additional issues such as if
|
1794
|
+
we are updating a list, the value shown will be the entire formatted
|
1795
|
+
line, and that will be updated into the formatted list.
|
1796
|
+
|
1797
|
+
3. So now we use `convert_value_to_text` to format the data, so scrolling
|
1798
|
+
can happen. Cellrenderer just does coloring based on select focus etc
|
1799
|
+
which was the original purpose. But since the formatted data is not
|
1800
|
+
in the list, movement methods like end of line, forward word don't
|
1801
|
+
work correctly since they consider the original data not the
|
1802
|
+
formatted data.
|
1803
|
+
|
1804
|
+
Currently, Listbox does not have a separation of methods that act on
|
1805
|
+
displayed data and actual (model) data. It assumes one list.
|
1806
|
+
Listbox already is complicated enough with all the editing.
|
1807
|
+
|
1808
|
+
I've gone back and forth with moving the formatting in and out of hte
|
1809
|
+
list, (in appdirtree and directorylist.rb) and i am doing no more. My
|
1810
|
+
suggestion is. ... perhaps you should put formatted data into the list
|
1811
|
+
itself. Have a backing store of the real data (that's what crow and
|
1812
|
+
row_index are for). However, in some case, you will have to face the
|
1813
|
+
difference between the 2 when updating only the model value.
|
1814
|
+
|
1815
|
+
|
1816
|
+
Some of hte performance considerations. If you have very long lists but
|
1817
|
+
only little of the data is seen by user the creating formatted date for
|
1818
|
+
all rows can be wasteful. Cellrenderer and convert_value_to_text only
|
1819
|
+
work on the rows beign displayed. However, they will keep working on the
|
1820
|
+
rows if you keep viewing them over and over. No cacheing etc.
|
1821
|
+
If you put formatted data in the list, there would be no repeated
|
1822
|
+
formatting. In the directory lister demo, there is no cacheing of file
|
1823
|
+
stat objects. Since the speed is fine, i did not bother to do any
|
1824
|
+
cacheing.
|
1825
|
+
|
1826
|
+
One option is to maintain a cache of only those objects on screen.
|
1827
|
+
Populate the cache in the convert_value_to_text loop. Or in
|
1828
|
+
cell_renderer. Clear it every time you get a row_index of 0 and start
|
1829
|
+
over.
|
1830
|
+
This way all operations that require movement over formatted data can
|
1831
|
+
use that cache.
|
1832
|
+
|
1833
|
+
* * * * * * * *
|
1834
|
+
|
1835
|
+
Subject: grabbars and scrollbar focusing
|
1836
|
+
----------------------------------------
|
1837
|
+
Date: 2010-10-07 11:49
|
1838
|
+
|
1839
|
+
|
1840
|
+
|
1841
|
+
* * * * * * * *
|
1842
|
+
|
1843
|
+
Subject: grabbar and scrollbar focusing
|
1844
|
+
---------------------------------------
|
1845
|
+
Date: 2010-10-07 11:49
|
1846
|
+
|
1847
|
+
Some objects like grabbars should not be in the way. they should be
|
1848
|
+
`focusable` on some key, or condition. I am thinking of Alt-Tab.
|
1849
|
+
Should there be some extra attrib for such since focusable will be
|
1850
|
+
false.
|
1851
|
+
|
1852
|
+
I could register such objects with a `FocusManager` array. Upon pressing some
|
1853
|
+
key (say F2), it cycles through these and makes then focusable. Works as
|
1854
|
+
a toggle.
|
1855
|
+
Or on pressing F2, it goes to next object in its array. So it will cycle
|
1856
|
+
between these objects directly setting focus to them. So they will never
|
1857
|
+
come in the TAB order.
|
1858
|
+
|
1859
|
+
This means i don't have to make a parallel `select_next_field` for such
|
1860
|
+
objects since they will have focusable true.
|
1861
|
+
|
1862
|
+
* * * * * * * *
|
1863
|
+
|
1864
|
+
Subject: grabbars and other strange things
|
1865
|
+
------------------------------------------
|
1866
|
+
Date: 2010-10-08 18:25
|
1867
|
+
|
1868
|
+
I've added these grabbars (dividers) for forms that have many panes. These are
|
1869
|
+
borders (much like a scrollbar) that allow user to drag them left right
|
1870
|
+
or up down and re-size panes. Currently, the alternative has been to use
|
1871
|
+
keys such as C-w - and +, which may not be obvious.
|
1872
|
+
|
1873
|
+
However, we don't want these dividers to take focus each time a user
|
1874
|
+
traverses the form. Thus, dividers are not focusable by default. But we
|
1875
|
+
add them to a module FocusManager. When F3 is pressed, the FocusManager
|
1876
|
+
toggles these dividers (or whatever it has in its list), to focusable.
|
1877
|
+
Now the user can tab into these dividers. Once the user is done, he may
|
1878
|
+
press F3 again and make them non-focusable. FocusManager can be used for
|
1879
|
+
amy objects that should only be focusable when user wants them. I may
|
1880
|
+
make scrollbars focusable in a future version.
|
1881
|
+
|
1882
|
+
* * * * * * * *
|
1883
|
+
|
1884
|
+
Subject: stacks and flows - thoughts
|
1885
|
+
------------------------------------
|
1886
|
+
Date: 2010-10-17 22:40
|
1887
|
+
|
1888
|
+
It should be possible to maintain stacks and flows within the app class.
|
1889
|
+
this way, the app can be asked to reposition the widgets and it can do
|
1890
|
+
so. This is required for when we get into using KEY_RESIZE (window
|
1891
|
+
resizing). So this will only be available within App, but then that's
|
1892
|
+
where stacks and flows are, anyway.
|
1893
|
+
Can we liberate S and F from App and make them independent ?
|
1894
|
+
|
1895
|
+
* * * * * * * *
|
1896
|
+
|
1897
|
+
Subject: color_pair added to widget
|
1898
|
+
-----------------------------------
|
1899
|
+
Date: 2010-10-18 23:04
|
1900
|
+
|
1901
|
+
Now we may directly pass a color_pair to a widget when creating. This
|
1902
|
+
way we can create one color_pair and pass it to multiple widgets, rather
|
1903
|
+
than passing actual colors to each. Also, this is a tad more efficient
|
1904
|
+
since the color won't be calculated each time a repaint is done.
|
1905
|
+
|
1906
|
+
* * * * * * * *
|
1907
|
+
|
1908
|
+
Subject: Usage of preferred_size
|
1909
|
+
--------------------------------
|
1910
|
+
Date: 2010-10-20 13:02
|
1911
|
+
|
1912
|
+
when the user may resize a component, or columns in a components, or
|
1913
|
+
user may specify widths or heights, we should use a `preferred_width`
|
1914
|
+
field.
|
1915
|
+
When we calculate width, use `preferred_width` if present, else calculate
|
1916
|
+
it. Program never updates `preferred_width`.
|
1917
|
+
|
1918
|
+
However, the question is what when a user resizes a component or
|
1919
|
+
sub-component. We want to respect that and not overwrite. So currently,
|
1920
|
+
i suggest that we update preferred_width on resizing, dragging etc. This
|
1921
|
+
does mean that the original specified width is lost, so a
|
1922
|
+
`reset_to_preferred_sizes` is not possible.
|
1923
|
+
|
1924
|
+
* * * * * * * *
|
1925
|
+
|
1926
|
+
Subject: single and multiple selection and keys
|
1927
|
+
-----------------------------------------------
|
1928
|
+
Date: 2010-10-28 23:07
|
1929
|
+
|
1930
|
+
If single selection (by spacebar) then pressing spacebar and pressing
|
1931
|
+
Enter should typically have same action. i.e. select current row and
|
1932
|
+
fire_event.(*)
|
1933
|
+
|
1934
|
+
If multiple selection, then Enter typically fires an action for current
|
1935
|
+
row such as opening an item or giving more details for that item.
|
1936
|
+
Spacebar selects multiple items (or Ctrl-Spacebar), and other keys will
|
1937
|
+
execute some action on selected rows (like delete, flag, move etc).
|
1938
|
+
|
1939
|
+
(*) Exceptions: in tree, Enter collapses or expands, and selects current
|
1940
|
+
row, whereas spacebar only selects and displays in other window.
|
1941
|
+
Spacebar does not expand or collapse tree node.
|
1942
|
+
|
1943
|
+
Typically in multiple select, spacebar selects first row (deselecting
|
1944
|
+
others) and Ctrl-Spacebar continues selection. Have to check this out
|
1945
|
+
with Listbox. including `ListSelectable` should take care of most of this.
|
1946
|
+
|
1947
|
+
* * * * * * * *
|
1948
|
+
|
1949
|
+
Subject: rmessagewindow
|
1950
|
+
-----------------------
|
1951
|
+
Date: 2010-11-04 12:23
|
1952
|
+
|
1953
|
+
Regarding bottomline and rmessagewindow
|
1954
|
+
|
1955
|
+
I was thinking that if i try to do bottomline in a separate window that
|
1956
|
+
just pops up and goes off, then i don't have to worry about having a
|
1957
|
+
window handle (since a new window is created with each call). I tried
|
1958
|
+
out this approach with rmessagewindow.
|
1959
|
+
|
1960
|
+
However, first of all one has to press a key to make the message go off.
|
1961
|
+
Secondly, when the window goes off, so does the message. Whatever was
|
1962
|
+
there before remains. Which is great if that's what you need. (But we
|
1963
|
+
already have alert() and rdialog for that).
|
1964
|
+
|
1965
|
+
This is fine for accepting input at screen bottom, but after ask() we
|
1966
|
+
still want to display some message like "file written" and let it be
|
1967
|
+
there. Which means i still have to write to existing window, so my
|
1968
|
+
problem remains. I need to have handle of existing window.
|
1969
|
+
|
1970
|
+
I've added a bottomline object in each window when we create so we can
|
1971
|
+
use it as `@window.ask`, `@window.agree`.
|
1972
|
+
|
1973
|
+
When you use App, you automatically get `ask()` connected to the root
|
1974
|
+
window, but what happens when one App calls another App!!
|
1975
|
+
|
1976
|
+
However, i really like how i can do a 'M-x' (taken from memacs), and
|
1977
|
+
then tab to see available commands. This way user does not need to
|
1978
|
+
remember key combinations.
|
1979
|
+
|
1980
|
+
* * * * * * * *
|
1981
|
+
|
1982
|
+
Subject: gmail style email completion
|
1983
|
+
-------------------------------------
|
1984
|
+
Date: 2010-11-20 13:26
|
1985
|
+
|
1986
|
+
I've just implemented some gmail style email completion.
|
1987
|
+
As you type in a field, values are shown in a window. You can key UP or
|
1988
|
+
DOWN, or keep typing. Pressing ENTER selects highilghted value. You can
|
1989
|
+
enter multiple emails in one field and get help on each.
|
1990
|
+
|
1991
|
+
However, in this case, the window is not modal, so the form below is
|
1992
|
+
painting itself. There are still some old widgets like Label and Field
|
1993
|
+
(perhaps button) that keep repainting redgarldess of whether changed.
|
1994
|
+
This overrides the non-modal window. I've just fixed field but putting a
|
1995
|
+
@repaint_required == true check in repaint.
|
1996
|
+
|
1997
|
+
Also, i think its possible, that rcommandwindow does a repaint and panel
|
1998
|
+
update more often than required. its called in different ways,
|
1999
|
+
interactive and non-interactive. Need to look into that at some time.
|
2000
|
+
|
2001
|
+
* * * * * * * *
|
2002
|
+
|
2003
|
+
Subject: calcurse
|
2004
|
+
-----------------
|
2005
|
+
Date: 2010-12-01 18:49
|
2006
|
+
|
2007
|
+
Just installed calcurse (port) and was checking the UI. Neat. Some salient
|
2008
|
+
points:
|
2009
|
+
|
2010
|
+
1. Windows or panels. Standard with title, title border, border color
|
2011
|
+
changes when focus in panel or box (that's because it keeps updating
|
2012
|
+
time and thereofre cursor remains on status bar)
|
2013
|
+
2. 2 bottom lines for keys like we have (keylabels)
|
2014
|
+
3. 3rd last row is a sort of status bar like emacs and vim have
|
2015
|
+
4. Data entry in last 2 rows. 2nd last has prompt, last has entry or
|
2016
|
+
edit
|
2017
|
+
5. Similarly menu options selected in last row. A page comes with
|
2018
|
+
options, letter indexed.
|
2019
|
+
6. Allows layout change of panels.
|
2020
|
+
7. Allows color change, immediate change. Displays colors rather than
|
2021
|
+
name. Color chooser for BG and FG.
|
2022
|
+
|
2023
|
+
Subject: App.rb confirm before quit
|
2024
|
+
-----------------------------------
|
2025
|
+
Date: 2011-09-17 11:49
|
2026
|
+
|
2027
|
+
App should be able to configure whether it wants quit-confirm. Or a
|
2028
|
+
procedure to call before quitting, such as saving values. It's okay for
|
2029
|
+
demos where there's no state to just press F1 or q or C-q to quit.
|
2030
|
+
|
2031
|
+
* * * * * * * *
|
2032
|
+
|
2033
|
+
Subject: porting to ffi-ncurses
|
2034
|
+
-------------------------------
|
2035
|
+
Date: 2011-09-17 11:51
|
2036
|
+
|
2037
|
+
I've been working on porting the rbcurse gem to ffi-ncurses, since
|
2038
|
+
ncurses gems is so so hard to install for a lot of people. Thanks to
|
2039
|
+
Sean's support the work and retesting was actually very little. It's
|
2040
|
+
just that there is a lot of testing to do with all the programs,
|
2041
|
+
widgets.
|
2042
|
+
|
2043
|
+
Sean is coming out with a version 0.4.0 which I am using. rbcurse 1.3.0
|
2044
|
+
onwards uses ffi-ncurses.
|
2045
|
+
|
2046
|
+
* * * * * * * *
|
2047
|
+
|
2048
|
+
Subject: color formatting
|
2049
|
+
-------------------------
|
2050
|
+
Date: 2011-11-03 15:03
|
2051
|
+
|
2052
|
+
Alot has happened since moving to ffi. New widgets and containers, a new
|
2053
|
+
tabbedpane that hopefully doesn't suck and is more rubyesque. However,
|
2054
|
+
its amazing how simple the color formatting issue was. Took me only a
|
2055
|
+
few minutes to get working with a good regular expression.
|
2056
|
+
|
2057
|
+
The motivation is to be able to have a document with color formatting. I
|
2058
|
+
am using the color formatting code of tmux, i.e., #[fg=green, bg=blue,
|
2059
|
+
bold] etc. However, I added an "#[end]" tag which pops the previous
|
2060
|
+
color, so now its more like html's span, than the terminal escape
|
2061
|
+
sequences which just override the previous.
|
2062
|
+
|
2063
|
+
I'll ofcourse use this in the statusline, in help screens, and also in
|
2064
|
+
some way in textview, and somehow even in messages, alerts, messageboxes
|
2065
|
+
etc. It's still rough, does no checking for mistakes and I don't have a
|
2066
|
+
routine to wrap text ignoring the color stuff. That will be needed soon.
|
2067
|
+
|
2068
|
+
* * * * * * * *
|
2069
|
+
|
2070
|
+
Subject: bifurcating into core and others
|
2071
|
+
-----------------------------------------
|
2072
|
+
Date: 2011-11-08 18:30
|
2073
|
+
|
2074
|
+
Perhaps it would be better to divide rbcurse into rbcurse-core and then
|
2075
|
+
other packages or gems.
|
2076
|
+
This way *core* can remain more or less frozen and bug fixes can be
|
2077
|
+
released quickly without waiting for other features to stabilize.
|
2078
|
+
|
2079
|
+
Changes in other packages can be made without disturbing core. Core can
|
2080
|
+
be kept backward compatible. And it can remain light with just form,
|
2081
|
+
window, field, buttons, list and perhaps textview.
|
2082
|
+
|
2083
|
+
Other widgets can be put in other gems. The entire extras, UI patterns,
|
2084
|
+
experimental work. There could be a *rbcurse-experimental* which moves to
|
2085
|
+
either core or standard as and when it stabilizes.
|
2086
|
+
|
2087
|
+
1. rbcurse-core - form, field, label, buttons, dialogs, basiclist, messagebox
|
2088
|
+
viewer, menus? , combo - basically whatever is required to run test2 and
|
2089
|
+
test1.rb. We must have a minimal number of programs to test for this.
|
2090
|
+
Actually, test2 incorporates a lot!
|
2091
|
+
|
2092
|
+
2. rbcurse-util
|
2093
|
+
menus?, textarea?, tabbedpane, tree
|
2094
|
+
tables, tabular, keylabel, progress, scrollbar, statusline,
|
2095
|
+
|
2096
|
+
3. rbcurse-extras
|
2097
|
+
vimsplit, multi-containers, masterdetail, directorylist etc
|
2098
|
+
statuswindow, rcommandwindow
|
2099
|
+
link, menulink, container
|
2100
|
+
|
2101
|
+
4. rbcurse-experimental
|
2102
|
+
resultset,
|
2103
|
+
Pad, subwin,derwin from window class, scrollform, app, stack/flow
|
2104
|
+
gmailfield
|
2105
|
+
|
2106
|
+
5. rbcurse-demos
|
2107
|
+
rfe, sqlc/m, dbdemo which can be installed and run from anywhere
|
2108
|
+
appemail
|
2109
|
+
This must be dependent on a specific version of core and util.
|
2110
|
+
|
2111
|
+
6. rbcurse-db
|
2112
|
+
database related work - resultsetview etc
|
2113
|
+
|
2114
|
+
* * * * * * * *
|
2115
|
+
Subject: textpad
|
2116
|
+
----------------
|
2117
|
+
Date: 2013-03-05 20:11
|
2118
|
+
|
2119
|
+
Moving to textpad usage
|
2120
|
+
This would simplify stuff since textview has to do a lot of work each
|
2121
|
+
time it displays, too much truncation of strings and all that, a lot of
|
2122
|
+
memory and gc happening.
|
2123
|
+
|
2124
|
+
Textpad is simpler, however there's one issue. ncurses does not see to
|
2125
|
+
do book-keeping of pads as it does of windows. When a popup or alert
|
2126
|
+
comes up from some part of the app, there's a black box left on the
|
2127
|
+
screen. padrefresh will take care of this, however, the box may cover
|
2128
|
+
not one but several pads, and we need to find all the pads and make them
|
2129
|
+
refresh themselves. until then have to postpone. the ffi-ncurses
|
2130
|
+
example also has a case where the underlyign frame is manuall repainted
|
2131
|
+
which sucks.
|
2132
|
+
|
2133
|
+
Window has the internal pads, not our textpad objects. So although it can delete
|
2134
|
+
pads it cannot do a padrefresh which is our textpad method.
|
2135
|
+
|
2136
|
+
* * * * * * * *
|
2137
|
+
|
2138
|
+
Subject: field history
|
2139
|
+
----------------------
|
2140
|
+
Date: 2013-03-06 14:27
|
2141
|
+
|
2142
|
+
I've added history to get_string. Wonder why it was not there.
|
2143
|
+
However, i think it should be a part of field, optional, since
|
2144
|
+
different fields should maintain their own history. Surely, I've done
|
2145
|
+
something on this, or thought it over.
|
2146
|
+
|
2147
|
+
Okay, Field can maintain its history if you extend FieldHistory, however if
|
2148
|
+
you use a field in a messagebox which is created over and over again, then we
|
2149
|
+
manually have to keep the history and pass it to the field when creating the messagebox.
|
2150
|
+
|
2151
|
+
* * * * * * * *
|