qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-11-15 01:11:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/ruamoko/qwaq/builtins/curses.c

1963 lines
48 KiB
C
Raw Normal View History

Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
/*
[qwaq] Clean up the qwaq directory Things were getting rather cluttered with everything being qwaq-* and all in one directory. Now most have lost the qwaq- prefix and have been moved into subdirectories (non-recursive make).
2020-03-29 17:34:08 +00:00
curses.c
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
[qwaq] Make some improvements to mouse handling 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
2020-03-21 12:05:34 +00:00
Ruamoko ncurses wrapper using threading
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
[qwaq] Make some improvements to mouse handling 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
2020-03-21 12:05:34 +00:00
Copyright (C) 2020 Bill Currie <bill@taniwha.org>
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
[qwaq] Make some improvements to mouse handling 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
2020-03-21 12:05:34 +00:00
Author: Bill Currie <bill@taniwha.org>
Date: 2020/03/01
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
*/
#ifdef HAVE_CONFIG_H
# include "config.h"
#endif
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
#include <sys/time.h>
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
#include <curses.h>
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
#include <errno.h>
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
#include <panel.h>
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
#include <pthread.h>
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
#include <stdlib.h>
#include <string.h>
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
#include <unistd.h>
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
#include "QF/dstring.h"
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
#include "QF/progs.h"
Move the ring buffer macros to their own header They seem to have proven themselves to be robust.
2020-03-19 14:53:54 +00:00
#include "QF/ringbuffer.h"
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
#include "QF/sys.h"
[build] Move to non-recursive make There's still some cleanup to do, but everything seems to be working nicely: `make -j` works, `make distcheck` passes. There is probably plenty of bitrot in the package directories (RPM, debian), though. The vc project files have been removed since those versions are way out of date and quakeforge is pretty much dependent on gcc now anyway. Most of the old Makefile.am files are now Makemodule.am. This should allow for new Makefile.am files that allow local building (to be added on an as-needed bases). The current remaining Makefile.am files are for standalone sub-projects.a The installable bins are currently built in the top-level build directory. This may change if the clutter gets to be too much. While this does make a noticeable difference in build times, the main reason for the switch was to take care of the growing dependency issues: now it's possible to build tools for code generation (eg, using qfcc and ruamoko programs for code-gen).
2020-06-21 14:15:17 +00:00
#include "ruamoko/qwaq/qwaq.h"
#include "ruamoko/qwaq/ui/curses.h"
#include "ruamoko/qwaq/ui/rect.h"
#include "ruamoko/qwaq/ui/textcontext.h"
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
#define always_inline inline __attribute__((__always_inline__))
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
#define CMD_SIZE(x) sizeof(x)/sizeof(x[0])
typedef enum qwaq_commands_e {
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
qwaq_cmd_syncprint,
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
qwaq_cmd_newwin,
qwaq_cmd_delwin,
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
qwaq_cmd_getwrect,
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
qwaq_cmd_new_panel,
qwaq_cmd_del_panel,
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
qwaq_cmd_hide_panel,
qwaq_cmd_show_panel,
qwaq_cmd_top_panel,
qwaq_cmd_bottom_panel,
qwaq_cmd_move_panel,
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
qwaq_cmd_panel_window,
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
qwaq_cmd_replace_panel,
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
qwaq_cmd_update_panels,
qwaq_cmd_doupdate,
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
qwaq_cmd_mvwaddstr,
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
qwaq_cmd_waddstr,
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
qwaq_cmd_mvwaddch,
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
qwaq_cmd_waddch,
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
qwaq_cmd_wrefresh,
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
qwaq_cmd_init_pair,
qwaq_cmd_wbkgd,
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
qwaq_cmd_werase,
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
qwaq_cmd_scrollok,
[qwaq] Add wrapper for wmove
2021-06-07 06:53:35 +00:00
qwaq_cmd_wmove,
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
qwaq_cmd_move,
qwaq_cmd_curs_set,
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
qwaq_cmd_wborder,
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
qwaq_cmd_mvwblit_line,
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
qwaq_cmd_wresize,
qwaq_cmd_resizeterm,
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
qwaq_cmd_mvwhline,
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
qwaq_cmd_mvwvline,
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
} qwaq_commands;
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
static const char *qwaq_command_names[]= {
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
"syncprint",
[qwaq] Add debug output to the command queue Be sure to redirect stderr or the screen will get messed up
2020-03-05 15:30:11 +00:00
"newwin",
"delwin",
"getwrect",
"new_panel",
"del_panel",
"hide_panel",
"show_panel",
"top_panel",
"bottom_panel",
"move_panel",
"panel_window",
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
"replace_panel",
[qwaq] Add debug output to the command queue Be sure to redirect stderr or the screen will get messed up
2020-03-05 15:30:11 +00:00
"update_panels",
"doupdate",
"mvwaddstr",
"waddstr",
"mvwaddch",
[qwaq] Add missed command enum string
2020-03-08 13:20:46 +00:00
"waddch",
[qwaq] Add debug output to the command queue Be sure to redirect stderr or the screen will get messed up
2020-03-05 15:30:11 +00:00
"wrefresh",
"init_pair",
"wbkgd",
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
"werase",
[qwaq] Add debug output to the command queue Be sure to redirect stderr or the screen will get messed up
2020-03-05 15:30:11 +00:00
"scrollok",
[qwaq] Add wrapper for wmove
2021-06-07 06:53:35 +00:00
"wmove",
[qwaq] Add debug output to the command queue Be sure to redirect stderr or the screen will get messed up
2020-03-05 15:30:11 +00:00
"move",
"curs_set",
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
"wborder",
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
"mvwblit_line",
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
"wresize",
"resizeterm",
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
"mvwhline",
"mvwvline",
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
"send_connected_devices",
"get_device_info",
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
};
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static window_t *
window_new (qwaq_resources_t *res)
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
return PR_RESNEW (res->window_map);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
static void
window_free (qwaq_resources_t *res, window_t *win)
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
PR_RESFREE (res->window_map, win);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
window_reset (qwaq_resources_t *res)
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
PR_RESRESET (res->window_map);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
static inline window_t *
window_get (qwaq_resources_t *res, unsigned index)
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
return PR_RESGET(res->window_map, index);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[build] Fix a pile of gcc 10 issues gcc got stricter about array accesses, complicating progs macros, and much better at detecting buffer overflows.
2020-12-20 17:12:51 +00:00
static inline int __attribute__((pure))
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
window_index (qwaq_resources_t *res, window_t *win)
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
return PR_RESINDEX (res->window_map, win);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[qwaq] Create some ring-buffer macros I expect I will need several messaging buffers, and ring buffers tend to be quite robust. Replacing the event buffer code with the macros made testing easy.
2020-02-28 13:27:29 +00:00
static always_inline window_t * __attribute__((pure))
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
get_window (qwaq_resources_t *res, const char *name, int handle)
{
[qwaq] Make stdscr available to progs
2020-02-29 05:38:54 +00:00
if (handle == 1) {
return &res->stdscr;
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
window_t *window = window_get (res, handle);
if (!window || !window->win) {
[qwaq] Correct mangled params to qwaq_mvwvprintf
2020-03-26 00:07:19 +00:00
PR_RunError (res->pr, "invalid window %d passed to %s",
handle, name + 5);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
return window;
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static panel_t *
panel_new (qwaq_resources_t *res)
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
return PR_RESNEW (res->panel_map);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
static void
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
panel_free (qwaq_resources_t *res, panel_t *win)
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
PR_RESFREE (res->panel_map, win);
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
panel_reset (qwaq_resources_t *res)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
PR_RESRESET (res->panel_map);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static inline panel_t *
panel_get (qwaq_resources_t *res, unsigned index)
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
return PR_RESGET(res->panel_map, index);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[build] Fix a pile of gcc 10 issues gcc got stricter about array accesses, complicating progs macros, and much better at detecting buffer overflows.
2020-12-20 17:12:51 +00:00
static inline int __attribute__((pure))
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
panel_index (qwaq_resources_t *res, panel_t *win)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[gamecode] Make PR_RESMAP macros more function-like I never liked that some of the macros needed the type as a parameter (yay typeof and __auto_type) or those that returned a value hid the return statement so they couldn't be used in assignments.
2021-03-21 12:26:36 +00:00
return PR_RESINDEX (res->panel_map, win);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
static always_inline panel_t * __attribute__((pure))
get_panel (qwaq_resources_t *res, const char *name, int handle)
{
panel_t *panel = panel_get (res, handle);
if (!panel || !panel->panel) {
PR_RunError (res->pr, "invalid panel passed to %s", name + 3);
}
return panel;
}
static int
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_cmd_peek (qwaq_resources_t *res, int ahead)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
return *RB_PEEK_DATA (res->commands.pipe, ahead);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
static dstring_t *
qwaq_cmd_string (qwaq_resources_t *res, int string_id)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
return res->commands.strings + string_id;
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
static void
cmd_syncprint (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int string_id = qwaq_cmd_peek (res, 2);
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
Sys_Printf ("%s\n", qwaq_cmd_string (res, string_id)->str);
qwaq_pipe_release_string (&res->commands, string_id);
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_newwin (qwaq_resources_t *res)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int xpos = qwaq_cmd_peek (res, 2);
int ypos = qwaq_cmd_peek (res, 3);
int xlen = qwaq_cmd_peek (res, 4);
int ylen = qwaq_cmd_peek (res, 5);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
window_t *window = window_new (res);
window->win = newwin (ylen, xlen, ypos, xpos);
[qwaq] Bypass ncurses for input handling For now, only 1003 mouse mode is supported, and function keys are not yet supported, but the mouse is much more reliable: no lost events.
2020-03-21 16:00:05 +00:00
keypad (window->win, FALSE); // do it ourselves
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
int window_id = window_index (res, window);
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int cmd_result[] = { qwaq_cmd_newwin, window_id };
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->results, cmd_result, CMD_SIZE (cmd_result));
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_delwin (qwaq_resources_t *res)
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
delwin (window->win);
window_free (res, window);
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
cmd_getwrect (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
int xpos, ypos;
int xlen, ylen;
window_t *window = get_window (res, __FUNCTION__, window_id);
getparyx (window->win, ypos, xpos);
if (xpos == -1 && ypos ==-1) {
getbegyx (window->win, ypos, xpos);
}
getmaxyx (window->win, ylen, xlen);
int cmd_result[] = { qwaq_cmd_getwrect, xpos, ypos, xlen, ylen };
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->results, cmd_result, CMD_SIZE (cmd_result));
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
}
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_new_panel (qwaq_resources_t *res)
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
panel_t *panel = panel_new (res);
panel->panel = new_panel (window->win);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
panel->window_id = window_id;
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
int panel_id = panel_index (res, panel);
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int cmd_result[] = { qwaq_cmd_new_panel, panel_id };
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->results, cmd_result, CMD_SIZE (cmd_result));
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
}
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_del_panel (qwaq_resources_t *res)
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int panel_id = qwaq_cmd_peek (res, 2);
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
del_panel (panel->panel);
panel_free (res, panel);
}
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
static void
cmd_hide_panel (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int panel_id = qwaq_cmd_peek (res, 2);
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
hide_panel (panel->panel);
}
static void
cmd_show_panel (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int panel_id = qwaq_cmd_peek (res, 2);
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
show_panel (panel->panel);
}
static void
cmd_top_panel (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int panel_id = qwaq_cmd_peek (res, 2);
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
top_panel (panel->panel);
}
static void
cmd_bottom_panel (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int panel_id = qwaq_cmd_peek (res, 2);
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
bottom_panel (panel->panel);
}
static void
cmd_move_panel (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int panel_id = qwaq_cmd_peek (res, 2);
int x = qwaq_cmd_peek (res, 3);
int y = qwaq_cmd_peek (res, 4);
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
move_panel (panel->panel, y, x);
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
cmd_panel_window (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int panel_id = qwaq_cmd_peek (res, 2);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
int window_id = panel->window_id;
int cmd_result[] = { qwaq_cmd_panel_window, window_id, };
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->results, cmd_result, CMD_SIZE (cmd_result));
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
}
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
static void
cmd_replace_panel (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int panel_id = qwaq_cmd_peek (res, 2);
int window_id = qwaq_cmd_peek (res, 3);
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
panel_t *panel = get_panel (res, __FUNCTION__, panel_id);
window_t *window = get_window (res, __FUNCTION__, window_id);
replace_panel (panel->panel, window->win);
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
cmd_update_panels (qwaq_resources_t *res)
{
update_panels ();
}
static void
cmd_doupdate (qwaq_resources_t *res)
{
doupdate ();
}
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
static void
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
cmd_mvwaddstr (qwaq_resources_t *res)
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int x = qwaq_cmd_peek (res, 3);
int y = qwaq_cmd_peek (res, 4);
int string_id = qwaq_cmd_peek (res, 5);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
mvwaddstr (window->win, y, x, qwaq_cmd_string (res, string_id)->str);
qwaq_pipe_release_string (&res->commands, string_id);
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
cmd_waddstr (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int string_id = qwaq_cmd_peek (res, 3);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
waddstr (window->win, qwaq_cmd_string (res, string_id)->str);
qwaq_pipe_release_string (&res->commands, string_id);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
}
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
static void
cmd_mvwaddch (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int x = qwaq_cmd_peek (res, 3);
int y = qwaq_cmd_peek (res, 4);
int ch = qwaq_cmd_peek (res, 5);
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
mvwaddch (window->win, y, x, ch);
}
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
static void
cmd_waddch (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int ch = qwaq_cmd_peek (res, 3);
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
waddch (window->win, ch);
}
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
static void
cmd_wrefresh (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
[qwaq] Read mouse movements Many thanks to https://gist.github.com/sylt/93d3f7b77e7f3a881603 for the necessary escape sequence to get xterm reporting mouse movement events.
2020-02-27 12:22:10 +00:00
wrefresh (window->win);
}
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
static void
cmd_init_pair (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int pair = qwaq_cmd_peek (res, 2);
int f = qwaq_cmd_peek (res, 3);
int b = qwaq_cmd_peek (res, 4);
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
init_pair (pair, f, b);
}
static void
cmd_wbkgd (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int ch = qwaq_cmd_peek (res, 3);
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
wbkgd (window->win, ch);
}
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
static void
cmd_werase (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
werase (window->win);
}
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
static void
cmd_scrollok (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int flag = qwaq_cmd_peek (res, 3);
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
scrollok (window->win, flag);
}
[qwaq] Add wrapper for wmove
2021-06-07 06:53:35 +00:00
static void
cmd_wmove (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int x = qwaq_cmd_peek (res, 3);
int y = qwaq_cmd_peek (res, 4);
[qwaq] Add wrapper for wmove
2021-06-07 06:53:35 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
wmove (window->win, y, x);
}
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
static void
cmd_move (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int x = qwaq_cmd_peek (res, 2);
int y = qwaq_cmd_peek (res, 3);
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
move (y, x);
}
static void
cmd_curs_set (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int visibility = qwaq_cmd_peek (res, 2);
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
curs_set (visibility);
}
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
static void
cmd_wborder (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int ls = qwaq_cmd_peek (res, 3);
int rs = qwaq_cmd_peek (res, 4);
int ts = qwaq_cmd_peek (res, 5);
int bs = qwaq_cmd_peek (res, 6);
int tl = qwaq_cmd_peek (res, 7);
int tr = qwaq_cmd_peek (res, 8);
int bl = qwaq_cmd_peek (res, 9);
int br = qwaq_cmd_peek (res, 10);
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
wborder (window->win, ls, rs, ts, bs, tl, tr, bl, br);
}
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
static void
cmd_mvwblit_line (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int x = qwaq_cmd_peek (res, 3);
int y = qwaq_cmd_peek (res, 4);
int chs_id = qwaq_cmd_peek (res, 5);
int len = qwaq_cmd_peek (res, 6);
int *chs = (int *) qwaq_cmd_string (res, chs_id)->str;
[qwaq] Get DrawBuffer and TextContext working Especially blitting whole regions. Partial regions not tested yet.
2020-03-12 17:09:55 +00:00
int save_x;
int save_y;
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
[qwaq] Get DrawBuffer and TextContext working Especially blitting whole regions. Partial regions not tested yet.
2020-03-12 17:09:55 +00:00
getyx (window->win, save_y, save_x);
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
for (int i = 0; i < len; i++) {
[qwaq] Treat 0 as transparent character
2020-03-19 10:53:32 +00:00
if (chs[i] & 0xff) {
mvwaddch (window->win, y, x + i, chs[i]);
}
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
}
[qwaq] Get DrawBuffer and TextContext working Especially blitting whole regions. Partial regions not tested yet.
2020-03-12 17:09:55 +00:00
wmove (window->win, save_y, save_x);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_release_string (&res->commands, chs_id);
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
}
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
static void
cmd_wresize (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int width = qwaq_cmd_peek (res, 3);
int height = qwaq_cmd_peek (res, 4);
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
wresize (window->win, height, width);
}
static void
cmd_resizeterm (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int width = qwaq_cmd_peek (res, 2);
int height = qwaq_cmd_peek (res, 3);
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
resizeterm (height, width);
}
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
static void
cmd_mvwhline (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int x = qwaq_cmd_peek (res, 3);
int y = qwaq_cmd_peek (res, 4);
int ch = qwaq_cmd_peek (res, 5);
int n = qwaq_cmd_peek (res, 6);
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
mvwhline (window->win, y, x, ch, n);
}
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
static void
cmd_mvwvline (qwaq_resources_t *res)
{
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int window_id = qwaq_cmd_peek (res, 2);
int x = qwaq_cmd_peek (res, 3);
int y = qwaq_cmd_peek (res, 4);
int ch = qwaq_cmd_peek (res, 5);
int n = qwaq_cmd_peek (res, 6);
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
window_t *window = get_window (res, __FUNCTION__, window_id);
mvwvline (window->win, y, x, ch, n);
}
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
static void
dump_command (qwaq_resources_t *res, int len)
{
[qwaq] Implement more debugger def views Structs and arrays now work (though could be better, eg collapsible).
2021-09-24 16:42:36 +00:00
if (0) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_commands cmd = qwaq_cmd_peek (res, 0);
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
Sys_Printf ("%s[%d]", qwaq_command_names[cmd], len);
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
if (cmd == qwaq_cmd_syncprint) {
Sys_Printf (" ");
} else {
for (int i = 2; i < len; i++) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
Sys_Printf (" %d", qwaq_cmd_peek (res, i));
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
}
Sys_Printf ("\n");
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
}
}
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
process_commands (qwaq_resources_t *res)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
struct timespec timeout;
int avail;
int len;
int ret = 0;
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
pthread_mutex_lock (&res->commands.pipe_cond.mut);
[qwaq] Bypass ncurses for input handling For now, only 1003 mouse mode is supported, and function keys are not yet supported, but the mouse is much more reliable: no lost events.
2020-03-21 16:00:05 +00:00
qwaq_init_timeout (&timeout, 20 * 1000000);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
while (RB_DATA_AVAILABLE (res->commands.pipe) < 2 && ret == 0) {
ret = pthread_cond_timedwait (&res->commands.pipe_cond.rcond,
&res->commands.pipe_cond.mut, &timeout);
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
}
[qwaq] Close up race-condition hole After a lot of thought, I have come to the conclusion that the weird crash the other day was caused by a race while the command ring buffer had just been emptied: the command submission code opened up space for writing, threads switched, and command processing saw the available data and pounced on it before the submit code could write valid data. Thus include the while header in the lock, and move the loop-end release outside the lock. It may be a little confusing, but it seems to work.
2020-03-25 07:18:14 +00:00
// The mutex is unlocked at the top of the loop and locked again
// (for broadcast) at the bottom, then finally unlocked after the loop.
// It should be only the data availability check that's not threadsafe
// as the mutex is not released until after the data has been written to
// the buffer.
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
while ((avail = RB_DATA_AVAILABLE (res->commands.pipe)) >= 2
&& avail >= (len = qwaq_cmd_peek (res, 1))) {
pthread_mutex_unlock (&res->commands.pipe_cond.mut);
[qwaq] Begin move over to threading Of course, it currently locks up, but there aren't any other threads as of yet so the queues starve.
2020-03-19 23:48:40 +00:00
dump_command (res, len);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_commands cmd = qwaq_cmd_peek (res, 0);
[qwaq] Add debug output to the command queue Be sure to redirect stderr or the screen will get messed up
2020-03-05 15:30:11 +00:00
switch (cmd) {
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
case qwaq_cmd_syncprint:
cmd_syncprint (res);
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_newwin:
cmd_newwin (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_delwin:
cmd_delwin (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
case qwaq_cmd_getwrect:
cmd_getwrect (res);
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_new_panel:
cmd_new_panel (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_del_panel:
cmd_del_panel (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
case qwaq_cmd_hide_panel:
cmd_hide_panel (res);
break;
case qwaq_cmd_show_panel:
cmd_show_panel (res);
break;
case qwaq_cmd_top_panel:
cmd_top_panel (res);
break;
case qwaq_cmd_bottom_panel:
cmd_bottom_panel (res);
break;
case qwaq_cmd_move_panel:
cmd_move_panel (res);
break;
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
case qwaq_cmd_panel_window:
cmd_panel_window (res);
break;
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
case qwaq_cmd_replace_panel:
cmd_replace_panel (res);
break;
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
case qwaq_cmd_update_panels:
cmd_update_panels (res);
break;
case qwaq_cmd_doupdate:
cmd_doupdate (res);
break;
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
case qwaq_cmd_mvwaddstr:
cmd_mvwaddstr (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
break;
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
case qwaq_cmd_waddstr:
cmd_waddstr (res);
break;
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
case qwaq_cmd_mvwaddch:
cmd_mvwaddch (res);
break;
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
case qwaq_cmd_waddch:
cmd_waddch (res);
break;
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
case qwaq_cmd_wrefresh:
cmd_wrefresh (res);
break;
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
case qwaq_cmd_init_pair:
cmd_init_pair (res);
break;
case qwaq_cmd_wbkgd:
cmd_wbkgd (res);
break;
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
case qwaq_cmd_werase:
cmd_werase (res);
break;
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
case qwaq_cmd_scrollok:
cmd_scrollok (res);
break;
[qwaq] Add wrapper for wmove
2021-06-07 06:53:35 +00:00
case qwaq_cmd_wmove:
cmd_wmove (res);
break;
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
case qwaq_cmd_move:
cmd_move (res);
break;
case qwaq_cmd_curs_set:
cmd_curs_set (res);
break;
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
case qwaq_cmd_wborder:
cmd_wborder (res);
break;
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
case qwaq_cmd_mvwblit_line:
cmd_mvwblit_line (res);
break;
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
case qwaq_cmd_wresize:
cmd_wresize (res);
break;
case qwaq_cmd_resizeterm:
cmd_resizeterm (res);
break;
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
case qwaq_cmd_mvwhline:
cmd_mvwhline (res);
break;
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
case qwaq_cmd_mvwvline:
cmd_mvwvline (res);
break;
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
pthread_mutex_lock (&res->commands.pipe_cond.mut);
RB_RELEASE (res->commands.pipe, len);
pthread_cond_broadcast (&res->commands.pipe_cond.wcond);
[qwaq] Close up race-condition hole After a lot of thought, I have come to the conclusion that the weird crash the other day was caused by a race while the command ring buffer had just been emptied: the command submission code opened up space for writing, threads switched, and command processing saw the available data and pounced on it before the submit code could write valid data. Thus include the while header in the lock, and move the loop-end release outside the lock. It may be a little confusing, but it seems to work.
2020-03-25 07:18:14 +00:00
// unlocked at top of top if there's more data, otherwise just after
// the loop
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
pthread_mutex_unlock (&res->commands.pipe_cond.mut);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static int need_endwin;
static void
[util] Pass a data pointer to shutdown functions And clean up the mess.
2020-03-21 13:24:11 +00:00
bi_shutdown (void *_pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
if (need_endwin) {
[qwaq] Disable xterm mouse handling on shutdown Getting mouse escape codes on the command line is not very pleasant (even if display-only).
2021-10-29 01:16:42 +00:00
qwaq_input_disable_mouse ();
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
endwin ();
}
}
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
static void
bi_syncprintf (progs_t *pr)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
const char *fmt = P_GSTRING (pr, 0);
int count = pr->pr_argc - 1;
pr_type_t **args = pr->pr_params + 1;
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int string_id = qwaq_pipe_acquire_string (&res->commands);
dstring_t *print_buffer = qwaq_cmd_string (res, string_id);
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
int command[] = { qwaq_cmd_syncprint, 0, string_id };
command[1] = CMD_SIZE(command);
dstring_clearstr (print_buffer);
PR_Sprintf (pr, print_buffer, "mvwaddstr", fmt, count, args);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add a synchronous printf command This puts a print command (to Sys_Printf) into the queue making it easier to check command sequences since regular printf is asynchronous with the stream.
2020-03-30 12:58:06 +00:00
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi_create_window (progs_t *pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
int xpos = P_INT (pr, 0);
int ypos = P_INT (pr, 1);
int xlen = P_INT (pr, 2);
int ylen = P_INT (pr, 3);
int command[] = {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
qwaq_cmd_newwin, 0,
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
xpos, ypos, xlen, ylen,
};
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
int cmd_result[2];
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_receive (&res->results, cmd_result, qwaq_cmd_newwin,
CMD_SIZE (cmd_result));
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
R_INT (pr) = cmd_result[1];
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi_destroy_window (progs_t *pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
int window_id = P_INT (pr, 0);
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int command[] = { qwaq_cmd_delwin, 0, window_id, };
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_getwrect (progs_t *pr, int window_id)
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_getwrect, 0, window_id, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
int cmd_result[5];
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_receive (&res->results, cmd_result, qwaq_cmd_getwrect,
CMD_SIZE (cmd_result));
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
// return xpos, ypos, xlen, ylen
(&R_INT (pr))[0] = cmd_result[1];
(&R_INT (pr))[1] = cmd_result[2];
(&R_INT (pr))[2] = cmd_result[3];
(&R_INT (pr))[3] = cmd_result[4];
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
}
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_getwrect (progs_t *pr)
{
qwaq_getwrect (pr, P_INT (pr, 0));
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi_create_panel (progs_t *pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
int window_id = P_INT (pr, 0);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Rename the internal function names Now they reflect the curses functions they wrap. The externally visible builtin names are not changed because the parameters are in x, y order rather than curses' y, x order.
2020-02-29 03:46:25 +00:00
int command[] = { qwaq_cmd_new_panel, 0, window_id, };
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
int cmd_result[2];
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_receive (&res->results, cmd_result, qwaq_cmd_new_panel,
CMD_SIZE (cmd_result));
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
R_INT (pr) = cmd_result[1];
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
static void
panel_command (progs_t *pr, qwaq_commands cmd)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
int panel_id = P_INT (pr, 0);
if (get_panel (res, __FUNCTION__, panel_id)) {
int command[] = { cmd, 0, panel_id, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
}
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi_destroy_panel (progs_t *pr)
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
{
panel_command (pr, qwaq_cmd_del_panel);
}
static void
bi_hide_panel (progs_t *pr)
{
panel_command (pr, qwaq_cmd_hide_panel);
}
static void
bi_show_panel (progs_t *pr)
{
panel_command (pr, qwaq_cmd_show_panel);
}
static void
bi_top_panel (progs_t *pr)
{
panel_command (pr, qwaq_cmd_top_panel);
}
static void
bi_bottom_panel (progs_t *pr)
{
panel_command (pr, qwaq_cmd_bottom_panel);
}
static void
bi_move_panel (progs_t *pr)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
int panel_id = P_INT (pr, 0);
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
if (get_panel (res, __FUNCTION__, panel_id)) {
[qwaq] Implement the immediately useful panel functions
2020-02-29 04:06:58 +00:00
int command[] = { qwaq_cmd_move_panel, 0, panel_id, x, y, };
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Convert remaining functions to command queue Now that the initial prototype seems to be working well, it's time to implement more commands. I might have to do some wrappers for actual command writing (and result reading) as it looks like there will be a lot of nearly identical code.
2020-02-29 02:44:43 +00:00
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
bi_panel_window (progs_t *pr)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
int panel_id = P_INT (pr, 0);
if (get_panel (res, __FUNCTION__, panel_id)) {
int command[] = { qwaq_cmd_panel_window, 0, panel_id, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
int cmd_result[2];
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_receive (&res->results, cmd_result, qwaq_cmd_panel_window,
CMD_SIZE (cmd_result));
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
(&R_INT (pr))[0] = cmd_result[1];
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
}
}
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
static void
bi_replace_panel (progs_t *pr)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
int panel_id = P_INT (pr, 0);
int window_id = P_INT (pr, 1);
if (get_panel (res, __FUNCTION__, panel_id)
&& get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_replace_panel, 0,
panel_id, window_id};
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
}
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
[qwaq] Add -refresh to TextContext This does the right thing in the presence of panels and dealing with stdscr.
2020-03-12 17:43:01 +00:00
qwaq_update_panels (progs_t *pr)
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
int command[] = { qwaq_cmd_update_panels, 0, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
}
[qwaq] Add -refresh to TextContext This does the right thing in the presence of panels and dealing with stdscr.
2020-03-12 17:43:01 +00:00
static void
bi_update_panels (progs_t *pr)
{
qwaq_update_panels (pr);
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
[qwaq] Add -refresh to TextContext This does the right thing in the presence of panels and dealing with stdscr.
2020-03-12 17:43:01 +00:00
qwaq_doupdate (progs_t *pr)
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
int command[] = { qwaq_cmd_doupdate, 0, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
}
[qwaq] Add -refresh to TextContext This does the right thing in the presence of panels and dealing with stdscr.
2020-03-12 17:43:01 +00:00
static void
bi_doupdate (progs_t *pr)
{
qwaq_doupdate (pr);
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
static void
qwaq_waddstr (progs_t *pr, int window_id, const char *str)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int string_id = qwaq_pipe_acquire_string (&res->commands);
dstring_t *print_buffer = qwaq_cmd_string (res, string_id);
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
int command[] = {
qwaq_cmd_waddstr, 0,
window_id, string_id
};
command[1] = CMD_SIZE(command);
dstring_copystr (print_buffer, str);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
}
}
static void
bi_waddstr (progs_t *pr)
{
int window_id = P_INT (pr, 0);
const char *str = P_GSTRING (pr, 1);
qwaq_waddstr (pr, window_id, str);
}
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
static void
qwaq_wresize (progs_t *pr, int window_id, int width, int height)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = {
qwaq_cmd_wresize, 0,
window_id, width, height
};
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
}
}
static void
bi_wresize (progs_t *pr)
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
int width = P_INT (pr, 1);
int height = P_INT (pr, 2);
qwaq_wresize (pr, window_id, width, height);
}
static void
qwaq_resizeterm (progs_t *pr, int width, int height)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
int command[] = { qwaq_cmd_resizeterm, 0, width, height };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
}
static void
bi_resizeterm (progs_t *pr)
{
int width = P_INT (pr, 0);
int height = P_INT (pr, 1);
qwaq_resizeterm (pr, width, height);
}
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
static void
qwaq_mvwhline (progs_t *pr, int window_id, int x, int y, int ch, int n)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = {
qwaq_cmd_mvwhline, 0,
window_id, x, y, ch, n
};
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
}
}
static void
bi_mvwhline (progs_t *pr)
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
int ch = P_INT (pr, 3);
int n = P_INT (pr, 4);
qwaq_mvwhline (pr, window_id, x, y, ch, n);
}
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
static void
qwaq_mvwvline (progs_t *pr, int window_id, int x, int y, int ch, int n)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = {
qwaq_cmd_mvwvline, 0,
window_id, x, y, ch, n
};
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
}
}
static void
bi_mvwvline (progs_t *pr)
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
int ch = P_INT (pr, 3);
int n = P_INT (pr, 4);
qwaq_mvwvline (pr, window_id, x, y, ch, n);
}
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
static void
qwaq_mvwaddstr (progs_t *pr, int window_id, int x, int y, const char *str)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int string_id = qwaq_pipe_acquire_string (&res->commands);
dstring_t *print_buffer = qwaq_cmd_string (res, string_id);
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
int command[] = {
qwaq_cmd_mvwaddstr, 0,
window_id, x, y, string_id
};
command[1] = CMD_SIZE(command);
dstring_copystr (print_buffer, str);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
}
}
static void
bi_mvwaddstr (progs_t *pr)
{
int window_id = P_INT (pr, 0);
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
const char *str = P_GSTRING (pr, 3);
qwaq_mvwaddstr (pr, window_id, x, y, str);
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_mvwprintf (progs_t *pr, int window_id, int x, int y, const char *fmt,
int count, pr_type_t **args)
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int string_id = qwaq_pipe_acquire_string (&res->commands);
dstring_t *print_buffer = qwaq_cmd_string (res, string_id);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
int command[] = {
qwaq_cmd_mvwaddstr, 0,
window_id, x, y, string_id
};
command[1] = CMD_SIZE(command);
dstring_clearstr (print_buffer);
PR_Sprintf (pr, print_buffer, "mvwaddstr", fmt, count, args);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
}
}
static void
bi_mvwprintf (progs_t *pr)
{
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
int window_id = P_INT (pr, 0);
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
const char *fmt = P_GSTRING (pr, 3);
int count = pr->pr_argc - 4;
pr_type_t **args = pr->pr_params + 4;
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_mvwprintf (pr, window_id, x, y, fmt, count, args);
}
static void
qwaq_wprintf (progs_t *pr, int window_id, const char *fmt,
int count, pr_type_t **args)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int string_id = qwaq_pipe_acquire_string (&res->commands);
dstring_t *print_buffer = qwaq_cmd_string (res, string_id);
[qwaq] Validate window before acquiring string If the window is invalid and recovery is done, string ids will leak if acquired before validation. Afterwards, make the rest of the builtin wrappers consistent: extract parameters, validate, [acquire resources], generate command.
2020-02-29 03:33:45 +00:00
int command[] = {
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_cmd_waddstr, 0,
window_id, string_id
[qwaq] Validate window before acquiring string If the window is invalid and recovery is done, string ids will leak if acquired before validation. Afterwards, make the rest of the builtin wrappers consistent: extract parameters, validate, [acquire resources], generate command.
2020-02-29 03:33:45 +00:00
};
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
command[1] = CMD_SIZE(command);
dstring_clearstr (print_buffer);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
PR_Sprintf (pr, print_buffer, "waddstr", fmt, count, args);
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
static void
bi_wprintf (progs_t *pr)
{
int window_id = P_INT (pr, 0);
const char *fmt = P_GSTRING (pr, 1);
int count = pr->pr_argc - 2;
pr_type_t **args = pr->pr_params + 2;
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_wprintf (pr, window_id, fmt, count, args);
}
static void
qwaq_wvprintf (progs_t *pr, int window_id, const char *fmt, pr_va_list_t *args)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
pr_type_t *list_start = PR_GetPointer (pr, args->list);
pr_type_t **list = alloca (args->count * sizeof (*list));
for (int i = 0; i < args->count; i++) {
list[i] = list_start + i * pr->pr_param_size;
}
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int string_id = qwaq_pipe_acquire_string (&res->commands);
dstring_t *print_buffer = qwaq_cmd_string (res, string_id);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
int command[] = {
qwaq_cmd_waddstr, 0,
window_id, string_id
};
command[1] = CMD_SIZE(command);
dstring_clearstr (print_buffer);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
PR_Sprintf (pr, print_buffer, "waddstr", fmt, args->count, list);
[qwaq] Move queue handling into separate functions This makes it so I need to edit only one place when I get threads working. Also, it fixes some bugs (eg, panel creation wasn't implemented correctly).
2020-03-02 09:15:31 +00:00
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Start work on the actual app It doesn't look good, but it does have panel based windows working, and using objects. Won't build reliably right now due to qwaq being in tools and thus building before ruamoko, but I'll fix that next.
2020-02-29 15:40:55 +00:00
}
}
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
static void
bi_wvprintf (progs_t *pr)
{
int window_id = P_INT (pr, 0);
const char *fmt = P_GSTRING (pr, 1);
__auto_type args = (pr_va_list_t *) &P_POINTER (pr, 2);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_wvprintf (pr, window_id, fmt, args);
}
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
static void
qwaq_waddch (progs_t *pr, int window_id, int ch)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_waddch, 0, window_id, ch };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
}
}
static void
bi_waddch (progs_t *pr)
{
int window_id = P_INT (pr, 0);
int ch = P_INT (pr, 0);
qwaq_waddch (pr, window_id, ch);
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
qwaq_mvwvprintf (progs_t *pr, int window_id, int x, int y,
const char *fmt, pr_va_list_t *args)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
pr_type_t *list_start = PR_GetPointer (pr, args->list);
[qwaq] Allocate enough bytes for the args list d'oh
2020-03-04 12:17:17 +00:00
pr_type_t **list = alloca (args->count * sizeof (*list));
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
for (int i = 0; i < args->count; i++) {
list[i] = list_start + i * pr->pr_param_size;
}
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int string_id = qwaq_pipe_acquire_string (&res->commands);
dstring_t *print_buffer = qwaq_cmd_string (res, string_id);
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
int command[] = {
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_cmd_mvwaddstr, 0,
window_id, x, y, string_id
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
};
command[1] = CMD_SIZE(command);
dstring_clearstr (print_buffer);
PR_Sprintf (pr, print_buffer, "waddstr", fmt, args->count, list);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
}
}
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
bi_mvwvprintf (progs_t *pr)
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
{
int window_id = P_INT (pr, 0);
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
const char *fmt = P_GSTRING (pr, 2);
__auto_type args = (pr_va_list_t *) &P_POINTER (pr, 3);
[qwaq] Correct mangled params to qwaq_mvwvprintf
2020-03-26 00:07:19 +00:00
qwaq_mvwvprintf (pr, window_id, x, y, fmt, args);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
}
static void
qwaq_mvwaddch (progs_t *pr, int window_id, int x, int y, int ch)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = {
qwaq_cmd_mvwaddch, 0,
window_id, x, y, ch
};
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
}
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_mvwaddch (progs_t *pr)
{
int window_id = P_INT (pr, 0);
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
int ch = P_INT (pr, 3);
qwaq_mvwaddch (pr, window_id, x, y, ch);
}
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_wrefresh (progs_t *pr, int window_id)
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_wrefresh, 0, window_id, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
}
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_wrefresh (progs_t *pr)
{
int window_id = P_INT (pr, 0);
qwaq_wrefresh (pr, window_id);
}
[qwaq] Don't call wrefresh in cmd_mvwaddstr There is now an implementation for wrefresh.
2020-02-29 05:43:08 +00:00
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
static void
bi_max_colors (progs_t *pr)
{
R_INT (pr) = COLORS;
}
static void
bi_max_color_pairs (progs_t *pr)
{
R_INT (pr) = COLOR_PAIRS;
}
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_init_pair (progs_t *pr, int pair, int f, int b)
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
int command[] = { qwaq_cmd_init_pair, 0, pair, f, b, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_init_pair (progs_t *pr)
{
int pair = P_INT (pr, 0);
int f = P_INT (pr, 1);
int b = P_INT (pr, 2);
qwaq_init_pair (pr, pair, f, b);
}
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_wbkgd (progs_t *pr, int window_id, int ch)
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_wbkgd, 0, window_id, ch, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
}
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_wbkgd (progs_t *pr)
{
int window_id = P_INT (pr, 0);
int ch = P_INT (pr, 1);
qwaq_wbkgd (pr, window_id, ch);
}
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
static void
qwaq_werase (progs_t *pr, int window_id, int ch)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_werase, 0, window_id, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
}
}
static void
bi_werase (progs_t *pr)
{
int window_id = P_INT (pr, 0);
int ch = P_INT (pr, 1);
qwaq_werase (pr, window_id, ch);
}
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_scrollok (progs_t *pr, int window_id, int flag)
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_scrollok, 0, window_id, flag, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
}
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_scrollok (progs_t *pr)
{
int window_id = P_INT (pr, 0);
int flag = P_INT (pr, 1);
qwaq_scrollok (pr, window_id, flag);
}
[qwaq] Fail at object oriented design 101 This is horrible, doesn't work, isn't really the direction I want to go (that became apparent while implementing Screen's handleEvent) and crashes anyway (Array and not-id...) *sigh* Still, this does have some good stuff in it, and it pushed qfcc along some more.
2020-03-03 12:30:47 +00:00
[qwaq] Add wrapper for wmove
2021-06-07 06:53:35 +00:00
static void
qwaq_wmove (progs_t *pr, int window_id, int x, int y)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add wrapper for wmove
2021-06-07 06:53:35 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_wmove, 0, window_id, x, y, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add wrapper for wmove
2021-06-07 06:53:35 +00:00
}
}
static void
bi_wmove (progs_t *pr)
{
int window_id = P_INT (pr, 0);
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
qwaq_wmove (pr, window_id, x, y);
}
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
static const char qwaq_acs_char_map[] = "lmkjtuvwqxnos`afg~,+.-hi0pryz{|}";
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_acs_char (progs_t *pr, unsigned acs)
[qwaq] Add mvwaddch and ACS support
2020-03-02 09:24:45 +00:00
{
if (acs < 256) {
R_INT (pr) = NCURSES_ACS(acs);
} else if (acs - 256 < sizeof (qwaq_acs_char_map)) {
R_INT (pr) = NCURSES_ACS(qwaq_acs_char_map[acs - 256]);
} else {
R_INT (pr) = 0;
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
}
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_acs_char (progs_t *pr)
{
int acs = P_INT (pr, 0);
qwaq_acs_char (pr, acs);
}
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_move (progs_t *pr, int x, int y)
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
int command[] = { qwaq_cmd_move, 0, x, y, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_move (progs_t *pr)
{
int x = P_INT (pr, 0);
int y = P_INT (pr, 1);
qwaq_move (pr, x, y);
}
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_curs_set (progs_t *pr, int visibility)
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
int command[] = { qwaq_cmd_curs_set, 0, visibility, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_curs_set (progs_t *pr)
{
int visibility = P_INT (pr, 0);
qwaq_curs_set (pr, visibility);
}
[qwaq] Add Group and clean up lots of mess Things are finally doing something again, and getting closer to having a moveable window.
2020-03-05 06:44:53 +00:00
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
static void
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_wborder (progs_t *pr, int window_id,
box_sides_t sides, box_corners_t corns)
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
int command[] = { qwaq_cmd_wborder, 0, window_id,
sides.ls, sides.rs, sides.ts, sides.bs,
corns.tl, corns.tr, corns.bl, corns.br, };
command[1] = CMD_SIZE(command);
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
}
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
bi_wborder (progs_t *pr)
{
int window_id = P_INT (pr, 0);
__auto_type sides = P_PACKED (pr, box_sides_t, 1);
__auto_type corns = P_PACKED (pr, box_corners_t, 2);
qwaq_wborder (pr, window_id, sides, corns);
}
[qwaq] Add wborder command
2020-03-05 15:31:29 +00:00
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
static void
qwaq__mvwblit_line (progs_t *pr, int window_id, int x, int y,
int *chs, int len)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
if (get_window (res, __FUNCTION__, window_id)) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
int chs_id = qwaq_pipe_acquire_string (&res->commands);
dstring_t *chs_buf = qwaq_cmd_string (res, chs_id);
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
int command[] = { qwaq_cmd_mvwblit_line, 0, window_id,
x, y, chs_id, len,};
command[1] = CMD_SIZE(command);
chs_buf->size = len * sizeof (int);
dstring_adjust (chs_buf);
memcpy (chs_buf->str, chs, len * sizeof (int));
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_pipe_submit (&res->commands, command, command[1]);
[qwaq] Add an mvwblit_line builtin I had to do my own thing with curses as the function I had planned to use turned out to be quite different from what I wanted (misread the man page).
2020-03-10 09:21:06 +00:00
}
}
static void
bi_mvwblit_line (progs_t *pr)
{
int window_id = P_INT (pr, 0);
int x = P_INT (pr, 1);
int y = P_INT (pr, 2);
int *chs = (int *) P_GPOINTER (pr, 3);
int len = P_INT (pr, 4);
qwaq__mvwblit_line (pr, window_id, x, y, chs, len);
}
[qwaq] Start threads for progs and curses No idea if anything works, probably come crashing down in a flaming pile of debris.
2020-03-20 15:01:36 +00:00
static void *
[qwaq] Pass resource data into the thread Things have come crashing down, but no fire (ie, no deadlocks so far).
2020-03-20 15:14:33 +00:00
qwaq_curses_thread (qwaq_thread_t *thread)
[qwaq] Start threads for progs and curses No idea if anything works, probably come crashing down in a flaming pile of debris.
2020-03-20 15:01:36 +00:00
{
[qwaq] Pass resource data into the thread Things have come crashing down, but no fire (ie, no deadlocks so far).
2020-03-20 15:14:33 +00:00
qwaq_resources_t *res = thread->data;
[qwaq] Start threads for progs and curses No idea if anything works, probably come crashing down in a flaming pile of debris.
2020-03-20 15:01:36 +00:00
while (1) {
process_commands (res);
}
thread->return_code = 0;
return thread;
}
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
static void
bi_initialize (progs_t *pr)
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
initscr ();
need_endwin = 1;
res->initialized = 1;
[qwaq] Implement basic color support
2020-02-29 05:48:18 +00:00
start_color ();
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
raw ();
[qwaq] Bypass ncurses for input handling For now, only 1003 mouse mode is supported, and function keys are not yet supported, but the mouse is much more reliable: no lost events.
2020-03-21 16:00:05 +00:00
keypad (stdscr, FALSE); // do it ourselves
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
noecho ();
nonl ();
nodelay (stdscr, TRUE);
mousemask(ALL_MOUSE_EVENTS | REPORT_MOUSE_POSITION, NULL);
refresh();
[qwaq] Make stdscr available to progs
2020-02-29 05:38:54 +00:00
[qwaq] Separate out mouse (de)init code This is the simplest fix for the curses/input initialization order issue. The terminal io code should still be moved to its own file, really, but I think it can wait.
2021-09-23 04:14:42 +00:00
qwaq_input_enable_mouse ();
[qwaq] Make stdscr available to progs
2020-02-29 05:38:54 +00:00
res->stdscr.win = stdscr;
[qwaq] Start threads for progs and curses No idea if anything works, probably come crashing down in a flaming pile of debris.
2020-03-20 15:01:36 +00:00
[qwaq] Pass resource data into the thread Things have come crashing down, but no fire (ie, no deadlocks so far).
2020-03-20 15:14:33 +00:00
create_thread (qwaq_curses_thread, res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__is_initialized (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
qwaq_resources_t *res = PR_Resources_Find (pr, "curses");
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
R_INT (pr) = res->initialized;
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__max_colors (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
bi_max_colors (pr);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__max_color_pairs (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
bi_max_color_pairs (pr);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__init_pair_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int pair = P_INT (pr, 2);
int f = P_INT (pr, 3);
int b = P_INT (pr, 4);
qwaq_init_pair (pr, pair, f, b);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__acs_char_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int acs = P_INT (pr, 2);
qwaq_acs_char (pr, acs);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__move_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
Point *pos = &P_PACKED (pr, Point, 2);
qwaq_move (pr, pos->x, pos->y);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__curs_set_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int visibility = P_INT (pr, 2);
qwaq_curs_set (pr, visibility);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__doupdate (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
bi_doupdate (pr);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__mvprintf_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
Point *pos = &P_PACKED (pr, Point, 2);
const char *fmt = P_GSTRING (pr, 3);
int count = pr->pr_argc - 4;
pr_type_t **args = pr->pr_params + 4;
qwaq_mvwprintf (pr, window_id, pos->x, pos->y, fmt, count, args);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__printf_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
const char *fmt = P_GSTRING (pr, 2);
int count = pr->pr_argc - 3;
pr_type_t **args = pr->pr_params + 3;
qwaq_wprintf (pr, window_id, fmt, count, args);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__vprintf_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
const char *fmt = P_GSTRING (pr, 2);
__auto_type args = (pr_va_list_t *) &P_POINTER (pr, 3);
qwaq_wvprintf (pr, window_id, fmt, args);
}
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__addch_ (progs_t *pr)
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
int ch = P_INT (pr, 2);
[qwaq] Implement missing addch I either forgot about it, or just didn't need it at the time, but I'm sure it will be useful later when more stuff is implemented.
2020-03-06 08:57:33 +00:00
qwaq_waddch (pr, window_id, ch);
}
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__addstr_ (progs_t *pr)
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
const char *str = P_GSTRING (pr, 2);
qwaq_waddstr (pr, window_id, str);
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__mvvprintf_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
Point *pos = &P_PACKED (pr, Point, 2);
const char *fmt = P_GSTRING (pr, 3);
[qwaq] Correct mangled params to qwaq_mvwvprintf
2020-03-26 00:07:19 +00:00
__auto_type args = &P_PACKED (pr, pr_va_list_t, 4);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
[qwaq] Correct mangled params to qwaq_mvwvprintf
2020-03-26 00:07:19 +00:00
qwaq_mvwvprintf (pr, window_id, pos->x, pos->y, fmt, args);
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
}
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__resizeTo_ (progs_t *pr)
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
{
__auto_type self = &P_STRUCT (pr, qwaq_textcontext_t, 0);
int window_id = self->window;
self->size = P_PACKED (pr, Extent, 2);
qwaq_wresize (pr, window_id, self->size.width, self->size.height);
if (window_id == 1) {
qwaq_wbkgd (pr, window_id, self->background);
}
}
[qwaq] Add -refresh to TextContext This does the right thing in the presence of panels and dealing with stdscr.
2020-03-12 17:43:01 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__c_TextContext__refresh (progs_t *pr)
[qwaq] Add -refresh to TextContext This does the right thing in the presence of panels and dealing with stdscr.
2020-03-12 17:43:01 +00:00
{
qwaq_update_panels (pr);
qwaq_doupdate (pr);
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__refresh (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
[qwaq] Add -refresh to TextContext This does the right thing in the presence of panels and dealing with stdscr.
2020-03-12 17:43:01 +00:00
qwaq_update_panels (pr);
if (window_id == 1) {
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_wrefresh (pr, window_id);
[qwaq] Add -refresh to TextContext This does the right thing in the presence of panels and dealing with stdscr.
2020-03-12 17:43:01 +00:00
qwaq_doupdate (pr);
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__mvaddch_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
Point *pos = &P_PACKED (pr, Point, 2);
int ch = P_INT (pr, 3);
qwaq_mvwaddch (pr, window_id, pos->x, pos->y, ch);
}
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__mvaddstr_ (progs_t *pr)
[qwaq] Implement more curses wrappers
2020-03-17 05:05:31 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
Point *pos = &P_PACKED (pr, Point, 2);
const char *str = P_GSTRING (pr, 3);
qwaq_mvwaddstr (pr, window_id, pos->x, pos->y, str);
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__bkgd_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
__auto_type self = &P_STRUCT (pr, qwaq_textcontext_t, 0);
int window_id = self->window;
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
int ch = P_INT (pr, 2);
[qwaq] Implement resizing Terminal resize is detected and the views adjust appropriately (well, those for which I've set grow flags: the window title bar doesn't adjust yet).
2020-03-23 11:14:32 +00:00
self->background = ch;
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
qwaq_wbkgd (pr, window_id, ch);
}
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__clear (progs_t *pr)
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
{
[qwaq] Clean up QwaqApplication It doesn't need to be fun little tests any more.
2020-03-24 16:06:20 +00:00
__auto_type self = &P_STRUCT (pr, qwaq_textcontext_t, 0);
int window_id = self->window;
int ch = self->background;
[qwaq] Add wrappers for werase
2020-03-19 09:36:15 +00:00
qwaq_werase (pr, window_id, ch);
}
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__scrollok_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
int flag = P_INT (pr, 2);
qwaq_scrollok (pr, window_id, flag);
}
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__border_ (progs_t *pr)
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
{
int window_id = P_STRUCT (pr, qwaq_textcontext_t, 0).window;
__auto_type sides = P_PACKED (pr, box_sides_t, 2);
__auto_type corns = P_PACKED (pr, box_corners_t, 3);
qwaq_wborder (pr, window_id, sides, corns);
}
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__mvhline_ (progs_t *pr)
[qwaq] Implement rectangular region clearing You'd think ncurses would have this, but I guess it's too window-oriented.
2020-03-28 00:41:54 +00:00
{
__auto_type self = &P_STRUCT (pr, qwaq_textcontext_t, 0);
int window_id = self->window;
__auto_type pos = &P_PACKED (pr, Point, 2);
int ch = P_INT (pr, 3);
int n = P_INT (pr, 4);
qwaq_mvwhline (pr, window_id, pos->x, pos->y, ch, n);
}
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
static void
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi__i_TextContext__mvvline_ (progs_t *pr)
[qwaq] Add a scrollbar view
2020-03-30 11:29:48 +00:00
{
__auto_type self = &P_STRUCT (pr, qwaq_textcontext_t, 0);
int window_id = self->window;
__auto_type pos = &P_PACKED (pr, Point, 2);
int ch = P_INT (pr, 3);
int n = P_INT (pr, 4);
qwaq_mvwvline (pr, window_id, pos->x, pos->y, ch, n);
}
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static void
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
bi_curses_clear (progs_t *pr, void *data)
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{
__auto_type res = (qwaq_resources_t *) data;
if (res->initialized) {
[qwaq] Separate out mouse (de)init code This is the simplest fix for the curses/input initialization order issue. The terminal io code should still be moved to its own file, really, but I think it can wait.
2021-09-23 04:14:42 +00:00
qwaq_input_disable_mouse ();
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
endwin ();
}
need_endwin = 0;
window_reset (res);
[qwaq] Prepare for threading So far, no threading has been set up, and only window creation and printing have been updated, but the basics of the design seem to be sound. The builtin functions now no longer call ncurses directly: the build commands and write them to a command buffer. Commands that have return values (eg, window creation) write their results to a results buffer that the originating builtin function reads. Builtin functions that expect a result "poll" the results buffer for the correct result (marked by the same command). In a single UI-thread environment, the results should always be in the same order as the commands, and in a multi-UI-thread environment, things should (fingers crossed) sort themselves out as ONE of the threads will be the originator of the next available result. Strings in commands (eg, for printing) are handled by acquiring a string id (index into an array of dstring_t) and including the string id in the written command. The string id is released upon completion of the command. Builtin functions write commands, acquire string ids, and read results. The command processor reads commands, releases string ids, and writes results. Since commands, string ids, and results are all in ring buffers, and assuming there is only one thread running the builtin functions and only one thread processing commands (there can be only one because ncurses is not thread-safe), then there should never be any contention on the buffers. Of course, if there are multiple threads running the builtin functions, then locking will be required on the builtin function side.
2020-02-28 16:45:33 +00:00
panel_reset (res);
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
}
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
#define bi(x,np,params...) {#x, bi_##x, -1, np, {params}}
#define p(type) PR_PARAM(type)
#define P(a, s) { .size = (s), .alignment = BITOP_LOG2 (a), }
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
static builtin_t builtins[] = {
[gamecode] Provide builtins with information about their parameters This will make it possible for the engine to set up their parameter pointers when running Ruamoko progs. At this stage, it doesn't matter *too* much, except for varargs functions, because no builtin yet takes anything larger than a float quaternion, but it will be critical when double or long vec3 and vec4 values are passed.
2022-01-23 12:54:03 +00:00
bi(initialize, 0),
bi(syncprintf, -2, p(string)),
bi(create_window, 4, p(int), p(int), p(int), p(int)),
bi(destroy_window, 1, p(ptr)),
bi(getwrect, 1, p(ptr)),
bi(create_panel, 1, p(ptr)),
bi(destroy_panel, 1, p(ptr)),
bi(hide_panel, 1, p(ptr)),
bi(show_panel, 1, p(ptr)),
bi(top_panel, 1, p(ptr)),
bi(bottom_panel, 1, p(ptr)),
bi(move_panel, 3, p(ptr), p(int), p(int)),
bi(panel_window, 1, p(ptr)),
bi(replace_panel, 2, p(ptr), p(ptr)),
bi(update_panels, 0),
bi(doupdate, 0),
bi(mvwprintf, -5, p(ptr), p(int), p(int), p(string)),
bi(wprintf, -3, p(ptr), p(string)),
bi(wvprintf, 3, p(ptr), p(string), P(1, 2)),
bi(mvwvprintf, 5, p(ptr), p(int), p(int), p(string), P(1, 2)),
bi(mvwaddch, 4, p(ptr), p(int), p(int), p(int)),
bi(waddch, 2, p(ptr), p(int)),
bi(mvwaddstr, 4, p(ptr), p(int), p(int), p(string)),
bi(waddstr, 2, p(ptr), p(string)),
bi(wrefresh, 1, p(ptr)),
bi(max_colors, 0),
bi(max_color_pairs, 0),
bi(init_pair, 3, p(int), p(int), p(int)),
bi(wbkgd, 2, p(ptr), p(int)),
bi(werase, 1, p(ptr)),
bi(scrollok, 2, p(ptr), p(int)),
bi(wmove, 3, p(ptr), p(int), p(int), p(int)),
bi(acs_char, 1, p(int)),
bi(move, 2, p(int), p(int)),
bi(curs_set, 1, p(int)),
bi(wborder, 3, p(ptr), P(1, 4), P(1, 4)),
bi(mvwblit_line, 5, p(ptr), p(int), p(int), p(ptr), p(int)),
bi(wresize, 3, p(ptr), p(int), p(int)),
bi(resizeterm, 2, p(int), p(int)),
bi(mvwhline, 5, p(ptr), p(int), p(int), p(int), p(int)),
bi(mvwvline, 5, p(ptr), p(int), p(int), p(int), p(int)),
bi(_c_TextContext__is_initialized, 2, p(ptr), p(ptr)),
bi(_c_TextContext__max_colors, 2, p(ptr), p(ptr)),
bi(_c_TextContext__max_color_pairs, 2, p(ptr), p(ptr)),
bi(_c_TextContext__init_pair_, 5, p(ptr), p(ptr),
p(int), p(int), p(int)),
bi(_c_TextContext__acs_char_, 3, p(ptr), p(ptr),
p(int)),
bi(_c_TextContext__move_, 3, p(ptr), p(ptr),
P(1, 2)),
bi(_c_TextContext__curs_set_, 3, p(ptr), p(ptr),
p(int)),
bi(_c_TextContext__doupdate, 2, p(ptr), p(ptr)),
bi(_i_TextContext__mvprintf_, -5, p(ptr), p(ptr),
P(1, 2), p(string)),
bi(_i_TextContext__printf_, -4, p(ptr), p(ptr),
p(string)),
bi(_i_TextContext__vprintf_, 4, p(ptr), p(ptr),
p(string), P(1, 2)),
bi(_i_TextContext__addch_, 3, p(ptr), p(ptr),
p(int)),
bi(_i_TextContext__addstr_, 3, p(ptr), p(ptr),
p(string)),
bi(_i_TextContext__mvvprintf_, 5, p(ptr), p(ptr),
P(1, 2), p(string), P(1, 2)),
bi(_i_TextContext__resizeTo_, 3, p(ptr), p(ptr),
P(1, 2)),
bi(_c_TextContext__refresh, 2, p(ptr), p(ptr)),
bi(_i_TextContext__refresh, 2, p(ptr), p(ptr)),
bi(_i_TextContext__mvaddch_, 4, p(ptr), p(ptr),
P(1, 2), p(int)),
bi(_i_TextContext__mvaddstr_, 4, p(ptr), p(ptr),
P(1, 2), p(string)),
bi(_i_TextContext__bkgd_, 3, p(ptr), p(ptr),
p(int)),
bi(_i_TextContext__clear, 2, p(ptr), p(ptr)),
bi(_i_TextContext__scrollok_, 3, p(ptr), p(ptr),
p(int)),
bi(_i_TextContext__border_, 4, p(ptr), p(ptr),
P(1, 4), P(1, 4)),
bi(_i_TextContext__mvhline_, 5, p(ptr), p(ptr),
P(1, 2), p(int), p(int)),
bi(_i_TextContext__mvvline_, 5, p(ptr), p(ptr),
P(1, 2), p(int), p(int)),
[qwaq] Create a TextContext class It is essentially just a wrapper around the window versions of ncurses functions.
2020-03-06 04:54:46 +00:00
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
{0}
};
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
void
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
BI_Curses_Init (progs_t *pr)
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
{
Create a basic hello world And it has begun. It has some problems, but worse, it seems I broke qfprogs and maybe pr_debug.c.
2020-02-26 16:18:38 +00:00
qwaq_resources_t *res = calloc (sizeof (*res), 1);
res->pr = pr;
[qwaq] Bypass ncurses for input handling For now, only 1003 mouse mode is supported, and function keys are not yet supported, but the mouse is much more reliable: no lost events.
2020-03-21 16:00:05 +00:00
[qwaq] Add input test app The queues in the curses resources struct have been cleaned up and the threading support code (including for the queues (pipes, really)) has been moved to its own file. The input test app currently just prints the devices and the events as they come in, but demonstrates the new input system working in a separate thread (though it is currently in with the curses thread).
2021-09-21 03:58:10 +00:00
qwaq_init_pipe (&res->commands);
qwaq_init_pipe (&res->results);
[qwaq] Move input handling to its own thread As it is now a completely separate sub-system, there is a bit of trouble with mouse handling in that curses must be initialized before input for the mouse to work properly, but the basic scheme seems to be working nicely. I suspect the solution to the init order issue is to make have the curses sub-system initialize the terminal input driver, at least for mouse input (ie, maybe just enable/disable mouse handing).
2021-09-22 07:22:11 +00:00
PR_Resources_Register (pr, "curses", res, bi_curses_clear);
[gamecode] Add a data pointer passed to builtin functions This is part of the work for #26 (Record resource pointer with builtin function data). Currently, the data pointer gets as far as the per-instance VM function table (I don't feel like tackling the job of converting all the builtin functions tonight). All the builtin modules that register a resources data block pass that block on to PR_RegisterBuiltins.
2022-01-23 15:20:05 +00:00
PR_RegisterBuiltins (pr, builtins, res);
[util] Pass a data pointer to shutdown functions And clean up the mess.
2020-03-21 13:24:11 +00:00
Sys_RegisterShutdown (bi_shutdown, pr);
Start working on a qwaq console tool The intention is it will hopefully become a debugger. It will certainly help with development of the progs engine.
2020-02-26 13:10:59 +00:00
}
Reference in a new issue Copy permalink