I got really weird error (invalid panel passed to top_panel) when there
was no such call, so I guess there was some memory corruption.
formatLine is the only suspect, but when I put in the guard, the error
wasn't reproduced (just scrolling through qwaq's makefile in a big
window).
With this, windows can be resized using any of the corners or the three
sides other than top (top side is move-only, otherwise moving a window
without resizing would be impossible).
It's a fairly high-level wrapper for TextBuffer in that it implements
file ops (load/save), searching, navigation, and formatting (simple
line-oriented with tab stops (currently at 4 spaces)).
While the key escape sequences are xterm-specific, they are only the
default and preliminary provision has been made for overriding them.
However, no override mechanism has been implemented beyond using dynamic
table lookup.
I'd left qwaq-curses running overnight and found it locked up: both
threads were looping because pthread_cond_timedwait was returning
EINVAL. Thus bail if anything other than 0 is returned, and try to
ensure tv_nsec is in the range 0..999999999
This doesn't fix the problem of lost events: that seems to be inside
ncurses. I've done some investigations, and it seems xterm sends
separate events for motion and pre/release (which have current coords),
in both 1003 and 1006 modes. No idea what ncurses is doing (does it even
handle 1003 properly?), and it requires the use of xterm-1006 for it to
use 1006 mode (which is nice in that it disambiguates button releases
and allows for huge terminals (not that I would use such normally)).
Guess I've got some side-work cut out for me :P
While writing the code I suspected this would be necessary, but it's
nice to know. Now the window seems to be correctly fetched, but
get_event locks up.
I realized that with dynamic thread creation the arrays resizing could
cause them to move around in memory which would be bad for anything
holding a pointer to the data, and even using indices wouldn't help that
much as the array would need to be mutex protected.
If none are specified, default to qwaq-app.dat (for now, anyway). For
each progs file, an optional args set can be specified in the same order
(separated by --). Missing sets default to empty, excess sets are
ignored.
The sets are separated by --, and the first set is passed to
getopt_long which currently recognizes only --qargs and non-options. The
--qargs options parses out a set (to -- or end of args) that is passed
to the qargs sub-system for standard qf command line parsing. Set 0 is
for the main qwaq application. Any additional sets (excluding --qargs)
will be used to spawn additional threads when that's working.
Other than the stray panel_free, that was surprisingly easy. However, do
need to check that the window can be moved otherwise window pos and
panel pos will get out of sync.
I think I've finally figured out what I want the core hierarchy to be.
Right now, it's just the two classes: View and Window (derived from
View). Window has a Group, and Group is just a collection of Views that
it manages. QwaqApplication is just an object but like a Window, it has
a Group of views.
View
Window has a Group
Group contains Views
QwaqApplication has a group
More work needs to be done on drawing and event handling, but things are
working again.
It doesn't work right now because View unconditionally sends refresh to
its textContext, but textContext can be a draw buffer which does not
respond to refresh. Still, these changes (notably the assignment chain
in qwaq-group.r really pushed qfcc).
This returns the character (as an int) at the index. Equivalent to
string[index], but qc code doesn't have char-level access and not having
it means that strings can internally change to wchar without too much
fuss (maybe).
refresh won't be in the drawing buffer protocol, and the move commands
need to be offset by the view's position in its window, but it works as
intended.
libr supplies an __obj_forward definition that links to a builtin, but
as it is the only def in its object file, it is readily replaceable by
an alternative Ruamoko implementation.
The builtin version currently simply errors out (rather facetiously),
but only as a stub to allow progs to load.
